2. Software Development Process
2.1 Project, Process, and Process Models
– Project: Single use; Process: Permanent, i.e., individual projects have limited lifetimes, the process is ideally continuous.
– Target: Semiotic description of mental processes
• Less complicated: Syntactic and semantic parts
• Problematic: Bridging the pragmatic gap in the system development and the process execution
– Early Models: Waterfall Model, V-Model – Phase-Based Life Cycle Model
– Identification of risks, consideration of undesirable events and irregular states caused by them
– State of the Art: Spiral Model
– Evaluation of Software Development Processes: CMM, SPICE, BOOTSRAP, ...
Plan the Project
Manage the Project Project
Management
Define the Process
Improve the Process Process Management
(in the sense of TQM)
Time Course
Organizational Framework
Requirements of the Software
Validation
Rough Design Verification
Detailed Design Verification
Coding / Debugging Modultest
Integration Test Validation Requirements
of the System Validation
Use and Maintenance Revalidation/
Regression Test
Classic Waterfall Model of Software Development Processes (Boehm, 1976)
Typical Cost Trend for Each Phase Costs
Functional Specifications
Design +
Specifications
Coding + Test Maintenance + Use
t Development Costs over the Phases
Desired Cost Trend per Phase Costs
Functional Specifications
Design +
Specifications
Coding + Test Maintenance + Use
t Development Costs over the Phases
Typical Trend
Fault Detection Probability
. . . Functional
Specification
Develop ment
Specification Coding Integration Acceptance t
Fault Detection Probability
Costs (Logarithmic)
. . . Functional
Specification
Develop ment
Specification Coding Integration Acceptance t
Subsequent Costs of Late Detected Faults
Desired Trend
Fault Detection Probability
. . . Functional
Specification
Develop ment
Specification Coding Integration Acceptance Time
Fault Detection Probability
Effectiveness of
Testing Unchanged
Forwarded Fault
In the Course of 1:x Amplified Fault
Newly Generated Fault
Not Discovered Fault
Next Step Fault
from Previous Step
Fault Impact Model (Pressman, 1987)
Need
Correct Requirement Need
Assessment
Requirement Definition / Problem Analysis
Faulty Requirements
Correct
Specification Specification Fault Fault Induced in Requirements System
Specification
Correct
Design Design Fault
in Requirements in Specification Fault Induced
Design
Correct
Program Program Fault
in Requirements in Specification Fault Induced
in Design Realization
Corrected Fault Correct
Behavior Known Uncorrected Unknown Fault
Faullt Test and
Intgration
Program with Known and Unknown Defects (Fault Avalanche, DGQ, 1986)
SW Requirements
SW/HW Integration &
Testing SW System Integration &
Testing Preliminary
SW Analysis Design
SW Subsystem Integration &
Testing Details SW
Analysis &
Design
SW Testing System
Decomposition
Operational Testing &
Evaluation Acceptance
Test &
Evaluation System Performance
Testing
Operation &
Management Required
Operational Capability
Engineering Studies
Experimental Development
Concept Evaluation
Research Phase Conceptual Phase Design & Development Phase Test & Evaluation Phase Operations & Maintenance Phase SW Subsystem
Design Review Start Test End of Operation & Management
Certification
Validation
Validation
Verification Verification
Verification
Verification Validation
System Requirements Review
System Design Review
Preliminary Design Review
Customer Delivery &
Physical Configura- tion Audit
Functional Configuration Audit
Coding &
Debugging Critical
Design Review Legende:
SW= Software
An Extension of the Conventional Waterfall Model (Jensen/Tonies 1979)
Use,
Maintenance Need
Defining System Requirements
Design Acceptance
Test
Modul-Test Integration
(Components) Detailed Specification
(External) Draft
Specification User
Requirements Operational
System
Prog.
Lang.
Prog.
Sys.
Maintenance Fault
(Real) Requirement Fault Test - Spec.
Fault
Requirement - Definition
Fault
Design Fault Test - Spec.-
Integration Fault
V A L I D A T I O N
V E R I FI C A T I O N V E R I FI C A T I O N
D E BU G GING
V E R I FI C A T I O N Documentation
Moduls ...
Descriptions
Descriptions
Descriptions
Descriptions Descriptions
Define goals, create options,
establish constraints
Evaluate options, identify risks,
create solution proposals
Plan the next phase Develop, verify
Successive Steps t
Cumulative Costs II
I
III IV
II
Refinement Degree/
Development Status Time (Proportional to
the Length of the Spiral)
IV III
– Objective: Selection from the "mountain" of methods and notations, and other aids
– Classification according to power:
• Notational Means
+ Descriptive: Cause-effect graphs, plot graphs, HIPO, SA, ...
+ Prescriptive: Checklists, decision tables, structure charts, ...
• Amplifying / Rationalising means
+ Generating: Regular expressions, production (replacement) rules, for example, BNF, compiler, ...
+ Recognizing: Finite automata
• Cognitive: High-order predicate logic, deductive databases, ...
– Classification according to precision, unambiguous interpretation:
• Formal: Analysis, verification, design, algorithmic (therefore, can be automated), based on sound mathematical models.
• Semi-formal: Not complete, mathematically consistent, but only algorithmic through human interaction.
• Non-formal: Mostly established ad-hoc, simplistic and sometimes very shallow.
• Formal (or "formalized“) methods are primarily considered here; they can be represented algorithmically (or in an algorithmic-like way.
CASE (Computer Aided Software Engineering) Tools
– Editing (Graphic, Text),
– Programming (Coding, Debugging, Code Generation),
– Verification and Validation (Static/Dynamic analyzer, Test Case Generator), – Configuration Management (Change Control Monitor, Configuration Builder), – Metrics (Code Analyzer, Execution Monitor),
– Project Management (Project Notebook, Cost Estimation Tools).
CASE Workbenches
– Planning/Modeling of commercial systems (e.g., PC Prism) – Analyse and design (e.g., Excelerator, Statemate),
– User Interfaces (e.g., DEC VUIT, HP Interface Architect), – Verification and validation (e.g., Battlemap, Logiscope),
– Maintenance and reverse engineering (e.g., Recorder, Rigi, Hindsight, SmartSystem),
– Configuration management (e.g., PCMS, PVCS, CCC, SCLM), – Project management (e.g., DEC Plan Coordinator, Synchronize).
– It is important for the selection that the individual CASE tools are compatible with each other, e.g., regarding the data exchange. Thereby, they can support the components of a project document ("Project Repository") of the software development process (in the sense of an open system, such as also for commonly available tools, public domain software, etc.) extensively. Repository also enables the data exchange between individual tools and tool integration.
This also enables a consistency check between any components throughout the all project levels and a wide scale configuration management.
– Such a repository system requires rigorous entrance –access- and integrity measures.
Quality Assurance
Graphs
t Histograms
Pareto-Diagramme
Checklists
Plot Diagrams Cause-Effect Diagrams
(also known as "Fishbone" / "Ishikawa" diagrams)
B
B1
B2
B3
A1
A2
R1 R2 R3 R4
J J N N
N J J N
N J / N
X X
X X
Decision Tables
..
Matrices / tables
Petri Nets Control Charts
t
Fault Trees
OR OR
AND
Hierarchy Diagrams Relation Diagrams
