ソフトウェアの開発工程

Size: px

Start display at page:

Download "ソフトウェアの開発工程"

れれかなり
5 years ago
Views:

1 プロジェクト管理プロジェクト管理の概要開発工程を見積もる方法成果物やプロセスの品質を評価する方法 1

2 1. プロジェクトの計画と管理プロジェクト管理とは要求を満たすソフトウェアを顧客に決められた期間で納品するために, ソフトウェア開発において, 誰がどの段階で何をすればよいのかを計画する作業プロジェクト管理の目的遂行に関わる経営諸資源 ( 人, 物, 金, 技術, 情報 ) を最も効果的に使用し, 費用時間品質の統合化を計りつつ, プロジェクトの目標を達成すること 2

3 1.1 プロジェクト計画プロジェクト計画において検討すべき項目 1. 開発目的 2. 開発目標 3. 開発対象業務及び運用方針 4. 開発システムの基本構成 5. 開発工数 6. 開発スケジュール 7. 開発体制 8. 開発環境や開発方法 9. 成果物の管理方法 10. リスクの管理方法 3

4 (6) 開発スケジュールで用いられる手法作業明細構造 : プロジェクトで実行される作業 ( アクティビティ ) を分割, 詳細化して記述したものガントチャート : 各アクティビティを並列に記述し, それぞれの作業期間を棒グラフで示したもの 4

5 作業明細構造の例ネット販売システムの構築システム計画 (1.0) 設計 (2.0) 実装 (3.0) 仕様の検討 (1.1) 予算の検討 (1.2) スケジュールの検討 (1.3) 計画の立案 (1.4) 最上位レベルの設計 (2.1) プロトタイプの作成 (2.2) UI 設計 (2.3) 詳細設計 (2.4) コーディング (3.1) 5

6 システム計画設計実装ガントチャートの例作業内容 1 月 2 月 3 月 4 月 5 月 6 月 7 月 8 月 9 月 10 月 11 月 12 月 1.1 仕様の検討 ( 仕様の承認 ) 1.2 予算の検討 ( 予算の承認 ) 1.3 スケジュールの検討 ( スケジュールの承認 ) 1.4 計画の立案 ( 計画の承認 ) 2.1 最上位レベルの設計 2.2 プロトタイプの作成 2.3 UI 設計 2.4 詳細設計 ( 設計の承認 ) 3.1 コーディング最後に演習マイルストーン : 特定のアクティビティの終了時点完了タスク本日予定タスク 6

7 (8) 開発環境や開発方法 : ハードウェア環境文書を作成閲覧するコンピュータ, プログラミングを行うコンピュータ, テストに使用するコンピュータ : ソフトウェア環境 OS, プログラミング言語, コンパイラ, 種々の開発ツール, コミュニケーションのためのツール : 方法論, コーディング規約, テストの方針 (10) リスクの管理方法リスク衝撃 ( リスクにより引き起こされる損失 ), リスク確率, リスク制御 ( リスクの影響を最小限に回避 ) 7

8 1.2 開発工程の見積もりプロジェクトの規模を見積もる代表的な方法 1. 経験に基づく方法 2. LOC 法生成するソースコードの行数 (Lines of source code) をもとに開発規模を見積もる方法 3. ファンクションポイント法開発にかかる工数を見積もる代表的な方法 1. 経験に基づく方法 2. 標準タスク法 3. COCOMO 4. COCOMO II 8

9 ファンクションポイント法 (FP 法 ) アルブレヒト (Allan J. Albrecht) ソフトウェアに含まれる機能の数 ( ファンクションポイント ) により, ソフトウェアの規模を算出する方法ソフトウェアの内部でどのような処理が行われているか ( 行われる予定か ) を分析し,5 つの機能に分類 (1) 外部入力 (external input:ei) 外部からソフトウェアへの入力 (2) 外部出力 (external output:eo) ソフトウェアから外部への出力 9

10 (3) 外部照会 (external inquiries:eq) 外部からソフトウェアへの照会 (4) 内部論理ファイル (internal logical files:ilf) ソフトウェア内部に存在するファイルの規模 (5) 外部インタフェースファイル (external interface file:eif) 他のシステムで管理され, ソフトウェアが参照するファイルの規模 10

