システム開発技術

# 情報システム戦略とシステム企画
## 情報システム戦略
経営戦略 → 情報システム全体考えよう
### 全体最適化計画
全体的な目線　→　情報システムの最適な形を考える計画
### 情報システム管理基準
（経済産業省）情報システム管理のルールを定める
### CIO(Chief Information Officer)
情報戦略を考え、経営戦略との矛盾を確かめる人（最高情報責任者）
・**ITガバナンス**：　情報システム戦略をコントロールすること

## EA（Enterprise Architecture）
各業務を見直す手法
→ 現在の姿（**As-lsモデル**）　↔︎　あるべき姿（**To-Beモデル**）　＝　差を分析（**ギャップ分析**）

（４つの視点で分析）
|アーキテクチャ|方法|
|:--|:--|
|**ビジネスアーキテクチャ**|ビジネスで実現すべき業務をまとめる|
|**データアーキテクチャ**|業務で必要なデータをまとめる|
|**アプリケーションアーキテクチャ**|業務の流れに合うシステムをまとめる|
|**テクノロジーアーキテクチャ**|システムに必要な技術的要素をまとめる|



## 共通フレーム
システム開発：ベンダ企業（IT製品をユーザーに販売する会社）によって同じ用語でも、解釈が異なる
→ **共通フレーム**：　ソフトウェア開発の「共通の物差し」＝作業範囲を明確化

(共通フレームのプロセス)
企画プロセス　→ 要件定義プロセス　→ システム開発プロセス　→ ソフトウェア実装プロセス　→ 保守プロセス
　
## 企画プロセス
システム化構想・システム化計画を立案する
### システム化構想
経営戦略にもとづいて、システム化の方針を考える
### システム化計画
構想を具現化するための計画
例）システム化する業務、スケジュール、コスト、役割分担.... を明確にする



## 要件定義プロセス
利用者のニーズ　→ システムの仕様を決める　例）　どんな家建てる？どういう機能持たせる？
- **業務要件**：　業務上実現すべき要件
- **機能要件**：　実現のために必要な機能
- **非機能要件**：　機能要件以外の部分（性能、信頼性、セキュリティ、移行方法、運用方法...）



## ベンダ企業を決める
システム開発を担当するベンダー企業を選ぶ
例）　家を建てることが決定　→　複数の業者から見積もり　→ 「どの業者に頼むの？」を考える

（ベンダ企業を選ぶ流れ）
![調達計画.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/bd5d4801-f67d-1c84-bcdb-e6cdaba9ed64.jpeg)
1. [発注側]　**情報提供依頼**(**RFI**(Request For Information))：ベンダの技術、製品に関する情報提供を依頼
1. [ベンダ側]　情報提供
1. [発注元]　**提案依頼書**(**RFP**(Request For Propodsl))：　システム内容、予算を提示　→ 提案書の提出を依頼
1. [ベンダ側]　**提案書**　：RFPを元に、具体的な内容を提出
1. [ベンダ側]　**見積書**　：「提案書」OK → 開発・運用・保守の費用を提示

＊　**NDA**（Non-Disclosure Agreement）：　秘密保持契約
＊　**CSR**(Corporate Social Responsibility)：　企業の社会的責任
　→ **グリーンIT**：　環境への配慮をしている情報通信機器を選ぶ
　→ **グリーン購入**：　グリーンITを実践している製品・サービスを選ぶこと









# ソフトウェア開発
システム開発を担当するベンダーが決定　→ ベンダで開発が始まる
## ソフトウェア開発工程
１. **システム要件定義**（外部設計）：　利用者にヒアリング　→　機能・性能を定義
成果物：システム要件定義書
決定内容：　システムの応答時間・処理時間など

２.**ソフトウェア要件定義**（外部設計）：　利用者にヒアリング　→ ソフトウェアに必要な機能を定義
成果物：ソフトウェア要件定義書
決定内容：　業務モデリング・ヒューマンインタフェースの設計など

３.**システム設計**（外部設計）：　開発者　→ システム要件を実現する方法を考える
成果物：システム設計書
決定内容：　ハードウェア構成・ソフトウェア構成、使うDBなど

４.**ソフトウェア設計書**（内部設計）：　開発者　→ ソフトウェア要件を実現する方法を考える
成果物：ソフトウェア設計書
決定内容：　ソフトウェア構造、ヒューマンインタフェース詳細設計など

５.**実装・構築（プログラミング）**：　開発者　→ プログラムを作成
成果物：プログラム

