JP2004192644A - 電子ソフトウェア設計仕様文書検証方法及び装置、並びにコンピュータ可読媒体 - Google Patents

Abstract

【課題】設計仕様検証ツール付きのソフトウェア開発環境を提供する。
【解決手段】自動化された設計仕様検証ツールが、設計仕様の第１セクションで定義されている１つまたは複数の関数について、各関数名が同一設計仕様の第２セクションで宣言されているかどうかを自動的に判定する。さらに、第１セクション内の各関数に関連するパラメータ名が第２セクションで宣言されているかどうか、および第１セクション内の各関数に関連するクラス属性名が第３セクションで宣言されているかどうかを判定することができる。検証プロセスの結果は報告することができる。実施形態では、第１セクションは関数定義セクションであり、第２セクションは関数リストセクションであり、第３セクションはクラス属性セクションであって、それぞれ設計仕様文書のクラス仕様の一部である。
【選択図】 図２４

Description

本発明は、包括的には、製品開発プロジェクト管理に関し、特に、電子ソフトウェア設計仕様を自動的にチェックし検証する技術に関する。

［関連出願への相互参照］
本出願は、「Ａutomated Ｍanagement Ｏf Ｄｅvelopment Ｐrojecｔ Ｆiles Ｏver Ａ Ｎetwork」と題する米国特許出願第０９／８８１，２５０号、および「Ｐroject Ｍanagement Ｏver Ａ Ｎetwork Ｗith Ａutomated Ｔask Ｓchedule Ｕpdate」と題する米国特許出願第１０／０５９，６５４号に関連し、これら両方の内容は、事実上本明細書に完全に記載されているかのごとく、全体として参照により本明細書に援用される。

製品開発プロジェクトは通常、監視および管理のための多大な努力を必要とする。さらに、コンピュータソフトウェア開発プロジェクトは本質的に管理が困難である。この困難は、部分的には、ソフトウェアパッケージを構成するタスクおよび関連する成果物が多数であること、ならびにこれらのタスクおよび成果物に関連する事務処理およびプロジェクトファイルが膨大であることに起因する。もう１つの寄与要因は、ソフトウェアパッケージの開発サイクル中に個別のタスクと成果物の間に確立される複雑な相互依存関係である。さらにもう１つの寄与要因は、開発中のソフトウェアに関連する設計仕様を生成し保守する必要があることである。

開発プロジェクトの管理は通常、プロジェクト文書、スケジュール等を編成し、保守し、およびそれらへのアクセスを制御することを含む。さらに、企業組織内で複数の開発プロジェクトが同時並行して行われているために文書管理労力が相当拡大している場合も多い。従来、マスタープロジェクトスケジュールの管理は、他のタスクのうちでもとりわけ、スケジューリングアプリケーションにデータを手入力すること、スケジュール間のリンクを手動で作成すること、および個別の開発者のタスクスケジュールをマスタープロジェクトスケジュールに手動で集約することを伴う。これらは面倒で誤りやすいタスクであり、監督および品質管理はほとんどまたは全くない。

マスタープロジェクトスケジュールは、しばしば絶え間なく変化しており、そのため管理側は開発者に、タスクステータスおよび関連するスケジュール更新を要請する。開発者によって管理側に提供されるフィードバックはほとんど監督がなく、したがって厳格なポリシー、手順、または検証プロセスに従っていないことが多い。このため、プロジェクトスケジュールの実際のステータスは確認が困難であることが多い。というのは、個人のタスクの進度は、そのタスクに割り当てられた個人による主観的な、しかもしばしば自分に有利な進度レポートによって決定されるからである。

例えば、いくつかのスケジューリングシステムでは、開発者は、タスクが部分的に完了したこと、例えば９０パーセント完了したことを表明することができる。そしてこの情報は、プロジェクトがスケジュール通りであるかどうかを判定するためにスケジューリングシステムに入力される。しかし、一般に、個人のステータスが信頼できるかどうかについての説明責任はないため、プロジェクトステータスを取得する現在のプロセスは、プロジェクトの現実の進度を隠蔽しがちである。

上記の点に鑑みると、相互依存的な開発プロジェクトのタスクスケジュールを管理するための、それに関連する手作業を減らす技法が明らかに必要とされている。

さらに、ソフトウェアの開発中に、正確で一貫性のある設計仕様を生成し保守することは難題である。時には、変数名がスペルミスされ、または設計仕様内で一貫性なしに使用されて、これらのエラーは検査プロセスで検出されないことも多い。さらに、時には、設計仕様で参照される変数名が、変数名前付け規則のような組織規則、制約およびプロセスと整合しないことがある。

設計仕様が不正確な、または一貫性のない変数名を含み、それが文書検査プロセス中に検出されない場合、これらのエラーは通常、その仕様に関連するソフトウェアコードがコンパイルされる時にコンパイラによって検出される。このような状況では、コード内および設計仕様内の両方において、エラーを訂正するのに時間と資源が浪費される。いくつかの組織では、設計仕様は、組織の文書変更管理プロセスにも従わなければならない。このため資源の浪費は悪化する。というのは、仕様文書の改訂は、文書変更要求の発生と、文書および変更要求のさらなる検査とを必要とし、このことがコストを追加し、結果として資源の浪費を増大させるからである。

本発明の目的は、上記の点に鑑み、ソフトウェア設計仕様文書の正確さおよび一貫性をチェックし検証するための自動化された技法を提供することにある。

一態様では、本発明のソフトウェア設計仕様文書を検証する技法は、関数定義セクションのような、設計仕様文書の第１セクションで定義されている１つまたは複数の関数のそれぞれについて、各関数名が、関数リストセクションのような、同一設計仕様文書の第２セクションで宣言されているかどうかを自動的に判定することを含む。関数名が第２セクションで宣言されていない場合、未宣言関数が報告される。一実施形態では、関数名が第２セクションで宣言されている場合、第１セクションで各関数名に関連する各パラメータ名が第２セクションで宣言されているかどうかが自動的に判定される。各パラメータ名が宣言されていない場合、その各パラメータ名が未宣言パラメータとして格納され、その各パラメータ名および各関数に関連する未宣言パラメータ頻度変数がインクリメントされる。さらに、一実施形態では、未宣言パラメータ名が存在する場合、その未宣言パラメータ名が未宣言パラメータ頻度変数の値とともに報告される。これは、未宣言パラメータが各関数で使用されている回数を示す。

一実施形態では、第１セクションで各関数名に関連する各属性名が、クラス属性セクションのような、同一設計仕様文書の第３セクションでリストされているかどうかがさらに自動的に判定される。各属性名がリストされていない場合、その各属性名が未宣言属性として格納され、その各属性名および各関数に関連する未宣言属性頻度変数がインクリメントされる。さらに、一実施形態では、未宣言属性名が存在する場合、その未宣言属性名が未宣言属性頻度変数の値とともに報告される。これは、未宣言属性が各関数で使用されている回数を示す。

一実施形態では、第１セクションで参照されている１つまたは複数のローカル変数名が格納され、各ローカル変数名および処理中の各関数に関連するローカル変数名頻度変数がインクリメントされる。１つまたは複数のローカル変数名（もしあれば）、および関連する頻度変数の値が報告される。

本発明によれば、電子設計仕様文書におけるスペルミスされた関数ならびに関連するパラメータおよび属性の発生は、設計仕様に関連するソフトウェアコードへの拡散の前に発見される。こうして、多くの場合、設計仕様文書のような管理されている文書を訂正することに関連する資源の使用は減少するか、または回避される。さらに、その後のコンパイル時エラーが減少するか、または回避される。

以下では、開発プロジェクトの管理に関与するタスクを自動化する諸技法が記述される。それらの技法は本明細書では主としてソフトウェア開発プロジェクトに関して記述されるが、それらの技法を他の開発プロジェクトに適用する場合にも本発明の利益が利用可能であることは当業者には認識されるはずである。以下の記述では、説明の目的上、本発明の徹底的な理解を提供するために数多くの具体的細目が記載される。しかし、明らかなように、本発明はこれらの具体的細目がなくても実施され得る。他の場合、本発明を不必要に不明瞭にすることを避けるために、よく知られている構造およびデバイスはブロック図形式で示される。

＜動作環境＞
図１は、本発明の諸態様が実施され得る動作環境の非限定的例を示している。この例示的動作環境は、複数のワークステーション１０２、ウェブサーバ１０４、およびデータベース１０６を備え、これらすべてが、これらの間の通信のために、ソフトウェア開発ネットワーク１０８に直接または間接に接続されている。随意に、後述の理由でデータベース１１０が存在してもよい。

ワークステーション１０２は通常、図２のコンピュータシステム２００によって例示されるように構成されるコンピュータシステムであり、例えば、開発プロジェクトに関連するタスクを完了するためにソフトウェア技術者／開発者によって利用される。このようなタスクの適切な非限定的例には、プロジェクトを開始すること、タスクスケジュールを作成し保守すること、ソフトウェアアーキテクチャを設計すること、仕様を作成すること、ソフトウェアコードを作成すること、ソフトウェアコードを実装しテストすること、種々のタスク成果物を検査すること等がある。さらに、プロジェクト管理者は、プロジェクトの進度を検討し管理するための情報にアクセスするためにワークステーション１０２を利用する。開発者および管理者は、ネットワーク１０８を通じて他の接続されているコンポーネント、すなわちウェブサーバ１０４およびデータベース１０６に情報を送信する。

ウェブサーバ１０４は、従来のウェブサーバを表している。これはコンピュータハードウェアとソフトウェアの組合せであって、適当なプロトコル（例えば、Ｈypertext Ｔransfer Ｐrotocol［ＨＴＴＰ］およびＴransmission Ｃontrol Ｐrotocol／Ｉnternet Ｐrotocol［ＴＣＰ／ＩＰ］）を用いて、ウェブページを形成するファイル（例えば、Ｈypertext Ｍarkup Ｌanguage［ＨＴＭＬ］またはＥxtensible Ｍarkup Ｌanguage［ＸＭＬ］ファイル）を、ワークステーション１０２を使用している開発者または管理者のようなユーザに提供する。一般に、開発プロジェクトのライフサイクル中に交換され管理される情報の大部分は、ウェブサーバ１０４によってネットワーク１０８を通じて提供される。さらに、本明細書で説明されるように、開発プロジェクトファイルの管理を自動化する技法の諸態様は、ウェブサーバ１０４上で実施され実行されてもよい。ただし、本発明の実施はこのような実施態様に限定されない。それらの技法は、ワークステーション１０２または図２に例示されているように同様に構成されるコンピュータシステムのような、いかなる他の処理システム上でも実施されることが可能である。

データベース１０６は、開発プロジェクトに関係する情報を格納する従来のデータベースを表している。したがってデータベース１０６は、ネットワーク１０８を通じて送信される問合せを通じて、ワークステーション１０２またはウェブサーバ１０４を使用している権限のある個人による情報へのアクセスを提供する。データベース１０６に格納される情報の種類は実質的に無限であり、非限定的例として、プロジェクト開始フォーム、個人および集約管理タスクスケジュール、仕様、ソフトウェアコード、検査レポート、ウェブページファイル、ならびに文書ディレクトリおよびインデックスがある。さらに、図３に示されそれに関して説明されるように、他の情報がデータベース１０６に格納されてもよい。代替的な動作環境では、従来のデータベース１１０がデータベースサーバとしてネットワーク１０８に直接接続される。

ネットワーク１０８は、ワークステーション１０２、ウェブサーバ１０４、およびデータベース１０６のような種々の接続されているコンポーネント間での情報の交換を容易にする従来のネットワーク、例えばパケット交換ネットワークを表している。ネットワーク１０８は、従来型イーサネット、ファーストイーサネット、トークンリング、または（Ｉnstitute of Ｅlectrical and Ｅlectronics Ｅngineers［ＩＥＥＥ］のワーキンググループによって開発された）８０２．１１ａおよび８０２．１１ｂに規定されているような無線ＬＡＮ等のローカルエリアネットワーク（ＬＡＮ）であってもよく、これは企業内で実施されるであろう。さらに、ネットワーク１０８は、仮想私設ネットワーク（ＶＰＮ）を通じてリモートユーザとの通信を容易にするために、インターネットのような広域ネットワーク（ＷＡＮ）であってもよく、あるいはネットワーク１０８は、ＬＡＮおよびＷＡＮの組合せとなってもよい。さらに、ネットワーク１０８は、種々の異なる媒体を用いて形成されることが可能であり、そのような媒体としては、以下のものには限定されないが、電気的有線すなわちケーブル接続、光接続、または無線接続がある。

＜ハードウェア概要＞
図２は、本発明の諸実施形態が実施され得るコンピュータシステム２００を例示するブロック図である。コンピュータシステム２００はさらに、ワークステーション１０２（図１）およびウェブサーバ１０４（図１）のシステム構成の非限定的例を示している。コンピュータシステム２００は、情報を通信するためのバス２０２等の通信メカニズム、およびバス２０２に結合した、情報を処理するプロセッサ２０４を含む。コンピュータシステム２００はまた、ランダムアクセスメモリ（ＲＡＭ）等のダイナミック記憶デバイスのような、バス２０２に結合した、情報およびプロセッサ２０４によって実行されるべき命令を格納するメインメモリ２０６も含む。メインメモリ２０６は、プロセッサ２０４によって実行されるべき命令の実行中に一時変数等の中間的情報を格納するために使用されてもよい。コンピュータシステム２００はさらに、バス２０２に結合した、プロセッサ２０４のためのスタティックな情報および命令を格納する読み出し専用メモリ（ＲＯＭ）２０８等のスタティック記憶デバイスを含む。磁気ディスク、光ディスク、または光磁気ディスクのような記憶デバイス２１０が、情報および命令を格納するために提供され、バス２０２に結合している。

コンピュータシステム２００は、バス２０２を通じて、ブラウン管（ＣＲＴ）や液晶ディスプレイ（ＬＣＤ）のような、情報をコンピュータユーザに対して表示するディスプレイ２１２に結合してもよい。英数字等のキーを含む入力デバイス２１４が、情報およびコマンド選択をプロセッサ２０４に伝えるためにバス２０２に結合している。もう１つのタイプのユーザ入力デバイスは、マウス、トラックボール、またはカーソル方向キーのような、方向情報およびコマンド選択をプロセッサ２０４に伝え、ディスプレイ２１２上のカーソル移動を制御するカーソルコントロール２１６である。この入力デバイスは通常、第１軸（例えばｘ）および第２軸（例えばｙ）という２つの軸方向に２つの自由度を有し、それによりこのデバイスは平面内の位置を指定することができる。

