第1回 RUPはどこに消えたのか？
……なんて始まり方は少々扇情的に過ぎるでしょうか？ 震災以降、いまだにおさまらない円高等々さまざまな要因があいまって、コスト削減という言葉に「抜本的」「聖域なき」という枕詞が付くようになりました。 もちろんソフトウェアの開発に携わる組織も、無関係ではいられません。「やり方を根本的に変えてでも」という言葉にも、今までにない真剣味がくみ取れるようになった昨今、昔からRationalの名前を知っている方から、「そういえばRUPはどうなったの？」と訊かれることが少なくありません。 開発技法の多様化やITの重要性がどんどん増している現実を受けて、RUPそれ自身も、そしてRationalのプロセスを核としたソリューションも大きく変貌しています。 ベンダーの記事は、どんなに繕っても所詮提灯記事の域を越えることはないわけで、この連載もその例外ではありません。しかし、ソフトウェア開発改善の現場に長く関与して
らくらく Unified Process - ライフサイクルモデル編 - 第 3 回 推敲フェーズを理解する | オブジェクトの広場
もしこれら 4 つのリスクに対して何も対応しない場合には、平均 2 ヶ月と少しのスケジュールの遅れ（すべてのリスクの発生確率 × 影響度の合計）が発生してしまいます。そのため、何らかの対応策を立案し、実施しなければなりません。だからといって、すべてのリスクに対応しなければならないかというとそういうわけでもありません。 リスク 3 のように発生確率が低いリスクは、実はリスクが発生しないかもしれません。そのようなリスクに対して、早期からリスク対応策を実施する必要はありません。その代わり、あらかじめリスク対応策を立案して、リスクの兆候を監視し、必要なタイミングでリスク対応策を実施に移すのです。 また、リスク 4 のように、リスクの被害（発生確率 × 影響度）と対応策にかかる期間がほぼ同じようなリスクについては、対応策すら立案せずにリスクを受容することも重要です。 このように、プロジェクトでは、リ
＠IT [FYI] ソフトウェア開発4つの課題（2）
（3） 各反復の計画時には、当初認識していた要求、リスクだけでなく、反復の過程で見い出された新たな要求、要求への拡張、リスクも勘案し、全体的に俯瞰（ふかん）して優先づけを行う。 反復しようとしているプロジェクトの多くで見受けられるのが、「計画の節目に（いつ）、なにを、どこまで（詳しく、あるいは深く）、決めればいいのか分からない」というケースである。 反復型プロセスの前提が「要求変更に積極的に対処する」ことである以上、作るシステムの仕様が、固定化されないという不安感を持つ方が多いのは理解できる。Rational Unified Process（以下、RUP）では、フェイズという概念を導入して、プロジェクト進行上の大きな節目を明示している（図）。基本的なフェイズは以下の4つである。 ● 方向づけ ● 推敲 ● 作成 ● 移行 各フェイズには、マイルストーンと呼ばれる、成果物が定義されている（詳
svn upする時に更新されるファイルを事前に調べる方法 - Hello, world! - s21g
svn upしたあとにどのファイルが更新されるかを事前にしらべるには、 以下のようなコマンドを使えば良いようです。
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
Part4 リスク最小化と再利用の要，「アーキテクチャセントリック」
UPにおけるアーキテクチャセントリックの目標は，（1）チームが迷わず進むための基盤となる「アーキテクチャ」を構築するための手順を提供することと，（2）プロジェクト内部・外部における再利用のための指針を提供することである。今回は，このアーキテクチャセントリックの手順を中心に解説しよう。 「アーキテクチャセントリック」とは，その名の通り“アーキテクチャを中心にすえて開発を進める”アプローチである。開発チームの環境として「アーキテクチャ」を準備し，開発メンバーが1つのアーキテクチャをプロジェクト内で共有することにより，実装モジュールとともに，知識や進め方の再利用を促す。開発者の経験や知識，出身母体や国境をまたいだチームに発生しやすい“思い込み”や“誤解”，“不整合”，“重複開発”などのリスクを減少させることを目的としたアプローチである。 メンバーの個性が発揮され過ぎていて，設計書やコードを見ても
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
