System Development

Life Cycle (SDLC)

 Six Phases of the
System Development
Life Cycle
Preliminary Investigation
Assesses feasibility and practicality of system
System Analysis
Study old system and identify new
requirements
Defines system from user's view
System Design
Design new/alternative system
Defines system from technical view
 Six Phases of the
System Development
Life Cycle
System Development
New hardware and software is acquired,
developed, and tested
System Implementation
System installation and training

System Operation & Maintenance

Daily operation
Periodic evaluation and updating
SDLC Phases
Preliminary
Investigation

System
System Operation Analysis
& Maintenance

System System
Implementation
n Design

System
Development
 Phase 1:
Preliminary Investigation
Determine if a new system is needed

Three primary tasks:

Define the problem
 By observation and interview, determine what
information is needed by whom, when, where and why
Suggest alternative solutions

Prepare a short report

 Phase 2:
System Analysis

In depth study of the existing system to

determine what the new system should do.
Expand on data gathered in Phase 1

In addition to observation and interviews,

examine:
Formal lines of authority (org chart)
Standard operating procedures
How information flows
Reasons for any inefficiencies
 Phase 2: System Analysis
Tools Used

Checklists - list of questions

Top-down analysis - start with top level
components, break down into smaller
parts through each successive level
Grid charts - to show relationship
between inputs and outputs
System flowcharts - charts flow of input
data, processing, and output which show
system elements and interactions
 Phase 2: System Analysis
Documentation Produced

Complete description of current system

and its problems
Requirements for for new system
including:
Subject
Scope
Objectives
Benefits
Possible development schedule
 Phase 3:
System Design
Uses specifications from the systems
analysis to design alternative systems
Evaluate alternatives based upon:

Economic feasibility - Do benefits justify

costs?
Technical feasibility - Is reliable technology
and training available?
Operational feasibility - Will the managers
and users support it?
 Phase 3: System Design
Tools Used
Computer-Aided Software Engineering
(CASE) tools are software-based products
designed to help automate the production of
information systems.
Examples:
Diagramming Tools
Data Repositories
Prototyping Tools
Test Data Generators
Documentation Tools
Project Management Tools
 Phase 3: System Design
Documentation Produced

System Design Report

Describe Alternatives including:
Inputs/Outputs
Processing
Storage and Backup
Recommend Top Alternative based upon:
System Fit into the Organization
Flexibility for the future
Costs vs. benefits
 Phase 4:
System Development

Build the system to the design specifications

Develop the software
Purchase off-the-shelf software OR
Write custom software
Acquire the hardware
Test the new system
Module (unit) test - tests each part of system
Integration testing - tests system as one unit
Create manuals for users and operators
 Phase 5:
System Implementation

Convert from old system to new system

Train users
Compile final documentation
Evaluate the new system
 Phase 5: System
Implementation
Types of Conversion
 Direct/plunge/crash approach – entire new system
completely replaces entire old system, in one step
 Parallel approach - both systems are operated side
by side until the new system proves itself
 Pilot approach - launched new system for only one
group within the business -- once new system is
operating smoothly, implementation goes company-
wide
 Phased/incremental approach - individual parts of
new system are gradually phased-in over time,
using either crash or parallel for each piece.
 Phase 5: System
Implementation

User Training
Ease into system, make them comfortable,
and gain their support
Most commonly overlooked
Can be commenced before equipment
delivery
Outside trainers sometimes used
 Phase 6: Operations &
Maintenance

Types of changes:
Physical repair of the system
Correction of new bugs found (corrective)
System adjustments to environmental changes
Adjustments for users’ changing needs
(adaptive)
Changes to user better techniques when they
become available (perfective)
 Phase 6: Operations &
Maintenance

Evaluation Methods

Systems audit - performance compared to

original specifications
Periodic evaluation - “checkups” from time
to time, modifications if necessary
 Deliverables of the SDLC
Approved Feasibility Abort Project
Preliminary
Investigation Study Goto next phase
Problem Goto Previous phase
System
Analysis Specifications

System
Design Design Specifications

System Coded and

Development Tested System
Begin building System System converted
new system Implementation Users trained
System
Maintenance
Operational System
Documentation completed
 Software engineering
Software engineering: the profession,
practiced by developers, concerned with
creating and maintaining software
applications by applying technologies
and practices from computer science,
project management, and other fields.

19
 Roles of people in software
people involved in software production
customer / client: wants software built
 often doesn't know what he/she wants
managers / designers: plan software
 difficult to foresee all problems and issues in advance
developers: write code to implement software
 it is hard to write complex code for large systems
testers: perform quality assurance (QA)
 it is impossible to test every combination of actions
users: purchase and use software product
 users can be fickle and can misunderstand the product

20
 Ad-hoc software
development
ad-hoc development: creating software
without any formal guidelines or process

what are some disadvantages of ad-hoc

