はじめにソフトウェアエンジニアリングとは 1. ソフトウェアの開発運用および保守におけるシステマティックでありディシプリン () に基づいた定量的なアプローチの適用である換言すればソフトウェアへの工学の適用である 2.1. で示したアプローチに関する研究であるとされている ()

Size: px

Start display at page:

Download "はじめにソフトウェアエンジニアリングとは 1. ソフトウェアの開発運用および保守におけるシステマティックでありディシプリン (*) に基づいた定量的なアプローチの適用である換言すればソフトウェアへの工学の適用である 2.1. で示したアプローチに関する研究であるとされている (*)"

こうごむこやま
5 years ago
Views:

1 Software Engineering Center Information-technology Promotion Agency, Japan 2011/07/22 財団法人計算科学振興財団ソフトウェアエンジニアリングセミナーソフトウェア開発の標準プロセス IPA ( 独立行政法人情報処理推進機構 ) ( ソフトウェアエンジニアリングセンター ) 研究員室谷隆 Copyright 2011 Information-technology Promotion Agency, Japan. All rights reserved. Center

2 はじめにソフトウェアエンジニアリングとは 1. ソフトウェアの開発運用および保守におけるシステマティックでありディシプリン (*) に基づいた定量的なアプローチの適用である換言すればソフトウェアへの工学の適用である 2.1. で示したアプローチに関する研究であるとされている (*) ディシプリン : 方法論に基いた教育訓練によって形成された規律つまり体系化しそれに従って作業しデータを収集しフィードバックすること Abran, Alain (eds.), SWEBOK; Guide to the Body of Knowledge, 2004 Version, IEEE Computer Society,2004 Center 2

3 目次第 1 部ソフトウェア開発の標準プロセス ~ 共通フレーム 2007 の概要 ~ 第 2 部日本独自のプロセス拡張のねらい ~ 超上流の重視超上流とはなにか ~ Center 3

4 第 1 部ソフトウェア開発の標準プロセス ~ 共通フレーム 2007 の概要 ~ 1. 共通フレームとは 2. なぜプロセスが重要なのか? 3. 共通フレームの特徴 4. 共通フレームのプロセス体系 5. 共通フレームの要素と階層 6. 共通フレームとガイダンスの見方 7. 規定例要件定義プロセス 8. 修整 ( テーラリング ) の適用について 9. テーラリング方法 Center 4

5 1. 共通フレームとは (1/3) 共通フレームとはソフトウェアの構想から開発運用保守廃棄に至るまでのライフサイクルを通じて必要な作業項目役割等を包括的に規定した共通の枠組み ( 1) 何を実施するべきかが記述されている ITシステム開発の作業規定 ( プロセス ) であるその目的は日本においてソフトウェア開発に関係する人々 ( 利害関係者 ) が同じ言葉で話すことが出来るようにするため ( 2) ( 1) 歴史的には 1994 年に共通フレーム 94 が発表され 1998 年の共通フレーム 98(SLCP-JCF98) を経て 2007 年 10 月に共通フレーム 2007(SLCP-JCF2007) ( 第 1 版 ) が刊行されたまた第 2 版が 2009 年 10 月 1 日に発行された ( 2) より詳しい目的背景 ( 共通フレームの必要性 ) が共通フレーム 2007 ( 第 2 版 ) の p.3~13 で説明されている Center 5

6 1. 共通フレームとは (2/3) その背景は ( 主として ) (1) 利害関係者同士の認識のズレによるトラブルの発生がある (2) 取引 ( 主として二者間契約 ) における作業項目役割分担等が明確化でなく取引の適正化がされていないその作成者はユーザ企業ベンダ企業 IPA/ 大学経済産業省からなる開発プロセス共有化部会 (2007 年 10 月当時 ) である ( 1) ( 1) 共通フレーム 2007 ( 第 2 版 ) の p.326 ( 第 1 版編著者 ) を参照 Center 6

