実践ソフトウェアエンジニアリング1章_感想とまとめ

こんにちは。

最近、実践ソフトウェアエンジニアリングを読んでます

実践ソフトウェアエンジニアリング (第9版) | ロジャー・プレスマン, ブルース・マキシム, 西康晴, 水野昇幸, 井芹久美子, 井芹洋輝, 池田暁, 岡澤裕二, 金子昌永, 衣笠駿, 鈴木一裕, 根本紀之, 松尾和昭, 山崎崇 | 工学 | Kindleストア | Amazon

1章を読んでかなり良かったので感想 & まとめを書きます。

まとめNotion:

hammerhead-calendula-6a6.notion.site

モチベーション

ソフトウェアエンジニアリングとは、ソフトウェアを作ってユーザーに提供するために必要な全てのことを論じる学問である

Software engineering is the branch of computer science that deals with the design, development, testing, and maintenance of software applications. Software engineers apply engineering principles and knowledge of programming languages to build software solutions for end users.

en.wikipedia.org

ソフトウェアを提供する組織に居る以上、ソフトウェアエンジニアリングはソフトウェアエンジニアのみならず、全ての人間が知っておくべきだと考えている。

自分の経験上、組織の与えられたロール・ドメインに対して必要な知識を習得する傾向があるが、ソフトウェアエンジニアリングがソフトウェアを作る共通言語なのに、ソフトウェアエンジニアしか知らない（なんなら自分もソフトウェアエンジニアとしては経験的な暗黙知しかなく体系的な知識は持ってない）ように思える。

もし、ソフトウェアエンジニアリングが組織の共通言語となったとき、ものすごいバリューを産むのだろうという仮説を立て、ソフトウェアエンジニアリングを学び始めた。

感想

ソフトウェアエンジニアリングの本として最近有名なのは Googleのソフトウェアエンジニアリング (通称、swe book)であろう。

swe bookはGoogleのそれまでのプラクティスからどのようにソフトウェアエンジニアリングを捉えて、文化形成、プロセスをつくっているかという本であった。

具体例も多く、Googleが重視するスケールとトレードオフというソフトウェアエンジニアリング原則が一貫しており、多くの人が理解しやすく、実践もしやすい本であると感じた。

一方、実践ソフトウェアエンジニアリング は、様々なソフトウェア開発プラクティスからソフトウェアエンジニアリングを体系化したと感じ、より学問・実学としてのソフトウェアエンジニアリング色が強いように思える。

swe bookに比べて、ソフトウェア開発経験がある程度ない人にはピンとこないであろうと思う。

特に、一章のソフトウェアエンジニアリングの抽象化は素晴らしいのだが、ソフトウェアエンジニアでないと理解するのは難しいと思う。

パッと見て全人類読んだ方が良いと思うくらい良い本だと個人的には感じるが、中々読者を選ぶんじゃないかと思う。

高い視点を与えており、血となり肉となるような知識が得られるだろうが、すぐに実践は難しいんじゃないかなとも思う。

FYI: 翻訳者の一人の方の書評が非常に参考になる。

masskaneko.hatenablog.com

以下に1章のまとめを抜粋する

ソフトウェアエンジニアリング階層

• ソフトウェアエンジニアリングはまず品質ありきで、プロセス・手法・ツールといった順に具体化される

ソフトウェアプロセス

我々が行っている具体的な開発方法を抽象化して構造に落とし込み使えるようにするためにプロセスという抽象的な構造を考える

プロセスはアクティビティ、アクション、タスクという構成要素を持つ

プロセスフレームワークとフレームワークアクティビティ

我々が実際に行っている開発方法のコンポーネント（例えば、要求分析、要件定義、設計、開発、テストなど）をプロセスフレームワークとして誰でも使えるようにするために、プロセスフレームワークというもので表現する

• プロセスフレームワークとは、複数のフレームワークアクティビティによってソフトウェアエンジニアリングプロセスが表現されたもの
  • フレームワークアクティビティは規模や複雑さに関わらず適用される（普遍的なもの）
  • プロセス全体に適用される包括的アクティビティをもつ
• プレセスフレームワークを構成する一般的フレームワークアクティビティ
  • コミュニケーション: ステークホルダーとコミュニケーションする
  • 計画: ソフトウェアプロジェクト計画を行う。技術的タスク、リスク、必要なリソース、成果物、スケジュールを明確にする。
  • モデリング: 何をどう組み合わせて動かすかのスケッチをする。ソフトウェア要求、設計を理解するためのモデルを作成する。
  • 構築: コードを作ってテストする
  • デプロイ: デリバリーして、評価され、フィードバックを受ける
• これらを組み合わせたフレームワークアクティビティが反復的に行われ（イテレーション）、ユーザーに機能やフィーチャーがソフトウェアにインクリメントされる

ソフトウェアプラクティス

• プラクティスとは？ : Polyaの問題解決原則に従った活動のこと
  • How to Solve It - Wikipedia
  • Understanding: 解くべき問題を理解する (コミュニケーションと分析)
    • 誰が問題解決に利害があるか
    • 何が分かってないのか、どんなデータや機能、フィーチャが必要か
    • 問題を理解しやすい小さい問題で表現できるか
    • 問題を視覚的に表せられるか
    • 類似の問題を解決したことはあるか？　再利用はできないか？
    • …
  • Plan: 解決策の計画 (モデリングとソフトウェア設計)
  • Do: 計画を実行に移す (コード実装)
    • コードは設計まで追跡できるか？
    • 正しそうか？　設計、コードはレビューされているか？
  • Check: 結果が正しいことを確認する (テストと品質保証)
    • テスト戦略
    • 解決策は要求されているデータ、機能、フィーチャは合致してるか