Sdlc

CSC 2202 Systems Analysis and Design

2. The Systems Development Life Cycle

(SDLC)


The System Development Life Cycle

It was started in the 1960s and 1970s as the first

documented approach to computer systems

development. All the stages of the development

system are thought about, planned, monitored

and Completed. SDLC is the process by which an

Information System comes to life and maintains

its usefulness to a business as it moves from

inception to replacement.


Business need - changing business conditions prompt request for new/improved computer system

System development - analyse, design and implement a system to meet the business need

System installation - move new system into production

System Development Life Cycle


System operation - period of active use

System obsolescence - system no longer reflects changed business needs

System Development Life Cycle


Need

Develop

Install

Operate

Obsolete

System Life Cycle - illustration


Critical Success Factors for Systems Development:effectively meet the stated business needsbuild a flexible and maintainable systembuild a reliable systemproduce a system on time and within

budget

System Development Challenges


The phases of the SDLC are described

Differently depending on the author:

Kendall & Kendall terminology

Shelly terminology

Powers et al terminology

Etc.

Terminologies for the SDLC phases


Investigation Identify problems and opportunities

Determine requirements

Analysis

Design

Develop software

System Test

Implement and evaluate

System Development Life Cycle(Kendall & Kendall terminology)


System Development Life Cycle(Kendall & Kendall terminology)


Systems planning Preliminary investigation report

Systems analysis System requirements document

Systems design System design specification

Systems implementation Complete functioning information system

Systems operation and support Operational information system

Systems Development Life Cycle(Shelly terminology)


SDLC – (Shelly terminology)

.


Systems planning Purpose – identify problem’s nature/scope Systems request – begins the process &

describes desired changes/improvements Systems planning – includes preliminary

investigation or feasibility study End product – preliminary investigation report

Systems Development Life Cycle


Systems analysis Purpose is to learn exactly how the current

system operates Fact-finding or requirements

determination is used to define all functions of the current system



Options Develop a system in-house Purchase a commercial package Modify an existing system Stop development

The end product for this phase is the systems requirements document



Systems designPurpose is to satisfy all documented

requirements Identify all outputs, inputs, files, manual

procedures, & application programsAvoid misunderstanding through manager and

user involvementEnd product is system design specification



Systems implementationConstruct/deliver information system Prepares functioning, documented systemWrite, test, document application programsUser and manager approval obtainedFile conversion occursUsers, managers, IS staff trained to operate and

support the systemPost-implementation evaluation performed



Systems operation and supportNew system supports business operationsMaintenance changes correct errors or meet

requirementsEnhancements increase system capabilityAfter several years of operation, systems

experience need for extensive changes Systems development life cycle ends with

system replacement



2. Determine requirements

3. Analysis

4. Design

5. Develop software

1. Investigation -Identify problems, opportunities

6. System Test

7. Implement and evaluate

System Development Life Cycle illustration


Many organisations and many authors use different terminology for the phases of the SDLC

However essentially the same activities are performed

Refer to examples of other terminology

Other Terminology for SDLC phases


Investigation phase

Analysis and General Design phase

Detailed Design and Implementation phase

Installation phase

Review phase

System Development Life Cycle(Powers et al terminology)


Initial investigation

Feasibility studyFinancial feasibilityTechnical feasibilityOperational feasibilityLegal /ethical feasibility

Investigation phase


Existing system review build model of existing system

New system requirements from User’s point of view

New system design sufficient information for management to decide

whether to proceed

Implementation and Installation planning plan to cover next phases

Analysis and General Design phase


Technical design for programs (pseudo-code), files, records, reports,

screens

Test specifications and Testingprepare test plansProgramming and Testing write and test program code

User TrainingSystem and Acceptance test by Users, simulating production conditions

Detailed Design and Implementation phase


File conversion run programs to convert files into new format

System installation critical system transition to production

Options for installation are: Cutover can be abrupt Operate old and new systems in parallel

(for 2 weeks) Phase in new system, over time Install version of the system

Installation phase


Development recap team review of project, for benefit of

future projects

Post implementation review evaluate how well the system is working to what extent are project benefits being

achieved?

Review phase


Business SurveyFeasibilitySystems AnalysisSystems DesignProgrammingTestingImplementationPost Implementation ReviewMaintenance

S D L C Phases (general)



Management needs to know:project is on timeproject is within budget

These project control stages (checkpoints) are the end of each phase of the System Development Life Cycle

Why have a System Development Life Cycle?


Initial broad term report

Estimate:project costproject resources (people)project time

Recommend whether go on to Feasibility

1. Business Survey


Assess feasibility of the project:operational feasibility technical feasibility financial feasibility

Identify possible solutions and optionsRecommend most appropriate to managementOutline of development plan

2. Feasibility


Information GatheringUser Requirements refined to specify the new systemGoal - User Requirements Document design for the new system just enough technical detail

for the customer

