現代的システム開発概論

by Recruit Technologies

Slide 1

Slide 1 text

現代的システム開発概論 (v1.0) 株式会社ウルフチーフ川島義隆

Slide 2

Slide 2 text

プロジェクトを進める上での基礎知識

Slide 3

Slide 3 text

プロジェクトとは何か? プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務 (PMBOKの定義) ● 特定の成果を達成するための組織 ● 期限が限定されている (有期性) ● 同じものはない (独自性) ● 相互に関連する作業の調整がなされる(相互関連性)

Slide 4

Slide 4 text

マネジメントのことが好きじゃない/苦手でも、プロジェクトマネージャと対等に話するために PMBOKの内容くらいは学んでおいたほうが良い …が、退屈な内容であることは変わりない私はこの本で分かった気になった

Slide 5

Slide 5 text

マネジメントライフサイクル ● 計画: QCDSを決める ● 実行: 計画にしたがって作業をする ● 監視: 計画と実績のズレを測る ● コントロール: ズレに対応する

Slide 6

Slide 6 text

計画 Plans are useless, but planning is indispensable. – Eisenhower 計画そのものは刻一刻と状況が変わりゆくプロジェクトにおいては役に立たない。どんなライフサイクルを採用しようとも、再計画を想定しておかなければならない

Slide 7

Slide 7 text

プロジェクト計画だいたい次のようなことを書く ● プロダクトの目的 ● 履歴 ● リリース基準 ● プロジェクトの目標 ● プロジェクトの編成 ● スケジュールの概要 ● プロジェクトの人員配置(人員配置の計画) ● スケジュール案 ● リスク一覧

Slide 8

Slide 8 text

ローリングウェーブ計画法 ● 段階的に詳細化する、計画策定の方法。 ● 直近の作業は詳細に、先の作業はおおざっぱに計画する。 ● 初期段階では、ワーク・パッケージの要素分解はマイルストーン・レベル。 ● プロジェクトが進行し、詳細が判明するにつれて、ワーク・パッケージはアクティビティに分解される。

Slide 9

Slide 9 text

リリース基準プロジェクトにとって重要なことは何か? – リリースの日程 – 機能セット – 欠陥の少なさ – 品質特性など、これを満たしたらリリース可能という基準を定める。

Slide 10

Slide 10 text

トレードオフ・スライダーを使って会話するとよい

Slide 11

Slide 11 text

リリース基準の書き方はSMARTに ● 具体的 (Specific) ● 計測可能 (Measurable) ● 達成可能 (Attainable) ● 現実的 (Relevant) ● 追跡可能 (Trackable) Time Boundとされることが多いが、Manage It!で使われているTrackableの方が意味合いがハッキリする

Slide 12

Slide 12 text

RiskとIssueの違い Risk Issue 未来にフォーカス現在・過去にフォーカスプロジェクト期間中に、主要なリソースが居なくなるかもしれないチームメンバが離任する。最終日は✕✕なので、引き継ぎを… チームメンバがプロジェクトの大事な期間に休暇をとるかもしれない。チームメンバが休暇を取ったとき、他の誰も対処できないことがある。予期せぬ要求の変更があるかもしれないプロジェクトのスコープに追加すべき機能が見つかった影響分析すると、プロジェクトのスケジュールを遅延させる問題が見つかるかもしれない。影響分析の結果、プロジェクトを1 週間後ろ倒ししそうな新たな問題が2つ見つかった。マトリックス型の組織でプロジェクトを進めると、現場が混乱し生産性が低下するかもしれない。我々の組織はマトリックス型なので、PMの権限と説明責任について混乱を減らすために、それを明記した文書を作成する必要がある。 https://www.linkedin.com/pulse/issue-risk-what-difference-sanjeev-kulkarni/

Slide 13

Slide 13 text

RiskはIssueとは使い方が違う。 – 対処予算の確保 – エグゼクティブラインを動かす

Slide 14

Slide 14 text

リスク対応戦略

Slide 15

Slide 15 text

リスクの主観的価値の非線形性質問1:あなたの目の前に、以下の二つの選択肢が提示されたものとする。選択肢A:100万円が無条件で手に入る。選択肢B:コインを投げ、表が出たら200万円が手に入るが、裏が出たら何も手に入らない。

