JP5614843B2 - ソフトウェア設計・運用統合管理システム - Google Patents

Description

本発明は、要件情報、設計情報、プログラム情報、運用情報を結び付けたソフトウェア設計・運用統合管理システムに関する。

従来から、ソフトウェアの設計や運用、あるいは開発作業の見積もりを支援するためのシステムが多数知られている。例えば、特許文献１には、入力された構成情報からシステム構成図を作成し、システム要件を入力させ、これと運用ポリシーデータを作成し、構成情報に反映させる設計支援システムが記載されている。また、特許文献２には、運用作業項目、運用条件、サービスレベルを格納する運用要件ＤＢと、運用要件ＤＢの内容を画面表示し、設計項目を入力する手段と、入力した運用設計項目をもとに、コストの算出、設計ドキュメントの作成をおこなう運用設計支援システムが記載されている。また、特許文献３には、ソフトウェア規模および開発工数の見積もりの指定を作業者に促す画面を表示し、作業者は順次表示される画面に情報を入力していく見積もり作業支援システムが記載されている。

特開２００９−２５１６７２号公報 特開２００９−０７５９６１号公報 特開２００３−２６３３２０号公報

しかしながら、上記特許文献の記載のシステムは、設計、運用、見積もりをそれぞれ個々に支援するものであるが、それらを一環してサポートするものではない。要件情報、見積情報、設計情報、プログラム情報、運用情報（障害情報を含む）は互いに密接に関連しており、一部の変更が他に与える影響範囲を確実に管理しなければならない。詳細設計段階やプログラミングの段階では、プログラム・モジュールの関連性や変更の管理をサポートするシステムは多く存在するが、要件定義から、見積もり、設計、製造（プログラミング及びテスト）、運用、保守に至るまで一環してサポートできる仕組みはまだ少ない。したがって、各段階での詳細レベルの情報を有機的に結合して、総合管理できるシステムが望まれている。

本発明では、上記のような課題に鑑み、要件定義から、見積もり、設計、製造、運用、障害時にいたるまで、ソフトウェアの各コンポーネントレベルで有機的に詳細情報を関連付け、統合されたソフトウェア設計・運用のための統合管理システムを提供することを目的とする。

上記課題を解決するため、本発明のソフトウェア設計・運用統合管理システムは、以下のような解決手段を提供する。
ソフトウェアの要件定義から、開発見積、設計、運用までを支援するソフトウェア設計・運用統合管理システムであって、業務案件を定義する要件情報と、前記要件情報に基づいて作成された見積情報と、前記要件情報に基づいて作成された設計情報と、前記設計情報に基づいて製造されたソフトウェアのリリース後の運用情報を格納するデータベースを備え、前記設計情報には、少なくとも、機能仕様書、外部インターフェース設計書、画面設計書、帳票設計書、ＤＢ設計書、プログラム設計書を設計要素として含み、前記設計情報を管理する設計情報管理部と、前記見積情報には、過去にリリースした案件の開発工数、開発期間の実績値を見積要素として含み、前記見積要素に基づいて、新規開発案件の見積値を算出する見積情報管理部と、前記運用情報には、前記ソフトウェアが稼動する先の顧客情報を運用要素として含み、前記運用情報を管理する運用情報管理部と、前記設計要素、前記見積要素、前記運用要素それぞれに対して、互いに影響範囲にある要素をリンク付けして前記データベースに格納する手段と、前記リンク付けされた情報を各情報管理部間で登録・修正・検索・照会する手段とを、備えることを特徴とする。

このような構成によれば、設計情報管理部、見積情報管理部、運用情報管理部がそれぞれ管理する情報を各要素単位で互いに影響を及ぼす情報をリンク付けしてデータベース上で管理し、見積情報管理部、設計情報管理部、運用情報管理部等のサブシステム間で、各段階の必要な場面で、それぞれの情報を作成・変更したり、参照したりすることができるので、要件定義から、見積もり、設計、運用までを一貫したシステムでサポートすることができる。

本発明のシステムは、下記のような特徴をさらに備えることができる。
前記顧客情報は、顧客担当者の連絡先情報を含み、前記連絡先情報は、前記ソフトウェアを構成するプログラムまたはプログラムの各出力に対応した設計要素にリンク付けされており、前記ソフトウェアの障害発生時に、障害が検知された設計要素にリンク付けされた前記顧客情報を表示することを特徴とする。

このような特徴によれば、本システムの障害支援機能として、ソフトウェアを構成するプログラム（プログラム・モジュール）またはプログラムの出力（ファイル、画面、帳票等）に対応する詳細レベルの設計情報に対して、プログラムまたはプログラムの出力に障害が発生した時点で連絡が必要な顧客の連絡先をリンク付けする。このようにすることで、設計情報の各要素ごとに、障害時に連絡が必要な連絡先を表示することができ、障害時の迅速な連絡を支援することができる。例えば、エンドユーザに対して、帳票出力を行うプログラムであったとし、その帳票のデータに誤りが発見された場合、顧客のエンドユーザに多大な影響がでるので、緊急の連絡が必要な場合があるからである。

本発明のシステムは、下記のような特徴をさらに備えることができる。
前記顧客情報は、障害時の対処方法を記述した情報を含み、前記障害時に、障害が検知された設計要素にリンク付けされた前記対処方法を表示することを特徴とする。

このような特徴によれば、障害時には各要素単位で連絡先を表示する他、予め定められた障害時の対処方法が運用状況監視者等（オペレータ）に表示できるようになる。例えば、ジョブがアベンドした場合、後続の連携するジョブを停止する等の必要な処置をとることができる。このようにすることで、障害時の判断を迅速に行うことができる。

