ITパスポート 完全攻略②|マネジメント系【開発手法・PMBOK・ITIL・見積もり手法・EVMS】
ITパスポート対策の第2回です。「マネジメント系」の開発手法、プロジェクトマネジメント、ITサービスマネジメント、見積もり手法、EVMSを扱います。問題数は少なめですが範囲が狭いため高得点率を出しやすい分野です。
システム開発ライフサイクル(SDLC)
①システム要件定義②基本設計(外部設計、画面レイアウト等ユーザー視点)③詳細設計(内部設計、プログラマ向け)④プログラミング⑤テスト工程の順で進みます。
テスト工程の4段階
- 単体テスト:モジュール(部品)単体の動作確認
- 結合テスト:部品同士を繋げたインターフェースの確認
- システムテスト:システム全体として要件を満たしているか、性能や負荷を検証
- 運用テスト:実際の業務環境でユーザーが確認するテスト
開発手法:ウォーターフォール vs アジャイル
ウォーターフォールモデル:要件定義→外部設計→内部設計→開発→単体テスト→結合テスト→運用テストの順に、前工程が完全に終わってから次へ進む。進捗・予算の計画は立てやすいが、後からの仕様変更に極めて弱い(大規模・公共系向き)。
アジャイル開発:1〜4週間の短いサイクル(イテレーション/スプリント)で計画→設計→実装→テストを繰り返す。ビジネス環境の変化や急な仕様変更に柔軟に対応できる。
スクラム(アジャイルの代表的フレームワーク):プロダクトオーナー(PO、要件・仕様の責任者)、スクラムマスター(開発を支援し障害を除去するファシリテーター)、デイリースクラム(毎日15分程度の朝会)。
リファクタリング:ソフトウェアの「外部から見た振る舞い(機能)」を変えずに、保守性や可読性を高めるため内部のソースコード構造を改善すること。
プロジェクトマネジメント:アローダイアグラムとクリティカルパス
WBS(Work Breakdown Structure)はプロジェクト全体の作業を階層的に細分化した構成図。ガントチャートは横軸に時間、縦軸にタスクを配置した進捗管理図。
クリティカルパス:プロジェクト開始から終了まで最長時間を要する経路。この経路上の作業が遅れるとプロジェクト全体が遅延する。余裕時間(フロート)はゼロ。
演習:経路①A(2日)+C(4日)=6日、経路②B(3日)+C(4日)=7日の場合、クリティカルパスは経路②(7日)。
ソフトウェア開発の見積もり手法
| 手法名 | 算出方法・特徴 |
|---|---|
| ファンクションポイント法(FP法) | 画面数・帳票数・ファイル数等、外部から見える機能の数と複雑さに基づいて見積もる |
| COCOMO | 想定ステップ数(コード行数)に補正係数を掛け合わせて見積もる数式モデル |
| 類推見積法 | 過去の類似プロジェクトの実績データを参考に見積もる |
| ボトムアップ見積法 | WBSで細分化した最小単位ごとに工数を見積もり合算。精度は高いが時間がかかる |
EVMS(アーンドバリュー分析)
プロジェクトの進捗を「金銭価値(コスト)」に換算して客観的に管理する手法です。
- PV(Planned Value):現時点までに完了しているはずだった作業の計画予算
- EV(Earned Value):現時点で実際に完了した作業の予算価値
- AC(Actual Cost):現時点で実際にかかった実コスト
判定式:CV(コスト差異)=EV-AC(プラスなら予算内)。SV(スケジュール差異)=EV-PV(プラスなら前倒し)。CPI=EV÷AC(1以上で良好)。SPI=EV÷PV(1以上で良好)。
演習:PV=100万円、EV=80万円、AC=90万円の場合。SV=80-100=-20(遅延)、CV=80-90=-10(コスト超過)。進捗は遅れ、コストも超過している最悪の状態と判断できる。
ITサービスマネジメント(ITIL)
- ITIL:ITサービスマネジメントのベストプラクティス集
- SLA:サービス提供者と顧客間で合意したサービス品質保証契約(例:稼働率99.9%以上)
- SLM:SLAで定めた水準を維持・改善する継続的活動
- インシデント管理:サービス停止時、根本原因究明より「迅速な暫定復旧」を最優先とする活動
- 問題管理:インシデントの「根本原因を究明」し再発防止策を講じる活動
サービスデスクの形態:ローカル(同じ拠点に配置)/中央(複数拠点を1箇所に集約)/バーチャル(分散担当者がネットワーク経由で1つの窓口のように対応)/フォロー・ザ・サン(時差を利用し24時間365日対応)
ITIL4の追加概念:SVS(サービスバリューシステム)は需要から価値を生み出すまでの全体の仕組み。既知のエラー(Known Error)は根本原因が判明し暫定対処法が確立されている問題(KEDBに登録)。
システム監査
独立した第三者(システム監査人)が、情報システムのリスク管理や運用状況を客観的に評価・検証し、助言・勧告を行うこと。監査人は改善命令を出す権限はない(助言・勧告にとどまる)。
次回は「テクノロジ系基礎」編で、基数変換、メモリ階層、RAID、ネットワーク技術、データベース・SQLを扱います。
コメント
コメントを投稿