自分用メモ
随時追記していく
※参考:キタミ式イラスト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

Page not found | Babls
※参考:アローダイアグラムとは?記号や結合点、クリティカルパスについて
システム開発の概要
これまで人の手で行なっていた企業内の業務活動をコンピュータに置き換えて効率アップを実現しようとするのが
システム開発(伝票書き作業が代表例)
システム開発は長い作業なので、
無事に行えるようにと、
様々な開発手法や分析手法が考案されている
システム開発の調達を行う
情報提供依頼
提案依頼書(RFP)の作成と提出
見積書の受け取り
システムベンダの選定
開発の大まかな流れと対になる組み合わせ
基本定義(要件定義)
システム定義
→外部設計:フロントエンド?
→内部設計:バックエンド?
→プログラム設計
プログラミング
テスト
→単体テスト:プログラム設計と関連
→結合テスト:内部設計と関連
→システムテスト:外部設計と関連
→運用テスト:基本計画(要件定義)と関連
導入と運用
システムの開発手法
ウォーターフォールモデル
プロトタイピングモデル
スパイラルモデル
RAD(迅速なアプリケーション開発)
アジャイルとXP(eXtreme Programing)
リバースエンジニアリング
マッシュアップ
「開発」とは?関係者や現場環境、手法など
開発に関わる関係者について
ユーザー、SE、プログラマ、プロジェクトマネージャの4者SEはプログラマに指示を与える人である、SEは段取りを行う人
単にコーディングする人は「コーダー」と呼ばれる
プログラマーに留まって欲しくない
プロジェクトマネージャーになって欲しい
実際の現場環境
大きく「定義」「制作」「運用」の3つに分かれる比率としては定義が4割、制作が2割、運用が4割
定義はヒアリングや要件定義、仕様書作成を行う
ここが一番難しい、顧客先に聞きに行く必要がある
人から話を聞き出す力が求められる
IT的な言葉を使わずに要望を聞き出す
高度なコミュニケーション能力が必要になる
3年のプロジェクトの中で1年半はここに費やされる事もある
制作はプログラミングやデザイン、テストを行う
プログラマが関わるのは「制作」の段階
コーディングしてる時間は案外短い
運用はバグの修正や機能の追加、環境の整備を行う
20人位の大きなチームだと役割は分かれる
15人以下だとプログラマが制作以外の領域を兼任することもある
開発手法について
以下の3つの手法がある。・ウォーターフォール型
システム開発における各工程を順番に進めていく開発手法
・アジャイル型
反復 (イテレーション) と呼ばれる短い開発期間単位を
採用することで、リスクを最小化しようとする開発手法
・プロトタイプ型
試作品を作り、お客様に確認してもらいながら
開発を進めていく技法
※参考:フローチャートとは?条件分岐や繰り返しなど
この記事へのコメントはありません。