comp2110 software design in 2004 chris...

DE?!GNsoftware

COMP2110 Software Design in 2004

Chris Johnson

1. Software Requirements and Software Design in a framework for Software Engineering

2. The Software Engineering ideas and conceptsin comp2110

3. Organisation of the course comp2110 in 2004It's similar to 2003 but

the time schedule is different

Industrial Design?Ph

ilipp

e St

arck

ww

w.p

hilip

pes

tarc

k.co

m

DE?!GN

Engineering design?

Software Design

Part of a Software Engineering process:● analyse● design● implement● test● maintain

The Waterfall Software Process

time

Requirements Analysis

Design

Milestone(s)

Phases (activities)

Implementation

Testing

Maintenance

Release product X

Two phases may occur at the same time for a short period

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

The Framework: main phases of the Software Process

1. Requirements Analysis (answers “ WHAT?” ) Specifying what the application must do

2. Design (answers “ HOW?” ) Specifying what the parts will be, and how they will fit together

3. Implementation (alias “ CODING”) Writing the code

4. Testing (a type of VERIFICATION) Executing the application with test data for input

5. Maintenance (REPAIR or ENHANCEMENT) Repairing defects and adding capability


Software Process Phases: Personal

Finance Example

❏ Requirements Analysis: Text producede.g., “ … The application shall display the balance in the user’ s bank account. … ”

❏ Design: Diagrams and text e.g., “ … The design will consist of the classes CheckingAccount,

SavingsAccount, … ”❏ Implementation: Source and object code

e.g., … class CheckingAccount{ double balance; … } …❏ Testing: Test cases and test results

e.g., “ … With test case: deposit $44.92 / deposit $32.00 / withdraw $101.45 / … the balance was $2938.22, which is correct. … ”

❏ Maintenance: Modified design, code, and text e.g., Defect repair: “ Application crashes when balance is $0 and

attempt is made to withdraw funds. … ”e.g., Enhancement: “ Allow operation with Euro currency.”


The Waterfall Software Process

time

Requirements Analysis

Design

Implementation

Testing

Maintenance


Why a Pure Waterfall Process is Usually Not Practical

1. We don’ t know up front everything wanted and needed Usually hard to visualize every detail in advance

2. We can only estimate the costs of implementing requirements (and the feasibility of the project)

1. To gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones

2. We will probably need to modify requirements as a result3. We often need to execute intermediate builds of programs

1. Stakeholders (clients, managers) need to gain confidence2. Designers and developers need confirmation they're building

what’ s needed and wanted(use frequent incremental building and testing)

4. Team members are not idle while others do requirements Typically put people to work on several phases at once


See also: in comp2110 eBrick. Parnas and Clements,A Rational Design Process, How and Why to Fake It

Another way(1): Spiral development process

completetargeted

requirements

Step n:Analyzerequirements

Step n+3: Test

Step n+2: Implement

Step n+1:Design

Product:classmodels +

Product: requirementsspecifications

Product: code + Product: test results +Adapted from Software Engineering: An ObjectOriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Spiral Process

time

1 R eq u irem en tsan aly s is

D es ig n

C o d in g

T es tin g

1Itera tio n #

1

1

2

2

2

3

3

3

Product released X

M I L E S T O N E S

2 3

2 3 1


Intermediate version(prototype) X

Intermediate version(2nd prototype) X

Another way(2): overlapping phases

Elaboration

Unified Process Matrix

Inception Construction Transition

Requirements

Analysis

Jacobson et al: USDP

Prelim.iterations

Iter.#1

Iter.#n

Iter.#n+1

Iter.#m

Iter.#m+1

Iter.#k

… .. … ..

Design

Implementation

Test

..

Adapted from Software Engineering: An ObjectOriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “ P’ s” of Software Engineering

People

(by whom it is done)

*

* Symbology from Ivar Jacobson,OO Software Engineering a Case Driven Approach AddisonWesley 1994Adapted from Software Engineering: An ObjectOriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Process(the manner in which it is done)

Elaboration



Requirements

Analysis


Prelim.iterations

Iter.#1

Iter.#n

Iter.#n+1

Iter.#m

Iter.#m+1

Iter.#k

… .. …..

Design

Implementation

Test

..


People



Project

(the doing of it)


People



Elaboration



Requirements

Analysis


Prelim.iterations

Iter.#1

Iter.#n

Iter.#n+1

Iter.#m

Iter.#m+1

Iter.#k

… .. …..

Design

Implementation

Test

..



People



Project

(the doing of it)

Product

(the application artifacts)

Elaboration



Requirements

Analysis


Prelim.iterations

Iter.#1

Iter.#n

Iter.#n+1

Iter.#m

Iter.#m+1

Iter.#k

… .. …..

Design

Implementation

Test

..*


Product



Software Engineering Product – the artifacts

Design model

a document in UML, for example

Source code programand object code

Software requirements specification

a document in legalistic English, and UML, for example


Product


c2110 concerns

What's in the course? comp2110 components

● core content– specifications of requirements for software– methods for designing software for a given purpose– technical "design ideas" to use

● at high level● at detailed level

● supporting concepts– notational methods for describing software design– notations for specification of requirements– software lifecycle framework– "quality" – what makes it a good design (or not)

What's in the course? comp2110 components (2)● core content: methods, design ideas, specification

● supporting concepts: notations, framework, quality

● not what you might have hoped for:– not user interface design – a specialised topic

● not what you might have feared:– not rigid "methodology"

or recipes for cookbook design

● develops your skills in doing design by making descriptions and by criticising existing designs

COMP2110 Organisation

● people● lectures● tutorials and laboratories● textbook● assignments● exam● assessment scheme

COMP2110 course organisation (1)● People

– Lecturer and tutor: Chris Johnson– Tutors: Tamiru Jarso and (tbc)

● Lectures see web courseplan– 3 per week: total 26

Mon, Tues, Fri (week 5 M only, week 13 M&T)– no lectures in weeks 6 & 8 (before the break) – week 7: no lectures, group work presentations in labs

● Tutorials & laboratories see web courseplan– weeks 26, 812 learning by practising

● TextbookEric Braude, Software Design the green book

COMP2110 course organisation (2)

● assignments no programming

1) criticise and create requirements

2) in small groups (3 or 4):create requirements, criticise existing design, start creating project designGroups will make 1 presentation and submit 1 report.

3) individual:detailed design and modified requirements for project

● final exam yes: sit down; written; open book● assessment scheme details: Friday 23 July

comp2110 software design in 2004 chris...

Documents