Using the activities detailed in this Project Planning process description and in supporting documents, project teams describe the work they will do, develop estimates of effort, develop a schedule, plan their management and technical approaches, identify measures to gather, and develop a risk management approach. It includes configuration management that is detailed in Chapter 5 titled Configuration Management.

The Project Monitoring and Controlling Process is used by project managers to ensure the team is making satisfactory progress towards the project goals. The purpose is to track all major project variables – cost, time, scope, and quality of deliverables.

The overall objectives of the process are to:

• Track and review actual project accomplishments and results to project plans
• Revise the project plan to reflect accomplishments thus far, and to revise the plan for remaining work, if needed
• Provide visibility into progress as the project proceeds, so that the team and management can take corrective action early when project performance varies significantly from original plans

• Project Planning Process
• Project Monitoring and Control Process
• Process for Project Reviews
• Process for Measuring Efficiency and Effectiveness Measures

• Supporting Templates
  • Short Project Summary – A minimal plan for a small project; this can also be used for tracking progress on the project.
  • WBS Elements from the Life Cycle Structure of 12207 WBS – List of WBS items that might be included in a life cycle for a project, with components for
    • Primary life cycles for acquisition, supply, development, maintenance, operations
    • Supporting processes for documentation, configuration management, quality assurance, verification, validation, joint review, audit, problem resolution
    • Organization processes for (project) management, infrastructure, improvement, and training

• Supporting Checklists
  • Project Planning Checklist – This checklist carries the Items to consider when checking the work of a project team in building a project plan.

• Supporting Templates
  • Weekly Project Status Report -A sample weekly status report for a project; includes items for tracking milestone progress, key accomplishments, costs, risks, and action items.
  • Tracking Templates – Several worksheets for tracking action items, a simple work breakdown structure, and risks
• Supporting Checklists
  • Change Management Checklist – Items to consider for documenting change requests, handling them with a change process, and ensuring approved changes are included in the project deliverables.
  • Configuration Management Checklist – Items to consider for planning and performing configuration management.
  • Project Monitoring Checklist – Items to consider when checking the work of a project manager and project team in monitoring the project to its plan.
  • Project Review Checklist – Items to consider when planning, conducting, and following up on actions after a project review
  • Quality Assurance Checklist – Items to consider for planning and performing quality assurance

Keeping in mind the special needs for the system we have categorized the analysis and design of the systems into two parts. Each phase of study and analysis would be specially treated and would be given important consideration to the fact of each systems impact on the other system.

The analysis and design phase will be split into two parts:

• Analysis and Design of Existing System
• Analysis and Design of Proposed System (new system)

As the development for the new/enhanced system has to be based on the existing system, the study of the existing system/components of system will be done critically. This will enable to understand the functional requirements of the system and if required suggest the required modification/enhancements.

The outcome of this study would enable us to design and develop a robust and optimized system. The existing system would require attention and special treatment keeping the following points in perspective:

• Functional aspects of the existing system to be enhanced in the new system
• Interfacing the new features in the system over the existing components

• Complete requirement specification (if available) of the existing system
• Complete functional specifications of the existing system

The prototype to be developed will be in two phases, namely:

1. Prototype Beta
2. Prototype Final

Specifics of the prototype to be developed based on the final understanding and the agreed final requirement is explained herein.

The beta prototype of the system will involve the development of new layouts, content, theme for the website along with the representation of the service/interfaces.

The final outcome of the development will be a prototype, which will be considered to be of Beta version and will subsequently be sent for the approval.

Any changes, modifications in the beta prototype will be reviewed and incorporated Inputs for the prototype development will be:

• Finalized Requirement specifications from study of new system
• Final Design evolved at the end of study of new system
• Final defined functional specifications

During this period modifications/enhancements will be carried out based on the feedback. This phase will also carry out review of the images/graphics/animations (as applicable) and upon successful clearance will be incorporated in the System.

The application development will commence only after the final approval of the beta prototype (i.e. with the final prototype). The system to be developed will be as per the set design and standards for the system. Each stage of application development will be monitored closely with the set milestones for each sub-system/sub-element/module.

Each successful accomplishment will be followed by the required round of testing (as applicable). The following tasks shall be carried out during this phase:

• UI and display logic development
• Business Logic Component development (enhancement/creation as required)
• Data handling components (specifically for new system)
• Creation of data /general information validation components

• Functional Requirements Document
• Technical Requirements Document
• Test Requirements Document
• Test Plan/Procedure
• Inventory item
• Defect report
• Change request
• Quality Assurance check list and signoff sheet

• Review functionality and technical capabilities to make sure that the capabilities to be coded to are understood.
• Identify capabilities and variances to be included. This is similar to what is required to be included in the test requirements. By identifying the test requirements more fully before the development process, the capabilities will be more fully understood. This will help with the code development by providing a better scope for the project.
• Test new code using unit and Integration Platforms with updated unit level test plan. A first level test will be performed on either the unit or the integration and testing platform. Any hardware requirements should have been identified in the test requirements so that it will be better understood what is needed to perform the unit level testing. This will also be the first level of integration testing. So any impacts to other modules will need to be identified at this stage.
• Inventory new code modules. Use the procedure documented in the following section to help understand the different inputs required.
• Update defect status. After completing code development, the status of the inventory item or defect should be changed to testing or system level testing as appropriate.

One of the important features of the system development and implementation will be development of required components for the new system and replacement of existing systems with the new systems. The basic point as mentioned in the Analysis/Understanding and Design of Systems phase is the study of the functional aspects of the system with the behavioral impact of system on the data being used in the new system. Also the point to be considered while system development will be of keeping the integrity of the existing systems components intact.

At the end of the exercise the system to be developed will be a final amalgamation of the content/functional components and flow of the existing system along with the new required/enhanced functionalities.

Each phase of testing will be undertaken as per the concerned stage of application development and will always have a sound process of preparing comprehensive test plans in adherence to the base system requirement catering to the complete (also special – if any) needs of every stage of system/sub-system.

The following methodology will be followed for testing as well as test plan preparation:

• Component Testing
• Integration Testing
• System Testing
• Acceptance Testing

Each stage of testing is incremental, fully taking into account the inputs from the previous testing phase. As shown in following figure each phase of testing follows a set of standard procedures, which strictly comply, with QA norms. Feedback and reporting at each phase is robust to evolve a sound check system at place, which becomes a benchmark for the tester of next phase testing. During the complete process of testing, the bugs and defects reported are closely monitored for making any kind of design/requirement decisions (if required) for enhancing the system. The outcome of this complete exercise is a robust standard system as per the requirements and expectations of the client.