7 1. 共通フレームとは (3/3) ソフトウェア開発方法論との関係はウォーターフォールスパイラルプロトタイプアジャイル系すべての開発方法論に共通したもの JIS X 0160(ISO/IEC12207) との関係は (1) 共通フレームは JIS X 0160 を逐次参照している (JIS X 0160 を包含する ) (2)IPA/ の立場としては共通フレームの参照 / 利用を推進している ( 1) ( 1) 経済産業省を始めとして官公庁でも JIS X 0160 よりも共通フレームを参照するよう啓蒙しているまた共通フレームの作成者 ( 企業や諸機関に所属する人々 ) 自身が中心となって例えば顧客向け講演会等で言及しその普及 / 啓蒙に努めている Center 7

8 参考共通フレーム 2007 ( 第 1 版, 第 2 版 ) の位置づけソフトウェアライフサイクルプロセス ISO/IEC 12207:1995 JIS 化 X 共通フレーム98 (1998 年 ) 共通フレーム 2007 ( 第 1 版, 07 年 10 月 ) 超上流の本 ISO 追補 1 (2002) ISO 追補 2 (2004) 主に ISO/IEC15504 で使用するフロセスを定義追補 1 2 の JIS 原案 JIS X 0160:2007 追補 1(ISO 追補 1,2 を含む ) 共通フレーム 2007 ( 第 2 版, 09 年 10 月 ) 12207:2008 JIS 化最新版 (2011 年度 ) 共通フレーム 201X システムライフサイクルプロセス ISO/IEC JIS 化 15288:2002 X0170: :2008 JIS 化最新版 2012 年度予定 ITIL PMBOK BABOK などのスタンダード実現済み取組み中未実現 Center 8

9 2. なぜプロセスが重要なのか?(1/2) プロダクトの品質はプロセスの品質から ( 工学 ( エンジニアリング ) の基本 ) プロセス : インプットをアウトプットに変換する, 相互に関連する又は相互に作用する一連の活動 (JIS Q 9000:2006)( 処理する加工する手を加える ) 活動を役割の観点でまとめている例開発プロセス運用プロセス保守プロセス What to do( 何をするか ) であり How to do( どのようにするか ) は決めていない Center 9

10 2. なぜプロセスが重要なのか?(2/2) 組織が提供する製品 ( サービス ) の品質向上や経営環境の変化に応じた適正価格対応などの面からプロセスの確立標準化及び改善が重要なためもし組織のプロセスが確立されていなければどうなる? (1) 製品 ( サービス ) の品質 (Quality) が安定しない (2) 納期 (Delivery) が不確実となる ( 納期を必ずしも守れない ) (3) 教育訓練の標準化も図れない ( 作業手順や方法がバラバラ ) (4) プロセスの確立や標準化が図れないため ITによるシステム化が難しい (5) コスト (Cost) は (1)~(4) の結果として増大する組織がその顧客に提供する製品 ( サービス ) の品質を維持しまたは向上させていくためには ( 顧客満足度の獲得 ) 組織の活動基盤となるプロセスの確立が重要である Center 10

11 3. 共通フレームの特徴 (1) 超上流の重視 ( 1) 左記 1 は第 2 版で明記されたがその考え方自体は第 1 版にも含まれていた ( 第 2 版で明確化したということ ) (2) モジュール性の採用 (3) 責任の明確化 (4) 責任範囲の明確化 (5) 工程時間からの独立性 (6) 開発モデル技法ツールからの独立性 (7) ソフトウェアを中心としたシステム関連作業までを包含 (8) システムライフサイクルプロセスとの整合性 (9) 文書の種類書式を規定しない (10) 修整 ( テーラリング ) の採用なお後述するが超上流の範囲は企画プロセスと要件定義プロセスからなる ( 2) 上記 (1)~(10) の詳細説明については共通フレーム 2007 ( 第 2 版 ) の p.21~29 を参照なおプロセスを修整 ( テーラリング ) する上で上記 (5)(6)(9) を強く認識しておく必要がある Center 11