本発明は、本明細書で説明される諸技法を実施するためのコンピュータシステム２００の使用に関する。本発明の一実施形態によれば、それらの技法は、プロセッサ２０４がメインメモリ２０６に含まれる１つまたは複数の命令の１つまたは複数のシーケンスを実行することに応答してコンピュータシステム２００によって実行される。このような命令は、記憶デバイス２１０のような別のコンピュータ可読媒体からメインメモリ２０６に読み込まれてもよい。メインメモリ２０６に含まれる命令のシーケンスの実行により、プロセッサ２０４は、本明細書で説明されるプロセスステップを実行する。代替実施形態では、本発明を実施するために、ソフトウェア命令に代えて、またはそれとともに、固定配線回路を使用してもよい。したがって、本発明の諸実施形態は、ハードウェア回路およびソフトウェアのいかなる特定の組合せにも限定されない。

本明細書で使用される場合、「コンピュータ可読媒体」という用語は、実行のためにプロセッサ２０４に命令を提供することに関与するいかなる媒体をも指す。このような媒体は多くの形態をとることが可能であり、以下のものには限定されないが、不揮発性媒体、揮発性媒体、および伝送媒体がある。不揮発性媒体の例としては、以下のものには限定されないが、記憶デバイス２１０のような、光ディスク、磁気ディスク、または光磁気ディスクがある。揮発性媒体としては、メインメモリ２０６のようなダイナミックメモリがある。伝送媒体としては、同軸ケーブル、銅線および光ファイバがあり、バス２０２を構成するワイヤも含まれる。伝送媒体は、電波および赤外線データ通信中に生成されるもののような音波または光波の形態をとることも可能である。

コンピュータ可読媒体の普通の形態としては、以下のものには限定されないが、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ等の磁気媒体；ＣＤ−ＲＯＭ、ＤＶＤ等の光または光磁気媒体；パンチカード、紙テープ等の、穴あきパターンを有する物理媒体；ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュＥＰＲＯＭ等のメモリチップもしくはカートリッジ、本明細書で以下で説明されるような搬送波、またはコンピュータが読み取ることができるいかなる他の媒体も含まれる。

種々の形態のコンピュータ可読媒体が、実行のためにプロセッサ２０４に１つまたは複数の命令の１つまたは複数のシーケンスを伝えることに関与してもよい。例えば、命令はまずリモートコンピュータの磁気ディスクに保持されていてもよい。リモートコンピュータはその命令を自己のダイナミックメモリにロードし、モデムを用いて電話回線を通じてその命令を送信することができる。コンピュータシステム２００側のモデムが電話回線上のデータを受信し、赤外線送信機を用いてそのデータを赤外線信号に変換することができる。赤外線検出器が赤外線信号で伝送されたデータを受信し、適当な回路がそのデータをバス２０２上に置くことができる。バス２０２はそのデータをメインメモリ２０６に伝送し、そこからプロセッサ２０４が命令を取り出して実行する。メインメモリ２０６によって受信された命令は、随意に、プロセッサ２０４による実行の前後に記憶デバイス２１０に格納されてもよい。

コンピュータシステム２００は、バス２０２に結合した通信インタフェース２１８も含む。通信インタフェース２１８は、ローカルネットワーク２２２に接続されたネットワークリンク２２０に結合する双方向データ通信を提供する。例えば、通信インタフェース２１８は、対応するタイプの電話回線へのデータ通信接続を提供するためのサービス総合デジタル網（ＩＳＤＮ）カードまたはモデムであってもよい。もう１つの例として、通信インタフェース２１８は、互換性のあるＬＡＮへのデータ通信接続を提供するためのローカルエリアネットワーク（ＬＡＮ）カードであってもよい。無線リンクも実施され得る。いかなるこのような実施態様においても、通信インタフェース２１８は、種々のタイプの情報を表すデジタルデータストリームを伝送する電気、電磁または光信号を送受信する。

ネットワークリンク２２０は通常、１つまたは複数のネットワークを通じて他のデータデバイスへのデータ通信を提供する。例えば、ネットワークリンク２２０は、ローカルネットワーク２２２を通じて、ホストコンピュータ２２４、またはインターネットサービスプロバイダ（ＩＳＰ）２２６によって運用されるデータ機器への接続を提供してもよい。ＩＳＰ２２６は、さらに、現在「インターネット」２２８と普通呼ばれているワールドワイドパケットデータ通信ネットワークを通じてデータ通信サービスを提供する。ローカルネットワーク２２２およびインターネット２２８はいずれも、デジタルデータストリームを伝送する電気、電磁または光信号を使用する。コンピュータシステム２００との間でデジタルデータを伝送する、種々のネットワークを通る信号ならびにネットワークリンク２２０上の信号および通信インタフェース２１８を通る信号は、情報をトランスポートする搬送波の例示的形態である。

コンピュータシステム２００は、ネットワーク（複数可）、ネットワークリンク２２０および通信インタフェース２１８を通じて、メッセージを送信し、プログラムコードを含むデータを受信する。インターネットの例では、サーバ２３０がインターネット２２８、ＩＳＰ２２６、ローカルネットワーク２２２および通信インタフェース２１８を通じてアプリケーションプログラムのための要求されたコードを送信してもよい。

受信されたコードは、受信されるとともにプロセッサ２０４によって実行されてもよく、および／または後で実行するために記憶デバイス２１０または他の不揮発性ストレージに格納されてもよい。このようにして、コンピュータシステム２００は、搬送波の形態でアプリケーションコードを取得し得る。

＜プロジェクトデータベース＞
図３は、データベース１０６のデータコンポーネントおよびウェブコンポーネントの非限定的例を示している。データベース１０６は、種々のプロジェクト文書を表すファイルを格納することが可能であり、その一部は、開発プロジェクトを運営し管理することに関するガイダンスを提供するために企業によって使用される汎用のプロジェクト関連文書であり、一部は特定のプロジェクトに固有である。汎用文書の例として、データベースは、以下のものには限定されないが、プロジェクト参加者（すなわち、技術者／開発者、管理者等）が使用するための１つまたは複数のひな形フォーム３０２、例えば、プロジェクト開始フォーム（対話的プロジェクト開始フォームの印刷された例として図５Ｂおよび図５Ｃ参照）または検査フォーム（対話的検査フォームの印刷された例として図１３参照）；ならびに、少なくとも開発プロジェクトに関して、企業のインフラストラクチャ、ポリシーおよび手順についてプロジェクト参加者に指示するための１つまたは複数のマニュアル３０４、ポリシー３０６、および手順３０８、を格納するように構成され得る。フォーム３０２は、システムデータベース１０６への情報の対話的入力を容易にし、主としてクライアント、または個人プロジェクト参加者によって使用され、印刷出力も定義する。

プロジェクトデータ３１０とは、プロジェクト固有の文書のことであって、以下のものには限定されないが、完成したプロジェクト開始フォーム（図５Ｂおよび図５Ｃ参照）、個人タスクスケジュール（図１２参照）、集約管理タスクスケジュール（図１４参照）、仕様、ソフトウェアコード、完成した検査フォーム（図１３参照）、ウェブページファイル、文書ディレクトリおよびインデックス、タスク割当てフォーム（図１９参照）、ならびに個人タスクスケジューラフォーム（図２０参照）を含み得る。なお、文書ディレクトリおよびインデックス、ならびにタスク割当てフォームおよび個人タスクスケジューラフォームは、代替的または追加的に、データベース１１０（図１）に格納されてもよいことに留意されたい。ワークステーション１０２で、または別法としてウェブサーバ１０４で作業するプロジェクト参加者は、サーチエンジン３２０を利用してデータベース１０６にアクセスし、種々の汎用およびプロジェクト固有文書を検索することができる。

プロジェクトホームページ３１２および１つまたは複数のプロジェクトサイト３１４によって表されているように、異なるレベルのプロジェクト固有情報がデータベース１０６からアクセスされることが可能である。プロジェクトホームページ３１２は、それらの１つまたは複数のプロジェクトサイト３１４へのリンクを提供する。当技術分野で知られているように、リンクとは、ある語、ピクチャ、または情報オブジェクトから他への選択可能な連絡である。リンクの実施態様の１つの非限定的例はハイパーリンクであり、適当なプロトコルおよび言語、例えばそれぞれＨＴＴＰおよびＨＴＭＬ、を利用する。リンクによってユーザは、リンクを作動させることによってホームページ３１２からプロジェクトサイト３１４にアクセスすることができる。リンクは通常、カーソルコントロール２１６（図２）および／または入力デバイス２１４（図２）を用いて、従来のウェブブラウザのような適当なアプリケーションと対話することによって作動する。プロジェクトサイト３１４にリンクされ、したがってプロジェクトサイト３１４からアクセス可能な情報の例については以下で説明する。

＜自動化されたプロジェクトファイル管理の開始＞
図４Ａは、本発明の一実施形態による、ネットワークを通じてプロジェクトファイルの自動化された管理を開始するステップを説明するフローチャートである。まず、ステップ４０２で、個人が、プロジェクト承認を求めて管理側に提出するためのプロジェクト開始フォームを完成させる。図５Ａは、オンライン対話的プロジェクト開始フォーム５００を通じてプロジェクトを開始する構成のブロック図である。対話的フォームは、ＨＴＭＬまたはＸＭＬに基づくページであることが可能である。プロジェクト開始者は、ウェブブラウザのようなネットワークインタフェースを通じて、必要な情報を入力する。その非限定的例としては、プロジェクトタイトル５０２、プロジェクトの説明５０４、予想されるプロジェクトメンバおよび責任５０６、全体スケジュール５０８、および予算５１０がある。入力された情報はウェブサーバ１０４を通じてデータベース１０６に送信され、そこでまず、図４Ａのステップ４０４で、要求されたプロジェクトの承認前のドラフト形式で格納される。さらに、開始者は、プロジェクト認可／承認プロセスに進む前に、ドラフトフォームを再検討することができる。図５Ａのデータベース１０６に描かれている情報のブロックは、図６のプロジェクトサイト６００のようなプロジェクトホームページまたはサイトで抽出され提示されることが可能な種々の情報を含む。

図５Ａはさらに、設計仕様検証ツール５１２を含む。これは、設計仕様文書のドラフトを自動的に検証するために使用される。設計仕様検証ツール５１２は、図２２に示されるソフトウェア設計プロセスをサポートするために使用可能である。設計仕様検証ツール５１２については後で詳細に説明する。

印刷または表示されたプロジェクト開始フォーム５５０の例を図５Ｂおよび図５Ｃに示す。関連する情報見出しは示すが情報は除いてある。対話的プロジェクト開始フォーム５００（フォーム５５０としても例示されている）は、データベース１０６（図１）のフォーム３０２（図３）コンポーネントから利用可能であり、一部のデータフィールドの自動入力のためにデータベース１０６内の他のデータにリンクされる。印刷／表示されたプロジェクト開始フォーム５５０のフォーマットはフォーム３０２に関連している。

図４Ａに戻って、判定ブロック４０６で、適当なプロジェクト承認権者が、提案されたプロジェクトを承認したかどうかが判定される。プロジェクトが承認されていない場合、ステップ４０８で、プロジェクト開始フォームは、プロジェクトが未承認であることを示すようにマークされ、ドラフトとしてデータベース１０６に格納される。提案されたプロジェクトが承認されると、ステップ４１０で、プロジェクトにはプロジェクト番号が自動的に割り当てられ、プロジェクトサイト３１４（図３）のような公式プロジェクトサイトが自動的に作成されて、プロジェクトホームページ３１２（図３）のようなプロジェクトホームページにリンクされる。さらに、ステップ４１０で、種々のデータベース１０６のエントリおよびインデックスページが作成される。ステップ４１２で、個人プロジェクト参加者に対するウェブサイトが作成され、ステップ４１４で、適当な公式プロジェクトサイトにリンクされる。さらに、必要なエントリがデータベース１０６に作成され、プロジェクト参加者によって利用される適当なスケルトンファイルにリンクされる。プロジェクト参加者は、取組中すなわちドラフトの文書を自己の個人サイトにリンクすることが可能であり、それによりその文書は、プロジェクトホームページ、すなわちプロジェクトホームページ３１２からのリンクの適当な連鎖を通じて、権限のあるプロジェクトメンバに利用可能となる。アクセス許可は、文書管理ポリシーに従って制限され管理される。いくつかの実施形態では、プロジェクトに関連するプロジェクトファイルのディレクトリが作成され、データベース１０６およびデータベース１１０（図１）に格納され、（図６に示すように）プロジェクトサイトにリンクされる。適当であれば、サブディレクトリおよびインデックスが作成され、プロジェクトサイト上の適当なディレクトリエントリにリンクされることが可能である。

＜検査プロセス−クライアント＞
図４Ｂは、一実施形態による、個人（クライアント）が文書検査プロセスに関して実行するステップを説明するフローチャートである。ステップ４５２で、文書、記録、またはレポート（参考資料）が個人プロジェクト参加者によって生成される。ステップ４５４の判定ブロックで、参考資料が、品質を保証するために検査を必要とする種類であるかどうかが判定される。例えば、技術情報および記録のような一部の情報は、品質検査を必要としないかもしれない。この場合、ステップ４５６で、当該個人は文書の登録を要求し、それによりフローはＲ１に進み、これは図４Ｃに示されている。参考資料の検査が品質を保証するために必要であるとみなされる場合、ステップ４５８で、当該個人はその検査を手配する。ステップ４６０で、検査が要求され、それにより、検査はプロジェクトファイル管理システムに登録され、本明細書で説明されるプロセスによって管理されることになる。この場合、フローはＲ２に進み、これは図４Ｄに示されている。

＜検査プロセス−サーバ＞
図４Ｃは、図４ＢのＲ１から続くサーバ側プロセスを説明するフローチャートである。この場合、参考資料は検査されず、文書登録が要求されている。ステップ４７２で、参考資料が、管理された環境下でデータベース１０６（図１）にコピーされ、その資料を作成した個人がそれをもはや修正することができないようにされる。別法として、資料は安全なファイルシステムにコピーされ、資料への参照がデータベース１０６に保存される。ステップ４７４で、情報エントリ、例えば、文書参照番号、タイトル、日付、および発信者が、適当なインデックスページ（図７Ａの７００参照）に作成される。ステップ４７６で、インデックスページから適当な文書および対応する文書フィールドへのリンクが作成される。

