SYSTEM AND METHOD FOR MANAGING A PROJECT BY INTEGRATING SET
OF MODULES
35 FIELD OF THE INVENTION:
The present invention generally relates to project management. More particularly, the present invention relates to a system and method for managing project through the integration of set of modules thereby facilitating project managers and other stakeholder’s tasks. 40
BACKGROUND:
Project Management is one of the widely followed methods in the software industries across the world to complete a project within in a specified time with assurable quality. The reason
45 for following this method is to deliver a complete project which complies with the client's objectives. This method generally involves the phases of initiating, planning, executing, controlling, and closing the project. Each phase involves many different tasks to be accomplished by project stakeholders. This way of planned execution of a project reduces the work of humans, particularly project managers who are responsible for monitoring a project
50 from the beginning to the end. Through this way of execution, the project managers can easily obtain the details such as number of members involved in the project in each phase, tasks assigned to them, time spent by each member against the tasks in the project, time taken for completing the overall project, etc. This method also helps other stakeholders / team members involved in the project to analyse and perform their work accordingly. Hence, this method is
55 widely considered for effectively utilising the time allocated for a particular project.
The project manager allocates one or more task(s) for each member in each phase of the project. The time spent for completing a task by each member in each phase was maintained and tracked in excel. This method of tracking time in excel was followed before the 60 automation of the project management. The tracking involved manual method of filling out timesheets in excel. This way of tracking was time consuming, error prone, easily modifiable

and not centrally stored. The consolidation of timesheets entered by different team members was also a cumbersome process. Hence, this resulted in the automation of project management activities including task planning and timesheet process that would facilitate the project 65 managers / stakeholders to monitor and track the project efficiently.
There are many existing prior art that discuss about the automation methods of project management. For example, United States Patent Number 5765140 to James George Knudson et al. entitled “Dynamic project management system” relates to a system and method for
70 managing project dynamically. The system comprises a server network with a programmable computer server and a master database. The programmable computer server and master database are operatively joined to a plurality of personal computer user terminals. The network in the system identifies a personnel resource pool that includes a plurality of users. The plan for the project is generated by a project planning tool that involves plurality of tasks
75 to be performed by the users with respective time schedules. The network then translates the project plan generated by the project planning tool into the master database to effect an assignments table including a list of project tasks assigned for completion by each of the users. The time sheets are periodically prepared in the master database from the assignments table and include a list of the project tasks assigned to a respective user and a time period
80 record for recording time entries therein.
United States Patent Number 7155700 to Avinash Sadhu and Paul Donald Koerber entitled “Computer program having an object module and a software project definition module which customize tasks in phases of a project represented by a linked object structure” relates to a 85 computer-readable medium that includes an object module and a software project definition module. The object module instantiate a linked object structure that represents a software development project. The software project definition module has one interface that interacts with the object module and another interface that interacts over a communication network with personal computers for the software development team.
90

United States Application Number 20100305994 to Peter John Ayrton Gaskell entitled “Project Management Tool” relates to a project management system. The system comprises a means for storing plurality of process definitions, plurality of phase definitions, plurality of task definitions, an association between each task definition, a selected process definition and 95 a selected phase definition, task status information associated with each task, and a display means for displaying the information.
Though there are various systems and methods to support project managers and stakeholders in manging the project / automating project management, none of them include integration 100 and automation of key project management activities involve in each phase of the project.
Hence, there is a need for a system and method that supports project managers and other stakeholders in managing a project by integrating separate modules for each phase thereby managing, tracking and monitoring the projects with very minimum time and effort.
105
OBJECTS OF THE INVENTION:
The primary object of the present invention is to provide a system and method for managing a project by integrating a set of modules for facilitating project managers and stakeholders.
110
Another object of the present invention is to provide a system and method for managing, tracking and monitoring a project with very minimum time and effort.
SUMMARY:
115
To achieve the above mentioned objects, the present invention discloses a system and method for managing a project by integrating a set of modules for facilitating project managers and stakeholders. This also allows them to manage, track and monitor a project with very minimum time and effort.

