JP7478011B2 - プロジェクト管理システムにおける管理サーバ、管理方法及びプログラム - Google Patents

Description

本発明は、プロジェクト管理システムにおける管理サーバ、管理方法及びプログラムに関する。

近年、ソフトウェア開発において、プログラムのソースコードを解析し、プログラマのスキルを評価する方法やプログラマのスキルに基づいて精度の高い開発計画を立案する方法が知られている。

例えば、特許文献１には、ＩＴエンジニアのプログラミングスキルを評価するためのプログラミングスキル評価装置が開示されている。この技術によれば、プログラミングスキルの被評価者である求職者に対して課題となるプログラミング要件を求人情報提供サーバから送信し、被評価者が作成したプログラムのソースコードを受信して、プログラム評価サーバでこれを実行して実行速度等からプログラミングスキルを評価する。多数の被評価者の中に悪意のある者が紛れ込み、ウィルス等の有害なプログラムが送信されるリスクに対応するために、ソースコードをプログラム評価サーバの隔離された仮想実行環境で実行し、実行後には仮想実行環境を廃棄する。

また、例えば、特許文献２には、作業フェーズに開発環境の使用能力（保有スキル）を有する開発者を割り当て、より精度の高い計画を立案することを目的とする計画生成装置等が開示されている。この方法によれば、複数の作業フェーズを含むソフトウェア開発を行うプロジェクトの計画を生成する計画生成装置において、ソフトウェア開発の開発環境の運用計画を表す開発環境計画情報を記憶する開発環境計画記憶部と、ソフトウェアを開発する開発者に対し、開発者のスケジュールと、ソフトウェア開発の開発環境の使用能力とを含む属性とを対応付けた担当者属性情報を記憶する担当者属性記憶部と、開発環境計画情報と担当者属性情報とに基づいて、複数の作業フェーズの各作業フェーズを実施する予定の期間に、作業フェーズに用いられる開発環境の使用能力を有する開発者を担当開発者として割り当てることの可否を判定し、担当開発者を割り当てることができる場合に、予定の期間に担当開発者を割り当てた計画情報を生成する計画情報生成部を備えている。

また、ＡＩ(Artificial Intelligence)の技術を活用して、複数のソースコードを機械学習させ、ソースコードの読みやすさを評価する方法も知られている。例えば、非特許文献１に記載の技術は、ソースコードのレビュー作業の効率化と精緻化を支援するツールであり、画像化されたソースコードを基に、ＡＩが主にソースコードの可読性を診断する。このツールで可読性が低い箇所に当たりを付け、該当箇所を集中的にレビューすることによって、レビューワは、作業の効率化と精緻化が見込めるようにしている。

特開２０１５－１４３８９０号公報 特開２０１８－１４２２６４号公報

日経ｘＴＥＣＨ（クロステック）、"ソースコードの不備をＡＩで見つける富士通、新しい診断ツールの中身"、［ｏｎｌｉｎｅ］、［令和２年２月２５日検索］、インターネット、< https://xtech.nikkei.com/it/atcl/column/14/346926/122501258/#>

しかしながら、人間は日々成長するものであるので、定期的に評価を更新し開発計画も更新できるようにする必要がある。特に、大型のシステム開発は、非常に多くのプログラマ（数百人規模）が関わり、完成後も長期にわたり保守が続くため、ソースコードの見易さやメンテナンスのしやすさは、非常に重要であり、プロジェクトの成功か否かを左右するといっても過言ではない。

上記の特許文献１，２の技術は、ソースコードの解析を通じてプログラマのスキルを評価したり、開発計画を生成したりするものではあるが、プログラム自体の評価だけでなく、見易さやメンテナンスのしやすさを主な判定基準に開発担当者の保守性の高いソースコードの作成能力を評価するものではなかった。また、プログラムが実環境で使用される利用頻度の観点から品質の評価値を求めるものではなかった。ソースコードの保守性は、特許文献１に係る発明がスキルの評価項目とする少なくとも「ソースコードの実行速度」や「ソースコード実行時の使用メモリ量」よりも重視要素である。

