第５部　ソフトウェア・プロセス

Size: px

Start display at page:

Download "第５部　ソフトウェア・プロセス"

たつぞうたかはし
5 years ago
Views:

1 第 12 章ソフトウェア開発のための作業 ISO/IEC 12207:2008 という規格 ISO 関係の国際規格に ISO/IEC 12207:2008( 該当する JIS 規格は JIS X 0160:2012) というものがある [JIS12a] この規格名には Information technology Software life cycle processes という標題が付いている英文を日本語に直して記述するがソフトウェアライフサイクルとはあるソフトウェアについてその必要性が認識された時から破棄されるまでの文字通りソフトウェアの一生を指す [ISO10a] プロセスという言葉の正式の定義はこの後すぐに述べるがここでは作業の総合名称を意味するからこの規格は単純にいえばソフトウェアの必要性を認識するところから始まって最後にそのソフトウェアを破棄するところまでのそのソフトウェアに関わる全ての作業を網羅したものということになる [JIS12a] ISO/IEC の目的この ISO/IEC 12207:2008 の前に ISO/IEC 12207:1995 という規格があった ISO 関係の規格はその発行した年を規格のナンバーとコロンの後に付けているのでこの規格が 1995 年に発行されたものであることが分かる ISO は 1995 年版の規格を作るために 1988 年 6 月に作業を始めているからこの規格作りに 7 年以上の時間をかけたことになるそのようなたいへんな作業をして ISO がこの規格を作った目的はどういうところにあったのだろうか一言でいうとソフトウェア作りに関わる世界中の全ての人が共通の言葉で話せるようになること ( 同じ言葉で話そう(Speak the same language) ) を目的としていたたいへん俗な言い方だがもっと具体的に言うと次のようなことになるソフトウェアの需要が増すにつれ自分のところで使用するソフトウェアの開発を自社の開発力だけで対応できるところが少なくなり開発を外部に委託するところが増えてきたこの仕事を委託するのは一般の企業であることが多いが受託するのはソフトウェア会社であるこの場合委託する側と受託する側の間にソフトウェア作りについての言葉の解釈に違いがあるとどういうことになるだろうか委託する作業について委託する方が小さく捉え受託する方がそれを包含して大きく捉えている場合には問題が生じないか仮に問題が起きても小さいしかしこれが逆になると仕事が終わる頃に問題が発生する受託した側はある理解に基づいて作業を行い受託した作業を完成したと考えるしかし委託した側がその作業の範囲はもっと広いものと考えているとするとここに行き違いが発生するこのような問題の解決の方法はいろいろあるしかし一般にその仕事でお金を払う方つまり委託者側の方が受託者側より強い言い換えるとソフトウェア会社はこの場合不利な立場に立つことになりかねないこのようなことが繰り返しあるとソフトウェア産業の順調な発展がむずかしくなるこの委託者と受託者の間の問題発生を両者が共通の言葉を使うことによって回避しようとするものがこの規格の本来の目的である [JIS96] しかしこの規格がソフトウェア構築に関わる全ての作業を網羅していることから今では ISO のソフトウェアの関わる規格の核とでもいうような位置づけになっているプロセスの定義 111

ここでソフトウェアライフサイクルの次にあるプロセスという言葉を見ておきたいプロセスという言葉は最近いろんなところでたいへんよく使われているこの定義が開発のための CMMI(Capability Maturity Model Integration-DEV: 能力成熟度モデル統合 )v3 の文献にあるので

(Verification steps) 出力 (Outputs) 終了基準 (Exit criteria) CMMI のテキストで示されたプロセス定義はここまでであるしかし私はこれに手順書 (Script) を付け加えたいハンフリー博士が提唱している PSP(Personal 1 Software Process) に則って

