JP2009505226A

JP2009505226A - サーバ側のプロジェクトマネージャ

Info

Publication number: JP2009505226A
Application number: JP2008526070A
Authority: JP
Inventors: カヤハラロイ; ジェイ．シュルツエドワード
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-08-09
Filing date: 2006-08-01
Publication date: 2009-02-05
Anticipated expiration: 2026-08-01
Also published as: EP1913451A4; US7657454B2; CN101243365B; US20070038489A1; WO2007021547A3; EP1913451A2; WO2007021547A2; ATE545896T1; JP5006324B2; CN101243365A; EP1913451B1; KR20080035615A; KR101255396B1

Abstract

サーバ側プロジェクトマネージャは、一連のウェブサービスＡＰＩを利用して、サーバ上でプロジェクトを作成、更新、スケジュールし、および管理する。ユーザは、新しいプロジェクトを作成するか、または既存のプロジェクトを修正するとき、プロジェクト更新要求をサブミットする。プロジェクト更新要求は、ウェブサービスを介してサーバを呼び出してプロジェクトを更新するＡＰＩと関連付けられる。ＡＰＩの例には、データ検索呼び出し、管理呼び出し、またはデータ更新呼び出しが含まれる。プロセッサは、プロジェクト更新要求を既存のプロジェクト定義と比較して更新値を識別する。更新値と既存の任意のプロジェクト定義を用いて一連の計算を行う。プロジェクトは、計算の結果に基づいて更新され、データストアに保存される。

Description

本発明は、サーバ側のプロジェクトマネージャに関する。

プロジェクト管理アプリケーションは、プロジェクトに関連付けられたタスクを管理する。プロジェクト管理アプリケーションプログラムにより、ユーザは、プロジェクトの目標を定義し、タスクおよびリソースを計画し、目標を達成するために完了に関するタスクをスケジュールし、プロジェクト計画を表示し、かつ、プロジェクトを実行および管理することができる。プロジェクト管理アプリケーションプログラムは、次の多くの利点をもたらす。すなわち、プロジェクトのスケジュールを自動的に計算すること、タスク情報が変更された場合にはプロジェクトのスケジュールを自動的に更新すること、プロジェクトのスケジュールを分析してリソースをスケジュールし、代替手段を評価すること、すべてのプロジェクトに関して整合性のある標準形式でスケジュール出力を提供すること、および将来のプロジェクトで用いるためにスケジュールデータを保存することである。

プロジェクト管理スケジュールは、タスクで構成される。このスケジュールは、タスクが発生する順序、タスクを完了するのに必要なリソース、およびタスクに関連付けられた予定表を定義する。各タスクは、開始および終了日時、完了した仕事の割合、要求されるリソース、予想されるコストおよび実際のコストなどと関連付けられた情報を含むように定義される。

サーバ側プロジェクトマネージャは、一連のウェブサービスのアプリケーションプログラムインターフェイス（ＡＰＩ）呼び出しを利用して、サーバ上でプロジェクトを作成、更新、スケジュールし、および管理する。ユーザは、プロジェクトアプリケーションから新しいプロジェクトを作成するか、または既存のプロジェクトを修正するときに、プロジェクト更新要求をサブミットすることによって、プロジェクト更新処理呼び出しを開始する。プロジェクト更新要求は、ウェブブラウザのインターフェイスを介してウェブサービスにサブミットされる。プロジェクト更新要求は、ウェブサービスを介してサーバを呼び出してプロジェクトを更新するＡＰＩと関連付けられる。ＡＰＩの例には、データの検索呼び出し、管理呼び出し、およびデータ更新呼び出しがある。プロセッサは、プロジェクト更新要求を既存のプロジェクト定義と比較して、更新値を識別する。この更新値および既存のプロジェクト定義を用いて一連の計算を行う。プロジェクトは、計算結果に基づいて更新され、データストアに保存される。

本発明の他の態様は、これらの方法を実行するためのシステムおよびコンピュータ可読媒体を含む。本開示の上述の概要は、本開示のあらゆる実装を説明しようとするものではない。以降の図面および詳細な説明は、これらの実装をより詳細に例示する。

サーバ側プロジェクトマネージャは、一連のウェブサービスＡＰＩを利用して、サーバ上でプロジェクトを作成、更新、スケジュールし、および管理する。ユーザは、新しいプロジェクトを作成するか、または既存のプロジェクトを修正するときに、プロジェクト更新要求をサブミットする。プロジェクト更新要求は、ウェブサービスを介してサーバを呼び出しプロジェクトを更新するＡＰＩと関連付けられる。ＡＰＩの例には、データの検索呼び出し、管理呼び出し、またはデータ更新呼び出しがある。プロセッサは、プロジェクト更新要求を既存の任意のプロジェクト定義と比較して、更新値を識別する。この更新値および既存の任意のプロジェクト定義を用いて一連の計算を行う。プロジェクトは、計算結果に基づいて更新され、データストアに保存される。

