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

本日のお話  ソフトウェアの開発の流れ（開発プロセス （ process ） ，開発工程，開発ライフサイクル （ life cycle ） ）について．  作業の段取り，計画は非常に重要．  引越し作業を例に考えてみよう． 段取りが悪いと … 荷造りが終わったのに車が来てない !! 車に荷物が入りきらない !! 段ボールの数が足りない !! 荷物を運ぶ人数が全然足りない !! 作業が終わらない !! 予算オーバー !!

ソフトウェア開発における 主要な作業項目  ソフトウェア開発における主要な作業項目は以下の通 り．  要求分析（ analysis, 要求定義）： 何を作るか（作り たいか）を決める．  設計（ design ）： 全体をどのように分割するかを決め る．  実装（ implementation ）： プログラミング，コー ディング．  テスト（ testing ）： 出来たプログラムを動かしてテ スト．  保守（ maintenance ）： 出荷後の修正，メンテナン ス． 設計実装テスト 要求分析 出荷

ソフトウェア開発プロセス  ソフトウェア開発の作業手順を定めたもの．開発ライフ サイクルともいう．プロセスはプロダクト（ product ） と並ぶソフトウェア工学上の主要な研究対象である．  様々な手順（プロセス）が提案されている． ウォーターフォールモデル スパイラルモデル プロトタイピングモデル RAD アジャイル MDA ソフトウェア工場 :  開発プロセスは現在でも発展中である．

ソフトウェアの開発形態と 開発に関わる人間  受託開発： 特定の顧客からの要求に応じてソフトウェアを開発，納 入する形態．日本では受託開発がほとんど．  パッケージ開発： 汎用のソフトウェア製品を開発，販売する形態．  オープンソース（ open source ）： ソースコードを公開し，不特定多数の開発者によって開 発，配布する形態．  顧客： 開発されるシステムに代金を支払う人，組織．  開発者： ソフトウェアを実際に構築する人，組織．  ユーザ（ user ）： ソフトウェアを実際に使う人，組織．

ソフトウェアの種類  OS  アプリケーション（ application ） 汎用アプリケーション ワープロ，表計算，データベース，画像処理， CAD … な ど GUI システム グラフィカルなユーザインタフェースを備えたもの 組み込みシステム 航空機，自動車，情報家電，携帯電話，計測機器 … など 業務システム，基幹系システム 経理業務，財務会計，販売管理，在庫管理，給与計算 … など Web アプリケーション ゲーム

工数と人月の神話  ソフトウェア開発では，作業にかかるコストを工数と呼 ぶ．  工数は一般に人月（ man-month ）で計量する．たとえ ば， 5 人で 3 ヶ月を要する作業は 15 人月と算出される． （ちなみに 1 人月の日本での相場は 100 万円程度）  実際は，人と月は可換ではない．（ F.P. ブルックス， Jr 「人月の神話」） 2 人で 5 ヶ月かかる作業 (10 人月 ) を 5 人で行っても 2 ヶ月で終わら ない． 人数が増えると相互のコミュニケーションのための負荷が大きく なるため． スケジュールが遅延しているときの，メンバの増員は非常に危険．

ウォーターフォールモデル （ water fall model ）（１）  ウィンストン.W. ロイスの 1970 年の論文が起源．  米国防総省の国防総省規格基準 2167-A に．  現在でも大規模プロジェクトでは主流．（日本 の開発プロジェクトの約 90% が採用）  ハードウェアなどの製造工程からの借用．  ウォーターフォールモデルの考え方： 「何を」作るか（問題, problem ）と「如何に」作る か（解法, solution ）は別．問題を間違えると，後の すべての作業が無駄になる． ひとつひとつ間違いがないことを確認しながら， （慎重に）作業を進めていこう．後で取り返しのつ かないことにならないように … （石橋を叩いて渡る 手法）

ウォーターフォールモデル （ water fall model ）（２）  開発作業をいくつかの工程に分 ける．  各工程の結果は成果物（ドキュ メント, document ）として残 される．成果物はその正しさを 検証された後，次の工程で利用 される．  基本的に開発は上流工程から下 流工程の方向に進み，工程間の 飛び越しや後戻りは原則的に認 めない．  ただし，例外的に 1 つ前の工程 への後戻りは許す場合が多い． （後戻りは軍の規格では欠 落．）  保守，運用を工程として位置づ け． システム 要求定義 ソフトウェア 要求定義 基本設計 詳細設計 コーディング テスト 運用保守 上流工程 下流工程 検証

ウォーターフォールモデルの 長所と短所  ウォーターフォールモデルの長所： 仕様や設計の変更は工程全体に深刻なダメージをもたらす． ウォーターフォールモデルでは，後の工程が混乱しないよう仕様 や設計を早い段階で固定化する． 各工程毎に成果物を残すことで，不具合が発覚したときに，その 原因の箇所を特定しやすくなる． プロジェクトの進捗の管理が容易である．  ウォーターフォールモデルの短所： 開発期間が長くなる． 成果物を逐一残すため負荷が増大． 後戻りを許さないため，開発途上で仕様や設計の変更ができない．  進歩の著しい分野に適さない．  一般に顧客の要求はあいまい．どれだけ検証しても，実際に動くも のを見て初めて「こんなはずではなかった」と気づく場合が多々あ る．  実装前に完全な設計を行うことはほぼ不可能．

本日のまとめ  ソフトウェアを開発する際の作業手順を開発プ ロセスという．  ウォーターフォールモデルが最も基本的なプロ セスモデルであるが，多くの問題を抱えており， 現状には即していない．  現在でも開発プロセスに関する議論は盛んであ る．