＠IT：連載：【改訂版】初歩のUML
ユースケースとは何か？ なぜ必要か？ 今回は、だれも書いたことがない視点から、オブジェクト技術者が理解しておくべきユースケースモデルについてのノウハウを解説します。そもそも、ソフトウェア開発には、必ず開発を行う目的があります。どんなソフトウェアであってもこの目的がはっきりしないと、よいソフトウェアなど作れるはずがありません。 筆者が初心者のころ、よく「構造化されたソフトウェアを考えてみよう」とか「継承を生かした何らかのソフトウェアを作ってみよう」といったことを計画し、自作ソフトウェアを作ろうと試みたことがありました。しかし、あえなくすべて失敗に終わってしまいました。「構造化」や「オブジェクトテクニック」が目的であっては何も作れないのです。 では、ソフトウェア開発にとって最も重要なことは何でしょうか。そうです、「ソフトウェアがどのような人に、どう使われるか」ということなのです。今回は、UML
Part3 「ライフサイクルフェーズ」と「反復開発」
前回は，UPの基本行動である「ユースケース駆動開発（UCDD）」について解説した。しかしUCDDはあくまで“基本行動”である。実際のUPのプロジェクトでは，UCDDはどのように使われているのだろう。今回は，UPの“プロジェクトの進め方”である「反復」と「ライフサイクルフェーズ」に焦点を当てて解説する。 ソフトウエア開発の世界では，30年前から変わらない2つの原理がある。ソフトウエア開発業界の歴史はこの原理との長い“闘い”の歴史であるとも言える。 「ソフトウエアは，何でもできてしまう」（その結果，顧客の要求に際限がなくなる） 「ソフトウエアは，動かしてみなければ正しいかどうか分からない」 この2つの原理に立ち向かうために，“工程”の概念を定義した「ウォーターフォール型開発プロセス」や，プロトタイピングによる「スパイラル型開発プロセス」，「反復型開発プロセス」などの様々な手段が検討されてきた。
UPを基本から理解する
開発プロセスとは，先人が見出した「開発プロジェクトのベストプラクティス」，平たく言えば「勝ちパターン集」である。 開発プロセスに興味を持ったことがあれば，「Unified Process(UP）」を一度は耳にしているはずだ。しかしUPを正しく理解し，活用できているプロジェクトはあまりにも少ない。 本講座では，UPに含まれる膨大な開発プロジェクトの「勝ちパターン」を，4つのPartに分解して解説する。RUPやUPの導入を検討している人はもちろん，オブジェクト指向や反復開発には全く縁がなくとも，「開発プロジェクトを成功させたい」という想いがあるのなら，UPの知識はきっと役立つはずだ。 Part1 Unified Process，その生い立ちと構造を知る Part2 「ユースケース駆動開発」でUMLを理解する Part3 「ライフサイクルフェーズ」と「反復開発」 Part4 リスク最小化と再利用
Part2 「ユースケース駆動開発」でUMLを理解する
ヤコブソン氏は，「オブジェクト指向」というソフトウエアの表現手段とその可能性に着目し，大規模並行開発に対応できる「システマチックな基本行動」を定義した。それが「ユースケース駆動開発(UCDD)」というアプローチである。今回は，UCDDの開発手順を解説しよう。 「ソフトウエア・エンジニアリング」――。今から20年以上前，1980年代にイヴァー・ヤコブソン氏がソフトウエア開発に求めた姿である。日本語では「ソフトウエアの工業化」とされることが多く，少なからず否定的な感覚を持たれることもある。 しかし，彼は「ソフトウエアをベルトコンベアの上で大量生産できる環境」を作り出すことを目指していたわけではない。当時は一般的だった“職人的な開発方法”では，ソフトウエアの規模と複雑性の増大に対応できないことを認識していたのである。 そこでヤコブソン氏は，「オブジェクト指向」というソフトウエアの表現手段とその可
Part1 Unified Process，その生い立ちと構造を知る
しかしこれは，ごく表面的な一つの側面を表現しているに過ぎない。UPと言えば「反復型開発」を思い浮かべる読者も多いだろう。しかし，「反復型開発」もUPのすべてではない。さらに，今では一般的となっている「オブジェクト指向」と「UML」が，その歴史の多くをUPとともに歩んできたという事実をご存じだろうか。 UPは，ウォーターフォール型開発プロセスに代表される「旧世代の開発手法」の弱点を克服するために，次の思想とともに生み出された。 ユーザーの求める真の要求を満足させること 要求や環境の変化に対応できること ソフトウエア開発のリスクを減少させること 再利用可能なコンポーネントベースのシステムを実現すること そしてソフトウエア業界に「品質の高いソフトウエアを効率的に開発するためのガイドラインを提供すること」を最終的な目的としている(図2）。 様々な人達が，「なぜ失敗するのか」「どうすれば同じ間違いを
反復型開発における見積もりの実際：ベースとなるのはユースケース
オブジェクト指向技術の浸透や，反復型開発の広がりなど，システム開発を巡る状況が大きく変化している。見積もり方法も，従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基本的な考え方や，ユースケース・ポイント法の活用手順について解説する。 オブジェクト指向開発の普及に伴い，ソフトウエアを段階的に繰り返して開発していく「反復型開発（イタラティブ開発）」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基本的な考え方やフェーズの分け方が異なるため，従来型の見積もり技法を適合できない面がある。 そこで第4部では，反復型開発における見積もりの基本的な考え方と，現在，一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお，システム開発のプロセスは反復型開発において最も標準的な「統一プロセス（Unified
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
