ソフトウェア工学とは、ソフトウェアの①に、②~④可能なアプローチを適用すること。すなわきソフトウェアに工学を適用すること。

ソフトウェア危機の際に起きたブルックスの法則とは？

構造化定理とは、任意の一入力、一出力関数は、①~③の3つのみからなる関数と等価であるという定理。

・ソフトウェア開発の際の手順を①という。また、①を一般化したものを①モデルという。 ・ソフトウェアライフサイクルとは、②から運用、保守、③に至るまでの過程である。

開発にはいくつか種類がある。 ①:一つ一つの開発工程を完了させて進める ②:①を実装工程と単体テストの部分で折り返し、上流と下流を対応付けたモデル ③:②からテスト工程を省いたモデル

・反復型モデルとは①からテストまでの期間を繰り返し、②が満足するまで何度か繰り返す開発 また、アジャイルソフトウェア開発とは③の反復型開発

XP(eXreme Programming)の5つの価値とは？

スクラムとは、現在最も人気の高い①開発。少人数のチームに別れて短期間の開発サイクルを繰り返し行うフレームワーク。 また、DevOpsとは②と③を同時並行的に行う

ソフトウェア開発手法とは、顧客から①し、それを②して最終的にプログラムコードに落とし込んでいくための大きな枠組み。③とも呼ぶ。

構造化設計は、①を高めてできるだけ1つのモジュールにまとめることと、②を弱めて互いに依存している部分が小さいことが重要

・データ抽象とは、インタフェースである①によりデータを抽象化する考え方 ・抽象データ型とは、データ抽象をプログラミングにおける型の②まで引き上げたもの。コンパイラで違反を検出できる

オブジェクト指向プログラミングは、①の発展形であり、クラスや継承など②を提供する

・オブジェクト指向プログラミングの枠組みでは、そのためのコード記述が複数のクラスやメソッドに散らばってしまうようなことを①という。 ・①をアスペクトという概念を用いてモジュール化する技術を②という

・モデリングとは、システムあるいはプロセスの①をつかみ、それを適切に②し、③に表現すること。 ・④とはOMGから提供されているモデリング表記の世界基準

ダイアグラムには構造、振る舞い、相互作用の3種がある。 ・構造:大きい順に①、コンポーネント図、パッケージ図、クラス、② ・振る舞いには③図などがある ・相互作用には④図などがある

・システムエンジニアとは顧客と開発エンジニアの間に立ち、①をメインの業務とするエンジニア ・要求工学とは、顧客から要求を的確に獲得し、それを②として記述するための技術分野

・①とは問題自体を分析するための手法 ・要求獲得の手法には②、③、業務フロー分析や調査を行う

・①とは抽出した要求機能を、UMLを構成するダイアグラムの一つであるユースケース図を用いて記述する ・関係とは②と③、②同士③同士の結びつき ・④(システム境界)は境界を明確化するためにユースケース郡を囲む枠線

・ユースケース記述とは①でユースケースの内容を補助する記述 ・②は、システムにとって害となるユースやアクターを抽出すること ・③の推奨規約はIEEE Std.830 ・④とは顧客のビジネス上の成功をゴールに設定し、それを達成するための要素をサブゴールとして展開していく分析方法

・ソフトウェア分析とは、抽象した要求に①や漏れがないか②と照らし合わせながら確認し、必要なら見直しを実施すること ・オブジェクト指向とはオブジェクト間の③でもって、現実世界を表現する ・オブジェクトの種類は人や役割、④やシステム、機会やインターフェースなどに分けられる ・構造モデリングとは、クラス図を用いて表現し、現実世界を⑤からモデリングする

クラス図の要素 ・①:クラスが持つ性質を示すデータ。名前:型の形で表される ・③:クラスが提供する振る舞いや機能。名前(引数の名前:型):型の形で表される ・⑤:クラス同士の数量的な対応

・振る舞いモデリングとは、現実世界のオブジェクト郡の①をモデリングする。シーケンス図やステートマシン図を用いる ・②分析は、ユースケースと概念的なクラス図から②図を作成する。画面などアクターとのインターフェースである③、データや情報の④、処理や機能の⑤がある。

・アーキテクチャ中心設計とは、①を中核に置く開発方法 。 ・②:優れたアーキテクチャ（設計する過程をパターン化させたもの。例)POSA ・③:今までに蓄積されてきたノウハウの中でも特に優れたものをカタログ化。例)Gof ・モデル駆動開発とは、ソフトウェア開発を④から下位モデルへの変換プロセスと考え、最終的にプログラムコードに変換する ・モデルコンパイラとは⑤から⑥への変換器