したがって、本発明は、上記の非特許文献１に記載のＡＩツールも活用し、プログラマ別にソースコードの作成スキルを評価しつつも、プログラムの機能単位であるモジュールごとの保守性を、プログラムの実環境での利用頻度を考慮して、客観的・定量的に評価できるシステムを提供することを目指している。より具体的には、プログラムの開発時におけるソースコードの評価において、プログラムの実際の利用環境で想定されるモジュールごとの利用頻度を指標として、評価基準を設定することを第１の目的とする。

また、開発が終了し、プログラムのリリース後の保守の際には、既存のモジュールに対してロジックを後付けで追加することで機能強化が行われることが多いため、一般的に、保守が行われるたびにソースコードの見易さが低下することが多い。その結果、保守性が低下し、長年にわたって使用されるプログラムは、いずれ全面的な改定が必要となる更改時期を迎えることになる。従来、この更改時期は、サーバ等の更改時期、すなわち、ハードウェアの寿命に併せて行われることが多かったが、それとは別に、プログラムそのものの更改時期を客観的・定量的に判定できれば「プログラムの寿命」を知ることができる。したがって、本発明の第２の目的は、長期にわたるプログラムの保守期間において、プログラムの更改時期を客観的・定量的に判定できるシステムを提供することである。

上記第２の目的を達成するため、本発明は、以下のような解決手段を提供する。

（１）プログラムの保守管理システムにおける管理サーバであって、前記プログラムの機能単位であるモジュールの識別子に、当該モジュールのソースコード及び当該ソースコードの変更日時を対応付けて格納するソースコードライブラリと、前記ソースコードライブラリのソースコードを解析し、その解析結果に基づいて、当該ソースコードの保守性に関する品質の評価値を算出するソースコード品質評価部と、前記プログラムの保守期間において、前記保守性に関する品質の評価値が所定の基準値を下回ることが予想される場合、前記プログラムの全面的な改定が必要となる更改のタイミングを判定する保守品質判定部と、を備えることを特徴とする。

（２）上記（１）の構成において、前記保守期間における品質評価方法は、開発時において用いられた保守性の品質評価方法と同じとすることを特徴とする。

（３）上記（１）又は（２）の構成において、前記保守期間における品質の評価値の算出は、前記モジュールごとの変更の頻度に応じて行われることを特徴とする。

（４）上記（１）から（３）のいずれかの構成において、前記更改の要否は、前記モジュールごとの評価値の加重平均が所定の基準値を下回ったときに判定することを特徴とする。

（５）プログラムの保守管理における管理方法であって、前記プログラムの機能単位であるモジュールの識別子に、当該モジュールのソースコード及び当該ソースコードの変更日時を対応付けてソースコードライブラリに格納するステップと、前記ソースコードライブラリのソースコードを解析し、その解析結果に基づいて、当該ソースコードの保守性に関する品質の評価値を算出するステップと、前記プログラムの保守期間において、前記保守性に関する品質の評価値が所定の基準値を下回ることが予想される場合、前記プログラムの全面的な改定が必要となる更改のタイミングを判定するステップと、をコンピュータが実行することを特徴とする。

（６）コンピュータのプログラムであって、上記（５）に記載の各ステップをコンピュータに実行させることを特徴とする。

本発明によれば、プログラムの保守期間において、プログラムムの更改時期を客観的・定量的に判定できるシステムを提供することができる。

本発明の実施形態に係る保守管理システムのシステム構成を示す図である。 上記保守管理システムの管理サーバの機能ブロックを示す図である。 本発明の実施形態に係るシステムの開発期間における品質評価手順を示す図である。 本発明の実施形態に係るシステムの保守期間における品質評価手順を示す図である。 本発明の実施形態に係るシステムの開発期間における開発品質管理テーブルの概略を示す図である。 本発明の実施形態に係るシステムの保守期間における保守品質管理テーブルの概略を示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号又は符号を付している。また、機能構成の図において、機能ブロック間の矢印は、データの流れ方向、又は処理の流れ方向を表す。

