応用情報　システム構成&システム開発（フォールトトーレラント、モジュール結合・分割・強度、レビュー、ヒューリスティック法）

⭐️システム構成⭐️

1.システムを処理の仕方によって分類

従来は…
○集中処理

○分散処理

↓
今は…

○クライアントサーバシステム

クライアントとサーバでやり取りをする
分散型である

✅シンクライアント(thin client)

サーバ→情報処理や保管をする。中枢
クライアント→入力や表示するだけ
↓
サーバを防御でき、情報漏洩などのリスクを軽減できる

✅ピアツーピア

完全な分散処理型
サーバがない

クライアントサーバシステムの機能

✅3層クライアントサーバシステム

○プレゼンテーション層
クライアントが、ユーザインターフェス(GUI)を使用できるように実装する

○ファンクション層
サーバ側が、業務を実現するための処理(ビジネスロック)をできるように実装する

○データ層
サーバ側が、データ管理の機能を使用できるように
実装する

↓
サーバ側で処理が完結する(シンクライアント)
そのため、サーバを防御でき、情報漏洩などのリスクを軽減できる

✅2層クライアントサーバシステム

○プレゼンテーション層&ファンクション層
クライアント側が、ユーザインターフェス(GUI)とビジネスロックを使用できるように実装する

○データ層
　　〃
↓
もしビジネスロックに変更があると、すべてのクライアントに修正が必要になる…面倒臭い

2.システムを構成によって分類

📌並行システム📌

2系統のシステムで常に線で繋いだ状態で並列処理をすることで、性能を上げる

📌デュアルシステム(2者)📌

一つの処理を、2系統のシステムで独立に行う
ただの並列処理と異なるのは、最後に繋ぎ結果を照合する

📌デュプレックスシステム(2連式)📌

メインのシステムと、サブのシステムに分ける

・ホットスタンバイ

データを分散させておく

◆ウォームスタンバイ

サブの施設に、予め機材を搬入しておく

◆コールドスタンバイ

サブ施設の場所だけ確保
災害時にようやく機材を搬入

📌クラスタ構成📌

・シェアドエブリシング

１つのデータを複数のサーバで共有・管理

✖　データベースの負荷が増大

・シェアドナッシング

データベース共有せず、サーバごとに保有
データは複数のデータベースに分散

✖　サーバが1台でも使えなくなると、システム全体に影響

3.システムの性能指標

会社によって、システムの性能が異なる。
性能を分かりやすく比較するために、指標がある

以下の３つの指標がある

〇スループット

単位時間あたりに処理できる仕事量

〇レスポンスタイム

処理にかかる時間

〇ターンアラウンド

入力+処理+出力にかかる時間

キャパシティプランニング

システムの稼働状況を定期的に評価して、処理能力を計画すること

✅スケールイン

サーバの台数を減らす
サーバリソースの最適化できる

✅スケールアウト（サーバをアウトする、つまり分散させる）

サーバの台数を増やす
並列処理に適している

☑スケールアップ

個々のサーバの処理能力を上げる。
一括処理に適する

☑スケールダウン

個々のサーバの処理能力を下げる
サーバリソースの最適化できる

4.強いシステムを作る設計

📌フォールトトレラント　fault tolerant

故障に対して寛容であること
※tolerant=寛容な

システムが部分的に故障しても、システム全体としては必要な機能が存在する設計

フェールソフト

障害発生時に、稼働を継続できる設計
(例)飛行機のエンジンは、片方が故障しても大丈夫
↓
ただし、機能は低下しながら稼働
(フォールバック)

フェールセーフ

障害発生時に、安全を優先させる設計

フェールオーバー

障害発生時に、バックアップで残したシステムに切り替える設計

フールプルーフ

人間が間違った操作をしても問題ない設計

フォールトマスキング

障害発生時に、影響が外部に及ばないようにする

📌フォールトアボイダンス

そもそも障害発生させないようにする考え方

5.信頼性の指標(RASIS)

R：信頼性

システムが故障せずに、どれだけ長く稼働できるか
平均故障間隔（MTBF)を用いる

A：可用性

ある期間でどれくらいの割合で稼働しているか
稼働率を用いる
＝平均故障間隔/（平均故障間隔＋平均修理時間）

S：保守性