図４Ｄは、図４ＢのＲ２から続くサーバ側プロセスを説明するフローチャートである。この場合、参考資料の検査が要求されている。一般に、本明細書で説明されるファイル管理プロセスを具現化するファイル管理システムは、要求された検査がスケジュール通りに完了しているかどうか、したがって検査結果が利用可能であるかどうかを監視する。ステップ４８２で、検査結果オブジェクト（図７Ｂの７７４参照）が参考資料にリンクされる。判定ブロック４８４で、検査結果が利用可能であるかどうかが定期的に判定される。検査結果がまだ利用可能でない場合、ステップ４８５で、プロセスは実質的にある一定期間経過するのを待機した後、検査結果を期待してブロック４８４に戻る。検査結果が利用可能になると、それが分析される。判定ブロック４８６で、検査結果が分析され、参考資料が、関連する検査者によって受理されるものと表示されたかどうかが判定される。資料は受理されないと判定された場合、ステップ４８８で、資料は再検査を必要とするか、それとも条件付きで受理されるか（受理とは異なる処分）が判定される。資料が再検査を必要とする場合、データベースがそのように更新される。この時点で、プロセスはブロック４８４に戻り、追加の検査結果が利用可能であるかどうかを判定してもよい。資料が条件付きで受理された場合、フローは判定ブロック４９０に進み、資料は、検査レポートからの指定された条件を満たすように修正されているかどうか、および訂正が検査長によって認定されているかどうかを判定するためにチェックされる。資料がまだ検査長によって認定されていない場合、ステップ４９１で、プロセスはある期間待機してブロック４９０に戻る。検査長による認定なしに所定期間が経過した後、文書がまだ認定されていないことを警告する電子メールが文書作成者および検査長に送られる。

判定ブロック４９０で、資料が検査長によって認定されたと判定されると、プロセスはステップ４９２に進む。これは、参考資料がブロック４８６で受理された場合に実行されるのと同じステップである。ステップ４９２で、現在の検査資料が、管理された環境下でデータベース１０６（図１）にコピーされ、その資料を作成した個人がそれをもはや修正することができないようにされる。ステップ４９４で、情報エントリ、例えば、文書参照番号、タイトル、日付、および発信者が、適当なインデックスページ（図７Ａの７００参照）に作成される。ステップ４９６で、インデックスページから適当な文書および対応する文書フィールドへのリンクが作成される。

＜プロジェクトウェブページ＞
図６は、プロジェクトサイト６００の例を示している。これは、特定プロジェクト（この場合、プロジェクトサイト６００の最初に示されているように、Ｊ０６プロジェクト）に固有の情報のいくつかの他のページへのリンク（下線付きのエンティティ）を有する。リンクには、以下のものには限定されないが、公式プロジェクト文書および記録のディレクトリ６０２；プロジェクトソースコードリンク６０４；プロジェクト要件リンク６０６；プロジェクトスケジュールリンク６０８；１つまたは複数の現行タスクリストリンク６１０ならびにプロジェクトに取り組んでいる個人、すなわち技術者／開発者に対するメンバウェブサイトリンク６１２がある。

ディレクトリ６０２は、プロジェクトに関連する種々の公式文書および記録のインデックスへのリンクを提示する。そのような文書および記録の非限定的例として、プロジェクト文書、検査結果、会議記録、変更、エラー追跡等の記録がある。

プロジェクトスケジュールリンク６０８は、集約管理タスクスケジュールへのアクセスを提供する。これは図１４に関連して例示され説明される。現行タスクリストリンク６１０は、プロジェクトについて各個人の割り当てられたタスクのタスクスケジュールへのアクセスを提供する。これは図１２に関連して例示され説明される。さらに、現行タスクリストリンク６１０を通じてアクセスされる個人タスクスケジュールと、プロジェクトスケジュールリンク６０８を通じてアクセスされる集約管理タスクスケジュールとの間の関係については、以下の「管理スケジュール生成」および「プロジェクトスケジュールの更新」と題する箇所で詳細に説明する。最後に、メンバウェブサイトリンク６１２は、１つまたは複数の個人ウェブサイトへのアクセスを提供する。そのウェブサイトの作成については上記で図４のステップ４０８に関連して説明されている。個人ウェブサイトは、個人タスクリスト（図１２参照）へのアクセスとともに、その個人による取組中のドラフト文書へのアクセスを提供する。

図７Ａは、インデックス７００の例を示している。これは、「プロジェクト文書のインデックス」である。インデックス７００、およびディレクトリ６０２にリンクされるいかなる他のインデックスも、データベース１０６（図１）に格納されている実際のファイルへのリンクを含む。図７Ｂは、例示的インデックスウェブページ７５０、プロジェクトデータベース１０６、および、データベース１０６によって管理される電子的または物理的ファイル／オブジェクト７７０の間のリンク関係を示している。参照番号７５２、文書タイトル７５４、および改訂番号７５６は同一オブジェクト、すなわち公式文書７７２にリンクされている。有効日７５８は、その文書が有効になるか、または改訂番号７５６に対応して最後に改訂された日付に対応する。検査７６０フィールドは、その文書に対して実行された検査に対応する検査結果７７４にリンクされている。ステータス７６２は、インデックスされている文書の現在のステータス、すなわち、その文書が適当な当事者からの認可を依然として待機しているのかどうかを提示する。ステータス７６２フィールドは、認可履歴オブジェクト７７６にリンクされている。インデックスウェブページ７５０に含まれる情報は、データベース１０６の管理下で、ウェブブラウザインタフェースを通じてクライアントに対して表示可能である。

＜ネットワークを通じてプロジェクトファイルを管理する方法＞
図８は、本発明の一態様による、ネットワークを通じてプロジェクトファイルを管理するステップを説明するフローチャートである。ステップ８０２で、プロジェクト開始情報が受信される。これは好ましくは、少なくともプロジェクトの記述およびプロジェクトタスクを実行する個人の記述を含む。ステップ８０２で受信される情報の非限定的例は、図５Ｂおよび図５Ｃのプロジェクト開始フォーム５５０に示されている。ステップ８０４で、プロジェクトが適当なエンティティによって承認されているかどうかが判定される。ステップ８０６で、プロジェクトが承認されている場合、プロジェクト開始情報が、プロジェクトが承認されていることを示すようにして、データベース１０６（図１および図３）のようなデータベースに格納される。

図８のステップ８０８で、個人ウェブサイト、またはページが、プロジェクトに取り組んでいる各個人ごとに作成される。種々の情報および業務成果文書（例えば、以下のものには限定されないが、ドラフトファイルおよびタスクスケジュール）が、個人ウェブサイトにリンクされ得る。この情報へのアクセスは通常は規制され、権限のある個人がネットワークを通じて利用可能である。ステップ８１０で、個人サイトは、プロジェクトサイト６００のメンバウェブサイト６１２（図６）によって例示されているように、プロジェクトサイトにリンクされる。ステップ８１２で、プロジェクトに関連するファイルのディレクトリが作成される。これは、ステップ８１４でデータベースに格納される。ステップ８１６で、ファイルのディレクトリは、図６に関連してディレクトリ６０２によって例示され関連する本文で説明したように、プロジェクトサイトにリンクされる。

図８のステップ８１８で、ドラフトファイルが完成しているかどうかが判定される。その完成は、検査に合格したこととして定義される。完成ファイルを定義するこの基準は、少なくとも以下の目的に役立つ。すなわち、この基準は、プロジェクトに関係する、ファイルの作成者でない２人以上の人による検査の結果として、ファイルの品質および完全性を保証する。またこの基準は、２値の完了ステータスを提供することによって、タスクが完了しているかどうかを明確にする。すなわち、タスクは、完了しているか否かとして記録され、ある割合の完了の記録を許容しない。なお、ステップ８１８は、図４Ｄの検査プロセスに関係していることに留意されたい。

ドラフトファイルが完成すると、そのファイルのステータスがドラフトから公式に変更され、これは、ステップ８２０で、そのステータスを示すようにデータベース１０６に格納される。別法として、物理ファイルが安全なファイルシステムにコピーされ、そのファイルへの参照がデータベース１０６に格納されてもよい。最後に、ステップ８２２で、公式ファイルがプロジェクトサイトにリンクされる。図６および図７に関連して例示したように、公式ファイルは、インデックス７００のようなインデックスへのリンクを通じてプロジェクトサイトに間接的にリンクされてもよい。その場合、インデックスそのものはディレクトリ６０２のようなディレクトリにリンクされ、そのディレクトリが、プロジェクトサイト６００のようなプロジェクトサイトに提示される。

図９は、図８の方法の一実施形態を示している。この実施形態では、個人タスクスケジュールが自動的に管理される。ステップ９０２で、１つまたは複数のタスクスケジュールが、プロジェクトに取り組んでいる個人から受信される。ステップ９０４で、個人タスクスケジュールがデータベース１０６（図１）に格納される。ステップ９０６および９０８は、いかなる順序で完了してもよいが、ステップ９０６で、個人タスクスケジュールを、図６の現行タスクリストリンク６１０を通じてアクセス可能な関連する個人のサイトに自動的にリンクすること、およびステップ９０８で、個人タスクスケジュールをプロジェクトサイトに自動的にリンクすることを含む。プロジェクトサイトリンクは、図６に関連して現行タスクリストリンク６１０として図示され、関連する本文で説明されている。

＜管理スケジュール生成＞
図１０は、図８の方法のもう１つの実施形態を示している。この実施形態では、総括管理スケジュールが自動的に管理される。ステップ１００２で、１つまたは複数のタスクスケジュールが、プロジェクトに取り組んでいる個人から受信される。ステップ１００４で、同一プロジェクトに関連する管理スケジュールが、個人タスクスケジュールに基づいて更新される。個人タスクスケジュールを管理タスクスケジュールにリンクさせることの利点は、管理タスクスケジュールを、個人タスクスケジュールへの変更時に自動的に更新することができることである。ステップ１００６で、管理タスクスケジュールが、図６に関連してプロジェクトスケジュールリンク６０８として図示され関連する本文で説明されているように、プロジェクトサイトにリンクされる。

図１１は、本発明の一態様による、プロジェクトスケジュールを自動的に更新することによってプロジェクトスケジュールを管理するために使用されるリンク関連づけを説明するブロック図である。この例では、複数のタスクリスト１１０２、１１０４、および１１０６（個人タスクリスト／スケジュールの例については図１２参照）がシステムマネージャ１１１０にリンクされ、システムマネージャ１１１０は本明細書に説明されるプロジェクトスケジュールを管理する方法を具現化している。タスクリスト１１０２〜１１０６は、プロジェクトに取り組んでいる個人ごとにあり、各タスクリストは通常は別々の個人に関連するが、本発明の実施はそのようには限定されない。プロジェクトスケジュール１１１２（または「管理スケジュール」）は、個人タスクリスト１１０２〜１１０６の集約であり、通常は、個人タスクスケジュールのような詳細なレベルでのタスク定義を含まない。したがって、プロジェクトスケジュール１１１２は、個人タスクリスト１１０２、１１０４、および１１０６を総括している。例えば、図１４は、管理スケジュール１４００の例を示している。これについては以下でさらに詳細に説明する。

個人タスクスケジュール内の各タスクの完了は検査フォームにリンクされ、その完成バージョンがデータベース１０６（図１）に格納される。例えば、図１３は、印刷または表示された検査フォーム１３００の例を示している。これについては以下でさらに詳細に説明する。個人タスク成果物に関して検査権限を有する検査チームによる肯定的処分があると、関連するタスクは完了したとみなされる。一実施形態では、各タスクのステータスは、タスクが一部完了したとは記録され得ないという意味で２値変数である。例えば、本明細書で説明されるプロジェクトファイル管理技法によれば、タスクは完了しているか完了していないかのいずれかであり、ある割合が完了しているということはない。したがって、権限のあるタスク検査チームがタスク成果物の検査を完了し、完成した検査フォームをデータベース１０６に格納した後にのみ、そのタスク成果物は「受理」または同様の処分を受ける。いくつかの実施形態では、個人タスクスケジュールは、完成した検査フォームの結果に基づいて自動的に更新される。さらに、個人タスクリスト１１０２、１１０４、および１１０６が更新されると、プロジェクトスケジュール１１１２が、更新された個人タスクリスト１１０２、１１０４、および１１０６に基づいて、（例えば図２１に関連して説明されるように）続いて更新される。

図１２は、個人「ＴＭ」の個人タスクスケジュール１２００の例を示している。図１３は、印刷または表示されたオンライン検査フォーム１３００の例を示している。一実施形態では、個人タスクスケジュール１２００および検査フォーム１３００は、図１４に示されているような管理スケジュール１４００を自動的に生成または更新するために使用されるステータスデータを提供する。このプロセスは、図１１に関連して説明したリンクによって容易になる。（フォーム１３００のような）検査フォームが完成すると、（タスクスケジュール１２００のような）個人タスクスケジュールが、完成した検査フォームに従って更新され、（スケジュール１４００のような）管理スケジュールがその結果として更新される。

図１３を参照すると、文書参照１３０２が、関係する個人タスクスケジュール内の同一タスクにマッピングされている。なお、文書参照１３０２は、文書のみを参照しているのではなく、より包括的に、個人タスクの成果物を参照していることに留意されたい。さらに、結果参照１３０４は、図１２のスケジュール１２００のような、関係する個人タスクスケジュールの「実際の終了（Ａctual Ｅnd）」列１２０８（図１２）にマッピングされている。「実際の終了」列１２０８に自動的に入力される日付は、特定タスクに対して要求されるすべての検査フォーム（すなわち、結果参照１３０４における「受理（Ａccept）」）についての最終受理完了日に基づいて自動的に決定される。本方法は、列１２０８の「実際の終了」日を決定するために、すべての検査が完了した時を判定すること、およびすべての完成した検査フォームが結果参照１３０４に「受理」を示しているかどうかを判定することのためのロジックを含む。別法として、検査結果が条件付き受理である場合、図４Ｄのステップ４９０に示されているように、検査長は、すべての訂正が成果物に含まれていることを通知しなければならない。

図１２および図１４を参照すると、タスクスケジュール１２００のいくつかのセルが管理スケジュール１４００にマッピングされている。例えば、タスクスケジュール１２００のセル１２０２は、特定タスクの最も早い「計画された開始（Ｐlanned Ｓtart）」に関連しており、管理スケジュール１４００のセル１４０２にマッピングされている。同様に、セル１２０４は、特定タスクの「計画された終了（Ｐlanned Ｅnd）」に関連しており、セル１４０４にマッピングされている。したがって、セル１２０２または１２０４のデータが追加、改訂、または削除された場合、セル１４０２または１４０４がそれに応じて自動的に改訂される。セル１２０６および１４０６も、前述のセルと同様に相互に関係している。他にもセル１２０２と同様に、特定の個人（この場合は「ＴＭ」）について、関連する管理スケジュールセルにマッピングされている多くのタスクスケジュールセルがあり、それにより、本発明の一態様による高水準の管理スケジュール１４００の自動更新を提供している。

