FGK-SYSTEMS 


戻る トップメニュー

.

システム開発の作業工程と作成される資料について

最近の2年で、いろいろなドキュメントを見てきた。どれも使いにくいし目的の 資料にたどりつくのに時間を無駄にしていた。どうしたら使いやすいのか。 整理してみた。

ホルダー

最初にホルダーの作り方のルールが必要だ。混乱させるホルダーは、打合せやレビューの度に 作成されるホルダーに重要な資料が散らばってしまうことだ。例えば分析段階であれば、 当初決めたUMLや業務機能説明書が、ヴァージョン管理され更新されなければならない。 管理される資料は複数に細かく分かれたファイルで良いのだが、構造化されたホルダーの 中に格納されていなければならない。

開始から分析段階

ホルダーを考える前に、プロジェクトの作業を整理しよう。 始まり方はいろいろあるので、おいといて、分析段階の作業の整理から。
・仕事の概略をまとめる。
・現状の調査と現状についての資料作成。
・現状調査結果のレビュー。
・新の業務についての資料資料作成。(改善や新業務モデルの反映)
・規模と大日程の予測
・新の業務についてレビュー

トップのホルダー

ホルダー名はプロジェクトコード
現状処理の資料用と新規開発用のホルダーは別にする。 例として
・旧のトップのホルダー名は”プロジェクトコード”+v1
・新のトップのホルダー名は”プロジェクトコード”+v2
新のトップホルダーに下記の者を格納する。
・あれば 要求仕様 (Requirement)
・あれば 提案依頼書(RFP ( Request For Proposal))
・大日程のファイル
・体制図のファイル
・分析段階資料のトップのホルダー
・環境関係の資料のトップのホルダー
・設計段階資料のトップのホルダー
・データベース資料のトップのホルダー
・レビューのファイルを格納したレビュー日ごとのホルダー

分析ツール

分析ツールとしてはDFDだ。最近使われないのだが、構造化がとても便利だ。 使われなくなったのは、設計段階でデータベースの書き方とオンライン処理の扱い方が うまくできないためだ。しかし分析段階では関係ない。 データベースはコンテキストに四角が一つあればいい。各フローのページにはDB検索とDB更新の線が 使われれば良い。分析段階では機能が重要だ。おおくくりのデータの流れで機能があぶり出されてくれば 問題ない。 オンライン処理も同じくコンテキストに部署の四角があれば十分、 各フローのページには画面操作の意味の線で良い。DFDの利点は最後のバブルにスペックのページを作るので、 ここに分析段階で必要な画面操作内容やデータベース操作内容が記述される。

分析段階資料のトップのホルダー

ホルダー名は”プロジェクトコード”+"_analysis"(または”分析”)
ここには下記のファイルとホルダーが置かれる。
・分析段階の日程と進捗のファイル
・分析段階資料のマイナーバージョン管理ファイル
・DFD
・スペックのファイル(スペックごとに別々に作成)
・WBS
・開発体制(分析、設計、実装で都度更新される)
・開発スケジュール(分析、設計、実装で都度更新される)
・Old ホルダー

バージョンとファイル名

ファイル名は、ファイル内容と構成の場所とマイナーバージョンが判るように作成する。下記は参考例。 ・”プロジェクトコード”+構成位置+処理名+バージョン

・PPPP_2_1_7_在庫登録_v001
マイナーバージョンは最初はv001から置く。マイナーバージョンはファイルごとではなく、 分析は分析単位、設計は設計単位、データベースはデータベース単位に付与する。
ファイルを変更した場合、廃止した文章や修正前の文章はコメントアウトや見え消しではなく、削除する。 修正する前にまず対象ファイルをOldホルダーにコピーする。変更前を残さなくてもOldホルダーをみれば 良いようにしておく。

ファイルの説明

スペックのファイル
   ・スペックの詳細(処理内容とDB操作)
   ・システム設計へつなげるためのプログラムID
   ・画面のイメージ
   ・画面操作の概要
