Software Development Cycles

We’ve touched briefly on the software development life cycle (SDLC) a couple of times in the course, but let’s really break it down now.

Just as the life cycle of an insect shows us the separate stages in its life - from conception all the way to maturity, the life cycle of software development describes the stages that software applications go through to get from an idea right through to being used and maintained.

You will quickly learn that there are many variations of these stages, but rest assured they are mostly just different ways of presenting the same information.

In the image above we have the SDLC described using 8 stages.

1. Request for proposal (RFP)
2. Requirements
3. Analysis
4. Design
5. Code
6. Test
7. Deploy
8. Maintain

Your organisation may simplify this or add more steps to suit them better, it depends a lot on the size of your organisation and the software development team.

Here is a guide as to what is expected to happen in each of the stages. Remember that there are many different variations of the stages, so some of these things will move around depending on the situation.

Request for proposal (RFP)

This is the first stage of the life cycle, which is sometimes just called ‘planning’. During this phase the project appears on your radar. It could be that a potential client has sent you a ‘Request for Proposal’ (RFP), or maybe the project is internal, and you’ve been sent a brief, or you’ve been invited to a ‘discovery’ meeting.

From the RFP/discovery you will have gained an overview of the project, beginning with identifying and understanding the business need or problem that has kicked all this off.

Now it is time to write up the project proposal.

We won’t go into much detail about proposal writing here, as we have a whole topic dedicated to it further on in the module.

Once you have won the tender with your amazing and professional proposal, you will need to:

• get the right people on board to support the project
• start booking in some meetings to get the ball rolling.

Requirements

Your proposal was accepted by the client, congratulations! Now you move on to the requirements gathering stage.

Before we get started on requirements though, having a contract means now you should start looking at the project planning side of the project. We will discuss this in detail in the next topic.

This step is normally performed by a business analyst (BA) or project manager. Their job is to gather requirements and information describing the problem from the client, document it, translate it from industry jargon, and then present it to the development team. They are the problem-solver, so they need to begin by gaining a very solid understanding of the problem/project.

The development team are not normally in communication with the client; therefore, communication must be a two-way street between the client and the BA.

The BA will begin with a discovery call or meeting with the client, to learn about the problem or business need by seeking more information and understanding from the client such as requirements in:

• function
• integration
• budget, timeline, and scope
• quality
• user experience (UX)
• methodology – waterfall vs agile.

The BA will document the client’s needs in a business requirements document (BRD) and possibly in a functional requirements document (FRD) as well – or it may be incorporated within the first document.

Analysis

The analysis stage is often incorporated into or combined with the Requirements stage above. Analysis is done in 3 steps:

1. Understand the current system/position and its problems.
2. Identify opportunities for improvement/what needs to be changed, enhanced, or built?
3. Create a concept for the solution.

For all projects, the feasibility and long-term viability of the proposed solution needs to be considered seriously before going any further, including a risk assessment. This will be handled differently depending on the size of the project, team, organisation, number of users, and the impact on users.

Design

In the design phase the development team take all the information that has been gathered about the ‘problem’ and the business needs, and they will turn that into a plan, otherwise known as a system design document (SDD). The plan will explain how the proposed software will meet the requirements using two sections: high-level design (HLD) and low-level design (LLD). The HLD outlines the proposed architecture of the system, and the LLD outlines how each page or module of the software will work and what it will do. The design will also need to cover:

• proposed programming language, framework, IDE etc.
• system structure – Unified modelling language (UML) diagrams: structure chart, use case diagram
• functionality, pages/modules
• human-computer interaction (HCI) / user experience (UX)
• how the system data will be gathered, stored, managed, and accessed
• scalability – data management and storage technology must match the application domain and support the development process and the application at launch as well as being ready and able to upscale if needed.

Only once client approval is received can you move on to the next step.

Coding/develop

When the design plan is approved by the client, the building begins. The development team create the software by writing code/programs according to the system design document (SDD) written in the previous stage. This is done by applying architecture, design patterns, services, data structures, tools, and algorithms to meet specifications and software development standards using existing and emerging technologies.

