Time management and task completion and prediction software6519763Abstract A computer software application in the form of a software management and task completion and prediction apparatus by which project completion can be ascertained and management of a project can be maintained with a high efficiency and accuracy. The software application is a web-based application which enables users to proactively manage and accurately predict strategic software development and deliverables. This application and delivery management system comprises distributed data collectors, an application server and a browser interface. The data collectors automatically gather data already being generated by various tools within the organization, such as scheduling, defect tracking, requirements management and software quality tools. This data is constantly being collected and fed into the application server, thereby providing objective and updated information. New tools can be easily added without disrupting operations. The data collected is fed into the applications server which is the brain of the apparatus. The application server analyzes the data collected by the data collectors to generate a statistically significant probability curve. This curve is then compared to the original planned schedule of product delivery to determine if the project is meeting its targets. Based upon this comparison, the software application predicts a probable delivery date based upon the various inputs and variables from the development process. In addition, the application server also generate early warning alerts, as needed and indicated. At such time as the software apparatus identifies a potential problem, the alerts automatically inform the user, so as to mitigate a crisis and assist with resolution of the problem. The alerts are communicated to the designated user by e-mail. Claims What is claimed is: Description APPENDIX
Keyword Description
tablename=NAME Start data for table NAME
/table End data for current table
column name=NAME Declares a column NAME
row Start a new data row
/row End current row
options mtime=<string> Sets some options, i.e. last modification
time.
options mode=replace Tells application serve to delete the records in
the existing tables, i.e. a full overwrite.
History is still maintained.
options mode=update Tells application server to consider the tables
as incremental updates.
For each data table that is written to the database file, the file contains the table command followed by a set of column commands. Each column command declares the set of columns that will appear in the given file. Each row provides values for exactly as many columns as were declared. The values for the rows are then provided, each one starting with a line containing the row commands with one field per line, followed by the end row command. The row and end row block may be repeated as many times as there are rows. The table ends with the end table command. Fields having embedded newlines may be specified by using a backslash at the end of the line to end the command. The "options mode=replace" command instructs the system to delete the existing table contents. This replace command is used when parsing requirement documents are utilized. With requirement documents the only way to know that a requirement has been deleted is when it is no longer in the set being transferred. By utilizing the "options mode=replace" command, the system ensures that new requirements completely replace old ones in the given table. However, prior to initiation of the "option mode=replace" command past records must be written to the application server's database to insure retention of the date in the system for analysis, report and alert generating purposes. Accordingly, the use of the "option mode=replace" command is intended to facilitate date collection through data collectors designed to extract data from third party tools that do not maintain a notion of a transaction record. The "options mode=update" command is utilized to point to a location in the database intended to indicate the division between data already processed and update data which has not yet been processed. The "option mode=update" command is used by data collectors where there exists transaction records that serves as a marker so that the transfer of the entire set of records need not be repeated. Accordingly, in this mode rows will not be deleted as in the "option mode=replace" command as deletion is not required since the system has a means for determining which data requires processing. Status fields in tables can refer to values by using a lookup table command. The lookup command will allow the data collector to store lookup keys instead of the actual values, thereby normalizing the database and preventing the data collector from hard coding the lookup keys. For example lookup keys may take the following form: lookup <colname><tablename><reference_col_name>< reference_col_value> If the table does not contain a row where the <reference_col_name> field has the specified value, then such a row is added.-In the new row the <colname> field has the value of max(<colname>)+1. Additionally, null fields may be specified by the NULL or NA keyword. The text file provides merely a mapping to the actual tables in the database as opposed to actual values. Accordingly, it is the responsibility of the users who wish to write their own data collectors to ensure that the named tables contain the columns and that they are of the right type. The data collectors may further be programmed with the following flags:
Flag Description
/out:FILENAME Specifies file where output is to be sent
/mtime:STRING Specifies a string encoding the last time when the data
was collected.
File(s) Options understood by the data collector, specified in
the data collector file.
The mtime option is a string encoding the last time when the data was collected and used by the data collector to recognize that the data has not changed and does not need to be collected again. In addition, the following environment variables can be set for the data collector:
Variable Description
ACQ_PRJ_ID Integer, project id
ACQ_SET_ID Integer, set by the dcol_var setting for requirements
ACQ_SCH_ID Integer, set by the dcol_var setting for Microsoft
Project schedules
Accordingly, the mtime option will be set and read by the data collector and stored in the database by the Application Server 22. Using this method to transfer the data from the data collector to the application server allows data collectors to be written independently of the application server and specific schemas. Data collectors are therefore easier to write, maintain, and can be updated independently of the entire application server for increased reliability and customizability. To further illustrate the functions of the data collectors, the following description will be provided in relation to Microsoft Project. However, as mentioned above, the scope of the disclosure should not be limited to the third party project management tools discussed herein. Alternative project management software tools may be utilized, thereby providing comparable functions. In the example provided, information gathered by the data collectors is extracted from a Microsoft Project .mpp file through OLE (object linking and embedding) automation. All extracted data is stored in a relational database using ODBC (open database connectivity) thereby allowing the user to use any supported underlying database. For Microsoft Project, in particular, it is helpful to have additional information about the project schedules. For this function, a utility called the the Microsoft Project data gatherer is provided. It is written in Visual Basic and uses OLE Automation to access information from the .mpp files created by Microsoft Project. The Microsoft Project data gatherer is a utility designed to enhance information contained with Microsoft Project schedules. This data gatherer is available as a standalone application for both reading and writing a .mpp file. The Microsoft Project data gatherer proceeds through all tasks and milestones and prompts the user for information. For example, FIG. 3 is illustrative of a sample screen for accumulating task information. There are eight sections for task breakdown, including: Design/Coding, unit testing, bug fixing, test creation, test execution, contingency and other. The activity breakdown is used to calculate alerts and otherwise analyze project development. Unit Testing assists in conveying how many tests were created per unit time spent testing, Bug Fixing assists in understanding how long it takes to resolve outstanding defects, and Contingency is the information a user enters to describe padding in a task or an entire task devoted to padding which helps maintain the accuracy of the prediction algorithm. Furthermore, the Confidence levels inputted by the user are implemented by the system to assist with the prediction algorithm. When this program first reads a .mpp file, it will open a screen and ask what percentages to query from the file. In the example illustrated in FIG. 3, the user customized the percentage query at 80% and 90%. Accordingly, the information provided on this screen is used as the seeded information on the Milestone Information Screen, see FIG. 4. This information is generally entered once, and then may be kept current as the project progresses. The data collector for Microsoft Project works like any other data collector in that it runs at it's scheduled collection time, and sends back a text file with lots of tables of data in a manner described above. OLE automation is used to automatically extract the required information from Microsoft project. The embodied system is further configured to manage multiple files configured from multiple third party project management software through the use of multiple data collectors. Each part of a system user's organization may have separate project files requiring different data collectors to properly extract data. In such cases, the system is configured to start one data collector for each of the related project files. The schedule table stores information corresponding to known information about a particular schedule. A sample schedule table is as follows:
Column Type Description
Sch_id Integer Primary Key
sch_name String
Sch_comment String
Sch_filename String
Sch_author_id Integer foreign key: names(sched_author)
Sch_start Date Filled in by data collector
Sch_end Date Filled in by data collector
Sch_ask_prob1 Integer Filled in by data collector, with user
requested input
Sch_ask_prob2 Integer Filled in by data collector, with user
requested input
The schedule identification (sch_id) is then generated by the database. A schedule baselines history table stores baseline information about a given schedule. This data is not stored in the schedule's table. For example, the baselines history table is completed by the data collector if the baseline information is present in the Microsoft Project schedule. In the event a user is utilizing Microsoft Project software and the information regarding the baseline is present in the schedule, the information for the baseline is completed by the data collector file. The schedule baseline history tables are updated when a baseline changes, i.e. when new rows are added to this table reflecting new baseline dates. This allows a user to track changes to the baseline dates over time and, if necessary, to calculate a deviation from the original date. In addition, the system comprises a schedule baseline table which is similar in appearance and configuration to the schedule baseline history table, except that the schedule baseline table omits the date. This specific schedule baseline table allows for comparison of current start and end dates with the current baseline start and end dates for the project. Accordingly, in addition to tasks, the overall prediction date for each schedule is also stored in a schedule predictions table. The data collector further obtains information from the project identified in the layout of the directory of the system. An example of a project table is as follows:
Column Type Description
prj_id Integer Primary Key
prj_name String Primary Key
prj_comment String
prj_warning_days Integer Number of days later, causes a yellow
light
prj_emergency_days Integer Number of days before a red light
prj_probability_1 Integer First probability for prediction
prj_probability_2 Integer Second probability for prediction
prj_manager_id Integer foreign key: names(prj_manager)
prj_status_id Integer pending/active/retired
The term "prj" in the above displayed table refers to the project. Furthermore, the system comprises a projects schedules table for storing information necessary for referencing a system project to all schedules used in that project. The data in the project schedules table is separated in order to allow different projects to share schedules. An example of when sharing of schedules becomes necessary is when different projects within a company are dependent on each other. Accordingly, the projects schedules table allows the system to collect information for that project only once, and is illustrated in the following table:
Column Type Description
prj_id Integer foreign key:projects (prj_id)
sch_id Integer foreign key:schedules (sch_id)
The prj_id field stores the project identification. This value is different for every project in the system. The system further comprises a table labeled "collectors table". The collectors table is used for storing data collector information so that all mtime's are stored in the same table for easy look-up. A sample of the collector table is as follows:
Column Type Decription
prj_id Integer foreign key: projects(prj_id)
dcol_tool String tool name
dcol_name String unique name for this data collector, supplied
by the user
dcol_host String hostname to run on
dcol_source String source from which to collect data
dcol_mtime String last modification time
The most significant fields in the collectors table is the name and the mtime. The application server 22 queries this table to determine if it needs to run the tool again. In a further embodiment, there is a project predictions table, which summarizes the high level predictions every time they are calculated. In addition to the above discussed projects tables, the system further comprises task tables. The task tables store information about each task. A sample of the tasks table is as follows:
Column Type Description
sch_id Integer foreign key: schedules (sch_id)
task_id Integer Comes from the Task.Uniquid.
Unique per prj_id and sch_id.
Task_row Integer Row is Microsoft Project schedule
(task.id)
task_level Integer Level in the hierarchy
task_wbs String In the form of 1.2.3.4 and shows the
location of the task in the outline
task_name String
task_start Date When should it start?
task_end Date When should it end?
task_duration Long Minutes
task_status_id Integer foreign key:-task_status (status_id)
task_act_start Date Actual start date
task_act_end Date Actual end date
task_act_duration Long Minutes
task_progress Integer From 0 to 100
task_milestone_type_id Integer foreign key: task_type (type_id).
Identified whether a milestone
task_is_summary Boolean Same as summary property (identifies
a summary task)
task_is_critical Boolean Critical path task
User Defined User defined columns set during
configuration of project
The prj_id field matches tasks with projects, and the prj_id fields and the task_id fields act as a unique index. The task_id field is a unique identifier for each task within a given schedule. A task_confidence field and value is set by the user to specify the confidence level that the user has for the task being completed on time. Within the task table is a task_progress field which stores a percentage indicating how much of the task has been completed so far. For example, the percentage completion data will be provided by Microsoft Project as the illustrated third party project management software. The task table further comprises a task_uniqueId field which is an identifier for the project, so that if the user changes a task the table will not be affected. Another table in the system is a task_type table which stores information that identifies whether a task is a milestone, and if affirmative, what level milestone has been achieved. A sample of a task_type table is as follows:
task_type_id (Integer) task_type (string)
1 Not_A_Milestone
2 Minor_Milestone
3 Major_Milestone
There is also a task_baselines_history table for storing the baseline information for all tasks performed, i.e. the history of baseline dates per task. It is stored separately because it can be populated from Microsoft Project in our illustration or the system itself. This table is updated for every task when a baseline changes. For example, when a baseline changes, new rows are added to the table reflecting a new baseline date. This permits a user to monitor changes to the baseline over time and to calculate a slip from the original date, if so desired. A sample of the task_baselines_history table is as follows:
Column Type Description
sch_id integer foreign key:schedules(sch_id)
task_id integer foreign key:tasks(task_id)
task_bl_start date baseline start date
task_bl_end date baseline end date
task_date date date when this baseline was created
task_bl_duration long minutes
For fast access to the status of the task and most recent developments, the system comprises a task_baselines table. In addition, for summary tasks and milestones, the system comprises a task_predictions table for storing both 80% and 90% confidence dates as computed by Acqua. A sample of the task_predictions table is as follows:
Column Type Description
sch_id integer foreign key:schedules(sch_id)
task_id integer foreign key:tasks(task_id)
taskpr_start_1 date
taskpr_end_1 date
taskpr_duration_1 long
taskpr_start_2 date
taskpr_end_2 date
taskpr_duration_2 long
In the above referenced table, both sch_id and task_id fields uniquely identify a task from the tasks table. The taskpr_*_1 field corresponds to predictions given the user's first percentage confidence estimate, and the taskpr_*_2 field stores the second percentage confidence estimate where * represents either "start", "end" or "duration." Accordingly, the tasks table stores information about each individual task. In addition, the system further comprises task dependencies tables defined as task_deps. These tables store information about the relationships between tasks. For example, if task 2 is required to be completed before task 7 can begin, such information would be stored in this table. This information is required to determine what tasks need to be completed before a milestone can be achieved. In the system, there are various types of dependencies that can be established between different tasks. An example of the task_dep table and how the dependencies are stored is illustrated in the following example:
Column Type Description
prj_id integer foreign key:projects(prj_id)
sch_id integer foreign key:schedules(sch_id)
task_id integer foreign key:tasks(task_id)
pred_sch_id integer foreign key:schedules(sch_id)
pred_task_id integer foreign key:tasks(task_id)
dep_type string foreign key:dep_types(dep_id)
It is important to note, since a task may have more than one dependency the table may contain multiple rows for the same project_id, schedule_id and task_id fields. Additionally, there are several other tables utilized in the multiple scheduling. For example, there is a resource table for storing a list of all resources available in each project. A person can be listed as a resource on two different projects but appearing with a different resource identifier each time. An assignments table stores a list of all assignments for each task in the project. The assignments are stored in a separate table to allow a particular task to be assigned to more than one resource. Finally, the system comprises a task status table which is a lookup table for the status of different tasks. Through the use of the tables schedule changes are tracked over time to assist with predicting schedule dates and various trends in product development. Accordingly, the following information is versioned: resource schedule history, task history and completion dates. For each resource, a resource history table stores the frequency a resource does not meet a schedule. In addition, the resource history table calculates percentage of completion for the resource. A task history table stores information regarding the frequency in which task dates are changed and by how much. The date changes commonly reflect a time slip or functionality change, and this information enables the user to identify how the project deadlines changed over time. This table detects individual task and summary task changes. If the user would desire to ascertain historical information baseline date changes for tasks and historical information on phase changes, the user would have to access the task baseline history table and the phase table/task history table respectively. Finally, the completion table is completed by the analysis program that executes the Monte Carlo simulation. This table contains all of the data resulting from the Monte Carlo simulation. Accordingly, each time the program is executed, the old information for this project is deleted. Furthermore, the software quality management capability of the Application Server 22 functions as a critical component of the application delivery management system. The software quality management capability ensures that all of the manual and automated testing activities are coordinated and archived. The software quality management (SQM) data collector allows collecting of all information pertaining to the testing effort and provides statistics of how many tests were added, removed, how many are passing, and how many are failing. This information is then used in the schedule prediction and trend graphs. The SQM data collector generates a suite identifier field for its internal database storage. Furthermore, the SQM data collector comprises a project suites table for storing information between suites and projects, a suite table for storing information about each suite, and a tests table for storing information about all test cases in the current suite. The test table stores classes and cases. A test class result is pass if all of its results pass, otherwise its result is fail. At such time as a test is deleted from a suite, it is removed from the tests table. The SQM data collector further comprises a lookup table for the state of test codes, a lookup table for the result codes, and a requirements table for storing the associations between requirements and tests, thereby allowing the determination of which requirements do not have tests, how many pass and how many fail. A suite can have one set of requirements associated with it. Accordingly, a single test suite can only verify one set of requirements as defined by a set of requirements documents. Furthermore, the SQM data collectors comprises the following tables: a defects tables for storing the association between defects and tests; a jobs tables for storing information about the test jobs; an outcomes table for storing information about the outcomes of tests in those jobs; and a trends table for storing computed trend information about tests. Based upon all of the data collected from the SQM data collectors and the above-defined generated tables, software quality management reports are generated. The following reports are available based upon these data collectors: percentage of requirements which have been verified, failed or untested; current test results for a given project of pass, fail or unexecutable; an outcome history for a given test case; a trend of new tests added versus the number of verified requirements; and a trend of time spent testing versus the number of verified requirements. Accordingly, the SQM data collectors, ensure that all of the manual and automated testing activities are coordinated. After data is collected from the identified tools in the system and prior to having reports generated, analyzer applications are invoked to analyze the data collected and write their reports back to the database. As discussed earlier, alerts are one form of analyzers. They are mechanisms for notifying team members when there are potential problems with the project. Team members are notified in two ways: through monitoring reports accessible through a web browser and by e-mail alerts. Alerts are stored in the database of the server machine 20. An alerts_defn table stores the alerts definitions, as follows:
Column Type Description
prj_id integer foreign key:projects(prj_id)
alert_id integer unique per project
alert_name string name of alert
sample_msg- string sample message to help configuration
screen
alert_date date date when this alert was last calculated
(i.e. the application server ran the last
analyze program)
email_users string space separated list of users to email
category string user-defined name of the category in
which this alert is placed
filter string future string that we can selectively filter
alerts on.
Alert_active integer true means this alert is active
In addition, the database further comprises an alert_threshold table which holds threshold and filter values for specific alerts. It is important to note that there may be more than one threshold per alert. The alert_threshold table is configured as follows:
Column Type Description
prj_id integer foreign key:projects(prj_id)
alert_id integer foreign key:alert_defn(alert_id)
threshold_name string name to use to look up the value in the
pair (proj_id, alert_id, threshold_id)
threshold_type_id long foreign key: threshold_types
(threshold_type_id)
threshold_prompt string message to use to prompt for a new
threshold value
threshold_value string value, stored as a string for this threshold
for this alert
Furthermore, the threshold_type table is a look-up table for the threshold_type_id field and is configured as follows:
Column Type Description
threshold_type_id long primary key
threshold_type string
Alerts that want to find the threshold variables in order to compute whether to generate the alert must open the alerts definition table in the database and find the alert identification alert_id field that matches their alert name. Then they can scan the alert_threshold field table looking for a match of alert_id field and threshold_name field, at which point they will extract the threshold_value field. Each of the alerts comprise threshold levels for which new values of the threshold can be modified, wherein any new modification value will take effect the next time the alerts are computed. The following alerts, for which there is no hierarchy, are currently available on the system, although this listing of alerts should not be considered limiting in that additional alerts can be added by users on an as needed basis. These alerts represent common software practices, or common warning signs of software development projects getting into trouble. Applied as a whole, these alerts represent a knowledge base of software development rules that serve to warn project managers of potential pitfalls before, during or after they have occurred. The benefit is obvious for early warnings of potential pitfalls, as project managers can take early corrective action. Timely presentation of accurate information during critical stages is also helpful for project managers. The title of the alert is generally descriptive of the message it is conveying to the user:
Defects Rising Too Fast Tasks Late
Not Enough New Defects Summary Task Late
Not Enough New Tests Created Summary Task Slip Predicted
Test Creation Warning Milestone Late
Not Enough Test Were Executed Milestone Slip Predicted
Test Passing Rate No Baseline Schedule
Critical Path Warning Requirements are not linked to
Missing Milestone development task and/or
Project Data Out of Date milestones
Project Warning Task Slip Predicted
Schedule Warning Schedule Slip Predicted
Project Confidence Decreasing Project Slip Predicted
Schedule Confidence Decreasing Project is Late
Project Prediction Date Slipping Schedule is Late
Schedule Prediction Date Slipping Requirements not Linked to Testing
Schedule Changed Tasks
Project Changed
Low Testing Effort
The alerts are computed at such time as the analyze file is executed. The analyze file will create rows in an alert table. After creation of the rows in the alert table, an alert page reads the rows to generate the proper set of alerts to display to the user. Programs which calculate alerts are specified in the analyze directory, and can also generate pages or additional tables in the database, similar to other analyze directory programs. Furthermore, each alert program in the analyze directory can generate more than one alert, but they are all of the same type. For example, if one alert looks for late schedules, this alert can generate two alert messages as long as the alerts comprise the same identification. The alerts are statically generated and presented to the user in a single html page. Furthermore, each alert begins with an explanation of the alerts, and may link to pages with more information such as a link to customize, a link to receive help on this specific alert, and a link to delete the alert. The link for more information takes the user to the page that the alert generation program found was the primary trigger for the alert. The help link takes the user to the on-line help which explains more information about the alert generated, what the alert message is trying to convey to the user, what the user can do about the alert generated, and the definitions of the threshold values. The customize link takes the user to a page enabling them to customize the threshold values. The delete link deletes the alert. An alerts_generated table stores all alerts generated in the database of the server machine_. A sample of an alert generated table is as follows:
Column Type Description
prj_id integer foreign key:projects (prj_id)
alert_id integer foreign key:alert_ defn(alert_id)
message string this string may be long, contain html
tags, tables . . .
priority integer
alert_date date
mail_sent boolean
The alert programs add rows to the alert_generated table. The same alert name is presented as that utilized in the analyze directory. The message and priority field are set by the alert program, and date, mail sent and alert_id fields are automatically set. In addition, the user is not limited to alerts present in the system. A user can add new alerts by writing the alert program and creating new analyze files in the specific project's ANALYZE directory, adding an entry for them in the ANALYZE directory's index file. The results produced by the analyzers may then be utilized by the reports generators. The user may specify when reports should be generated. The user further has the option to force the regeneration of a given report, which may be useful after documents in the database are updated and the user wants to see the new confidence level predictions for meeting project delivery deadlines. Reports are generated by processing html files stored in a directory accessible to the Application Server 22, and may include calls to programs to generate some additional html or images. Furthermore, these html files may include applets, frames, or any other type of standard web-based logic. There are several customization options available for the reports generated. For example, the users can modify the web site for their project by editing these html files directly. Furthermore, users can add new links by editing the html pages directly, or the users can add new pages by adding lines to the index file in the PROJECT/REPORTS directory. Finally, user can embed commands to generate graphs in existing or new html pages. Accordingly, the user has a plurality of options available for customizing the reports generated by the application. The user further has the option to force data to be collected interactively. In such circumstances, the user is prompted to designate which data sources to update and which reports to generate. Regardless of how or when the data is collected and the reports are generated, all of the reports are catalogued and archived by default once per day immediately before the daily data collection report generation occurs. Reports that are regenerated are placed into a LATEST directory updating the previous information stored in this directory. However, the previous set of reports can always be retrieved from the LATEST directory. Accordingly, the Application Server 22 first collects all of the data, then runs all of the analyzers, and finally generates all of the reports for a given project, wherein all of the reports are archived and accessible from other reports. In a further embodiment of the invention, the invention has the ability to predict when projects will be completed. The system gathers information from a wide variety of tools to deliver a realistic assessment of project delivery, and a more realistic assessment than one tool can provide individually. During the initial setup, as disclosed earlier, the user is requested to supply information that assists the system in producing accurate predictions. In a preferred embodiment, the system uses the following data sources to provide prediction of project delivery, although additional data sources may be utilized with access to a related data collector: Project schedules maintained in Microsoft Project; Defect reports stored in PVCS Tracker; Requirements stored in Microsoft Word; and Testing information stored in the Acqua test management system. Based upon the initial information provided by the user and the information obtained by the data collectors, the prediction process incorporates a Monte Carlo algorithm to predict accuracy of project completion. The prediction algorithm is described as follows: First, the algorithm builds a probability curve for each task. The curve is set upon at least three data points the user has entered for each task, through the project gatherer utility, although fewer data points may be utilized. According to the probabilities calculated, a duration for this task is assessed. Second, the system analyzes the individual resources assigned to the task based upon the history of the resource in completing their tasks in a timely manner. Based upon the analysis, the duration is either increased or decreased based upon the history collected and the percentage of timely task completions. Accordingly, this outlined analysis is applied over approximately one hundred iterations to establish a probability curve for this one task, which will then be used as input into the overall Monte Carlo simulation. In this novel manner, multiple sources of data are applied to each individual task in order to determine it's liklihood (probability) of completing over a range of times. Applying additional sources of information other than mentioned above is easily imagined and can be applied equally well to the overall algorithm. Following this, the following three step analysis is undertaken. First, a trend analysis is implemented. The trend analysis generates additional potential delivery delays by analyzing various trends, such as incoming defects, number of tests created, and number of regressions found. Second, an alert analysis is performed. Alerts that have been triggered might mean a delivery problem. In the event that factors causing the alert have not previously been taken into consideration in prior steps of the prediction algorithm then the duration of the prediction must be altered for early or delayed prediction of product delivery. Finally, a comparison of additional time required in the trend and alert analysis against contingency factors is attained and time for project completion is increased or decreased from the total duration, as deemed appropriate. The basic prediction calculation works by defining a probability map for each task, as described above, and then adding the additional tasks that represent potential delays. The Monte Carlo simulation technique is then applied over a plurality of iterations so as to establish a refined probability curve for the entire schedule. The current date is then fitted to the curve and a confidence level is assigned to the task completion. In addition, the user can also access and review 80% and 90% confidence dates (or a different set of confidence factors of their choosing) for project completion. In a preferred embodiment, the system comprises the ability to manage, monitor and predict completion of projects based upon a multi-faceted, multi-data, multi-tooled approach. As such, the prediction software may operate to evaluate completion of a plurality of tasks in order to accurately predict completion of an entire project comprising a plurality of tasks and/or deliverable units. The system evaluates information gathered from an array of software tools to deliver a realistic assessment of project completion. The presently disclosed embodiments are therefore considered in all respects illustrative and not restrictive. The scope of the invention is indicated by the appended claims, rather than the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
|
Same subclass Same class Consider this |
||||||||||