ECM2414 SDLC Flashcards
SDLC – broad categories
Requirements analysis
Design
Implementation
Testing
Evolution
Requirements analysis
What business/scientific problem is the system addressing? Is it
feasible?
What will the system do? Who are the users?
Design
What are the hardware, software and network requirements?
What parts of these will be in-house, and what will be externally
Implementation
The programming
Evolution
Has the system accomplished its goals? Are there modifications to be made? If so, return to requirement analysis.
Software Development Methodologies
Although the broad categories remain, there are multiple SD
methodologies
E.g.,
-Waterfall
-Prototyping
-Rapid Application Development
-Agile
Selection of methodology is dependent on the project type and
resources available
Waterfall
◼ The Waterfall approach breaks the SDLC into distinct sequential
phases
◼ Each phase needs sign-off (approval) before moving to the next
◼ Leads to very well-documented projects
◼ But means that errors propagate through if not spotted, which
can be very expensive to fix
Prototyping
Not a complete methodology but a way of tackling larger
stages in other methodologies
◼ Prototyping approaches exist across design areas
◼ Involves end users during process
◼ Lower functionality prototype(s) constructed, to try our ideas, to
learn from, and to get feedback
◼ Analysis, design and implementation tightly coupled leading to
prototypes that feed back – can sometimes cause initial plans to
be reassessed
◼ Often prototypes are discarded
Rapid Application Development
◼ Heavy focus on tool use to reduce development time and costs
(IDEs, GUI builders, database management systems)
◼ The planning and software implementation are interleaved
◼ Business need paramount
◼ Often development deadline prioritised over requirements: i.e.,
the project iterations are overrunning, the focus is on reducing
requirements rather than extending the deadline
An iterative, incremental process, meeting the need of the business with time
Agile development
Software development practice based on short iterative “sprints”
these sprints include all regular stages of the SDLC, but involve scrum meetings
Based on short fixed-length sprints
Typical 2-4 weeks long
Aim to produce deployable software in each sprint
Sprint planning meeting
- Which items will be worked on
- Identify sprint tasks
- Divide the sprint into timeboxes
Daily Scrum meeting
- Summarise previous day’s work and coming day’s work
- Intended to foster collaboration
Sprint review meeting
- Demonstration of completed software
- Project owner determines which items of work are complete
DIFFERENCE BETWEEN RAD AND AGILE
Both iterative and incremental
Agile requires understanding the entire system before implementation stage, so you can have a set definition of what each sprint will feature, and what will be reviewed in each sprint review
Agile is very formal
At the end of the end of an agile sprint, you are aiming to create a (semblence of a) product, whether that’s a product, incomplete prototype, or new feature
Pair Programming
Two people working on a single programming
task
- One is called the driver – they are actually typing
the code
- The other is the navigator – they are responsible
for the overall direction of the programming
Roles are periodically reversed between the two
Better productivity than two programmers
working independently
Promotes dissemination of project knowledge
among the team
Good for transferring skills to junior developers
Advantages of agile development
◼ User engagement
◼ Rapid development of a usable product
◼ Early testing catches bugs and results in a high-quality product
◼ Small incremental changes mitigate the potential risk of introducing a large change to a system
