The software lifecycle

Written Explanation

The seven stages

Here are the stages in the order they first happen.

Different books and companies use slightly different names and sometimes split or merge stages. Wikipedia, for instance, notes that the phases of a development process are not always strictly separated and that simple projects may combine or overlap phases. The seven names above are the ones this course uses. If you see "implementation" for build, "deployment" or "deploy" for release, or "maintenance" for operate and change, they are close cousins.

Stage 1: Requirements

Before anyone writes code, the team needs to know what is needed, and for whom. This is the requirements stage.

Good requirements say what the software must do, in words the users and the team both understand. For a food-ordering app:

• "A customer can see the menu of a restaurant."
• "A customer can place an order and pay."
• "A restaurant sees new orders within a few seconds." (Notice how a requirement can include how fast something should be.)

Requirements also cover limits: how many users, how safe, how much it may cost. They come from talking to users, the business, and other teams.

A frequent trap: requirements that are not clear. "Make the app better" cannot be tested or built. "A customer can reorder a past order in two taps" can.

Stage 2: Design

Design answers: how will it work? Before building, the team plans.

For a backend, design includes decisions such as:

• What pieces are there (a mobile app, a website, a backend, a place to store data)?
• What data is stored, and in which form?
• How do the pieces talk to each other?
• What happens if something fails?

Design does not need to be a giant document. It can be a sketch on a whiteboard. Its purpose is to find the big mistakes while they are still cheap to fix: moving a box on a drawing costs nothing, while moving it in finished code costs days.

Stage 3: Build

In the build stage, programmers write the code (the instructions from the first lesson) and prepare it to run. This is what most beginners picture when they think of software work.

Building includes more than typing code: it also means organizing the code, reusing existing tools and libraries, and keeping the work saved safely (you will learn version control with Git later). In this course, you will spend a lot of time here.

Stage 4: Test

Testing is checking that the software does what the requirements say, and finding problems before users do. Testers and developers try the normal cases and the unusual ones: "What if the basket is empty?", "What if the price is negative?", "What if two people order the last item at the same moment?"

A defect (also called a bug) is a difference between what the software does and what it should do. Tests may be run by people, or by other programs written to check the software automatically; both are common.

Testing can show that problems exist; it cannot prove there are none. That is why teams keep testing and keep watching after release.

Stage 5: Release

Release is the moment the software is made available to real users. For a mobile app, that may mean publishing a new version in an app store. For a backend, it means putting the new instructions onto the servers and starting them (this is often called deploying).

Release can be a big event, with a specific date, or a small routine step done many times a day. Either way, it is where the software leaves the team's hands and meets real people and real data.

Stage 6: Operate

Operate means keeping the released software running and healthy, for as long as people use it. For a backend, this is where the lesson on services applies: the service must stay up, answer quickly, and keep the data safe.

Operating includes:

• Monitoring: watching signs that the software is working (is it answering? how fast? any errors?).
• Fixing: dealing with problems and failures as they appear.
• Maintaining: updating the software, the servers, and the tools it depends on.
• Listening: collecting what users report and what the monitoring shows.

This is typically the longest stage. A piece of software may be operated for many years after it was built.

Stage 7: Retire

Software does not live forever. At some point, it is replaced by a new system or no longer needed. Retiring means shutting it down on purpose and doing so safely:

• Telling users in advance.
• Moving the data that still matters to its new home, or deleting what must not be kept.
• Switching off the servers, and cleaning up so that nothing keeps running or costing money without reason.

Retiring is often forgotten. Old services that nobody owns anymore, still running, still holding data, are a real problem in many companies.

The lifecycle is a loop

If the lifecycle were a straight line, it would stop after release or after retire. In reality, the middle of the story keeps going around:

   Requirements -> Design -> Build -> Test -> Release -> Operate -> Retire
        ^                                                  |
        |                                                  |
        +------------ feedback: bugs, new needs -----------+

After Release, the software is operated. In operation, real users find bugs that tests missed, ask for features, and use the software in ways nobody expected. Those findings become new requirements and the cycle runs again, perhaps for a small fix or for a new feature. The loop ends only when the software is retired.

That is why "software is done once it is released" is wrong. Release is the beginning of the part where the software is really used.

Different ways of organizing the stages

All teams go through these activities, but they arrange them differently. Some do each stage once, in order, for a large project (often called the waterfall style). Others use many short cycles, in which a small piece goes through requirements, design, build, test, and release in days or weeks, and then they repeat (agile methods are examples). The course's later modules touch on this. For now, remember: the stages are activities, and a team can do them in big steps or in small, repeated cycles. In the small-cycle style, the loop turns fast.

Why early checks are cheaper

A principle that guides much of software work: the later a problem is found, the more it costs to fix. Picture a mistake in the requirements, such as forgetting that orders must be paid before the restaurant sees them. If caught at requirements, you change a sentence. If caught at design, you change a drawing. If caught in build, you change code written so far. If caught in test, you change code and its tests. If caught by customers after release, you also have unhappy customers, possibly wrong data, and an urgent fix.

I describe this as a general principle based on common experience in software work. I did not find a specific number in the sources I checked, so do not quote a figure for it.