情報処理技術者試験対策「アーンドバリューマネジメント」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
コストマネジメントの手法として、アーンドバリューマネジメントと呼ばれる手法があります。
実際にかかったコストや実際の成果物の量を計画値と照らし合わせることでコスト管理をする手法であり、応用情報や高度情報(PM)では頻出です。PMPの試験でも出題されます。
実務でもPMがよく使っています。
PGやSEの内はあまり馴染みがないと思いますが、PMを目指すなら避けては通れないですし、基本情報でも出る可能性はあるので、これを機に覚えた方が良いでしょう。
　
アーンドバリューマネジメントでは、管理対象の工程についてまずPV(計画価値、Planned Value)を定めます。
PVは「計画工数(人日)×1人日当たりの費用」で求まります。
また、縦軸にコスト、横軸にスケジュールをとると、PVは下記のようにS字を描きます。

（工程開始時は前準備のため工数を割けない、準備が整い次第工数を割いて進捗、工程完了間際は一部の残作業の消化となるため再び工数を減らす）

次に、実際にかかった費用をAC(実コスト、Actual Cost)として計測します。
ACは「実際の工数(人日)×1人日当たりの費用」で求まります。
ACがPVよりも高ければ予定よりもコストがかかっているということになり、逆に低ければ予定よりもコストが少なく済んでいるということを指します。

そして、実際に生産された成果物の価値をEV(アーンドバリュー(直訳すると取得価値)、Earned Value)として計測します。
EVを計測する方法としては重み付けマイルストーン法や固定法等がありますが、情報処理技術者試験では金額という形で前提条件として提示されます（今のところは）。
EVがPVよりも高ければ予定よりも多くの成果物を生産できていることになり、逆に低ければ予定よりも成果物を生産できていないということを指します。

PV、AC、EVの3つの指標を見ることで、進捗状況を把握することができます。
例えば、ACがPVよりも高く、EVがPVよりも低い場合、多くのコストをかけても予定通りに成果物を生産できていないことを指していますので、進捗しない原因を調べて除去する、計画が楽観的すぎでないか見直す、等の対応が必要になります。
　
以下は、PV、AC、EVの3つの指標から算出できる指標です。
これも出題されることがあります（計算式も覚える必要があります）。

• CV(コスト差異、Cost Variance)
  コストが予算内に収まっているかを計測（CV≧0なら予算内）。
  成果物(EV)を生み出すのに必要以上にコスト(AC)がかかっていないかを計測すれば良いので、
  CV = EV - AC
• SV(スケジュール差異、Schedule Variance)
  計画通りに成果物を生産できているかを計測（SV≧0なら計画通りかそれ以上）。
  成果物(EV)が予定(PV)よりも早く出来上がっているかを計測すれば良いので、
  SV = EV - PV
• CPI(コスト効率指数、Cost Performance Index)
  1単位のコストに対する成果物の生産量を示す割合（CPI≧1なら予定以上の効率）。
  CVを指標(比率)として算出したものである。
  CPI = EV / AC
• SPI(スケジュール効率指数、Schedule Performance Index)
  1単位の期間に対する成果物の生産量を示す割合（SPI≧1なら予定以上の効率）。
  SVを指標(比率)として算出したものである。
  SPI = EV / PV
• BAC(開始時プロジェクト予算、Budget At Completion)
  プロジェクト全体の予算。
  各工程のPVの合計。
• ETC(残作業のコスト見積り、Estimate To Completinon)
  残作業で発生するコストの見積もり。
  残作業は、プロジェクト開始時で生産予定の成果物-今まで生み出した成果物である。
  ここで、コストに対する生産量を把握できれば、残作業がどの程度のコストをかければ完了するのかを把握することができる。
  よって下記式となる。
  ETC = (BAC - EV) / CPI
• EAC(完成時総コスト見積り、Estimate At Completion)
  プロジェクト完了時の実際のコストの見積もり。
  過去の作業の実コストはAC、未来の作業のコスト見積もりはETCで求まるため、下記式となる。
  EAC = AC + ETC

なお、今回は具体的な金額の例を出しませんでしたが、これについては過去問が良い例になりますので、実際に過去問で計算して確かめてみましょう。

