参考文献。 Sommerville, Software Engineering, 10 ed, Chapter 2
全体像
A software process is a structured set of activities required to develop a software system. 私たちは「ソフトウェアプロセス」について話しているのであって、 「ソフトウェア開発プロセス」ではないことに注意してください。「
ソフトウェア プロセスにはさまざまな種類がありますが、どのプロセスにも次の 4 種類の基本的な活動が含まれます。
- ソフトウェアの仕様 – システムが何をすべきかを定義する、
- ソフトウェアの設計と実装 – システム構成を定義しシステムを実装する、
- ソフトウェア検証 – 顧客の求めることを行っているかチェックする、
- ソフトウェア進化 – 顧客のニーズの変化に応答してシステムを変化させる。
ソフトウェアプロセスモデルとは、プロセスの抽象的な表現である。 それは、ある特定の観点からのプロセスの記述を提示する。 ソフトウェアプロセスを記述し議論する場合、通常、データモデルの指定、ユーザインタフェースの設計など、これらのプロセスにおける活動、およびこれらの活動の順序について話す。プロセス記述には、
- プロセス活動の成果である製品、
- プロセスに関わる人々の責任を反映する役割、
- 前後条件、プロセス活動が実施される前と後に真である記述、または製品が生産されることも含まれることがあります。
計画駆動型プロセスとは、すべてのプロセス活動が事前に計画され、この計画に対して進捗が測定されるプロセスのことである。 アジャイルプロセスでは、計画は漸進的であり、変化する顧客要求を反映してプロセスを変更することが容易である。 実際には、ほとんどの実用的なプロセスには、計画駆動型アプローチとアジャイルアプローチの両方の要素が含まれている。
Software process models
The waterfall model Plan-driven model（計画駆動型モデル）。 仕様、ソフトウェア設計、実装、テスト、保守の各フェーズが分離しており、区別されている。 インクリメンタル開発 仕様、開発、検証が交互に行われる。 システムは一連のバージョン（インクリメント）として開発され、各バージョンは前のバージョンに機能を追加していく。 計画駆動型とアジャイル型がある。 統合と構成 再使用可能なコンポーネント／システムが相当数存在することを前提とする。 システム開発プロセスでは、これらのコンポーネントをゼロから開発するのではなく、システムに統合することに重点を置く。 計画主導型とアジャイル型がある。
実際には、ほとんどの大規模システムはこれらすべてのモデルからの要素を組み込んだプロセスを使用して開発される。
The waterfall model
Waterfall modelには個別の特定フェーズがある： Requirements analysis and definition システムサービス、制約、目標がシステムユーザーとの協議により確立される。 その後、それらを詳細に定義し、システム仕様とする。 システム設計とソフトウェア設計 システム設計では、システム全体のアーキテクチャを確立することにより、要求をハードウェアシステムまたはソフトウェアシステムに割り当てる。 ソフトウェア設計では、ソフトウェアシステムの基本的な抽象概念とその関係を特定し、記述する。 実装と単体テスト この段階では、ソフトウェア設計が一連のプログラムまたはプログラムユニットとして実現される。 ユニットテストでは、各ユニットがその仕様を満たしているかどうかを検証する。 統合とシステムテスト 個々のプログラムユニットやプログラムを統合し、完全なシステムとしてテストし、ソフトウェア要件が満たされていることを確認する。 テスト終了後、ソフトウェアシステムは顧客に引き渡される。 運用・保守 通常（必ずしもそうではないが）、ライフサイクルの中で最も長いフェーズである。 システムがインストールされ、実用化される。 メンテナンスでは、ライフサイクルの初期段階で発見できなかったエラーの修正、システムユニットの実装の改善、新しい要件の発見に伴うシステムのサービス向上などが行われる。
ウォーターフォールモデルの最大の欠点は、プロセスが進行した後の変更に対応することが難しいことである。 原則的に、あるフェーズが完了してから次のフェーズに移行しなければならない。 したがって、このモデルは、要件が十分に理解され、設計プロセス中の変更がかなり制限される場合にのみ適切である。 要件が安定しているビジネスシステムはほとんどない。 ウォーターフォールモデルは、複数の拠点でシステムを開発する大規模なシステムエンジニアリング・プロジェクトに多く採用されています。このような状況では、ウォーターフォールモデルの計画駆動型の性質が作業の調整に役立ちます。
Incremental development model
Benefits of incremental development:
Lower cost of changes 顧客要件の変化に対応するコストを削減することができる。 やり直さなければならない分析および文書化の量は、ウォーターフォールモデルで必要とされるよりもはるかに少なくなります。 頻繁なフィードバック 実施された開発作業に対する顧客からのフィードバックが得られやすい。 お客様はソフトウェアのデモにコメントし、どの程度実装されたかを確認することができます。 納期短縮 顧客に有用なソフトウェアをより迅速に納品、展開することができる。 ウォーターフォールプロセスよりも早く、お客様にソフトウェアをお使いいただき、その価値を実感していただくことができます。
インクリメンタル開発の問題点（マネジメントの観点から）：
プロセスが見えない マネージャーは進捗を測るために定期的に成果物を出す必要がある。 システムを短期間で開発する場合、システムの各バージョンを反映したドキュメントを作成するのはコスト的に不利になる。 新しいインクリメントを追加すると、システムの構造が劣化する傾向がある ソフトウェアを改善するためにリファクタリングに時間と費用を費やさない限り、定期的な変更によってその構造が壊れる傾向がある。 さらにソフトウェアの変更を取り入れることがますます難しくなり、コストがかかるようになる。
Integration and Configuration
このアプローチは、既存のコンポーネントまたはCOTS（市販のシステム）からシステムを統合する系統だった再利用に基づいている。
再利用は、今や多くの種類のビジネスシステムを構築するための標準的なアプローチです。
ソフトウェアコンポーネントの種類：
- サービス標準に従って開発され、リモート呼び出しが可能なウェブサービス。
- .NET や J2EE などのコンポーネントフレームワークと統合するためにパッケージとして開発されたオブジェクトのコレクション。
- 特定の環境での使用のために構成されたスタンドアロンの商用オフザシェルフシステム (COTS) 。
Software process activities
Real Software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system.Software process activities
Real Software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of a software system.
仕様、開発、検証、および進化の 4 つの基本的なプロセス活動は、異なる開発プロセスで異なる構成になっています。 ウォーターフォールモデルでは、それらは順番に編成されるが、インクリメンタル開発では、それらはインターリーブされる。
ソフトウェア仕様 どのようなサービスが必要で、システムの運用や開発にどのような制約があるかを確定するプロセス。 要求工学のプロセス。
- フィージビリティスタディ：システムを構築することが技術的、経済的に可能か
- 要件の引き出しと分析：システム関係者がシステムに何を要求、期待するか
- 要件仕様：要件を詳細に定義
- 要件検証：要件の妥当性をチェック
ソフトウェア設計と実装 システム仕様を実行可能システムに変換していくプロセスである。
- ソフトウェア設計：仕様を実現するソフトウェア構造を設計する、
- 実装：この構造を実行可能なプログラムに変換する、
設計と実装の活動は密接に関連しており、相互に入れ替わることがある。 設計の活動には
- 建築設計：システムの全体構造、主要な構成要素（サブシステムまたはモジュールと呼ばれることもある）、それらの関係、およびそれらの分散方法を特定する。
- インターフェース設計：システムコンポーネント間のインターフェースを定義する。
- コンポーネント設計：各システムコンポーネントを取り上げ、それがどのように動作するかを設計する。
- データベース設計：システムのデータ構造を設計し、それらがどのようにデータベースで表現されるかを設計する。
ソフトウェアの検証 検証（V & V）は、システムがその仕様に適合し、システム顧客の要求を満たしていることを示すことを目的とする。
- バリデーション：正しい製品（顧客が望むもの）を作っているか
- 検証：正しい製品を作っているか
V &Vにはチェックとレビュープロセス、システムテストが含まれる。 システムテストでは、システムが処理する実データの仕様から導き出されたテストケースを用いてシステムを実行する。 テストは最もよく使われるV & V活動で、以下の段階がある。
- 開発またはコンポーネントテスト：個々のコンポーネントを独立してテストする。コンポーネントは、機能またはオブジェクト、あるいはこれらのエンティティの一貫したグループかもしれない。
- システムテスト：システム全体のテスト、出現する特性のテストは特に重要である。
- 受入テスト：システムが顧客のニーズを満たしているかを確認するための顧客データによるテスト。
ソフトウェア進化ソフトウェアは、本来柔軟で変化しやすい。 これまで開発と進化（保守）の区分はあったが、完全に新規のシステムは少なくなってきており、これはますます意味をなさなくなってきている。
Coping with change
Change is inevitable in all large software projects.Business changes lead to new and changed system requirementsNew technologies open up new possibilities for improving implementations.Changing platforms requires application changes.Change leads to rework so the costs include both rework (e.g.,).The changes is inevitable in all large software projects.変更は手直しをもたらすので、変更のコストは、新しい機能を実装するコストと同様に、手直し（例えば、要件の再分析）の両方を含む。
手直しのコストを削減する2つの戦略：
変更回避 ソフトウェアプロセスには、重要な手直しが必要になる前に可能な変更を予測できる活動が含まれています。 例えば、顧客にシステムの主要な機能を見せるためにプロトタイプシステムを開発することがある。 変更許容性 プロセスは、比較的低いコストで変更に対応できるように設計される。これは通常、ある種の漸進的な開発を含む。 提案された変更は、まだ開発されていないインクリメントで実施することができる。 これが不可能な場合は、1つのインクリメント（システムの小さな部分）だけを変更して、変更を取り込む必要があるかもしれない。
Software prototyping
A prototype is a initial version of a system used to demonstrate concepts and try out the design options. プロトタイプは、
- 要求エンジニアリング プロセスで、要求の引き出しと検証を支援します。
- 設計プロセスで、オプションを検討し、UI デザインを開発します。
プロトタイピングの利点：
- システムのユーザビリティの向上。
- ユーザーの実際のニーズにより近い。
- デザインの質の向上。
- 保守性の向上。
- 開発工数の削減。
試作は迅速な試作言語またはツールに基づいている場合があります。
- プロトタイプは、よく理解されていない製品の領域に焦点を当てるべきです。
- エラーチェックとリカバリはプロトタイプに含まれないかもしれません。
- 信頼性やセキュリティなどの非機能要件よりも機能要件に焦点を当てる。
プロトタイプは生産システムの基礎として適切ではないため、開発後は破棄すべきである。
- 非機能要件を満たすためにシステムを調整することは不可能かもしれない。
インクリメンタル開発/提供
システムを一度に提供するのではなく、開発および提供は、必要な機能の一部を提供する各インクリメントに分解される。インクリメントの開発が開始されると、要件は凍結されるが、後のインクリメントの要件は引き続き進化させることができる。
Process improvement
多くのソフトウェア企業は、ソフトウェアの品質を高め、コストを削減し、開発プロセスを加速させる方法として、ソフトウェアプロセス改善に注目しています。 プロセス改善は、既存のプロセスを理解し、製品品質の向上および/またはコストや開発時間の削減のためにこれらのプロセスを変更することを意味します。
プロセス成熟度アプローチ プロセスとプロジェクト管理の改善、および優れたソフトウェア工学の実践を導入することに重点を置く。 プロセスの成熟度は、組織のソフトウェア開発プロセスにおいて、優れた技術や管理の実践がどの程度採用されているかを反映する。 アジャイルアプローチ 反復開発とソフトウェアプロセスにおけるオーバーヘッドの削減に重点を置いている。 アジャイル手法の主な特徴は、機能の迅速な提供と、変化する顧客要求への対応です。
プロセス改善活動は、フィードバックループによる継続的なサイクルを形成している：
- ソフトウェアプロセスまたは製品の1つまたは複数の属性を測定する。 これらの測定は、プロセスの改善が効果的であったかどうかを判断するのに役立つ基準値を形成する。
- 現在のプロセスを分析し、あらゆるボトルネックを特定する。
- 識別されたプロセスの弱点のいくつかに対処するために、プロセスを変更する。
プロセス測定
- 可能な限り、定量的プロセスデータを収集すべきである。
- プロセス測定は、プロセス改善を評価するために使用すべきである。例えば、活動またはプロセスを完了するためのカレンダータイムまたは労力。
- プロセスまたは活動に必要なリソース、例えば人日単位の総労力。
- 特定のイベントの発生数、例えば発見された欠陥の数。
SEI capability maturity model
- Initial: 基本的に管理されていない
- 繰り返し可能。 製品管理手順が定義され、使用されている
- 定義されている。 プロセスマネジメントの手順と戦略が定義され、使用されていること
- 管理されていること。 品質管理戦略を定義し、使用する
- 最適化する。 プロセス改善戦略を定義し、使用する