©LAWanninger 2001

Systems Development Life Cycle

• Introducing the SDLC (Systems Development Life Cycle)

• First Step: Strategic Analysis (of the Business) and Prioritization of Projects

• Strategic Importance

• Extent of Problem or Opportunity

• Analysis and Design (Prototyping)

• Construction

• Implementation

• Projects 1-5

• Cover the SDLC through Analysis and Design

• Illustrate the roles, responsibilities, and necessary interaction of IS and non-IS people

©LAWanninger 2001

GlobalInformation System

Architecture

IS Development Life Cycle (BUILDING IS)

BUSINESS AREAAnalysis

(Process/Data Flow Diagrams)

DATABASEDESIGN

(Data Model Diagram)

Computers &Communication

Networks

INFORMATION SYSTEM DESIGN- Application Processes

- User Interfaces (Forms+)

DATABASE(Related Tables)

CODE

STRATEGICCompetitiveANALYSIS

generate

executeread/write

define & populate

information requirements

PROCESSES

DATA PLATFORMPlanning

USERINTERFACE

©LAWanninger 2001

Information SystemsDevelopment Life Cycle

PLANNING&

ANALYSIS

DESIGN(MODELING)

CONSTRUCTION(GENERATION)

OPERATION&

MAINTENANCE

PRIORITIES, SCOPE

DESIGN DATABASE"REPOSITORY"

©LAWanninger 2001

Traditional SDLCISDEV

©LAWanninger 2001

The Systems Development Life Cycle (SDLC)

• PLANNING - global architectures, scoping, setting priorities• ANALYSIS - feasibility (technical, economic, operational),

- cost/benefit, - requirements - (WHAT)• DESIGN (synthesis) - (HOW)

Conceptual (business solution) Detailed design (IS solution)• Process modeling (DFD’s)• Data modeling (ER Diagrams)• User Interface (windows, menus, queries, forms, reports...)• Platform design (Computers + Communication Networks)

• CONSTRUCTION - definitions, programming, - (BUILD IT) - testing (unit, system, acceptance)

• INSTALLATION - conversion (direct cutover, parallel, pilot/phased)

• PRODUCTION / OPERATION --• POST-IMPLEMENTATION REVIEW• MAINTENANCE & ENHANCEMENT [& REPLACEMENT]

©LAWanninger 2001

SDLC - Overview and Metaphors

• Phase 1• Project Identification and Selection• Information Requirements & Systems

Analysis• System Design

• Phase 2• Construction, Testing• Implementation• Operation, Support, Maintenance

• QA – throughout• Get requirements right• Develop test cases• Minimize errors and cost• Maximize satisfaction and effectiveness

©LAWanninger 2001

A Marketing View of Information Systems

• SDLC – Life Cycle Model of IT Applications• Consumer Product Development – A

Metaphor for IT Applications• Software Requirements Determination

• MIS Theories 1 & 2• Systems Analysis & Design• Phased/Adaptive Development - "Learning"• Testing & QA• Implementation• Operation• Maintenance and Continual Improvement• Project Success Factors

©LAWanninger 2001

Cake & Frosting

©LAWanninger 2001

Consumer Product Development Metaphor

• Consumer Product Development Attributes• 20 - 30% Success Rate

• Find and Kill Failures Early• Evolution of successes throughout life cycle

• Profit & quality improvement• Proliferation

• Tie directly to business objectives• Lots of up-front time defining the product• Wide variety, series of Prototypes• Measurement & Iteration• Pilots for scale-up• KEY Players on the Team• Mix of creativity, new ways, business analysis,

marketing, expectations, manufacturing• Brand Management model – Matrix

©LAWanninger 2001

Evaluation - Formal Product and Market Research Methods

• Focus groups• Expert panels• Consumer panels• "Church basement" product evaluations• Mall intercepts• In-home tests• Mail consumer panels• Opinion research• Attitude and purchase intent measurement

• Secondary databases• Store scanner databases for product tracking

©LAWanninger 2001

Model of an IT Application

©LAWanninger 2001

Determining Information Requirements

• Two IS Theories• #1 - Managers do not know what information they need

