システム開発では、何を実現するかを合意し、設計・実装・テストを通じて形にし、運用・保守につなげます。この章では活動の目的を表す「プロセス」と、進め方を表す「開発モデル」を分けて学びます。OSが実行を管理する「プロセス」とは別の意味です。
共通フレーム：関係者が同じ言葉で確認する
共通フレーム2013は、システム・ソフトウェア・サービスに関わる人々が、作業や役割を共通の枠組みで確認するための資料です。特定の開発モデルだけを強制する工程表ではありません。以下は学習用に代表的な活動を整理したものです。
| 活動 | 主な目的 |
|---|---|
| 企画 | 経営・業務の課題を整理し、構想や実施計画を検討する |
| 要件定義 | 利害関係者のニーズを整理し、必要な機能・性能・制約などに合意する |
| 開発・実装 | 要件を設計に落とし、ソフトウェア等を作成・結合・検証する |
| 運用 | サービスの提供、監視、利用者支援などを行う |
| 保守 | 障害修正、環境変化への適応、改善などの変更を管理する |
| 管理・支援 | 計画、進捗、品質、構成、変更、リスクなどを横断的に扱う |
要件から設計・テストへつなげる
システム要件は、システム全体が満たすべき機能・性能・制約などです。システム方式では、ハードウェア・ソフトウェア・ネットワークなどへ役割を割り当てます。ソフトウェア要件、方式設計、詳細設計へと具体化し、実装・単体確認・結合・要件への適合確認につなげます。
- ソフトウェア結合：ソフトウェア要素を組み合わせ、設計されたインターフェースや連携を確認する。
- ソフトウェア適格性確認テスト：ソフトウェア要件への適合を確認する。
- システム結合：システム要素を組み合わせ、方式で定めた連携を確認する。
- システム適格性確認テスト：システム要件への適合を確認する。
「基本設計・外部設計」「詳細設計・内部設計」という区分の範囲は組織や契約で異なります。外部設計を見た目の画面だけに限定せず、外部から見える振舞いや入出力・連携も確認します。要件とテストを対応付けることで、作ったものが要求を満たすか追跡できます。
代表的な開発モデルを比較
| モデル・考え方 | 中心となる特徴 | 注意点 |
|---|---|---|
| ウォーターフォール | 工程と成果物を段階的に確定して進める | 変更時は影響分析と合意・変更管理が必要 |
| プロトタイピング | 試作品で要件や操作感、技術を確かめる | 試作と本番品質を混同しない |
| スパイラル | 反復ごとのリスク分析・低減を重視する | 単に小分けに作るだけではない |
| アジャイル | 顧客と協調し、短いフィードバックで変化に適応する | 計画・設計・文書・品質管理を省く意味ではない |
ウォーターフォール：変更が禁止されるわけではない
要件・設計・実装・テストなどを段階的に進め、成果物をレビューします。要件が比較的安定し、合意した成果物や工程の管理が重要な場面で検討されます。途中の誤りや変更は起こり得るため、必要な手戻りと変更管理を行います。実行するテストが後半でも、要件・設計のレビューやテスト計画は早期から行えます。
プロトタイピング：試作の目的を決める
紙や画面モック、動く試作品などを使って、利用者と認識を合わせます。使い捨てる試作と、段階的に製品へ育てる試作を区別し、本番の性能・セキュリティなどを満たすかも確認します。必ず期間や費用が減るとは限りません。
スパイラル：リスクを軸に反復する
目標・選択肢・制約を整理し、リスクを分析して低減策を試し、その結果を踏まえて開発と次の計画へ進みます。リスクを確かめるための試作品も利用できますが、毎回同じ作業順や小さな機能分割が必須という意味ではありません。
反復と漸増を区別する
反復（イテレーティブ）は評価を受けて改善を繰り返すこと、漸増（インクリメンタル）は利用可能な機能などを段階的に増やすことです。両方を組み合わせる場合もあります。
アジャイルと関連用語
変化を受け入れながら、動作するソフトウェアと対話を通じて学び、計画を更新します。Scrum（スクラム）はその実践に使われるフレームワークの一つです。スクラムでは、1か月以内の一定の長さのスプリントで、価値のあるインクリメントを生み出します。アジャイル全体の反復をすべてスプリントと呼ぶわけではありません。
- XP：コミュニケーション、単純さ、フィードバック、勇気、尊重などの価値と技術的実践を重視する。
- ペアプログラミング：2人が協力して実装・確認を進める。
- CI：変更を頻繁に統合し、自動ビルド・テストなどで問題を早く見付ける。
- TDD：小さなテストを書き、失敗を確認し、通る実装を作って整理するサイクル。
- リファクタリング：外部から見た振舞いを保ちながら内部構造を改善する。単なる機能追加とは区別する。
既存システムを理解・再構築する用語
リバースエンジニアリングは既存システムを分析して設計や仕様などを理解することです。実行せずに調べる静的解析、実行時の振舞いを調べる動的解析などがあります。逆アセンブルは機械語をアセンブリ表現に、逆コンパイルは実行形式などから高級言語に近い表現へ変換します。元のソースを完全に復元できるとは限りません。
この文脈のアセンブルはアセンブリ言語を機械語へ変換する処理、コンパイルはソースを機械語や中間表現などへ変換する処理です。コンパイル結果が必ずCPUで直接実行する機械語になるとは限りません。バイナリは2進形式のデータを指し、実行ファイルに限りません。
リエンジニアリングは既存システムを分析し、構造・実装などを再構築して保守性などの改善を図る取組です。分析から再設計・再実装・テストへ進める場合があります。解析・再利用では、権利やライセンスの条件も確認します。EULAはエンドユーザー向けの利用許諾契約を指します。
プロセス中心とデータ中心のアプローチ
POA（プロセス中心アプローチ）は業務機能や処理に注目し、DFDなどでデータの流れと変換を整理します。DFDは単なる作業順のフローチャートとは異なります。DOA（データ中心アプローチ）は、業務が扱うデータや関係を中心に捉え、E-R図などでモデル化します。
POAでもデータを扱い、DOAでも処理を設計します。一方が他方を完全に置き換えるというより、何を設計の中心にするかを区別しましょう。
確認問題
スパイラルモデルを見分ける中心的な特徴はどれでしょうか。
- 変更と手戻りを一切認めない
- 反復ごとにリスクを分析し低減する
- 設計やテストを行わない
- 必ず画面だけを試作する
解答・解説を見る
正解：2。単に反復するだけでなく、リスクの分析と低減を軸に進める点が特徴です。
次の学習テーマを選ぶ
開発の流れを押さえたら、設計に使うUMLやオブジェクト指向などへ進みましょう。開発プロセスとOSのプロセス・スレッドは別のテーマなので、教材名と内容を確かめて選んでください。
コメント