Slide 16

Slide 16 text

質問2:あなたは200万円の負債を抱えているものとする。そのとき、同様に以下の二つの選択肢が提示されたものとする。選択肢A:無条件で負債が100万円減額され、負債総額が100万円となる。選択肢B:コインを投げ、表が出たら支払いが全額免除されるが、裏が出たら負債総額は変わらない。

Slide 17

Slide 17 text

プロスペクト理論

Slide 18

Slide 18 text

発生確率の主観評価の難しさブラックスワン 1697年まではヨーロッパでは真実だった。「白鳥は白い」経験に基づく知識現在の知識の限界　→　分からないことが分からない

Slide 19

Slide 19 text

ブラックスワンの特徴 ● 予測不能 ● 非常に強いインパクトを持つ ● 実際に起こると後付けで説明がなされ、偶然ではなく、最初からわかっていたような気にさせられる (後知恵バイアス)

Slide 20

Slide 20 text

失敗を避けるのではなく失敗を前提としてシステムを設計する Availability := MTTF MTTF + MTTR https://www.slideshare.net/ufried/patterns-of-resilience Werner Vogels(Amazon CTO): “Everything fails all the time” MTTFを長くする → Robust MTTRを短くする → Resilient

Slide 21

Slide 21 text

ブラック・スワン提唱者のタレブ博士のその次の作品Antifragile(反脆弱性)は非常に面白いし、ソフトウェアの世界でも重要な概念になりつつあるので横道ですが話しておきます

Slide 22

Slide 22 text

プットオプションとリーマンショック http://www.jsda.or.jp/manabu/qa/derivative05.html

Slide 23

Slide 23 text

https://taylorpearson.cdnoptimus.com/wp-content/uploads/2013/05/Convexity-and-Concavity.png 変動幅が大きいと儲かる (長期投資) 変動幅が小さいと儲かる (短期投資)

Slide 24

Slide 24 text

Fragile 変化に対して弱い・損失が大きい仕組み ● 後戻りの計画・その分の予算確保がないウォーターフォールのプロジェクト ● プロビジョニングが十分でないシステム (ex. 30分 2000PVでダウンする図書館システム) ● 例外のハンドリングが雑なアプリケーション

Slide 25

Slide 25 text

Robust 変化に対して、十分強い仕組み (フラジャイルの裏返し) ● よく計画されたウォーターフォールの開発プロジェクト ● 急激なアクセス増や異常なデータファイルに対しても、安全に処理できるアプリケーション ● 例外を適切にハンドリング出来ているコード

Slide 26

Slide 26 text

Resilient 大きな変化に対し、一時的にシステムのパフォーマンスを落としてもすぐに復旧できる仕組み

Slide 27

Slide 27 text

Antifragile 変化が起これば起こるほどメリットがある仕組みストレスが増せば増すほど強くなる仕組みそんなことが可能なのでしょうか?

Slide 28

Slide 28 text

Benefit Change Cost Antifragile Resilient Robust Fragile

Slide 29

Slide 29 text

ダモクラスフェニックスヒドラ Fragile Robust (Resilient) Antifragile ちょっとしたことで上に吊るされた剣が落ちてきて死亡死んでも何度でも甦る 1つ首を切ると、 2つはえてくるイメージ図

Slide 30

Slide 30 text

トライアドのフレームワーク特になにもしない業務に関係ないものも、アレコレつまみ食いする業務で必要なものを勉強する Antifragile Robust Fragile 世の中の事象を、Fragile/Robust/Antifragile の3つ組(トライアド)に沿って考えると面白い。エンジニアの技術学習のトライアド

Slide 31

Slide 31 text

Netflix Chaosシリーズ意図的に本番障害を起こし、何が起きるかをモニタリングする Chaos Monkey: EC2インスタンス単位で落とす Chaos Gorilla: AZ単位で落とす Chaos Kong: リージョン単位で落とす Latency Monkey: 1Microserviceのレスポンスを遅延させる https://www.slideshare.net/JoshEvans2/embracing-failure-reinvent-2014

Slide 32

Slide 32 text