11 ファンクションポイント法における機能分類と複雑度に関するマトリックス利用者 EI EO 開発ソフトウェア ILF ELF 外部システム EQ EIの複雑度関連でデータ項目数ファイル数 1~4 5~15 15~ 0~1 単純単純普通 2 単純普通複雑 3~ 普通複雑複雑内部論理ファイル ILF, ELFの複雑度関連でデータ項目数ファイル数 1~4 5~15 15~ 0~1 単純単純普通 2 単純普通複雑 3~ 普通複雑複雑 EI: 外部入力 ( 入力画面など ) EO: 外部出力 ( 集計や分析フォーマッティングを行った出力画面, 帳票出力画面 ) EQ: 外部照会 ( インプットとアウトプットがそのまま同じような単純な入力出力機能単票の入力画面など ) ILF: 内部論理ファイル ( データベース ) EIF: 外部インタフェースファイル ( オンライン処理など ) EO, EQ の複雑度関連ファイル数でデータ項目数 1~4 5~15 15~ 0~1 単純単純普通 2 単純普通複雑 3~ 普通複雑複雑 11

12 ファンクションポイントの算出複雑度機能単純普通複雑 EI EO EQ ILF EIF 複雑度機能 (b) 重み付け係数単純普通複雑 EI EO EQ ILF EIF (a) 複雑度別の機能数 EI: 外部入力 EO: 外部出力 EQ: 外部照会 ILF: 内部論理ファイル EIF: 外部インタフェースファイル複雑度機能単純普通複雑 EI EO EQ ILF EIF =680 ( 未調整 FP) (c) ファンクションポイント 12

13 最終的なファンクションポイントを算出する際には, ソフトウェアの特性に応じて得点を割り当て, 調整用係数を算出する必要があるソフトウェアの特性を評価する項目は, 全部で 14 項目 ( データ通信, 分散処理, パフォーマンス, など ) 各項目に対して,6 段階で得点を付ける 0: まったく関係ない 1: ほとんど影響を受けない 2: 適度に影響を受ける 3: 平均的な影響を受ける 4: 大きな影響を受ける 5: 非常に大きな影響を受ける 13

14 ソフトウェアの特性に関する合計得点を P とすると調整用係数 C = ( 0.01 合計得点 P ) P の最大値は 70(5 点 14 項目 ) 調整後のファンクションポイントは FP = ( 調整用係数 C ) ( 未調整ファンクションポイント ) 調整用係数の範囲 :0.65~1.35 例 ) P=28 のとき C = 0.93 最終的なファンクションポイント FP = =

15 オブジェクトポイント法自然言語 (4GL) に類するものには FP 法に代えて利用可能 1) 各オブジェクトの複雑度を重みづけ 2) 上記を合計 3)NOP = OP ( 1 - 再利用比率 ) 4) 環境要因 PRG 生産性の逆数をかけて工数を求める 15

16 標準タスク法ソフトウェア開発に必要とされる作業 ( 標準タスク ) ごとに開発工数をあらかじめ設定し, そのうえで, 実際のソフトウェア開発に現れる作業を予測して, それらに応じて工数を積み上げていく算出方法 16

17 標準タスク法による工数見積もりの例 (a) 標準タスク A の作業工数複雑度規模単純普通複雑小中大 (b) プロジェクト X における標準タスク A の件数複雑度規模単純普通複雑小中大複雑度規模単純普通複雑小中大 (c) プロジェクト X における標準タスク A の工数標準タスク A の総工数 =260 プロジェクト X の総工数 = 標準タスク A の総工数 + 標準タスク B の総工数 + 17