• #2 - Most of the information you need to make a decision comes from outside your area

• Four major mistakes in determining information requirements• Viewing applications as functional

• Cross-functional, one function doesn’t know everything

• Conducting individual interviews • Limited perspective

• Asking wrong questions• Asking them - assumes they know!• Catalog - they ask for all

• Not allowing trial-and error• We must “learn" our requirements

©LAWanninger 2001

Approaches to Get Information Requirements Right

1. View systems as cross-functional• Conduct joint application design – multifunction

2. Broaden the perspective of input• Group vs. individual interviews

3. Ask Right Questions - Structured Interviews• CSFs - focus on business priorities• Ends & means - effectiveness & efficiency focus• Decisions – data needed and methods used• Describe your business process – steps, decisions,

data, errors, options and exceptions• Each of these help get at information requirements

of process, data and interfaces4. Provide means to help people learn their requirements

• Prototyping (Phased-Adaptive Development)• Learn from hands-on experience• View change positively vs. an enemy• Set user expectations & involvement

©LAWanninger 2001

Ends & Means Questions

• Efficiency

What is key to achieving efficiency?

How do you measure your efficiency?

• Effectiveness

What is key to operating effectively?

How do you measure your

effectiveness?

• What kinds of information help you achieve

or measure effectiveness or efficiency?

• Relate these questions to CSFs

©LAWanninger 2001

Decision Questions

• What kinds of decisions must you make - by

business process?

How important are those decisions?

How frequently do they occur?

• What information will help you make those

decisions?

How often do you not have which

information?

• Relate these questions and information needs to

CSFs

©LAWanninger 2001

Cost of Fixing System Defects

Require-ments

Design Develop Test & Debug

User Accept

Install0

20

40

60

80

100

120

140

160

Cost To "Fix System Defects"

©LAWanninger 2001

System Requirements & Design – Primary Source of "Defects" in Systems

• 2/3 of "System Defects" occur in the requirements and design phases• Not doing the "Right Thing",• Or not doing it the "Right Way”

• Problems:• Very high levels of maintenance and cost• Projects are late• Projects are over budget• People are unhappy and not satisfied with the

system or IS• Objectives and Actions:

1. Emphasize getting the requirements right, sooner - prototype, JAD, ask helpful questions, broad perspective

2. Find the errors sooner - QA and testing process3. Reduce the cost of fixing the errors - development

tools, flexible design, QA and testing process

©LAWanninger 2001

Concepts about the SDLC process

• Phased / adaptive development• Phased implementation• Expectations - managing & meeting• Prototypes

• Education, demos, breadth• Construction and testing• Pilot and scale-up• Evaluation

• Throughout, particularly prior to rollout• Group evaluation using marketing research

methods• Rollout

• Expect and seek out problems• Deal quickly with problems

• Anticipate and plan for continued development & change

©LAWanninger 2001

Output of Requirements Determination (P1)

• Relationship between Business and System Priorities

• General Requirements of the System• User Expectations

• Users and MIS people must then work as a team to make sure the "specifications" of a proposed system are "correct", both in terms of WHAT the system is to do, and HOW it is to do it.

• Users must "Correct" the Analysts' Representations

• Next step is systems analysis

©LAWanninger 2001

Systems Analysis & Design (P2-5)

• Study and model the existing business processes, information systems and information flows• Data flow diagrams, process flow diagrams, etc.• Communication vehicle between stakeholders

and implementers• What changes should be made to the processes?

• Study and model the data requirements, and determine the data creators, users and owners• Entity relationship diagrams• “Normalize” the data base for input efficiency• Communication vehicle between stakeholders

and implementers• Prototype to determine the primary interfaces for

the variety of users of the application (input and output)

©LAWanninger 2001

Systems Analysis & Design Models

• Process Design - (Project 2)• WHAT the system does• Process Model (Data Flow Diagram - Context)

• Data Design – (Project 3)• WHAT data will be maintained by the system• Data Model (Entity Relationship Diagram)

• User Interface Design – (Projects 4, 5, and more)• HOW the user will work with the system• Input - Screen layouts and forms, editing,

sequence, interface format, etc.• Output - Reports, queries, etc.• Prototype