Software Development Lifecycle (SDLC)

The Software Development Lifecycle (SDLC) provides a framework for discussing the process of creating high-quality software. It’s broken down into different stages, each of which involves people with different roles and responsibilities. The exact format of each stage can vary a lot from project to project, but the framework helps to ensure that we have a common frame of reference for the activities. Organisational policies and procedures should be considered throughout the whole lifecycle in order to keep standards high.

Seven stages of the development lifecycle

There are seven stages of the SDLC. They are:

1. Feasibility study
2. Requirements analysis
3. Design
4. Development
5. Testing
6. Implementation
7. Maintenance

By defining the typical responsibilities, activities, and outputs of each stage we can be confident that a project is happening in a sensible order, and we can communicate that easily to internal and external stakeholders.

Feasibility study

Before we spend money developing software, we should conduct a feasibility study.​ This is a cheap way to determine how likely a project is to succeed.​ A feasibility study includes domain analysis, technical feasibility, financials, and risks and assumptions.

Domain analysis involves understanding the business we are building software for and how it operates. This involves researching what sets it apart and identifying its needs and pain points. This helps in aligning the software solution with the specific requirements of the stakeholders and the users.

Technical feasibility involves researching if the proposed idea is technically feasible and identifying any potential risks. This may involve exploring available tools and libraries and prototyping a small part of the system.

Financials play a crucial role in determining the viability of the project. This includes conducting a cost-benefit analyisis by estimating the costs, benefits, and time predictions.

Risks and assumptions need to be thoroughly analysed and documented in a risk report. This includes:

• Describing the nature of the risks
• Rating their likelihood of occurrence
• Identifying potential impacts
• Identifying mitigation strategies to avoid or lessen the impact of the risk

A combination of these analyses allows us to form a business case which is the output for this stage. This includes a detailed report and a short presentation of the findings of the feasibility study as well as a cost-benefit analysis (see below). This is distributable to wider stakeholders and allows senior managers to assign and prioritise projects more effectively, which helps avoid wasted effort and cost.

Cost-benefit analysis

A cost-benefit analysis of the product should be undertaken. This involves:

• Calculating the cost:
  • Think about the lifetime of the project – costs change over time
  • Direct costs like annual licensing, consulting fees, maintenance costs, tax…
  • Indirect costs like training, expenses and facility expansion, labour…
• Calculate benefits​:
  • Possible benefits – productivity, ​cost savings​, profitability​, time savings​
  • Value of intangible benefits as well as those that have a monetary value​
  • Speak to stakeholders​ to work out their benefits
  • Often easier to estimate % increases​ e.g increased output, reduced inventory costs, improved time-to-market
• Incorporate time:
  • How far do you project into the future?​
  • What is the return-on-investment period?​
  • Optimistic and pessimistic projections?

An example cost-benefit analysis for a gym mobile app might be:

Costs:​

• App development: £250,000​
• Training: £50,000​
• Total: £300,000​

Benefits:​

• 1 fewer receptionist needed at peak times (x 100 clubs)​
• 3 hours / peak-time-shift * £10/hr * 100 clubs = £3,000/day​

Break-even:​

• App build: 3 months​
• Time to pay off (once up-and-running): £300,000 / £3,000/day = 100 days​
• Total time to break even: 6-7months

Requirements analysis

After deciding that our idea is feasible, the next stage is to find out, in detail, what the stakeholders want. This is done by business analysts and is split up into three stages: requirements gathering, requirements prioritisation, and requirements specification.

Requirements gathering

You might think, to gather requirements, we just ask the stakeholders what they want but requirements can come from several places, including:

• The stakeholders –​ the people, groups, or companies with a vested interest, or stake, in the software
• The users –​ the people who will actually have to use the software​
• Regulatory agencies/regimes e.g. GDPR

We should try to gather requirements in terms of the business need, rather than in technical terms.​ We can then combine these requirements with our knowledge of software to design a good end product. These are a mixture of functional and non-functional requirements.

Functional requirements specify a behavior or function, typically in terms of a desired input or output:

• Supports Google Authentication
• Has an administrative portal
• Usage tracking​
• Metric collection​
• Business Rules

