記事ディレクトリ
ガント図とパート図
- ガント チャートは、各タスクの開始/終了時間と各タスク間の並列性を明確に記述することができ、プロジェクトの開発進捗を動的に反映することもできますが、複数のタスク間の論理的な関係を反映することは難しく、PERT ではプロジェクトを使用します。ネットワーク ダイアグラムと各アクティビティに必要な推定時間 (加重平均によって得られる) を使用して、プロジェクトの合計時間を計算します。これは、タスク間の順序関係を強調しますが、タスク間の並列性とプロジェクトの現在の進行状況を反映することはできません。 .
- ガント チャートは、カレンダーに関連するプロジェクト タスクを表す単純な横棒グラフです。横軸はカレンダーのタイムライン (時間、日、週、月、年など) を表し、各バーはタスクを表し、左の列にはタスク名が縦にリストされ、タスクの開始点と終了点が表示されます。図の横棒は横軸に対応しています。棒の時間はタスクの開始時刻と終了時刻を表し、横棒の長さはタスクの期間を表します。カレンダーで同じ期間に複数の横棒が存在する場合は、タスク間の同時実行を示します。下の図に示すガント ダイアグラムは、3 つのタスクのスケジュールを記述したものです。タスク 1 は最初に開始され、完了するまでに 6 か月かかります。タスク 2 は、1 か月後に開始され、完了するまでに 9 か月かかります。タスク 3 は、6 か月後に開始され、完了するまでに 5 か月かかります。
- PERT グラフは有向グラフであり、グラフ内の矢印はタスクを表し、タスクを完了するのに必要な時間をマークできます。グラフ中のノードは、ノードに流入するタスクの終了と、ノードから流出するタスクの開始を表し、ここではノードをイベントと呼びます。ノードに流入するすべてのタスクが終了した場合にのみ、ノードによって表されるイベントが発生し、ノードから流出するタスクを開始できます。イベント自体は時間とリソースを消費しません。特定の時点を表すだけです。イベントには、イベント番号と、イベントが発生した最も早い時刻と最も遅い時刻があります。最も早い時間は、このイベントから開始するタスクをこの時間より前に開始できないことを意味します。最も遅い時間は、このイベントから開始するタスクをこの時点より前に開始する必要があることを意味します。そうしないと、プロジェクト全体をスケジュールどおりに完了できません。各タスクにはスラック タイム (スラック タイム) もあり、これは全体の期間に影響を与えずにタスクを完了するためにどれだけの余裕があるかを示します。タスク間の関係を表すために、いくつかの空のタスク (点線の矢印で示される) を図に追加することもできます。空のタスクを完了する時間は 0 です。
-
クリティカル パス法とは、グラフのソース ポイントからシンク ポイントまでの最長のパスであり、クリティカル パスの時間をプロジェクト期間と呼び、プロジェクトの完了に必要な最小時間としても表されます。
クリティカル パスの詳細については、 -
合計時間差: 合計時間を遅らせないこのアクティビティの操作時間。一般的には、図中の最遅終了時刻から最早終了時刻を引いたもの、または最遅開始時刻から最早開始時刻を引いたものである。
-
ネットワーク ダイアグラムには、スケジュール モデルを使用する際に使用されるスケジュール ネットワーク分析手法であるクリティカル パス分析法が一般的に使用されます。プロジェクト スケジュールのネットワーク ルートに沿って順方向および逆方向の分析を実行し、リソースの制約に関係なく、計画されたすべての活動の理論上の最早開始日と最遅開始日と最遅開始日を計算します。
-
シングルコード ネットワーク ダイアグラム: ノードはアクティビティを表し、矢印はアクティビティ間の依存関係を表します。
-
ダブルコード化されたネットワーク ダイアグラム: ノードはマイルストーンを表し、矢印はアクティビティを表します。
危機管理
- リスクの特徴: 不確実性と損失の可能性。
- リスクの種類: プロジェクト リスクには、プロジェクトの損失につながる可能性のある、さまざまな形の予算、スケジュール、人員、リソース、および顧客関連の問題が含まれます。技術的リスクには、プロジェクトの損失につながる可能性のある技術関連の問題が含まれます。ビジネスリスクは市場要因に関連しています。社会的リスクには、ポリシー、規制、およびその他の要因が含まれます。
- リスク エクスポージャーは、リスク エクスポージャーとも呼ばれ、資産の全体的なセキュリティ リスクを測定し、実際の損失の可能性を表す情報と、起こり得る損失の相当額を表す情報を 1 つの数値評価に組み合わせます。定量的リスク分析の最も単純な形式では、リスクの可能性と影響を掛け合わせてリスク エクスポージャを計算します。
リスクエクスポージャー（Risk Exposure）＝エラー発生率（リスク発生率）×エラーによる損失（リスク損失）。
構成管理
ソフトウェア構成管理は、ソフトウェア エンジニアリング プロセス全体で使用されます。その主な目標は、変更を識別し、変更を制御し、変更が正しく実装されるようにすることです。
(2) ソフトウェアプロジェクト実施計画
(3) ソフトウェア要件仕様
(4) 設計仕様（データ設計、アーキテクチャ設計、モジュール設計、インターフェース設計、オブジェクト記述（オブジェクト指向技術を使用する場合））
(5)ソースコード一覧
(6) テスト計画と手順、テストケースとテスト結果記録
(7) 操作とインストールマニュアル
(8) 実行プログラム (実行プログラムモジュール、接続モジュール)
(9) データベース記述 (モードとドキュメント結果、初期コンテンツ) )
(10) ユーザーマニュアル
(11) 保守資料 (ソフトウェア問題レポート、保守要求、技術変更シーケンス)
(12) ソフトウェア技術標準
(13) プロジェクト開発の概要
(1) 開発ライブラリ
(2) 管理ライブラリ
(3) 製品ライブラリ
コミュニケーション管理
- メイン プログラマーがいます: n メンバー グループ、1 つのメイン プログラマー、通常のプログラマーはメイン プログラマーと通信するだけで済みます。
通信経路: n-1. - オーナーレス プログラマー: n 人のメンバーからなるプロジェクト チームは、互いに通信できます。
通信経路: n(n - 1) / 2.
トピックの例
次の図は、ソフトウェア プロジェクトのアクティビティ図です。頂点はプロジェクトのマイルストーンを表し、頂点を結ぶエッジはアクティビティを表し、エッジの重みはアクティビティを完了するのに必要な時間 (日数) を表し、次にアクティビティ ( ) を表します。クリティカル パス上にありません。活動 BI と EG の緩和時間はそれぞれ ( ) です。
質問1
- A.BD
- B.BI
- C.GH
- D.KL
質問2
- A. 0 と 1
- B. 1 と 0
- C.0と2
- D. 2 と 0
[試験問題の分析]: キーパスは ABDIJKL と AEGHKL の 2 つで、長さは 20 です。
最初の質問では、クリティカル パス上にないアクティビティは BI であり、残りの BD、GH、および KL はすべてクリティカル パス上にあります。
2番目の質問では、BIとEGの緩和時間が求められます.アクティビティBが通過するパスはABUKLとABIJLの2つあり、両方のパスの長さは19です.(2つの異なるパスがある場合は、最大のものを選択します.) 、クリティカル パス 20-19=1 からパスの長さを引きます。これは、アクティビティの緩和時間を意味します。
アクティビティ EG はクリティカル パス AEGHKL にあり、それを遅らせる方法はありません。つまり、ルーズ タイムは 0 です。
リスク管理では、通常、( ) 以外の目的でリスク監視が必要です。
- A. リスクを排除する
- B. 予測されたリスクが発生したかどうかを評価する
- C. リスク軽減の手順が適切に実施されていることを確認する
- D. 後続のリスク分析のために情報を収集する
[試験問題の説明]: リスク監視とは、主に、リスクを防止するために関連する情報を予測、評価、および収集し、関連する予防措置を講じることです。
リスク監視の目的は、予測されたリスクが発生したかどうかを評価し、リスク軽減手順が正しく実施されていることを確認し、その後のリスク分析のために情報を収集することです. リスクを排除するオプション A については、リスクを排除することはできません.可能な限り避けるしかありません. .
リスクに関する次の記述のうち、間違っているものはどれですか ( )。
- A. リスクはイベントの可能性です
- B. リスクを予測できれば回避できる
- C. リスクとは、損失をもたらす可能性がある事象です
- D. 損失を減らすためにリスクに介入する
【試験問題の解説】：リスクとは、損失が発生する可能性のある事象であり、リスクを予測した上で介入して損失を軽減することはできますが、回避することはできません。オプション B の説明が間違っています。
ソフトウェア事業費見積モデル COCOMO II では、( ) に基づいてアーキテクチャ段階モデルを見積もっています。
- A. 応募ポイント数
- B. 機能点数
- C. 再利用または生成されたコードの行数
- D. ソースコードの行数
[試験問題の分析]: この問題では、プロジェクトのコスト見積もりモデルを調べます。
COCOMO II モデルもサイズ推定情報を使用する必要があり、モデル階層には、オブジェクト ポイント、関数ポイント、およびコード行という 3 つの異なるサイズ推定オプションがあります。アプリケーション アセンブリ モデルはオブジェクト ポイントを使用し、初期設計段階のモデルはコード行に変換できるファンクション ポイントを使用し、アーキテクチャ モデルはコード行を使用します。
したがって、正解は選択肢Dです。
ソフトウェアのリスクに関する次の記述のうち、間違っているのは () です。
- A. リスクはイベントの可能性です
- B. リスクが発生した場合、リスクの性質、程度、タイミングがリスクの結果に影響を与える可能性がある
- C. リスクが予測可能であれば、回避できる
- D. リスクはコントロールできる
【試験問題分析】：ソフトウェアのリスクには、一般的に不確実性と損失の2つの特徴があると考えられており、不確実性とは、リスクが発生する可能性と発生しない可能性を意味し、選択肢Aが正しいことを意味します。
リスクの影響を評価する. リスクが発生した場合、リスクの結果に影響を与える可能性のある 3 つの要因、つまりリスクの性質、範囲、時間があります. オプション B が正解です. リスクが予測できれば、その発生を回避できる 予測できても回避できないリスクがある 選択肢 C は誤りです。
リスク管理の目的は、プロジェクト チームがリスクに対処するための戦略を確立するのを支援することです。オプション D が正しいです。
プロジェクトの活動期間とその依存関係を下の表に示します。プロジェクトを完了するための最短時間は ( ) 日です。
- A.43
- B.45
- C.50
- D.55
【試験問題の分析】：
ワークロード見積もりモデル COCOMO II の階層構造では、見積もりオプションに () が含まれていません。
- A.物点
- B. 機能点
- C. ユースケースのポイント
- D. ソースコード行
[テスト問題の説明]: COCOMO II モデルもスケール推定情報を使用する必要があります.モデル階層には、オブジェクト ポイント、関数ポイント、およびコード行の 3 つの異なるスケール推定オプションがあります。
構成管理は、ソフトウェア開発の全プロセスを通じて実行されます。以下のうち、構成管理に属さないものは()です。
- A) バージョン管理
- B. リスク管理
- C. 変更管理
- D. 構成ステータス レポート
[試験問題の分析]: 構成管理には、ACD と構成監査が含まれます。
コストを見積もるとき、() メソッドはコストの主な要因として規模を取り、複数のコスト ドライバーを考慮します。この方法には、アプリケーション アセンブリ モデル、初期設計フェーズ モデル、およびアーキテクチャ フェーズ モデルという 3 つのフェーズ モデルが含まれます。
- A.専門家の見積もり
- B.ウォルバートン
- C.ココモ
- D.ココナッツⅡ
[試験問題の分析]: ソフトウェアのコスト見積もりに一般的に使用されるモデルには、Putnam モデル、Function Point モデル、COCOMO モデル、およびその後の COCOMO Ⅱ モデルがあります。その中で、COCOMO Ⅱモデルが最も広く使用されています。これは、COCOMO モデルを改良したもので、コストを主な要因とし、複数のコスト駆動要因を考慮しています。したがって、この質問ではオプションDのCOCOMOⅡモデルを選択します。
ソフトウェア構成管理の内容には ( ) は含まれません。
- A) バージョン管理
- B. 変更管理
- C. プロセスのサポート
- d.品質管理
【出題分析】：ソフトウェア構成管理の基礎知識を問う問題です。
ソフトウェア構成管理 (SCM) はソフトウェア エンジニアリング プロセス全体で使用され、その主な目標は、変更の特定、変更の制御、変更の正しい実装の確認、および変更の報告です。その主な内容は、バージョン管理、構成サポート、変更サポート、プロセス サポート、チーム サポート、変更レポートおよび監査サポートなどです。
リスクは通常、( ) に従って優先順位が付けられます。
- A. リスクの影響
- B. リスク確率
- C. リスクエクスポージャー
- D.リスクコントロール（リスクコントロール）
[試験問題の説明]: リスク エクスポージャーとも呼ばれるリスク エクスポージャーは、資産の全体的なセキュリティ リスクを測定するもので、実際に損失が発生する可能性と、大きな星が失われる可能性を示す情報を 1 つの数値評価に組み合わせます。定量的リスク分析の最も単純な形式では、リスクの可能性と影響を掛け合わせてリスク エクスポージャを計算します。
リスクエクスポージャー（Risk Exposure）＝エラー発生率（Risk Occcurrence Rate）×エラー発生損失（Risk Loss）。
プロジェクトの複雑さ、規模、および構造の不確実性は ( ) リスクです。
- A. プロジェクト
- b. 技術
- c.経済
- D.事業
【試験問題解説】: プロジェクトリスクは、予算、スケジュール、人員、リソース、顧客など、さまざまな形で問題が発生し、プロジェクトの損失につながる可能性があります。
以下の進捗管理ツールのガントチャートの説明で、間違っているのは()です。
- A. 各タスクの開始時刻、終了時刻、期間を明確に説明できる
- B. タスク間の並列関係を明確に表現できる
- C. タスク間の依存関係を明確に判断できない
- D. 進捗に影響する重要なタスクを明確に特定できる
【試験問題の分析】：ガントチャートは、カレンダーに基づいてプロジェクトのタスクを記述したシンプルな横棒グラフです。横軸はカレンダーのタイムライン (時間、日、週、月、年など) を表し、各バーはタスクを表し、左の列にはタスク名が縦にリストされ、タスクの開始点と終了点が表示されます。図の横棒は横軸に対応しています。棒の時間はタスクの開始時刻と終了時刻を表し、横棒の長さはタスクの期間を表します。カレンダーで同じ期間に複数の横棒がある場合、タスク間の同時実行を意味します。
ガントル ダイアグラムは、各タスクの開始時期、終了時期、タスクの進行状況、および各タスク間の並列性を明確に表すことができます。しかし、その欠点は、タスク間の依存関係を明確に反映できないこと、プロジェクト全体のキー ポイントを決定することが難しいこと、計画の潜在的な部分を反映できないことです。
() ソフトウェア コスト見積もりモデルは、ソフトウェア システム全体を見積もるための静的な一変量モデルです。
- A. パットナム
- B.ベーシックココモ
- C.中級ココモ
- D.詳細ココモ
【試験問題の分析】：COCOMOの基本は静的一値モデルで、ソースコード1000行あたりの行数（KLoC）で測ったプログラムサイズからソフトウェア開発の作業量（とコスト）を計算します。COCOMO は 3 つの異なるソフトウェア プロジェクトに適用できます。
オーガニック プロジェクト - 比較的小規模で単純なソフトウェア プロジェクトで、小規模な経験豊富なチームによって完成され、要件が少なく、過度に制限されていません。
中程度に分離されたプロジェクト - 中程度の規模 (サイズと複雑さ) のソフトウェア プロジェクトを指し、さまざまな経験レベルの人々のチームによって、厳格な要件とそれほど厳格でない要件の両方で完成されます。
組み込みプロジェクト - ハードウェア、ソフトウェア、および運用上の制約への準拠のコンパクトなセットに依存する必要があるソフトウェア プロジェクトを指します。
最も不適切なリスク管理戦略は、「プロジェクトが完了する前に重要なスタッフが転職する」リスクに対するものです。
- A. 主要な技術者ごとに、バックアップ担当者をトレーニングする必要があります。
- B.プロジェクトチームを設立して、開発活動について全員に通知する
- C. 関連する能力を持つ新しいスタッフの一時的な採用
- D. すべての作業の詳細なレビューを整理する
【試験問題の分析】：ITプロジェクトにおいて、人材の一時的な増減は慎重に扱うべき事項です。新しい人員は元のチームに慣れる必要があるため、プロジェクトの状況を理解するのに多くの時間がかかり、同時に通信コストも増加します。
リスク参照レベルの定義は、( ) アクティビティで一般的に使用される手法です。
- A. リスクの特定
- B. リスク予測
- C. リスク評価
- D. リスク管理
[試験問題の説明]: リスク識別のタスクは、リスク エントリ チェックリストを確立することによって、プロジェクト計画に対する脅威を体系的に判断しようとすることです。. チェックリストを使用してリスクを特定し、人々がいくつかの一般的で既知の予測可能なリスクの特定に集中できるようにします。
リスク予測は、リスク推定とも呼ばれ、リスクが発生する可能性または可能性と、リスクが発生した場合の結果という 2 つの側面からリスクを評価します。
リスク評価のタスクは、リスク参照レベル値を定義し、参照レベル値に影響を与えるリスクの組み合わせを予測することです。
リスク管理のタスクは、リスク回避、リスク監視、リスク管理、および緊急時対応計画です。
ソフトウェア プロジェクト チームが積極的なリスク管理方法を採用している場合、( ) が最適なリスク管理戦略です。
- A. リスク回避
- B. リスク監視
- C. リスクの軽減
- D. リスク管理と緊急時対応計画
【試験問題の解説】：リスク回避とは、損失を生む可能性のある活動や仕事を断念または控えることを意味します。たとえば、洪水のリスクを回避するために、水はけのよい高台に工場を建てることができます。これは、積極的なリスク管理方法です。
リスク監視とは、意思決定機関の運営中にリスクの発生と変化を監視し、必要に応じて対応戦略を調整するプロセス全体を指します。
リスク管理とは、リスクが確実に存在する環境において、リスクを最小限に抑える管理プロセスを指します。リスクを移転して回避することはできますが、排除することはできません。
( ) は、所有者プログラマー グループのない開発者組織の最も不適切な形式です。
- A. 少数のプロジェクト開発者 (3 ～ 4 人など) によるプロジェクト
- B. 新技術を使用したプロジェクト
- C. 大規模プロジェクト
- D.確実性の低い項目
[テスト問題の分析]: 大規模なプロジェクトでは、メイン プログラマーがさまざまなモジュール プログラムを統合する必要があるため、メイン プログラマー グループを持たない開発者の組織形態を採用するのは最も不向きです。
リスク管理に関する次の記述のうち、間違っているものはどれですか ( )。
- A. 結果のみに基づいてリスクに優先順位を付ける
- B. システムのパフォーマンスまたは機能要件を変更することで、特定のリスクを回避できる
- C. すべてのリスクを排除することは不可能ですが、それらを軽減または軽減するための措置を講じることはできます
- D. プロジェクト開発中にリスクを定期的に評価および管理する必要がある
[試験問題の説明]: リスクの優先度は、リスクの結果にリスクの発生確率を掛けた値に等しいリスクの露出に基づいています。
ガント チャート (ガント チャート) は ( ) できません。
- A. プロジェクトのスケジュール管理ツールとして
- B. 各タスクの開始と期限を明確に記述する
- C. 並行して実行されているタスクに関する明確な情報を取得する
- D. タスク間の依存関係を明確に取得する
【テスト問題の分析】：ガントチャートは、各タスクの開始と期限を明確に記述し、タスクの並行進行状況に関する情報を効果的に得ることができるプロジェクト進捗管理ツールです。
プロジェクトの見積もり方法に関する次の記述のうち、間違っているものはどれですか ( )。
- A. 専門家の判断方法は、専門家の経験と主観に左右される
- B. ヒューリスティック手法 (COCOMO モデルなど) のパラメータを決定するのが難しい
- C. 機械学習方法では、トレーニング データの特徴付けと類似性の判断が困難
- D. 上記の 3 つの方法を組み合わせると、正確な推定結果が得られます
【テスト問題の分析】: 一般的に使用されるプロジェクト見積もりの方法には、主に専門家の判断、ヒューリスティックな方法、機械学習の方法が含まれます。
エキスパートジャッジメント法とは、専門知識、知識、経験を有する専門家に相談し、その長年の実務経験と判断力に基づいて計画されたプロジェクトを予測する方法を指します。明らかに、この方法を使用すると、専門家の経験と主観の影響を受けやすくなります。
ヒューリスティック法は、比較的単純で一般的なヒューリスティックなルールのセットを使用して推定しますが、パラメータの決定が難しく、精度が低いという特徴があります。
機械学習法は、人工知能やニューラルネットワーク技術に基づく推定法であり、訓練データの特徴を記述し、その類似性を判断することは困難です。
どの推定方法を使用しても、推定結果は正確ではなく概算です。
大規模なソフトウェアの場合、制御されていない変更はすぐに混乱につながる可能性があります。効果的な変更管理のために、構成データベースとベースラインの概念が使用されます。( ) は構成データベースに属していません。
- A. 開発ライブラリ
- B. 管理図書館
- C. 情報ベース
- D. 製品ライブラリ
【出題分析】：ソフトウェア変更管理と構成管理の基礎知識を問う問題です。
ソフトウェアの変更管理は変更管理の重要な部分であり、変更管理を効果的に実行するには、構成データベースとベースラインの概念が必要です。通常、構成データベースには、開発リポジトリ、管理リポジトリ、および本番リポジトリが含まれます。
ソフトウェア プロジェクトの開発過程において、ソフトウェア プロジェクトのリスクを評価する場合、( ) はリスクとは関係ありません。
- A. 上級管理職はプロジェクトを支援することを正式に約束していますか?
- B. 開発者とユーザーはシステムの要件を完全に理解していますか?
- C. エンドユーザーが開発したシステムを展開することに同意するかどうか
- D. 開発に必要な資金が予定どおりに調達できるかどうか
【出題分析】：リスクマネジメントの基礎知識を問う問題です。
ソフトウェア開発におけるリスクは、上級管理者のサポートの程度、システム要件の理解度、開発資金のタイムリーな投資に関係しますが、エンド ユーザーには関係なく、システムの最終的な展開と運用には関係ありません。開発プロセスに属します。Boehm が提唱する 10 のリスクとは、開発者の不足、スケジュールと予算の未達、不適切なソフトウェア機能の開発、不適切なユーザー インターフェイスの開発、派手な要件、常に変化する要件、要件を満たさない外部で実行されるタスク、外部から提供されるコンポーネントが機能することです。要件を満たしていない、リアルタイム パフォーマンスが要件を満たしていない、コンピューター サイエンスの開発レベルを超えている。
ソフトウェアのリスクには、一般に 2 つの特徴があります。
- A. 消防と危機管理
- B. 既知および未知のリスク
- C. 不確実性と損失
- D. スタッフと予算
【試験問題の分析】：この問題では、ソフトウェアのリスクの特徴を調べます。ソフトウェア リスクには一般に、不確実性と損失の 2 つの特性が含まれます。不確実性とは、リスクが発生する可能性があるかどうかを意味し、損失は望ましくない結果であり、リスクが発生した場合に発生する損失です。消防と危機管理は不適切ですが、頻繁に採用されるソフトウェア リスク管理戦略です。既知および未知のリスクは、ソフトウェア リスクを分類する 1 つの方法です。スタッフと予算は、プロジェクトのリスクを特定する際に特定する必要がある要因です。
システム開発計画書は、プロジェクト期間中のシステム開発者とプロジェクトマネージャー間のコミュニケーションに使用されるもので、()や予算配分表などを含みます。
- A.PERTチャート
- B. マスタープラン
- C. テスト計画
- D. 開発契約
【試験問題分析】：システム開発計画書の知識を問う問題です。
プロジェクト期間中のシステム開発者とプロジェクトマネージャー間のコミュニケーションに使用される文書は、主にシステム開発計画書であり、タスク分解表、PERT チャート、ガントチャート、予算配賦表などがあります。全体的な計画および開発契約は、システム計画およびシステム分析フェーズでのシステム アナリストとのコミュニケーションに使用されます。テスト計画は、システム テスターとシステム開発者の間のコミュニケーションに使用されます。
リスク予測は、リスクの発生可能性と（ ）の2つの側面からリスクを評価します。
- A. リスクの原因
- B. リスク監視技術
- C. リスクを排除できるか
- D. リスク発生の結果
【試験問題の分析】：リスク予測に関する知識を問う問題です。リスク予測では、リスクが発生する可能性と、リスクが発生した場合の影響が深刻かどうかという 2 つの側面からリスクを評価します。
ソフトウェア システムの構築に必要な人数を決定する際は、( ) を考慮しないでください。
- A. システムの市場展望
- B. システムのサイズ
- C. システムの技術的な複雑さ
- D. プロジェクト計画
【出題分析】：プロジェクトマネジメントの内容を問う問題です。ソフトウェア開発リソースを計画するときは、ソフトウェア システムを構築するために必要な人数を決定するために、ソフトウェア システムの規模、システムの技術的な複雑さ、プロジェクト計画、および開発者の技術的背景を考慮する必要があります。 、およびシステムに無関係な市場の見通しがあるかどうか。