18 COCOMO Constructive Cost Model ソフトウェアの開発規模と開発工数の関係を統計的なモデルから推測する技法開発ソフトウェアの規模を, コメントを除いたソースコードの行数 (Line of code:loc) で測定開発規模 (LOC) COCOMO 変換モデル開発工数 { 基本 COCOMO 中間 COCOMO 詳細 COCOMO { 組織モード : 小規模開発で小規模なチームによる組込みモード : 大規模で複雑な開発を多人数で行う半組込みモード : 組織モードと組込みモードの中間的な開発 18

19 (1) 基本 COCOMO 開発の初期段階で使い, 主として LOC だけで見積もる (2) 中間 COCOMO 要求定義が完了した後で使い, 構成要素ごとに影響要因を考慮して見積もる (3) 詳細 COCOMO 設計が終了した後で使い, システムサブシステムモジュールの 3 分割に対して影響要因を考慮して見積もる 19

20 COCOMO で用意されている 3 つのモード (1) 組織モード少人数で行う単純で小規模な開発の場合のモード開発自体を自社で行っている場合に相当 (2) 組み込みモード複雑で大規模, あるいは, 厳しい制約をもつ開発の場合 (3) 半組み込みモード一般的な業務処理ソフトウェアの開発などの場合のモード最終的な開発工数は, 人月値 (1 人が 1 カ月の間にソフトウェア開発に費やす時間 ) 20

21 COCOMO II 開発工程の早期にソースコードの行数を知ることは困難 COCOMO II 3 つのモデルを用いて開発工程を見積もる (1) アプリケーション組み立てモデル GUI ビルダーやコンポーネントを用いたプロトタイプ開発において, オブジェクトポイントの観点からソフトウェアの規模を見積もるモデル (2) 初期設計モデルファンクションポイント法を用いて, 機能数から規模を測定するモデル (3) ポストアーキテクチャモデル外部設計によりシステム構造が定義された後に, ファンクションポイント法やソースコードの行数により開発工数を算出するモデル 21

22 2. プロジェクト管理の知識体系従来のプロジェクト管理 QCD quality: 品質 cost: コスト delivety: 納期 + KKD( 勘と経験と度胸 ) PMI( 米国プロジェクト管理協会 ) PMBOK( プロジェクト知識管理体系 ) プロセス群を 5 つのグループに分類日本国内のガイドライン : SLCP-JCF98 : 6 つの主プロセス,8 つの支援プロセス, 4 つの組織に関するプロセス, システム監査プロセス, 修正プロセス 22

23 PMBOK の 9 つの視点 ( 知識エリア : 管理すべき対象領域 ) 視点内容総合管理スコープ管理時間管理コスト管理品質管理人的資源 ( 人材 ) 管理コミュニケーション管理リスク管理調達管理プロジェクト計画の策定, 実施, 変更管理スコープ ( プロジェクトで実施される作業やプロジェクトで生成される成果物 ) に関する定義, 検証, 変更管理スケジュールの作成, 作業順序の決定, 所要時間の見積もり, 進捗管理資源計画, コストの見積もりと予算化品質 ( 信頼性, 使用性, 保守性など ) の評価と保証プロジェクトチームの組織構成, 開発要員の調達, チーム編成や育成情報の共有化, コミュニケーションの確立, 実績報告リスクの洗い出し, リスクの定量化, リスク対策機器の調達, 発注先の選定, 契約 23

24 アーンドバリュー (Earned Value) 分析コスト, 資源, 生産性を管理するために有効なツールアーンドバリュー : 成果物の達成度を金額に換算した出来高のこと出来高 ( 完了した作業の予算コスト ), 実コスト計画を比較して, パフォーマンスを測定する実コスト (AC:Actual Cost) 実際に費やした作業コストのこと作業実行者のコスト単価と要した時間で求めることができるコスト差異 (CV:Cost Variance) ある時点における計画コスト値と実績コスト値の差のことアーンドバリュー (EV) から実コスト (AC) を引いた値がコスト差異 (CV) となる CV = EV - AC 値が 0 であれば計画通りであることを示す正の値なら計画を下回っていることを示して負の値だと計画コストを超過していることになる 24

25 スケジュール差異 (SV:Schedule Variance) ある時点における計画スケジュール値と実績進捗値の差のこと SV = EV - PV 値が 0 であれば計画通りであることを示す正の値なら計画を前倒ししていることを示して負の値だと計画から遅れていることになるコスト効率指数 (CPI:Cost Performance Index) プロジェクトのパフォーマンスを計測する指標で計画時の予算をベースにコストの効率を測る計画予算から計測時点で超過しているのか下回っているのかまた何パーセント乖離しているかを知ることができる CPI = EV / AC CPI が 1.0 未満のときにはコスト超過を示し 1.0 を上回っている場合には見積りコストを下回っていることを示すスケジュール効率指数 (SPI:Schedule Performance Index) プロジェクトのパフォーマンスを計測する指標で計画時の予算をベースにスケジュールの効率を測る計画スケジュールから計測時点で超過しているのか下回っているのかまた何パーセント乖離しているかを知ることができる SPI = EV / PV SPI が 1.0 未満のときにはスケジュールが遅れていることを示し 1.0 を上回っている場合には計画より前倒しに進んでいることを示す 25

26 完成時総コスト見積り (EAC:Estimate at Completion) ある時点でその作業が全て完了した際の総コストを予想した値 EAC を求めるには 3 種類の方法がある差異を反映した EAC 現在生じている計画と実績の差異が今後も継続すると判断した場合に用いられるつまり現時点で計測したコスト効率 (CPI) が今後も変化せずに継続すると判断できる場合にこの方法を採用する EAC = AC + (BAC - EV) / CPI = BAC / CPI 偶発差異を織り込んだ EAC 現在の計画と実績の差異が特殊なもので今後同様の差異は生じないだろうと判断した場合に用いられるつまり以降は計画時に設定したコスト効率で作業が進められると判断できるときはこれらの方法を使用する EAC = AC + (BAC - EV) 前提条件に誤りがある場合の EAC これはつまり見積もり直す必要があるということでそれまでの実績値では求めることはできない再見積もりした残作業見積もり (ETC) を現在の実コストに足すことで EAC の値になる EAC = AC + ETC 26

27 残作業のコスト見積り (ETC:Estimate to Complete) ある時点で終わっていない作業量をコスト的に定量化した値のこと ETC = EAC - AC 完成時総予算 (BAC:Budget at Completion) 作業が完了した時点の PV の値のこと作業が完了した時点の EV の値でも同じつまりその作業が完了するのに必要だと見積もった計画値のこと 27

28 EAC BAC PC EV 28

29 EVM の計算例計画 : a. 完了予定予算 BAC = 1000 万円 b. 予定工期 5ヶ月現時点の測定値 : c. 測定時の計画価値 ( 予算 ) PV = 300 万円 d. アーンドバリュー EV = 240 万円実コスト AC = 400 万円現状把握 : e. コスト差異 CV = EV-AC = = -160 万円 (160 万円のコスト超過 ) f. スケジュール差異 SV = EV-PV = = -60 万円 (60 万円分のスケジュール遅延 ) g. コスト効率指数 CPI = EV/AC = 240/400 = 0.6( 予定より40% コスト超過 ) * 予算消費実績 (400 万円 ) に対して60% の価値しか生み出していない h. スケジュール効率指数 SPI = EV/PV = 240/300 = 0.8( 予定より20% スケジュール遅延 ) * スケジュールは予定に対して 80% しか進んでいない完了時予測 : i. 今後発生するコスト予測 ETC =(BAC-EV)/CPI =( )/ 万円 ( 但し今後も同様の傾向が続くと仮定 ) j. 完了時総コスト予測 EAC = AC + ETC = = 1667 万円 (667 万円のコスト超過 ) k. 予測工期完了予測後期 = 予定工期 /SPI = 5/0.8 = 6.25ヶ月 (1.25ヶ月の工期超過) 29

30 30

31 例 ) 製造コスト 10 万円の製品を 10 個作るプロジェクト基本パラメータ完成時総予算 (BAC:Budget at Completion) 完成時総予算プロジェクトの総予算 31

32 アーンドバリュー (EV:Earned Value) 出来高完了した作業に対する予算コスト予算上 100 万円分のコストの作業を完了したら EV は 100 万円たとえ実際のコストが 1000 万円であっても 1 万円であっても 32

33 プランドバリュー (PV:Planed Value) ある時点で完成する予定の作業に対する予算コスト 4 月 1 日に 100 万円分の予算の作業が完了する計画になっていたらその時点の PV は 100 万円実際は計画からすごく遅れているかもしれないけど計画上は現時点で 100 万円分の作業が完了したはずだよねというのが PV 33

34 実コスト (AC:Actual Cost) ある時点までの作業によって発生した実際のコスト 5 月 1 日時点で合計 1 億円のコストが出ていたら 5 月 1 日時点の AC は 1 億円 34

35 パフォーマンスを測定する指標スケジュール差異 (SV:Schedule Valiance) SV = EV - PV ( 出来高から計画を引いたもの ) プラスならば作業先行 (OK) マイナスなら遅延 (NG) SV が 1 万円なら 1 万円分の作業が進んでいる SV がマイナス 1 万円なら 1 万円分の作業が遅れている 35

36 コスト差異 (CV:Cost Valiance) CV = EV - AC ( 出来高から実際のコストを引いたもの ) プラスならコスト内 (OK) マイナスならコスト超過 (NG) CV が 1 万円なら予定より 1 万円少ないコストで済んでいる CV がマイナス 1 万円なら予定より 1 万円のコスト超過 36

37 スケジュール効率指数 (SPI:Schedule Performance Index) CPI = EV / AC ( 出来高と実コストの比 ) 1 より大きい場合はコスト効率が良い (OK) ( 出来高 > 実コスト ) 1 より小さい場合はコスト効率が悪い (NG) ( 出来高 < 実コスト ) CPI = 1.1 ならば 1.1 のコストがかかる作業を 1 のコストで終わらせた CPI = 0.9 ならば 0.9 のコストがかかる作業に 1 のコストを使ってしまっている 37

38 38

39 残作業のコスト見積り (ETC:Estimate To Complete) ETC=(BAC-EV) CPI 現在の CPI が今後も続く場合のモデル ETC の計算方法はモデルによって異なる 39

40 完成時総コスト見積り (EAC:Estimate At Completion) EAC = AC+ETC 完了時コスト差異 (VAC:Variance At Completion) VAC = BAC-EAC 40

41 残作業効率指数 (TCPI:To-Complete- Performance-Index) TCPI=(BAC EV)/(BAC AC) もしくは (BAC EV)/(EAC AC) 計画を当初予算を変えない場合と目標予算を変更した場合計画予算内に収めるために必要となるコスト効率 41

42 42

43 PMBOK における 5 つのプロセス群 (1) 立ち上げプロセス : プロジェクトまたはプロジェクトのフェーズを定義し, 認可する (2) 計画プロセス : プロジェクトの目標を定め, それを洗練するさらに, 目標とスコープを達成するために必要な一連の活動を計画する資源 ( 予算, 人, 機器など ) の調達も行う (3) 遂行プロセス : プロジェクト計画を実施するスコープの検証や品質の保証も行う (4) 制御プロセス : プロジェクト計画との差異を認識するために, 実績報告や進捗の測定を行う変更管理やリスク対応も行う (5) 終結プロセス : 契約の完了手続き行い, プロジェクトを終了する 43

44 3. プロセス評価モデルソフトウェアプロセス改善のサイクル 1. プロセスの計測 2. プロセスの分析 3. プロセスの変更 44

45 CMMI (CMM Integration) CMM(Capability Maturity Model): SEI(Software Engineering Institute) が,1980 年代半ばに構築した, ソフトウェアプロセスの成熟度に関するモデル CMMI (CMM Integration): 他の領域にも提供できるように, 類似したモデルを統合したモデル 45

46 SW-CMM における成熟度定量的な分析のフィードバックにより継続的にプロセスを改善できるレベル 5 最適化プロセスとプロダクトの定量的データを収集しているデータ分析とデータに基づく管理ができるレベル 4 管理化プロセス改善プロセスが文書化, 標準化されているすべてのプロジェクトで標準プロセスを利用しているレベル 1 初期レベル 2 反復可能レベル 3 既定義プロセスの抑制プロセスの定義定量的管理基本的な管理プロセスが存在する過去に成功したプロセスを繰り返せるプロセスが未定義である成功は偶然か個人の能力で決まる 46

47 4. プロジェクト管理におけるヒューマンファクターピープルウェアコンピュータに関係する構成要素の考え方で, ハードウェアとソフトウェアと対比して人間的要因を表した用語ブルックスの法則遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけデスマーチ長時間の作業といった作業環境悪い状況で, 成功の可能性が低いプロジェクトに参加させられている状況を説明する言葉 47

48 ガントチャート演習 48

49 ガントチャートとはプロジェクト管理や生産管理などあらゆる管理工程に使う表横棒グラフを使用し完了日などを管理するスケジュール表管理表などと呼ぶ組織もある何かの作業を進めていく段取りを項目別にまとめた表全体の計画を見える化しパッと見ただけでおおむね全体像をつかめるツリー構造とチャート ( 横棒 ) で表す左側のツリー構造部分には管理するタスク名完了日などの日付のデータ担当者などの項目を列挙右側のチャートには開始日と完了 ( 予定 ) 日 +α を表記横軸の単位は日週期年などプロジェクトの長さによってスケールを変えて表記 49

50 ガントチャートに使う項目の例やること ( 管理項目名 ) 開始日完了 ( 予定 ) 日作業内容担当者作業間の関連マイルストーン 50

51 例 ) あなたは料理の素人 3 人のチームでイタリアンのランチをランチタイム内に提供するというプロジェクトのマネジャーになりましたやるべきことを列挙し上司に報連相しながら期日まで ( 時間内 ) に料理を出さなければならない 51