図面を参照して本発明の実施形態を詳細に説明するが、図面では、いくつかの図を通して同様の参照符号が同様の部分および集まりを表す。様々な実施形態への言及は、本開示の範囲を限定せず、これは添付の特許請求の範囲の範囲によってのみ限定される。本明細書で示す例は限定的なものとせず、単に多くの可能な実施形態のうちのいくつかを示す。したがって、次の詳細な説明は、限定的な意味で解釈されるべきではない。

＜例示的な動作環境＞
図１を参照すると、本発明を実装する例示的なシステムは、コンピュータデバイス１００などのコンピュータデバイスを含む。基本的な構成では、コンピュータデバイス１００は典型的に、少なくとも１つの処理ユニット１０２と、システムメモリ１０４とを含む。コンピュータデバイスの正確な構成および型に依存して、システムメモリ１０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこの２つの組み合わせである場合がある。システムメモリ１０４は、典型的には、オペレーティングシステム１０５と、１つまたは複数のアプリケーション１０６とを含み、プログラムデータ１０７を含む場合もある。一実施形態では、アプリケーション１０６はさらに、以下にさらに詳細に説明するプロジェクトマネージャ１０８を含む。

またコンピュータデバイス１００は、追加の特徴および機能性を有することもある。例えば、コンピュータデバイス１００は、例えば磁気ディスク、光ディスク、またはテープなど、追加のデータ記憶装置（取り外し可能および／または取り外し不可能）を含むこともある。このような追加の記憶装置は、図１にて取り外し可能な記憶装置１０９および取り外し不可能な記憶装置１１０で説明している。コンピュータ記憶媒体は、コンピュータ可読の命令、データ構造、プログラムモジュール、または他のデータなどの情報を保存する方法または技術で実現された揮発性および不揮発性の、取り外し可能および取り外し不可能な媒体を含むことができる。システムメモリ１０４、取り外し可能な記憶装置１０９、および取り外し不可能な記憶装置１１０はすべてコンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくは他の磁気記憶装置、または所望の情報を保存するために使用することができコンピュータデバイス１００によってアクセスされることが可能な他の媒体があるが、これらに限定されない。このようなコンピュータ記憶媒体は、デバイス１００の一部であることもある。またコンピュータデバイス１００は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの入力装置１１２を有することもある。ディスプレイ、スピーカ、プリンタなどの出力装置１１４が含まれることもある。これらの装置はすべて当技術分野では知られており、本明細書で長々と説明する必要はない。

コンピュータデバイス１００はまた、例えばネットワークまたは無線メッシュネットワークを介してデバイスが他のコンピュータデバイス１１８と通信できるようにする通信接続１１６を含む。通信接続１１６は、通信媒体の一例である。通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他の搬送機構などの変調データ信号に組み入れるものであり、任意の情報配信媒体を含む。「変調データ信号」という用語は、特徴の１つまたは複数のセット、または情報を信号に符号化するように変更された信号を意味する。一例として、限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続などの有線媒体と、音響、高周波、赤外線、および他の無線媒体などの無線媒体とを含む。本明細書で使用するコンピュータ可読媒体という用語は、記憶媒体と通信媒体の両方を含む。

＜サーバ側のプロジェクトマネージャ＞
本開示を、コンピュータデバイスで実行される、ソフトウェアモジュールなどのコンピュータ実行可能な命令またはコンポーネントの一般的な状況で説明する。一般に、ソフトウェアモジュールは、特定のタスクを実行するまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本明細書ではコンピュータ実行可能な命令またはコンポーネントに関して説明するが、ファームウェアまたは特定用途の論理回路など、ソフトウェア以外のプログラム機構を用いて本発明を同様に実装することができる。

図２は、サーバ側のプロジェクトＡＰＩ呼び出しを用いて更新することができるデータフィールドを定義するプロジェクトデータセットのブロック図を示す。プロジェクトデータセットは、プロジェクトデータテーブル２００と、タスクデータテーブル２１０と、リソースデータテーブル２２０と、割当てデータテーブル２３０とを含む。プロジェクトデータテーブル２００は、プロジェクトのヘッダ情報を含む。タスクデータテーブル２１０は、タスク情報を含み、ここでタスクはプロジェクトにて実行されるアクションである。タスクは、互いに依存している場合がある。リソースデータテーブル２２０は、プロジェクトで働いている人についての情報を含む。リソースは、ローカルまたは企業規模である場合がある。割当てデータテーブル２３０は、リソースとタスクとの関係を定義する。換言すれば、割当ては、対応するタスクを完了するようにスケジュールされたリソースを識別する。

