ソフトウェア工学シリーズ記事 その1

ソフトウェアプロセス

ソフトウェア開発で従うロードマップを「ソフトウェアプロセス」って呼ぶんだ。

能力成熟度モデル (CMM)

CMMはソフトウェアプロセス改善を次の5つの成熟度レベルに分けるよ。

1. 初期レベル (Initial)

​ ソフトウェアはめちゃくちゃで、時には混乱することもある。明確に定義された手順はほとんどなく、プロジェクトの完了は完全に個人の努力とヒーロー的なキーパーソンの役割にかかっているんだ。

2. 反復可能レベル (Repeatable)

​ プロジェクトの費用、スケジュール、機能特性を追跡するための基本的なプロジェクト管理プロセスと実践が確立されていて、以前の類似プロジェクトでの成功を繰り返すために必要なプロセスガイドラインがあるんだ。

3. 定義済みレベル (Defined)

​ 管理面と工学面の両方のソフトウェアプロセスが文書化、標準化されて、ソフトウェア開発組織全体の標準ソフトウェアプロセスに統合されている状態だね。すべてのプロジェクトは、実際の状況に合わせて修正された標準ソフトウェアプロセスを使ってソフトウェアを開発・保守するんだ。

4. 管理済みレベル (Managed)

​ ソフトウェアプロセスと製品品質の詳細な測定基準が定められているんだ。ソフトウェアプロセスの製品品質は、開発組織のメンバーに理解されていて、制御されているよ。

5. 最適化レベル (Optimized)

​ 定量分析が強化されていて、プロセス品質のフィードバックと新しいアイデアや技術からのフィードバックを通じて、プロセスが継続的に改善され続けるんだ。

CMMモデルは、ソフトウェアプロセス改善の進化ステップを5つの成熟度レベルに編成するフレームワークを提供してくれて、プロセスの継続的な改善のための段階的な基盤を築いているよ。この5つの成熟度レベルは、組織のソフトウェアプロセス成熟度を測定し、そのソフトウェアプロセス能力を評価するために使われる、順序だった尺度を定義しているんだ。

能力成熟度モデル統合 (CMMI)

CMMの成功で、様々な分野に適用できるモデルがたくさん生まれたんだけど、一つのプロジェクトで複数の分野が絡むこともよくあるから、いろんなプロセス改善の取り組みを統合する必要があったんだ。CMMIは、いくつかのプロセスモデルを統合して改善したものだよ。

CMMIには、ステージング型モデルと連続型モデルの2つの表現方法があるよ。

1. ステージング型モデル

ステージング型モデルの構造はCMMに似ていて、組織の成熟度に焦点を当てているんだ。CMMI-SE/SW/IPPD バージョン1.1には、5つの成熟度レベルがあるよ。

• 初期：プロセスが予測不能で、コントロールが効かない。
• 管理済み：プロセスがプロジェクトに貢献している。
• 定義済み：プロセスが組織全体に貢献している。
• 定量的管理済み：プロセスが測定され、制御されている。
• 最適化：プロセス改善に集中している。

2. 連続型モデル

連続型モデルは、それぞれのプロセス領域の能力に注目するモデルだ。組織は、異なるプロセスに対して異なるプロセス領域能力レベル (Capability Level, CL) を達成できるんだ。CMMIには6つのプロセス領域能力レベルが含まれていて、レベル番号は0から5まであるよ。能力レベルには共通目標とそれに関連する共通プラクティスが含まれていて、これらのプラクティスはプロセス領域内の特定目標やプラクティスに追加されるんだ。組織がプロセス領域の特定目標と共通目標を満たしたとき、その組織はそのプロセス領域の能力レベルを達成したって言われるんだね。

• CL₀ (未完了)：プロセス領域が実行されていないか、CL₁で定義されたすべての目標を達成していない。
• CL₁ (実行済み)：その共通目標は、プロセスが識別可能な入力作業成果物を識別可能な出力作業成果物に変換して、プロセス領域をサポートする特定目標を達成することだ。
• CL₂ (管理済み)：その共通目標は、管理されているプロセスの制度化に集中しているよ。組織レベルのポリシーに基づいて、プロセスの運用でどのプロセスを使うかが規定されていて、プロジェクトは文書化された計画とプロセス記述に従う。仕事をしているみんなは十分なリソースを使う権利を持っていて、すべての作業タスクと成果物が監視、制御、レビューされているんだ。
• CL₃ (定義済み)：その共通目標は、定義されたプロセスの制度化に集中しているよ。プロセスは組織の標準プロセス集から、組織のテーラリングガイドラインに従って仕立てられているんだ。また、プロセス資産とプロセスの測定値を収集して、将来のプロセス改善に使う必要があるね。
• CL₄ (定量的管理済み)：その共通目標は、定量的に管理可能なプロセスの制度化に集中している。測定と品質保証を使ってプロセス領域を制御し、改善するんだ。品質とプロセス実行に関する定量的目標を管理基準として確立し、使用するよ。
• CL₅ (最適化)：定量的（統計学的な）手段を使ってプロセス領域を変更・最適化するんだ。これによって、顧客要求の変化や継続的な改善計画におけるプロセス領域の有効性を満たすことを目指すよ。

ソフトウェアプロセスモデル

ソフトウェアプロセスモデルは、一般的にソフトウェア開発モデルとも呼ばれるものだね。これは、ソフトウェア開発のすべてのプロセス、活動、タスクの構造的フレームワークなんだ。代表的なソフトウェアプロセスモデルには、ウォーターフォールモデル、インクリメンタルモデル、進化的モデル（プロトタイプモデル、スパイラルモデル）、ファウンテンモデル、コンポーネントベース開発モデル、形式手法モデルなどがあるよ。

ウォーターフォールモデル

ウォーターフォールモデルは、ソフトウェアのライフサイクルにおける各活動を、線形に順序づけられたいくつかの段階（要件分析、設計、コーディング、テスト、運用、保守）に規定したモデルなんだ。これは、滝の水が段階的に落ちるように、前から後ろへと連なり、固定された順序を定めているよ。

ウォーターフォールモデルは、ソフトウェアの開発と保守に効果的な管理パターンを提供してくれる。このパターンに基づいて開発計画を立てたり、コスト予算を組んだり、開発体制を組織したりするんだ。プロジェクトの段階レビューや文書管理を手段として、開発プロセス全体を効果的に指導するから、これは文書駆動型で、ソフトウェア要件がとても明確なソフトウェアプロジェクトに適したモデルだね。

ウォーターフォールモデルは、開発対象のシステム要件が完全で、簡潔で、一貫していて、設計や実装が完了する前に生成できる、って仮定しているんだ。

ウォーターフォールモデルの利点は、理解しやすく、管理コストが低いこと。開発の段階的な早期計画や要件調査、製品テストを重視している点だね。 不足している点は、顧客が自分のニーズを完全、正確、かつ明確に表現できる必要があること。最初の2〜3段階では、実際の進捗状況を評価するのが難しいこと。プロジェクト終盤に近づくと、大量の統合とテスト作業が発生すること。そして、プロジェクトが終わるまでシステムの能力をデモンストレーションできないこと、だね。 ウォーターフォールモデルでは、要件や設計の誤りがプロジェクトの後半になってようやく発見されることが多くて、プロジェクトリスクの制御能力が弱いんだ。その結果、プロジェクトが遅延したり、開発費用が予算を超過したりすることがよくあるよ。

Vモデル

ウォーターフォールモデルの派生の一つがVモデルだよ。

Vモデルは、品質保証活動と、コミュニケーション、モデリング関連活動、そして早期構築関連活動との関係を表しているんだ。ソフトウェアチームがVモデルの左側のステップを下にたどっていくにつれて、基本的な問題要件が徐々に詳細化されて、問題と解決策の技術的な記述が形成される。コーディングが終わったら、チームはVモデルの右側のステップを上にたどっていくんだけど、これは実際には一連のテスト（品質保証活動）を実行していることになるんだね。これらのテストは、Vモデルの左側を下にたどる過程でチームが生成した各モデルを検証するものなんだ。Vモデルは、検証・確認活動を初期のソフトウェア工学作業に適用する方法を提供してくれるよ。

インクリメンタルモデル

