MAINFRAME > Tips & Techniques > Application Development

Four Application Development Methods Have Unique Approaches

Editors note: This is the first of two articles on methods to develop applications. This article discusses frameworks including waterfall, prototyping, incremental and agile. Article two will look at DevOps.

For application software, there’s a lifecycle. It begins with an idea or a list of requirements and ends when the application is replaced or no longer used, i.e., “being sunset.” A key subset of the software lifecycle is the process to create applications called the development process. The development steps can be formal and well defined, often called a process, or more general in nature, called an approach. The term framework is also used in both relaxed and more formal ways.

There are many different processes, approaches and frameworks that support software development. They have names like waterfall, prototyping, incremental, spiral, rapid, extreme and agile. They are all related to one another in subtle ways. Each alternative can be discussed by explaining its basic operation and principles, as well as its “fit” for certain kinds of projects based on a number of factors. Consider these three dynamics:

  • Team maturity and experience: Some approaches work better for less experienced teams whereas others require expert teams
  • Organizational participation: Some frameworks are a good fit for organizations that choose to have high organizational participation whereas others work best when teams are autonomous
  • Project size: Some processes favor minor efforts whereas others are best for large and complex projects

These factors aren’t the only ones to consider and the above brief discussion doesn’t include any mention of the importance of one over the others as this is relative to the organization. For example, it’s recommended that an approach like waterfall is a good fit when the team is inexperienced since this method fosters participation from the organization to offer guidance, input and help when needed. Nevertheless, some organizations with highly experienced teams use waterfall because it matches the organizations’ preference for a high degree of participation and involvement.

Waterfall Was an Early Method

The main ideas behind the waterfall framework were borrowed from engineering and applied to software development because it was clear from the beginning that the complexity of software development could benefit from an orderly approach. The hallmark of waterfall is a sequential development approach going through several phases with names like requirements, design, coding, testing, integration, installation and maintenance. With this approach, the important aspects are careful planning, managing time schedules and dates, and keeping to the budget for an entire application or business system.

This framework was useful then and is still useful today although many organizations are moving or have moved away from waterfall. It’s still a good fit for less experienced teams or teams whose composition fluctuates because, by design, the team gets help from the broader organization through the life of the project. It’s attractive because of its focus on order and predictable progress. Waterfall is sometimes used in conjunction with other methods like prototyping so it’s flexible enough to accommodate hybrid approaches.

Waterfall projects can be easy to measure by proven metrics like tracking planned versus actual task starts and completes from a comprehensive project plan. It’s a known pitfall that it’s easy to start tasks and harder to complete them so keeping an eye on the revised “estimated hours to complete” for tasks is important for the project manager.

Waterfall does have its weaknesses. Project controls like reviews, meetings, documents and reports can result in high development costs. The time gap between design and testing phases means problems in design can be found well after the design phase is completed. Also, design specifications aren’t always useful to users and stakeholders.

Prototyping Evolved as a Fix

The idea behind the prototyping approach is to create a partial version of the software application. This technique can result in breaking the large application into smaller parts involving one or more prototypes, with the goal of reducing risk. This approach often utilizes high user involvement, which can improve the eventual acceptance rate of the system. The iterative approach used with the prototype can reveal subtle but necessary dimensions of the application’s processing and use. Prototyping can be mixed with waterfall or other development methods, as you probably don’t want to prototype a complete application.

Prototyping is best used when handling a selected part of a larger project. The “show me” approach with prototyping is better than “tell me” for many users in getting their requirement out in the open, thus improving user participation and acceptance. With prototyping, the final design might be more innovative when given the time and effort to explore new ideas.

By design, most prototypes are discarded, as their purpose is mainly to develop look and feel, and basic flow and processing, and to reveal additional processing details. Sometimes there is a lack of strictness with actions like approvals which may introduce problems. Also, prototyping may present the situation of frequently changing requirements and iterations that may lead to high expenses. The use of “time boxes” is one technique that project managers use to help manage the time dedicated to prototyping activities.

Incremental to Tackle Big Applications

Think of the incremental framework as a sequence of small waterfalls, each for a logical part of the application combining linear (i.e., waterfall) and iterative (like prototyping) at the same time. Why do this? Practitioners say that it lowers risk by developing the application in smaller units like application components or subsystems. With an incremental approach, you generally have the flexibility to handle requirements up front or as part of each development segment.

There are some straightforward benefits of incremental, including:

  • Each mini development cycle can learn from the previous so design mistakes are reduced.
  • From the project manager’s point of view, controlling the project is less onerous.
  • Project reviews by management can also be more straightforward.

One potential downfall of incremental is that designers and developers may be less focused on the big challenge being addressed by the overall system because their attention is on the current component being designed or developed and tested. Just like it’s easier to start than end a task, it’s hard to resist moving the tough components of an application until later in the project to improve the odds of some early success.

Agile: A New Direction

Agile is a group of methods. Most agile methods strive to integrate business and IT through collaboration. They combine small parts of the application through iterative and incremental developing often using self-organizing and cross-functional teams. The methods use time boxes to manage time and move quickly, called a sprint. Teams not only do things rapidly but also provide a flexible response to change. Many sustain often daily interaction between developers and customers.

Agile has many benefits like an emphasis on customer satisfaction and flexibility regarding change. Frequent communication and interaction with customers improves the usefulness and quality of the application. Building the application components or subsystem one at a time utilizes frequent testing, which means lessons are learned early rather than later as compared to waterfall.

There is the potential for change to happen too frequently. Sprints can create documentation gaps, as writing is likely to suffer when time is exhausted. The process can be rough and tumble and teams can appear like they aren’t organized. Also, team members need to be motivated and skilled, otherwise progress can stall.

Each Has Own Idea

The development methods that have been discussed have their own main ideas yet there are powerful relationships between them. Some approaches work together like waterfall and prototyping whereas others are motivated by a strong contrast like agile as a reaction to waterfall. Because of this vibrancy and these motivating relationships, these methods will be used for many years to come.

In the second article in this series, I will explore DevOps, which is a kind of agile method that links software development with administration and management of the resulting application.

Joseph Gulla is the IT leader of Alazar Press, an imprint of Royal Swan Enterprises. Previously, he was an executive IT specialist at IBM ending his 28-year career with the company in August 2012.

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

A Beginner's Guide to the REXX Programming Language on z/OS

Reading and Writing Files in the REXX programming language on z/OS.


Application Management is Important to the Entire Process


Application Testing: Giving Users What They Need

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters