適した役割り分担と柔軟な体制作り

• 仕様把握、開発言語理解、工程管理及び品質管理のできる者をリーダーに選定します。
• 開発業務・開発言語に熟達した者でメンバーを構成します。
• プロジェクトリーダーは、プロジェクト開始にあたり受注した範囲と機能を明確にし、各行程毎にどのようなスケジュールと人員体制を定めてプロジェクトを遂行するかを決定します。
• プロジェクト開始報告書は、各部門のプロジェクト進捗会議で妥当性を検討しレビューを受けます。この時点で納品日、カットオーバー等のイベント納品物は明確にします。

要求を正確に把握しドキュメントに落とし込む

• エンドユーザの場合、お客様からの資料、ヒアリングを元にお客様の要求を明確化します。
• お客様の要求を要求仕様書としてまとめ、その要求に沿って共通的な仕様を共通仕様とします。
• 要求仕様書に基づいて、画面、帳票、データの流れを明確にして基本設計書を作成します。
• 受託開発の場合、発注元から提供された仕様を基に、基本設計書及び詳細設計書を作成します。

プロジェクト開発標準を定め効率化を図る

• 作成した詳細設計書の通りプログラムを作成します。
• 開発をはじめるにあたりプロジェクトの開発方針を定めたプロジェクト開発標準*を定めます。
• 開発行程では、コーディングのステップ数単体テスト項目作成数、単体テスト消化数並びに各フェーズのレビュー完了日を管理します。
• 開発中の疑問点や問題点は、課題管理表に記録し解決していきます。
• テーブルの変更や共通仕様の変更については、変更管理表や改版履歴に記載します。
• プロジェクト開発標準、課題管理表、変更管理表、週間報告書（進捗管理）

この文書には共通の文書の格納場所、文書の更新担当者、レビューのタイミングと方法、単体テスト仕様書のフォーマット、結合テストの実施方法などプロジェクトの開発に必要なものを全て定めます。

徹底したテストで高品質を保証

• 単体テストは基本的に開発の工程に含まれます。
• 仕様書作成者とコーダーが違う場合にはＰＣＬを先に作成することがあります。
• それぞれのプログラムのテストを行うテスト仕様書をＰＣＬ、単機能のテストを単体テスト仕様書と呼びテスト項目のフォーマットが異なります。
• 画面や機能単位のテストが終了したものを集めて結合テストを行います。結合テストは全ての開発を待って行う場合と、順次行っていく場合がありプロジェクト開発標準で定めます。
• 結合テストは、全てのルートを確認するルートチェックやデータの流れを確認します。データ確認チェック、新規、変更、削除の確認や機能間の連携などのテストを行います。
• 総合テストは、お客様の運用を想定したテストを行います。特に業務フローに対応したテストでは、様々なパターンを設定して「運用テスト仕様書」を作成してお客様と打ち合わせを行い、運用がお客様でスムーズに行えるよう協力してテストを実施します。
• テスト行程では各機能毎のＢＵＧの情報を集計して、それぞれのフェーズでの品質見解を作成し、お客様に報告します。

確実な成果物納品と検収で信頼性を提供

• 受注時に定めた各工程の成果物及び納入書類を提出します。
• お客様に納品物の検収をして頂き検収書に確認をいただきます。

徹底検査とランク別対策で品質向上を確約

• 検収検査で摘出した不良は、その不良対策に追加して所定の基準で品質向上を実施します。
• 不良別ランク付けして各ランク毎に基準を設定して品質向上を図りその結果を報告します。

万全の運用設計とリリース手順で安心の稼働をサポート

• 運用を委託された場合には契約で定めた運用設計書から詳細をまとめた運用詳細設計書を作成して対応を行います。毎月、正しく運用が行われているか社内で検討し運用上の問題を共有し解決を図ります。
• 運用開始後のリリースについてはリリース手順書を作成してお客様と合意の上リリースを実施します。リリース手順書にはリリース開始前の告知～リリース時の動作確認の為のテスト項目なども記載します。