６.**テスト**：　プログラムにミスがないかテストを行う


## 開発手法
ソフトウェア開発の種類
### ウォーターフォールモデル
上位工程　→　下位工程　へ順番に進めていく方法

（特徴）
- スケジュールの管理がしやすい
- 各工程が完了　→　次の工程へ進む
- 前工程に戻る（手戻る）ことがないよう、各工程で綿密にチェック

（欠点）
- 開発途中に、利用者の要件を取り入れにくい
- 仕様変更　→ コスト・時間が膨大
- 最後の工程で不具合　→ 出戻りが多くなる
- 上流工程での間違いであるほど、下流工程への影響大・修復コスト大


### アジャイル開発
「短い期間で開発」を繰り返す

（特徴）
- ドキュメントの作成　＜　ソフトウェアの作成
- 利用者の要件　→ 素早く取り入れられる
- 仕様変更　→ 柔軟に対応できる

（欠点）
- スケジュール管理　→ しにくい
- 開発の方法性　→ ぶれやすい

### XP（eXtreme Programming）=エクストリームプログラミング
アジャイルの一つ　、5つのことを実践
|実践|内容|
|:--|:--|
|**イテレーション**|イテレーション(短い期間（１〜２週）)でプログラム作成　→ 繰り返す|
|**ペアプログラミング**|２人１組でプログラミングをする|
|**リファクタリング**|完成後→外部仕様は変えず、内部のコードを随時改善|
|**継続的インテグレーション**|コードの結合→テスト＝継続的に繰り返す|
|**テストファースト**|テスト内容を決める　→ パスするプログラム作る|

### スクラム開発
アジャイルの一つ、チームが一体となる開発
（特徴）
- **スプリント**：　短い期間（１〜４週）でプログラム作成　→ 繰り返す
- 優先順位の高い機能から作成
- **デイリースクラム**：　毎日ミーティング
- **レトロスペクティブ**：　振り返り

（ウォーターフォールとアジャイル開発のイメージ）
![ウォーターフォール_アジャイル.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/9a56aba1-6eb4-af6e-e121-78e371b40da8.jpeg)

### プロトタイピングモデル
システム開発の初期：試作品（**プロトタイプ**）作成　→ 利用者と確認しながら開発を進める
例）　コスメの試供品
（イメージ）
![プロトタイプモデル.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/9b406003-de18-c616-be92-7f2d97810b94.jpeg)

### スパイラルモデル
システム　→ 複数のサブシステムに分割　→ サブシステムごとに開発
（イメージ）
![スパイラルモデル.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/a405ae8f-e6a0-66a5-883b-e57b5609d8d2.jpeg)

### リバースエンジニアリング（Reverse：逆）
既存プログラム：解析して、プログラム仕様・設計書を取り出す　（通常：仕様書　→ プログラム作成）
→ それを元に、新規開発を行う

## DevOps
開発部門（Development）・運用部門（Operations）が連携してシステム改善する考え

## CMMI（Capability Maturity Model Integration）　＝統合能力成熟度モデル
システム開発組織→プロセス成熟度を評価するモデル













# 業務モデリング
**業務プロセス**：　業務の一連の流れ
→ソフトウェア要件定義：　業務を可視化する（業務モデリング）
→業務のモデリング方法：２種類

（業務改革）
＊　**BPR**(Bisiness Process Re-engineering)：　業務プロセスを再設計　→ 企業を改革
＊　**BPM**(Bisiness Process Management)：　BPRを継続的に改善する



## DFD(Data Flow Diagram)
データの流れをモデル化したもの
(記号)
|記号|名前|意味|
|:--:|:--:|:--|
|→|データフロー|データの流れ|
|◯|プロセス|データの処理|
|＝|データストア|ファイル|
|□|データの源泉・吸収|データの始まり、終わり|

![DFD.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/239fafe3-cbf9-7cd1-61d4-7b9209a8d582.jpeg)
1. 取引先から注文書がくる
1. 注文を受注台帳に登録
1. 在庫台帳で在庫準備
1. 在庫がある場合、在庫台帳を更新
1. 在庫がない場合、購買販売部門に購入を依頼




## UML
オブジェクト指向開発で使うモデリング
設計〜テストまで統一した表記法


### ユースケース図
- 外部に提供する機能
- 利用者・システムとの関係
表す
![ユースケース図.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/4864b280-23f9-dc50-9223-c20d2ce697d0.jpeg)
＊　**アクター**：　システムに働きかける利用者・外部システム
＊　**ユースケース**：外部に提供する機能