Non-Functional requirements specify quality attributes of a system and constrain how the system should behave​:

• Performance​
• Security​
• Usability​
• Scalability​
• Supportability​
• Capacity

Requirements prioritisation

There will almost always be more requirements than we can budget for!​ We need to help the stakeholders work out which of their requirements is most important to achieving the business goals​ and what is the minimum we could build that would enable them to launch a product.​ This is called a Minimum Viable Product (MVP).

Requirements specification

After the requirements have been prioritised, a specification is written. This needs to be written in enough detail that the designers and developers can build the software from it. This is a formal document, and should be written in clear unambiguous language, because it is likely that stakeholders will need to approve it and all developers, designers and stakeholders need to be able to use it as a reference.

Design

In the design phase, we take the requirements specification from the previous phase and work out what to build. This includes designing the system architecture and the User Interface (UI).

System design and architecture

System architecture defines the technical structure of the product. This is where the technologies used are defined, including what programming language and frameworks are used. It encompasses the connections between all the components of the system, their structures, and the data flow between them.

A system architecture diagram can be used to display the system architecture. This visually represents the connections between various components of the system and indicates the functions each component performs. An example of a gym app diagram is shown below.

It displays what the components are and how they interact, as well as which part of the system the users interact with.

There are other aspects of a system that should be considered at this point; which of these are needed depends on the particular project but may include the following.

• I/O design: this addresses how data enters and leaves the system, including for example data formats and validation
• Data design: the way that data is represented, for example, the entities, relationships and constraints that will form the database schema
• Security and control design: this needs to cover data protection and access, security requirements and auditing and legislative compliance

Another output of the system design phase is a code specification: a low-level, detailed description of how each feature will be implemented. A quantity of feature tickets (in Jira, Trello, etc.) can also be written at this stage.

UI design

UI design is the process designers use to build interfaces in software, focusing on looks or style. This involves:

• User personas –​ created representations of the target users, which help the development team gain a deeper understanding of their needs, preferences, and behaviors.
• User journeys –​ describe the end-to-end experience of users with the system, taking into account their personas and guiding their interactions with the software.
• Prototyping –​ involving the creation of sketches, wireframes, and mockups to visualise the user interface and interactions. These prototypes serve as early iterations that allow for testing and feedback from users, helping to refine the design and ensure it aligns with user expectations.
• High-fidelity designs –​ the final polished versions of the user interface, with a clear direction and behavior that meets user and stakeholder expectations.

Recall your experience of this process in the mini-project planning exercise during Bootcamp. It would be worthwhile reviewing your process and results from that exercise.

Functional vs technical specification

Once you have reached this point in the project planning you will have produced both a functional specification and technical specification of the software that is to be built.

A functional specification defines what the software should do – this would be comprised of the UI designs and feature tickets describing how features of the system should behave.

A technical specification defines how the software should be built – so this comes from the system architecture and other technical designs and the code specification.

Development

This stage you’ll know all about! The development stage of a software project aims to translate the feature tickets (in Jira/Trello/etc.) and designs into ready-to-test software.

Note that as per the discussion below under Methodologies, the Development and Testing phases often overlap. This is especially the case in an Agile project.

Testing

Testing is important because it helps us discover errors and defects in our code, as well as define where our product does not meet the user requirements. By having thorough testing we can be confident that our code is of high quality and it meets the specified requirements.

There are many different types of testing, some examples are:

• Unit testing – testing an individual component
• Integration testing – testing that different components in your system work together correctly
• System testing – testing a full system from end-to-end, making it as realistic as possible, including all real dependencies and data
• Acceptance Testing – testing software concerning user’s needs, business processes, and requirements, to determine if it satisfies acceptance criteria

The first three types of testing listed above will generally be automated tests and so should be written during the Development phase. This is especially the case when following the Test Driven Development approach to software (you learned about this in the Chessington exercise during the Bootcamp, so reviewing those notes would be worthwhile). Even if you’re not following TDD it is important to aim for a high level of automated test coverage of the code you’ve produced, so that you’re protected from later changes to the code introducing regressions (i.e., breaking things that previously worked).

The outputs of this section are:

