Sergey Galushko - Fotolia
There's no single software development model to follow, though iterative and incremental approaches are becoming norms for organizations. An iterative development model is a way to create software by breaking down the build into manageable components. When a component is completed, the team can move it to test while developers work on other components. Two iterative models of development exist: simple iterative development and Agile.
Both Agile and simple iterative development models differ greatly from Waterfall development. Waterfall earned its name from how a software project moves through successive distinct phases -- design, development, testing and release -- like water cascading down the steps of a waterfall. For decades, all software was built this way, and it suited most development requirements. But times change. Thanks to componentization, for example, software does not have to change at a single pace anymore.
Waterfall teams in search of a faster and more flexible SDLC model should consider a shift to either simple iterative or Agile development. But Waterfall, too, has its place for teams that might not be able to switch to an iterative or incremental model.
So, when should an organization choose Waterfall vs. Agile vs. simple iterative development approaches? Let the nature of the project guide the choice. Each development model has its own types of projects and environments for which it's well suited.
Iterative vs. Agile development
Unlike Waterfall, simple iterative development and Agile are products of componentization and variations of the same approach. Componentization breaks down the notion of a single software project. Service-oriented architecture, microservices and other componentized software architectures enabled development teams to work on distinct components of the overall software, updating a specific feature or capability in line with business needs.
Let's explore the simple iterative development model and what technologies, processes and tools enable an Agile model.
Simple iterative development model. Simple iterative development parallels development tasks but unites the components during the testing phase. Service- and microservice-based design creates components and interfaces at the specification/design phase. Once a development team establishes those rules, component developers can proceed autonomously.
Independent, parallel work in software development tasks isn't new. For example, in the 1990s, when applications consisted of multiple programs, developers often created such programs in parallel. However, componentized services and microservices have made it possible to apply parallelism to almost every application.
In a simple iterative development model, a software architect does the basic structuring and the rest of the team builds it, each having a piece or component. When the project has more resources, the team can complete the application faster, without losing control. Developers do not have to wait on one overall completed project to move on to other work. Therefore, developers are as productive as possible.
Iteratively developed apps are also generally easier to maintain than tightly integrated projects, because the basic structuring rules make it possible to identify what components are involved in any change. Nearly all software developed via Waterfall could, arguably, be built better with simple iterative development.
Agile iterative development model. Agile is iterative development taken beyond the software structure. Where simple iterative development is a way to work with, and apply resources to, a software structure broken into smaller pieces, Agile development is an entire change structure. A change request generates a short sprint to a new release. Each incremental change is an iterative development project.
A simple iterative development model maps changes via the basic structuring that defined the application's components and interfaces. But Agile development assumes that each component is a unit of functionality that developers can treat like a micro-application. The process is straightforward enough:
- identify the feature in need of change;
- pull the component(s) code for redesign;
- make the changes to the codebase;
- test the code changes; and
- reinject the altered code into the production software with a deployment.
Design-code-test-deploy is all iterated at the component or change level.
In Agile environments with a high rate of change, there's a risk that multiple changes collide, and create confusion and chaos. Numerous practices and tools -- such as version control and Git repositories -- coordinate changes and releases.
How to choose a development model
Simple iterative programming beats Waterfall in most every circumstance. However, Agile isn't always better than simple iterative programming.
To decide between Waterfall, Agile and simple iterative programming, reflect on the independence of application features and the pace at which code changes happen.
Independence of features. Generally, if an application's features can be relatively independent of each other and are driven by different business forces, don't develop with Waterfall. Treat the development of each component as a separate coding or change task. Agile is a good fit here. If application changes tend to affect large numbers of components, because useful features require broad changes, then simple iterative programming might be a better fit than Agile, which requires additional changes to the team's tools and practices.
Pace of code changes. If frequent and quick change is necessary, Agile is likely the way to go. Consider social media sites, where features and capabilities are highly modular and managed fairly independently. A rapidly changing and consumer-focused app is the perfect argument for Agile development, but it's a situation that's less common in business software.
Where warranted, Agile development practices can enhance iterative development, and it can become part of the development process gradually. For example, a team can develop iteratively, and add release management and repository tools to support the application lifecycle. The team can then implement automated testing once accustomed to working with the other tools.