Overview of Software Engineering Principles
CSCI 589: Software Engineering for Embedded Systems
August 25, 2003
Engineering
Engineering is …
The application of scientific principles and methods To the construction of useful structures & machines
Mechanical engineering Civil engineering Chemical engineering Electrical engineering Nuclear engineering Aeronautical engineering
Examples
Software Engineering
The term is 35 years old: NATO Conferences
Garmisch, Germany, October 7-11, 1968 Rome, Italy, October 27-31, 1969
Computer science as the scientific basis
The reality is finally beginning to arrive
Other scientific bases?
Methods/methodologies/techniques Languages Tools Processes
Many aspects have been made systematic
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
production of quality software, delivered on time, within budget, satisfying customers’ requirements and users’ needs
Goal
Ever-Present Difficulties
Few guiding scientific principles Few universally applicable methods As much managerial / psychological / sociological as technological
Why These Difficulties?
SE is a unique brand of engineering
Software is malleable Software construction is human-intensive Software is intangible Software problems are unprecedentedly complex Software directly depends upon the hardware
It is at the top of the system engineering “food chain”
Software solutions require unusual rigor Software has discontinuous operational nature
Software Engineering ≠ Software Programming
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
Software Engineering ≠ Software Programming
Software engineering
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
Economic and Management Aspects of SE
Software production = development + maintenance (evolution) Maintenance costs > 60% of all development costs
20% corrective 30% adaptive 50% perfective higher up-front costs may defray downstream costs poorly designed/implemented software is a critical cost factor
Quicker development is not always preferable
Relative Costs of Fixing Software Faults
200
30
10
1
Requirements
2
Specification
3
Planning
4
Design Implementation Integration Maintenance
Mythical Man-Month by Fred Brooks
Published in 1975, republished in 1995
Experience managing development of OS/360 in 1964-65 Large projects suffer management problems different in kind than small ones, due to division in labor Critical need is the preservation of the conceptual integrity of the product itself Conceptual integrity achieved through chief architect Implementation achieved through well-managed effort Adding personnel to a late project makes it later
Central argument
Central conclusions
Brooks’s Law
Software Development Lifecycle Waterfall Model
Requirements Design Implementation Integration
Validation
Deployment
Software Development Lifecycle Spiral Model
Determine objectives alternatives, constraints
Evaluate alternatives, identify, resolve risks, develop prototypes
Plan next phases
Develop, verify next-level product
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 client asks for wrong product client is computer/software illiterate specifications are ambiguous, inconsistent, incomplete
Difficulties
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
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.
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 module interaction errors order of integration may influence quality and productivity
Difficulties
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
Different Flavors of Components
Third-party software “pieces” Plug-ins / add-ins Applets Frameworks Open Systems Distributed object infrastructures Compound documents Legacy systems
Verification and Validation
Analysis
Static “Science” Formal verification Informal reviews and walkthroughs
Dynamic “Engineering” White box vs. black box Structural vs. behavioral Issues of test adequacy
Testing
Deployment & Evolution
Operation → Change
maintain software during/after user operation determine whether the product still functions correctly rigid design lack of documentation personnel turnover
Difficulties
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 Software manufacture Managing simultaneous updates (team work)
CM in Action
1.0 1.1 1.2 1.3
2.0
2.1 2.2
4.0
1.4
1.5
3.0
3.1
Software Engineering Principles
Rigor and formality Separation of concerns
Modularity and decomposition Abstraction
Anticipation of change Generality Incrementality Scalability Compositionality Heterogeneity
From Principles to Tools
TOOLS
METHODOLOGIES
METHODS AND TECHNIQUES
PRINCIPLES
Software Qualities
Qualities (a.k.a. “ilities”) are goals in the practice of software engineering External vs. Internal qualities Product vs. Process qualities
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
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
Some Software Qualities
Correctness
ideal quality established w.r.t. the requirements specification absolute
statistical property probability that software will operate as expected over a given period of time relative
Reliability
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
ability of end-users to easily use software extremely subjective
Usability
Some Software Qualities (cont.)
Understandability
ability of developers to easily understand produced artifacts internal product quality subjective
ease of establishing desired properties performed by formal analysis or testing internal quality
Verifiability
Some Software Qualities (cont.)
Performance
equated with efficiency assessable by measurement, analysis, and simulation
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
Evolvability
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 ability of software (sub)systems to cooperate with others easily integratable into larger systems common techniques include APIs, plug-in protocols, etc.
Interoperability
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
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 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
Portability
Software Process Qualities
Process is reliable if it consistently leads to highquality 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
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
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 more costly it is to detect and correct the less likely it is to be properly corrected
The longer a fault exists in software
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