システム開発の進め方
システム開発の進め方
homepage
# システム開発の進め方 ## 担当と役割について プロジェクトは、組織的に実施される <img src="https://s2.ax1x.com/2019/10/11/uHabhn.png" width="80%"/> <br><br><br> ## PM(プロジェクトマネージャー)の役割について ・ 管理職<br> ・ 大きなプロジェクトの管理<br>  &e若しくは、複数のプロジェクトの管理<br>  ( 工数、進捗、品質などを管理 ) ・ ユーザとの交渉 ( 予算、体制など )<br> ・ 決裁<br>  見積書提出、契約処理、請求処理、予算管理 <br><br><br> ## PL(プロジェクトリーダー)の役割について ・PMの下について、プロジェクトの管理と メンバーの管理<br> ・サブチームリーダとして、工数、進捗、品質など の管理<br> ・場合により、仕様書や設計書の作成にも携わる。<br> <br> ・ SE3年以上の経験者<br> ・ 決裁に近い判断を行うことができる人材<br> <br><br><br> ## SE(システムエンジニア)の役割について ・ 顧客との打ち合わせ<br> ・ プログラマとの調整<br> ・ 資料作成<br> ・ 主に、要件定義~詳細設計 の業務を行う。<br> <br> ・ PG3年以上の経験者<br> <br><br><br> ## PG(プログラマ)の役割について ・ プログラミング(専任)<br> ・ テスト明細の作成<br> ・ テストの実施<br> <br> ・ 詳細設計書を見てプログラミングを行う。<br> <br><br><br> ## 業務フローについて システム製造に関わる業務について説明する。<br> 業務としては、以下の工程で流れる。<br><br> 要件定義→基本設計→機能設設→詳細設計→製造→単体テスト→結合テスト→運用・保守<br><br><br> ## 要件定義ついて ・ユーザから、「何をしたいのか」 「何が必要か」 を聞き取り、完成したシステムで、どんなことを、したいかを文書としてまとめたもの。<br> ・ユーザが必要としている要件を定義し、まとめたもの。<br><br> <img src="https://i.loli.net/2019/10/17/K6VFrIwOJ1ZTuCp.png" width="80%"/> <img src="https://i.loli.net/2019/10/17/bBTzgRaoLvyw86s.png" width="80%"/> <br><br><br> ## 要件書サンプル <br> <img src="https://i.loli.net/2019/10/17/TPl83hICojZ12xp.png" width="80%"/> <img src="https://i.loli.net/2019/10/17/SXMbk12dAti4n5F.png" width="80%"/> <br><br><br> ## 基本設計ついて ・要件定義を基に、システムの基礎的な仕様を文書としてまとめたもの。<br> [内容]<br> 機器の構成<br> 実装すべき機能<br> 画面や帳票などの操作<br> 入出力に関する事項<br> 生成・保管されるデータの概要 など<br> <br> <img src="https://i.loli.net/2019/10/17/JL3kwfUvc4YMdCP.png" width="80%"/> <br><br> ## 基本設計書サンプル (1) <img src="https://i.loli.net/2019/10/17/rLGMP39s4lB7gmX.png" width="80%"/> <br> <img src="https://i.loli.net/2019/10/17/3GyOEXwQz4Ja2NM.png" width="80%"/> <br><br> ## 基本設計書サンプル (2) <img src="https://i.loli.net/2019/10/17/Ff8HtBueLcwOaW2.png" width="80%"/> <br> <img src="https://i.loli.net/2019/10/17/8htGAixa5fCwoMV.png" width="80%"/> <br><br><br> ## 機能設計ついて ・システムに実装すべき機能を定義したもの。<br>   ( システムに必要な機能を定義する )<br> ・各機能を実現するためのシステムやプログラム、データの構成や仕様などを定義する。 <br><br><br> ## 詳細設計ついて ・システムの構造や仕様などをプログラム単位に分割し、各プログラムの動作を定義したもの。<br> <img src="https://i.loli.net/2019/10/17/g2zS91XmNbFwkOr.png" width="80%"/> <br><br><br> ・詳細設計書を基に、プログラマーが ソースコードを記述する。( コーディング ) <br><br><br> ## 単体テストについて ・ 個々のモジュール(部品)を対象としたテスト。<br> ・対象のモジュールが仕様書で要求された機能や性能を満たしているかどうかをテストする。<br><br> ・ テストはローカルな端末で実施してもよい。 <br><br><br> ## 結合テストついて ・ 複数のモジュールを組み合わせて行うテスト。<br> ・ 単体テスト後に行う。<br> ・ 主にモジュール間のインターフェース(接点)がうまく機能するかどうかに注目して行われる。<br><br> ・ お客様の環境と同じ環境でテストを行う<br> ・ 単体テストと重複するテストは実施しない。<br><br><br> ## 単体/結合テストついて ・ テスト明細書の作成<br> ・ テスト明細書のレビュー<br> ・ テストの実施<br> ・ テスト結果の確認<br> ・ テスト結果の報告<br> <img src="https://i.loli.net/2019/10/17/muq5R6dzM7n93fj.png" width="80%"/> <br><br><br> ## テストに関して知っておきたい用語ついて ### バグ(欠陥)密度 = 検出バグ数 ÷ ソースコード数<br> 単体テスト:6件/KLOC<br> 結合テスト:3件/KLOC<br> バグが多ければ、コーディングの品質が悪すぎるとされる。<br> バグが少なければ、テストでバグの検出が十分にされていないと判断される。<br> ### ホワイトボックステスト システム内部の構造を理解した上でそれら一つ一つが意図した通りに動作しているかを確認する、プログラムのテスト方法。<br> ### ブラックボックステスト プログラムの内部構造とは関係なく、外部から見て仕様書通りの機能を持っているか確認するテスト方法。<br><br><br> ## 運用・保守ついて ・ マシンやアプリケーションの起動、停止<br> ・ データやアプリケーションのバックアップ作成、保管<br> ・ システム障害やシステム停止からの復旧作業<br> ・ マシンやネットワークの運転状況の監視<br> ・ システム資源(メモリ、CPU、ディスク)の監視<br><br> ・ システムの障害(バグやトラブル)の原因究明<br> ・ ネットワーク環境の障害対応<br> ・ 周辺機器、サーバ、OS、端末のリプレース<br>
content
戻る