インクリメンタルモデルは、ウォーターフォールモデルの基本要素とプロトタイプ実現のイテレーション（反復）特性を融合したものだよ。これは、要件を一連のインクリメンタルな製品に分割できると仮定していて、それぞれのインクリメンタルな製品を個別に開発できるんだ。このモデルは、スケジュールの進行とともに入れ替わる線形シーケンスを採用していて、それぞれの線形シーケンスがソフトウェアのリリース可能な「インクリメント」を生み出すんだよ。

インクリメンタルモデルを使うとき、最初のインクリメントが核となる製品になることが多いよ。顧客は各インクリメントを利用・評価して、それが次のインクリメントでリリースされる新機能や機能として活用されるんだ。このプロセスは、それぞれのインクリメントがリリースされた後に繰り返し行われて、最終的に完璧な製品が作られるまで続くよ。インクリメンタルモデルは、すべてのインクリメントで動作可能な製品をリリースすることを強調しているんだ。

インクリメンタルモデルはウォーターフォールモデルの派生版だから、ウォーターフォールモデルの利点をすべて持っているんだ。それに加えて、次の利点もあるよ。最初の成果物バージョンに必要なコストと時間が少ないこと。インクリメントで表される小さなシステム開発に伴うリスクが小さいこと。最初のバージョンがすぐにリリースされるため、ユーザー要求の変更を減らせること。そして、インクリメンタルな投資、つまりプロジェクト開始時に1つか2つのインクリメントにのみ投資できること、だね。

インクリメンタルモデルには、次の不足点もあるんだ。ユーザーの変更要求に対する計画がなければ、生成された初期インクリメントが後続のインクリメントを不安定にする可能性があること。要件が早期に考えたほど安定していて完全でなかった場合、いくつかのインクリメントを再開発・再リリースする必要があるかもしれないこと。そして、発生するコスト、進捗、構成管理の複雑さが組織の能力を超える可能性があること、だね。

進化的モデル

ソフトウェアは他の複雑なシステムと同じで、時間の経過とともに進化していくものだよね。開発中に、次のような状況に直面することがよくあるんだ。ビジネスや製品の要件が頻繁に変わるせいで、最終製品の実現が難しくなること。厳しい納期のために開発チームがソフトウェア製品を完全に仕上げるのは不可能でも、競争やビジネス上の圧力に対応するために機能が限定されたバージョンをリリースしなければならないこと。そして、コアとなる製品やシステムの要件はよく理解しているんだけど、製品やシステムの拡張に関する詳細な問題が定義されていないこと、とかね。このような状況や類似のケースでは、ソフトウェア開発者は絶えず進化するソフトウェア製品に特化したプロセスモデルを必要とするんだ。

進化的モデルはイテレーション（反復）型のプロセスモデルで、ソフトウェア開発者がより完成度の高いソフトウェアバージョンを段階的に開発できるようにしてくれるんだ。進化的モデルは、ソフトウェア要件に対する正確な認識が不足している場合に特に適しているよ。代表的な進化的モデルには、プロトタイプモデルやスパイラルモデルなどがあるね。

プロトタイプモデル (Prototype Model)

すべての要件を事前に定義できるわけじゃないんだ。多くの経験が示すところによると、開発初期に完全で正確な要件仕様書を得るのは難しいんだよ。これは主に、顧客が将来のシステムに対する全体的な要求を正確に表現できないことが多くて、開発者も解決すべきアプリケーション問題についてあいまいな理解しか持っていないため、作成される要件仕様書が不完全だったり、不正確だったり、時には曖昧だったりするからだね。さらに、開発プロセス全体でユーザーが新しい要求を出すことで、要件が変更されることもあるんだ。ウォーターフォールモデルは、このような要件の不確実性や変化に対応するのが難しいから、ラピッドプロトタイプという新しい開発手法が登場したんだよ。プロトタイプ方法は、ユーザーの要件が不明確だったり、頻繁に変化したりする場合に比較的適しているね。システム規模がそれほど大きくなく、複雑でもないときにこの方法を採用するのは良い選択だと言えるよ。

