SLCP,情報ｼｽﾃﾑ開発の流れ,ｼｽﾃﾑ化計画,要件定義,ﾍﾞﾝﾀﾞ選定(RFI,RFP,提案書,見積書:FP法・類推法),NDA,ｼｽﾃﾑ要件定義・方式設計,ｿﾌﾄｳｪｱ要件定義・方式設計,ｿﾌﾄｳｪｱ構築・品質
◆SLCP（共通フレーム）
Software Life Cycle Process。
ソフトウェアの構想から、開発・運用・保守・廃棄までの全工程（ライフサイクル）のこと。
またライフサイクルを通じて、必要な作業内容・用語の意味 等を規定した共通の枠組み。
ISO/IEC 12207：国際標準化機構(ISO)によって策定されたSLCPの標準的なモデル。
JIS X 0160：ISO/IEC 12207を日本語化したもの。
SLCP-JCF(Japan Common Frame)：JIS X 0160に対し、情報処理推進機構(IPA)が日本独自の事情を織り込んだガイドライン。SLCP共通フレーム。
組織的・商業的なソフトウェア開発・運用に際しては、発注側（顧客）・受注側（ベンダ）の間で、相互の役割・責任範囲・各工程の具体的な業務内容について認識の差異が生じないよう、SLCP-JCFのような標準モデルを参照して共通理解を深める必要がある。
◆情報システム開発の流れ（ウォーターフォール型の場合）
開発の各手順を時系列的に順番に一つずつ完了させながら進める。
この前半を「上流工程」、後半を「下流工程」と呼ぶ。
代表的な各手順は次。
①「システム化計画」
②「要件定義」
③「システム要件定義」「システム方式設計」
④「ソフトウェア要件定義」「ソフトウェア方式設計」「ソフトウェア詳細設計」
⑤「ソフトウェア構築（プログラミング）」（コードレビュー）
⑥「単体テスト」（④ソフトウェアレベルの確認）
⑦「結合テスト」（④ソフトウェアレベルの確認）
⑧「システムテスト」（③システムレベルの確認）
⑨「運用・受入れテスト」（②要件レベルの確認）
※2000年行こうには従来の漸進式（インクリメンタル型）の開発工程とは異なり、設計・実装・テストのサイクルを何度も繰り返し、徐々に完成度を上げる反復式（イテレーティブ型／スパイラス型）の開発手法も広まっており、その場合は上流・下流という区分はあまり使われない。
◆システム化計画プロセス（情報システム開発の①工程）
「システム化構想の立案」「システム化計画の立案」を行う。
システム化構想の立案：情報システム戦略に連動した経営上のニーズやシステム化を必要とする業務上の課題を確認して、システム化の方針を立案する。
システム化計画の立案：システム化する業務の内容を分析し、どのような情報システムが必要となるか、どのように開発・導入を進めるか 等の基本方針を策定・立案する。また、スケジュール・コスト概算も同時に行うことが多い。
費用対効果の観点が必要になる。
◆RoI
Return on Investment。
RoI（%）= 利益／投資額 * 100
投資額に対する利益の割合。
費用対効果を図る指標のひとつ。
投資額がどの程度効率的に利益を生み出しているかを把握できる。
この数値が高いほど「投資額が効率的に活用されている」と判断する。
情報システムの開発計画を立てる際にもRoIを考えることが重要である。
◆要件定義(RD)プロセス（情報システム開発の②工程）
Requirements Definition。
「システム化する業務」「システム化の仕様（範囲・機能 等）」を明確にする。
発注元（利用者）の積極参加が必要。
要件定義：2種類ある。「業務（ビジネス）要件定義」「システム要件定義（機能要件定義+非機能要件定義）」
業務（ビジネス）要件定義：利用者のニーズを考慮した業務に関する要件。システム化する業務手順、関連組織の責任・権限 等を定義する。
システム要件定義：2種類で構成される。「機能要件定義」+「非機能要件定義」
機能要件定義：業務要件を実現するために必要なシステム要件。データ項目抽出、処理内容、ユーザインターフェース 等を定義する。
非機能要件定義：機能要件以外に必要なシステム要件。信頼性、保守性、可用性、セキュリティ性 等を定義する。
◆ベンダ選定（調達）
発注元（利用者）が、開発を担当するベンダを選定・契約を結ぶ。
契約までに、以下のような各種情報や書類をやり取りする。
発注元が発行：「RFI」「RFP」
ベンダが発行：「提案書」「見積書」
RFI：Request For Information。情報提供依頼書。発注元が発行。発注先候補のベンダに対して、システム調達条件等を決定するために必要な情報を提供させる文書。RFP作成に役立てる。
RFP：Request For Proposal。提案依頼書。発注元が発行。発注先候補のベンダに対して、具体的な提案を依頼する文書。システムの目的・概要・要件・制約条件・スケジュール・予算 等が記載されている。これを受けてベンダが提案書・見積書を発行する。
提案書：RFPを基にベンダが発行。
見積書：RFPを基にベンダが発行。代表的な見積算出手法に「ファンクションポイント法」「類推見積法」がある。
◆ファンクションポイント法（見積算出に用いられる手法のひとつ）
Function Point method。
ソフトウェアの規模を計測する手法のひとつ。
内部の機能を数え上げ、それぞれの複雑さ等に応じ重みづけしたものを積算して点数（ファンクションポイント）として表す。
利用者から見たソフトウェアの持つ機能（帳票数・画面数・ファイル数 等）に対して、各機能を複雑度から点数付けし、それに基づいてソフトウェアの開発工程や開発費用 等を見積もる手法。
主なメリットは以下3点。
1.利用者から見える帳票・画面 等を単位として見積もるので、利用者にとって理解しやすい。
2.LOC(Line Of Code：ソースコード行数)等による評価・見積に比べ、プログラミング言語・書き方・機能の実装 等に依存しない。
3.データフローダイアグラム・ER図 等の設計段階で作成される資料から算出できる。
主なデメリットは以下１点。
1.機能の複雑度の判定は主観が入り込みやすく、過去に類似の事例の無い場合は点数付けが難しい。（評価法についてIFPUGに標準的なガイドラインがある）
◆類推見積法（見積算出に用いられる手法のひとつ）
ソフトウェアの規模を計測する手法のひとつ。
過去に開発した類似のシステムの実績を元に推定していく方式。
過去に類似の事例が無い場合は、経験・勘を元に見積る。
主なメリットは以下１点。
1.要件や機能 等が明確に定義される以前の、初期の段階でも適用が可能。
主なデメリットは以下2点。
1.精度は担当者の知識・経験に大きく左右される。
2.精度が低く、客観性・根拠に乏しいため、要件定義以降の詳細な見積もりには適さない。
◆NDA
Non-Disclosure Agreement。
秘密保持契約。
企業間で互いに知りえた相手の秘密情報の守秘義務について契約したもの。
◆システム要件定義(SR)・システム方式設計(SA)（情報システム開発の③工程）
System Requirements (Definition)。
System Architectural (Design)。
システム要件定義（システム要件定義書作成）後、システム方式設計（システム方式設計書作成）を行う。
システム要件定義：要件定義の内容を基に、開発者が発注元をヒアリングして、システム化する対象範囲を明確にし、システムに必要な機能・性能（システム応答時間・処理時間・信頼性）等を定義する。成果物として、システム要件定義書が作成される。
システム方式設計：システム要件をシステムでどのように実現できるか検討する。システムに必要とされる各要件を「ハードウェア」「ソフトウェア」「利用者による手作業」のいずれかによって実現するかを確定し、全体の公正や構造を決定する。成果物として、システム方式設計書が作成される。
◆ソフトウェア要件定義・ソフトウェア方式設計・ソフトウェア詳細設計（情報システム開発の④工程）
ソフトウェア要件定義（ソフトウェア要件定義書作成）後、ソフトウェア方式設計（ソフトウェア方式設計書作成）、ソフトウェア詳細設計（ソフトウェア詳細設計書作成）を行う。
ソフトウェア要件定義：システム要件定義の内容を基に、開発者が発注元をヒアリングして、ソフトウェアに要求される機能・性能（ユーザインターフェース） 等を定義する。成果物としてソフトウェア要件定義書が作成される。
ソフトウェア方式設計：ソフトウェア要件をソフトウェアでどのように実現できるか検討する。ソフトウェアの構造・プログラム間のインターフェースに関する仕様 等を決定する。成果物として、ソフトウェア方式設計書が作成される。
ソフトウェア詳細設計：ソフトウェア要件定義書、ソフトウェア方式設計書に基づき、プログラム作成できる（モジュール）レベルまで細分化した、プログラムの仕様 等を決定する。成果物として、プログラム詳細設計書が作成される。
モジュール：module。ある独立した機能を持った構成単位。ソフトウェアユニットとも呼ばれる。
◆ソフトウェア構築（情報システム開発の⑤工程）
ソフトウェア詳細設計書に基づき、成果物としてプログラムを作成。
コードレビューにて不備や誤りを発見・対策し、品質を上げる。
◆ソフトウェアの品質特性
代表的な品質特性は次。「機能性」「使用性」「信頼性」「効率性」「保守性」「移植性」
機能性：仕様書通りに操作でき、正しく動作すること。
使用性：利用者にとって、理解・習得・操作がしやすいこと。
信頼性：必要な時に使用でき、故障時には速やかに回復できること。
効率性：応答時間・処理時間・信頼性 等 求められる性能が備わっていること。
保守性：プログラムの修正がしやすいこと。
移植性：ある環境から、他の環境に移植しやすいこと。
※下記テスト工程は、別の記事にまとめる。
⑥「単体テスト」（④ソフトウェアレベルの確認）
⑦「結合テスト」（④ソフトウェアレベルの確認）
⑧「システムテスト」（③システムレベルの確認）
⑨「運用・受入れテスト」（②要件レベルの確認）
この記事が気に入ったらサポートをしてみませんか？