本発明のシステムは、下記のような特徴をさらに備えることができる。
前記対処方法には、障害復旧の完了必達時間を含み、前記障害の復旧完了予定時間が前記完了必達時間よりも遅れる場合には、顧客に通知することを前記運用情報管理部の操作員に促すことを特徴とする。

このような特徴によれば、復旧完了予定時間を保守員等が入力し、復旧が早期に見込まれる場合等には、不要な連絡をしない等の処理をとることができる。このようにすることで、障害時の判断を的確に行うことができる。

また、本発明のシステムは、下記のような特徴をさらに備えることができる。
前記見積情報管理部は、案件の画面数、帳票数、機能数、外部ファイル項目数を設計パラメータとしたとき、FP =k + a₁×［画面数］+ a₂×［帳票数］+ a₃×［機能数］+ a₄×［外部ファイル項目数］+ ・・・、で定義されるＦＰ算出式において、過去実績のＦＰ値と前記設計パラメータの実績値から、ｋ_１，ａ_１，ａ_２，の各種定数を回帰分析によって算出することを特徴とする。

このような特徴によれば、本システムの見積支援機能として、見積情報管理部が保存している過去の案件のＦＰ値と上記の各種パラメータ実績値を上記算出式に代入し、上記算出式の各種定数（係数）を回帰分析によって求めることで、ＦＰ（ファンクション・ポイント）法における、ソフトウェアの持つ機能の数をもとに、そのソフトウェアの規模を測定する手法の考えにのっとり、見積もりを定量化するための一つのＦＰ算出式を求めることができる。

上記の見積支援機能は、下記のような特徴をさらに備えることができる。
前記見積情報管理部は、前記各種定数の求まった前記ＦＰ算出式に、新規開発案件の画面数、帳票数、機能数、外部ファイル項目数の予測値を入力することにより、ＦＰ予測値を算出することを特徴とする。

このような特徴によれば、新規案件のパラメータ数を見積もり、上記の回帰分析により定数（係数）が求まったＦＰ算出式に入力することで、新規案件に対するＦＰ予測値が得られる。

上記の見積支援機能は、下記のような特徴をさらに備えることができる。
前記見積情報管理部は、前記新規開発案件の案件リリース後に、前記各種定数を定める前の前記ＦＰ算出式に、リリース後の案件の画面数、帳票数、機能数、外部ファイル項目数の実績値を入力することにより、各種定数を再度求めることにより前記ＦＰ算出式にフィードバックをかけることを特徴とする。

このような特徴によれば、新規案件をリリースした後に、ＦＰ実績値、各種パラメータ実績値を、入力することで、上記のＦＰ算出式の各種定数を再度求め、ＦＰ算出式自体にフィードバックをかけることができる。このようにすることで、案件情報が蓄積すればするほど、より正確な見積もりが行えるようになる。

上記の見積支援機能は、下記のような特徴をさらに備えることができる。
前記見積情報管理部は、開発担当者のスキル値の実績値を含み、前記算出されたＦＰ見積値と前記スキル値から、新規案件の作業期間を見積もることを特徴とする。

このような特徴によれば、ＦＰ予測値を人日でなく、見積日数（見積作業期間）として求めることができる。

本発明によれば、要件定義から、見積もり、設計、製造、運用、障害時にいたるまで、ソフトウェアのコンポーネントレベルで有機的に関連付け、統合されたソフトウェア設計・運用のための統合管理システムを提供することができる。

本発明の一つの実施形態に係るソフトウェア設計・運用統合管理システムの全体像を示す図である。 設計用語の定義を示す図である。 サブシステム情報管理の画面遷移を示す図である。 要件情報と設計情報のリンクを示す図である。 設計情報とプログラムのリンクを示す図である。 障害連絡時の判断支援（Ｃａｓｅ１）を示す図である。 障害連絡時の判断支援（Ｃａｓｅ２）を示す図である。 障害連絡時の判断支援画面イメージを示す図である。 見積支援の概要を示す図である。 見積支援画面イメージを示す図である。 開発工数見積ロジックを示す図である。 開発工数見積ロジックの例を示す図である。 開発期間見積ロジックを示す図である。 開発期間見積ロジックの例を示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。

図１は、本発明の一つの実施形態に係るソフトウェア設計・運用総合管理システム（以下、本システム１００と呼ぶ）の全体像を示す図である。本システムは、図示するように、典型的な構成としては、設計情報ＤＢを備えた設計情報管理部１１０、変更管理部１２０、ワークフロー管理部１３０、リリース管理部１４０、見積支援ツールと見積情報ＤＢを備えた見積情報管理部１５０、運用管理ツールと運用情報ＤＢを備えた運用情報管理部１６０、リソース管理ツールとプログラムソース管理ＤＢを備えたリソース管理部１７０から構成される。それぞれの管理部は、本システム１００のサブシステムとして機能する。

設計情報管理部１１０は、各種のデザイン支援ツール（画面デザインツール、帳票デザインツール等）と連動し、様々な設計書を格納する設計情報ＤＢを備えた設計情報管理サブシステムである。設計情報ＤＢには、設計書として、ビジネスフロー定義書、要件定義書、及び要件定義書に基づいた機能設計書が格納される。さらに、この機能設計書に基づいた画面設計書、帳票設計書、外部Ｉ／Ｆ設計書をはじめとして、データベース（以下、ＤＢ）設計書、レイアウト設計書、コード設計書、パラメータ設計書、メッセージ設計書、プログラム設計書、ジョブネット設計書等が格納される。これらの設計書は、設計要素とも呼ばれ、後述の図２の表で定義した内容を含んだファイルである。これらの設計書は、お互いの依存関係を示すため、互いに紐付け（リンク付け）されて、設計情報ＤＢに格納される。本システム１００では、１または複数のサーバ装置が、複数のユーザ端末とネットワークで接続され、設計情報ＤＢを中核とする各ＤＢを用いて、各ファイルのバージョン管理、影響範囲管理、変更履歴管理を行う。