図１は、本発明の実施形態に係る保守管理システム（以下、本システムと呼ぶ）のシステム構成を示す図である。本システムは、発明者らの別出願である開発時におけるソースコードの評価システムを保守管理に応用したものである。

本システムは、特に大規模プロジェクトにおいて、数十人～数百人規模の開発プログラマが作成したソースコードの保守を管理するため、保守担当のプログラマに割り当てられたプログラマ端末１０と、変更されたソースコードを集積し、管理するための管理サーバ１００と、システムを監視し、管理するための管理者端末２０とがネットワークを介して接続される。

管理サーバ１００は、データベースとして、ソースコードライブラリ１０１と、機械学習データ１０２と、利用頻度データ１０３と、運用実績データ１０４と、開発計画データ１０５と、保守計画データ１０６とが交信可能に接続される。

ソースコードライブラリ１０１は、プログラマによって作成又は変更されたソースコードファイルを、プログラムの機能単位であるモジュールの識別子（ＩＤ）に、当該モジュールのソースコード及び当該ソースコードの作成日時又は変更日時を対応付けて格納するデータベースである。また、ソースコードライブラリ１０１は、作成者のプログラミングスキル（対応可能なプログラミング言語、経験年数、過去のプロジェクトにおける役割等）を格納した個人別情報をモジュールＩＤに関連付けてもよい。

機械学習データ１０２は、ＡＩ技術を活用して、ソースコードを解析するための機械学習データを格納するデータベースである。

利用頻度データ１０３は、実環境で想定される利用頻度（画面のユーザのアクセス頻度又は画面以外の装置若しくは他のモジュールとのアクセス頻度）をモジュールごとに格納したデータベースである。利用頻度は、設計者の想定値、及び過去の類似モジュールがあれば、その実績データに基づいて決定される。利用頻度について詳しくは後述する。

運用実績データ１０４は、開発を終了し、リリース後の実際の利用頻度（アクセス頻度）のデータをモジュールごとに格納したデータベースである。運用実績データ１０４は、過去の類似プロジェクトの実績データを含む。

開発計画データ１０５は、プロジェクトの開発計画を格納するデータベースである。開発計画にはモジュール単位の開発計画も含む。

保守計画データ１０６は、プログラムのリリース後の保守計画とその実績を格納したデータベースである。

ただし、このようなシステム構成に限定されるものではなく、例えば、管理サーバ１００が複数で構成されてもよいし、管理サーバ１００からデータベースを分離し、データベース及びそのデータベースサーバが別に構成されてもよい。

図２は、本システムの管理サーバ１００の機能ブロックを示す図である。この実施形態では、管理サーバ１００に、上記のデータベース（データ格納手段）が接続され、各データベースを参照しながら個々の機能を実行する機能実行部（機能実行手段）が示されている。機能実行部としては、ソースコード解析部１１０と、ソースコード品質評価部１１１と、評価基準設定部１１２と、開発品質判定部１１３と、開発計画更新部１１４と、保守品質判定部１１５と、保守計画更新部１１６とを備えている。ただし、このような構成に限定されるものではない。

ソースコード解析部１１０は、プログラマが作成したソースコードを、定期的又は指示されたタイミングでソースコードライブラリ１０１から読み出し、その時点までに作成されたソースコードを、モジュール（１つの機能を有するプログラム単位）ごとに解析する。特に、コメントの適切さ、ネストの深さなどが解析される。

