ソフトウェア工学

情報システムは、人・機械・コンピュータなどから構成され、お互いに協調してある目的 を達成する仕組み全体のことである。, 情報処理システムは、情報システムの中にあって、コンピュータから構成されるている仕組 みのことである。

情報システム, 組込みシステム

行政・企業・個人など幅広く用いられ、人間の業務を支えるものである。

物理現象に働きかけるシステムで、機器に「組み込まれた」コンピュータシステムである。

ソフトウェアとは、コンピュータに仕事をさせるために必要なプログラム、データ、関連するドキュメント等であり、プログラムだけのことを指すわけではない。

ソフトウェアの良し悪しは、プロジェクトの成否とも言える。, つまり、QCD（品質、コスト、納期）が満たされたものであることが重要である, たとえば、「Q と C」のために D を捨てるなどは良くはない。

上流工程で不具合が作られた場合、その不具合が見つかるのは下流工程であることが多い。, もし、下流工程で不具合が見つかった場合、手戻りを行い、不具合が作られた工程までさかのぼる必要があり、工数が増加する。

ソフトウェア規模の増大によって間接的な作業である管理業務の、重要性や比重が高まる。, つまり、コミュニケーション力、調整力が、さらに求められるようになる。

ビジネスの変化、プラットフォームの変化（OS やハードウェア面など）によって、ソフトウェアは対応が必要である。, しかし、工数を低減したいため、ソフトウェアの再利用を行いたい。また、できるだけ「動いている部分」を変更せず使いたい。

データとは、事実、概念、指示の表現である。 情報とは、データを評価して得ることのできる意味であり、人間によってデータに何かしらの意味を与えられたものである。

まず、「ソフトウェアの動作は離散的である。」ことがある。飛び飛びの値しか表現できず、 飛び 飛びのタイミングでしか実行できない。, 次に、「インタリーブして動作する。」ことがあ る。OS は、見かけ上同時にプログラムが動 いて いるように見せるが、実際には実行するプログラムを切り替えながら動作する。人間 が必ずしもタ イミングを決定することができない。, 最後に、「最終的に機械語で実行される。」こと がある。-インタリーブするのも機械語単位 で ソースコードと必ずしも対応しない。

まず、いずれも複数台のコンピュータからシステム が構成される。, 前者は、同じ処理を複数台で実行するシステムである（RAID1（ミラーリング）と同じ概念） から、よち故障に強いが、冗長である。, 後者は主系と従系があり、普段は別々の処理を行っているが、故障した場合は主系から従系 に切り 替えて実行を続けるシステムである。前者と比べて 故障に弱いが、効率良い。, なお、これらの差は、「同じ機能を持つコンピュー タが複数あるだけ」か、「普段は違う機 能だが、故 障時は処理を肩代わりできるか」の違いである。

専用ハードウェア：ハードウェアへの依存が強く、移植性が悪い。, イベントドリブン(リアクティブ性)：イベントが生じてから、イベントに対応する処理を実 行する（応答する）ことが多い。, リアルタイム性：定められた時間要件で処理をする性質・遅すぎず早すぎず実行する必要が ある。, 資源の制約：大量生産する場合もあるため、コストをできる だけ抑える、小型軽量化した い、省電力化したい、など様々 な需要があり、これらを考えると、CPU、メモリなどの資源 が限られていることが多い。, 高い信頼性・安全性：長時間連続動作が求められるため、故 障せず要求通りの動作をする こと（高信頼性）が要求される ことや、他の財産（人・モノ・環境など）を傷つけてはな ら ない（安全性）が要求されることがある。

顧客が欲しい物＝要求から、要求仕様書をまとめる工程

機能要求はシアン、イエロー、マゼンタ、ブラックのインクを使って、カラー印刷ができる こと。, 非機能要求は印刷のカスレは、1000 枚印刷以内では生じないように保証すること。

システムによって影響を受ける、またはシステ ムに影響を与えるすべての人、グループ、組織 のことで、システムによって間接的に影響を受 ける人も含まれる。

データとは、事実、概念、指示の表現である。, 情報とは、データを評価して得ることのでき る意味であり、人間によってデータに何かしらの意味を与えられたものである。

データとは、事実、概念、指示の表現である。, 情報とは、データを評価して得ることのできる意味であり、人間によってデータに何かしらの意味を与えられたものである。

ソフトウェアに対する要求を明らかにした上 で、それらがまとめられた文書のことである。, 開発の初めに作成される文書であり、 この文書が基となって今後の開発が進む。, そのため、品質が低いと手戻りによる影響が 大きくなる。, また、作成するうえでの難しさとして、 顧客の専門性、理解度、利益相反、 システム境界、 整理されることによる気づきなどにより、合意を得ることに時間がかかることがある。

まず、要求獲得でステークホルダの要求を獲得する。, 次に、要求分析で獲得した要求事項を整理し、システムに必要な要求を抽出し、矛盾やあい まいさを確認する。, その後、要求仕様化を行い、文書化する。, 最後に、要求の検証を行い、要求仕様書を ステークホルダ間で確認をする。

インタビューは、顧客に（ステークホルダに）質問 をして情報を聞き出す手法で、情報が 未整理の状態 で伝えられるリスクはあるが、柔軟に質問内容を変えることもでき、深掘り していく上では有効である。, アンケートは、顧客に確認項目を書面などで示し、回答させる手法。落ち着いて回答でき、 まとまった 状態で（または確認などが済んだ状態で）回答が得 られるが、深掘りはただち にできない。, ワークショップは、複数のステークホルダで議論をし、議論の中で少人数では気づかない要 求を見つけ出すことが目的である。議論が発散することもあるため、進行役が重要となる。