2 ここでソフトウェアライフサイクルの次にあるプロセスという言葉を見ておきたいプロセスという言葉は最近いろんなところでたいへんよく使われているこの定義が開発のための CMMI(Capability Maturity Model Integration-DEV: 能力成熟度モデル統合 )v3 の文献にあるのでここで紹介しておきたい[CMM10a] プロセスとは単純に入力を出力に変換するものであり以下の属性を持っているとしている目的 (Purpose) 入力 (Inputs) 開始基準 (Entry criteria) 活動 (Activities) 役割 (Roles) 測定 (Measures) 検証のステップ (Verification steps) 出力 (Outputs) 終了基準 (Exit criteria) CMMI のテキストで示されたプロセス定義はここまでであるしかし私はこれに手順書 (Script) を付け加えたいハンフリー博士が提唱している PSP(Personal 1 Software Process) に則って PDCA サイクルを回してプロセスを改善する時の方法としてこのプロセスの内容を記述した手順書の改訂が必要になるからである手順書まで加味したプロセスの概念を図にしたものを図表 12-1 に示す入力目的開始基準手順書活動役割人組織検証のステップ測定終了基準出力図表 12-1 プロセスについての概念図 1 PSP については第 44 章で述べる 112

3 さらにここで ISO/IEC 12207:2008 で使われているプロセスを見ておきたいここではこのプロセスとアクティビティタスクなどとの関連を示すものとして図表 12-2 が示されている図表 12-2 は UML 方式で表示されているまず素直なケースではプロセスの下に 1 つ以上のアクティビティがありアクティビティの下のまた 1 つ以上のタスクがある 2 それ以外にプロセスは再帰的に定義されているつまりプロセスの下に別のプロセスがあることがありプロセスの上に別のプロセスがあることもあるこれが ISO/IEC 12207:2008 で使われているプロセスの位置づけである [JIS12a] 図表 12-2 ISO/IEC 12207:2008 におけるプロセスなど [JIS12a] ISO/IEC 12207:2008 の内容それでは ISO/IEC 12207:2008 の内容を見てみよう ISO/IEC 12207:2008 は大きく 3 つの部分に分かれているその 1 つをシステム関連プロセス他の 1 つをソフトウェア固有プロセスと呼ぶシステム関連プロセスは純粋なソフトウェアを作るプロセスではなくソフトウェアと一体となって両者でシステムを構成するハードウェアがある場合にそのハードウェアなどを構築するプロセス群である 3 2 タスクの下の注記はあることもないこともある 3 ハードウェアを作るためだけにシステム関連プロセスが使われる訳ではないすぐ後で述べるがここには取得プロセスと供給プロセスがあるこれらはハードウェアの取得と供給だ 113

それではソフトウェアライフサイクルプロセスの中になぜハードウェアを構築する部分があるのだろうか実は 1995 年版の ISO/IEC 12207 の中にもハードウェアに係わる部分があったその割合は微々たるものだったがそれでもソフトウェアライフサイクルの中に携帯電話のような組込みシステムを構築することが配慮されていた 4 その後 2002 年にシステムライフサイクル

4 それではソフトウェアライフサイクルプロセスの中になぜハードウェアを構築する部分があるのだろうか実は 1995 年版の ISO/IEC の中にもハードウェアに係わる部分があったその割合は微々たるものだったがそれでもソフトウェアライフサイクルの中に携帯電話のような組込みシステムを構築することが配慮されていた 4 その後 2002 年にシステムライフサイクルプロセスの規格が制定され本格的にシステムエンジニアリングへの対応が図られたその規格を ISO/IEC 15288:2002(JIS X 0170: 2004) と呼んでいたこの時点で ISO/IEC 12207:1995 の中にあるハードウェア対応の部分は不要になったがその状態が今回の 2008 年版発行まで継続していた図表 12-3 システム関連プロセス [JIS12a] この ISO/IEC 12207:2008 の発行と歩調を合わせて ISO/IEC 15288:2008( 日本国内の規程は JIS X 0170:2013) も発行された [JIS13b] この両者は整合性を保っておりハードウェアの部分はでソフトウェアの部分はでというようにそれぞれ規程を使い分けても作業に齟齬を来すことがないよう配慮されているしかし簡単なシステムを構築する場合に 2 つの規程を使い分けるということは煩雑であるできることなら 1 つだけで対応できるようにしたいその意味で今回もソフトウェアライフサイクルプロセスの中にハードウェア構築の部分が取り込まれているそれがシステム関連プロセスの部分であるけでなくソフトウェア製品やサービスの取得と供給にも使用される 4 最近の組込みシステムの伸びは著しい財務省が発表している貿易統計によると 2009 年の日本の製品輸出額は 54.2 兆円ありそのうちの 52.2% が組込みソフトウェアを組み込んだ製品である [METI16] まさにソフトウェアが外貨を稼いでいる時代になったといえる 114

