特許第6053153号(P6053153)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 中国電力株式会社の特許一覧
<>
  • 特許6053153-システムの開発支援システム 図000002
  • 特許6053153-システムの開発支援システム 図000003
  • 特許6053153-システムの開発支援システム 図000004
  • 特許6053153-システムの開発支援システム 図000005
  • 特許6053153-システムの開発支援システム 図000006
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6053153
(24)【登録日】2016年12月9日
(45)【発行日】2016年12月27日
(54)【発明の名称】システムの開発支援システム
(51)【国際特許分類】
   G06F 9/44 20060101AFI20161219BHJP
【FI】
   G06F9/06 620J
【請求項の数】3
【全頁数】12
(21)【出願番号】特願2013-68768(P2013-68768)
(22)【出願日】2013年3月28日
(65)【公開番号】特開2014-191739(P2014-191739A)
(43)【公開日】2014年10月6日
【審査請求日】2016年3月1日
(73)【特許権者】
【識別番号】000211307
【氏名又は名称】中国電力株式会社
(73)【特許権者】
【識別番号】503320061
【氏名又は名称】株式会社エネルギア・コミュニケーションズ
(74)【代理人】
【識別番号】100126561
【弁理士】
【氏名又は名称】原嶋 成時郎
(72)【発明者】
【氏名】齋藤 智子
(72)【発明者】
【氏名】竹原 宏
(72)【発明者】
【氏名】藤井 康治
(72)【発明者】
【氏名】渡辺 健二
(72)【発明者】
【氏名】吉本 昌史
(72)【発明者】
【氏名】松井 歩
(72)【発明者】
【氏名】杉谷 智宏
【審査官】 石川 亮
(56)【参考文献】
【文献】 特開2003−50723(JP,A)
【文献】 特開2000−250749(JP,A)
【文献】 特開平3−84609(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/44
(57)【特許請求の範囲】
【請求項1】
システムの開発や保守の導入時や変更時を含む作業において、作業者がプログラムを含むファイルを変更した際に、前記作業者ごとに前記ファイルに対する変更内容を含む変更情報を画像として取得する変更情報取得手段と、
前記変更情報取得手段で取得した変更情報を記憶する変更情報記憶手段と、
前記変更情報記憶手段に基づいて、前記作業者ごとに不具合の発生に伴う前記変更情報を取得して、不具合の傾向を判定する不具合傾向判定手段と、
を備えることを特徴とするシステムの開発支援システム。
【請求項2】
前記変更情報記憶手段は、前記作業ごとに変更情報を記憶し、
不具合傾向判定手段は、前記変更情報記憶手段に基づいて、前記作業ごとに不具合の発生に伴う前記変更情報を取得して、不具合の傾向を判定する、
ことを特徴とする請求項1に記載のシステムの開発支援システム。
【請求項3】
前記変更情報記憶手段は、前記作業ごとに変更情報を記憶し、
前記作業ごとに、作業の目的を含む作業内容を記憶する作業内容記憶手段と、
前記変更情報記憶手段に基づいて、前記作業ごとに前記変更情報を取得して、前記作業の目的ごとに必要な変更内容を抽出する作業内容抽出手段と、
を備えることを特徴とする請求項1に記載のシステムの開発支援システム。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、システムの開発時に、作業者ごとの不具合の傾向を容易に把握することが可能なシステムの開発支援システムに関する。
【背景技術】
【0002】
システムの新規開発や、障害復旧作業、仕様変更、機器の導入や切り替えなどに伴って、例えば、プログラムや、定義ファイル、データベース、フォルダなどの追加、修正、削除(変更)や、入力ファイルや出力ファイルのアクセス権限の設定変更などを含む開発、保守作業が発生する。また、開発環境で作成したプログラムや各種ファイルなどを運用環境に移行する際には、運用環境のみで行う作業、例えば、ファイルの登録やファイル名の変更などが必要なことがある。運用環境への移行時にテストを実施して不具合が発見された場合は、プログラムや各種ファイルなどが修正される。
【0003】
システムの開発、保守を委託契約で依頼する場合は、注文者は作業に立ち会わない事が多く、注文者は受託者から作業内容の作業報告を受けることになる。しかしながら、受託者が作業内容を漏れなく記録して報告することは、手間と時間とを要してしまう。
【0004】
また、システムの開発、保守では、不具合を把握、管理して品質管理することがシステムの信頼性を高度に維持するためには重要である。特に、システムの開発、保守を委託契約で依頼する場合は、受託者ごとの不具合を管理して傾向を判定することにより、受託者ごとに品質管理が可能となる。
【0005】
ところで、マニュアル作成に関して、マニュアルの作成後における変更を容易に行うことが可能であり、マニュアルに記載する画像を容易に取得可能とすることによってマニュアル作成作業の負担を軽減させたマニュアル作成ツールに関する技術が知られている(例えば、特許文献1参照。)。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2007−164585号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
さらに、システムの開発、保守を委託契約で依頼する場合は、注文者は作業をしないため技術を習得することができないという問題があった。
【0008】
そこで、本願の発明者は、受託者が行った作業内容を漏れなく記録することにより、不具合の発生と修正内容とを把握することができると考えた。また、作業内容を把握することにより、注文者が技術を習得することができると考えた。
【0009】
そこでこの発明は、システムの開発時に、作業者ごとの不具合の傾向を判定することが可能なシステムの開発支援システムを提供することを目的としている。
【課題を解決するための手段】
【0010】
前記の課題を解決するために、請求項1の発明は、作業者がプログラムを変更した際に、前記作業者ごとに変更内容を含む変更情報を画像として取得する変更情報取得手段と、前記変更情報取得手段で取得した変更情報を記憶する変更情報記憶手段と、前記変更情報記憶手段に基づいて、前記作業者ごとに、不具合の傾向を判定する不具合傾向判定手段と、を備えることを特徴とするシステムの開発支援システムである。
【0011】
この発明によれば、変更情報記憶手段に基づいて、不具合傾向判定手段によって、作業者ごとに、不具合の傾向が把握される。
【0012】
請求項2の発明は、請求項1に記載の発明において、前記変更情報記憶手段は、作業ごとに変更情報を記憶し、不具合傾向判定手段は、前記変更情報記憶手段に基づいて、前記作業ごとに、不具合の傾向を判定する、ことを特徴とする。
【0013】
請求項3の発明は、請求項1に記載の発明において、前記変更情報記憶手段は、作業ごとに変更情報を記憶し、前記変更情報記憶手段に基づいて、前記作業ごとに、変更情報を抽出し作業内容を抽出する作業内容抽出手段と、を備えることを特徴とする。
【発明の効果】
【0014】
請求項1に記載の発明によれば、変更情報記憶手段に基づいて、作業者ごとに、不具合の傾向を判定することができるので、各作業者に対して不具合の傾向について注意喚起し、不具合を低減するよう指導することが可能になる。これにより、システムの品質を向上することが可能である。
【0015】
また、作業者がプログラムを変更した際に、作業者ごとに変更内容を含む変更情報を画像として取得するので、作業者が変更情報を記録したり報告したりする必要がなくなる。つまり、変更情報を自動的に取得することにより、変更情報を漏れなく把握することができる。さらに、変更情報を画像として取得するので、視覚的に容易に把握することができる。
【0016】
請求項2に記載の発明によれば、変更情報記憶手段に基づいて、作業者かつ作業ごとに、不具合の傾向を判定することができるので、より詳細に不具合の傾向を判定することが可能になる。すなわち、作業者が不具合を起こし易い作業を把握することができるので、より適切な注意喚起をすることが可能になる。
【0017】
請求項3に記載の発明によれば、変更情報記憶手段に基づいて、作業ごとに、変更情報を抽出し作業内容を抽出するので、作業ごとにどのような変更が必要であるかを把握することができる。具体的には、システムを変更する場合に、過去に行った同様の作業の変更情報を確認することで、例えば、どのプログラムや、定義ファイル、データベース、フォルダをどのように変更すればよいのかを把握することができる。このように必要な作業を抽出できるので、システムの変更を効率的に行うことができる。また、委託契約の場合であっても、注文者が作業ごとにどのような変更が必要であるかを把握することができるので、注文者が技術を習得可能である。
【図面の簡単な説明】
【0018】
図1】この発明の実施の形態に係るシステムの開発支援システムの概略構成ブロック図である。
図2図1のシステムの開発支援システムにおける依頼書データベースのデータ構成図である。
図3図1のシステムの開発支援システムにおける変更情報データベースのデータ構成図である。
図4図1の不具合傾向判定タスクによる処理を示すフローチャートである。
図5図1の作業内容抽出タスクによる処理を示すフローチャートである。
【発明を実施するための形態】
【0019】
以下、この発明を図示の実施の形態に基づいて説明する。
【0020】
図1は、この発明の実施の形態に係るシステムの開発支援システム1の概略構成ブロック図である。このシステムの開発支援システム1は、システムの開発時に、作業者ごとの不具合の傾向を判定することが可能なシステムであり、開発サーバ20と通信網NWを介して相互に通信可能となっている。
【0021】
ここで、この実施の形態においては、電力会社の業務で使用するシステムの開発、保守を、作業ごとに委託契約で実施する場合について説明し、電力会社の担当部署を注文者、ソフトウェア開発会社を受託者、ソフトウェアの開発会社の開発者を作業員とする。また、注文者から受託者には、作業(委託契約)ごとに、依頼するシステムの開発、保守の作業目的、作業日時、作業者などが記載された依頼書が提示されるものとする。作業目的とは、システムの開発、保守の作業の目的のことであり、例えば、「プログラム改修(入力ファイル追加)、処理JOB01に入力ファイルINFILE01を追加」、「プログラム改修(出力ファイル変更)、処理JOB02の出力ファイルOUTFILE02の出力項目追加」、「サーバ切替、SERVER03(現行)からSERVER04(新規)に切り替え」などのことである。作業日時は、委託契約に関する日時のことであり、例えば、依頼日時や納品予定日時、納品日時などのことである。作業者は、受託者とその作業員を識別するIDのことであり、例えば、「受託者ID+作業員ID」で示されるものとする。また、この実施の形態では、作業者とは、受託者の作業員を示すものとする。
【0022】
開発サーバ20は、システムの開発支援システム1と通信網NWを介して有線または無線にて通信可能となっており、委託契約で開発、保守を実施するシステムに関するプログラムやデータベース、ファイルなどが納品、すなわち、格納されるようになっている。すなわち、作業者は、当該開発、保守作業時は、開発サーバ20において、プログラムやデータベース、ファイルなどを編集(追加、更新、削除)する。そして、編集後にテストを実施して不具合を発見すると、再度、プログラムやデータベース、ファイルなどを編集しテストを実施して、不具合が解消されるまでこのような操作を繰り返す。また、作業者は、開発サーバ20にログインする際は、当該作業の作業IDと、受託者とその作業員を識別する作業者IDとを入力してログインするようになっている。
【0023】
システムの開発支援システム1は、図1に記載されているように、主として、通信部11、記憶部12、作業内容記憶手段としての依頼書記憶部13、変更情報記憶手段としての変更情報記憶部14、変更情報取得手段としての変更情報取得タスク15、不具合傾向判定手段としての不具合傾向判定タスク16、作業内容抽出タスク17、および、これらの制御などを行う制御部10とを備えている。
【0024】
記憶部12は、変更情報取得タスク15や不具合傾向判定タスク16、作業内容抽出タスク17を記憶したり、システムの開発支援システム1の情報処理に必要なデータを記憶したりするものである。また、記憶部12は、開発サーバ20におけるプログラムの実行履歴やテストの実施履歴を記憶するようになっている。
【0025】
依頼書記憶部13は、委託契約に関する作業目的を含む作業内容(依頼内容)を依頼書として記憶する依頼書データベース13aを格納するものである。図2に示すように、依頼書データベース13aには、依頼書ごとに、つまり、依頼書を識別する作業ID131ごとに、作業日時132、作業目的133、作業者ID134が記憶されている。作業ID131は、例えば、システムの種類を示す大区分と、業務区分を示す中区分と、処理区分を示す小区分とを組み合わせて、「大区分−中区分−小区分−連番」などのように発番されたIDが記憶されており、IDによってシステムの種類や業務区分、処理区分などを系統的に把握可能となっている。作業日時132には、作業に関する日時、すなわち、依頼日時や納品予定日時、納品日時などが記憶されている。作業目的133には、依頼作業の仕様(依頼作業の目的)が記憶されており、例えば、「プログラム改修(入力ファイル追加)、処理JOB01に入力ファイルINFILE01を追加」、「プログラム改修(出力ファイル変更)、処理JOB02の出力ファイルOUTFILE02の出力項目追加」、「サーバ切替、SERVER03(現行)からSERVER04(新規)に切り替え」などのように記憶されている。作業者ID134には、受託者とその作業員を識別するIDが記憶されている。
【0026】
この依頼書データベース13aは、注文者が受託者との間で委託契約の作業を依頼した場合に追加され、委託契約の変更・解除があった場合に更新・削除される。
【0027】
変更情報記憶部14は、作業者がプログラムを変更した際に、後述する変更情報取得タスク15によって取得された、変更内容を含む画像である変更情報を変更情報データベース14aとして格納するものである。ここで、変更内容とは、作業者が、開発サーバ20にログインした状態で、定義ファイル、プログラムファイルなどに対して行った編集(追加、更新、削除)操作のことであり、開発サーバ20において編集操作を行った編集画面(ウィンドウ)を画像としたものである。具体的には、エンターキーが押下されて、確定、保存を含む編集終了を意味する所定操作が行われた際に、エンターキーが押下される直前の編集画面、すなわち、編集終了時の編集画面を変更内容として記憶している。
【0028】
図3に示すように、変更情報データベース14aには、作業者、つまり、受託者とその作業員を識別する作業者ID141および作業ID142ごとに、作業日時143、変更内容144が記憶されている。作業ID142には、依頼書を識別するIDが記憶されており、依頼書データベース13aの作業ID131と対応するようになっている。作業日時143には、開発サーバ20における作業者の作業日時が納品日時として記憶されている。変更内容144には、開発サーバ20において作業者が実際に行った作業の内容である変更内容情報を記憶したメモリアドレスが記憶されている。変更内容情報としては、変更内容情報ID1441、変更内容1442が記憶されている。変更内容情報ID1441には、変更内容を識別するIDが記憶され、変更内容1442には、編集終了時の編集画面が画像として記憶されている。
【0029】
具体的には例えば、作業ID142に対応する依頼書ID131に該当する依頼書データベース13aの作業目的133が「プログラム改修(入力ファイル追加)、処理JOB01、入力ファイルINFILE01追加」の作業の場合は、変更内容1442には、「定義ファイルCONFFILE01に入力ファイルINFILE01に関する定義を追加」した際の編集画面、「プログラムファイル(ソースコード)PRGFILE01に入力ファイルINFILE01に関する処理を追加」した際の編集画面、「入力ファイルINFILE01を保存するためのディレクトリを作成」した際の編集画面が画像として記憶されている。また、作業ID142に対応する依頼書ID131に該当する依頼書データベース13aの作業目的133が「プログラム改修(出力ファイル変更)、処理JOB02、出力ファイルOUTFILE02変更」の作業の場合は、変更内容1442には、「定義ファイルCONFFILE02に出力ファイルOUTFILE02に関する定義を変更」した際の編集画面、「プログラムファイル(ソースコード)PRGFILE02に出力ファイルOUTFILE02に関する処理を変更」した際の編集画面が画像として記憶されている。また、作業ID142に対応する依頼書ID131に該当する依頼書データベース13aの作業目的133が「サーバ切替、SERVER03(現行)からSERVER04(新規)に切り替え」の作業の場合は、変更内容1442には、「定義ファイルCONFFILE03にサーバに関する定義をSERVER03からSERVER04に変更」した際の編集画面が画像として記憶されている。
【0030】
また、作業者が編集後にテストを実施して不具合を発見した場合は、再度、プログラムやデータベース、ファイルなどを編集するので、同一の作業者ID141および作業ID142について、変更内容情報(変更内容1442)のレコード数が増加する。つまり、作業者がプログラムを変更しテストを実施して不具合が発生した場合は、再度、当該プログラムを変更するため、当該プログラムの編集終了時の編集画面が複数、変更内容144として記憶されるようになっている。このように、変更情報データベース14aは、同一の作業者ID141および作業ID142について変更内容1442のレコード数が多いほど、当該作業について変更が多い、すなわち、不具合が多く発生し、プログラムの修正などの変更が多く発生したと判定することができる。
【0031】
この変更情報データベース14aは、作業者が開発サーバ20においてプログラムを変更した際、すなわち、変更情報取得タスク15によって変更情報が画像として取得された際に追加される。
【0032】
変更情報取得タスク15は、システムの開発や保守の導入時や変更時を含む作業において、作業者が定義ファイル、プログラムファイルなどを変更した際に、作業者ごとにファイルに対する変更内容を含む変更情報を画像として取得する機能を有するプログラムである。この変更情報取得タスク15は、システムの開発支援システム1が起動されると制御部10によって起動され、作業者が開発サーバ20にログインした後に、定義ファイル、プログラムファイルなどを変更していないかを常時監視するようになっている。
【0033】
この変更情報取得タスク15は、作業者が定義ファイル、プログラムファイルなどを変更したと判定した場合、すなわち、所定のディレクトリの定義ファイル、プログラムファイルなどを編集(追加、更新、削除)して確定、保存を含む編集終了を意味する所定操作が行われたと判定した場合に、編集操作を行った編集画面(ウィンドウ)を画像として記憶する機能を有するプログラム、タスクである。例えば、定義ファイルやプログラムファイルを編集した際は、編集のために開いた編集画面を画像として記憶する。具体的には、エンターキーが押下されて、確定、保存を含む編集終了を意味する所定操作が行われた際に、エンターキーが押下される直前の編集画面、すなわち、編集終了時の編集画面を記憶するようになっている。
【0034】
不具合傾向判定タスク16は、変更情報データベース14aに基づいて、作業者ごと、作業ごとに、不具合の発生に伴う変更情報を取得して、不具合の傾向を判定する機能を有するプログラム、タスクである。
【0035】
ここで、不具合の傾向とは、(A)作業者ごとの不具合が多い作業の有無、例えば、各作業者の不具合が特定の作業に偏っていないかを含む作業者ごとの不具合の傾向と、(B)不具合が多い作業の有無、例えば、全作業者の不具合が特定の作業に偏っていないかを含む作業ごとの不具合の傾向と、(C)その他の不具合の傾向、とを含むものとする。
【0036】
作業者ごとの傾向(A)は、具体的には例えば、以下のように判定する。
【0037】
(A1)変更情報データベース14aに存在する作業者ID141が特定の作業者(例えば、作業者A)であるデータは、作業ID142が特定の大区分および中区分の作業についてデータ数(件数)が多い場合は、作業者Aは、特定の作業について不具合が多い傾向があると判定する。
【0038】
(A2)変更情報データベース14aに存在する作業者ID141が特定の受託者の作業者(例えば、受託者Bの作業者)であるデータは、作業日時143が当該作業者の初回作業から所定回数以内(初回作業から所定期間以内)の作業についてデータ数が多い場合は、特定の受託者Bの各作業者は、作業経験が少ないうちは不具合が多い傾向があると判定する。
【0039】
(A3)変更情報データベース14aに存在する作業者ID141が特定の作業者(例えば、作業者C)であるデータは、変更内容1442が特定の変更内容、例えば、特定のプログラムを編集している画像のデータ数が多い場合は、作業者Cは、特定の変更内容が必要となる不具合が多い傾向があると判定する。
【0040】
作業ごとの傾向(B)は、具体的には例えば、以下のように判定する。
【0041】
(B1)変更情報データベース14aに、作業ID142が特定の大区分および中区分の作業についてデータ数が多い場合は、特定の作業について不具合が多い傾向があると判定する。
【0042】
(B2)変更情報データベース14aに、変更内容1442が特定の変更内容、例えば、特定のプログラムを編集している画像のデータ数が多い場合は、特定の変更内容が必要となる不具合が多い傾向があると判定する。
【0043】
不具合傾向判定タスク16は、具体的には、まず、変更情報データベース14aから、作業者ID141、作業ID142ごとに、変更内容1442を抽出して、不具合傾向を判定する。このとき、同一作業ID142の変更内容1442として、同一の定義ファイル、プログラムファイルなどの編集画面の画像が複数あり、その画像に差異がある、すなわち、同一ファイルに編集が複数回行われている場合は、当該ファイルの変更において、不具合が発見され、その解消のための変更内容1442であると判定する。また、記憶部12に、開発サーバ20における当該作業に関するテストの実施履歴が存在し、テスト後に記憶された変更内容1442がある場合は、テストによって不具合が発見され、その解消のための変更内容1442であると判定する。
【0044】
具体的には例えば、同一の作業者ID141、作業ID142について、変更内容1442に、「定義ファイルCONFFILE01に入力ファイルINFILE01に関する定義を追加」した際の編集画面が複数あり、画像に差異がある場合は、定義ファイルCONFFILE01に対して編集を複数回行った、すなわち、定義ファイルCONFFILE01に対して間違いなど不具合が発生したものと判定する。
【0045】
この不具合傾向判定タスク16は、注文者が、システムの開発、保守における不具合の傾向を判定したいと考えた際に注文者によって、または、所定期間ごとに制御部10によって起動するようになっている。そして、不具合傾向判定タスク16は、判定結果を注文者の担当者に通知するようになっている。
【0046】
作業内容抽出タスク17は、変更情報データベース14aに基づいて、作業ごとに、変更情報を取得して、作業の目的ごとに必要な変更内容を抽出する機能を有するプログラム、タスクである。すなわち、作業内容抽出タスク17は、依頼書に記載された作業目的に対して、受託者がどのような作業を行ったかを抽出するものである。
【0047】
作業内容抽出タスク17は、まず、依頼書データベース13aから、作業目的133に対応する作業ID131を抽出する。そして、変更情報データベース14aから、これらの作業ID131に対応する作業ID142の変更内容144を取得する。例えば、作業目的133が「入力ファイル追加」に該当する作業ID131の場合は、対応する作業ID142の変更内容144の画像から、「定義ファイルCONFFILE01に入力ファイルINFILE01に関する定義を追加」した際の編集画面、「プログラムファイル(ソースコード)PRGFILE01に入力ファイルINFILE01に関する処理を追加」した際の編集画面、「入力ファイルINFILE01を保存するためのディレクトリを作成」した際の編集画面を取得する。すなわち、「入力ファイル追加」する際には、「定義ファイルCONFFILE01に入力ファイルINFILE01に関する定義を追加」、「プログラムファイル(ソースコード)PRGFILE01に入力ファイルINFILE01に関する処理を追加」、「入力ファイルINFILE01を保存するためのディレクトリを作成」する作業が必要であることが取得できるようになっている。
【0048】
また、同一の定義ファイル、プログラムファイルなどの編集画面の画像が複数あり、その画像に差異がある、すなわち、同一ファイルに編集が複数回行われている場合は、当該ファイルの変更において不具合が発見されたものであると判定できることから、当該編集画面の中から再新の変更内容144を正しい変更内容として取得する。
【0049】
この作業内容抽出タスク17は、依頼書の作業目的に対して、受託者がどのような作業を行ったかを抽出したい際に、注文者によって、または、所定期間ごとに制御部10によって起動するようになっている。具体的には、作業内容抽出タスク17は、注文者が作業目的133や作業ID131を入力すると起動されるように制御部10によって制御されている。そして、作業内容抽出タスク17は、抽出結果を注文者の担当者に通知するようになっている。
【0050】
次に、このような構成のシステムの開発支援システム1における情報の処理手段および作用について説明する。
【0051】
注文者が、受託者の不具合の傾向を判定したい場合には、注文者によって不具合傾向判定タスク16が起動される。このとき、所定の受託者や作業員について不具合の傾向を判定したい場合は、当該受託者や作業員を特定する作業者IDを指定して不具合傾向判定タスク16が起動され、全受託者について不具合の傾向を把握したい場合は作業者IDを指定せずに不具合傾向判定タスク16が起動される。ここでは、全ての受託者について不具合の傾向を把握する場合について説明する。
【0052】
図4は、不具合傾向判定タスク16による処理手順を示している。不具合傾向判定タスク16が起動されると、まず、変更情報データベース14aから、作業者ごとに変更内容144が取得される(ステップS11)。そして、取得した作業者ごとの変更内容144から、不具合傾向が判定される(ステップS12)。
【0053】
これにより、具体的には例えば、変更情報データベース14aに存在する作業者ID141が作業者Aに関するデータは、作業ID142が特定の大区分および中区分の作業についてデータ数が多い場合は、作業者Aは、特定の作業について変更が多い、すなわち、不具合が多い傾向があると判定される。この場合は、注文者によって、受託者(作業者A)に、作業ID142が特定の大区分および中区分の作業についてミスが多いことが指摘され、作業内容(作業手順)を予め検証するように指導される。
【0054】
また、変更情報データベース14aに存在する作業者ID141が受託者Bの作業者は、作業日時143が当該作業者の初回作業から所定回数以内(初回作業から所定期間以内)の作業についてデータ数が多い場合は、特定の受託者Bの各作業者は、作業経験が少ないうちは不具合が多い傾向があると判定される。この場合は、注文者によって、受託者Bの各作業者は、作業経験が少ない期間は、作業内容を予め熟練者によって確認してもらうように指導される。
【0055】
さらに、変更情報データベース14aに存在する作業者ID141が作業者Cに関するデータは、変更内容1442が特定の変更内容、例えば、特定のプログラムを編集している画像のデータ数が多い場合は、作業者Cは、特定の変更内容(例えば、定義ファイルの設定)が必要となる不具合(例えば、定義ファイルの設定漏れ)が多い傾向があると判定される。この場合は、注文者によって、作業者Cに、定義ファイルの設定ミスが多いことが指摘され、作業時は定義ファイルの設定ミスがないことを確認するように指導される。
【0056】
同様に、作業ごとの傾向についても判定され、変更情報データベース14aに、作業ID142が特定の大区分および中区分の作業についてデータ数が多い場合に、特定の作業について不具合が多い傾向があると判定される。この場合は、注文者によって、作業内容を予め熟練者によって確認してもらうように指導される。
【0057】
さらに、変更情報データベース14aに、変更内容1442が特定の変更内容、例えば、特定のプログラムを編集している画像のデータ数が多い場合は、特定の変更内容が必要となる不具合が多い傾向があると判定される。この場合は、注文者によって、作業内容を予め熟練者によって確認してもらうように指導される。
【0058】
また、注文者が、技術承継のために、依頼書(依頼目的)ごとの作業内容を把握したい場合には、作業内容抽出タスク17が起動される。
【0059】
図5は、作業内容抽出タスク17による処理手順を示している。作業内容抽出タスク17が起動されると、まず、変更情報データベース14aから、作業ごとに変更内容144が取得され(ステップS21)、作業ごとの変更内容144が抽出される(ステップS22)。
【0060】
具体的には例えば、「入力ファイル」を追加したい場合に、どのような作業を行うかを抽出したい際は、ステップS21によって、作業目的133に「入力ファイル追加」を含む作業ID131が複数抽出される。そして、変更情報データベース14aから、これらの作業ID131に対応するに対応する作業ID142の変更内容144が取得される。これにより、「入力ファイル追加」の作業目的において、受託者が行った作業が取得される。例えば、作業目的が「入力ファイル追加」の場合は、変更内容144の画像から「定義ファイルCONFFILE01に入力ファイルINFILE01に関する定義を追加」、「プログラムファイル(ソースコード)PRGFILE01に入力ファイルINFILE01に関する処理を追加」、「入力ファイルINFILE01を保存するためのディレクトリを作成」する編集操作を行ったことがわかる。これにより、注文者によって、「入力ファイル」を追加したい場合に、行うべき作業が確認される。
【0061】
以上のように、このシステムの開発支援システム1によれば、変更情報データベース14aに基づいて、作業者ごとに、不具合の傾向を判定することができるので、各作業者に対して不具合の傾向について注意喚起し、不具合を低減するよう指導することが可能になる。これにより、システムの品質を向上することが可能である。
【0062】
また、作業者がプログラムを変更した際に、作業者ごとに変更内容を含む変更情報を画像として取得するので、作業者が変更情報を記録したり報告したりする必要がなくなる。つまり、変更情報を自動的に取得することにより、変更情報を漏れなく把握することができる。さらに、変更情報を画像として取得するので、視覚的に容易に把握することができる。
【0063】
また、変更情報データベース14aに基づいて、作業者や作業ごとに、不具合の傾向を判定することができるので、より詳細に不具合の傾向を判定することが可能になる。すなわち、作業者が不具合を起こし易い作業や作業者によらず不具合を起こし易い作業を把握することができるので、より適切な注意喚起をすることが可能になる。
【0064】
さらに、依頼書データベース13aと変更情報データベース14aに基づいて、作業ごとに、変更情報を抽出し作業内容を抽出するので、作業ごとに、すなわち、作業の目的ごとに、どのような変更が必要であるかを把握することができる。具体的には、システムを変更する場合に、過去に行った同様の作業目的の変更情報を確認することで、例えば、どのプログラムや、定義ファイル、データベース、フォルダをどのように変更すればよいのかを把握することができる。このように、委託契約の場合であっても、注文者が作業ごとにどのような変更が必要であるかを把握することができるので、注文者が技術を習得可能である。また、作業の目的ごとに必要な作業を抽出できるので、システムの変更を効率的に行うことができる。
【0065】
以上、この発明の実施の形態について説明したが、具体的な構成は、上記の実施の形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計の変更等があっても、この発明に含まれる。例えば、システムの開発支援システム1を、開発サーバ20に備えるようにしてもよいことはもちろんである。
【0066】
また、委託契約でシステムの開発、保守を委託契約で実施する場合について説明したが、システムの開発支援システム1は、委託契約以外のシステムの開発、保守であっても適用できることはもちろんである。具体的には例えば、システムの開発、保守を電力会社(自社)で行う場合は、依頼書データベース13aに、当該開発、保守において要求する仕様を定義した作業の概略を記憶するようにすればよい。
【符号の説明】
【0067】
1 システムの開発支援システム
11 表示部
13a 依頼書データベース(作業内容記憶手段)
14a 変更情報データベース
15 変更情報取得タスク(変更情報取得手段)
16 不具合傾向判定タスク(不具合傾向判定手段)
17 作業内容抽出タスク(作業内容抽出手段)
図1
図2
図3
図4
図5