12 4. 共通フレームのプロセス体系主ライフサイクルプロセス契約と合意の視点取得プロセス供給プロセス契約の変更管理プロセス支援ライフサイクルプロセス文書化プロセス構成管理プロセス品質管理の視点品質保証プロセス検証プロセス企画と要件定義の視点エンジニアリングの視点運用の視点妥当性確認プロセス組織に関するライフサイクルプロセス管理プロセス企画プロセス要件定義プロセス環境整備プロセス改善プロセス開発プロセス保守プロセス人的資源プロセス資産管理プロセス運用プロセス再利用施策管理プロセスドメイン技術プロセス共同レビュープロセス監査プロセス問題解決プロセスユーザビリティ ( 使用性向上 ) プロセスシステム監査の視点システム監査プロセス共通フレームの修整修整プロセス : 規格部分 : 共通フレームで拡張した部分 : 追補で変更, 追加された部分 ( 1) 上記の図は共通フレーム 2007 ( 第 2 版 ) の p.38 に掲載 Center 12

13 5. 共通フレームの要素と階層次の図のように 4 つの要素が階層化されているプロセスアクティビティタスクリスト ( 例示 ) リストリスト目的および成果アクティビティタスクリストアクティビティタスクリストプロセスとはシステム開発作業を役割の観点でまとめたもの ( 1) アクティビティとは相関の強いタスクをまとめたタスクの集合のこと ( 1) タスクとはアクティビティを構成する個々の作業のこと ( 1) リストとはタスクを構成する要素のことなお JIS 規格でも共通フレームでもリストは例示として取り扱う ( 1) 上記の図は共通フレーム 2007 ( 第 2 版 ) の p.39 に掲載またプロセスアクティビティタスクの規格上の定義については共通フレーム 2007 ( 第 2 版 ) の p.38 を参照 Center 13

14 6. 共通フレームとガイダンスの見方 ( 本体の形式 ) システム適格性確認テストの準備システムの適格性確認要求事項ごとに, システム適格性確認テストを行うため, 一連のテスト, テストケース ( 入力, 出力及びテスト準備 ) 及びテスト手順を作成し, 文書化する開発者は, 結合したシステムがシステム適格性確認テストを実施できる状態にあることを確認するテスト実施にあたって各種マスタファイルのデータ, トランザクションデータを作成し, テスト環境に登録するガイダンス : データは本稼働で用いるデータにできる限り近いものを設定する現行システムのデータが存在する場合は, セキュリティを考慮し移行して利用する ( 青色の囲み ) 共通フレーム定義体を表す ( 文字種 ) 国際標準 : 太字国際標準の追補 : 太字 / 斜体国内での追加部分 : 細字 ( ガイダンス ) 国内で追加した解説を表す国際標準との差異を明示している ( 2) ( 1) 上記の見方は共通フレーム 2007 ( 第 2 版 ) の p.77 に掲載 ( 2) 文字種について書籍上では太字はゴシック体に細字は明朝体による表示となっている Center 14

15 7. 規定例要件定義プロセス (1/2) 目的 : 要件定義プロセスの目的は, 新たに構築する ( あるいは再構築する ) 業務, システムの仕様を明確化し, それをベースにシステム化範囲とその機能を具体的に明示することであるまた, 関連する組織およびシステムに対する制約条件を明確にし定義された内容について取得者側の利害関係者間で合意することである ( 1) ここで示す規定例は第 2 版に基づく成果 : 要件定義プロセスの実施に成功すると次の状態になる取得者側の利害関係者間で (1) 対象システムを含む業務, 組織に関する要件が定義され, かつ合意される (2) システムに対する要件及び制約事項が定義され, かつ合意される (3) 定義された要件と, プロセスの入力となったニーズとの整合性が保たれる ( 2) 成果とはプロセスの実施が成功した状態のことをいう Center 15