＜プロジェクトスケジュールの更新＞
図１５は、本発明の一態様による、プロジェクトのスケジュールを生成および／または更新するステップを説明するフローチャートである。ステップ１５０２で、検査データを含む完成した検査フォームがネットワークを通じてデータベース１０６（図１）から受信される。完成した検査フォームは、タスク成果物を検査するために開かれる検査チーム会議の結果に対応し、それにより、完成した検査フォームは検査に基づく情報を含む。検査フォーム１３００の例は再び図１３を参照されたい。

ステップ１５０４で、個人のタスクスケジュール（すなわち、その個人はそのタスクを完了する責任がある）が、受信された検査フォームに基づいて自動的に更新される。ポリシーによれば、検査結果レポートが完了を示していなければ、あるいは図４Ｄに示したように検査結果が条件付き受理を示している場合には検査長が成果物への訂正を認定しなければ、プロジェクトタスクは完了しない。ステップ１５０６で、図１４に例示したような、プロジェクトに関連するすべての個人タスクスケジュールの集約である管理スケジュールが、ステップ１５０４からの更新された個人タスクスケジュールに基づいて自動的に更新される。

一実施形態では、個人スケジュールおよび管理スケジュールは、プロジェクトタスクが部分的には完了し得ないことを規定するポリシーによって支配され、スケジュールの自動更新はこのポリシーに従って実行される。

ステップ１５０８で、完成したプロジェクトタスク成果物がデータベース１０６（図１および図３）に格納され、その成果物へのアクセスは文書管理ポリシーに従って規制される。一実施形態では、完成したタスク成果物は、ハイパーリンクのような適当なリンクを通じて、インターネットまたは企業ネットワークのようなパケット方式のネットワークによりアクセス可能である。

＜タスク階層＞
本発明の一実施形態によれば、開発プロジェクトを管理するためにタスク階層が使用される。タスク階層は、開発プロジェクトの完了に関連するタスク間の関係を表す。一実施形態では、この関係は、親タスクの完了が１つまたは複数の下位レベルの子タスクの完了に依存するような、階層内のタスク間の依存関係を表す。したがって、この依存関係は、階層内のメンバタスクへの変更が階層内の他のメンバタスクに対して、もし影響があればどのように影響するかを指定する。タスク階層の使用により、下位レベルのタスクスケジュールへの変更に応じてプロジェクトタスクスケジュールを自動的に更新することが容易になる。

図１６は、本発明の一実施形態による、開発プロジェクトを管理するために使用可能なタスク階層を表している。図１６に示されたタスク階層は、３レベルのタスクを含む。これらはレベル１タスク、特定のレベル１タスクを完了するために完了することが必要とされるレベル２タスク、および特定のレベル２タスクを完了するために完了することが必要とされるレベル３タスクを含む。タスクの階層のレベル数は図１６に示されるような３レベルには限定されず、開発プロジェクトの主要タスクおよび関連するサブタスク（または詳細タスク）を定義する必要に応じた数のレベルを含み得る。

なお、いかなる特定レベルのタスクも、関連するサブタスクを有することが必要なわけではないことに留意されたい。例えば、タスク１６０２（設計文書ガイドライン）およびタスク１６０４（Ｊ０７プロジェクトプラン）は、レベル１タスクとして定義されているが、いかなる関連する下位レベルタスクを有するようにも定義されていない。さらに、タスク１６０８としてまとめて識別されているレベル２タスク（共通、Ｓend Ｓervice、およびＳend Ｔimer）は、タスク１６０８を完了するために完了を必要とするいかなる関連するレベル３タスクを有するようにも定義されていない。図１６に示されているように、タスク１６０２、１６０４、１６０６、および１６１０はレベル１タスク（主要タスクとも呼ばれる）である。タスク１６０８としてまとめて識別されている３つのタスクは、関連するレベル１タスク、すなわちタスク１６０６（パッケージ設計）を完了するために完了を必要とするレベル２タスクである。さらに、タスク１６１０（クラス仕様）はレベル１タスクであり、これは２つの関連するレベル２タスク、１６１２（共通）および１６１４（Ｓend Ｔimer）を有する。さらに、タスク１６１２は２つの関連するレベル３タスク、１６１６（ＣＢaseＳervice）および１６１８（ＣＢaseＳystemＲegistry）を有し、タスク１６１４は２つの関連するレベル３タスク、１６２０（ＣＳendＴimer）および１６２２（ＣＳendＳystemＲegistry）を有する。図１６に示されているタスクは、開発プロジェクトの完了に関係するタスクの階層を説明するための、単なる例示目的のものである。したがって、本発明の実施は、図示されているタスクに限定されない。

＜タスクデータ構造体＞
図１７は、本発明の一実施形態によるタスクデータ構造体１７００を図式的に説明する図である。各タスクに関連するデータは、ある形態のコンピュータメモリ、例えば、限定はされないが、データベース１０６に関連するメモリに格納される。タスクデータ構造体１７００は、オブジェクト指向プログラミング技法を用いて実装されてもよい。それによりタスクデータ構造体１７００はオブジェクトクラスとして定義され、各タスクは、当該オブジェクトの状態である対応するデータを有するオブジェクトとしてインスタンス化される。本発明の実施または実施態様は、オブジェクト指向プログラミング技法の使用に限定されず、当技術分野で既知の他のコンピュータソフトウェアプログラミング技法も、本明細書で説明される技法を実施するために使用可能である。

図１７は、オブジェクトクラスとして実装されたタスクデータ構造体１７００を表している。ここで属性としては、以下のものには限定されないが、タスク名１７０２、タスクスケジュール１７０４、下位レベル参照のベクタ１７０６、親参照１７０８、および履歴のベクタ１７１０がある。タスク名１７０２は単にタスクに割り当てられた名前であり、タスクオブジェクトを識別するために使用される。タスク名１７０２の例は、「ＣＳendＴimer」（図１６の参照１６２０）である。

タスクスケジュール１７０４は、タスクの履行に関係する日付を含む。一実施形態では、日付は「計画日」、「計画された開始」日、「計画された終了」日、「実際の開始」日、および「実際の終了」日を含む。計画日は、他のタスクスケジュール日付のいずれかが最後に入力または更新された日付を示す。一実施形態では、現在の日付（すなわち、スケジュールへの入力または変更がなされた日付）が、システムクロックから自動的に取得され、適当な計画日フィールドに入力される。他のタスクスケジュール日付、すなわち、計画された日付、および実際の日付の内容は、改めて説明するまでもない。これらのフィールドの操作は、図２０に示されそれに関連して説明されるオンラインタスクスケジューラフォームを用いることにより実行され得る。

タスクスケジュール１７０４の実装は複数の形態をとることが可能であり、それらは本発明の範囲内に入る。例えば、限定されないが、タスクスケジュール１７０４は、プログラミングオブジェクトのベクタ、マップ、リスト、または構造体クラスを用いて実装され得る。

下位レベル参照のベクタ１７０６は、タスクの階層構造において特定タスクから下位レベルタスクへの参照を提供するために使用されるプログラミングツールである。例えば、タスク１６１２（図１６）のようなレベル２タスクは、それに関連する下位レベルタスク、すなわち子タスクであるタスク１６１６（図１６）および１６１８（図１６）を指す参照のベクタを有する。「ベクタ」という用語は、Ｃ＋＋プログラミング言語に関連する標準テンプレートライブラリのことであり、項目の１次元のランダムアクセスシーケンスの実装を提供する。本発明の実施は、あるタスクオブジェクトから他のタスクオブジェクトへの参照を提供する際のベクタの使用に限定されず、他の参照技法も実施可能であり、やはり本発明の範囲内に入る。

親参照１７０８は、タスクの階層構造において特定タスクから関連する上位レベルタスク、すなわち親タスクへの参照を提供するために使用される。例えば、タスク１６１２（図１６）のようなレベル２タスクは、それに関連する親タスク１６１０への親参照を有する。親参照１７０８は、いかなる特定の形態にも限定されず、例えば、タスクからその親タスクへの単純なポインタの形態をとってもよい。参照のベクタ１７０６および親参照１７０８の使用については、図１８に関連してさらに詳細に説明する。

履歴のベクタ１７１０は、特定タスクから、その特定タスクに関係する履歴データへの参照を提供する。例えば、履歴のベクタ１７１０は、特定タスクに関連する履歴日付を表すデータの位置への単純なポインタとして実装されることが可能である。したがって、タスクスケジュールは、図１２の要素１２１０としてまとめて参照されているように、現在の日付とともに、計画された開始、計画された終了、実際の開始、および実際の終了のような、日付フィールドのいずれかについての履歴（すなわち、「古くなった（old）」、または「使われなくなった（obsolete）」）日付を含み得る。この特徴は、タスクスケジュールを見る人に、スケジュールの抜けや進捗の増分的規模に関する情報を提供する。

図１８は、本発明の一実施形態による、タスクオブジェクト間の関係を視覚的に表すタスクデータ構造体の階層関係を説明する図である。図１８は、レベル１タスクオブジェクト１８００；レベル２タスクオブジェクト１８１０、１８２０、および１８３０；ならびにレベル３タスクオブジェクト１８４０および１８５０を表している。各オブジェクトは、名前、スケジュール、子参照、親参照、および履歴を含む、図１７に示されたデータ構造を有するように表されている。一部のデータフィールドはヌル値を有し、関連データがないフィールドを表している。そのようなフィールドとしては、例えば、タスクオブジェクト１８００の親参照フィールド１８０４（親がないこと、したがって親参照がないことを示している）、タスクオブジェクト１８１０の子参照フィールド１８１４（子がないこと、したがって子参照がないことを示している）、およびタスクオブジェクト１８４０の子参照フィールド１８４４（子がないこと、したがって子参照がないことを示している）がある。

図１８は、開発プロジェクトに対する複数のタスクオブジェクト間の関係および相互作用を示しており、以下の例は、オブジェクト相互作用を説明することを助けるために使用される。例えば、タスクオブジェクト１８４０のスケジュールデータに更新が行われた場合、本明細書で説明される自動タスクスケジュール更新技法によれば、タスクオブジェクト１８４０の親参照１８４６が、オブジェクト１８４０の親タスクを識別するためにアクセスされる。なお、親参照１８４６（一般には、図１７の親参照１７０８）はベクタとして実装されてもよく、したがってタスクデータ構造体１７００は、タスクが複数の親タスクを有し得るようなタスクの階層を可能にする。本例では、タスクオブジェクト１８４０は、親参照１８４６で参照される単一の親タスクを有し、これはタスクオブジェクト１８２０を参照しており、これは完了のためにタスクオブジェクト１８４０に関連するタスクに依存する。親タスクが識別されると、それが、その子参照を識別するためにアクセスされる。例えば、タスクオブジェクト１８２０の下位レベル参照のベクタはタスクオブジェクト１８２０の２つの子タスク、すなわちタスクオブジェクト１８４０およびタスクオブジェクト１８５０を指している。子タスクが識別されると、子タスクオブジェクトのスケジュールデータがアクセスされ、親オブジェクト１８２０のスケジュール日付のいずれかが、子オブジェクト１８４０のスケジュールデータに対する変更の結果として更新を必要とするかどうかを判定するために解析される。例えば、タスクオブジェクト１８４０によって表されるタスクの実際の終了日が、兄弟タスクオブジェクト１８５０によって表される実際の終了日より後となるように更新された場合、親タスクオブジェクト１８２０は、親タスクの現在の実際の終了日を反映するように更新を要求し、タスクオブジェクト１８２０のスケジュールデータがそれに応じて更新される。

さらに、親オブジェクト１８２０の親参照が、タスクオブジェクト１８２０の親があればそれを識別するためにアクセスされ、次の上位レベルにある親タスクオブジェクトのスケジュールデータが、タスクオブジェクト１８４０のスケジュールデータに対する変更およびそれにより生じるオブジェクト１８２０への変更の結果として更新を必要とするかどうかについて判定をすることができる。例えば、オブジェクト１８２０の親参照はタスクオブジェクト１８００を指している。タスクオブジェクト１８００が、その子参照を識別するためにアクセスされる。例えば、タスクオブジェクト１８００の下位レベル参照のベクタは、タスクオブジェクト１８００の３つの子タスク、すなわちタスクオブジェクト１８１０、タスクオブジェクト１８２０、およびタスクオブジェクト１８３０を指している。子タスクが識別されると、子タスクオブジェクト（すなわち、１８１０、１８２０、および１８３０）のスケジュールデータがアクセスされ、それらの親オブジェクト１８００のスケジュール日付のいずれかが、孫オブジェクト１８４０のスケジュールデータに対する変更の結果として更新を必要としているかどうかを判定するために解析される。このプロセスは、最上位レベル（レベル１）に到達し、最上位レベルにあるタスクスケジュールに対する必要な更新が判定されるまで、タスク階層のすべての必要なレベルに沿って実行される。本発明の一実施形態による、タスクスケジュールデータ構造体を更新する方法は、タスクスケジュール日付の解析をさらに詳細に例示するが、これは図２１で説明される。

＜タスク管理ツール＞
図１９は、特定のプロジェクト参加者に特定のタスクを割り当てるために本発明の一実施形態で実施される、オンラインタスク割当てフォーム１９００の例を示している。タスク割当てフォーム１９００は、「タスク（Ｔasks）」列１９０２および「担当者（Ａssigned Ｔo）」列１９０４を含む。列１９０２および１９０４は、タスク１６１２の「共通」（図１６）のようなタスク名を列１９０２のフィールドに入力するため、およびプロジェクト参加者名（またはその他の識別データ、例えば従業員番号）を列１９０４のフィールドに入力するためのデータ入力フィールドを含む。

タスク割当てフォーム１９００はさらに、「主要タスクリスト（Ｍajor Ｔask Ｌist）」メニュー１９０６および「タスクレベル（Ｔask Ｌevel）」メニュー１９０８のようなプルダウンメニューを含む。場合によっては、特定のタスクが、例えば会社のポリシーまたは開発プロジェクトの性質によって、開発プロジェクトに必要であるかもしれない。このような場合、メニュー１９０６は、このような必要なタスクを含むようにプログラムされることが可能である。その結果として、プルダウンメニュー１９０６は、オンラインタスク割当てフォーム１９００を通じてプロジェクトタスクを割り当てる際に、プロジェクト参加者、例えば技術管理者またはプロジェクトリーダによって利用され得る。さらに、主要な、すなわち上位レベルのタスクがプロジェクトのために識別されると、それらのタスクは、アドミニストレータまたはプロジェクト管理者のような者によってメニュー１９０６に追加され得る。一実施態様では、メニュー１９０６は、レベル１タスクとして定義される主要タスクのみを含むが、本発明はそのようには限定されない。「タスクレベル」プルダウンメニュー１９０８は、システムに入力されオンラインタスク割当てフォーム１９００を通じて割り当てられるタスクにレベル（例えば図１６のレベル１〜３）を割り当てるために、管理側プロジェクト参加者によって利用され得る。

