peeks-blog

自分用メモ

随時追記していく

※参考：キタミ式イラストIT塾 基本情報技術者の内容まとめ

システム開発の流れ～マスタスケジュールとメンバー数の推移、各工程作業～

システム開発のマスタスケジュールとプロジェクトメンバーの人数の推移、
各工程の作業内容について解説。

まず「要件定義」という工程から始まる。→ウォーターフォール？
クライアントからどんなシステムを作りたいかヒアリングして、
要件定義書としてまとめる。

要件定義書が完成したら、見積もりに入る。
クライアントからの要望をどのくらいの期間、人数で行えるか見積もり、
クライアントと金額の交渉を行う。

交渉の結果、スケジュールとプロジェクトメンバー数が決まる。
ここでやっとシステム開発のプロジェクトの全貌が見えてくる。

システム開発のプロジェクトでは、メンバー数が大きく変動する。
なぜなら各工程で必要とされる作業内容と作業量が異なるから。

①要件定義

要件定義書と見積もりを作成することがゴールになる。
・主な作業内容：打ち合わせ→要件定義書作成→見積もり作成

②基本設計（BD）

要件定義をインプットに、クライアントに見える画面や帳簿等の詳細を定義する。
機能単位で担当者を決めて基本計画書を作成し、チーム内部でレビューを行う。
レビューは、指摘を取り込んで何度も実施することが多い。
内部でのレビューが終わったら、クライアントにもレビューしてもらう。
・主な作業内容：基本設計書作成→内部レビュー→お客様レビュー

③詳細設計（DD）

基本計画書の内容を、どのようにPGMで実現するか検討し、
PGM単位で詳細設計書としてPGが作成する。
それを基本設計を担当したSEがレビューする。クライアントは出てこない。
記載のレベル感は、プロジェクトによって全く違う。
・主な作業内容：詳細設計書作成→内部レビュー

④製造・単体テスト（M/UT）

詳細設計書をもとにPGがプログラムを作成する。
完成時たらテストケース（パターン）を作成し、
PGM単位で詳細設計書通りに動くかを検証する。
SEはテスト結果のレビューや各種ルール作り、テストで発見したバグ対応等を行う。
・主な作業内容：プログラム作成→単体テストケース作成
　→単体テスト実施→単体テストケース/結果レビュー

⑤結合テスト（IT）

単体テストでPGM単位での検証を行なったが、その範囲を機能単位での検証に拡大する。
結合テストでは、基本設計書通りに動くかを検証する。
基本設計レベルの検証のためテストケースをSEが作成し、テスト実施をPGがやる事が多い。
・作業内容：結合テストケース作成→テスト実施→結果レビュー

⑥総合テスト（ST）

要件定義の内容通りにシステム全体が動くかを検証する。
具体的には、要件定義で作成した業務フローをもとに、
テストシナリオ（テストの流れ）を作成する。
それを、更に詳細な確認ポイントを記載した、テストケースに落とし込む。
開発側のテストはこれで終わり。この段階でバグを出し切る必要がある。
・作業内容：シナリオ作成→ケース作成→テスト実施→結果レビュー

⑦受入テスト（RT）

基本的にクライアント側のテストなので、開発側が実施する作業はない。
テストを実施するための準備を行なったり、問い合わせ対応を行う。
ただクライアントがシステムに詳しくない場合は、
ケース作成から開発側でやる事もある。
・主な作業内容：お客様テストのヘルプ、お客様お問い合わせ対応

その他、見ておいた方がいいページまとめ

【SI業界】そもそもシステムって何よ？【就活生向け】


【SI業界】システム開発の流れ～プロジェクト概要と体制図～【就活生向け】


SI業界は知識集約型ではなく労働集約型の産業であり、これにより日本のシステムはダメになっている。


「WBS」と「詳細スケジュール」はどう違う？スケジュール管理のツールまとめ
※画像：WBSやプロジェクトマネジメントの内容まとめ


スケジュール管理って何をするんだろう？ スケジュール管理の「準備」と「運営」＋4つのポイント


システム開発のスケジュールの立て方を書いてみた。1


※参考：アローダイアグラムとは？記号や結合点、クリティカルパスについて

システム開発の概要

これまで人の手で行なっていた企業内の業務活動を
コンピュータに置き換えて効率アップを実現しようとするのが
システム開発（伝票書き作業が代表例）

システム開発は長い作業なので、
無事に行えるようにと、
様々な開発手法や分析手法が考案されている

システム開発の調達を行う

情報提供依頼
提案依頼書（RFP）の作成と提出
見積書の受け取り
システムベンダの選定

開発の大まかな流れと対になる組み合わせ

基本定義（要件定義）
システム定義
→外部設計：フロントエンド？
→内部設計：バックエンド？
→プログラム設計
プログラミング
テスト
→単体テスト：プログラム設計と関連
→結合テスト：内部設計と関連
→システムテスト：外部設計と関連
→運用テスト：基本計画（要件定義）と関連
導入と運用

システムの開発手法

ウォーターフォールモデル
プロトタイピングモデル
スパイラルモデル
RAD（迅速なアプリケーション開発）
アジャイルとXP（eXtreme Programing）
リバースエンジニアリング
マッシュアップ

「開発」とは？関係者や現場環境、手法など

開発に関わる関係者について

ユーザー、SE、プログラマ、プロジェクトマネージャの４者

SEはプログラマに指示を与える人である、SEは段取りを行う人
単にコーディングする人は「コーダー」と呼ばれる

プログラマーに留まって欲しくない
プロジェクトマネージャーになって欲しい

実際の現場環境

大きく「定義」「制作」「運用」の３つに分かれる
比率としては定義が4割、制作が2割、運用が4割

定義はヒアリングや要件定義、仕様書作成を行う
ここが一番難しい、顧客先に聞きに行く必要がある
人から話を聞き出す力が求められる
IT的な言葉を使わずに要望を聞き出す
高度なコミュニケーション能力が必要になる
3年のプロジェクトの中で1年半はここに費やされる事もある

制作はプログラミングやデザイン、テストを行う
プログラマが関わるのは「制作」の段階
コーディングしてる時間は案外短い

運用はバグの修正や機能の追加、環境の整備を行う

20人位の大きなチームだと役割は分かれる
15人以下だとプログラマが制作以外の領域を兼任することもある

開発手法について

以下の３つの手法がある。

・ウォーターフォール型
システム開発における各工程を順番に進めていく開発手法

・アジャイル型
反復 (イテレーション) と呼ばれる短い開発期間単位を
採用することで、リスクを最小化しようとする開発手法

・プロトタイプ型
試作品を作り、お客様に確認してもらいながら
開発を進めていく技法

※参考：フローチャートとは？条件分岐や繰り返しなど