__NOTOC__
本書は、ソフトウェア工学の入門書であり、学部レベルのコースの教科書として意図されている。
ソフトウェア工学( ''software engineering'' )はチームで行うものである。
解決すべき問題があまりにも複雑であったり、大規模であったりするため、一人の開発者ではもう解決できないのである。
また、ソフトウェア工学はコミュニケーションも重要である。チームは開発者だけでなく、テスター、アーキテクト、システムエンジニア、顧客、プロジェクトマネージャーなど、さまざまなメンバーで構成されている。ソフトウェアプロジェクトは非常に大規模になるため、綿密な計画を立てなければならない。
実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、さらにユニットテストも書かなければならない。
しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。
そして、測定基準を使って問題のある部分を発見できなければならない。測定基準は、私たちのコードが特定の標準に従っているかどうかを教えてくれる。
大規模なプロジェクトでは、ソフトウェアの保守に多くの人が長い間忙殺されることがある。
プロジェクトの成否を左右する要素は非常に多いので、プロジェクト管理とその落とし穴、特にプロジェクトを成功に導く要素について少し学ぶ必要がある。
そして最後になるが、優秀なソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とし、そのツールについて知る必要がある。
最初のころ、皆さんは個人でコーディングしていた。 解決すべき問題は小さかったので一人で解決することができた。
現実の世界では、問題の大きさや時間の制約から、チームでなければ解決できないような問題がある。
チームが効果的に機能するためには、コミュニケーションするための言語（UML）が必要である。
また、チームは開発者だけでなく、テスター、アーキテクト、システムエンジニア、そして最も重要な顧客からも構成されている。
そこで、良いチームとは何か、顧客とのコミュニケーションの取り方、ソースコードだけでなく、ソフトウェアプロジェクトに関わる全てのことを文書化する方法などを学ぶ必要がある。
これまでの講座では、JavaやC++などの言語と、アイデアをコードにする方法を学んだ。しかし、これらのアイデアは言語から独立している。
統一モデリング言語（ ''Unified Modeling Language'' ; UML）を使えば、言語から独立してコードを記述する方法を見ることができるし、さらに重要なことに、1レベル上の抽象化レベルで考えることを学ぶことができる。
UMLは、コミュニケーションとドキュメンテーションのツールとして非常に有効である。
私たちは、パターンという全体像を見ることを学ぶ。これにより、さらに一段高い抽象度を得ることができる。
ここでもまた、仲間とのコミュニケーションをより効果的にするための語彙が増える。また、先輩から学ぶことも素晴らしい方法である。
これは、大規模なソフトウェアシステムを設計する際に必要不可欠なことである。
また、ソフトウェアを書くことができるだけでは、そのソフトウェアが良いものであるとは限らない。そこで、何が良いソフトウェアなのか、そして、どのようにソフトウェアの品質を測定するのかを明らかにする。静的解析( ''static analysis'' )や測定基準( ''measuring metrics'' )によって既存のソースコードを分析できるようになる一方で、コードが一定の品質基準を満たしていることをどのように保証すればよいのであろうか？この文脈では、テストも重要であり、高品質の製品を保証するものである。
これまで、IDE、コンパイラー、デバッガーについて知っていただけたかと思う。しかし、ソフトウェア・エンジニアが自由に使えるツールはもっとたくさんある。
チームで作業するためのツール、ソフトウェアを文書化するためのツール、開発作業全体を支援・監視するためのツールなどがある。
ソフトウェアアーキテクトのためのツール、テストやプロファイリングのためのツール、自動化やリエンジニアリングのためのツールもある。