・再利用可能なアプリケーションの枠組みを①という。ホットスポット(公開されている拡張可能な部分)とフローズンスポット(ホットスポット以外の部分) ・製品系列の考えをソフトウェア開発に応用したものを②という

・①はソフトウェアが正しく動作するか確かめること ・②はプログラムへの入力ケースと正しい出力ケースの組み合わせのこと。いかに少ない数のケースでより多くのバグを検出するか ・③はソフトウェアが要求仕様を満たしているかを確認する

機能テストの種類 ・①:ソフトウェアの中身を一切関知せずにテストケースが満たされるかを確認する ・②:プログラムの中身、制御構造に沿ってテストを行う

・どのくらい実行経路をテストが通過したかを表す指標を①という。 C0は全ての②を実行した場合の網羅率100% C1は③の全ての組み合わせ C2はC1で考慮しなかった&やorを考慮する MC/DCは④ともいう。

・①は、具体的なテスト入力値を用いた動的実行と②を組み合わせたもの ・②は、変数をシンボルとして扱い、それに対する代入や参照を解析することで条件を満たす入力値を求める。 ・単体テストとは③ごとに実施する ・結合テストとは全ての④したものが本当に正しく動作するか確認する ・システムテストは⑤において、予定した性能が出るか、使い勝手が満足するレベルかを確認するテスト ・⑥(回帰テスト)はソフトウェアの品質が後戻りしていないか確認する ・テストの種類が多い理由は、品質の最後の砦だから

・①は入力集合を同値クラス(ソフトウェアの動作が同じと見なせる)に分けること ・正常なら②、エラーなら③に分ける ・④は同値クラス間の境界値のテストケースを抽出すること

例外テストの方法 ・FTAまたは①:発生が好ましくない故障を取り上げて木のルートに据え、発生経路や原因、発生確率を木を展開しながら解析するトップダウン方式 ・②:設計の潜在的な欠陥をボトムアップで見つける ・③:潜在的なハザードの特定に抜けや漏れがないようガイドワークを用いてリスク分析する

・①:対象プログラムの一部を機械的に書き換えて(ミューテーション操作)、人工的にバグを含むプログラム(ミュータント)を生成する ・②:組み合わせのペアのみを網羅するようにテストケースの項目数を絞る手法 ・③:先にテストを行うためのコードを書き、その後テストが通過するようにプログラム本体を開発する ・④:テスト対象のプログラムの出力結果と比較することが出来る正解の求め方

・①は硬いソフトウェアを開発するための数学ベースのアプローチ ・硬いソフトウェアとは、鉄道運行システムや宇宙航空システムなど②が求められるソフトウェアがある。 ①の構成 ・③:数学を用いて厳密に仕様を記述する ・④:ソフトウェアの正しさを数学的に示す

形式的仕様記述の種類 ・①:集合関数論理などの数学的概念を用いてソフトウェアの仕様をモデルとして記述する。VDMやZ言語など ・②:開発対象のソフトウェアが持つ性質に基づいて仕様を記述する。OBJやCafeOBJなど

形式検証にはシステム検証とプログラム検証がある ・①:ある性質を与えたとき対象となる構造がその性質を満たすかどうかを形式的に調べる。 ②という到達可能な状態をノード、状態遷移をエッジ、ノードからその状態で成立する性質の集合とする遷移系をもつ ③はモデル検査器が示す、時相論理式が成り立たない例 ・④:プログラムの正当性が論理的に証明できるように一階述語論理を拡張したもの。仕様は事前条件と事後条件で記述できる。

プログラムの正当性 ・①:プログラムSを事前条件Pが成立する時、実行した際に停止するならば事後条件Qが成立する。{P}S{Q} ・②:プログラムSを事前条件Pが成立する時、実行した際に停止し、事後条件Qが成立する。［P］S［Q］

・①:モジュールの利用者と供給者の間の契約を供給者のプログラムコード中に、事前条件、事後条件、不変条件として記述する方法 利用者:呼び出す側 利用者:呼び出される側 不変条件:クラスが持つ公開された各メソッドの開始時と正常終了時に共通して保証されるべき条件

・①:ソフトウェアのバグを修正したり、将来のことを考慮してプログラムの構造を見直したりすること。ソフトウェア発展やソフトウェア進化ともいう

レーマンによる分類 ・S型:問題と仕様を①的に定義できるソフトウェア ・P型:問題は明確に定義できるが、②としての仕様しか定義できない ・E型:③システムに組み込まれ、その一部として機能する。E型は寿命が長く、④や⑤が重要な役目を果たす

ソフトウェア保守の分類 ・①:リリース後に発見されたバグを修正 ・②:リリース後の環境変化に対応させて修正 ・③:リリース後の性能や保守性の改善を目的とする ・④:欠陥が顕在化する前に修正

