INTRODUCTION TO SYSTEM DEVELOPMENT LIFE CYCLES

WHAT IS AN INFORMATION SYSTEM (IS)?

Hardware, software, data, people, and procedures that

work together to produce quality information

System—Set of components that interact to achieve

common goal

Businesses use many types of systems

WHAT ARE THE PHASES OF THE SYSTEM DEVELOPMENT CYCLE?

Phase 1. Planning

Phase 2. Analysis

Phase 3. Design

Phase 4. Implementation

Phase 5. Support

Review project requests Prioritize project

requests Allocate resources Identify project

development team

Conduct preliminary investigation Perform detailed analysis activities:

Study current systemDetermine user requirementsRecommend solution

Acquire hardware and software, if necessary

Develop details of system

Develop programs, if necessary Install and test new system Train users Convert to new system

Conduct post-implementation system review

Identify errors and enhancements Monitor system performance

WHO PARTICIPATES IN THE SDLC?

WHAT IS A SYSTEMS ANALYST?

Responsible for designing Responsible for designing and developing and developing

information systeminformation system

Liaison between users Liaison between users and IT professionalsand IT professionals

WHAT IS THE PROJECT TEAM?

Consists of users, systems analyst, and other IT professionals

Formed to work on project from beginning to end

Project leader—one member of the team who manages and controls project budget and schedule

WHAT IS FEASIBILITY?

Measure of how suitable

system development will be to the

company

Operational feasibility

Schedule feasibility

Four feasibility tests:

Technical feasibility

Economic feasibility

(also called cost/benefit feasibility)

WHAT IS DOCUMENTATION?

Includes reports, diagrams, programs, and other deliverables

Collection and summarization of data and information

WHY CREATE (OR MODIFY) AN INFORMATION SYSTEM?

Competition can lead to change

To improve existing system

Outside group may mandate change

To correct problem in existing system

WHAT IS A REQUEST FOR SYSTEM SERVICES? Formal request for

new or modified information system Also called

project request

PLANNING PHASE

Begins when steering committee receives project request

Steering Steering committeecommittee——

decision-making decision-making body for the body for the

companycompany

Function of committee:

Review and Review and approve project approve project

requestsrequests

Allocate Allocate resourcesresources

Form project Form project development development team for each team for each

approved approved projectproject

Prioritize Prioritize project requestsproject requests

ANALYSIS PHASE

Conduct preliminary Conduct preliminary investigation, also investigation, also

called feasibility called feasibility studystudy

Perform detailed Perform detailed analysisanalysis

PRELIMINARY INVESTIGATION Determine exact nature of problem or improvement

and whether it is worth pursuing Findings are presented in feasibility report, also known as a feasibility study

DETAILED ANALYSIS

Sometimes called logical design

2. Determine user’s wants, needs, and requirements

3. Recommend solution

1. Study how current system works

SYSTEM PROPOSAL

Presented to Presented to steering steering

committee, committee, which decides which decides

how system will how system will be developedbe developed

Assesses Assesses feasibility feasibility

of each of each alternative alternative solutionsolution

Recommends Recommends the most the most feasible feasible

solution for solution for the projectthe project

IDENTIFY POSSIBLE SOLUTIONS

Buy packaged software—prewritten software available for purchase

Outsource—have outside source develop software

Write own custom software—software developed at user’s request

Vertical market software—designed

for particular industry

Horizontal market software—meets

needs of many companies

DESIGN PHASE

Acquire hardware and software

Develop all details of new or modified information system

Visit vendors’ storesVisit vendors’ stores

ACQUISITIONWhat is needed to acquire new hardware and software? Identify all hardware and software requirements of new or modified system

Surf WebSurf Web

Read print and Read print and online trade journals, online trade journals,

newspapers, and newspapers, and magazinesmagazines

Talk with other Talk with other systems analystssystems analysts

HOW TO TEST SOFTWARE PRODUCTS?