16 7. 規定例要件定義プロセス (2/2) アクティビティ一覧このプロセスは, 次のアクティビティからなる (1) プロセス開始の準備 (2) 利害関係者要件の定義 (3) 利害関係者要件の確認業務要件の定義要件定義者は, 新しい業務のあり方や運用をまとめた上で, 業務上実現すべき要件を明らかにする業務要件には例えば次のようなものを記述する (a) 業務内容 ( 手順, 入出力情報, 組織, 責任, 権限など ) (b) 業務特性 ( ルール, 制約など ) (c) 業務用語 (d) 外部環境と業務の関係, 授受する情報プロセス開始の準備要件定義作業の組立て必要な支援プロセスの組込み利害関係者の定義と役割の確認要件合意及び承認ルールの決定要件定義環境の準備要件定義プロセス実施計画の作成利害関係者要件の定義利害関係者のニーズの識別と制約事項の定義業務要件の定義組織及び業務環境要件の具体化機能要件の定義非機能要件の定義スケジュールに関する要件の定義実現可能性とリスクの検討利害関係者要件の確認要件の合意と承認要件変更ルールの決定リストとしての例示 Center 16

17 8. 修整 ( テーラリング ) の適用について (1/3) 第 1 レベル第 2 レベル第 3 レベル修整修整修整特性別 ( 領域別 ) 標準共通フレーム ( 規格を含む ) 組織 ( 企業 ) 標準例 ) 事務処理系, 制御系など技法ツール例 )DOA,OO,RAD 修整 ( テーラリング ) とは共通フレームをそのまま適用するのではなく組織 ( 企業 ) やプロジェクトの特性 ( 例えば開発モデル ) に合わせて共通フレームで規定されているプロセス / アクティビティ / タスクを取捨選択したり繰り返し実行できるように又は複数を一つに括って実行できるように組み替えたりする作業をいう第 4 レベルプロジェクト標準 ( 注 1) DOA : データ中心のアプローチ ( 注 2) OO : オブジェクト指向の方法論, 技法など ( 注 3) RAD : 短期間アプリケーション開発技法この修整 ( テーラリング ) プロセスが共通フレームに含まれていることによって共通フレームの適用が非常に柔軟なものとなる ( 1) 上記の図は共通フレーム 2007 ( 第 2 版 ) の p.32 に掲載 Center 17

18 8. 修整 ( テーラリング ) の適用について (2/3) テーラリングのポイント (1) 共通フレームに書いてあることをすべてそのまま実行しなければならないということではない ( 1) 共通フレーム 2007 ( 第 2 版 ) の p.268~269 参照 (2) 共通フレームに書いてあることを妥当と判断した場合には省略してもよい ( 組織 ( 企業 ) 標準やプロジェクト標準に加えなくてもよいということ ) (3) 共通フレームに書いていないことを組織 ( 企業 ) 標準やプロジェクト標準に追加してもよい組織やプロジェクトの特性 ( 例えば二者間契約の内容もその一つ ) に合わせてできるだけ最適と思われる作業の組み立て ( プロセス設計 ) を行うために必要な活動が修整 ( テーラリング ) である修整であり修正ではない! Center 18

19 8. 修整 ( テーラリング ) の適用について (3/3) もし修整 ( テーラリング ) をしなければどうなるのか? ( 例 ) 小規模プロジェクトにとって冗長的な作業項目が含まれ生産性が低下する安全性が特に求められるシステムを構築する場合は品質保証活動 ( レビュー / 検証 / 妥当性確認 / 監査など ) が不足することとなりシステムの信頼性について確実な確信が持てなくなるだからこそ組織やプロジェクトの特性に合わせ適切な修整 ( テーラリング ) が必要となる! Center 19

20 9. テーラリング方法 (1/3) (1) 作業工程を定義する時間軸 ( 管理の区切り ) を取り入れて組織やプロジェクトの作業に必要なプロセスアクティビティタスクを時間軸にマッピングして工程定義を行う他のプロセスアクティビティタスクとの関連を時間軸 (PERT 図など ) で表現する例えば運用プロセスの移行準備作業は開発工程が終了した後の運用工程でから始めるのではなく開発工程内で実施する各プロセスにはそれぞれプロセス開始の準備というアクティビティが定義されているので参照されたい Center 20