ソースコード品質評価部１１１は、ソースコード解析部１１０の解析結果に基づいて、場合によっては機械学習データ１０２も参照し、前述の品質評価値を算出する評価ツールである。一つのモジュールを複数のプログラマが担当する場合は、プログラマごとの評価も行う。ただし、モジュールのソースコードが前回の品質評価時から変更されていない場合は、そのモジュールの評価をスキップするようにしてもよい。このようにすることで、効率的な判定ができる。また、ここでの評価項目は、開発時だけでなく保守時にも適用できるように同じものを用いてよく、その場合はソースコードの可読性などの保守性に関する評価項目とすることが望ましい。なお、評価項目に対する各モジュールの評価値を算出する方法は公知の技術を活用してもよい。すなわち、このときの評価ツールは、前述したように、既存のソースコード評価システムを利用してもよい。例えば、非特許文献１のＡＩを活用したソースコード評価ツールを用いて、ソースコードの読み易さ（可読性）を評価項目としてもよい。さらに、別の評価ツールを併用してもよい。ソースコードの可読性には、適切なコメントがあるか、ネストの深さが適切か、その他プログラミングのルールに沿っているかなどが評価項目としてあげられる。

また、ソースコード品質評価部１１１は、ソースコードライブラリ１０１の個人別情報を用いて以下の活用も可能である。

（個人別の複数の時点の評価の活用）
評価は、通常、ソースコードライブラリ１０１に記憶されたソースコードをある程度まとまった単位で評価するが、同一の個人識別情報が対応付けられたソースコードを抽出して評価することで、個人別作業の評価が可能となる。また、個人別作業の評価である２時点間の評価を比較したときに、以前よりも評価が高くなっていれば、評価を上げるための術を習得していると評価できる。つまりは保守性の高いソースコードを作る技術を習得していると言える。このような個人別の評価は、開発計画の中での人員配置（再配置）の判断指標とすることができる。

（開発予定期間終了日とソースコードの作成・更新日の活用）
期限より早く完了した者同士を比較したときに、早くて保守性の高いソースコードを作れる者と、早いが保守性の低いソースコードになってしまう者とに線引きができる。同様に、期限ぎりぎりに完了した者同士、期限超過した者同士でも、同じ線引きが可能となる。このように分析することで、いうなれば個人の特性と能力に基づいた人員計画への反映が可能となる。なお、開発期間終了日に限らず、所定の基準日を設けて同様に評価することも可能である。

（ソースコードの履歴情報の活用）
作成日付及び更新日付を複数時点で記憶し、当該複数時点ごとのソースコードが管理されている場合（または履歴上の日付ごとの評価を記憶していてもよい）は、全ソースコードを同じタイミングで評価するのではなく、例えば最初の作成日直後の評価と最終更新日直後の評価を比較することも可能となる。つまり、ソースコードの評価をある日時（２０２０年３月３１日）基準に一括評価するのではなく、最初の作成日と１回目の更新の期間で評価がどう変わったか、また完了直前の評価と完了後の評価でどの程度違いがあるかなどをソースコードごとに知ることが可能である。何度修正を加えても評価が変わらない者（高い評価のままと低い評価のままが考えられる）、更新を経るごとに評価が高くなる者、更新を経るごとに評価が下がってしまう者などが考えられる。このように、同一基準日でなく、個別のソースコードの更新履歴を追うことできめ細かい評価ができる。
また、上記の評価の変化を検出し、総合的に評価することできめ細かな人員計画も可能となる。

評価基準設定部１１２は、ソースコード品質評価部１１１が評価を行った結果を定量的に判定するための評価基準を設定する。ここでは、モジュールごとの、場合によってはプログラマごとも、品質基準値及び更改基準値を設定する。この設定は、通常はプロジェクトの管理者が行う。ここで、品質基準値とは、開発時におけるソースコード品質の合否の基準値を定めるものであり、リリースしてよいかの判断基準である。具体的には、評価の最高値（理想的なパーフェクト値）を１００とすれば、各プログラムがリリース時に最低クリアすべき評価値を、例えば、７０～８０のように設定する。モジュールごとに作成難易度、実環境で利用される頻度が異なるので、モジュールごとに品質評価値を定める。ここで、モジュールが利用される頻度が高いものほど（例えば、そのモジュールの機能を利用するときの画面のアクセス頻度が高いもの）、他のモジュールより品質基準値を高くする。画面のアクセス頻度（例えば、１日の画面表示の想定回数）は、過去の類似のモジュールのデータから予想したものを利用頻度データ１０３に格納しておく。また、モジュールの機能が画面以外の入出力装置又は他のモジュールとの直接又は間接のアクセスを伴う場合は、そのアクセスの想定頻度をアクセス頻度としてもよい。