120
According to the present invention, the system comprises six modules namely Estimation module for estimating task and effort for a project, a Scheduling module for scheduling task and resource for a development project, a Ticket Maintenance module for scheduling maintenance task and resource for a support project, a Review Reporting module for 125 conducting review on the project, a Test Scenario & Test Case automation module for testing functionalities in the project using test scenarios and test cases and a Defect Tracker module for logging defects in the project. .
In accordance with the present invention, the method for managing a project comprises the 130 steps of estimating size and effort required for a project, scheduling task and resource for the project, scheduling maintenance task and resource for the project, conducting review on the project, testing functionalities in the project using test scenarios and test cases and logging defects in the project..
135 The set of modules in the proposed system are specifically built to facilitate the project managers and other stakeholders to prepare the essential project related artifacts in quick time. This system is made available instantly throughout the life of the project i.e., from requirement phase to project / product delivery.
140 In accordance with the present invention, the system minimizes the effort normally put in by the stakeholders for preparing the artifacts, sending to and fro the artifacts. This increases the productivity drastically. This also helps the project managers and key stakeholders to efficiently manage, track and monitor the software projects with very minimum time and effort.
145
The objective and advantages of the present invention will become more evident from the following detailed description when taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS:
150
The objective of the present invention will now be described in more detail with reference to the accompanying drawings, in which:
FIG. 1 shows the system with the modules proposed in the present invention for managing 155 projects;
FIG. 2 shows the overall flow of the method proposed in the present invention for managing projects;
160 FIG. 3 shows the overall flow of the method followed in the estimation module in the system of the present invention;
FIG. 4 shows the overall flow of the method followed in the scheduling module for development project in the system of the present invention;
165
FIG. 5 shows the overall flow of the method followed in the ticket maintenance module for support project in the system of the present invention;
FIG. 6 shows the overall flow of the method followed in the review reporting module in the 170 system of the present invention;
FIG. 7 shows the overall flow of the method followed in the test scenario and test case automation module in the system of the present invention; and
175 FIG. 8 shows the overall flow of the method followed in the defect tracker module in the system of the present invention,

REFERENCE NUMERALS
180 100 – Overall System proposed of the present invention
101 – Estimation module
102 – Scheduling module
103 – Ticket maintenance module
104 – Review reporting module
185 105 – Test Scenario & Test case automation module 106 – Defect tracker module
DETAILED DESCRIPTION OF THE INVENTION:
190 The present invention discloses a system and method for managing a project by integrating a set of modules for facilitating project managers and stakeholders. This also allows them to manage, track and monitor a project with very minimum time and effort.
According to the present invention, the system comprises six modules namely an estimation 195 module for estimating task and effort for a project, a scheduling module for scheduling task and resource for a development project, a ticket maintenance module for scheduling maintenance task and resource for a support project, a review reporting module for conducting review on the project, a test scenario and test case automation module for testing functionalities in the project using test scenarios and test cases and a defect tracker module for 200 logging defects in the project.
In accordance with the present invention, the method for managing a project comprises the steps of estimating size and effort required for a project, scheduling task and resource for the project, scheduling maintenance task and resource for the project, conducting review on the 205 project, testing functionalities in the project using test scenarios and test cases and logging defects in the project.

Each member involved in the project has a definite role throughout the project. The members generally involved in a software project include project manager, test lead, developers and 210 testers.
FIG. 1 shows the system with six modules proposed in the present invention. Similarly, FIG. 2 shows the overall flow of the method proposed in the present invention for managing projects. The method shows the functioning of each module in a definite flow.
215
The detailed flow of method followed in each module of the system is explained below:
Estimation module:
220 The first module of the system is the estimation module. FIG. 3 shows the overall flow of the method followed in the estimation module. The purpose of this module is to capture various types of inputs to find out the most realistic size for the project. The estimated size is further used to estimate the probable effort to carry out the various phases of project development such as requirement, design, development, testing, delivery and project management. The size
225 of the project is estimated using “Feature Task Count” technique which is one of the software size estimation techniques.
Feature Task Count
230 In Feature Task Count Technique, the estimation is performed using bottom-up approach. The following steps are carried out to calculate the size and effort involved to complete each life cycle phase:
. Breaking down the requirements into phases / modules, if applicable
. Breaking the phases / modules into business features and capturing the same
235 . Categorizing the features under masters, transactions and master detail