またプロジェクト２００は、特定のプロジェクトの実装に特有の補助データ構造を含むことがある。例えば、プロジェクトデータテーブル２００は、プロジェクトカスタムフィールドのデータテーブル２４０と関連付けられる場合がある。プロジェクトカスタムフィールドのデータテーブル２４０は、プロジェクトに関するユーザ定義データを含む。タスクデータテーブル２１０は、タスクカスタムフィールドのデータテーブル２５０と関連付けられる場合がある。タスクカスタムフィールドのデータテーブル２５０は、タスクに関するユーザ定義データを含む。リソースデータテーブル２２０は、リソースカスタムフィールドデータテーブル２６０と関連付けられる場合がある。リソースカスタムフィールドのデータテーブル２６０は、リソースに関するユーザ定義データを含む。割当てデータテーブル２３０は、割当てカスタムフィールドのデータテーブル２７０と関連付けられる場合がある。割当てカスタムフィールドのデータテーブル２６０は、割当てに関するユーザ定義データを含む。カスタムフィールドのデータテーブル２４０、２５０、２６０、２７０により、ユーザがデータテーブル独自のタスク、割当て、リソース、およびプロジェクトを入力できるようになるので、システムの拡張性を向上させる。

図３は、サーバ上でプロジェクトを管理するシステムの機能ブロック図を示す。このシステムは、クライアント３００と、ウェブサービス３１０と、サーバ３２０と、データストア３９０とを含む。サーバ３２０は、キューマネージャ３３０と、トランザクションキュー３４０と、ディスパッチャ３５０と、プロセッサ３６０、３７０、３８０とを含む。ユーザは、クライアント３００でプロジェクト更新要求をサブミットすることによりプロジェクト更新処理呼び出しを開始する。クライアント３００でロードされたプロジェクトアプリケーションにおいてユーザが新しいプロジェクトを作成するか、または既存のプロジェクトを修正するときに、プロジェクト更新要求がサブミットされる。プロジェクト更新要求は、プロジェクトに関連付けられたスケジュール情報を変更する要求を含む場合がある。プロジェクト更新要求は、データストア３９０に保存された情報を修正する要求を含むこともできる。プロジェクト更新要求は、ウェブブラウザのインターフェイスを介してウェブサービス３１０にサブミットされる。いくつかの予備的な入力データ検証を行う場合がある。プロジェクト更新要求は、ウェブサービス３１０を介してサーバ３２０を呼び出して、プロジェクトを更新し、かつ計算を実行するアプリケーションプログラムインターフェイス（ＡＰＩ）と関連付けられる。ＡＰＩの例について、以下に詳細に説明する。

プロジェクト更新要求は、キューマネージャ３３０にサブミットされる。キューマネージャ３３０は、入ってくる要求を監視し、要求をトランザクションキュー３４０に保存する。ディスパッチャ３５０は、プロジェクト更新要求を利用可能なプロセッサ（３６０、３７０、または３８０）に転送する。複数のプロセッサが、負荷バランシングおよび需要の平滑化を支援する。

プロセッサは、プロジェクト更新要求および既存の任意のプロジェクト定義から更新値を決定する。プロジェクト更新要求が新たに作成されたプロジェクトと関連付けられる場合は、プロセッサは既存のプロジェクト定義を参照しない。更新値は、プロジェクト更新要求から直接に、またはプロジェクト更新要求と既存のプロジェクト定義との差から、決定される場合がある。この更新値および既存の任意のプロジェクト定義を用いて一連の計算を行う。計算の例には、ノード整合の計算、スケジューリング動作、ロールアップ計算、およびカスタムフィールド計算がある。プロジェクトは、計算結果に基づいて、データストア３９０にて更新される。

ユーザが特定のプロジェクトデータ要素またはフィールド（例えばタスクまたは割当て）を修正すると、関連するデータ要素およびフィールドが更新されて整合性を維持するように、ノード整合の計算が実行される。例えば、タスクは、開始日を月曜日に設定し、終了日を水曜日に設定する場合がある。このタスクの継続期間は３日である。ユーザが、終了日を木曜日に延長する場合がある。このときタスクの継続期間は４日であるので、この修正はデータの不整合を作り出す。データの不整合を解消するためにノード整合の計算が行われて、継続期間データフィールドが自動的に更新されて修正を反映するようになる。したがって、タスクの継続期間は更新されて４日になる。

スケジューリング動作は、クリティカルパススケジューリングを実行し、時間の制約により発生する場合があるスケジュールの衝突を解決する。スケジューリング動作は、サーバ２２０上のスケジューリングエンジンにより実行されることもある。一例では、スケジューリング動作は、カレンダ上で何日が公式の作業日であるかを決め、非作業日にタスクが行われるようなスケジュールをしないようにする。

ロールアップ計算が実行されて、プロジェクトの情報を集めて、蓄積された情報のサマリを生成する。一実施形態では、複数のタスクがサマリタスクと関連付けられる場合がある。ロールアップ計算は、複数のタスク間で共有される情報をサマリタスクの中に含めて集める。例えば、１つのタスクが月曜日〜水曜日に実行されるようにスケジュールされる場合がある。別のタスクが、木曜日と金曜日に実行されるようにスケジュールされる場合がある。両方のタスクは、単一のサマリタスクの下でグループ化されることが可能である。このサマリタスクは、５日の継続期間を有する。

