Overview of Software Engineering Principles

8/11/2019 Overview of Software Engineering Principles

1/38

Overview of SoftwareEngineering Principles

CSCI 589:Software Engineering for Embedded Systems

August 25, 2003


2/38

EngineeringEngineering is

The application of scientific principles and methods

To the construction of useful structures & machinesExamplesMechanical engineeringCivil engineering

Chemical engineeringElectrical engineeringNuclear engineering

Aeronautical engineering


3/38

Software EngineeringThe term is 35 years old: NATO Conferences

Garmisch, Germany, October 7-11, 1968

Rome, Italy, October 27-31, 1969The reality is finally beginning to arriveComputer science as the scientific basis

Other scientific bases?

Many aspects have been made systematicMethods/methodologies/techniquesLanguagesToolsProcesses


4/38

Software Engineering in a

NutshellDevelopment of software systems whosesize/complexity warrants team(s) of engineers

multi-person construction of multi-version software[Parnas 1987]

Scopestudy of software process, development principles,techniques, and notations

Goalproduction of quality software, delivered on time, withinbudget, satisfying customers requirements and users needs


5/38

Ever-Present DifficultiesFew guiding scientific principlesFew universally applicable methods

As muchmanagerial / psychological / sociologicalas technological


6/38

Why These Difficulties?SE is a unique brand of engineering

Software is malleable

Software construction is human-intensiveSoftware is intangibleSoftware problems are unprecedentedly complexSoftware directly depends upon the hardware

It is at the top of the system engineering food chain

Software solutions require unusual rigorSoftware has discontinuous operational nature


7/38

Software Engineering

Software ProgrammingSoftware programming

Single developer

Toy applications Short lifespanSingle or few stakeholders

Architect = Developer = Manager = Tester = Customer = User

One-of-a-kind systemsBuilt from scratchMinimal maintenance


8/38


Software ProgrammingSoftware engineering

Teams of developers with multiple roles

Complex systemsIndefinite lifespanNumerous stakeholders

Architect Developer Manager Tester Customer User

System familiesReuse to amortize costsMaintenance accounts for over 60% of overalldevelopment costs


9/38

Economic and Management

Aspects of SESoftware production =

development + maintenance ( evolution )

Maintenance costs > 60% of all developmentcosts 20% corrective30% adaptive

50% perfectiveQuicker development is not always preferablehigher up-front costs may defray downstream costspoorly designed/implemented software is a critical

cost factor


10/38

Relative Costs of Fixing

Software Faults

Requirements Specification Planning Design Implementation Integration Maintenance1 2

3 410

30

200


11/38

Mythical Man-Month

by Fred BrooksPublished in 1975, republished in 1995

Experience managing development of OS/360 in 1964-65Central argument

Large projects suffer management problems different inkind than small ones, due to division in laborCritical need is the preservation of the conceptualintegrity of the product itself

Central conclusionsConceptual integrity achieved through chief architectImplementation achieved through well-managed effort

Brookss Law Adding personnel to a late project makes it later


12/38

Software Development Lifecycle

Waterfall ModelRequirements

Design

Implementation

Integration

Validation

Deployment


13/38

Evaluate alternatives,identify, resolve risks,develop prototypes

Develop, verifynext-level productPlan next phases

Determine objectivesalternatives, constraints

Software Development Lifecycle

Spiral Model


14/38

RequirementsProblem Definition Requirements Specification

determine exactly what the customer and user want

develop a contract with the customerspecifies what the software product is to do

Difficultiesclient asks for wrong productclient is computer/software illiteratespecifications are ambiguous, inconsistent, incomplete


15/38

Architecture/DesignRequirements Specification Architecture/Design

architecture: decompose software into modules withinterfacesdesign: develop module specifications (algorithms, datatypes)maintain a record of design decisions and traceabilityspecifies how the software product is to do its tasks

Difficultiesmiscommunication between module designersdesign may be inconsistent, incomplete, ambiguous


16/38

Architecture vs. Design

[Perry & Wolf 1992] Architecture is concerned with the selection ofarchitectural elements, their interactions, andthe constraints on those elements and theirinteractions necessary to provide a frameworkin which to satisfy the requirements and serveas a basis for the design.Design is concerned with the modularizationand detailed interfaces of the design elements,their algorithms and procedures, and the datatypes needed to support the architecture andto satisfy the requirements.


17/38


18/38

Component-Based

DevelopmentDevelop generally applicable components of areasonable size and reuse them acrosssystemsMake sure they are adaptable to varyingcontextsExtend the idea beyond code to other

development artifactsQuestion: what comes first?Integration, then deploymentDeployment, then integration