変更管理部１２０は、設計情報が基づいている案件情報に変更があった場合や設計情報に変更があった場合に、その変更を管理するサブシステムである。ワークフロー管理部１３０は、上記設計書を新規作成、変更、照会する場合に、作成者、変更者、照会者、承認者等及びその承認経路を定義したＤＢ（図示せず）を備えた承認ワークフローのためのサブシステムである。リリース管理部１４０は、単体テスト後のプログラムを結合してシステムテストを行う際、及び本番リリース時のバージョン、レビジョン等のリリース管理や配布管理、貸出管理、自動コミット等を行うためのサブシステムである。

見積情報管理部１５０は、新規案件の見積もりや既存案件の変更見積もりが必要な場合に、見積者が、類似する過去の案件の見積情報を参照したり、現在登録されている開発担当者（ＳＥやプログラマ等）のスキルや単価等を格納した見積情報ＤＢを備えたサブシステムである。本システム１００の見積情報は、案件情報、設計情報とも密接に関係付けられる。

運用情報管理部１６０は、ソフトウェアが実際のユーザの環境で稼動後の運用状況を監視する運用ツールと、障害時に障害内容や障害を関係者に連絡するための連絡先情報を格納する運用情報ＤＢを備えたサブシステムである。本システム１００の運用情報は、案件情報、設計情報とも密接に関係付けられる。

リソース管理部１７０は、開発中及びリリース後のプログラムのソースファイルをソース解析し、プログラム間の関連性を管理したり、ソースファイルのＣＲＵＤ（Create（生成）、Read（読み取り）、Update（更新）、Delete（削除））を管理するリソース管理ツールと、それらの情報を格納したプログラムソース管理ＤＢを備えたサブシステムである。なお、本システム１００では、上記のサブシステム以外にも、製造・単体テストを管理する単体テスト管理部、プログラム設計書に基づいてプログラムを自動生成するＰＧＭ生成部等が存在するが、ここでは省略している。

本システム１００では、これらのサブシステム内、サブシステム間の情報の関連を確実に紐付けるため、要件定義段階、見積段階、設計段階、製造段階（プログラミング段階）、テスト段階、運用段階のドキュメントやデータの各コンポーネント（これらを、それぞれ「要件情報要素」、「見積情報要素」、「設計情報要素」、「プログラム要素」、「運用情報要素」と呼ぶことにする）おのおのにＩＤ（識別子）を定義し、互いにリンク付けした上でＤＢに格納することを特徴としている。言い換えれば、ＩＤをふられたファイルや情報を、「要素」と呼ぶことにする。設計要素には、上述した各種の設計書が含まれるし、見積情報要素には、過去の案件の情報や開発担当者や運用担当者の情報が含まれる。また、運用情報要素には、運用状況のデータや顧客情報が含まれる。

なお、上記図示した構成は、あくまでも一例であり、一つの機能部（サブシステム）を更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。各機能部は、サーバ装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only
Memory）またはハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わない。

図２は、設計用語の定義を示す図である。この表は、主に設計時に用いられる用語の定義を表にまとめたものである。例えば、「パラメータ設計」とは、「システムの挙動を簡単に変えることができるような業務に関するデータを定義する作業である」のように定義され、その作業のアウトプットのドキュメントがパラメータ設計書である。設計情報ＤＢに格納される設計書（設計情報ファイル）は、この表の内容を定義したファイルであり、本システム１００の画面デザインツールや帳票デザインツール等に沿った所定のフォーマットに従って作成されるものと、ビジネスフロー定義書、要件定義書、機能定義書等、任意のファイル形式であってよいものが存在する。また、この表は一例であり、特に表には示していないような設計用語も存在する。

図３は、サブシステム情報管理の画面遷移を示す図である。本発明のソフトウェア設計・運用統合管理システム１００は、要件定義から、見積もり、設計、プログラミング、テスト、リリース、運用、障害対処まで、様々な局面で利用されるが、それぞれの局面をサポートするため、すでに述べた複数のサブシステムで構成される。本システム１００に登録された情報は、互いに紐づけされ、関連するので、サブシステム内ではもちろん、サブシステム間でも共用される必要がある。ここでは、複数のサブシステム間の情報管理のために画面遷移について説明する。また、本システム１００では、単に情報共有だけでなく、上記の様々な業務を支援するようなツールが提供され、本システムのユーザ、例えば、プロジェクトリーダ、設計者、プログラマ、テスタ、運用監視者、保守要員等に対して、それぞれの役割にあった情報を提供することは言うまでもない。

ユーザは、本システムにアクセスするために、まず、ログイン画面からログインする必要がある。ログイン画面は他のサブシステムと共通であってもよいし、サブシステム毎に別々の画面であってもよい。ここでは、あるユーザが、通常、Ａサブシステムを使用するユーザであり、場合によって、他のサブシステム（Ｂサブシステムとする）に情報照会をする場合を考える。ユーザがＡサブシステムのログインに成功すると、Ａサブシステムがサポートするメニュー画面が表示される。ここでは、情報連携のため、大きく分けて、「登録・修正画面」、「検索画面」、「照会画面」を取り上げている。

