bis-m5-planning and implementing information systems

Module 5Planning and

Implementing Information Systems

SDP(Software Development

Process)

Waterfall Model

4

SDLC (Systems Development Life

Cycle)• SDLC is usually used in large information

systems development• SDLC is also known as waterfall method• During each phase, verification activities (e.g.

reviews) are done to ensure quality

5

SDLC Phases

• Requirements Analysis

• System Design

• Construction & Unit Testing

• Functionality Testing (System Testing & User Acceptance Testing)

• Implementation

• Support & Maintenance

6

Requirements Analysis• Defines the functional and technical

characteristics of the system• Systems analysis: five-step process

– Investigation

– Technical feasibility study (h/w, s/w)

– Economic feasibility study (Cost/benefit analysis, Return on investment (ROI))

– Operational feasibility study

– Requirements Definition

• Output: Requirements specification document

7

Requirements Analysis (continued)

Figure 12.3: Phases in systems analysis

8

Requirements Analysis (continued)

Figure 12.4: Estimated benefits and costs of an IS ($000)

9

System Design• Define

– Software architecture

– Data structures

– Interface requirements

– Algorithms

• Tools used– Data Flow Diagrams

– Unified modeling language (UML), which consists of use-cases and actors

• Output: System Design Document

10

Construction & Unit Testing• Construction

– Programming

– Unit Testing of completed modules

11

FunctinalTesting• System testing

– Test the entire integrated system for system functionality (includes the verification of the integrated software system, system interfaces, databases, performance, security etc)

• User Acceptance Testing– The business user will test whether his

requirements are met, by testing the business processes provided in the new system

12

Implementation

• Do Data Conversion (if required)• Move the new system to production• Training to client (users, operators etc)

13

Support & Maintenance

• Support– Service Desk (User Support)

– Production Support (Technical Support)

• Maintenance– Post-implementation debugging

– Updates

– Adding postponed features

• Longest phase of system life cycle

14

V-Shaped SDLC Model

• A variant of the Waterfall that emphasizes the verification and validation of the product.

• Testing of the product is planned in parallel with a corresponding phase of development

15

V-Shaped SDLC Model

Other Software Development Methods

17


– Treat software development as series of contacts with users

– Fast development of software

– Improve software after user specifications received

– Iterative programming

18


– Agile software development

– Rapid Application Development

– Extreme programming (XP)

– Adaptive software development (ASD)

– Lean development (LD)

– Rational unified process (RUP)

– Feature driven development (FDD)

– Dynamic systems development method (DSDM)

– Scrum

– Crystal

19


• Risks– Analysis phase limited or eliminated

• Risk of incompatibilities

– Less documentation• Difficult to modify

• Manifesto for Agile Software Development prioritizes individuals and interactions over processes

• Light but sufficient development process

20


Figure 12.10: Agile methods emphasize continuous improvement basedon user requests

21


• User involvement encouraged throughout process

• Test modules immediately after completion• Communication with users informal• Two programmers per module• Dominoes Pizza successfully implemented agile

method

22

Spiral SDLC Model

• Adds risk analysis, and 4gl RAD prototyping to the waterfall model

• Each cycle involves the same sequence of steps as the waterfall process model

23

Spiral SDLC Model

System Integration

25

Systems Integration• Systems integration: combine disparate

systems– Examines needs of entire organization

– Allows data to flow between units

– Some service companies specialize in this

– Integration more challenging than development

– Interface legacy systems with new systems

26

Systems Integration (continued)

Figure 12.12: Situations calling for systems integration

27

Systems Integration (continued)

• Systems integrators must be skilled in hardware and software

• Difficult to overcome incompatibility issues• Systems integration may span several

organizations• Integration with telecommunications

Summary

29

Summary• IT planning important because of high

investment rate• Standardization important part of IT planning• Systems development life cycle (SDLC) has

well-defined phases• Purpose of systems analysis is to determine

needs the system will satisfy

30

Summary (continued)• Feasibility studies determine if system is

possible and desirable• System requirements detail features needed• Developers outline system components

graphically• Unified Modeling language used to create model

of desired system• Implementation includes training and conversion

to new system

31

Summary (continued)• Support entails maintenance and satisfying

changing needs• Agile methods are popular alternative to

traditional systems development cycle• Systems integration more complicated than

systems development• Great responsibility of IS professionals results in

certification requirements

Quality

33

Quality – the degree to which the software satisfies stated

and implied requirements• Absence of system crashes• Correspondence between the software and the

users’ expectations• Performance to specified requirements

Quality must be controlled because it lowers production speed, increases maintenance costs and can adversely affect business

System Integration

35

Quality Assurance Plan

• The plan for quality assurance activities should be in writing

• Decide if a separate group should perform the quality assurance activities

• Some elements that should be considered by the plan are: defect tracking, unit testing, source-code tracking, technical reviews, integration testing and system testing.

36

Quality Assurance Plan

• Defect tracing – keeps track of each defect found, its source, when it was detected, when it was resolved, how it was resolved, etc

• Unit testing – each individual module is tested• Source code tracing – step through source code line

by line• Technical reviews – completed work is reviewed by

peers• Integration testing -- exercise new code in

combination with code that already has been integrated

• System testing – execution of the software for the purpose of finding defects.

CMMi version 1.2