development?

 some important actions (testing, design) may

go ignored
 not clear when to start or stop doing each

task
 does not scale well to multiple people
21
 not easy to review or evaluate one's work
 The software lifecycle
software lifecycle: series of steps / phases,
through which software is produced
can take months or years to complete

goals of each phase:

mark out a clear set of steps to perform
produce a tangible document or item
allow for review of work
specify actions to perform in the next phase

common observation: The later a problem is

found in software, the more costly it is to fix

22
 Lifecycle phases
 standard phases
1. Requirements Analysis & Specification
2. Design
3. Implementation, Integration
4. Testing, Profiling, Quality Assurance
5. Operation and Maintenance

 other possible phases

 risk assessment: examining what actions are
critical and performing them first (part of
Spiral model)
 prototyping: making a quick version of the
product and using it to guide design decisions
23
 One view of SW cycle phases
Requirements System Object Implemen-
Analysis Testing
Elicitation Design Design tation

Implemented
Expressed in By
Structured Realized By
Terms Of By Verified
By

class...
class...
class... ?
class.... ?
Use Case Applicatio Solution
n Subsystems Source Test
Model Domain
Domain Code Cases
Objects
Objects
24
 Some software models
Several models for developing software
(besides ad-hoc) have been attempted:
code-and-fix: write some code, debug it, repeat
until finished
evolutionary: build initial requirement spec,
write it, then "evolve" the spec and code as
needed
waterfall: perform the standard phases
(requirements, design, code, test) in sequence
rapid prototyping: write an initial "throwaway"
version of the product, then design, code, test
spiral: assess risks at each step, and do the
most critical action immediately

25
 code-and-fix model
Code First
Version

Modify until
Client is satisfied

Operations Mode

Retirement
26
 Problems with code-and-fix
What are some reasons not to use the
code-and-fix model?

 code becomes expensive to fix (bugs are

not found until late in the process)
 code didn't match user's needs (no
requirements phase!)
 code was not planned for modification,
not flexible
27
 Evolutionary model
Requirements

Verify
Arch. Design

Verify
For each build:
Perform detailed
design, implement.
Test. Deliver.

Operations

Retirement

28
 Problems with evolutionary
The evolutionary model is similar to
code-and-fix, but it assumes the
repetitions are "evolutions" of the code,
not necessarily bug fixes. Problems with
 difficult to distinguish from code-and-fix
this?
 assumes user's initial spec will be flexible; fails
for:
 separate pieces that must then be integrated
 "information sclerosis": temporary fixes become
permanent constraits
 bridging; new software trying to gradually replace
29 old
 Waterfall model (Royce,
1970)
Req. Change
Requirements

Verify
Design

Verify
Implementation

Test

Operations

Retirement
30
 Rapid prototyping model
Req. Change
Rapid Prototype

Verify
Redesign

Verify
Re-implementation

Test

Operations

Retirement
31
 Waterfall / Prototyping issues
The waterfall models (with or without
prototyping) are perhaps the most common
model for software development
we will use waterfall in this course!
What are some positives and negatives
about this method?

+ formal, standard, has specific phases with clear goals

+ good feedback loops between adjacent phases
- rigid, too linear; not very adaptable to change in the
product
- 32
requires a lot of planning up front (not always easy /
 Spiral model (Boehm) Cumulative
cost

Progress
through
Determine steps Evaluate alternatives,
objectives, identify, resolve risks
alternatives,
constraints
(OAC) Risk
Assessment
Concrete
Specification
OAC Risk
Assessment
Abstract
Specifcation
OAC Risk Risk
Requirements Assessment Control
Risk
OAC Control
Risk
Commit Control
Review
partition Requirements
Concept of
Plan
Operation
Requirements
Abstract Specification Abstract
Plan Specification Concrete
Requirements Specification
Validation
Concrete Specification
Plan
Abstract Specification
Validation

Software Concrete
Plan next phases Development Plan Specification Validation Develop, verify
and Verification next-level product
33
 Another view of spiral model
Risk Assessment
Req. Change
Requirements
Risk Assessment
Verify
Design
Risk Assessment
Verify
Implementation

Test
Adds a Risk Analysis
step to each phase
Operations

(phases may not be

completed in this order Retirement
34 any more!)
 Spiral model problems
What are some positives and negatives
about this method?

+ focuses attention on reuse

+ accommodates changes, growth
+ eliminates errors and unattractive choices early
+ limits to how much is enough (not too much design,
reqs, etc)
+ treats development, maintenance same way
- matching to contract software (doesn't work well when
you're bound to a fixed inflexible contract)
- relying on developers to have risk-assessment expertise
35
- need for further elaboration of project steps (clearer
 Tools for software engineers
CASE (Computer-Aided Software
Engineering)
requirements / spec generation software
design diagram (UML) software
integrated development environments (IDEs)
test suites (JUnit) and benchmarking /
profiling software

36