システムに登録された情報の検索・照会時においては、ユーザが検察入力画面（ＳＦ−Ａ２１−０１）から必要な情報をキーワード等で検索し、その結果を検索結果画面（ＳＦ−Ａ２１−０２）に表示させる。検索結果表示画面（ＳＦ−Ａ２１−０２）で、必要な情報のＩＤ（対象定義ＩＤ）が見つかると、そこに表示されたリンク等をクリックすることで、照会画面（ＳＦ−Ａ２１−０３）に移り、その情報を参照することができる。照会画面からさらに変更履歴照会画面（ＳＦ−Ｂ０２−０３）に移り、変更履歴も参照することができる。図示するように、照会画面から登録・修正画面へは、複数のＴａｂキー等を押すことにより、いつでも切り替えることができる。

登録・修正時においては、入力画面（ＳＦ−Ａ２１−０４）から新規にシステムに登録する情報の入力や、登録した情報を修正することができる。登録・修正入力画面（ＳＦ−Ａ２１−０４）で、「実行」キーを押すことで、確認画面（ＳＦ−Ａ２１−０５）が表示され、登録・修正が完了すると完了画面（ＳＦ−Ａ２１−０６）が表示される。

ユーザが、別のサブシステムであるＢサブシステム管理下にある情報にアクセスする必要がある場合は、Ｂサブシステムにアクセスするための申請検索を申請検索入力画面（ＳＦ−Ｂ０１−０１）から行う。この申請は、プロジェクト関係者であればそのまま処理されるが、部外者がアクセスする場合等、必要な場合には承認ワークフローサブシステムを利用するようにしてもよい。承認ワークフローサブシステムのその他の典型的な利用例としては、重要な変更と考えられる「設計情報の変更」などがある。この申請が処理されると、申請検索結果画面（ＳＦ−Ｂ０１−０２）が表示され、そこからＡサブシステムの照会画面（ＳＦ−Ａ２１−０３）に戻り、Ｂサブシテム下の情報に、以後アクセスすることができるようになる。この申請により、Ｂサブシステムの照会画面（ＳＦ−Ａ１６−０３）に対象定義ＩＤによってＡサブシステムの照会画面（ＳＦ−Ａ２１−０３）からリンク付けがされるからである。このようにすることで、Ｂサブシステムに再度ログインする等の手間がなくなる。このような情報管理画面を提供することで、ユーザは、複数のサブシステム間のアクセスが容易になり、各情報の連携が進むことになる。

図４は、要件情報と設計情報のリンクを示す図である。既に述べたように、設計情報ＤＢに格納される各ファイルは、互いに紐付け（リンク付け）されるが、ここでは、一例として、要件情報と設計情報のリンク付けを示す。要件情報とは、ビジネスフロー定義と、要件定義を記述したファイルである。ビジネスフローとは、図２で示したように、顧客の業務について明確化する作業（アクティビティ）であり、要件定義とは、顧客が漠然と考えているシステムに求める役割を明確化する作業である。図示するように、一つのビジネスフロー定義から複数の要件定義が生まれることもある。それぞれを定義したファイルには、アクティビティＩＤ（ＢＡ０１），要件ＩＤ（ＲＱ０１，ＲＱ０２）のような変更管理ＩＤがふられ、それぞれの変更管理ＩＤがリンク付けされて（図では太い実線で示す）、ＤＢ上で管理される。

設計情報レポジトリ（設計情報ＤＢ）には、機能設計書、画面や帳票等の人間とのインターフェースであるＩ／Ｆ設計書、ＤＢの詳細（テーブル等）を定めたＤＢ設計書、プログラム（ＰＧＭ）ファイルが格納され、それぞれのファイルに対応するＩＤ（機能ＩＤ，画面ＩＤ，帳票ＩＤ，テーブルＩＤ，プログラムＩＤ）がふられて、各ＩＤがリンク付けされる。また、プログラムＩＤは、単体テストシナリオまたは単体テストケースのＩＤとリンク付けされテスト管理で使用される。それぞれのリンク付けは、情報の作成者が、多くの場合、その情報を作成する際に参照した情報のＩＤを指定することによってなされるが、プログラム設計書等、所定のフォーマットで作成する場合は、フォーマット中にリンク先のＩＤを含めるようにする。また、プログラムソース・ファイルの場合は、ソースファイルを解析し、モジュールの呼び出し関係からリンク情報を自動で作成することも可能である。

図５は、設計情報とプログラムのリンクを示す図である。この図では、設計情報とジョブ及びプログラムとのリンク付けの簡単な一例を示す。図示するように、データ連携ジョブネット１０（ＩＤ：ＪＮ１１）は、後続のデータ連携ジョブネット２０（ＩＤ：ＪＮ１２）を従えている。ジョブネットとは、実行順序を指定した、一つ以上のジョブの集まりのことである。この図では、データを連携する２つのジョブネットを示している。

データ連携ジョブネット１０は、データ連携ジョブ１１（ＩＤ：ＪＢ１１）と帳票出力ジョブ１２（ＩＤ：ＪＢ１２）の２つのジョブから構成されている。データ連携ジョブ１１は、データ連携のためのメインプログラムであるデータ連携メイン１３（ＩＤ：ＰＧ１１）とリンク付けされ、データ連携メイン１３は、ファイル出力サブルーチン１５（ＩＤ：ＰＧ０１）と帳票出力サブルーチン１６（ＩＤ：ＰＧ０２）を呼び出している。ファイル出力サブルーチン１５は、外部のサブシステムとデータ連携するためのファイルを出力するプログラムである。出力したファイルは、Ｉ／Ｆ ＩＤとしてＩＦ０１がふられ、このＩＤを、ファイル連携用のＩＤ、例えば、ＨＵＬＦＴ（登録商標）；（Host Unix Linkage File Transfer） ＩＤとして、出力サブルーチンと紐付けて管理する。帳票出力サブルーチン１６は、帳票出力メイン１４（ＩＤ：ＰＧ１２）からも呼び出される共通サブルーチンでもあり、顧客確認用の帳票（帳票フォーム１８（ＩＤ：ＲＰ０１）、及び帳票フォーム１９（ＩＤ：ＲＰ０２））を出力する。