52 プロジェクトの3つの決まっていること目的が定まっているイタリアンのランチを提供する期限が決まっている 11~14 時のランチタイム内使える資源が決まっているメンバー 3 人コンロ 2つまな板 1 枚 52

53 プロジェクトを管理するために必要なこと 1. やるべきタスクを洗い出す ( 網羅されていること ) 2. 上司や先輩に本当にこのやり方で良いのか事前にチェックしてもらう 3. タスクを分類する ( 管理しやすいようにまとめる ) 4. タスクにメンバーをアサインする ( 責任の所在をはっきりさせる ) 5. おのおののタスクに開始日と完了日を設定する ( そのうちは NG) 53

54 プロジェクトの管理手段 54

55 タスクを洗い出す 55

56 もう少し細かく 56

57 おそらくこれは細かすぎ 57

58 ガントチャートのタタキができ, ピザの生地作りピザの盛り付け焼きサイドメニュー ( サラダとスープ ) の作成という 3 つの大きな流れが分かる 58

59 作業日程を割り振る 59

60 まとめガントチャート作成時の注意点タスクの粒度は細か過ぎず荒過ぎず項目を眺めただけで全体像がイメージできる程度を目安にする作業日程の割り振りは最初からムリな計画を立てない 60

61 ガントチャートで使われる用語 61

