1. ソフトウェア開発ライフサイクルモデルの概要
システム開発と聞いて皆さんはどのような作業を思い浮かべるでしょうか？
プログラマーがパソコンに向かってキーボードで黙々とプログラムを書いている
そんなシーンを思い浮かべる人も多いのではないでしょうか？
確かに、プログラミングもシステム開発の一部です。
しかし、大工さんが家を立てるときにいきなり柱を削ったり、屋根を葺いたりしないように、その前に色々とやることがあるのです。例えば、家造りでいえば間取りなどの設計が必要ですね。また、そもそも、間取りを設計するためには「どんな暮らしがしたいか？」、「どのような家がほしいか？」を施主さんにヒアリングする工程が大切ですね。ソフトウェア開発もまた同じなのです。
ソフトウェア開発ライフサイクル【Software Development Life Cycle:SDLC】モデルとは、ソフトウェア開発プロジェクトを計画し、設計し、構築し、テストし、展開するためのフレームワークです。このフレームワークは一連のステップ（または「フェーズ」）に分けられます。各ステップには特定の活動とその成果物があります。
以下に、一般的なSDLCフェーズとそれぞれの概要を紹介します。（各工程の呼び名や内容は会社ごとプロジェクトごとに異なります）
1.1 SDLCフェーズ
要件定義 【Requirements Definition】
このフェーズでは、クライアントやステークホルダーとのコミュニケーションを行い、システムの必要条件や要件を明確にします。要件定義では、システムの目的や機能性、性能要件、制約、インタフェースの詳細、使用シナリオなどが考慮されます。要件定義フェーズでの成果物が要件定義書というドキュメントです。家造りでいえば施主さんに理想の家や個々の家族のニーズを聞き出す段階です。
基本設計【Basic Design】
要件をもとに、システムの大まかな構造やその関連性、ユーザーインターフェースを設計します。この段階では、全体のフレームワークやアーキテクチャに焦点を当てます。画面設計などをするのがこのフェーズになります。また、基本設計フェーズでの成果物が基本設計書というドキュメントです。家造りでいえば、外から見える間取りや材質を決める段階です。この段階ではお客様の意見を最大限尊重するのも家造りと似ています。
詳細設計【Detailed Design】
基本設計を更に詳しく、具体的に展開していきます。ここでは、データ構造、インタフェース、アルゴリズムなどの詳細を設計します。この段階でのドキュメントは、開発者がコードを書く際の指針となります。詳細フェーズでの成果物が詳細設計書というドキュメントです。当社の研修ではクラス図などを作成していきます。家造りでいえば、外からは見えない電気や水道の配管を決める段階です。この段階から専門家の意見が尊重されるのも家造りに似ています。
プログラム設計【Program Design】
このステップでは、詳細設計を元に具体的なプログラミングのための設計を行います。実際のコーディング方法などが決定されます。プログラム設計フェーズでの成果物がプログラム設計書というドキュメントです。当社の研修ではクラス仕様書などを作成していきます。家造りでいえば、窓やクローゼットの設計図を引く段階です。
実装【Implementation】
このフェーズでやっと設計されたプログラムを実際にコードとして実装します。プログラマが、プログラミング言語やツールを使ってシステムの機能を実現するコードを書きます。実装フェーズでの成果物がソースコードになります。家造りでいえば、大工さんがやってきて実際に家を建てる段階です。
単体テスト【Unit Test】
メソッド（関数）やモジュール単位でのテストを行います。モジュールとはプログラムの部品のことでJavaではクラスに相当します。この段階では、コードが正確に動作するか、予期された出力を返すかを確認します。プログラム設計書の内容を検証します。UTと略されることもあります。単体テストフェーズでの成果物が単体テスト報告書というドキュメントです。家造りではキッチンやお風呂などの個々の部分が正常に動いているかを確認する段階です。
結合テスト【Integration Test】
異なるモジュールが適切に連携して動作するかを検証します。単体での動作が確認された後、それらが統合されても期待通りに機能するかを確認するためのテストです。詳細設計書の内容を検証します。ITと略されることもあります。結合テストフェーズでの成果物が結合テスト報告書というドキュメントです。家造りで例えれば、給湯器からキッチンやお風呂などにお湯が流れるかをひとまずは水を流して確認するイメージです。
システムテスト【System Test】
システム全体としての動作を開発者側が確認するテストです。システムテストでは、全てのモジュールが統合され、実際の環境での動作を検証します。ユーザーにとって意味のあるシステムであるかどうかがテストされます。基本設計書の内容を検証します。STと略されることもあります。システムテストフェーズでの成果物がシステムテスト報告書というドキュメントです。建築士さんや大工さんが集まって家全体が設計通りに機能するかを確認する段階です。
運用テスト【Operational Test】
システムがユーザーの実際の運用環境で正常に動作するかを確認するテストです。運用テストは、実際のユーザーが使用する環境での動作を確認するため、システムのデプロイメントやリリース前の最終ステップとなります。運用テストフェーズでの成果物が運用テスト報告書というドキュメントです。施主さんが実際に家に住んでみて、日常生活での機能や快適性を評価するようなものです。
以上の各フェーズの終わりにはレビュー【review】が実施されます。レビューは各フェーズの成果物を関係者が見直して次の工程に進めるか否かを判定するために行われます。
1.2 V字モデル
V字モデル（V-Model）は、Software Development Life Cycle (SDLC) の一つのアプローチで、開発の各段階がテストの各段階と対応しています。
以下の図のように文字通り "V" の形をしており、左側が開発の進行を、右側がテストの進行を示しています。
開発の各工程の成果物を確実にテストするという考え方に基づいています。
2. 要件定義
要件定義と設計は、ソフトウェア開発プロジェクトの成功にとって非常に重要なフェーズです。これらのフェーズが適切に行われないと、ソフトウェアが顧客の期待を満たすことができず、予算や時間の超過が発生する可能性があります。
2.1 要件定義の重要性
- 要件定義は、ソフトウェアが達成すべき目標とその方法を明確にします。開発チームは何を開発するべきか、どの機能が最も重要かを理解でき、プロジェクトの方向性が明確になります。
- 要件定義を通じて、開発チーム、顧客、利害関係者（ステークホルダー）はソフトウェアの目標について合意します。すべての関係者が同じビジョンを共有し、誤解やコミュニケーションの問題を最小限に抑えることができます。
- 要件定義は、開発の範囲を明確にするために行われます。スコープクリープ【Scope creep】（プロジェクトの範囲が管理されずに拡大してしまう現象）を防ぎ、プロジェクトを予定通りに進行させるのに役立ちます。
3. 設計
3.1 設計の重要性
- 設計は、ソフトウェアの詳細な構造を描くフェーズです。開発チームはどのようにコードを書くべきか、どのモジュールがどのように互いに連携するべきかなどを理解できます。
- 設計フェーズでは、アーキテクチャ、データ構造、インターフェースなどの問題を事前に検討します。一般に後のフェーズになるほど修正は高くつくためこの段階で解決しておくことはとても重要です。
- 適切な設計は、ソフトウェアの性能、安定性、可用性、保守性などの品質特性を向上させます。多額の投資をしたソフトウェアは長期間にわたって使い続けたいものです。
3.2 設計工程の種類
システム開発における設計工程は、大まかに基本設計、詳細設計、プログラム設計の3つに分けられます。それぞれの工程の役割と内容を解説します。
基本設計
基本設計は、ユーザーとシステムのやり取りやシステム全体の動作を設計する工程です。主に以下のような内容を含みます。
- システムとユーザーがやり取りするための画面や入力フォームなどの設計を行います。
- システム全体の構成や各モジュールの関係を定義します。
- システムが提供する主な機能や処理の要件を定義します。
基本設計では、要件を元にシステムの全体的な設計を行い、ユーザーとシステムのやり取りを考慮します。基本設計の成果物として、画面設計書や機能要件定義書などが作成されます。
詳細設計
詳細設計は、基本設計で定義されたシステムの機能や動作を実現するための詳細な設計を行う工程です。主に以下のような内容を含みます。
- 基本設計で定義された機能をモジュール単位で詳細に設計します。
- データベースのテーブル構造や関連を定義します。
- 処理の流れや手順を定義し、アルゴリズムを設計します。
詳細設計では、基本設計で決まったシステムの機能を実現するための具体的な手順や仕組みを定義します。詳細設計の成果物として、詳細設計書やデータベース設計書などが作成されます。
プログラム設計
プログラム設計は、詳細設計で定義された機能やアルゴリズムをプログラムコードに落とし込むための設計を行う工程です。主に以下のような内容を含みます。
- 各機能を実現するためのプログラムモジュールを設計します。
- プログラムで使用する変数やデータ構造を定義します。
- 具体的なプログラムコードの設計を行います。
プログラム設計では、詳細設計で定義されたシステムの詳細な仕様をプログラムコードとして具体化します。プログラム設計の成果物として、プログラム仕様書などが作成されます。
これらの設計工程を順に進めていくことで、システム開発の各段階で必要な情報と設計が整理され、効率的にシステム開発が進められます。
4. コーディングとテスト
コーディングとテストは、ソフトウェア開発ライフサイクル（SDLC）の重要なステージです。これらのフェーズは、ソフトウェア製品が指定された要件を満たし、信頼性と効率性を保証するために必要です。
4.1 コーディング
コーディングは、ソフトウェア設計を具体的なプログラムに変換するプロセスです。コーディングはプログラミング言語を使って行われます。その言語はプロジェクトの要件、開発チームの知識、目標プラットフォームなどに基づいて選ばれます。
コーディングフェーズでは、以下のことが重視されます。
- コードは読みやすく、保守しやすい必要があります。そのためには、コード規約といって明確な命名規則、適切なコメント、一貫したインデント（字下げ）とスタイリングなどを用いることが必要です。
- コードは、メモリ量と計算時間を効率的に使用する必要があります。これは、アルゴリズムの選択、適切なデータ構造の使用、冗長な操作の排除などによって達成されます。
- コードは予期しない入力や異常状況を適切に処理する必要があります。これは、適切な例外処理とログ出力によって達成されます。
コーディングについては、この後の研修でもJavaを使って深く学んでいきます。
4.2 テスト
テストは、ソフトウェアが指定された要件を満たしているかどうかを確認するプロセスです。テストフェーズは、ソフトウェアが本番環境で動作する前に発生する可能性のある問題を特定し、修正するために行います。
テストフェーズでは、前述の、単体テスト、結合テスト、システムテスト、運用テストが一般的に実施されます。
これらのテストは、手動で行うこともありますが、可能な限り自動化することが一般的です。これは、回帰テスト（すでに修正されたバグが再発しないかを確認するテスト）を繰り返し実行するため、また新しいコードの追加による既存の機能への影響をチェックするために重要です。
テストについては章を改めてお話しします。
5. レビュー
システム開発では、PDCA（Plan-Do-Check-Action）サイクルを回すことが重要です。PDCAサイクルのCheckにあたるのがレビューです。
レビューはウォーターフォールモデルの各フェーズで行います。すなわち、要件レビュー、設計レビュー、コードレビューなどの種類がありますが、ここではコードレビューに絞ってお話します。
5.1 コードレビュー
コードレビュー【code review】とは、他の人（含む過去の自分）が書いたコードを読み、その質を評価しフィードバックするプロセスのことです。「re=再び view=見る」というわけですね。
コードレビューには、以下のような利点があります。
- コード内のバグや問題点を早期に発見し、ソフトウェアの品質を向上することができます。
- チームメンバー間での知識や経験の共有にも役立ちます。新しい手法やテクニックを学んだり、より良い方法について理解を深めることができます。
- コードベース全体でのスタイルや設計の一貫性を維持するのにも、コードレビューは有効です。一貫性のあるコードは、読みやすく、理解しやすく、保守しやすいです。
- レビューは、自分のコードを他人に見てもらうという体験を通じて、プロフェッショナリズムを高める助けになります。自分の仕事に責任を持ち、他人からのフィードバックを受け入れ、反省し、改善する能力は、プロのエンジニアにとって不可欠なスキルです。
これらを考えると、コードレビューは単なる「コードをチェックする」行為を超えた意義を持っています。皆さんがお互いに学び合い、高品質なソフトウェアを生み出すためのプロセスです。当社の研修でも積極的にレビューをする機会を作りますので、ぜひ、建設的に意見を交わしてください。
6. メンテナンスとシステムの改善
ソフトウェア開発ライフサイクル（SDLC）の最終段階は、メンテナンスとシステムの改善です。これらのフェーズは、ソフトウェア製品が将来に渡ってユーザーのニーズを継続的に満たすために必要です。
6.1 メンテナンス
ソフトウェアがリリースされた後のメンテナンスフェーズでは、ソフトウェアのバグを修正し、ユーザーのフィードバックに基づいて機能を更新または改善します。このフェーズでは、ソフトウェアのパフォーマンスを監視し、問題が発生した場合に迅速に対応することが重要です。また、セキュリティの問題が発見された場合、修正のためのパッチを速やかにリリースすることが求められます。
メンテナンスフェーズは、以下の種類のメンテナンス活動を含むことがあります。
- 既存のバグや問題を修正します。
- ソフトウェアを新しいオペレーティングシステムやハードウェア環境に適合させます。
- ユーザーの要件の変更に対応するために、新機能を追加したり既存の機能を改善したりします。
また、ここで得られたユーザーニーズは次のシステム開発提案の良いネタになりますので、積極的に収集するようにしてください。
6.2 システムの改善
システムの改善は、ソフトウェア製品の性能、安全性、利便性、効率性を向上させるための活動を含みます。新しいテクノロジーの導入、新しいユーザー要件の統合、ソフトウェア設計の改善、コードのリファクタリング（外部から見た振る舞いを変えずに内部構造を改善すること）など、さまざまな方法で達成できます。
システムの改善活動には、以下のようなものがあります。
- ソフトウェアの速度や効率を改善します。
- ユーザーインターフェースを改善したり、新しい機能を追加したりして、ユーザーの使用体験を向上させます。
- セキュリティ対策を強化して、データ漏洩や他のセキュリティリスクを防ぎます。
メンテナンスとシステムの改善は、ソフトウェアがそのライフサイクル全体で価値を提供し続けるために不可欠です。また、これらのフェーズはソフトウェアが常に最新であり、ユーザーの要件とテクノロジー環境の変化に対応できるようにする役割も果たします。
次回は、「オブジェクト指向設計技法のUMLを理解する」を学びます。