トップ
プロセス中心設計
リスクマネジメントの体系
- リスクマネジメント
- リスクアセスメント
- リスク分析
- リスク評価(損失の財務的影響度の評価)
- リスク対応(リスク処理の優先順位の決定)
- リスク回避：発生頻度 大、被害額 大
- リスク最適化(リスク低減)：発生頻度 大 被害額 小
- リスク移転：発生頻度 小、被害額 大
- リスク保有：発生頻度 小、被害額 小
- リスク受容(リスクの処理方法の費用対効果の分析)
- リスクコミュニケーション
ソフトウェア導入
- ソフトウェア導入計画の作成
- ユーザテストが完了し検収が終わった後、本番運用に移行する
- 本番運用への移行をスムーズに実施するために、事前に移行方法を検討し、データ移行や要員訓練などを含む移行計画を作成する必要がある
- ソフトウェア導入の実施
- 新しい業務ソフトウェアの開発が完了し、実環境へ導入することになった時に、当該ソフトウェアの導入時に必要な作業として適切なもの
- ディスク容量など、必要なハードウェア資源の確保
- 受託したシステムの新規開発において、ソフトウェアを本番環境に移行するための計画を顧客に説明する
リスクチェックリスト
- プロジェクトのリスクに関連する項目を一覧にしたもの
- 類似したプロジェクトなどの過去の情報や経験、その他の情報源から得た知識をもとに作成されるリスクの分類と項目に関する一覧表
- プロジェクトで発生する可能性の高い一般的なリスクについて整理されているので、プロジェクトのリスクマネジメントにおいて、リスクを特定するためのテンプレートとして利用する
ステガノグラフィ
- 隠したい署名データを画像データの中に埋め込むことによって、署名の存在自体を外から判別できなくする
- 画像などのデータの中に、秘密にしたい情報を他者に気付かれることなく埋め込む
フェールソフト(fail soft)
- システムの一部に障害が発生したとき、その部分を切り離すことによってシステムの運転を継続するという設計の考え方
- システムの一部に障害が発生したとき、その部分を切り離すなどの措置を取ることによって、処理能力を低下させてもシステムの運転を継続するという考え方
- システムの一部が故障したときに、故障を起こした装置や部分を切り離して、処理能力を落としても、システムの全面停止を回避する信頼性設計技法
- フォールトトレランスの考え方の1つ
- フェールソフトによりシステムの処理能力を運転することを縮退運転(フォールバック運転)という
- ハードウェアの障害時に、パフォーマンスは低下するが、構成を縮小して運転を続けられるようにする
- 故障が発生したときに、あらかじめ指定されている縮小した範囲のサービスを提供すること
- システムの一部に不具合が生じたとき、その部分を停止させて機能を縮小してシステムを稼働し続ける仕組み
- 故障が発生した場合、一部のサービスレベルを低下させても、システムを縮退して運転を継続する設計のこと
- 装置の一部が故障しても、システムの全面的なサービス停止にならないようにする
- 情報システムの設計のうち、フェールソフトの考え方を適用した例
- ハードウェアの故障時に、パフォーマンスは低下するが、構成を縮小して運転を続けられるようにする
- 故障して100%の機能を維持できないとき、ある機能を切り捨てることで全停止に至らないようにする工夫
- できるだけ中核機能を残すようにする
- システムの一部に障害が発生した際、障害箇所を切り離し、残りの部分を使ってシステムの縮退運転を続けること
- 障害が発生したとき、機能が一部低下しても可動を続けること
- 障害が発生したとき、システムの一部機能を縮退させて稼働を続けること
- 装置やシステムの一部が故障した場合に、性能が低下しても処理を継続しシステム全体のサービス停止にならないようにすること
- 故障が発生したときに、あらかじめ指定されている縮小した範囲のサービスを提供すること
- 制御プログラムの障害時に、システムの暴走を避け、安全に運転を停止できるようにする
- フェールソフトの考えに基づいて設計されたシステムが、故障発生時にとる動作
- システムの一部に障害が発生したとき、システムを全面停止とせず、それ以外の部分の機能でシステム必要最小限の機能を維持するための運転を継続する
- ハードウェアの障害時に、パフォーマンスは低下するが、構成を縮小して運転を続けられるようにする
- クラスタ構成のシステムにおいて、あるサーバが動作しなくなった場合でも、他のサーバでアプリケーションを引き継いで機能を提供する
アクティビティ
- WBSで展開したワークパッケージをもとに定義する
- ワークパッケージを、プロジェクトの見積やスケジュールの作成・監視などの対象となる詳細化された作業単位に分解したもの
- スケジュールを作成する単位
ITIL(ITIL 2011 edition)
- SMART
- ITIL 2011 editionにおいて、良い目標値を設定するための条件
- S:Specific(具体的)
- M;Measurable(測定可能)
- A:Achievable(達成可能)
- R:Relevant(適切)
- T:Time-bound(適時)
- 7ステップの改善プロセス
- 改善の戦略を識別
- 改善活動前に、戦略的・戦略的・運用上の目標を確認する
- 測定するものを定義
- 改善の戦略を識別で確認した目標の達成状況を評価するための測定基準を定義する
- 効果的にサービスを測定するために、経済的、定量的で、求められる結果を出すために役立つ、重要で意味のある少数の指標に着目して測定項目を定義する
- データ収集
- データ処理
- データ分析
- データと情報を分析し、組織の意思決定を支援するナレッジに変える
- 情報を提示し利用
- 得られたナレッジを利用して、改善活動の計画立案を行う
- 改善の実施
- サービスを改善するために得られたナレッジを利用する
- サービス資産管理および構成管理プロセス(SACM;Service Asset and Configuration Management)
- サービスを提供するために必要な資産が適切にコントロールされるようにすること、そして、それら資産に関する正確で信頼性のある情報が必要なときに必要なところで利用できるようにすることを責務とするプロセス
- 構成コントロールが適切に行われないことによって発生する事象
- ライセンス契約数を超えて行われる、ソフトウェアの利用
- サービス資産管理が適切に行われないことによって発生する事象
- 許可なく実施された、リリースの稼働環境への展開
- 構築環境に存在する修正中のプログラムをパッケージ化したリリースの、稼働環境への展開
- 不具合のあるリリースの、稼働環境への展開
- サービスサポート
- インシデント管理
- インシデントが発生した場合に暫定的な手段でシステムを復旧させるプロセス
- 問題管理
- インシデントの根本原因を調査し恒久的な対策を行うプロセス
- サービスライフサイクル
- サービスストラテジ
- ITサービス及びITサービスマネジメントに対する全体的な戦略を確立する
- サービスデザイン
- 事業要件を取り入れ、事業が求める品質、信頼性及び柔軟性に応えるサービスと、それを支えるプラクティス及び管理ツールを作り出す
- サービストランジション
- サービス及びサービス変更を運用に利用できるようにするために、前の段階の成果を受け取り、事業のニーズを満たすかどうかをテストし、本番に展開する
- サービスオペレーション
- 顧客とサービス提供者にとっての価値を確保できるように、ITサービスを効果的かつ効率的に提供しサポートする
- 継続的サービス改善
- ITサービスマネジメントプロセスとITサービスに対する改善の管理を責務とし、効率性、有効性及び費用対効果を向上させるために、サービス提供者のパフォーマンスを継続的に測定して、プロセス、ITサービス、インフラストラクチャに改善を加える
- サービス・パッケージ
- コアサービス、実現サービス及び強化サービスの組合せで構成された、特定種類の顧客ニーズへのソリューションを提供する複数のサービスの集まりである
- サービス・ポートフォリオ
- サービス・パイプライン、サービス・カタログ及び廃止済みサービスで構成された、サービス・プロバイダによって管理されている全てのサービスである
- サービス・パイプラインに収録されるサービス
- サービス・カタログ
- 成果物、価格、連絡先などが内容として含まれた、稼働中の全てのITサービスに関する情報を格納するデータベース又は構造化された文書である
- 開発が完了し、顧客に提供することが可能なサービス
- サービス・ポートフォリオで管理するサービスのうち、稼働中のすべてのサービスを記載したもの
- サービス・ポートフォリオの廃止されるサービス
- 今後、段階的に停止されたり、取り消されたりするサービス
- リリース管理
- ハードウェア、ソフトウェア、ライセンス、文書などで構成された、稼働中のITサービスに対して承認された変更を実施するためのコンポーネントの集合である
- 7ステップの改善プロセス
- ステップ1:改善の戦略を識別する
- ステップ2:測定するものを定義する
- ステップ3:データを収集する
- ステップ4:データを処理する
- ステップ5:情報とデータを分析する
- ステップ6:情報を提示して利用する
- ステップ7:改善を実施する
- ITILのサービスライフサイクルの構成要素
- サービスオペレーション段階で実行されているサービス
- サプライヤのカテゴリ化
- サプライヤ管理を行う上で、サービスを展開/維持していくうえで、必須のサプライヤはどこなのかを識別する必要があり、サプライヤは以下のようなカテゴリに分ける
- 戦略的なサプライヤ
- ビジネス的にも重要で、代替が難しいサービスを提供しているサプライヤ
- 戦術的なサプライヤ
- ビジネス的に重要か、または代替が難しいかなどのサービスを提供しているサプライヤ
- 運用上必要なサプライヤ
- 戦術的ではないけど、コモディティでもないサプライヤ
- コモディティ化されているサプライヤ
- サプライヤの利用に関連する"リスクとインパクト"、及び事業に対するサプライヤとそのサービスの"価値と重要性"に着目する方法がある
- "リスクとインパクト"と"価値と重要性"を評価して、サプライヤをカテゴリ①～④に分けた図
①比較的容易に代替ソーシングされ得る、価値が低く容易に入手できる製品とサービスを提供するサプライヤに対するカテゴリ
②運用上の製品、又はサービスのサプライヤに対して、下級運用マネジメントによって管理するカテゴリ
③顕著な商業活動及び事業のやり取りがあり、中級マネジメントが関与するカテゴリ
④長期的な計画を促進するために、戦略の機密情報を共有する上級マネジメントが関与するカテゴリ
- インシデント管理において、インシデント・モデルを定義しておくことによって得られるメリット
- 繰り返し発生するインシデントに対して、事前に定義された経路で、事前に定義された時間枠内に対応できる
- ITILのサービス・ポートフォリオの構成要素
- サービス・パイプライン
- サービスカタログ
- 廃止されるサービス
- 今後、段階的に停止されたり、取り消されたりするサービス
- ITILの管理プロセス
- 可用性管理
- ITサービスが必要とされたときに合意済みの機能を提供するためのプロセス
- "ITサービスが必要とされるときに、合意した条件の下で要求された機能を果たせる状態にある能力"について、定義し、分析し、計画し、測定し、改善する活動を行う
- リアクティブな可用性管理の活動で用いる技法
- ITサービスの可用性と信頼性の管理に関わるKPIとして用いるもの
- 可用性管理における重要業績評価指標(KPI)の例
- 保守性を表わす指標値(平均サービス回復時間)の短縮
- ITサービス継続性管理
- ITインフラとサービス設備が、合意した期限内に回復できるするプロセス
- インシデント管理
- サービスサポートでインシデントが発生した場合に暫定的な手段でシステムを復旧させるプロセス
- インシデント管理において、インシデント・モデルを定義しておくことによって得られるメリット
- 繰り返し発生するインシデントに対して、事前に定義された経路で、事前に定義された時間枠内に対応できる
- 問題管理
- サービスサポートでインシデントの根本原因を調査し恒久的な対策を行うプロセス
- イベント管理
- インシデントに対する一連の活動のうち、イベント管理プロセスが分担する活動
- インシデントの発生を検出して、関連するプロセスに通知する
- インシデントに対する、問題解決管理プロセスが分担する内容
- インシデントの発生後に、その原因などをエラーレコードとして記録する
- インシデントの発生後に、問題の根本原因を分析して記録する
- インシデントに対する、イベント管理プロセスが分担する内容
- インシデントの発生を早期に検出して、関連するプロセスに通知する
- ITILのサービスライフサイクルの構成要素
- サービスストラテジ/戦略(service strategy)
- 戦略的資産として、どのようにサービスマネジメントを設計、開発、導入するかについての手引きを提供する
- サービスデザイン/設計(service design)
- サービストランジション
- 顧客及び利害関係者の満足度を改善するために、サービス要件に規定された要件と制約に沿って、サービスを利用できるようにする
- サービスオペレーション
- 継続的サービスの改善(continual service improvement)
- PDCAサイクルに基づく改善活動を通して、サービスの効率、有効性、費用対効果の観点で運用状況を継続的に測定し、改善していく
- 全てのITサービスやITサービスに関わる活動を継続的に改善するプロセス
- ITILにおいて、良い目標値を設定するための条件として"SMART"がある
- S Specific(具体的)
- M Measurable(測定可能)
- R Relevant(適切)
- T Time-bound(適時)
- A Achievablr(達成可能)
- サービスデスク組織の特徴
- バーチャル・サービスデスク
- サービスデスク・スタッフは複数の地域に分散しているが、通信技術を利用することによって、利用者からは単一のサービスデスクのように見える
- サービスサポート
- サービスデスク
- インシデント管理
- 問題管理
- 構成管理
- 変更管理
- リリース管理
- サービスデリバリ
- サービスレベル管理
- ITサービス財務管理
- キャパシティ管理
- ITサービス維持性管理
- 可用性管理
- サービスストラテジ
- 顧客のニーズにあわせたITサービスの戦略を立案する
- サービスデザイン
- サービストランジション
- 変更管理、リリース管理、構成管理をすばやく実行する
- サービスオペレーション
- インシデント管理、問題管理、サービス管理を実行する
- 継続的サービス管理
- 自分自身を含めて個々のサービスをフォローし、継続的に改善する
- ITサービスマネジメントのフレームワーク
- ITサービスを運用管理するための方法を体系的にまとめたベストプラクティス集
- システム運用管理、ITサービス管理に関するベストプラクティスのガイドブック
- ITILの用語
- 障害の発生から本格的な対応までの一連の活動と対応するITILの管理プロセス
- 利用者からサービスデスクに”特定の入力操作が拒否される”という連絡があったので、別の入力操作による回避方法を利用者に伝えた
- 原因を開発チームで追求した結果、アプリケーションプログラムに不具合があることが分かった
- 障害の原因となったアプリケーションプログラムの不具合を改修する必要があるのかどうか、改修した場合に不具合ヶ所以外に影響が出る心配はないかどうかについて、関係者を集めて確認し、改修することを決定した
- 改修したアプリケーションプログラムの稼働環境への適用については、利用者への周知、適用手順及び失敗の切戻し手順の確認など、十分に事前準備を行った
無線LANの規格
- 無線LANの規格
- IEEE 802.11b
- 最大伝送速度：11Mbps
- 周波数帯：2.4GHz
- 変調方式：PS-SS
- 特徴：障害物に強い。無線の場合は実効スループットは大幅に落ちるので、マルチメディア通信などには向いていない
- IEEE 802.11a
- 最大伝送速度：54Mbps
- 周波数帯：5GHz
- 変調方式：OFDM
- 特徴：早くから普及した規格
- IEEE 802.11g
- 最大伝送速度：54Mbps
- 周波数帯：2,4GHz
- 変調方式：DS-SS/OFDM
- 特徴：11bと上位互換。11bと混在させられるが、11bのノードに対する待ち時間が大きくなり、11g対応ノードの通信速度は落ちる
- IEEE 802.11n
- 最大伝送速度：600Mbps
- 周波数帯：2.4GHz/5GHz
- 変調方式：OFDM
- 特徴：11a,11b,11gと上位互換。2つの周波数帯を使用するのが特徴。従来規格と互換性があり、11a,11b,11g対応のノードも11nのネットワークに接続することが可能。チャネルボンディング、MIMO対応
- IEEE 802.11ac
- 最大伝送速度：7Gbps
- 周波数帯：5GHz
- 変調方式：OFDM
- 特徴：11a,11nと上位互換。チャネルボンディング、MIMO対応
- チャネルボンディング
- MIMO
- データの送受信に複数のアンテナを使い、並行通信を行うことで通信速度を上げる技術
- 無線LANはではチャネルを使い分けることで同時通信ができる
- 使用するチャネルが同一であったり、間隔が小さいと電波干渉を起こす
- スペクトルアナライザを使うと、電波の使用状況が分かる
ホップ数(Hop count)
- 通過できるルータの数
- データを送信するときにホップ数が指定され、ルータを超えるたびに1つずつ減算され、0になると消滅する
- 最大ホップ数を決めておけば、設定を間違ってデータがネットワークの同じところを往復しっぱなしになってしまっても、しばらくすれば自然消滅するようになる
ルータ広告(RA;Router Advertise;ルータアドバタイズ)
- ネットワーク情報をクライアントに伝える仕組み
- 近隣要請メッセージの一部
- 定期的に送信されることで、プレフィックスが変わった場合には、その変更をクライアントへと伝えて反映させることができる
調達計画・実施
- 入札案内(IFB; Invitation for Bids)
- 発注したソフトウェアが納品されたときに確認する項目
- 調達手順の例
- 調達手順の例
- 情報システムの調達
RFI：発注元はシステム化の目的や業務内容などを示し、調達先に情報提供を依頼する
↓
RFP：発注元は調達対象システム、調達条件などを示し、提案書の提出を依頼する
↓
供給者の選定：発注元は提案書、能力などに基づいて、調達先を決定する
↓
契約の締結：発注元と調達先や責任分担などを、文書で相互に確認する
- 調達プロセス
- 提案評価方法の決定→提案依頼書(RFP)の発行→提案評価→調達先の選定→調達の実施
- 購入・取得計画
- 契約計画
- 納入者回答依頼
- 納入者選定
- 検収
- ベンダからの納品物が要求した仕様通りであるかの確認を行う
- システム開発プロジェクトにおいて、システム要件定義から
- ソフトウェアの導入・受入れ支援までを開発ベンダが受注した。システム開発に関する文書のうち、開発ベンダが作成する文書
- システムテスト結果報告書
- ソフトウェア導入計画書
電子透かし
- 画像や音楽などのディジタルコンテンツが、不正にコピーされて転売されたものであるかを判別するしくみ
- 元のデータからの変化が一見して分からないように作成日や著作権情報などを埋め込む
- 画像や音楽などのディジタルコンテンツの著作権者などの情報を埋め込む
プロバイダ
- サービスを提供する事業者のこと
- 狭義の意味においてはインターネットネットに接続する通信回線を提供する事業者、またはそのサービス形態
ホスト(host)
- 通信の「送信元」もしくは「宛先」となる機器のこと
- パソコンやスマートフォン、携帯電話のほか、各種サーバもホストである
マイクロカーネルOS
- カーネルのサイズを可能な限り小さくしたOS
- 特定のアプリケーションに特化している
- OSを構成する要素・機能をカーネル空間から切り離し、外部モジュール化するなどで実装する
リアルタイムOS
- リアルタイムOSの特徴
- リアルタイムOSはリアルタイムシステムを構築する目的で利用される
- 主な特徴
- 限定されたメモリサイズ
- ディスクレス起動のサポート
- リアルタイム性(実時間性)
- 高信頼性
- OSを構築する要素のカスタマイズが可能
- リアルタイムOSの構成
- カーネルとドライバから構成される
- カーネル
- 複数タスクの実行管理を行うことでシステム全体としてのアプリケーションの並列処理を実現する
- ドライバ
- 各種入出力の制御やファイルシステム、ネットワークプロトコルなどを含み、ハードウェアへのアクセス機能を提供する
- 利用目的に応じてドライバを組み合わせてリアルタイムOSを構築できることが必要
- システムコール
- アプリケーションがカーネル、ドライバのサービスを利用するために用いるAPI関数群
- 主な種類
- エンジン制御、ハードディスク制御などの制御系ハードリアルタイムシステムや組込みシステムでリアルタイムOSを活用する理由
- 期待される応答時間内にタスクや割込みを処理するための仕組みが提供されるため
- 定められた時間内にイベントに対応した処理を完了させる機構が必要だから
- 制御系の組込みシステムで使用されるリアルタイムOS
- リアルタイムOSにおけるコンテキストの使用方法
- 割込み処理を、割込み処理ごとのコンテキスト(プログラムの内部状態、状況、条件)で実行させる
- 多重割込みを処理するリアルタイムOSの割込みハンドラ処理
- 割込み禁止状態での処理を極力減らして、割込み可能状態で動作する
DoS攻撃(サービス停止攻撃,Denial of Services attack )
- 正規のサービス要求を過大に繰り返すことで、サーバを機能不全に陥れる攻撃
- 特定のサーバに大量のリクエストを送信することで、CPUやメモリを使用不能にすることでサービスを妨害する攻撃
- パケットの断片化と再構築による攻撃
- パケットの到着順序が順不同になり、データを組み立てることでシステムの負荷が高まる
- 対処
- ポートを閉じる(ただし、サービスも止まる)
- IDS/IPSを導入する
- 一定時間経過したら、ポートやメモリを開放する
- 攻撃者のIPアドレスが特定できる場合、通信を拒否する
- アクセス制御の設定や特定サイトからの要求を遮断する
- 正規のサービス要求とDoS攻撃を切り分けることは困難
- 例：新商品の発表によるWebサイトへのアクセス増大
- 種類
- TCP SYN Flood
- TCPのSYN要求を大量に行う
- クラッカーはACKを返さないので、標的サーバはいつまでもポートやメモリなどの資源を使ってACKを待ち続ける
- TCP接続要求であるSYNパケットを大量に送信する
- コネクション開始要求に当たるSYNパケットを大量に送ることによって、攻撃対象のサーバに、接続要求ごとに応答を返すための過大な負荷を掛ける
- SYNパケットはTCPのセッション接続要求に利用されるので、このシーケンスを大量かつ中途半端に実行することで、3ウェイハンドシェイク処理が完了せず接続待ちとなる状態が大量に発生してシステムリソースを消費させる
- TCP接続要求であるSYNパケットを大量に送信する
- 3ウェイハンドシェイク(SYN)を大量に送り付ける
- 対策
- Windowsであればnetstatを実行し、「SYN_RECEIVED」で止まっているものが多く、さらに増えているようであればSYNフラッド攻撃を受けている可能性がある
- パケットフィルタリングによるファイアウォールの設定が有効
- Connection Flood
- 大量のコネクションを確立して、標的サーバの資源を飽和させる
- 大量のTCPコネクションを確立することによって、攻撃対象のサーバに接続を維持させ続けリソースを枯渇させる
- 大量のコネクションを確立させる
- コネクションが成立するので、攻撃しているノードのIPアドレスが分かってしまう
- 踏み台などで使われる
- UDPフラッド攻撃 / UDP Flood攻撃
- UDPポートにパケットを送り続けることでサービスを飽和させる
- サイズの大きいUDPパケットを大量に送信する
- セッションという概念がないので、攻撃される側だけでなく、攻撃側のPCにも負荷がかかるので、自分のマシンからではなく第三者のPCから実行されることが多い
- サイズが大きいUDPパケットを大量に送信する
- UDPポートに大量のデータを送り付ける
- ICMPフラッド攻撃 / ICMP Flood攻撃 / Ping Flood攻撃
- 大量のpingを送り付ける
- pingで送信するパケットのサイズを変更するなどの手口も併用される
- pingに応答しないよう設定を行う対策がある
- pingコマンドを用いて大量の要求パケットを発信することによって、攻撃対象のサーバに至るまでの回線を過負荷にしてアクセスを妨害する
- ICMPリクエストパケットを高速で送信し、目標となったマシンは大量の接続処理を行おうとしてリソースを使い果たし、正当な接続も落としてしまう攻撃
- pingコマンドを用いて同時に発信した大量の要求パケットによって、攻撃対象のサーバに至るまでの回線を過負荷にしてアクセスを妨害する
- Pingを大量に送り付ける
- Smurfアタック / smurf攻撃
- サービス不能攻撃(DNS)の一つ
- ICMPの応答パケットを大量に送りつける
- ICMPの応答パケットを大量に発生させる
- ソースアドレスを偽装したICMPエコーパケットをブロードキャストに送り、ルータを増幅器として悪用して、ターゲットホストにICMPエコー応答を受信させトラフィックを増加させる攻撃
- mail bomb攻撃
- サイズの大きい電子メールや大量の電子メールを送信する
- HTTP GET Flood攻撃
- HTTP GETコマンドを繰返し送ることによって、攻撃対象のサーバのコンテンツ送信に負荷を掛ける
- FINフラッド攻撃
- 負荷が重いTCP通信の終了処理を大量に行わせる攻撃
- 分散型サービス不能攻撃(DDoS；Distributed Denial of Service)
- 分散DoSともいう
- DoS攻撃を大量のマシンから行う
- 攻撃マシンを特定しにくい
- インターネットに分散している多くのコンピュータから一斉に特定のサーバへパケットを送出し、トラフィック過剰やサーバ機能を停止させる攻撃
- インターネット上の多数のコンピュータから、公開しているサーバに一斉にパケットが送り込まれたので、当該サーバが一時使用不能になった
- 攻撃元が複数でそれが膨大な数になることがある
- NATやNAPTの内側にあるLAN内のホストから攻撃が行われる事もある
- 正常なアクセスと明確に区別することが難しく、本当の攻撃元を割り出すことが難しい
- インターネット上にある多数の踏み台サイトにあらかじめ仕掛けておいた攻撃プログラム(ボットなど)から、一斉にDoS攻撃を仕掛けることで、ターゲットサイトのネットワークの帯域をあふれさせる
- DNSの再帰問合せを利用したDDoS(Distributed Denial of Service、分散サービス不能)攻撃
- 攻撃対象のサービスを妨害するために、攻撃者がDNSサーバを踏み台に利用して再帰的な問合せを大量に行う
- マルチベクトル型DDoS攻撃
- 攻撃対象のWebサーバ1台に対して、多数のPCから一斉にリクエストを送ってサーバのリソースを枯渇させる攻撃と、大量のDNS通信によってネットワークの帯域を消費させる攻撃を同時に行う
- マルチベクトル型攻撃とは、従来の単一方法による攻撃ではなく、複数の攻撃手法を組み合わせて攻撃を行うことで、攻撃対象のシステム(サーバ)に対してネットワーク層、トランスポート層、アプリケーション層に同時に攻撃を行うことでシステム管理者の攻撃への対応を難しくし、攻撃を有効にする
- Webサイトに対して、SYN Flood攻撃とHTTP POST Flood攻撃を同時に行う
- 対策
- 十分な帯域をもつネットワークを使用する
- 公開サーバ及び経路上のネットワーク機器の処理能力を増強する
- 発信元が偽装されているパケットやブロードキャストアドレスあてパケットをファイアウォールで遮断する
- 不要なICMPパケット、UDPパケットを遮断したり帯域制限を行う
- CDN(コンテンツデリバリネットワーク)プロバイダなどが提供するDDoS攻撃対策サービスを利用する
- 反射・増幅型DDoS攻撃/分散反射型DoS攻撃(DRDoS)
- 通信手順の応答に着目することで攻撃効率を増大させている
- 踏み台サーバに、標的コンピュータに偽装したSYNパケットを投げる
- TCP、UDP、ICMPなど、TCP/IPプロトコルの基本的な通信手順やアプリケーションの仕様において生成される様々な応答パケットを大量に発生させてDDoS攻撃を行う手法
- UDPの性質を悪用したDDoS攻撃(DNSリフレクター攻撃)
- 踏み台サーバに標的コンピュータに偽装したSYNパケットを投げる
- DNSリフレクター攻撃、smurf攻撃、NTPリフレクター攻撃も反射・増幅型DDoS攻撃の一種
- 対策
- 攻撃の対象となる可能性のあるサーバを外部に公開する必要がない場合は、アクセス制限などによりインターネットからのアクセスを遮断する
- 悪用されやすいコマンド等を無効にする
- 十分な回線帯域を確保し、ネットワーク機器、サーバの負荷分散を行う
- NTPを使った増幅型のDDoS攻撃に対して、NTPサーバが踏み台にされることを防止する対策
- NTPサーバの設定変更によって、NTPサーバの状態確認機能(monlist)を無効にする
- EDoS攻撃(Economic Denial of Service,Economic Denial of Sustainability)
- 従量課金制のクラウドサービスにおけるEDoS攻撃
- クラウドサービス利用者の経済的な損失を目的に、リソースを大量消費させる攻撃
インバスケット
- 問題解決能力の育成方法の一つ
- 日常起こりやすい問題を多数提示して、これを一定時間内に判断して処理させる
- 短い制限時間の中で数多くの案件を処理することで、分析力や判断力を養成する方法
- インバスケットという名称は、未決裁書類を入れる箱(棚)からつけられている
- 制限時間の中で数多くの案件を処理する
CMMI(プロセス成熟度モデル;Capability Maturity Model Integration)
- W.ハンフリーが提唱会社や組織、プロジェクトなどのソフトウェア開発能力や習熟度を客観的に示す品質評価基準
- プロセス習熟度モデル(CMM;Capability Maturity Model)としてソフトウェア開発の分野で開発されたものをシステム工学分野でも適用できるCMMIに発展させた
- ソフトウェア開発組織は、その開発プロセスの成熟段階において、5つの段階を経て発展していくという考えに基づき、プロジェクトやソフトウェア開発工程を評価・改善するのに用いられる
- ソフトウェアプロセスの標準化と最適化を推進し、製品やサービスの開発、調達及び保守活動において、組織のもつプロセスを改善するためのガイドラインを提供する
- 製品やサービスについて、組織が開発と保守のプロセスを改善するのを助ける
- ソフトウェア開発組織及びプロジェクトのプロセスの成熟度を評価するためのモデル
- ソフトウェア開発やプロセスの成熟度評価モデルであるCMMに、多くのCMM改善事例を反映させたモデル
- ソフトウェアを評価対象として、開発と保守のプロセス改善を支援する目的で作成された開発モデル
- CMMIは、CMMで評価対象としていたソフトウェアに加え、ハードウェアを含む製品やサービスを評価対象にしている
- 組織がプロセスを改善することに役立つベストプラクティスの適用に対する手引きを提供している
- CMMIの評価には、CMMと同様に「初期」「管理された」「定義された」「定量的に管理された」「最適化している」と、全体を5段階で評価する段階表現のほかに、22のPA(Process Area)についてそれぞれPAごとの能力レベルを評価する連続表現の方法がある
- 成熟度レベル
- レベル1(初期プロセス;initial process)
- プロジェクトの予測がつかず、失敗が多いレベル
- プロセスが確立されていない状態
- レベル2(反復できるプロセス;repeatable process)
- プロジェクトマネジメントができるレベル
- 特定のプロジェクトリーダーや技術者に依存している状態
- 作業成果物の状況が、主要なタスクの完了時点で管理層に対して見える状態になっている
- レベル3(定義されたプロセス;defined process)
- レベル2のプロジェクトをマネジメントを組織運営できるレベル
- システム開発の経験が組織として共有され、首尾一貫したプロセスを標準として持っている状態
- プロセスが明文化されて、組織内のすべての人がそれを利用している
- レベル4(管理されたプロセス;managed process)
- 組織的なプロセスを定量的に管理できるレベル
- プロセスの実績が定量的に予測可能であり、標準化されたプロセスを定量的に測定し、洗練化していくことが可能な状態
- 実績が定量的に把握されており、プロセスが組織的に管理されている
- レベル5(最適化しているプロセス;optimizing process)
- 定量的な計測法を用いて、プロセス改善ができるレベル
- 技術、要件環境の違いによって標準プロセスを最適化して用いることが可能であり、プロセスそれ自体を改善していくための仕組みが規定されている状態
- プロセスを継続的に改善していくための仕組みが機能している
- ソフトウェア開発組織及びプロジェクトのプロセスの成熟度を評価するためのモデル
- ITベンダが、情報システムを開発する際のプロジェクト管理能力、エンジニアリング能力を高めていくために、現状のプロセス状況を5段階に分けて評価し、不十分な部分を改善することを目指すもの
- ソフトウェア開発組織及びプロジェクトのプロセスの成熟度を評価するためのモデル
- 組織がプロセスを改善することに役立つ、ベストプラクティスの適用に対する手引を提供する
- 利用目的
- ソフトウェア開発の生産性のレベルを客観的に知り、開発組織の能力を向上させるために、より高い生産性レベルを目指して取り組む
- 開発のためのCMMI 1.3版のプロセス領域
- 要件開発
- 運用の考え方及び関連するシナリオを確立し保守するプラクティスを含むもの
- 技術解
- 要件に対する解を選定し、設計し、そして実装することである。解、設計、および実装は、単体の、または適宜組み合わせた成果物、成果物構成要素、および成果物関連のライフサイクルプロセスを網羅すること
- 検証
- 選択された作業成果物が、指定された要件を満たすようにすること
- 成果物統合
- 成果物構成要素から成果物を組み立て、統合されたものとして成果物が適切に動くようにし、そしてその成果物を納入すること
OJT(On Job Training)
- 実際のプロジェクトを通じて能力を高めていく方法
- プロジェクト通して当該個人やチームに習得させようとする項目やレベルをあらかじめ計画しておき、本人に認識させ、計画に従って育成を図ることが重要
- 効果的なOJTのためには、業務を遂行するうえでの組織内での標準やルール、体系立った方法論や技法の存在が重要であり、これらを習得させることが要員育成のポイントになる
- 日常の開発業務の中で、先輩や上司が個別に指導し、実体験から知識を習得させる技法
- 上司や先輩が実務に密着して実践的に知識や技術を教育するので、必要な能力が習得できる
- 例
- 参画しているプロジェクトにおいて、モデル化のスキルを習得するため、一部の業務プロセスのモデル化を担当した
- 必要とされる技術力を持っていない要員が複数いて、プロジェクトの遂行に支障を来すおそれがあるときの教育方針
- 個々の技術力に応じて、受講させる集合研修やOJTの内容を変えて教育する
SQL
- 例
- 次のSQL文の実行結果の説明
CREATE VIEW 東京取引先 AS
SELECT * FROM 取引先
WHERE 取引先.所在地 = '東京'
GRANT SELECT
ON 東京取引先 TO "8823"
利用者"8823"は、実表"取引先"の所在地が"東京"の行を参照できるようになる
- A表の主キーがB表の外部キーによって参照されている場合、各表の行を追加・削除する操作の参照制約に関する制限について、正しく整理した図.△印は操作が拒否される場合があることを表し、○印は制限なしに操作ができることを表す
ソフトウェア要件定義
- システム方式設計で確定したソフトウェアアーキテクチャの機能要件と非機能要件を整理し確定させる
- 手法の例
- ソフトウェア要件の確立
- 機能
- 例：集計するデータ項目としてどのようなものが必要であるか
- 能力
- インタフェース
- ヒアリングなどにより要件を収集する
- ソフトウェア要件の評価
- アウトプット
- システム機能定義書
- システムを構成する個々の機能について、目的、入力、出力、処理内容を記述した物
- プロトタイプ
- ユースケース
- DFD
- E-R図
- UML
- 機能階層図
- システム全体または一部の機能を階層的に表現したもの
- 図の最上位に対象となる機能を置き、それをルート(根)にしたツリー図の形態でシステムの構造を記述する
ソフトウェア方式設計
- 手順
- ソフトウェアがどのようなコンポーネントで構成されるかという骨組みを決定する
- ソフトウェア要件定義で洗い出された要件を各コンポーネントに割り当て、それをどのような仕組みで実現するかを明確にする
- 作業例
- コンポーネントの機能仕様決定
- コンポーネント間のインタフェース設計
- 入出力設計(ユーザインタフェースなど)
- データ設計
- その他
- マニュアルなどの利用者文書の作成
- ソフトウェア結合のためのテスト
- 要求事項の定義
- ソフトウェア方式設計・基本設計(外部設計)
- 既に決定しているソフトウェア要件を、どのように実現させるかを決める
- システム構想書を受けて利用者の立場に立ち、システムをどのように実装するかを決定する作業
- システム要件定義の結果を受けてシステム化を進めるに当たって行う作業
- データ項目を洗い出して論理データ構造を決定する
- 論理データ設計：データ項目の洗い出しとデータ構造の決定
- ソフトウェア構造とコンポーネントの方式設計において、機能要求を実現するための各オブジェクトの作業分担を記述するのに適した図
- 外部設計
- 主にユーザから見える範囲のシステム設計を行う
- 画面・帳票の設計やシステム機能設計、論理データ設計、外部システムとのインタフェース設計などを実施する
- 画面・帳票レイアウトの設計
- 出力帳票の設計方針
- 帳票に統一性をもたせるために、タイトルの位置、データ項目の配置などに関する設計上のルールを決めておく
- アプリケーションが表示するエラーメッセージを設計するときの留意事項
- 利用者が何をすべきかを、簡潔かつ正確に表示する
- ヒューマンインタフェース設計
- コード設計
- システムで使用するコードを洗い出し、その目的・用途を定義した上でコード体系を設定すること
- システムで使用するデータの識別や分類・配列を容易にするためのコードの設計
- システムの外部設計を完了させるとき、承認を受けるもの
システム要件定義
- ユーザがシステムに求める要件を分析し、実現すべきシステムの要件を定義すること
- 機能要件
- 非機能要件
- 利用者が直接業務で使わない仕組みに関する内容
- 機能要件を条件面で支える
- システムを利用者に提供する上でのサービスレベルやセキュリティに関する要件
- システム要件定義
- システム開発の最初の工程で行う作業で現状の業務を分析し、システム要件を整理する
- システムの機能及び能力を決める工程
- 最も上流の工程であり、後続の工程をスムーズに進めるためには、この工程で十分な検討を行う必要がある
- 開発するシステムが何をするものなのかを決定する
- 開発する予定のソフトウェアに対する顧客の要求を、ある仕様記述に基づいてまとめ、決定する
- 対象業務の調査・分析を行い、業務要件の定義、データ分析、システム要求分析などを実施する
- 機能
- 能力
- 業務・組織及び利用者の要件
- 設計条件
- 適格性要件
- システム要件定義で実施する作業
- 応答時間の目標値の決定
- 例）現在5分程度掛かっている顧客検索を、時期システムでは1分以下で完了するようにしたい
- システム要件の評価
システム方式設計
- ハードウェアとソフトウェアのアーキテクチャを設計する作業
- どのようなハードウェアやソフトウェアを用いるかを最上位レベルで確定する
- システムをハードウェア、ソフトウェア、運用時のオペレーティングなどの品目に分け、それぞれの目指す姿を明確にする
- 各品目ごとに、どのような構成品目で成り立つかを整理し、文書化する
- システム要件定義で明確になった各要件項目は、すべてどの要件がどの構成品目に関係するかを紐づける
- システムの最上位レベルでの方式を確立する
- ハードウェア
- ソフトウェア
- 手作業の機能分割
- ハードウェア方式設計
- ソフトウェア方式設計
- アプリケーション方式設計
- データベース方式設計
- システム方式設計において実施する作業
- システムのハードウェア構成、ソフトウェア構成を明確にする
- システム方式の評価
フットプリンティング
- ネットワーク上のコンピュータに侵入する準備として、攻撃対象の弱点を探るために個人や組織などの情報を収集すること
- 攻撃者は、収集した情報をもとに、目標となるコンピューターの弱点を見つけたり、侵入の経路方法を絞り込み、攻撃に利用するツールなどを決定する
アサーションチェッカ
- 変数の間で論理的に成立すべき条件を、プログラムの適切な箇所に挿入し、実行時にその条件を満たしているかどうかを検査するツール
- 変数の間で理論的に成立すべき条件が満たされているか否かを検査するコードをプログラムの適切な箇所に挿入し、実行時に検査結果が確認できる支援ツール
リスクへの対応
- リスク対応プロセスで、 予算及びスケジュールに資源と活動とを投入することによってリスクを扱う
- リスク対応にはリスクの回避、軽減、転嫁又はリスクが発現したときに使用するコンティンジェンシ計画の作成が含まれる
- JIS Q 21500での記述
- 目標
- プロジェクトの目標への機会を高めて脅威を軽減するために、選択肢を作成して対策を決定すること
リーンソフトウェア開発
- 日本の自動車製造におけるムダを省いたリーン生産方式をソフトウェア開発に適用したもので、アジャイル型開発手法の一つ
- 現場に適応した具体的な実践手順を作り出す助けとなる7つの原則がある
- 7つの原則
- ムダをなくす
- 品質を作り込む
- 知識を作り出す
- 決定を遅らせる
- 早く提供する
- 人を尊重する
- 全体を最適化する
ライセンス管理
- 法人でPC100台分のソフトウェアXのライセンスを購入し、ライセンス分のインストールを実施した場合の対応
- 使用許諾契約に反していない
- PC10台を他部署へ移動させたが、ディスク内のソフトウェアXは消去せず、移動先でそのまま使用した
- 使用許諾契約に反している
- 新規にPC10台を購入し、ソフトウェアXをインストールしたが、ライセンスの追加購入はしなかった
- ソフトウェアXが販売停止となったので、ライセンスの使用状況の管理を中止し、自由にインストールできるようにした
- ソフトウェアXをインストールしたPCの台数ではなく、同時に利用している台数が、購入したライセンス数を超えないようにした
- デュアルライセンスのソフトウェアを利用する条件
- 複数のライセンスが設定されているので、利用者はそのうちの一つのライセンスを選択して同意する
リンクステート
- ルーティング技術
- トロポジマップ(ネットワークの構成図)を作って、それを参照して経路を決定する方法
- 構成図には、中継機器の性能、回線速度などを加味することができる
- ディスタンスベクタ方式より高速な経路を選択できる可能性が高くなる
- 構成図を作るのに時間がかかる
- 機器やネットワークの負荷が大きい
- OSPFで使用されている
フォワードエンジニアリング
- リバースエンジニアリングによって既存のシステムから解析された仕様をもとに、新規のシステムを開発すること
- 既存のプログラムから導き出された仕様を修正してプログラムを開発すること
- 既存のプログラムやファイルを解析して仕様書を作成し、これを参考にして同等の機能をもったプログラムやファイルを作成する開発手法
ストレートケーブル
- PC(MDIポートを持つ機器)と周辺機器・通信機器(MDI-Xポートを持つ機器)をつなぐためのケーブル
RADモデル(Rapid Application Development)
- 高品質のシステム開発を、早く、安く行う事を目的とするシステム開発方法論
- 少数精鋭のチームを組み、各種開発ツールを活用し、プロトタイプモデルによってシステム開発を進める
- 要求分析や設計作業に対するエンドユーザの参画を重視する
- 早期にアプリケーションを開発するための手法
- プロトタイプを多用することで設計期間を短縮する
- ライフサイクルの無制限な繰り返しを防ぐため、タイムボックスと呼ばれる一定の開発期間を設定する
- CASEツールを多用し、ユーザの積極的な参画を得ながら、短期間(90～180日)でシステムを完成させる手法
HIPO(Hierarchy plus Input Process Output)
- システムの全体構造を階層的に記述するのに適しており、構造化分析・設計に用いられる
- データとデータの変化に着目する
SQLインジェクション
- データベースを利用するWebサイトに入力パラメタとしてSQL文の断片を与えることによって、データベースを改ざんする攻撃
- Webアプリケーションに問題があるとき、悪意のある問い合わせや操作を行う命令文をWebサイトに入力して、データベースのデータを不正に取得したり改ざんしたりする攻撃
- 攻撃者が、Webアプリケーションの入力データとしてデータベースへの命令文を構成するデータを入力し、管理者の意図していないSQL文を実行させる
- ユーザの入力データをもとにSQL文を編集してDBにアクセスする仕組みになっているWebアプリケーションに対して不正なSQL文を入力することで、機密情報を不正に取得したり、DBを不正に操作したりする攻撃手法
- SQL文のリテラル部分の生成処理に問題があるアプリケーションに対して、攻撃者が、任意のSQL文を渡して実行させる
- 不正なSQLを含む悪意の入力データを与え、データベースに対する不正な問合せを実行させる攻撃
- 対策
- Webアプリケーションの実装における対策：プレースホルダを利用する、SQL分の組立てに静的プレースホルダを使用する
- Webアプリケーションの実装以外の対策：データベースのアカウントがもつデータベースアクセス権限を必要最小限にする
- ユーザの入力データ中にスクリプトやSQL文として特別な意味を持つメタキャラクタが存在した場合、それらをエスケープ処理することで対処する
- SQLインジェクションを防ぐために、Webアプリケーション内でデータベースへの問合せを作成する際にプレースホルダを使用する
- SQLインジェクション対策について、Webアプリケーションプログラムの実装における対策と、Webアプリケーションプログラムの実装以外の対策
- Webアプリケーションプログラムの実装における対策：プレースホルダを利用する
- Webアプリケーションプログラムの実装以外の対策：Webアプリケーションプログラムが利用するデータベースのアカウントが持つデータベースアクセス権限を必要最小限にする
- SQLインジェクション攻撃による被害を防ぐ方法
- 入力された文字が、データベースへの問合わせや操作において、特別な意味をもつ文字として解釈されないようにする
- あらかじめ用意されたSQL文を利用するバインド機構を利用する
- サニタイジングを行う
アーンドバリューマネジメント(EVM)
- アーンドバリューマネジメントを使うと、スコープ、スケジュール、コストを組み合わせて客観的に管理できる
- スケジュールとコストの両面を同時に管理する方法
- 各アクティビティの予定コストをそのアクティビティの価値とみなす
- あるアクティビティが完了したら、そのアクティビティの価値を予定したコストの値で示す
- EVMは、PV、AC、EVの3つの指標を比較することで、スケジュールとコストを総合的に分析してプロジェクトの進捗を表す
- ACがPVより低いときは予定よりもコストは使っていないが、EVがACよりさらに低いと、使用したコストに見合っただけの成果物が完了できていないと判断できる
- EVMを使うとその時点の進捗状況が客観的に把握できるだけでなく、現在のプロジェクトの状況をもとに客観的にプロジェクトの終了時の予測を行うことも可能になる
- プロジェクトの全作業を金銭価値に置き換えて、チェックポイントごとの達成予定額を設定し、達成作業量を金銭価値に換算したものと比較することによって、プロジェクトの進捗管理を行う方法
- 達成額と実コストとの比較によってコスト面での進捗も数量的に把握することができ、全体としてスケジュールとコストを統一的に把握することが可能
- 作業状況とコストの進捗状況及びその結果を用いて今後の予測ができる
- PV(プランドバリュー)
- 評価時点までのアクティビティの計画コストの累積値を予定コスト、又は予定出来高として計画の基準ラインとする
- プロジェクト終了時のPVはプロジェクトの総予算を表す
- 所定の期間内で、この作業に割り振られた承認済みの見積り金額
- AC(実コスト)
- ある時点までに実際にかかったコストの累積値のこと
- 作業済みの全てのアクティビティの実コストを集めて求める
- 所定の期間内で、この作業を完成させるために要した実際の費用(金銭価値)
- EV(アーンドバリュー)
- 作業済みのアクティビティの計画コスト(=アクティビティの価値)を累積したもの
- 出来高ともいう
- 報告時点でのその作業の成果物(出来高)を金銭換算したもの
- アーンドバリューの測定基準には、固定法などのような基準が使われる
- コスト差異(CV):
- スケジュール差異(SV):
- コスト効率指標(CPI):
- スケジュール効率指標(SPI):
- 完成時総コスト見積り(EAC)
- 計測時点までの実コストに基づいたプロジェクトの完了日における総コストの見積り予測
- 完成時総予算(BAC)
- 残作業のコスト見積り(ETC)
赤外線
- リモコンなどで利用される波長の長い電磁波
- IEEE802.11bで規定されるまでは無線LANの代表として使用されていた
ミリ波
- 60GHz帯、120GHz帯という周波数帯で使用されている
- 伝送速度1Gbps以上
- 60GHz帯は免許不要
サブミリ波
- 高速無線LANで利用されている19/25GHz帯という周波数帯
- 伝送速度10Mbps以上
- 19GHz帯は免許が必要であるが25GHz帯は不要
- FWAサービスなどで使用される
ISMバンド(Industry Science Medical Band)
- 900MHz帯、2.4GHz帯、5.7GHz帯と呼ばれる周波数帯で、利用可能な伝送速度は数Mbps
- IEEE802.11a、IEEE802.11b、IEEE802.11g、Bluetoothなど
- 2.4GHz帯は電子レンジや医療用機器にも利用される
- 水に吸収されやすい
- 隣接したAP(Access Point ： 基地局、アクセスポイント)が同じチャネル、または隣接したチャネルを使用すると、チャネルの相互干渉により両方の無線ネットワークで通信に影響が出る
小電力無線
- 最大出力10mW
- 伝送速度32kbps以下
- コードレス電話やワイヤレスマイクに利用されている
- PHS-FWA(Fixed Wireless Access)などで使用される
- 利用に免許は不要
アローダイヤグラム法(ADM;Arrow Diagramming Method)
- アクティビティを矢印で、矢印間の結節点をノード(通常、円形)で表す
- 個々の作業を矢印線(アロー)で表し、作業(アロー)と作業(アロー)を〇印のノードで結ぶ
- アローダイヤグラム法で定義できる作業間の順序関係は、完了-開始関係(FS)のみ
- 同期が必要な作業は、点線の矢印線のダミー作業を利用して表す
- ダミー作業は順序関係だけを示すもので、時間やコストは0として扱う
近隣広告メッセージ(Neighbor Advertisement)
- 近隣要請メッセージに対する応答
- 近隣要請メッセージに対する応答であるが、近隣要請メッセージが到達しなくても、ホストが自ら情報を送信したいときには、いつでも送信される可能性がある
- 近隣広告メッセージには、自身のMACアドレスなどの物理アドレスが含まれる
データ中心設計
- データを共有資源と見なし、その一貫性や完全性維持を重視して資源側からソフトウェアを規定する、という考え方に基づく
- 対象とする業務をデータの関連に基づいてモデル化し、分析する
- 対象業務領域のモデル化に当って、情報資源のデータ構造に着目する
- データ資源の重複だけでなく、それに起因するプロセスの重複も排除することを目的としている
- 「プログラムの処理ロジックが頻繁に変更されたとしてもデータは比較的安定的である」という考え方を基本とする
- データ中心設計法におけるカプセル化の特徴
- データとその操作の実装がカプセル内に閉じ込められるので、カプセルの利用者と提供者を明確に切り分けることができる
- トランザクション正規化
- トランザクションを標準データと標準プロセスごとに分割すること
- データ中心アプローチによる開発手順
- データモデリング(要求分析/データ分析)
- 業務で利用するデータの構造を分析し、抽出したエンティティとエンティティ間の関係をE-R図などで整理する
- データ中心アプローチによる開発では、データ分析を先に行い、モデル化することを優先する
- データ標準化/データベース設計
- モデル化したデータの意味や特性を明確にし、標準データとして定義する
- 標準プロセスの設計
- 標準データに対応する処理プログラムとして標準プロセスを設計する
- 標準プロセスは、標準データの発生/変更/消滅という基本的な処理機能と、データ整合性維持のための機能を含む
- カプセル化/トランザクション正規化
- 標準データと標準プロセスをひとまとめにするカプセル化を行う
- 応用プログラム設計
リンカ
- 相互参照の解決などを行い、複数の目的モジュールなどから一つのロードモジュールを生成する
テスト
- プログラムがシステム設計通りに動作すること、業務要件を満たしていることを確認するために、テスト計画を作成し、テストを実施する
- 問題が発見された場合は、そのレベルに応じて上流の工程に戻りプログラムや内部設計、外部設計を修正する
- 外部設計および内部設計の誤りは、プログラムだけでなく、マニュアルなどにも影響を与えるので、コーディングの誤りに比べて修復コストは高い
- プログラムのテストでは、正常なケースで正しく動作するかどうかだけではなく、意図しなかった動きがあるかどうか、あるいは誤った入力があった場合にも意図した動作(エラー処理など)をするかどうかを調べる必要がある
- テストにおけるユーザ部門の役割
- システム開発における成果物に対して、業務的観点から内容確認を行う
- プログラムの詳細設計は開発部門に任せる
- システムテストの段階で参加する
- 用意された運用マニュアルが適切であることを確認する(運用テスト時)
- プログラムの変更管理の実施
- 変更実施結果の評価基準として、変更作業工数の予測値、障害発生率の目標値を決める
- 障害発生率：ここでは変更したことによる新たな障害の発生率を示す
- 例
- 本社に設置したサーバのデータを、本社及び各事業所内のLANと、本社各事業所とを接続する通信回線とから構成されている自社ネットワークを介して、全国の事業所に提供するアプリケーションを開発する場合、システムテストを本社内のLAN環境で行うとき、応答時間の検証は困難
- テストの順序
- システム開発におけるテストでは、小さな単位から大きな単位へテストを積み上げていく方法が採られることが多い
- 単体テスト
- 結合テスト
- システムテスト(総合テスト)
- 運用テスト
- テストの準備
- テストケース作成
- 環境
- 既に稼働中のシステムに機能を追加するために、プログラムの一部を変更した場合に、本番稼動してよいかどうかを判断するために、稼働中のシステムに影響を与えることなくテストを行うために本番環境と同等のテスト環境を用意する
- システム適格性確認テストを実施するとき、用意しておくべきテストデータ
- 実際に業務で使うデータや、業務上例外として処理されるデータ
- 実験計画法を利用したテストデータ作成方法
- 効率良くテストするために、直行表を用いてテストデータを作成する
- カバレージモニタ
- プログラムの動的テストに用いられるテスト支援ツール
- 記号実行ツール
- 静的テストを行うツール
- 数値の代わりに記号を入力して実行をシミュレーションする
- 構文チェッカ
- コードオーディタ
- プログラムのソースコードが、コーディング規約にのっとっているかどうかをチェックする静的解析を行う
- テスト項目目標数
- プログラム図式生成ツール
- プログラムからフローチャートなどの図を生成する静的なテスト支援ツール
- テスト実施
- テスト完了後のプログラムを修正した場合、修正部分を確認するテストデータを確認済みのテストデータに追加して再テストを行うほうがよい
- テスト結果の評価
- ソフトウェアのテスト工程において、バグ管理図を用いて、テストの進捗状況とソフトウェアの品質を判断したいときの考え方
- テスト工程の消化の累積件数、バグ摘出の累積件数及び未解決バグの件数の推移がすべて横ばいになった場合は、解決困難なバグに直面しているかどうかを確認する必要がある
- テストの進捗管理に使用する指標
- 品質の判断
- テスト消化率のグラフ
- テスト項目件数が増えるにつれて累積バグ件数は収束する
横軸：テスト項目消化件数
縦軸：累積バグ件数
- テスト消化率のグラフの例
- まだ多くのバグが内在している可能性があることを示す
- バグ管理図
- バグ管理図において、すべての線が横ばい状態になった状況から、解決困難なバグに直面しており、その後のテストが進んでいないことが推測できる
- バグの発生状況を記載し、管理限界内に入っているかどうかを見るための図
- QC七つ道具の一つである管理図の記載方法に準拠して作成する
- テストカバレッジ
- あるテストデータがプログラムのどの経路を通ったのかを調べ、プログラム全体の経路のうち、何%をカバーしたかを求めること
- テストカバー率
- システム開発プロジェクトにおいて、成果物の品質を評価するために使用する指標
- バグ原因分析表
- 発見されたバグが作りこまれた原因(仕様ミス、設計不良、プログラム誤り、テスト不足など)を分析し、表にまとめたもの
- テストカバレージ分析
- ホワイトボックステストにおいて、コード中のどれだけの割合の部分を実行できたかを評価するのに使うもの
ペネトレーションテスト(penetration test;侵入テスト)
- コンピュータやネットワークのセキュリティ上の弱点を発見するテスト手法の一つ
- システムを実際に攻撃して侵入を試みる手法
- 実際にネットワークを介してWebサイトを攻撃し、不正に侵入できるかどうかを検査する
- DMZに設置されているWebサーバへ外部から実際に侵入を試みる
- サーバやネットワークを実際の攻撃に近い手法で検査することによって、もし実際に攻撃があった場合の被害の範囲を予測する
- 公開Webサーバや組織のネットワークの脆弱性を探索し、サーバに実際に侵入できるかどうかを確認する
- ファイヤウォールや公開サーバに対するセキュリティホールや設定ミスがないか確認する
- ファイアウォールや公開サーバに対して侵入できないかどうかを確認する
ソフトウェア受け入れ
- 受入れレビューと受入れテスト
- ソフトウェアの受入れ：受入れは、そのソフトウェアの取得者が行い、開発者は受入を支援する
- ソフトウェア製品の納入と受入れ
- 利用者マニュアル
- 教育訓練
- ソフトウェア受入れにおいて実施される事項
- 利用者マニュアルを整備し、利用者への教育訓練を実施する