CMSC 435: Sof tware Engineering Section 0201 Atif M. Memon (atif - - PDF document

1

CMSC 435: Sof tware Engineering Section 0201

• Atif M. Memon (atif @cs. umd. edu)
• 4115 A. V. Williams building
• Phone: 301- 405- 3071
• Of f ice hours

– Tu. Th. (11:00am- 1:00pm)

• Don’t wait, don’t hesitate, do

communicate!!

– Phone – E- mail – Of f ice hours – Course discussion group

More Resources

• Class TA

– I shan Banerjee – ishan@cs. umd. edu – Of f ice location

• 4122 A.V.Williams building

– Of f ice hours

• TBA
• Course page

– www. cs. umd. edu/ ~atif/ teaching/ spring2003

2

How Cars are Engineered (A simple view)

• User requirements

– Engine power, all- wheel, seating, comf ort, MP3 player!!

• Detailed design

– Blueprints, design documents

• Test design

– Simulation, prototyping

• Develop parts (components)

– Test each component – Components may be reused – Mass produced

• Assemble the car

– Test the car

• Fr ont / side cr ash t est s
• St abilit y t est s

– Usability testing

• Feedback f r om dr iver s/ passenger s

I n Pictures!!

3

But Seriously

• Features of many LEGO parts

– Modularity – Reusability

• Each part can be used in dif f erent places

and ways

– Flexibility of design – Compatibility

• Wit h ot her LEGO set s
• Building- blocks

Similar Techniques Used by Builders: Bridges

4

Detailed Design and Specif ications

Galvanized Bridge Wire for Parallel Wire Bridge Cables. Recommended diameter .196 inch. Galvanized Bridge Strand--consists of several bridge wires, of various diameters twisted together. Galvanized Bridge Rope--consists of six strands twisted around a strand core.

Parallel Wire Cable

Detail of Main Cable and Cable Band. The wrapping wire is omitted at the right for clarity. Note the closed construction and aluminum fillers.

More Detailed Design and Specif ications

5

Tacoma Narrows Bridge Disaster Back to Sof tware

• Sof tware uses some of the most

complex structures ever designed

• Need to apply/ develop engineering

principles to/ f or sof tware

• Sof tware engineering is concerned

with theories, methods and tools f or prof essional sof tware development

6

I mportant: Team Work

• Most sof tware is developed

– By teams of

• Designers
• P

rogrammers

• Managers
• Social skills

– Trust other team members

• They will develop sof t ware component s t hat you may

use

• Management skills

– Schedules – Work distribution – Budget

A Few Facts About Sof tware Today

• Sof tware costs of ten dominate

system costs.

– The costs of sof tware are of ten greater than the hardware cost

• Sof tware costs more to maintain

than it does to develop.

– For systems with a long lif e, maintenance costs may be several times development costs

7

Costs I nvolved

• Typically

– 60% of costs are development costs, – 40% are testing costs. – For custom sof tware, evolution costs of ten exceed development costs

• Costs vary depending on the type of

system being developed and the requirements of system attributes such as perf ormance and system reliability

• Distribution of costs depends on the

development method that is used

We will Engineer Sof tware

• But what is sof tware?

– Computer programs and – Associated documentation

• Sof tware products may be

developed f or

– A particular customer or – A general market

8

Role of a Sof tware Engineer

• Sof tware engineers should adopt a

systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available

Attributes of Good Sof tware

• Should deliver the required f unctionality

and perf ormance

• Maintainability

– Sof tware must evolve to meet changing needs

• Dependability

– Sof tware must be trustworthy

• Ef f iciency

– Sof tware should not make wastef ul use of system resources

• Usability

– Sof tware must be usable by the users f or which it was designed

9

Sof tware Processes

• What is a Sof tware Process?

– A set of activities whose goal is the development or evolution of sof tware

• Some Activities:

– Specif ication

• what t he syst em should do and it s development

const raint s

– Development

• product ion of t he sof t ware syst em

– Validation

• checking t hat t he sof t ware is what t he cust omer

want s

– Evolution

• changing t he sof t ware in response t o changing

demands

Sof tware Process Models

• A simplif ied representation of a sof tware

process, presented f rom a specif ic perspective

• Examples of process perspectives are

– Workf low perspective

• sequence of act ivit ies

– Data- f low perspective

• inf ormat ion f low

– Role/ action perspective

• who does what
• Generic process models

– Waterf all – Evolutionary development – Formal transf ormation – I ntegration f rom reusable components

10

Generic Sof tware Process Models

• The waterf all model

– Separate and distinct phases of specif ication and development

• Evolutionary development

– Specif ication and development are interleaved

• Formal systems development

– A mathematical system model is f ormally transf ormed to an implementation

• Reuse- based development

– The system is assembled f rom existing components

Waterf all Model

Requirements Def inition Requirements Def inition System & Sof tware Design System & Sof tware Design I mplementation & Unit Testing I mplementation & Unit Testing I ntegration & System Testing I ntegration & System Testing Operation & Maintenance Operation & Maintenance

11

Waterf all Model Problems

• I nf lexible partitioning of the

project into distinct stages

• This makes it dif f icult to respond

to changing customer requirements

• Theref ore, this model is only

appropriate when the requirements are well- understood

Evolutionary Development

• Exploratory development

– Objective is to work with customers and to evolve a f inal system f rom an initial outline specif ication. Should start with well- understood requirements

• Throw- away prototyping

– Objective is to understand the system

• requirements. Should start with poorly

understood requirements

12

Evolutionary Development

Outline Description Outline Description Specif ication Specif ication Development Development Validation Validation I nitial Version I nitial Version I ntermediate Versions I ntermediate Versions I ntermediate Versions I ntermediate Versions Final Version Final Version Concurrent Activities

Evolutionary Development

• Problems

– Lack of process visibility – Systems are of ten poorly structured – Special skills (e. g. in languages f or rapid prototyping) may be required

• Applicability

– For small or medium- size interactive systems – For parts of large systems (e. g. the user interf ace) – For short- lif etime systems

13

Formal Systems Development

• Based on the transf ormation of a

mathematical specif ication through dif f erent representations to an executable program

• Transf ormations are ‘correctness-

preserving’ so it is straightf orward to show that the program conf orms to its specif ication

• Embodied in the ‘Cleanroom’

approach to sof tware development

Formal Systems Development

Requirements Def inition Requirements Def inition Formal Specif ication Formal Specif ication Formal Transf ormation Formal Transf ormation I ntegration & System Testing I ntegration & System Testing

14

Formal Transf ormations

Formal Specif ication Formal Specif ication Executable Program Executable Program R3 R3 R2 R2 R1 R1 P1 P1 P2 P2 P3 P3 P4 P4 T1 T2 T3 T4 Formal Transf ormations Proof s of Transf ormation Correctness

Formal Systems Development

• Problems

– Need f or specialised skills and training to apply the technique – Dif f icult to f ormally specif y some aspects of the system such as the user interf ace

• Applicability

– Critical systems especially those where a saf ety or security case must be made bef ore the system is put into

• peration

15

Reuse- oriented Development

• Based on systematic reuse where

systems are integrated f rom existing components or COTS (Commercial- of f - the- shelf ) systems

• Process stages

– Component analysis – Requirements modif ication – System design with reuse – Development and integration

• This approach has received a lot of

attention recently

Reuse- oriented Development

Requirements Specif ication Requirements Specif ication Component Analysis Component Analysis Requirements Modif ication Requirements Modif ication System Validation System Validation System Design With Reuse System Design With Reuse Development & I ntegration Development & I ntegration

16

Process I teration

• System requirements ALWAYS

evolve in the course of a project so process iteration where earlier stages are reworked is always part

• f the process f or large systems
• I teration can be applied to any of

the generic process models

• Two (related) approaches

– I ncremental development – Spiral development

I ncremental Development

• Rather than deliver the system as a

single delivery, the development and delivery is broken down into increments with each increment delivering part of the required f unctionality

• User requirements are prioritized and

the highest priority requirements are included in early increments

• Once the development of an increment is

started, the requirements are f rozen though requirements f or later increments can continue to evolve

17

I ncremental Development

Def ine Outline Requirements Def ine Outline Requirements Assign Requirements to I ncrements Assign Requirements to I ncrements Design System Architecture Design System Architecture Develop System I ncrement Develop System I ncrement Validate I ncrement Validate I ncrement I ntegrate I ncrement I ntegrate I ncrement Validate System Validate System Final Version Final Version System I ncomplete

I ncremental Development Advantages

• Customer value can be delivered

with each increment so system f unctionality is available earlier

• Early increments act as a prototype

to help elicit requirements f or later increments

• Lower risk of overall project f ailure
• The highest priority system

services tend to receive the most testing

18

Extreme Programming

• New approach to development based
• n the development and delivery of

very small increments of f unctionality

• Relies on constant code

improvement, user involvement in the development team and pairwise programming

Spiral Development

• Process is represented as a spiral rather

than as a sequence of activities with backtracking

• Each loop in the spiral represents a

phase in the process.

• No f ixed phases such as specif ication or

design - loops in the spiral are chosen depending on what is required

• Risks are explicitly assessed and resolved

throughout the process

19

Spiral Model of the Sof tware Process

Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototyp e 3 Opera- tional protoype Concept o f Operation Simulations, models, benchmarks S/W requirements Requirement valid a tion Design V&V Product design Detailed design Code Unit test Integr a tion test Acceptance test Serv ice Develop, verify next-level product Evaluate alternatives identify, resolve risks Determine ob jectiv es alternatives and constraints Plan next p ha se Integration and test p lan Development pla n Requirements plan Life-cycle plan REVIEW

Spiral Model Sectors

• Objective setting

– Specif ic objectives f or the phase are identif ied

• Risk assessment and reduction

– Risks are assessed and activities put in place to reduce the key risks

• Development and validation

– A development model f or the system is chosen which can be any of the generic models

• Planning

– The project is reviewed and the next phase

• f the spiral is planned

20

Sof tware Specif ication

• The process of establishing what

services are required and the constraints on the system’s

• peration and development

The Requirements Engineering Process

Feasibility Study Feasibility Study Requirements Elicitation & Analysis Requirements Elicitation & Analysis Requirements Specif ication Requirements Specif ication Requirements Validation Requirements Validation Requirements Document Requirements Document User & System Requirements User & System Requirements System Models System Models Feasibility Report Feasibility Report

21

Sof tware Design and I mplementation

• The process of converting the system

specif ication into an executable system

• Sof tware design

– Design a sof tware structure that realises the specif ication

• I mplementation

– Translate this structure into an executable program

• The activities of design and

implementation are closely related and may be inter- leaved

The Sof tware Design Process

Architectural Design Architectural Design

Requirements Specif ication Requirements Specif ication

Abstract Specif icat ion Abstract Specif icat ion I nt erf ace Design I nt erf ace Design Component Design Component Design Dat a Structure Design Dat a Structure Design Algorit hm Design Algorit hm Design Algorit hm Specif icat ion Algorit hm Specif icat ion System Architecture System Architecture Sof t ware Specif icat ion Sof t ware Specif icat ion I nt erf ace Specif icat ion I nt erf ace Specif icat ion Component Specif icat ion Component Specif icat ion Data Structure Specif icat ion Data Structure Specif icat ion

Design Activities Design Products

22

Design Methods

• Systematic approaches to

developing a sof tware design

• The design is usually documented as

a set of graphical models

• Possible models

– Dat a- f low model – Entity- relation- attribute model – Structural model – Object models

Programming and Debugging

• Translating a design into a program

and removing errors f rom that program

• Programming is a personal activity -

there is no generic programming process

• Programmers carry out some

program testing to discover f aults in the program and remove these f aults in the debugging process

23

The Debugging Process

Locate Error Locate Error Design Error Repair Design Error Repair Repair Error Repair Error Retest Program Retest Program

Sof tware Validation

• Verif ication and validation is intended to

show that a system conf orms to its specif ication and meets the requirements

• f the system customer
• I nvolves checking and review processes

and system testing

• System testing involves executing the

system with test cases that are derived f rom the specif ication of the real data to be processed by the system

24

The Testing Process

Unit Testing Unit Testing Module Testing Module Testing Sub- system Testing Sub- system Testing System Testing System Testing Acceptance Testing Acceptance Testing Component Testing I ntegration Testing User Testing

Testing Stages

• Unit testing

– I ndividual components are tested

• Module testing

– Related collections of dependent components are tested

• Sub- system testing

– Modules are integrated into sub- systems and tested. The f ocus here should be on interf ace testing

• System testing

– Testing of the system as a whole. Testing of emergent properties

• Acceptance testing

– Testing with customer data to check that it is acceptable

25

Testing Phases

Requirements Specif ication Requirements Specif ication System Design System Design System Specif ication System Specif ication Detailed Design Detailed Design Module & Unit Code & Tests Module & Unit Code & Tests Sub- system I ntegration Test Sub- system I ntegration Test System I ntegration Test System I ntegration Test Acceptance Test Acceptance Test

Service Service Acceptance Test Plan Acceptance Test Plan Sub- system I ntegration Test Plan Sub- system I ntegration Test Plan System I ntegration Test Plan System I ntegration Test Plan

Sof tware Evolution

• Sof tware is inherently f lexible and

can change.

• As requirements change through

changing business circumstances, the sof tware that supports the business must also evolve and change

26

System Evolution

Def ine System Requirements Def ine System Requirements New System New System Existing Systems Existing Systems Assess Existing Systems Assess Existing Systems Propose System Changes Propose System Changes Modif y Systems Modif y Systems