ソフトウェア工学 知能情報学部 新田直也

講義概要  私の研究室： 13 号館 2 階 (13-206)  講義資料について :  参考図書 : 玉井哲雄 : 「ソフトウェア工学の基礎」, 岩波書店  成績評価 : 主に試験 (1 回 ) ，演習で評価

講義計画  第 1 回 ソフトウェア危機とソフトウェア工学  第 2 回 ソフトウェア開発プロセスモデル  第 3 回 ソフトウェア分析設計モデル  第 4 回 テスト，保守，コスト見積もりモデル  第 5 回 演習  第 6 回 オブジェクト指向の概念 (1)  第 7 回 オブジェクト指向の概念 (2)  第 8 回 UML に基づく開発手法 (1)  第 9 回 UML に基づく開発手法 (2)  第 10 回 演習  第 11 回 デザインパターン  第 12 回 アジャイル開発手法とリファクタリング  第 13 回 形式的手法と検証  第 14 回 まとめ  第 15 回 試験

ソフトウェア危機  世界最初のプログラム． (EDSAC 1949 年 )  ソフトウェアの巨大化． IBM OS/360 （ 1964 年）， 500 万行規模のプログラ ム．  ピーク時に 1000 人以上が開発．  マネージャであった，フレデリック・ P ・ブルックス， Jr は， 1975 年「人月の神話」を執筆， 1999 年チューリング賞を受 賞． NASA ， GEMINI 計画（ 1960 年代中期） 600 万行規模．  APOLLO 計画（ 1970 年代前半）では 1300 万行規模．  SPACE SHUTTLE 計画（ 1970 年代後半）では 4500 万行規模．  ソフトウェアに対する社会的需要の増加． メインフレームコンピュータの普及（ 1960 年代後 半） → ソフトウェア危機（ software crisis ）

ソフトウェア危機の内容  開発スケジュールの遅れ． 当初の予定通り開発が完了しない． 手戻り（作業のやり直し）が発生する． バックログ（ backlog, 開発の積み残し）を生じる．  製品の品質の低下． テストに膨大な時間がかかる． 保守，メンテナンスに多くのコストがかかる． 売り上げの低下，補償問題への発展．  開発者へのストレス，労働環境の悪化． 超過勤務． 離職率の増加．

ソフトウェア工学  ソフトウェア工学（ software engineering ）： ソフトウェア危機の解決のため． ソフトウェア危機への対処として， 1968 年ドイツの ガルミッシュで開かれた NATO の国際会議によって提 唱される． 「ソフトウェアの開発，運用，保守に対して，体系的 で規律化された定量的アプローチを適用すること，す なわち，ソフトウェアに工学を適用すること．」 （ IEEE std ）

なぜ今ソフトウェア工学か？  ソフトウェア危機は過去の問題ではない． 大規模 IT プロジェクトの半数以上が失敗に終わって いる．（米国，国家事業評価法， 1993 年） 約 1/3 のプロジェクトが途中で中止，残る 2/3 が倍の 予算と時間をかけて完成（ Brown 他， 1998 年） ソフトウェアに対する要求が，国家的なソフトウェ アの生産能力を上回っている．（米国， IT に関する 大統領諮問委員会 PITAC ， 1999 年） 数々のシステム障害．

最近のシステム障害の例  国内： 2000 年問題 NTT ドコモ，携帯電話を 10 万台以上回収（ 2000 年） みずほ銀行，口座振替未了が 250 万件以上に．（ 2002 年） 航空管制システムが障害， 200 便以上欠航．（ 2003 年） すべての金融機関で他行カードが使えず．（ 2004 年） トヨタプリウス，高速走行中にエンジン停止．（ 2005 年）  海外： デンバー空港の手荷物配送システムの不具合により開港が遅れる． （ 1995 年） 米国軍巡洋艦ヨークタウンが航行不能．（ 1997 年） 米国海兵隊 V-22 オスプレイが墜落，海兵隊員 4 人死亡．（ 2000 年）

ソフトウェア製品の特質  フレデリック・ P ・ブルックス， Jr ： 「人月の神話 ～狼人間を撃つ銀の弾はない～」 より． 複雑性： 大きさの割には他のどの人工構造物より複 雑．（似た部分が少ない．） 同調性： ハードウェア，人間の習慣，社会制度など の環境に順応させなければならない． 可変性： 頻繁に変更を要求される． 不可視性： 目に見えない． 銀の弾（ silver bullet ）とは ? 「ソフトウェア構築を容易にする特効薬」 → 他の工業製品ほど扱い易くない．

ソフトウェア工学の成果と現状  大規模で変化しないソフトウェアを，膨大な時 間とコストをかけて 1 から作るのに一定の成果． 国家主導． メインフレーム上で稼動． 逐次処理．  現代のソフトウェアは， 時代の進歩に合わせて仕様が絶えず変化． 国家主導の開発から民間主導の開発へ． （時間とコストの削減） ダウンサイジング． OS やフレームワークなどの基盤を利用する必要性． インタラクティブ（対話的）なシステムが主流． 可変性 同調性

ソフトウェア開発の流れ（ 1 ）  個人でソフトウェアを作る場合， → いきなりプログラミング．  多人数で開発する場合，そうはいかない． どの部分を誰が担当するか ? 言語は何を使うか ? そもそもソフトウェア全体をどのように分割する か ? そもそも何を作るか ? 作ったものはきちんと動くか ?  意思疎通の問題．  開発効率の問題．  信頼性の問題．

ソフトウェア開発の流れ（ 2 ）  要求分析： 何を作るか（作りたいか）を決め る．  設計： 全体をどのように分割するかを決める．  実装： プログラミング，コーディング．  テスト： 出来たプログラムを動かしてテスト．  保守： 出荷後の修正，メンテナンス． 設計実装テスト 要求分析 出荷

生産性の個人差  プログラミング能力の個人差は大きい． 個人の能力差は最大で 28 対 1 （サックマン， 1968 年） 最優秀者の測定値は最低者の約 10 倍（トム・デマルコ， 1986 年） 上位 50% の平均測定値は，下位 50% の 2 倍以上（同 上）  生産性はオフィス環境によって変わる．  開発チームの結束力が重要． （トム・デマルコ：「ピープルウェア」，日経 BP 社）

ソフトウェア工学の対象  開発プロセス（工程）： 開発の流れや手順を変更して効率化，高信頼化を図る．  分析設計モデル： 要求分析や設計で用いるモデルを考える． ドキュメント化（文書化）の方法，フォーマット．  見積もり： コストや期間などを事前に見積もる． 過去のプロジェクトの評価をする． 個人や開発チームの能力を評価する．  プログラミング言語，開発ツール： 直接的な効果．  基礎理論： ソフトウェア基礎理論，計算モデル，論理学，代数学．  心理学，社会学，組織論： 結局人間が関わる作業．

本日のまとめ  大規模なソフトウェアを開発する際の問題（ソフトウェ ア危機）．  ソフトウェア危機を解決するためにソフトウェア工学が 生まれた．  ソフトウェア開発は本質的に難しい（銀の弾はない）． 複雑性 同調性 可変性 不可視性  ソフトウェア開発において必要な作業．  プログラミング能力の個人差は大きい．