1. Overview of Software Engineering Principles

2. Engineering Engineering is … Examples
The application of scientific principles and methods
to the construction of useful structures & machines
Examples
Mechanical engineering
Civil engineering
Chemical engineering
Electrical engineering
Nuclear engineering
Aeronautical engineering

3. Software Engineering The term is almost 40 years old: NATO Conferences
Garmisch, Germany, October 7-11, 1968
Rome, Italy, October 27-31, 1969
The application of scientific principles, methods, models, standards and theories
Many aspects have been made systematic
Methods/methodologies/techniques
Languages
Tools
Processes

4. Software Engineering in a Nutshell
Development of software systems whose size/complexity warrants team(s) of engineers
multi-person construction of multi-version software [Parnas 1987]
Scope
study of software process, development principles, techniques, and notations
Goal
production of quality software, delivered on time, within budget, satisfying customers’ requirements and users’ needs

5. Ever-Present Difficulties
Few guiding scientific principles
Few universally applicable methods
As much managerial / psychological / sociological as technological

6. Why These Difficulties?
SE is a unique brand of engineering
Software is malleable (extended, adaptable)
Software construction is human-intensive
Software is intangible
Software problems are unprecedentedly complex
Software directly depends upon the hardware
and (lots of) other software
Software solutions require unusual rigor
Software has discontinuous operational nature

7. Software Engineering ≠ Software Programming
Single developer
“Toy” applications
Short lifespan
Single or few stakeholders
Architect = Developer = Manager = Tester = Customer = User
One-of-a-kind systems
Built from scratch
Minimal maintenance

8. Software Engineering ≠ Software Programming
Teams of developers with multiple roles
Complex systems
Indefinite lifespan
Numerous stakeholders
Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
System families
Reuse to amortize costs
Maintenance accounts for over 60% of overall development costs

9. Economic and Management Aspects of SE
Software production = development + maintenance (evolution)
Maintenance costs > 60% of all development costs
20% corrective
30% adaptive
50% perfective
Quicker development is not always preferable
higher up-front costs may defray downstream costs
poorly designed/implemented software is a critical cost factor

10. Relative Costs of Fixing Software Faults
200 30 10 4 3 2 1
Requirements
Specification
Planning
Design
Implementation
Integration
Maintenance

11. Mythical Man-Month by Fred Brooks
Published in 1975, republished in 1995
Experience managing development of OS/360 in
Central argument
Large projects suffer management problems different in kind than small ones, due to division in labor
How does large software project get to be one year late?
Central conclusions
Conceptual integrity achieved through chief architect
Implementation achieved through well-managed effort
Brooks’s Law
Adding personnel to a late project makes it later

12. Software Development Lifecycle Waterfall Model
Requirements
Design
Implementation
Integration
Validation
Deployment

13. Software Development Lifecycle Spiral Model

14. Requirements Problem Definition → Requirements Specification
determine exactly what the customer and user want
develop a contract with the customer
specifies what the software product is to do
Difficulties
client asks for wrong product
client is computer/software illiterate
specifications are ambiguous, inconsistent, incomplete

15. Architecture/Design Requirements Specification → Architecture/Design
architecture: decompose software into modules with interfaces
design: develop module specifications (algorithms, data types)
maintain a record of design decisions and traceability
specifies how the software product is to do its tasks
Difficulties
miscommunication between module designers
design may be inconsistent, incomplete, ambiguous

16. Architecture vs. Design [Perry & Wolf 1992]
Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.
Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.

17. Implementation & Integration
Design → Implementation
implement modules; verify that they meet their specifications
combine modules according to the design
specifies how the software product does its tasks
Difficulties
module interaction errors
order of integration may influence quality and productivity

18. Component-Based Development
Develop generally applicable components of a reasonable size and reuse them across systems
Make sure they are adaptable to varying contexts
Extend the idea beyond code to other development artifacts
Question: what comes first?
Integration, then deployment
Deployment, then integration

19. Different Flavors of Components
Third-party software “pieces”
Plug-ins / add-ins
Applets
Frameworks
Open Systems
Distributed object infrastructures
Compound documents
Legacy systems