ユーザは、プロジェクト、タスク、リソース、および割当てカスタムフィールドを設置することができる。カスタムフィールドは、プロジェクトに関するメトリックを表す計算を行うように定義されることが可能である。例えば、「days late」という名前のカスタムフィールドは、タスクの実際の終了日からスケジュールされた終了日を引く計算を行うように定義されることが可能である。

共有されるサーバ上でプロジェクトを作成、更新、スケジュールし、および管理するために、一連のウェブサービスＡＰＩが呼び出される。このＡＰＩは、データ検索呼び出し、管理呼び出し、およびデータ更新呼び出しを含む。データ検索呼び出しは、ReadProjectおよびReadProjectTeamを含む。管理呼び出しは、CheckOutProjectおよびCheckInProjectを含む。データ更新呼び出しは、CreateProject、CreateProjectFromTemplate、UpdateProject、AddToProject、DeleteFromProject、UpdateProjectTeam、およびCalculateを含む。これらの呼び出しの各々について、以下に詳細に説明する。

ReadProjectは、単一プロジェクトに対してデータを読み取るために呼び出される。例えば、
projectDS=project.ReadProject(projectID);
ここで、「projectDS」は、データベースからプロジェクトデータと共に返されるプロジェクトデータセットである。
「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「projectID」は、タスク、依存関係、リソース、または割当てが削除されるプロジェクトのＧＵＩＤである。

CheckOutProjectは、編集または削除に関するプロジェクトを保留するために呼び出される。プロジェクトが編集を利用できない場合、例外が発生する。プロジェクトは、クライアントのアプリケーションまたはサーバのＡＰＩのいずれかに変更が行われる前にロックされなければならない。ロックは、アプリケーションレベルの論理ロックである。サーバ側のプロジェクトのＡＰＩと共に使用される場合、チェックアウト操作は、クライアントのアプリケーションにおいてプロジェクトの読み書き動作を開始することと論理的に等しい。チェックアウト操作は同期式であり、直ちに処理される。例えば、
project.CheckOutProject(projectID, sessionID, sessionDesc);
ここで、「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「projectID」は、チェックアウトされるプロジェクトのＧＵＩＤである。
「sessionID」は、呼び出し側から与えられる固有の識別子である。プロジェクトの論理ロックは、セッションＩＤＧＵＩＤ、およびチェックアウト呼び出しを行うユーザに関連付けられる。チェックアウトされたプロジェクトに対するその後の動作は、ユーザがプロジェクトをチェックアウトしたユーザと同じであって、セッションＩＤＧＵＩＤが呼び出しと共に与えられる場合に承諾されるにすぎない。
「sessionDesc」は、ユーザが与えた任意の文字列であり、プロジェクトがチェックアウトされる間プロジェクトの一部として保存され、チェックアウトされたプロジェクトと関連付けられるユーザを示す。一実施形態では、文字列はプロジェクトがチェックアウトされたクライアント名である。サーバ側のプロジェクトの呼び出しについては、ユーザは呼び出しに合うどんな文字列も与えることができる。典型的には、文字列は、チェックアウトを行った処理の名前である（例えば「Timesheet updates」）。

CheckInProjectは、プロジェクトのロックを解放する。プロジェクトに対する変更が保留中である（すなわちキューにある）場合、チェックイン操作がキューに入れられ、変更の完了で発生する。変更が保留中でない場合には、チェックイン操作は直ちに発生する。プロジェクトは、チェックアウトを行ったユーザにより、または「強制チェックイン」オプションを用いて管理者特権を有するユーザにより、チェックインされる。チェックイン操作は、データベースのあらゆるデータの再計算を強制する。例えば、
project.CheckInProject(projectID, checkinOption, sessionID, sessionDesc);
ここで、「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「projectID」は、チェックアウトされるプロジェクトのＧＵＩＤである。
「checkinOption」は、チェックイン操作に関連するあらゆるオプションを定義する。オプションの例は、標準および強制を含む。標準チェックイン操作は、プロジェクトを解除する。その後の「プロジェクトアプリケーションの読み書きをオープンする（Open read-write in the project application）」または「更新のために読み取る（Read for update）」というサーバ側のプロジェクトの呼び出しが、データベースからプロジェクトの未公開のコピーを受信する。他のすべてのプロジェクトの読み取りＡＰＩおよびプロジェクトのウェブアクセスは、プロジェクトの公開されたバージョンを見続ける。強制チェックイン操作は、管理者特権を必要とし、セッションＩＤＧＵＩＤは無視される。プロジェクトアプリケーションの保存されていない変更はいずれも失われる。
「sessionID」は、プロジェクトがチェックアウトされたときに使用されたセッションの識別子である。呼び出しするユーザまたはセッションのＩＤがチェックアウトの呼び出しで使用されたものと異なる場合、チェックイン操作は失敗する（管理者チェックインを除く）。
「sessionDesc」は、任意でユーザが与える文字列である。この文字列は、サーバには無視される場合があるが、診断目的で、すなわち文字列がチェックアウト呼び出しで与えられた文字列と一致しない場合に、使用されることが可能である。

