位置づけ
本当に完全に全くの0から中規模以上のシステムを作る場合の知見をまとめます。
また、開発フローもアジャイル・ウォーターフォールをあまり気にしていません。
多分どちらでも使えると思います。
残念ながらインフラ領域は門外なので、割愛します。
参考
IPA非機能要求グレード
https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html
Webシステム／Webアプリケーションセキュリティ要件書 3.0
https://github.com/ueno1000/secreq
モバイルアプリケーションセキュリティ検証標準
https://github.com/coky-t/owasp-masvs-ja
git-flow
https://nvie.com/posts/a-successful-git-branching-model/
github-flow
http://scottchacon.com/2011/08/31/github-flow.html
https://gist.github.com/Gab-km/3705015
gitlab-flow
https://postd.cc/gitlab-flow/
想定する開発フロー
やりたいこと、その規模（XX月後、XX年後にこのくらいの売上になっていたい）が定義された状態で
非機能とかインフラ選定・技術選定しようとする段階をターゲットにします。
ドキュメントフロー
フォーマットなどは特に気にしたいのですが、 決める必要がある といった観点で以下のフローを想定します。
これもあくまで目安程度です。
品質設計の手順
1.非機能要求を元にした要件定義
IPAの非機能要求グレードの活用表をもとに、今から作るシステム特性を検討し、非機能要件を決めます。
IaaS（AWS..etc）、PaaS(Heroku)などでも十分有効に使えます。
https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html
利用方法
一般論レベルですが、結局
- 06_活用シート.xls
を全部上から下まで舐めるだと思います。
ただし、誰が決めるかは要求のセクションによって担当を分けるべきだと思います。
樹形図を見て担当を決める
Bの章が「システムを実装する」観点では重要になります。
重要項目とされていませんが、この段階で性能テストもある程度考えておくと実装後に慌てるタイミングが減ります。
また、Eの章ではセキュリティも定められているため（実装観点ではセキュアコーディングしましょうといったレベルですが）確認が必要です。
2.セキュリティ要件を決める
実装方式に影響するため、設計・実装よりも前に確実に詰めます。
サーバサイド・バッチ
OWASPの「Webシステム／Webアプリケーションセキュリティ要件書 3.0」がとてもわかり易く要件を整理していえるため、
こちらをもとに要件を検討すると決めやすくなります
https://github.com/ueno1000/secreq
モバイル・SPA
OWASPの「モバイルアプリケーションセキュリティ検証標準」がとてもわかり易く要件を整理していえるため、
こちらをもとに要件を検討すると決めやすくなります
https://github.com/coky-t/owasp-masvs-ja
3. 実装計画
ブランチ設計
バージョン管理として、Gitを前提に検討します。
開発を始める前にブランチ運用を決めることはとても重要です。
この運用を決めないと、CI/CDも構築できません。
事実上デファクトになっている運用flowがあるので、想定する開発の回し方に応じて選択・カスタマイズが必要になります。
git-flow
flowは本当によくできており、高い理想を感じるのですが、実際の開発現場でこれを完全に回しきった事例をあまり見ません。
github-flow
本番環境＝masterのとてもシンプルな構成です。
単純すぎてこれで本当にこれで運用が回せるのか不安をいだきます。
hotfixなどの考えを入れて運用するパターンが多かったです。
gitlab-flow
(ちょっと違いますが)github-flowに環境面の考えを入れたflowです。
現実に落としてきた感じがします。
規約
いわゆるコーディング規約です。
フォーマットレベルの話はlinterに任せるべきですが、それ以外（命名・変数の使い方など）は全体の品質を平準化させるために必要だと思います。
linter
言語・フレームワークに合わせて有効なLinterを選定し、ルールは規約に合わせて書き換えましょう。
CI(CDは割愛)
できればgitpushに引っ掛けて段階でCIでできる限りのチェックを実行したいです。
品質担保・レビュワーの負荷軽減のためです。
- literチェック
- 静的バグ解析（linterに含まれる場合もあり）
- UT
- e2e
ペアプロ
経験の浅い人のコードはどうしてもお作法も、ロジックもベテランに比べて品質が低くなります。
そこで始めの1本はペアを組ませて書き方を学んでもらいましょう。
レビュー
github/gitlabの機能が充実しているので、全面的にPullRequest/MergeRequestのレビュー機能を利用すると良いです。
4.テスト計画
設計・実装の前にテストの定義をすることで、以下の様な実装段階で発生する問題が事前に検討・解決できます。
- テスト内容のばらつき
- テストのやり過ぎ
- テストの不足
- あれ？このテスト何をやったら終わるんだ？といった疑問
増減はしますが、私の理解の範囲では以下のようなテストが一般的に実施されると思います。
また、セオリーとしてテスト範囲は最小粒度から徐々に広くしていきます。
- UT
ホワイトボックステスト - いわゆるテストクラスの範囲
基本はカバレッジを保証するもので、この保証のレベルを定義します
一般的に以下のキーワードで調べると指標がわかりやすく解説されています
C0/C1/C2/MMC
重要なのは「C0を選択した場合もMMC相当の保証を後続のテストでは実施する必要がある」という点です。 - e2e
End to Endの略です
ブラックボックステスト - apiであればRequest/Response、画面であれば画面の挙動確認（Selenium他）をするものです。
機能単位のインターフェイス（データパターン）を保証するテストになります。
テストクラスをサボるとここが厚くなります。 - 特定サービスのテスト
個別の機能が保証された前提で、サービスが正常に動作するかを確認するテストになります。 - 自ステムのテスト（機能）
サービスが保証された前提でシステム全体を確認するテストになります。 - 自ステムのテスト（非機能）
非機能で定義した要件を満たしているの確認するテストになります。
アプリケーションとしては、性能試験、セキュリティ試験がここに当てはまります。 - 外部システムとの結合テスト
例えば別会社のシステムからRequestを受け付ける、ファイルを受け取るなどの処理から、システム全体としてビジネスを実現できるのかを確認するテストになります。
最後に
ここまでを100％設計前に実施するのは、大体の場合期間の制約で不可能です。
ですが、検討した上で落とすのと、最初から通すのでは品質に雲泥の差がでるので、リスク踏まえて落とす・落とさないの選択が必要だと思います。