. Capturing the following operations for every feature
• Identifying Input Operations and giving a weightage for the same. The input
operations comprises of components that is visible for the users to either
observe the data or other actions performed by the users. The components
240 visible to the user are the number of data points to enter the data and other
actions like SAVE, ADD, EDIT, DELETE, PRINT, etc., performed by system users
• Identifying Business Operations and giving a weightage for the same. The
business operations comprises of components that includes steps / calculations
245 to accomplish specific tasks, which are written and consumed and are not
visible to users.
• Identifying Data Operations and giving a weightage for the same. The data
operations comprise of data points to absorb data captured with input
operations and the data points are internally used for calculations or
250 establishing relationships.
• Identifying Reporting Operations and giving a weightage for the same
• Identifying Interfaces and giving a weightage for the same
. Identifying and capturing the External Interface requirements with their weightage
. Arriving at the Total Task Count (TTC) for each feature by summing up total input,
255 business and data operation. The task count is calculated using reference chart.
. The complexity for each feature is calculated based on TTC. The complexity for each feature is categorized under Very High, High, Medium, and Low.
. The effort required for developing each complexity is arrived to compute the
complexity wise unadjusted effort in terms of person days. The complexity wise
260 unadjusted effort is summed up to derive total unadjusted development effort.
The effort specified here changes due to factors such as platform in which the project is developed, experience of the team, type of project development (Onsite / Offshore model), Software Development Life Cycle (SDLC), etc., Based on the ‘unadjusted effort’ from the

265 above steps and ‘% effort distribution’ defined at Organization level or Project Level, the ‘unadjusted project effort’ is arrived. The ‘unadjusted project effort’ is multiplied by ‘Value Adjustment Factor’ that gives the ‘adjusted project effort’. This value plus any ‘Special/Additional Effort’ (if any) provides the ‘Total Effort’ for the project in terms of person-days and also interpreted in terms of person-months (if required).
270
Scheduling (for Development Project):
The second module of the system is the scheduling module. FIG. 4 shows the overall flow of the scheduling module for development project in the system of the present invention. The 275 project scheduling module is built primarily to capture all tasks pertaining to different phases of a typical software development project. The different phases include requirement, design, development, testing, and delivery including project management activities.
The starting and ending date of a project are selected from the finalized and baselined 280 (approved) estimation, and they are defaulted when the schedule is prepared. There is a template in the module that comprises of a typical project development tasks and listed out for the project manager to assign the same to the resources attached to him / her. The task is then allocated to one or more resources who are mapped to the project.
285 There is a provision given to the user to view the resource wise allocated plans (earlier ML & Schedule Plan) with planned start date and planned end date with hours. This enables the project manager to view the existing plans for the team members for a given date range before allocating the task. The authorized person who plays the role of project manager either allocate the tasks by selecting start and end dates or specified hours with start date (the end
290 date is calculated automatically). The tasks are created accordingly and the resource may fill up the actuals on the same allocated date / time or on latter dates based on the actual date / time on / at which the task started and ended.

The key feature of scheduling module is that the sub tasks are created upto 10 levels and 295 planned start date and planned end date are updated for the current level as well as for all the previous Levels (main tasks) upto the root task. Similarly, the actual start and end time gets updated for current level as well as for all the previous levels upto the root task. The project manager is able to view the overall plan and status at broader level, phase level or even at sub-task / task level at any moment.
300
The tasks created initially are set to open status till the task is initiated by the resource / team member. The project manager / authorized user marks the task closed, when the task is tested (in case of development) and finished and till such time it is ‘In Progress’ status.
305 The following assumptions are made in the scheduling module:
1. Employee information such as Emp ID, Name, Designation, email ID, HR reporting head, etc., are furnished from HR Portal to a common repository on daily basis
2. Default working hours for a day is 7 hours
3. Unit testing is conducted by development team not under the current scope
310 4. The resource enters the timesheet till the employee is transferred to other project and at the same time, the project manager sends a transfer request mail to admin team
5. New NOVAC calendar with holidays & weekends are updated and made available by
the admin team
6. In case of a project working on different calendar, the details about the start time and
315 end time of daily work are furnished by the respective project manager with holidays
and weekend list.
Ticket Maintenance (for Support Project):
320 The third module of the system is the ticket maintenance module. FIG. 5 shows the overall flow of the method followed in the ticket maintenance module for support project in the system of the present invention. The main purpose of this module is to capture, track and monitor the maintenance requests (otherwise called Tickets) received from customer after the

