方法論

• 短期出張して細かい打ち合わせを行います。
• お客様側のリーダクラスの方が訪印し、チームに説明します。
• メール・電話・チャットなどでコミュニケーションをとります。
• 説明資料、プロトタイプを作成し、お客様と確認します。

• 主にウォークスルー形式のレビューを行っています。つまり、仕様書を見ながらプログラムの動きを想定し、仕様の理解を徹底的に行い、不具合を発見する方法です。
• ソースコードレビューを行います。
• 主に、トップダウンテストを行います。重要度の高い上位モジュールから下位モジュールの順に行います。
• 場合により第三者による試験を実施します。

• 要件定義レビュー
  • お客様要求を誤解していることはないか
  • WHY、WHAT、WHO、WHERE、WHEN（5W）を重視する
  • 変更の際、必ず文書化する
• 外部設計レビュー
  • 要求は適切に機能へ展開されているか
  • HOWはこの時点では理論的
  • すべての可能性がカバーされているかの確認する
  • 機能洗い出しは適切に行われているか
• 内部設計レビュー
  • 機能が適切に実現されているか
  • すべてのロジックパスを通るか
  • プログラム構造や機能分割は適切か
• コードレビュー
  • ソースコードの妥当性、読みやすさを確認する
  • コーディング規約に従うコードになっているか
  • コードウォークスルーを行う
• テスト計画レビュー
  • テスト手順、テスト内容は妥当かを確認する
  • テストケースのカバレッジの確認する

• 計算法
  プロジェクトで必要となる作業の洗い出し（ワーク・ブレイクダウン・ストラクチャ（WBS）を用いる）、その作業ごとの工数を見積もります。以前のプロジェクト経験から見積もることができます。
• ファンクションポイント法（FP法）

• 要件定義：
• 要件定義書に対して作業範囲記述書、見積書、工程表、QA表
• 外部設計：
• 外部設計書、機能仕様書、画面レイアウト、画面一覧、外部接続概念、処理フロー、テーブル設計書（テーブル一覧、接続概念図―ER図）、入出ファイル一覧
• 内部設計：
• 内部設計書、機能詳細仕様書、プログラム一覧、プログラム処理説明書、テーブル設計書（テーブル定義書、テーブル関連書）、モジュール構成図、関数一覧
• 単体試験成績書、問題管理シート、結合試験成績書、システムテスト成績書、取扱説明書

• お客様の希望によりますが、プログラム単位または工程単位で行います。
• 通常、週に1回です。
• 通常、弊社のマネージャやリーダが作成し、管理します。
• 電話会議を設ける場合もあります。

• 品質 = お客様の 100％ の満足
• 納期内に欠陥のないシステムを納品する
• お客様の立場でご要望を理解し、これを実現する
• 仕様の変更など、お客様のご要望に柔軟に対応する
• 設計レビュー・コードレビューを定期的に実施する
• コーディング規定を遵守する
• 徹底的な試験仕様を準備する
• お客様と十分なコミュニケーションを取り、SDLCの履歴を残す

• 保証期間は1年です。
• 通常、5％〜10%程度までの仕様変更は請求しません。それを超えた場合、お客様に相談させていただきます。
• 不具合対応の方針は以下の通りです。