神戸大学 大学院理学研究科 地球惑星科学専攻 博士後期課程 D2 納多 哲史

Presentation on theme: "神戸大学 大学院理学研究科 地球惑星科学専攻 博士後期課程 D2 納多 哲史"— Presentation transcript:

1 2008.11.14 神戸大学 大学院理学研究科 地球惑星科学専攻 博士後期課程 D2 納多 哲史
ソフトウェア開発工程と 開発モデルの紹介 神戸大学 大学院理学研究科 地球惑星科学専攻 博士後期課程 D2 納多 哲史

2 今回の発表について ソフトウェア開発の考え方を紹介します 一般的なモデルのみの紹介で, 具体的な手法には言及しません
リクエストがあれば今後の計算機セミナーでの紹介も考えます

3 問題提起 我々研究者はどのようにソフトウェア開発を進めると効率良く研究を進められるだろうか? 発表の最後にまた考えることにします.

4 目次 前提 行き当たりばったりなソフトウェア開発の例 開発工程 開発プロセスモデル （おまけ） アジャイルソフトウェア開発

5 前提 ソフトウェア開発を「顧客の要望する機能をソフトウェアとして実現する作業」と定義 経費や期限が予め決まっている
これから話す内容は営利目的のソフトウェア開発を前提 とされているため, 営利目的のソフトウェア開発を前提を示しておく. ソフトウェア開発を「顧客の要望する機能をソフトウェアとして実現する作業」と定義 ソフトウェアを欲しい人と作る人は異なる 経費や期限が予め決まっている 予算やスケジュールの管理が必要 ソフトウェア開発は複数の開発者によって分担される 作業の並列化が必要

6 行き当たりばったりな ソフトウェア開発の例

7 行き当たりばったりな ソフトウェアの作り方
とにかく早く作ってしまおうとする 顧客の要望は最初に一通り聞くだけ 仕様書, 設計書は書かない いきなりプログラミングを始める いきなりシステム全体を稼動させる ろくにテストも行わず, 動けば即納品

8 顧客の要望をちゃんと聞かないと…… 具体的に何を作ればよいのか分からない 顧客が欲しいソフトウェアとは異なったものができる
一から作り直しの場合も （時には契約解除, 損害賠償請求も）

9 仕様書・設計書を書かず, いきなりプログラミングを始めると……
工数・費用の把握が困難になり, 作業分担やスケジュールの管理を行いにくい 各開発者の作ったプログラムがそのまま結合できない (プログラム間で渡すデータの型が異なるなど) 機能の抜け漏れ, 重複が生じやすい 後からの機能追加・変更が多いとコードが複雑化しやすく, 保守が困難になる 品質・信頼性を高められなくなる

10 いきなりシステム全体を 稼動させると…… バグの特定が困難 テストの組み合わせ数が膨大になる

11 結局, 行き当たりばったりな ソフトウェア開発は……
顧客の思い通りの製品が出来ない 作業の手戻りが多発する 完成までに時間がかかる 進捗管理が困難 高い品質・信頼性を得られない 後からの保守が難しくなる 大規模なソフトウェアには通用しない！

12 ソフトウェア開発工程

13 ソフトウェア開発工程とは ソフトウェア開発を複数の段階（プロセス）に分割, モデル化したもの
利点: 作業が複数に分割されることで費用, 開発者数の見積もり・スケジュール管理が行いやすくなる 注意: 開発現場で厳密に採用されているわけではない. 複数の段階をサポートするようなツールもある

14 ソフトウェア開発工程の全体像 要求定義 何をしたいか明文化 上流 外部設計 内部設計 何を作るか明文化 プログラム設計 プログラミング
実際に作る テスト 品質の確認 下流 （納品） （運用・保守） プログラミング（コーディング）は開発の一部に過ぎない！ 仕様書、設計書などの書類作成にも多くが費やされる

15 開発工程: 要求定義 顧客がどのような機能を持つソフトウェアを要求しているか明らかにする. 顧客と開発者が話し合って決める.
要求定義に時間がかかるケース 顧客の要求が漠然としている（例: 「業務を効率化したい」） 複数の部署が使うソフトウェアの場合, 部署ごとで要求が異なる 開発者が顧客の業務や専門用語をよく知らないため, コミュニケーションの齟齬が生じる

16 開発工程: 外部設計 ユーザから見える部分の設計を行う. 顧客と開発者の打ち合わせによって決める. 画面のレイアウト 操作手順
入出力データのフォーマット 既存システムとのデータの受け渡し方法

17 開発工程: 内部設計 外部設計の仕様書をもとに, ユーザから見えない, システム内部の設計を行う. 開発者が行う.
システムをモジュール（プログラムの最小単位）に分割する モジュールの処理内容の設計 モジュール間で受け渡しするデータの内容の設計

18 開発工程: プログラム設計 外部設計の仕様書をもとに, プログラムの仕様を決める モジュール内のアルゴリズムの設計

19 開発工程: プログラミング プログラム設計書をもとにプログラムを書く. コーディングとも呼ぶ.

20 開発工程: テスト プログラムが仕様通り動くか確認する. いわゆるバグつぶしはこの段階. 単体テスト 結合テスト システムテスト 運用テスト
モジュール単体のテストをする 結合テスト 複数のモジュールをつなぎ合わせてテストする システムテスト 全モジュールをつなぎ合わせてテストする 運用テスト 顧客によって本番さながらのテストを行う

