Overview of Software Engineering Principles

CSCI 599:Software Engineering for Embedded

Systems

August 27, 2002

Engineering Engineering is …

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

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

Ever-Present Difficulties Few guiding scientific principles Few universally applicable

methods As much

managerial / psychological / sociologicalas 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 highly complex Software directly depends upon the hardware

It is at the top of the system engineering “food chain”

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

Quicker development is not always preferable higher up-front costs may defray downstream costs poorly designed/implemented software is a critical cost

factor

Relative Costs of Fixing Software Faults

Requirements Specification Planning Design Implementation Integration Maintenance

1 2 3 410

30

200

Mythical Man-Monthby Fred Brooks Published in 1975, republished in 1995

Experience managing development of OS/360 in 1964-65

Central argument 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 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

Software Development LifecycleWaterfall Model

Requirements

Design

Implementation

Integration

Validation

Deployment

Evaluate alternatives,identify, resolve risks,develop prototypes

Develop, verifynext-level productPlan next phases

Determine objectivesalternatives, constraints

Software Development LifecycleSpiral Model

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

Verification extensive specification reviews with the customer identify ambiguity, inconsistency, incompleteness ascertain feasibility, testability develop system/acceptance test plan

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

Verification design inspections to establish conformance to requirements check module interactions develop integration test plan

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

Difficulties module interaction errors order of integration may influence quality and productivity

Verification code reviews to establish conformance to requirements & design check module interactions develop unit test plan: focus on individual modules test on unit, integration and acceptance test plans

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

Testing Dynamic “Engineering” White box vs. black box Structural vs. behavioral Issues of test adequacy

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

Verification extensive reviews to ensure correct changes and updates to

documentation test to determine that change is correctly implemented regression testing: ensure that no inadvertent changes are made to

compromise system functionality

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 Software manufacture Managing simultaneous updates

(team work)

CM in Action

1.1

1.2

1.4

2.0

2.1

2.2

3.1

3.0

1.5

4.0

1.0

1.3

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

PRINCIPLES

METHODS ANDTECHNIQUES

METHODOLOGIES

TOOLS

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

Reliability statistical property probability that software will operate as expected

over a given period of time relative

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

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

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

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.

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

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

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

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 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