Transcript 2回目 - ソフトウェア設計検証研究室

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