システム開発技術

情報システム戦略とシステム企画

情報システム戦略

経営戦略 → 情報システム全体考えよう

全体最適化計画

全体的な目線　→　情報システムの最適な形を考える計画

情報システム管理基準

（経済産業省）情報システム管理のルールを定める

CIO(Chief Information Officer)

情報戦略を考え、経営戦略との矛盾を確かめる人（最高情報責任者）
・ITガバナンス：　情報システム戦略をコントロールすること

EA（Enterprise Architecture）

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

（４つの視点で分析）

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

共通フレーム

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

(共通フレームのプロセス)
企画プロセス　→ 要件定義プロセス　→ システム開発プロセス　→ ソフトウェア実装プロセス　→ 保守プロセス
　

企画プロセス

システム化構想・システム化計画を立案する

システム化構想

経営戦略にもとづいて、システム化の方針を考える

システム化計画

構想を具現化するための計画
例）システム化する業務、スケジュール、コスト、役割分担.... を明確にする

要件定義プロセス

利用者のニーズ　→ システムの仕様を決める　例）　どんな家建てる？どういう機能持たせる？

• 業務要件：　業務上実現すべき要件
• 機能要件：　実現のために必要な機能
• 非機能要件：　機能要件以外の部分（性能、信頼性、セキュリティ、移行方法、運用方法...）

ベンダ企業を決める

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

（ベンダ企業を選ぶ流れ）

1. [発注側]　情報提供依頼(RFI(Request For Information))：ベンダの技術、製品に関する情報提供を依頼
2. [ベンダ側]　情報提供
3. [発注元]　提案依頼書(RFP(Request For Propodsl))：　システム内容、予算を提示　→ 提案書の提出を依頼
4. [ベンダ側]　提案書　：RFPを元に、具体的な内容を提出
5. [ベンダ側]　見積書　：「提案書」OK → 開発・運用・保守の費用を提示

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

ソフトウェア開発

システム開発を担当するベンダーが決定　→ ベンダで開発が始まる

ソフトウェア開発工程

１. システム要件定義（外部設計）：　利用者にヒアリング　→　機能・性能を定義
成果物：システム要件定義書
決定内容：　システムの応答時間・処理時間など

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

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

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

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

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

開発手法

ソフトウェア開発の種類

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

上位工程　→　下位工程　へ順番に進めていく方法

（特徴）

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

（欠点）

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

アジャイル開発

「短い期間で開発」を繰り返す

（特徴）

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

（欠点）

• スケジュール管理　→ しにくい
• 開発の方法性　→ ぶれやすい

XP（eXtreme Programming）=エクストリームプログラミング

アジャイルの一つ　、5つのことを実践

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

スクラム開発

アジャイルの一つ、チームが一体となる開発
（特徴）

• スプリント：　短い期間（１〜４週）でプログラム作成　→ 繰り返す
• 優先順位の高い機能から作成
• デイリースクラム：　毎日ミーティング
• レトロスペクティブ：　振り返り

（ウォーターフォールとアジャイル開発のイメージ）

プロトタイピングモデル

システム開発の初期：試作品（プロトタイプ）作成　→ 利用者と確認しながら開発を進める
例）　コスメの試供品
（イメージ）

スパイラルモデル

システム　→ 複数のサブシステムに分割　→ サブシステムごとに開発
（イメージ）

リバースエンジニアリング（Reverse：逆）

既存プログラム：解析して、プログラム仕様・設計書を取り出す　（通常：仕様書　→ プログラム作成）
→ それを元に、新規開発を行う

DevOps

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

CMMI（Capability Maturity Model Integration）　＝統合能力成熟度モデル

システム開発組織→プロセス成熟度を評価するモデル

業務モデリング

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

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

DFD(Data Flow Diagram)

データの流れをモデル化したもの
(記号)

記号	名前	意味
→	データフロー	データの流れ
◯	プロセス	データの処理
＝	データストア	ファイル
□	データの源泉・吸収	データの始まり、終わり

1. 取引先から注文書がくる
2. 注文を受注台帳に登録
3. 在庫台帳で在庫準備
4. 在庫がある場合、在庫台帳を更新
5. 在庫がない場合、購買販売部門に購入を依頼

UML

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

ユースケース図

• 外部に提供する機能
• 利用者・システムとの関係
  表す
  
  ＊　アクター：　システムに働きかける利用者・外部システム
  ＊　ユースケース：外部に提供する機能

オブジェクト図

インスタンス（オブジェクト）同士の関係を表た図

クラス図

クラス同士の関係を表す

アクティビティ図

処理の流れを表した図（フローチャートと同じ）

シーケンス図

オブジェクト間のやりとりを時系列で表した図
例）分散型システム：2相コミットメント

＊　コミュニケーション図：　オブジェクト間のやりとりを関係性で表す（シーケンス図：時系列）

ヒューマンインタフェース

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

画面・帳票設計

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

画面設計の留意点（Webサイトの場合）

パンくずリスト：　トップページから現在ページの経路情報　→ 表示する
目的：各Webページの相対位置を把握するため

GUI（Graphical User Interface）

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

（主なGUI部品）

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

シグニファイア

物体に対して、何ができるかを示すもの
例）　青い色・下線が付いてる→リンク

入力チェック

データが入力　→ 正しいかどうか検査
（チェック方法）

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

チェックディジット検査

1. 入力データ　→　チェックディジット（検査文字）求める
2. チェックディジット　→ 入力データの末尾に付加
3. 入力の誤りを検査
   