図２０は、タスクスケジュールおよび階層情報を入力するために本発明の一実施形態で実施される、オンライン個人タスクスケジューラフォーム２０００の例を示している。タスクスケジューラフォーム２０００は、タスクおよび関連する日付を入力するために使用されるとともに、システムにすでに入力されているタスクを閲覧するために使用されるインタフェースである。タスクスケジューラフォーム２０００は、「タスク（Ｔasks）」列２００２を含む。これは、タスク１６１２の「共通」（図１６）のようなタスク名を列２００２のフィールドに入力するためのデータ入力フィールドを含む。一実施形態によれば、データベース１０６（図１）のようなデータベースに入力されるタスクが、タスクスケジューラフォーム２０００に提示される。さらに、タスクスケジューラフォーム２０００に提示されるタスクは、タスク階層におけるそれらのタスクの位置を表すように提示される。例えば、列２００４は、「＋」を表示することができる。これは、コンピュータのマウス等のポインティングデバイスでクリックすることが可能であり、それにより、関連する下位レベルタスクが、好ましくはその親、すなわち依存するタスクからインデントされて表示される。例えば、列２００２において「パッケージ設計」タスク１６０６（図１６）の隣の「＋」をクリックすると、それに関係する下位レベルタスク、すなわち、タスク１６０８としてまとめて識別されている「共通」、「ＳendＳervice」、および「Ｓend Ｔimer」タスク（図１６）が表示されることになる。さらに、オンライン個人タスクスケジューラフォーム２０００を通じて、新たな下位レベルタスクをタスク階層のこの特定ステージに直接入力することが可能であり、したがってそのタスクは現在表示されている親タスク（例えばパッケージ設計）に自動的に関連づけられる。一実施形態によれば、この関連づけは依存関係であり、それにより、タスクはその完了のために１つまたは複数の他のタスクの完了に依存する。レベル２タスクは、例えばインデントにより、タスク階層内の他のタスクとの関係で、階層内のそれらの位置を視覚的に描写するように提示される。

タスクスケジューラフォーム２０００はさらに、「主要タスクリスト（Ｍajor Ｔask Ｌist）」メニュー２００６および「タスクレベル（Ｔask Ｌevel）」メニュー２００８であるプルダウンメニューを含む。これらのプルダウンメニューは、主要タスクを閲覧および／または入力するため（メニュー２００６）、ならびに階層的タスクレベルを指定するため（メニュー２００８）に、図１９のメニュー１９０６および１９０８と同様に使用される。

タスクスケジューラフォーム２０００はさらに、開発プロジェクトタスクの履行および完了に関係するいくつかの列を含む。これらは、タスクのそれぞれのスケジュール日付の入力および閲覧のためのデータ入力フィールドを含む。日付列としては、「計画された日付（Ｐlanned date）」列２０１０（図１２の「識別された日付（Ｉdentified Ｄate）」および図１７の「計画日」と同等）、「計画された開始（Ｐlanned Ｓtart）」列２０１２、「計画された終了（Ｐlanned Ｅnd）」列２０１４、「実際の開始（Ａctual Ｓtart）」列２０１６、および「実際の終了（Ａctual Ｅnd）」列２０１８があり、これらはタスクオブジェクトのタスクスケジュール１７０４（図１７）データ要素に対応する。

オンラインタスクスケジューラフォーム２０００の使用は、タスクを定義するタスクオブジェクトに対して作用する。いかなるタスクについても、列２００２および２０１０〜２０１８のいずれかにデータを入力することは、その特定タスクを定義するタスクオブジェクトの状態を作成または変更する。例えば、列２００２内のデータを入力または変更することは、タスク名１７０２属性（図１７）の状態に影響し、列２０１０〜２０１８内のデータを入力または変更することは、タスクスケジュール１７０４属性（図１７）、およびおそらくは履歴のベクタ１７１０属性（図１７）の状態に影響し、特定タスクに関連してのメニュー２００８の使用は、下位レベル参照のベクタ１７０６（図１７）および親参照１７０８の属性（図１７）の状態に影響する。

＜タスクスケジュールデータを更新する方法＞
図２１は、本発明の一実施形態による、タスクスケジュールデータ構造体を更新するプロセスを説明するフローチャートである。図示されているプロセスは、例えば、オンラインタスクスケジューラフォーム２０００を通じて特定の開発プロジェクトに対するタスク階層のいずれかのレベルにあるデータを入力または変更するというようなイベントによって、またはタスクの完了によって、トリガされる。このトリガイベントは、親参照１７０８（図１７）を用いて、親タスクに対する更新プロセス（図２１）をトリガする。図示されているプロセスは、タスク階層のすべてのレベルで動作可能であるが、所与のタスクの視点から、（図示のように）タスクを更新するプロセスはタスク階層を「下方に見ていき」、当該所与のタスクに対する更新を判定し実施するように構成されている。

したがって、所与のタスクに対して、（図１４の管理スケジュール１４００のような）プロジェクトタスクスケジュールに対する更新プロセスをトリガするアクションがあると、ステップ２１０２で、所与のタスクが（上記のタスク階層に関して）下位レベルタスク、すなわち子タスクを有するかどうかが判定される。下位レベルタスクが存在しない場合、ステップ２１０４で、本方法はアクションなしで復帰する。例えば、関連するレベル３タスクのないレベル２タスクが処理されている場合、ステップ２１０２の問合せはＮＯとなり、処理は呼出し側プロセスに復帰する。一実施形態では、プロセスは、例えば、図２０のタスクスケジューラフォーム２０００の使用により変更されたトリガ側タスクに復帰する。

ステップ２１０２の応答がＹＥＳである場合、すなわち、所与のタスクが、定義されたタスク階層において下位レベルタスクを有している場合、ステップ２１０６で、トリガアクションが下位レベルタスクの追加であったかどうかが判定される。ステップ２１０６に対する応答がＮＯである場合、ステップ２１０８で、トリガアクションが、下位レベルタスクのタスクスケジュール１７０４データ（図１７）の「計画された」日付（すなわち、計画された開始または計画された終了）に対する変更であったかどうかが判定される。ステップ２１０８に対する応答がＮＯである場合、ステップ２１１０で、実際の開始日が所与のタスクに対して更新されているかどうかが判定される。ステップ２１１０に対する応答がＮＯである場合、ステップ２１１２で、すべての下位レベルタスクが考慮されたかどうかが判定される。ステップ２１１２に対する応答がＮＯである場合、本方法はステップ２１１４で開始点に復帰する。

ステップ２１１２に対する応答がＹＥＳである場合、ステップ２１２６で、下位レベルタスクから最終の実際の終了日が取得され、所与のタスクのデータ構造体に格納される。例えば、所与のタスクの下位レベル参照のベクタ１７０６（図１７）が、所与のタスクのすべての子を識別するためにアクセスされる。ステップ２１２６に従って、各子タスク（ブロック２１２６で下位レベルタスクとして参照される）のタスクスケジュール１７０４（図１７）が、それらのタスクの間で最終の実際の終了日を判定するためにアクセスされ、これはその後所与のタスクのタスクスケジュール１７０４内で参照される。こうして、トリガ側タスクのタスクスケジュール１７０４に対してなされた変更が、必要であれば、所与のタスクのタスクスケジュール１７０４内に「ロールアップ」される。トリガ側タスクに対する変更の結果、そのタスクがその兄弟タスク（すなわち、同一階層レベルにあり、同一親タスクを有するタスク）のうちの最終の実際の終了日を有することにならない場合、所与のタスクスケジュールに対する変更は不要である。ステップ２１２６が完了するとすぐに、ステップ２１１４で、プロセスが呼出し側プロセスに復帰する。一実施形態では、ステップ２１１４は、タスクスケジューラフォーム２０００（図２０）で操作された子タスクの呼出し側プロセスに復帰する。

ステップ２１１０に戻って、ステップ２１１０に対する応答がＹＥＳである場合（すなわち、下位レベルタスクの実際の開始日が更新され、これがトリガイベントである場合）、ステップ２１２４で、所与のタスクの下位レベルタスクから最初の実際の開始日が取得され、所与のタスクのデータ構造体に格納される。ステップ２１２４に従って、各下位レベルタスクのタスクスケジュール１７０４（図１７）が、それらのタスクの間で最初の実際の開始日を判定するためにアクセスされ、これはその後所与のタスクのタスクスケジュール１７０４内で参照される。こうして、トリガ側子タスクのタスクスケジュール１７０４に対してなされた変更が、必要であれば、所与のタスクのタスクスケジュール１７０４内にロールアップされる。トリガ側タスクに対する変更の結果、そのタスクが最初の実際の開始日を有することにならない場合、所与のタスクスケジュールに対する変更は不要である。ステップ２１２４が完了するとすぐに、ステップ２１１４で、プロセスは呼出し側プロセスに復帰する。

ステップ２１０８に戻って、ステップ２１０８に対する応答がＹＥＳである場合（すなわち、下位レベルタスクの計画された開始日または終了日が更新され、これがトリガ側イベントである場合）、プロセスはステップ２１１６に進み、これにより、現在のデータが所与のタスクの履歴のベクタ１７１０（図１７）に移動される。

ステップ２１０６に戻って、ステップ２１０６の応答がＹＥＳである場合（すなわち、下位レベルタスクが追加され、所与のタスクに関連づけられた場合）、ステップ２１１６で、現在のデータが所与のタスクの履歴のベクタ１７１０（図１７）に移動される。ステップ２１１８で、現在の日付が、所与のタスクのタスクスケジュール１７０４（図１７）における計画日として使用される。さらに、トリガ側タスクに対する改訂が、トリガ側タスクの別の関連する親タスクに対する改訂を必要とする場合、現在の日付は、当該別の親のタスクスケジュール１７０４における計画日としても使用される。一実施形態では、現在のデータは、プロジェクト管理システムが実行されているワークステーション１０２（図１）またはコンピュータシステム２００（図２）のようなコンピュータプラットフォームのシステムクロックから取得される。

ステップ２１２０で、下位レベルタスク（これはトリガ側タスクを含む）から最初の計画された開始日が取得され、所与のタスクのデータ構造体に格納される。ステップ２１２０に従って、各下位レベルタスクのタスクスケジュール１７０４（図１７）が、それらのタスクの間で最初の計画された開始日を判定するためにアクセスされ、これはその後所与のタスクのタスクスケジュール１７０４内で参照される。こうして、トリガ側子タスクのタスクスケジュール１７０４に対してなされた変更が、必要であれば、所与のタスクのタスクスケジュール１７０４内にロールアップされる。トリガ側タスクに対する変更が計画された開始日に対するものでない場合、ロジックは単にステップ２１２２に進む。トリガ側タスクに対する変更の結果、そのタスクが最初の計画された開始日を有することにならない場合、所与のタスクスケジュールに対する変更は不要である。

別法として、図２１のロジックは、ステップ２１２０の前に、次のような判定ブロックを含んでもよい。すなわち、この判定ブロックでは、計画された日付に対する変更が計画された開始日に対する変更であるか、それとも計画された終了日に対する変更であるかが判定される。その後ロジックは、その判定ブロックからの結果に応じて、ステップ２１２０またはステップ２１２２のいずれかに進むことができる。

図２１に示された方法に戻って、ステップ２１２２で、ステップ２１２０に関して上記で説明したのと同様に、下位レベルタスクから最終の計画された終了日が取得され、所与のタスクのデータ構造体に格納される。この場合も、トリガ側タスクのタスクスケジュール１７０４に対してなされた変更が、必要であれば、所与のタスクのタスクスケジュール１７０４内にロールアップされる。トリガ側子タスクに対する変更の結果、そのタスクが最終の計画された終了日を有することにならない場合、所与のタスクスケジュールに対する変更は不要である。ステップ２１２２が完了するとすぐに、ステップ２１１４で、プロセスは開始点に復帰する。

図２１に示されたプロセス全体を通じて、所与のタスクのスケジュールエントリのいずれかが変化した場合、所与のタスクは、親タスク１７０８（図１７）への参照を通してその親タスクにおいて図２１と同じプロセスをトリガすることになる。図２１のプロセスは子タスクによってトリガされるので、ステップ２１０２は、無関係のプロセスが図２１のプロセスフローをトリガしないようにする安全性チェックとなる。

＜ソフトウェア設計仕様＞
図２２は、ソフトウェア設計およびコーディングプロセスの概要を説明するフローチャートである。ブロック２２００で、設計者は設計仕様文書を起草する。設計仕様文書は多くの形態をとり得るが、一実施形態では、設計仕様文書はクラス仕様セクションを含む。

クラス仕様の一部の例（ＨＴＴＰ＿ＨＴＭＬクラス仕様：Ａ００と称す）を表１〜表３に示す。この実施形態によれば、クラス仕様は次の３つのセクションに編成される。すなわち、（１）関数リストＡ０２、（２）クラス属性Ａ０４、および（３）関数定義Ａ０６である。

表１の関数リストＡ０２セクションは、設計仕様のクラス仕様セクションで記述される特定クラスの関数宣言を含む。表１〜表３の例示的クラス仕様Ａ００では、「ＣＨＴＴＰ＿ＨＴＭＬ」という名前のクラスが指定される。さらに、関数リストＡ０２は、関数リストＡ０２で宣言される関数に関連するパラメータを含む。一実施態様では、関数のパラメータには、そのパラメータがそれぞれの関数でどのように使用されるかに応じて「ｉｎ＿」、「ｏｕｔ＿」または「ｉｎＯｕｔ＿」というプレフィクスが付けられる。例えば、パラメータＡ１０は、「ｉｎ＿ｓＩＰ」という名前のパラメータを表しており、またパラメータＡ１２は、「ｏｕｔ＿ＳtatusＩnfo」という名前のパラメータを表している。上記のプレフィクスが例として提示されているが、パラメータ名前付けに関連する組織規則および必要な付加物の意味は後でさらに説明する。

さらに、構造体も関数リストＡ０２で宣言されてよい。例えば、構造体Ａ１４は、「ＶendorＭodelＩnfo」という名前の構造体を表している。一実施態様では、構造体のメンバには、構造体メンバＡ１６の「ｍ＿ｓＶendorＮame」によって表されているように、「ｍ＿」というプレフィクスが付けられる。上記のプレフィクスは例として提示されているが、名前付け規約の意味は後でさらに説明する。