CreateProjectは、新しいプロジェクトを作成するために使用される。例えば、
project.CreateProject(projectDS, validateOnly);
ここで、「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「projectDS」は、プロジェクトに追加するために、プロジェクトのヘッダ、タスク、依存関係、リソース、および割当ての情報を入れたプロジェクトデータセットである。
「validateOnly」は、呼び出しがプロジェクトを作成すべきか、またはデータ検証を行うべきかを示す論理値である。「真」という結果が生成される場合、データベースを更新することなく、データ検証のみが実行される。「偽」という結果が生じる場合、データ検証が実行され、エラーが見つからなければプロジェクトが作成される。プロジェクトデータセットは、プロジェクタヘッダ情報と同様に、タスク、割当て、およびリソースを含むことができる。呼び出しごとに、ただ１つのプロジェクトを作成することができる。データセットに複数のプロジェクトが指定される場合には、第１のプロジェクトのみが考慮に入れられ、他のすべてのプロジェクトデータは無視される。

CreateProjectFromTemplateは、既存のプロジェクトのテンプレートに基づいて新しいプロジェクトを作成する。例えば、
newProjectID=project.CreateProjectFromTemplate(templateID, newProjectName, newProjectVersionID);
ここで、「newProjectID」は、新しく作成されたプロジェクトを確認する、システムが割り当てたＧＵＩＤである。
「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「templateID」は、新しいプロジェクトの基礎として使用するテンプレートのＧＵＩＤである。
「newProjectName」は、新しく作成されるプロジェクトに与えられる名前である。
「newProjectVersionID」は、新しいプロジェクトと関連付けられるバージョンのＧＵＩＤである。

UpdateProjectは、既存のプロジェクトおよび／または既存のタスク、リソース、および割当てを更新する。例えば、
project.CreateProject(sessionID, projectDS, validateOnly);
ここで、「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「sessionID」は、プロジェクトがチェックアウトされたときに使用されたセッションの識別子である。呼び出しするユーザの識別子、またはセッションの識別子がチェックアウト呼び出しで使用される識別子とは異なる場合、更新操作は失敗する。
「projectDS」は、プロジェクトのヘッダまたは既存のタスク、依存関係、リソース、および割当てへの変更を含んでいるプロジェクトデータセットである。
「validateOnly」は、呼び出しがプロジェクトを作成すべきか、またはデータ検証を行うべきかを示す論理値である。「真」という結果が生成される場合、データベースを更新することなく、データ検証のみが実行される。「偽」という結果が生成される場合、データ検証が実行され、エラーが見つからなければプロジェクトが作成される。プロジェクトデータセットは、プロジェクトヘッダ情報と同様に、タスク、割当て、およびリソースを含むことができる。データセットのすべての列は、既存のエンティティを参照する。呼び出しごとに１つのプロジェクトを作成する。データセットに複数のプロジェクトが指定される場合には、第１のプロジェクトのみが考慮に入れられ、他のすべてのプロジェクトデータは無視される。

AddToProjectは、既存のプロジェクトに新しいタスク、依存関係、リソース、および割当てを追加する。例えば、
project.AddToProject(sessionID, projectDS, validateOnly);
ここで、「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「sessionID」は、プロジェクトがチェックアウトされたときに使用されたセッションの識別子である。呼び出しするユーザの識別子、またはセッションの識別子がチェックアウト呼び出しで使用される識別子とは異なる場合には、呼び出しは失敗する。
「projectDS」は、投入されたプロジェクトデータセットである。タスク、依存関係、リソース、および割当てに関するデータテーブルが使用される。プロジェクトデータテーブルは無視される。
「validateOnly」は、呼び出しがプロジェクトを作成すべきか、またはデータ検証を行うべきかを示す論理値である。「真」という結果が生成される場合、データベースを更新することなく、データ検証のみが実行される。「偽」という結果が生成される場合、データ検証が実行され、エラーが見つからなければプロジェクトが作成される。プロジェクトデータセットは、プロジェクトのヘッダ情報と同様に、タスク、割当て、およびリソースを含むことができる。データセットのすべての列は、既存のエンティティを参照する。呼び出しごとに１つのプロジェクトを作成することができる。データセットに複数のプロジェクトが指定される場合は、第１のプロジェクトのみが考慮に入れられ、他のすべてのプロジェクトデータは無視される。

