システムづくりにおもいやり

HSはプロジェクト管理において社内標準化と開発方法論に忠実に従うともに、品質と納期を最優先とした一貫性のあるプロジェクト遂行プロセスを適用しております。

1. 開発体制決定

仕様把握、開発言語理解、工程管理及び品質管理のできる者をリーダーに選定します。

開発業務・開発言語に熟達した者でメンバーを構成します。

プロジェクトリーダーは、プロジェクト開始にあたり受注した範囲と機能を明確にし、各行程毎にどのようなスケジュールと人員体制を定めてプロジェクトを遂行するかを決定します。

プロジェクト開始報告書は、各部門のプロジェクト進捗会議で妥当性を検討しレビューを受けます。この時点で納品日、カットオーバー等のイベント納品物は明確にします。

プロジェクト開始計画書

2. 設計

エンドユーザの場合、お客様からの資料、ヒアリングを元にお客様の要求を明確化します。

お客様の要求を要求仕様書としてまとめ、その要求に沿って共通的な仕様を共通仕様とします。

要求仕様書に基づいて、画面、帳票、データの流れを明確にして基本設計書を作成します。

受託開発の場合、発注元から提供された仕様を基に、基本設計書及び詳細設計書を作成します。

手資料一覧／提出資料一覧／議事録／要求仕様書／業務フロー／ＤＢ設計書／基本設計書／プログラム設計書／運用設計書

3. 開発

作成した詳細設計書の通りプログラムを作成します。

開発をはじめるにあたりプロジェクトの開発方針を定めたプロジェクト開発標準を定めます。

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

プロジェクト開発標準／課題管理表／変更管理表／週間報告書(進捗管理)

開発行程では、コーディングのステップ数単体テスト項目作成数、単体テスト消化数並びに各フェーズのレビュー完了日を管理します。

開発中の疑問点や問題点は、課題管理表に記録し解決していきます。

テーブルの変更や共通仕様の変更については、変更管理表や改版履歴に記載します。

プロジェクト開発標準、課題管理表、変更管理表、週間報告書（進捗管理）

4. テスト

弊社では、単体テストは基本的に開発の工程に含まれる作業です。

仕様書を作成した人とコーディングを行った人が違う場合にはＰＣＬを先に作成することもあります。

それぞれのプログラムのテストを行うテスト仕様書をＰＣＬ、単機能のテストを単体テスト仕様書と呼びテスト項目のフォーマットが異なります。

画面や機能単位のテストが終了したものを集めて結合テストを行います。結合テストは全ての開発を待って行う場合と、順次行っていく場合がありプロジェクト開発標準で定めます。

結合テストは、全てのルートを確認するルートチェックやデータの流れを確認します。データ確認チェック、新規、変更、削除の確認や機能間の連携などのテストを行います。

総合テストは、お客様の運用を想定したテストを行います。特に業務フローに対応したテストでは、様々なパターンを設定して「運用テスト仕様書」を作成してお客様と打ち合わせを行い、運用がお客様でスムーズに行えるよう協力してテストを実施します。

テスト行程では各機能毎のＢＵＧの情報を集計して、それぞれのフェーズでの品質見解を作成し、お客様に報告します。

ＰＣＬ／単体テスト仕様書／結合テスト仕様書／総合テスト仕様書／BUG票／BUG票管理台帳／テスト結果報告書／テスト工程管理図／品質見解

5. 納入

受注時に定めた各工程の成果物及び納入書類提出します。

検収書／納品書／品質管理報告書

6. 検査対応

検収検査で摘出した不良は、その不良対策に追加して所定の基準で品質向上を実施

不良別ランク付けして各ランク毎に基準を設定して品質向上を図ります。

品質向上報告書

7. 運用・リリース

運用を委託された場合には契約で定めた運用設計書から詳細をまとめた運用詳細設計書を作成して対応を行います。毎月、正しく運用が行われているか社内で検討し運用上の問題を共有し解決を図ります。

運用開始後のリリースについてはリリース手順書を作成してお客様と合意の上リリースを実施します。リリース手順書にはリリース開始前の告知〜リリース時の動作確認の為のテスト項目なども記載します。

運用詳細設計書／リリース手順書