5 図表 12-4 システム関連プロセスの各プロセスの内容 [JIS12a] プロセス名目的合意プロセス 2つの組織の間での合意を確立する取得プロセス取得者が表明したニーズを満たす製品及び / 又はサービスを取得する供給プロセス合意した要求事項に合致した製品又はサービスを取得者に提供する組織のプロジェクトイネーブリンプロジェクトを開始支援及び制御することによって製品又はサービスを取グプロセス得及び供給するための組織の能力を管理するライフサイクルモデル組織によって使われる方針ライフサイクルプロセスライフサイクルモデルと手管理プロセス順を定義し保守し可用性を保証するライフサイクル全般にわたって組織及びプロジェクトの目標を支援するためインフラストラクチャ管にイネーブリングするためのインフラストラクチャ及びサービスをプロジェクトに理プロセス提供するプロジェクトポートフォリ組織の経営的目標を満たすために必要充分かつ適切であるプロジェクトを開オ管理プロセス始し維持する組織に必要な人的資源を提供し事業ニーズに見合った能力を要員が維持で人的資源管理プロセスきるようにする製品サービス及びライフサイクルプロセスの実施が組織の品質目標に合致品質管理プロセスし顧客満足を達成することを保証するプロジェクトプロセスプロジェクトの形をした計画アセスメント及び制御に関係した作業を遂行するプロジェクト計画プロセ効率的で実行可能なプロジェクト計画を作成し伝達するスプロジェクトアセスメント及び制御プロセス意思決定プロセスリスク管理プロセス構成管理プロセス情報管理プロセス測定プロセステクニカルプロセス利害関係者要求定義プロセスシステム要求分析プロセスシステム方式設計プロセス実装プロセスシステム結合プロセスプロジェクトの状態を見定めプロジェクトを計画とスケジュールにしたがって予測された予算内でプロジェクトを遂行すること及びそれが技術目標を満足することを確実にする代替手段が存在する場合にプロジェクトの行動に最も有益な進路を選定するリスクを継続的に識別し分析し取り扱いをしそのリスクを監視するプロジェクト又はプロセスの全ての出力の完備性を確立し維持しかつ関係する当事者が利用できるようにするシステムのライフサイクルの期間中及び該当する場合にはシステムのライフサイクルの後に指定された当事者に関連するタイムリーな完全な妥当な及び必要な場合には機密の情報を提供する組織単位内で作成される作成物及び実施されたプロセスに関するデータを収集し分析し報告することそれらを通してプロセスの効果的管理を支援すること並びに成果物の品質を客観的に示すシステムに関する要求の定義からサービスを廃止するまでの活動のテクニカルな面の詳細を定義する定義された環境において利用者及び他の利害関係者が必要とするサービスを提供するシステムに対する要求事項を明らかにするする定義された利害関係者の要求事項をシステム設計に導くことになる望まれるシステムの技術的要求事項の集合へ変換するシステム要求事項のどれをシステム要素のどれに割り当てることが望ましいかを識別する指定されたシステム要素を実現するシステム設計及びシステム要求事項に表現された利害関係者の期待を満たす完全なシステムを作り出すためにシステム要素 ( ソフトウェア構成品目ハードウェア構成品目手作業及び必要に応じて他のシステム ) を結合するシステム適格性確認テ各システムの要求事項について実装の適合性がテストされシステムの納入ストプロセス準備ができていることを確実にするソフトウェア導入プロセス合意した要求事項を満たすソフトウェア製品を実環境に導入するソフトウェア受入れ支援プロセス製品が要求事項を満たしているという確信を取得者が持つことを助けるソフトウェア運用プロセス意図された環境でソフトウェア製品を運用しソフトウェア製品の顧客への支援を提供するソフトウェア保守プロセス納入されたソフトウェア製品に対して費用対効果の高い支援を提供するソフトウェア廃棄プロセスシステムのソフトウェア実体の存在を終了する 115

したがってシステム関連プロセスは基本的に ISO/IEC 15288:2008 で規定されている内容と同じである一部ソフトウェアとの整合性を取るために表現が変更されているところがある程度といわれているなお製品ベースで見るとシステムの一部にソフトウェアが位置していることから規程でも ISO/IEC 15288:2008 が上位にあり ISO/IEC 12207:2008

