ずっと受けたかったソフトウェアエンジニアリングの授業〈１〉 ...第2章を読んでみた

第２章　ソフトウェア開発におけるプロセス（プロセスとは；ソフトウェア開発におけるプロセス　ほか）

①内容まとめ

企業活動はプロセスの集合体であり、そのプロセスに沿った要求や課題があり、変化に対する不断の適応能力が試されている。

ソフトウェア開発においてもそれは同じで、プロセスの策定と改善は良いプロダクトを作る上で大変重要なものである。

これを達成するために様々な開発モデルがある

②認識のズレ、印象

アジャイルはその成立の背景からウォーターフォールと対極の位置にあり、関連性や補完性は全くないと思っていた。何なら喧嘩してる？アジャイルによってウォーターフォールは駆逐される？傾向にあると思っていた

しかし、実際はそれぞれ独立した規律である。

すなわち、ウォーターフォールは人間の合理性に着目した成果物中心の規律であり、アジャイルは、人間の弱さに着目したプロセス中心の規律である。

③不明ワード

【BPM】（p51）

Business Process Managementの略。

業務プロセスのPDCAサイクルを回して業務の成果を上げること。現場の実態に即した仕事のやり方を可視化し、自ら設計・適用・評価しながら継続的に改善してゆくこと

【ソフトウェアライフサイクル】（p58）

要求が発生してからソフトウェアが作成され運用されるまでの課程の繰り返しのこと

【ウォーターフォールモデル】（p59）

一つのプロセスを完了してから次のプロセスに行く開発モデル。

進捗管理が容易で作業分担がしやすく教育に向くが、手戻りが発生する課題がある。

(※手戻りというのはきちんと計画が立てられていないことに起因する事象であり、それはスコープ管理の柔軟さに依存する部分で、ウォーターフォールかアジャイルかの違いによるものではない)

【プロトタイピング】（p64）

ウォーターフォールの早い時期に、UIだけ先に作って顧客との認識のズレをなくしつつ開発するモデル。なお、作成したプロトタイプは捨てる。

（※プロトタイプを捨てない場合で有効に使う場合は「曳光弾」という）

【インクリメンタルモデル】(p64)

漸増的な開発モデル。優先度の高い機能から順番に作る開発モデル

【イテレーティブモデル】(p64)

反復的な開発モデル。リリース後も部分的に追加や修正を行う開発モデル

【スパイラルモデル】(p64)

開発プロセスを「計画」「目標・対策・制約決定」「評価・分析」「開発・検証」に分け、4つの区域を経てブラッシュアップ、それを何周も行う開発モデル

【アジャイル開発手法】(p66)

現代の曖昧で困難なビジネス環境の変化に対応するために生まれた開発手法。

イテレーティブモデルのサイクルをもっと短くしており、アジャイル開発宣言に見られるように、顧客の要求が頻繁に変わるという予測不能な困難に対する手法が盛り込まれている

【銀の弾丸】(p69)

困難を解決する決め手、万能薬。「銀の弾丸はない」という文脈上で用いられる。

【システムアーキテクチャ】(p73)

システムに求められることを効率よく行っていくために必要な機能や相互データの更新を定める枠組みのこと

【ミドルウェア】(p73)

OSと特定の業務に特化したアプリケーションとの、中間に位置するソフトウェアのこと。Webサーバ、アプリケーションサーバ、データベース管理サーバなどがある。

ミドルウェアが提供するAPIを使ってプログラムを開発すると、OSやハードウェアとアプリケーションの違いをミドルウェアが吸収するので、アプリケーションの互換性が高まる

【システム信頼性】(p73)

システムの信頼性を数値的に評価する基準として、MTBFやMTTR、稼働率がある。

→【MTBF（Mean Time Between Failure：平均故障間隔）】
故障から次の故障までの時間の平均値。システムが正常に稼働していた時期を指す。

→【MTTR（Mean Time To Repair：平均修復時間）】
修理にかかる時間の平均値。システムが停止していた時期を指す。
※全稼働時間を「MTBF＋MTTR」とし、全稼働時間のうち正常に稼働した時間（MTBF）の割合を稼働率として求める。

【ソフトウェアアーキテクチャ】(p73)

ソフトウェア開発におけるアーキテクチャ。

すなわち、特定の目的を叶えるために、ソフトウェアに「最適な構造（偏り）」を付与すること

たとえば、「変更容易性」を重視するなら、テストしやすい構造を導入することでシステムの破損を防止したり、

コードを直接書かない、もしくは書いても詳述しない構造を導入することがそれにあたる

それにより、「変更容易性」は最適化されるが、たとえば「開発効率」が低下する等といった不都合が起こることもある

このように、「目的」の部分が変わったときは、元の目的のために最適化したことで、新しい目的にとってはマイナスやデメリットになることもある

これが「偏り」と表現した部分であり、別「重力場」とも表現される。

……なるほど！偏りかぁ！！

→【アーキテクチャ】コンポーネントと、コンポーネント間および環境との「関係」、またその設計と進化の指針となる原理に体現された「システムの基本構造」

【バッチプログラム構造】(p73)

一括処理を行うプログラムの構造。複数の処理がまとまってカプセル化している。

バッチとは元々メインフレームの時代にデータを一々処理するのは非効率なので、ある程度まとまったデータ量を一括処理していた頃の名残。

対義語はリアルタイム処理。

例：日々の帳票入力がリアルタイム処理、月締処理がバッチ処理。

【共通ライブラリ】(p73)

部品化されたプログラムの集合であるライブラリの一種で、複数のプログラムから共有・共用されるもの

【ValidationとVerificationの違い】(p73)

Validationは仕様が課題に対して正しいかどうかの検証

Verlificationの違いは設計が仕様に対して間違いなく実装できているかの検証