1.2.3 Software development

SDLCs

When developing software, teams will often utilise different software development lifecycles (SDLCs) in order to organise and schedule development.

Stages of an SDLC

SDLCs are generally split into a few common stages to describe the different stages of development during a project’s lifecycle.

Analysis

In this stage, the stakeholders will first provide the requirements for the finished product. These requirements will be used to

• Define the problem
• Estimate the feasibility of the project
• Deciding on the scope of the project
• Determining profitability

The point of this stage is to understand the problem provided by the stakeholders, decide whether the project is worth or possible undertaking, and what they want the finished product to be able to do.
This is essentially the same as the analysis section of the programming project.

Design

Design is where the requirements provided in the analysis stage are converted to a project plan. This is where technical details such as choice of language, framework, hardware, etc will be made.
Most aspects of the program will be identified and scaffolded in this stage, such as:

• Inputs
• Outputs
• UI design
• Security
• Performance

Development

This is where a large portion of the project’s lifecycle will be. Development is where the plan created in design will be converted into a collection of modules, where teams can then be allocated to work on coding the program.
Modules are ideally self contained, as this improves the ability for a team to work in parallel.

Testing

Testing is grouped into different categories to fit different stages of development. These strategies will be ideal for different circumstances, and will have different objectives or focuses.

White box testing

White box testing is the in-house testing of the code’s structure and algorithms. White box testing focuses on the code itself, and therefore requires knowledge of how the code is written. White box testing is used across the development cycle, and is consistently used to monitor for regressions.
White box testing often involves:

• Unit tests
• Valid, invalid, boundary and erroneous data

White box testing is often automated using Continuous Integration (CI) tools, or utilities that are part of the language/framework’s ecosystem, such as cargo test in the Rust ecosystem.

Black box testing

The goal of black box testing is to check the functionality of the program, ignoring anything unrelated to such, including the code quality or structure.
Black box testing is performed by the end users, where their feedback will be used to refine the functionality.

Alpha testing

Alpha testing is any testing performed by the in house developers, or other employees of the development company/department during the development stage. This will involve the early release of an in-development build of the program, where features may be missing or non functional.

Alpha testing will focus on pinpointing and fixing early bugs that may critically affect the program, and to give an idea of the current state of development.

Beta testing

Beta testing is carried out similarly to alpha testing except instead with the end user using the build, where they will be allowed to use the program as they expect. The beta build will be often made after the main development has completed and functionality is present. The end user will then provide feedback to the developers on any remaining issues regarding the program.

Beta builds are often very close to the final release of the program, where the only thing stopping the final release is quality control.

Warning

Regression and acceptance testing are not in the specification. However it’s probably good to know

Regression Testing

Acceptance Testing

Implementation

After a build is passing all tests and has been approved by the client, the program can then be installed onto production servers or systems. Implementation also often involves the additions of application tweaks such as DRM and digital signatures. It can also involve setting up distribution, such as pushing updates or creating download servers/CDNs

Evaluation

Maintenance

System development methodologies

The above stages can be grouped together in different ways to create System development methodologies, which determine how teams will approach the development of a project.

Waterfall

Waterfall is a linear SDLC where each stage is completed sequentially, cycling round each time. The structure is highly rigid, where if the team needs to go back to a previous stage, the stages from then and the most recent stage must als obe repeated. In addition, the users generally only give any feedback to the development team near the start or end of a waterfall cycle, therefore making changes is tedious and difficult with this paradigm.

Advantages:

• Clear milestones
• Easy to produce good documentation
• Simple management
• Very predictable
• Well understood and well known

Disadvantages:

• Inflexible to requirement changes
• Mistakes need to be caught during the stage they appear, otherwise backtracking stages is expensive

This is probably the simplest SDLC, but is also being phased out for the agile methodologies .

Spiral

The Spiral model is a similarly iterative SDLC that takes the ideas of Waterfall, but injects additional risk assessments after the analysis stage. The spiral model is generally split into four stages in the following order

The spiral model is used for projects that are high risk and high cost, where the additional risk assessments are necessary. Every spiral’s evaluation stage will feed into the next spiral’s analysis to inform the next iteration.

Advantages:

• Extensive risk management
• Evaluation feeds into the next iteration
• Simple

Disadvantages:

• Costly
• Time consuming

Rapid Application Development (RAD)

When the inital requirements are unclear and the project scope is relatively small, RAD can be used.
RAD is an iterative methodology that involves the development of many early prototypes that are then presented to the client.
The development team will take the feedback from the client to produce the next prototype.

Eventually, after enough early prototypes, the prototype will match the requirements of the client, where it can then be presented as the finals solution.

Advantages:

• Fast delivery of functional prototypes
• strong user involvement
• flexible to requirement changes.

Disadvantages:

• Less suitable for very large systems
• Potential for scope creep
• Depends on availability of end users.

Agile

Agile describes a family of iterative methods that prioritise flexibility during development. Generally, the development team will focus on different aspects of the project at the same time, therefore allowing development to be completed in parallel.

The team will focus on producing a prototype early on which can be presented to the client for feedback. This delivery of prototypes continues throughout the lifecycle as well.

Advantages:

• Frequent prototypes
• Continuous customer feedback
• Versatile
• Common in workplaces

Disadvantages:

• Requires disciplined teams
• Requires constant stakeholder engagement

🔥Extreme Programming🔥

Extreme programming is a subset of the Agile methodology that emphasises engineering practices to improve code quality and responsiveness.

Extreme programming generally involves pair programming, test‑driven development (TDD), continuous integration, simple design and small frequent releases as these are all techniques that focus on specific code quality.

Advantages:

• High code quality
• Rapid response to change
• Strong developer collaboration.

Disadvantages:

• Requires more teamwork
• Requires 2 developers per section/session
• Clients may not be available