62 タスク管理項目の最小単位開始日完了予定日が定義されているタスクグループ複数のタスクを束ねたものイタリアンランチプロジェクトではピザを作るというタスクグループの中に生地作りソースを作る焼く仕上げという 4 つのタスクが入っている複雑なチャートになるとこの階層が複数に何重にもなるリンクタスクの依存関係タスク A で作成した成果物を用いてタスク B を作成するなどがある 62

63 ステータスタスクの状況を表すもの着手前着手順調遅れ完了などが代表的なステータスアウトプット成果物プロジェクトやタスクグループステータスごとに成果物がある道路工事プロジェクトでれば開始時途中完了後に提出する写真などが成果物に当たるマイルストーン進捗 ( しんちょく ) を管理するために途中に設定している目印もともとは高速道路などで距離を表す標識の意味最終的なゴールへの重要な途中経過と考えるとよい製品開発プロジェクトであればリリース会議や試作品の判定会などが設定される 63

64 リソース管理する ( される ) 項目分かりやすいのは人お金であったり設備であったり資材であったりもするリソース管理という言葉も使われるクリティカルパスプロジェクト全体に関わる重要なタスク郡イタリアンランチプロジェクトであればピザ作成の生地作りの辺りここがコケるとピザのないイタリアンランチになりかねないガントチャートでプロジェクトを管理する肝はクリティカルパスを見える化し全体のスケジュールが遅れないようにすることと言っても過言ではない 64

