基本情報技術者　企業が行うべきシステム開発の流れ、手法　モジュール結合・分割・強度

システム開発の流れ

①企画→②要件定義(基本計画)→③調達→④開発→⑤テスト→⑥運用と保守の繰り返し
※各工程で必ず、レビューを行う(最後に詳しく記載)

共通フレームがこれらを定義している

①企画でやること

経営者に、経営上のニーズを聞く
経営・事業の目的を達成する上で、要求される内容を、定義すること

1,プライバシーバイデザイン

予防的に、システムから個人情報が漏洩するリスクを減らすこと

2,システム化構想の立案プロセス

新たなシステムの構想を立案する
↓
具体的に…
経営上の課題・ニーズを確認したり、仕事をする環境の調査をしたりする

全体最適化(P549)を実現するシステムを開発するために必要
経営戦略を無視すると、部分最適化になる恐れがある

3,システム化計画の立案プロセス

上のシステム化構想を実現するために、計画をする
↓
具体的に…
・ITポートフォリオを用いて、投資配分を考える(ROIも考慮する)

②要件定義(基本計画)でやること

ベンダーに対して発注する前に、システムが持つべき機能や性能を予め決める

1,ユーザー、利害関係者(ステークホルダー)のニーズを知る

2,要件定義に必要な３つの要素を定義する

☑️業務要件
業務について行うべき要件

✅機能要件
ユーザーから聞いてわかった、必要な機能

✅非機能要件
表面にはない裏の要件
試験によく出るのは、「開発基準の技術要件」

☑️組織及び環境要件

③調達

開発を担当するシステムベンダーに対して、発注をかけること

1,発注側が情報提供依頼書(RFI)を書く

RFI→リクエスト　for インフォメーション

ベンダーに対して、ベンダーの情報(実績等)を送るように、要求すること

2,発注側が提案依頼書(RFP)を書く

RFP→リクエスト　for プロポーサル

ベンダーに対して、システム設計や機器構成の内容、受注条件などを記載した提案書を提出するよう、要求すること

※RFPを作成するメリット
・認識の相違による開発手戻りが減る
・発注先の選定基準が明確になるので、価格が適正になりやすい

3,ベンダーが、提案依頼書に答える形で、提案書を返送する

4,発注側がシステムベンダーを選定する

5,契約

6,調達開始

✅CSR調達
社会的責任(調達先の労働環境など)を果たした調達の仕方を求めること

✅グリーン調達(グリーン購入)
発注側が調達先から製品を購入する時に、環境にやさしい製品を優先して買うこと
調達先は、ISO14001という規格を取得して、環境にやさしい製品を作る

④開発

1,システム要件定義

ベンダー側(調達先)が、現状の業務を分析し、システムが持つべき機能や性能(システム要件)を整理する

2,システム設計

(1)システム方式設計

(2)ソフトウェア要件定義

顧客に意見を求めて、仕様を定義する
業務モデル(DFD データフロー図)を作成して定義

(3)ソフトウェア方式設計

ソフトウェア要件定義の後に行う
ソフトウェア品目に対する要件を，最上位レベルの構造を表現する方式であって、かつ，ソフトウェアコンポーネントを識別する方式に変換する。

(4)ソフトウェア詳細設計

ソフトウェア方式設計で、プログラムを、モジュールに分割すること

⭕️データ結合が、最も結合度が弱い

モジュールの分割方法
✅STS分割法
入力処理、変換処理、出力処理に分ける方法

✅トランザクション分割法
一連のトランザクション単位に分ける方法

✅共通機能分割法
共通機能をモジュールとして分割する方法
↓
類似機能を重複して作らなくても良い

3,プログラミング

以下の記事に全て書いてある

システム要件定義〜テストで行う開発の手法(伝統的なもの)

📌ウォーターフォールモデル📌
上記の開発工程を順番に進めること

☑️プロトタイピングモデル
開発初期の段階で、試作品(プロトタイプ)を作り、利用者に確認してもらう

☑️スパイラルモデル
システム設計から後を、細かく分解して、最後に繋げる

システム要件定義〜テストで行う開発の手法(新しいもの)

☑️RAD
とにかく短期間で開発を行うための手法
プロトタイプ(試作品)を作って、それを評価するサイクルを繰り返す。
↓
ただし、期限を設けないと無限になるので
期限(タイムボックス)を作る必要がある。

📌アジャイル📌