DeleteFromProjectは、既存のプロジェクトからタスク、依存関係、リソース、および割当てを削除する。例えば、
project.DleteFromProject(sessionID, projectID, deleteGUIDs[]);
ここで、「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「sessionID」は、プロジェクトがチェックアウトされたときに使用されたセッションの識別子である。呼び出しするユーザの識別子、またはセッションの識別子がチェックアウト呼び出しで使用される識別子とは異なる場合、呼び出しは失敗する。
「projectID」は、タスク、依存関係、リソース、または割当てが削除されるプロジェクトのＧＵＩＤである。
「deleteGUIDs」配列は、削除されるタスク、依存関係、リソース、または割当てのＧＵＩＤを含む。

呼び出しごとに、ただ１つのプロジェクトを削除することができる。削除ＧＵＩＤが指定されたプロジェクトにないエンティティを参照する場合には、例外が発生して、削除操作は失敗する。「protected actuals」オプションがプロジェクトに関して選択される場合には、プロジェクトの実際の作業に伴う割当ておよびリソースが削除されることはない。

ReadProjectTeamは、プロジェクトにおけるリソースのリストを返す。この呼び出しは、プロジェクトのウェブアクセスでチームビルダのページにより最初に使用されるよう意図されている。例えば、
projectTeamDS=project.ReadProjectTeam(projectID);
ここで、「projectTeamDS」は、ＰｒｏｊｅｃｔＴｅａｍのデータテーブルを含むデータセットである。
「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「projectID」は、リソースを追加するプロジェクトのＧＵＩＤである。

呼び出しするユーザは、追加される企業リソースへの割当て許可を与えられるか、またはセキュリティーの例外が発生して呼び出しが失敗する。指定された企業リソースがすでにプロジェクトチームに存在する場合、企業リソースはもっとも最近の企業リソースデータで更新される。

UpdateProjectTeamは、プロジェクトに割り当てられたリソースに変更を加える。変更には、新しい企業リソースをプロジェクトチームに追加すること、プロジェクトチームからリソースを削除すること、既存のリソースを他の企業リソースと置き換えること（および影響を受けた割当てを更新すること）、ならびに既存のリソースの予約方式を変更することを含むことができる。例えば、
project.ReplaceResources(sessionID, projectID, projectTeamDS);
ここで、「project」は、サーバ側のプロジェクトのウェブサービスプロキシへの参照である。
「sessionID」は、プロジェクトがチェックアウトされたときに使用されたセッションの識別子である。呼び出しするユーザの識別子、またはセッションの識別子がチェックアウト呼び出しで使用される識別子とは異なる場合、呼び出しは失敗する。
「projectID」は、リソースを置き換えるプロジェクトのＧＵＩＤである。
「projectTeamDS」は、ＰｒｏｊｅｃｔＴｅａｍのデータテーブルを含むデータセットである。この呼び出しは、企業リソースまたはローカルリソースで予約方式を変更するのに使用することができる。ローカルリソースは、プロジェクト間で共有されるサマリリソースの割当てがないため、ローカルリソースの予約方式は、ローカルプロジェクト内で見られるにすぎない。ローカルリソースの予約方式は、プロジェクトの外では意味をなさない。

Calculateは、プロジェクトを再スケジュールし、プロジェクト定義への一連の更新の後にカスタム式フィールドを再計算する。例えば、
project.Calculate(sessionID, projectID);
ここで、「project」は、サーバサードのウェブサービスプロキシへの参照である。
「sessionID」は、プロジェクトがチェックアウトされたときに使用されたセッションの識別子である。呼び出しするユーザの識別子、またはセッションの識別子がチェックアウト呼び出しで使用される識別子とは異なる場合、呼び出しは失敗する。
「projectID」は、リソースを置き換えるプロジェクトのＧＵＩＤである。

上述のように、ＡＰＩ呼び出しにより提供される機能には、新しいプロジェクトを作成することと、タスク、タスク間の依存関係、プロジェクトチームのリソース、およびタスクのリソースの割当てを追加する、削除する、および更新することを含む既存のプロジェクトを更新することと、プロジェクトデータ上のデータの競合を管理することと、スケジュールし、計算されたスケジュールの結果およびプロジェクトのウェブアクセスアプリケーションで用いる作業の割当てを公開することと、を含む。

図４は、サーバ上でプロジェクトを管理する処理を説明する動作フロー図である。処理手続きは、プロジェクトアプリケーションがクライアントにロードされるスタートブロックに始まる。ユーザは、クライアントにおいてプロジェクト更新要求をサブミットすることによりプロジェクト更新の呼び出しを開始する。ユーザが新しいプロジェクトを作成し、または、既存のプロジェクトを変更するときに、プロジェクト更新要求がサブミットされる。プロジェクト更新要求は、ＡＰＩ呼び出しと関連付けられる。クライアントにおけるウェブブラウザのインターフェイスがプロジェクト更新要求をウェブサービスにサブミットし、ウェブサービスで入力データの検証を行うことができる。ウェブサービスは、ブロック４００でプロジェクト更新要求を受信する。