• Test Plans – A test plan should be written from the functional specification and functional and non-functional requirements
• Go/No-Go decisions – The results of all the forms of testing above should be summarised into a report that a group of senior stakeholders will assess and then decide whether to proceed with release

Implementation

Before implementation, it is crucial to have procedures in place to ensure that the release is verifiable and meets the desired outcomes. One important aspect is documenting the changes made in release notes. This helps in keeping track of the updates and communicating them to stakeholders. It is also essential to consider whether users require any training or a guide to understand and use the new release effectively.

An implementation plan is effectively a roadmap for how software will be released. It should cover the tasks involved in releasing the software, responsibilities of the various parties involved and a timeline. Having an implementation plan in place helps streamline the process and ensures consistency across environments.

There are different ways to approach the implementation phase including Big bang and Phased impelementation.

Big bang

Big bang implementation is the all-at-once strategy. This method consists of one release to all users at the same time.

Phased implementation

This method is more of a slow burner. The phased strategy implements releasing in rolled-out stages rather than all at once.

Version numbering changes

When implementing there are various version changes that you should be aware of:

Look at how the version numbers change:

• Alpha releases: 0.0.X
• Beta releases: 0.X.Y
• Major release: first digit increases by 1, minor/patch go back to 0
• Minor release: second digit increases by 1, patch goes back to 0
• Patch release: third digit increases by 1

Maintenance

The maintenance of a software system is split up into incident management and change management.

Incident management

Incident management support structure typically consists of three levels: first-line support, second-line support, and development support.

First-line support serves as the first point of contact for users who encounter issues with the system. They are responsible for documenting and reproducing the reported issues, as well as triaging them to determine if it is a simple resolution or if it needs escalating to higher levels of support.

Second-line support possesses a deeper level of technical knowledge about the system and is responsible for diagnosing and correcting issues with local installations. They manage the change release cycle, ensuring that updates and patches are properly tested and implemented.

Development support typically involves the vendors or outsourced development team that created the software system. They have access to the system’s code and internal components, allowing them to diagnose and fix complex issues. They may also be responsible for managing infrastructure-related issues, such as server configurations and database management.

Overall, the support structure is designed to provide a hierarchical approach to resolving issues with the software system, starting with basic troubleshooting at the first-line support level and escalating to higher levels of expertise as needed. This ensures that users receive prompt and effective assistance in resolving their technical issues.

Change management

Change management is needed when there has been a change in the requirements or system that requires action. This is normally handled by development support. This can be split up into four types of maintenance:

• Corrective maintenance – diagnosing faults and fixing them
• Adaptive maintenance – meeting changing environments and making enhancements and improvements
• Perfective maintenance – tuning/optimising the software and increasing its usability
• Support – keeping the system running and helping with day-to-day activities

Some examples of when change management will be needed are:

• New user requirements e.g. ‘Users now need to be able to sort searches by relevance’​
• Platform/infrastructure change e.g. the API format changes
• Identifying problems or incidents e.g. a security vulnerability is found
• Regulation changes e.g. GDPR updates.

Methodologies

Software development methodology refers to structured processes involved when working on a project. The goal is to provide a systematic approach to software development. This section will take you through a few different software development methodologies.

Waterfall workflow

For a long time the Waterfall methodology was the default for software development. It prescribes the precise and complete definition of system requirements and designs up-front, and completes each lifecycle stage entirely before continuing to the next. It focuses on upfront design work and detailed documentation to reduce costs later in the project.

Agile workflow

A widely accepted alternative to Waterfall is Agile. Agile principles emphasise frequent delivery, effective communication, rapid feedback cycles, and flexibility to required changes. Agile is as much a philosophy as a framework for methodology and so can take a lot of time and effort to take root within a community. The methodology focuses on the acceptance of change and rapid feedback throughout the project.

Agile is a term used to describe a methodology that follows the Agile manifesto:

