ソフトウェア工学
システム開発プロジェクト応用
神講義らしい
https://www.youtube.com/playlist?list=PLbBGNsln3DxR3yFgCPvj40_nV-k5buTvz
授業めも１
第1講 ドメイン分析・要求分析
効率よく高品質なソフトウェア製品を開発・運用するための活動を対象とする学問であるソフトウェア工学を学ぶ
変化が激しく多種多様なソフトウェア開発・運用において原則な既存技術を踏まえつつ適切なアプローチを定めていくための素養を身につける
ソフトウェア工学概論
良い本
モデリングとプロセス
要求→仕様→設計→実装
モデルの例として、ウォーターフォールやV字がある
上流でミスるとコストがヤバいので重要
UML
手続き型プログラミングにおける問題
・データと機能の暗黙的な依存関係
・アプリケーションを分割して生まれた再利用性の低い手続き
オブジェクト指向プログラミング
・データとそのデータに対する機能をオブジェクトとして部品化
・メッセージングによるカプセル化された機能の利用
UML：Unified Modeling Language
図形式によるオブジェクト指向モデリング
クラス図は、ひこうきの予約はどのようなシステムで行われているかを書かれている
これもオブジェクト指向
ドメイン分析・要求分析概観
要求に問題があると全開発費の30~50%を消費
UMLによるモデリング・分析
Domain modeling and analysis
実世界の問題領域において構成要素となる概念やその関係について理解、表現する
astahツール
航空券予約業務に関する業務のモデリング
ゴール指向要求分析
ユースケースを得るまでの段階が本来重要なはず
ゴールを分析すべき
一般的なゴールモデルの概念
一般的にはDAG
まとめ
ドメイン分析・要求分析
プロジェクトの成否に大きく関わる最も重要な活動
第2講 システム分析・設計
システム分析
システム分析
要求およびドメインのモデルに基づき機能をどうシステムとして実現するかに関するシステムモデルを構築する
ロバストネス分析
システム分析の代表的な手法
1 各ユースケースにおいて、システムによる実現の流れを分析、定義する
2 得られたユースケースごとの定義をシステム全体へと統合し、各構成要素が提供する操作や構成要素間の関係を整理、確認する
ロバストネス分析における3種類のクラス
システムの構成要素として下記の３つを考え、各ユースケースの実現方法を抽象的に定める
・バウンダリ：アクターとシステムのインターフェースとして働くクラス
・コントロール：バウンダリからの刺激に応じ、エンティティや他のコントロールに働きかけるクラス
・エンティティ：情報を維持的あるいは恒久的に保存するクラス
設計原則
どのように要求を実現するかの本質を定めていく
アーキテクチャレベルの設計と部品レベルの設計
・カプセル化：構造・振る舞いをグループ化して、抽象的な要素として定義する
・情報隠蔽：部品の実証詳細をクライアントから隠蔽する
・抽象化：
・モジュール化
・分割統治
・凝集・結合の考慮
・関心ごとの分離：異なる互いに無関係な責務は異なる部品に割り当てられるなど分離されるべき
アーキテクチャ設計
構成される部品、部品が持つべき特性、部品間の関係を定めたもの
アーキテクチャパターン
・多層アーキテクチャ
・MVCアーキテクチャ：気づいたらこれを使っていることが多い
・ブローカーアーキテクチャ
詳細設計
アーキテクチャ設計後、各部品の設計へ
デザインパターン
頻出する設計の解法を汎用かし再利用できるようにしたもの
カタログの形で整理される
第3講 型式手法
V&Vと形式手法
正当性確認と妥当性確認のこと
ここまで扱ったモデルはスケッチ的
形式手法
数理論理学に基づき、品質の高いソフトウェアを効率よく開発するための科学的系統的アプローチの総称
文法と意味論が数学的に定まったモデルを活用
OCL
UMLにおける制約を記述するための形式言語
プログラム検証
正当性は仕様に対して相対的に決まる
手続き型プログラムの場合、事前条件と事後条件を考える
ホーア論理
やったなー
静的解析
プログラムぞ実行せずに分析・検証
形式仕様記述
機能使用や設計を形式的に記述、検証するアプローチ
機能使用全体を表せるように表現力が高く、実装詳細を捨象するためプログラミング言語より抽象的な言語を用いることが多い
定理証明を用いて検証する
モデル検査
状態遷移を網羅的に探索し、検証対象の性質が成り立つかどうかを検証する技術
特に並列システムにおいて、特定の実行パスでしか顕在化しないデッドロックや排他制御・同期制御の誤りを検出できる
第4講 テスト
テスト概要
ソフトウェアを調べ、不具合、バグまたは障害を発見するために故障を発生させる
様々な観点からの分類
動的テスト
プログラム実行
静的テスト
インスペクション、ウォークスルー
頭の中でテストケースに対するプログラム実行を追う
ホワイトボックステスト
プログラムの内部構造を踏まえてテストを設計
ブラックボックステスト
プログラムの内部構造は意識せず、仕様に基づいてテストを設計する
工程
ユニットテスト
結合テスト・統合テスト
システムテスト
受け入れてすと
ホワイトボックス・テスト
論理網羅・被覆率
命令網羅
分岐網羅
条件網羅
ブラックボックス・テスト
同値分割
特定の振る舞いにつながる入力値を同値クラスとしてまとめる
境界値分析
組み合わせテスト
複数要員に対する特定の値の組み合わせにおいて不具合が顕在化する可能性がある
直交表
第5講 保守・管理
ソフトウェア保守
納入後の開発ソフトウェアを維持・管理する作業
非常に大きな役割を果たす
全体の2/3のコストとも呼ばれる
機能変更において最も重要なこと：追跡・理解
→変更影響分析
１、必要な情報をあらかじめ記録しておく
２、リーバスエンジニアリングにより必要な情報を抽出する
進捗がやばい時はドキュメントを書かないので、多くの場合でリバースエンジニアリングをすることが多い
構成管理
ソフトウェアシステムにおける変更を追跡し、管理する
gitなどで実装されるバージョン管理より広い概念を指すことが多い
回帰テスト
以前のバージョンより悪くなっていないかを調べる
これは重要
というのも、どこかをいじったら他のところが悪くなっていることがあるので
制御フローグラフ
制御依存関係
データ依存関係
リファクタリング
改善保守：管理しやすさや再利用性などの向上
予防保守：将来の使用法で起きうる問題などに対処
将来は見越した設計は難しいのでリファクタリングは重要
Bad Smells：潜在的な問題を示唆しうる兆候
プロジェクトマネジメント
コスト見積もり手法
メトリクス：プロセスあるいは内部成果物・最終成果物に関する様々なメトリクスを計測・監視し、経験的知識を利用し、様々な活動に反映
第6講 アジャイル開発・様々なパラダイム
アジャイルソフトウェア開発概要
古典的なアプローチに対する反省
計画指向・定形化指向すぎた
変化・適応をあまり想定していない
コードが得られるまでの時間が長い
アジャイルマニフェスト
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
とにかく動くものを作れ！！
時代の変化は早い！
チームが自己組織化されている
個人が最終決定権を持つので、責任感を持ってやる必要がある
最小限のソフトウェア開発を行う
アジャイルプラクティス
アジャイルソフトウェア開発は原則とそれを達成するための実践的ノウハウ・技術の集合として実践していく
今までは、コード設計に関するパターンだが、これは開発者がどのように開発を進めていくかというパターン
その中でもいろいろなパターンがある、自分たちで作っていくべき
かんばん
タスクの実施状況を管理するボードを用いるとともに並行実施数の制限を明記・実施する
ベロシティ計測
イテレーションあたりの完了ストーリー数をベロシティとして計測し、見積もりに用いる
プランニングポーカー
初期には開発対象の知識が少なく、参加者複数人の見積もりを考慮して、見積もりを行う必要がある
テスト駆動開発
実行可能なテストコードを定義し、それをパスするコードの開発を行うということを小さい単位で繰り返す
とにかくテストをパスするコードを書き、そのあとリファクタリングするという思想も強い
その他のプラスクティす
朝礼ミーティング
ふりかえり
コーディング規約
共通の部屋
ニコニコカレンダー
ビヘイビア駆動開発
まとめ
アジャイルソフトウェア開発
計画・定形化への偏りへの反動、変化が激しい時代への対応として１つの主軸となる考え方へ
プロダクトオーナー：顧客の立場からプロジェクト参加者
ユーザーストーリ：ユーザー視点で要求を明文化
スクラムマスター：チーム内外のファシリテーション、外部妨害対処など
スプリント：反復の単位（１週間〜）
バックログ：やりたいこと・やるべきことの一覧
ベロシティ：開発の速度
第7講 先端研究トピック
アスペクト指向
関心ごとの分離が大切
横断的関心ごとをアスペクトとして捉え、分離して部品化するための仕組み
プログラミングフレームワークとしてAspectJ
ソフトウェアプロダクトライン
類似するプロダクトの系列をまとめて体系的に開発する考え方
ドメインエンジニアリング：全プロダクトに共通する部分、個別に定まる部分を区別して、各プロダクトの開発に用いるコア資産を構築
アプリケーションエンジニアリング：コア資産に基づいて基本的に選ぶだけの形で効率的に各プロダクトを構築
プロダクトライン管理
コア資産と各プロダクトが連動して変化していくような仕組み作りが必要
モデル駆動開発
モデル変換を通して開発を行う
CIM：ビジネスおよびドメインに関するモデル
PIM：実装プラットフォーム非依存のシステムモデル
PSM：実装プラットフォーム依存の設計モデル
まとめ
特に再利用性と変化への対応を意識し、様々なパラダイムが提案され続けている
自動テスト生成
ある論理式が充足可能であるとき、その論理式を真とする解釈が存在する
SATソルバー
論理式が充足可能であるか判定する問題
SMTソルバー
SAT問題に整数など特定範囲の知識を扱うよう拡張した問題を解くツール
CBMC
C/C++プログラムの有界モデル検査ツール
SAT/SMTソルバーへの変換に基づく検査
Verilog連携、テストスイート生成などの付加機能
Concolic Testing
Symbolicだけでやるとスケールしない
具体値での実行と組み合わせ
サーチベースドソフトウェア工学
ソフトウェア工学における様々な問題を、最適化問題に帰着し、メタヒューリスティックで解くアプローチ
自動テスト生成、自動設計、取り組む要求の選択、不具合修正などなど
ここ10年で盛んに研究され、人が作ったものよりも良いテストスイートを10秒で生成するなど
Facebookが使っているとの発表あり
自動プログラム修正
ここしばらくSE研究分野ではホットトピック
雑には、プログラムいろいろいじってみてテスト全部通ればそれが修正案ということ
うまくいじってみる技術がきもである
ソフトウェアリポジトリマイニング
実験あるいは現場のデータから知見を得ることを重視したアプローチ
githubや組織内リポジトリに対するデータマイニング
機械学習工学
演繹的システム開発と帰納的システム開発
演繹的システム開発：計算や判断を行うための知識・規則を人が決めてプログラムという形で書き下す
帰納的システム開発（機械学習）：計算や判断を行うための知識・規則を訓練データから獲得し生成する
機械学習は従来のテストが通用しない
まとめ
盛んな研究が行われている
ソフトウェア工学って名前のめちゃ分厚いやつ
「ソフトウェア工学」
1章 なぜソフトウェア工学か
2章 プロセスのモデル化とライフサイクル
3章 プロジェクトの計画と管理
4章 要求分析
5章 システム設計
6章 プログラミング
7章 プログラムテスト
8章 システムテスト
9章 システムの出荷
10章 システムの保守
11章 製品、プロセス、資源の評価
12章 予測、製品、プロセス、資源の改善
アジャイル開発メモ
1 アジャイル開発とは？スクラムとは？
アジャイル開発をするための手法がスクラム
代表的なフレームワークがスクラム
ウォーターフォールみたいなやり方だと失敗する可能性が大きい
製品リリース後に要求された機能は使わないものが多い
アジャイルは3~7人ぐらいがよい
連携が密になる
このチームをスクラムチームという
アジャイルマニフェスト
1 プロセスやツール < 個々と対話
2 包括的なドキュメント < 動作するソフトウェア
3 契約交渉 < 顧客とのコラボレーション
4 計画に従順 < 変更への対応
アジャイルの12の原則
1 顧客満足
早期かつ継続
開発のあらゆる段階で変更を歓迎する
動作中のソフトウェアを頻繁に納品する
2 品質
動くソフトウェアが最高
技術的に優れ、柔軟性と拡張性がある設計に注意
シンプルさを求め、無駄なく作れる量を最大限にすることが本質
3 チームワーク
ビジネス側と開発者は日々一緒に働く
意欲に満ちた人々でプロジェクトを構成する
face to faceで話をする
4 プロジェクト管理
持続可能で一定のペース
最強のアーキテクチャ・要求・設計のために自己組織的なチームづくり
チームがもっと効率を高めることができるかを定期的に振り返り、やり方を最適に調整していく
2 アジャイル開発を選ぶ理由
3 アジャイルフレームワーク
Scrum
Hybrid
Scrumban
XP
Kanban
Lean
4 スクラムの理想的な開発環境とツール
5 スクラムの役割
6 チーム構成
7 アジャイル開発の進め方