THE SYSTEMS DEVELOPMENT LIFE CYCLE

Major Attributes of the Life Cycle

The project -Moves systematically through phases where each phase has a standard set of outputs Produces project deliverables Uses deliverables in implementation Results in actual information system Uses gradual refinement

Systems Development stages

1. 2. 3. 4. 5.
Need for the system Feasibility System Analysis System Design System Documentation

6. 7. 8. 9. 10.

Programming Testing Implementation Training Maintenance

Project Phases
Planning (Why build the system? How should the team go about building it?) Analysis (Who uses system, what will it do, where and when will the system be used?) Design (How will the system work?) Implementation (System delivery)

Planning
Identifying business value Analyze feasibility Develop work plan Staff the project Control and direct project

Analysis
Analysis strategy Gathering business requirements Requirements definition use cases Process modeling Data modeling

Design
Design selection Architecture design Interface design Data storage design Program design

Implementation
Construction
Program building Program and system testing

Installation
Conversion strategy Training plan Support plan

The Systems Development Process

Processes and Deliverables

Process
Planning

Product
System Request Feasibility Analysis Workplan System Proposal System Specification New System and Maintenance Plan

Analysis

Design
Implementation

Systems Development Life Cycle

Project Planning System Analysis System Design Construction Integration and Testing Installation Operation & Maintenance
Testing

SDLC Phases
Project Planning
Put project in context Small part of a much larger system? New system or modify old?

System Analysis
Define user requirements Analyze tasks Develop specifications

System Design - Define the system to be built

Logical design Physical design

SDLC Phases (continued)

Construction
Write (or buy) the code

Integration and Testing

Unit testing, system testing, acceptance testing

Installation
Testing, training, conversion

Operations & Maintenance

Put into production Fix bugs, add facilities

SYSTEM DEVELOPMENT METHODOLOGIES

What Is a Methodology?
A formalized approach to implementing the SDLC
A series of steps and deliverables

Methodology Categories
Process-Centered Data-Centered Structured Design Rapid Application Development Agile Development Object-Oriented

Waterfall Development Methodology

Consists of a set of phases that a project progresses through in a sequential order. Each phase must be completed before the project can progress to the next phase. At the end of each phase is some form of gateway, usually a formal review where that decision is made. There is no overlap between phases. Straight forward, simple to understand and use. Deliverables are frozen at the end of each phase and serve as the baseline for the following phases. You do not see the software until the end of the project (big bang software development). Changes are not supposed to happen or are limited or are tightly controlled.

Strengths of the Waterfall Model

We can see that the waterfall model has many strengths when applied to a project for which it is well suited. Some of these strengths are: The model is well known by nonsoftware customers and end-users (it is often used by other organizations to track nonsoftware projects) It tackles complexity in an orderly way, working well for projects that are well understood but still complex. It is easy to understand, with a simple goal to complete required activities. It is easy to use as development proceeds one phase after another. It provides structure to a technically weak or inexperienced staff. It provides requirements stability. It provides a template into which methods for analysis, ,design, code, test and support can be placed.

Strengths of the Waterfall Model contd

It works well when quality requirements dominate cost and schedule requirements. It allows for tight control by project management. When correctly applied, defects may be found early, when they are relatively inexpensive to fix. It is easy for the project manager to plan and staff. It allows staff who have completed their phase activities to be freed up for other projects. It defines quality control procedures. Each deliverable is reviewed as it is completed. The team uses procedure to determine the quality of the system. Its milestones are well understood. It is easy to track the progress of the project using a timeline or Gantt Chart the completion of each phased is used as a milestone.

Weaknesses of the Waterfall model

We can also note weakness of the model when it is applied to a project for which it is not well suited: It has an inherently linear sequential nature any attempt to go back two or more phases to correct a problem or deficiency results in major increases in cost and schedule. It does not handle the reality of iterations among phases that are so common in software development because it is modeled after a conventional hardware engineering cycle. It doesnt reflect the problem solving nature of software development. Phases are tied rigidly to activities, not how people or teams really work. It can present a false impression of status and progress 35 percent done is a meaningless metric for the project manager.

