7 Software Development Models You Should Know
Software Development Models are integral to the success (or failure) of a project. Here are 7 models you should know, from Waterfall to the V-Model to Scrum.
Join the DZone community and get the full member experience.
Join For FreeThe Software Development Life Cycle, or SDLC, is the process of planning, designing, developing, testing, and deploying high-quality software at the lowest cost possible, preferably in the shortest amount of time. To achieve this goal, software engineering teams must choose the correct software development model to fit their organization’s requirements, stakeholders’ expectations, and the project. There are a myriad software development models, each with distinct advantages and disadvantages.
Details of the project, including timeframe and budget, should influence your choice of model. The goal is to select a software development model that will ensure project success. Selecting the incorrect model will result in drawn out timelines, exceeded budgets, low quality outputs, and even project failure.
Software Development Models
Today, let’s cover seven of the most popular software development models.
Bear in mind that models contribute heavily to the project’s quality, budget, timeline, and the stakeholder’s final satisfaction (or perhaps lack thereof).
1. The Waterfall Model
The Waterfall model was the first approach to software development. As the name indicates, the process involves moving down through the linear development stages in order: analysis, design, development, testing, deployment, and maintenance. Every stage is well defined with specific deliverables and milestones.
The Waterfall model is sequentially linear, meaning the next step cannot begin until the current stage is complete. A stage is complete when the goals are met and someone signs off for the project to advance.
There is no flexibility in this model because you cannot skip, backtrack, or overlap the stages. As a result, adjusting is difficult and expensive. Regardless of when errors are found, they cannot be fixed until the maintenance stage.
This lack of flexibility makes this model more costly and time consuming than other models. If requirements are unclear or misunderstood, this model is very risky.
Additionally, the Waterfall model is not ideal for long, complex, or ongoing projects where more flexibility is required.
Although the disadvantages of this model are prominent and significant, it can be useful for small, one-time projects with few requirements and short timelines because it is simple and can be quickly configured. The team must ensure all requirements are well defined, unambiguous, and fixed.
However, the disadvantages of the Waterfall model outweigh the advantages. Thus, this model has lost popularity as IT teams practice more agile software development, allowing for increased flexibility, communication, and continuous improvements.
2. The V-Model
The V-model, or Validation and Verification model, expands on the Waterfall model with the addition of early test planning. Instead of moving down linearly through the software development stages, the V-Model moves down until the coding phase when it pivots and begins to ascend upward to form a “V” shape.
Each development stage has a corresponding testing activity. This allows the team to detect errors in requirement specifications, code, and architecture early in the development of the project. Unfortunately, fixing errors is still difficult and expensive as there is not a clear path for resolving these problems.
The addition of early test planning gives the V-Model a greater chance of success than that of the Waterfall model. However, the V-Model is still linear, making it inflexible.
Like the Waterfall model, a team can only start the next stage when the current stage is complete. This makes adjustments difficult, expensive, and time-intensive.
Therefore, this model is best for short projects with fixed, clearly defined, documented requirements, but it is not ideal for long, complex, or ongoing projects.
3. Iterative (and Incremental) Model
Like many other software development models, the Iterative (and Incremental) model was developed to eliminate some of the shortcomings of the Waterfall model. Like the Waterfall model, it begins with planning and ends with deployment. Unlike the Waterfall model, this model includes repeated cycles throughout the process.
Like the name of the model suggests, these repeated cycles are iterative (repeated) and incremental (occurring in short periods of time).
The software development process begins with a small set of requirements, and each cycle is accompanied by a new set of requirements. The iterative nature of this model allows the software to continue to evolve and grow as small changes can be made throughout the process as the newest iteration is built off the previous iteration. Developers can make alterations based on the learnings of the previous cycles.
Because all requirements are not outlined at the onset of the project and many changes are made through the process, work can begin quickly. However, resources may be quickly consumed as the process is frequently repeated, not to mention management becomes more complex.
Additionally, although this model allows for some change requests, it is still composed of defined processes which result in inflexibility at times. Even though the cost of changes is less than the Waterfall and V-models, this model is not ideal for projects where requirements are subject to change during the iteration.
The Iterative model can pose more risks with frequent changes, unknown costs and resource requirements, and uncertain deadlines.
4. Prototyping Model
The Prototyping model is centered around increasing the development team’s understanding of the customer’s wants/needs by creating prototypes. By creating a working small-scale replica of the desired software program, miscommunications or misunderstandings can be resolved before full development occurs.
Before developers begin working on the final product, they create a prototype of what they believe the customer wants. The prototype is developed, tested, and refined according to customer feedback. Once the prototype is accepted, the team begins developing the final product.
The Prototyping model can drastically reduce the number of iterations required for the SDLC due to the early customer feedback. This saves time and increases the chances of customer satisfaction.
Although some time is saved, you must take into account the time the developer spends developing the prototypes. If the customer requires many changes, changes their mind frequently, or makes impossible requests, this time developing the prototype can quickly compound. For this reason, it is best to place a cap on the number of iterations allowed before the prototype must be accepted.
When the final prototype is in development, no more requirements or alterations can be made to the plan. This is a significant drawback to the prototyping model
5. Spiral Model
The Spiral Model focuses on risk assessment. As a result, any team looking to use this model must have people with knowledge and skills in this area.
This model has four phases dividing the model into quadrants: planning, risk analysis, engineering, and evaluation. The number of loops in the spiral depends on the specific project and the project manager’s discretion. On average, software development takes 6 months with this model.
It combines features of the Waterfall and Prototyping models by stressing design, including prototyping (in the engineering phase), and by following phases similar to those in the Waterfall model.
Continuous and repeated development allows the developers to make changes and add new features while managing risks. Additionally, development is systematic, which streamlines the process.
The customer is involved to review each stage of the cycle, which can be cumbersome to the development process if the customer is slow or lacking in feedback. However, customer alterations are not allowed during the engineering phase.
Because the number of loops, or iterations, is undefined, there is a risk of exceeding budget and not meeting deadlines. Achieving the final product is often costly and time intensive.
Additionally, the model is highly customized for each customer so reusing your work is impossible.
Agile Methodology
Agile is a methodology based on the 12 principles outlined in the Agile Manifesto. It is a mindset rather than a set of strict protocol.
Agile was developed to deliver better software more effectively and efficiently than previous methodologies, including Waterfall, through a focus on collaboration, communication, and constant change.
The adoption of Agile was swift and continuous. According to the Project Management Institute, “A full 71 percent of organizations report using agile approaches for their projects sometimes, often, or always.”
There are several Agile software development models. These models are focused on teamwork, cross-functional collaboration, iterative development, and early customer feedback. Testing, feedback, and making adjustments allow teams to develop and deliver the best software.
Let’s look at 2 Agile models.
6. Scrum Model
The Scrum model is the most popular Agile model. Its iterations of software development are known as sprints. During these 1-4 weeklong sprints, teams assess the previous sprint, add new features (coded and tested functionality), and plan the next sprint. Changes are not allowed after the sprint’s activities are defined.
After each sprint, new features/items are added to be coded and tested in the next sprint. This occurs until all features have been added and the project is deemed ready for release.
Increased collaboration between cross-functional teams and between the organization and the customer reduces the guesswork and errors that often result from insufficient communication. Additionally, the incremental stages decrease time to market.
Enhanced communication reduces time spent resolving errors and increases the likelihood of the end user being satisfied with the product. However, this collaboration does require more input and time from the customer during the process. If too many features are requested and added, the team risks pushing back deadlines.
7. Kanban Model
Kanban is an Agile model, and the final model we will cover today.
Unlike the other models, Kanban does not have pronounced iterations. If a team does plan iterations, they are incredibly short sprints, sometimes as short as one day.
A Kanban board with sticky notes is used to visually outline the projects and their details, including project owners and progress status. This visualization allows the team to narrow concentration on the most important feature in development at the moment.
Additionally, the Kanban board highlights the room remaining for continual improvement to perfection of features.
Although the method of sticky notes on a board helps motivate the team to focus on perfecting the important task at hand, it is a poor way to define and maintain timeframes. For this reason, planning long projects is very difficult.
Since there is no set planning stage, changes can be made at any time. One common disadvantage of Kanban is the lack of timeframes. This issue can be accentuated if changes are made continually.
The Shift to Agile
Every model was created with the purpose of improving the software development and delivery process. Today, every software development model works well for specific types of projects. However, older manual models, like Waterfall, are quickly becoming a thing of the past.
IT teams, and businesses at large, must move faster and more effectively to deliver software, please their end-users, and keep up with the competition. A faster, repeatable, and more secure software development process is anchored in automation.
This level of automation and speed is not attainable with many models. As a result, the Agile methodology has become increasing popular.
Companies are adopting enabling technologies and processes like continuous integration, continuous delivery, and release automation, and DevOps.
In this webinar, three companies share their experiences adopting more agile software development and delivery processes and implementing DevOps. Watch the recording to see what results they achieved.
Published at DZone with permission of Mallaidh Mleziva. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments