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
Other Software Development Methods
– Treat software development as series of contacts with users
– Fast development of software
– Improve software after user specifications received
– Iterative programming
18
Other Software Development Methods
– 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
Other Software Development Methods
• 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
Other Software Development Methods
Figure 12.10: Agile methods emphasize continuous improvement basedon user requests
21
Other Software Development Methods
• 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
Risks
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
3.6.3 – Risk Response Planning : Tools & Techniques
Mitigation– seeks to reduce the probability or consequences of an
adverse event– Takes the form of implementing new course of action
5454
3.6.4 – Risk Response Planning : Tools & Techniques
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