As the software begins to take shape, an accurate and clear technical maintenance manual (documentation for back-end users) and user manual will get written.

At the end of this stage there should be a working app ready for testing.

Only once client approval is received can you move on to the next step.

Testing

Now the testing team begins work to assess how the system performs against client requirements. They’ll be testing for:

• bugs
• load
• speed
• accuracy
• function
• integration

As they find issues, these are raised with the development team, who will fix the bugs/errors and then pass it on to the testing team for more testing, this cycle will continue until it is fixed and working as required.

Once the testing team is happy with the software, it gets passed on to the client for User Acceptance Testing (UAT). Now the client performs their own testing to ensure it meets all their needs as agreed upon during the requirements stage.

Only once client approval is received can you move on to the next step.

Deploy

Let’s roll this baby out! D-day! Go Live! Whatever you want to call it… the software has been designed, written, tested, and now it’s time for implementation and users begin to use the software for its intended purpose.

No doubt, further bugs will be found, especially in the early days. The development team and testing team will be ready for it.

Production support/maintain

The work doesn’t stop there. An excellent software is not something that is stagnant. It is something that will continue to evolve as everything around it evolves, such as:

• operating systems and browsers get updated and change
• new phones/devices are released and need supporting
• business grows and product needs to be scaled to handle more users
• business has additional requirements.

Some of these changes will be so big that the software must go right back to the beginning of the life cycle again to gather requirements, analyse, design, develop, test, and redeploy.

User and maintenance manuals will need to be kept up to date.

Also, at this stage, once the project is complete, it is time to write up your project report. We will have a look at that in the next topic.

It’s important that we keep these in the right order. For just one example, jumping the gun and starting to code before you have the design finalised could result in a lot of reworking.

Throughout this course, and in fact throughout your career as a software developer, you will most certainly find it helpful to keep a blog.

Writing your experiences and learnings down, especially new ones, will help you to remember what you learned, and will be a great reference to return to time and again. Share your blog with others in your cohort so they can learn from you as well, and you from theirs.

Watch Kethmar, a full stack developer from Estonia, explain Why blogging makes you a better developer – learnings after one year (Developer Habits, 2020) [7:47] and then complete the activity that follows.

Keeping up with the latest and greatest

Spend some time now searching for some reliable, exciting, and interesting YouTube channels and blogs (Cressler, 2021) to subscribe to or follow, to help you keep up with exciting changes in this fast-paced industry.

Developer blogging

From the blogs link above, look at 5 or more developer blogs, and write on your own computer ten top tips for yourself about blogging, based on what you observed.

Feedback

Well done, it was worth taking the time to make these observations before you start any kind of blogging yourself. Read Technical Blogging Basics – How to Write Articles as a Developer (Adhikary, 2021) to learn many very valuable tips about writing blogs – some of these you may have observed while you completed this activity and others might be new.

Which blogging platform?

For an advanced blogger, who wants more control over the way their blogs look, WordPress would be a good platform.

However, we recommend you use Google Blogger to begin with, as it is easy to use and free.

When you’re ready go to Create a blog (Google, n.d.) to get started setting up your own blog.

As mentioned in Stage 4 - Design, you will need to put together some diagrams to show how the proposed system will work. You will use UML diagrams, as these provide the standards that you should follow for best practice diagram writing for software development projects.

Begin by watching UML diagram types (Gleek diagram maker, 2021) [6:32] to learn about the 14 different types of UML diagrams for software development, and then answer the questions that follow.

UML diagram matching

There are a few diagrams which are more commonly used, which you should be familiar with. We have listed the top three below, but you will need to match up their descriptions (from the video) with their names.

Read 25 Best UML tools (Walker, 2022), to find out about the features of the best UML tools, some of which are free to use.

The life cycle you use will be affected by many different factors as we discussed earlier, but there still will be a lifecycle. Let’s have a quick look what the life cycle might look like if you were to use one of these two very common methodologies – Agile (Scrum) and Waterfall.

Agile (Scrum) methodology

