More Related Content Similar to ソフトウェア工学2023 04 開発プロセスモデル Similar to ソフトウェア工学2023 04 開発プロセスモデル (20) More from Toru Tamaki (20) 5. 代表的な開発プロセス
n一方通行の開発
• モデル
• ウォーターフォール
• V字
• 上流が下流に影響
• 終わるまで始められない
• 遅れたらしわ寄せ
n顧客の問題
• 最初の要件定義を分かっていない
• 開発途中で様々な追加要求を出
してくることがある
• 「それができるならあれもでき
るよね」「これもできるように
なったら嬉しい」など
• 要件定義，外部設計，内部設計
をすべてやり直し
• 顧客はモノを見ないと分からない，
納得しない
• 見たら要求も出てくる，変わる
• 顧客の意見は入らない
• 受け入れテストまで成果物を見
られない
7. 開発プロセスとビジネスプロセス
nサイクルを伴う開発プロセス
• プロトタイピング
• スパイラル
• アジャイル
nサイクルを伴うビジネスプロセス
• MVP (minimum value product)
• 最小限の機能のみを実装，リリース．
• アーリーアダプターからのフィードバックを
次の製品に反映
• 注：開発モデルというよりはビジネス手法・
事業モデル（リーンスタートアップ）
n類似点
• 素早いフィードバックループの構築
社会
企業 BtoC
BtoB
リリース
クライ
アント
ベンダ
BtoB
開発
10. ウォーターフォールモデル
nメリット
• 順番が明確
• 進捗管理が容易
• 分担も明確
• 長年利用されている
nデメリット
• 実際にはやり直しもある
• 遅れが生じると下流にしわ寄せ
がいく
• システムが納品されるまでクラ
イアントはシステムを見ること
ができない
要件定義
外部設計
内部設計
実装
テスト
運用・保
守
要件定義書
外部設計書
内部設計書
プログラム
上
流
工
程
下
流
工
程
システム
16. スパイラルモデル
n4つのフェーズを繰り返す
• 目的と対策の決定
• 対策とリスクの評価
• 開発と検証
• 次フェーズの計画
n反復によって徐々に改良
• 要求を具体的に
• 設計を詳細に
Spiralmodel, vectorized from Barry W. Boehm: Software Engineering
Economics, Prentice Hall PTR, 1981Marekventur - Own work
•CC BY-SA 3.0
17. スパイラルモデルとプロトタイピングモデル
The three basic approaches applied to software development methodology frameworks. Beao Old waterfall: Paul Smith -
File:Waterfall model revised.svg File:Rapid application software development.svg File:Software Development Spiral.svg
Three software development patterns mashed together.
Public Domain
n類似点
• プロトタイプを作成
• 顧客に確認
n相違点
• スパイラルモデルは
• 要求分析も反復する
• 仕様書を改善する
• プロトタイプではない
• 各反復で製品まで
• サブシステム開発にも適用
• サブシステム1を作り，2を
作り，3を作る，と反復する
18. 高速アプリケーション開発
nRAD
• Rapid Application Development
• （ユーザーを含む）少人数のチームで開発
• プロトタイプを作ってそれを評価するというサイクルを繰り返す
• 目的
• とにかく速く製品を開発することを目的とする
• RAD専用のものを活用する
• 自動化ツール
• ライブラリ
• テンプレート
• モジュール
Gambar RAD Modif A Ambarita - Own work
CC BY-SA 4.0
20. アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、
左記のことがらに価値があることを認めながらも、
私たちは右記のことがらにより価値をおく。
Kent Beck, Mike Beedle, Arie van Bennekum,
Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew
Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber,
Jeff Sutherland, Dave Thomas
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含める
ことを条件に自由にコピーしてよい。
https://agilemanifesto.org/iso/ja/manifesto.html
参考：
アジャイル領域へのスキル変革の指針：ア
ジャイルソフトウェア開発宣言の読みとき
方, IPA, 2020
29. エクストリーム・プログラミング（XP）
n 価値
• コミュニケーション
• シンプルさ
• フィードバック
• 勇気
• 尊重
n 原則
• フィードバックは迅速かつ頻繁に
• シンプルさを前提に
• 変化を受け入れる
n 開発プラクティス
• テスト駆動開発
• 実際のコードを書くよりも前に単
体テストのコードを書く
• ペアプログラミング
• 二人一組でプログラミングを行う
• 1人はコーディング（ドライバー）
• もう1人は確認とサポート（ナビ
ゲーター）
• リファクタリング
• コードを分かりやすく書き直す
• YAGNI（You Aren't Going to Need
It）
• それは必要ない
• （＝必要なことだけやろう）
37. 現代：プログラミングはほんの一部
(16) APIの実現性の確認（候補
パッケージのAPI、既存システムとの
接続性等の評価）
(1) 事業要件定義
(2) プロジェクトゴールの策定
(3) 要求品質の明確化
(4) パッケージを利用し実現す
る業務の新全体像の作成
(5) ベンダに対しシステム、パッ
ケージ等の情報提供要求、試算
見積依頼(RFI)
(6) ユーザに対しRFIに基づくシ
ステム、パッケージ等の情報の
提供、試算見積の提示
(7) 業務要件定義
(8) ベンダに対しパッケージ候補
選定のための情報提供依頼
(RFI)
(9) ユーザに対しRFIに基づくパッ
ケージ関連情報の提供、概算見
積の提示*2
(15) パッケージ候補の
システム要件評価
(17) パッケージソフトウェアの
選定と要件定義
システム要件定義と評価
(22) モディファイ、アドオンの範囲の
確定、及びそれに伴うユーザI/F・他
システムI/F設計*3
(25) ソフトウェア設計*1
(41) ハード保守、カスタ
マイズ部分保守開始
2.1 企画
2.2 要件定義
(27) 適格性確認テスト、監査、
ソフトウェア導入
(26) モディファイ、アドオンの設計、
プログラミング、ソフトウェアテスト
2.3 システム開発 3.1 運用 2.6 保守
運用準備
パッケージカスタマイズ 取引・契約モデルの全体像
重要事項説明書 A要件定義支援及びパッケージソフトウェア候補選定支援業務契約(カスタマイ
ズモデル)：準委任、(1)～(13)適用、Bパッケージソフトウェア選定支援及び要件定義支援業務
契約(カスタマイズモデル)：準委任、(14)～(18)適用
別紙1
（パッケージ、SaaS/ASP活用、保守・運用）＜ 追補版＞
設計・制作・テスト・移行
(
29
)
検
収
(
受
入
れ
）
(19) ベンダへの見積要求*2
(20) ユーザへの見積提出
(23) 外部設計書の承認(受入れ)
(28) 納品
(45) 廃棄
(42) 運用支援
(43) システム運用評価
及び業務運用評価
(43) 投資効果及び業務
効果の評価
(36) 運用テスト
(38) 利用者導入教育
※数字は共通フレーム2013該当項番
(40) 業務運用
(37) 完了報告(受入れ）
A 要件定義支援及びパッケージ
ソフトウェア候補選定支援契約
重要事項説明書 D外部設計支援業務契約：準委任・(21)～(23)適用、Eソフトウェア設計・制作契約：請負・(25)～
(29)適用、F構築・設定業務契約：請負・(30)～(32)適用、Gデータ移行支援契約：準委任・(33)～(34)適用、H運用テ
スト支援契約：準委任・(35)～(37)適用、I導入教育支援契約：準委任・(38)～(39)適用
(10) パッケージの機能要件、非機
能要件、使用許諾契約（利用条件、
保守等）の検討
(11) パッケージ候補の選定
(12) 業務要件及び適合するパッ
ケージ候補の報告書の提出
(39) 完了報告（受入れ）
パッケージソフトウェア利用コンピュータシステム構築委託契約書
重要事項説明書 J保守契
約：準委任・(14)(21)
(25)(41)適用、K運用支援
契約 ：準委任、(42)適用)
(33)データ移行
(34) 完了報告(受入れ）
(30) 構築業務
（機器・OS等の設定、納品）
(32) 検収(受入れ）
※ベンダ主体
※ユーザ主体／ベンダ支援
E ソフトウェア設計・制作契約
F 構築・設定業務契約
G データ移行支援契約
I 導入教育支援契約
H 運用テスト支援契約
J 保守契約
K 運用支援契約
(13) 受入れ
(18) 受入れ
■参照すべき規格：共通フレーム2013「2.1 企画プロセス」・「2.2 要件定義
プロセス」、JIS Q 20000 情報技術－サービスマネジメント、JIS Q 27001
情報技術－セキュリティ技術 テ システム
■チェックリスト：コンサルタントチェックリスト、セキュリティチェックリスト
■参照すべき規格：共通フレーム2013「2.2. 要件の 」・「2.3 システム開発プロセス」・「 .6
監査プロセス」、JIS Q 27001情報技術－セキュリティ技術 テ システ
ム
■チェックリスト：RFPチェックリスト、パッケージ選定チェックリスト、SaaS/ASP選定チェックリスト
■参照すべき規格：共通フレーム2013 「3.1 運用プロセス」・「2.6
保守プロセス」、 JIS X 0129-1 7.1 利用時の品質、JIS X 0161 ソフ
ス
■チェックリスト：検収チェックリスト
パッケージソフトウェア、OS、第三者ソフトウェアの使用許諾契約
パッケージソフト、OS、第三者ソフトの使用許諾契約の検討
（制限事項、保守、バージョンアップ等）
選定したパッケージソフト、OS、第三
者ソフトの使用許諾契約の締結及び
必要に応じて保守契約の締結*1
選定したパッケージソフト、OS、第
三者ソフトの使用許諾契約の締結
及び必要に応じて保守契約の締結
*1 パッケージソフトウェアの使用許諾契約及び保守は、開
発に入る段階で締結するのが一般的であるが、APIの実現
性の確認、又は外部設計で、使用許諾契約、保守契約を
締結しなければならない製品がある。使用許諾契約、保守
契約の開始については(10)で事前に検討が必要である。
*2 システム規模と要件によって見積は概算もしくは詳細に
なる。
(21) 使用許諾によってはパッケージ、
OS、ハードの導入及び保守の開始
（一部保守開始 *1）
(31) システム結合、テスト
Bパッケージソフトウェア選定支援
及び要件定義支援契約
D 外部設計支援契約
(14) 使用許諾によってはパッケー
ジ、OS、ハードの導入及び保守の
開始（一部保守開始 *1）
(24) ユーザへの見積提出
(35) 運用に関わる作業手
順の確立
IPA, 「情報システム・モデル取
引・契約書」第二版, 2020
ここだけ
38. 上流工程のレビュー
n設計審査（デザインレビュー）
• 上流工程の設計に関するレビュー
• 成果物（仕様書）のチェック
• 要件定義書のレビュー
• 外部設計書のレビュー
• 内部設計書のレビュー
• タイプ
• 顧客による設計の審査と承認
• 上位管理者（上司）による審査
と承認
• 第三者（コンサル）による評価
と問題点の洗い出し
n 参考
• 定量的品質予測のススメ 〜ITシステム開
発における品質予測の実践的アプローチ〜,
IPA, 2008
• 続 定量的品質予測のススメ 〜ITシステム
開発における定量的品質管理の導入ノウハ
ウと上流工程へのアプローチ〜, IPA,
2011
• ソフトウェア開発データが語るメッセージ
「設計レビュー・要件定義強化のススメ」,
IPA, 2017
• レビューの質の向上〜 幸せのレビュー目
指して〜, 財団法人日本科学技術連盟,
2012ソフトウェア品質保証部長の会2G,
2012
• レビューの質と価値の定量化の提案,一般
財団法人 日本科学技術連盟 SQiP研究会担
当, 2011
40. コードレビュー
nコードレビュー
• 開発工程でのコードのレビュー
• 目的
• 不具合の発見と修正
• メンバー間の理解とコミュニケーションの促
進，ノウハウの共有
• リスクと開発状況の把握
• 評価者
• レビューする人：レビュアー（reviewer）
• レビューされる人：レビュイー（reviewee）
• ピアレビュー：ピア（peer，同僚）によるレ
ビュー
• レビュアーにもレビュイーにもなる
https://pixabay.com/photos/people-looking-in-laptop-5069842/
Pixabay license
reviewer
reviewee reviewer
43. コードレビューの方法
nコードレビューで確認すること
• コードはよく設計されているか
• 機能がユーザーにとって良いもので
あるか
• UIの変更が賢明で見栄えが良いか
• 並列プログラミングが安全に行われ
ているか
• コードが必要以上に複雑になってい
ないか
• 開発者は，将来的に必要になるかも
しれないが，今は必要かどうか分か
らないものを実装していないか
• コードには適切なユニットテストが
あるか
• テストはよく設計されているか
• 開発者はすべてに明確な名前を使っ
ているか
• コメントは明確で有用であり，「何
をする」ではなく「なぜするのか」
を説明しているか
• コードは適切に文書化されているか
（通常は g3doc）
• コードがスタイルガイドに準拠して
いるか
nコーディング規約も重要
https://google.github.io/eng-practices/review/reviewer/
https://github.com/google/eng-practices
49. ライセンス
nよくある問題
• 研究・教育用はOK
• 商用利用は要問い合わせ
• ダメなときもある
n深層学習時代の問題
• コードだけでなくデータセット
にもライセンスがある
http://www.uco.es/investiga/grupos/
ava/node/26
ArUco: a minimal library for
Augmented Reality applications
based on OpenCV
https://image-net.org/about.php
About ImageNet
https://cocodataset.org/#termsofuse
COCO Dataset
50. 生成系AI時代の「データの権利」
n 画像AIの種類
• 解析系AI：画像認識や音声認識．データ自体は表に出
なかった
• 生成系AI：画像や文章の生成．データ自体が表舞台に
登場することになる
n 「データセット」のライセンス
• 頑張って収集した「データセット」を使って良いか
• LAION-5BはCC-BY 4.0なので誰でも商用利用可
• 画像生成AI「Stable Diffusion」などの開発に大きな貢献を果たした超巨大データセット「LAION-5B」とは？,
2022/12/14, Gigazine
n 「データ」の権利
• 収集された個々の「データ」を作成した個人には許
可をとってない
• 画像生成AIは新たなアート？ それとも著作権侵害？ 最前線に迫る, 2023/3/30, NHK国際ニュースナビ
• 文章・画像生成AIは著作権侵害か 訴訟に発展も, 2023/2/7, ウォールストリート・ジャーナル
• 無断でダウンロードしたデータでもAI開発に使える？ 改正著作権法を弁護士が解説, 2019/3/29, @IT
• 現状日本では合法（2019年著作権法改正第30条の4）
まるで人間のアーティストが描いたような画像を生成するAIが「アーティストの権利
を侵害している」と批判される, 2022年08月15日
https://gigazine.net/news/20220815-stable-diffusion-controversy-ai-infringes-artists/
