System Development Life Cycle (SDLC)edit Master subtitle style Click to

what a systems development lifecycle (SDLC)

why it is needed
4/10/12

Why SDLC
v Each system is composed of a rigorous set

of tasks which result in well-defined outputs.

v The data, the division of responsibilities

and the interface definitions are required because of the complexity of these systems.
v well-defined
4/10/12

Objectives
An SDLC has three primary business objectives:
v Ensure the delivery of high quality

systems

v Provide strong management controls v Maximize productivity.

4/10/12

2 major activities in SDLC

v Management v Technical

Activities
v defining objectives v setting priorities v project tracking and

Activities
v system

definition/developmen t

status reporting
v change control, v risk assessment, v step wise commitment v cost/benefit analysis,

v Testing v system installation v evaluating

alternatives
v reconciling

information across

4/10/12

Investigati on Maintenance Implementation & Evaluation Testing Feasibility Study Analysis Design

Developmen t
4/10/12

Preliminary Investigation
v Study of current system v Identifying the limitations and/or problems How Current System

of

your business process 1. What current v Proposing Scope andcan do system Objectives of new system 2. What are the benefits System 1. What newwhich you are missing . should do 3. What else can 2. What you want to system perform achieve with the 4/10/12 new system

existing system With respect to works

3- levels of Information Requirements

Organization-Level information Requirements Database Requirements Application Level Information Requirements

Social /behavioral Requirements Technical Requirements

4/10/12

Strategies for Determining Information Requirements

Asking Deriving from an existing information

system

Synthesizing from characteristics of the

utilizing system

Discovering from experimentation with an

evolving information System.

4/10/12

Feasibility Study
v Identifying
v Project Type v Project Size v System Type

v Proposing and Checking new System

Feasibility

> Technically feasible 4/10/12 > Operationally feasible

Analysis
v Gathering the data about user requirements

according to the new system

v Functional hierarchy showing the functions to

be

performed by the new system and their relationship with each other.

v All procedures, requirements are analyzed

and documented in the form of detailed DFDs, data dictionary, logical data structures and 4/10/12 Control

Design
v Design is a blue print of a computer

system solution to a given problem

v Input, output and processing specifications

are drawn up in detail.

v The data which is gathered in analysis

phases is used in design phase Stages.

4/10/12

Development
v Blue Print is converted into computer

understanding language (i.e Coding is done)

v This is also called the programming

phase in which the programmer converts the specifications into computer instructions

4/10/12

Testing
v Before actually implementing the new

system into operations, a test run of the system is done removing all the bugs, if any
v Testing Steps:v Define Test Criteria v Design Test Cases v Build Test Cases
4/10/12

Implementation
v After having the user acceptance of the

new system developed, the implementation phase begins.

v During this phase, all the programs of the

system are loaded onto the user's computer. After loading the system, training of the users starts.

v Main topics of such type of training are:

- How to execute the package - How to enter the data 4/10/12 - How to process the data (processing

Maintainance
v Maintenance is necessary to eliminate

errors in the system during its working life and to tune the system to any variations in its working environment.

v It is the review of the system from time

to time. The review of the system is done for: - knowing the full capabilities of the system - knowing the required changes or 4/10/12 the

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, testing.

Waterfall 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

4/10/12

Waterfall 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

4/10/12 Integration is one big bang at the end

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.

4/10/12

Prototyping Model

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements.

4/10/12

Advantages of Prototyping
Users are actively involved in the development It provides a better system to users, as users have natural tendency to change

their mind in specifying requirements and this method of developing systems supports this user tendency.
Since in this methodology a working model of the system is provided, the

users get a better understanding of the system being developed.

Errors can be detected much earlier as the system is mode side by side. Quicker user feedback is available leading to better solutions.
4/10/12

Disadvantages
Leads to implementing and then repairing way of building

systems.

Practically, this methodology may increase the complexity

of the system as scope of the system may expand beyond original plans.

4/10/12

RAD model
RAD model that emphasizes on extremely short development cycle (anywhere from 6090 days).

The RAD model is a high-speed adaptation of the linear sequential model / Waterfall model.

4/10/12

Business Modeling: The information flow among business functions is modeled in a way that answers the following questions:
What information drives the business processes? What information is generated? Who generates it? Where does the information flow? Who processes it?

Data Modeling :The information flow defined as part of the business modeling phase is refined into a set of data objects that are 4/10/12 needed to support the business. The

RAD Strengths
Reduced cycle time and improved productivity with fewer people

means lower costs

Time-box approach mitigates cost and schedule risk Customer involved throughout the complete cycle minimizes risk of

not achieving customer satisfaction and business needs

Focus moves from documentation to code. Uses modeling concepts to capture information about business, data,

and processes.

4/10/12

Disadvantages
For Large (but scalable) projects, RAD requires sufficient

resources to create the right number of RAD teams.

Not all applications are compatible for RAD. If a system cannot

be properly modularized, building components for RAD will be problematic.

RAD not appropriate when technical risks are high. This

normally occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability.

4/10/12 It requires equal commitment from both customers and

Incremental SDLC Model

Construct a partial

implementation of a total system functionality

Then slowly add increased The incremental model

prioritizes requirements of the system and then implements them in groups. the system adds function to the previous release, until all designed functionality has been implemented.

Each subsequent release of

Incremental Model Strengths

Develop high-risk or major functions

first

Each release delivers an operational

product

Customer can respond to each build Uses divide and conquer breakdown

of tasks
Lowers initial delivery cost Initial product delivery is faster Customers get important functionality
4/10/12

Incremental Model Weaknesses

Requires good planning and design Requires early definition of a complete and

fully functional system to allow for the definition of increments (some will be developed long before others) lower

Well-defined module interfaces are required

Total cost of the complete system is not

4/10/12

When to use the Incremental Model

Risk, funding, schedule, program

complexity, or need for early realization of benefits. front but are expected to evolve over time market early

Most of the requirements are known upA need to get basic functionality to the On projects which have lengthy

development schedules

On a project with new technology

4/10/12

4/10/12

Thank you

4/10/12