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

Slides:



Advertisements
Similar presentations
1 プリミティブ Web サービスの 入出力データに関する一考察 2005 年 3 月 21 日 松江工業高等専門学校 情報工学科 奈良先端科学技術大学院大学 情報科学研究科 越田高志 電子情報通信学会 2005年総合 大会.
Advertisements

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 ソフトウェア部品推薦のための.
ソフトウェア工学 知能情報学部 新田直也. リファクタリング  リファクタリング( refactoring ): 「プログラムの外的振る舞いを変えることなく,その内 部構造を改善すること」  もともと Smalltalk のコミュニティで使われていた.  M. ファウラーの 1999 年の著書.
1 情報基礎 A 第 9 週 プログラミング入門 VBA の基本文法 1 準備・変数・データの入出力 徳山 豪・全 眞嬉 東北大学情報科学研究科 システム情報科学専攻 情報システム評価学分野.
CMU2005 海外エンジニアリングワークショップ参加報告書 1 「真の要求を見極めろ!」: teamB 要求定義をどう捉えるか ● 要求定義とは何か? 製品には、顧客の望むことを正しく反映させる必要がある。 そのために必要なものが要求仕様である。 すなわち、要求仕様とは、顧客と製品を結ぶものであり、これを作ることが要求定義である。
平成26年度「浪江町 タブレットを利用したきずな再生・強化事業(システム設計・開発)」 ( 様式6 ) 提案書雛型 (提案者名を記載) ○○○○ 受付番号 平成 26 年度「浪江町 タブレットを利用したきずな再生・強化事業(システム設計・開 発)」 企画提案書.
1 EASE プロジェクトにおける EPM ( Empirical Project Monitor) を用いたプロジェクト管理デモ 奈良先端科学技術大学院大学 産学官連携研究員 松村 知子 2005 年 9 月 30 日 JISA 経営者セミナー.
OWL-Sを用いたWebアプリケーションの検査と生成
システム開発におけるユーザ要求の 明示的表現に関する一検討
東京工科大学 コンピュータサイエンス学部 亀田弘之
背景 ソフトウェアの大規模化・複雑化 生産性と品質の向上 ↓ オブジェクト指向分析設計の適用 開発ツールの投入.
東京工科大学 コンピュータサイエンス 亀田弘之
操作は、バッチファイルを ダブルクリックするだけ!
XXXの提案書 チーム名 サブタイトル(必要であれば).
「ICT社会におけるコミュニケーション力の育成」 研修モジュール C-6:ポスターセッション
OJT研修 「テスト実施、テスト設計の技術習得」 日時: 8月22日(月)  場所: 本社5階.
3-1システム戦略 3-1-3ソリューションビジネス (Point) ・代表的なサービスを通じ、ソリューションの考え方を理解
早稲田大学大学院理工学研究科 情報科学専攻修士2年 後藤滋樹研究室 坂本義裕
事業計画 発表者名 | 会社名.
ビジネスパターンに基づく クラウドシステムのサービスレベル設計
ソフトウェア工学 知能情報学部 新田直也.
オープンソフトウェア利用促進事業 第3回OSSモデルカリキュラム導入実証
CHAPTER1 UMLとオブジェクト指向の基本概念(2)
情報科学1(G1) 2016年度.
パッケージソフトウェア利用コンピュータシステム構築委託契約書 パッケージソフトウェア、OS、第三者ソフトウェアの使用許諾契約
~スマートフォン利用~ 店舗管理システムのご提案 サイボウズ中国.
開発流れ.
リファクタリングのための 変更波及解析を利用した テスト支援ツールの提案
~企画~ GO,桑田,ヒルズ.
営業帳票システムに関するご提案書 (Draft)
政府情報システムのコスト削減の 取組状況について
本章では、モデル取引・契約書追補版が対象とする顧客や開発モデルなどの概要、第1版との相違点について 解説します。
資格取得スキルⅠb (ITパスポート試験対策講座)
ソフトウェア工学 第五回 知能情報学部 新田直也.
ソースコードの変更履歴における メトリクス値の変化を用いた ソフトウェアの特性分析
製造準備段階における 工程FMEAの実施と不具合未然防止
XP Extreme Programming.
Satoimo 最終発表 PM 吉田浩二 篠崎友識 野上大輔 姉崎祐樹.
アップデート 株式会社アプライド・マーケティング 大越 章司
技術参照モデルとシステム要件定義 に関する学習システム
第7回 授業計画の修正 中間テストの解説・復習 前回の補足(クロックアルゴリズム・PFF) 仮想記憶方式のまとめ 特別課題について
~新たなソフトウェア開発の手法~ 発表 土屋俊介
ユーザ・インタフェース 小テスト 第5回.
12の発明の原理だけで発想できるプロセス アイデア発想とアイデア選定
ソフトウェア設計検証 研究室の紹介 知能情報学部 准教授 新田直也.
オープンソース開発支援のための ソースコード及びメールの履歴対応表示システム
東京工科大学 コンピュータサイエンス学部 亀田弘之
シリーズ:著者の回答  質問 (韓国 K社、L.Y氏 開発・設計 )
Ibaraki Univ. Dept of Electrical & Electronic Eng.
13 ソフトウェア工学 Software Engineering ソフトウェアプロセス SOFTWARE PROCESS.
第15回放送授業.
ビジネス プロジェクトの計画 発表者名 | 会社名.
早稲田大学大学院 基幹理工学研究科 情報理工学専攻 後藤研究室 修士1年 魏 元
コードクローン分類の詳細化に基づく 集約パターンの提案と評価
プロジェクトの概要 プロジェクト名 | 会社名 | 発表者名.
INTRODUCTION TO SOFTWARE ENGINEERING
プロジェクト演習 知能情報学部 新田直也.
パッケージソフトウェア利用コンピュータシステム構築委託契約書 パッケージソフトウェア、OS、第三者ソフトウェアの使用許諾契約
企業システム戦略を成功させる! ドキュメント・レビュー実践法 企業システム戦略家 青島 弘幸.
All Rights Reserved, Copyright © 2004, Kobayashi
設計情報の再利用を目的とした UML図の自動推薦ツール
保守請負時を対象とした 労力見積のためのメトリクスの提案
開発作業の形式化に基づく プロセス評価 松下誠 大阪大学.
プログラム分散化のための アスペクト指向言語
プログラムの一時停止時に 将来の実行情報を提供するデバッガ
第2回実務者会議の議論を受けた検討(データWG関係)
プログラミング言語論 第九回 理工学部 情報システム工学科 新田直也.
オブジェクト指向メトリクスを用いた 開発支援に関する研究 --- VC++とMFCを用いた開発を対象として ---
アジャイル開発プロセス 森口朋広.
ソフトウェア工学 理工学部 情報システム工学科 新田直也.
Presentation transcript:

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

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

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

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

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

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

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

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

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

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

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

ソフトウェア開発工程

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

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

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

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

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

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

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

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

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

開発プロセスモデル

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

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

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

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

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

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

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

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

(おまけ) アジャイルソフトウェア開発 について

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

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

アジャイル って何?

agile = 俊敏な, 素早い

どういう 考え方?

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 計画を厳守することより, 変化に対応することを優先する 原文は http://agilemanifesto.org/ から引用. 日本語訳は 「Rails によるアジャイル Web アプリケーション開発」から引用.

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

調べきれず orz

調査継続

もしくは 誰か教えて

終わり

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