6 したがってシステム関連プロセスは基本的に ISO/IEC 15288:2008 で規定されている内容と同じである一部ソフトウェアとの整合性を取るために表現が変更されているところがある程度といわれているなお製品ベースで見るとシステムの一部にソフトウェアが位置していることから規程でも ISO/IEC 15288:2008 が上位にあり ISO/IEC 12207:2008 はその傘下に位置づけされているシステム関連プロセスの内容 ISO/IEC 12207:2008 のシステム関連プロセスには上位のプロセスが 4 つありその下位に 25 個のプロセスが位置づけされているそれらを図表 12-3 と 12-4 に示すソフトウェア固有プロセスの内容 ISO/IEC 12207:2008 のソフトウェア固有プロセスには上位のプロセスが 3 つありその下位に 17 個のプロセスが位置づけされているそれらを図表 12-5 と 12-6 に示す図表 12-5 ソフトウェア固有プロセス [JIS12a] 修整プロセスについて ISO/IEC 12207:2008 にはこれまでに述べた 2 つのプロセスに加えて 3 つ目の重要なプロセスとして修整プロセスがある修整プロセスは組織やプロジェクトの活動に合わせるために規程に手を入れてその内容を一部修正するためのものである 116

7 図表 12-6 ソフトウェア固有プロセスの各プロセスの内容 [JIS12a] プロセス名ソフトウェア実装プロセスソフトウェア要求事項分析プロセスソフトウェア方式設計プロセスソフトウェア詳細設計プロセス目的ソフトウェアの中に実装することになった仕様で指定されたシステム要素 ( ソフトウェア品目 ) を作り出す作業を明確にするシステムのソフトウェア要素の要求事項を確立する要求事項を実装しそれに対して検証できるソフトウェアの設計を提供する要求事項及びソフトウェア方式に対して実装し検証できコーディング及びテストを可能にするために充分に詳細である設計をソフトウェアのために提供するソフトウェア構築プロセソフトウェア設計を適切に反映した実行可能なソフトウェアユニットを作り出すスソフトウェア結合プロセソフトウェアユニット及び構成部品を組み合わせ結合されたソフトウェア品目スを作り出すソフトウェア適格性確結合されたソフトウェア製品がその定義された要求事項を満たすことを確認す認テストプロセスる特化したソフトウェアプロセスを実行するための活動の特定の絞り込んだ集合ソフトウェア支援プロセスを提供するソフトウェア文書化管プロセスによって作成されるソフトウェア情報の記録を作成し維持する理プロセスソフトウェア構成管理ププロセス又はプロジェクトのソフトウェア品目の完整性を確立し維持しさらにロセスそれらを関係当事者が利用できるようにするソフトウェア品質保証プ作業成果物及びプロセスがあらかじめ定義された条件と計画にしたがっていロセスることを保証するソフトウェア検証プロセプロセス又はプロジェクトのそれぞれの作業成果物及び / 又はソフトウェアスサービスが指定の要求事項を適切に反映していることを確認するソフトウェア妥当性確ソフトウェア作業成果物の特定の意図された用途に対する要求事項が満たさ認プロセスれていることを確認するソフトウェアレビュープ合意目標に対する進捗及び利用関係者を満足させる製品の開発を確実にすロセスるために実施が望ましいことについて利害関係者と共通理解を維持するソフトウェア監査プロセ選ばれた製品及びプロセスが該当する要求事項計画及び合意に対してス適合しているかどうかを独立に決定するソフトウェア問題解決発見された全ての問題を解決するために識別し分析し管理し制御する管理プロセスソフトウェア再利用プロセスプロジェクトの境界を越えてソフトウェア品目を再利用する組織の能力を支援するドメイン ( 領域 ) エンジニドメインモデルドメイン方式及びドメインのための資産を作成し維持するアリングプロセス再利用資産管理プロセ構想から廃止までの期間にわたって再利用資産の存続を管理するス再利用施策管理プロセ組織の再利用施策を計画し確立し管理し制御しさらに監視する併せてス再利用の機会を体系的に活用するその性格上規程は全ての活動についての最大公約数的なものにならざるを得ないしたがって行わなければならない / 行った方が良い活動に対して多くの場合不足している部分があり逆に組織やプロジェクトとして不要な部分がある 5 不足している箇所には必要なものを追加し不要な箇所は割愛するこれが修整の作業である組織やプロジェクトにとってその活動に過不足のない適切な規程を用意しておくことが望 5 例えばビジネス系の情報システムを構築する時にはハードウェアの設計や実装は必要ないしたがってビジネス系の情報システムを構築している企業やプロジェクトではハードウェアに係わる部分を必要とない 117