プロトタイプは、期待されるシステムの一部を反映した実行可能なバージョンだよ。プロトタイプは、目標とするソフトウェアのすべての制約を満たす必要はなくて、その目的は、迅速かつ低コストで構築できることにあるんだ。もちろん、プロトタイプ方法を採用できるのは、開発ツールの急速な発展のおかげで、ユーザーが見て触れることができるシステムフレームワークを素早く開発できるようになったからだね。こうして、コンピューターにあまり詳しくないユーザーでも、このフレームワークに基づいて自分の要件を提案できるようになるんだ。プロトタイプシステムを開発するには、まずユーザー要件を確定して初期プロトタイプを開発し、次にユーザーから初期プロトタイプに対する改善意見を募って、その意見に基づいてプロトタイプを修正していくんだよ。

プロトタイプモデルはコミュニケーションから始まるんだ。目的は、ソフトウェアの全体目標を定義し、要件を特定すること。その後、プロトタイプ開発の計画を迅速に立て、プロトタイプの目標と範囲を決定して、ラピッドデザインの手法でモデリングを行い、プロトタイプを構築するんだ。開発されたプロトタイプは顧客に提供されて使ってもらい、顧客からのフィードバック意見を収集するよ。これらのフィードバック意見は、次のイテレーションでプロトタイプの改善に活かされるんだ。前のプロトタイプを改善する必要があるとき、またはその範囲を拡張する必要があるときに、次のプロトタイプのイテレーション開発に入るんだね。

スパイラルモデル

複雑な大規模ソフトウェアの場合、一つのプロトタイプを開発するだけでは要件を満たせないことが多いんだ。スパイラルモデルは、ウォーターフォールモデルと進化的モデルを組み合わせて、どちらのモデルも無視していたリスク分析を取り入れて、これら2つのモデルの欠点を補っているよ。

スパイラルモデルは、開発プロセスをいくつかのスパイラルサイクルに分けているんだ。それぞれのスパイラルサイクルは、だいたいウォーターフォールモデルに合致していて、次の4つの作業ステップに分かれるよ。

1. 計画の策定。ソフトウェアの目標を決定し、実施案を選定して、プロジェクト開発の制約条件を明確にする。
2. リスク分析。選択した案を分析し、リスクを特定して、リスクを解消する。
3. エンジニアリングの実施。ソフトウェア開発を実施し、段階的な製品を検証する。
4. ユーザー評価。開発作業を評価し、修正提案を提出して、次のサイクルの開発計画を立てる。

スパイラルモデルはリスク分析を重視していて、開発者とユーザーが各進化段階で発生するリスクを理解し、それに応じた対応を取れるようにしているんだ。だから、このモデルは、大規模で複雑、かつリスクの高いシステムに特に適しているんだよ。

ウォーターフォールモデルと比較して、スパイラルモデルはユーザー要件の動的な変化をサポートしてくれるし、ユーザーがソフトウェア開発のすべての重要な意思決定に参加しやすくして、ソフトウェアの適応能力の向上に役立つんだ。さらに、プロジェクト管理者が管理上の意思決定をタイムリーに調整しやすくしてくれるから、ソフトウェア開発のリスクを低減できるよ。スパイラルモデルを使ってソフトウェア開発を行う場合、開発者には非常に豊富なリスク評価経験と専門知識が必要だね。それに、イテレーションの回数が多すぎると開発コストが増加して、納期が遅れる可能性もあるんだ。

ファウンテンモデル

ファウンテンモデルは、ユーザー要件を原動力とし、オブジェクトを駆動源とするモデルで、オブジェクト指向開発手法に適しているんだ。これは、ウォーターフォールモデルがソフトウェアの再利用や複数の開発活動の統合をサポートしない、という限界を克服しているよ。ファウンテンモデルは、開発プロセスに反復性とシームレス性を持たせるんだ。

イテレーションとは、モデル内の開発活動が何度も繰り返される必要があって、その過程でソフトウェアシステムが継続的に改善されることを意味するんだ。シームレス性っていうのは、開発活動（例えば分析、設計、コーディング）の間に明確な境界がないこと、つまり、ウォーターフォールモデルみたいに、要件分析活動が終わってから設計活動が始まり、設計活動が終わってからコーディング活動が始まる、っていうんじゃなくて、それぞれの開発活動が並行して、反復的に進められることを許容する、っていうことだよ。