### オブジェクト図
インスタンス（オブジェクト）同士の関係を表た図
![オブジェクト図.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/d3d8d796-b607-d12f-214b-6c3a7d613045.jpeg)


### クラス図
クラス同士の関係を表す
![クラス図.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/f775be81-8e7c-7ddd-93fe-3aa75b6a3088.jpeg)


### アクティビティ図
処理の流れを表した図（フローチャートと同じ）
![アクティビティ図.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/283da6cf-c819-d9e4-f93c-7dad7ba84621.jpeg)


### シーケンス図
オブジェクト間のやりとりを時系列で表した図
例）分散型システム：2相コミットメント
![シーケンス図.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/d1c7bfeb-97c2-55bb-70fc-b99b9e92fe45.jpeg)
＊　**コミュニケーション図**：　オブジェクト間のやりとりを関係性で表す（シーケンス図：時系列）













# ヒューマンインタフェース
インタフェース：あるモノとあるモノの間に立って、やり取りを仲介するもの
**ヒューマンインタフェース**：　利用者（ユーザー）とシステム（コンピュータ）の間に立って、互いのやり取りを仲介するもの
→ ソフトウェア要件定義（外部設計）：　利用者にヒアリング　→ ヒューマンインタフェース設計（画面・帳票のレイアウトなど）

## 画面・帳票設計
事前に、レイアウト・デザイン・タイトルの位置・文字の大きさ・文字の色など共通化

### 画面設計の留意点（Webサイトの場合）
**パンくずリスト**：　トップページから現在ページの経路情報　→ 表示する
目的：各Webページの相対位置を把握するため![パンくずリスト.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/cece9641-f7ef-36e5-7034-d6277c22e706.jpeg)

### GUI（Graphical User Interface）
画面のアイコン・ボタンをマウスでクリックする　→　視覚的に操作するインタフェース

（主なGUI部品）
|GUI|操作|
|:--:|:--|
|**ラジオボタン**|互いに排他的な項目→１つ選択、１つ選択→選んでた選択は解除|
|**チェックボックス**|各項目を選択させる、クリックする→選択・非選択が切り替わる|
|**スピンボタン**|連続する値を増減させる、増減ボタンをクリック→値が増減|
|**プルダウンメニュー**|上から垂れ下げて表示|
|**ポップアップメニュー**|画面から浮き出るように表示|

![GUI_部品.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/331826bf-5482-5bc4-82d1-1a0b8a62e039.jpeg)

### シグニファイア
物体に対して、何ができるかを示すもの
例）　青い色・下線が付いてる→リンク

## 入力チェック
データが入力　→ 正しいかどうか検査
（チェック方法）
|方法|内容|
|:--:|:--|
|**ニューメリックチェク**|数値チェック|
|**シーケンスチェック**|データが決まった順番に並んでるかチェック|
|**重複チェック**|重複データがないかチェック|
|**フォーマットチェック**|データ形式が正しいかチェック|
|**論理チェック**|論理的に矛盾しないかチェック|
|**リミットチェック**|値が一定の範囲内かチェック|
|**照合チェック**|データがファイルにあるかチェック|


### チェックディジット検査
1. 入力データ　→　**チェックディジット**（検査文字）求める
1. チェックディジット　→ 入力データの末尾に付加
1. 入力の誤りを検査
![チェックディジット.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/463610b3-b514-6ad8-6fb6-bd0ff8af7efe.jpeg)

## ユニバーサルデザイン
国籍・年齢・性別・身体的条件と関係なく、誰でも使える設計
- **アクセシビリティ**：　誰もが支障なく使えること
- **ユーザビリティ**：　利用者がストレスを感じずに使えること　（**インタビュー法**：利用者と会話して調査）
- **UX**(User eXperience)：　使いやすい＋快適な体験ができること















# モジュール分割
システム開発　→ プログラムを「モジュール」に分割して開発する

## 構造化設計
大きな機能　→ 少しずつ詳細化していく設計
|設計|内容|
|:--:|:--|
|システム設計|システム→サブシステム（機能）に分割|
|ソフトウェア要素の設計|サブシステム→**コンポーネント**（機能の一部品）に分割|
|モジュール設計|コンポーネント→**モジュール**（プログラムを構成する最小単位）に分割|

![構造化設計_モジュール分割.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/76d96296-5da2-eb39-f9f7-e3185655f1c5.jpeg)
※ システム：最終的にたくさんのモジュールで構成