8 ましいその意味で修整は必要不可欠な作業である共通フレーム 2013 について日本ではソフトウェアライフサイクルプロセスを規定したものに ISO/IEC 12207: 2008 とそれを JIS 化した JIS X 0160:2012 に加えて共通フレーム 2013 と呼ばれる規程がある [IPA13a] 共通フレーム 2013 は JIS X 0160:2012 をベースにしそれに日本でのソフトウェアライフサイクルモデルという立場でいくつかの作業を追加して体系化したものである章末の付 1 に共通フレーム 2013 の内容を示すこの表で網掛けされた部分が共通フレーム 2013 で追加された部分である数え方が難しいが共通フレーム 2013 には上位のプロセスが 8 個ありその下位に 55 個のプロセスが用意されているアクティビティとタスク ISO/IEC 12207:2008 でも共通フレーム 2013 でもプロセスとはインプットをアウトプットに変換する相互に関連する又は相互に作用する一連の活動と定義されている [JIS13a] それではプロセスの下に位置しているアクティビティとタスクとは何だろうかアクティビティの定義はプロセスの構成要素で関連の強いタスクの集合でありタスクはプロセスの一つ以上の成果の達成に貢献するように意図された要求事項勧告又は許される行動とある [JIS13a] これではよく分からないので実例を示してみよう共通フレーム 2013 の中に要件定義プロセスというプロセスがあるこれを構成するアクティビティとタスクを以下に示す [IPA13a] 要件定義プロセスプロセス開始の準備要件定義作業の組み立て必要なプロセスの組込み要件合意及び承認ルールの決定要件定義環境の準備要件定義プロセス実施計画の作成利害関係者の識別利害関係者の識別要件の識別要件の抽出制約条件の定義代表的活動順序の定義利用者とシステム間の相互作用の識別システムの使用が周辺に及ぼす影響への対処 JIS X 0160:2012 と共通フレーム 2013 のどちらを使用するか JIS X 0160:2012( 元の規程は ISO/IEC 12207:2008) と共通フレーム 2013 はたいへ 118

9 ソフトウェア構築作業の将来最近ソフトウェア開発に関わる人たちの間で超高速開発という言葉が使われ話題になることがある超高速開発にはいくつかの方法と手段が提案されている中には人工知能 (AI) を使用したものもありその将来の活用が期待される [ICT14] 超高速開発は一言でいえば要件定義を行えば設計もプログラミングの必要とせずコンピュータが情報システムを生成する方式である 6 これが一層普及すれば情報システム構築のプロセスは大幅に変わることになるその日の到来が早いことを大いに期待したいキィワードソフトウェアライフサイクルプロセス PDCA サイクルアクティビティタスクシステム関連プロセスソフトウェア固有プロセスソフトウェアライフサイクルプロセスシステムライフサイクルプロセス共通フレーム 2013 修整プロセス超高速開発略語 CMMI:Capability Maturity Model Integration PSP:Personal Software Process 規格 ISO/IEC 12207:2008 JIS X 0160:2012 CMMI-DEV v3 ISO/IEC 15288:2008 JIS X 0170:2013 共通フレーム 2013 んよく似ているそれではどちらを使うのが適切なのだろうかそれぞれ考え方があり好みもあるだろうが私は日本国内で使用するのなら共通フレーム 2013 を使用することをお勧めする内容が日本の情報システム産業向けに改定されていて使いやすいことがその理由であるただしこの規程は日本国内でしか通用しないので海外でソフトウェアライフサイクルプロセスをベースにした話をするのであれば JIS X 0160:2012( 元の規程は ISO/IEC 12207: 2008) を使用せざるを得ないということになる参考文献とリンク先 [CMM10a] CMMI 成果物チーム開発のためのCMMI 1.3 版 CMMI-DEV, V1.23 CMU/SEI-2010-TR-033 ESC-TR より良い成果物のためのプロセス改善カーネギーメロン大学ソフトウェア工学研究所 2010 年この資料は次の URL からダウンロードできる ( 確認日 :2017 年 ( 平成 29 年 )1 月 25 日 ) [ICT14] 一般社団法人 ICT 経営パートナーズ協会著関隆明監修超高速開発が企業システムに革命を起こす日経 BP 社 2014 年 [IPA13a] 情報処理推進機構ソフトウェアエンジニアリングセンター編共通フレーム超高速開発については第 28 章で記述する 119