また、プログラムのロジックが複雑で作成の難易度が高いと判断されるモジュールは、品質基準値を他のモジュールより下げるようにしてもよい。その場合は、過去のプロジェクトの統計データを用いて、評価値を、評価ツールが出力したそのままの値（Raw Score）ではなく、スコアの同一化（Equating）と呼ばれる統計処理によって算出された換算値（Scaled Score）を用いるようにしてもよい。このようにすることで、評価値がプログラムの難易度に依存しないようにすることもできる。

また、評価基準値は、プログラムが稼働する企業の業種別に基準値が異なるようにしてもよい。保守作業が定期的、頻繁に行われる企業、例えば、金融機関においては基準値を高くするなどである。

更改基準値とは、保守開始後の将来の更改時期（プログラムを全面的に見直して改定が必要な時期であり、例えば、７年～１５年後）を判定するための基準値である。前述したように、プログラムは修正を繰り返すと、コードが複雑になり、リリース直後よりも多くの場合、保守性に関する評価値が下がる傾向がある。したがって、本システムでは、リリース後も所定のタイミングで、例えば半年ごと、あるいは小規模な変更が実施された直後などに、同じ評価ツールを用いて評価を繰り返す。そして、設定された更改基準値より評価が下回りそうな時点を更改必要と判断する。具体的には、リリース開始直後の各モジュールの品質評価値が７０～８０であるとすると、品質評価値が例えば６０～７０を下回ると予想された時期までに更改が必要と判断する。すなわち、このようにすることで、モジュールごとの品質評価値の下降傾向に基づいて、加重平均を取るなどして、総合評価値を算出し、プログラム全体の更改基準値を下回る時期を判定し、更改計画の作成・更新に利用することができる。

開発品質判定部１１３は、ソースコード品質評価部１１１が開発期間において算出した品質評価値を、その判定時期ごとに判定する。このとき、開発期間におけるモジュールごとの品質の判定は、利用頻度データ１０３を参照し、モジュールごとの変更の頻度に応じて行なうようにしてもよい。そうすることで、より効率的に判定の時期を決定できる。そして、開発計画データ１０５に格納されたデータを参照し、開発計画の更新（開発プログラマの入れ替え、リリース時期の更新）が必要と判定した場合は、開発計画更新部１１４に処理を渡す。また、開発品質判定部１１３は、プログラマごと、モジュールごとに、品質評価値の推移と傾向を表示する手段を備える。

開発計画更新部１１４は、プロジェクト管理者の判断を仰ぎながら、更新された開発計画を開発計画データ１０５に格納する。また、開発計画更新部１１４は、更新前のデータと更新後のデータを比較してグラフ化して表示する手段を備える。

保守品質判定部１１５は、ソースコード品質評価部１１１が保守期間において算出した品質評価値を、その判定時期ごとに算出する。このとき、保守期間におけるモジュールごとの評価値の算出は、運用実績データ１０４を参照し、モジュールごとの変更の頻度に応じて行なうようにしてもよい。そうすることで、より効率的に判定の時期を決定できる。そして、保守計画データ１０６に格納されたデータを参照して、保守性に関する品質が所定の基準値を下回ることが予想される場合、プログラムの全面改定が必要となる更改のタイミングを判定する。さらに、保守計画の更新（保守プログラマの入れ替え、更改時期の更新）が必要と判定した場合は、保守計画更新部１１６に処理を渡し、保守計画を更新させる。また、保守品質判定部１１５は、モジュールごと、プログラマごとに、品質評価値の推移と傾向を表示する手段を備える。