情報処理技術者試験対策「クリティカルパス」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
今回は、プロジェクトマネジメントのプロジェクト・タイム・マネジメントについて、クリティカルパスの話をしたいと思います。
　
システムを開発する上では、色々な作業を並行して進めます。
並行して進める作業の内、多少の遅れであれば全体のスケジュールの遅延に繋がらない作業と、少しでも遅れれば全体のスケジュールの遅延に繋がる作業が存在します。
クリティカルパスとは、後者の作業のことを指します。
　
例えば、「言い訳機能」と「反省機能」で成り立つ遅刻対応システムを以下の条件下で開発しているとします。

• 製造・単体テスト工程は5日間の予定
• 言い訳機能の製造・単体テストに5人日を要する予定
  (1人の人が5日間作業すれば終わる作業量、の意)
• 反省機能の製造・単体テストに3人日を要する予定
• 言い訳機能に1人を割り振る予定
  (→5日間かかる)
• 反省機能に1人を割り振る予定
  (→3日間かかる)

この場合、反省機能であれば2日間遅れても製造・単体テスト工程の遅延には繋がりません。
しかし、言い訳機能は少しでも遅れれば製造・単体テスト工程全体の遅延に繋がります。つまりクリティカルパスです。
　
クリティカルパス上の作業については原則として遅延が許されないため、人を増やす（言い訳機能に2人を割り振れば計算上は2.5日間で終わる）、計画時にあらかじめバッファを持たせる（製造・単体テスト工程を7日間で計画すれば、2日間の余裕を持たせられる）、クリティカルパス上に高スキルの人員を割り振る、等の方法でスケジュール遅延のリスクに対応します。
スケジュールをコントロールする上では、このようにクリティカルパスに注目し重点的に対策を取ることが重要になります。

情報処理技術者試験対策「クラウドコンピューティング」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
志向を変えて、システム戦略について書こうと思います。
今回はクラウドコンピューティングについて書きます。
クラウドコンピューティングは今流行りのサービス形態の一つであり、ここ２～３年で情報処理技術者試験でもSaaS・PaaS・IaaSの定義を知らないと解けない突っ込んだ問題が出題されるようになりました。
　
クラウドコンピューティングとは、サービス事業者が管理するシステムにインターネットを介して接続することで、目的のサービスを受けるというものです。
月額必要を支払うことで、自社でシステム資源を用意し管理する必要がなくなるというメリットがあります。
可用性等のシステム要件はサービス提供事業者毎に異なり、SLAにより合意します。
世界的に有名なサービスとしては、Amazon Web Services(AWS)、Google Cloud Platform(GCP)、Microsoft Azure等が挙げられます。
最近では、実務でもこれらのサービスの名前を耳にすることが多くなってきたかと思います。
　
クラウドコンピューティングのサービス形態は、大きく分けると以下の３つがあります。
（先頭の一文字が何の略かを覚えれば覚えやすいです）

• SaaS(Software as a Service)
  サービス提供事業者はアプリケーション・ミドルウェア・OS・ハードウェアを提供・管理する。
  利用者はクラウド上のアプリケーションを使用する。
  利用者が管理するものはない。
  利用者はアプリケーションにおける設定可能範囲内でカスタマイズが可能。
• PaaS(Platform as a Service)
  サービス提供事業者はミドルウェア・OS・ハードウェアを提供・管理する。
  利用者は、クラウド上で用意されたプログラミング言語・ライブラリ・サービス・ツールを使用し、アプリケーションを実装する。
  利用者はアプリケーションを管理する。
  利用者はミドルウェアにおける設定可能範囲内でカスタマイズが可能。
• IaaS(Infrastructure as a Service)
  サービス提供事業者はOS・ハードウェア、若しくはハードウェアのみを提供・管理する。
  利用者は、クラウド上で用意されたインフラ資源を利用し、システムを構築する。
  利用者はアプリケーション・ミドルウェアを自前で用意・管理し、OSがサービス提供事業者から提供されない場合はOSも用意・管理する。
  利用者はアプリケーション・ミドルウェア・OSに関するコントロール権を持ち、場合によりネットワーク設定も認められた範囲で変更できる。

　
