開発技術関連
開発技術関連の基本知識
問題一覧
1
ソフトウェアサイクルを合意プロセス、テクニカルプロセス、運用•サービスプロセス、支援プロセスなどのプロセス群に分けて、それぞれの作業内容を定めている。
共通フレーム
2
ISO/IEC12207に対応する「ソフトウェアサイクルプロセス」の規格。
合意プロセス、組織のプロジェクトイネーブリングプロセス、テクニカルマネジメントプロセス、テクニカルプロセスの4つに分類。
JIS X 0160
3
各工程の終了基準を前もって明確に定義しておき、その基準を達成しない場合は次の工程に進まない。原則として前の工程には戻らない。
ウォーターフォールモデル
4
独立性の高い部分ごとに要件定義、設計、プログラミング、テストというプロセスを、「目的、代替案、制約の決定」「代替案の評価とリスクの明確化、解消」「開発と検証」「次サイクルの検討」のフェーズを繰り返しながら進める技法。
スパイラルモデル
5
確定している要求を段階的に開発する方式で、事前に計画された製品改善モデルとも呼ばれる。
段階的モデル
6
要求に不明確な部分があるために最初に要求の定義ができない場合に用いられる方式で、部分的に定義された要求を開発し、要求を洗練させる。
進化的モデル
7
要件定義の段階で試作品を作成し、その結果を以降の開発工程に反映させる開発手法である。ユーザー要求の明確化や仕様の実現性評価を目的として、各種開発手法の中で採用される。
プロトタイプ
8
固定の期間中に、そのチームが達成できる要求のボリュームと作業量なこと。
ベロシティ
9
プロダクトとして実現したいことを優先順位付けしてリストにしたもの。
プロダクトバックログ
10
顧客の要求であるユーザーストーリーを見積もるための単位
ストーリーポイント
11
反復しながら開発を進める開発サイクル単位。スクラムではスプリントという。
イテレーション
12
未実現の機能や作業を時間軸に沿って折れ線グラフ化したもので、進捗を把握できる。
バーダウンチャート
13
開発の初期段階の設計よりもコーディングとテストを重視し、各工程を順番に積み上げていくことよりも、常にフィードバックを行なって修正と再設計していくことを重視する。
エクストリームプログラミング
14
プログラミングを2人1組で行い、片方が書いたコードを片方がチェックするという作業を交代しながら進める。
ペアプログラミング
15
短い期間ごとにリリースを繰り返すこと。
反復
16
まずテストを作成し、そのテストに合格するように実装を進めること。
テスト駆動開発
17
バグがなくても、コードの効率や保守性を改善していくこと
リファクタリング
18
日本の自動車製造におけるムダを省いた方式をソフトウェア開発に適用したもの。
「ムダをなくす」「品質を作り込む」「知識を作り出す」「決定を遅らせる」「早く提供する」「人を尊重する」「全体を最適化する」
リーンソフトウェア開発
19
スプリントという短い開発期間を設定し、透明性と検査、適応によって、経験に基づいた最適化をすすめながら、各スプリントの中で選択した機能を開発していく。
スクラム
20
各スプリントの最後で実施する振り返り。
レトロスペクティブミーティング
21
業務の中で取り扱われるデータそのものは比較的変化が少ない点に着目し、抽象データ型から構成されるデータ基盤を事前に構築して、そのデータ基盤上にビジネスプロセスを構築していく技法。
データ中心アプローチ技法
22
システムを構築する機能に着目し、機能ごとのモジュール分割を行って機能の階層構造化を図るとともに、構造化プログラミングを実施して品質を向上させる技法。
構造化技法
23
機能とデータが一体化したものをシステムの構成要素として捉え、識別したものを再利用可能なコンポーネントとして開発していく技法。
オブジェクト指向技法
24
幾つかのクラスに共通する性質を持つクラスを定義すること
汎化
25
あるクラスを基に幾つかの性質を付加して新しいクラスを定義すること
特化
26
ユースケース図やユースケースの詳細な記述で表された要求モデルを入力として、ユースケースのクラスをバウンダリクラス、コントロールクラス、エンティティクラスの3つに分けて分析し、クラス間の関連を定義する図を作成する。
ロバストネス分析
27
システムで意図しない誤操作や正しくないデータが入力されないようにする信頼性設計技法のこと。
フールプルーフ
28
システムの一部に故障や異常が発生したとき、その影響が安全な方向に働くように、システムの信頼性を追求する耐障害設計の考え方。
フェールセーフ
29
システムの一部が故障した時に、故障を起こした装置や部分を切り離して、処理能力を落としてもシステムの全面停止を回避するという高信頼化設計技法。
フェールソフト
30
冗長構成を講じることによって、システムが部分的に故障してもシステム全体として必要な機能を維持できるようにする高信頼化設計技法。
フォールトトレラント
31
通常の開発作業とは逆にプログラムのソースコードから設計仕様などを導き出す技術のこと。
リバースエンジニアリング
32
リバースエンジニアリングによって現行システムの上流開発工程の成果物を再生産し、その仕様を修正して新システムを構築する。
リエンジニアリング
33
各手続きの構造を明確に、整理された形で（構造化定理に基づいて）記述する手法。
構造化プログラミング
34
再利用を前提としたソフトウェア部品であるコンポーネントを組み合わせる事でシステムを構築する手法。
コンポーネント指向プログラミング
35
各機能を表すアイコンを画面上で並べるなど、視覚的な操作によってプログラム作成を支援する手法。
ビジュアルプログラミング
36
個々の利用者に提供するサービスを実現する機能単位の集まりととらえ、利用者や業務上から要求されるサービスを設計するという、大規模な情報システムの開発の考え方。サービス間の関係は疎結合で設計する。
SOA
37
複数の異なるコンテンツ（サービス）を取り込み、それらを組み合わせて利用し、新しいコンテンツ（サービス）を作成する手法を総称した言葉。
マッシュアップ
38
プログラム内部のロジックに基づいてテストケースを設計する技法。
ホワイトボックステスト
39
ホワイトボックステストで、全ての命令を最低1回は実行させるテスト。
命令網羅
40
ホワイトボックステストで、各判定を少なくとも1回はとらせるテスト。
判定条件網羅
41
ホワイトボックステストで、判定条件中のすべての条件で、真と偽を少なくとも1回はとらせるテスト。
条件網羅
42
機能仕様に基づいて、入力とその結果に着目してテストケースを設計する技法。
ブラックボックステスト
43
ブラックボックステストで、正常処理となる入力値と異常処理となる入力値に分割して、それぞれの代表値を用意するテスト。
同値分割
44
ブラックボックステストで、正常と異常の境界付近の値をテストケースとして採用するテスト。
限界値分析
45
故意に埋め込んだエラーもソフトウェアに潜在していたエラーも、同じ比率で発見されることを前提とした、ソフトウェアの残存エラー数を推定する方法。
エラー埋込み法
46
直公表によるテストケースの作成条件を緩和した技法で、2因子間の取り得る値の組み合わせが同一回数でなくても、1回以上存在すればよいとしてテストケースを設計する技法。
ペアワイズ法
47
プロジェクトメンバーがn人の場合、コミュニケーションチャネル数は、プロジェクトメンバーのうちから、任意の2人を選ぶ組み合わせの数だけ存在する。式は？
nC2
48
開発生産性の式は？
開発規模÷(3.0×(開発規模)1.12)
49
全体の生産性を表す式は？
1/ 1/X+1/Y+1/Z
プロジェクトの立ち上げ
プロジェクトの立ち上げ
ユーザ名非公開 · 14問 · 1年前プロジェクトの立ち上げ
プロジェクトの立ち上げ
14問 • 1年前ユーザ名非公開
プロジェクト計画（計画〜WBS）
プロジェクト計画（計画〜WBS）
ユーザ名非公開 · 14問 · 1年前プロジェクト計画（計画〜WBS）
プロジェクト計画（計画〜WBS）
14問 • 1年前ユーザ名非公開
プロジェクト計画（定義〜順序付け）
プロジェクト計画（定義〜順序付け）
ユーザ名非公開 · 16問 · 1年前プロジェクト計画（定義〜順序付け）
プロジェクト計画（定義〜順序付け）
16問 • 1年前ユーザ名非公開
プロジェクト計画（スケジュール作成〜見積り）
プロジェクト計画（スケジュール作成〜見積り）
ユーザ名非公開 · 16問 · 1年前プロジェクト計画（スケジュール作成〜見積り）
プロジェクト計画（スケジュール作成〜見積り）
16問 • 1年前ユーザ名非公開
プロジェクト計画（予算の作成〜リスクの評価）
プロジェクト計画（予算の作成〜リスクの評価）
ユーザ名非公開 · 23問 · 1年前プロジェクト計画（予算の作成〜リスクの評価）
プロジェクト計画（予算の作成〜リスクの評価）
23問 • 1年前ユーザ名非公開
問題一覧
1
ソフトウェアサイクルを合意プロセス、テクニカルプロセス、運用•サービスプロセス、支援プロセスなどのプロセス群に分けて、それぞれの作業内容を定めている。
共通フレーム
2
ISO/IEC12207に対応する「ソフトウェアサイクルプロセス」の規格。
合意プロセス、組織のプロジェクトイネーブリングプロセス、テクニカルマネジメントプロセス、テクニカルプロセスの4つに分類。
JIS X 0160
3
各工程の終了基準を前もって明確に定義しておき、その基準を達成しない場合は次の工程に進まない。原則として前の工程には戻らない。
ウォーターフォールモデル
4
独立性の高い部分ごとに要件定義、設計、プログラミング、テストというプロセスを、「目的、代替案、制約の決定」「代替案の評価とリスクの明確化、解消」「開発と検証」「次サイクルの検討」のフェーズを繰り返しながら進める技法。
スパイラルモデル
5
確定している要求を段階的に開発する方式で、事前に計画された製品改善モデルとも呼ばれる。
段階的モデル
6
要求に不明確な部分があるために最初に要求の定義ができない場合に用いられる方式で、部分的に定義された要求を開発し、要求を洗練させる。
進化的モデル
7
要件定義の段階で試作品を作成し、その結果を以降の開発工程に反映させる開発手法である。ユーザー要求の明確化や仕様の実現性評価を目的として、各種開発手法の中で採用される。
プロトタイプ
8
固定の期間中に、そのチームが達成できる要求のボリュームと作業量なこと。
ベロシティ
9
プロダクトとして実現したいことを優先順位付けしてリストにしたもの。
プロダクトバックログ
10
顧客の要求であるユーザーストーリーを見積もるための単位
ストーリーポイント
11
反復しながら開発を進める開発サイクル単位。スクラムではスプリントという。
イテレーション
12
未実現の機能や作業を時間軸に沿って折れ線グラフ化したもので、進捗を把握できる。
バーダウンチャート
13
開発の初期段階の設計よりもコーディングとテストを重視し、各工程を順番に積み上げていくことよりも、常にフィードバックを行なって修正と再設計していくことを重視する。
エクストリームプログラミング
14
プログラミングを2人1組で行い、片方が書いたコードを片方がチェックするという作業を交代しながら進める。
ペアプログラミング
15
短い期間ごとにリリースを繰り返すこと。
反復
16
まずテストを作成し、そのテストに合格するように実装を進めること。
テスト駆動開発
17
バグがなくても、コードの効率や保守性を改善していくこと
リファクタリング
18
日本の自動車製造におけるムダを省いた方式をソフトウェア開発に適用したもの。
「ムダをなくす」「品質を作り込む」「知識を作り出す」「決定を遅らせる」「早く提供する」「人を尊重する」「全体を最適化する」
リーンソフトウェア開発
19
スプリントという短い開発期間を設定し、透明性と検査、適応によって、経験に基づいた最適化をすすめながら、各スプリントの中で選択した機能を開発していく。
スクラム
20
各スプリントの最後で実施する振り返り。
レトロスペクティブミーティング
21
業務の中で取り扱われるデータそのものは比較的変化が少ない点に着目し、抽象データ型から構成されるデータ基盤を事前に構築して、そのデータ基盤上にビジネスプロセスを構築していく技法。
データ中心アプローチ技法
22
システムを構築する機能に着目し、機能ごとのモジュール分割を行って機能の階層構造化を図るとともに、構造化プログラミングを実施して品質を向上させる技法。
構造化技法
23
機能とデータが一体化したものをシステムの構成要素として捉え、識別したものを再利用可能なコンポーネントとして開発していく技法。
オブジェクト指向技法
24
幾つかのクラスに共通する性質を持つクラスを定義すること
汎化
25
あるクラスを基に幾つかの性質を付加して新しいクラスを定義すること
特化
26
ユースケース図やユースケースの詳細な記述で表された要求モデルを入力として、ユースケースのクラスをバウンダリクラス、コントロールクラス、エンティティクラスの3つに分けて分析し、クラス間の関連を定義する図を作成する。
ロバストネス分析
27
システムで意図しない誤操作や正しくないデータが入力されないようにする信頼性設計技法のこと。
フールプルーフ
28
システムの一部に故障や異常が発生したとき、その影響が安全な方向に働くように、システムの信頼性を追求する耐障害設計の考え方。
フェールセーフ
29
システムの一部が故障した時に、故障を起こした装置や部分を切り離して、処理能力を落としてもシステムの全面停止を回避するという高信頼化設計技法。
フェールソフト
30
冗長構成を講じることによって、システムが部分的に故障してもシステム全体として必要な機能を維持できるようにする高信頼化設計技法。
フォールトトレラント
31
通常の開発作業とは逆にプログラムのソースコードから設計仕様などを導き出す技術のこと。
リバースエンジニアリング
32
リバースエンジニアリングによって現行システムの上流開発工程の成果物を再生産し、その仕様を修正して新システムを構築する。
リエンジニアリング
33
各手続きの構造を明確に、整理された形で（構造化定理に基づいて）記述する手法。
構造化プログラミング
34
再利用を前提としたソフトウェア部品であるコンポーネントを組み合わせる事でシステムを構築する手法。
コンポーネント指向プログラミング
35
各機能を表すアイコンを画面上で並べるなど、視覚的な操作によってプログラム作成を支援する手法。
ビジュアルプログラミング
36
個々の利用者に提供するサービスを実現する機能単位の集まりととらえ、利用者や業務上から要求されるサービスを設計するという、大規模な情報システムの開発の考え方。サービス間の関係は疎結合で設計する。
SOA
37
複数の異なるコンテンツ（サービス）を取り込み、それらを組み合わせて利用し、新しいコンテンツ（サービス）を作成する手法を総称した言葉。
マッシュアップ
38
プログラム内部のロジックに基づいてテストケースを設計する技法。
ホワイトボックステスト
39
ホワイトボックステストで、全ての命令を最低1回は実行させるテスト。
命令網羅
40
ホワイトボックステストで、各判定を少なくとも1回はとらせるテスト。
判定条件網羅
41
ホワイトボックステストで、判定条件中のすべての条件で、真と偽を少なくとも1回はとらせるテスト。
条件網羅
42
機能仕様に基づいて、入力とその結果に着目してテストケースを設計する技法。
ブラックボックステスト
43
ブラックボックステストで、正常処理となる入力値と異常処理となる入力値に分割して、それぞれの代表値を用意するテスト。
同値分割
44
ブラックボックステストで、正常と異常の境界付近の値をテストケースとして採用するテスト。
限界値分析
45
故意に埋め込んだエラーもソフトウェアに潜在していたエラーも、同じ比率で発見されることを前提とした、ソフトウェアの残存エラー数を推定する方法。
エラー埋込み法
46
直公表によるテストケースの作成条件を緩和した技法で、2因子間の取り得る値の組み合わせが同一回数でなくても、1回以上存在すればよいとしてテストケースを設計する技法。
ペアワイズ法
47
プロジェクトメンバーがn人の場合、コミュニケーションチャネル数は、プロジェクトメンバーのうちから、任意の2人を選ぶ組み合わせの数だけ存在する。式は？
nC2
48
開発生産性の式は？
開発規模÷(3.0×(開発規模)1.12)
49
全体の生産性を表す式は？
1/ 1/X+1/Y+1/Z