モダン・ソフトウェアエンジニアリング

著 : Ivar Jacobson、Harold “Bud” Lawson、Pan-Wei Ng、Paul E. McMahon、Michael Goedicke

訳 : 角征典

監修 : 鷲崎弘宣

https://m.media-amazon.com/images/I/61pYeR8bpEL.jpg

Amazon : https://amzn.to/3QRFaBO

主に、国際的な共通基盤 Essence について書かれた書籍

『モダン・ソフトウェアエンジニアリング』という書籍名ではあるが、ソフトウェアエンジニアリング全体というよりは、主に開発におけるプラクティスの言語化を扱っている

nobuoka.icon 書籍名はちょっと誇張が過ぎると思う

とはいえ、プラクティスや手法について言語化するとか、そういう思想は非常に良いと思うので、学ぶことはあった

Ivar Jacobson International のプラクティスライブラリ : https://practicelibrary.ivarjacobson.com/start

内容メモ

1 部ソフトウェアエンジニアリングの本質

1 章プログラミングからソフトウェアエンジニアリングへ

プログラミング、ソフトウェア開発、ソフトウェアエンジニアリング

2 章ソフトウェアエンジニアリングの手法とプラクティス

手法とは、ソフトウェアを開発・維持するときに必要となるすべてのことに対してアドバイスを提供するもの

ミニ手法 = プラクティス

世の中には無数の手法が存在するが、それらは小さなプラクティスの合成にすぎない

プラクティスは再利用可能

ソフトウェアエンジニアリングの歴史

手法に関してパラダイムシフトが起こると過去との断絶が起こる

プラクティスについても再利用がなされず車輪の再発明が多い

SEMAT イニシアティブ

各チームや組織が独自の手法を構築するための基盤となるソフトウェアエンジニアリングの共通基盤 (カーネル) の構築を目指す

2014 年に Object Management Group (OMG) によって Essence が標準化

3 章 Essence の概要

Essence の話

4 章ソフトウェアエンジニアリングの重要な要素を特定する

あらゆるソフトウェア開発に含まれる要素

5 章ソフトウェアエンジニアリングの言語

Essence の言語

プラクティスのエッセンシャル化の方法

1. 要素を特定する

2. 要素間の関連と各要素の概要を下書きする

3. 詳細を追記していく

6 章ソフトウェアエンジニアリングのカーネル

Essence カーネル

7 章理論のふりかえり

ソフトウェアエンジニアリングの理論

合意された統一的な理論はない

「Where's the Theory for Software Engineering?」という論文

Tarpit 理論

2 部 Essence を使ったソフトウェア開発

9 章 Essence で開発を始める

チェックポイントを設定する

どういうチェックポイント？そのチェックポイントで検査するアルファはどれか？通過条件となるアルファの状態は？

サブアルファ

例 : 要求項目、欠陥、課題

10 章 Essence を使った開発

Essence を使って反復型開発の手法を確立する

継続的な PDCA

11 章開発の旅

累積フロー図

12 章 Essence カーネルのふりかえり

各アルファは各領域の理論に基づく

チームについてはタックマンモデル

ステークホルダーについてはステークホルダーエンゲージメントの各種業績

アルファは個別のものだが、独立していない (同じ開発プロセスを異なる視点で見ている) ので、ウェーブ上に進む

3 部プラクティスを使った小規模開発

13 章プラクティスを使って開発を進める

ソフトウェア開発をするにはスクラムだけでは不十分

適切な要求を考え、それらを設計、実装、テストするプラクティスが必要

要求プラクティスとしてユーザーストーリーやユースケース

ソフトウェアシステムを進化させるプラクティスとしてマイクロサービス

プラクティスを適用すると、具体的な監視項目 (どのアルファ・サブアルファを監視するか？) が明確になる

14 章スクラムを利用する

Essence によるスクラムの表現

15 章ユーザーストーリーライトを利用する

Essence によるユーザーストーリーの表現

16 章ユースケースライトを利用する

ユースケース、ユースケース駆動開発

17 章マイクロサービスを利用する

マイクロサービス

Unified Modeling Language (UML) での表記

18 章プラクティスを合成する

4 部大規模で複雑な開発

19 章スケールの意味

20 章プラクティスのエッセンシャル化

プラクティスアーキテクチャ

21 章大規模で複雑な開発にスケールアップ

ここでの大規模は 30 人以上が関与する開発 (30 人に強い意味があるわけではない)

成功の秘訣は、サブシステムとチームの依存関係を減らすこと

過去にはコンピュータが高価だったため、高速なプロトタイピングに適した環境ではなかった → CMMI や RUP

現在はコンピュータがより安価に → DAD、LeSS、SAFe などの大規模アジャイル開発手法が登場

22 章

プラクティスアーキテクチャからメソッドアーキテクチャ (手法のアーキテクチャ) へ

組織でのプラクティスライブラリの構築

文化は重要

「文化は戦略を食らう」という格言もある (ピーター・F・ドラッカーの言葉)

23 章そして未来へ

付録 A ソフトウェアとソフトウェアエンジニアリングの歴史

ソフトウェアとソフトウェアエンジニアリングの歴史

#書籍 #文献