1.1 The Software Phenomenon
What has become of Software Projects?
(Reported in 1990 by Diebold International on government contracts, U.S.)
Product Delivered, does not function 47%
Used as developed 2%
Re-engineered, deployed 3%
Re-engineered, not deployed 19%
Paid, not deployed 29%
Managed
Optimizing
Repeatable
Defined
Initial Cost
Level 5
Level 4
Level 3
Level 2
Level 1 Disciplined Process
Standard, Consistent
Process
Continously Improving Process
Predictable Process
Time
Capability Maturity Levels (Process Evolution) from SEI, CMU (1990)
5%
40%
30%
20%
10% 9%
16%
30%31%
2%
11%
1%
0%
1 2 3 4 5
Initial Defined Managed Optimizing Percentage of Companies (%)
“Maturity Level”
Repeat- able
SEI-Evaluation of 167 Companies (1990)
1.2 The Nature of the Software
– From the computer program to software: Generic and customized products (prototypically unique)
– “Software-Phenomenon,” “Software-Crisis,” especially for customer-specific software products
– Necessity of the formalization of the program design
– NATO-Workshop “Software-Engineering,” 1968 in Garmisch-Partenkirchen – “Programming in Small,” “Programming in Large”
– Problem Area: Documentation
100
60
40 20 80
%
Hardware
Software- Development
Software- Maintanance
Time
1955 1970 1995
Percentage of Total Software Development Costs
1.3 Handling of Complex Systems
– Complex Systems
• are not monolithic, i.e., they have a lot of components which depend each other in many ways.
• have critical and pluralistic characteristics (Reliability, Availability, Fault Tolerance, ...).
• are embedded in other (complex) systems.
– Result: Complex systems are difficult to construct, understand, handle, ...
– Remedy: Special methods for modeling and analysis.
– Software systems are complex systems in terms of:
• Computability (“Computational Complexity”): Execution time and space.
• Productivity / Labor Intensity (“Psychological Complexity”): Time to understand, correct and modify a program.
– For to the design process: Identify risks / different development activities (design, specification, verification/validation) and the evolutionary nature of the products (usability, reliability, maintainability).
– For the production process: Employ rationalization products / tools (CASE:
Computer Aided Software Engineering).
1.4 Configuration Management
– Configuration: Constellation of components of a system and their structural relationships.
– Baseline: The "frozen" system configuration to a well-defined point in time ("Milestone") until the release of the next baseline.
– Configuration management (CM) identifies and controls the system
configuration at a desired state during the development and the use of the system.
– CM Functions:
• Identification of system components and baselines through meaningful identifiers with reference to hierarchy, version, serial membership etc.
• Change control from the application until the execution of the change (Change Board).
• Accounting changes by versions/change management (Change/Release Management).
– CM Tools are integrated into production environments.
Subroutine/
Subsystem
Segment/
Module Section
Program/
System
Statement . . .
. . .
. . .
. . . >100,000 Instructions
~3,000 Instructions
~300 Instructions
~50 Instructions
Typical Program Structure
Component A Version 23
. . . . . .
. . .
Baseline X. Y. 1 System
. . .
2
Component Z Version 1516
changed!
. . .
Component Z Version 46
47
Component ZB Version 11
Component ZAA Version 3
Component ZAB Version 89
Identification, Baseline, Change
A. 10 A. 11 A. 12 A2.1 A2.2 A3.1 Alt.A. 1 Alt.A. 2
CorrA.1 Alternative Development
Correction
: Refinement/Integration : Revision
: Variant : Repair
Version Group, Development History
1.5 Conceptual Clarification
– Software includes all the resources of mental character, which completes the hardware to an efficient computing system.
– Software is more than programs :
Software := Program(s) + Documentation + Methods (Design, Management) + Means and Tools
– Software engineering attempts to discover the principles and establish rules, in order to develop software economically and deterministically, and enable a reliable and friendly use.
Meaning
User/
Producer
Meta-characters (Construct) Semantics
Semantic Fault
Syntactic Fault Pragmatic
Fault
Pragmatics Syntactics
(Syntax)
Stigmatic Fault
Stigmatics Sign/Symbol
Signified/
symbolized object
Semiotics- Based (Symbols Theory) View
1.6 Objectives, Phases and Activities of Software Engineering
Objectives
Activities for
Phases of Activities for - Usability
- Portability - Auditability
- Cost Effectiveness
- Requirements definition - Design
- Implementation - Validation - Use
- Maintenance
- System Design - Software Design - Process Support - Process Management
Management Procedures
Computer Support
Technical Methods
Software-Developer
Select Tools
Create
Transparent Structure
Keep Management Reports
Coordinate and
Lead
Support Method
Determine Required Tools
Software-Development
Software- Development Methodology
Software-Development Software-Developer
Software Development Approaches
Software Development Environment
1.7 Principles, Methods and Tools
– Principles are general acting guidelines of software development, which can algorithmically be carried out by methods for special objectives and tasks.
– Tools enable, simplify and rationalize the use of the methods. They can be used manually or with computer support (tools).
– The most important Principles: Information hiding and structuring via abstraction for modularization and standardization.
– Abstract data types and abstract functions are instruments of abstraction.
– Another Principle: Locality and documentation integrated into the development and quality assurance.
– In general: Foresight and restriction, i.e., timely plan, validate and employ only as many methods and aids as necessary.
– Abstraction Principle (Information Hiding)
• Abstracting – Concretising
• Generalize – Specialize
• Modeling - Realization (Implementing)
– Abstraction Levels ⇒ Hierarchical Arrangement
⇒ Structure
• Data Abstraction ⇒ Abstract Data types
• Functional Abstraction ⇒ Abstract Functions
Example of Principles / Methods / Aids Hierarchy
– Principles: Structuring (of Programs).
– Methods: Elimination of non-linearities by using only three control structures sequence, selection and iteration.
– Means/Tool: Structure diagrams ("Nassi-Shneiderman Diagrams"), which do not allow "goto" statement (jump).
Non-Linear Programs
– Systems can be structured according to different criteria for different purposes:
Hierarchical, layered, net, ring, etc.
– Instrumentation of the structuring principle via
• methods of structured programming (use only the language constructs sequence, selection, and iteration).
• dedicated means: structure diagrams (Nassi-Shneiderman Diagrams).
– This is a good example of hierarchy:
Principle → Method → Means
Structuring → Structured Programming → Structure Diagram
– Programs with other constructs, for example, with goto's are therefore unstructured (non-linear “Spaghetti programs”).
– Special algorithms enables for structuring.
– Construction of "Structure Labeled Programs" is based on the following terms and relationships:
• A “proper program" has a definite beginning, a definite end, a arbitrary number of related function nodes, i.e., one can reach the end from each node and from the beginning to each node.
• "Functional equivalence" is that interchanging predicates of cascading selections does not change the function of the segment.
• "Execution equivalence" is that exporting function nodes out of a loop does not change the function of a segment.
• Execution equivalence implies functional equivalence.
– Structure Theorem: For every proper unstructured program, a functionally-
equivalent structured program is available; it contains the nodes of the original program, additional statements and tests of a counter (labels).
Example: A Non-proper Program
Begin
B End
A
D
F E C
Functional Equivalence
=^ A
q p
a > 3 a > 0
J
J A
p q
a > 0 a > 3
N
N
N
N J J
Execution Equivalence
=^ A
A
p
A p
Execution Equivalence ⇒ Functional Equivalence
PROCEDURE spaghetti;
...
BEGIN (* Spaghetti *)
marke_1: IF <p> THEN DO BEGIN
<A>; GOTO marke_2 END
ELSE IF <q> THEN GOTO marke_2 ELSE DO BEGIN
<B>; GOTO marke_1 END
marke_2: END (* spaghetti *);
...
- Create a structure diagram, program flow diagram and the linearized program.
Begin
p
q
End
B A
J N
J N
– Algorithm for Linearization
• Step 1: Number the nodes, End node: 0.
• Step 2: Label the nodes using the numbers of the following nodes, i.e., add label assignments.
• Step 3: Steer through the labels.
• Step 4: Simplify by combining the same labels.
Step 1: Numbering of the Nodes
Begin
p
q
End
B A
J
N
J 1
2 3
4
0
Basic Idea:
h j ⇒ h l := j
i i
l := j j
p
l := k k
i
⇒ p
Extension of the Nodes to Labels
Beg. Beg. l := 1
1. p
l := 2
l := 3
2. A l := 0
3. q
l := 0
l := 4
4. B l := 1
Begin End l := 2
l := 3
l := 0
l := 0
l := 4
l := 1 l := 1 l>0
q p
l
B A J
N
1
2
3
4
Step 4: Stepwise Simplification (Recursive Structure Program) 4.1 Inserting Switch = 4
Begin End
l := 2
l := 3
l := 0
l := 0
l := 1 l := 1 l>0
q p
l A
J N
1
2
3
B
Begin End l := 2
l := 0 l := 1 l>0
p
l
A J
N
1
2
l := 0
l := 1 q
B
4.3 Inserting Switch = 2
Begin End
l := 0
l := 1 l>0
p
A
J N
l := 0 q
B l := 1
- Result: The Linearized Program.
PROCEDURE spaghetti_smoothed;
BEGIN
label := 1;
WHILE label>0 DO BEGIN
IF <p> DO THEN BEGIN
<A>; label := 0 END
ELSE IF <q> THEN label := 0 ELSE BEGIN
<B>; label := 1 END
END
END; (* Spaghetti smoothed *) ...
- Create the related structured diagram.