21 9. テーラリング方法 (2/3) (2) 開発モデルを選択する開発モデルに依存していないためプロジェクトの特性に応じた開発モデルを選択し共通フレームにあるタスクを組み立てる例えばプロジェクト全体ではウォーターフォールモデルを採用するが企画要件定義段階では繰り返し型や一部プロトタイピング型の開発モデルを使ってシステム化の実現性を調査する開発モデルが異なっていても実施するタスクは同じであるどの時点でどう実施するのかの違いである Center 21

22 9. テーラリング方法 (3/3) (3) プロセスの利用者を具体化する共通フレームは各プロセスの実施をどういった立場や資質の人間がなすべきかを適用主体者として定義している実際の利用ではこれを参考に組織から利用者を選定する必要がある例えば企画プロセスの利用者は企画者であるが実際の組織に当てはめると業務部門であったり企画部門であったりする誰の責任で実施すべきかどのタスクを誰がいつ実施すべきかを組織プロジェクト開発モデルの特性に合わせる Center 22

23 第 1 部終わり Center 23

24 第 2 部日本独自のプロセス拡張のねらい ~ 超上流の重視超上流とは ~ 1. プロセス拡張のねらい 2. 企画プロセスと要件定義プロセス 3. 超上流とは? 4. もし超上流を軽視したら? 5. 超上流でのトラブルの要因は? 6. 共通フレームに含まれている主な考え方 Center 24

25 1. プロセス拡張のねらい IT システムは事業 ( ビジネス ) 又は業務で使われるために開発される事業 / 業務における利用目的を明らかにしその利用目的に応じてシステムに対する要求事項を定義することが非常に重要であるここを疎かにしてしまうと利用目的が曖昧となる結果使い勝手の悪いシステムや利用されないシステム等が出来上がってしまう恐れがある共通フレームはこの考えを導入した事業 ( ビジネス ) 事業又は業務レベル全体におけるシステム利用 ( 人による活動も含む ) に対する要求事項を明確に定義する業務システムシステム (HW+SW) に対する要求事項を定義するソフトウェアソフトウェアに対する要求事項を定義する Center 25

26 2. 企画プロセスと要件定義プロセス開発に入る前の要求品質の確保企画プロセスシステム化の方向性システム化計画要件定義プロセス開発プロセスシステムは事業 ( ビジネス ) を実現するために開発されるすなわち開発に入る前の要求品質を確保することが重要になってくるこのため超上流と呼んでいる企画要件定義のプロセスが追加されたのである Center 26

27 3. 超上流とは? 共通フレーム 2007 ( 第 1 版 ) の著編者はその発行前に以下の書籍を刊行している経営者が参画する要求品質の確保 ~ 超上流から攻める IT 化の勘どころ ~ ( 第 1 版 :2005 年第 2 版 :2006 年 ) これ以降本資料では超上流の本と呼ぶこの本のポイント 1 超上流の重視を説いている 2 経営者の参画を ( 経営者としての役割があると ) 説いている 3 原理原則 17 ヶ条の活用による問題解決を提唱している Center 27

28 (ビジネス)3. 超上流とは? 経営戦略経営評価企画システム化の方向性システム化計画評価超上流プロセス要件定義の方向性投資効果はあるか? 事要求は正しかったか? 運用テストシステム要件定義ソフトウェア要件定義仕様どおりか? プログラミングシステム適各性確認テストソフトウェア適格性確認テスト業務システムソフトウェア業 Center 28

29 4. もし超上流を軽視したら? もし超上流を軽視したらどうなる? システム開発における手戻り発生コスト増加などのリスク [ 可能性としての例示 ] 契約変更 ( または追加契約締結 ) プロジェクトの赤字 ( 予想 ) トラブル発生社会的な悪影響要因? ( 次ページ ) 訴訟等 Center 29

