Components Based Design and Development. Unit 2: Software Engineering Quick Overview

(1)

Components Based Design and Development

Computer Engineering Studies Universidad Carlos III de Madrid

Juan Llorens

Högskolan på Åland – Finland / Universidad Carlos III de Madrid - Spain [email protected]

Unit 2: Software Engineering Quick Overview

(2)

Software Engineering

• Engineering...

“the profession in which

a knowledge of the mathematical and natural sciences gained by study, experience and practice

is applied with judgment

to develop ways to utilize, economically, the materials and forces of

nature for the benefit of mankind.” (Accreditation Board for Engineering nature for the benefit of mankind.” (Accreditation Board for Engineering and Technology, 1996).

• Particularities of software engineering

– The “product” (software)

– A lot of development, little engineering discipline – Frequent changes in the product

– It is not seen as necessary by the “so called” software engineers

From Gonzalo Genova

(3)

Software Engineering

• The economies of ALL developed nations are dependent on software.

• More and more systems are software controlled

• Software engineering is concerned with theories, methods and tools for

• Software engineering is concerned with theories, methods and tools for professional software development.

• Expenditure on software represents a

significant fraction of GNP in all developed countries.

©Ian Sommerville 2004 - Software Engineering, 7th edition. Chapter 1

(4)

The systems engineering process

System design Requirements

definition

System evolution

System decommissioning

System integration Sub-system

development design

System installation

evolution

(5)

Inter-disciplinary involvement

Electronic engineering

Mechanical engineering Software

engineering

ATC systems engineering

Electrical engineering

User interface design

Architecture Structural

engineering

Civil engineering

(6)

What is a software process?

Objectives, needs, ideas problems, failures,..

“Software application”

BNot a Software system

How is a software project done?

(7)

What is a software process?

• A set of activities whose goal is the development or evolution of software.

• Generic activities in all software processes are:

– Specification - what the system should do and its development constraints – Development - production of the software system

– Validation - checking that the software is what the customer wants – Evolution - changing the software in response to changing demands.

(8)

What is a software process model?

• A simplified representation of a software process, presented from a specific perspective.

• Examples of process perspectives are

– Workflow perspective - sequence of activities;

– Data-flow perspective - information flow;

– Role/action perspective - who does what.

• Generic process models

– Waterfall;

– Iterative development;

– Component-based software engineering.

(9)

Usual workflow Activities

design implementation tests

Req. analysis

Not so Usual workflow Activities

Project Mgmt Estimation Debriefing Vocabulary Id.

Risk Mgmt. Project Plan. Indexing

Sw For Reuse

(10)

Types of Software Processes : the waterfall process

analysis of requirements Need

A single iteration

design

implementation

tests Final product is an idealization never

realized in this pure form

(11)

Iterative process [spiral]

Requirements analysis design

N iterations

implementation tests

need

N versions of the product, documentation...

final product

(12)

Iterative and incremental process

• Enables the evolution in parallel of several workflows, and by that the work in parallel of several teams of people

• the different versions of the documents produced in each iteration are not necessarily compatible between them: organize well the documentation

iteration 1 iteration 2 iteration 3

analysis (version 1)

analysis (version 2)

analysis (version 3) design

(version 1)

design (version 2) implementation

(version 1)

(13)

UP: Phases, iterations and workflows

requirements

analysis

Phases of the life cycle

Workflows _Inception Elaboration Construction Transition

an iteration in the phase of Elaboration

design

implementation

tests

iterations

Preliminary iteration(s)

Iter.

#1

Iter.

#2

Iter.

#n

Iter.

#n+1

Iter.

#n+2

Iter.

#m

Iter.

#m+1

(14)

My Favorite workflow structure

for Development

S o ft w a re fo r R e u se

New Project

PMgnt

Risk

Plan-Est

Req Ana

S o ft w a re w ith R e u se

Req Cap

Voc

Sw for reuse

Find + Reuse

S o ft w a re fo r R e u se

New Solution

Req Ana

Arc. Des

D Des

Dev

Tes

Db

Ix

S o ft w a re w ith R e u se

CM

WG

Traceability

Document Mngmnt.

(15)

My Favorite dataflow structure

for Development

PMgnt

Risk

Plan-Est

Req Ana Req Cap

Voc

^Ontology

Document Templates

Gantt Diagrams Spreadsheets

Text based Requirements

Text Based Risks

Requirements Models

Req Ana

Arc. Des

D Des

Dev

Tes

Db

Ix

Requirements Models Documents

Architectural Models

Software Models Code

Reports Acknowledged

Reports Documents

Documents

(16)

Terminology of UP Classical terminology requirements

requirements analysis analysis

Other frameworks and nomenclatures

design design

implementation

implementation integration

tests tests

Eric Braude, Software Engineering. An Object-Oriented Perspective, John Wiley & Sons, 2001, p. 30.

(17)

• divide a project in mini-projects, easier to manage and complete

• each mini-project is an iteration

• each iteration contains all the elements of a normal project:

– planning

– analysis and design – construction

How to perform an Iterative Software Process

– construction

– integration and tests

– generate a version of the product (internal or external)

• each iteration generates a baseline that includes a partially completed version of the final system, and all the associated documentation

• the successive iterations build on top of each other until the final system is finished

• the difference between two baselines is known as an increment

(18)

What are software engineering methods?

• Structured approaches to software development which include system models, notations, rules, design advice and process guidance.

• Model descriptions

– Descriptions of graphical models which should be produced;

• Rules

– Constraints applied to system models;

• Recommendations

– Advice on good design practice;

• Process guidance

– What activities to follow.

Based on Ian Sommerville 2004 - Software Engineering, 7th edition. Chapter 1

(19)

What are the costs of software engineering?

• Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.

• Costs vary depending on the type of system being developed and the

requirements of system attributes such as performance and system reliability.

• Distribution of costs depends on the development model that is used.

(20)

Software costs

• Software costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost.

• Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs.

• Software engineering is concerned with cost-effective software development.

(21)

Activity cost distribution

Waterfall model

Iterative development

Specification Design Development Integration and testing

25 50 75 100

0

25 50 75 100

0

Component-based software engineering

Development and evolution costs for long-lifetime systems

System evolution

10 200 30 400

0

System development

Specification Development Integration and testing

25 50 75 100

0

Specification Iterative development System testing

(22)

Product development costs

(23)

The maturity of the Software Engineering discipline (swing)

1. Real need: what the customer really wanted.

2. Client side: what the client was able to describe as his/her clear need.

3. Sale process: what the software manufacturer promised the client.

4. Requirements: the final understanding of what the customer described as requirements.

the customer described as requirements.

5. Analysis: how was planned that the system should finally work at the client side.

6. Design: how the system should perform the analysed functionality.

7. Coding: what the programmer finally produced.

8. On-site installation: what was really installed in the client site.

9. Test: what the responsibles saw in the system.