References from vendor Talk to current users of product Product demonstrations Trial version of software Benchmark test measures performance

DETAILED DESIGN

Includes several activities

Database design

Input and output design

Program design

Detailed design specifications for components in proposed solution

PROTOTYPING TOOLS/METHODS: MOCKUP Sample of input or output that contains actual data

PROTOTYPING TOOLS/METHODS: PROTOTYPE

Working model of proposed system

Beginning a prototype too early may lead to

problems

PROTOTYPING TOOLS/METHODS: CASE CASE (Computer-Aided Software Engineering) tools

support activities of the SDLC

Convert to new systemConvert to new system

IMPLEMENTATION PHASE Purpose is to construct, or build, new or modified

system and then deliver it to users

Train usersTrain users

Install and test new systemInstall and test new system

Develop programsDevelop programs

TESTINGThree kinds of tests performed by system developers:

Verifies application works with other

applications

Systems test

Integration Test

Unit Test

Verifies each individual program

works by itself

Verifies all programs in application work

together

TRAINING Showing users exactly how they will use new

hardware and software in system

SUPPORT PHASE

Conduct post-implementation system review—meeting to find out if information system is performing according to expectations

Identify errors

Identify enhancements

Monitor system performance

Providing ongoing assistance after the system is implemented

FEASIBILITY Every organization which performs system

development, or has it done for them, needs a way to choose which projects are worth the effort

Feasibility study is a common approach to make such decisions thoughtfully

Basis for feasibility study is generally the problems and opportunities analysis

PROBLEMS & OPPORTUNITIES We can look for problems and opportunities

in many parts of our organization, and the existing systems which are supported Track maintenance costs for existing systems Measure existing processes to determine their

cost, and compare to industry standards Monitor availability of support for existing

system components Look for signs of unhappy employees

Check quality of work products (outputs) Listen to customers, vendors, and suppliers

Both complaints and suggestions Measure customer satisfaction Monitor competitor’s offerings and plans Monitor changes in technology which could help Don’t forget obvious measures of success, like

sales, profit, or number of contracts awarded

PROBLEMS & OPPORTUNITIES

PROJECT SELECTION Selection of projects is based on many

factors – cost, urgency, the systems affected, etc.

From the organization’s perspective, choosing projects is kind of like shopping There’s generally a limited amount of funds

and people available to work on the possible projects, and management needs to choose which projects to support

There are five typical requirements for a project to be supported Management support for the project Appropriate timing of commitment to the project Relevance to helping meet organizational goals Project must be practical and feasible Project must be worthwhile compared to other

possible expenditures Are we getting enough ‘bang for our buck?’

PROJECT SELECTION

PROJECT OBJECTIVES Based on the problems and opportunities

identified for a project, we can set objectives for the project These not only help the feasibility study which

follows, but set goals against which we can later test the system

Objectives should not only address the type of improvement sought, but set a desired level of improvement

Examples of objectives might include Improve customer satisfaction 10% within 1 year Reduce the response time for customer

complaints by 15% Get a new feature to market before competitors Reduce error rate for data entry from 2% to 0.5% Improve sales to new customers by 5% Reduce voluntary employee turnover by 10%

PROJECT OBJECTIVES

FEASIBILITY ANALYSIS

Feasibility consists of several types we want to assess for each candidate project Technical feasibility

Can the project be done with existing technology? Are people available to use the technologies needed?

Economic feasibility How much does the system cost to develop? Maintain?

How long will it be usable? Some add schedule feasibility – how long will it take

to create the system?

Operational feasibility What impact will the new system have on how we do

business? Will there be changes to where or how processes are performed?

Will there be changes to employee skills needed? Changes to employee training?

Are existing users amenable to a new system? These types of feasibility can be measured

for each project, and compared to determine which is most feasible

FEASIBILITY ANALYSIS

Like voting or buying a car, feasibility analysis is rarely completely logical or quantifiable

Many other issues can also affect it Political climate State of the US and/or global economy Preferences of the decision makers – favored