30 5. 超上流でのトラブルの要因は? (1) システム化の方針目的があいまいであるまたは周知徹底されていない (2) 要件が固まらない要件定義書が作成されない実現可能性について十分に検討されていない要件について合意されていない (3) あいまいな見積りのまま開発段階に入ってしまい実際の開発規模にズレが生じる ( 大概は規模が増大する ) また要件 ( 機能等 ) が膨らむ (4) 要件が確定しないのに次工程に進んでしまうあるいは発注者の合意や承認を取らずに次工程に進んでしまう Center 30

31 6. 共通フレームに含まれている主な考え方 (1) 利害関係者の役割と責任分担の明確化を提唱 (2) 多段階の見積り方式を提唱 (3) V 字モデルの採用を提唱 (4) 超上流における準委任契約の採用を提唱 (5) 要件の合意及び変更ルールの事前確立を提唱 (6) 非機能要件の重要性を認識することを提唱 (7) 運用保守を含めたSLCPを考えることを提唱 Center 31

32 1) 利害関係者の役割と責任分担の明確化を提唱参照先超上流の本 :p.37 の 3.2(1) 項 p.41 の 4.1 共通フレーム ( 第 2 版 ):p.5 の第 1 部 2.(1) 項 p.8 の同 (3) 項 p.22 の第 2 部 5.1(4) 項補足説明集の 1.1 及び 1.2 事業要件業務要件システム要件を定義できるのはそれぞれ経営層業務部門情報システム部門であるそれぞれが責任をもって自らの役割を果たすことで要件を適切に定義できる部署等 / 役割 ( ロール ) 社長経営層担当役員部門長業務推進担当業務部門システム推進担当関連会社部門長情報システムシステム開発担当部門システム子会社元請けベンダ事業要件定義要件の定義内容業務要件定義システム要件定義ベンダアウトソーササブベンダ Center 32

33 (2) 多段階の見積り方式を提唱参照先超上流の本 :p.38 の 3.2(2) 項原理原則 15 共通フレーム ( 第 2 版 ):p.9 の第 1 部 2.(6) 項わずかな情報で見積ること自体リスクが高いそれ故それだけでプロジェクトの目標としてはならない規模不確定要素が多い中での見積りを, プロジェクトの目標値として設定すべきではないあいまいさが多く残る段階の見積りを, より明確になった段階で, 再見積りできるルールづくり等が, プロジェクト成功の鍵となる誤差最終的な規模わずかな情報 / 情報の充実 / 高いリスク低いリスクシステム化の方向性システム化計画要件定義設計製作時間仮試算試算概算確定 BOOKS 経営者が参画する要求品質の確保 ~ 超上流から攻める IT 化の勘どころ ~ ( 第 2 版 ) より引用一部改修 Center 33

34 (3) V 字モデルの採用を提唱参照先超上流の本 :p.24 の図 2.3 共通フレーム ( 第 2 版 ):p.22 の図 2-2 設計 ( 品質の埋め込みプロセス ) とテスト ( 品質の検証プロセス ) とを対応させることによりプロダクト品質を確保するシステム化の方向性システム化計画要件定義システム要件定義システムレベルの設計システム方式設計運用評価運用テストトシステムテストシステムテストシステムレベルのテストシステムシステム結合結合ソフトウェア設計ソフトウェア設計ソフトウェアソフトテストテストシス業事プログラミングソフトウェアテム務業 Center 34

35 (4) 超上流における準委任契約の採用を提唱参照先経済産業省情報システムの信頼性向上のための取引慣行契約に関する研究会報告書 ~ 情報システムモデル取引契約書 ~ ( 2007 年 4 月 13 日公表 ) 共通フレーム ( 第 2 版 ):p.9 の第 1 部 2.(5) 項 p.20 の ( 注 ) サービスメニューの項超上流は基本的にはユーザ責任であるためベンダにとって準委任契約とするのが合理的である ( もし請負契約にするとユーザの事情に大きく影響されるためリスクが大きい ) 例超上流準委任ならば運用テスト準委任にソフトウェア開発請負システム化の方向性システム化計画システムレベルの設計要件定義システム要件定義準委任に! 準委任のときシステム方式設計ソフトウェア設計ソフトウェア設計プログラミングソフトウェアソフトテストテストソフトウェア運用テストトシステムテストシステムテストシステムシステム結合結合運用評価システムシステムレベルのテスト業務事業 Center 35