保守計画更新部１１６は、リリース後の保守期間全般にわたって、ソースコード品質評価部１１１が算出した品質評価値を、その判定時期ごとに判定し、保守計画データ１０６に格納されたデータ及び運用実績データ１０４を参照し、保守計画の更新（場合によっては、保守を担当する人員の増加、保守時期の変更など）が必要と判定した場合は、保守計画を更新する。ここで、運用実績データ１０４には、モジュールごと、及び/又は、モジュールが提供する画面ごとに、ユーザが実際に利用した回数、頻度などのデータが格納されている。なお、保守品質判定部１１５は、モジュールごとに、品質評価値の推移（特に保守が入った後）と傾向をグラフ化して表示する手段も備える。

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

（品質評価手順）
以下、本システムにおける開発期間及び保守期間における評価手順について説明する。なお、以降の処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。

図３は、開発期間における品質評価（開発品質評価）の手順を示す図である。まずステップＳ１０において、モジュールＩＤ、及びそのモジュールを作成したプログラマＩＤを取得する。次にステップＳ１１において、そのモジュールの目標として設定された品質評価値を取得し、更に、当該モジュールのアクセス頻度を利用頻度データ１０３から取得する。

続いて、ステップＳ１２において、アクセス頻度が所定値以上（例えば１０万回/日以上）のモジュールか否かが判定される。アクセス頻度が所定値以上の場合は、ステップＳ１４において、目標とする評価基準値を、アクセス頻度が所定値未満の場合のモジュールよりも高く設定する。アクセス頻度が所定値未満の場合は、ステップＳ１３において、標準の評価基準値を設定する。ここでは、簡単のためアクセス頻度が高いか低いかによって基準値を二段階に設定しているが、アクセス頻度に応じて多段階で設定してもよい。

最後に、ステップＳ１５において、評価基準値の未設定の別のモジュールがあるか否かを判定し、未設定のモジュールがあれば、ステップＳ１０～Ｓ１４の処理を繰り返す。

図４は、保守期間における品質評価（保守品質評価）の手順を示す図である。まずステップＳ２０において、保守計画をデータ格納手段である保守計画データ１０６から取得する。次にステップＳ２１において、保守作業が所定日後（例えば、５日～１０日程度）に終了する予定か否かを判断する。その結果、所定日内に終了する予定の場合は、ステップＳ２２において、保守作業が終了後、保守品質評価の判定を行う。この判定は保守対象のすべてのモジュールに対して実行する。また、所定日内に保守作業が終了しない場合は、いったん以降の処理を終わらせるか、図示のように、所定日が来るまで待機するようにしてもよい。ここで、ステップＳ２２で用いられる保守品質の評価方法は、開発時における評価方法と同じにすれば、次の開発時にも保守時の評価判定の結果を実績データとして利用できる。

保守品質判定の実行が終わると、続いて、ステップＳ２３において、各モジュールの判定結果が基準値よりも下回ったか否かを判定する。判定結果が基準値よりも下回った場合は、ステップＳ２４において、過去の判定結果の推移を参照し、次の更改が必要となる更改時期を判定する。例えば、全面的な改修となる更改の判定基準である品質基準値が７０と設定されていたとすると、７０未満のモジュールの数の推移から、更改時期を１年後、２年後などと判定する。判定結果が基準値を下回らなかった場合は、いったん処理を終了し、次回の判定時期（例えば数か月後～半年後など）が来たら再開する。また、判定結果によっては、全体的な更改までは必要ないが、モジュールごとの比較的小規模な保守が必要な時期を判定するようにしてもよい。

図５は、システム開発期間における開発品質管理テーブルの概略を示す図である。この表は、モジュールＩＤごとに、品質基準値が設定され、品質評価を行った判定日ごとに、判定の結果である評価点が示されている。ただし、ここでは説明を簡単にするため、一つのモジュールは一人のプログラマが担当しているものとしている。

