-
JIS Q 21500:2018(プロジェクトマネジメントの手引)によれば，プロジェクトマネジメントのプロセスのうち，計画のプロセス群に属するプロセスはどれか。
スコープの定義
-
プロジェクトを正式に許可する文書であるプロジェクト憲章を作成することを目的とするプロセスで、立上げのプロセス群に属しています。
"プロジェクト憲章の作成"
-
プロジェクトにおける作業を金銭の価値に置き換えて定量的に実績管理をする進捗管理手法です。
EVM(Earned Value Management)
-
プロジェクト開始当初、現時点までに計画されていた作業に対する予算
PV(Planned Value)
-
現時点までに完了した作業に割り当てられていた予算
EV(Earned Value)
-
現時点までに完了した作業に対して実際に投入した総コスト
AC(Actual Cost)
-
完了時の総コスト見積り
EAC(Estimate At Completion)
-
AC＋ETC=
完成時総コスト見積り(EAC)
-
(BAC－EV)÷CPI=
残作業のコスト見積り(ETC)
-
EV÷AC=
コスト効率指数(CPI)
-
縦軸に「残作業量」、横軸に「時間」を取り、実績をプロットしていくことで作業の消化具合を視覚的に把握できるようにした図
バーンダウンチャート
-
システムの要求分析時に行うインタビュー実施上の留意点として、はい"か"いいえ"で答えられる「コンテント質問」ではなく、情報提供者の情報を引き出す「プロセス質問」を用いることで事実・知識・経験を引き出すことが重要です。
正しい
-
PMBOKのプロジェクト統合マネジメントにおいて，プロジェクトスコープの拡張や縮小を行うのに必要なもの
変更要求
-
統合能力成熟度モデルと呼ばれ、組織におけるプロセス改善をガイドするモデル
CMMI(Capability Maturity Model Integration)
-
ソフトウェア開発組織及びプロジェクトのプロセスの成熟度を評価するためのモデルである。
CMMI(Capability Maturity Model Integration)
-
CMMIで、場当たり的で無秩序な組織として最も低い状態。
レベル1：初期
-
CMMIで、継続的な改善プロセスが常に機能している状態。
レベル5：最適化している
-
値の大きい順に分析対象の項目を並べた棒グラフと、累積構成比を表す折れ線グラフを組み合わせた複合グラフで、主に複数の分析対象の中から、重要である要素を識別するために使用します。
パレート図
-
矢印付き大枝の先端に特性を，中枝，小枝に要員を表した図であり，要因同士の因果関係を分析するために使用します。
特性要因図
-
工程の状態や品質を時系列に表した図であり，工程が安定した状態にあるかどうかを判断するために使用します。
管理図
-
トヨタ生産方式が生んだ「7つのムダ」の基本理念を発展させたリーン生産方式を、ソフトウェア開発に適用した手法
リーンソフトウェア開発,リーン(lean)は、痩せていて脂肪のないこと、無駄がなく引き締まっていることなどを意味します。
-
プログラム中心のアジャイル開発のフレームワークで4分類、19のプラクティスを適用します。
エクストリームプログラミング(XP)
-
アジャイル開発の方法論の1つで、開発プロジェクトを数週間程度の短期間ごとに区切り、その期間内に分析、設計、実装、テストの一連の活動を行い、一部分の機能を完成させるという作業を繰り返しながら、段階的に動作可能なシステムを作り上げるフレームワークです。
スクラム
-
ユーザにとって価値のある小さな機能のかたまり(フィーチャ)を単位として、実際に動作するソフトウェアを短期反復的に開発し、徐々に完成に近づけていくアジャイル開発のフレームワークです。5つのプロセス、8つのプラクティスが定義されています。
フィーチャ駆動型開発(FDD)
-
システム開発の早い段階で試作品を作成し，機能を確認しながら進める。
プロトタイプモデルの説明です。
-
部分的に定義された要求から開発を開始し，後続する幾つかの開発で要求を見直していく。
進化型のアプローチが採用されているスパイラルモデル
-
システムを幾つかのサブシステムに分割して，それぞれの開発を並行して進める。
インクリメンタルモデル
-
定義された要求を順序付けられた幾つかの開発部分に分割して，段階的に開発を行う。
ウォータフォールモデルの説明
-
開発規模，難易度及び開発の特性による要因を考慮し，工数やコストを見積もる手法である。
ソフトウェアの規模を入力値として工数を見積もるCOCOMO
-
開発するすべてのプログラム・モジュールの行数を算定し，それを基にシステムの開発規模や所要資源を見積もる手法である。
プログラムステップ法
-
システム開発の工数を細かい作業に分割し，分割された個々の作業を詳細に見積り，これを積み上げて，全体の開発規模や所要工数を見積もる手法である。
標準値法(標準タスク法)の説明
-
PMBOKでは、マイナスのリスク(脅威)への対応戦略の分類
「回避」「転嫁」「軽減」「受容」
-
PMBOKによれば，プロジェクトで実施する作業の相互関係を特定して文書化するのはどのプロセス？
アクティビティ順序設定で実施
-
プロジェクト全体を成果物を基準として階層的に分割していきますが、このとき最下層の成果物を作成する作業単位を「ワークパッケージ」といいます。
WBS
-
作業を階層的に要素分解してワークパッケージを定義する。
WBS作成で実施する作業
-
過去に蓄積したデータと関連する変数との統計上の関係を使って、見積りを行う手法です。試験でよく登場する"ファンクションポイント法"や"COCOMO"及び"プログラムステップ法"もパラメトリック見積りの一種
パラメトリック見積り(係数見積り)
-
関連する過去のデータとその他の変数との統計的関係を用いて，プロジェクトにおける作業のコストを見積もる。
パラメトリック見積り(係数見積り)
-
楽観値，悲観値，最可能値を使って，個々のアクティビティのコストを見積もる。
三点見積り
-
外部から見たときの振る舞いを変えずに、ソフトウェアの内部構造を変えること
リファクタリング(Refactoring)
-
ソフトウェア部品を組み合わせてシステムを開発する。
コンポーネント指向開発の説明です。
-
プログラムの修正が他の部分に影響していないかどうかをテストする。
レグレッションテスト(リグレッションテスト｜回帰テスト｜退行テスト)の説明です
-
アジャイル開発における反復の単位で、分析、設計、実装、テストの一連の活動を含みます。
イテレーション(Iteration)
-
ソフトウェアに存在する顧客の要求との不一致を短いサイクルで解消したり，要求の変化に柔軟に対応したりする。
アジャイル開発で"イテレーション"を行う目的のうち，適切なもの
-
タスクの実施状況を可視化して，いつでも確認できるようにする。
タスクボードの目的です。
-
ペアプログラミングのドライバとナビゲータを固定化させない。
ピンポンペアプログラミングの目的です。
-
毎日決めた時刻にチームメンバが集まって開発の状況を共有し，問題が拡大したり，状況が悪化したりするのを避ける。
日次スクラムの目的です。
-
プロジェクトのスコープを変更せずにコストを追加投入することでプロジェクト全体のスケジュールを短縮させる方法です。
クラッシング
-
ソフトウェア産業界においての"共通の物差し"となることを目的として作成された規格
共通フレーム
-
アメリカのプロジェクトマネジメント協会(PMI)が策定しているプロジェクト管理のフレームワークです。
PMBOK （Project Management Body of Knowledgeの略）
-
統合能力成熟度モデルと呼ばれ、組織におけるプロセス改善をガイドするモデルです。
CMMI （Capability Maturity Model Integration）
-
PMBOKガイド第6版によれば，脅威と好機の，どちらに対しても採用されるリスク対応戦略
受容
-
開発対象のシステムやソフトウェアで実現されるべき要求機能や要素をまとめたものです。
バックログ
-
チームが1回のイテレーションで完了させたユーザストーリのストーリポイントの合計値、すなわち開発生産性を表します。ざっくり言えば、1スプリントにおける開発量のことです。
ベロシティ
-
各種ソフトウェア設計・開発技法を使って開発作業を自動化し，ソフトウェア開発の生産性を向上を図る。
CASE(Computer Aided Software Engineering)ツールの目的
-
ソフトウェアライフサイクルを，主，支援及び組織に関する三つのライフサイクルプロセスに分けてアクティビティを定め，ソフトウェアプロセスの標準化を図る。
共通フレームの目的
-
EVMを活用したパフォーマンス管理をしている。開発途中のある時点でEV－PVの値が負であるとき，どのような状況を示しているか。
プロジェクトの進捗が，計画より遅れている。
-
アクティビティに追加資源を投入して、所要期間を短縮することでスケジュールの短縮を図る方法
クラッシング
-
開始当初の計画では直列に並んでいた作業を同時並行的に行ったり、作業の前後を入れ替えたりすることで期間短縮を図る方法
ファストトラッキング
-
ソフトウェアの再利用の説明のうち，適切なもの
再利用可能な部品の開発は，同一規模の通常のソフトウェアを開発する場合よりも工数がかかる。
-
第三者がプロジェクトの成果物をレビューすることによって，設計の不具合の有無を確認する。
デザイン・レビューの目的
-
プロジェクトのパフォーマンスや進捗状況を評価して，プロジェクトの継続や中止を判断する。
フェーズ・ゲートの目的
-
スクラムチーム全体が自律的に協働できるように、場作りをするファシリテーター的な役割を担う
スクラムマスタ
-
スクラムの理論とプラクティスを全員が理解するように支援する。
スクラムマスタの行うことです。
-
各スプリントの終わりにプロダクトインクリメントのリリースの可否を判断する。
開発者の行うこと
-
プロダクトバックログアイテムを明確に表現する。
プロダクトオーナ
-
プロダクトバックログの優先順位を決定する。
プロダクトオーナ
-
ソフトウェアがどのような構成品目の組み合わせで構成されているかという構成識別体系を管理台帳や管理用のソフトウェアに記録して管理することをいいます。
ソフトウェア開発における構成管理
-