10 経営者業務部門が参画するシステム開発及び取引のためにソフトウェアライフサイクルプロセス共通フレーム 2013 オーム社平成 25 年. [ISO10a] ISO/IEC/IEEE, System and software engineering Vocabulary-ISO/IEC/IEEE 24765:2010(E), ISO/IEC, [JIS96] 日本工業標準調査会審議ソフトウェアライフサイクルプロセス JIS X (ISO/IEC 12207:1995) 日本規格協会平成 8 年. [JIS12a] 日本工業標準調査会審議ソフトウェアライフサイクルプロセス JIS X (ISO/IEC 12207:2008) 日本規格協会平成 24 年. [JIS13b] 日本工業標準調査会審議システムライフサイクルプロセス JIS X 0171:2013 (ISO/IEC 15288:2008) 日本規格協会平成 25 年. [METI16] 経済産業省商務情報政策局情報処理振興課 / 情報経済課組込みシステム基盤開発事業の概要平成 26 年 2 月 3 日. この資料は次の URL からダウンロードできる ( 確認日 :2017 年 ( 平成 29 年 )1 月 9 日 ) ou1_siryou5_3.pdf (2004 年 ( 平成 16 年 )8 月 1 日初稿作成 ) (2006 年 ( 平成 18 年 )8 月 9 日一部修正 ) (2007 年 ( 平成 19 年 )5 月 20 日追加 ) (2007 年 ( 平成 19 年 )9 月 17 日追加 ) (2008 年 ( 平成 20 年 )8 月 11 日一部修正 ) (2010 年 ( 平成 22 年 )7 月 16 日追加 ) (2014 年 ( 平成 26 年 )3 月 18 日大幅改定 ) (2016 年 ( 平成 28 年 )4 月 13 日一部修正 ) (2017 年 ( 平成 29 年 )1 月 9 日一部修正 ) 120

