ELT-MCGID
Methodology and Work Plan
Version 1.0
Group Id: F000000
Supervisor Name :abc
Revision History
Date / Version / Description / Author21-01-2011 / 1.0 / Method and Work Plan / Mc00000000
Table of contents
1. Introduction of the Planning Phase
2. Methodologies
2.1 Existing Methodologies
2.2 Adopted Methodology
2.3 Reasons for choosing the Methodology
3. Work Plan (Use MS Project to create Schedule/Work Plan)
1. Introduction of the Planning Phase
I have covered the requirement phase of my project. I have submitted my SRS documentation. Some of the requirements will be discovered in the next stages and dealt accordingly. The tools I have learnt and the tool I am learning to develop the project are described in the “Reason to choose methodology” portion which is coming a little later in this document. Moreover the Gantt chart at the end of this document will show that what I have covered and what I have planned to cover in future.
Advantages of Planning in Project:
· Everything is clear to us and to everyone that what sorts of tasks are to be performed throughout the project and when to perform those tasks.
· We are totally aware how a task affects the other task in the sequence of tasks.
· We can easily and clearly track the progress of our task
· It almost never happens that we miss a major task in our plan
· Planning in project forces us to complete the project in time
· Planning helps us in estimating time and cost of the project
· Planning helps us in gauging the ability of our present resources to accomplish the project
· It helps us in planning the future policies
2. Methodologies
2.1 Existing Methodologies
Some commonly used methodologies for the development of a project are described below:
Ø Build-and-Fix methodology
Ø Waterfall methodology
Ø Rapid Prototyping methodology
Ø Incremental methodology
Ø Spiral methodology
Build-and-Fix Methodology
Unfortunately many projects are developed using this model. Developers use no specification and construct no design. They simply develop a system and give it to user. Users use it and give feedback if not satisfied. The developers modify the system according to feedback and give it to users again. This process carries on unless the user is satisfied. This method is used for small projects. The cost of build-and-fix is greater than the cost of properly specified and carefully designed product. It is because the system is modified repeatedly.
Waterfall Methodology
This methodology is called waterfall because of its systematic and sequential nature. This methodology goes through the sequence of analysis, design, coding, testing, and maintenance.
The five stages of the sequence are:
Requirement Analysis and Definition: In this stage the systems services, constraints and goals are defined by consulting the system with users.
System and Software Design: In this stage the requirements are classified into hardware and software systems. It gives the overall architecture of the system.
Implementation and Unit testing: In this stage the software design is implemented in units and each unit is tested and verified for its correct function.
Integration and system testing: When all the units verified for their correct function they are then combined to form a whole system. And the system is delivered to the user.
Operation and Maintenance: In this stage the system is installed and put into practical use. If errors are found they are corrected and system is improved.
The waterfall model proposes a sequential flow. It means that no next stage is started unless the previous stage is finished. But in real life it is not true. Each stage overlaps the previous stage.
Because each stage in this model is well worked out and well documented so the maintenance becomes easy.
This methodology also suffers from time and cost related consequences because the user feedback is taken at the end and after the system is delivered.
Rapid Prototyping Methodology
The Rapid Prototyping Model is used to understand and capture the requirements from user. The developers develop rapidly a prototype or a mockup of the system which is delivered to the user. User tests that mockup and gives feedback. On the basis of that feedback the mockup is improved and given to user for further feedback. When the requirements from the user are fully understood and captured then the actual system is developed from scratch.
Incremental Model
In the waterfall methodology the main shortcoming was that the complete product is developed and delivered to the user in one package. Due to this reason the feedback from the user is delayed.
So to get the instant feedback from the user we use incremental methodology. In the incremental methodology the product is divided into smaller units. Each unit is developed and delivered to the user in increments. Each unit can be developed quickly as it is much smaller in size. Also an instant feedback is available from the user. So errors in smaller units are easy to be eliminated. The Incremental model has an open architecture so that the smaller units can be integrated to make a bigger product.
Spiral Methodology
This methodology was developed to avoid the risk that might be faced in development of software. For example, the risk might be a resignation from the key person or it might be a declaration of the manufacturer of the software as being bankrupt.
The spiral model is almost a waterfall method with an addition of risk analysis. In this methodology, before evolution and planning for a stage we first, identify its alternatives and analyze its risks. If these issues are not resolved the stage and in some cases the product is terminated.
There are two dimensions in a Spiral Model; A Radial dimension which represents the cumulative cost to date, and an angular dimension which represents the progress through the spiral.
The spiral model is very sensitive to risks. Due to its spiral nature the development and maintenance run in parallel. This method is used for development of large-scale and in-house software.
2.2 Adopted Methodology
I will adopt the VU Process Model which is the combination of Waterfall methodology and Spiral methodology. VU Process Model will combine the benefits of Waterfall and Spiral methodologies.
VU Process Model:
In the VU Process Model each stage of the project is improved iteratively until it is approved. If a stage has some deficiencies, these deficiencies are iteratively identified and then improved accordingly. No next stage is started unless its previous stage is accepted. This merit of the VU Process model is taken from the Spiral Model.
And when one stage of the project, under the VU Process Model, is well improved and accepted then the next stage is started and worked on.
This merit of the VU Process model is taken from the Waterfall Model.
VU Process Model Diagram:
2.3 Reasons for choosing the VU Process Model
I have chosen the VU Process Model because;
My project is divided already into different phases i.e. gathering and analyzing requirements phase, planning phase, analysis and design phase, development & final project report phase, and final report/viva phase.
I will complete each phase in sequence and will submit it to my supervisor. He will suggest me improvement in each phase before starting the next phase. I will make improvement in that phase. This process will be adopted due to the spiral nature of VU Process model. When the phase is well-improved and well worked-out, and also accepted by my Supervisor then I will proceed to next phase. This will be done due to the waterfall nature of the VU Process model.
3. Work Plan
The work plane of the project is given in the following Gantt chart.
There are six red colored labels in the left pane of the chart. These labels are showing stepwise all the major tasks to be completed to ensure the successful development of the project.
Each task is divided into its subtasks.
Horizontal black colored bars against each major task are showing the total duration within which the task will be completed.
Blue bars under each task are showing the duration for subtasks.
Black strip inside the blue bars are showing the percentage completed for a subtask.