-
ソフトウェアライフサイクルPlan, Do, Seeの三つのフェーズに関する計画
-
ウォーターフォールモデルソフトウェアに対して、工程順に開発を進める開発手法。工程間の平衡作業ができない
-
プロトタイプモデル開発の早い段階で作成したプロトタイプをユーザーに試してもらい、ユーザーの要求に合うように修正を繰り返しながら開発する手法
-
スパイラルモデル対象システムを独立性の高いいくつかの部分に分割し、部分ごとに一連の開発工程を繰り返しながら、徐々にシステムの完成度を高めていく手法。小規模開発を先行させ、その評価を皇族の開発に生かすことで開発コスト増加などのリスクを最小にしつつ開発を行う
-
インクリメンタルモデル定義された要求を全部一度に実現するのではなく、いくつかの部分に分けて、順次、段階的に開発し提供していくモデル。例えば最初にコア部分を開発し、順次機能を追加していく場合に適している。
-
進化的モデルシステムへの要求に不明確な部分があったり、要求変更の可能性が高いことを前提としたモデル
-
アジャイル開発ソフトウェアに対する要求の変化やビジネス目標の変化に迅速かつ柔軟に対応できるよう、短い期間単位で、計画、実行、評価を繰り返す反復（イテレーション）型の開発手法。
-
スクラムアジャイル開発のアプローチの一つ。開発チームに適用されるプロダクト管理のフレームワーク。反復の単位をスプリントと呼ぶ
-
スプリントプランニングスプリントの開始に先立って行われるミーティング。プロダクトバックログの中からプロダクトオーナが順位に従って、見積もりを行う
-
デイリースクラム朝会のように、毎日決まった場所。時刻で行う短いミーティング
-
スプリントレビュースプリントの最後に成果物をデモンストレーションし、リリースの可否をプロダクトオーナが判断する
-
スプリントレトロスペクティブスプリントの振り返りを実施し、次のスプリントに向けての改善を図る
-
プロダクトバックログ今後のリリースで実装するプロダクトの機能をユーザーストーリー形式で記述したリスト
-
XPeXtreme Programming：アジャイル開発における手法やマネジメントの経験則をまとめたもの。対象者である「共同、開発、管理者、顧客」の四つの立場ごとに全部で19の具体的な実践手法が定義されている
-
ペアプログラミング2人のプログラマがペアとなり、その場で相談したりレビューしながら一つのプログラム開発を行う
-
テスト駆動開発最初にテストケースを設計し、必要最低限の実装を行った後、コードを洗練させる
-
リファクタリング完成済みのプログラムも随時相良し、保守性の高いプログラムに書き直す
-
継続的インテグレーションコードの結合とテストを継続的に繰り返す
-
YAGNIYou Aren't Going to Need it：今必要なことだけをする。将来を見据えた機能の追加を避ける
-
リーンソフトウェア開発製造業の現場から生まれた無駄のない生産方式の考え方をソフトウェアに適用した開発手法
-
プラットフォーム開発組み込み機器の設計・開発において、複数の異なる機器に共通して利用できる部分を最初に設計・開発し、それを土台として機器ごとに異なる機能を開発する
-
MDAモデル駆動型アーキテクチャ：システムをプラットフォームに依存する部分と依存しない部分とに分けてモデル化する
-
コンカレントエンジニアリング同時実行が可能な工程を平衡して進めることで、開発期間の短縮を図ること
-
コデザイン開発の早期にハードウェアとソフトウェアを同時に設計すること
-
リエンジニアリング既存のソフトウェアを利用して新しいソフトウェアを作製するための技術
-
リバースエンジニアリング既存のソフトウェアからそのソフトウェアの仕様を持ちびき出す技術
-
フォワードエンジニアリング新規ソフトウェアに合うように修正・変更し、それを基に新規ソフトウェアを構築する
-
V字モデル設計とテストとを対応させたもの
-
CMMIW.ハンフリーによって提唱。能力成熟度モデル結合と呼ばれ、ソフトウェアを開発・保守する組織の作業の在り方を示したモデル。5段階で管理される
-
構造化分析法SA：システム機能間のデータの流れに注目して、開発の対象となるシステムの要求を仕様化する技法
-
DFD業務を構成する処理と、その間で受け渡されるデータの流れを3つの要素（プロセス、源泉と吸収、データストア）及び、データフローを用いて図式表現したもの
-
コンテキストダイアグラム一つだけのプロセスが記述された最上位のDFD
-
DFDの作成順現物理モデル→現論理モデル→新論理モデル→新物理モデル
-
データディクショナリ（データ辞書）階層化された全てのDFD中にある、データフローで示されたデータと、データストアを構成するデータ内容を定義したもの
-
ミニスペック（ミニ仕様書）最終的に詳細化された基本的なプロセス、再開のDFDの機能仕様書
-
プロセス中心設計データの設計に先行してプロセスを設計士、プロセスに合わせて必要なデータを設計する手法
-
データ中心設計データ設計を先行して行う手法
-
CRUDマトリクスデータがどのプロセスによって、Create, Read, Update, Deleteされるかをマトリクス形式で表した図
-
事象応答分析外部型の事象とその事象に応答するタイミングなどを時間的な関係の抽出を行い、制御の流れを分析すること
-
状態遷移図時間の経過や状況の変化に応じて状態が変わるようなシステムの動作を記述するときに用いられる図式化技法
-
ペトリネット図平衡動作する機能同士の同期を表現することができる図式化技法。トランジション（事象）とプレース（状態）によって表現し、トークン（印）の推移と発火によって記述される
-
システム開発プロジェクトのライフサイクルこ
-
カプセル化データとそれを操作する手続きを一体化して、オブジェクトの実装の詳細をオブジェクトの内部に隠ぺいすることを
-
クラスいくつかの類似オブジェクトに共通する性質を抜き出し、属性やメソッドを一般化して新たに定義したもの。
-
インスタンスクラスの使用宣言をしてはじめて実体が生成され、その実態のこと（具体的な値を持ったオブジェクト）
-
インヘリタンス上位クラスの属性やメソッドを下位クラスが継承すること
-
is-a関係汎化ー特化関係：動物と人間、犬など
-
part-of関係集約－分解関係：車とタイヤ、エンジン、ボディなど
-
ポリモーフィズム同じメッセージを送ってもオブジェクトごとに異なる動作が行われる特性
-
オーバーロード同一クラス内に、メソッドが同一であって、引数の型、個数または並び順が異なる複数のメソッドを定義すること
-
UMLUnified Modeling Language：オブジェクト指向分析・設計で用いられるモデリング言語
-
クラス図（システム領域に存在するクラスとの関連を表す図）
-
シーケンス図（オブジェクト間の相互作用を時間軸に沿って表す図）
-
ユースケース図機能（ユースケース）と利用者（アクタ）との相互作用を表す
-
ステートマシン図オブジェクトの状態遷移の図
-
アクティビティ図システムやユースケースの動作の流れを表す
-
データの流れに着目したモジュール分割技法（3つ）STS分割、TR分割、共通機能分割
-
データの構造に着目した分割技法（2つ）ジャクソン法、ワーニエ法
-
STS分割Source, Translate, Sink, （源泉、変換、吸収）の三つのモジュールに分解
-
最大抽象入力点入力とは言えない点まで抽象化された地点
-
最大抽象出力点はじめて出力データといえる形をあた和下天
-
TR分割トランザクション分割：入力トランザクションの種類により、実行する処理が異なる場合には有効な分割技法。
-
TR分割におけるプログラムの３つの分割トランザクションを、入力するモジュール、属性ごとに振り分けるモジュール、処理モジュール
-
ジャクソン法
-
ワーニエ法
-
モジュール結合の６つの種類（強い順）内容結合＞共通結合＞外部結合＞制御結合＞スタンプ結合＞データ結合
-
データ結合相手モジュールをブラックボックスとして扱い、必要なデータだけを引数として渡す
-
モジュール強度（モジュール内の構成要素間の関連性の強さ：強い順）暗号的強度＞論理的強度＞時間的強度＞手順的強度＞連絡的強度＞情報的強度＞機能的強度
-
コード設計
-
ブラックボックステストプログラムの内部構造や論理構造には一切着目せず、プログラムの外部使用に基づくテストケースを作製し、正しい出力が得られるかどうかに着網したテスト
-
同値分析テスト対象となる、プログラムへの入力データを、同じ特性を持つい来るかのクラスに分割し、各クラスを代表する値をテストデータとする方法
-
限界値分析それぞれのクラスの境界値をデータとして設定する。
-
原因結果グラフ
-
実験計画法検証項目の組み合わせによるテストケースの数が膨大になる場合に有効なテストケース設計法。直交表を用いる
-
ホワイトボックステストプログラムの内部論理の正当性の検証を行うテスト
-
命令網羅全ての命令を少なくとも一回は実行するようにテストケースを設計
-
判定条件網羅結果が真になる場合と偽になる場合の両方がテストされるようにテストケースを設計
-
条件網羅判定条件が複数条件である場合に採用する方法。
-
複数条件網羅判定条件を構成する各条件の起こりうる真と偽の組み合わせと、それに伴う判定条件を網羅する
-
制御パステストプログラムの処理経路を網羅的に実行し、正しく動作しているかを検証
-
フローグラフプログラムを連続した逐次命令群と、分岐命令に分け、それぞれをノードとして処理の順にノードを結んだもの
-
サイクロマチック数フローグラフから得られるすべての経路の数（N=E-V+2）
-
モジュール集積テスト技法増加テストと非増加テストがある。結合テストを進めるための技法
-
増加テストボトムアップテストとトップダウンテスト、折衷テストがある
-
ボトムアップテスト下位のモジュールから上位のモジュールへと順にモジュールを結合しながらテストを行う。未完成の上位モジュールの代わりにドライバを用いる
-
トップダウンテストボトムアップテストの逆。未完成の下位モジュールの代わりに、スタブを用いる
-
デシジョンテーブル
-
その他のテスト種類
-
α：テスト初期でバグが発生→プログラムの質が悪い。β：テストの中盤でもバグがない→テストの質が悪い。解決困難なバグに直面した -
信頼度成長曲線横軸にテスト時間、あるいはテスト消化件数をとり、縦軸にはバグの累積個数をとったもの
-
バグ埋め込み法あたかじめ既知のバグをプログラムに埋め込んで、その存在を知らない検査グループがテストを行い、洗剤バグ数を推定
-
二段階エディット法完全に独立した二つのテストグループが、テストケースやテストデータをそれぞれのグループで用意し、一定時間平衡してテストを行う
-
レビュー成果物の問題点やあいまいな点、あるいは成果物としての妥当性を検証
-
承認レビュー成果物の内容を審査してのレビュー
-
成果物レビュー成果物の問題点を早期に発見し、品質向上を図る
-
ウォークスルーレビュー対象物の作成者が説明者になり行われるレビュー
-
ピアレビュー同僚や専門家仲間と行う
-
IV＆VIndependent Verification and Validation：ソフトウェア開発組織や開発委託組織から独立した組織の指導と管理に基づいて、V&Vを実施すること。そのV&Vを主導する組織をいう場合もある。 システムやソフトウェアの品質保証を行うことを考えたとき、開発を行った当事者がいくらテストやレビューを行ってもそれが組織内部の活動である限り、客観的な証拠にはならない。IV&Vは、開発組織とは技術面・管理面・財政面で独立した組織がV&V活動の作業や方法を定め、開発組織に義務付けることによってV&V活動の客観性を保証することをいう
-
インスペクション作業成果物の作成者以外の参加者がモデレータとして会議の進行を取り仕切り行われるレビュー
-
ラウンドロビンレビュー参加者が持ち回りでレビュー責任者を務めながら、全体としてレビューを遂行していくレビュー技法
-
バスアラウンドレビュー対象となる成果物を複数のレビュアーに個別にレビューしてもらう方法
-
デザインレビュー検証対象である成果物が設計仕様書であるレビュー
-
形式手法論理学や離散数学を基礎とした形式的な仕様記述とモデル検証によって品質を確保しようとするもの
ログイン
オンライン単語帳
このページを利用するにはログインする必要があります。ログインするとAnkilotをより便利にご利用いただけます。