システムの開発・運用・評価の体系 その１ 開発
メルマガに載せる文を、アップしておきます。
なお、今日は、これを書いたので、いつもの応用情報の問題解答は、お休みします。
いままでは、システムそのものを体系化していました。
ここから数回は、そのシステムを開発・運用・評価するための体系について
見ていきたいと思います。
システムは作って、それを運用していかなければなりません。
そして、作ったシステムが妥当かどうか、評価していかなければなりません。
システムの開発、運用、評価には、以下のことが関係します。
・システムの開発
ソフトウェア工学
プロジェクトマネジメント
・システムの運用
サービスマネジメント
・システムの評価
ソフトウエアプロセス評価（CMMI等）
システム監査
今回は、「ソフトウェア工学」について体系化します。
-
-
-
- -
-
-
ソフトウェア工学は、ソフトウエア開発全体のプロセス等全体に関することと、
ソフトウエア開発の各プロセスの詳細についてのお話です。
情報処理試験では、このソフトウエア工学の分野を「開発技術」としてまとめ、
ソフトウエア開発の全体のプロセスなどを、「ソフトウェア開発管理技術」とし、
ソフトウエア開発の各プロセスに関することを「システム開発技術」としています。
「システム開発技術」は、開発の各工程に基づき、以下のように応用情報の
シラバスでは、詳細化されています。
1. システム要件定義
（1）システム要件定義のタスク
（2）システム要件の定義
（3）システム要件の評価
2. システム方式設計
（1）システム方式設計のタスク
（2）システムの最上位レベルでの方式確立
（3）システム結合テストの設計
（4）システム方式の評価
3. ソフトウェア要件定義
（1）ソフトウェア要件定義のタスク
（2）ソフトウェア要件の確立
（3）ソフトウェア要件の評価
（4）業務分析や要件定義に用いられる手法
4. ソフトウェア方式設計・ソフトウェア詳細設計
（1）ソフトウェア方式設計のタスク
（2）ソフトウェア詳細設計のタスク
（3）ソフトウェア方式設計
（4）ソフトウェア詳細設計
（5）インタフェース設計
（6）ソフトウェアユニットのテストの設計
（7）ソフトウェア結合テストの設計
（8）ソフトウェア設計評価
（9）ソフトウェア品質
（10）ソフトウェア設計手法
（11）コンポーネントの設計
（12）モジュールの設計
（13）部品化と再利用
（14）デザインパターン
（15）レビュー
5. ソフトウェアコード作成及びテスト
（1）ソフトウェアコード作成及びテストのタスク
（2）ソフトウェアコード作成
（3）ソフトウェアコード及びテスト結果の評価基準
（4）コーディング基準
（5）コードレビュー
（6）デバッグ
（7）ソフトウェアユニットのテスト
6. ソフトウェア結合・ソフトウェア適格性確認テスト
（1）ソフトウェア結合のタスク
（2）ソフトウェア適格性確認テストのタスク
（3）ソフトウェア結合テスト
（4）ソフトウェア適格性確認テスト
（5）テスト結果の評価
7. システム結合・システム適格性確認テスト
（1）システム結合のタスク
（2）システム適格性確認テストのタスク
（3）システム結合テスト
（4）システム適格性確認テスト
（5）テスト結果の評価
8. ソフトウェア導入
（1）ソフトウェア導入のタスク
（2）ソフトウェア導入計画の作成
（3）ソフトウェア導入の実施
（4）利用者支援
9. ソフトウェア受入れ
（1）ソフトウェア受入れ支援のタスク
（2）受入れレビューと受入れテスト
（3）ソフトウェア製品の納入と受入れ
（4）教育訓練
（5）利用者マニュアル
10. ソフトウェア保守
（1）ソフトウェア保守の意義
（2）ソフトウェア保守の形態
（3）ソフトウェア保守の手順
このプロセスの順番は、共通フレーム２００７（SLCP-JCF2007）
に基づいています。
各プロセスのはじめに、
〜のタスク
というのがあり、実際に行うアクティビティは、その下から、
〜（の）評価
と書かれている間になります。その後があるものについては、
手法、技法について書かれています。
-
-
- -
-
ソフトウエア工学などで言われる開発工程と対応させると、
3. ソフトウェア要件定義
は、要求分析
4. ソフトウェア方式設計・ソフトウェア詳細設計
の「ソフトウェア方式設計」が外部設計（基本設計）
の「ソフトウェア詳細設計」が詳細設計
5. ソフトウェアコード作成及びテスト
がプログラミング＆単体テスト
6. ソフトウェア結合・ソフトウェア適格性確認テスト
が結合テスト
7. システム結合・システム適格性確認テスト
が総合テスト
8. ソフトウェア導入
が移行（導入）準備
9. ソフトウェア受入れ
が導入・運用
10. ソフトウェア保守
が運用・保守
となります。とくに、設計のときテスト仕様を作ってしまうので、
W字開発に近いです。また、プログラミングと単体テストは、１つの
カテゴリなので、TDDでも問題ありません。
そうすると、「1. システム要件定義」と「2. システム方式設計」が
残りますが、これは何か？というと、RFPの段階が近いと思います。
1. システム要件定義
がRFP作成
2. システム方式設計
が提案書作成
に内容的には近いと思います。
-
-
-
- -
-
-
一方、各論ではなく、全体の話、「ソフトウェア開発管理技術」には
何が書いてあるかというと、こんなかんじです。
1. 開発プロセス・手法
（1）ソフトウェア開発手法
（2）構造化手法
（3）形式手法
（4）マッシュアップ
2. 知的財産適用管理
（1）著作権管理
（2）特許管理
（3）ライセンス管理
3. 開発環境管理
（1）開発環境構築
（2）管理対象
4. 構成管理・変更管理
（1）構成管理
（2）変更管理
「ソフトウェア開発手法」のところに、ウォーターフォールとか、アジャイル
などの手法が挙げられています。
なお、「構造化手法」があって、オブジェクト指向がないのは、オブジェクト
指向は、各論である、「システム開発技術」の 「3. ソフトウェア要件定義」
の「（4）業務分析や要件定義に用いられる手法」でUMLが、「4. ソフトウェア
方式設計・ソフトウェア詳細設計」の「（10）ソフトウェア設計手法」で、
オブジェクト指向設計が出てきているので、あえて、ここでは書いていないもの
と思われます。
-
-
-
- -
-
-
このように、情報処理試験では、ソフトウエア開発工程は、共通フレーム
２００７（SLCP-JCF2007）をもとに、構造化手法、オブジェクト指向共に
対応した内容となっています。