vendors, technologies, types of projects, etc.

FEASIBILITY ANALYSIS

PLANNING ACTIVITIES To help structure development activities, we

use a life cycle model to identify the major sets of activities, called life cycle phases

There are many kinds of life cycle models The Waterfall model is the oldest, and uses

phases like Requirements Analysis, High Level Design, Low Level Design, Coding, and Testing

The Rational Unified Process has Inception, Elaboration, Construction, and Transition phases

Each life cycle phase is broken down into more and more specific activities, until the time needed for each activity can be reliably estimated

Then the tasks are put into a Gantt chart or Pert chart to show when they occur relative to each other Tasks might occur sequentially, have to start

or end together, or wait for some other tasks to be completed

PLANNING VIA THE SDLC

Tasks for a project often include the acts of creating specific documents or work products, approving things or making decisions; such as ‘Prepare system test plan’ ‘Approve system release’ ‘Conduct user satisfaction survey’ ‘Approve system requirements specification’

So the life cycle model provides guidance on the types of activities needed, but the tasks provide authority for people to do them

PLANNING VIA THE SDLC

WATERFALL MODEL

FEATURES OF A WATERFALL MODEL

A waterfall model is easy to follow. It can be implemented for any size project. Every stage has to be done separately at the right

time so you cannot jump stages. Documentation is produced at every stage of a

waterfall model allowing people to understand what has been done.

Testing is done at every stage.

ADVANTAGES OF A WATERFALL MODEL

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

DISADVANTAGES OF A WATERFALL MODEL

All requirements must be known up front 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 Integration is one big bang at the end Little opportunity for customer to preview the

system (until it may be too late)

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.

AGILE SDLCS

Speed up or bypass one or more life cycle phases

Usually less formal and reduced scope Used for time-critical applications Used in organizations that employ disciplined

methods

AGILE MANIFESTO

SOME AGILE METHODS Adaptive Software Development (ASD) Feature Driven Development (FDD) Crystal Clear Dynamic Software Development

Method (DSDM) Rapid Application Development (RAD) Scrum Extreme Programming (XP) Rational Unify Process (RUP)

EXTREME PROGRAMMING - XP

For small-to-medium-sized teams developing software with vague or rapidly changing requirements

Coding is the key activity throughout a software project

Communication among teammates is done with code

Life cycle and behavior of complex objects defined in test cases – again in code

XP PRACTICES (1-6)

1. Planning game – determine scope of the next release by combining business priorities and technical estimates

2. Small releases – put a simple system into production, then release new versions in very short cycle

3. Metaphor – all development is guided by a simple shared story of how the whole system works

4. Simple design – system is designed as simply as possible (extra complexity removed as soon as found)

5. Testing – programmers continuously write unit tests; customers write tests for features

6. Refactoring – programmers continuously restructure the system without changing its behavior to remove duplication and simplify

XP Practices (7 – 12)

7. Pair-programming -- all production code is written with two programmers at one machine

8. Collective ownership – anyone can change any code anywhere in the system at any time.

9. Continuous integration – integrate and build the system many times a day – every time a task is completed.

10. 40-hour week – work no more than 40 hours a week as a rule

11. On-site customer – a user is on the team and available full-time to answer questions

12. Coding standards – programmers write all code in accordance with rules emphasizing communication through the code

XP is “extreme” because

Commonsense practices taken to extreme levels

If code reviews are good, review code all the time (pair programming)

If testing is good, everybody will test all the time If simplicity is good, keep the system in the simplest design that

supports its current functionality. (simplest thing that works) If design is good, everybody will design daily (refactoring) If architecture is important, everybody will work at defining and

refining the architecture (metaphor) If integration testing is important, build and integrate test

several times a day (continuous integration) If short iterations are good, make iterations really, really short

(hours rather than weeks)

SUMMARY

This has been a (very) quick tour through the life cycle of a system.

You will have to do—to some extent—all of these activities for your project.