＠IT：連載：【改訂版】初歩のUML 第9回
連載 【改訂版】初歩のUML 第9回 UMLベース開発プロセスの流れ 萩本順三 株式会社豆蔵 2003/8/19 今回は、エンタープライズ・システム開発の中でUMLをどのように活用しているのかについて、概要を説明していきます。説明の中では、順平君という架空のエンジニアの経験を通して、単純だった昔のソフトウェア開発の時代から、近代的なエンタープライズ・システム開発の時代まで、エンジニアとして経験していく道のりをたどりながら、その中でUMLモデルがどのような局面で効果的な活用がなされるのか説明していきます。 ◇ステップ1：プログラムする前に設計が必要だと気付く プログラムが単純だった古き良き時代には、順平君は、気が付いたアイデアからいきなりプログラムを書くことがほとんどでした。順平君が作ったプログラムを説明する資料などは1つも作らず、とにかく試行錯誤の中からプログラムを作成していました。 ある
概要設計
■概要設計 ウォータフォール型のシステム開発は、大きく分けると「概要設計」「基本設 計」「プログラム開発・テスト」となります。概要設計は、建築で例えると建 物のコンセプト、規模、仕様、おおまかなデザインなどを決定するフェーズで す。開発が一部のサブシステムなど小規模の場合は、いきなり基本設計から始 める場合もあります。 概要設計は、 （１）システムの目的を認識し、 （２）システムの目標を設定、 （３）システムの目標実現のための業務設計を行い、 （４）プログラム開発するべき機能を洗い出す といった手順で行ないます。 システムの目的とは、顧客が何故システムを新規で開発しようとしているのか、 という事で、例えば本当に一例ですが「全社損益の早期把握」などです。 システムの目標とは、システムの目的の範囲内で実現するべき改善目標です。 上記のシステムの目的の例に対する目標
意図が伝わる設計書作成の心得【第1回】：行きすぎた技術志向
設計書の書き方には絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなる。標準の設計フォームや設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。 一般によく言われることだが，設計書の書き方には「正解」や「こうしなければならない」という絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなり，完成した設計書の内容と質は設計者ごとに大きく異なる――といった結果に陥りやすい。 もちろん，標準の設計フォーム（ひな型）や設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。一
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://72.14.235.104/search?q=cache:fpERNa5FG9oJ:cgi.members.interq.or.jp/cool/k-masuda/FreeStyleWiki/wiki.cgi%3Fpage%3D%25B6%25C8%25CC%25B3%25C0%25DF%25B7%25D7%20%E6%A5%AD%E5%8B%99%E8%A8%AD%E8%A8%88&hl=ja&ct=clnk&cd=3&gl=jp&lr=lang_ja&client=firefox