https://www.youtube.com/watch?v=ZMbqbXxRthE&index=40&list=PLRsbF2sD7JVqk90s0ogP\_dcfM9T-y1DRm

Slide 33

Slide 33 text

WBS

Slide 34

Slide 34 text

WBS作成のうえで適用されるルール ● 100%ルール ● 8/80ルール ● 7×7ルール https://www.itmedia.co.jp/im/articles/1001/27/news103.html

Slide 35

Slide 35 text

スケジュールタスクスケジューリング見積「Manage It!」での定義スケジュール

Slide 36

Slide 36 text

スケジューリングと見積の違い ● スケジューリング – タスクの依存関係を明らかにし、順序付けを行うこと ● 見積 – あるタスクが完了するのにどれくらい時間がかかるかを推定すること

Slide 37

Slide 37 text

タスクの依存関係 A B Finish to Start Start to Start Finish to Finish Start to Finish A B A B A B Bが終わるまでAが完了にならない Aが完了しないとB が始められない Aを始めるまでBが始められない Aを始めないとBが完了できない

Slide 38

Slide 38 text

Finish-to-Start A B A:認証ライブラリを作る B:認証ライブラリが返すユーザオブジェクトを使って、検索するプログラムを作る

Slide 39

Slide 39 text

Start-to-Start A B A:ユーザマニュアルを書く B:ユーザマニュアルをレビューする

Slide 40

Slide 40 text

Finish-to-Finish A B A:検索機能のテストを書く B:検索機能を作る

Slide 41

Slide 41 text

問題 A B C D A:認証モジュール作る (3d) B:認証モジュールをテストする (2d) C:認証ライブラリが返すユーザオブジェクトを使って、検索するプログラムを作る (3d) D:検索機能をテストする (2d) 以下のスケジュールを短縮することができるでしょうか?

Slide 42

Slide 42 text

回答例 A C D A:認証モジュールインタフェース作る (1d) A’:認証モジュール実装作る(2d) B:認証モジュールをテスト作る (2d) C:認証ライブラリが返すユーザオブジェクトを使って、検索するプログラムを作る (3d) D:検索機能をテスト作る (2d) A’ B

Slide 43

Slide 43 text

ポイント ● タスクを分解する – 抽象概念を作り出すのがポイント ● 2つのタスクが本当にFinish-to-Startかを考える ● リソースに余裕があればタスクを割り当てて、工期を短縮できる (リソース効率を上げる)

Slide 44

Slide 44 text

スケジューリングの技法 ● トップダウンスケジューリング – まずマイルストーンを置き、それを支えるタスクをひねり出す ● ボトムアップスケジューリング – 特定のタスクから始め、それに連なるタスクを洗い出しマイルストーンをひねり出す。 – 漸進型ライフサイクルで有用 ● インサイドアウト – 自分(たち)の分かっていることをマインドマップに書き出し、そこからタスクとマイルストーンを作る ● ハドソン・ベイスタート – まず小さくプロジェクトを始めてみて、そこでの理解をもとにタスクやマイルストーンを作る

Slide 45

Slide 45 text

計画の種類 ● フェーズベースの計画 – 特定の部門の人たちからなるチームが、プロジェクトの各部の責任を追う。 – 責任を負う人たちが「終了」と宣言すれば、そのフェーズが完了 ● 成果物ベースの計画 – 成果物に基づいたマイルストーンを置く – 成果物の完成に各チームが集中できるようになる一方、マイルストーンが守られずグダグダになるリスクがある。

Slide 46

Slide 46 text

https://www.slideshare.net/yusuke/itaws これはあるあるだけれども、ウォータフォールが全てそうだというわけではなくフェーズベースの計画が適してないのに、そうしてしまったという場合の失敗

Slide 47

Slide 47 text

見積プロジェクトが大失敗する原因は2つある – 見積ミス – 仕様を凍結できない “見積の大部分は、非現実的で単なる希望にすぎない。さらに悪いことに、不正確な見積を改善するすべがないのだ”ソフトウエア開発 55の真実と10のウソより

Slide 48

Slide 48 text

見積の技法 ● 経験ベース – 類推法 – デルファイ法 ● アルゴリズムベース – Function Point – Use Case Point

Slide 49

