(57)【要約】【課題】様々な開発プロセスに対応できる、プロジェクト特性評価による開発プロセス作成システム及びそれを用いた開発プロセス作成方法を提供する。【解決手段】プロセス構成部１１は入力としてプロジェクト特性を受け取り、プロセスアーキテクチャデータベース１２から受け取ったプロセスアーキテクチャとアクティビティ取得部２１から受け取ったアクティビティとを合成して、要求のあったプロジェクト向けの開発プロセスを返却する。アクティビティ取得部は、プロセス構成部からのアクティビティ取得要求を受けて、アクティビティデータベース２２から複数のアクティビティを取得する。この時、プロセス構成部から渡されたプロジェクト特性と、過去のアクティビティ選択履歴情報とに基づき、適切と思われるアクティビティのみに絞り込んで取得する。取得されたアクティビティは、プロセス構成部へ返却される。【選択図】      図１
2004341804.tif 000002
【特許請求の範囲】
【請求項１】
プロセス構成部とアクティビティ取得部とプロセスアーキテクチャデータベースとアクティビティデータベースとから構成され、
前記プロセス構成部は、入力としてプロジェクト特性を受け取り、該プロジェクト特性を基にプロセスアーキテクチャとアクティビティとを合成して、対象プロジェクト向け開発プロセスを作成し、返却し、
前記プロセスアーキテクチャデータベースは、前記プロセス構成部からのプロセスアーキテクチャ取得要求により、プロセスアーキテクチャを前記プロセス構成部へ返却し、
前記アクティビティ取得部は、前記プロセス構成部より入力として前記プロジェクト特性と要素ＩＤを受け取り、適切なアクティビティを前記プロセス構成部へ返却し、
前記アクティビティデータベースは、前記アクティビティ取得部より入力として前記要素ＩＤを受け取り、要求に合致するアクティビティを前記アクティビティ取得部へ返却し、また、前記アクティビティ取得部よりアクティビティ最終決定のフィードバックを受け取り、該当するアクティビティの選択履歴情報を更新する、プロジェクト特性評価による開発プロセス作成システム。
【請求項２】
前記プロセスアーキテクチャデータベースは、要素ＩＤと前要素ＩＤとから構成され、
開発プロセスを形作るための骨格全体を指す前記プロセスアーキテクチャは、該プロセスアーキテクチャの骨格をいくつかに区分けした各部分であるプロセスアーキテクチャ要素から構成され、
各プロセスアーキテクチャ要素はそれぞれ前記要素ＩＤにより一意に識別可能であり、
開発プロセスにおいてはプロセスアーキテクチャ要素間には前後関係があり、該前後関係は自分の前に来るべきプロセスアーキテクチャ要素の要素ＩＤで示すため、前要素ＩＤにその情報を格納し、先頭のプロセスアーキテクチャ要素の場合はそれより前に位置すべきプロセスアーキテクチャ要素が存在しないため前要素ＩＤにはＮＵＬＬが入る、請求項１に記載のプロジェクト特性評価による開発プロセス作成システム。
【請求項３】
前記アクティビティデータベースは、アクティビティＩＤと所属要素ＩＤと複数のプロジェクト特性とから構成され、
前記アクティビティＩＤはアクティビティを一意に識別する情報であり、
前記所属要素ＩＤは前記アクティビティを選択肢とするようなプロセスアーキテクチャ要素を識別するための情報であり、
前記複数のプロジェクト特性は、各アクティビティの、所定のプロジェクト特性における選択履歴情報であり、各プロジェクト特性ごとに取りうる特性値について、選択回数が１以上なら、対応するアクティビティが選択可能であり、選択回数が０なら、対応するアクティビティは選択不可能であり、選択回数は、前記アクティビティ取得部からのアクティビティ最終決定のフィードバックに基づき、更新される、請求項２に記載のプロジェクト特性評価による開発プロセス作成システム。
【請求項４】
前記プロセス構成部が入力としてプロジェクト特性を受け取ると、前記プロセスアーキテクチャデータベースから、プロセスアーキテクチャ要素の集合を取得する第１のステップと、
各プロセスアーキテクチャ要素に当てはめるためのアクティビティを取得するために、前記プロジェクト特性と前記プロセスアーキテクチャ要素の要素ＩＤを入力として前記アクティビティ取得部に要求し、対応するアクティビティ群を取得する第２のステップと、
前記第２のステップを全プロセスアーキテクチャ要素に対して繰り返す第３のステップと、
全プロセスアーキテクチャ要素に対するアクティビティを取得し終えたら、該アクティビティをプロセスアーキテクチャ要素間の前後関係に従って、プロジェクト向け開発プロセスとして構築し、返却する第４のステップとを有する、
請求項３に記載のプロジェクト特性評価による開発プロセス作成システムを用いた開発プロセス作成方法。
【請求項５】
前記第２のステップで、前記プロセス構成部が前記アクティビティ取得部にアクティビティ取得要求を出すと、前記アクティビティ取得部は、入力としてプロジェクト特性とプロセスアーキテクチャ要素の要素ＩＤを受け取り、「所属要素ＩＤ＝指定されたプロセスアーキテクチャ要素の要素ＩＤ」という絞込み条件により、前記アクティビティデータベースより複数のアクティビティを取得するステップと、
取得した各アクティビティが持つプロジェクト特性の特性値の選択回数と、前記プロセス構成部から入力情報として渡されたプロジェクト特性ごとの特性値とを比較して、選択可能なアクティビティのみにさらに絞り込むステップと、
最終的に絞り込まれたアクティビティ群を、該当アクティビティに関して、入力情報として受け取ったプロジェクト特性の箇所の選択回数の総和の多い順に並べ替えて、前記プロセス構成部へ返却するステップとを有する、請求項４に記載のプロジェクト特性評価による開発プロセス作成システムを用いた開発プロセス作成方法。
【請求項６】
前記アクティビティデータベースに類似アクティビティを識別するための情報であるカテゴリという項目を追加し、
前記第２のステップで、前記プロセス構成部が前記アクティビティ取得部にアクティビティ取得要求を出すと、前記アクティビティ取得部は、入力としてプロジェクト特性とプロセスアーキテクチャ要素の要素ＩＤを受け取り、「所属要素ＩＤ＝指定されたプロセスアーキテクチャ要素の要素ＩＤ」という絞込み条件により、前記アクティビティデータベースより複数のアクティビティを取得するステップと、
取得した各アクティビティが持つプロジェクト特性の特性値の選択回数と、前記プロセス構成部から入力情報として渡されたプロジェクト特性ごとの特性値とを比較して、選択可能なアクティビティのみにさらに絞り込むステップと、
最終的に絞り込まれたアクティビティ群を、該当アクティビティに関して、入力情報として受け取ったプロジェクト特性の箇所の選択回数の総和の多い順に前記カテゴリごとに並べ替えて、前記プロセス構成部へ返却するステップとを有する、請求項４に記載のプロジェクト特性評価による開発プロセス作成システムを用いた開発プロセス作成方法。
【請求項７】
前記アクティビティ取得部は、フィードバック情報としてプロジェクト特性と選択されたアクティビティを受け取るステップと、
前記アクティビティ取得部は、前記アクティビティデータベースに対して、前記選択されたアクティビティの選択履歴情報であるプロジェクト特性の部分を、受け取ったプロジェクト特性に照らして、該当する特性値のところの選択回数を＋１するよう要求し、前記アクティビティデータベースは、該当する特性値のところの選択回数を＋１するステップとを有する、請求項５または請求項６に記載のプロジェクト特性評価による開発プロセス作成システムを用いた開発プロセス作成方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プロジェクト特性評価による開発プロセス作成システム及びそれを用いた開発プロセス作成方法に関する。
【０００２】
【従来の技術】
開発プロセスの作り方として「標準」的なものから、各利用状況に応じてカスタマイズして作るやり方がある。この「標準」の一つの典型例がＩＳＯ／ＩＥＣ１２２０７「Ｉｎｆｏｒｍａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ  −  Ｓｏｆｔｗａｒｅ  ｌｉｆｅ  ｃｙｃｌｅ  ｐｒｏｃｅｓｓｅｓ」の「Ｄｅｖｅｌｏｐｍｅｎｔ  ｐｒｏｃｅｓｓ」であり、またここには「ｔａｉｌｏｒｉｎｇ  ｐｒｏｃｅｓｓ」として開発プロセスのカスタマイズの仕方が記述されている。
【０００３】
このような開発プロセス作成の一例として、以下の例がある（特許文献１参照）。
【０００４】
従来の開発プロセス作成システムは、図１３より、開発環境データを格納する入力データバッファ１、開発に必要なツールの情報を管理するソフトウェアツール情報バッファ３、開発プロセスフローチャートを管理する開発プロセスフローチャート情報バッファ４、開発プロセスフローチャートを生成する開発プロセスフローチャート作成処理部７、それを格納する出力データバッファ２、ユーザ端末と本システム間を仲介する通信制御処理部５、本システムの内部データフォーマットとユーザ端末上でのデータフォーマット間の変換をする入出力データ処理部６から構成される。
【０００５】
このような従来の開発プロセス作成システムは、以下のように動作する。
【０００６】
ユーザ端末から通信制御処理部５を介して送られてきたプログラム開発言語、開発マシン、動作環境などの開発環境データをいったん入力データバッファ１に格納し、入出力データ処理部６においてそのデータを所定のフォーマットに変換する。すると、開発プロセスフローチャート作成処理部７は変換されたデータをもとに、ソフトウェアツール情報バッファ３および開発プロセスフローチャート情報バッファ４  からそれぞれソフトウェアツール情報と開発プロセスフローチャート情報を読み出し、それらを合成して、ソフトウェアツール名称を適宜含んだ開発プロセスフローチャートを生成し、出力データバッファ２、入出力データ処理部６、通信制御処理部５を経て、生成結果の開発プロセスフローチャートがユーザ端末上に表示される。
【０００７】
【特許文献１】
特開平４−２３７３２９号公報
【０００８】
【発明が解決しようとする課題】
しかしながら、従来の開発プロセス作成システムにおいては、次のような課題がある。
【０００９】
開発プロセスの実施において、有効なソフトウェアツールを示すことに主眼を置き、開発環境によって変動する部分をツールの名称のみとしたため、開発プロセス自身（例えば「画面設計をする」という作業そのもの）は、そういった開発環境により変動できないということである。また、ある開発環境におけるツールは一つのみと決め打ちしており、複数の選択の余地が残されてないと言うことである。
【００１０】
本発明の目的は、開発環境を含めたプロジェクト特性を加味して、開発プロセスそのものを自動的に加工して、選択幅を残しつつ、ユーザに提示する、プロジェクト特性評価による開発プロセス作成システム及びそれを用いた開発プロセス作成方法を提供することにある。
【００１１】
【課題を解決するための手段】
本発明は、対象プロジェクト向けに開発プロセスを作成するシステムにおいて、対象としているプロジェクトが持ついくつかの特性（以後「プロジェクト特性」と記載する）をシステムに入力すると、適切なアクティビティを自動的に選択してきて、そのプロジェクトに適した開発プロセスを構成する。
【００１２】
その際に、過去に入力されたプロジェクト特性とアクティビティの選択結果の履歴情報に基づき、適切なアクティビティを選択する。
【００１３】
本発明は、以上のことを特徴としている。
【００１４】
「プロジェクト特性」とは、例えば、「開発期間」「開発規模」「開発手法」「開発言語」「対象領域」などである。開発期間や開発規模によって、しっかりと設計情報を文書化する場合もあれば、ソースコード中のコメントで代用して済ますこともある。開発手法によって、分析・設計時の着目点がオブジェクト、データ、機能などと異なることもある。このように開発プロセスに様々な影響を及ぼす性質がプロジェクト特性である。
【００１５】
本発明のプロジェクト特性評価による開発プロセス作成システムは、プロセス構成部とアクティビティ取得部とプロセスアーキテクチャデータベースとアクティビティデータベースとから構成される。
【００１６】
プロセス構成部は入力としてプロジェクト特性を受け取り、プロセスアーキテクチャデータベースから受け取ったプロセスアーキテクチャとアクティビティ取得部から受け取ったアクティビティとを合成して、要求のあったプロジェクト向けの開発プロセスを返却する。
【００１７】
アクティビティ取得部は、プロセス構成部からのアクティビティ取得要求を受けて、アクティビティデータベースから複数のアクティビティを取得する。この時、プロセス構成部から渡されたプロジェクト特性と、過去のアクティビティ選択履歴情報とに基づき、適切と思われるアクティビティのみに絞り込んで取得する。取得されたアクティビティは、プロセス構成部へ返却される。
【００１８】
なお、このようにして取得されたアクティビティはあくまで「候補」であり、その中には内容的に重複しているものがあって今回は使用しないもの、新たに追加するものなど最終的には人間の手により微調整を行う必要がある。
【００１９】
そのようにして最終決定した情報をアクティビティ取得部に対してフィードバックする。アクティビティ取得部はその情報をアクティビティ選択履歴情報としてアクティビティデータベースへ反映する。
【００２０】
ここで先述の用語、「プロセスアーキテクチャ」「アクティビティ」「プロジェクト特性」および後述する「プロセスアーキテクチャ要素」について補足説明をしておく。
【００２１】
開発プロセスを形作るための骨格全体を指すものがプロセスアーキテクチャ、その骨格をいくつかに区分けした各部分がプロセスアーキテクチャ要素、その骨格に肉付けするための交換可能な部品がアクティビティである。
【００２２】
そしてプロジェクトの性質を表すもののうち、特にそれによって開発プロセスに影響を及ぼすようなものがプロジェクト特性である。
【００２３】
以下、もう少し具体例を用いて説明する。
【００２４】
開発プロセスを考えた場合、一般的にいくつかの工程に分けて考えることができる。例えば「設計」して、次に「実装」して  最後に「テスト」するというようにである。
【００２５】
この開発プロセスを分解した「設計」「実装」「テスト」と言った個々の要素を「プロセスアーキテクチャ要素」と呼び、「設計」→「実装」→「テスト」と言うように各プロセスアーキテクチャ要素間を関連付けて構成した開発プロセスの骨格全体像を「プロセスアーキテクチャ」と呼ぶ。
【００２６】
この典型的な例がＩＳＯ／ＩＥＣ１２２０７であり、その中の「Ｄｅｖｅｌｏｐｍｅｎｔ  ｐｒｏｃｅｓｓ」が「プロセスアーキテクチャ」であり、「Ｐｒｏｃｅｓｓ  ｉｍｐｌｅｍｅｎｔａｔｉｏｎ」「Ｓｙｓｔｅｍ  ｒｅｑｕｉｒｅｍｅｎｔｓ  ａｎａｌｙｓｉｓ」といった「ａｃｔｉｖｉｔｙ」が「プロセスアーキテクチャ要素」である。
【００２７】
ところで「設計」はさらにいろいろな設計作業が考えられる。例えばＤＢを使用するシステム開発の場合、「ＤＢアクセス部品設計」がある。さらにこの部分は、例えばプロジェクトで使用する開発言語によって、Ｃ／Ｃ＋＋なら「ＯＤＢＣを使用してＤＢアクセス部品を設計する」、Ｊａｖａなら「ＪＤＢＣを使用してＤＢアクセス部品を設計する」というように開発プロセスが変わってくる。
【００２８】
この例の「開発言語」のように開発プロセスに影響を及ぼすプロジェクトの性質を「プロジェクト特性」と呼ぶ。
【００２９】
そして「ＯＤＢＣを使用してＤＢアクセス部品を設計する」のように、プロセスアーキテクチャ要素をより具体化したもので、かつ、プロジェクト特性によって変化するものを「アクティビティ」と呼ぶ。
【００３０】
ＩＳＯ／ＩＥＣ１２２０７中にも「ａｃｔｉｖｉｔｙ」という用語があるが、本願発明における「アクティビティ」とは同義ではなく、「アクティビティ」の方が概念的により詳細で具体的な作業内容のことを指している。
【００３１】
このようにして、本願発明では、開発プロセスを大きく「プロセスアーキテクチャ」と「アクティビティ」に分解して管理し、またアクティビティ選択時において過去の選択結果履歴情報を活用するので、対象プロジェクト向けの開発プロセスを自動で、かつそのプロジェクトに適した形で作成することができる。
【００３２】
なお、本願発明において、「プロジェクト特性」「プロセスアーキテクチャ要素」「アクティビティ」の内容に関して、特に具体的な指定はしない。最低限以下の要件を満たすものであればよい。
【００３３】
・プロジェクト特性…「アクティビティ」を選択する際の判断基準となるもの。
【００３４】
・プロセスアーキテクチャ要素…「プロジェクト特性」の影響を受けることなく固定的に規定できるもの。
【００３５】
・アクティビティ…「プロジェクト特性」により変動するもので、かつ「プロセスアーキテクチャ要素」を詳細化かつ具体化したもの。
【００３６】
【発明の実施の形態】
（発明の第１の実施の形態）
図１は、本発明の第１の実施の形態としての開発プロセス作成システムの構成を示している。図１において、プロセス構成部１１は入力としてプロジェクト特性を受け取り、その情報を基にプロセスアーキテクチャとアクティビティとを合成して、対象プロジェクト向け開発プロセスを作成し、返却する。
【００３７】
プロセスアーキテクチャデータベース１２はプロセス構成部１１からのプロセスアーキテクチャ取得要求により、プロセスアーキテクチャをプロセス構成部１１へ返却する。
【００３８】
アクティビティ取得部２１はプロセス構成部１１より入力としてプロジェクト特性と要素ＩＤを受け取り、適切なアクティビティをプロセス構成部１１へ返却する。
【００３９】
また、選択したアクティビティに対して人間による最終決定のフィードバック情報をアクティビティ選択履歴情報として、アクティビティデータベース２２に反映する。
【００４０】
アクティビティデータベース２２はアクティビティ取得部２１より入力として要素ＩＤを受け取り、要求に合致するアクティビティをアクティビティ取得部２１へ返却する。
【００４１】
また、アクティビティ取得部２１よりアクティビティ最終決定のフィードバックを受け取り、該当するアクティビティの選択履歴情報を更新する。
【００４２】
以下、２つのデータベース中のデータの構造について詳細に説明する。
【００４３】
図２は、図１のプロセスアーキテクチャデータベース１２のデータ格納状況を示している。図２において、左側のフローチャートはプロセスアーキテクチャデータベースに格納したいプロセスアーキテクチャを示している。これに対して、右側はそれをプロセスアーキテクチャデータベースに格納した時の状態を示している。
【００４４】
各プロセスアーキテクチャ要素はそれぞれ「要素ＩＤ」により一意に識別可能である。
【００４５】
開発プロセスにおいてはプロセスアーキテクチャ要素間には前後関係があり、それは自分の前に来るべきプロセスアーキテクチャ要素の要素ＩＤで示し、「前要素ＩＤ」にその情報を格納する。先頭のプロセスアーキテクチャ要素の要素１の場合はそれより前に位置すべきプロセスアーキテクチャ要素が存在しないため前要素ＩＤにはＮＵＬＬが入る。
【００４６】
図３は、図１のアクティビティデータベース２２のデータ格納状況を示している。図３中の左側の項目から順に以下説明していく。
【００４７】
「アクティビティＩＤ」はアクティビティを一意に識別する情報である。
【００４８】
隣の「所属要素ＩＤ」はそのアクティビティを選択肢とするようなプロセスアーキテクチャ要素を識別するための情報である。図３の例では、図２の左側のプロセスアーキテクチャ上の要素１の箇所に入りうる選択肢としてアクティビティ１からアクティビティ３までの３つのものが存在するということを示している。
【００４９】
最後に３番目以降の「プロジェクト特性１」から「プロジェクト特性Ｎ」までの項目は、各アクティビティの、あるプロジェクト特性における選択履歴情報である。ここの項目の数は、以下の個数によって決まる。
【００５０】
・開発プロセス作成システムで取り扱うプロジェクト特性の数
・上記各プロジェクト特性ごとに取りうる特性値の数
ここで「＜選択回数＞」となっている箇所のデータの意味について説明する。
【００５１】
あるプロジェクト特性がある特性値の場合、
・選択回数が１以上なら、対応するアクティビティが選択可能。
【００５２】
・選択回数が０なら、対応するアクティビティは選択不可能。
という意味を表している。また、アクティビティ新規登録時には、初期値として１または０を入力する。
【００５３】
図３の例で言えば、アクティビティ２はプロジェクト特性の「言語」がＣ／Ｃ＋＋であるようなプロジェクト向けには選択可能であるが、Ｊａｖａを使用するプロジェクトに対しては選択不可能という意味である。これに対して、アクティビティ１は言語がＣ／Ｃ＋＋、Ｊａｖａのどちらの時でも選択可能という意味である。
なおこの「＜選択回数＞」は「人間が下した最終決定」のフィードバック情報に基づき、更新されていく。
【００５４】
図１のシステムの動作を図４、５、６に示すフローチャートを使用して説明する。
【００５５】
まず図１のプロセス構成部１１に主眼を置いて説明する。
【００５６】
図１において、プロセス構成部１１が入力としてプロジェクト特性を受け取ると、まずプロセスアーキテクチャデータベース１２から、プロセスアーキテクチャ要素の集合を取得する（図４のステップ１）。
【００５７】
次に各プロセスアーキテクチャ要素に当てはめるためのアクティビティを取得するために、プロジェクト特性と当該プロセスアーキテクチャ要素の要素ＩＤを入力としてアクティビティ取得部に要求し、対応するアクティビティ群を取得する（図４のステップ３）。
【００５８】
この動作を全プロセスアーキテクチャ要素に対して繰り返す（図４のステップ２）。
【００５９】
全プロセスアーキテクチャ要素に対するアクティビティを取得し終えたら、それらをプロセスアーキテクチャ要素間の前後関係に従って、「プロジェクト向け開発プロセス」として構築し、返却する（図４のステップ４）。
【００６０】
次に図１のアクティビティ取得部２１に主眼を置いて説明する。
【００６１】
図４のステップ３で、プロセス構成部１１がアクティビティ取得部２１にアクティビティ取得要求を出す。この時、アクティビティ取得部２１の方は、入力としてプロジェクト特性とプロセスアーキテクチャ要素の要素ＩＤを受け取る。そして、「所属要素ＩＤ＝指定されたプロセスアーキテクチャ要素の要素ＩＤ」という絞込み条件により、アクティビティデータベース２２より複数のアクティビティを取得する（図５のステップ１）。
【００６２】
次に取得してきた各アクティビティが持つプロジェクト特性に関する情報（ある特性値の時に選択可能か否か）とプロセス構成部１１から入力情報として渡されたプロジェクト特性情報とを比較して、「選択可能」なアクティビティのみにさらに絞り込む（図５のステップ２）。
【００６３】
最終的に絞り込まれたアクティビティ群を総合的な選択回数の多い順に並べ替えて、プロセス構成部１１へ返却する（図５のステップ３）。
【００６４】
ここで「総合的な選択回数」とは該当アクティビティに関して、入力情報として受け取ったプロジェクト特性の箇所の「選択回数」の総和である。
【００６５】
以上のようにして作成された開発プロセスはドラフト版とみなされ、最終的には人間の手で取捨選択の後、最終的な開発プロセスを確定する。その情報をフィードバック情報として受け取る際の動作について図６を使って説明する。
【００６６】
図１のアクティビティ取得部２１は、フィードバック情報として「プロジェクト特性」「選択されたアクティビティ（のＩＤ）」を受け取る（図６のステップ１）。
【００６７】
アクティビティ取得部２１はアクティビティデータベース２２に対して、「選択されたアクティビティ（のＩＤ）」の選択履歴情報（図３の「プロジェクト特性１」〜「プロジェクト特性Ｎ」の部分）を、受け取った「プロジェクト特性」に照らして、該当する特性値のところの「＜選択回数＞」を＋１するよう要求する（図６のステップ２）。
【００６８】
次に具体例を用いて説明する。
【００６９】
図７のように、プロセスアーキテクチャデータベース１２中には「設計」「実装」「テスト」からなるプロセスアーキテクチャがあるとする。プロセス構成部１１が入力としてプロジェクト特性を受け取ると、プロセスアーキテクチャデータベース１２から情報を受け取り、図７の左のような構造を理解する。
【００７０】
次に「設計」「実装」「テスト」それぞれに当てはめるべきアクティビティの取得に移る。例では「実装」のアクティビティに関して説明する。
【００７１】
プロセス構成部１１から要求を受けたアクティビティ取得部２１は、図８のようなアクティビティデータベース２２から「所属要素ＩＤ」が「実装」のものについて絞り込む。次に絞り込まれたアクティビティに対してプロジェクト特性によるチェックを行う。
【００７２】
例として図９のようなプロジェクト特性が与えられているとする。この場合、図８で点線で囲った部分に着目し、選択可能なアクティビティ、すなわち「選択回数」が非０のものを取得する。
【００７３】
図８の例では「×」のついている「ＪＤＢＣでＤＢ部品実装」「Ｓｗｉｎｇで画面部品実装」が対象からはずれることになる。
【００７４】
対象が絞り込まれたところで「総合的な選択回数」順に並べる。「ＤＢ部品実装」は２＋４＝６、「ＯＤＢＣでＤＢ部品実装」は５＋３＝８、「画面部品実装」は３＋４＝７である。以上の結果順に並べられ、対象アクティビティがプロセス構成部１１へ返却される。
【００７５】
プロセス構成部１１では、プロセスアーキテクチャと返却されたアクティビティを合成して、ドラフト版の開発プロセスを作成する。それが図１０である。
【００７６】
そして最後に人間の手で取捨選択をし、最終的な開発プロセスとする。取捨選択した結果が、図１０の点線で囲った部分である。
【００７７】
この結果がアクティビティ取得部２１に伝えられ、該当するアクティビティの選択履歴情報（図８中の二重丸で囲った部分）が＋１される。
【００７８】
（発明の第２の実施の形態）
本発明の第２の実施の形態として、その基本的構成は第１の実施の形態の通りであるが、アクティビティデータベース２２中のデータ格納イメージについてさらに工夫している。その構成を図１１に示す。本図において、先の図８のデータ格納イメージと比較して、点線で囲った「カテゴリ」という項目が追加されている点が異なっている。これは、アクティビティの並べ替えにおいて類似アクティビティを識別するための情報である。
【００７９】
図１１の例では、５つのアクティビティに対して「ＤＢ実装」「画面実装」という大きく２つのカテゴリに分類している。
【００８０】
人間による最終的な取捨選択の判断において、類似アクティビティが複数ある場合、そのうちのどれか一つのみが選択される可能性が高い。図１０の例において、アクティビティ数が非常に多い場合に、それらを一様に並べ替えてしまうと、類似アクティビティが散らばってしまい、見落とす可能性が高くなる。
【００８１】
故に、図５のステップ３について並べ替えは類似アクティビティ同士で行うようにし、ドラフト版開発プロセスを表示する際には、カテゴリごとに固めて表示するようにする。
【００８２】
その結果の例が図１２である。図１０の例と比べて、アクティビティの並び方がカテゴリごとに固まって表示されるようになったのがわかる。
【００８３】
このように、本実施の形態では、ドラフト版開発プロセスを表示する際にカテゴリごとにまとめて表示しているので、人間が最終的に取捨選択する際の類似アクティビティの見落としが減るという効果が得られる。
【００８４】
なお、本構成において、カテゴリは図１１の例のような１階層のみでなく、Ｎ階層のカテゴリを用意してもよい。例えば、大・中・小分類という３階層のカテゴリ情報にしてもよい。
【００８５】
【発明の効果】
以上説明したように、本発明においては、以下に記載するような効果を奏する。
【００８６】
第１の効果は、開発プロセスを、全体的な作業の流れを定義しているプロセスアーキテクチャと、個々の作業の詳細を定義しているアクティビティとに分割して管理しているので、局所的に修正するだけで様々な開発プロセスにも柔軟に対応できることである。
【００８７】
例えば、新たなスタイルとして「テストの設計」作業を従来のスタイルよりも、かなり前の段階で行うようにしたければ、プロセスアーキテクチャの定義だけを変えれば済む。また、新たな開発言語に対応させたければアクティビティの追加だけを行えばよい。
【００８８】
第２の効果は、「プロジェクト特性」という入力情報を採用しているので、そのプロジェクトに適切な開発プロセスを機械的に作成することが可能なことである。
【００８９】
第３の効果は、「アクティビティ選択履歴情報」を活用しているので、本システムを使えば使うほど、傾向的な面から適切と思われる開発プロセスを作成できる可能性が高くなっていくことである。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態としての開発プロセス作成システムの構成を示す図である。
【図２】図１のプロセスアーキテクチャデータベースのデータ格納状況を示す図である。
【図３】図１のアクティビティデータベースのデータ格納状況を示す図である。
【図４】図１のシステムの動作をプロセス構成部に主眼を置いて説明するフローチャートである。
【図５】図１のシステムの動作をアクティビティ取得部に主眼を置いて説明するフローチャートである。
【図６】最終的な開発プロセスを確定し、その情報をフィードバック情報として受け取る際の動作を説明するフローチャートである。
【図７】プロセスアーキテクチャの具体例を用いて説明する図である。
【図８】アクティビティデータベースの具体例を用いて説明する図である。
【図９】入力プロジェクト特性の例を示す図である。
【図１０】ドラフト版の開発プロセスの例を示す図である。
【図１１】アクティビティデータベースの具体例を用いて説明する図である。
【図１２】ドラフト版の開発プロセスの例を示す図である。
【図１３】従来の開発プロセス作成システムの構成を示す図である。
【符号の説明】
１    入力データバッファ
２    出力データバッファ
３    ソフトウェアツール情報バッファ
４    開発プロセスフローチャート情報バッファ
５    通信制御処理部
６    入出力データ処理部
７    開発プロセスフローチャート作成処理部
１１    プロセス構成部
１２    プロセスアーキテクチャデータベース
２１    アクティビティ取得部
２２    アクティビティデータベース
【図１】
2004341804.tif 000003
【図２】
2004341804.tif 000004
【図３】
2004341804.tif 000005
【図４】
2004341804.tif 000006
【図５】
2004341804.tif 000007
【図６】
2004341804.tif 000008
【図７】
2004341804.tif 000009
【図８】
2004341804.tif 000010
【図９】
2004341804.tif 000011
【図１０】
2004341804.tif 000012
【図１１】
2004341804.tif 000013
【図１２】
2004341804.tif 000014
【図１３】
2004341804.tif 000015