前述したように、モジュールごとに想定される利用頻度（アクセス頻度）が異なるので、品質基準値は、アクセス頻度の高いモジュールほど、その他のモジュールよりも高く設定する。アクセス頻度は、一般的な銀行システムを例にとると、入出金明細機能、振込・振替機能、投資信託に関する機能などを処理する画面は、他の画面よりもアクセス頻度が高いとすると、それらの画面に対応する品質基準値を、アクセス頻度の比較的低い画面よりも高くする。画面ごとのアクセス頻度は、過去の類似のプロジェクトの実績値から予測することができる。ただし、過去の類似例にない新機能の画面の場合は、まずはアクセス頻度が高いと仮定してもよい。

このようにすることで、プログラムの開発時におけるソースコードの評価において、プログラムの実際の利用環境で想定されるモジュールごとのアクセス頻度を考慮して、評価基準を設定することができる。その結果、一律の基準を設けることに比べて、より有効な評価をすることができる。

図５の開発品質管理テーブルでは、モジュールごとの機能が示され、品質基準値は、説明を簡単にするため、アクセス頻度が高いモジュールは８０、アクセス頻度が低いモジュールは７０と設定している。また、品質評価の判定時期は、ここでは、開発がスタートしてから半年ごとと設定しているが、このような定期的な判定だけでなく、仕様変更、スケジュール変更、プログラマの変更などのイベントの後にも行うなど柔軟に設定してもよい。

また、この例の開発品質管理テーブルでは、開発が進むにつれて評価点が上がっていく、すなわち、品質が向上していく様子が示されているが、一般的には、開発初期の段階では、プログラムのコードの完成度が低く、コードが完成していくにつれて、評価点は上がったり下がったりする。そのため、図示は省略しているが、各判定日ごとに異なる品質基準値を設けてもよい。ただし、少なくともリリース前には、あらかじめ定められた品質基準値をすべてのモジュールがクリアしているか否かを判定する必要がある。そのためには、定められた判定日だけでなく、各プログラマは、定期診断の前のプレ診断として、自分が作成したプログラムの評価を個々に自発的に行なうように奨励してもよい。

このように、開発品質管理テーブルを作成し、各判定日の評価値を記録していくことで、開発品質の推移を定期的又は不定期に、客観的・定量的に把握することができる。また、開発したプログラムがリリースの基準に達しているかも判断することができる。万一、所定の基準に達していない場合は、開発計画を見直したり、遅れているモジュールのプログラマを増員又は再配置したり、リリース時期を再検討したりすることができる。

図６は、システム保守期間における保守品質管理テーブルの概略を示す図である。この表は、開発時の品質評価テーブルを保守時にも拡張したもので、保守を担当したプログラマＩＤとモジュールＩＤごとに、品質評価を行った判定日ごとに、判定の結果である評価点が示されている。一般に開発時のプログラマが保守を担当するとは限らない。また、一つのモジュールに対して複数のプログラマが担当することもあるし、途中でプログラマが交代する場合もある。図の例ではモジュールＭ００１５０は、判定日１の段階からプログラマＰＭ２０３５が増員され、モジュールＭ００３５０は、判定日２の段階でプログラマＰＭ２１２０からプログラマＰＭ２１２５に交代したことが示されている。

この例の保守品質管理テーブルでは、保守期間が進むにつれて判定日ごとに評価点が下がっていく様子が示されている。これは前述したように、保守時には障害対処の他、小規模な機能拡張が行われることも多いので、その結果、既存のモジュールにロジックが追加され、その結果プログラムが肥大化し、見易さという点では品質が徐々に低下していくことがよくあるからである。

また、保守期間が長期化し、全面的な更改が必要となるタイミングを予想するため、更改基準値が設定される。この更改基準値もモジュールごとに設定され、更改が必要か否かも所定の時期に判定が行われる。モジュールごとの結果を総合判定し、システム全体の更改の必要な時期を予想する。

