Software Life Cycles and Kitchen Sinks

The software industry has matured over the years. Don’t get me wrong—there is still room for significant growth, development, and improvement in almost every area where software is useful. However, compared to a decade ago, most of the software tools for important business and home applications are sophisticated, easy to use, and stable. One can write a novel, publish a newsletter, organize a photo album, or maintain a home budget and checkbook with relative ease nowadays. In fact, there is software for almost any application you can conceive. The software that most people are familiar with was designed to be installed and operate on a single computer (for example, Microsoft Word).

Another class of software is often referred to as “enterprise software.” Enterprise software is software that is being used for central and/or mission-critical business applications by users who play a variety of different roles and are located in many different locations. For example, the software that tracks customer complaints at a national cable company would be “enterprise software.” The process of choosing and installing enterprise software is far more complex than simply installing an application on a desktop. The enterprise application often must interoperate with a variety of different software systems, from very old legacy systems to new systems. In addition, software workflow considerations may not only affect individuals, but may have cascading effects on hundreds and thousands of workers, creating measurable changes (either positive or negative) on productivity. For these reasons, companies often create exhaustive evaluation processes for the purchase of enterprise software. Sometimes, they choose to develop the software themselves, either internally or with the help of consulting firms.

In all cases, the development of high-quality software—from desktop to enterprise—requires a mature, well-thought-out and carefully followed Software Development Life Cycle (SDLC) process. The SDLC is the process by which the conceptualization, planning, and building of complex software are coordinated. Enterprise software demands the use of an SDLC because of the complexity of the system and the business risk of poorly implemented software. Furthermore, regulatory requirements in the pharmaceutical industry require an SDLC for the development, maintenance, and retirement of software used in the collection and analysis of regulated data. The SDLC may seem an unfamiliar concept to the uninitiated, but it is not unlike the planning and development process for a home renovation.

Kitchen woes

Home renovations are on my mind a lot these days, mostly because I am currently living through major renovations of my kitchen and family rooms. Each night, as I eat my microwaved dinners off paper plates, I get to discuss the progress of our project and think about a day when I won’t have to wash my dishes in the bathroom sink. Despite the relative chaos that this has created for my family and me, I can see clearly that our contractor is following a carefully coordinated and planned process.

When we first began to work with our contractor and his architect, we started with our requirements. The architect listened and interpreted, often taking our fixed concepts and turning them into general requirements. After much discussion, questions, and answers, the architect had a pretty clear idea of what we were looking for and created a plan. The initial plan was at the highest level, without certain specifics (for example, the location of the light switches, or even the specifics of lighting). We worked with this plan for a while, fine-tuning it until we were satisfied. We knew that some aspects of it might change at a later date, but we accepted that this would be at an increasing cost to us—knowing that the further along in a project, the more costly the change.

At a certain point, the design was complete enough to begin building. There were many details that were not yet decided—the color of the paint, the type of pulls to be used on the cabinets, among others. However, we knew that these details weren’t required at first, and would be decided with some “prototyping” at a later date (like trying a few swabs of different paint color on the walls). We still tested the plan in our minds, walking into rooms and turning on lights, moving food between the kitchen and dining room, to validate that the design worked. We also envision what the completed project would look like. Although we didn’t write it down, we know what we will look for in the completed project to determine if it was built correctly. Do the dishwashers work? Does the refrigerator make and dispense ice cubes? Can all the cabinet doors open and swing properly?

The architect used the design that we created to develop detailed specifications for the installation of plumbing, lighting wires, cabinets, and everything else. These were at a level where the builder could develop materials lists and a project plan for coordinating the work of the plumber, electrician, plasterer, and cabinetmaker. Each of these subcontractors checked the designs carefully, and coordinated as needed, to make sure that their work would mesh with that of the others. All of this detail was done without our participation or knowledge. As “end users” of the kitchen, we didn’t need to know much of the detail of its construction.

As each step of the project was completed, it was tested to make sure that it met our initial requirements and the specifications of the builder. Sometimes a building inspector would actually need to sign off on a particular phase before work was continued. Over the next month or so, the project will be completed. We will have the opportunity to test the final kitchen and decide whether it meets our specifications or not. Any defects that arise after this will hopefully be taken care of by our builder. However, standard maintenance will be our responsibility. At some point in the very, very distant future, we may even decide that the kitchen is old and in need of renovation again. At this stage, the entire life cycle of the kitchen will have run its course and the life cycle of a new kitchen will begin.

From homes to software

Software development indeed shares many aspects of the kitchen design and build process. In fact, some of the language of software development derives directly from the construction process (for example, the job title software architect). Despite the similarities between construction and software development, one difference is important to note. In construction, the design and testing processes are relatively short compared with the construction itself. In software engineering this is reversed. The design process is typically quite long and involved compared to the final development stage.

Although simple software can be “hacked” together by a single individual, most enterprise software requires the closely coordinated effort of teams of individuals, each working on different aspects of the project, with a similarly sized team for documentation and quality assurance. Without a carefully coordinated SDLC, it would be very difficult if not impossible to create software that does what it is supposed to do and can be validated. Software used in the conduct of any FDA requirement must, by definition, use a high-quality SDLC, and be fully validated.