20. Verification and Validation
Analysis (check against requirements)
Static
“Science”
Formal verification
Informal reviews and walkthroughs
Testing (functions have been tested)
Dynamic
“Engineering”
White box vs. black box
Issues of test adequacy

21. Deployment & Evolution
Operation → Change
maintain software during/after user operation
determine whether the product still functions correctly
Difficulties
rigid design
lack of documentation
personnel turnover

22. Configuration Management (CM) [Tichy 1988]
CM is a discipline whose goal is to control changes to large software through the functions of
Component identification
Change tracking
Version selection and baselining
Managing software
Managing simultaneous updates (team work)

23. CM in Action
1.0
4.0
1.1
1.2
2.0
1.3
2.1
1.4
2.2
3.0
1.5
3.1

24. Software Engineering Principles
Rigor and formality
Separation of concerns
Modularity, decomposition, abstraction
Cohesion and coupling
Anticipation of change
Generality
Incrementality
Scalability
Heterogeneity

25. From Principles to Tools

26. Software Qualities
Qualities are goals in the practice of software engineering
External vs. Internal qualities
Product vs. Process qualities

27. External vs. Internal Qualities
External qualities are visible to the user
reliability, efficiency, usability
Internal qualities are the concern of developers
they help developers achieve external qualities
verifiability, maintainability, extensibility, evolvability, adaptability

28. Product vs. Process Qualities
Product qualities concern the developed artifacts
maintainability, understandability, performance
Process qualities deal with the development activity
products are developed through process
maintainability, productivity, timeliness

29. Some Software Qualities
Correctness
ideal quality
established w.r.t. the requirements specification
absolute
Reliability
statistical property
probability that software will operate as expected over a given period of time

30. Some Software Qualities (cont.)
Robustness
“reasonable” behavior in unforeseen circumstances
subjective
a specified requirement is an issue of correctness; an unspecified requirement is an issue of robustness
Usability
ability of end-users to easily use software
extremely subjective

31. Some Software Qualities (cont.)
Understandability
ability of developers to easily understand produced artifacts
internal product quality
subjective
Verifiability
ease of establishing desired properties
performed by formal analysis or testing
internal quality

32. Some Software Qualities (cont.)
Performance
equated with efficiency
assessable by measurement, analysis, and simulation
Evolvability
ability to add or modify functionality
addresses adaptive and perfective maintenance
problem: evolution of implementation is too easy
evolution should start at requirements or design

33. Some Software Qualities (cont.)
Reusability
ability to construct new software from existing pieces
must be planned for
occurs at all levels: from people to process, from requirements to code
Interoperability
ability of software (sub)systems to cooperate with others
easily integratable into larger systems
common techniques include APIs, plug-in protocols, etc.

34. Some Software Qualities (cont.)
Scalability
ability of a software system to grow in size while maintaining its properties and qualities
assumes maintainability and evolvability
goal of component-based development

35. Some Software Qualities (cont.)
Heterogeneity
ability to compose a system from pieces developed in multiple programming languages, on multiple platforms, by multiple developers, etc.
necessitated by reuse
goal of component-based development
Portability
ability to execute in new environments with minimal effort
may be planned for by isolating environment-dependent components
necessitated by the emergence of highly-distributed systems (e.g., the Internet)
an aspect of heterogeneity

36. Software Process Qualities
Process is reliable if it consistently leads to high- quality products
Process is robust if it can accommodate unanticipated changes in tools and environments
Process performance is productivity
Process is evolvable if it can accommodate new management and organizational techniques
Process is reusable if it can be applied across projects and organizations

37. Assessing Software Qualities
Qualities must be measurable
Measurement requires that qualities be precisely defined
Improvement requires accurate measurement
Currently most qualities are informally defined and are difficult to assess

38. Software Engineering “Axioms”
Adding developers to a project will likely result in further delays and accumulated costs
Basic tension of software engineering
better, cheaper, faster — pick any two!
functionality, scalability, performance — pick any two!
The longer a fault exists in software
the more costly it is to detect and correct
the less likely it is to be properly corrected
Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design
detecting the causes of those faults early may reduce their resulting costs by a factor of 100 or more