Slide 49 text

見積の正確度と精度正確度(Accuracy) 精度(Precision)

Slide 50

Slide 50 text

未知の領域の見積タスクが大きいとだけ分かっていて、どれくらい大きいかを見積もる適切な方法が見当つかないスパイクタスクの情報を得るために作る小さなタイムボックス

Slide 51

Slide 51 text

Five Orders of Ignorance 0OI: 全部分かっている「答え」を持っている。あとは書き写すだけで完成する。 1OI: 分からないことが分かっている答えを得るための「質問」を持っている。 2OI: 分からないことが分からない「質問」を持たない状態。決定的な答えを引き出すための「質問」ができない。 3OI: 分からないことが分からない状況を何とかする術を知らない 2OI→1OI→0OIと進んでいくためのプロセスがない状態です。 4OI: 無知にレベルがあることを知らない http://qiita.com/seki_uk/items/4001423b3cd3db0dada7

Slide 52

Slide 52 text

ベルトとサスペンダー方式 ● 見積の正確度をあげることができないことへの妥協策 – a) 経験者の意見をベースにした見積 – b) ある程度の正確度を期待できるアルゴリズムで算出した予測値の2つを使って予測する。

Slide 53

Slide 53 text

見積に関するおかしな真実 ● ソフトウェア開発の見積は、プロジェクトの開始に実施する場合が非常に多い。これだと要件定義が固まる前に見積ることになり意味がない。 ● プロジェクトが進むにしたがって見積を調整することはまずない。したがって不適切な時期に不適切な人間が実施した見積を修正することはほとんどない。 ● 見積精度がいい加減だと、実際のプロジェクトが見積どおりに進まなくても、まったく気にならないはずだが、現実にはみんな気にする。

Slide 54

Slide 54 text

ソフトウェア開発ライフサイクル要件定義設計実装コーディングテストデプロイ保守

Slide 55

Slide 55 text

開発ライフサイクル種類ライフサイクルの例長所および成功に必要な条件プロジェクトの優先順位逐次型ウォーターフォール、フェーズゲート ● コストのリスクを管理できる (経営陣がフェーズゲートを使用する場合) ● システムアーキテクチャをよく理解できている ● プロジェクトの過程で要件が変動しない 1.機能セット 2.欠陥の軽減 3.リリース期日反復型スパイラル、進化的プロトタイピング、RUP ● 技術的リスクを管理できる ● 要件が進化し続ける 1.機能セット 2.欠陥の低減 3.リリース期日漸進型スケジュールに応じた設計、段階的納品 ● スケジュールのリスクを管理できる ● 多少の要件の変更を吸収できるが、アーキテクチャに影響を与える変化には十分対応できない 1.リリース期日 2.欠陥の低減 3.機能セット反復漸進型アジャイル ● スケジュールのリスクと技術的リスクの両方を管理できる ● すべてのメンバが同一サイトで作業を行える ● 統合チーム以外では円滑な進行が難しい 1.リリース期日 2.機能セット 3.欠陥の低減場当たり型 Code and Fix なし 1.リリース期日 2.機能セット 3.欠陥の低減

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

逐次型ライフサイクル逐次型ライフサイクルを選択可能な条件 ● 技術的リスクが小さい ● スケジュールリスクが小さい ● プロジェクトチームが安定している ● 要求変動リスクが小さい逐次型ライフサイクルで対処できるリスク ● 機能セット ● 何をいつ行うのかが分かる ● コストのリスク

Slide 58

Slide 58 text

逐次型ライフサイクルの隠れたリスク ● アーキテクチャ上のリスク – BDUFに陥る ● テストのリスク ● スケジュール上のリスク https://enterprisezine.jp/iti/detail/2392

Slide 59

Slide 59 text

反復型ライフサイクル ● 代表的なプロセス – スパイラル – 進化的プロトタイピング ● 反復型ライフサイクルによって対処されるリスク – 頻繁に変更される要件 – 技術的なリスク

Slide 60

Slide 60 text

反復型ライフサイクルのリスク ● スケジュールのリスク ● コストのリスク – 製品の最も重要な部分でなく、製品の最もリスクを伴う部分を最初に実装することを前提としている。

Slide 61