ファウンテンモデルの各段階には明確な境界がなくて、開発者は並行して作業を進められるんだ。その利点は、ソフトウェアプロジェクトの開発効率を高め、開発時間を節約できることだね。ファウンテンモデルは開発の各段階が重複しているから、開発プロセス中に大量の開発者が必要で、プロジェクト管理には不利なんだ。それに、このモデルは厳格な文書管理が求められるから、監査の難易度も上がっちゃうんだよ。

統一プロセス (UP) モデル

統一プロセスモデルは、「ユースケースとリスク駆動型、アーキテクチャ中心、反復的かつインクリメンタル」な開発プロセスで、UMLの手法とツールにサポートされているんだ。イテレーションっていうのは、ソフトウェア開発プロジェクト全体をたくさんの小さな「ポケットプロジェクト」に分割するってこと。それぞれの「ポケットプロジェクト」には、通常のソフトウェアプロジェクトのすべての要素が含まれるんだよ。つまり、計画、分析と設計、構築、統合とテスト、それに内部および外部リリース、だね。

統一プロセスは、4つの技術段階とその成果物を定義しているよ。

1. 開始フェーズ (Inception Phase)

   開始フェーズはプロジェクトの立ち上げ活動に集中するんだ。主な成果物としては、ビジョン文書 (Vision Document)、初期ユースケースモデル、初期プロジェクト用語集、初期ビジネスユースケース、初期リスク評価、プロジェクト計画（フェーズおよびイテレーション）、ビジネスモデル、そして必要に応じて1つ以上のプロトタイプがあるよ。

2. 具現化フェーズ (Elaboration Phase)

   具現化フェーズでは、最初の領域範囲を理解した後、要件分析とアーキテクチャ進化を行うんだ。主な成果物としては、ユースケースモデル、補足要件、分析モデル、ソフトウェアアーキテクチャ記述などがあるよ。

3. 構築フェーズ (Construction Phase)

   構築フェーズはシステムの構築に注目して、実装モデルを生み出すんだ。主な成果物としては、設計モデル、ソフトウェアコンポーネント、統合されたソフトウェアインクリメント、テスト計画と手順、テストケース、そしてサポート文書などがあるよ。

4. 移行フェーズ (Transition Phase)

   移行フェーズは、ソフトウェアの提出に関する作業に注目して、ソフトウェアインクリメントを生み出すんだ。主な成果物としては、提出されたソフトウェアインクリメント、βテスト報告書、そして包括的なユーザーフィードバックがあるよ。

それぞれのイテレーションでは、最終システムの部分的に完成したバージョンと、関連するプロジェクト文書を含むベースラインが生成されるんだ。段階的なイテレーションを通じてベースライン同士が相互に構築されていき、最終システムが完成するまで続くよ。各イテレーションには5つのコアワークフローがあるんだ。

1. システムが何をすべきかを捉える要件ワークフロー
2. 要件を詳細化し構造化する分析ワークフロー
3. システムアーキテクチャ内で要件を実現する設計ワークフロー
4. ソフトウェアを構築する実装ワークフロー
5. 実装が期待通りに機能するかを検証するテストワークフロー

UPの段階が進むにつれて、各コアワークフローの作業量は変化するんだ。4つの技術段階は、主要なマイルストーンで終了するよ。

• 開始フェーズ：ライフサイクル目標
• 具現化フェーズ：ライフサイクルアーキテクチャ
• 構築フェーズ：初期動作機能
• 移行フェーズ：製品リリース

統一プロセスの代表例はRUP (Rational Unified Process) だね。RUPはUPの商業拡張版で、UPと完全に互換性があるんだけど、UPよりもさらに完全で詳細なものなんだ。

アジャイル手法

アジャイル開発の全体的な目標は、「価値のあるソフトウェアを可能な限り早く、継続的に提供すること」を通じて顧客を満足させることなんだ。ソフトウェア開発プロセスに柔軟性を取り入れることで、アジャイル手法 (Agile Development) は、開発サイクルの後期にユーザーが要件を追加したり変更したりできるようにしてくれるんだよ。

アジャイルプロセスの代表的な手法はたくさんあって、それぞれが原則のセットに基づいていて、それらの原則がアジャイル手法が提唱する理念（アジャイル宣言）を実現しているんだ。

1. エクストリームプログラミング (XP)