なお、クラウドコンピューティングは、仮想化技術によって支えられています。
仮想化技術とは、１台の物理サーバを複数台の仮想的なサーバに分割し、それぞれに別のOSやアプリケーションソフトを動作させる技術のことです。
１台の物理サーバで複数の仮想サーバをコントロールできるため管理が容易になりますが、１台のサーバに処理が集中し競合も起きるため、サーバの利用率やCPUのオーバヘッドは上昇します。
仮想化を実現する製品は、VMWareがデファクトスタンダードとなっています。
仮想化技術も時折出題されるキーワードですし、実務でも関わる可能性が高まっているので、ついでに覚えておくと良いでしょう。

情報処理技術者試験対策「アジャイル開発」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
プロセスモデルの一つとして、「アジャイル開発」というものがあります。
ウォーターフォールモデルと比較すると新しいモデルであり、最近になって情報処理技術者試験でも出題されるようになりました。
　
アジャイル開発はその名の通り迅速に開発を行うもので、短い期間（数週間～1ヶ月程度）毎にユーザにとって重要な機能から順番にリリースを行います。
一つの期間はイテレーションと呼ばれ、計画・設計・実装・テストがこの期間の間に行われます。
このように開発を行うことで、ユーザは少ない期間・コストで重要な機能を使用することができるようになります。ユーザの要求の変更にもいち早く対応することができます。また、システムを実際に使うと新たな要望が浮かぶものなのですが、システムを早い段階で手に取ることができるので新たな要望を早く出すことができます。仮に、せっかくリリースした機能がユーザに響くものでなかったとしても、その問題に少ない期間・コストで気付き、軌道修正することができます。
これらの利点により、重厚長大なウォーターフォールモデルを採用した場合に比べて、ビジネス上で優位に立つことができるようになります。
（特にスタートアップ企業にとってはこれらの利点が重要）
　
しかし、アジャイル開発はユーザの要望が頻繁に変わる小規模システムの開発には向くものの、要望が固定されているミッションクリティカルな大規模システムの開発には向かないとされています。
アジャイル開発ではシステムを小出しで開発するので、システム全体の整合性や最終製品の品質を上手く管理しないと、システムの品質が低下する問題やシステムのスケーラビリティが損なわれる問題が発生してしまいます。
そのため、教科書的には、要望が固定されているミッションクリティカルな大規模システムの開発はウォーターフォールモデルの方が向いているとされています。
　
ところで、迅速に開発しろと言われても、そのための手法がなければただのカオスとなってしまいます。
アジャイル開発を実現するための手法、またアジャイル開発と親和性の高い考え方としては、以下のようなものがあります。
（試験で出そうな順に並べています。スクラム以降はまだ試験では出ていません（多分）。）

• アジャイルソフトウェア開発宣言
  http://agilemanifesto.org/iso/ja/manifesto.html
• エクストリームプログラミング(XP)
  迅速にプログラミングを行うための手法。リファクタリング（保守性を高めるためのコード見直し）、ペアプログラミング（一人がコーディング、もう一人がリアルタイムにコーディングを見ることで、即座にレビュー・知識共有を行う）、テスト駆動開発（テストケース・テストコードを先に設定してからプログラミングを行う）により実現する。
• プロトタイピング
  ユーザからのフィードバックを早期に得るために試作品を作成して提供する。試作品はコーディングして作成するとは限らず、紙芝居のような形でコンセプトを伝えるペーパープロトタイピングと呼ばれる手法もある。
• スクラム
  チーム一体となってプロジェクトを遂行して行くことに重点を置くプロセスモデル。デイリースクラム（始業時に今日の予定と問題点を共有する）、プロダクトバックログ（システムの要求一覧）、スプリントバックログ（イテレーション内で対応する要求一覧）、イテレーション、スプリントレビュー（イテレーション内で開発した機能のユーザとのレビュー）、ふりかえり（イテレーション終了時の改善点の共有）により実現する。
• バーンダウンチャート
  縦軸に「作業量」、横軸に「時間」を割り当て、残りの作業量を折れ線グラフにより記述したチャート。ガントチャート等と比べて、プロジェクトの進捗状況をいち早く把握することができる。紙媒体で誰もが見える場所に張り出すと効果が高い。