21 ソフトウェア開発工程の全体像 要求定義 何をしたいか明文化 上流 外部設計 内部設計 何を作るか明文化 プログラム設計 プログラミング
実際に作る テスト 品質の確認 下流 （納品） （運用・保守） プログラミング（コーディング）は開発の一部に過ぎない！ 仕様書、設計書などの書類作成にも多くが費やされる

22 開発プロセスモデル

23 開発プロセスモデルとは 開発工程を作業順に並べた一式

24 開発モデル: ウォーターフォールモデル 利点 欠点 進捗の管理がしやすい 大規模かつ信頼性の高いソフトウェアを作りやすい
開発モデル: ウォーターフォールモデル 上流から下流へ一方向に進める. 基本的に逆行はしない. 利点 進捗の管理がしやすい 大規模かつ信頼性の高いソフトウェアを作りやすい 欠点 大量の書類 （仕様書） が必要になる 途中からの新しい要求に対応しにくい 顧客がソフトウェアの実物を見るのは工程の一番最後のため, 顧客の予想と異なったものが出来ることがある

25 開発モデル: 成長モデル 利点 欠点 顧客の要求が曖昧な場合でも開発に着手できる 顧客の満足の行くソフトウェアを開発しやすい
顧客の要求の変更があるたびに, 要求定義～テストを繰り返す 利点 顧客の要求が曖昧な場合でも開発に着手できる 顧客の満足の行くソフトウェアを開発しやすい 新しい要求に柔軟に対応できる 欠点 最終的な開発期間, コストが予測しにくく, 進捗管理が難しい

26 開発モデル: プロトタイピングモデル 利点 欠点 具体的なソフトウェアがあるので顧客と開発者の行き違いが生じにくい
要求定義の段階でプロトタイプ（試作品）を作り, 顧客の評価を要求定義に反映させる. 利点 具体的なソフトウェアがあるので顧客と開発者の行き違いが生じにくい 要求定義が明確になるので, 上流工程への手戻りが生じにくい 欠点 進捗管理が困難 顧客の要望を取り入れすぎ, まとまりのないシステムができることがある

27 開発モデル: その他のモデル スパイラルモデル 契約モデル 発展的プロトタイピングモデル 段階的配布モデル 発展的配布モデル
システムをサブシステムに分割し, サブシステムごとにウォーターフォールモデルやプロトタイピングモデルを採用する. 契約モデル 各工程ごとに契約する. 官公庁に多い. 発展的プロトタイピングモデル 顧客が満足するまで試作品作成と評価を繰り返す 段階的配布モデル 顧客の評価をもとに, サブシステムごとに内部設計～テストを繰り返す 発展的配布モデル 顧客の評価をもとに, システム全体で内部設計～テストを繰り返す.

28 どのモデルが最良か? 万能なモデルはない. 状況に応じて使い分けられている.

29 問題提起 我々研究者はどのようにソフトウェア開発を進めると効率良く研究を進められるだろうか? 既存のモデルは参考になるだろうか?
研究用のソフトウェア開発の特徴 開発者がユーザでもある ソフトウェアの出力が予測しづらい どうなるか知りたいからソフトウェアを作る 仕様変更がよくある 得られた知見によって新しい機能を加えたりする

30 まとめ 開発工程とは, 効率よいソフトウェア開発を目的として, 開発を複数の作業内容に分割, モデル化したものである
プログラミングだけでなく設計, テストも重要 開発工程を作業順に並べた一式を開発プロセスモデルと呼び,様々なモデルが提案されている 開発プロセスモデルに万能なものはなく, 状況に応じて使い分けられている

31 （おまけ） アジャイルソフトウェア開発 について

32 アジャイル ソフトウェア 開発

33 という 考え方が あるらしい

34 アジャイル って何?

35 agile = 俊敏な, 素早い

36 どういう 考え方?

37 Manifesto for Agile Software Development （アジャイルソフトウェア開発宣言）
Individuals and interactions over processes and tools プロセスやツールより, 人と人の対話を重視する Working software over comprehensive documentation 分厚いドキュメントより, ちゃんと動くソフトウェアを作ることに専念する Customer collaboration over contract negotiation 契約交渉より, 顧客の協力を得ることに力を入れる Responding to change over following a plan 計画を厳守することより, 変化に対応することを優先する 原文は から引用. 日本語訳は 「Rails によるアジャイル Web アプリケーション開発」から引用.

38 何をすれば 「アジャイル」 なのか?

39 調べきれず orz

40 調査継続

41 もしくは 誰か教えて

42 終わり

43 参考文献 ソフトウェア開発工程 – Wikipedia 西川猛史「図解雑学 ソフトウェア開発」ナツメ社
西川猛史「図解雑学　ソフトウェア開発」ナツメ社 Steve McConnell 「CODE COMPLETE」 日経 BP ソフトプレス 日高哲郎 「「基本情報」かららくらく受かるソフトウェア開発技術者」 日本経済新聞社 Manifesto for Agile Software Development Dave Thomas ほか 「Rails によるアジャイル Web アプリケーション開発」 オーム社 アジャイルソフトウェア開発 - Wikipedia