• Emphasising individuals and interactions over processes and tools – great people make great software! It’s more important for the team to be able to do the best thing for the project than to stick to a fixed process.
• Working software over comprehensive documentation – working software is what counts. Most Agile processes are light on documentation and deliver working features regularly.
• Stakeholder collaboration over contract negotiation – negotiating all the details of a project upfront is time-consuming and inflexible. Collaboration throughout the project makes it easier to meet the needs of the stakeholder.
• Responding to change over following a plan – rigidly following a plan risks having the software become out of date before it is delivered. Being responsive to change allows the software to adapt and remain relevant.

Scrum

Scrum is a methodology built on Agile, which prescribes structures for reinforcing team coordination by reducing feedback cycles. Key structures include sprints, sprint meetings, daily scrums, and retrospectives. Instrumental to the Scrum process is the product owner, a client representative who communicates requirements and priorities to the team. Scrum defines some specific roles and events that should be run during the project. These definitions are all here.

Events

• The sprint – the heartbeat of the scrum. Each sprint should bring the product closer to the product goal and is a month or less in length.
• Sprint planning – the entire scrum team establishes the sprint goal, what can be done, and how the chosen work will be completed. Planning should be timeboxed to a maximum of 8 hours for a month-long sprint, with a shorter timebox for shorter sprints.
• Daily scrum – the developers (team members delivering the work) inspect the progress toward the sprint goal and adapt the sprint backlog as necessary, adjusting the upcoming planned work. A daily scrum should be timeboxed to 15 minutes each day.
• Retrospective – the scrum team inspects how the last sprint went regarding individuals, interactions, processes, tools, and definition of done. The team identifies improvements to make the next sprint more effective and enjoyable. This is the conclusion of the sprint.
• Sprint review – the entire scrum team inspects the sprint’s outcome with stakeholders and determines future adaptations. Stakeholders are invited to provide feedback on the increment.

Roles

• Developers – on a scrum team, a developer is anyone on the team that is delivering work, including those team members outside of software development.
• Scrum master – helps the team best use Scrum to build the product.
• Product Owner – holds the vision for the product and prioritizes the product backlog.

Artifacts

• Product backlog – an emergent, ordered list of what is needed to improve the product and includes the product goal.
• Sprint backlog – the set of product backlog items selected for the sprint by the developers (team members), plus a plan for delivering the increment and realizing the sprint goal.
• Increment – a sum of usable sprint backlog items completed by the developers in the sprint that meets the definition of done, plus the value of all the increments that came before. Each increment is a recognizable, visibly improved, operating version of the product.

Kanban

Kanban is a lightweight framework for managing Agile software development. The focus is on limiting work in progress and speeding up cycle time. Work items are represented visually on a Kanban board, allowing team members to see the state of every piece of work at any time.

• Visualise – project status is typically tracked on a Kanban board, tasks move across the board as they are progressed
• Limit WIP – limiting work in progress incentivises the team to get tasks finished and encourages knowledge sharing
• Manage flow – the Kanban board makes it easy to see if and where there are any blockers or bottlenecks
• Make policies explicit – for example, It should be clear what must happen for each card to reach the next column of the board
• Feedback loops – short feedback loops are encouraged, typically including automated testing, retrospectives, and code review
• Improve and evolve – there is an emphasis on improving how the team works

Test-Driven Development (TDD)

TDD evolved from rigorous testing practices and is another subsection of Agile. Requirements are split into minimal test cases, and the test code is written first. As the name suggests, the test process drives software development. In TDD, developers create small test cases for every feature based on their initial understanding. The primary intention of this technique is to modify or write new code only if the tests fail. This prevents duplication of test scripts.

Roles and responsibilities

There are different roles within a team and it’s important to understand what the responsibilities of each role are.

Development team

You will probably be familiar with the development team! The composition and roles can vary from project to project depending on the complexity and nature of the software being developed and the organisation’s structure. Here is a setup for a standard development team:

Developers

Developers are primarily involved during the development phase but may also participate as testers before UAT. They work from the design spec to produce the working code for the product and usually produce the unit, integration, and system tests.

Technical lead

The technical lead is a senior developer, who leads the team during development and who will often direct team standards such as code styles, review processes, etc. They will be a technical expert capable of solving hard problems and may prototype new technologies before they are fully integrated.

Technical architect/design lead