• リーン生産方式
  トヨタ生産方式を元に編み出された方式。開発工程におけるムダを排除することを目的として、製品および開発工程の全体にわたって、トータルコストを系統的に減らそうとするのが狙い。「ムダをなくせ（顧客に価値を与えない作業を無くす）」「学習を強化せよ（反復型開発）」「決断を遅らせよ（状況の変化に合わせた決断）」「できる限り早く出荷せよ（機会損失防止）」「チームに権限を（チームの手で最良のプロセスを採用）」「摺り合わせて作り込め（ユーザとのトライ＆エラーの繰り返し）」「全体を見よ（全体最適化）」という７つの原則によって成り立っている。
• チケット駆動開発
  スプリントバックログを約２～３時間のタスクである「チケット」に分割し、チケットを管理することで、メンバーの作業把握と成果物の更新理由の把握を容易にする。
• ストーリーポイント
  案件の規模や複雑性を「ストーリーポイント」と呼ばれる直感的・相対的な基準で測ることにより、俯瞰的な視点で直感的に迅速に見積もりを行う。

日本ではアジャイル開発はあまり普及しておらず、アジャイル開発を採用しているプロジェクトには巡り合えないかもしれませんが、それでも顧客の要望に沿ったシステム開発を行う必要があることには変わりないので、アジャイル開発の手法や考え方は部分的にでも取り入れる必要があるかと思います。
　
なお、情報処理技術者試験では、「スパイラルモデル（要求分析から実装までの開発プロセスを繰り返し、システムを構築するプロセスモデル）」、「ラウンドトリップ（オブジェクト志向開発において、設計とプログラミングを何度か行き来し、トライ＆エラーで改良する手法）」についても出題されたことがあります。
アジャイル開発に通じる所もあるので、ついでに覚えると良いでしょう。

-------------------------------
　
2019/02/12 追記
　
偶然、IPAが発行している初心者向けガイドを見つけました。
200ページ超で、内容も書籍と同じくらい濃いです。
これが無料で読めるのは凄いことなので、興味がある方は是非。
　
アジャイル型開発におけるプラクティス活用事例調査 調査報告書 ～ガイド編～

https://www.ipa.go.jp/files/000026849.pdf

情報処理技術者試験対策「ウォーターフォールモデルとＶ字モデル」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
次はソフトウェア開発のプロセスモデルについて書きます。
様々なプロセスが存在しますが、今回は最もメジャーなウォーターフォールモデルについて書きます。
日本でシステム開発をする場合、大部分のプロジェクトでウォーターフォールモデルが採用されており、試験だけでなく実務でも超メジャーな分野です。
　
ウォーターフォールモデルでは、実際にプログラムを作るまでは「要件定義（基本計画）」→「外部設計（基本設計）」→「内部設計・プログラム設計（詳細設計）」→「プログラミング（製造）」といった工程を踏みます。
ユーザの要求からスタートし、段階的に詳細化しシステム化の方針を決めるといった形で、トップダウンで開発を行います。
プログラムを作り終えてからは、「単体テスト(UT)」→「結合テスト(IT)」→「システムテスト(総合テスト、ST)」→「運用テスト(UAT)」といった工程を踏みます。
バグ頻発でテスト進行が妨げられることを防ぐために、細かい箇所からテストを行い徐々に統合するという形で、ボトムアップで開発を行います。
　
開発工程とテスト工程は、以下のように連関しています。
プログラミングの内容は単体テスト、内部設計・プログラム設計の内容は結合テスト、外部設計の内容はシステムテスト、要件定義の内容は運用テストで検証します。
これをＶ字モデルと呼びます。

 

誤りを修正する場合、後の工程になるほど手戻り工数が増え、修正コストが増大します。
（最悪なのは、リリース後に誤りが発見され、修正の必要が生じた場合です）
教科書的には、レビューを強化する等し、ある工程で埋め込んだ誤りはその工程の中でできる限り解消することが重要になります。
仮に後の工程で誤りが発見された場合は、その誤りについてなるべく早い段階で例外的に前工程に戻り、その誤りの修正に関わる要件・設計・実装を見直すことが重要になります。
大規模かつミッションクリティカルなシステム開発では特にこの原則を守ることが重要となります。
以下は東証のシステム更改の例で、前工程への手戻りを正式にプロセスに組み込むことで手戻り工数を削減する「フィードバック型Ｖ字モデル」が採用されました。