Slide 61 text

反復型ライフサイクルとアジャイルの違いアジャイル反復型イテレーション期間は一定イテレーション期間に制限はないイテレーション終わりには機能を完成させるイテレーション終わりに必ずしも完成している必要はない

Slide 62

Slide 62 text

漸進型ライフサイクル顧客と頻繁にやり取りせず、機能毎に実装を行う機能チームを作れる場合に向いている。 (日本の比較的大規模開発で独自進化を遂げている、五月雨式ウォータフォールはこれに近い) ● 漸進型ライフサイクルによって対処されるリスク – スケジュール上のリスク – プロジェクトチームの変更 – 要件の変更

Slide 63

Slide 63 text

漸進型ライフサイクルのリスク ● アーキテクチャ上のリスク – 機能の開発順序を見誤ると、後回しにした機能によってアーキテクチャを変更せざるを得ないことがでてくる ● 要件の変更 – 以前に開発済みの機能を変更したくなった場合、チームの作業が増える

Slide 64

Slide 64 text

アジャイルライフサイクル ● アジャイルライフサイクルによって対処されるリスク – スケジュール上のリスク – プロジェクトチームの変更 – 要件の変更 – コストのリスク

Slide 65

Slide 65 text

アジャイルライフサイクルのリスク ● プロジェクトの優先順位を経営者が決定できない ● 要件について意思決定する必要のある人物が決定できない ● プロジェクトのスタッフが固定化してしまう

Slide 66

Slide 66 text

プロジェクトの時間 = 開発時間 + アーキテクチャとリスク削減時間 + やり直しの時間走り出すまでにどれくらい全体の設計を考えておくべきか? Making Software, How Much Architecting Is Enough?

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

V&V ● Validation: 正しいシステムを作っているか? ● Verification: システムを正しく作っているか?

Slide 69

Slide 69 text

V-Model 要件定義外部設計コーディングシステムテスト内部設計単体テスト結合テスト Validation Verification Verification

Slide 70

Slide 70 text

ソフトウェアの品質機能性信頼性使用性効率性保守性移植性アーキテクチャ設計非機能要求 (NFR) 品質特性アーキテクチャパターン

Slide 71

Slide 71 text

品質特性シナリオ成果物 (Artifact) 環境 (Environment) レスポンス (Response) レスポンス計測 (Response Measure) 刺激発生源 (Source of Stimulus) 刺激 (Stimulus) Software Architecture in Practice より

Slide 72

Slide 72 text

可用性のケース成果物環境レスポンスレスポンス計測刺激発生源刺激ヘルスチェックヘルスチェックサーバ無応答プロセス平常状態ダウンタイムなし運用が継続できる

Slide 73

Slide 73 text

品質特性シナリオの例平常状態において、ヘルスチェックが1回無応答状態になっても、そのサーバは適切に切り離されサービス全体としてはダウンタイムなしに処理継続されること Environment Source of Stimulus Stimulus Artifact Response Measure Response

Slide 74

Slide 74 text

可用性の戦術 Availability Tactics 異常の検知異常状態からのリカバリ異常状態の防止切り離しトランザクション予測モデル例外防止再起動準備と修復縮退スペア例外ハンドリングロールバックリトライデグラデーションシャドウモード再同期再起動レベルグレイスフルリスタート ping/echo 監視ハートビート例外検知自己診断

Slide 75

Slide 75 text

性能の戦術 Performance Tactics リソース要求のコントロールリソースの管理リソースを増やす並列化する計算リソースの複数コピーをもつデータの複数コピーをもつキューサイズを制限するリソースをスケジューリングするサンプリングレートをコントロールするイベントレスポンスを制限するイベントに優先度をつけるオーバーヘッドを減らす実行時間を制限するリソース効率をあげる

Slide 76

Slide 76 text

品質特性間のトレードオフ可用効率柔軟完全相互運用保守移植信頼再利用堅牢テスト使い勝手可用＋＋効率 ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ 柔軟 ➖ ➖ ＋＋＋＋完全 ➖ ➖ ➖ ➖ ➖ 相互運用 ➖ ＋ ➖ ＋保守＋ ➖ ＋＋＋移植 ➖ ＋＋ ➖ ＋＋ ➖ 信頼＋ ➖ ＋＋＋＋＋再利用 ➖ ＋ ➖ ➖ ＋堅牢さ＋ ➖ ＋＋テスト＋ ➖ ＋＋＋＋使い勝手 ➖ ＋ https://msdn.microsoft.com/en-us/library/bb402962.aspx