11 プロセス名合意プロセス取得プロセス供給プロセス付 1 共通フレーム 2013 の内容 ([IPA13a] より ) 合意契約内容の変更プロセステクニカルプロセス企画要件定義の視点企画プロセスシステム化構想の立案プロセスシステム化計画の立案プロセス要件定義プロセス開発保守の視点システム開発プロセスシステム開発プロセス開始の準備プロセスシステム要件定義プロセスシステム方式設計プロセス実装プロセスシステム結合プロセス目的 2 つの組織の間の合意を確立する取得者が表明したニーズを満たす製品及びサービスを得る合意した要件に合致した製品又はサービスを取得者に提供する取得者と供給者の二者間で締結した契約内容に影響を与える変更要求が生じた場合二者間で合意できる新たな契約内容を導く組織及びプロジェクトの担当部門が技術的な決定及び行動の結果生じる利益を最適化しリスクを軽減できるようにする活動を定義する経営事業の目的目標を達成するために必要なシステムに関係する要件の集合とシステム化の方針及びシステムを実現するための実施計画を得る経営上のニーズ課題を実現解決するために置かれた経営環境を踏まえて新たな業務の全体像とそれを実現するためのシステム化構想及び推進体制を立案するシステム化構想を実現するために運用や効果等の実現性を考慮したシステム化計画とプロジェクト計画を具体化し利害関係者の合意を得る定義された環境下において利用者及び他の利害関係者が必要とするサービスを提供できるシステムに対する要件を定義するシステムソフトウェア製品又はサービスを開発するシステム開発プロセスを成功裏に完了して所期のシステムを得るためにその準備を行う定義された利害関係者要件をシステム設計に導くことになる望まれるシステムの技術的要件の集合へ変換するシステム要件のどれをシステム方式のどれに割り当てることが望ましいかを識別する指定されたシステム要素を実現するシステム設計及びシステム要求事項に表現された利害関係者の期待を満たす完全なシステムを作り出すためにシステム要素 ( ソフトウェア構成品目ハードウェア構成品目手作業及び必要に応じて他のシステム ) を結合するシステム適格性確認テストプ各システムの要求事項について実装の適合性がテストされシステムロセスの納入準備ができていることを確実にするシステム導入プロセス合意した要求事項を満たすシステムを実環境に導入するシステム受入れ支援プロセスシステムが要求事項を満たしているという確信を取得者が持つことを助けるソフトウェア実装プロセスソフトウェア製品又はソフトウェアサービスとして実現される指定のシステム要素を作り出すソフトウェア実装プロセス開始ソフトウェア実装プロセスを成功裏に完了し所期のソフトウェア品目をの準備プロセス得るためにその準備を行うソフトウェア要件定義プロセスシステムのソフトウェア要素の要件を確立するソフトウェア方式設計プロセス要件を実装しそれに対して検証できるソフトウェアの設計を提供するソフトウェア要件及びソフトウェア方式に対して実装し検証できソフトウェア詳細設計プロセスコーディング及びテストを可能にするために充分に詳細である設計をソフトウェアのために提供するソフトウェア設計を適切に反映した実行可能なソフトウェアユニットを作りソフトウェア構築プロセス出すソフトウェア結合プロセスソフトウェアユニット及び構成部品を組み合わせて結合されたソフトウェア品目を作成するソフトウェア適格性確認テスト結合されたソフトウェア製品がその定義された要件を満たすことを確認プロセスするソフトウェア導入プロセス合意した要件を満たすソフトウェア製品を実環境に導入するソフトウェア受入れ支援プロセ製品が要件を満たしているという確信を取得者が持つことを助けるスハードウェア製品又はサービスとして実現される指定のシステム要素ハードウェア実装プロセスを作り出す納入されたソフトウェア及びソフトウェア製品に対して費用対効果が保守プロセス高い支援を提供する 121

12 運用サービスプロセス運用プロセス廃棄プロセスサービスマネジメントプロセス支援プロセス文書化管理プロセス品質保証プロセス検証プロセス妥当性確認プロセス共同レビュープロセス監査プロセス問題解決プロセスプロジェクトプロセスプロジェクトマネジメントの視点プロジェクト計画プロセスプロジェクトアセスメント及び制御プロセスプロジェクトサポートの視点意思決定管理プロセスリスク管理プロセス構成管理プロセスソフトウェア構成管理プロセス情報管理プロセス測定プロセス開発の終了したシステムソフトウェア製品サービスなどを稼働させて顧客への支援を提供する意図された環境でシステム及びソフトウェア製品を運用しシステム及びソフトウェア製品の顧客への支援を提供するシステム又はソフトウェア実体の存在を終了させる JIS Q に準拠したサービスマネジメントシステムを構築している組織がシステムやソフトウェア製品を運用することで顧客に IT サービスを提供するに当たりサービス提供者の活動と資源を指揮し管理するシステム開発プロセス又はソフトウェア実装プロセスを実行するための活動の特定の絞り込んだ集合を提供するプロセスによって作成されるシステム又はソフトウェア情報の記録を作成し維持する作業成果物及びプロセスがあらかじめ定義された条件及び計画に従っていることを保証するプロセス又はプロジェクトのそれぞれのシステムソフトウェア作業成果物及び / 又はソフトウェアサービスが指定の要件を適切に反映していることを確認するシステムソフトウェア又はサービスの作業成果物の特定の意図された用途に対する要件が満たされていることを確認する合意目標に対する進捗及び利害関係者を満足させる製品の開発を確実にするために実施が望ましいことについて利害関係者と共通理解を維持する選ばれた成果物又はプロセスが該当する要件計画及び合意に対して適合しているかどうかを独立に決定する発見された全ての問題を解決するために識別し分析し管理し制御するプロジェクト計画を確立して進展させ計画に対する実績及び進捗のアセスメント行いプロジェクトの実行を完了時まで制御する効果的で実行可能なプロジェクト計画を作成し伝達するプロジェクトの状態を見定めプロジェクトを計画及びスケジュールにしたがって予想された予算内で遂行するさらにそれが確実に技術目標を満足させるようにする特化した管理目標を実行するためのタスクの特化の絞り込んだ集合を提供し組織全体から単一のライフサイクルプロセス及びそのタスクにわたるそれぞれの局面での管理を行う代替手段が存在する場合にプロジェクトの行動に最も有益な進路を選定するリスクを継続的に識別し分析し取り扱いをしそのリスクを監視するプロジェクト又はプロセスの全ての出力の完備性を確立し維持しかつ関係する当事者が利用できるようにするプロセス又はプロジェクトのソフトウェア品目の完整性を確立し維持しさらにそれらを関係当事者が利用できるようにするシステムのライフサイクルの期間中及び該当する場合にはシステムのライフサイクルの後に指定された当事者に関連するタイムリーな完全な妥当な及び必要な場合には機密の情報を提供する組織単位内で作成される作成物及び実施されたプロセスに関するデータを収集し分析し報告することそれらを通してプロセスの効果的管理を支援すること並びに成果物の品質を客観的に示す 122