## モジュール分割
モジュールに分けていく　→ モジュールの独立性が高くなるように設計
モジュールの独立性：あるモジュールを変更しても、他のモジュールへの影響が低いこと
　→「モジュール強度」「モジュール結合度」で評価


### モジュール強度
モジュール内の機能同士で、どれだけ関連してるか
→モジュール強度：強い　＝　独立性：高い


### モジュール結合度
他のモジュールとどれだけ結合しているか（どんなデータをやり取りして、他のモジュールと結合するか）
→モジュール結合度：弱い　＝　独立性：高い
|名称|モジュール同士でやり取りするデータ|結合度|独立性|
|:--:|:--|:--:|:--:|
|**データ結合**|単一データ：引数で渡す|弱|高|
|**スタンプ結合**|データ構造（複数のデータをまとめたもの）：引数で渡す|↑|↑|
|**制御結合**|制御パラメータ(他モジュールを制御する)：引数で渡す|｜|｜|
|**外部結合**|外部宣言したデータ：複数モジュールが参照|｜|｜|
|**共通結合**|外部宣言したデータ構造：複数モジュールが参照|↓|↓|
|**内容結合**|他のモジュール内にあるデータ：参照する|強|低|


### レビュー
各工程が終わった後の検討会
|代表的なレビュー|内容|
|:--:|:--|
|**ラウンドビン**|順番に進行役を回す検討会|
|**ウォークスルー**|作成者：説明、周りの人：質問・コメント|
|**インスペクション**|進行役(**モデレータ**)→参加者の役割を決める|















# オブジェクト指向
## オブジェクト指向設計
オブジェクト単位でシステムを設計する
オブジェクト同士でメッセージをやり取りして処理する

### オブジェクト
データ（属性）・メソッド（手続き）を一つにしたもの

### カプセル化
オブジェクト内のデータ・メソッド　→ 外部から隠蔽すること
（誕生日オブジェクト）
![カプセル化.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/84c49dad-029e-7a2d-2296-7d006d474b35.jpeg)

## クラスとインスタンス
### クラス
オブジェクトを定義したもの（設計図のようなもの）

### インスタンス
クラスを基にして生成されたオブジェクト

## 継承とポリモフィズム
既存のクラスを基にして、新しいクラスを生成する
- **スーパークラス（基底クラス）**：　基となるクラス
- **サブクラス（派生クラス）**：　新しく生成したクラス

### 継承
スーパークラスのデータ・メソッド　→　サブクラスが受け継ぐこと（サブクラス：スーパークラスとの差分を定義）

### ポリモフィズム
同じメッセージを送る　→ 各インスタンスで特有の処理をする
→ **オーバーライド**で実現（オーバーライド：スーパークラスのメソッド→サブクラスで再定義する）

＊　**委譲**：　依頼された処理　→ オブジェクト内部　→ 他のオブジェクトに委ねる

## クラスの階層化
クラスの基本的な考え　「オブジェクトは抽象化して定義」
→ クラスを階層化していく（上位クラス　↔︎ 下位クラス　＝　関係性）

### 汎化（抽象化）ー特化　（is a 関係）
- **汎化**：　下位クラスの共通部分を抽出　→ 上位クラスを定義
- **特化**：　抽象的な上位クラス　→　具体的な下位クラスとして定義
→ 継承関係がある
![汎化_特化_isa_.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/71de456b-8a78-4146-511a-647d12b7228d.jpeg)

### 集約ー分解　（part of 関係）
- **集約**：　上位クラスは下位クラスを組み合わせて定義
- **分解**：　下位クラスは上位クラスの一部として定義
→　継承関係はない
![集約_分解_partof.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/3534486d-2808-5803-c54c-11b5d5018aad.jpeg)

 
# テスト手法
## プログラムテスト
**バグ**：プログラムの誤り　→　見つけて排除（テストの目的）
テストの実施　→　バグ減る　→　高品質プログラム
＜**信頼度成長曲線**（**ゴンペルツ曲線**）＞
![信頼度成長曲線.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/bfc54010-ba82-5a5c-4529-2dbc4a700cf8.jpeg)
テストを進めると上記の信頼度成長曲線になる

＜バグ管理図＞
![バグ管理図.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/7b0171bb-8685-9f4d-6429-8f118fbd3372.jpeg)
バグ検出数・未消化テスト項目数・未解決バグ数＝横ばい
→ **解決困難なバグに直面してるか確認する必要あり**

