社会年号クイズ
社会年号クイズ
chicken · 10回閲覧 · 84問 · 2年前社会年号クイズ
社会年号クイズ
10回閲覧 • 84問 • 2年前社会年号クイズ2
社会年号クイズ2
chicken · 57問 · 2年前社会年号クイズ2
社会年号クイズ2
57問 • 2年前返読文字
返読文字
chicken · 11問 · 2年前返読文字
返読文字
11問 • 2年前純物質or混合物
純物質or混合物
chicken · 17問 · 2年前純物質or混合物
純物質or混合物
17問 • 2年前炎色反応 元素→色
炎色反応 元素→色
chicken · 7問 · 2年前炎色反応 元素→色
炎色反応 元素→色
7問 • 2年前炎色反応 色→元素
炎色反応 色→元素
chicken · 7問 · 2年前炎色反応 色→元素
炎色反応 色→元素
7問 • 2年前短歌 作品名 一問一答
短歌 作品名 一問一答
chicken · 8問 · 2年前短歌 作品名 一問一答
短歌 作品名 一問一答
8問 • 2年前イオン結合からなる物質
イオン結合からなる物質
chicken · 3回閲覧 · 6問 · 2年前イオン結合からなる物質
イオン結合からなる物質
3回閲覧 • 6問 • 2年前英単語 動詞編
英単語 動詞編
chicken · 41問 · 2年前英単語 動詞編
英単語 動詞編
41問 • 2年前地理
地理
chicken · 28問 · 1年前地理
地理
28問 • 1年前英表
英表
chicken · 25問 · 1年前英表
英表
25問 • 1年前問題一覧
1
ソフトウェアの企画・要件定義から開発、運用、保守、そして廃棄に至るまでの一連のプロセスのこと。
ソフトウェアライフサイクル
2
ソフトウェアを開発するための手順や工程の進め方をパターン化した枠組み。
ソフトウェア開発モデル
3
上流工程から下流工程へと滝のように一直線に開発を進める、手戻りを前提としない伝統的な開発モデル。
ウォータフォールモデル
4
開発の初期段階で試作品（プロトタイプ）を作成し、ユーザーの評価や要求を確認しながら開発を進める手法。
プロトタイプモデル
5
システムを独立性の高い部分ごとに分割し、設計・実装・テストのサイクルを繰り返しながら徐々に完成度を高める手法。
スパイラルモデル
6
システムを機能ごとに分割し、優先度の高い機能から順番に開発・リリースを繰り返してシステムを拡張していく手法。
インクリメンタルモデル
7
初期バージョンを素早くリリースし、ユーザーのフィードバックを得ながら機能追加や改善を繰り返してシステムを進化させる手法。
進化的モデル
8
短期間の開発サイクル（イテレーション）を繰り返し、仕様変更に柔軟に対応しながら素早く価値を提供する開発手法の総称。
アジャイル型開発
9
2001年に提唱された、アジャイル開発の根底にある4つの価値観と12の原則をまとめた宣言文。
アジャイルソフトウェア開発宣言
10
チームのコミュニケーションを重視し、短い期間（スプリント）で開発を繰り返すアジャイル開発の代表的なフレームワーク。
スクラム
11
スクラムにおいて、開発からリリース可能な製品の一部を作成するまでの反復的で短い開発期間（通常1〜4週間）。
スプリント
12
会議や作業に対して「最大でこれだけの時間を使う」とあらかじめ固定の制限時間を設けるタイムマネジメントの手法。
タイムボックス
13
スプリントの開始時に、そのスプリントで「何を作るか」「どう作るか」をチーム全体で決定する計画会議。
スプリントプランニング
14
開発チームが毎日同じ時間・場所で行う、進捗状況の共有と問題の早期発見を目的とした短いミーティング（朝会など）。
デイリースクラム
15
スプリントの終わりに、完成した成果物をプロダクトオーナーや関係者にデモをして評価やフィードバックを得る会議。
スプリントレビュー
16
スプリントの終わりに開発チームが行う、プロセスやツールの改善点を話し合う振り返り会議。
スプリントレトロスペクティブ
17
プロダクトに必要な機能や要件、改善要望などを優先順位を付けて一覧化したリスト。
プロダクトバックログ
18
プロダクトバックログの項目を追加、見直し、詳細化し、優先順位を整理する活動。
プロダクトバックログリファインメント
19
スプリントにおける成果物の量
ベロシティ
20
良いユーザーストーリー（バックログ項目）が満たすべき6つの条件の頭文字をとった原則。
INVEST
21
INVESTの「I」。各ストーリーが他のストーリーに依存せず、独立して開発・リリース可能であること。
Independent
22
INVESTの「N」。ストーリーは固定された契約ではなく、チーム間で交渉や議論の余地があること。
Negotiable
23
INVESTの「V」。ストーリーがユーザーや顧客にとって明確な価値をもたらすものであること。
Valuable
24
INVESTの「E」。チームがストーリーの実装に必要な工数やサイズを見積もることができること。
Estimable
25
INVESTの「S」。ストーリーが1回のスプリント内に収まる程度に適切な（小さな）サイズであること。
Small
26
INVESTの「T」。ストーリーが完了したかどうかを検証するためのテストが可能であること。
Testable
27
開発の初期からプログラミングとテストを重視し、変更に柔軟に対応するアジャイル手法の1つ。
XP （エクストリームプログラミング）
28
2人のプログラマが1台のPCを共有し、1人がコードを書き、もう1人がレビューや設計をしながら共同で開発する手法。
ペアプログラミング
29
実装コードを書く前にまずテストコードを書き、そのテストを通るように実装を進める開発手法（TDD）。
テスト駆動開発
30
プログラムの外部から見た動作を変えずに、ソースコードの内部構造を整理して読みやすく、保守しやすくする作業。
リファクタリング
31
コードの変更を頻繁に共有リポジトリに統合し、自動ビルドと自動テストを継続的に実行する開発プラクティス（CI）。
継続的インテグレーション
32
チーム全員がすべてのソースコードに対する責任を持ち、誰でもどこでも修正・改善してよいとするXPのプラクティス。
コードの共同所有
33
「今は必要ない機能は作るな（You aren't gonna need it）」という、無駄な事前設計を避けるXPの原則。
YAGNI
34
トヨタ生産方式を体系化したもので、徹底的に「ムダ」を排除し、価値の流れを最適化する生産管理の手法。
リーン生産方式
35
製品やサービスが顧客に届くまでの「価値の流れ」と「ムダ」を視覚化し、プロセスの改善点を見つけるための図。
バリューストリームマップ
36
複数の製品やサービスで共通して利用できる土台（プラットフォーム）となるシステムや基盤を開発すること。
プラットフォーム開発
37
システムの仕様をプラットフォームに依存しないモデル（PIM）で定義し、そこから自動変換で特定のコードを生成する開発手法。
MDA （モデル駆動アーキテクチャ）
38
製品開発における複数の工程（設計、製造手配など）を同時並行で進め、全体の開発期間を短縮する手法。
コンカレントエンジニアリング
39
ハードウェアとソフトウェアの設計を切り離さず、両者を連携させながら同時並行で最適化していく設計手法。
コデザイン
40
既存のシステムやビジネスプロセスを根本から見直し、最新の技術で再構築・最適化すること。
リエンジニアリング
41
既存のソフトウェアの動作やコードを解析し、仕様書や設計図を導き出すこと。
リバースエンジニアリング
42
リバースエンジニアリングで抽出した仕様を基に、新しい要件を加えて新たなシステムを開発すること。
フォワードエンジニアリング
43
最小限のソースコード記述とGUI（画面上の視覚的な操作）を組み合わせて、素早くシステムを開発する手法。
ローコード開発
44
組織のソフトウェア開発やシステム構築のプロセスの成熟度を、1（初期）から5（最適化している）の5段階で評価するモデル。
CMMI
45
システムの機能やデータの流れをトップダウンで階層的に分割し、図解を用いて要件を視覚的に分析する手法。
構造化分析法
46
データがシステム内でどのように処理され、どこへ流れていくかを示す図。
DFD （データフローダイアグラム）
47
構造化分析において、現在の業務が「誰によって・どのように」物理的に行われているかを表したモデル。
現物理モデル
48
現物理モデルから物理的な制約（人や手段）を取り除き、現在の業務の「論理的な本質（何をしているか）」を表したモデル。
現論理モデル
49
現論理モデルに、システム化による新しい要件や機能を加えた、新しいシステムの論理的なモデル。
新論理モデル
50
新論理モデルを基に、新しいシステムで「誰が・どの技術で」実現するかを具体的に割り当てたモデル。
新物理モデル
51
DFDの最上位の図で、対象システム全体を1つのプロセス（丸）で表し、外部の環境とのデータの入出力を示した図。
コンテキストダイアグラム
52
DFDなどに現れるデータの意味や構成要素（データ型や桁数など）を定義し、一元管理する辞書。
データディクショナリ
53
DFDの最下層のプロセス（これ以上分割できない処理）の具体的な処理手順や論理を記述した仕様書。
ミニスペック
54
システムで「どのような処理（機能）を行うか」に着目し、処理手順を中心にシステムを設計する手法。
プロセス中心設計
55
業務の処理（プロセス）の流れを中心にシステムの構造を分析・設計する考え方（POA）。
プロセス中心アプローチ
56
システムが「どのようなデータを扱うか」に着目し、データの構造を中心にシステムを設計する手法。
データ中心設計
57
業務で扱うデータ（エンティティ）の構造は変化しにくいという前提に基づき、データモデルを中心に設計する考え方（DOA）。
データ中心アプローチ
58
各機能（プロセス）がデータに対して「生成(C)・参照(R)・更新(U)・削除(D)」のどの操作を行うかを表にした図。
CRUDマトリクス
59
システムの外部から発生するイベント（事象）に対して、システムがどう反応・処理するかを分析する手法。
事象応答分析
60
システムやオブジェクトが、あるイベントをきっかけに「どのような状態からどのような状態へ変化するか」を示した図。
状態遷移図
61
丸（プレース）と棒（トランジション）、トークン（点）を用いて、システムの並行処理や同期・非同期の挙動を数学的にモデル化した図。
ペトリネット図
62
（※構造化分析法と同義）システムの機能やデータの流れを階層的に分割し、図を用いて視覚的に要件を分析する手法。
構造化分析
63
データとそのデータを操作する手続きを「オブジェクト」というひとまとまりの単位とし、それらのやり取りでプログラムを構成する考え方。
オブジェクト指向
64
オブジェクト内部のデータや詳細な処理手順を隠蔽し、外部からは決められたメソッド（窓口）を通してのみ操作できるようにすること。
カプセル化
65
オブジェクト指向において、同じ性質を持つオブジェクトのデータ構造（属性）と振る舞い（メソッド）を定義した「設計図」。
クラス
66
オブジェクト指向プログラミングで、よく使われる汎用的なクラスを再利用しやすいように集めてまとめたファイル。
クラスライブラリ
67
クラス（設計図）を基に、コンピュータのメモリ上に実体化された具体的なオブジェクトのこと。
インスタンス
68
既存のクラスの属性やメソッドを受け継いで、新しいクラスを作成する仕組み（インヘリタンス）。
継承
69
クラス間の関係で、共通の性質を抽出した上位クラス（汎化）と、固有の性質を追加した下位クラス（特化）の「is-a」関係。
汎化-特化関係
70
クラス間の関係で、全体を構成するクラス（集約）と、その一部を構成する部品のクラス（分解）の「part-of」関係。
集約-分解関係
71
同じ名前のメソッド（操作）を呼び出しても、対象となるオブジェクトのクラスによって異なる動作をする性質。
ポリモーフィズム （多様性・多相性）
72
上位クラス（親）から継承したメソッドの処理内容を、下位クラス（子）で自分用に上書き・再定義すること。
オーバーライド
73
メソッドの名前と引数・戻り値の型だけが定義され、具体的な処理内容（実装）を持たないメソッド。
抽象メソッド
74
抽象メソッドを1つ以上含み、それ単体ではインスタンス化（実体化）できない、継承されることを前提としたクラス。
抽象クラス
75
同じクラス内で、メソッド名は同じだが引数の型や数が異なるメソッドを複数定義すること。
オーバーロード
76
オブジェクトが受け取った処理の要求を、自分自身で処理せずに内部で保持している他のオブジェクトに任せること（デリゲーション）。
委譲
77
あるオブジェクトで発生したイベントや変更が、関連する他のオブジェクトへと次々に伝わっていく仕組み。
伝搬
78
オブジェクト指向開発において、システムの設計や構造を視覚的に表現するための標準化されたモデリング言語（統一モデリング言語）。
UML
79
UMLの構造図の一つで、システムを構成するクラスの属性・操作や、クラス間の関係（関連、継承など）を静的に表現した図。
クラス図
80
UMLを拡張し、ソフトウェアだけでなくハードウェアなども含めたシステム全体の設計をモデリングするための記述言語。
SysML
81
UMLの振る舞い図の一つで、オブジェクト間でやり取りされるメッセージの順序を「時間軸（縦方向）」に沿って表現した図。
シーケンス図
82
UMLの振る舞い図の一つで、オブジェクト間の相互作用を、オブジェクト同士の「繋がり（リンク）」を中心に表現した図。
コミュニケーション図
83
UMLの振る舞い図の一つで、ユーザー（アクター）から見たシステムの機能と、ユーザーとシステムとのやり取りを表現した図。
ユースケース図
84
UMLの振る舞い図の一つで、1つのオブジェクトがイベントによってどのように状態を変えていくか（状態遷移）を表現した図。
ステートマシン図
85
UMLの振る舞い図の一つで、一連の処理の流れや条件分岐、並行処理などをフローチャートのように表現した図。
アクティビティ図
86
システムやプログラムを、独立性が高く管理しやすい小さな部品（モジュール）に分割するための設計技法。
モジュール分割技法
87
プログラムのデータフローを「源泉(Source)」「変換(Transform)」「吸収(Sink)」の3つの部分に分割する技法。
STS分割
88
データフローにおいて、処理の種類やトランザクションの種別ごとにモジュールを分割する技法（トランザクション分割）。
TR分割
89
複数のモジュールで共通して利用される処理を見つけ出し、独立した1つのモジュールとしてくくり出す技法。
共通機能分割
90
ログ出力やセキュリティなど、プログラムのあちこちに散らばる「横断的な関心事」を分離してモジュール化する手法。
アスペクト指向プログラミング
91
入力データと出力データの「データ構造（階層構造）」に着目し、その構造に合わせてプログラムの構造を設計する手法。
ジャクソン法
92
入力データを「順次・選択・繰り返し」の論理構造で分析し、それに対応するようにプログラムの制御構造を設計する手法。
ワーニエ法
93
モジュール分割において、各モジュールが他のモジュールにどれだけ依存せず、単独で機能できるかを示す度合い。結合度が弱く、強度が強いほど独立性が高い。
独立性
94
モジュール同士の結びつきの強さを示す指標。結合度が弱い（疎結合）ほど、モジュール間の影響が少なく良い設計とされる。
モジュール結合度
95
最も悪い結合度。他のモジュールの内部データを直接参照したり、内部の処理を直接書き換えたりする結合状態。
内容結合
96
2番目に悪い結合度。複数のモジュールが、グローバル変数などの共通データ領域を直接参照・共有している結合状態。
共通結合
97
3番目に悪い結合度。複数のモジュールが、外部で宣言された単一の変数（外部変数）を共有している結合状態。
外部結合
98
普通の結合度。呼び出し元のモジュールが、呼び出し先の処理手順を指示するフラグ（制御パラメータ）を引数として渡す結合状態。
制御結合
99
良い結合度。実行に不要なデータも含んだ配列やレコード（データ構造）を引数として受け渡す結合状態。
スタンプ結合
100
最も良い結合度。モジュール間で、処理に必要な単一のデータ項目（変数）だけを引数として受け渡す結合状態。
データ結合