Slide 77

Slide 77 text

第1部まとめプロジェクトマネジメントの最大誤謬ソフトウェア開発で最も重要なことは、プログラマが使うツールや技法ではなく、プログラマ自身の質である。

Slide 78

Slide 78 text

開発フェーズ毎の極意

Slide 79

Slide 79 text

ここから先は、ワークショップベースで各開発プロセスの極意を体験していきます

Slide 80

Slide 80 text

要件定義

Slide 81

Slide 81 text

「顧客が本当に望んだもの」とズレる要因顧客自身が必要なものを分かってないため、とよく言われるが ● 認知バイアス ● 誤謬などによって、言語化する際に少しずつ歪みが生じていく。

Slide 82

Slide 82 text

選択バイアス

Slide 83

Slide 83 text

合成の誤謬 https://atarimae.biz/archives/6914

Slide 84

Slide 84 text

フィーチャークリープ

Slide 85

Slide 85 text

システム1だけで処理して終わり、にしないように。 https://togetter.com/li/1253386

Slide 86

Slide 86 text

要件定義ワークショップ1 クラウド型オーディオプレイヤーA社の演奏システムを作ります。A社から出された機能要求は以下のとおりです。 ● 複数のアルバムとそれに含まれる曲が登録されています。 ● 登録された曲およびアルバムを通常再生できます。 ● リピート機能とランダム再生機能をもちます。機能仕様を決めていくにあたって、A社にどういう点を確認しますか?

Slide 87

Slide 87 text

ワークショップ1のポイント ● 用語の使い方が定まっていない場合がある。 ● 機能が動的に組み合わさった場合の挙動は、曖昧なままではシステムは作れない。 ● 自分の経験・知識から組み立てるのは大事ではあるが、要求されている以上のことへは拡げないこと。

Slide 88

Slide 88 text

要件定義ワークショップ2:掲載管理クライアント毎に購入した枠数分(月次)だけ、記事掲載できます。 ● 毎月、翌月分の枠数だけ載せる記事をクライアントに入稿してもらいます。 ● 記事は当月分のものと同じものを流用して入稿することも可能です。 ● 記事は掲載前に内容の審査を行うため、3営業日前までにクライアントに入稿してもらう必要があります。必要な機能を設計してみましょう。

Slide 89

Slide 89 text

ワークショップ2のポイント ● 結局のところ、実現したいことは何であるか? を追求する。 ● 補助線を引くと、シンプルな解決策がみえることもある。

Slide 90

Slide 90 text

RequirementsとSpecifications https://softwareengineering.stackexchange.com/questions/121289/what-is-the-difference-between-requirements-and-specifications ● Requirements – プログラムが何をすべきか ● Specifications – プログラムをどう実現していくかのプラン現実には混同されてRequirementsにSpecificationsまで含まれている(ように受け取ってしまう)ことがあるので注意

Slide 91

Slide 91 text

ワークショップ3:健康ランドの割引率計算以下の割引計算のルールを洗い出してみましょう。 ● クーポン持参:10％OFF ● 平日割引:30％OFF ● 平日シニア割引（65歳以上）:50％OFF ● 土日祝ジュニア割引（15歳以下）:20％OFF ● 2つ以上の割引サービスが重なった場合は，割引率が高い方が優先される

Slide 92

Slide 92 text

デシジョンテーブルで仕様を漏れなく記述する

Slide 93

Slide 93 text

簡略化

Slide 94

Slide 94 text

簡略化して仕様を書き下す ● クーポンを持っておらず、休日である → 割引なし ● クーポンを持っていて、休日で、16歳以上である → 10％OFF ● 休日で、15歳以下である → 20%OFF ● 平日で65歳未満である → 30%OFF ● 平日で65歳以上である → 50%OFF

Slide 95

Slide 95 text

