ソフトウェア工学第二回知能情報学部新田直也本日のお話ソフトウェアの開発の流れ（開発プロセス（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つ前の工程への後戻りは許す場合が多い．（後テスト検証戻りは軍の規格では欠落．）保守，運用を工程として位置づけ．下流工程運用保守検証ウォーターフォールモデルの長所と短所  ウォーターフォールモデルの長所：     仕様や設計の変更は工程全体に深刻なダメージをもたらす．ウォーターフォールモデルでは，後の工程が混乱しないよう仕様や設計を早い段階で固定化する．各工程毎に成果物を残すことで，不具合が発覚したときに，その原因の箇所を特定しやすくなる．プロジェクトの進捗の管理が容易である．ウォーターフォールモデルの短所：    開発期間が長くなる．成果物を逐一残すため負荷が増大．後戻りを許さないため，開発途上で仕様や設計の変更ができない．    進歩の著しい分野に適さない．一般に顧客の要求はあいまい．どれだけ検証しても，実際に動くものを見て初めて「こんなはずではなかった」と気づく場合が多々ある．実装前に完全な設計を行うことはほぼ不可能．本日のまとめソフトウェアを開発する際の作業手順を開発プロセスという．  ウォーターフォールモデルが最も基本的なプロセスモデルであるが，多くの問題を抱えており，現状には即していない．  現在でも開発プロセスに関する議論は盛んである． 