The waterfall approach is a number a small development steps. A step does not start until the previous step has been completed, although in practice there is often considerable overlap. A key output in a waterfall project is the User Requirements Specification. This is a detailed non-technical document that forms the basis for the new system and covers its functionality as a whole. Before a waterfall’s steps are decided a feasibility study is done, in order to answer questions like, can we solve it, should we solve it and what is the most cost-effective solution.
In a waterfall project it becomes increasingly expensive to correct errors and omissions as development progresses because of the increase in the amount of re-working that is necessary, as if what the customer in presented with fails to meet their requirements the waterfall has to be rolled back. This means much time can elapse before the end-users see a working system and because of this, the waterfall method is considered slow but due to the need for rigorous system analysis and specification it remains the preferred approach for developing systems, where it is very important to get the specification exactly right.
1.1 Overview of the waterfall method
1.2 Rapid Application Development
RAD is based on the recognition that businesses rely on information technology and as a result, they must be capable of developing and deploying new information systems rapidly. The time required for a waterfall development is a severe constraint, which RAD counters by making the assumption that nothing is ever perfect first time. RAD takes a different approach to the development life cycle than the waterfall method by concentrating on identifying and delivering the main business benefits as rapidly as possible
1.2.1 Overview of Rapid Application Development
1.3 Design Approaches
Traditional decomposition also known as functional or traditional design decomposes the solution into major steps and each major step into further smaller steps. This type of design is defined as procedural-oriented. An advantage to this approach is the smaller the problem gets, the easier it becomes to write as a coder. The disadvantages to this approach are the data and operations are separated and there is no data abstraction or information hiding, this approach is also not responsive to change.
The object-oriented design can be seen as identify interacting objects, the classification of each object, Identify the data and operations within each object, establishing relationships between other objects and the grouping of similar objects . The advantages of OOP and design are its quick response to change, Encapsulation, simplify Testing, debugging, Easy to understand, don’t have to keep reinventing the wheel and it’s easier to manage and maintain. A disadvantage to object orientated design can be that it over generalises and their can be artificial class relations. I chose to design my system using object orientated design over the traditional decomposition because of the disadvantages I described above but I also chose object orientated design because of the speed I was are able to solve the problems.
Created: 2014-09-17 13:12:20 Updated: 2014-10-06 13:18:51