38

Capability Maturity Model Integrated

• CMMi was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University.

• CMMI models provide guidance for developing or improving processes that meet the business goals of an organization

• A CMMi model may also be used as a framework for appraising the process maturity of the organization

• CMMi defines 5 levels of process maturity• CMMi 1.2 of Aug 2006 provides models for development,

acquisition & service• CMMi1.2 covers 22 Key Process Areas that need

attention to improve the processses

39

Levels of the CMMi• Initial (chaotic, ad hoc, individual heroics) - the

starting point for use of a new process.• Managed - the process is managed according to

the metrics described in the Defined stage.• Defined - the process is defined/confirmed as a

standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions).

• Quantitatively managed• Optimized - process management includes

deliberate process optimization/improvement.

40

CMMi Maturity Levels

[4]Buchholtz & Cordes[4]Buchholtz & Cordes

41

CMMi Maturity Levels & KPAs

Maturity Key Process Area

2 Requirements Management

2 Project Monitoring and Control

2 Project Planning

2 Supplier Agreement Management

2 Configuration Management

2 Measurement and Analysis

2 Process and Product Quality Assurance

3 Product Integration

3 Requirements Development

3 Technical Solution

3 Validation

42

CMMi Maturity Levels & KPAs

3 Verification

3 Organizational Process Definition +IPPD

3 Organizational Process Focus

3 Organizational Training

3 Integrated Project Management +IPPD

3 Risk Management

3 Decision Analysis and Resolution

4 Organizational Process Performance

4 Quantitative Project Management

5 Organizational Innovation and Deployment

5 Causal Analysis and Resolution

4444

Software Risk Management

• What is Risk?– An uncertain event or condition that, if it occurs, has a

positive or negative effect on a project objective.

• What is Risk management?– Systematic process of identifying, analyzing and

responding to project risk.– Includes maximizing the probability and consequences

of positive events and minimizing the probability and consequences of adverse events of the project.

4545

Boehm’s Top 10 Risks in Software development

• Unrealistic Schedules and Budgets: Detailed, multisource cost and schedule estimation; design to cost; incremental development; software reuse; requirements scrubbing.

• Developing the wrong software functions: Organizational analysis; mission analysis; operational concept formulation; user surveys; prototyping; early users’ manuals.

• Personnel Shortfalls: Staffing with top talent; job matching; team-building; morale-building; cross-training; prescheduling key people.

• Developing the wrong user interface: Prototyping; scenarios; task analysis.

• Gold-plating. Requirements scrubbing: prototyping; cost-benefit analysis; design to cost.

4646

1.2.2 Boehm’s Top 10 Risks in Software development

• Continuing stream of requirements changes: High change threshold; information-hiding; incremental development (defer changes to later increments).

• Shortfalls in externally-performed tasks: Reference-checking; pre-award audits; award-fee contracts; competitive design or prototyping; team-building.

• Shortfalls in externally-furnished components: Benchmarking; inspections; reference checking; compatibility analysis.

• Real-time performance shortfalls: Simulation; benchmarking; modeling; prototyping; instrumentation; tuning.

• Straining computer science capabilities: Technical analysis; cost-benefit analysis; prototyping; reference checking.

4747

3.3.4 – Risk Identification : Tools & Techniques: Probability &

Consequence Which illustration depicts the higher risk?

Consequence = Probability =

Risk =

High Low

Consequence = Probability =

Risk =

Low Medium

Medium Low

• Probability or consequence of a risk condition is not, by itself, a good measure of risk

4848

Qualitative Risk Analysis: Tools & Techniques

LowConsequence

MediumConsequence

HighConsequence

HighProbability

MediumRisk

HighRisk

HighRisk

MediumProbability

LowRisk

MediumRisk

HighRisk

LowProbability

LowRisk

LowRisk

MediumRisk

The Risk Scoring Matrix

4949

Quantitative Risk Analysis

• Aims to analyze numerically the probability of each risk and its consequences on project objectives, as well as overall project risk.

5050

3.5 – Outputs from Risk Analysis– Determination of top risks

– Opportunities to pursue

– Opportunities to ignore

– Threats to respond to

– Threats to ignore

5151

3.6.1 – Risk Response Planning : Tools & Techniques (ATMA)

Avoidance• Some risks may be avoided• Changing the project plan to eliminate the risk• Risks that arise early in the project can be dealt with by

• Clarifying requirements• Obtaining information• Improving communication• Acquiring expertise

Examples:-• Reducing scope to avoid high risk activities• Adding resources or time• Adopting familiar approach instead of innovative one• Avoiding unfamiliar subcontractors

5252

3.6.2 – Risk Response Planning : Tools & Techniques

Transference– Seeking to shift the consequence of a risk to a third

party together with ownership of the response.– Another party becomes responsible, it does not

eliminate the risk– Involves payment of a risk premium to the party taking

the responsibility

5353


Mitigation– seeks to reduce the probability or consequences of an

adverse event– Takes the form of implementing new course of action

5454


Acceptance– Indicates that the project team has decided not to

change the project plan– Contingency plan is applied to the identified risks– Fallback plan is developed if the risk has a high

impact, or a selected strategy may not be fully effective.

– Usual risk response for this situation is to establish contingency allowance

bis-m5-planning and implementing information systems

Documents