## テスト工程
＜テストの種類・流れ＞
![テスト種類_流れ.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/426a0a2f-2174-b634-76f8-da21f4547d58.jpeg)
**テストケース**：　テスト項目＋期待する動き　まとめたもの
→　テストケースを元に、各工程でテストする

## ソフトウェアユニットテスト　（単体テスト）
モジュール単位でするテスト　→ 代表的な手法２つ

### ホワイトボックステスト
モジュールの内部構造（アルゴリズムなど）に着目するテスト　→ 開発者自身が行う
（テストケース手法）
|手法|内容|
|:--|:--|
|**命令網羅**|全ての命令　→ 最低一回は確認|
|**分岐網羅**|全ての分岐　→ 最低一回は確認|
|**条件網羅**|真偽の組み合わせ　→ 最低一回は確認|
|**複数条件網羅**|真偽の組み合わせ　→ 全て確認|

＊　色んな条件を網羅　→ 品質は上がるが、テストの時間がかかる

### ブラックボックステスト
モジュールの外部仕様に着目するテスト（意図した機能になってるか検証） → 第三者が実施
（テストケース手法）
|名称|概要|
|:--|:--|
|限界値分析|有効値と無効値の境界の値をテストケースにする|
|同値分割|グループに分ける→それぞれの代表的な値をテストケースにする|

＜限界値分析の例＞
![ブラックボックステスト_限界値分析.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/7fe3a292-74f0-4c6f-7bcc-fa20c29351f8.jpeg)
＜同値分析の例＞
![ブラックボックス_代表値分析.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/8d6308bd-843d-2e34-5d96-bfd9369f8be1.jpeg)

## ソフトウェア統合テスト（結合テスト）
ソフトウェアユニットテストが完了したモジュール同士を結合して行うテスト
→　**モジュール間のインタフェースを確認**

（代表的な手法）
### トップダウンテスト
上位モジュール　→　下位モジュール　の順で結合　　→ インタフェース確認
（下位モジュール＝未完成）
仮のモジュール（**スタブ**）が必要
![トップダウンテスト.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/862a458b-4491-b15d-1c11-a505905e1d73.jpeg)

### ボトムアップテスト
下位モジュール　→　上位モジュール　の順で結合　→　インタフェース確認
（上位モジュール＝未完成）
仮のモジュール（**ドライバ**）が必要
![ボトムアップテスト.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746950/fd4eb328-66a9-5b88-ff52-8f9f13491a2e.jpeg)

## システム統合テスト
システム設計で定義したテストをする
→ （開発者）ソフトウェア・ハードウェア・関連するシステムを結合　→ 動くかテスト
## ソフトウェア検証テスト
ソフトウェア要件定義で定義したテストをする
→（開発者）要件を満たしてるか検証
## システム検証テスト（システムテスト）
システム要件定義で定義したテストをする
→（開発者）業務で使うデータ　→ 要件を満たしてるか検証

＊　システム統合テスト・ソフトウェア検証テスト・システム検証テストの具体的なテスト方法
|テスト方法|内容|
|:--|:--|
|**機能テスト**|必要な機能が含まれてるかテスト|
|**性能テスト**|処理能力は十分かテスト|
|**操作性テスト**|ヒューマンインタフェースが使いやすいかテスト|
|**例外処理テスト**|エラーがちゃんと出るかテスト|
|**負荷テスト（ストレステスト）**|大きな負荷（大量のデータ）　→　正常に動くかテスト|

## 運用テスト・受入れテスト
システム運用直前　→ 利用者（業務担当者）が行うテスト
→ **受入れテスト**（システムを納品するかテスト）を兼ねる時も
→ **妥当性確認テスト**：　システムが目的を果たせるかテスト
→ ここまで終了して、運用開始・保守プロセスへ

## ソフトウェア保守
稼働中のソフトウェア　→ 障害回復・新しい要件に対する機能拡張
・　**リグレッションテスト**（**退行テスト**）：修正・変更　→ 他の箇所に影響が出ないかテスト

## ソフトウェアの品質特性
以下の特性が備わってる　→ 利用者にっとて使いやすいソフトウェア
|特性|内容|
|:--:|:--|
|**機能性**|正しく動作する|
|**使用性**|使用しやすいい|
|**信頼性**|必要時に使用できる|
|**効率性**|求められる性能が備わってる|
|**保守性**|プログラムの修正がしやすい|
|**移植性**|他の環境へ移しやすい|