修理のしやすさ
平均修理時間を用いる

I：保全性

データが正常に保存できているか

S：機密性

データが安全に保存できているか

MTBF・MTTR・稼働率　計算方法

・MTBF　Mean Time Between Failures　（平均故障間隔）

稼働時間の合計 ÷ 故障回数の合計

・MTTR　Mean Time To Recovery　（平均修理時間）

修理する時間の合計 ÷ 故障回数の合計

・稼働率

平均故障間隔/（平均故障間隔＋平均修理時間）
つまり、MTBF/(MTBF + MTTR)

⭐️システム開発の流れ⭐️

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

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

①企画でやること

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

☑️組織及び環境要件

③調達

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

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

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

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

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

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

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

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

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

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

5,契約

6,調達開始

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

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

④開発

1,システム要件定義

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

◆システム要件定義〜テストで行う開発の手法

✅ウォーターフォールモデル

上記の開発工程を順番に進めること

✅プロトタイピングモデル

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

✅スパイラルモデル

システム設計から後を、細かく分解して、最後に繋げる

☑️RAD (rapid application development)

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

☑️ラウンドトリップ開発

設計とプロトタイピングとを繰り返しながら開発を行うこと

※ラウンドトリップ＝往復

☑️クロス開発

ソフトウェアを実行する機器とは
CPUのアーキテクチャが異なる機器で開発を行う

☑️XDDP (extreme derivative development process)

派生開発を、変更プロセスと追加プロセスとに分けて開発を行う

📌アジャイル

スパイラルモデルの派生
より短い反復単位で開発をする手法の総称

・XP(エクストリーム　プログラミング)

アジャイルの代表的手法
少人数で素早く開発を進める開発手法

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

✅ペアプログラミング

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

✅リファクタリング

外部からの見た目を変えず、内部のコードだけを改善し続けること
↓
リファクタリング後は、回帰テストをして、他機器に悪影響がないか検証

✅継続的インテグレーション

単体テスト後、すぐに結合テストする手法
↓
問題点を修正していく

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

☑️テスト稼働開発

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

☑️ソースコードの共同所有

コードの作成者だけでなく、チーム内全員が修正できること

・XP以外の開発手法

✅リーンソフトウェア開発

トヨタ生産方式を、ソフトウェア開発に応用したもの

・バリューストアマップ

トヨタ生産方式で使われたマップ
付加価値を生み出す流れを、プロセスと共に図示されたもの

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

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

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

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

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

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

◆グラフを用いた、具体的手法

バーンダウンチャート

残り作業量と、予定との差を把握できる

バグ管理図

発見されたバグの累計が一定になれば、「これ以上バグが発見されていない」ことがわかる

以下のような信頼度成長曲線になることが理想

要因ヒストグラム

EVM（アーンドバリューマネジメント）

プロジェクトの進捗度を、お金に換算したもの
※実際にかかったお金ではない

詳しい計算方法は、以下の記事で

2,システム設計

(1)システム方式設計

・データ中心設計

データこそが、最も安定した共有資源であるため、データを中心に設計

・プロセス中心設計

業務手順・機能を中心に設計
業務の流れを、そのままプログラミング言語で記述

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

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

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

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

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

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

モジュールの分割方法

✅STS分割法

入力処理、変換処理、出力処理に分ける方法

✅トランザクション分割法

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

✅共通機能分割法

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

3,開発工程

✅フォワードエンジニアリング

プログラムの仕様から→新しいソフトウェアを開発
通常の工程

✅リバースエンジニアリング

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

☑️リエンジニアリング

フォワード+リバース

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

⑤テスト

モジュール

プログラミングにおいて、部品のこと

◆モジュールの性質

・独立性

他モジュールと直接関わらずに動作できる

・再利用性

作成したモジュールは、他のプログラム等で使用できる

・管理しやすい

モジュールとして細かく分けるため、管理しやすい

◆モジュール分割

✅STS分割

源泉S、変換T、吸収S、ごとに分割する方法
(DFDの源泉、吸収のこと)
つまり、入力処理、変換処理、出力処理のこと

✅(TR)トランザクション分割

切り離せない、一連の処理で分割する方法

✅共通機能分割法

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

◆モジュール分割の評価

◆モジュール結合

・内部結合

モジュールの内部を、直接参照する