表２のクラス属性Ａ０４セクションは、設計仕様文書のクラス仕様セクションで記述される特定クラスの属性メンバを記載し、かつ定義する。一実施態様では、属性名には「ｍ＿」というプレフィクスが付けられる。例えば、属性Ａ１８は「ｍ＿ＶendorＭodelＩnfoVector」という名前の属性を表している。上記のプレフィクスが例として提示されているが、クラス属性名前付けに関連する組織規則および必要な付加物の意味は後でさらに説明する。

表３の関数定義Ａ０６セクションは、設計仕様文書のクラス仕様セクションで記述される特定クラスに関連する関数を実装するために使用されるアルゴリズムを記述する。パラメータＡ１０およびＡ１２のような関数パラメータならびに属性Ａ１８のようなクラス属性が、関数定義Ａ０６セクションで記述される関数定義で使用される。

さらに、関数定義で使用されるローカル変数が、関数定義Ａ０６セクションの関連アルゴリズムで指定されてもよい。一実施態様では、関数定義Ａ０６セクションで指定されるローカル変数名には「ｌｏｃ＿」というプレフィクスが付けられる。上記のプレフィクスが例として提示されているが、ローカル変数名前付けに関連する組織規則および必要な付加物の意味は後でさらに説明する。

図２２に戻って、ブロック２２０２で、対応する設計仕様文書に関連するソフトウェアコードが、その内部のロジックを検証するためにテストされる。ブロック２２００がブロック２２０２と同時並行して、または反復的に実行されることも多い。ブロック２２０４で、ブロック２２００で生成されたドラフト設計仕様文書が検討され検査される。ブロック２２０４の検討および検査プロセスは、１つの統合されたプロセスであっても、または複数のプロセスであってもよい。

ブロック２２０６で、ブロック２２０４の検査に合格した後、設計仕様文書は、組織の内部で公式文書として登録される。公式文書として、設計仕様は、文書管理システムを通じて管理される。さらに、設計仕様文書は、より大きなソフトウェア仕様文書の一部であってもよい。最後に、ブロック２２０８で、適切な時に、ソフトウェアコーダが、設計仕様に指定された設計を実施する。この目的のため、コーダは通常、ソフトウェアをコーディングしテストする。

＜設計仕様検証ツール＞
図２３は、図５Ａの検証ツール５１２のような、設計仕様検証ツール（「検証ツール」）の機能コンポーネントを示すブロック図である。検証ツール５１２は、変数チェッカ２３０２、規則２３０４、レポータ２３０６ならびに任意選択で、名前付け規則エンフォーサ２３０８およびクラスレコンサイラ２３１０を含む。

変数チェッカ２３０２は、設計仕様のクラス属性セクションに記述されているクラス属性名と対照して、設計仕様の関数定義セクション内のクラス属性名を自動的にチェックするように構成される。例えば表１〜表３を参照すると、変数チェッカ２３０２は、クラス仕様Ａ００の関数定義Ａ０６セクションに記載されているクラス属性名を見つけ、それを同一設計仕様のクラス仕様Ａ００のクラス属性Ａ０４セクションに記述されているクラス属性名と比較する。

例えば、変数チェッカは、関数定義Ａ０６で参照されているクラス属性名Ａ２０（ｍ＿ＶendorＭodelＩnfoＶector）を見つけ、クラス属性名Ａ２０を、クラス属性Ａ０４に記述されているクラス属性名と比較する。この例では、クラス属性名Ａ１８（ｍ＿ＶendorＭodelＩnfoＶector）がクラス属性Ａ０４に見つかり、関数定義Ａ０６のクラス属性名Ａ２０と一致する。よって、設計仕様がクラス属性ｍ＿ＶendorＭodelＩnfoＶectorに関して正しいことが検証される。すなわち、特定のクラス属性に関してスペルミスがなく、また特定のクラス属性に関してクラス仕様Ａ００のクラス属性Ａ０４と関数定義Ａ０６のセクション間に不整合がない。一実施形態では、変数チェッカ２３０２は、関数定義Ａ０６内に他にクラス属性ｍ＿ＶendorＭodelＩnfoＶectorが出現すればそれを見つけ、それをもとの出現と対照して検証する。一実施形態では、クラス属性名が関数定義Ａ０６に現れるがクラス属性Ａ０４には見つからないことが発見された場合、そのクラス属性名は格納され、未宣言、または未定義のクラス属性名として報告される。こうして、スペルミスは、２つのセクション間の不整合に基づいて特定されることになる。

変数チェッカ２３０２はさらに、設計仕様の関数定義セクション内の関数パラメータ名を、同一設計仕様の関数リストセクション内の関数パラメータ名と対照して自動的にチェックするように構成される。例えば表１〜表３を参照すると、変数チェッカ２３０２は、設計仕様のクラス仕様Ａ００の関数定義Ａ０６セクションに含まれる関数パラメータ名を見つけ、それを同一設計仕様のクラス仕様Ａ００の関数リストＡ０２で宣言されている関数パラメータ名と比較する。

例えば、変数チェッカは、関数定義Ａ０６内の関数Ａ２１（setＩＰＡddress）の関数パラメータ名Ａ２２（ｉｎ＿ｓＩＰ）を見つけ、関数パラメータ名Ａ２２を、関数リストＡ０２に含まれ、すなわち宣言されている関数パラメータ名と比較する。この例では、関数パラメータ名Ａ１０（ｉｎ＿ｓＩＰ）が関数リストＡ０２内のＡ１１（setＩＰＡddress）に見つかり、関数定義Ａ０６の関数パラメータ名Ａ２２と一致する。よって、設計仕様は関数パラメータ名ｉｎ＿ｓＩＰに関して正しい。すなわち、パラメータ名に関してスペルミスがなく、また特定の関数パラメータ名に関してクラス仕様Ａ００の関数リストＡ０２と関数定義Ａ０６のセクション間に不整合がない。さらに、変数チェッカ２３０２は、関数定義Ａ０６内に他に任意のパラメータ名ｉｎ＿ｓＩＰが出現すればそれを見つけ、それをもとの出現と対照して検証する。一実施形態では、パラメータ名が関数定義Ａ０６に現れるが関数リストＡ０２には見つからないことが発見された場合、そのパラメータ名は格納されるか、あるいは未宣言パラメータとして報告されることが可能である。こうして、スペルミスは、２つのセクション間の不整合に基づいて識別されることになる。

一実施形態では、変数チェッカ２３０２はさらに、関数定義Ａ０６で参照されるローカル変数名を探索するように構成される。ローカル変数は、関数定義Ａ０６内のアルゴリズムで指定されてもよい。ローカル変数名が関数定義Ａ０６で指定される場合、それらのローカル変数名は、組織規則に従って名前付けされるべきである。しかし、ローカル変数名はクラス仕様Ａ００の他のセクションでは必ずしも使用されず、そのため関数定義Ａ０６セクションで見つかった場合、そのローカル変数名をチェックすべき他のセクションはない。そこで、ローカル変数名が関数定義Ａ０６内の所与のアルゴリズムで１回だけ見つかった場合、その変数は、所与のアルゴリズム内のどこか他の場所で誤ったスペルで綴られている可能性が存在する。決定的ではないが、関数定義Ａ０６のアルゴリズム内でローカル変数名が１回だけ出現することは、設計仕様にエラーがあるかもしれないことを意味し得るので、ローカル変数名の単一出現は報告される。別法として、ローカル変数の出現頻度を報告してもよい。したがって、ユーザは、エラーの可能性が警告され、問題をさらに調査することができる。

上記のようなクラス属性名および関数パラメータ名に関係するチェックに関して、検証ツール５１２は、矛盾が見つかればそれを報告する。例えば、検証ツール５１２のレポータ２３０６は、問題を表すデータをローカルメモリまたは共有メモリに保存することによって、問題の指示を表示することによって、問題の指示を印刷することによって、またはこれらのいずれかの組合せによって、検証中の設計仕様に関する矛盾があればそれを報告することができる。さらに、ローカル変数の出現が検証される実施形態では、レポータ２３０６は、同じいずれかの方法によりローカル変数の単一出現を報告することができる。一実施形態では、矛盾を報告する際に使用される情報は、所与の属性またはパラメータが関数定義Ａ０６に表されているそれぞれの関数で使用される回数を含む。

規則２３０４は、例えば、クラス属性名、関数パラメータ名、構造体名およびローカル変数名に関する組織名前付け規約に関する文書化規則を含む。例えば、一実施態様では、属性名には「ｍ＿」というプレフィクスが付けられ、関数パラメータには「ｉｎ＿」、「ｏｕｔ＿」または「ｉｎＯｕｔ＿」のいずれかのプレフィクスが付けられ、ローカル変数名には「ｌｏｃ＿」というプレフィクスが付けられる。規則２３０４は、上記の規則の数またはタイプには限定されない。というのは、規則２３０４は、設計仕様生成に関係する任意個数の組織制約、すなわち、名前付け規則等を含むように実施され得るからである。規則２３０４に具現化される他の規約が、設計仕様の他の要素を検証するために使用可能である。

規則２３０４は、設計仕様文書またはファイルをチェックするために変数チェッカ２３０２によって使用される。規則２３０４に具現化される名前付け規約は、クラス仕様Ａ００の異なるセクション（すなわち、関数リストＡ０２、クラス属性Ａ０４、関数定義Ａ０６）内の適用可能な要素、例えば、クラス属性名、関数パラメータ名およびローカル変数名を探索するために、それらの要素がクラス仕様Ａ００の他のセクションにおける出現と比較され得るように使用される。当該要素のタイプが、規則２３０４に基づいて、例えばそれぞれの要素タイプに関連する名前付けプレフィクスによって、関数リストＡ０２またはクラス属性Ａ０４のセクションに見つかるとすぐに、関数定義セクションＡ０６が、対応する要素を求めて検索される。この検索は、適用可能なプレフィクスだけでなく、それぞれのセクションに見つかる完全な要素名または要素名の一部を必要とし得る。こうして、対応する要素のスペルミスされた出現が、より容易に見つかる可能性が高くなる。

これらの教示の実施態様はさまざまとなり得る。例えば、要素がまず関数定義Ａ０６で探索された後、関数リストＡ０２およびクラス属性Ａ０４内の対応する要素を検索し、それにより検証されてもよい。

検証ツール５１２の任意の名前付け規則エンフォーサ２３０８は、設計仕様のクラス仕様Ａ００内の要素の出現に対して名前付け規則を強制することができるモジュールである。例えば、クラス仕様Ａ００の種々のセクション内に矛盾が発見された場合、名前付け規則エンフォーサ２３０８は、規則に従ってスペルミスされた要素の名前を付け直すことによって矛盾点を一致させるように構成される。規則２３０４が、名前付け規約を強制する間に名前付け規則エンフォーサ２３０８によって参照される。さらに、検証ツール５１２は、名前付け規則エンフォーサ２３０８に加えて、またはその代わりに、他の同様に機能する規則エンフォーサとともに構成されてもよく、それにより、任意個数の他の規則または組織規約が設計仕様文書に対して強制されることが可能である。

検証ツール５１２の任意のクラスレコンサイラ２３１０は、ソフトウェアアプリケーションの異なるクラス間で、要素、例えばクラス属性名および関数パラメータ名の使用法を一致させることができるモジュールである。最初のクラス（設計仕様のクラス仕様によって表される）が検証ツール５１２によって処理された後、他のクラス仕様のその後の検証は、最初のクラスを検証し、かつ一致させる際に得られる知識を使用することができる。したがって、異なる対応するクラス仕様によって表される異なるクラス間の一貫性が、参照されるクラス属性および関数パラメータに関して保証される。検証ツール５１２の機能が、本明細書で論考した、具体的に想定されているもの以外の他の要素の検証を含むように拡張される場合、クラスレコンサイラ２３１０の機能は、種々のクラス仕様間で当該他の要素を一致させるために、それに応じて拡張されることが可能である。

一実施形態では、クラスレコンサイラ２３１０は、親クラスと、関連する任意の派生クラスとの間で要素を一致させるように構成される。よって、派生クラスの検証は、親クラスを検証する際に得られる知識を使用することによって利益を受ける。

＜設計仕様文書を検証するプロセス＞
図２４は、電子設計仕様文書を検証するプロセス２４００を説明するフローチャートである。プロセス２４００への入力は、設計仕様文書を表現し、かつ適当なコンピュータ可読媒体に格納されている１つまたは複数のコンピュータ可読ファイルである。例えば、設計仕様文書の複数のクラス仕様のそれぞれのクラス仕様が、別個のコンピュータ可読ファイルとして表現されてもよい。プロセス２４００は、コンピュータソフトウェアコードとして、したがって自動化された検証プロセスとして具現化される。さらに、プロセス２４００は、検証ツール５１２（図２３）によって実行されてもよい。プロセス２４００は、本明細書で説明される諸実施形態の特定の実施態様を表している。したがって、ステップによってはプロセス２４００において追加または削除されてもよいものもあり、その結果として得られるプロセスも依然として、より一般的な本明細書の教示の範囲内に入る。

判定ブロック２４０２で、入力ファイルが指定されているかどうかが判定される。入力ファイルが指定されていないと判定されることは、不適当な入力コマンドがプログラムプロセスに提示されたことを示している。入力ファイルが指定されていない場合、ブロック２４０４でエラーメッセージが報告され、またブロック２４０６でプロセスは終了する。一実施形態では、エラーメッセージは、プロセス２４００を実施するプログラムの使用法についての案内を含む。ブロック２４０２で、入力ファイルが指定されていると判定された場合、ブロック２４０８でプログラムのタイトルが報告される。例えば、一実施態様では、ブロック２４０８で、「Ｖariable Ｃhecker」が、出力ファイルoutput．txtの最初の付近に報告される。

判定ブロック２４１０で、まだ他に処理すべきファイル名があるかどうかが判定される。一実施態様では、設計仕様のクラス仕様を表すファイル名は、配列としてコマンドラインからプロセス２４００に渡され、配列に示される順序で処理される。他に処理すべきファイル名がない場合、ブロック２４１２で終了メッセージが報告され、ブロック２４１４でプロセスは終了する。ブロック２４１０で、まだ他に処理すべきファイル名があると判定された場合、すなわち、コマンド配列に示される処理すべきクラス仕様がまだ他にある場合、ブロック２４１６で次の未処理ファイルが取得される。

