You are on page 1of 42

Module

CC3018NP:
Advanced Systems Analysis
Lecture for Week 1
AY 2012 Autumn

Agenda
About this module:
Your module leader
Your lecturer and tutor

What is expected from you


Attend all Lectures.
Come in tutorial classes well prepared for class
works.
Clear your doubts during tutorials.

Strategy
Assessment Strategy
50% Course Work
50% Unseen Exam
Class Types
Lecture
Tutorial

Learning Outcomes
Able to understand the strengths and
limitations of various approaches to
systems development.
Able to choose appropriately from a range
of systems analysis and design methods
and apply each of these methods to
system specification
Aware of modern trends in systems
development

SDLC
SYSTEM DEVELOPMENT LIFE CYCLE
System
Its Development
And Life Cycle of Development

System
Tools
Process

People

Information System
Combination of information
technology and people's activities that
support operations, management and
decision making.
Information systems help to control the
performance of business processes.

SDLC Objectives
ensure that high quality systems are
delivered
provide strong management controls over
the projects
maximize the productivity

SDLC Activities - Technical


System Definition (analysis, design, coding)
Testing
System Installation (training, data migration)
Production Support
Evaluate Alternatives
Define Releases
Define Technical Strategy

SDLC Activities - Managerial


Define Objectives
Project Tracking and Status Reporting
Change Control
Risk Assessment
Cost/Benefit Analysis
Managing Vendors
Post Implementation Reviews
Quality Assurance Reviews

Software
Brooks suggests,
software
is pure thought stuff,
infinitely malleable
as well as
invisible and
unvisualizable.

Why Projects Fail?

System and Life Cycle


All Systems have a life cycle or a series of
stages they naturally undergo

The number and name of the stages varies,


but the primary stages are conception,
development, maturity and decline
The systems development life cycle (SDLC)
therefore, refers to development stage of the
systems life cycle.

Methodologies
Is there a difference between the term SDLC
and term methodology?
SDLC refers to a stage all systems naturally
undergo,
Methodology refers to an approach invented by
humans to manage the events naturally occurring
in the SDLC.

Methodology
A methodology is, in simple terms
-a set of steps
-guidelines
-activities and/or principles

to follow in a particular situation.


Most methodologies are comprehensive, multisteps approaches to system development

SDLC Approach

Refers to a linear sequence of stages to


develop a system from planning to
analysis to design to implementation.

Stages are followed from beginning to


end.
Revisiting prior stages is not permitted.

SDLC
SDLC highlights 6 distinct phases:
-

Project Identification and Selection


Project Initiation and Planning
Analysis
Design
Implementation
Maintenance

Project Identification and Selection


Main Activities
Identification of need
Prioritization and translation of
need into a development schedule
Helps organization to determine whether or
not resources should be dedicated to a
project

Project Initiation and Planning


Main Activities
Formal preliminary investigation of
the problem at hand
Presentation of reasons why system
should or should not be developed by
the organization

Analysis
Study of current procedures and information
systems
Determine requirements
Study current system
Structure requirements and eliminate
redundancies
Generate alternatives designs
Recommended best alternatives

Design
Logical Design
Concentrates on business aspects of
the system
Physical Design
Technical specifications

Implementation

Hardware and software installation


Programming
User Training
Documentation

Maintenance
System changed to reflect changing
conditions
System update as per change

System Development Constraints

Various Models
Waterfall Model
V-Shaped SDLC Model
Rapid Application Model (RAD)
Incremental SDLC Model
Spiral Model

Waterfall 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

Iterative Waterfall Model


Concept
Exploration
Process
System
Allocation
Process
Requirements
Process
Design
Process
Implementation
Process
Verification
& Validation
Process
Installation
Process
Operation &
Support Process

When 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.

V-Shaped Model
A variant of the Waterfall
that emphasizes the
verification and
validation of the product.
Testing of the product is
planned in parallel with a
corresponding phase of
development

V-Shaped Steps
Project and Requirements Planning allocate
resources
Product Requirements and Specification Analysis
complete specification of the software system
Architecture or High-Level Design defines how
software functions fulfill the design
Detailed Design develop algorithms for each
architectural component

V-Shaped Steps
Production, operation and maintenance provide for
enhancement and corrections
System and acceptance testing check the entire
software system in its environment
Integration and Testing check that modules
interconnect correctly
Unit testing check that each module acts as expected
Coding transform algorithms into software

When to use V-Shaped Model


Excellent choice for systems requiring high
reliability hospital patient control applications
All requirements are known up-front
When it can be modified to handle changing
requirements beyond analysis phase
Solution and technology are known

Rapid Application Model


Requirements Planning Phase (a workshop
utilizing structured discussion of business
problems)
User Description Phase automated tools
capture information from users
Construction Phase productivity tools, such as
code generators, screen generators, etc. inside
a time-box. (Do until done)
Cutover Phase -- installation of the system,
user acceptance testing and user training

When to use RAD

Reasonably well-known requirements


User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized

Incremental Model

When to use Incremental Model


Most of the requirements are known up-front but
are expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development
schedules
On a project with new technology

Spiral Model
This model of development combines the
features of the prototyping model and the
waterfall model.
The spiral model is favored for large,
expensive, and complicated projects.

Spiral Model

When 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
Significant changes are expected (research and
exploration)

Thanks Y

Thank You.

You might also like