以上、図４、図５の例で説明したように、本システム１００では、要件定義情報から、機能仕様書、ジョブ定義書、プログラム、及び最終的に出力されるファイルや帳票にいたるまで、一つ一つのコンポーネント（要素）にＩＤがふられ、それぞれの関係が紐付けされてＤＢで管理されるので、それぞれのコンポーネントが他のコンポーネントに及ぼす影響の範囲（これを影響範囲と呼ぶ）を詳細に捉えて管理することができる。この影響範囲の管理は、単に開発時の設計情報の間だけでなく、開発以前の見積段階や開発リリース後の運用保守情報の影響の管理にも役立てることができる。そのため、以降では、特に、障害時の判断支援や見積支援にスポットを当てて、具体例を説明する。

図６は、障害連絡時の判断支援（Ｃａｓｅ１）を示す図である。この図では、設計情報と運用情報をリンク付けすることによる影響範囲管理の具体例として、障害連絡時の判断支援を説明する。ここでは、Ｃａｓｅ１として、実環境で運用開始後、帳票データが誤っていることが発覚した場合を想定している。図で示した各コンポーネント間のリンク関係を表すツリー構造は、基本的には図５と同じであるとする。

設計情報と運用情報のリンクとして、ここでは、各ジョブの出力であるインターフェース１７、２２、及び帳票フォーム１８、１９に、それぞれ顧客情報１７ａ，１８ａ，１９ａ，２２ａが紐付けられている。「顧客情報」とは、対象ソフトウェアが稼動するシステムを運用する顧客の連絡先等（部署名、担当者名、電話番号）、及び障害時に顧客管理のため必要な対処法の情報を記述したファイルである。顧客情報は、設計時に定義されることもあるが、運用時に設定されることが普通であるので、通常は、設計情報ＤＢでなく、運用管理情報ＤＢに格納される。

ここで、帳票フォーム１８（ＩＤ：ＲＰ０１）でデータの誤りが発覚した場合を考える。この場合、帳票フォーム１８に誤りが発覚した時点で、保守要員等（オペレータ）が運用管理ツール上で所定の操作をすると、帳票フォーム１８にリンクされた顧客情報１８ａが表示される。また、システムがリンク情報を参照することで、影響範囲の対象であるコンポーネント（ここでは網掛けで示している）をすべて表示し、同じ帳票出力サブルーチン１６が出力した帳票フォーム１９についても横並びのチェックが必要なことが直ちに判断できる。さらに、このリンク情報から、帳票そのものでなく、ファイル出力サブルーチン１７が出力したファイル１７（ＩＤ：ＩＦ０１）にも誤りがある可能性が容易に判断がつくので、後続のデータ連携のため、例えば、ＨＵＬＦＴキックジョブを停止したりする必要性や、原因究明に時間がかかりそうな場合は、顧客に連絡が必要であることも直ちに判断できる。

顧客情報１８ａには、顧客連絡先の他、直ちに連絡すべきかどうかを判断するための情報も含まれていてもよい。例えば、無条件に直ちに報告を必要とする場合を定めた情報や、所定時間以内に解決すれば事後報告のみでよいとする場合を定めた情報等である。また、顧客情報には、顧客の連絡先だけでなく、開発担当者やプロジェクトリーダの連絡先等を含ませてもよいし、担当者情報を格納したＤＢ中の担当者ＩＤをリンク付してもよい。このようなリンク付によって、たとえ障害が発生しても、誰に、どういう手順で、どのくらいのタイミングで連絡すべきかを、障害が発生したコンポーネントごとに詳細に定義することができる。このことにより、逆に、無駄な連絡や報告を減少させることも可能である。

図７は、障害連絡時の判断支援（Ｃａｓｅ２）を示す図である。この図では、設計情報と運用情報をリンク付けすることによる影響範囲管理として、障害連絡時の判断支援の別の例を説明する。ここでは、Ｃａｓｅ２として、実環境で運用開始後、ジョブがアベンド（Ａｂｅｎｄ）した場合を想定している。ここでも、図で示した各コンポーネント間のリンク関係を表すツリー構造は、基本的には図５と同じであるとする。

帳票出力ジョブ１２（ＩＤ：ＪＢ１２）がアベンドしたことが検知されると、システムが、影響範囲のコンポーネントのリンク情報を参照することで、網掛けで図示するように関連するコンポーネントが保守員等に表示される。まず、同じジョブ内では、帳票フォーム１８と帳票フォーム１９が、このジョブの出力であるので、それらにリンク付けされた顧客情報１８ａ、１９ａが表示される。その顧客情報には、帳票が出ないことで即座に顧客に伝える必要がある場合には、オペレータから顧客に連絡させるための必要な情報が表示される。また、この場合、帳票出力ジョブ１２がアベンドして停止しているので、後続のデータ連携ジョブネット２０にも影響範囲が及ぶことになる。そのため、後続のデータ連携ジョブネット２０には、これにリンク付けされた復旧の完了予測時間、完了必達時間の情報が表示される。また、データ連携ジョブ２１には、前ジョブがアベンドしたことをいつまでに原因究明しないと顧客に影響が出るかを表示するようにする。不要な顧客連絡をしないようにもできる。また、次のデータ連携のジョブネットがある場合には、インターフェース２２（ＩＤ：ＩＦ０２）にＨＵＬＦＴ送信時刻が過ぎそうであれば、顧客にオペレータから連絡が必要とのリンク情報を表示することもできる。

