ソフトウェア工学 知能情報学部 新田直也 講義概要 私の研究室： 講義資料について: 13号館2階(13-206) http://silverbullet.is.konan-u.ac.jp/lectures/ 参考図書: 玉井哲雄:「ソフトウェア工学の基礎」, 岩波書店 成績評価: 主に試験(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万行規模のプログラム． NASA，GEMINI計画（1960年代中期）600万行規模． ピーク時に1000人以上が開発． マネージャであった，フレデリック・P・ブルックス，Jr は，1975年 「人月の神話」を執筆，1999年チューリング賞を受賞． APOLLO計画（1970年代前半）では1300万行規模． SPACE SHUTTLE計画（1970年代後半）では4500万行規模． ソフトウェアに対する社会的需要の増加． メインフレームコンピュータの普及（1960年代後半） →ソフトウェア危機（software crisis） ソフトウェア危機の内容 開発スケジュールの遅れ． 製品の品質の低下． 当初の予定通り開発が完了しない． 手戻り（作業のやり直し）が発生する． バックログ（backlog, 開発の積み残し）を生じる． テストに膨大な時間がかかる． 保守，メンテナンスに多くのコストがかかる． 売り上げの低下，補償問題への発展． 開発者へのストレス，労働環境の悪化． 超過勤務． 離職率の増加． ソフトウェア工学 ソフトウェア工学（software engineering）： ソフトウェア危機の解決のため． ソフトウェア危機への対処として，1968年ドイツのガル ミッシュで開かれたNATOの国際会議によって提唱される． 「ソフトウェアの開発，運用，保守に対して，体系的で規律 化された定量的アプローチを適用すること，すなわち，ソフ トウェアに工学を適用すること．」（IEEE std 610.12） なぜ今ソフトウェア工学か？ ソフトウェア危機は過去の問題ではない． 大規模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社） ソフトウェア工学の対象 開発プロセス（工程）： 分析設計モデル： 直接的な効果． 基礎理論： コストや期間などを事前に見積もる． 過去のプロジェクトの評価をする． 個人や開発チームの能力を評価する． プログラミング言語，開発ツール： 要求分析や設計で用いるモデルを考える． ドキュメント化（文書化）の方法，フォーマット． 見積もり： 開発の流れや手順を変更して効率化，高信頼化を図る． ソフトウェア基礎理論，計算モデル，論理学，代数学． 心理学，社会学，組織論： 結局人間が関わる作業． 本日のまとめ 大規模なソフトウェアを開発する際の問題（ソフトウェア危 機）． ソフトウェア危機を解決するためにソフトウェア工学が生まれ た． ソフトウェア開発は本質的に難しい（銀の弾はない）． 複雑性 同調性 可変性 不可視性 ソフトウェア開発において必要な作業． プログラミング能力の個人差は大きい．
© Copyright 2024 ExpyDoc