Using the agile Scrum method, everyone involved is aware and expecting that there will be ongoing agility and flexibility in the workflow to ensure that the business needs are met. The customer is kept involved all the way through the process. The scope and timelines are not quite as rigid as they are under the waterfall methodology.

Here is an example of how the lifecycle might look using an iterative agile methodology such as Scrum. After Sprint 1 the client gets a look at what has been produced so far and can provide feedback and discuss changes, that can be designed and built into the software during Sprint 2. The software is built with this kind of flexibility in mind. There may be several sprints and incremental releases before getting to the final version the client wants to stick with.

For a detailed look at Agile, take a look at Atlassian’s Agile Coach. It is a great resource that covers all the aspects of the Agile method of project management and software development. Take note of the comparison between Agile and the Waterfall method outlined later in this section, as well as the advantages and disadvantages of Agile.

Scrum, in more detail;

Let’s unpack Scrum a little further, as that is the method you will most likely be using the most in your career as a software developer.

Watch Introduction to Scrum (Uzility, 2014) [7:51] to learn about sprints, user stories, product backlog, and the burndown chart, and how they all fit into the life of a Scrum project. Then have a go at the activity that follows.

User stories

In this activity, use what you learned in the video to write three user stories on your own computer for the three users pictured above, based on the scenario below.

Scenario

You are creating a shopping app for the purchase of photos. For the following 3 users, please write two or more user stories to show how each of them will need to use the app.

• User 1 – the client/product owner, she is the one selling the products.
• User 2 – the young man is the photographer, supplying the photos for the products.
• User 3 – the older man represents the shoppers.

Feedback

Everyone’s answers to this activity will be slightly different. What is important is that you understand the function of user stories. Here are some examples.

1. As the owner, I need to login so that I can access my management tools.
2. As the owner, I need my new, unprocessed sales to stand out when I log in so that I can process them quickly.
3. As the photographer, I need to be able to login so that I can upload my new images.
4. As the photographer, I need to be able to see sales of my photos so I can see what is popular and improve what I supply.
5. As the customer, I need to be able to select a product and choose an image to see what it will look like to help me choose what I want to buy.
6. As the customer, I need to be able to order and pay securely through the app.

The Stand-up Meeting

It is a daily team meeting where a semi-real status of the project is given to all team members, possible issues or roadblocks are raised and efforts to eliminate those potentially challenging and time-consuming problems are discussed and planned for. The goal is to identify challenges and deal with them before they develop into serious issues.

Some guidelines or rules for stand-up meetings are:

• Standing not sitting – the standing posture keeps every team member focused and engaged
• Frequency  and duration – same place & time in the morning when team members get to work and before they start working, typical duration of the meeting is 15 minutes
• Agenda – stick to core points, and avoid any in-depth discussion of the issues
• Meetings are not postponed. Every team member is encouraged to attend. The meeting continues even if members are absent.

During the meeting, each team member gets to respond to the following questions:

1. What was completed after the previous day's stand-up meeting?
2. What are the objectives for the present day?
3. What challenges must be addressed?

Waterfall methodology

If the waterfall method is chosen for the project, everyone involved knows there is a fixed budget, timeline, and scope, and that the lifecycle is also rigid so there will likely be only one version or iteration built during that allotted time. Each stage begins only after the previous one is completed. Once you get to the end, it is very difficult to go back and make changes.

Every team will look different, due to the nature, size, and environment of the project, so some roles will occur in one software development project but not others. Here are some common roles.

• Client (client’s company)
• Product Owner /Project Manager
• Business Analyst
• Architect
• UX Designer
• Quality Assurance
• Software Developers/Engineers
• Testers
• User Acceptance Testers (client’s company)
• Users (client’s company, or external).

To complete this topic, watch Software development life cycle in 9 minutes (Testaholic, 2016) [9:13], a video overview of the SDLC which also explains some of the roles involved in a typical software development project, and then complete the activity that follows.

To see what you can remember about the lifecycle stages and team roles you have learned about in this topic, drag and drop the labels to their matching definitions.