以上、図６、図７で説明したように、設計時の各コンポーネントに顧客情報までもリンク付けることで、より柔軟な運用や保守が可能となる。また、即座に顧客に連絡すべきか否か、障害の完了予測時間や完了必達時間等の情報は、通常は、設計時には予測できないものであるので、運用管理ＤＢで管理されるが、設計情報ＤＢと運用情報ＤＢとの間で各コンポーネントがリンク付けされ、情報の作成・変更が管理されるのはいうまでもない。

図８は、障害連絡時の判断支援画面イメージを示す図である。この図では、保守担当者等が使用する運用管理ツールの一つの画面イメージを表している。図の中央の横線３０は時間軸を表している。ここで、例えば、ジョブがアベンドしたことを何らかの手段でシステムが検知すると、現在時刻（１２月１日 ７：４５）の時間と共に、アベンドしたジョブネットのＩＤ、この例ではＪＮ１２のアイコンが「×アベンド」（図中の白抜きの文字）として表示される。保守員等は、このアベンドしたジョブネットＪＮ１２のアイコン３１をクリックすると、そのジョブネットの詳細情報３２が表示される。また、ジョブネットＪＮ１２に関連して、完了要のジョブネットがある場合は、それらのアイコンが符号３３で示すように表示される。特に、ジョブネットＪＮ１２の影響範囲内にあるジョブネットは、図のように網掛けで表示され、「△要注意」であることが示される。

ここで、「△要注意ジョブネット」のうち、例えば、△ＪＮ８２のアイコンをクリックすると、ジョブネットＪＮ８２の詳細情報３４がさらに表示される。この詳細情報３４の中には、ジョブネットＪＮ１２の説明の他、システム状況として、障害復旧担当者等が入力した完了予定時刻の他、システムによって予め定められた完了必達時刻が表示され、このままでは完了必達時刻に間に合わない可能性がある旨が表示されている。また、ジョブネットＪＮ８２の詳細情報３４の中には、出力対象帳票としてＲＰ０２２のアイコンが表示され、このアイコンをクリックすると、帳票ＲＰ０２２の詳細情報３５（ここでは対応する顧客連絡先等も含んでいる）がさらに表示される。これを見た保守員等は、オペレータに顧客に連絡することを指示することになる。また、アベンドしたＪＮ１２の影響範囲にあるインターフェースであり、要注意の△ＩＦ１１のアイコン３６をクリックすると、そこにリンク付けされた顧客連絡先３７（この例では、開発を担当した会社の連絡先）が表示され、ここにも連絡が必要なことがわかる。このように、本システムの影響範囲管理の仕組みは、障害時の状況把握や必要な連絡先の表示等、リアルタイムに障害連絡時の判断をサポートすることができる。

図９は、見積支援の概要を示す図である。この図では、本システムの影響範囲管理の別の具体例として、開発着手前の見積もり段階を支援する場合を示す。図で示す見積管理システムは、図１で説明した見積情報管理部１５０が設計情報管理部１１０と連携したイメージを表している。

通常、新規開発案件の見積もりには要件定義、既存システムの変更の見積もりでは変更外形要素の定義と変更影響を管理する機能が必要である。また、開発方針や前提条件を定めた開発スコープ等が必要となる場合もある。さらに、開発実績の工数や障害時の対応工数等、過去の類似案件を実績分析することも必要である。また、開発要員の稼動状況や個人スキル値等も考慮する必要がある。これらの情報を本システムでは、主として、設計情報ＤＢと見積情報ＤＢに格納している。個々の情報は、変更管理ＩＤで管理され，互いにリンク付けされているのは言うまでもない。

見積管理システムは、上記の各インプットから求められるデータを、ファンクション・ポイント（ＦＰ）算出式に入力し、新規案件の見積もりを行うことができる（これを改善ＦＰ法と呼ぶことにする）。また、要件、関連設計情報、変更外形要素、個人スキル値等を入力することで、新規案件の見積もりだけでなく、既存案件の変更の見積もりにも対応することができる。また、図９の右端で示すように、改善ＦＰ法のアウトプットは、開発の総人日として求められるので、それを個人スキル値で割ることにより、作業期間の見積もりをすることもできる。改善ＦＰ法による見積もり支援については以降の図で具体的に説明する。

図１０は、見積支援画面イメージを示す図である。この図は、見積管理システムが、見積者に対して表示する画面のイメージを示したものである。見積者は、左上の検索窓４０から、検察したい種類（要件説明、ブロック説明等）を選択し、プロジェクトのキーワード等を入力して、関連する過去の案件を検索することができる。検索の結果は、左中央の符号４１で示すように、要件ＩＤ、要件概要、ＦＰ、外部設計項目数（ブロック数、画面数・・・）等が一覧で表示される。そして、例えば、案件ＩＤのＲＱ０１のアイコンをクリックすると、右の符号４２で示すように、各要件に紐づく情報がツリー構造で表示される。また、右下の符号４３で示すように、その案件を担当した担当者ごとに、階層（スキルレベル）、担当した工程、その実績工数（人日）が表示される。

図１１は、開発工数見積ロジックを示す図である。この図では、改善ＦＰ法を用いて開発工数を見積る際の手順を説明する。開発工数の見積手順としては、（１）＜準備＞、（２）＜利用方法＞、（３）＜フィードバック＞の３段階で実施する。ただし、（２）＜利用方法＞には、「ＦＰ見積式を利用する方法」と、「似たような案件から規模感を乗じて算出」の２通りがある。以下、実施方法を順に説明する。

