The Requirement Deficiencies Of Project Failures Information Technology Essay
For any project gathering the requirements is the basic and key step which defines what the project is supposed to do. Requirements give the information on which the system design is based. If the requirements gathered are incorrect or incomplete this will lead to the failure of the project. Requirements deficiencies may occur due to many reasons, difficulty in prioritizing, natural conflicts of interest. While gathering the requirements for a project we need to estimate the cost of the project, scope of the project, reliability, etc. The law states that the incomplete or wrong definition of requirements is the major cause for the project failure.
EXAMPLE:
A software company, Virtusa released software for its client Phase Forward but within few days the software didn’t worked as per the requirement of the clients and the software had to undergo inspection, the result was the failure in providing the complete requirements by the client. At last the software was a failure due to requirements deficiencies.
Boehm’s first law
“Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed.”
There are many errors in requirements definition stage and design stage; errors in design stage are less serious than in requirements stage. The developer of the project should know the exact purpose of the project and identify the errors in the earlier stage of the project development otherwise the removing these errors in later stage would be costly as the time of the project increase the expenses of the people based the project increases. And it takes the team to more time to remove these errors later on.
EXAMPLE:
Mentor Graphics Company released a software application with over 300 bugs in it. The expected deadline for the software was almost impossible to achieve with all the bugs in it. The company had to hire more software engineers to remove the errors from the software which increased the cost of the project which was much higher than estimated.
Boehm’s second law
“Prototyping (significantly) reduces requirement and design errors, especially for user interfaces.”
Prototyping helps the user to see how the completed project would appear. Prototyping of a project helps identify and reduce the errors in the project. Prototyping also reduces the gap between description and implementation. Prototyping of the project helps to keep a better understanding between the development team and the client. Depending upon the user requirements and the changes to the projects different prototype can be built.
Example:
Davis’ law
“The value of a model depends on the view taken, but none is best for all purposes.”
A model is used to represent a system. A model can be viewed for different aspects such as data, process, state transition, structure and behaviour. The importance of the model is the way it is viewed. Model are used for checking the consistency but not executed. A model can answers many questions that a actual project would face in the real world.
Example:
Ford motors create a real life size model of it vehicles out of clay to observe the look and feel it gives. It also helps the engineers to collect the data about the aerodynamics of the car and the changes can be made by observing the model before building a real one.
Your first task is to describe each software development methodology clearly and completely in your own words. You may use diagrams, examples or UML to help you do this.
Waterfall Model:
Waterfall model is the classic life cycle tool for the software engineers. The waterfall model demands a systematic sequential approach to the software development that start at the system analysis level and passes through analysis, design, coding, testing and maintenance. The waterfall model goes through the following activities:
System engineering and analysis.
Software requirements analysis.
Design.
Coding.
Testing.
Maintenance.
Analysis
System engineering
Design
Code
Testing
Maintenance
In the waterfall model we need to go through one phase to another phase when the requirements of one phase are met. For example if the requirements of the design phase are complete then we move to coding phase, if the requirements in this phase are not complete then we will be stuck in coding phase until the requirements of this phase are met. There are advantages and disadvantages in the waterfall model.
Real time projects rarely follow the sequential flow of the waterfall model as it is difficult for the customer to give all the requirements at a time. Waterfall model is only suitable for projects in which the requirements are specified explicitly.
Agile Methodology:
Using an agile methodology the project is break down into small sections or tasks. Each task is done in one week to four weeks. Each task undergoes the complete development cycle i.e requirement analysis, designing, coding and testing. After each task is completed a working prototype is shown to the client, the client may then have some more requirements which they did not mention in the beginning to be added to the project which can be added in the next iteration. In this way there will be very less bugs when the software is released at the end.
An agile team consists of 5-9 persons, where the persons are software developers, testers, etc.. . By having a small team it is easy for the team to communicate with each other. An agile team prefer to meet the client face to face rather than by having requirements on paper when the team and client are in same location or by video conferring when the client is overseas. The main aim of an agile methodology is to develop the product with less errors and complete functionality with a given time.
Using the first four laws of the text, show where these are either implemented or missing in each software development methodology (Total Two). If a law is missing, explain the consequences and suggest how the process might be improved.
Waterfall model with Glass’ Law
“Requirement deficiencies are the prime source of project failures.”
According to glass law insufficient requirements is the major cause for project failures. So according to glass law the requirements for a project should be clearly defined so that the project is done successfully. In a waterfall model each phase should be completely satisfy the needs of that phase so as to go to next phase. Therefore in the requirement analysis phase in waterfall model should be completely fulfilled so the glass law is applicable in waterfall model.
Waterfall model with Boehm’s First Law
“Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed.”
According to Boehm’s first law identifying the errors in the later stage of the project is more costly to remove them. So the errors should be identified in the earlier stage of the project. Boehm’s first law is applicable in waterfall model as in the waterfall model is more reliable and the final product of the project is good. In waterfall model we go from one phase to another so to correct the errors we need to come back and start from the beginning which would become more costly in doing it.
Waterfall model with Boehm’s Second Law
“Prototyping (significantly) reduces requirement and design errors, especially for user interfaces.”
Boehm’s second law states that prototyping the project reduces the requirement and design errors. So the project should have a prototype and a good user interface which helps us to reduce the requirement and design errors. In the Waterfall model prototypes should be considered when we are defining the requirements so that we can use these prototypes to identify the errors in the earlier stage.
Waterfall model with Davis Law
“The value of a model depends on the view taken, but none is best for all purposes.”
According to the Davis law the value of a model only can be determined by the view taken, but none of the view can satisfy all the purposes of the project. So there is no model which can satisfy all the purpose in one view so waterfall model is cannot be implemented using the Davis law.
Agile methodology with Glass Law
“Requirement deficiencies are the prime source of project failures”
According to the Glass law insufficient requirements is the major cause for the failure of the projects. In the Agile methodology the requirements are defined in the earlier stage and can be defined whenever they are required so there is no issue of insufficient requirements in the Agile methodology therefore the Agile methodology can be implemented using the glass law.
Agile methodology with Boehm’s First Law
“Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed”
According to Boehm’s first law removing the errors in the later stage of the project is more expensive then to identify them in the earlier stage and remove them. In the Agile methodology the errors can be identified when they occur and can be removed as they occur, so there will not be any errors later. But if they occur it would be costly to remove them later. Therefore Boehm’s first law is applicable with the spiral model.
Agile methodology with Boehm’s Second Law
“Prototyping (significantly) reduces requirement and design errors, especially for user interfaces.”
According to the Boehm’s second law prototyping of the project reduces the errors. In Agile methodology we develop prototypes for each and every task as the project develops so as to reduce the errors. Therefore, Boehm’s second law in applicable for Agile methodology.
Agile methodology with Davis’ Law
“The value of a model depends on the view taken, but none is best for all purposes”
According to the Davis law the value of the project depends on the view taken, but none of the views can be best suited for all purposes. Different views of the project satisfy the different purposes of the project. Therefore Agile methodology or any model is not applicable with the Davis law.