Report contents geared towards customer

3. Systems Analysis


Convert User Requirements into computer terms

Specify how system will operatewhat programs are neededwhat the programs will do

4. Systems Design


Convert specifications into program codePrepare test plans for unit testing (individual programs)

5. Programming and Design Aim


Design aim must ensure that the system is: Accurate • Implementable Maintainable • Acceptable Timely • Flexible Robust • Economic Efficient • Secure Compatible • Portable

5. Programming and Design Aim


System Testing & Acceptance Testing

System Testing test program as part of the whole

system e.g. new program in whole payroll system

6. Testing - make system “bullet proof”


Acceptance TestingCustomers / Users now involvedusually have their own test planssometimes also use programmer

tests

Sign-Off document - signed by Customer Coordinator

6. Testing - make system “bullet proof”


Implementation Plan or Update Log

Provides project leader with a list of all: files - new / amendedscreen messages - new / amendedprograms (sources) - new / amended

Timing for lodgment in production environment decided with customer

7. Implementation


BUILDING of the system is now complete

Development recap team review - what can be learned from the

project

Post Implementation Review (after 3 or 4 months) degree to which system meets objectives often results in recommended improvements

8. Post Implementation Review


Ensure customer changes to the system: retain quality adhere to standards and procedures

Now back at the beginning of the SDLCSize of maintenance change will determine whether all (or subset of) phases of the system Development Life Cycle are required

9. Maintenance


Life-Cycle Models

1. The waterfall model

2. The spiral model

3. Rapid application development

4. Joint application development

5. The V model


Each Phase of SDLC has an “Output”

PhaseRequirements analysis

Design

Implementation

Test

OutputSoftware Requirements Specification (SRS),

Design Document,Design ClassesCode

Test Report, Change Requests


“Life-Cycle” Models

Single-Version Models

Incremental ModelsSingle-Version with Prototyping

Iterative Models


“Life-Cycle” Models (1)

Single-Version ModelsWaterfall Model

Waterfall Model with “back flow”

“V” model: Integrating testing


Incremental vs. Iterative

These sound similar, and sometimes are equated.

Subtle difference: Incremental: add to the product at each phase Iterative: re-do the product at each phase

Some of the models could be used either way


The waterfall modelFirst described by Royce in 1970

There seem to be at least as many versions as there are authorities - perhaps more

The Waterfall model


Waterfall Model

Requirements

Design

Implementation

Test

Each phase “pours over” into the next phase.


Waterfall Model

Managers love waterfall models:Nice milestonesNo need to look back (linear system), one

activity at a timeEasy to check progress : 90% coded, 20%

tested


Waterfall Model

Traditional life cycleAnalysis, design, code, test & maintenanceTop down rigidityNo iteration between phasesDifficult accommodating uncertainty & riskBlack box approach


Why Not Waterfall?

2. Requirements are not stable/unchanging.

The market changes—constantly.

The technology changes.

The goals of the stakeholders change.


Why Not Waterfall?3. The design may need to change during implementation.

Requirements are incomplete and changing.

Too many variables, unknowns, and novelties.

A complete specification must be as detailed as code itself.

Software is very “hard”. Discover Magazine, 1999: Software characterized as the most

complex “machine” humankind builds.


V - Model

The V Model Distinguishes between Development and Verification Activities


V - ModelEach phase has corresponding test or validation counterpart

Requirements Analysis

System Design

Program Design

Implementation

Unit Test

Integration Test

Acceptance Test


V - ModelLevel of Detail

Project Time

Low

High

AcceptanceTesting

Problem with V-Model: Client’s Perception is the same as the Developer’s Perception

Client’s UnderstandingDeveloper’s Understanding

RequirementsElicitation

Analysis

Design

System Testing

Object Design Unit Testing

Integration Testing


Problems with V - Model

The V model does not model iteration


Boehm Spiral Model

Four major activities

1. Determination of objectives, alternatives, and constraints

2. Risk analysis and prototyping

3. Waterfall approach to next level product

4. Plan for the next phase cycle:


Boehm Spiral Model


Identify risks

Assign priorities to risks

Develop a series of prototypes for the identified risks starting with the highest risk.

Use a waterfall model for each prototype development (“cycle”)

If a risk has successfully been resolved, evaluate the results of the “cycle” and plan the next round

If a certain risk cannot be resolved, terminate the project immediately

Spiral Model Deals with Iteration


Limitations of the Waterfall and Spiral Models

Neither of these model deals well with frequent change The Waterfall model assume that once you are

done with a phase, all issues covered in that phase are closed and cannot be reopened

The Spiral model can deal with change between phases, but once inside a phase, no change is allowed

What do you do if change is happening more frequently? (“The only constant is the change”)


Rapid Application Development

RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles.

This has a number of distinct advantages over the traditional sequential development model.




