はじめに
情報システム部の方で、ITに詳しいだろうからという理由で、ビジネス用のシステム開発のマネージメントをするように依頼されることはないでしょうか？
実際は情報システム部の仕事と、ビジネス用システムの開発は大きく異なるものかと思います。
また、非IT企業では、システム開発を依頼する機会も少なく、一発勝負になることも多いです。
そんなお悩みを解決できるよう、いち非IT企業の情報システム部メンバーとして、実体験に基づくシステム開発の依頼の流れをまとめさせていただきました。
システム開発でお悩みの方は、是非見てみてください！
またITベンダーの皆さんにも企業側はこんなこと考えてるんだなーと思ってみていただければ嬉しいです。
単体試験とは？
プログラムを構成する小さな単位(ユニット)が、個々の機能を正しく果たしているかを検証する試験
単体試験は開発者がコード作成と同時/直後にテストケースを作成するため、妥当性の高いテストケースを残せるものである。単体試験はプログラムの改修に備え、自動化（テストコードを作成）しておくことが望ましい
テストコードの作成には時間が掛かるため、必須とする場合はRFPに入れ込んでおくべきである。(請負の場合に実施されない可能性がある）
単体試験の効果
手戻りコストは「１：１０：１００の法則」があると言われています。
設計時の修正コスト：１
開発時の修正コスト：１０
（総合試験時の修正コスト：４０）
リリース後の修正コスト：１００
単体試験の工程でバグを発見できれば、総合試験時の 1 / 4 の工数で対応ができます。このタイミングでできる限りのバグを落とすことが望ましいです。
単体試験の内容
単体試験においては、網羅性のある試験を行うことが望ましいです。試験については、それぞれで見るだけでなく、結合試験・総合試験も勘案して対応することが重要である。そのため、試験の全体を見渡して、必要な網羅性を定義することがよい。
網羅性
命令網羅（C0）：プログラムが一回実行される
分岐網羅（C1）：プログラムの分岐を考慮し一回実行される
条件網羅（C2）：発生しうる条件をすべてテストする
網羅性を上げるほど、試験効率が落ち、工数が増大します。医療システムや車載システムなどで、C2網羅100%などの厳しい条件が必要なことがわかっている場合は、RFPに記載すべきである。
コメント