システム開発
共通フレーム2013
ソフトウェア、システム、サービスに関係する人々が共通の枠組みとするために作成されたガイドライン。システムやソフトウェアの構想から開発、運用、保守、廃棄に至るまでのライフサイクル全般にわたって必要なベースとなる作業内容が包括的に規定され、標準化されている。システムの開発者や情報システム部門に限定されたものではなく、経営者、業務部門といった情報システムに係る様々な利害関係者の立場に立って、その適正な取引の実現に向けて書かれたものであることが特徴である。
共通フレームの基盤となる規格
- ISO/IEC 12207 ソフトウェアライフサイクルプロセス規格
- ISO/IEC 15288 システムライフサイクルプロセス規格
用語の整理
- システム
- 業務の一部となるものである。業務は大きく「人による活動」と「システム」に分類される。共通フレームは業務の一部をシステムに置き換えるための活動を定義したものである。
- ソフトウェア
- システムの一部となるものである。システムは大きく「ハードウェア」「ソフトウェア」「その他の設備」で構成される。共通フレームにおけるシステムは主にソフトウェアを中心として扱う。
共通フレームの階層
共通フレームは階層構造となっており、以下の4階層で構成される。
- プロセス
- システム開発作業を役割の観点でまとめたもので、主に入力を出力に変換されるものである。
- アクティビティ
- 相関の強いタスクをまとめたもので、プロセスを作業目的ごとに分割したものである。
- タスク
- アクティビティをより具体的に遂行するために分割した個々の作業のこと。
- 注記
- タスクの構成要素。主として例示となっており、すべての作業を表しているわけではない
共通フレームのプロセス
共通フレームには数多くのプロセスがあり、プロセス体系としてまとめられている。
ただし、プロセスはこれがすべてではなく、例えばシステム開発プロセスの中にはシステム要件定義プロセス、システム方式設計プロセスなどが存在する。また要件定義プロセスは、企画・要件定義の視点の中の「要件定義プロセス」のほかに、システム開発プロセスの中の「システム要件定義プロセス」「ソフトウェア要件定義プロセス」が存在しており、それぞれ別で考える必要がある。
試験対策としては、まずはテクニカルプロセスと運用・サービスプロセスについて押さえる。各プロセスの流れが次のようになっていることを覚える。
要件定義プロセス
利用者及び他の利害関係者が必要とするサービスを提供できるシステムに対する要件を定義することを目的とする。利害関係者とそのニーズ及び要望を識別、分析をして、要件定義に変換する。開発モデルによっては、システムプロジェクト開始前の作業として位置づけられる。
- 業務要件
- 新しい業務のあり方や運用をまとめたうえで、業務上実現すべき要件を明らかにしたもの。
- 機能要件
- 業務要件を実現するために必要なシステム機能を明らかにしたもの。データの流れを明確にし、人の作業やシステム機能の実現範囲を定義する。また、他システムとの情報連携のインタフェースを定義する。
- 非機能要件
- 業務要件を実現するために必要なシステム機能のうち、機能要件以外の要件を明らかにする。非機能要件がユーザーへのヒアリングでは知ることが難しいため定義する際に注意する必要がある。非機能要件には、性能や信頼性、拡張性、セキュリティなどがある。
システム開発プロセス
システム開発プロセスには多くのプロセスが存在するが、主なプロセスとしては以下のものがある。
システム要件定義プロセス
要件定義プロセスで定義された要件をシステムの技術的要件に変換する。システム化目標、対象範囲、セキュリティ、運用・保守の要件などをシステム要件として定めて文書化する。
システム方式設計プロセス
定義されたシステム要件について、必要なハードウェアやソフトウェアを洗い出し、どれをどのシステム要素に割り当てるのが望ましいか識別する。
ソフトウェア実装プロセス
ソフトウェア実装プロセスには多くのプロセスが存在するが、主なプロセスは以下のものがある。
ソフトウェア要件定義プロセス
システムを構成するソフトウェアの要件を定義する。ソフトウェア品目やその周辺のインタフェース、データ定義、データベースの要件が定義される。
ソフトウェア方式設計プロセス
要件を実際のソフトウェアに実装し、検証できるように設計する工程。ソフトウェア構造やコンポーネント、データベースの設計が行われる。
ソフトウェア詳細設計
ソフトウェア要件、ソフトウェア詳細設計を踏まえて、それをコーディングが行えるレベルに詳細に設計していく。
ソフトウェア構築プロセス
実行可能なソフトウェアユニットとデータベースを実際に作成していく。ソフトウェアユニットの作成を一般的にコーディングと呼ぶ。
適格性確認・テスト
各プロセスで設計とテストに対応関係を持たせ、確認作業や評価、テストを行うこととされている。図に表すとV字となるのでV字モデルといわれる。
他の用語
- テラーリング（修正）
- 共通フレームはすべてを取り入れるのではなく、テラーリングと呼ばれる修正プロセスにおいて取捨選択をして使用する。
システム開発技術
ウォーターフォールモデル
もっともオーソドックスなシステム開発手法。必要な作業を順番に処理していく。
プロトタイピングモデル
プロトタイプ（試作品）を作り、ユーザーが確認・評価することでシステムの仕様を確定していく。ウォーターフォールモデルより手戻りが少なくなる利点がある。
スパイラルモデル
ウォーターフォールモデルとプロトタイピングの折衷案的な開発手法。システムをいくつかの部分に分け、部分ごとに開発のサイクルを繰り返す。
アジャイル開発
迅速で柔軟なシステム開発を目指した手法。2001年にまとめられたアジャイルソフトウェア開発宣言には次の4つの価値が示されている。
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うよりも変化への対応を
具体的な開発手法には以下のものがある
エクストリームプログラミング（XP）
柔軟なシステム開発に重点を置いた開発手法。5つの価値と19のプラクティスからなる。
5つの価値
価値とは開発において重視するものというような意味合いがある。
- コミュニケーション
- プロジェクトの失敗の原因の多くはコミュニケーション不足である。開発チーム内だけでなく顧客とのコミュニケーションも重視する。
- シンプル
- 最初の設計はシンプルにする。過度な実装はせず、必要な時に都度対応する。
- フィードバック
- ユーザーからのフィードバックを得て、必要な機能を洗い出す。不要な実装を避ける目的がある。
- 勇気
- 綿密な計画を立てないため、途中で大胆な変更がある場合がある。
- 尊重
- チームメンバーを尊重する。
19のプラクティス
4つのカテゴリに19のプラクティスがある。
| 共同のプラクティス |
|
| 開発のプラクティス |
|
| 管理者のプラクティス |
|
| 顧客のプラクティス |
|
- 反復（イテレーション）
- 設計～テストまでの一通りの作業が含まれる開発サイクルで、これを繰り返すことによりアジャイル開発が行われる。1つのイテレーションは1週間～1か月程度となる。
- テスト駆動開発
- プログラムより先にテストを作る手法。プログラマが品質を意識した開発を行うことを目的とする。
- ペアプログラミング
- 2人一組で実装を行う手法。一人はコードを書き（ドライバ）、一人はチェックを行う（ナビゲータ）。ペアは適宜変えながら行うことで、コミュニケーションを円滑化するとともに教育効果も見込む。
- リファクタリング
- 完成済みコードを動作を変更させずに改善させること。効率が良く保守性の高いコードにすることを目的とする。
- 継続的インテグレーション
- 開発者がソースコードを共有のリポジトリに頻繁にマージする手法。少なくとも1日1回はマージし、マージ後は自動化されたテストを実行する。バグを早期に発見、対処して、ソフトウェアの品質を高めることを目的とする。
スクラム
チームワークを重視したアジャイル開発手法の一つ。個々の開発者は次の3つの役割を持ち、スクラムチームを形成する
- プロダクトオーナ
- 作成したプロダクト（成果物）に最終的に責任を持つ人。
- スクラムマスタ
- プロジェクトの推進に責任を持つ人。全体の進行をサポートし、チーム内のトラブルなどに関してプロダクトオーナと相談し、開発中の指揮を執る。
- 開発者
- スクラムマスタやプロダクトオーナの指示に従い、実際に開発を進めるスタッフ。
スクラムの用語
- スプリント
- 開発工程の単位。これを繰り返すことで開発を進める。1つのスプリントごとに動くソフトウェアを作る。
- プロダクトバックログ
- プロダクトを作るにあたって、必要な項目を並べたリスト。それぞれの項目は優先順位が行われ、開発を進める中で項目の追加も行われる。
- スプリントバックログ
- 1回のスプリントごとに必要な項目を並べたリスト。開発者によって開発者のために作成され、リアルタイムで更新される。
- スプリントレトロスペクティブ
- スプリントの最後に行われる振り返り作業。
システム設計
システム設計のアプローチ方法
システム設計の際のアプローチ方法は以下の3種類がある
プロセス中心アプローチ（POA）
ソフトウェアの機能（プロセス）を中心に設計をする手法。システムをサブシステムに、さらに詳細に分割していき最小機能単位のモジュールにする。DFD（データフローダイアグラム）や状態遷移図などを用いて設計することが多い。また言語は構造化言語が用いられることが多い。
従来の作業との整合性が高く初期のシステム設計で用いられた手法で、現在も使用されているが、システム間の連携が取りにくく柔軟性に欠ける点がある。
データ中心アプローチ（DOA）
業務で扱うデータに着目して設計を行う手法。システムで重要なのはプロセスよりもデータであることに着目し、POAの改善を図ったもの。要求を分析して、E-R図を使ってデータモデリングを作成し、そのデータが入るデータベースを中心に設計を行うことによりデータの整合性や一貫性が保たれ、システム間の連携が容易になる。
オブジェクト指向アプローチ（OOA）
プログラムやデータをオブジェクトとしてとらえ、それを組み合わせてシステムを構築する。これはモジュール強度を高め、モジュール結合度を弱め、プログラムの生産性・保守性・再利用性を向上させる目的で行われる。UMLを用いて設計されることが多い。
システム設計で用いられる図
DFD（データフローダイアグラム）
プロセスを中心に、データの流れを記述する図。システムの入力・出力がどんな情報なのか、データがどこからきてどこへ行き、どこに格納されるのかを示す。構造化分析ツールの手法の一つ。以下の4つの要素で構成されている。
- データフロー
- データの流れを示したもの。以下に示す3つの要素間のデータの流れを示す。
- プロセス
- 入力されたデータに対して何らかの処理を行い出力する。
- データストア
- データの一時的な保管場所。データベースやファイルなどの媒体を示す。
- 外部実態
- 対象とするシステムの外側のもの。データを入力する人や外部システムなどを示し、外部要因となるため必ずしも記載する必要はない。記載されている場合はシステムへの理解を深めるための補助的なものと考えるとよい。源泉と吸収、ターミネータ、情報源などの呼び方もする。
DFDはシステムの構築過程において複数作成される。作成手順としては次の2通りがある
- 段階別詳細化（トップダウンアプローチ）
- 最初にシステム全体のDFDを作成たあと、プロセスに分割し、そのプロセス別にDFDを記述する。プロセスをさらに分割してさらにDFDを記述し、それがモジュールになるまで繰り返す。
- 新物理モデルの作成
- 現物理モデル→現論理モデル→新論理モデル→新物理モデルの順番で現状の業務からシステム化された新しいモデルを作成する。
UML
システムの構造や振る舞いなどを図示するために用いられる統一モデリング言語で、オブジェクト指向アプローチでよく使用される。1990年代は多くの技法が乱立していたが、それを標準化しようという意図で作成された。従来から用いられているフローチャートや状態遷移図も取り込み、14種類のダイアグラムからなる。ダイアグラム図はシステムの性的な構造を表す構造図とシステムの振る舞いを表す振る舞い図に分けられる。振る舞い図の中の相互作用にはさらに4つのダイアグラムがある。
構造図
- クラス図
- クラスの仕様とその関係性を表現する図。ほとんどのオブジェクト指向設計で用いられる。ER図の発展形。
- コンポーネント図
- ソフトウェアコンポーネントやモジュールの構造や繋がりを表現した概要図。システム全体を俯瞰する際に便利な図。
- ディプロイメント図（配置図）
- 物理的なハードウェア（処理ノード）の配置構造と、ハードウェア内部のコンポーネント間の関係性を表現したもの。ネットワークの通信状況などシステム管理者が見るのに便利な図。
- コンポジット図（複合構造図）
- パッケージ図
- オブジェクト図
- プロファイル図
振る舞い図
- アクティビティ図
- 処理の流れを表現する図。フローチャートに似ているが、並行処理やオブジェクトの流れを表すことができる。
- ステートマシン図
- オブジェクトの状態変化を表現する図。状態遷移図の発展形。
- ユースケース図
- システムが提供する機能と利用者の関係を表現する図。
相互作用図
- シーケンス図
- オブジェクト間の相互作用を時系列で表現する図。イベントの発生順序やオブジェクトの生存、メッセージの流れなどを表すことができる。
- インタラクション概要図
- タイミング図
- コミュニケーション図
- オブジェクト間の相互関係やメッセージの流れを表した図。
ソフトウェア品質
ソフトウェアの品質を指す。ソフトウェア品質の定義は様々あるが、試験対策的には標準化された規格であるJIS X 25010（ISO/IEC 25010）（システム及びソフトウェア製品の品質要求および評価（SQuaRE）―システム及びソフトウェア品質モデル）を覚える。
JIS X 25010
- 利用時の品質モデル
-
特定の使用状況におけるシステムとの対話結果に関係する5つの特性が定義されている。
- 有効性
- 効率性
- 満足性
- リスク回避性
- 利用状況網羅性
- 製品品質モデル
-
ソフトウェアの特徴に関係する8つの特性が定義されている。
- 機能適合性
- 性能効率性
- 互換性
- 使用性
- 信頼性
- セキュリティ
- 保守性
- 移植性