Weaknesses of the Waterfall model

Integration happens in one big bang at the end. With a single pass through the process, integration problems usually surface too late. Previously undetected errors or design deficiencies will emerge, adding risk with little time to recover. There is insufficient opportunity for a customer to preview the system until very late in the life cycle. There are no tangible interim deliverables for the customer; user responses cannot be fed back to developers. Because a completed product is not available until the end of the process- the user is involved at the beginning while gathering requirements and at the end during acceptance testing. Users cant see quality until the end. They cant appreciate quality if the finished product cant be seen. All training must occur at the end of the life cycle, when the software is running.

Weaknesses of the Waterfall model

It is possible for a project to go through the disciplined waterfall process, meet written requirements, but still not be operational Each phase is a prerequisite for succeeding activities, making this method a risky choice for unprecedented systems because it inhabits flexibility. Deliverables are created for each phase and are considered frozen that is, they should not be changed later in the life cycle of the product. If the deliverable of a phase changes, which often happens, the project will suffer schedule problems because the model did not accommodate, nor was the plan based on managing a change later in the cycle. All requirements must be known at the beginning of the life cycle, yet customers can rarely state all explicit requirements at that time. The model is not equipped to handle dynamic changes in requirements over the life cycle, as deliverables are frozen. The model can be very costly to use if requirements are not well known or are dynamically changing during the course of the life cycle.

Weaknesses of the Waterfall model

Tight management and control is needed because there is no provision for revising the requirements. It is document driven and the amount of documentation can be excessive. The entire software product is being worked on at one time. There is no way to partition the system for delivery of pieces of the system. Budget problems can occur because of commitments to develop an entire system at one time. Large sums of money are allocated, with little flexibility to reallocate the funds without destroying the project in the process. There is no way to account for behind- the scenes rework and iterations.

Pros and Cons of the Waterfall Methodology

Pros
Identifies systems requirements long before programming begins Minimizes changes to requirements as project progresses

Cons
Design must be specified on paper before programming begins Long time between system proposal and delivery of new system

Parallel Development Methodology

Pros and Cons of Parallel Development Methodology

Pros
Reduces Schedule Time Less Chance of Rework

Cons
Still Uses Paper Documents Sub-projects May Be Difficult to Integrate

Rapid Application Development

Incorporate special techniques and tools:
CASE tools JAD sessions Fourth generation/visualization programming languages Code generators

Three RAD Categories

Phased development
A series of versions developed sequentially

Prototyping
System prototyping

Throw-away prototyping
Design prototyping

Phased Development Methodology

Insert Figure 1-4 here

Pros and Cons of Phased Development Methodology

Pros
Users Get a System To Use Quickly Users Can Identify Additional Needs For Later Versions

Cons

Users Work with a System that is Intentionally Incomplete

How Prototyping Works

Used to develop a quick implementation of the software prior to or during the software requirements phase. The customer uses the prototype and provides feedback to the software developers as to its strengths and weaknesses. This feedback is used to refine or change the prototype to meet the real needs of the customer. Can either be evolutionary or throw away.

Pros and Cons of Prototyping Methodology

Pros
Users Interact with Prototype Very Quickly Users Can Identify Needed Changes And Refine Real Requirements

Cons
Tendency to do Superficial Analysis Initial Design Decisions May Be Poor

Prototyping Guidelines

Throwaway Prototyping

Pros and Cons of Throwaway Prototyping Methodology

Pros
Risks are Minimized

Cons
May Take Longer Than Prototyping

Important Issues are Understood Before the Real System is Built

V-SHAPED MODEL
The following list contains a brief description of each phase of the V-Shaped model, from project and requirements planning through acceptance testing. Projects and requirements planning - Determines the system requirements and how the resources of the organization will be allocated to meet them. (Where appropriate, this phase allocates functions to hardware and software). Product requirements and specification analysis Includes analysis of the software problem at hand and concludes with a complete specification of the expected external behavior of the software system to be built. Architecture or high-level design Defines how the software functions are to implement the design.