project / product is made live and in maintenance / support mode. This facilitates the project 325 manager / lead to create ML requests based on the estimation performed and effort arrived. Then, the task is assigned to team, tracked and monitored effectively till its release and closure. The actual effort spent on each planned task is captured and monitored by this module. This module also provides provisions to capture the effort spent on Non-Project activities as well. This helps the project manager and other stakeholders to evaluate trend of 330 the project easily.
Ticket Types (Request Types):
The following are generally considered as Ticket types 335 1. L0 : Data related issues / Parameter settings
2. L1 : Minor screen issues which affects page / form / libraries, executables
3. L2 : Change Requests or Enhancements
4. L3 : New Requests

345 The following are generally considered as Ticket types:
1. Organizational Training
2. Human Resource related
3. Learning & Development
350 4. Call Centre Activity
The following assumptions are made in the ticket maintenance module:
1. Employee information such as Emp ID, name, designation, email ID, HR reporting head,
355 etc., are furnished from HR Portal to a common repository on daily basis. The records
pertaining to those who had joined recently or those had resigned recently, are available in the repository including employee information that underwent changes.
2. Estimation is performed for the maintenance request and impact analysis is completed
3. Default working hours for a day is 7 hours

360 4. Unit testing is conducted by the development team not under the current scope
5. The resource enter the timesheet till the employee is transferred to other project and at the same time the project manager sends a transfer request mail to admin team
6. New NOVAC Calendar with holidays and weekends are updated and made available by the admin team
365 7. In case of a project working on different calendar, the details about the start time and end time of daily work are furnished by the respective project manager with holidays and weekend list 8. Impacted features belong to a ticket is tested completely and status of the ticket (either IT Completed or Reopen) is communicated back to development team
370
Review Reporting:
The fourth module of the system is the review reporting module. FIG. 6 shows the overall flow of the method followed in the review reporting in the system of the present invention.
375 This module covers the functionality of reviews conducted on the various work products prepared or developed in a project. The review is normally conducted by a peer member within the project or outside the project or sometimes conducted by group of professionals within the organizations. The artifacts are reviewed and comments are logged in the review report. Upon fixing the defects, the reviewer again revisits the review report after fixing the
380 defects and verifies / ensures that all the defects are fixed and then either closed or reopened. There are review checklists that are referred during the review and ensured that all points mentioned in the checklist, are addressed.
The following assumptions are made in the review reporting module:
385
a. The respective artifact(s) are sent by author to reviewer by mail
b. The reviewer informs author about the completion of the review for his fixation
c. Defect type and error cause list undergoes change if there is any change in the template
used for Review Report in Quality Management System (QMS)

390 Test Scenario & Test Case Automation:
The fifth module of the system is the test scenario and test case automation module. FIG. 7 shows the overall flow of the method followed in the test scenario and test case automation module in the system of the present invention. This module covers the test scenario which is a
395 high-level description of an end to end functionality (Unit) to be tested and the test case which is a set of actions executed to verify a particular feature or functionality of a software application. The test case gives complete emphasis on "what to test" and "how to test" and has a set of steps with test data, precondition, certain expected and actual results developed for specific test scenario to verify any requirement. The test scenario focuses on more "what to
400 test" than "how to test" and has one or more relations with test case i.e., a scenario has multiple test cases. The flow of data functionalities are completely covered when test scenario and test cases are written with the help of business requirements and design documents.
The test scenarios and test cases are created using this module either by test leads or 405 authorized person prior to actual testing and upon receipt of patches (test requests from the development team). The work of a tester is well organized and simplified as they are written for functionality (unit) is already mapped with test scenario / test case. The corresponding test scenarios and test cases with steps are listed out for the testers to select and proceed while logging the defects. Thus, this module and defect tracker module are well integrated and 410 defect report on functionality wise (unit wise), TS / TC wise is generated easily and tracked. This also helps to ensure that the business processes and flows are as per the functional requirements.
The system proposed in the present invention is built in such a way that it enables the user to 415 easily understand, learn the sub-systems and operate, perform specific tasks more quickly with operations such as filtering, paging, sorting etc. The same user of the system plays single or multiple roles (Project Manager, Test Lead, Developer, Tester) simultaneously.

