Слайд 1“You’ve got to be very careful if you don’t know
where you’re going, because you might not get there.”
Yogi Berra
Слайд 2Software Development Life Cycle (SDLC)
“You’ve got to be very careful
if you don’t know where you’re going, because you might
not get there.”
Yogi Berra
Слайд 7The SYSTEM LIFE CYCLE is a process of stages which
occur during the development of a new ICT system.
Слайд 8What do you think?
Steps of SLC?
Слайд 9Definition
Investigation and analysis
Design
Implementation
Testing
Installation
Documentation
Evaluation
Слайд 10Definition
The very first part of the SLC is to define
the problem.
In the definition stage the role of the analyst
is to scope out the problem.
The analyst has a number of methods available to do this :
Interviews with management to get their viewpoint
Interviews with staff to understand the limitations of the current system
Other methods that will be discussed later in this mini-web
Слайд 11Investigation and Analysis: investigating the system
In order to reach this
stage in the SLC, management would have listened to the
alternative solutions presented by the system analyst and have decided to either commission a brand new IT system or have changes made to their current system.
Слайд 12The current system
how staff / customers interact with the current
system i.e. how tasks are carried out
how other systems interact
with the current system
what is good about the current system
what causes problems with the current system
which parts of the system are critical to the business
Слайд 13The proposed new system
what the new system is expected to
be able to do
how the new system is expected to
do this
what people want from the new system
which working methods from the old system should be incorporated into the new system
Слайд 16Once the diagrams have been completed, two key documents/ reports
are produced:
1. A full written analysis of the current system,
the processes and the problem it causes
2. Detailed user requirements for the new system
Слайд 17Design phase
This document will include the following information:
Data capture methods
for the system
Data inputs to the system
Data outputs from the
system
Data processing within the system
The file structure for data storage
The user interface i.e. screen layouts, buttons, error messages
How information is accessed and indexed or sorted.
The operating system to be used
The hardware to be used to run the new system
Слайд 20 Implementation (development)
the tables and data structures
validation routines
data capture forms
data input
forms
automated processing routines i.e. macros
queries
the user interface i.e. screen, buttons,
help messages
printing outputs
Слайд 22Installation
The system has been developed and tested. It is working
correctly and doing everything that was agreed during the design
stage. The business is waiting in eager anticipation for the new system to be handed over to them.
Слайд 23User Documentation
Table of contents
Short introduction or overview of the system
Brief
technical details such as the hardware and software requirements to
run the system
User Guide : this is the bulk of the document
Glossary of technical terms
Troubleshooting: usually a simple list of things to check before calling for further help
Index
Слайд 24Evaluation
Does the finished solution meet its requirements?
Does it solve the
problem?
Слайд 25http://www.teach-ict.com/as_a2_ict_new/ocr/A2_G063/331_systems_cycle/slc_stages/miniweb/pg23.htm
Слайд 26Waterfall Model
Requirements – defines needed information, function, behavior, performance and
interfaces.
Design – data structures, software architecture, interface representations, algorithmic details.
Implementation
– source code, database, user documentation, testing.
Слайд 27Waterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced
staff
Milestones are well understood
Sets requirements stability
Good for management control (plan,
staff, track)
Works well when quality is more important than cost or schedule
Слайд 28Waterfall Deficiencies
All requirements must be known upfront
Deliverables created for each
phase are considered frozen – inhibits flexibility
Can give a false
impression of progress
Does not reflect problem-solving nature of software development – iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview the system (until it may be too late)
Слайд 29When to use the Waterfall Model
Requirements are very well known
Product
definition is stable
Technology is understood
New version of an existing product
Porting
an existing product to a new platform.
Слайд 30Spiral SDLC Model
Adds risk analysis, and 4gl RAD prototyping to
the waterfall model
Each cycle involves the same sequence of steps
as the waterfall process model
Слайд 31Spiral Quadrant
Determine objectives, alternatives and constraints
Objectives: functionality, performance, hardware/software interface,
critical success factors, etc.
Alternatives: build, reuse, buy, sub-contract, etc.
Constraints: cost,
schedule, interface, etc.
Слайд 32Spiral Quadrant
Evaluate alternatives, identify and resolve risks
Study alternatives relative
to objectives and constraints
Identify risks (lack of experience, new technology,
tight schedules, poor process, etc.
Resolve risks (evaluate if money could be lost by continuing system development
Слайд 33Spiral Quadrant
Develop next-level product
Typical activites:
Create a design
Review design
Develop code
Inspect code
Test
product
Слайд 34Spiral Quadrant
Plan next phase
Typical activities
Develop project plan
Develop configuration management plan
Develop
a test plan
Develop an installation plan
Слайд 35Spiral Model Strengths
Provides early indication of insurmountable risks, without much
cost
Users see the system early because of rapid prototyping tools
Critical
high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently
Слайд 36Spiral Model Weaknesses
Time spent for evaluating risks too large for
small or low-risk projects
Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-development phase activities
May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration
Слайд 37When to use Spiral Model
When creation of a prototype is
appropriate
When costs and risk evaluation is important
For medium to high-risk
projects
Long-term project commitment unwise because of potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)
Слайд 38Agile SDLC’s
Speed up or bypass one or more life cycle
phases
Usually less formal and reduced scope
Used for time-critical applications
Used
in organizations that employ disciplined methods
Слайд 39Some Agile Methods
Adaptive Software Development (ASD)
Feature Driven Development (FDD)
Crystal Clear
Dynamic Software Development Method (DSDM)
Rapid Application Development
(RAD)
Scrum
Extreme Programming (XP)
Rational Unify Process (RUP)
Слайд 40Extreme Programming - XP
For small-to-medium-sized teams developing software with vague
or rapidly changing requirements
Coding is the key activity throughout a
software project
Communication among teammates is done with code
Life cycle and behavior of complex objects defined in test cases – again in code
Слайд 41DSDM Principles
Active user involvement imperative (Ambassador users)
DSDM teams empowered to
make decisions
Focus on frequent product delivery
Product acceptance is fitness for
business purpose
Iterative and incremental development - to converge on a solution
Requirements initially agreed at a high level
All changes made during development are reversible
Testing is integrated throughout the life cycle
Collaborative and co-operative approach among all stakeholders essential
Слайд 42DSDM Lifecycle
Feasibility study
Business study – prioritized requirements
Functional model iteration
risk
analysis
Time-box plan
Design and build iteration
Implementation
Слайд 43Adaptive SDLC
Combines RAD with software engineering best practices
Project initiation
Adaptive
cycle planning
Concurrent component engineering
Quality review
Final QA and release