ソフトウェア制作論 平成30年12月12日

第12章 ソフトウェアライフサイクルと調達、システム開発 第12章　ソフトウェアライフサイクルと調達、システム開発 ＜学習内容＞ ソフトウェアライフサイクル 企画プロセス 要件定義プロセス 調達 開発（「システム開発＋ソフトウェア実装」）プロセス ソフトウェアの品質管理 ＜目的＞ 情報システムを導入する際の流れを把握する。今回は、その中の企画プロ セス、要件定義プロセス、調達、開発プロセスで行うべき内容を理解する。

１．ソフトウェアライフサイクル SLCP（Software Life Cycle Process）とは？ 　ソフトウェアの開発から廃棄までの一連のライフサイクル*)のこと。 　＊）商品が市場に現れてから姿を消すまでの流れを表すもの。（ASCII.jpデジタル用語 辞典） ライフサイクルの中で、ソフトウェアを発注する際など、取得者（依 頼元）と供給者（発注先）とで用語の意味の取り違え等がよく発生し、 システム開発に影響を与えた。 ライフサイクルに関する問題多発 共通の物差しとなるガイドラインが策定された。 ＜共通フレーム2013＞ 基礎課題12-1 企画 プロセス 要件定義 プロセス システム開発プロセス ソフトウェア実装 プロセス 保守 プロセス

２．企画プロセス システム化構想の立案 システム化計画の立案 　経営上のニーズやシステム化する業務の課題を分析・確認してシステ ム化の方針を立案する。 システム化計画の立案 　業務のシステム化にあたり、開発スケジュール、開発体制、概算コス ト、費用対効果、リスク分析などを行う。システム化の全体像を明ら かにして、情報システムの有効性や投資効果を明確にする。 重要な用語　TCO（Total Cost of Ownership） ハードウェア及びソフトウェアの導入から運用管理まで含んだ総コストを意味する。削減は、初期コスト削減と運用コスト削減の2通り。 基礎課題12-2、基礎課題12-3、基礎課題12-4