420 Defect Tracker:
The sixth module of the system is the defect tracker module. FIG. 8 shows the overall flow of the method followed in the defect tracker module in the system of the present invention. The purpose of the defect tracker module is to log the defects entered after system integration 425 testing is conducted. The main users of the defect tracker module are testers, test lead / test managers, project managers / project leaders and developers. The testing team (testers, test lead / test managers) receives test requests (patches) from development team (developers).
The defects are logged in the following 3 ways: 430
1. Patch is received and defects are found
2. Regression testing is conducted and defects are found
3. On adhoc basis
435 The defects are detected by the testers using test scenarios / test cases (1st case mentioned above) or without test scenarios / test cases (in case of 2nd / 3rd mentioned above) and are logged in the defect tracker. The same defects are then reviewed by test lead / test manager and if approved, the same is communicated to the development team for fixation. The project manager analyses the defect report, and then error cause. The priority is then set for each
440 defect and assigned to a developer based on their availability.
The present invention facilitates all the members involved in the project in the following ways:
445 For project managers
. Allows the project manager to prepare the key project artifacts such as estimation, project schedule (in case of development project) and log maintenance tickets (in case of maintenance & support project), assign tasks, track and monitor till its closure. The

450 project manager also receives artifacts for review, log review reports, track and
monitor its closure.
. Enables the project manager to manage testing process very effectively with the help of defect tracker module. It also facilitates to prepare test scenario & test cases which is well integrated with defect tracker module.
455 . Facilitates the project manager to generate weekly status & monthly status report
instantly to produce the same for management review
For Test lead
460 . Facilitates the test lead to track the defects efficiently right from the receipt of test
request, logging the defects, approving & assigning the same to testers and update the testing status which is instantly available to development team.
. Provides option to view the overall status of the defects is given
. Creation of test scenarios and test cases are possible and the same are instantly
465 available while logging the defects for the specific functionality
. Allows the test lead to approve the defects raised by testers, approve their timesheets etc.,
For Developers
470
. Help the developers to view the planned assigned tasks on time, carry out the tasks, log the actual time against the planned tasks and update the status. This is instantly available for other relevant stack holders.
475 For Testers
. Helps the testers to view the assigned tasks (i.e.) test requests, carry out the testing, log the timesheets, defects or verify the existing fixes and update the request status. The

defects raised by testers are instantly visible to development team upon finishing the 480 testing.
All the modules in the system are available all time and the integrity of information is maintained as well. This system has less than 1hr downtime and that too during non-working hours as and when the new sub-system and enhancement / patch release.
485
The system accommodates 400 users during the peak usage time window of 4:30 pm to 5:30 pm, with estimated average session duration of 20 minutes. The web pages generated by the system are downloaded in not more than 10 seconds over a 40KBps modem connection. The responses to query take no longer than 7 seconds to load on the screen after the query is 490 submitted by the user. The system display confirmation messages to user within 4 seconds after the user submit information to the system.
The system by default supports windows authentication, where user doesn’t need to give the credentials to access the modules. This system ensures and prevents unintended access and 495 resist deliberate attacks intended to gain unauthorised access to confidential information, or to make unauthorised modifications to information or to the sub-systems or to deny service to legitimate users.
While the foregoing written description of the invention enables one of ordinary skill to make 500 and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The invention should therefore not be limited by the above described embodiment, method, and examples, but by all embodiments and methods within the scope and spirit of the invention as claimed.
505

1. A system (100) for managing a project by integrating a set of modules, comprises:
a. an estimation module (101) for estimating size and effort required for the project; 510 b. a scheduling module (102) for scheduling task and resource for the project;
c. a ticket maintenance module (103) for scheduling maintenance task and resource
for the project;
d. a review reporting module (104) for conducting review on the project;
e. a test scenario and test case automation (105) module for testing functionalities in
515 the project and
f. a defect tracker module (106) for logging defects in the project.
2. The system as claimed in claim 1, wherein the size and effort are calculated by breaking
down requirements into phases / modules.
520
3. The system as claimed in claim 1, wherein the scheduling module captures tasks in each
phase.
4. The system as claimed in claim 2, wherein the phases includes requirement, design,
525 development, testing, delivery and project management activities.
5. The system as claimed in claim 1, wherein the functionalities are tested using test
scenarios and test cases.
530 6. A method for managing a project by integrating a set of modules, comprises the steps of
a. estimating size and effort required for the project;
b. scheduling task and resource for the project;
c. scheduling maintenance task and resource for the project;

d. conducting review on the project; 535 e. testing functionalities in the project; and f. logging defects in the project.