・共通結合

大域宣言されたデータ構造を、複数のモジュールが参照

・外部結合

大域宣言された単一のデータを、複数のモジュールが参照

・制御結合

モジュールの動作を制御するための要素を受け渡す

・スタンプ結合

処理に必要なデータのみ、データ構造として受け渡す

・データ結合

処理に必要なデータだけ
⭕️データ結合が、最も結合度が弱い

〇静的テスト

プログラムを実行しないで行うテスト

〇動的テスト

プログラムを実行して行うテスト

📌単体テスト

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

✅ホワイトボックステスト

モジュールの内部構造が正しく作られているか検証するテスト

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

・命令網羅

⬜︎（命令）を一回でも通れば良い

・判定条件網羅

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

↓

📌結合テスト

スタブやドライバを使用し
モジュールをつないで、モジュール間のインターフェースを検証

✅ブラックボックステスト

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

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

✅トップダウンテスト

スタブ
下にあり、上位モジュール（ドライバ）から呼び出されるもの

上位モジュール（ドライバ）から開発するので、上位モジュールに対してテスト回数が多くなる
→上位モジュールの信頼性が高くなる

✅ボトムアップテスト

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

✖上位（ドライバ）に問題があると、下位（スタブ）もすべて修正しなきゃいけない

↓

📌システムテスト

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

↓

📌運用テスト

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

↓

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

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

※グラフ

バスタブ曲線

◯初期故障期
材料の欠陥、設計時のミスが原因で、故障率は高い

◯摩擦故障期
疲労によって高い

バグ管理図

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

逓減課金方式

システムを使えば使うほど、課金額が減っていくこと

※レビュー

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

レビューの種類

✅デザインレビュー

成果物の問題点の早期発見を、組織内で行う

✅コードレビュー

コードの内容のチェックを、組織内で行う

✅コードレビュー（Code Review）

• 目的: プログラムコードに対して、他の開発者がチェックを行うことで、品質を向上させる。

• 特徴: ソースコードの可読性、パフォーマンス、保守性を確認し、バグや設計の問題を発見する。

• 重要点: ペアプログラミングのように対面で行う場合や、ツールを使ってリモートで行う場合もある。

✅ピアレビュー（Peer Review）

• 目的: 同じプロジェクトや同じ分野のメンバー同士が成果物をレビューし合う。

• 特徴: 比較的インフォーマルな方法で、レビュー対象がドキュメント、コード、設計など多岐にわたる。

• 重要点: 同僚やチームメンバーによって行われるため、専門知識を共有でき、学習機会が増える。

✅アドホックレビュー（Ad-hoc Review）

• 目的: 非公式なレビュー方法で、特別な手順や役割分担なしに行われる。

• 特徴: 事前の準備を必要とせず、簡単に開始できる。例えば、同僚に成果物を見てもらうようなカジュアルなやり方。

• 重要点: 柔軟で迅速に行えるが、体系的ではないため見逃しが発生する可能性もある。

✅パスアラウンド

成果物を複数のレビュアーに回す
↓
コメントさせる

✅ウォークスルー

会議形式
成果物を説明
↓
質問

✅インスペクション (inspection、つまり検査)

モデレータ(責任者)が、作業全体をコーディネート
明確な役割に分けられ、チェックリストに基づく

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

✅ラウンドロビン

発言者を回していく方式

※ユーザビリティの評価

ユーザビリティとは

有効性・効率・満足度

✅インタビュー法

満足度を聞くときに、直接顧客に聞くこと

✅ヒューリスティック評価法

ヒューリスティック＝経験則
複数の専門家が、自分たちの経験則とプロトタイプを照らし合わせて評価

✅ログデータ分析法

被験者に製品を操作してもらい、その操作ログ（履歴）から利用パターンを分析

ユーザビリティを向上させる機能

✅入力チェック

ユーザがコンピュータに入力したデータが適切か調べること

⚪︎論理チェック
入力したデータが論理的に正しいかチェック
(例)商品の注文日が未来の日付になっているのは不適

⚪︎重複チェック
重複していないかチェック

⚪︎フォーマットチェック
正しい形式になっているかチェック

⚪︎シーケンスチェック
正しい順番で並んでいるかチェック

✅Undo機能

✅マクロ機能

✅ショートカットキー