19/38

Different Flavors of

ComponentsThird- party software pieces Plug-ins / add-ins

AppletsFrameworksOpen Systems

Distributed object infrastructuresCompound documentsLegacy systems


20/38

Verification and Validation Analysis

Static

Science Formal verificationInformal reviews and walkthroughs

Testing

Dynamic Engineering White box vs. black boxStructural vs. behavioral

Issues of test adequacy


21/38

Deployment & EvolutionOperation Change

maintain software during/after user operation

determine whether the product still functionscorrectly

Difficultiesrigid design

lack of documentationpersonnel turnover


22/38

Configuration Management

(CM) [Tichy 1988]CM is a discipline whose goal is tocontrol changes to large software

through the functions ofComponent identificationChange tracking

Version selection and baseliningSoftware manufactureManaging simultaneous updates (teamwork)


23/38

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


24/38


PrinciplesRigor and formalitySeparation of concerns

Modularity and decomposition Abstraction Anticipation of changeGeneralityIncrementalityScalabilityCompositionality

Heterogeneity


25/38

From Principles to Tools

PRINCIPLES

METHODS ANDTECHNIQUES

METHODOLOGIES

TOOLS


26/38

Software QualitiesQualities (a.k.a. ilities) are goals in thepractice of software engineeringExternal vs. Internal qualitiesProduct vs. Process qualities


27/38

External vs. Internal QualitiesExternal qualities are visible to the user

reliability, efficiency, usability

Internal qualities are the concern ofdevelopers

they help developers achieve externalqualitiesverifiability, maintainability, extensibility,evolvability, adaptability


28/38

Product vs. Process QualitiesProduct qualities concern the developedartifacts

maintainability, understandability,performance

Process qualities deal with thedevelopment activity

products are developed through processmaintainability, productivity, timeliness


29/38

Some Software QualitiesCorrectness

ideal quality

established w.r.t. the requirements specificationabsolute

Reliabilitystatistical propertyprobability that software will operate as expectedover a given period of timerelative


30/38

Some Software Qualities

(cont.)Robustness

reasonable behavior in unforeseencircumstancessubjectivea specified requirement is an issue of correctness;an unspecified requirement is an issue ofrobustness

Usabilityability of end-users to easily use softwareextremely subjective


31/38


(cont.)Understandability

ability of developers to easily understand

produced artifactsinternal product qualitysubjective

Verifiabilityease of establishing desired propertiesperformed by formal analysis or testinginternal quality


32/38


(cont.)Performance

equated with efficiency

assessable by measurement, analysis, andsimulation

Evolvabilityability to add or modify functionalityaddresses adaptive and perfective maintenanceproblem: evolution of implementation is too easyevolution should start at requirements or design


33/38


(cont.)Reusability

ability to construct new software from existingpiecesmust be planned foroccurs at all levels: from people to process, fromrequirements to code

Interoperabilityability of software (sub)systems to cooperate withotherseasily integratable into larger systemscommon techniques include APIs, plug-inprotocols, etc.


34/38


(cont.)Scalability

ability of a software system to grow in size

while maintaining its properties andqualitiesassumes maintainability and evolvability

goal of component-based development


35/38


(cont.)Heterogeneity

ability to compose a system from pieces developed inmultiple programming languages, on multiple platforms, by

multiple developers, etc.necessitated by reusegoal of component-based development

Portabilityability to execute in new environments with minimal effortmay be planned for by isolating environment-dependentcomponentsnecessitated by the emergence of highly-distributed systems(e.g., the Internet)an aspect of heterogeneity


36/38

Software Process QualitiesProcess is reliable if it consistently leads to high-quality productsProcess is robust if it can accommodateunanticipated changes in tools and environmentsProcess performance is productivityProcess is evolvable if it can accommodate new

management and organizational techniquesProcess is reusable if it can be applied acrossprojects and organizations


37/38

Assessing Software QualitiesQualities must be measurableMeasurement requires that qualities beprecisely definedImprovement requires accuratemeasurementCurrently most qualities are informallydefined and are difficult to assess


38/38


Axioms Adding developers to a project will likely result infurther delays and accumulated costsBasic tension of software engineering

better, cheaper, faster pick any two!functionality, scalability, performance pick any two!

The longer a fault exists in softwarethe more costly it is to detect and correct

the less likely it is to be properly correctedUp to 70% of all faults detected in large-scale softwareprojects are introduced in requirements and design

detecting the causes of those faults early may reduce theirresulting costs by a factor of 100 or more

Overview of Software Engineering Principles

Documents

Transcript of Overview of Software Engineering Principles