システム（system）という語は、 ギリシャ語の「結合する」に由来します。
システムは 2 つのもので決まります。
| 構成要素 | ハンドル、サドル、フレーム、チェーン、タイヤ（前）、タイヤ（後） |
|---|---|
| 干渉 |
ハンドルを動かすと、タイヤ（前）が方向づけられる ペダルを回すとチェーンが動く チェーンが動くと、タイヤ（後）が回る フレームは全体を形成する（結合する） |
| 外界との干渉 | 人間がサドルに座ってバランスをとる |
部品を並べただけではシステムになりません。 どう干渉するかが決まってはじめてシステムです。 逆にいえば、システムを理解するとは、干渉のしかたを理解することです。 この見方は、あとで出てくるモジュール分割（第6〜7回）でそのまま効いてきます。 「どう分けるか」とは「どんな干渉を残すか」に他ならないからです。
システムはソフトウェアから構成されます。では、そのソフトウェアとは何でしょうか。 ハードウェアと並べると、性質の違いがはっきりします。
| ハードウェア | ソフトウェア | |
|---|---|---|
| 語感 | 固いもの | 柔らかいもの |
| もとの意味 | 金物 | 利用技術 |
| 実体 | 物質的 | 抽象的 |
| 見え方 | 目に見える（有形） | 目に見えない（無形） |
| 作り方 | 工業生産 | 手作業生産 |
| 測り方 | 定量的 | 定性的 |
この 3 つが、ソフトウェア開発を難しくしています。
ソフトウェア工学の多くの手法は、この 3 つを何とかしようとする試みだと言えます。 見えないものを図に描き（UML）、手作業をプロセスで律し（開発プロセス）、 定性的なものを基準で測ろうとする（結合度・強度、網羅率）。
かつてソフトウェアは、ハードウェアに付随したサービス的な価値しかないと見られていました。 機械を買えばおまけで付いてくるもの、という扱いです。
いまは逆転しています。第1回で見たとおり、 価値を生んでいるのはソフトウェアであり、 ハードウェアはそれを載せる器になりつつあります。
「動く」だけでは足りません。ソフトウェアの品質は多面的です。
| 観点 | 問い |
|---|---|
| 機能性 | 求められた機能を備えているか |
| 信頼性 | 落ちないか。落ちても回復できるか |
| 使用性 | 使いやすいか。学びやすいか |
| 効率性 | 速いか。資源を無駄に使わないか |
| 保守性 | 直しやすいか。変更が他へ波及しないか |
| 移植性 | 別の環境へ移せるか |
このうち保守性は、開発中には見えにくいのに、 費用への影響がもっとも大きい項目です。 ソフトウェアの費用の多くは、作った後の変更に費やされます。
ソフトウェアは、企画から廃棄までの一生（ライフサイクル）を持ちます。
| 工程 | やること | この授業で扱う回 |
|---|---|---|
| 要求分析（要求定義） | 何を実現するかを明確にする | 第4〜5回 |
| 外部設計 | サブシステムへ分割し、外から見た仕様を決める | 第6回 |
| 内部設計 | モジュールレベルまで詳細化する | 第6〜7回 |
| 実装 | プログラムを書く | — |
| テスト | 仕様を満たすことを確かめる | 第8回 |
| 運用・保守 | 使いながら直し、育てる | 第11回 |
費用の大半は人件費であり、開発工数に比例します。 だからソフトウェア開発の管理とは、突きつめれば 「人の時間をどこに使うか」の管理です。 次回は、その時間をどんな順序で使うか ── 開発プロセスを扱います。