The technical architect/design lead designs the system architecture by prototyping unknown technologies and producing architecture diagrams and code specifications for the development team. They consider functional and non-functional requirements, as well as any constraints that the project may face. The key decisions for the development team including hardware, software, languages, etc are all made by them.

Project manager/product owner

Both the project manager and project owner have a responsibility to manage their team to realise a successful product.

Project managers are more focused on the longer-term outcomes by planning resources and ensuring completion within budget. They can also represent the stakeholders to the team.

Product owners are more focused on the current sprint by prioritising the backlog and representing stakeholders to the team.

Infrastructure

The infrastructure is responsible for encouraging and improving automation among the team. They improve the internal tooling for teams and are often responsible for deployment band releases. They can also monitor system alerts and the performance of the project.

Information secretary

The information secretary works outside individual development teams and develops security plans and policies for the organisation. They also test for vulnerabilities and monitor for security breaches.

Business analyst

The business analysts gather requirements from stakeholders and users. They work closely with the product owner to align the product closely with the business needs and may remain a part of the development team throughout. This helps the team understand the business processes more. A business analyst would also support acceptance testers during UAT.

Scrum master

The scrum master leads the team’s standups and retros and ensures the team is effectively practicing agile practices. They also protect the team from outside disruptions.

Business team

The business team can be set up as follows but can vary depending on requirements and procedures.

Project sponsor

The project sponsor ‘owns’ and is accountable for the project as a piece of business. They provide resources for the project and are usually a senior manager or director. They are in charge of making the final key decisions on the scope of a project. The project sponsor has an important role in requirements analysis, ensuring that the requirements meet the user’s needs.

End users

End users are people who will use the end product. This could be other employees at the company, employees elsewhere, or the general public. They can provide vital insight during the requirements analysis phase. Their opinions and experience will ultimately judge the outcome of the project.

Domain experts

Domain experts are people within the organisation who have a wider perspective on the problem. They may have experience working with existing solutions to the problem. Domain experts are often key to providing insight into the product and processes. They are likely to contribute to producing valuable requirements and designing/performing user acceptance tests.

User acceptance testers

User acceptance testers will perform the user acceptance tests. End users or domain experts also ensure that the software meets the underlying business needs. They are often supported by business analysts during the testing and may be involved in the requirements analysis if user acceptance tests are designed at that time.

Helpdesk support

Helpdesk support, also known as service desk, is first-line support. They deal directly with users and own the relationship with them. They will pass the issue up to technical support if it requires further investigation.

Communication

Above we have discussed different development methodologies and roles within a project, and now we’ll consider different communication methods that you’ll use and how to communicate appropriately depending on the purpose and audience.

Communication methods

Communication both inside and outside your organisation is a vital part of your job. Even if you’re fantastic perfect code, you need to be able to both share information about it and engage others to understand what is required.

The purpose of your communication and the audience should guide the method you choose. The following are some general principles to follow.

• Choose the medium wisely
  • For example, emails are ideal for reporting project status to a client, whereas a telephone call would be ideal for an urgent response and in-person communication is best for clarifying misunderstandings.
  • There are many other media such as video calls and instant messaging that would be more or less suitable depending on things like the amount of information being communicated, how much back-and-forth communication will occur and the formality of the relationship (where communication with a client is likely to be much more formal than with a colleague).
  • Remember that you don’t need to stick to a single medium. For example, after an in-person meeting it is wise to follow up with an email summarising any conclusions, or if you’re booking a call it might be helpful to send an agenda (list of topics to be discussed) in advance.
  • People generally have a preferred way of communicating (a preference for emailing might be to avoid direct interaction, or a preference for calling might come from wanting to be less formal), but you should think carefully about choosing the most appropriate medium rather than your preferred one.
• Know your audience
  • One of the most important aspects to consider is whether the recipient is technical or non-technical – this affects not the terminology you use, but also the viewpoint from which they think about whatever is being discussed.
  • Consider whether the communication is one-on-one or effectively a broadcast to a group of recipients.
  • Is the audience a customer or a colleague? This is likely to be significant for the style of communication (e.g., formal vs casual).
