Students need to understand the concepts of the following software process models:
The waterfall is the first methodology generally acknowledged as being dedicated to software development. Its principles are for the first time described by Winston W. Royce even though the actual term waterfall is not used in the article. It emphasizes meticulous planning and it outputs comprehensive documentation. The Waterfall methodology is a linear sequential process where every stage starts only after the previous has been completed. Each stage has its own deliverables. The Waterfall methodology is predictable and values rigorous software planning and architecture.

Prototyping is a methodology that evolved out of the need to better define specifications and it entails building a demo version of the software product that includes the critical functionality. Initial specifications are defined only to provide enough information to build a prototype. The prototype is used to refine specifications as it acts as a baseline for communication between the project team and the project owner. The prototype is not meant to be further developed into the actual software product. Prototypes should be built fast and most of the time they disregard programming best practices.

Iterative and incremental is a methodology that relies on building the software application one step at a time in the form of an expanding model. Based on initial specification a basic model of the application is built. Unlike the prototype, the model is not going to be discarded, but is instead meant to be extended. After the model is tested and feedback is received from the project owner specifications are adjusted and the model is extended. The process is repeated until the model becomes a fully functional application that meets all the project owner’s requirements.
Extreme programming breaks the conventional software development process into smaller more manageable chunks. Rather than planning, analyzing, and designing for the entire project at once, extreme programming exploits the reduction in the cost of changing software to do all of these activities a little at a time, throughout the entire software development process. It enforces pair programming where two developers use the same computer. One is writing code and the other is supervising. They change roles at regular intervals. For reducing the number of errors, it relies heavily on unit testing, and developers are required to write tests before writing the actual l code. There is a collective ownership code policy where any developer can change any code sequence even if it was not written by him. The project owner is the one that decides the priority of the tasks.

Q. Based on the strengths and weaknesses given what do you think which methodology is the best one and why?

  

Transcribed Image Text:

Methodology Waterfall Prototyping Characteristics comprehensive documentation - meticulous planning - linear-sequential process - each phase has its own deliverables Strengths - easy to manage - easy to understand for the project owner and team - build one or more demo accurate identification versions of the of software product - project owner is actively involved - prototypes are meant to be discarded. writing code is valued over writing specifications application requirements - early feedback from the project owner - improved user experience - early identification of missing or redundant Weaknesses working code is delivered late in the project - does not cope well with changing requirements - low tolerance for design and planning errors leads to unnecessary increase of the application's complexity - increased programming effort - costs generated by building the prototype Methodology Waterfall Prototyping Characteristics comprehensive documentation - meticulous planning - linear-sequential process - each phase has its own deliverables Strengths - easy to manage - easy to understand for the project owner and team - build one or more demo accurate identification versions of the of software product - project owner is actively involved - prototypes are meant to be discarded. writing code is valued over writing specifications application requirements - early feedback from the project owner - improved user experience - early identification of missing or redundant Weaknesses working code is delivered late in the project - does not cope well with changing requirements - low tolerance for design and planning errors leads to unnecessary increase of the application's complexity - increased programming effort - costs generated by building the prototype

Answer rating: 100% (QA)

Answer Based on the strength and weakness given Iterative and incremental software process model is ... View the full answer