@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
設計技術の基礎、基本を勉強し直したい...
«前のページへ
1|2|3|4|5
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-03-17 15:26
はにまるです。
建築設計の話が出たので。 (って、建築設計の「け」の字も知らずに勝手に記述していますよ〜ん) 昔は、設計と言えば、 「木材で家を作ると火に弱く、強度が低いですが、室内の湿度を一定に保ちます。」 「これだけ広い部屋を作るには、中心に柱が無いと強度が保てません。」 など、家の概念が皆一緒だった為、専門的なお話をすれば良かったと思います。 (職人スタイルで習えるレベルの設計技術のお話ですね) ところが、小さな土地や、家の概念が変り、 「窓が多い家にしてって言ったけど、冬は暖房費が掛るじゃ無い!」 「こんな駐車場では、運転の下手な嫁では無理だよ!」 等、家の目的に対する要望が増えてきました。 (業務要件あたりですかね...) そして極めつけ 「売る時に高く売れるような家にしてよ...」 「年取った時の事、考えて欲しかったな...バリアフリーって知らないの?」 等、要望の視点が多様化しています。 (情報化戦略あたりですかね...) 御客と接する設計者は、このレベルの話を全て一人で対応する事が 日常茶飯事では無いでしょうか? 「設計て何?」、「私は何?私は神じゃ無いのよ!」と言いたい所ですが、 でも、自分達が家を建てるなら、確かにこのレベルの注文を 一人の建築設計者に言うんでしょうね。 あ!一戸建ての家を買うお金が無かった!(爆 シ、、システム設計者に愛を... 愛より金かな? | ||||||||
|
投稿日時: 2004-03-17 15:30
個人的な意見ですが、「設計」(設計書のほうが良いかも)というものの位置付けは 実行モジュールに対するソースコードのようなもので、システムの実体が実行モジュール 設計書がソースコードのような位置付けで考えてます。 で、「設計技術」そのものを学術的に定義するのは難しいと思いますが、最初のほうで 議論されていた「設計の目的」という面では学術的な面もあります。 例えば、設計の目的というのを、 ・自分自身の考えを整理、まとめるもの ・開発プロジェクト関係者への伝達の為 ・お客様への伝達の為 ・未来の改造、置換え等の技術者への伝達の為 というような目的を考えると、1つめではシステムや処理を構築する為の技術であったり 考え方の整理学であったりします。2つめ以降のように第3者への伝達という意味では 人に解りやすい設計書の書き方、図、文章の書き方等というように細かい分類のものが 寄せ集まっているものと考えると学術論として語れない訳ではないでしょうね。 (もちろんベースにはITのテクニカル技術という面もありますが) この中で、UML等の設計手法に関しては、ひとつの答えまたは例ということになるのか なぁと。つまり設計技術そのものではなくて、表現方法のひとつという感じですかね。 | ||||||||
|
投稿日時: 2004-03-17 15:33
センスがよければ1年目でもSEやらせてますよ。 期待通り伸びてくれれば2年目ではPLやらせられます。 3年目には営業サポートでしょうか... 「プログラムを作っていく過程で、設計技術の基礎...」はその通りだと思います。ただ、逆も真なりではないのではないかと思います。つまり優秀なプログラマの下積みとして設計だの営業だのを一通り経験しておくのもよいということです。 | ||||||||
|
投稿日時: 2004-03-17 19:28
unibon です。こんにちわ。
この学問は「アプリケーションエンジニア」の範疇ではないでしょうか。情報処理技術者試験の試験区分にもありますよね。あるいは「アプリケーション開発」や「システム開発」(システムはちょっと外れるかも)でしょうか。題名にこれらの言葉が付く書籍を探されてはどうでしょうか。システム設計とか、はたまたシステムエンジニアにいたっては、遠い彼方でしょう。 ちなみにいまどき「アプリケーション」って言っても、ちょっと高尚さが感じられない言葉ですね。でも設計が必要なソフトウェアの多くはアプリケーションのはずです。 | ||||||||
|
投稿日時: 2004-03-18 10:21
そういったことがいいたかったのか初めてわかったような気がする。 あるいはソフトウェア開発技術者試験ですね。でも個人的にいわせてもらえるとこれらの 試験範囲の要素をしらずにいままでやってきたのかな?と考えてしまいます。 そうだとすれば設計技術の基礎を学びたいという気持ちもよくわかる。もちろん仮定の話ですが | ||||||||
|
投稿日時: 2004-03-18 11:29
設計技術に求めている事は、「こんな感じです.」と言う事で
私が書き留めている設計概論を提示します。 下記内容は、業務設計をする者であれば、基礎的な設計技術レベルと思いますが、 実際にはxxxxxって感じですよね。(xxxxは、貴方にお任せ!) しかし、私自信がどれだけ解ってんの?と思います。 別の設計技術を求めるべきか...むむむむって感じです。 -- 設計概論 -------------------------- ここでいうシステムはコンピュータのみで無く、 「仕事の手順」や「組織」も含めます。 1.集計処理について 「A情報→(集計)→B集計」の流れを持つ場合、 「AとBの整合性」が重要となります。 この様な場合、一般的に(集計)の規約に従いAに対し制限を掛けます。 これとは別の話で、情報の信憑性を確保する為、 Bとは別のルートで発生したC情報を用いて B情報とC情報をマッチングし「A情報」、「(集計)」、「B情報」が 正しい事を証明する行為が一般的に発生します。 この際にB情報とC情報が不一致する事があります。 不一致の理由がAの間違であれば、 Aに対する制約を解除し、Aを訂正し「再集計」が出来る機能が必要となります。 ただ、時間経過の問題でAやBを訂正出来ない場合、 A情報に対する別集計が存在する場合、単純再集計を取れない場合があります。 この際は、 次回の(集計)処理で処理するか 差分のみをB’情報として集計する必要があります。 AとBの整合性を無くすと、コンピュータ・システム仕様では楽になりますが、 Bの信憑性はシステム上弱くなり、また「A情報」、「(集計)」の信憑性も弱まり、 システムの品質基準を保持できない場合があります。 2.情報の時系列について マスタは特定期間の情報を保持します。これにより、 1.実社会で状態変化が起きたタイミングと同一タイミングで コンピュータ・システムに状態変更を指示する必要がある。 2.過去のトランザクションを参照した場合、マスタが現時点の状態で 不整合や誤った情報になる。 この状態では利便性が悪く、危険性であり、なにより 時間を追う毎にコンピュータ・システム内部のデータが不整合を起し信憑性を損ないます。 これを回避する為、 1の対策として「マスタの更新予約」、 1と2の対策として「マスタの履歴(世代)管理」 があります。 : (以下省略) |
«前のページへ
1|2|3|4|5