For analysis, design, and implementation, ANVIN suggests the Rational Unified Process (RUP), a Software Engineering approach that ensures the production of high quality software, in meeting the requirements of its end users in a timely manner. RUP will be adapted to suit the needs of CLIENT requirements and specific development scenarios.
The following will be the phased approach that ANVIN will follow:
Below is a description of each of the four phases of the RUP process, tailored to suit the needs of CLIENT, along with a description of what the phase outputs will be and the modality (onsite/offshore) of the work to be performed
Inception phase launches the project. During this phase, ANVIN analysts will work with CLIENT to complete the following tasks:
The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, and to eliminate the highest risk elements of the project.
The following activities will be carried out:
Design of CLIENT system including Object modeling, and designing interactions between objects to realize the use cases
Elaboration phase involves freezing of architecture and developing a Proof of Concept to validate the architecture. This phase also involves both onsite and offshore components.
Design Document
Review and Approval of design document
This phase involves programming and testing. The developers will implement the common application framework, and all the interfaces. The developers will also perform unit testing of all the code. Programming and unit testing will be followed by system testing activity at onsite.
This phase will include:
Transition phase will primarily be an onsite activity at CLIENT. The following activities are performed during this phase:
Training of end users and System maintainers Migrating operational data into the new system Parallel run with an existing system (if required) System rollout (cut-over)
The extent of the transition support required will be agreed upon, between the client and ANVIN
ANVIN places great emphasis on project management of our onsite/offshore projects. Our project managers are experienced in all key aspects of project management, and the manager assigned to this project will have multiple onsite/offshore implementations as relevant, recent experiences. This section details key areas of project management that we address specially as success points for onsite/offshore project development.
For every project, there will be a Project Manager from ANVIN and a Project Champion from CLIENT. They will be responsible for overall delivery of the project within the timeline and defined resource criteria. The primary goal of the Project Manager is to communicate between the various stakeholders of the project and ensure successful completion of the project.
The major responsibilities of the project manager are:
The ANVIN project manager will act as a consolidator of issues and will coordinate issue tracking and resolution. The CLIENT project champion and the ANVIN project manager will work on all issue identification and resolution activities. Periodic conference calls and meetings will be held to discuss and resolve any issues, and these will be included as part of the project’s status reporting process. The issue resolution process will follow the same methodology as the change control procedure described later in the document.
As part of the project co-ordination, requirement manageability will be done, by tracking the requirements throughout the lifecycle, with the help of a requirements-tractability matrix
Communications management describes the processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information. ANVIN’s approach is based on honest and open communication both internally within the project team, as well as externally with the client project team and the client executives. ANVIN places great emphasis on keeping the client project team informed on all aspects of project progress.
The activities involved in communications management are:
Our Scope or Change Management approach is used for any changes to the project that entail significant changes to timelines, functionality, quality, work process, or budget, not just changes in project scope. This is a generic approach that can be adapted to fit CLIENT’s own scope control method, if so required.
Once the need for a change has been identified, the originator must complete a Change Request (CR) form. Change requests may originate from any sources affiliated with the project. These sources would include end users, technical staff, etc. Traditionally, most requests for change originate with either the project team members or the user. The originator will need to describe the current problem. Additional details may be filled in at this time if they are known. The originator may optionally assign an initial priority to the request in order to communicate the urgency of the request.
Once the need for a change has been identified, the next step is to determine whether the request warrants further investigation. The CR is forwarded to the ANVIN project manager.
The next step is to determine whether the change warrants further investigation and whether it is in the scope of the project. If further investigation deems that the change is not in scope and is not needed, then the Change Request will be closed. If the change is deemed as required by the project – whether in scope or out of scope - the impact of making the change will be analyzed (during Evaluation). The Change Request will be assigned to a team member for evaluation
The next step is to assign and prioritize the change request. Assignment depends on the nature of the change and availability of staff. The ANVIN project manager will also prioritize the change, depending on the impact evaluated during the initial review
Once the request and an impact analysis have been deemed necessary, the impact of making the change will have to be analyzed. This will include determination of the size, complexity, criticality, and resource requirements to implement the request. The analysis will detail the impact and cost of making the change. Examples include:
Specific tasks / deliverables requiring re-work and time estimates for each
The project team will determine whether the change is truly a change in scope and its impact on the project schedule. Regarding scope, many factors can contribute to the need for valid changes. These can include external events such as legal mandates, errors or omissions in defining the scope of the project, or value-added changes. The impact on the project schedule, resource requirements and any other information required to assess the change request and to determine the appropriate action items will be analyzed. If the change will affect the overall timeline or cost of the project, it is necessary to elevate the request to the Client Steering Committee for approval.
Once the impact of the change has been analyzed, a decision will be made on whether to implement the change, as well as the priority for making the change. The Client Project Coordinator and Client Project Director (if applicable) will also review all requests (either during the Project Status Meeting, or earlier, if the request is urgent). Each change request will be recorded and tracked. The description of the change, results of the impact evaluation, and the current status of the change will be recorded. The change request is managed throughout its life cycle and stored for historical viewing.
Thus, the Change Request may be :
If the change is rejected or cancelled, the CR will be closed. If the change is approved, it will need to be signed off before any further action may be taken.
If the CR is approved, the change may be implemented in a number of ways. If the change is to be implemented as part of the existing project, all deliverables affected by this change must be updated accordingly. The project plan must be updated (if affected) to include the change itself (including effort required to analyze the change) and any rework of other products/deliverables. All reworked deliverables will be reissued and all interested parties will be informed that the change has been completed.
The team member assigned to the CR will make the change. The project manager will update the project work plan and any other relevant documentation.
The CR may be closed at any point in the process – the change must have been completed, rejected or cancelled. Closed CRs will be reviewed in the Project Status Meeting