デバッグ支援技術 ・①:他のプログラムをテストしたりデバッグする際に用いられるコンピュータプログラム。 主な機能は、柔軟な実行(②インや②アウト)、条件を満たした時点で停止する点(③) ・④:エンジニア間でのWhy/Whynotの形をしたQ&Aの連鎖でバグを見つける ・⑤:テストにパスするプログラムは正しいという考えのもと、自動的にバグを修正する技術

バグ位置の特定手法:① プログラム実行し、テストに合格の場合と不合格の場合のステートメントを比較して、後者の割合が高い方をバグと予測する パッチ生成方法:② バグを含むプログラムとテストスイートを入力し、プログラムを変異させながらテストケースが全て通るようなプログラムを得る

プログラム解析 ・コントロールフロー解析:プログラムの①を解析 ・②:変数への値の代入や参照を解析 ・③:あるステートメントに関連するプログラム片のみを切り出す技術 ・④:ある修正がプログラム中のどの箇所に影響するのかを解析し、その結果をエンジニアに提示する ・⑤:変数をシンボルとして扱うと共にそれに対する代入や参照を解析することで、条件を満たす入力値を求める ・⑥:プログラムの潜在的な欠陥を検出する手法

・①:ソフトウェアの外部的な振る舞いを保ったまま内部の構造を改善していく作業 ・②:ソフトウェアの中に人間の操作履歴などの情報を収集するプログラムを埋め込み、時間経過で人間行動がどのように変化しているかを監視する仕組み

・①:製品としてのソフトウェアそのものに対する品質 ①の種類 ・②:横軸にテスト実施日、縦軸にその日までに発見したバグの累積数をプロットしたもの ・③:②を何らかの数式でモデル化 ・内部品質:ソフトウェアの中身が適正に作られているかどうかを見る側面 ・④:バグが出尽くした使い勝手に問題は無いという側面

ソフトウェア製品の品質モデル ①:要求された機能を提供しているか ②:性能は適切か ③:共存性や相互運用性は保たれているか ④:使い勝手や習得は容易か ⑤:動作は信頼出来る？ ⑥:機密性は保たれている？ ⑦:保守、改良は容易か？ ⑧:容易に別の環境に移して利用できる？

狩野モデル:顧客の要求品質をその要求度によって区分する ①:バグがないなど、顧客から見て達成出来て当たり前のこと ②:不十分だと不満があり、充足されると満足 ③:使い勝手がいい、デザインが格好良いといった魅力

①:ソフトウェアを開発するプロセスが適切であるかどうかを見る ②:ソフトウェア開発能力を組織的に改善する ③:ある成果物の作者または作者以外が内容を確認すること レビュー方法 ・④:成果物の作者がレビュアーを募り、内容を説明する ・⑤:別の第三者が事前に定められた手順とチェックリストに従ってプログラムコードなどの精査を行う

①:ソフトウェア品質を定量的に評価する方法や基準 ②:製品としてのソフトウェア構成物から収集したデータから算出する指標 ③のソフトウェアサイエンス:オペレーター(演算子)とオペランド(変数や定数)の種類数と出現数からソフトウェアの規模や開発工数を予測 ④メトリクス:オブジェクト指向プログラム（対象としたソフトウェアメトリクス ⑤メトリクス:ソフトウェア開発活動から収集したデータから算出する指標 ⑥:ある対象項目に関する任意のメトリクスをトップダウン方式で決定するための技法 ⑦:リポジトリに格納されたプログラムの変更履歴やバグ修正履歴など、大量の開発データを分析し、開発運用保守に役立つ知見を抽出すること

①:プロジェクトを円滑に進めるために予算、スケジュール、品質などを適切に管理すること。 ②:独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務

予算管理:プロジェクトに与えられた予算とある時点までに使用したコストを管理する ①:プログラムコードの予想行数にソフトウェア規模の大小を表す係数をかけることで開発工数を見積もる ②:開発予定のソフトウェアが持つ機能の数に基づいて開発工数を見積る

計画策定:プロジェクトの開始時期と終了時期、途中のマイルストーンなどを定める ①:プロジェクトの仕事を細かく個々の作業単位にまで発展したもの

進捗管理:節目でプロジェクトが予定通り進んでいるかを確認すること ①:プロジェクトの進捗を視覚的に表現する ②:チケットを用いて管理する開発スタイル ③:プロジェクトの進捗のコストに換算して管理する

ソフトウェア開発の流れとその支援技術を書け 1 →ソフトウェア2 →ソフトウェア3 →プログラム4 →ソフトウェア5 →ソフトウェア6 支援技術3つ

ソフトウェア工学の誕生は何年の何会議？ ①年 ②会議

世界初のコンピュータは何年のENIAC