Katsuoのサイト
応用情報の勉強ノートの3ページ目。
情報セキュリティ対策は、機密性、完全性、可用性を維持すること。
情報セキュリティは、機密性(Confidentiality),完全性(Integrity),可用性(Availability)の維持を目的に実施する。
機密性
情報にアクセスすることを許可された人だけがアクセスできるようにすること。
完全性
情報が正確で完全であること、およびその情報の処理の方法が正確で完全であること。
可用性
許可された人が必要なときに情報にアクセスできるようにすること。
情報セキュリティの維持と可用性と完全性の内容は関係あるようにぱっと見は思えないので忘れやすい。
完全性が弱いと、不正確な情報や不正確な処理が脆弱性につながって、セキュリティーの弱さにつながるのかもしれない。
可用性については、情報へのアクセス許可の管理がちゃんとしていないと、悪意をもった人にアクセスされてしまうなどの
問題が起こると考えられる。そのため、完全性と可用性が情報セキュリティーに関係ある。
情報セキュリティ対策は大きく分けて3種類に分類されていて、人的セキュリティ対策、技術的セキュリティ対策、物理的セキュリティ対策に分けられる。
人的セキュリティ対策
組織全員への遵守事項の教育や周知など、人的な対策をすること。
技術的セキュリティ対策
コンピュータの管理、アクセスの制御、不正プログラム対策、不正アクセス対策など、技術的な対策。
ファイアウォール、暗号化、アクセス制御、パスワード運用の他にもいっぱいあるが、覚え方としては、人的セキュリティ対策と物理的セキュリティ対策以外の
対策が技術的セキュリティ対策と認識すると、分かりやすい。
物理的セキュリティ対策 建物や設備、サーバーなどで利用するパソコンなどの管理で、物理的な対策を実施すること。窃盗、破壊、自然災害、温湿度の不安定さなどに対して保護する。 入退室管理、ケーブルの保護、耐震、防火、空調などの対策を実施することが物理的セキュリティ対策。
情報セキュリティポリシーとは、企業が情報を保護するにあたっての目的や意図、基本方針をだれでも分かるように分かりやすく文章にしたもの。
組織の全員が遵守すべきことを宣言する。
情報セキュリティポリシーが一番上位の概念で、その下に、情報セキュリティ基本方針がある。さらに、情報セキュリティ基本方針の下に、情報セキュリティ対策基準がある。
情報セキュリティー基本方針と情報セキュリティ対策基準を合わせて、情報セキュリティポリシーという。
上記のように、情報セキュリティポリシーは簡単な宣言でもあり、基本方針と対策基準を含んだ概念でもあるので混乱しそうだが、
情報セキュリティポリシーはこの2つの側面があると覚えておく。
情報セキュリティ基本方針
経営の最高責任者が情報保護に関する考え方を示すもので、組織が情報を保護するための方法論を簡単にわかりやすくまとめたもの。
情報セキュリティ対策基準
情報セキュリティ基本方針をうけ、セキュリティ対策の対象と対策方法を定めたガイドライン。遵守しないといけないセキュリティ規定項目が定義されたもの。
リスクアセスメントをしてリスクを評価して、リスク対応をする。リスク対応は、リスクコントロールと、リスクファナンシングがある。
リスクマネジメントの指針、標準として、JIS Q 3100がある。これは組織のリスクに焦点を当てた指針、標準。
Computer Security Incident Response Teamは、企業や行政機関に設置される組織。ネットワークに保安上の問題につながるインシデントが発生
したときに対応する組織。
インターネットを通じた不正アクセスに関しての情報を収集、公開する団体。セキュリティについての啓もうや教育もしている。 この組織は、攻撃の総称をインシデントと呼んでいて、インシデントを6つのタイプに分類している。
Scan
スキャンやプローブなどの不審なアクセス。ポートスキャンはサイバー攻撃の前準備として、侵入先を探し出すために使われる。
ポートスキャンとは、順番に各ポートにパケットを送って、攻撃先の応答を受けることによって、どんなサービスが稼働しているかを確認すること。
OSの種類も特定できる。ポートスキャンの種類としては、TCPスキャン、SYNスキャン、FINスキャン、NULLスキャンがある。
Abuse
サーバープログラムのメール送信機能を悪用してスパムメールを正規の普通の送信サーバーに処理させることで不正中継して送信する。
Forged
送信ヘッダを詐称した電子メールを送ること。
Intrusion
システムへの侵入
DoS
サービス妨害につながる攻撃(大量の不正アクセスでサーバーを停止に追い込むこと)
Other
そのほかの不正な攻撃など
日本のサイバーレスキュー隊。社会や産業に大きな影響を及ぼすおそれのある標的型サイバー攻撃の被害が予見される場合に、
標的にされた組織などに対して被害が他にも拡散しないように支援をする。
情報処理推進機構(Information-technology Promotion Agency, Japanの略)は、国が管理している団体。
日本のIT向上のために作られた。
Japan Vulnerability Notesの略で、日本で使用されているソフトウェアなどの脆弱性関連の情報と対策情報を提供しているポータルサイト。
脆弱性の情報と対策、製品開発者の対応状況を公開していて、IPAとJPCERT/CCが共同で運営している。
企業や組織内に設置する情報セキュリティのための組織として、情報セキュリティ委員会、SOCがある。
情報セキュリティ委員会
企業や組織における情報セキュリティマネジメントの最高意思決定機関。CIOやCISOが主催する。
CIO(Chief Information Officer:最高情報責任者)は情報システムの最高責任者。
CISO(Chief Information Security Officer:最高情報セキュリティ責任者)は、企業内で情報セキュリティを統括する担当役員の1つ。
SOC
Security Operation Centerは、顧客や自組織を対象として情報セキュリティ機器やサーバー、ネットワークなどを監視し、
これらの機器が生成するログ・ジャーナルを分析して、サイバー攻撃の検出や通知をする組織。
National center of Incident readiness and Strategy for Cybersecurityの略で、政府の情報セキュリティ関連の施策を推進する機関。
サイバーセキュリティ基本法に基づいて、内閣官房に設置されている。
サイバーセキュリティ戦略本部は、国レベルの情報セキュリティ組織。
ISMSというワードを見ていつも何だったかなと忘れてしまうので、覚えにくいので注意。自分の中でISMSが何なのか整理できていないので、
しっかり理解しておく。
ISMSはInformation Security Management Systemの略。
ISMSは組織が情報を適切に管理するための大きな枠組みのこと。
どういう情報の管理かというと、Information Securityという文字通り、情報の安全性を管理する。機密情報の管理や、個人情報の保護など。
ISMSという機関?規格?など用語を見る限り漠然としていて何なのかすっきりしないけど、ISMSの枠組みを利用できるよう、標準化されている。
それがJIS Q 27001（ISO/IEC 27001)。
JIS Q 27001はISMSの要求事項を定めた規格で、ISMSを組織が利用しISMSの要求事項を達成するために作成されている。
企業の実施しているISMSがちゃんとJIS Q 27001に沿ったものかを評価し、評価基準を満たしていたら認証を与える制度もある。
その制度を、ISMS適合性評価制度という。
ISMS認証を管理している組織が、JIPDEC。
事業者が個人情報をちゃんと取り扱っていることを認定する資格みたいなものが、プライバシーマークという制度。
これもJIPDECが管理していて、事業者に対してプライバシーマークを付与している。
プライバシーマークを格上げして、規格としたものが、
JIS Q 15001(個人情報保護マネジメントシステム)
CC(Common Criteria:セキュリティ共通評価基準)とは、情報技術・コンピュータセキュリティの国際規格で具体的な規格名が
ISO/IEC15408。この規格によって、IT製品や情報システムに対し情報セキュリティを評価し認証するための評価基準が定められている。
ISOやJISは当たり前のようにおなじみだけど、IECは知らずなじみがないのでメモ。
IEC(International Electrotechnical Commition)は、電気、電子についての国際規格を標準化する団体。
DeMilitarized Zone(非武装地帯)は、外部のネットワークと内部のネットワークの中間に置かれる中間的なネットワーク領域。
隔離されたDMZの領域を設けることで外部ネットワークからアクセスを受ける領域を内部ネットワークから切り離す。
外部と通信するサーバーなどが内部ネットワークと同じところに設置されていると、突破されたときに内部ネットワークに直接
影響がでてしまうため、内部ネットワークから切り離してDMZにサーバーなどを設置することで、内部ネットワークに侵入できないようにし
内部ネットワークを保護する。
DMZを構築する方法としては、外部ネットワークとDMZの間にファイアーウォールを設置し、DMZと内部ネットワークの間にもファイアウォールを設置する。
内部ネットワークとDMZの間のファイアウォールは突破できないように厳密に設定することで、内部への侵入を遮断する。
DMZに置かれるDNSサーバーは、外部からの問い合わせに対応する必要があるので、外部のIPアドレスで識別してアクセスを制限することができない。
また、ポート番号はTCP/UDP53で固定なので、問い合わせのパケットを通過させる必要もある。このため、DNSサーバーへの問い合わせパケットを遮断することは難しい。
webサーバーのアプリケーションプログラムの脆弱性を狙った攻撃に対しては、ファイアーウォールで対応することが難しい。
攻撃内容がパケットのデータ部分に書かれているのに対し、ファイアーウォールのパケットフィルタリングはデータの内容でフィルタリングできないので、
攻撃が書かれたパケットがファイアーウォールを通過しwebサーバーのアプリケーションプログラムに届くことが可能になってしまうため。
そのため、WAF(web application firewall)で対応することが必要になる。
DMZに置かれた内部ネットワークに対してのwebサーバーやファイルサーバーは、内部ネットワークに情報提供するので、ポート番号を外部に公開しない、
つまり、外部へのポートを閉じて遮断することで、webサーバーやファイルサーバーに対する外部からの不正アクセス攻撃を遮断できる。
DMZに置かれたプロキシサーバーの使用していないポートを公開しなければ、つまり、公開していないポートを閉じて遮断しておくことで、
プロキシサーバーの使用していないポートを狙った外部からのポートスキャンを防止することができる。
ポートスキャンでは、未使用のポートを公開しているだけでも脆弱性につながる可能性があるので、未使用のポートは閉じておくのがよい。
ファイアーウォールで使われるパケットフィルタリングは、パケットのヘッダの内容をチェックして通過させるパケットと
遮断させるパケットを識別する仕組み。
宛先と送信元の情報: IPアドレス、ポート番号などがヘッダに含まれている。
ヘッダの内容だけチェックし、データの内容には関知しない。
IDSとIPSはどちらも、パケットのヘッダをチェックしている。アプリケーション層での処理はできないので、Webアプリケーションとのやり取りはできない。
WAFはアプリケーション層で動作するので、Webアプリケーションとやり取りできる。という特徴がある。
システム開発工程で、システム設計やテスト設計はトップダウン方式で、抽象的な概念から具体的な概念へと工程を進める。
一方、具体的なテストは、ボトムアップ方式で工程を進める。モジュールなど、細かな単位でのテストを実施し、徐々にシステムを結合しつつ、全体的なテストへと
テスト工程を進めていく。
一般的には、下記のような流れで開発工程を進める。
見ると当たり前の工程に見えるけど、しっかりと頭にいれておく。
要件定義では、誰の何のためのシステムで、どこまで必要かなどを、システムを使う側であるユーザーの代表者などが参加して協議し詰める。
外部設計では、システムの操作画面やUIなど決める。内部設計では、システムの機能や動作の設計をする。言語、データベース、APIの選定など
技術的要素をどれにするか検討し決めていく。要件定義、外部設計、内部設計までの工程を、上流工程と呼ぶ。
開発の工程では、上流工程で決めた仕様をもとに、プログラムを作成していく。ここからが、下流工程と呼ばれる。
テストの工程では、テスターというテストを専任している担当者が、作成したプログラムの動作を検証していき、バグがないか、正しく動作
するかを確かめる。製造行でいう品質保証、試験チームみたいな感じ。テストは、単体テスト、結合テスト、総合テストの順に実施していく。
単体テストで細かい機能単位で動作を確認し、結合テストでは単体テストした機能などのグループを作り、そこで正しく動作するか、バグがない
かを確認する。そして、総合テストでは、システム全体の単位でテストをしシステムとしてちゃんと使えるかを確かめる。
最後に、運用テストをする。運用テストでは、完成したシステムをユーザーに使ってもらい、ちゃんと動くかを検証する。
JIS X 0160および共通フレーム2013においては、下記のような工程の表現と流れになる。表現は違って見えるが、上記の流れと
同じことを言っている。
システム要件定義
↓
システム方式設計
↓
ソフトウェア要件定義
↓
ソフトウェア方式設計
↓
ソフトウェア詳細設計
ここまでが、トップダウンの流れで進めるシステム設計・テスト計画工程となる。
ソフトウェア詳細設計以降の工程から、ボトムアップで進めるテスト工程となる。
ソフトウェア詳細設計
↓
プログラム作成、単体テスト
↓
ソフトウェア結合テスト
↓
ソフトウェア適格性確認テスト
↓
システム結合テスト
↓
システム適格性確認テスト
いつも両者の違いが分からなくなるので、しっかりと覚えておく。
ブラックボックステストは、ユーザーでもできるテストで、プログラムの構造とかわからなくてもできる、入力に対して出力がちゃんと
想定通りにされるかを確認するテスト。
一方、ホワイトボックステストは、主に開発者が実施するテストで、プログラムの内部構造など知っておかないとできないテスト。
プログラムの動きに着目したテストで、システムに対してもちゃんと知っておかないとできないので、開発者が主に実施する。
内部構造に着目しているので、抜けなく網羅性のあるテストとなる。
特徴：単体テストのときに、ホワイトボックステストが利用される。結合テスト以降のテスト工程では、ブラックボックステストがメインになる。
Computer Aided Software Engineeringは、システム開発や保守作業の自動化を支援するソフトウェア。
幅広いツールがあるけど、一般的にCASEと呼ばれているのは、分析や設計に関するツール。
システム開発の上流工程で利用されるCASEを上流CASEと呼び、要求定義、分析、ダイアグラム作成、プロトタイピングなどをCASEツールで実施する。
下流工程で利用されるCASEを下流CASEと呼び、プログラミング、画面作成や帳票作成、ファイルやデータベース設計などをCASEツールで実施する。
保守工程で利用されるCASEを保守CASEと呼び、リバースエンジニアリングやソースプログラムの解析や修正、再構造化などをCASEツールで実施する。
プロセスモデルとは、ソフトウェア開発工程をモデル化し、開発手順としたもので、ウォーターフォールモデル、プロトタイピングモデル、
スパイラルモデル、RADなどがある。
ソフトウェア開発工程を上流から下流に向けて作業を進めていくモデルで、古くから存在するモデル。大規模開発で使われる。
要求定義、外部設計、内部設計、プログラミング、テスト、運用の順に工程を進めていく。
順番に進めるのでプロジェクト管理がしやすい。原則、前工程が終わらないと次工程に進まない。
後戻りが発生しないように各工程の終わりにレビューを徹底するけど、後戻りが発生してしまうと開発の効率が低下する。
全体を独立性の高い部分に分割し、各部分ごとにシステム開発をしていく方法をスパイラルモデルと呼ぶ。大規模開発で使われることが多い。
小さめの規模の開発では、スパイラルモデルよりもアジャイル開発モデルが使われることが多い。
各部分のシステム開発については、ウォーターフォールモデルやプロトタイピングモデルを採用する。
各部分ごとに一連の開発工程を何度も繰り返しつつ、開発工程の規模を少しずつ拡大(機能改良・追加)していくので、
スパイラルモデルと呼ぶ。一見するとスパイラルモデルという名称と内容のイメージが湧きにくいので注意。
システム開発の早い段階で試作を作って、ユーザーの要求を早い段階から取り入れる手法。
コンピュータとユーザーのやり取りが多いシステムほど、プロトタイピングモデルの利用が効果的となる。
Rapid Application Developmentは、数か月程度の短期間で開発を完了させることを目的とした開発手法。
プロトタイピングモデルのように、ユーザーも参加し、試作品を作りつつそれを評価して改良するというスパイラルで開発を進め完成品に近づけていく。
一般的で煩雑になる処理のソースコードを自動的に生成する機能を利用することで、開発を効率的に進める。Qtやvisual studioなどのIDEもRADツールに分類される。
Continuous Integration 継続的インテグレーションとは、ソフトウェア開発においてビルドやテストを頻繁に繰り返すことによって問題を早く発見し、開発の効率化や省力化、納期の短縮などを図る手法。
専用のツールを用いて自動化、または半自動化して効率的に開発を進めること。
githubなどの分散バージョン管理システムなどを利用した開発でよく利用される。
開発者は中央サーバー・リポジトリに、自分の担当するコードを頻繁に提出する。
中央サーバ側では、誰かが変更操作をする度に、または決まった時間間隔などで、プロジェクト全体のビルドや各モジュールの
単体テスト・変更されたモジュール間の結合テストなどを実施する。
結果はすぐ各担当者にフィードバックされる。不具合が発生した場合は、ビルドの直前にされた変更や変更箇所に関連するコードが原因として考えられるので、
問題点を早期に発見・修正できるというメリットがある。
ソフトウェア開発にどれだけコスト(コストだけどお金じゃなく工数など)がかかるかについての見積もり手法として、
FP法、COCOMO、Putnamモデルなどがある。
コスト＝お金と考えがちだけど、その前の段階の工数や開発ステップのことなので、勘違いに注意。
開発のステップ数とは、プログラムの規模の大きさを確認する指標の一つ。意味のあるプロゴラムのソースコードの行数。
コメントや空行などもソースコードの中に含まれるので、そういったものを除いた行数をステップ数として数える。
Function Pointとは、機能の数のこと。機能の数が工数や規模に比例するので、機能の数に着目してどれだけのコストがかかるかを見積もりする。
ソフトウェアの機能、画面やデータベース、帳票出力といった機能を、外部入力、外部出力、外部照会、内部論理ファイル、外部インターフェースファイル
という5種類のFunction Pointに分ける。そして、分けた機能それぞれについて、個数・難易度から開発コストを算出する。
機能数だけでなく、複雑さで手間が変わってくるため、機能数と複雑さを考慮したものがFunction Pointとなる。
FP法では誰が見積もりを実施しても人によるばらつきがなく、見積もりが同じ結果となることが特徴。
各機能が事前に細かく定義されているため、誰が見積もりしても同じ結果になる。
FP法ではファンクションをデータ処理に関する”トランザクションファンクション”と、データ格納に関する”データファンクション”に大別して集計する。
各区分のファンクションごとに点数を定めているので、点数表に集計すると合計のスコアが簡単に求められる仕組みとなっている。
Constructive Cost Modelは、過去の統計値・経験値をもとにして、ソフトウェアの開発ステップ数からソフトウェアの開発工数を算出する。
算出した開発工数によって、開発期間を見積もる。
詳細はcocomoについてのわかりやすい記事を参照する。
Putnamというひとが作った見積もり手法。トップダウン方式の見積もりをする。
まず全体的な要員数や工数を見積もりそこから細かな単位で見積もりをしていく。
外部からの見た動作を変えずに、プログラムをより良く作り直すこと。
プログラムは設計変更やバグの修正などで、次第に冗長になりやすい。リファクタリングによって動作は変わらなくてもプログラムをより良いものに見直すことで、
プログラムの品質が向上するので、冗長なプログラムになることを防止できる。
各機能についてのテストを先に作成し、テストに通るように最低限のプログラムを作成し、リファクタリングしプログラムを洗練させる。
そしてテスト項目を追加し、また前述の短い工程を繰り返してプログラムを洗練させ完成させるというプログラム開発手法。
最初にテストを作成するので、テストファーストと呼ばれる。
テスト駆動開発のメリットとデメリット：
モジュール単位やユニットごとの小さめの単位でテストをして、テストを通るようにするので、バグを早期に発見できる。あとでバグが発生しにくくなる。
テストコードを作成するためには要件や仕様をちゃんと理解しておかないとテストコードを作成できないので、要件や仕様に対する理解が深まる。
リファクタリングやコードの追加をするたびに他の部分への異常や影響がないかを確かめるリグレッションテストをするので、異常がないかを都度確かめつつ
開発を進められるので、自分のした作業でプログラムが壊れるのではないかという心理的負担が軽減される。
テストを先に作成するという、通常の思考の流れとは違う感じなので、ちゃんとしたテストを作ることに慣れることに時間がかかる。
要求定義やソフトウェア設計の結果を表現する技法がいろいろある。
機能階層モデルとは、機能に着目して要求モデルを作成するもので、システムの持つ機能を階層的に分割しながら要求モデルを作成する。
トップダウンなウォーターフォールモデルで開発する時に最適なモデル。
Data Flow Diagramとは、主にシステム開発の要件定義の段階で使われるデータフローモデル。
システムにおいてデータ全体の流れを確認するために作られる図。
システムを作るときに、システム全体の流れとデータ処理のプロセスを図表にすることで視覚的に把握できる。
DFDはシステム開発の要件定義のときだけでなく、業務フローを分析するためにも利用される便利な手法。
データの入力、処理、記憶、出力の4つを表現する。ただし、処理のタイミングなどは表現しないので、タイミング制御を伴わない
データの流れを表現するのに適している。
DFDが使われる目的として、関係者とシステムイメージを共有するために使われる。
既存のシステムに対して全体像が整理できていないときに、DFDを使うことで全体像を把握するために使われる。
システムに対して、機能漏れや機能の重複がないように機能を整理するために使われる。
システムの処理を詳細にしていくために使われる。
DFDについてかなり詳しい参考記事を参照する。
データ指向モデルとは、システムの機能ではなくデータの分析を中心に進めるモデルのこと。
データに指向を置いたモデルと考えるといい。
データ指向のモデルには、E-Rモデル、抽象データモデル、オブジェクト指向モデルがある。
E-Rモデルは、Entity-relationship Modelの略で、日本語でいうと実体関連モデルと呼ぶ。
対象を実体(Entity)と関連(Relationship)をE-R図によって表現する。
E-R図は、作成した図がそのまま物理データベース上に変換できるので、関係データベースの設計に利用される。
実体と関連を構成する要素を属性と呼ぶ。
ERモデルについてのわかりやすい参考記事を参照する。
Unified Modeling Languageは、オブジェクト指向システムを定義、視覚化、文書化するために使う言語。
言語というとプログラミング言語のようなイメージをどうしても持ってしまって実際の内容との乖離を感じるので、
一連の手法・表現方法と覚えた方が覚えやすそう。UMLは分析から設計までの表現をカバーできる。
図や表の表現が人によって異なると混乱するので、誰でも共有できるようにするため、図や表の書き方が標準化されている。
UMLは広い範囲をカバーできるので、広く普及している。規格が都度バージョンアップされており、バージョンはUML2.0
のような表記で表されている。
UMLで標準化されている図は14種類あり、システムの様々な面を表現できるようになっているので、
すでに存在するシステムを分析して図にしたり、開発予定のシステムを開発メンバーと協議し設計をしていく
場面などでUMLの図が利用される。
UMLについてのわかりやすい記事を参照する。
各図の簡単な説明は下記。
下記のクラス図～パッケージ図は構造を記述するための図。
ユースケース図～アクティビティ図はシステムの動作を記述するための図。
システムのオブジェクトとその性質や機能を記載し、各オブジェクト間の関係が分かるようにするための図で、
プログラミングにおけるクラス間の関係を図にしたり、開発システムを大きく俯瞰するために図にしたり、
様々な場面で利用される図。
クラスよりも大きい単位のサブシステム単位を対象とした図で、システムを全体的に俯瞰する際に便利な図。
クラスの性質や機能の関係をより詳細に記述するための図で、クラス図をさらに深堀りしたもの。
システムの内容を理解しやすくするために利用される。
ハードウェア間の関連を図にしたもの。ハードウェアで稼働されるソフトウェアやサーバーも記載するので、
ネットワークで繋がれたハードウェア間の関連が分かりやすくなっている。
パッケージ図は、クラス図の一部で、複数のクラスを一定の基準でグルーピングしてパッケージ単位にし、複数のパッケージ間の依存関係を
表すのに利用される。依存関係が難しく分かりにくくならないようにするために利用される。
ユーザーから見たシステムが提供する機能を表現する図。システムの要件定義の段階で利用される。
ユーザーやハードウェアと、システムが提供する機能を線で結ぶ。システムに関連するユーザーやハードウェアをアクターと呼び、
システムが提供する機能をユースケースと呼ぶ。
オブジェクト間の相互作用を時系列で上から下に向かって表現する図。時系列でシステムがどのように動いていくのかを分かりやすく見る
ことができる。システムのあるきまった抽象度だけで利用されるのではなく、いろんな抽象度で使われる。
オブジェクト間の相互作用や関連を表現する図。シーケンス図との違いは、時系列に書かないこと。
オブジェクトの状態遷移を表現する。プログラムのより詳細な抽象度の状態遷移を表すことに使われる。
一連の処理をする際の条件分岐などが書かれた流れ図、フローチャートに似ている図。
システム開発するためには、どんな業務なのか、対象の業務を把握することが必要。システム開発の対象とする業務をどんな目線で把握
するかについて、着目の仕方が2種類に分けられる。プロセスに着目して業務を把握するアプローチをプロセス中心アプローチという。
また、データに着目して業務を把握するアプローチをデータ中心アプローチという。
プロセス中心アプローチをPOA(Process Oriented Approach)と呼ぶ。
データ中心アプローチをDOA(Data Oriented Approach)と呼ぶ。
古くからあるアプローチ方法で、対象業務を構成している機能に着目し、入力データをどのように出力に変換するかについて
検討し、システムを構築する。プロセスフローという処理の手順を表す図を利用する。
業務の手順やプロセスに着目して設計をする。システムの機能要件を作るときに利用される。
POAはある特定の業務内容をシステム化することが優先になり、システムの再利用などの応用がしにくいシステムになりがちとなる。
システムの要求定義と設計段階で使われるアプローチ方法。オブジェクト指向設計やE-RモデルなどがDOAの例。
データベースを利用するシステムに使われることが多い。
業務内容を表すデータの構造やデータに着目し、データ(指向)モデルの作成を中心にしてシステムを構築する。
プロセス中心アプローチでは対応できなくなってきたので、データ中心アプローチが生まれ、こっちのほうにやりかたがシフトしている。
オブジェクトを部品として扱うことで、設計やプログラミング作業の効率を上げることができる。 データ(属性)と操作(メソッド)を一体化することをカプセル化といい、カプセル化したものをオブジェクトという。
同じような機能のオブジェクトをまとめたものをクラスという。
オブジェクト指向でソフトウェア設計するときは、ウォーターフォールモデルのように後戻りできないという問題が
そもそもない。理由は、オブジェクト指向のライフサイクルがラウンドトリップ型だから。
ラウンドトリップとは、どの工程にも分岐できるという意味。
クラスの階層構造を表現するために汎化と特化という呼び方を使う。
スーパークラスの性質をいくつかに分解してサブクラスに具現化することを特化と呼び、
サブクラスの共通する性質をいくつかまとめて抽象化することを汎化と呼ぶ。
汎化と特化はis-a関係で表される。例えば、”生物”をスーパークラス、”猫”をサブクラスとすると、
汎化することを”猫is-a生物”、特化することを”生物is-a猫”と表現する。
汎化と特化はクラスで使われる表現に対し、集約と分解はクラスよりも大きな単位のオブジェクト間で使われる表現。
集約と分解はオブジェクト間の関係を表現するために使われる呼び方。
下位オブジェクトの共通する部分をまとめて抽象化することを集約と呼び、
上位オブジェクトの部分をいくつかに分解することを分解と呼ぶ。
集約と分解はpart-of関係で表される。例えば、”キーボード”を上位オブジェクト、”キーキャップ”を下位オブジェクトとすると、
“キーキャップpart-ofキーボード”のように表現する。
子オブジェクトは部品と考えることができ、再利用が可能となることが特徴。
集約して抽象化した全体に対し、部分側だけでは存在できずそれが全体側に依存している強い依存関係があるとき、
その強い集約関係をコンポジションと呼ぶ。
コンポジションの例)生物と細胞、車とタイヤなど
(モジュールの分割手法やモジュール強度・結合度についての記事)[https://www.momoyama-usagi.com/entry/info-software09]を参照する。
ソフトウェアをプロセスとデータに分けて考えるとき、プロセスを中心に設計を進めるときは構造化設計技法が使われる。
一方、データを中心に設計を進めるときはジャクソン法という技法が使われる。
構造化設計技法としてSTS分割、TR分割がある。
STS分割は、プログラム構造をSource(源泉・入力)、Transform(変換)、Sink(吸収・出力)という3つの単位に分割し、それぞれを単体のモジュールにすること。
STS分割の基準は、最大抽象入力点と最大抽象出力点。
最大抽象入力点とは、これ以降は入力データが発生しない区切りの地点で、最大抽象出力点とは、これ以降は出力データが発生しない区切りの地点。
最大抽象入力点は、SourceモジュールとTransformモジュールの間に存在し、最大抽象出力点は、TransformモジュールとSinkモジュールの間に存在する。
STSに分割した後は、3つのモジュールを制御する制御モジュールとして、親モジュールを位置づける。
Transaction分割とは、入力されたデータの種類に応じて実行するトランザクションが分かれるとき、一つのトランザクションを1つの単位のモジュールとして分割すること。
データフローがデータの種類ごとに分岐するとき、それぞれのデータフローをトランザクションと呼ぶ。
TR分割では、個々のトランザクションに対応する処理群をまとめてモジュールとする。
Jackson Structured Programmingの略で、JSPと略される。
入力データの構造が出力データの構造に対応しているときにJSPが使える。
対応していない場合にJSPを利用するには、入力データの構造が出力データの構造に対応できるようにするための中間ファイルを作るなどの処置が必要になる。
入出力のデータの構造からプログラムの構造を決めていく設計技法。
入力するデータと出力したいデータが明確であると、処理内容が自動的に決まってくることを利用している。
処理内容を決める際に、木構造の階層構造で処理を表現し、個々の処理として、基本、繰り返し、連接、選択の4つの処理を利用して構造を作成する。
ウォークスルーとインスペクションの違いについてを問う問題が試験に出やすい。
ウォークスルーとインスペクションの違いは、ウォークスルーは内部関係者かつ上長が参加しない非公式な集まりでの打ち合わせ。
インスペクションは、第三者が参加して評価基準に基づいて仕様書やソースコードの評価をして、不具合等を摘出するためにする。
インスペクションはモデレータという管理者が指揮をとって進める。インスペクタと呼ばれる担当者が評価作業をする。
インスペクションは不具合、エラーの摘出が目的なので、解決策は別途進める。
### ソフトウェア開発管理技術
システムを構築するにあたって、色んな技術を利用する。
技術としては再利用技術、モジュール設計、プログラミング手法などがある。
リユーステクノロジとも呼ばれる。再利用技術とはソフトウェアを再利用することである。
再利用と同じ意味として、モジュール化、リバースエンジニアリング、コンポーネント化、オブジェクト指向設計
などの技術がある。
再利用の技術を利用する目的は、生産性が高まるから。
ソフトウェアの開発に必要な知識などを標準化し、繰り返し利用できるようにしておく。
それを新しいソフトウェアをつくるときに再利用することで、全部1から作らなくていいのでソフトウェア開発が効率的になる。
リエンジニアリングとは、既存のものを見直し、ゼロから、根本的に作り直すこと。
意味を忘れやすい、単語から意味が想起しにくいので注意。
リエンジニアリングするときには、リバースエンジニアリングとフォワードエンジニアリングを利用する。
オブジェクト指向を利用すると、カプセル化するため情報が隠蔽され、局所性の高いオブジェクトが作れるので
変更などによる影響範囲が限定され、再利用しやすくなる。
オブジェクト指向自体=再利用といってもいいくらい。
モジュール強度とモジュール結合度についての問題が頻出しているが、強度と結合度の細かな区分の内容が覚えにくい。
まずは両極端の項目をしっかりと頭に入れておく。
モジュール強度は、1つのモジュールを構成しているモジュール内部の関連性の強さを表している。
モジュール強度が高いほど、独立性の高いモジュールなので望ましい。
モジュール結合度は、複数のモジュール間での関連性の強さを表している。モジュール結合度が弱いほど
モジュールの独立性が高く、他の関連するモジュールへの依存性が小さいので望ましい。
モジュール強度が強く結合度が弱い、理想的な良いモジュールであると、モジュールの改修が入ったときに
影響範囲が他のモジュールに広がらないので、改修の手間が少なくて済む。
反対に良くないモジュールだと、１つのモジュールを修正するだけでも他のモジュールも修正が必要になるので
手間がかかり、思わぬバグの発生にもつながりやすくなる。
モジュール強度と結合度をイメージしやすい記事を参照してイメージを掴む。
語呂合わせをして項目を覚えておく。
語呂合わせ：暗論時手連情機。あんろんじて、れんじょうき。
暗号的強度->論理的強度->時間的強度->手順的強度->連絡的強度->情報的強度->機能的強度
語呂合わせ：内共外制スデ。ないきょうがい、せいすで。
内部結合->共通結合->外部結合->制御結合->スタンプ結合->データ結合
品質計画、管理、評価において、QFDという技術がある。
QFDとはQuality Function Developmentの略で、品質機能展開と呼ぶ。
顧客の要求する品質を具体的に評価する品質特性に置き換えて、品質特性を技術特性に置き換えて、サブシステムやモジュールに展開し落とし込むこと。
工程管理や進捗管理にはアローダイアグラムやガントチャートが利用される。
アローダイアグラムとガントチャートは対象とする工程の粒度が違う。
アローダイアグラムは個々のモジュールなど個々の工程の具体的な管理に使い、ガントチャートは開発全体の進捗状況を把握し管理するために使う。
アローダイアグラムは作業の関連と所要日数を表現できるので、大規模なプロジェクトの日程管理にも使われる。
一方、ガントチャートは作業の関連は表現できない。
アローダイアグラムは、海外ではPERT図と呼ばれる。また、アローダイアグラムは新QC7つ道具の一つ。
システム開発におけるマネジメントのことをプロジェクトマネジメントという。一方、システム運用・保守におけるマネジメントのことをサービスマネジメントという。
このように、システム開発とシステム運用・保守で呼び方が分かれていることに注意する。
プロジェクトで作るものと、それを作り出すために必要な作業のことを、プロジェクトスコープと呼ぶ。
そのプロジェクトスコープを管理することをプロジェクトスコープマネジメントと呼ぶ。
プロジェクトスコープマネジメントではプロジェクトの計画及び定義のことをスコープ計画およびスコープ定義と呼ぶ。
スコープ計画とスコープ定義をしっかりと吟味しておかないと、あとで手戻りが発生したり追加作業が発生したりし
プロジェクトがスムーズに進まなくなる恐れがある。
プロジェクトスコープマネジメントでは、スコープ計画・スコープ定義を決めた後に、WBS(Work Breakdown Structure)を作成する。
WBSを作成することによって、細かい粒度で具体的なプロジェクトの見積もりやプロジェクトの作業範囲が明確になるので、作業スケジュールが作りやすくなる。
WBSを作成後、プロジェクトが進行しだしたら、スコープ検証・スコープコントロールを実施することでプロジェクトを評価し見直しする。
これによって、プロジェクト進行中の軌道修正、是正などを適切に実施できる。
プロジェクトスコープマネジメントは、PDCAサイクルと同等の手順となっているのでプロジェクトスコープマネジメントとはPDCAであるともいえる。
プロジェクトスコープマネジメントにおいては、PDCAの
となるので、プロジェクトマネジメントの要素をPDCAに当てはめると覚えやすくなるかもしれない。
Project Management Body of Knowledgeの略で、プロジェクトマネジメントを体系的にまとめた指針の一つ。
世界的によく利用されているので、プロジェクトマネジメントの世界的標準となっている。
品質、コスト、納期であるQCDをプロジェクトマネジメントの大枠とし、QCDを管理するために5つのプロセスを定義している。
5つのプロセスは、立ち上げプロセス、計画プロセス、実行プロセス、監視及びコントロールプロセス、終結プロセスがあり、
さらにこれら5つのプロセスを進める中で指針とするものに、10の知識エリアと呼ばれる10個の観点がある。
総合マネジメント、スコープマネジメント、コストマネジメント、スケジュールマネジメント、品質マネジメント、
リスクマネジメント、調達マネジメント、ステークホルダーマネジメント、資源マネジメント、コミュニケーションマネジメントの
10項目が、10の知識エリアである。
PMBOKを基にした国際規格にISO 10006がある。これは品質管理のISO9000シリーズのガイドライン規格。
ISO10006の日本版が存在し、JIS Q 10006としてJIS規格になっている。
ガイドライン規格(ガイダンス規格)は、ISOが世界中の有識者を集めて作成した国際的な手引書のこと。
規格は推奨事項で構成されていて、推奨事項は国際的なお手本という位置づけになる。
推奨事項に準拠することは、いろんな組織・団体から国際的に高い評価を受けることにつながる。
EVMは覚えるのが大変で理解もしにくいので、何度も触れることで慣れるようにする。
Earned Value Managementの略。プロジェクト全体のスケジュールの遅れやコストの超過を見える化する進捗管理手法。
EVMは作業進捗や達成度を金額で表現することが特徴。
EVMではPV、BAC、EV、AC、EACという指標を使って進捗状況を判断する。
PV(Planned Value：出来高計画値)
ある時点における費用総額の予測値。なぜある時点の予測値が分かるかというと、PVは線図にするとカーブを描いた線になっていて、
予算の計画線なので、線上のある任意の時点の点は、計画通りに進んだ場合どのくらいの累計で予算がかかるかを表しているモデル線図になっているから。
BAC(Budget At Completion：完成時総予算)
プロジェクト完了時点におけるPV。すなわち予算の合計金額のこと。
EV(Earned Value：出来高実績値)
作業の実績値の累計。完了済の作業に対する予算。EVを線図にすることで、PVとの差が可視化され計画に対しての進捗が分かる。
ここで注意なのが、完了済の作業に対する”予算”なので、実際にかかったコストではないことに注意。
AC(Actual Cost：コスト実績値)
実際にかかった費用の累計。ACも線図にすることで、PV線図やEV線図と比較でき、ある任意の時点においてコストが超過していないかなどを比較できる。
EAC(Estimate At Completion：完成時総コスト見積り)
完成するまでの実際の総コストの予測値。完成していないある時点から、実際の総コストを予測するために計算する。
EACの求め方：EAC=AC+(BAC-EV)/CPI
BAC-EV
完成までにかかる計画上の総予算であるBAC(完成時のPV値)からある時点での完了済の作業に対する予算を引いたものなので、
ある時点での、残り使える予算を表している。
CPI
Cost Performance Index：コスト効率指数と呼ばれるもので、投入したコストに対してどの程度の成果を上げているかを表す指数。
CPI=EV/ACで求まる。ある時点でのEVに対してACが小さい場合は、作業の進みに対して、実際のコストが低コストであることを表しているので、
コスト効率がよいことを意味している。逆に、ある時点でのEVに対してACが大きい場合は、作業の進みに対して、実際のコストが高コストである
ことを表しているので、コスト効率がわるいことを意味している。
CPIが1より大きい場合は、EV>ACであり作業の進みに対して実コストが想定よりも低コストで済んでおり、コスト効率がよい。
逆に、CPIが1より小さい場合は、EV<ACであり想定よりも高コストになっていることを表している。
(BAC-EV)/CPI
BAC-EVはある時点での使える残りの予算を表しているので、これをCPIで割ると、残りの作業に対するの実コストの予測値が求まる。
現在のコスト効率であるCPIがこのまま続く前提として計算する。
残りの予算(BAC-EV)が100万円とすると、CPIが1の場合は、コスト効率は予定通りなので、100/1=100万円が残りの作業にかかる実コストの予測値。
CPIが2とすると、100/2=50万円が残りの作業にかかる実コストの予測値で、予算よりも低コストで済むことが予測される。
CPIが0.5とすると、100/0.5=150万円が残りの作業にかかる実コストの予測値で、予算よりも高コストでこのままでは予算を50万円超過
してしまうことを意味している。
AC+(BAC-EV)/CPI = (EAC)
残りの作業にかかる実コストの予測値である(BAC-EV)/CPIにこれまでにかかった実コストACを足したものなので、
これが完成するまでの実総コストの予測値となる。
QC7つ道具についての記事を参照する。かなり詳しく分かりやすい記事。
サービスマネジメントはITのライフサイクルすべてを対象とするマネジメント。
世界的なデファクトスタンダードとなっているガイドラインで、ITILをベースに制定された規格としてISO20000がある。
ISO20000に対応するJIS規格はJIS Q 20000。
これまでにバージョンアップが繰り返されてきて、現在ではバージョン4になっているが、本などはバージョン3のことが載っている感じ。
ITILバージョン3は大きく5つのステージ(5つの段階)に活動を分類している。
下記の5つのステージは戦略->設計->移行->運用->継続的サービス改善の順番に進められる。
ITILは、ステージ-プロセス-機能という階層で構成されている。
主なプロセスと機能についての問題がほぼ毎回出題されているので、しっかりと頭にいれておく。
ITILには4つのPと呼ばれる考え方がある。
People, Processes, Products, Partnersの4つの分野について、適切にバランスよく対策をするという考え方。
正味現在価値についてわかりにくく、なかなか理解できなかったので注意する。
正味現在価値(Net Present Value)は投資する価値があるかを判断する指標として使う。
NPVが0より大きいなら投資額よりも上回り利益がでるので投資する価値がある。
NPVが0なら投資額と見込める利益が±0となり利益も損もでないので意味がない、NPVが0未満なら将来の利益が投資額を下回るので
損をするので投資する価値がないと判断する。
NPVは大きければ大きいほど利益も大きくなるので、複数の投資先の選択肢がある場合は、NPVの大きさでどれに投資するかを決める根拠にすることができる。
NPVを計算する手順：
まず投資額を明らかにする。初期投資額として100万円までは使えるとする。
例えば100万円を投資することで将来に100万円がいくらになるのかを将来価値と呼ぶ。
年に10%増えるとする。また、3年後の将来価値を知りたいとする。この場合は、
将来価値は、100ｘ(1+0.10)^3という計算式で求めることができる。
よって、将来価値は133.1万円となる。
いくら投資すればいいのかはわからないけど、3年後に133．1万円得られる権利があるとする。
これから現在価値を計算すると、133.1/(1+0.1)=100万円となる。
このため、利益を出すためには、投資額を100万円未満に抑えないと利益がでないことがわかる。 見かけ上は、100万円投資したとすると100万円が133.1万円に増えているけど、100万円未満で133.1万円を得る権利を入手できないと、 利益が出ないと考えることが正味現在価値の考え方。直観に反して見えるけど。
現在価値は、将来得る金額が分かっているとして、それを現在に換算するといくらになるのかを表す概念。
例えば、割引率10％で3年後の将来に100万円を得られる権利がある場合、現在価値は、100÷(1+0.1)^3=75.1万円となる。
3年後に必ず100万円を受け取る権利を持っているとすると、将来価値(3年後の100万円)から現在価値は75.1万円なので、
NPVは、現在価値PV - 投資額 で求めることから、75.1万円未満でその権利を買うことができないと利益がでないことになり、投資する意味がないことを意味している。
現在価値が75.1万円の商品を投資額60万円で入手できる場合、NPVは75.1-60=15.1万円となり、投資で利益がでると判断できる。といった感じに、
現在価値と投資額の値が分かれば、投資する価値があるのかどうかを直観的に簡単に判断できるようになっている計算式がNPVである。