まず、（１）＜準備＞として、図示するようなＦＰの算出式（式（１））の各種定数（ｋ_１，ａ_１，ａ_２，・・・）の初期値を求める。そのためには、入力パラメータである画面数、帳票数、機能数、外部ファイル項目数等を、過去の実績値からインプットし、回帰分析を行い、上記の各種定数（係数）の大きさを推計する。上記のＦＰ算出式では、ＦＰが回帰分析における従属変数であり、各入力パラメータが独立変数である。回帰分析には様々な手法があるが、最小２乗法のような代表的な手法を用いてよい。実際には、見積者がＦＰ実績値や各パラメータをいちいち入力せずとも、案件ＩＤを選択するだけで、見積管理システムが、ＦＰ実績値と各パラメータの実績値とから、各種定数を算出する。

上記の各種定数の算出が終わると、次に、（２ａ）＜利用方法１＞において、「ＦＰ見積式を利用する方法」画面数、帳票数等の各パラメータに値を代入してＦＰを算出することでＦＰ見積を求める。ここでのインプットは、（１）＜準備＞で算出した各種定数と、今回見積もりを行う案件の画面数、帳票数、機能数、外部ファイル項目数等の各パラメータの予測値である。これを、上記のＦＰ算出式に代入することで、ＦＰ見積値（人日）が求まる。

上記の（２ａ）＜利用方法１＞では、システムが過去の実績値から予測パラメータからＦＰ見積もりを算出した「ＦＰ見積式を利用する方法」であるが、（２ｂ）＜利用方法２＞では、見積者が、検索結果から、似たような要件を持つ案件があれば、今回の案件がその案件と比較して規模感を決め、それをインプットとしてＦＰ見積もりを算出する。規模感は、似たような案件を持つ案件との規模比較（今回、何％の作業量がありそうか？）といった抽象的なもので、見積者の過去の経験に依存することになるが、逆に実戦的な手法でもある。また、（２ａ）＜利用方法１＞と併用することで、機械による単純計算と人間の経験に基づいた直感が組み合わさることで、より正確な見積もりをすることも可能である。

上記のようにして求めたＦＰ見積値は、案件リリース後に、（３）＜フィードバック＞として、その案件のＦＰ実績値と、各種パラメータの実績値をインプットとして、ＦＰ算出式の精度を上げるために利用される。すなわち、ＦＰ見積値とＦＰ実績値の差が最小になるように各種定数（ｋ_１，ａ_１，ａ_２，・・・）を算出しなおす。このように求めた各種定数は、以後の案件のＦＰ算出式で使用されることになる。

図１２は、開発工数見積ロジックの例を示す図である。この図では、図１１で説明した開発工数見積ロジックの簡単な具体例を示す。まず、（１）＜準備＞では、過去の案件ごとに、テーブル５０で示すような実績値が与えられているとし、これを回帰分析することで、ＦＰ算出式が式（２）のように求まる。ただし、ここでは、簡略化するために、設計パラメータをテーブル項目数、修正画面数だけに限定している。また、この例では、ＦＰの単位として金額（千円）を使用しているが、標準工数等、様々な指標であってもよい。

（２ａ）＜利用方法１＞においては、今回の案件Ａ１０１の各種パラメータをテーブル５１のように予測し、（１）＜準備＞で求めた式（２）に代入すると、ＦＰ見積＝８０．６＋１２．８×２＋２２．２×１０＝３２８．２［千円］とＦＰ見積が求まる。

（２ｂ）＜利用方法２＞においては、案件Ａ１０２と最も似ている案件がテーブル５０のＡ００２であったとし、Ａ１０２はＡ００２と比べ、機能が若干複雑になりそうなため１２０％くらいの作業量とすると、単純に、ＦＰ見積＝３００［千円］×１２０％＝３６０［千円］と予測できる。あるいは、Ａ００２を変更することでＡ１０２が実現可能と予測できる場合は、Ａ００２からの変更量を５０％とすれば、ＦＰ見積＝３００［千円］×５０％＝１５０［千円］と予測できる。このような場合、どちらの開発スコープを取るかで見積もりが大きく変わってくるので注意が必要であることが本見積管理システムを利用することで容易に判断できる。

（３）＜フィードバック＞においては、案件Ａ１０１が来たときにかかった実績工数も算出式のインプットとして利用する。実績値がテーブル５２で示すような結果であった場合、ＦＰ算出式を再び回帰分析を利用して作成すると、ＦＰ見積=７１．３＋１４．７×［修正対象テーブル項目数］＋８．２×［修正画面数］ ［千円］・・・式（２）´となる。

図１３は、開発期間見積ロジックを示す図である。この図では、図１２で説明した開発期間見積ロジックの簡単な具体例を示す。開発期間見積では、過去実績として、データベースに保持した社員（担当ＳＥ、プログラマ等）の作業履歴も利用する。これらの情報を利用することで、新規案件の開発工数だけでなく、作業期間の見積もりも可能となる。以下、その手順を説明する。

まず、（１）＜準備＞では、図示するような式（３）に当てはめ、回帰分析にて個人能力値（スキル値）を見積もる。この場合のインプットは、ＦＰ（過去の１案件あたりの特定業務・特定工程あたりの工数（人日））と、社員ｉの作業工数（社員ｉが１案件・特定行部・特定工程に費やした工数）である。アウトプットは、社員ｉのスキル値（社員のスキルを係数化した値）である。

（２）＜利用方法＞では、図１１の開発工数ロジックで算出した「ＦＰ見積」を、対応する社員のスキル値で割ることで、見積作業期間（見積日数）を算出する（式（４）参照）。この場合のインプットは、ＦＰ見積、社員ｉのスキル値、社員ｉの作業比率（社員がその案件に力を入れる割合（０〜１００％））である。アウトプットは、見積日数（見積作業期間）である。