13 組織のプロジェクトイネーブリングプロセスライフサイクルモデル管理プロセスインフラストラクチャ管理プロセスプロジェクトポートフォリオ管理プロセス人的資源管理プロセス品質管理プロセス知識管理プロセスソフトウェア再利用プロセスドメイン ( 領域 ) エンジニアリングプロセス再利用資産管理プロセス再利用施策管理プロセスシステム監査プロセスプロセスビューユーザビリティプロセステーラリング ( 修整 ) プロセスプロジェクトの開始支援及び制御によって製品又はサ-ビスを取得及び供給するための組織の能力を管理するこの共通フレームの適用範囲に対して組織によって使われる方針ライフサイクルプロセスライフサイクルモデル及び手順を定義し保守し可用性を保証するライフサイクルにわたって組織及びプロジェクトの目標を支援するために組織及びプロジェクトが必要とするインフラストラクチャ及びサービスをプロジェクトに提供する組織の経営的目標を満たすために必要充分かつ適切であるプロジェクトを開始し維持する組織に必要な人的資源を提供し事業ニーズに見合った能力を要員が維持できるようにする製品サービス及びライフサイクルプロセスの実施が組織の品質目標に合致し顧客満足を達成することを保証する組織を通じて個人の知識情報及びスキルが集約され共有され再利用され改善されることを確実にするプロジェクト境界を越えてソフトウェア品目を再利用する組織の能力を支援するドメインモデルドメイン方式及びドメインのための資産を作成し維持する構想から廃止までの期間にわたって再利用資産の存続を管理する組織の再利用施策を計画し確立し管理し制御しさらに監視する併せて再利用の機会を体系的に活用する情報システムにまつわるリスクに対するコントロールが適切に整備運用されていることを担保し利害関係者に対する説明責任を果たす最適化支援及び教育作業生産性及び作業品質の j 向上人についての作業環境の改善及びシステムの利用者による拒絶の機会の減少を可能にするために利害関係者の関心事及びニーズへの配慮を確実にするこの共通フレームを種々の状態に対応させるためにプロセスを適応させる ( 網掛けされた部分は共通フレーム 2013 のために追加されたものであることを示す ) 123

14 124 第 12 章ソフトウェア開発のための作業

再利用アセスメント計画実行及び制御レビュー及び評価ソフトウェアの再利用を行う組織では再利用施策管理者という人が位置づけされることになっておりこのプロセスはその人が組織の中で再利用を実施するために行うべき作業を定義したものである再利用資産管理プロセスの目的は構想から廃止までの再利用資

再利用アセスメント計画実行及び制御レビュー及び評価ソフトウェアの再利用を行う組織では再利用施策管理者という人が位置づけされることになっておりこのプロセスはその人が組織の中で再利用を実施するために行うべき作業を定義したものである再利用資産管理プロセスの目的は構想から廃止までの再利用資第 35 章ソフトウェアの再利用ソフトウェアの再利用の定義 ISO と IEC それに IEEE が共同で作成した用語集 (Vocabulary) についての規格 1(ISO /IEC/IEEE 24765:2010) では再利用 (Reuse) は次のように定義されている [ISO10a] ( 翻訳は筆者 ) 1. 別の問題の解決の中でのある資産の使用 (IEEE Std 1517-1999

第５部 ソフトウェア・プロセス

第５部　ソフトウェア・プロセス