判定ブロック２４１８で、現在処理中のファイルが正しいファイルタイプであるかどうかが判定される。非限定的例として、一実施態様によれば、すべてのクラス仕様ファイルがＨＴＭＬフォーマットであることが要求される。ファイルタイプがクラス仕様ファイルとして正しくない場合、プロセスは判定ブロック２４１０に戻り、まだ他に処理すべきファイルがあるかどうかが判定される。ブロック２４１８で、現在のファイルのファイルタイプが正しいと判定された場合、ブロック２４２０でファイルがオープンされる。判定ブロック２４２２で、ブロック２４２０におけるファイルのオープンが不成功である場合、プロセスはブロック２４１０に戻り、まだ他に処理すべきファイルがあるかどうかが判定される。例えば、ファイルはファイル破損のためにオープンに成功しないかもしれない。

ブロック２４２０におけるファイルのオープンが成功した場合、判定ブロック２４２４で、ファイルがクラス仕様を表現しているかどうかが判定される。ファイルがクラス仕様を表現していない、または含まない場合、プロセスは判定ブロック２４１０に戻り、まだ他に処理すべきファイルがあるかどうかが判定される。例えば、クラス仕様ファイル名以外のファイル名が、不注意により入力コマンドを通してプロセスに渡されてしまっているかもしれない。ファイルがクラス仕様を表現している場合、ブロック２４２６でクラス名が報告される。非限定的例として、表１〜表３のクラス仕様との関連では、「ＣＨＴＴＰ＿ＨＴＭＬ」が出力ファイルoutput．txtに関連して報告される。

ブロック２４２８で、関数名および関連するパラメータが格納される。例えば、クラス仕様Ａ００の関数リストＡ０２（表１）が走査および／または解析され、関数リストＡ０２に見つかった関数および関連するパラメータがメモリに格納される。

ブロック２４３０で、属性名が格納される。例えば、クラス仕様Ａ００のクラス属性Ａ０４（表２）が走査および／または解析され、関数リストＡ０２に見つかった属性がメモリに格納される。

ブロック２４３２で、処理すべき関数があるかどうかが判定される。例えば、Ａ００のようなクラス仕様の関数リストＡ０２（表１）に全く関数が記載されていない可能性がある。その場合、関数定義Ａ０６（表３）セクションはないであろう。すると、プロセスはブロック２４１０に戻り、まだ他に処理すべき入力ファイルがあるかどうかが判定される。ブロック２４３２で、処理すべき関数がもう存在しないと判定された場合、プロセスはブロック２４１０に戻り、まだ他に処理すべき入力ファイルがあるかどうかが判定される。処理すべき関数がある場合、ブロック２４３４で、クラス仕様Ａ００の関数定義Ａ０６のような、ファイルの関数定義セクションが探索される。

関数を特定するために関数定義Ａ０６が走査および／または解析され、各関数が順に処理される。ブロック２４３６で、現在処理中の関数の名前が報告される。例えば、関数名はoutput．txtのような出力ファイルに格納され、これを印字することができる。判定ブロック２４３８で、関数名が、例えばブロック２４２８で格納されているかどうかが判定される。こうして、ブロック２４２８で、クラス仕様ファイルの関数リスト（例えば、表１の関数リストＡ０２）に見つかった関数名が格納されているので、ブロック２４３８で、関数定義セクション（例えば、表３の関数定義Ａ０６）が処理され、関数定義セクションで定義されている関数が関数リストセクションに見つかった関数と整合しているかどうかが判定される。したがって、関数定義セクションは、設計仕様のクラス仕様の関数リストセクションと対照して検証され、関数名のそれぞれの出現が整合しているかどうかが判定される。

ブロック２４３８で、関数定義セクションに見つかった関数名がすでに格納されたものではない場合、ブロック２４４０で、処理中の関数が宣言されていないことの指示がなされる。例えば、関数名が未宣言関数として出力ファイルに格納され、これを印字することができる。宣言されていない関数に遭遇することは、その関数が関数定義Ａ０６または関数リストＡ０２のいずれかでスペルミスされていることを示している可能性がある。というのは、一致する関数名が見つからなかったからである。

関数を未宣言と指摘することは、単に関数名がクラス仕様の関数リストまたは関数定義のいずれかのセクションでスペルミスされていることを意味するだけかもしれない。名前付け規則エンフォーサ２３０８（図２３）を含む実施形態では、関数のスペルミスされた出現を探索し、スペルミスされた出現を訂正するように名前付け規則を強制することによって、「未宣言」関数を一致させることが可能であり、それにより、クラス仕様全体を通じて一貫した正しい関数名前付けが得られる。例えば、関数定義Ａ０６で定義されている関数を処理している間に関数名setＩＰＯＡddressに遭遇し、関数定義Ａ０６のそれぞれの関数名を関数リストＡ０２と比較している間に関数リストＡ０２において関数名setＩＰＡddressに遭遇した場合、setＩＰＯＡddressが未宣言関数名として報告される。さらに、規則エンフォーサは、関数リストＡ０２が正しいスペルの関数名を宣言しているとの仮定の下で、関数定義Ａ０６で見つかった関数名setＩＰＯＡddressを、関数リストＡ０２で見つかったsetＩＰＡddressに訂正するように動作することができる。

未宣言関数の存在によりブロック２４４０に到達した場合、関数パラメータチェックは迂回され、またブロック２４４６で、クラス仕様の関数定義セクション（例えば、表３の関数定義Ａ０６）で参照されている見つかったクラス属性名が、ブロック２４３０で格納されたものと対照してチェックされ、一致するパラメータ名が存在するかどうかが判定される。

判定ブロック２４３８に戻って、現在の関数名が格納されていると判定された場合、ブロック２４４２で、関数定義セクションで現在の関数に関連するパラメータ名がチェックされ、それらが、例えばブロック２４２８で格納されているかどうかが判定される。現在の関数に関連する所与の任意のパラメータ名が格納されていない場合、ブロック２４４４で、当該所与のパラメータ名が未宣言パラメータとして報告（例えば格納）され、当該所与のパラメータ名に関連する未宣言パラメータ頻度変数がインクリメントされる。

現在の関数に関連するすべてのパラメータ名がブロック２４２８で格納されたパラメータ名と対照してチェックされるとすぐに、プロセスはブロック２４４６に進み、クラス属性名がチェックされる。すなわち、クラス仕様の関数定義セクション（例えば、表３の関数定義Ａ０６）で参照されている各クラス属性名が、クラス仕様のクラス属性セクション（例えば、表２のクラス属性Ａ０４）で見つかったクラス属性名と比較され、かつブロック２４３０で格納される。現在の関数に関連する所与のクラス属性名が格納されていない場合、ブロック２４４８で、当該所与のクラス属性名が未宣言または未定義クラス属性として報告（例えば、出力ファイルに格納）され、当該所与のクラス属性名に関連する未宣言属性頻度変数がインクリメントされる。

未宣言関数の場合と同様に、名前付け規則エンフォーサ２３０８（図２３）を含む実施形態では、それぞれのパラメータおよびクラス属性のスペルミスされた出現を探索し、スペルミスされた出現を訂正するように名前付け規則を強制することによって、「未宣言」のパラメータおよびクラス属性を一致させることが可能であり、それにより、クラス仕様全体を通じて一貫した正しい名前付けが得られる。

ブロック２４５０で、クラス仕様の関数定義セクション（例えば、表３の関数定義Ａ０６）で参照されている任意のローカル変数名があればそれが報告（例えば、出力ファイルに格納）される。さらに、それらが所与の関数に現れる頻度が格納される。上記のように、ローカル変数名が所与の関数定義に１回だけ現れる場合、当該所与の関数定義内のローカル変数名がスペルミスされて他に出現している可能性がある。

ブロック２４５２で、ブロック２４４４で発見され、かつ格納された未宣言パラメータ名、ブロック２４４８で発見され、かつ格納された未宣言属性名、およびそれらに関連する頻度変数のそれぞれの値が報告される。ブロック２４５４で、ブロック２４５０で発見され、かつ格納されたローカル変数名およびそれらに関連する頻度変数のそれぞれの値が報告される。例えば、検証ツール５１２（図２３）のレポータ２３０６（図２３）が、上記のパラメータ、属性およびローカル変数の名前ならびにそれらに関連する頻度を印刷する。

最後に、プロセスはブロック２４３２に戻り、まだ他に処理すべき関数があるかどうかが判定される。依然として処理を必要とする関数が関数リスト（例えば、表１の関数リストＡ０２）に発見された場合、プロセスは再びブロック２４３４に進み、関数定義セクション（例えば、表３の関数定義Ａ０６）で現在の関数を捜す。ブロック２４３２で、現在のクラス仕様ファイルに対して処理すべき関数がもう存在しないと判定された場合、ブロック２４１０で、まだ処理されていない入力ファイル名が他にあるかどうかが判定される。まだ他に処理すべきファイルがある場合、プロセスはブロック２４１６に進み、次のファイルを取得する。処理すべきファイルが他に存在しない場合、ブロック２４１２で終了メッセージが報告（例えば、印刷のために出力ファイルに格納）され、自動化された設計仕様検証プロセスは終了する。

本明細書で説明された実施形態は、設計仕様文書の特定のセクションを参照している。例えば、設計仕様文書の「クラス仕様」部分の「関数リスト」、「クラス属性」、および「関数定義」セクションという用語が全体を通じて使用されている。しかし、本発明の実施形態の使用は、これらの特定のタイトルを有するセクションでの使用に限定されない。というのは、異なるタイトルを有する同様のセクションに関連した実施形態の使用も具体的に想定されるからである。上記のタイトルの使用は、より一般的な本明細書の教示の実施態様の一例である。したがって、クラスに関連する関数および関連パラメータを記載または宣言するクラス仕様のセクション、クラスに関連するクラス属性を記載するセクション、およびクラスに関連する関数を基礎づけるアルゴリズムを定義するセクションが、上記の教示に従って解析され、かつ処理されることが可能である。

このように、上記の詳細な説明は、設計仕様の自動検証技法を説明している。さらに、本開示では、いくつかのプロセスステップが特定の順序で記載され、またいくつかのステップを識別するために英字および英数字ラベルが使用されている。本開示で特に断らない限り、本発明の実施形態は、このようなステップを実行するいかなる特定の順序にも限定されない。特に、ラベルは単にステップの便宜的識別のために使用されており、このようなステップを実行する特定の順序を含意、指定または要求することを意図していない。

以上、本明細書において、本発明は、その特定の実施形態に関連して説明されている。しかし、より一般的な本発明の精神および範囲から逸脱することなく、それらの実施形態に種々の変更形態および変形形態を行うことが明らかである。よって、本明細書および図面は、制限的ではなく例示的なものとみなされるべきである。

本発明の諸態様が実施され得る動作環境の例を示す図である。 本発明の諸実施形態が実施され得るコンピュータシステムを示すブロック図である。 本発明の一実施形態によるデータベースのデータコンポーネントおよびウェブコンポーネントの例を示す図である。 本発明の一実施形態による、ネットワークを通じてプロジェクトファイルの自動化された管理を開始するステップを示すフローチャートである。 本発明の一実施形態による、文書検査プロセスに関連して個人（クライアント）が実行するステップを示すフローチャートである。 本発明の一実施形態による、図４ＢのＲ１から続くサーバ側プロセスを示すフローチャートである。 本発明の一実施形態による、図４ＢのＲ２から続くサーバ側プロセスを示すフローチャートである。 本発明の一実施形態による、オンライン対話フォームを通じてプロジェクトを開始する構成のブロック図である。 本発明の一実施形態で利用可能な、印刷または表示されたプロジェクト開始フォームの例を示す図である。 図５Ｂの例示的な印刷／表示されたプロジェクト開始フォームの続きの図である。 本発明の一実施形態による、プロジェクトサイトの例を示す図である。 本発明の一実施形態による、プロジェクト文書インデックスの例を示す図である。 本発明の一実施形態による、例示的ウェブインデックスページ、プロジェクトデータベース、およびデータベースによって管理される電子的または物理的ファイル／オブジェクトの間のリンク関係を示す図である。 本発明の一態様による、ネットワークを通じてプロジェクトファイルを管理するステップを示すフローチャートである。 個人タスクスケジュールが自動的に管理される、図８の方法の一実施形態を示す図である。 総括管理スケジュールが自動的に管理される、図８の方法のもう１つの実施形態を示す図である。 本発明の一態様による、プロジェクトスケジュールを管理するために利用される関連づけを示すブロック図である。 本発明の一実施形態による、個人タスクスケジュールの例を示す図である。 本発明の一実施形態による、個人タスクスケジュールを自動的に更新するために利用されるオンライン検査フォームの印刷または表示された例を示す図である。 本発明の一実施形態による、管理スケジュールの例を示す図である。 本発明の一態様による、プロジェクトのためにスケジュールを生成し更新するステップを示すフローチャートである。 本発明の一実施形態による、開発プロジェクトを管理するために使用可能なタスク階層を表す図である。 本発明の一実施形態による、タスクデータ構造体を図式的に示す図である。 本発明の一実施形態による、タスクデータ構造体の階層関係を示す図である。 本発明の一実施形態による、オンラインタスク割当てフォームの例を示す図である。 本発明の一実施形態による、オンライン個人タスクスケジューラフォームの例を示す図である。 本発明の一実施形態による、タスクスケジュールデータ構造体を更新する方法を示すフローチャートである。 ソフトウェア設計およびコーディングプロセス概要を示すフローチャートである。 設計仕様検証ツールの機能コンポーネントを示すブロック図である。 設計仕様文書を検証するプロセスを示すフローチャートである。

符号の説明

１０２ ワークステーション
１０８ ソフトウェア開発ネットワーク環境
１０６、１１０ データストレージ／データベース
１０４ ウェブサーバ
２１２ ディスプレイ
２１４ 入力デバイス
２１６ カーソルコントロール
２０６ メインメモリ
２１０ 記憶デバイス
２０２ バス
２０４ プロセッサ
２１８ 通信インタフェース
２３０ サーバ
２２８ インターネット
２２０ ネットワークリンク
２２２ ローカルネットワーク
２２４ ホスト

Claims (36)

1. 電子ソフトウェア設計仕様文書を検証する方法であって、コンピュータにより実施される以下のステップ、すなわち、
   前記設計仕様文書の第１セクションで定義されている関数を特定するステップと、
   前記関数が前記設計仕様文書の第２セクションで宣言されているかどうかを自動的に判定するステップと、
   前記関数が前記第２セクションで宣言されていない場合、該関数が宣言されていないことを報告するステップと、
   を含む電子ソフトウェア設計仕様文書を検証する方法。
2. 前記第１セクションは、ソフトウェアアプリケーションに関連する関数を記載する請求項１に記載の電子ソフトウェア設計仕様文書を検証する方法。
3. 前記第１および第２セクションは、前記設計仕様文書のクラス仕様に関連している請求項１に記載の電子ソフトウェア設計仕様文書を検証する方法。
4. 前記ソフトウェア設計仕様文書に関連するコンピュータソフトウェアコードをコンパイルする、コンピュータにより実施されるステップ、
   をさらに含む請求項１に記載の電子ソフトウェア設計仕様文書を検証する方法。
