ソフトウェア工学(ウォータフォールモデルの流れとアジャイル開発の方法)
序
ソフトウェア工学の講義の事項とその流れをざっと
ソフトウェア設計方法のうち主にウォータフォールモデルに焦点を当て、
その上流工程である、「要求定義、分析」と、「設計」段階の流れを確認する
さらに、ソフトウェア開発のプロジェクト管理の主流である「アジャイル開発」の手法の一つであるスクラムについてもまとめる.
目次
語句とか
- ソフトウェア工学の構成軸
ライフサイクル軸、プロセス-プロダクト軸、モデル-方法-ツール軸 からなる. 構造化プログラミング
理解しやすく、品質保証や保守のし易いプログラムを書く指針. 構造を組み立てる要素として、 逐次、選択、反復 を採用し、深さ方向（インデントや入れ子）と幅方向（兄弟関係）の観点からプログラムの設計を行う考え方.
あるブロックとその縦横の隣接関係だけを注視すればプログラムの全体構造が理解できるという利点がある.データ構造
全てのデータを単にメモリセルに一次元的に並べるだけではダメプログラミングのプロセス
擬似プログラミングを使用した段階的詳細化モジュール化プログラミング
いかに妥当なモジュールを見出し、的確にそれらを分割するかに注目. 理想は構造化分析に基づいて、構造化設計で述べる指針に従うこと. しかし実際には、新たなモジュールの必要性の発見、分析、設計段階で定めたモジュール構造との食い違いから再度設計をし直すことが多い.オブジェクト指向プログラミング
どの単位をクラスとするか、良いクラス階層を以下に作るかに注目.
ウォーターフォールモデルにおける「要求分析、定義」と「設計段階」の比較
要求段階
要求段階とは、システムに対するニーズとその制約条件を整理する段階のこと
- 何を作るかを考える
- 顧客、ユーザから見える外部に焦点を当てる
- 顧客との関係における合意文書を、発注仕様書として作成する
要求獲得
- インタビューやミーティングで開発者が受注者、使用者の要求を、ドメイン知識の不足を補いながらうまく聞き出す.
- 業務フロー図やIDEF0などを使用して現行システムの分析を行う.
- 現状での問題点や、その因果関係を洗い出し、より洗練された解決策を列挙する.
- 解決策を提供することで生まれるトレードオフを考慮、ニーズに応じてどのソリューションを採用するかの意思決定を行う.
要求記述
- ここまでで目的とシステム化の対応が取れ始めるので、そのユーザとシステムのインタラクション、動作をシナリオ化する
- ノード・アーク図で要求を記述する
構造分析と仕様化 / オブジェクト指向分析と仕様化
- 構造化プログラミングの場合であれば、データフローモデル、状態遷移モデル、実体関連モデルなど、オブジェクト指向プログラミングの場合であれば、統一モデリング言語等を使ってソフトウェアシステムの構成を明確にする
形式的仕様記述
- VDM等で使用記述をさらに厳密なものにする必要
設計段階
設計段階とは要求分析とプログラミングをつなぐ段階のことで、各要求がソフトウェアのどの部分に割り当てられるかを決定する. ソフトウェアの全体構造とその組立を記述する「概略設計」と、各コンポーネントの詳細な振る舞いを記述する「詳細設計」 に大きく分けることができる.
要求割り付け
前の要求分析、定義の段階で獲得された要求を、ソフトウェアのどの部分に対応させるかを決定する.
割当られる各コンポーネントはビューと呼ばれる. 主なビューは以下
- 機能とデータ構造
- プロセスの構造
- システムの構成
- システムの配置
構造化設計 / オブジェクト指向設計
機能指向のデータフローモデルを中心として構造化分析をモジュール化プログラミングへと結びつける「機能指向設計」と、ファイル内のデータ構造や、
データベースの情報構造に注目して、それらを処理する機能へプログラムを設計する「データ中心設計」などに沿って、全段階の要求をプログラムの各部分に割り当てていく.
オブジェクト指向プログラミングの場合であれば、複合構造図などを使って、オブジェクトの振る舞いを決定していく.
その他
上記の他にも、
- ソフトウェアアーキテクチャ
一般的なプレゼンテーション層、ビジネス層、データ層に分割する三層構造、Ruby on RailsとかSails.jsで流行りのMVCアーキテクチャなど - デザインパターン
オブジェクト指向プログラミング等でオブジェクトの詳細、関係性を整理する
について詳細に定める必要もある.
スクラムによるプロジェクト管理 (アジャイル開発の手法)
そもそもアジャイル開発とは
短い期間で開発、顧客を招いてのテストを行うというサイクルを反復的に行う手法. 開発の初期段階で設計ミス等に気づくことができるため修正範囲が限定され、修正が容易であり、 顧客の要望を忠実に取り込み、その変化にも柔軟に対応できるという利点がある.
スクラムとは
スクラムはアジャイル開発における手法の一つで、共通の目標に到達するために チームが一体となって開発を行うこと. そのためにはチーム内のメンバー同士の緻密なコミュニケーションが必要となる.
スクラムのチーム構成
製品開発にあたっては、
- チーム
5人から9人で形成される開発チーム. 作業プロセスと結果の責任をもって、自らでチームを管理する. - プロダクトオーナー
顧客の意志の代表として、プロジェクトに問題がないことをビジネス視点で保証し、顧客の要望をプロダクトバックログに反映させる. - スクラムマスター
スクラムのフレームワークが開発に適用されていることを保証する. 主な作業はチーム内外の組織間の調停と、妨害要因の排除である.
がそれぞれの役割を果たす.
バックログの作成
プロダクトバックログ
製品に必要な要素に優先順位をつけた一覧. 各項目に対して、チームが難易度(コスト)の見積もりをつけ、プロダクトオーナーが顧客の観点から価値を見積もる.
スプリントバックログ
スプリントで実現する項目の一覧. 各項目については、スプリント完了時にコーディング、テスト、ドキュメンテーションが完了していることが要求される. スプリントバックログはプロダクトバックログの各項目を管理可能な単位に細分化したもので、難易度についても見積もりを行う必要がある.
プロジェクトの区分
プロジェクトを最長4週間までの区間に分割し、それぞれをスプリントとし、スプリントバックログにまとめられた項目の完了を目標とする.
具体的な工程
計画ミーテイング
プロダクトオーナーが、プロダクトバックログを確定させる. この際に過去の開発の経験から、優先順位や項目の消化ペースを正確に予測し、項目を作成することが大切である. また、プロダクトオーナーが提示したバックログに対して必ずチームがフィードバックを行い、そのフィードバックを活かし、チームと合意の上でバックログを作成する必要がある. また、スプリント終了時の目標としてスプリントゴールも定める.
スプリント
開発の主な工程. 開発、まとめ、レビューの繰り返し.
スプリントレビュー
開発したソフトウェアのレビュー. レビューには顧客、マネージャー、開発者、営業、マーケティング開発者が参加する. また、必要に応じてバックログに項目を新たに追加する. スプリントとレビューの繰り返しは顧客が十分と判断するまで繰り返される.
スクラム会議
スクラムマスターがチーム全員に、
のみを質問する. 問題の発生の報告があればスクラムマスターは即座に決断を下し、それが外的要因によるものであればその解決に責任を持つ.
クロージャ
最終でバッグ、販促を行う最終段階. これが終了すればプロジェクトは終了である.
制御 (control)
通常ブラックボックスになりがちな開発工程を管理するための仕組み.
例えば、
