SE LifeCycle Paradigm

1
SE Life-Cycle Paradigm
1. Traditional Waterfall Model - Validation
Verification understood, but only made explicit
in the Testing phase.
System Engineering
Maintenance
2
An Example of the Waterfall Process Model
Requirements Gathering Analysis
Architectural Design
HLD / I1
LLD / I2
CODE /13
UT
Integration
HLD High-level design I1 HLD Inspection LLD
Low-level design I2 LLD Inspection I3 Code
Inspection UT Unit Test RAISE Reliability,
Availability, Install Serviceability,
and ease of use
Component Test
RAISE System Test
Early Customer Feedback and Beta Test Programs
Release
3
Risk-Driven Development
Planning
Risk Analysis
Initial requirements gathering and project
planning
Risk analysis based on initial requirements
Risk analysis based on customer reaction
Planning based on customer comments
Go /No Go
BEGIN
Towards a Completed System
Customer Evaluation
Initial Software prototype
Next Level prototype
Engineered System
Assessment (Customer-Oriented)
Engineering
4
Iterative Development Process (IDP) Model
Domain Analysis
Customer Requirements
Requirements Definition
Software Architecture
Iteration
Risk Assessment
Prototype Highest Risk
Test Suite Development
Integrate with Previous Iterations
Release Iteration
5
Iterative (Fast Prototyping Paradigm)
Start
Stop
Requirements Gathering and refinement
Engineer Product
Quick Design
Building Prototype
Refining Prototype
Customer Evaluation of Prototype
6
The Cleanroom Process
Customer Requirements
Specification
Function
Usage
Incremental Devlpmnt Planning
Usage Specification
Functional Specification
Random Test Case Generation
Formal Design Correctness, Verif
Source Code
Test Cases
Statistical Testing
Improvement Feedback
Interfail Times
Quality Certification Model
MTBF Estimates
7
CASE-Based Fast Prototyping
Preliminary requirements gathering
Requirements analysis
Prototyping
4GT
Spiral Model
Design
Prototyping nth iteration
4GT
Coding
4GT
Spiral Model nth iteration
Testing
Operational System
Maintenance
4GT Fourth Gen Testing
8
iii) Partial SDL Process For Client Object
This is the part related to Get Quote scenario
9
Object-Oriented Design SE Paradigm
(Design ltgt incrementally iteratively adding
detail)
ANALYSIS 2
ANALYSIS 1
Identify objects, methods, association, links
Capture key Use Cases, Scenarios (Normal, High
Risk)
OBJECT MODEL (Structural)
English, FSDs
SCENARIO MODEL (Interactions) (interfaces)
DYNAMIC BEHAVIOUR MODEL (FSM MODEL)
FUNCTIONAL MODEL (Data Flow Diagram- Flow of
Computations)
10
Example UML Class Association Diagramof Get
Quote Scenario
11
UML Sequence Diagram Of Get Quote Requirement
Scenario
12
Pragmatic Incremental and Iterative Software Dev
(IDP) Process
CONSTRUCTION (Operation/ Assessment)
TRANSITION (Planning / Evolution)
ELABORATION ( Requirements, HLD Prototype)
INCEPTION ( Recognize Opportunity)
4
3
2
1
Release 1.0
Release 1.1
Release 2.0
installing on internal servers had to go back
rethink some aspects of design (elaboration)
13
Release Nomenclature

• ? Collect ideas, proof-of-concept
• 1.0 Prototype installed on corporate hosting
  site (servers) for display
• 1.1 Minor fixes must-haves not in 1.0
• 2.0 Product to sell to a specific customer with
  intention to attract others

14
Phase 0 STARTING POINT - Meeting of Minds

• Architect/Planner (knowledgeable in domain and
  product line expert)
• Design Project Manager
• Senior design team members
• Product Test Manager

15
Phase 1 INITIAL PROTOTYPE

• Identify potential customers
• Get feedback on system concept from Phase 0
• Set up internal hosting site to demo to potential
  clients
• Initial prototype installed on site (Release 1.0)
• Customers will recognize requirements needs

16
Phase 2 REAL REQUIREMENTS

• Real customer identified (and pre-sold or at
  least have seen customers business case)
• See if prototype satisfies (uncaptured)
  requirements
• Major new requirements
• Significant platform retargeting
• More components resources
• Support infrastructure identified
• bug fixes
• plan for help desk

17
Summary of Pragmatic IDP

• Project process
• highly dynamic
• very team oriented
• involves a lot of dialogue
• regular meetings of the entire group as needed
• Teams are open to use of metrics and other tools
  and also specific notations such as UML
• Designer Testers collaboration yields
• improved time to market
• improved quality

18
Example High-Yield Secondary Scenarios

• In UML, divide use cases into primary (normal)
  and secondary (moderate to high yield) scenarios
• count primary (low-yield) scenarios
• Derive and count secondary scenarios
• add high-yield scenarios to improve coverage

19
Phase 0 Attributes Achievables

• Market opportunity (i.e. product) is identified
• Limited detailed requirements gathering
• This looks like what they will want
• Saves time and helps to launch a project (and
  product)
• Availability of relevant components inside the
  corporation and state of in-house and external
  vendor technology are identified

20
Phase 1 Attributes Achievables

• Installation on internal host may not be clean
• Host (servers) must be reliable and secure
• Useful to attract customers
• Useful to gather, refine prioritize
  requirements