36 (5) 要件の合意及び変更ルールの事前確立を提唱参照先超上流の本 :p.39 の 3.2(4) 項共通フレーム ( 第 2 版 ):p.8 の第 1 部 2.(4) 項 p.10 の同 (7) 項 p.35 の第 2 部 5.4.2(1)(c) 項ソフトウェア開発においては時の経過に伴って要件は変わるものでありユーザとベンダとが事前にルールを策定し合意 ( 確定 ) しておかないといざトラブルが発生した時に速やかな対応が取れない出所超上流の本 p.31 より Center 36

37 (6) 非機能要件の重要性を認識することを提唱参照先超上流の本 :p.11 の 1.3(3)2 項 p.39 の 3.2(3) 項共通フレーム ( 第 2 版 ):p.113 の第 3 部 ( 非機能要件の定義 ) とそのガイダンス運用テストの段階に至って問題をもたらす要因は機能要件のみならずむしろ深刻な事態になりがちな非機能要件の方であるため早い段階で非機能要件の重要性を認識し何かしらの対応策を講じることが望ましい機能要件とはシステムに実装する機能に関する要件のこと非機能要件とは運用要件移行要件性能要件セキュリティ機密情報保護対策など機能要件以外の要件のこと出所超上流の本 p.43 より注意業務部門 ( システムの利用部門等 ) にとっては業務要件こそが重要であるなお業務要件に機能要件非機能要件も含まれる ( 業務要件については共通フレーム ( 第 2 版 ):p.112 の第 3 部参照 ) Center 37

38 (7) 運用保守を含めた SLCP を考えることを提唱参照先超上流の本 : 原理原則 6 7 共通フレーム ( 第 2 版 ):p.11~12 の第 1 部 2.(8)(9)(12) 項 ( 注 ) SLCP : システムライフサイクルプロセスの略記またソフトウェアライフサイクルプロセスの略記でもあるシステムは生きもの作って終わりではない顧客との取引が継続する限りまたは事業や業務が続く限り (IT システムを必要とする限り ) システムライフサイクル全般に目配せしてシステム化計画 ( 企画 ) や要件定義を行うことが結局は適正コストで使えるシステムを実現できる企画プロセス要件定義プロセス開発プロセス運用プロセス保守プロセス Center 38

39 第 2 部終わり Center 39

40 本セミナーのまとめ (1) 共通フレーム 2007 の概要を説明しました ( 例 ) 共通フレーム 2007 は例えば情報処理技術者試験でも基礎知識として取り入れられています (2) システム開発又は保守などの組織 ( 企業 ) 標準を整備する上で IT 専門家の見識が詰まった共通フレーム 2007 を参照すると有用です (3) システムを調達する場合特定ベンダの開発方法論に依存していない共通フレーム 2007 の言葉を使用し RFP( 提案依頼書 ) や調達仕様書等を記述することによって中立性を確保することができます (4) 超上流の本を一読して頂きご活用することを強く推奨します共通フレーム 2007 に込められた考え ( ねらい ) を理解する上で大変役立つと共に IT 化の勘どころとして単独に使用しても有用です Center 40

41 ご清聴ありがとうございました Center 41

Software Engineering Center Information-technology Promotion Agency, Japan 2012/8/25 第 2 回 ITC 近畿会セミナー IPA 共催セミナー (2/2) 第 1 部共通フレーム 2007 概要とプロセス改善共通

Software Engineering Center Information-technology Promotion Agency, Japan 2012/8/25 第 2 回 ITC 近畿会セミナー IPA 共催セミナー (2/2) 第 1 部共通フレーム 2007 概要とプロセス改善共通フレーム 2007 概要独立行政法人情報処理推進機構 (IPA) 技術本部ソフトウェアエンジニアリング