XPは、軽量（アジャイル）で、高効率、低コスト、柔軟性があり、予測可能で科学的なソフトウェア開発手法なんだ。これは、価値観、原則、実践、行動の4つの部分から構成されていて、お互いに依存し、関連し合いながら、行動を通じてライフサイクル全体を貫いているよ。

• 4つの大きな価値観：コミュニケーション、シンプルさ、フィードバック、勇気
• 5つの大きな原則：迅速なフィードバック、シンプルさの仮定、段階的修正、修正の推奨、高品質な仕事
• 12のベストプラクティス
  • 計画ゲーム（迅速な計画策定、詳細の変化に合わせて洗練させる）
  • 小規模リリース（システムの設計は、可能な限り早期に提供できるようにする）
  • メタファー（適切な比喩を見つけて情報を伝える）
  • シンプルな設計（現在の要件だけを扱い、設計をシンプルに保つ）
  • テスト駆動開発（先にテストコードを書き、その後にプログラムを作成する）
  • リファクタリング（要件と設計を再検討し、新しい要件と既存の要件に合致するように明確に再記述する）
  • ペアプログラミング
  • 共同コード所有
  • 継続的インテグレーション（顧客に日ごと、場合によっては時間ごとに動作可能なバージョンを提供できる）
  • 週40時間労働
  • オンサイト顧客（システムの最終ユーザー代表がXPチームに全面的に協力する）
  • コーディング標準

2. クリスタル法 (Crystal)

クリスタル法は、それぞれの異なるプロジェクトには異なる戦略、慣習、方法論が必要だと考えるんだ。

人間がソフトウェアの品質に重要な影響を与えると考えているから、プロジェクトの品質や開発者の質が向上するにつれて、プロジェクトとプロセスの品質もそれに伴って向上するんだ。より良いコミュニケーションと頻繁なデリバリーを通じて、ソフトウェアの生産性が向上するってわけだね。

3. スクラム (Scrum)

スクラムはイテレーション（反復）の手法を使っていて、30日ごとのイテレーションを「スプリント」と呼び、要件の優先度に従って製品を実現するんだ。複数の自己組織化された自律的なチームが並行して製品をインクリメンタルに実現していくんだけど、調整は短い日常の状況会議で行われるんだよ。まるでラグビーの「スクラム」みたいだね。手順は次の通りだよ。

4. 適応的ソフトウェア開発 (ASD)

ASDには6つの基本的な原則があるんだ。

• 指針となるミッションがあること
• 特徴が顧客価値のキーポイントと見なされること
• プロセスにおける待機が重要で、「やり直し」は「実行」と同じくらい重要であること
• 変化は修正ではなく、ソフトウェア開発の実際の状況への調整と見なされること
• 確定された納期が、開発者に生産されるすべてのバージョンの重要な要件を真剣に検討させること
• リスクもその中に含まれること

5. アジャイル統一プロセス (AUP)

アジャイル統一プロセス (Agile Unified Process, AUP) は、「大規模では連続的」であり「小規模では反復的」という原理を使ってソフトウェアシステムを構築するんだ。古典的なUPの段階的活動（開始、具現化、構築、移行）を採用し、チームがソフトウェアプロジェクトの包括的なプロセスフローを構想できるような一連の活動を提供するんだよ。それぞれの活動の中で、チームはアジャイルを反復的に使いながら、意味のあるソフトウェアインクリメントを可能な限り迅速にエンドユーザーに提供するんだ。AUPの各イテレーションでは、次の活動を実行するよ。

• モデリング。ビジネスや問題領域のモデル表現を作成する。これらのモデルは、チームが先に進むのに「十分良い」ものであればいいんだ。
• 実装。モデルをソースコードに変換する。
• テスト。XPと同じように、チームは一連のテストを設計・実行してエラーを発見し、ソースコードが要件を満たしていることを保証するんだ。
• デプロイ。ソフトウェアインクリメントの提供と、エンドユーザーからのフィードバックの取得。
• 構成管理とプロジェクト管理。変更管理、リスク管理、そしてチームのあらゆる成果物の制御に焦点を当てる。プロジェクト管理は開発チームの作業進捗を追跡・制御し、チーム活動を調整するんだ。
• 環境管理。標準、ツール、そして開発チームに適用されるサポート技術などのプロセスインフラを調整する。