• Preliminary to formalization
• Treat site as the customer

21
Phase 2 Attributes Achievables

• Continue to adapt to market place
• Continue to adapt to technology
• Start top down iterated design
• Continue with evolution of user requirements and
  high level architecture
• Release 1.1
• small but urgent functionality additions and/or
  customizations and fixes
• potential new requirements noted for major new
  functionality and/or significant platform
  retargeting

22
Phase 2 Attributes Achievables

• Release 2.0
• many more pieces and requires additional people
  and additions to the project code
• Planning for a business model to support the
  evolving product (multiple levels of customer
  support)
• When revenue stream is significant, setup help
  desk to relay more technical questions to the
  installation team (or if necessary, to one of the
  original developers) who are more technically
  competent than the help desk advisors

23
Software Quality Engineering-- Software Process
Quality

• Based on
• Defect Prevention Process
• i) Root Cause Analysis of Existing Errors
• ii) Suggest Preventive Actions
• iii) Implement Defect Prevention Strategy
• SEI CMM
• Malcolm Baldrige
• ISO 9000

24
PROCESS MANAGEMENT

• SEI - Capability Maturity Model
• Malcolm Baldrige Award
• ISO - ISO 9000 Series

25
Key Elements in the Capability Maturity Model
Level 5-Optimizing Process change
management Technology change management Defect
Prevention
Level 4-Managed Software quality
management Quantitative process management
Level 3-Defined Peer reviews, Inter-group
coordination SW Product engineering Integrated SW
management Training program Process definition
Focus
Level 2-Repeatable Requirements management SW
Configuration Management Quality
Assurance Project Planning Mgmt
Level 1-Initial
26
The SEI Process Capability Maturity Model (CMM)

• Level 1 Initial
• Characteristics chaotic unpredictable cost,
  schedule, and quality performance.
• Level 2 Repeatable
• Characteristics Intuitive cost and quality
  highly variable, reasonable control of schedules,
  informal and ad hoc methods and procedures. Key
  elements
• Requirements management
• Software project planning and oversight
• Software subcontract management
• Software quality assurance
• Software configuration management

27
The SEI Process Capability Maturity Model (CMM)

• Level 3 Defined
• Characteristics qualitative reliable costs and
  schedules, improving but unpredictable quality
  performance.
• Key elements
• Organizational process improvement
• Organizational process definition
• Training program
• Integrated software management
• Software product engineering
• Intergroup coordination
• Peer reviews

28
The SEI Process Capability Maturity Model (CMM)

• Level 4 Managed
• Characteristics quantitative reasonable
  statistical control over product quality.
• Key elements
• Process measurement and analysis
• Quality management
• Level 5 Optimizing
• Characteristics quantitative basis for
  continued capital investment in process
  automation and improvement.
• Key elements
• Defect prevention
• Technology innovation
• Process change management

29
Metrics-related Topics

• Profiles of software size maintained for each SW
  configuration item over time
• Statistics on software design errors
• Statistics on software code and test errors
• Projection of design errors and comparison with
  actuals
• Projection of test errors and comparison with
  actuals
• Measurement of Coverage 1. Design Review 2. Test
• Tracking of Actions to closure 1. Design Review
  2. Test
• Database for process metrics data across all
  projects
• Analysis of review data gathered during design
  reviews
• Analysis of data to determine the likely
  distribution and characteristics of the errors
  remaining in the project
• Analysis of errors to determine their
  process-related causes
• Analysis of review efficiency for each project

30
The Malcolm Baldrige Assessment

• Leadership
• Information and analysis
• Strategic quality planning
• Human resource utilization
• Quality assurance of products and services
• Quality results
• Customer satisfaction

31
Purpose of the Malcolm Baldrige Assessment

• Help elevate quality standards and expectations
  in the country.
• Facilitate communication and sharing among and
  within organizations of all types based on a
  common understanding of key quality requirements.
• Serve as a working tool for planning, training,
  assessment, and other uses.
• Provide the basis for making the award.
• Provide feedback to the applicants.

32
ISO 9000 Standard Series
Standard Title
Key Elements
Fundamental quality concept defines key terms
and provides guidance on selecting, using, and,
if necessary, tailoring ISO 9001, 9002, and
9003. Covers all elements listed in ISO 9002
and 9003. Addresses design, development and
servicing capabilities. Addresses the
prevention, detection, and correction of problems
during production and installation. It is more
extensive and sophisticated than ISO
9003. Address requirements for the detection and
control of problems during final inspections and
testing. Provides guidance for a supplier to use
in developing and implementing a quality system
and in determining the extent to which each
quality system element is applicable. ISO 9004
examines each of the quality system elements
(cross-referenced in the other ISO 900
standards)in greater detail. Not intended for
contractual auditing.
ISO 9000 Quality management and quality assurance
standards guidelines for selection and
use. ISO 9001 Quality systems model for
quality assurance in design/development,
production, installation and servicing. ISO
9002 Quality systems model for quality assurance
in production and installation. ISO9003 Qualit
y systems model for quality assurance in final
inspection and test. ISO9004 Quality management
and quality system elements guidelines
Adapted from Maureen Breitenberg, Questions and
Answers on Quality, the ISO 9000 Standard Series,
Quality System Registration and Related
Issues. US Department of Commerce, National
Institute of Standards and Technology, Nov. 1991