ユニバーサルデザイン

国籍・年齢・性別・身体的条件と関係なく、誰でも使える設計

• アクセシビリティ：　誰もが支障なく使えること
• ユーザビリティ：　利用者がストレスを感じずに使えること　（インタビュー法：利用者と会話して調査）
• UX(User eXperience)：　使いやすい＋快適な体験ができること

モジュール分割

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

構造化設計

大きな機能　→ 少しずつ詳細化していく設計

設計	内容
システム設計	システム→サブシステム（機能）に分割
ソフトウェア要素の設計	サブシステム→コンポーネント（機能の一部品）に分割
モジュール設計	コンポーネント→モジュール（プログラムを構成する最小単位）に分割

※ システム：最終的にたくさんのモジュールで構成

モジュール分割

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

モジュール強度

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

モジュール結合度

他のモジュールとどれだけ結合しているか（どんなデータをやり取りして、他のモジュールと結合するか）
→モジュール結合度：弱い　＝　独立性：高い

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

レビュー

各工程が終わった後の検討会

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

オブジェクト指向

オブジェクト指向設計

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

オブジェクト

データ（属性）・メソッド（手続き）を一つにしたもの

カプセル化

オブジェクト内のデータ・メソッド　→ 外部から隠蔽すること
（誕生日オブジェクト）

クラスとインスタンス

クラス

オブジェクトを定義したもの（設計図のようなもの）

インスタンス

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

継承とポリモフィズム

既存のクラスを基にして、新しいクラスを生成する

• スーパークラス（基底クラス）：　基となるクラス
• サブクラス（派生クラス）：　新しく生成したクラス

継承

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

ポリモフィズム

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

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

クラスの階層化

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

汎化（抽象化）ー特化　（is a 関係）

• 汎化：　下位クラスの共通部分を抽出　→ 上位クラスを定義
• 特化：　抽象的な上位クラス　→　具体的な下位クラスとして定義
  → 継承関係がある
  

集約ー分解　（part of 関係）

• 集約：　上位クラスは下位クラスを組み合わせて定義
• 分解：　下位クラスは上位クラスの一部として定義
  →　継承関係はない
  

テスト手法

プログラムテスト

バグ：プログラムの誤り　→　見つけて排除（テストの目的）
テストの実施　→　バグ減る　→　高品質プログラム
＜信頼度成長曲線（ゴンペルツ曲線）＞

テストを進めると上記の信頼度成長曲線になる

＜バグ管理図＞

バグ検出数・未消化テスト項目数・未解決バグ数＝横ばい
→ 解決困難なバグに直面してるか確認する必要あり

テスト工程

＜テストの種類・流れ＞

テストケース：　テスト項目＋期待する動き　まとめたもの
→　テストケースを元に、各工程でテストする

ソフトウェアユニットテスト　（単体テスト）

モジュール単位でするテスト　→ 代表的な手法２つ

ホワイトボックステスト

モジュールの内部構造（アルゴリズムなど）に着目するテスト　→ 開発者自身が行う
（テストケース手法）

手法	内容
命令網羅	全ての命令　→ 最低一回は確認
分岐網羅	全ての分岐　→ 最低一回は確認
条件網羅	真偽の組み合わせ　→ 最低一回は確認
複数条件網羅	真偽の組み合わせ　→ 全て確認

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

ブラックボックステスト

モジュールの外部仕様に着目するテスト（意図した機能になってるか検証） → 第三者が実施
（テストケース手法）

名称	概要
限界値分析	有効値と無効値の境界の値をテストケースにする
同値分割	グループに分ける→それぞれの代表的な値をテストケースにする

＜限界値分析の例＞

＜同値分析の例＞

ソフトウェア統合テスト（結合テスト）

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

（代表的な手法）

トップダウンテスト

上位モジュール　→　下位モジュール　の順で結合　　→ インタフェース確認
（下位モジュール＝未完成）
仮のモジュール（スタブ）が必要

ボトムアップテスト

下位モジュール　→　上位モジュール　の順で結合　→　インタフェース確認
（上位モジュール＝未完成）
仮のモジュール（ドライバ）が必要

システム統合テスト

システム設計で定義したテストをする
→ （開発者）ソフトウェア・ハードウェア・関連するシステムを結合　→ 動くかテスト

ソフトウェア検証テスト

ソフトウェア要件定義で定義したテストをする
→（開発者）要件を満たしてるか検証

システム検証テスト（システムテスト）

システム要件定義で定義したテストをする
→（開発者）業務で使うデータ　→ 要件を満たしてるか検証

＊　システム統合テスト・ソフトウェア検証テスト・システム検証テストの具体的なテスト方法

テスト方法	内容
機能テスト	必要な機能が含まれてるかテスト
性能テスト	処理能力は十分かテスト
操作性テスト	ヒューマンインタフェースが使いやすいかテスト
例外処理テスト	エラーがちゃんと出るかテスト
負荷テスト（ストレステスト）	大きな負荷（大量のデータ）　→　正常に動くかテスト

運用テスト・受入れテスト

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

ソフトウェア保守

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

ソフトウェアの品質特性

以下の特性が備わってる　→ 利用者にっとて使いやすいソフトウェア

特性	内容
機能性	正しく動作する
使用性	使用しやすいい
信頼性	必要時に使用できる
効率性	求められる性能が備わってる
保守性	プログラムの修正がしやすい
移植性	他の環境へ移しやすい