The software development lifecycle (SDLC) involves 8 stages: 1) determine scope, 2) gather requirements, 3) write specifications, 4) design solution, 5) code design, 6) test program, 7) write documentation, and 8) review and maintain. The stages ensure a systematic process of planning, developing, testing and documenting a software project. Requirements gathering is critical to understand user needs, while testing verifies the program functions as intended. Documentation provides instructions to users and information for future maintenance.

1. Software Development
Lifecycle
“You’ve got to be very careful if you don’t know where
you’re going, because you might not get there.”
Yogi Berra
1

2. SDLC Stages
1: Determine
Scope
8: Review 2: Gather
& Maintain Requirements
7: Write 3: Write
Documentation Specification
6: Test the 4: Design
program Solution
5: Code the
design
2

3. 1: Determine the Scope
Also called the Problem Domain
Describe the boundaries of the problem
Identify what is and what is not covered
Include those who are affected (stakeholders)
and describe how they are affected.
 what functions is the product supposed to have
i.e. how the interface should be, what should the
product do, how will the user use the product.
3

4. 2: Gathering Requirements
4

5. 2: Gathering Requirements
A common failure of IT projects worldwide
The Functional Requirements must be
known
 What is wanted by those who are affected
Gathering techniques:
 Existing Documentation
 Observation
 Interview
 Questionnaires
5

6. 3: Write Specification
A categorised list of elements required to
start designing a solution, inc:
 Inputs
 Outputs
 Processing
 Storage
 User interface
 Constraints
6

7. 4: Design Solution
Using design tools, inc
 Forms design
 Flowcharts
 Structure diagrams
 DFDs and ERDs
 UML diagrams
 Class schemas
7

8. 5: Code the design
Designs are converted into program code
Language will have been selected
depending on program function
Teams of programmers may work on
different modules or classes
Teams must adopt similar working
practices and understand how their modules
fit into larger solution
8

9. 6: Test the program
Testing is a critical part of the quality
assurance process,
2 common methods for module testing are:
 Black Box - doesn’t care about how the
program was written, only if it does what it’s
supposed to do.
 White Box – examines performance of code.
Ensures code generates correct results
White box starts after Black box and takes
longer.
9

10. 6: Test the program
A thorough test plan should include:
 All possible outcomes (check flowcharts
logical pathways e.g. Loops & True/False)
 Sufficient test data which checks Normal,
Extreme and Erroneous data.
 Trace table inc; Date, Test, Expected result,
Actual Result, Corrective action and
 Screen captures
Debugging tools include:
 Breakpoint & Trace (run program line-by line),
 Watches (changes to variable contents)
10

11. 7: Write Documentation
Three types of documentation
Internal (inside code)
 Meaningful variable names,
 Tidy layout & good comments (why not how)
Technical (for maintenance)
 Requirements specification, Design diagrams,
Test strategy, fully commented code,
Troubleshooting guide.
User (step-by step instructions)
 Text files (e.g. Readme.txt), PDF files,
Sceencasts and animations. 11

12. 8: Review & Maintain
Reviewing
 Looking at the solution and comparing it with
the original requirements
 Have they been met? and How well is the
solution working?
Maintenance
 Keeping the solution working
 Expanding the scope of the program to add
extra features and functionality
 Over 80% of the lifecycle can be maintenance
12