契約形態
1.開発委任契約型:
合意したスキルレベルの技術者を人月で提供し、
システム開発の成果に対して責任を負わない契約である。
2.開発請負契約型:
システム開発の成果に対して責任を負う契約となります。
事前に納期、費用、成果物などを決定した後、
プロジェクトを進めることになります。
3.混同契約型:
開発請負契約型と開発委任契約型の併用型である。。
4.ラボ契約型:
ある一定期間(半年や1年などを基本とされています)で発注する仕事量の最低保証を行う契約である
人材確保
————上記の契約形態は案件の特徴より決められる
コミュニケーション
■ 概要:
オフショア開発においてお客様に信頼いただくため、下記のツールを利用し、コミュニケーションを行います。
■ 課題・進捗管理・ソースコード管理
詳細はこちらhttp://www.backlog.jp/をご覧ください。
■ チャット・会議
詳細はこちらhttps://products.office.com/ja-jp/skype-for-business/online-meetingsをご覧ください。
Projectの進捗状況は、参加者の皆様にいつでも開示する体制を構築します。また、コミュニケーションは全て日本語で実施します。
詳細な作業報告は、日々BacklogにExcel情報をUpdateいたします。
一般的な工程別Document一覧
| 工程 | Document名 | 記載内容 |
|---|---|---|
| 企画 | システム企画書 | システムの企画書。システム構築のメリット・デメリットなどの企画・構想を記述したもの |
| 要件定義 | 要件定義書 | システム企画から必要なシステム要件を抽出したもの |
| 業務フロー | 要件定義 | |
| PFD | 業務フローからシステムへのIOを定義したもの | |
| DFD(データフロー) | 業務フローからデータのIOを定義したもの | |
| 論理ER | データベース設計の元となる、ユーザー視点で作成された「Entity Relationship Diagram」 | |
| 非機能要求仕様書 | パフォーマンス要件・稼働要件など、システム機能に関連しない要求をまとめたもの。 | |
| WBS | 以降の作業工程・作業SCHEDULEを定義したもの。 | |
| 基本設計 | 画面定義書(基本設計書) | 画面の定義書 |
| 処理概要書(基本設計書) | 画面・BATCH処理などの処理定義書 | |
| 画面遷移図 | 画面の遷移図 | |
| 物理ER図 | データベース設計の元となる、システム視点で作成された「Entity Relationship Diagram」 | |
| テーブル定義書 | ERから作成されるテーブル個別の定義書 | |
| 共通設計書 | Session,Cokieなど共通項目や共通処理の設計書 | |
| プロトタイプ | プロトタイプ | 各機能のプロトタイプ実装 |
| 詳細設計 | 処理詳細(詳細設計書) | 基本設計書の処理内容をさらに細かく定義したもの |
| QL定義書 | SQL単体の定義書 | |
| 単体テスト | 単体テスト仕様・結果報告書 | 詳細設計書をもとにした、単体での動作検証を保証する仕様書・結果報告書 |
| 結合テスト | 内部結合テストシナリオ・結果報告書 | 業務フロー・基本設計をもとにした、当システム内部での結合を行うシナリオでの動作検証を保証する仕様書・結果報告書 |
| 外部結合テストシナリオ・結果報告書 | 業務フロー・基本設計をもとにした、外部システムとの結合を行うシナリオでの動作検証を保証する仕様書・結果報告書 | |
| 非機能要求テスト仕様・結果報告書 | 非機能要求定義に対するテスト・結果報告書 | |
| リリース | リリースタイムスケジュール | リリース手順・タイムスケジュールを定義したもの |
取引先