5. 前記特定するステップ、前記判定するステップおよび前記報告するステップは、前記ソフトウェア設計仕様に関連するコンピュータソフトウェアコードをコンパイルする前に実行される請求項１に記載の電子ソフトウェア設計仕様文書を検証する方法。
6. コンピュータにより実施される以下のステップ、すなわち、
   前記関数が前記第２セクションで宣言されている場合、前記第１セクションにおける前記関数に関連するパラメータが前記設計仕様文書の前記第２セクションで宣言されているかどうかを自動的に判定するステップと、
   前記関数に関連する前記パラメータが前記第２セクションで宣言されていない場合、前記パラメータを未宣言パラメータとして格納するステップと、前記パラメータおよび前記関数に関連する未宣言パラメータ頻度変数をインクリメントするステップと、
   をさらに含む請求項１に記載の電子ソフトウェア設計仕様文書を検証する方法。
7. 未宣言の前記パラメータおよび前記未宣言パラメータ頻度変数の値の両方を報告する、コンピュータにより実施されるステップ、
   をさらに含む請求項４に記載の電子ソフトウェア設計仕様文書を検証する方法。
8. コンピュータにより実施される以下のステップ、すなわち、
   前記第１セクションにおける前記関数に関連するクラス属性が前記設計仕様文書の第３セクションに記述されているかどうかを自動的に判定するステップと、
   前記関数に関連する前記クラス属性が前記第３セクションに記述されていない場合、前記クラス属性を未宣言クラス属性として格納するステップと、前記クラス属性および前記関数に関連する未宣言属性頻度変数をインクリメントするステップと、
   をさらに含む請求項１に記載の電子ソフトウェア設計仕様文書を検証する方法。
9. 未宣言の前記クラス属性および前記未宣言属性頻度変数の値の両方を報告する、コンピュータにより実施されるステップ、
   をさらに含む請求項８に記載の電子ソフトウェア設計仕様文書を検証する方法。
10. 前記第３セクションは、ソフトウェアアプリケーションに関連するクラスのクラス属性を記載する請求項８に記載の電子ソフトウェア設計仕様文書を検証する方法。
11. コンピュータにより実施される以下のステップ、すなわち、
    前記第１セクションで参照されているローカル変数名を格納するステップと、
    前記ローカル変数名および前記関数に関連するローカル変数名頻度変数をインクリメントするステップと、
    前記ローカル変数名および前記ローカル変数名頻度変数の値を報告するステップと、
    をさらに含む請求項１に記載の電子ソフトウェア設計仕様文書を検証する方法。
12. 設計仕様文書ファイルのファイルタイプを検証する、コンピュータにより実施されるステップ、
    をさらに含む請求項１に記載の電子ソフトウェア設計仕様文書を検証する方法。
13. １つまたは複数の規則のセットを前記設計仕様文書に自動的に適用する、コンピュータにより実施されるステップ、
    をさらに含む請求項１に記載の電子ソフトウェア設計仕様文書を検証する方法。
14. 前記規則のセットは、特定の付加物が前記設計仕様文書内の属性名に関連していることを要求する規則を含む請求項１３に記載の電子ソフトウェア設計仕様文書を検証する方法。
15. 前記規則のセットは、特定の付加物が前記設計仕様文書内のパラメータ名に関連していることを要求する規則を含む請求項１３に記載の電子ソフトウェア設計仕様文書を検証する方法。
16. 前記規則のセットは、特定の付加物が設計仕様文書内のローカル変数名に関連していることを要求する規則を含む請求項１３に記載の電子ソフトウェア設計仕様文書を検証する方法。
17. ソフトウェア設計仕様文書を検証する方法であって、コンピュータにより実施される以下のステップ、すなわち、
    設計仕様文書ファイルのファイルタイプを検証するステップと、
    前記設計仕様文書のクラス仕様の関数リストセクションで宣言されている１つまたは複数の関数名および関連する１つまたは複数のパラメータ名を格納するステップと、
    前記クラス仕様のクラス属性セクションに記載されている１つまたは複数の属性名を格納するステップと、
    前記クラス仕様の関数定義セクションで定義されている１つまたは複数の関数のそれぞれについて、それぞれの関数名が格納されているかどうかを判定するステップと、
    それぞれの関数名が格納されていない場合、該それぞれの関数が宣言されていないことを指示するステップと、
    それぞれの関数名が格納されている場合、前記関数定義セクションにおいて前記それぞれの関数名に関連する１つまたは複数のパラメータ名のそれぞれのパラメータ名が格納されているかどうかを判定するステップと、
    前記それぞれの関数に関連するそれぞれのパラメータ名が格納されていない場合、前記それぞれのパラメータ名を未宣言パラメータとして格納するステップと、前記それぞれのパラメータ名および前記それぞれの関数に関連する未宣言パラメータ頻度変数をインクリメントするステップと、
    もしあれば、１つまたは複数の未宣言パラメータ名と、関連する未宣言パラメータ頻度変数の値とを報告するステップと、
    前記関数定義セクションにおいて前記それぞれの関数名に関連する１つまたは複数の属性名のそれぞれの属性名が格納されているかどうかを判定するステップと、
    前記それぞれの関数に関連するそれぞれの属性名が格納されていない場合、前記それぞれの属性名を未宣言属性として格納するステップと、前記それぞれの属性名および前記それぞれの関数に関連する未宣言属性頻度変数をインクリメントするステップと、
    もしあれば、１つまたは複数の未宣言属性名と、関連する未宣言属性頻度変数の値とを報告するステップと、
    を含む電子ソフトウェア設計仕様文書を検証する方法。
18. 電子ソフトウェア設計仕様文書を検証する１つまたは複数の命令シーケンスを備えるコンピュータ可読媒体であって、前記１つまたは複数の命令シーケンスが１つまたは複数のプロセッサに、
    前記設計仕様文書の第１セクションで定義されている関数を特定するステップと、
    前記関数が前記設計仕様文書の第２セクションで宣言されているかどうかを自動的に判定するステップと、
    前記関数が前記第２セクションで宣言されていない場合、前記関数が宣言されていないことを報告するステップと、
    を実行させるコンピュータ可読媒体。
19. 前記第１セクションは、ソフトウェアアプリケーションに関連する関数を記載する請求項１８に記載のコンピュータ可読媒体。
20. 前記第１および第２セクションは、前記設計仕様文書のクラス仕様に関連している請求項１８に記載のコンピュータ可読媒体。
21. １つまたは複数の命令シーケンスが１つまたは複数のプロセッサに、
    前記ソフトウェア設計仕様文書に関連するコンピュータソフトウェアコードをコンパイルするステップ、
    を実行させる請求項１８に記載のコンピュータ可読媒体。
22. 前記特定するステップ、判定するステップおよび報告するステップは、前記ソフトウェア設計仕様に関連するコンピュータソフトウェアコードをコンパイルする前に実行される請求項１８に記載のコンピュータ可読媒体。
23. 前記１つまたは複数の命令シーケンスが前記１つまたは複数のプロセッサに、
    前記関数が前記第２セクションで宣言されている場合、前記第１セクションにおける前記関数に関連するパラメータが前記設計仕様文書の前記第２セクションで宣言されているかどうかを自動的に判定するステップと、
    前記関数に関連する前記パラメータが前記第２セクションで宣言されていない場合、前記パラメータを未宣言パラメータとして格納するステップと、前記パラメータおよび前記関数に関連する未宣言パラメータ頻度変数をインクリメントするステップと、
    を実行させる請求項１８に記載のコンピュータ可読媒体。
24. 前記１つまたは複数の命令シーケンスが前記１つまたは複数のプロセッサに、
    未宣言の前記パラメータおよび前記未宣言パラメータ頻度変数の値の両方を報告するステップ、
    を実行させる請求項２３に記載のコンピュータ可読媒体。
25. 前記１つまたは複数の命令シーケンスが前記１つまたは複数のプロセッサに、
    前記第１セクションにおける前記関数に関連するクラス属性が前記設計仕様文書の第３セクションに記述されているかどうかを自動的に判定するステップと、
    前記関数に関連する前記クラス属性が前記第３セクションに記述されていない場合、前記クラス属性を未宣言クラス属性として格納するステップと、前記クラス属性および前記関数に関連する未宣言属性頻度変数をインクリメントするステップと、
    を実行させる請求項１８に記載のコンピュータ可読媒体。
26. 前記１つまたは複数の命令シーケンスが前記１つまたは複数のプロセッサに、
    未宣言の前記クラス属性および前記未宣言属性頻度変数の値の両方を報告するステップ、
    を実行させる請求項２５に記載のコンピュータ可読媒体。
27. 前記第３セクションは、ソフトウェアアプリケーションに関連するクラスのクラス属性を記載する請求項２５に記載のコンピュータ可読媒体。
28. 前記１つまたは複数の命令シーケンスが前記１つまたは複数のプロセッサに、
    前記第１セクションで参照されているローカル変数名を格納するステップと、
    前記ローカル変数名および前記関数に関連するローカル変数名頻度変数をインクリメントするステップと、
    前記ローカル変数名および前記ローカル変数名頻度変数の値を報告するステップと、
    を実行させる請求項１８に記載のコンピュータ可読媒体。
29. 前記１つまたは複数の命令シーケンスが前記１つまたは複数のプロセッサに、
    設計仕様文書ファイルのファイルタイプを検証するステップ、
    を実行させる請求項１８に記載のコンピュータ可読媒体。
30. 前記１つまたは複数の命令シーケンスが前記１つまたは複数のプロセッサに、
    １つまたは複数の規則のセットを前記設計仕様文書に自動的に適用するステップ、
    を実行させる請求項１８に記載のコンピュータ可読媒体。
31. 前記規則のセットは、特定の付加物が前記設計仕様文書内の属性名に関連していることを要求する規則を含む請求項３０に記載のコンピュータ可読媒体。
32. 前記規則のセットは、特定の付加物が前記設計仕様文書内のパラメータ名に関連していることを要求する規則を含む請求項３０に記載のコンピュータ可読媒体。
33. 前記規則のセットは、特定の付加物が設計仕様文書内のローカル変数名に関連していることを要求する規則を含む請求項３０に記載のコンピュータ可読媒体。
34. 電子ソフトウェア設計仕様文書を検証する１つまたは複数の命令シーケンスを備えるコンピュータ可読媒体であって、前記１つまたは複数の命令シーケンスが１つまたは複数のプロセッサに、
    設計仕様文書ファイルのファイルタイプを検証するステップと、
    前記設計仕様文書のクラス仕様の関数リストセクションで宣言されている１つまたは複数の関数名および関連する１つまたは複数のパラメータ名を格納するステップと、
    前記クラス仕様のクラス属性セクションに記載されている１つまたは複数の属性名を格納するステップと、
    前記クラス仕様の関数定義セクションで定義されている１つまたは複数の関数のそれぞれについて、それぞれの関数名が格納されているかどうかを判定するステップと、
    それぞれの関数名が格納されていない場合、前記それぞれの関数が宣言されていないことを指示するステップと、
    それぞれの関数名が格納されている場合、前記関数定義セクションにおいて前記それぞれの関数名に関連する１つまたは複数のパラメータ名のそれぞれのパラメータ名が格納されているかどうかを判定するステップと、
    前記それぞれの関数に関連するそれぞれのパラメータ名が格納されていない場合、前記それぞれのパラメータ名を未宣言パラメータとして格納するステップと、前記それぞれのパラメータ名および前記それぞれの関数に関連する未宣言パラメータ頻度変数をインクリメントするステップと、
    もしあれば、１つまたは複数の未宣言パラメータ名と、関連する未宣言パラメータ頻度変数の値とを報告するステップと、
    前記関数定義セクションにおいて前記それぞれの関数名に関連する１つまたは複数の属性名のそれぞれの属性名が格納されているかどうかを判定するステップと、
    前記それぞれの関数に関連するそれぞれの属性名が格納されていない場合、前記それぞれの属性名を未宣言属性として格納するステップと、前記それぞれの属性名および前記それぞれの関数に関連する未宣言属性頻度変数をインクリメントするステップと、
    もしあれば、１つまたは複数の未宣言属性名と、関連する未宣言属性頻度変数の値とを報告するステップと、
    を実行させるコンピュータ可読媒体。
35. 電子ソフトウェア設計仕様文書を検証する装置であって、
    設計仕様文書の第１セクションで定義されている関数を特定する手段と、
    前記関数が前記設計仕様文書の第２セクションで宣言されているかどうかを自動的に判定する手段と、
    前記関数が前記第２セクションで宣言されていない場合、前記関数が宣言されていないことを報告する手段と、
    を備える装置。
36. 電子ソフトウェア設計仕様文書を検証する装置であって、
    設計仕様文書ファイルのファイルタイプを検証する手段と、
    前記設計仕様文書のクラス仕様の関数リストセクションで宣言されている１つまたは複数の関数名および関連する１つまたは複数のパラメータ名を格納する手段と、
    前記クラス仕様のクラス属性セクションに記載されている１つまたは複数の属性名を格納する手段と、
    前記クラス仕様の関数定義セクションで定義されている１つまたは複数の関数のそれぞれについて、それぞれの関数名が格納されているかどうかを判定する手段と、
    それぞれの関数名が格納されていない場合、該それぞれの関数が宣言されていないことを指示する手段と、
    それぞれの関数名が格納されている場合、前記関数定義セクションにおいて前記それぞれの関数名に関連する１つまたは複数のパラメータ名のそれぞれのパラメータ名が格納されているかどうかを判定する手段と、
    前記それぞれの関数に関連するそれぞれのパラメータ名が格納されていない場合、該それぞれのパラメータ名を未宣言パラメータとして格納する手段と、
    前記それぞれのパラメータ名および前記それぞれの関数に関連する未宣言パラメータ頻度変数をインクリメントする手段と、
    もしあれば、１つまたは複数の未宣言パラメータ名と、関連する未宣言パラメータ頻度変数の値とを報告する手段と、
    前記関数定義セクションにおいて前記それぞれの関数名に関連する１つまたは複数の属性名のそれぞれの属性名が格納されているかどうかを判定する手段と、
    前記それぞれの関数に関連するそれぞれの属性名が格納されていない場合、該それぞれの属性名を未宣言属性として格納する手段と、
    前記それぞれの属性名および前記それぞれの関数に関連する未宣言属性頻度変数をインクリメントする手段と、
    もしあれば、１つまたは複数の未宣言属性名と、関連する未宣言属性頻度変数の値とを報告する手段と、
    を備える装置。

Images