The Application Lifecycle Explained

The Application Lifecycle describes all of the different activities that go into making a software application, and it is unfortunately still quite poorly understood - even among people who have been making a living in the software industry for decades. Sometimes, if you’re the kind of person who considers themselves a “Hacker” this is intentional and not necessarily a bad thing. But for everyone else, here is a short overview of what you need to know.

Five Main Activities

In Software Engineering there are 5 main activities that together make up the application lifecycle. You might recognise this drawing, describing the following activities:

• Analysis - What is the problem we are trying to solve?
• Design - What is the best way to solve this problem?
• Implementation - Building the solution.
• Quality Assurance - Validation that the solution actually solves the problem, and conforms to the design.
• Application Management - Placing the necessary support structures around the software, and maintaining it until the software is retired or replaced.

Analysis

Analysis is where it all starts. Analysis uncovers requirements and describes the problem domain. Now because software engineering is a “Garbage in, Garbage out” process, a strong case can be made that analysis is the most significant activity in the application lifecycle, because it sets the bar for the highest possible correctness for the software. Unfortunately, because most people think they know what they want, this is also often the activity that least time is spent on. In my opinion, this is the primary reason why so many IT projects fail catastrophically.

Design

Software design is the activity that traditionally follows analysis. Software design is figuring out how different requirements impact each other, and how to best address different kinds of concerns, and resolve problems. Software design is quite a mature discipline and we have a large toolbox known as design patterns at our disposal for effectively designing software. This is good, because design activities generally have significant impact on the quality and maintainability of the resulting software.

Implementation

During the implementation activity, engineers work to turn requirements and software design into functional software. Implementation is generally (and incorrectly, but I’ll get back to that later) perceived as the activity that takes up the most time, and is seen as the activity which creates most value for money. It seems intuitively obvious that this is the case, the more you code, the more functionality you get. Of course this is not necessarily true, it is a bit like saying that people who read a lot are smarter, than people who don’t, and while this rings true, it depends on which books you’re reading, and how many times you’re reading them. Reading “The Secret” a million times, will not make you as smart as reading “The Demon-Haunted World” once. However an in-depth discussion of doing the right things and doing things right is beyond the scope of this article.

Quality Assurance

Quality assurance is the activity of verifying and reviewing everything else, although usually it is only practiced with regards to the actual software, and it is also unfortunately often one of the first places to cut corners when it’s crunch time. Testing, or more correctly, the lack of testing is the close runner-up for why so many IT projects fail. If the analysis was great but testing was done haphazardly, then ultimately you will still end up with less correct software. Conversely if the analysis was done poorly, verifying the actual software is mostly pointless, as nobody knows what the software is supposed to do, besides that which it incidentally does so it is correct by default. Never let your software become the specification.

Application Management

Application management is making sure that the software continues to work, in an ever changing world, and keeping your software up to date. The actual things which need to be done depends on what kind of software you have, but in general a good analogy is that, much like your car or your teeth, your software needs regular maintenance to combat entropy. With software however, you also need to consider the security aspect of protecting your users against new security vulnerabilities that are being discovered every day. The CVE lists more than 15.000 known vulnerabilities discovered in 2018. How many are you exposed to because your software hasn’t been patched or updated?

The Inconvenient Truth

In the introduction I showed you a drawing, that drawing is a lie. The actual drawing should probably look more like this:

In other words, as a function of time, analysis and design activities are measured in months, implementation and quality assurance is measured in years and application management is measured in decades. Some of you might say that the above illustration is useless, because it seems to indicate that everything else in the application lifecycle is dwarfed by application management. This comes as a genuine surprise to many people, so now you can plan for the future. This is fairly counter intuitive because while a new oil filter in the car now and then is an expense, it is by no means over the lifetime of a car, more expensive than buying the car in the first case. Of course the reason for this is that car thieves don’t discover 15.000 new ways to steal or destroy your car every year. Now I know you’re thinking that no software exists for decades, and my counter argument would be that you’re reading this on LinkedIn, a company founded on the 28th of December 2002, literally 16 years ago as of this writing. Now that we know roughly how much time each activity takes relative to its others, we can start estimating it’s cost, based on the old adage that time is money. Of course some activities require more highly skilled individuals, whose hourly fee will be higher, so it’s not an exact model. But it is a pretty good measuring stick for how much trouble your software project is in, if your budget only covers the Implementation activity, which is actually a quite small percentage of the overall lifetime cost of software. Generally there are three different ways to build software, the classic dilemma is usually written as “Good, Fast, Cheap - choose 2”, so how does that affect our software development costs? The following three paragraphs explain how costs are distributed, based on your priorities. In the following diagrams, each box represents roughly a week, but it can be more or less depending on the relative complexity of the problem we are trying to solve, what matters is proportionality.

Fast And Cheap

The fastest and cheapest way to develop software is using an ad-hoc approach to development often simply called “Code and Fix” for reasons which shall become obvious shortly.

As you can see from the diagram, almost the entire budget is spent on implementation and maintenance. Now because maintenance is, over the lifetime of the application the most time consuming, the consequence of this is that the maintenance costs quickly skyrocket to the point where the software is abandoned or rewritten from scratch. Most software in the world is developed in this fashion. By a huge margin.

Fast And Good

If you want to trade cheap for good, then the way to go is the phase-gate or waterfall model. This method was pioneered during the Apollo program, so it has pedigree like nothing else, particularly if you ignore the Apollo 1 disaster. Nevertheless, the phase-gate model put a man on the moon in only 8 short years, fulfilling JFK’s promise, even if it was at a tremendous cost.

As you can see from the diagram the budget is split fairly evenly across all activities, which results in much lower maintenance costs, and more time spent on Analysis and Design means that less time is wasting coding things that are incorrect, likewise the additional emphasis on Quality Assurance means that much less time will have to be spent fixing bugs.

Cheap And Good

If you want to trade fast for cheap, then the way to go is using agile and lean principles. Inspired by Taiichi Ohno’s “The Toyota Way” of eliminating “waste”, Jeff Sutherland and Ken Schwaber Scrum is still relatively new, being pioneered at the same time as large scale enterprise applications emerged. The most publicised success story is the FBI “Sentinel” project.

As you can see from the diagram, the main differences between the agile and the phase-gate model is less reliance on up front design and up front analysis in exchange for customer feedback and additional testing. This feedback and additional testing translates into a shorter turnaround time when errors are discovered or when change requests are needed as a response to changes in the market.

What Do We Do Now

Now you should have a good idea of the application lifecycle, how your budget should be distributed depending on the relative quality, relative price and relative time-to-market of software you want, as well as the long term impact of IT projects. If you need any kind of assistance evaluating the viability of any given IT project, feel free to contact Acto.