（３）＜フィードバック＞では、案件リリース後に、ＦＰ実績値と、各種パラメータをインプットとして、ＦＰ算出式（３）の精度を上げる。この場合のインプットは、ＦＰ実績値、社員ｉの作業工数であり、アウトプットは、社員のスキル値である。

図１４は、開発期間見積ロジックの例を示す図である。この図では、図１３で説明した開発期間見積ロジックの簡単な具体例を示す。ここでは、簡略化のため、工程や業務知識は無視して、同一工程・同一業務に対する案件であるとする。まず、（１）＜準備＞において、各案件における担当者の作業工数がテーブル６０のようであったとする。このテーブルをインプットとして、前図の式（３）から、各社員の能力がテーブル６１のように求まる。

（２）＜利用方法＞においては、図１１で説明した開発工数見積ロジックを利用し、ＦＰ=２００（千円）となるような案件が発生したとして、これを社員２と社員３の２人体制で作業するとした場合、図示するように、ＦＰ＝２００÷（１．３＋）＝５０日がかかることになる。同じ案件を社員１のみで作業したとすると、ＦＰ＝２００÷６．４＝３２日間で開発完了する見込みになる。

以上説明したように、本システム１００は、ソフトウェアの設計開発・運用支援を行うものであるが、単にソフトウェア開発だけに留まらず、ハードウェアを含んだ様々な製品やサービスの開発においても応用することが可能である。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またそのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

１０、２０ データ連携ジョブネット
１１、２１ データ連携ジョブ
１２ 帳票出力ジョブ
１３ データ連携メイン
１４ 帳票出力メイン
１５ ファイル出力サブルーチン
１６ 帳票出力サブルーチン
１７、 ＩＦ ＩＤ
１８、１９ 帳票フォーム
１００ ソフトウェア設計・運用統合管理システム
１１０ 設計情報管理部
１２０ 変更管理部
１３０ ワークフロー管理部
１４０ リリース管理部
１５０ 見積情報管理部
１６０ 運用情報管理部
１７０ リソース管理部

Claims (8)

1. ソフトウェアの要件定義から、開発見積、設計、運用までを支援するソフトウェア設計・運用統合管理システムであって、
   業務案件を定義する要件情報と、前記要件情報に基づいて作成された見積情報と、前記要件情報に基づいて作成された設計情報と、前記設計情報に基づいて製造されたソフトウェアのリリース後の運用情報を格納するデータベースを備え、
   前記設計情報には、少なくとも、機能仕様書、外部インターフェース設計書、画面設計書、帳票設計書、ＤＢ設計書、プログラム設計書を設計要素として含み、前記設計情報を管理する設計情報管理部と、
   前記見積情報には、過去にリリースした案件の開発工数、開発期間の実績値を見積要素として含み、前記見積要素に基づいて、新規開発案件の見積値を算出する見積情報管理部と、
   前記運用情報には、前記ソフトウェアが稼動する先の顧客情報を運用要素として含み、前記運用情報を管理する運用情報管理部と、
   前記設計要素、前記見積要素、前記運用要素それぞれに対して、互いに影響範囲にある要素をリンク付けして前記データベースに格納する手段と、
   前記リンク付けされた情報を各情報管理部間で登録・修正・検索・照会する手段とを、
   備えることを特徴とするソフトウェア設計・運用統合管理システム。
2. 前記顧客情報は、顧客担当者の連絡先情報を含み、前記連絡先情報は、前記ソフトウェアを構成するプログラムまたはプログラムの各出力に対応した設計要素にリンク付けされており、前記ソフトウェアの障害発生時に、障害が検知された設計要素にリンク付けされた前記顧客情報を表示することを特徴とする、請求項１に記載のソフトウェア設計・運用統合管理システム。
3. 前記顧客情報は、障害時の対処方法を記述した情報を含み、前記障害時に、障害が検知された設計要素にリンク付けされた前記対処方法を表示することを特徴とする、請求項２に記載のソフトウェア設計・運用統合管理システム。
4. 前記対処方法には、障害復旧の完了必達時間を含み、前記障害の復旧完了予定時間が前記完了必達時間よりも遅れる場合には、顧客に通知することを前記運用情報管理部の操作員に促すことを特徴とする、請求項３に記載のソフトウェア設計・運用統合管理システム。
5. 前記見積情報管理部は、案件の画面数、帳票数、機能数、外部ファイル項目数を設計パラメータとしたとき、
   FP =k + a₁×［画面数］+ a₂×［帳票数］+ a₃×［機能数］+ a₄×［外部ファイル項目数］ + ・・・
   で定義されるＦＰ算出式において、過去実績のＦＰ値と前記設計パラメータの実績値から、ｋ_１，ａ_１，ａ_２，の各種定数を回帰分析によって算出することを特徴とする、請求項１に記載のソフトウェア設計・運用統合管理システム。
6. 前記見積情報管理部は、前記各種定数の求まった前記ＦＰ算出式に、新規開発案件の画面数、帳票数、機能数、外部ファイル項目数の予測値を入力することにより、ＦＰ予測値を算出することを特徴とする、請求項５に記載のソフトウェア設計・運用統合管理システム。
7. 前記見積情報管理部は、前記新規開発案件の案件リリース後に、前記各種定数を定める前の前記ＦＰ算出式に、リリース後の案件の画面数、帳票数、機能数、外部ファイル項目数の実績値を入力することにより、各種定数を再度求めることにより前記ＦＰ算出式にフィードバックをかけることを特徴とする、請求項６に記載のソフトウェア設計・運用統合管理システム。
8. 前記見積情報管理部は、開発担当者のスキル値の実績値を含み、前記算出されたＦＰ見積値と前記スキル値から、新規案件の作業期間を見積もることを特徴とする、請求項６乃至７に記載のソフトウェア設計・運用統合管理システム。

Images