As with the building of a house, the development of software begins with a requirements phase. Those responsible for the development of requirements must listen carefully to real users of the products, understand, and even observe the workflow of the process being automated. Often the end users will not understand how to translate their needs into a systematic requirement, nor will they have fixed ideas about how they want the software to look. The requirement gatherer must sift through much of the information and develop requirements that are specific enough to base the design of a system on, but not too prescriptive. These requirements must be checked and tested with the end users for feasibility, completeness, ambiguity, and consistency. A final document should be the agreed upon requirements for the software—to be used for checking against the end result. This document is similar to the high-level design drawings of the architect. Although these requirements may change during the software building process, changes come at a cost of time and increased expense. Again, the later in the process a change occurs, the greater the cost.

Once the requirements are complete, the software team will begin a detailed design specification, much as the construction architect went from high-level drawings to detailed wiring, plumbing, and cabinetry plans. In developing a specification, the software architect makes many decisions about what functionality will be contained in each of the different software modules and how these modules interact. The specification document will form the basis of the test plan for unit and final testing of the software.

Following the agreed upon design, the software will be implemented—the actual software code will be written and the various modules will then be integrated together. Each individual unit or module will be tested, and the overall integrated product will be tested to make sure that it works as specified. Once the project is completed, it must be accepted by the end users, often through another series of practical tests. It will then be installed and deployed in production.

As with a house, over time the software will require continued maintenance during operation, which may be as simple as changing an installation parameter, or as complex as rewriting some of the code. Finally, the software will eventually reach an end of its usable life, at which point it will likely be replaced by a new product. The life span of software may be brief (like that of a Web browser) or very long (as in the case of some COBOL-based banking systems from the 1960’s that are still in use today).

The Waterfall

The SDLC model described above is commonly referred to as the Waterfall model—each step takes input from the previous step and produces output that is used by the next step. The development of the software flows from step to step like a waterfall. The steps are:

• Requirements
• Analysis
• Design
• Coding
• Testing
• Acceptance
• Installation
• Deployment
• Maintenance
• End-of-life.

Although the Waterfall development is quite straightforward, it doesn’t work well in the current world of rapid application development and complex projects. Waterfall development works best when the user starts the process by specifying requirements, but isn’t involved thereafter until final testing. In addition, it is a relatively inflexible model that limits the ability to predict timing of a project and resource requirements. As in the renovation of a home, there needs to be much back and forth, changing of requirements, and modification of design specifications during the design-and-build process. The Waterfall method works best in an environment where change occurs rarely, so that portions or stages of a project can be completed, closed, and not reopened. For this reason, a number of other theoretical models have been developed.

Alternative models for SDLC

One commonly used alternative to the Waterfall method is a rapid prototyping method. Using languages and tools that make it possible to quickly assemble an application, the programmers can develop one or many prototypes to test requirements and specifications. Users interact with the prototypes, suggesting modifications and improvements. When all prototyping is completed the prototypes are set aside and the code is completely rewritten in a more robust environment, often using a version of the Waterfall methodology. A risk of rapid prototyping is that some aspects of the prototype may be too difficult or expensive to build as part of the final system. The user may have to accept less functionality from the final system than the prototyped one.

Prototypes can be illustrative prototypes, which can be nothing more than a mocked-up Web page or even storyboard. Other prototypes are functional, which can actually deliver part or all of a working system or part of a system. A major risk of functional prototypes is the temptation to incorporate the rapidly developed prototype into the final system, sacrificing quality and integrity of the process and product.

The SDLC methodology known as the Incremental model assigns requirements to a particular section of the software. The sections are each built to completion and tested individually, beginning with the highest priority module. As each module is added on, the product takes on more and more functionality. Both Microsoft and Netscape manage huge projects with a related methodology using a Synchronize and Stabilize method whereby the entire project is built each night from the currently completed modules. Incremental models allow for adaptation to changing requirements through user interaction with the partially completed software.

Another methodology that is related to the Incremental methodology is the Spiral model, whereby the modules that have the highest risk inherent in them are prototyped. As these are completed, risk is reassessed and the next highest risk module is prototyped. As more and more of the software is completed, the process becomes more straightforward and carries much less risk, until the final software is built from the prototypes.

There are many, many more models of SDLC methodologies, including the V model, Sawtooth, Shark’s tooth, and others. The most radical is Extreme Programming (XP) wherein the software is rapidly built from user “stories” without formal requirements, through an iterative process. Programmers work in teams of two on discreet parts of the software—providing rapid and high-quality development. This form of SDLC requires a highly committed team with ownership and knowledge. It works well for first-time products in start-up companies.

Back to basics

In simple terms, all of the SDLC models are different variations on making sure that software is properly defined at the beginning, properly built, properly tested, and properly implemented. In the end, the use of any SDLC methodology creates a process that ideally is predictable, repeatable, measurable, and efficient. Through the SDLC we get a high-quality process for the development of high-quality products that can achieve regulatory compliance. In software development and in GCP, the requirements of a fixed process can bring order, but can also suppress innovation and quality in favor of structure. As in the building of a new kitchen, it is essential that everyone involved consider what they are doing, and for whom, throughout the project. Despite the many pressures to complete the software on time and on budget, each participant must be ready to question, reexamine, and modify the process and product to deliver the best quality result.