V-SHAPED MODEL
Detailed design Defines and documents algorithms for each component that was defined during the architecture phase. These algorithms will be translated into code. Coding Transforms the algorithms defined during the detailed design phase into software.. Unit testing Checks each coded module for errors. Integration and testing Interconnects the sets of previously unit-tested modules to ensure that the sets behave as well as the independently tested modules did during the unit-testing phase. System and acceptance testing Checks whether the entire software system (fully integrated) embedded in its actual hardware environment behaves according to the software requirements specification. Production, operation and maintenance Puts software into production and provides for enhancement and corrections. Acceptance testing (not shown) Allows the user to test the functionality of the system against the original requirements. After final testing, the software and its surrounding hardware become operational. Maintenance of the system follows.

V-SHAPED MODEL
Similar to waterfall except it emphasizes the importance of considering the testing activities up front instead of later in the life cycle.
Each test phase is considered in its matching development phase: Requirements == System /Functional Testing High-Level Design == Integration Testing Detailed Design == Unit Testing
REQUIREMENTS SYSTEM TEST PLANNING SYSTEM TESTING

PRELIMINARY DESIGN

INTEGRATION TEST PLANNING

INTEGRATION TESTING

DETAILED DESIGN

UNIT TEST PLANNING

UNIT TESTING

CODING

Strengths of the V-Shaped Model

When applied to a project for which it is well suited, the V-shaped model offers several strengths; The model emphasizes planning for verification and validation of the product in the early stages of product development. Emphasis is placed on testing by matching the test phase or process with the development process . The unit testing phase validates detailed design. The integration and testing phases validate architectural or high - level design. The system testing phase validates the product requirements and specification phase. The model encourages verification and validation of all internal and external deliverables, not just the software product. The V-Shaped model encourages definition of the requirements before designing the system, and it encourages designing the software before building the components. It defines the products that the development process should generate; each deliverable must be testable. It enables project management to track progress accurately; the progress of the project follows a timeline, and the completion of each phase is milestone. It is easy to use (When applied to a project for which it is suited).

Weakness of the V-Shaped Model

When applied to a project for which it is not well suited, the weaknesses of the V-shaped model are evident: It does not easily handle concurrent events. It does not handle iterations of phases. The model is not equipped to handle dynamic changes in requirements throughout the life cycle. The requirements are tested too late in the cycle to make changes without affecting the schedule for the project. The model does not contain risk analysis activities.

Incremental Development
Allows a project to construct the software in incremental stages where each stage adds additional functionality. Each stage consists of design, code and unit test, integration test and delivery. Allows you to put functional software into the hands of the customer much earlier than either the waterfall or V-shaped model. You can plan the stages in such a way that you determine what functionality you do first.
i.e. you may choose to deliver the most important functionality to the customer first.

Provides tangible measures of progress. Requires careful planning at both the project management level and the technical level

SPIRAL
Developed by Barry Boehm. A risk-oriented software life cycle. Each spiral addresses major risks that have been identified. After all the risks have been addressed, the spiral model terminates as a waterfall software life cycle

SPIRAL

Spiral (Iterative) Model

Agile Development: Extreme Programming

Pros and Cons of Agile Methodologies

Pros
Fast Delivery of Results

Cons
Requires Discipline Works Best in Small Projects

Works Well in Projects With Undefined or Changing Requirements

Requires Much User Input

Criteria for Selecting the Appropriate Methodology

Clear user requirements Familiarity with technology Complexity of system Reliability of system Time schedule Schedule visibility

Importance of Testing
Unit Test Make sure the Integration Test system works! Full System Test Stress Testing Field Testing (Alpha and Beta Tests) Regression Testing

Installation: Conversion Strategies

Strategies used to convert from one IS to another

Operations & Maintenance

Activities in Systems Support