Different Types Of Software Development Models

The Waterfall methodology was created by Winston Royce in 1970 and is based on the idea of "...progressing linearly from conception, through requirements, design, code and test..." (Neill, 2004). One of the main assumptions about this method is that the requirements will change very little if at all and that users will not be involved in development or be providing much feedback (Neill, 2004). A really good definition given by Laplante and Neil on this methodology is, "This model of development assumes that requirements are set, stable, and fully evolved before analysis begins, because development progresses linearly through the phases from requirements through system deployment. A phase is revisited only if artifacts created in that phase fail inspection review, or test. If you run into people who dispute this argument, remind them that water doesn 't flow up a waterfall" (10).

The incremental model is an intuitive approach to the waterfall model. Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases. A working version of software is produced during the first iteration, so you have working software early on during the software life cycle. Subsequent iterations build on the initial software produced during the first iteration.

The project will be managed using a modified waterfall technique. In this approach, the initial two phases of the

As the world became more and more dependent on technology with each passing day, software automatically became an important organ for development. Since software is needed almost everywhere today, its development is a highly intelligent and precise process, involving various steps. Known as software development life cycle, these steps include planning, analysis, design, development & implementation, testing and maintenance. These steps go on to create the perfect software for clients. ”

This article by Phillip A. Laplante and Colin J. Neill of Penn State University explores the rumors of the demise of the waterfall model. The Waterfall process model progresses software products linearly from conception, through requirements, design, code, and test (Neill, 2004). The Waterfall method was developed in 1970 by Winston Royce when computer systems were monolithic, number-crunching entities with rudimentary front ends and users’ needs were filtered through the partisan minds of the computer illuminati building the systems (Neill, 2004). Most systems built in that time did not pay much attention to input from stakeholders, which is a good environment for the Waterfall method to work in – an environment where requirements seldom change after specification due to the fact that users are not involved in the development and therefore cannot provide feedback regarding incorrect assumptions or missing features (Neill, 2004).

There is a cross section of projects ranging from a few weeks to a few years. There are also a wide cross section of customers, those capable of articulating clearly their requirements and the ones that are not clear on their requirements and the overall outcome to be achieved. The level of programmers within the Information Technology Department, where development work is executed, range from intermediate to advance or above average programming competence. The Waterfall approach is easier to manage and can be utilized for projects where there are clear requirements and the project is determined to be a long term one. Also, this method may be best suited given the organization’s requirements for thorough documentation and project accountability, when it comes to budget and cost. The Agile methodology can be used for projects where the requirements as well as the expectation from the end product are not as clear. The developers that are above average in terms of their competence can also use this method. In addition, the Agile method is also best suited for the projects that would require rapid

how they should be applied, none have used project data to clearly conclude which one is

The two models for to be considered and discussed in this section are the Business Process Re-engineering and Kaizen models.

The waterfall methodology is one of the most prominently recognized and most utilized methods in project management. Whether you’re using the waterfall methodology to manage a project or in some other fashion, let’s say for example, in software development, it works the same in producing a product – in a sequential manner and design, and in a series of stages that follow each other one after another. This means, once a person completes one step they move onto the next step and not before. As this process is sequential, once a step has been completed, the person cannot go back to a previous step – not without scratching the whole project and starting from the beginning. There’s no room for change or error, so a project outcome and an extensive plan must be set in the beginning and then followed carefully.

I will show what I consider as advantages and disadvantages of the waterfall model in the table below:

The original Waterfall model has a foundation that is supported by two distinct characteristics. First, the methodology is rooted in the fact that that the software be developed in stages. “Originally created by Benington in 1956 and later modified by Royce in 1970, the quintessential Waterfall model is linear and sequential in evolution, typically with milestones at each phase of development. (Pavolka, 2005). As seen in figure 1 (Ruparelia, May 2010), the typical thresholds consisted of Evaluation, Requirements, Analysis, Design, Development, Validation, and ultimately Deployment. The evaluation phase, at the aggregate level, helps to reveal the situation at hand. The requirements phase is arguably the most important phase of the Waterfall plan as it lays out the project statement and sets the framework and expectations for the project. The next phase, Analysis, works as a comparison between what capabilities are needed versus what constraints currently exist. That leads into the Design phase in which the software developers determine the architecture required to meet the customer’s expectations taking into account the constraints previously identified. Development is the next phase that takes the inputs from the Design phase and outputs a tangible product ready for testing. The testing or Validation phase is the process in which the software is checked for two things: a) any and all bugs are identified and removed and b) the original scope of work including all

Due to its characteristics, the Waterfall method has some really good advantages towards it. First of it, the client knows what to expect. After all the requirements gathering and analysis a well estimated project is presented, with a good idea of the size, cost, and timeline for the project. More than this, the client will have a definite idea of what their program will do in the end. Secondly, its meticulous record keeping allows the ability to improve the existing program in the future, and because of waterfall’s strong documentation it allows for minimal project impact when facing an employee turnover. These two main points, predictability and well-documented projects are the Waterfall flagship in an industry that pursue the best cost

The waterfall model consists of five phases such as requirements, Design, implementation, verification and maintenance. The method is a sequential design process where progress is seen as flowing downwards in a steadily manner, each development phase has its own distinct goals. The model is similar to water flowing down a cliff it can only flow in one way and cannot go back up it is the same with waterfall development ,after a development phase is completed it proceeds to the next development phase you cannot go back.

There are many development methodologies for creating information systems. One of the more popular methods, developed in 1970 by Winston Royce, was the waterfall methodology. The waterfall methodology required that a team follow a prescribed sequence of five major steps when developing an information system. The project phases are linear and performed in a very methodical order starting with requirements analysis, then moving to design, followed by implementation, verification, and finally maintenance (see Exhibit A.). This methodology has been in place for many years but the highly structured methodology posed some major challenges. One major problem is when the business users dramatically change the requirements in later phases. This results in major rework and in some cases even project failures. With the advent of the Internet and Web-based technologies, the systems development community needed a more flexible methodology as projects were under greater pressure to deliver systems faster. Then in 2001, a small team of technologists created an iterative agile development methodology which forced systems development efforts to be broken up into smaller manageable timeframes called “sprints”. These iterative sprints contain a set of manageable system components allowing the teams greater flexibility when producing software (see Exhibit B). According to the Agile for Dummies text, “Agile is an attempt to make the process of software development lean and effective, and it’s

Waterfall model: This model has five phase like requirements, design, implementation, verification and maintenance. It is a sequential process. It is originated from manufacturing and construction industries. It is proposed by Royce. This model is series of cascading steps that covers actual development process of the project and has iteration between its steps. The main problem with this model is that rigidity of the model and there is no iteration between any other stages other than adjacent stages. As we all know that web is the fastest mode of developing technology, therefore a model which will automatically adapt to the changes taking place in the environment are to be preferred.