スパイラルモデルの派生
より短い反復単位で開発をする手法の総称
↓
XP(エクストリーム　プログラミング)
アジャイルの代表的手法
少人数で素早く開発を進める開発手法

以下、XPの開発の具体的手法

✅ペアプログラミング
2人一組でプログラムを組む手法
1人がコードを書いて、もう1人がそのコードの検証役となる

✅リファクタリング
完成した後も内部のコードだけを改善し続けること

✅テスト稼働開発
テストを決めてから、ソフトウェアを作り込む手法

✅継続的インテグレーション
単体テスト後、すぐに結合テストする手法
↓
問題点を修正していく

◯バグを早期発見できる
◯ソフトウェアの品質向上が見込める

☑️ソースコードの共同所有
コードの作成者だけでなく、チーム内全員が修正できること

☑️YAGNI
You Aren’t Going to Need It.の略
あなたはそれを必要とする予定ではない
↓
言い換えると
今必要とされる機能だけの、シンプルな実装に留めること

☑️マッシュアップ
公開されているサービスを組み合わせて、新しいサービスを作る手法
各サービスがAPIを公開しており、これを利用して組み合わせる

スクラム(アジャイルでの管理手法)

スプリントと言う単位でプロジェクト管理すること

◯スプリントの具体的イベント
割愛

◯スクラムで関わる人物
・責任者(プロダクトオーナー)
作業内容に優先順位をつけたプロダクトバックログを作成
↓
・スクラムマスタ
全体の進捗度の管理 & 意思疎通の円滑化
メンバーが自律的に協働できるようにする
↓
・開発者
実際に開発
成果物をインクリメントという

開発工程

✅フォワードエンジニアリング
プログラムの仕様から→新しいソフトウェアを開発
通常の工程

✅リバースエンジニアリング
既存のソフトウェアの解析で、プログラムの仕様・ソースコード(UMLのクラス図やE-R図など)を導く
通常の工程とは逆なのでリバース

☑️リエンジニアリング
フォワード+リバース

※ソフトウェア権利者の許可なく行うと、知的財産権の侵害にあたる可能性

モジュール結合

データ結合が一番弱い

モジュール分割

・STS分割
源泉S、変換T、吸収S、ごとに分割する方法
(DFDの源泉、吸収のこと)

•(TR)トランザクション分割
切り離せない、一連の処理で分割する方法

モジュールの強度

7つある

⑤テスト

単体テスト

各モジュールごとにテストを行うテスト

✅ホワイトボックステスト
モジュールの内部構造が正しく作られているか検証するテスト

以下の網羅性のレベルに基づきテストケースを設計
↓

・命令網羅

⬜︎を一回でも通れば良い

・判定条件網羅

◇で、真と偽の両方を一回は通る必要がある

↓

結合テスト

モジュールをつなぎ合わせて検証を行うテスト

✅ブラックボックステスト
同値分割
データ範囲を種類ごとに分けて、その中からテストデータに用いるものを抜き出す

限界値分割
境界値前後の値をテストデータに用いる

✅トップダウンテスト
スタブ
下にある、上位モジュールから呼び出されるもの

✅ボトムアップテスト
ドライバ
上にある、引数を渡して下位のモジュールを呼び出す(下位のモジュールからテストをおこなう)もの

↓

システムテスト

システム全体が正常に作動するか確かめるテスト
本番環境とは隔離された環境で行う
全ての要件事項を網羅するように設計する

↓

運用テスト

システムを、本番と同じ環境で作動して、正常に作動するか確かめるテスト

↓

リグレッションテスト(退行テスト)

プログラムを修正したときに、修正したものが逆に悪影響を与えていないか確かめるテスト

バグ管理図

発見されたバグの累計が一定になれば、「これ以上バグが発見されていない」ことがわかる
↓
これを表した図が、バグ管理図。以下のような信頼度成長曲線になることが理想

※レビュー

各工程で必ず行う、振り返り作業のこと

レビューの種類

✅デザインレビュー

✅コードレビュー

✅パスアラウンド
成果物を複数のレビュアーに回す
↓
コメントさせる

✅ウォークスルー
会議形式
成果物を説明
↓
質問

✅インスペクション (inspection、つまり検査)
モデレータ(責任者)が、作業全体をコーディネート
明確な役割に分けられ、チェックリストに基づく

チェックリストに基づいて検査をすると覚えよう

✅ラウンドロビン
発言者を回していく方式