ブロック４１０に移ると、プロジェクト更新要求に関連付けられたＡＰＩが、ウェブサービスによって識別されて呼び出される。ＡＰＩは、データ検索呼び出し、管理呼び出し、またはデータ更新呼び出しであることができる。ＡＰＩは、サーバ上でプロジェクトを作成する、更新する、スケジュールする、および管理するために呼び出される。例えば、プロジェクト更新要求が新しいプロジェクトを作成しようとする場合、CreateProjectのＡＰＩが識別されて呼び出される。同様に、プロジェクト更新要求が、プロジェクトからタスクを削除しようとする場合は、DeleteFromProjectのＡＰＩが識別されて呼び出される。

ブロック４２０に移ると、プロジェクト更新要求がキューマネージャにサブミットされ、サーバのトランザクションキューに保存される。ブロック４３０に進むと、プロジェクト更新要求は、トランザクションキューからサーバ上のプロセッサに発送される。プロジェクト更新要求は、１群のプロセッサの中の１つのプロセッサに発送される場合がある。プロジェクト更新要求が発送されるプロセッサは、１群のプロセッサ間の負荷の均衡がとれ、プロセッサの需要が平滑化されるように選択されることが可能である。

ブロック４４０へと続き、プロセッサがプロジェクト更新要求から更新値を識別すると、ユーザによってサブミットされたプロジェクトへの変更が決定される。またプロセッサは、プロジェクト更新要求が新しく作成されたプロジェクトに関連付けられていない場合には、既存のプロジェクト定義を識別することができる。更新値は、プロジェクト更新要求を既存のプロジェクト定義と比較することにより決定されることが可能である。

ブロック４５０に進むと、更新値および既存のプロジェクト定義を用いて計算が行われる。この計算の結果が、プロジェクトに新しいプロジェクトデータ値をもたらす。計算の例には、ノード整合性の計算、スケジューリング動作、ロールアップ計算、およびカスタムフィールド計算がある。ノード整合性の計算を使用して、プロジェクト更新要求によって直接修正されたデータと関連付けられたプロジェクトデータを更新し、プロジェクト全体に整合性が維持されるようにする。スケジューリング動作は、クリティカルパススケジューリングを行い、時間の制約により起こる可能性があるスケジュールの衝突を解決する。ロールアップ計算は、共有情報を集めることによりサマリを供給する。カスタムフィールド計算は、ユーザ定義のデータフィールドで行われる計算である。ブロック４６０に移動すると、プロジェクトは新しいプロジェクトデータ値を用いて一緒に更新され、データストアに保存される。処理手続きはその後、終了ブロックで終わる。

上述した様々な実施形態は、単に実例として提供し、本発明を限定すると解釈されるべきではない。本明細書で説明して記載した例示の実施形態および応用に従わず、かつ添付の特許請求の範囲に示された本発明の真の趣旨および範囲から逸脱することなく、本発明に行うことができる様々な修正および変更を、当業者は容易に理解するであろう。

本発明の一態様で使用することができる例示的なコンピュータデバイスを示す機能ブロック図である。サーバ側プロジェクトのＡＰＩ呼び出しを用いて更新することができるデータフィールドを定義するプロジェクトデータセットのブロック図である。サーバ上でプロジェクトを管理するシステムの機能ブロック図である。サーバ上でプロジェクトを管理する処理を説明する動作フロー図である。

Claims