ワークショップ3のポイントデータパターンを漏れなく洗い出すのは、Specificationsを書き下すソフトウェアエンジニアの重要な仕事であるが、これをそのまま実装してはならない。

Slide 96

Slide 96 text

[閑話休題] 仕様調整で3案出す理由選んで欲しい案極端回避性により、竹案が選ばれやすい予算の面などであまり現実的ではない案技術的負債となりそうな案

Slide 97

Slide 97 text

設計

Slide 98

Slide 98 text

ETC割引のルール ETC割引の計算ロジックを実装します。 ● 平日朝夕割引 – 平日「朝:6時〜9時」、「夕:17時〜20時」 – 地方部 – 当月の利用回数が5回〜9回 30%割引、10回以上 50%割引 ● 休日割引 – 普通車、軽自動車等(二輪車)限定 – 土曜・日曜・祝日 – 地方部 – 30%割引 ● 深夜割引 – すべての車種 – 毎日0〜４時 – 30%割引

Slide 99

Slide 99 text

ワークショップ4: ETC割引のルール実装上記の業務ルールにしたがい、割引率を計算するインタフェースDiscountServiceを実装して下さい。 public interface DisountService { public long calc(HighwayDrive drive); } 走行記録はHighwayDriveクラスで表現され、DiscountService#calcに渡されるものとします。また、割引率はパーセンテージの正の整数で表現されます。

Slide 100

Slide 100 text

ワークショップ5:様々な提携先システムとの連携あるECサイトでは、自前で在庫管理している商品もあれば、提携先の代理店を担っているものもあります。提携先の注文は、自テーブルにINSERTした後、提携先のAPIをコールし、注文処理を行います。現在のビジネスルール - 自社発送先の注文: Orderを保存して終了 - 提携先A社への注文: Orderを保存したら、注文内容をemailでA社に送る。 - 提携先B社への注文: Orderを保存したら、注文内容をB社のAPIを経由して送る。今後、提携先が増減することも考慮に入れて、設計を考えてみましょう

Slide 101

Slide 101 text

ワークショップ5のポイント提携先は今後増減していく可能性が高いので、追加・削除が簡単にできるように設計しておく。 ● コアの処理に、フックポイントを設ける。 ● 提携先ごとに個別な処理はプラグインとして実装する。 ● プラグインを適切なフックポイントに登録する。

Slide 102

Slide 102 text

シンプルな設計を目指すために Simple Made Easy ● Easy – 慣れている – すぐに使い始められる – 似たようなものをすでに知ってて、身近だ – 今の自分の能力の範疇内だ ● Simple – ひとつの役割 – ひとつのタスク – ひとつの概念 – ひとつの次元

Slide 103

Slide 103 text

対象何がコンプレクトしている？状態(state) 状態を変更するすべてのものオブジェクト状態と一意性と値メソッド関数と状態と名前空間継承複数の型変数状態と時間アクター「何を」と「誰が」 switch文/match文「何を」と「誰が」とのペアが複数個混ざっている

Slide 104

Slide 104 text

オブジェクトの捉え方の違い

Slide 105

Slide 105 text

テスト

Slide 106

Slide 106 text

ありがちなテスト計画単体テスト: 単一モジュールについて、ホワイトボックス観点でテストを行う機能内結合テスト: 同一機能内で複数モジュールをまたいだで、ブラックボックス観点でテストを行う。機能間結合テスト: 複数機能間をまたいで、テストを行う。特に外部システムとの連携ポイントをテストする。システムテスト: 業務シナリオに沿ってテストを行う。 ● どの要求・仕様をテストするのか、トレーサビリティが不明。 ● ● 工程の中で性質の異なるテストを組み合わせてやるので、品質指標が決めづらい。

Slide 107

Slide 107 text

工程と種別は違う https://qiita.com/kawasima/items/1fed574e7456edbad727

Slide 108

Slide 108 text

ワークショップ6 ①就活サイトのように大規模でかつオープン時にシステムへのアクセス集中が激しいサイトの開発について、工程にテスト種別をマッピングしてみましょう。 ②既存のPC向けサイトの一部機能をスマフォ専用サイトとして開発しました。工程にテスト種別をマッピングしてみましょう。

Slide 109

Slide 109 text

参考文献