このようにすることで、長期にわたる保守期間においても、プログラムの更改時期を客観的・定量的に判定することができる。より具体的には、保守品質管理テーブルを作成し、各判定日の評価値を記録していくことで、保守品質の推移を定期的又は不定期に、客観的・定量的に把握することができる。また、保守しているプログラムの保守品質が、更改が必要となるレベルまで落ち込んでいるか否かも判断することができる。品質の低下が予想よりも早く、あらかじめ計画された更改時期よりも早める必要があったり、逆に品質の低下が少なく、更改を延期してもよいと判断される場合は、保守計画を見直したり、次のバージョンの開発計画を見直したりすることができる。

（実施形態の効果）
本システムによれば、長期にわたる保守期間においても、プログラムの更改時期を客観的・定量的に判定することができる。
また、保守期間における品質評価方法は、開発時において用いられた保守性の品質評価方法と同じとすることで、保守時のデータを開発時にもフィードハックすることができる。
また、保守期間における品質の判定は、モジュールごとの保守の頻度に応じて行なえば、より効率的に判定の時期が決定できる。
また、更改の要否は、モジュールごとの評価値の加重平均が所定に基準値を下回ったときに判定すれば、プログラム全体の更改の要否が容易に判定できる。

なお、上記の実施形態では、主に大規模プロジェクトを念頭にプロジェクト管理システムについて説明したが、中小規模のプロジェクトにも適用が可能である。

また、本発明は、物の発明として、プロジェクト管理システムにおける管理サーバとして主に説明したが、本発明は、管理方法の発明又はコンピュータ・プログラムの発明としても捉えることができる。

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

１０ プログラマ端末
２０ 管理者端末
１００ 管理サーバ
１０１ ソースコードライブラリ
１０２ 機械学習データ
１０３ 利用頻度データ
１０４ 運用実績データ
１０５ 開発計画データ
１０６ 保守計画データ
１１０ ソースコード解析部
１１１ ソースコード品質評価部
１１２ 評価基準設定部
１１３ 開発品質判定部
１１４ 開発計画更新部
１１５ 保守品質判定部
１１６ 保守計画更新部

Claims (5)

1. プログラムの保守管理システムにおける管理サーバであって、
   前記プログラムの機能単位であるモジュールの識別子に、当該モジュールのソースコード及び当該ソースコードの変更日時を対応付けて格納するソースコードライブラリと、
   前記ソースコードライブラリのソースコードを解析し、その解析結果に基づいて、当該ソースコードの保守性に関する品質の評価値を算出するソースコード品質評価部と、
   前記プログラムの保守期間において、前記保守性に関する品質の評価値が所定の基準値を下回ることが予想される場合、前記プログラムの全面的な改定が必要となる更改のタイミングを判定する保守品質判定部と、
   を備えることを特徴とする管理サーバ。
2. 前記保守期間における品質評価方法は、開発時において用いられた保守性の品質評価方法と同じとすることを特徴とする請求項１に記載の管理サーバ。
3. 前記更改の要否は、前記モジュールごとの評価値の加重平均が所定の基準値を下回ったときに判定することを特徴とする請求項１又は２に記載の管理サーバ。
4. プログラムの保守管理における管理方法であって、
   前記プログラムの機能単位であるモジュールの識別子に、当該モジュールのソースコード及び当該ソースコードの変更日時を対応付けてソースコードライブラリに格納するステップと、
   前記ソースコードライブラリのソースコードを解析し、その解析結果に基づいて、当該ソースコードの保守性に関する品質の評価値を算出するステップと、
   前記プログラムの保守期間において、前記保守性に関する品質の評価値が所定の基準値を下回ることが予想される場合、前記プログラムの全面的な改定が必要となる更改のタイミングを判定するステップと、
   をコンピュータが実行することを特徴とする管理方法。
5. 前記請求項４に記載の各ステップをコンピュータに実行させることを特徴とするプログラム。

Images