サーバ上でプロジェクトを管理する、コンピュータに実装される方法であって、
プロジェクトアプリケーションからのプロジェクト更新要求を受信するステップと、
前記プロジェクト更新要求に関連付けられたアプリケーションプログラムインターフェイスを識別するステップと、
前記識別されたアプリケーションプログラムインターフェイスを呼び出すステップであって、
前記アプリケーションインタフェースは、
前記プロジェクト更新要求で識別された更新値を決定し、
前記更新値を使用して計算を実行し、前記実行された計算から新しいプロジェクトデータ値が生成されるように定められた、アプリケーションプログラムインターフェイスを呼び出すステップと、
前記新しいプロジェクトデータ値を使用して前記サーバ上で前記プロジェクトを更新するステップと
を備えることを特徴とするコンピュータに実装される方法。
プロジェクト更新要求を受信するステップは、新しいプロジェクトの作成が要求されるときにプロジェクト更新要求を受信するステップをさらに含むことを特徴とする請求項１に記載のコンピュータに実装される方法。
プロジェクト更新要求を受信するステップは、既存のプロジェクトの修正が要求されるときにプロジェクト更新要求を受信するステップをさらに含むことを特徴とする請求項１に記載のコンピュータに実装される方法。
前記アプリケーションプログラムインターフェイスは、さらに、前記更新値を使用して既存のプロジェクト定義で計算を実行するように定められていることを特徴とする請求項１に記載のコンピュータに実装される方法。
前記アプリケーションプログラムインターフェイスは、プロジェクトデータを検索するために呼び出されることを特徴とする請求項１に記載のコンピュータに実装される方法。
前記アプリケーションプログラムインターフェイスは、プロジェクトデータを更新するために呼び出されることを特徴とする請求項１に記載のコンピュータに実装される方法。
前記アプリケーションプログラムインターフェイスは、プロジェクトデータにおける管理アクションを行うために呼び出されることを特徴とする請求項１に記載のコンピュータに実装される方法。
前記アプリケーションプログラムインターフェイスは、さらに、前記プロジェクト更新要求を既存のプロジェクト定義と比較することによって、更新値を決定するように定められていることを特徴とする請求項１に記載のコンピュータに実装される方法。
更新されたプロジェクトをデータストアに保存するステップをさらに備えることを特徴とする請求項１に記載のコンピュータに実装される方法。
前記アプリケーションプログラムインターフェイスは、さらに、ノード整合性の計算を実行することによって計算を実行するように定められ、前記ノード整合性の計算が、前記新しいプロジェクトデータ値と関連付けられたプロジェクトデータを更新して、前記プロジェクトデータが前記新しいプロジェクトデータ値と整合性が取れるようにすることを特徴とする請求項１に記載のコンピュータに実装される方法。
前記アプリケーションプログラムインターフェイスは、さらに、スケジューリング動作を実行することによって計算を実行することを定められ、前記スケジューリング動作が、前記新しいプロジェクトデータ値によって作成されたプロジェクトにおけるスケジュールの衝突を判定することを特徴とする請求項１に記載のコンピュータに実装される方法。
前記アプリケーションプログラムインターフェイスは、さらに、ロールアップ計算を実行することによって計算を実行するように定められ、前記ロールアップ計算はプロジェクトデータを集めてプロジェクトサマリを生成することを特徴とする請求項１に記載のコンピュータに実装される方法。
前記アプリケーションプログラムインターフェイスは、さらに、カスタムフィールド計算を実行することによって計算を実行するように定められ、前記カスタムフィールド計算は、前記プロジェクトに関連するユーザ定義の計算を行うことを特徴とする請求項１に記載のコンピュータに実装される方法。
プロジェクトを管理するためのシステムであって、
メモリに保存されたプロジェクトアプリケーションを含み、前記プロジェクトアプリケーションからプロジェクト更新要求を受信するように定められたクライアントと、
前記クライアントと連結されたウェブサービスであって、
前記ウェブサービスは、
前記プロジェクト更新要求と関連付けられたアプリケーションプログラムインターフェイスを識別し、
前記識別されたアプリケーションプログラムインターフェイスを呼び出すように定められた、ウェブサービスと、
前記クライアントに連結され、呼び出される前記識別されたアプリケーションプログラムインターフェイスに応答するサーバであって、
前記サーバは、
前記プロジェクト更新要求で識別される更新値を決定し、
前記更新値を使用して計算を実行し、新しいプロジェクトデータ値が実行した計算から生成され、
前記新しいプロジェクトデータ値を使用して前記プロジェクトを更新するように定められた、サーバと
を備えることを特徴とするシステム。
前記サーバに連結されたデータストアをさらに備え、更新されたプロジェクトは前記データストアに保存されることを特徴とする請求項１４に記載のシステム。
新しいプロジェクトの作成が要求されるときに、前記クライアントは前記プロジェクト更新要求を受信することを特徴とする請求項１４に記載のシステム。
既存のプロジェクトの修正が要求されるとき、前記クライアントは前記プロジェクト更新要求を受信することを特徴とする請求項１４に記載のシステム。
前記アプリケーションプログラムインターフェイスは、プロジェクトデータを検索すること、プロジェクトデータを更新すること、およびプロジェクトデータにおける管理アクションを行うことのうちの少なくとも１つを行うために呼び出されることを特徴とする請求項１４に記載のシステム。
サーバ上でプロジェクトを管理するための、コンピュータ実行可能な命令を有するコンピュータ可読媒体であって、
プロジェクトアプリケーションからプロジェクト更新要求を受信するステップと、
前記プロジェクト更新要求と関連付けられたアプリケーションプログラムインターフェイスを識別するステップと、
前記識別されたアプリケーションプログラムインターフェイスを呼び出すステップであって、
前記アプリケーションプログラムインタフェイスは、
前記プロジェクト更新要求で識別された更新値を決定し、
前記更新値を使用して計算を実行し、前記実行された計算から新しいプロジェクトデータ値が生成されるように定められた、アプリケーションプログラムインターフェイスを呼び出すステップと、
前記新しいプロジェクトデータ値を使用して前記サーバ上で前記プロジェクトを更新するステップと、
前記更新されたプロジェクトをデータストアに保存するステップと
を備えることを特徴とするコンピュータ可読媒体。
前記識別されたアプリケーションプログラムインターフェイスを呼び出すステップは、さらに、プロジェクトデータを検索するステップ、プロジェクトデータを更新するステップ、およびプロジェクトデータにおける管理アクションを行うステップのうちの少なくとも１つを行うステップを含むことを特徴とする請求項１９に記載のコンピュータ可読媒体。