採算性 【基礎課題12-5】 （平成22年度春） 類似：応用課題12-A 【基礎課題12-5】　（平成22年度春） 導入を検討している機械について採算性の評価を行う。評価には予想 される費用と、期待される利益を対比する方法を用いる。採算評価の 期間は10年間であり、導入によって、毎年110万円の利益を得られる。 また、保守費用として毎年取得費用の1%が発生する。この機械の取得 費用が何万円未満であれば、採算が取れるか。 　ア　1,000　　　　イ　1,100　　　　ウ　1,111　　　　エ　1,222 類似：応用課題12-A 利益 = 110(万円)×10(年）= 1,100(万円） 採算が取れるためには 費用＜利益　でなければならない。 1.1x ＜ 1100より x ＜ 1000(万円） 取得費用をX(万円）とすると、 費用 = 取得費用 + 保守費用 = x + x×0.01×10(年） = 1.1x (万円）

３．要件定義プロセス 利用者（現場）の視点から考える 業務要件定義 機能要件定義 非機能要件定義 利用者のニーズを整理して、システムに対する要件を明確化し、シス テム化の範囲とその機能を定義する。次の3種類に分類される。 業務要件定義 　業務上実現すべき要件（業務の手順や入出力情報、ルール、制約な ど）。 機能要件定義 　業務要件を実現するために必要なシステムの機能に関する要件 非機能要件定義 　機能要件以外（性能、信頼性、セキュリティなど）。 利用者（現場）の視点から考える 基礎課題12-6、基礎課題12-7、基礎課題12-8

４．調達 参考資料 ベンダ企業を選定し、システム開発を依頼する。 ＜ベンダ企業との契約締結までの流れ＞ ① ② 依頼元 ベンダ企業 企画 プロセス 要件定義 システム開発プロセス ソフトウェア実装 保守 ベンダ企業を選定し、システム開発を依頼する。 ＜ベンダ企業との契約締結までの流れ＞ ① ② 情報提供依頼 提案依頼書の作成と配布 依頼元 ベンダ企業 ベンダ企業 依頼元 情報提供 提案書・見積書の作成と提案 ③ ④ 調達先の選定 ベンダ企業 依頼元 提案内容の比較評価 依頼元

用語の確認 情報提供依頼（RFI：Request For Information） 提案依頼書の作成に先立って、考えうる手段や技術動向に関する情報 を集めるために、ベンダ企業に対しシステム化の目的や業務概要を明 示し、情報提供を依頼すること。 提案依頼書（RFP：Request For Proposal） ベンダ企業に対し、導入システムの基本方針や提案依頼事項、調達条 件などを明示し、提案書の提出を依頼するための文書。 秘密保持契約（NDA：Non Disclosure Agreement) システム開発などを他社に委託する際に、お互いに知り得た相手方の 秘密情報を漏らさないようにする契約。 基礎課題12-9、基礎課題12-10、基礎課題12-11

５．開発（「システム開発＋ソフトウェア実装」）プロセス 企画 プロセス 要件定義 システム開発プロセス ソフトウェア実装 保守 順次次の工程に引き継がれる システム要件定義 システム方式設計 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 ソフトウェアコード構築 システム要件定義書 システム方式設計書 ソフトウェア要件定義書 ソフトウェア方式設計書 ソフトウェア詳細設計書

5-1．システム要件定義＋システム方式設計 システム要件定義（要件定義） システム方式設計（外部設計） システム化する業務や対象範囲を明確にする。 システムに必要な機能や性能を決定する。 システム要件定義書を作成する。 システム方式設計（外部設計） システム要件定義書を基に、全ての要件をハードウェア で実現するもの、ソフトウェアで実現するもの、手作業 で行うものに振り分ける。→システム構成を決定する。 システム方式設計書を作成する。 システム要件は開発者側の視点から作成する。 こちらは利用者側の視点から作成する。 業務要件、機能要件等との違いは？ システム要件定義 システム方式設計 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 ソフトウェアコード構築 システム = ソフトウェア＋ハードウェア＋手作業 基礎課題12-12～基礎課題12-17

5-2．ソフトウェア要件定義＋ソフトウェア方式設計 システム = ソフトウェア＋ハードウェア＋手作業 システム要件定義 システム方式設計 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 ソフトウェアコード構築 ソフトウェア要件定義（外部設計） システム方式設計書を基に、システムを構成するソフト ウェアの機能や能力、インタフェース（入出力画面や 帳票の形式）や操作性の決定、そしてデータベースで 使用するデータ項目を定義する。 ソフトウェア要件定義書を作成する。 ソフトウェア方式設計（内部設計） ソフトウェア要件定義書を基に、開発者の視点から、 ソフトウェアの要件をどのように実現させるか、という システム内部の最上位レベルの構造設計を行う。 使用するデータの構造を設計する。 ソフトウェア方式設計書を作成する。 基礎課題12-18 ～基礎課題12-22

5-3．ソフトウェア詳細設計＋ソフトウェアコード構築 システム要件定義 システム方式設計 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 ソフトウェアコード構築 ソフトウェア詳細設計（プログラム設計） ソフトウェア方式設計書を基に、プログラムを記述 できるレベルまで詳細化する。 プログラムの仕様（アルゴリズムを含む）や、プロ グラム構造の細かい処理単位を設計する。 ソフトウェア詳細設計書を作成する。 ソフトウェアコード構築（プログラミング） ソフトウェア詳細設計書を基に、コーディング規約 に従ってプログラムを作成する。 基礎課題12-23～基礎課題12-25

6．ソフトウェアの品質管理 ＜ソフトウェアの品質特性（JIS）＞ 品質特性 内容 １．機能性 ２．使用性 ３．信頼性 ４．効率性 ５．保守性 使用目的や要件に従って正しく動作すること ２．使用性 利用者にとって理解、習得、操作しやすいこと ３．信頼性 必要なときに使用でき、故障時には速やかに回復できること ４．効率性 応答時間や処理時間など求められる性能が備わっていること ５．保守性 修正しやすいこと ６．移植性 ある環境から他の環境へ移しやすいこと 基礎課題12-26、基礎課題12-27

旭川医大とＮＴＴ 電子カルテシステム訴訟① 旭川医大とＮＴＴ　電子カルテシステム訴訟① ＜１審判決（2016年3月29日）＞ 産経ニュース（http://www.sankei.com/affairs/news/160329/afr1603290020-n1.html） 　旭川医大病院（北海道旭川市）への電子カルテシステム納入が遅れたことをめぐり、医大 と、発注先のＮＴＴ東日本が互いを訴えた２件の訴訟の判決で、旭川地裁（武藤貴明裁判 長）は２９日、それぞれ相手方への賠償を命じた。医大側に約３億８３００万円、ＮＴＴ東 日本側に約３億６５００万円の賠償命令。 　双方の訴状によると、医大とＮＴＴ東日本は平成２０年１０月３１日、電子カルテシス テムを中核とする病院情報管理システム納入の契約を結んだ。２２年１月にシステムを稼 働させる予定だったが納品が間に合わず、医大は同４月に契約解除した。 　医大病院には最終的に別の業者がシステムを納入した。医大側は「導入が遅れた結果、 余計な経費が必要になり、削減できたはずの経費も削減できなくなった」と主張。 　ＮＴＴ東日本側は「納期に間に合わなかったのは、システム開発段階で医大から当初の 契約にはなかった仕様の追加や変更を求められたからだ」などと反論していた。

旭川医大とＮＴＴ 電子カルテシステム訴訟② 旭川医大とＮＴＴ　電子カルテシステム訴訟② ２審判決（2017年8月31日） 毎日新聞（https://mainichi.jp/articles/20170901/ddl/k01/040/252000c） 旭川医大のみに１４億円賠償命令　「電子カルテ」控訴審 旭川医大病院への電子カルテシステム納入が遅れたことを巡り、旭川医大と受注者のＮ ＴＴ東日本が互いに損害賠償を求めた訴訟の控訴審判決で、札幌高裁は８月３１日、旭 川医大に対し、約１４億１５００万円をＮＴＴ側に支払うよう命じた。 昨年３月の１審旭川地裁判決は、双方に賠償を命令。過失割合はＮＴＴ側が８割、医大 側が２割としたが、高裁の竹内純一裁判長は「医大が契約や合意に反し、大量の追加要 望を出したことでシステム開発が遅れた」として、ＮＴＴ側の責任を否定。その上で 「医大はシステムがほぼ完成していたのに、一方的に契約を解除した」とし、医大側の 請求を棄却した。