65 Excel でガントチャート作成基本のガントチャートを Excel で作る 65

66 1 タスクを洗い出す 2 タスクをグルーピングする 66

67 料理名ピッツァスープサラダの三つが大項目大項目の下に中項目として料理の工程を設定大項目ピッツァの中項目は生地作りソースを作る焼く仕上げの四つその後洗い出したタスクを中項目にひも付ける例えばタスク生地をこねる生地を伸ばすは中項目生地作りにひも付く 67

68 3 Excel にタスクと日付を記入する Excel の A 列にタスクをグループごとに記入するインデントを操作してタスクの階層を見える化する行 1 に月を行 2 に日を記入セルの色を変更して曜日の区別を付ける ( ここでは平日を灰色に土曜日を薄い青色に日曜日を薄い赤い色に ) 68

69 ツールバーのインデントボタン Sheet1 69

70 70

71 4 日程の割り振り各タスクを実行するために必要な日程を割り振り割り振られた日程のセルの色を変更 ( ここでは紺色に塗りつぶし ) 71

72 5 マイルストーンの設定最後にマイルストーン ( 目印 ) を入れるピッツァ作成は生地の出来具合が重要中盤に生地ができているかの確認というマイルストーンを追加ゴールとしてテーブルに運んでフィニッシュというマイルストーンも追加 72

73 Sample ここまで,Sheet2 73

74 関数とグラフで負荷状況を見える化する Excel の機能を使ってガントチャートをさらに便利にする 74