Iteration allows for effectiveness and self-correction. Iterations results into many small refinements and improvements. An important, fundamental principle of iterative development is that each iteration delivers a functional version of the final system



Like prototyping, uses iterative development

Uses tools to speed up development GUI reusable code code generation programming, language testing and debugging



RAD projects are typically staffed with small integrated teams comprised of developers, end users, and IT technical resources. Small teams, combined with short, iterative development cycles optimizes speed, unity of vision and purpose, effective informal communication and simple project management.


Rapid Application DevelopmentHigh SpeedHigh QualityAnd Lower Cost Quality is a primary concept in the RAD environment. Systems developed using the RAD development path meet the needs of their users effectively and have low maintenance costs.


Preliminary working version of a system (or one of its parts) built quickly and inexpensively using “friendly, powerful” software reviewed by end userssuggest changes for system improvements.

Prototyping


Iterative process, say 10 versionsResult - evolve to become final system, or... throw away, but clarified SDLC requirements

Prototyping


Identify Basic User RequirementsIdentify Basic User Requirements

Rapidly Develop PrototypeRapidly Develop Prototype

Users work with PrototypeUsers work with Prototype

Obtain User FeedbackObtain User Feedback

Modify the PrototypeModify the Prototype

IterativeIterativeenhancementenhancement

ThrowawayThrowawayPrototypePrototype

EvolutionaryEvolutionaryPrototypePrototype

Prototyping Process


Prototype

Steps followed by a systems analyst using a prototype during the systems analysis phase are shown


Prototype

*


Prototyping can help to obtain complete and reliable system requirements

Prototyping process: iterativeUser works with latest version of prototype

to determine the refined requirementsprototype quickly amended (by the User

and systems analyst)

Prototyping


Interactive software development tools

Allows designer to quickly:design screens, create files, data entry

routines, basic reporting functions

Tools should be flexible and easy to use

Prototyping tools


Prototyping goal is to enhance the System development process. Prototyping focuses on the Analysis and General Design phase.Outcome – one extreme is prototype actually becomes the

finished system (after many iterations) other extreme is throw away prototype and

build system using conventional methods BUT now have very high level of confidence

with accuracy and completeness of User Requirements

Prototyping and the SDLC


Prototyping

Performing analysis, design, and implementation phases concurrently, and repeatedly

Users see system functionality quickly and provide feedback

Decision maker learns about problem

But can lose gains in repetition


Prototyping

Design

Implementation

Analysis

Need

Planning

Prototype

System

Prototype Not OKPrototype OK


Uses of Prototyping Verifying user needs

Verifying that design = specifications

Selecting the “best” design

Developing a conceptual understanding of novel

situations


Uses of Prototyping Testing a design under varying environments

Demonstrating a new product to upper

management

Implementing a new system in the user

environment quickly


Prototyping

Proposed AdvantagesImproved user

communicationUsers like itLow riskAvoids over-designExperimentation

and innovationSpreads labor to

user department

Disadvantages in practice Prototypes are used “as is”

Integration often difficult

Design flaws Poor performance

Difficult to manage process Creates unrealistic

expectations Documentation is difficult


Advantages of Prototyping

Short development time

Short user reaction time

Improved user understanding

Low cost


Disadvantages of Prototyping

Gains may be lost in

Thorough understanding information System’s benefits and costs

Detailed description of information needs

Easy to maintain IS design

Well-tested IS

Well-prepared users


Alternative methodologies to SDLC are: Structured approaches.

Structured System Analysis & Design Methodology

YourdonJackson system developmentMerise Work flow systems

Prototyping.

Alternative system development methodologies


Alternative methodologies to SDLC are: Joint Application DevelopmentRapid Application DevelopmentObject oriented analysis and design.Soft Systems Methodology.

Alternative system development methodologies


JAD

Joint application development (JAD) Task force of users, managers, and IS staff Objectives

Gather information Discuss business needs Define the new system requirements

Methods Team usually meets at specific location Team has project leader and recorder(s) Key users participate in intense development effort

JAD can be costly, but highly effective

PackageClick to see Figure 3-11


RADRapid application development (RAD) Team method similar to JAD, but goes further RAD phases resemble a mini-SDLC

Requirements planning, user design, construction, and cutover

RAD involves a continuous design process Team can react quickly Final objective is a functioning system

RAD can be faster and less costly, but stresses system mechanics rather than strategic needs


OOAD

Object-oriented (O-O) systems development Object-based model Objects and their attributes are abstract entities Classes and subclasses


Review Questions

1. List and describe the major stages of the systems development life cycle.

2. What is prototyping and what advantages does it offer in the SDLC?

3. Explain why the investigation phase and the initial analysis and design phases are perhaps the most critical stages of the SDLC.

4. Explain the systems life cycle and describe why this concept is important to systems developers.

Date post:	14-Nov-2014
Category:	Documents
Upload:	api-27124815
View:	51 times
Download:	2 times

Sdlc

Documents