要求仕様 (Requirement)
   ・開発依頼するシステムの概要
   ・システム化の目的・背景・狙い
   ・開発依頼するシステム要件
提案依頼書(RFP ( Request For Proposal))
   ・開発依頼するシステムの概要
   ・システム化の目的・背景・狙い
   ・開発依頼するシステム要件
   ・エンドユーザーが必要とするハードウェアやソフトウェア
   ・エンドユーザーが必要とするサービス
   ・依頼事項、保証用件、契約事項など
WBS
   ・工数を見積もるために作成
   ・進捗管理には使わない  

設計段階 環境とDB

アプリの設計に入るまえに、使用するアプリサーバ、DBサーバ、ネットワーク、パソコンを決めておこう。 そしてプログラム仕様書を作るときに参照できるレベルでデータベースを設計する。 下記ホルダーを作りプログラム仕様書を作れるように準備する。 ・環境関係の資料のトップのホルダー
・設計段階資料のトップのホルダー
・データベース資料のトップのホルダー
・プロジェクト管理のトップのホルダー

環境関係の資料のトップのホルダー

ホルダー名は”プロジェクトコード”+"_environment"(または”環境”)
ここには下記のファイルとホルダーが置かれる。
 ・設計段階環境関係の日程と進捗のファイル
 ・設計段階環境関係資料のマイナーバージョン管理ファイル
 ・システムの構成図
 ・ネットワーク構成図
 ・共通化仕様書
   ・画面の表示規則
   ・ボタン等の配置位置などの規則
   ・命名の規則
 ・機能一覧
   ・機能ID(プログラム設計から運用まで管理しやすいコードを付ける)
   ・機能名(DFDのスペックにほぼ1隊1で対応)
 ・非機能要件(性能、操作性、拡張性、保守性、移行性、セキュリティ、環境) ・Old ホルダー

データベース資料のトップのホルダー

ホルダー名は”プロジェクトコード”+"_detabase"
ここには下記のファイルとホルダーが置かれる。
 ・設計段階DB関係の日程と進捗のファイル
 ・設計段階DB関係資料のマイナーバージョン管理ファイル
 ・ER図
 ・テーブル一覧
 ・各テーブル説明書
 ・Old ホルダー

設計段階 プログラム

プログラム仕様書を作成する。併せて操作説明と単体テスト用のテスト計画書も作成する。 この段階で内部へレビューする。 そしてこの作業をした人が、単体テスト結果の確認をする。 設計者がテストの確認をすることは開発を効率にする。 テスト確認後の内部へのレビューをする。 サーバ側と画面側の設計を分けるプロジェクトが結構あるが、分けてはいけない。この件はべっと説明する。  

設計段階資料のトップのホルダー

ホルダー名は”プロジェクトコード”+"_design"
ここには下記のファイルとホルダーが置かれる。
 ・プログラム設計の日程と進捗のファイル
 ・プログラム設計資料のマイナーバージョン管理ファイル
 ・各プログラムの仕様書(仕様書が多い場合はホルダーにまとめる)
   ・処理概要
   ・レイアウト図(画面やファイル)
   ・処理詳細
   ・制約等(性能、操作性、)
 ・各プログラムのテスト計画書
 ・各プログラムの操作マニアル
 ・Old ホルダー

実装段階

プログラムを作成し、所定の場所へ格納する。プログラマは必ず単体テストをし、 単体テスト計画書に結果を記入する。

実装作業のトップのホルダー

ホルダー名は”プロジェクトコード”+"_program"
ここには下記のファイルとホルダーが置かれる。
 ・実装の日程と進捗のファイル
 ・各プログラムのテスト計画書(テスト結果)
 ・Old ホルダー

.

戻る トップメニュー


2022-09 Copyright FGK-SYSTEM. All Rights Reserved.