情報システムの運用（第11回）

ソフトウェア開発管理技術（マネジメント系・開発技術）

配布資料

第11回（問1～問26）
解答なし，解答あり，解説（要ID・パスワード）

訂正

(なし)

中分類9 「ソフトウェア開発管理技術」

【位置付け】

表: ITパスポート出題範囲（マネジメント系）
共通キャリア
  • スキルフレームワーク
    		•  出題範囲（出題の考え方）
    分野 大分類 中分類
    マ
    ネ
    ジ
    メ
    ン
    ト
    系    		 4開発技術 8システム開発技術
    • 要件定義，システム設計，プログラミング，テスト，ソフトウェア保守などシステム開発のプロセスの基本的な流れを問う。
    • システム開発における見積りの考え方を問う。
    9ソフトウェア開発管理技術
    • 代表的な開発モデルや開発手法に関する意義や目的について問う。
    5プロジェクトマネジメント 10プロジェクトマネジメント
    • プロジェクトマネジメントの意義，目的，考え方，プロセス，手法を問う。
    6サービスマネジメント 11サービスマネジメント
    • ITサービスマネジメントの意義，目的，考え方を問う。
    • サービスデスク（ヘルプデスク）など関連項目に関する理解を問う。
    • コンピュータやネットワークなどのシステム環境整備に関する考え方を問う。
    12システム監査
    • システム監査の意義，目的，考え方，対象を問う。
    • 計画，調査，報告など，システム監査の流れを問う。
    • 内部統制，IT ガバナンスの意義，目的，考え方を問う。

    【小分類】

    小分類26 「開発プロセス・手法」

    【目標】
    【説明】
    【項目】
    (1) 主なソフトウェア開発手法
    代表的なソフトウェア開発手法の特徴を理解する。
    用語例：構造化手法，オブジェクト指向，データ中心アプローチ，プロセス中心アプローチ，ユースケース，UML
    (2) 主なソフトウェア開発モデル
    代表的なソフトウェア開発モデルの特徴を理解する。
    用語例：ウォータフォールモデル，スパイラルモデル，プロトタイピングモデル，RAD（Rapid Application Development），アジャイル，リバースエンジニアリング
    (3) 開発プロセスに関するフレームワーク
    開発プロセスに関する代表的なフレームワークの特徴を理解する。
    ①共通フレーム
    ソフトウェア開発とその取引の適正化に向けて，それらのベースとなる作業項目を一つ一つ定義し，標準化した共通フレームとしてSLCP（Software Life Cycle Process）があり，その基本的な考え方を理解する。
    ②能力成熟度モデル
    開発と保守のプロセスを評価，改善するに当たって，システム開発組織のプロセス成熟度をモデル化したCMMI（Capability Maturity Model Integration：能力成熟度モデル統合）があること，成熟度を5段階のレベルで定義するなど，CMMIの基本的な考え方を理解する。

    小分類26 「開発プロセス・手法」

    (1) 主なソフトウェア開発手法

    表: 主なソフトウェア開発手法
    開発手法 説明
    構造化設計 手続きや関数を基本構造で表現し，部品化を推進して開発する手法。
    モジュール設計 データ形式の定義とそれを処理する手続きや関数をまとめたモジュールをもとにして開発する手法。
    プロセス中心アプローチ
    （POA：Process Oriented Approach）    		 業務の処理手順に着目してシステム開発を行う手法。
    処理（入力・加工・出力の3つの要素からなる）にもとづいて，システムを分割して，設計・実装を行う。
    業務プロセスの変更があると，システムの大規模な改修が必要となる。
    データ中心アプローチ
    （DOA：Data Oriented Approach）    		 業務で扱うデータの構造と流れに着目してシステム開発を行う手法。
    まず，業務データの統一的なデータベースを作成し，そのデータベースをもとにしてシステム設計・実装を行う。
    業務プロセスの変更には容易に対応できるが，業務データの変更があると，システムの大規模な改修が必要となる。
    オブジェクト指向設計
    （Object-oriented）    		 データ処理やシステム操作を手続きの流れとしてとらえるのではなく，“もの”およびその関係としてとらえて開発を行う手法。

    オブジェクト指向（Object-oriented）

    データと処理を一つのまとまりであるオブジェクト（Object）として定義する考え方。

    以下の4つの基本的な概念をもつ。

    ①クラス（Class）とインスタンス（Instance）
    個々の具体的なオブジェクトをインスタンス（Instance）と呼び，インスタンスを抽象化したものをクラス（Class）と呼ぶ。
    データと処理の手続きにより，クラスを定義でき，クラスを用いて，個々のインスタンスを生成できる。
    なお，処理の手続きはメソッド（Method）と呼ばれる。
    ②カプセル化（Encapsulation：エンカプセレーション）
    オブジェクト内部のデータやメソッドを隠蔽できる。
    ③インヘリタンス（Inheritance：継承）
    既に定義されているクラスの構造や機能を利用して，拡張や変更を加えた新しいクラスが定義できる。
    ④ポリモフィズム（Polymorphism：多態性，多様性，多相性）
    受け取るオブジェクトのクラスに応じて，同一のメソッドで異なった処理が行える。

    UML（Unified Modeling Language：統一モデリング言語）

    オブジェクト指向によるシステム開発などで用いられる，図を用いてモデルを記述するための言語。

    現在は，OMG（Object Management Group）が世界標準として規格化している。

    UMLの図は，システムの静的な構造を示す「構造図」と，システムの振る舞いを示す「振る舞い図」の2つに大別される。 また，振る舞い図の中で，オブジェクト間のメッセージのやり取りに着目したものを特に「相互作用図」と呼ぶ。

    UML 2.0以降では，以下の13種類の図が定義されている。

    表: UML 2.0の13種類の図
    分類 図 備考
    構造図 ①クラス図  
    ②オブジェクト図
    ③複合構造図（コンポジット構造図）
    ④コンポーネント図
    ⑤配置図
    ⑥パッケージ図
    振る舞い図 ⑦アクティビティ図  
    ⑧ユースケース図
    ⑨ステートチャート図（状態遷移図，ステートマシン図，状態機械図）
    ⑩シーケンス図 相互作用図
    ⑪コミュニケーションズ図
    ⑫相互作用概要図
    ⑬タイミング図

    (2) 主なソフトウェア開発モデル

    表: 主なソフトウェア開発モデル
    開発モデル 説明
    ウォータフォールモデル システム開発のプロセスを複数の工程に分割し，要件定義（基本計画），システム設計（外部設計，内部設計），プログラミング，テストなどのように，上流工程から下流工程に向けて，一つひとつの工程を完了させてから次の工程に移る開発手法。
    次工程から手戻りが発生しないように，各工程が終了する際に厳密にチェックを行う。
    全体を見通すことができ，スケジュールの決定や資源配分が容易になる。
    成長モデル 開発するシステムを独立性の高いソフトウェアに分割し，ソフトウェアを仕様変更の可能性があるものとないものに分類する。
    仕様変更の可能性がないものについては，ウォータフォールモデルと同様の手法で開発し，
    仕様変更の可能性があるものについては，作成，見直し，変更のプロセスを繰り返す。
    スパイラルモデル 大規模アプリケーションを独立性の高い部分に分割し，その部分ごとに，設計，プログラミング，テストの工程を繰返し（分析と設計，プログラミングを何度か行き来しながら，トライアンドエラーで）徐々にその開発範囲を広げて，完成させていく手法のこと。
    基本的にオブジェクト指向開発で用いられる開発手法。
    プロトタイピングモデル プロトタイプ（試作品）を作成し，ユーザによるプロトタイプの評価・プロトタイプの修正を繰り返すことで，比較的短期間にユーザの要求するシステムを開発する手法。
    システム開発の早い段階で試作品を作成するので，ユーザ部門と開発部門との認識のずれやあいまいさを早期に取り除くことができる。
    RAD（Rapid Application Development） システム全体を，独立性の高い複数のサブシステムに分割し，サブシステム単位で開発を行い，一つのサブシステムの開発が完了すると，次のサブシステムの開発を繰り返し，システム全体を完成させる開発手法。

    (3) 開発プロセスに関するフレームワーク

    ①共通フレーム

    • SLCP
    SLCP（Software Life Cycle Process）とは，ソフトウェア開発とその取引の適正化に向けて，それらのベースとなる作業項目（用語や作業内容など）を一つひとつ定義し，標準化するために作られたガイドライン。

    ②CMMI

    CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）とは，ソフトウェア開発工程をより適切に管理できるようになることを目的として，遵守するべき指針を体系化したもの。

    CMMIでは，プロセス習熟度を以下の5つのレベルとして規定している。

    1. 初期状態
      混沌とした，行当りばったりな，一部の有能なメンバーに依存している状態。
    2. 管理された状態
      プロジェクト管理やプロセス規則が存在し，反復してプロセスを実行できる状態。
    3. 定義された状態
      標準プロセスとして明示的に定義され，関係者の承認を得ている状態。
    4. 定量的に管理された状態
      プロセスの定量的な品質目標が設定され，計測・管理されている状態。
    5. 最適化している状態
      継続的に自らプロセスの改善が可能な状態。

    CMMIはソフトウェア開発工程の評価・改善に用いることができる。

    (4) その他

    ①システム開発の上流過程と下流過程

    システム開発を，①要件定義（基本計画），②外部設計，③内部設計，④プログラム設計，⑤プログラミング，⑥テストの6工程とすると，①～③の工程を上流工程，④～⑥の工程を下流工程と呼ぶ。

    • フォワードエンジニアリング（Forward Engineering）
    システム開発の上流過程から下流過程に向かって開発を行うこと。
    • リバースエンジニアリング（Reverse Engineering）
    ソフトウェアやハードウェアなどの完成品を分析・分解することで，その仕様や仕組み，利用されている技術などを解明し，設計仕様などのシステム開発の上流工程の成果を抽出する開発手法。
    • コンカレントエンジニアリング（Concurrent Engineering）
    製品開発において，概念設計・詳細設計・生産設計・生産準備など，各種設計および生産計画などの工程を同時並行的に行うことにより，開発期間や納期を短縮や生産の効率化などを進める手法。

    ②CASEツール

    CASE（Computer Aided Software Engineering：コンピュータ支援ソフトウェア工学）ツールとは，ソフトウェア開発の効率化，自動化を支援するツール。

    • 上流CASEツール
    上流工程（基本計画→外部設計→内部設計の工程）を支援するCASEツール。
    • 下流CASEツール
    下流工程（プログラム設計→プログラミング→テストの工程）を支援するCASEツール。
    • 統合CASEツール
    ソフトウェア開発の全工程を支援するCASEツール。

    ③ソフトウェアの品質特性

    ソフトウェアの品質特性とは，ソフトウェアの品質を評価する基準のこと。

    ISO/IEC 9126では，以下の6つの品質特性を定めている。

    (1) 機能性（Functionality）
    使用目的から求められる必要な機能の実装の度合い
    (2) 信頼性（Reliability）
    機能が正常動作し続ける度合い，障害の起こりにくさの度合い
    (3) 使用性（Usability）
    分かりやすさの度合い，使いやすさの度合い
    (4) 効率性（Efficiency）
    目的達成のために使用する資源の度合い
    (5) 保守性（Maintainability）
    保守（改訂）作業に必要な労力の度合い
    (6) 移植性（Portability）
    移植のしやすさの度合い，別の環境へ移した際そのまま動作する度合い

    ④信頼度成長曲線

    横軸をテスト項目消化数（または時間）として，縦軸を累積バグ発見数（発見された総エラー数）としてプロットしたグラフ。

    ゴンペルツ曲線やロジスティック曲線などのS字曲線となる場合が多い。

    これは，最初はテストに不慣れなためバグ発見率が低いが，次第にテストに慣れるにつれバグ発見率が高くなり，最終的にはバグの残りが少なくなるため再び発見率が低くなりゼロに近づくため。

    すぎうら しげき <>