75 1 タスクの数 ( 工数 ) を積算する Excel の COUNTA 関数を使って日別の工数を積算できるようにする (COUNTA は指定した範囲に含まれるデータの合計を計算する関数 ) 1) まずタスクの入っているセルに何でもいいので文字を入力ここでは見た目に分かりやすいようにという黒い四角の文字を使う分かりやすいように文字を赤くするが実際に作成する場合は背景と同じ色で構わない 75

76 2) 次に日にちの一番下のセルに文字の入ったセルをカウントする関数 COUNTA を使った式を記述するこれで一日ごとのプロジェクト全体のタスク数が計算できる例えばセル F44 に =COUNTA(F9:F43) と記入すると入力した範囲内のの総数が表示される 76

77 77

78 2 プロジェクトの負荷状況を見える化する Excel のスパークライン機能 ( ワークシートのセル内でデータを視覚的に表現する小さな棒グラフ ) を使って作成した日ごとのタスク数をグラフ表示しプロジェクトの負荷状況が一目で分かるようにする (Excel 2010 以降 ) 78

79 スパークラインの挿入手順 1. 対象期間の上にあるセルを全て選んで一つに結合する (F~CA) 2. 結合したセルをクリックしてツールバーよりグラフスパークラインを選択する 3. スパークラインの挿入というボックスが出てくるのでデータ範囲をマウスでドラッグして指定する ( 今回は積算されたタスク数を表す F45~CA45 配置する場所で 1 で結合したセルを指定する OK ボタンを押す 79

80 80

81 負荷状況を調整する図のグラフを見ると 7 月 16 日前後のタスクが多過ぎることが分かるタブを見ると 7 月 15 ~17 日の工数合計が 4 となっている (Excel の条件付き書式を活用 ) 本プロジェクトの条件はメンバーは 3 人 1 人が 1 度に処理できるタスクは 1 つまで =4 つのタスクを同時進行させられないなので工数合計がオーバーしている日のタスクを他の日に割り振って負荷を分散させなければならない 81

82 全体のバランスを見ると中項目オニオンスープを作るの日程を変更しても全体に支障が出ないことが分かるのでこれらを 6 日分後倒しする図の黄色い囲みにある AS30~BU36 までのセルを選択しそれをドラッグして右にずらすそうすると一日当たりの工数が 3 以下になる 82

83 83

84 84

85 実際のプロジェクト運用では工数の調整は複雑な要因に依存しあちらを立てればコチラが立たずになりがちだからこそガントチャートを作成する時点でできるだけタスク同士がかぶらないように設計することが大切 85

86 第 2 章演習問題解答例設問 1 (1) エ (2) イ設問 2 (1) ウ (2) イ (3) ア設問 3 開発工程の初期の段階で要求を完全に確定することは一般に困難であり, 要求が完全に確定しないまま先に進むことになり, 結果として後戻りの原因となる. テスト工程がプロジェクト後半に設定されているため, 上流工程に欠陥があってもそれがプロジェクトの終盤まで発見できないケースが多い. 設問 4 インクリメンタル型開発が, システムを機能やサブシステム, あるいはサービス単位に分割し, 分割単位ごとに設計とテストを繰り返し行うのに対して, イタラティブ型では, 前サイクルの成果を土台にして次サイクルを開発する形でシステム全体を繰り返し開発し, サイクルをまわす毎に完成度を高めていく. 設問 5 ユーザ要求や仕様の変更リスクを軽減するために, 顧客や開発者間のコミュニケーションを重視し, コーディングとテスト, コードの修正に重点を置いて, 短期間のリリースを繰り返して開発を進めていくソフトウェア開発方法論で, アジャイルプロセスモデルと総称される一連の手法のうちの代表的な1つである. テスト駆動開発やペアプログラミング等の技法がとられる. 86

第49章　プロジェクト管理のポイント

第49章　プロジェクト管理のポイントこの章の内容と目的第 3 章でソフトウェア危機について考えた時ソフトウェア危機の症状としてスケジュール遅れと開発費用の超過があることを見たそしてそのスケジュールの遅延は当初決めたスケジュールからの遅延であり費用の超過は当初決めた予算からの超過であることを確認したその意味でプロジェクトの立ち上がり段階で決めるスケジュールと予算はたいへんに重要であるもしここで適切なスケジュールと予算が決められたらスケジュール遅れも予算超過もなく