sho992 note
▼システム屋の独り言〜その１：システム開発の概要
システム開発の概要を纏めてみた。
システム開発の概要
１．要件定義
@要件定義書を作成する。
ユーザの「こんなシステムがほしい」という要望を元に、
・必要機能
・作業工数
・システムで使うハードウェア
・システムで使うソフトウェア
・作業工数
・作業にかかる見積もり
を纏め、要件定義書を作成する。
ここで、いい人ぶって安く見積もったり、できない機能を盛り込んだりすると後で失敗する大きな要因となる。
できることをちゃんと纏めることが大事！！
A必要あらば現状分析を行う。
要件定義を行う上で、システム屋の方がユーザ業務の現状分析を行い、システム化できそうな箇所を提案することもある。
２．基本設計・レビュー
@機能毎の入出力部分を纏める。
要件定義で定められた必要機能について
・データ入力部（画面、紙、DB、他機能からの受け渡し等）
・加工部（入力データの加工）
・データ出力部（画面、紙、DB、他機能への受け渡し等）
・制限事項
・機能毎の作業工数
を纏る。
A作成する処理（プログラム）を洗い出す。
@で纏めた内容を元に必要な処理（ユーザ画面、紙、加工ロジック等）を洗い出す。
B基本設計書を作成する。
@、Aの内容を纏め基本設計書を作成する。
C基本設計書をレビューする。
第3者と以下の観点でレビューする。
・要件定義で定められた内容を満たしているか。
・機能内の処理が正しいか
・機能間、システム間の連携が正しいか。
D問題点を浮き彫りにする。
基本設計書の作成・レビューを行うことで要件定義で見えなかった問題点を浮き彫りにする。
→ここで気が付いた問題等は「問題点管理表」を作成し、後の工程で埋もれないよう工夫する。
３．詳細設計・レビュー
@処理（プログラム）毎に以下の内容を決定する。
・項目レベルでの入力→加工→出力を明確にする。
・データや処理タイミングでの処理条件を明確にする。
・正常、エラーの処理を明確にする。
A詳細設計書を作成する。
@の内容を纏め詳細設計書を作成する。
B詳細設計書をレビューする。
第3者と以下の観点でレビューする。
・要件定義で定められた内容を満たしているか。
・処理が正しいか。
C問題点を浮き彫りにする。
詳細設計書の作成・レビューを行うことで基本設計で見えなかった問題点を浮き彫りにする。
→ここで気が付いた問題等は「問題点管理表」を作成し、後の工程で埋もれないよう工夫する。
この時点である程度、要件定義で見えなかった問題点が見えてくる。
問題点は大きく分けて２つになる。
・ユーザへの確認が必要なもの。
・システム開発内で調整すれば解決するもの。
解決できるものから解決していくよう勤める。
４．プログラム開発
詳細設計書を元にプログラムを作成する。
５．単体テスト
@単体テスト試験項目表作成
詳細設計書に書かれている内容を元に「単体テスト試験項目表」を作成する。
作成観点は、
・項目レベルでの出力内容があっているか。
・データや処理タイミングでの処理内容があっているか。
・正常、エラーの処理が正しく行われているか。
詳細設計書がうまくかけていれば、詳細設計書に確認番号を振る程度で終わる。
A単体テスト実施
@で作成した「単体テスト試験項目表」を元に単体テストを行う。
６．結合テスト
@結合テスト試験項目表作成
基本設計書に書かれている内容を元に「結合テスト試験項目表」を作成する。
作成観点は、
・機能間の連携が正しく行われるか。
・正常、エラーの処理が正しく行われているか。
A結合テスト実施
@で作成した「結合テスト試験項目表」を元に結合テストを行う。
７．運用設計
@誰が、何時、どこで、何をするかフローに纏める。
→システム想定外（停電、天災等）の動きも考慮する。
Aデータのバックアップタイミングや戻しの方法も検討する。
８．運用テスト
@運用設計書を元に実際にシステムを使ってみる。
Aシステムダウンした場合に、正しく復旧できることなども確認する。
９．リリース
めでたくシステムリリース
画像 (小 中 大)
2007.03.14：sho992
⇒HOME
(C)
powered by samidare