http://ac.nikkeibp.co.jp/cn/xdev10/pdf/10907-xdev-A-1.pdf

 　
なお、実務では、実現性が疑わしい箇所について開発開始前にプロトタイプを作成し、実現性をあらかじめ検証するという手法も使われます。
プロトタイプを作ることで、開発開始時に実現性の問題が出て手戻りが発生することを防ぐことができます。
　
ざっくりまとめると、先が見える場合は１つ１つの作業を確実にこなす、先が見えない場合は先回りして視界を良好にする、という姿勢がプロジェクトを進行する上で重要になります。

情報処理技術者試験対策「システムテストや同時期に実施するテスト」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
テストについては一通り書こうと思います。
今回は、システムテストについてです。
あまり面白いことは書けませんが…。
　
システムテストは結合テストの後に開発部隊が行うテストであり、システムが要件を満たしていることを確認するためのテストです。
以下の２つの要件を満たしていることを確認します。
（なお、バグの原因切り分けを容易にするため、モジュール単独で検証できることは前工程で行う必要があります。例えば、性能テストに関して、SQL単独の性能計測は単体テストの範囲です。）

• 機能要件
  システムが提供する機能に関する要件。
  ユーザインターフェースやその裏側の業務処理等。
  実運用を想定し、シナリオテストや実時刻テストを行うことにより検証する。
  　
• 非機能要件
  機能要件を実現するための土台として必要になる要件。
  性能テスト、負荷テスト、セキュリティテスト等により検証する。

また、本番環境でのテストもシステムテストで行う必要があります。
テスト環境と本番環境で環境差異（関連モジュールやライブラリのバージョン差異、ネットワーク構成の差異等）がある可能性があり、それがシステムの機能に影響を及ぼす可能性があるためです。
サービス提供時間にテストを行うことはできないため、サービス提供時間外にテストを行うことになります。
場合によっては、テストのために例外的にサービス停止することも検討します。
　
ついでに説明しますが、ユーザ部門による運用テストも同フェーズで実施します。
運用テストでは、開発されたシステムで実運用できるかを検証します。
また、保守開発（本番サービス中のシステムに対する改修）の場合は、リグレッションテスト（退行テスト）も実施します。
リグレッションテストは改修した箇所が他の箇所（現行サービスで問題なく提供できている機能）に影響を及ぼしていないかを確認するためのテストで、同一のインプットで同一のアウトプットが出ることを確認します（現新比較）。

情報処理技術者試験対策「結合テストの進め方（スタブ・ドライバ）」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM
-------------------------------
せっかく単体テストについて書いたので、次は結合テストについて書きます。
主にスタブとドライバについて書きます。
　
結合テストは、モジュール間の整合性を検証するために行います。
モジュール間でインターフェースの実装に相違がないか、業務データの取り扱いに相違がないか、といった所を中心に見ることになります。
モジュール単独の品質が担保されていないと、バグ発生時に原因の切り分けが困難になったり、結合テストで本来検証するべきこと（モジュール間の整合性確認）が検証できなくなったりして工数がかさみますので、単体テストでモジュール単独の品質を担保することが前提になります。
　
連携するモジュールが未完成（単体テストで品質を担保する所まで行っていない）場合は、仮のモジュールであるスタブやドライバを使って当面の間はテストを継続することになります。

• スタブ
  下位モジュール（呼び出される側）の代わりとなるモジュール。値を返却するだけ等の形で簡単に実装する。
• ドライバ
  上位モジュール（呼び出す側）の代わりとなるモジュール。処理を呼び出して返却値を表示するだけ等の形で簡単に実装する。

スタブやドライバを作成すれば、連携するモジュールが未完成でも、完成したモジュールから先に結合テストを進めることができます。
スタブやドライバの実装が単純であればスタブやドライバにバグが潜んでいる可能性も低くなるので、バグ発生時にはテスト対象のモジュールに問題があると推測することができ、原因切り分けが容易になります。
　
教科書的には、スタブはトップダウンテスト、ドライバはボトムアップテストで用いられ、トップダウンテストは原因切り分けが容易だが並行してテストを進められない、ボトムアップテストはその逆とされています。
が、実務の上でこのことを意識したことはありません。
（ボトムアップテストでもトップダウンテストでも、状況に応じてまとめてテストしたり１つ１つ着実にテストしたりするので）