• Know the purpose of the communication
  • Examples include providing critical vs. non-essential information or asking a question.
  • Make sure that the main purpose is clear to the recipient. For example, if you’re drafting an email that is intended to give a project status update and also asking the recipient to make an important decision then there is a risk that the question will be overlooked – it might be better to put the question in a separate email.
• Be succinct and accurate
  • This is related to knowing the purpose of the message: you want to recipient to be focus on the most important points that you write or say, but if your communication is unnecessarily long or descriptive then they might be overlooked.
  • You need to use judgement, because if you’re too brief then the message could be ambiguous be inaccurate. It’s always wise to get important emails or discussion plans reviewed by an experienced colleague to check that you’ve got this balance right.
  • The use of a visual representation can often be very helpful and reducing the amount of textual explanation that is necessary.
• Be professional
  • It is important to be professional in all your work-related communication – in particular, be polite, avoid being brusque and don’t get angry or upset.
  • Even in more casual forms of work-related communication, such as with a colleague or in a social context, it is important to maintain professionalism in your communication and behaviour.

Non-conscious communication

When you’re communicating in-person or on a video call, be aware that a significant amount of information is imparted beyond the words being said or signed. You should be conscious of what information you might be sharing with the recipient unintentionally – ask for feedback from others of what they perceive.

• Vocal communication other than words can include your tone of voice and the speed at which you’re speaking
• Body language communicates a lot of information; in particular, be conscious of the effects of your facial expressions, posture and gestures
• Eye contact is especially important in one-on-one communication because it shows that you are engaged, and a lack of eye contact can be interpreted as a lack of trustworthiness; even if you are making a presentation to a group, making eye contact with members of the audience makes can have similar benefits

Active listening

Active listening is an important skill that demonstrates that you are engaged with what someone else is communicating to you, particularly one-on-one or in a small group. Hallmarks of active listening are responding by paraphrasing what has been said to prove that you have understood it, and asking for explanations or extrapolations.

Developing this habit ensures that people who are communicating with you will have confidence that you are interested in, and understand, what they are saying.

Policies and procedures

Each organisation will have its own policies and procedures so that the best practices are taken for building secure software. Here are some examples of policies you may encounter:

General Data Protection Requlation (GDPR)

GDPR is a large set of data protection rules for which the full text can be found here. At the core of GDPR are six key principles for personal data. Personal data must:

• Be processed fairly and lawfully
• Be obtained only for specified, explicit and lawful purposes and then used only for those purposes
• Be adequate, relevant, and limited to only what’s necessary for the purpose above
• Be accurate and kept up to date
• Not be held for any longer than necessary
• Be protected against loss, theft, or misuse

Account and password policy

Your organisation will have an account and password policy in place to protect against the threat of cyber attacks. This could include:

• Individual passwords are those that are only known by a single individual and they should never be divulged to anyone else.
• Users should not share the same individual password between different systems, websites, and services.
• Users must not allow other users to access any systems via their login, either by logging in deliberately on the other’s behalf or by logging in and leaving the PC unattended. Immediately on receiving a login and password, the user must change the password to one that they have created by the password policy below
• When reset, passwords should be entirely changed and not simply modified by changing a few characters or adding a suffix/prefix.

Secure development policy

Delivering secure software is essential and should be considered a requirement on all development projects even if not explicitly specified. The security needs for each project should be assessed at the start of the project. The high-level design of the system should explicitly consider security features, and take a defense-in-depth approach. This policy could include detailed approaches to the code review process, testing process, working with outside organisations, and using third-party components.

Accessibility Guidelines

When building software, there could be accessibility (a11y) practices that should be followed. The GEL guidelines used for building BBC software are a great example of this. Here are some following examples from it:

• Any field’s element needs to be associated programmatically with a label. This is achieved by making the label’s for attribute and the input’s id attribute share the same value.
• Sometimes multiple form elements should be grouped together under a common label. The standard method for creating such a group is with the <fieldset> and <legend> elements. The <legend> must be the first child inside the <fieldset>.
• Use a screenreader in the QA process.

Summary

In summary, the SDLC provides a framework for a shared understanding of the different roles and responsibilities involved in different stages of the production of software. It’s important to know how different parts of the process work together and the different approaches to building software that teams might take.