現代的システム開発概論

2019年度リクルート新人ブートキャンプ エンジニアコースの講義資料です

Transcript

1. 現代的システム開発概論 (v1.0) 株式会社ウルフチーフ 川島 義隆
2. プロジェクトを進める上での 基礎知識
3. プロジェクトとは何か? プロジェクトとは、独自のプロダクト、サービス、所産を 創造するために実施する有期性のある業務 (PMBOKの定 義) • 特定の成果を達成するための組織 • 期限が限定されている (有期性) • 同じものはない (独自性) • 相互に関連する作業の調整がなされる(相互関連性)
4. マネジメントのことが好きじゃない/苦手でも、 プロジェクトマネージャと対等に話するために PMBOKの内容くらいは学んでおいたほうが良い …が、退屈な内容であることは変わりない 私はこの本で分かった気になった
5. マネジメントライフサイクル • 計画: QCDSを決める • 実行: 計画にしたがって作業をする • 監視: 計画と実績のズレを測る • コントロール: ズレに対応する
6. 計画 Plans are useless, but planning is indispensable. – Eisenhower 計画そのものは刻一刻と状況が変わりゆくプロ ジェクトにおいては役に立たない。 どんなライフサイクルを採用しようとも、再計 画を想定しておかなければならない
7. プロジェクト計画 だいたい次のようなことを書く • プロダクトの目的 • 履歴 • リリース基準 • プロジェクトの目標 • プロジェクトの編成 • スケジュールの概要 • プロジェクトの人員配置(人員配置の計画) • スケジュール案 • リスク一覧
8. ローリングウェーブ計画法 • 段階的に詳細化する、計画策定の方法。 • 直近の作業は詳細に、先の作業はおおざっぱに 計画する。 • 初期段階では、ワーク・パッケージの要素分解 はマイルストーン・レベル。 • プロジェクトが進行し、詳細が判明するにつれ て、ワーク・パッケージはアクティビティに分 解される。
9. リリース基準 プロジェクトにとって重要なことは何か? – リリースの日程 – 機能セット – 欠陥の少なさ – 品質特性 など、これを満たしたらリリース可能という 基準を定める。
10. トレードオフ・スライダーを使って会話するとよい
11. リリース基準の書き方はSMARTに • 具体的 (Specific) • 計測可能 (Measurable) • 達成可能 (Attainable) • 現実的 (Relevant) • 追跡可能 (Trackable) Time Boundとされることが多 いが、Manage It!で使われてい るTrackableの方が意味合いが ハッキリする
12. RiskとIssueの違い Risk Issue 未来にフォーカス 現在・過去にフォーカス プロジェクト期間中に、主要なリ ソースが居なくなるかもしれない チームメンバが離任する。最終日 は✕✕なので、引き継ぎを… チームメンバがプロジェクトの大事 な期間に休暇をとるかもしれない。 チームメンバが休暇を取ったと き、他の誰も対処できないことが ある。 予期せぬ要求の変更があるかもしれ ない プロジェクトのスコープに追加す べき機能が見つかった 影響分析すると、プロジェクトのス ケジュールを遅延させる問題が見つ かるかもしれない。 影響分析の結果、プロジェクトを1 週間後ろ倒ししそうな新たな問題 が2つ見つかった。 マトリックス型の組織でプロジェク トを進めると、現場が混乱し生産性 が低下するかもしれない。 我々の組織はマトリックス型なの で、PMの権限と説明責任について 混乱を減らすために、それを明記 した文書を作成する必要がある。 https://www.linkedin.com/pulse/issue-risk-what-difference-sanjeev-kulkarni/
13. RiskはIssueとは使い方が違う。 – 対処予算の確保 – エグゼクティブラインを動かす
14. リスク対応戦略
15. リスクの主観的価値の非線形性 質問1:あなたの目の前に、以下の二つの選択肢 が提示されたものとする。 選択肢A:100万円が無条件で手に入る。 選択肢B:コインを投げ、表が出たら200万円が 手に入るが、裏が出たら何も手に入らない。
16. 質問2:あなたは200万円の負債を抱えているも のとする。そのとき、同様に以下の二つの選択肢 が提示されたものとする。 選択肢A:無条件で負債が100万円減額され、負 債総額が100万円となる。 選択肢B:コインを投げ、表が出たら支払いが全 額免除されるが、裏が出たら負債総額は変わらな い。
17. プロスペクト理論
18. 発生確率の主観評価の難しさ ブラックスワン 1697年まではヨーロッパでは真実だった。 「白鳥は白い」 経験に基づく知識 現在の知識の限界　→　分からないことが分からない
19. ブラックスワンの特徴 • 予測不能 • 非常に強いインパクトを持つ • 実際に起こると後付けで説明がなされ、偶然で はなく、最初からわかっていたような気にさせ られる (後知恵バイアス)
20. 失敗を避けるのではなく 失敗を前提としてシステムを設計する 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
21. ブラック・スワン提唱者のタレブ博士の その次の作品Antifragile(反脆弱性)は 非常に面白いし、ソフトウェアの世界でも 重要な概念になりつつあるので横道ですが 話しておきます
22. プットオプションとリーマンショック http://www.jsda.or.jp/manabu/qa/derivative05.html
23. https://taylorpearson.cdnoptimus.com/wp-content/uploads/2013/05/Convexity-and-Concavity.png 変動幅が大きいと儲かる (長期投資) 変動幅が小さいと儲かる (短期投資)
24. Fragile 変化に対して弱い・損失が大きい仕組み • 後戻りの計画・その分の予算確保がないウォー ターフォールのプロジェクト • プロビジョニングが十分でないシステム (ex. 30分 2000PVでダウンする図書館システ ム) • 例外のハンドリングが雑なアプリケーション
25. Robust 変化に対して、十分強い仕組み (フラジャイルの裏返し) • よく計画されたウォーターフォールの開発プロジェクト • 急激なアクセス増や異常なデータファイルに対しても、 安全に処理できるアプリケーション • 例外を適切にハンドリング出来ているコード
26. Resilient 大きな変化に対し、一時的にシステムのパフォーマ ンスを落としてもすぐに復旧できる仕組み
27. Antifragile 変化が起これば起こるほどメリットがある仕 組み ストレスが増せば増すほど強くなる仕組み そんなことが可能なのでしょうか?
28. Benefit Change Cost Antifragile Resilient Robust Fragile
29. ダモクラス フェニックス ヒドラ Fragile Robust (Resilient) Antifragile ちょっとしたことで 上に吊るされた剣が 落ちてきて死亡 死んでも 何度でも甦る 1つ首を切ると、 2つはえてくる イメージ図
30. トライアドのフレームワーク 特になにもしない 業務に関係ないも のも、アレコレつ まみ食いする 業務で必要なもの を勉強する Antifragile Robust Fragile 世の中の事象を、Fragile/Robust/Antifragile の3つ組(トライアド)に沿って考えると面白 い。 エンジニアの技術学習のトライアド
31. Netflix Chaosシリーズ 意図的に本番障害を起こし、何が起きるかをモニタリングする Chaos Monkey: EC2インスタンス単位で落とす Chaos Gorilla: AZ単位で落とす Chaos Kong: リージョン単位で落とす Latency Monkey: 1Microserviceのレスポンスを遅延させる https://www.slideshare.net/JoshEvans2/embracing-failure-reinvent-2014
32. https://www.youtube.com/watch?v=ZMbqbXxRthE&index=40&list=PLRsbF2sD7JVqk90s0ogP\_dcfM9T-y1DRm
33. WBS
34. WBS作成のうえで適用されるルール • 100%ルール • 8/80ルール • 7×7ルール https://www.itmedia.co.jp/im/articles/1001/27/news103.html
35. スケジュール タスク スケジューリング 見積 「Manage It!」での定義 スケジュール
36. スケジューリングと見積の違い • スケジューリング – タスクの依存関係を明らかにし、順序付けを 行うこと • 見積 – あるタスクが完了するのにどれくらい時間が かかるかを推定すること
37. タスクの依存関係 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が 完了できない
38. Finish-to-Start A B A:認証ライブラリを作る B:認証ライブラリが返すユーザオブジェクトを使って、検索す るプログラムを作る
39. Start-to-Start A B A:ユーザマニュアルを書く B:ユーザマニュアルをレビューする
40. Finish-to-Finish A B A:検索機能のテストを書く B:検索機能を作る
41. 問題 A B C D A:認証モジュール作る (3d) B:認証モジュールをテストする (2d) C:認証ライブラリが返すユーザオブジェクトを使って、検索す るプログラムを作る (3d) D:検索機能をテストする (2d) 以下のスケジュールを短縮することができるでしょうか?
42. 回答例 A C D A:認証モジュールインタフェース作る (1d) A’:認証モジュール実装作る(2d) B:認証モジュールをテスト作る (2d) C:認証ライブラリが返すユーザオブジェクトを使って、検索す るプログラムを作る (3d) D:検索機能をテスト作る (2d) A’ B
43. ポイント • タスクを分解する – 抽象概念を作り出すのがポイント • 2つのタスクが本当にFinish-to-Startか を考える • リソースに余裕があればタスクを割り当てて、 工期を短縮できる (リソース効率を上げる)
44. スケジューリングの技法 • トップダウンスケジューリング – まずマイルストーンを置き、それを支えるタスクをひねり出す • ボトムアップスケジューリング – 特定のタスクから始め、それに連なるタスクを洗い出しマイルストーンをひねり出す。 – 漸進型ライフサイクルで有用 • インサイドアウト – 自分(たち)の分かっていることをマインドマップに書き出し、そこからタスクとマイルス トーンを作る • ハドソン・ベイスタート – まず小さくプロジェクトを始めてみて、そこでの理解をもとにタスクやマイルストーンを 作る
45. 計画の種類 • フェーズベースの計画 – 特定の部門の人たちからなるチームが、プロジェク トの各部の責任を追う。 – 責任を負う人たちが「終了」と宣言すれば、その フェーズが完了 • 成果物ベースの計画 – 成果物に基づいたマイルストーンを置く – 成果物の完成に各チームが集中できるようになる一 方、マイルストーンが守られずグダグダになるリス クがある。
46. https://www.slideshare.net/yusuke/itaws これはあるあるだけれども、ウォータフォールが全てそうだというわけではなく フェーズベースの計画が適してないのに、そうしてしまったという場合の失敗
47. 見積 プロジェクトが大失敗する原因は2つある – 見積ミス – 仕様を凍結できない “見積の大部分は、非現実的で単なる希望にすぎ ない。さらに悪いことに、不正確な見積を改善す るすべがないのだ”ソフトウエア開発 55の真実と10のウソより
48. 見積の技法 • 経験ベース – 類推法 – デルファイ法 • アルゴリズムベース – Function Point – Use Case Point
49. 見積の正確度と精度 正確度(Accuracy) 精度(Precision)
50. 未知の領域の見積 タスクが大きいとだけ分かっていて、どれくらい 大きいかを見積もる適切な方法が見当つかない スパイク タスクの情報を得るために作る小さなタイムボックス
51. Five Orders of Ignorance 0OI: 全部分かっている 「答え」を持っている。あとは書き写すだけで完成する。 1OI: 分からないことが分かっている 答えを得るための「質問」を持っている。 2OI: 分からないことが分からない 「質問」を持たない状態。決定的な答えを引き出すための「質問」がで きない。 3OI: 分からないことが分からない状況を何とかする術を知 らない 2OI→1OI→0OIと進んでいくためのプロセスがない状態です。 4OI: 無知にレベルがあることを知らない http://qiita.com/seki_uk/items/4001423b3cd3db0dada7
52. ベルトとサスペンダー方式 • 見積の正確度をあげることができないことへの 妥協策 – a) 経験者の意見をベースにした見積 – b) ある程度の正確度を期待できるアルゴリ ズムで算出した予測値 の2つを使って予測する。
53. 見積に関するおかしな真実 • ソフトウェア開発の見積は、プロジェクトの開始に実 施する場合が非常に多い。これだと要件定義が固まる 前に見積ることになり意味がない。 • プロジェクトが進むにしたがって見積を調整すること はまずない。したがって不適切な時期に不適切な人間 が実施した見積を修正することはほとんどない。 • 見積精度がいい加減だと、実際のプロジェクトが見積 どおりに進まなくても、まったく気にならないはずだ が、現実にはみんな気にする。
54. ソフトウェア開発ライフサイクル 要件定義 設計 実装 コーディング テスト デプロイ 保守
55. 開発ライフサイクル 種類 ライフサイク ルの例 長所および成功に必要な条件 プロジェクトの 優先順位 逐次型 ウォーターフォール、 フェーズゲート • コストのリスクを管理できる (経営陣がフェーズゲートを使用する場合) • システムアーキテクチャをよく理解できている • プロジェクトの過程で要件が変動しない 1.機能セット 2.欠陥の軽減 3.リリース期日 反復型 スパイラル、進化的プ ロトタイピング、RUP • 技術的リスクを管理できる • 要件が進化し続ける 1.機能セット 2.欠陥の低減 3.リリース期日 漸進型 スケジュールに応じた 設計、段階的納品 • スケジュールのリスクを管理できる • 多少の要件の変更を吸収できるが、アーキテク チャに影響を与える変化には十分対応できない 1.リリース期日 2.欠陥の低減 3.機能セット 反復漸進型 アジャイル • スケジュールのリスクと技術的リスクの両方を管 理できる • すべてのメンバが同一サイトで作業を行える • 統合チーム以外では円滑な進行が難しい 1.リリース期日 2.機能セット 3.欠陥の低減 場当たり型 Code and Fix なし 1.リリース期日 2.機能セット 3.欠陥の低減
57. 逐次型ライフサイクル 逐次型ライフサイクルを選択可能な条件 • 技術的リスクが小さい • スケジュールリスクが小さい • プロジェクトチームが安定している • 要求変動リスクが小さい 逐次型ライフサイクルで対処できるリスク • 機能セット • 何をいつ行うのかが分かる • コストのリスク
58. 逐次型ライフサイクルの隠れたリスク • アーキテクチャ上のリスク – BDUFに陥る • テストのリスク • スケジュール上のリスク https://enterprisezine.jp/iti/detail/2392
59. 反復型ライフサイクル • 代表的なプロセス – スパイラル – 進化的プロトタイピング • 反復型ライフサイクルによって対処されるリス ク – 頻繁に変更される要件 – 技術的なリスク
60. 反復型ライフサイクルのリスク • スケジュールのリスク • コストのリスク – 製品の最も重要な部分でなく、製品の最もリスクを 伴う部分を最初に実装することを前提としている。
61. 反復型ライフサイクルとアジャイルの違い アジャイル 反復型 イテレーション期間は一定 イテレーション期間に制限 はない イテレーション終わりには 機能を完成させる イテレーション終わりに必 ずしも完成している必要は ない
62. 漸進型ライフサイクル 顧客と頻繁にやり取りせず、機能毎に実装を行う機 能チームを作れる場合に向いている。 (日本の比較的大規模開発で独自進化を遂げている、 五月雨式ウォータフォールはこれに近い) • 漸進型ライフサイクルによって対処されるリスク – スケジュール上のリスク – プロジェクトチームの変更 – 要件の変更
63. 漸進型ライフサイクルのリスク • アーキテクチャ上のリスク – 機能の開発順序を見誤ると、後回しにした機 能によってアーキテクチャを変更せざるを得 ないことがでてくる • 要件の変更 – 以前に開発済みの機能を変更したくなった場 合、チームの作業が増える
64. アジャイルライフサイクル • アジャイルライフサイクルによって対処される リスク – スケジュール上のリスク – プロジェクトチームの変更 – 要件の変更 – コストのリスク
65. アジャイルライフサイクルのリスク • プロジェクトの優先順位を経営者が決定できな い • 要件について意思決定する必要のある人物が決 定できない • プロジェクトのスタッフが固定化してしまう
66. プロジェクトの時間 = 開発時間 + アーキテクチャとリスク削減時間 + やり直しの時間 走り出すまでにどれくらい 全体の設計を考えておくべきか? Making Software, How Much Architecting Is Enough?
68. V&V • Validation: 正しいシステムを作っている か? • Verification: システムを正しく作って いるか?
69. V-Model 要件定義 外部設計 コーディング システム テスト 内部設計 単体テスト 結合テスト Validation Verification Verification
70. ソフトウェアの品質 機能性 信頼性 使用性 効率性 保守性 移植性 アーキテクチャ 設計 非機能要求 (NFR) 品質特性 アーキテクチャ パターン
71. 品質特性シナリオ 成果物 (Artifact) 環境 (Environment) レスポンス (Response) レスポンス計測 (Response Measure) 刺激発生源 (Source of Stimulus) 刺激 (Stimulus) Software Architecture in Practice より
72. 可用性のケース 成果物 環境 レスポンス レスポンス計測 刺激発生源 刺激 ヘルスチェック ヘルスチェック サーバ無応答 プロセス 平常状態 ダウンタイムなし 運用が継続できる
73. 品質特性シナリオの例 平常状態において、ヘルスチェックが1回 無応答状態になっても、 そのサーバは適切に切り離され サービス全体としてはダウンタイムなしに 処理継続されること Environment Source of Stimulus Stimulus Artifact Response Measure Response
74. 可用性の戦術 Availability Tactics 異常の検知 異常状態からのリカバリ 異常状態の防止 切り離し トランザクション 予測モデル 例外防止 再起動 準備と修復 縮退 スペア 例外 ハンドリング ロールバック リトライ デグラデーション シャドウモード 再同期 再起動レベル グレイスフル リスタート ping/echo 監視 ハートビート 例外検知 自己診断
75. 性能の戦術 Performance Tactics リソース要求のコントロール リソースの管理 リソースを増やす 並列化する 計算リソースの複数コピーをもつ データの複数コピーをもつ キューサイズを制限する リソースをスケジューリングする サンプリングレートを コントロールする イベントレスポンスを 制限する イベントに優先度をつける オーバーヘッドを減らす 実行時間を制限する リソース効率をあげる
76. 品質特性間のトレードオフ 可 用 効 率 柔 軟 完 全 相 互 運 用 保 守 移 植 信 頼 再 利 用 堅 牢 テ ス ト 使 い 勝 手 可用 ＋ ＋ 効率 ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ 柔軟 ➖ ➖ ＋ ＋ ＋ ＋ 完全 ➖ ➖ ➖ ➖ ➖ 相互運用 ➖ ＋ ➖ ＋ 保守 ＋ ➖ ＋ ＋ ＋ 移植 ➖ ＋ ＋ ➖ ＋ ＋ ➖ 信頼 ＋ ➖ ＋ ＋ ＋ ＋ ＋ 再利用 ➖ ＋ ➖ ➖ ＋ 堅牢さ ＋ ➖ ＋ ＋ テスト ＋ ➖ ＋ ＋ ＋ ＋ 使い勝手 ➖ ＋ https://msdn.microsoft.com/en-us/library/bb402962.aspx
77. 第1部まとめ プロジェクトマネジメントの最大誤謬 ソフトウェア開発で最も重要なことは、プログラ マが使うツールや技法ではなく、プログラマ自身 の質である。
78. 開発フェーズ毎の極意
79. ここから先は、ワークショップベースで 各開発プロセスの極意 を体験していきます
80. 要件定義
81. 「顧客が本当に望んだもの」とズレる要因 顧客自身が必要なものを分かってないため、とよく 言われるが • 認知バイアス • 誤謬 などによって、言語化する際に少しずつ歪みが生じ ていく。
82. 選択バイアス
83. 合成の誤謬 https://atarimae.biz/archives/6914
84. フィーチャークリープ
85. システム1だけで処理して終わり、 にしないように。 https://togetter.com/li/1253386
86. 要件定義ワークショップ1 クラウド型オーディオプレイヤーA社の演奏システムを作りま す。A社から出された機能要求は以下のとおりです。 • 複数のアルバムとそれに含まれる曲が登録されています。 • 登録された曲およびアルバムを通常再生できます。 • リピート機能とランダム再生機能をもちます。 機能仕様を決めていくにあたって、A社にどういう点を確認しま すか?
87. ワークショップ1のポイント • 用語の使い方が定まっていない場合がある。 • 機能が動的に組み合わさった場合の挙動は、曖 昧なままではシステムは作れない。 • 自分の経験・知識から組み立てるのは大事では あるが、要求されている以上のことへは拡げな いこと。
88. 要件定義ワークショップ2:掲載管理 クライアント毎に購入した枠数分(月次)だけ、記事掲載でき ます。 • 毎月、翌月分の枠数だけ載せる記事をクライアントに入稿し てもらいます。 • 記事は当月分のものと同じものを流用して入稿することも可 能です。 • 記事は掲載前に内容の審査を行うため、3営業日前までにク ライアントに入稿してもらう必要があります。 必要な機能を設計してみましょう。
89. ワークショップ2のポイント • 結局のところ、実現したいことは何であるか? を追求する。 • 補助線を引くと、シンプルな解決策がみえるこ ともある。
90. RequirementsとSpecifications https://softwareengineering.stackexchange.com/questions/121289/what-is-the-difference-between-requirements-and-specifications • Requirements – プログラムが何をすべきか • Specifications – プログラムをどう実現していくかのプラン 現実には混同されてRequirementsにSpecificationsまで 含まれている(ように受け取ってしまう)ことがあるので注意
91. ワークショップ3:健康ランドの割引率計算 以下の割引計算のルールを洗い出してみましょう。 • クーポン持参:10％OFF • 平日割引:30％OFF • 平日シニア割引（65歳以上）:50％OFF • 土日祝ジュニア割引（15歳以下）:20％OFF • 2つ以上の割引サービスが重なった場合は，割引率 が高い方が優先される
92. デシジョンテーブルで仕様を 漏れなく記述する
93. 簡略化
94. 簡略化して仕様を書き下す • クーポンを持っておらず、休日である → 割引 なし • クーポンを持っていて、休日で、16歳以上であ る → 10％OFF • 休日で、15歳以下である → 20%OFF • 平日で65歳未満である → 30%OFF • 平日で65歳以上である → 50%OFF
95. ワークショップ3のポイント データパターンを漏れなく洗い出すの は、Specificationsを書き下すソフトウェア エンジニアの重要な仕事であるが、これをそのま ま実装してはならない。
96. [閑話休題] 仕様調整で3案出す理由 選んで欲しい案 極端回避性により、竹案が選ばれやすい 予算の面などであまり現実的ではない案 技術的負債となりそうな案
97. 設計
98. ETC割引のルール ETC割引の計算ロジックを実装します。 • 平日朝夕割引 – 平日「朝:6時〜9時」、「夕:17時〜20時」 – 地方部 – 当月の利用回数が5回〜9回 30%割引、10回以上 50%割引 • 休日割引 – 普通車、軽自動車等(二輪車)限定 – 土曜・日曜・祝日 – 地方部 – 30%割引 • 深夜割引 – すべての車種 – 毎日0〜４時 – 30%割引
99. ワークショップ4: ETC割引のルール実装 上記の業務ルールにしたがい、割引率を計算するインタフェー スDiscountServiceを実装して下さい。 public interface DisountService { public long calc(HighwayDrive drive); } 走行記録はHighwayDriveクラスで表現さ れ、DiscountService#calcに渡されるものとします。 ま た、割引率はパーセンテージの正の整数で表現されます。
100. ワークショップ5:様々な提携先システムとの連携 あるECサイトでは、自前で在庫管理している商品もあれば、提携先の代理店を担っているものもあ ります。 提携先の注文は、自テーブルにINSERTした後、提携先のAPIをコールし、注文処理を行います。 現在のビジネスルール - 自社発送先の注文: Orderを保存して終了 - 提携先A社への注文: Orderを保存したら、注文内容をemailでA社に送る。 - 提携先B社への注文: Orderを保存したら、注文内容をB社のAPIを経由して送る。 今後、提携先が増減することも考慮に入れて、設計を考えてみましょう
101. ワークショップ5のポイント 提携先は今後増減していく可能性が高いので、追 加・削除が簡単にできるように設計しておく。 • コアの処理に、フックポイントを設ける。 • 提携先ごとに個別な処理はプラグインとして実 装する。 • プラグインを適切なフックポイントに登録す る。
102. シンプルな設計を目指すために Simple Made Easy • Easy – 慣れている – すぐに使い始められ る – 似たようなものをす でに知ってて、身近 だ – 今の自分の能力の範 疇内だ • Simple – ひとつの役割 – ひとつのタスク – ひとつの概念 – ひとつの次元
103. 対象 何がコンプレクトしている？ 状態(state) 状態を変更するすべてのもの オブジェクト 状態と一意性と値 メソッド 関数と状態と名前空間 継承 複数の型 変数 状態と時間 アクター 「何を」と「誰が」 switch文/match文 「何を」と「誰が」とのペアが複数個混 ざっている
104. オブジェクトの捉え方の違い
105. テスト
106. ありがちなテスト計画 単体テスト: 単一モジュールについて、ホワイトボックス観点でテストを行う 機能内結合テスト: 同一機能内で複数モジュールをまたいだで、ブラックボッ クス観点でテストを行う。 機能間結合テスト: 複数機能間をまたいで、テストを行う。特に外部システム との連携ポイントをテストする。 システムテスト: 業務シナリオに沿ってテストを行う。 • どの要求・仕様をテストするのか、トレーサビリティが不明。 • • 工程の中で性質の異なるテストを組み合わせてやるので、 品質指標が決めづらい。
107. 工程と種別は違う https://qiita.com/kawasima/items/1fed574e7456edbad727
108. ワークショップ6 ①就活サイトのように大規模でかつオープン時に システムへのアクセス集中が激しいサイトの開 発について、工程にテスト種別をマッピングし てみましょう。 ②既存のPC向けサイトの一部機能をスマフォ専 用サイトとして開発しました。工程にテスト種 別をマッピングしてみましょう。
109. 参考文献