ステークホルダ間では、必ずしも利害が一致 しないため、全員が納得する要求に落とし込 むことが難しい。, 顧客のほしいものは、できるだけ叶えたほう がソリューションとしてはよいが、開発者の 目線で言えば、開発できもしないシステムを 請け負うことは、後の契約を達成できないこ ととなるため、受け入れられないことがある。, 顧客から得られる金銭や時間等に対して実現 可能な範囲で、可能な限り顧客にとって最も 妥当な問題解決を提案する必要がある。

現実世界やシステムが最終的にこうなって欲しいという意図（＝ゴール）を定義し、サブゴ ールに分割していくことで、システムが達 成しなければならない目標を明らかにしていく分析である。ゴールは、具体例ではなく一 般化されたものであることが多いため、抽象的な場合が多い。

シナリオ分析は、具体的な一連の出来事を時系列 で定義していく（＝シナリオ）ことで、実際のシステムの動作から、必要な要求を抽出していく分 析である。, たとえば、叙述的な分析により文章でシナリオを 書き起こす。この分析だと詳細な状況な どはわか りやすいが、整理されていないため、理解することに時間がかかる。, そこで、ソフトウェアモデル（UML など）や構造的なシナリオ（箇条書きや表の利用）を 行うことで、全体像の把握を簡単にしたり、整理したりすることも有効である。

良い要求仕様とは、ステークホルダにとって不満がなく、イメージと文章が合致しており、 かつステークホルダによって 認識のズレがない要求仕様であり、全員が納得して進められ る要求仕様のことである。また、工程が進んでいったとしても、要求の抜けや漏れがなく、手戻りが生じないことが重要である。 その結果作成された要求仕様書についても、誤解や読みづらさがなく、高い品質の文書であることも重要である。

「要求仕様書」から、「設計書」を作成する 工程で、実装するべきことがすべて書かれた 文書を作成することが目的である。

要求は「何を(what)」であり、設計は「どの ように(how)」である。 また、要求は解決するべき問題であり、 設計は解決するべき問題に対するソリューション（解）であると言える。, つまり、設計と要求の関係は、「ある問題 （要求事項）」を解決するためには、「1 つ以上 の解（設計事項）」が割り当たっていることといえる。

構造化プログラミングは、逐次、分岐、反復を用いてプログラムを書くことである。, 構造化プログラミングによってソースコードの可読性が向上するが、かわりに実行速度の低下やメ モリ使用量の増大が問題になりうる。, しかし、最近のコンパイラの最適化性能や、コン ピュータの高性能化によって、無視できる程度の 差しか生じないことが増えてきているため、 これらの問題を無視できるケースが多い。

モジュール結合度は、モジュール同士の結びつきの強さであり、結びつきが弱ければ弱いほど、つまり、結合度が低いほど望ましい設計である。モジュール同士のつながりが強いということは、モジュールで分けているにもかかわらず、実質はモジュールがうまく分割されていない（結局くっついている）状態ということである。, モジュール間の結びつきの強さは、他モジュールをどのように 利用しようとするかで決まる。データだけを渡すような結びつきは、変数やデータがどこに属しているかがわかりやすく、処理も明確に分割されているため、結合度が弱い。しかし、共有 変数を使うと、変数が利用される範囲を特定しにくくなり、 データが有効な範囲や、変更を行っている箇所の特定が難しく なる。さらに、goto 文を使うともっとも結合度が強くなり、処理がまったく分割できていない状態になる。

外部モジュールから、自モジュールの内部構造を見えなくし、公開された操作のみを許可す る設計である。たとえば すべての変数を public としてアクセスできるようにすると、 意 図しない変数操作が増加するリスクがあり、結局、共有 変数を扱うように変数の値を変更 できるようになる。そのため、アクセスする手段を制限することで、他モジュール から自 モジュールを不正に変更できないようにすることが 必要となる。, また、この効果として、「setter 関数」や「getter 関数」が 使われることが増える。これらの関数は、変数への書き込み（setter）と読み込み（getter）を行うものだが、 単に書き込みや読み込みを行うだけではなく、書き込み時の下限・上限の判定や、形式の変換など、共通で行わなけ ればならない前処理ができるメリットがある。

ポリモーフィズムを実現するための手段で、 スーパークラスのメソッドを継承する時、サブクラスで同じ名前のメソッドを再定義することができる。, オーバライドしたメソッドは、動的にクラス が決まったとしても、そのサブクラスに対応するメソッドを実行することができる。

同名のメソッドで、引数の型が異なるものを 定義することができ、引数の型ごとに実装を切り替えられる機能の こと

モデリングとは、情報システムに関する対象を抽象化し、形式性のある記法で表現する作業 を指す。, 有用性としては 3 つあり、– 基本的な視点や記述方法の提供により、典型的なパターンを 使って、読み手・書き手の双方 に対して共通の視点を与えられる。, 規模や複雑さの軽減により、対象のある側面のみを 注視して理解することが容易になる。 全体像の理解や、特定の部分のみなど、モデルを使う目的にのみ注力できる。, 正確な表現方法の提供により、モデルを書くことに よって、不正確であいまいな部分を見つけられるこ とや、互いの理解の間にずれがあることに気づくことがある。

ある側面・性質を抜き出して把握することで あり、特定の 1 つの「側面」だけ考えることである。

データ結合, スタンプ結合, 制御結合, 外部結合, 共通結合, 内容結合