l01web 2x2

23
Comp 6471 Software Design Methodologies COMP 6471/4 NN Steven Winikoff [email protected] H-966-2 514-848-2424, ext. 7619 Comp 6471 Motivation …with proper design, the features come cheaply. This approach is arduous, but continues to succeed. - Dennis Ritchie Comp 6471 What This Course is About simple questions: What should go into a given piece of software? How do you put it there? ...with complex answers Page 7 Comp6471 Software Design Methodologies Software Engineering ca. 1968: Reasons for the software crisis were determined. Software development should be treated as an engineering activity and not as an ad-hoc activity => software development should be a systematical activity. Definition provided by the IEEE: Software Engineering is the systematic approach to development , maintenance, organization of software systems. Starting point of the software crisis. Acknowledgement: These slides are based on work originally created by Dr. Juergen Rilling, CSE, Concordia

Upload: banimustafa

Post on 24-Jan-2015

142 views

Category:

Documents


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: L01web 2x2

Com

p 64

71

Software Design Methodologies

COMP 6471/4 NN

Steven [email protected]

H-966-2514-848-2424, ext. 7619

Com

p 64

71

Motivation

…with proper design, the features come cheaply. This approach is arduous, but continues to succeed.

- Dennis Ritchie

Com

p 64

71

What This Course is About

simple questions:

What should go into a given piece of software?

How do you put it there?

...with complex answers

Page 7

Comp6471 Software Design Methodologies

Software Engineeringca. 1968: Reasons for the software crisis were determined.

Software development should be treated as an engineering activity and not as an ad-hoc activity => software development should be a systematical activity. Definition provided by the IEEE:

Software Engineering is the systematic approach to development , maintenance, organization of software systems.

Starting point of the software crisis.

Acknowledgement: These slides are based on work originally created by Dr. Juergen Rilling, CSE, Concordia

Page 2: L01web 2x2

Page 8

Comp6471 Software Design Methodologies

Goals of Software Engineering

Improve the productivity of the programming/development processImprove the comprehension of the developed software systemImprove the maintainability of the systemsImprove the quality of the software system (software product)Improve the “quality” of the software system.

- Reliability- Efficiency (Speed, resource usage)- User-friendly (user acceptance)

General goal:

Produce software which is useful for people

Page 9

Comp6471 Software Design Methodologies

Software Life Cycle

Software Engineering

0

10

20

30

40

50

60

70

Analys

is

Specif

icatio

n

Design

Imple

men

tatio

n

Testin

g

Software Life Cycle Phase

Eff

ort Without SE

Applying SE

The phases of a software development cycle.

Analysis:

Specification

Design

Implementation

Testing

Delivery/Maintenance

Page 10

Comp6471 Software Design Methodologies

Software Life Cycle

Feasibility study – WHY? Cost benefit analysis (is it worth doing the project)

Requirements analysis + specification: WHAT? What should the software do, produce a document.

Design - How? How should the software do it. Architectural design (overall structures + organization of objects/modules, choice of data structures, etc.

Coding/Implementation: Realize ! components. Code modules, prodcuts: software,

Testing: Realize ! Test individual modules, test whether modules work together, test system as a whole, document test results.

Delivery and maintenance: Evolve!

Page 11

Comp6471 Software Design Methodologies

Goals of Software EngineeringProducts: External deliverables, internal products; software products: final

code, test driversPaper documents: external: user manual, installation guide; Internal: requirements document, specification document, design document, test plan

Processes: How the software is created, how its quality is evaluated and ensured

Tools: CASE tools, editors, project management tools

People: Technical, social and managerial skills

Principles Providing permanency, guidelines and maturity in the software development process.

Page 3: L01web 2x2

Page 12

Comp6471 Software Design Methodologies

Skills of a Software Engineer

Programming: data structures and algorithms programming languages tools: compilers, debuggers, editors

Communication: spoken, written, presentations teamwork with external people (customers)

Page 13

Comp6471 Software Design Methodologies

Skills of a Software Engineer

Design– be familiar with several approaches– be flexible and open to different application domains– be able to shift between several level of abstraction – application domain jargon– requirements and specification: declarative model– architectural design, high-level operational model – detailed coding

Page 14

Comp6471 Software Design Methodologies

Software Lifecycle Models

Definition.A (software/system) lifecycle model is a description of the sequence of activities carried out in a software engineering project, and the relative order of these activities.

Page 15

Comp6471 Software Design Methodologies

A lifecycle model provides a fixed generic framework that can be tailored to a specific project.

Project specific parameters will include: size (person-years), budget, duration. project plan = lifecycle model + project parameters

Page 4: L01web 2x2

Page 16

Comp6471 Software Design Methodologies

There are many different lifecycle models to choose from, e.g:

waterfall, code-and-fix spiral rapid prototyping unified process (UP) agile methods, extreme programming (XP) COTS …

but many are minor variations on a smaller number of basic models.

Page 17

Comp6471 Software Design Methodologies

By changing the lifecycle model, we can improve and/or trade off:

development speed (time to market) product quality project visibility administrative overhead risk exposure customer relations, etc, etc.

Page 18

Comp6471 Software Design Methodologies

Normally, a lifecycle model covers the entirelifetime of a product.

From the birth of an idea to the final deinstallation of the last release

i.e. The three main phases:design,build,maintain.

Page 19

Comp6471 Software Design Methodologies

Note that we can sometimes combine lifecycle modelse.g. waterfall inside evolutionary – onboard

shuttle software

We can also change lifecycle model between releases as a product matures,

e.g. rapid prototyping → waterfall

Page 5: L01web 2x2

Page 20

Comp6471 Software Design Methodologies

The Waterfall Model

• Classic lifecycle model – widely known, understood and (commonly?) used.

• In some respect, waterfall is the "commonsense" approach

(Introduced by Royce 1970)

Page 21

Comp6471 Software Design Methodologies

User Requirements

Software Requirements

Architecture Design

Detailed design & Coding

Testing

Delivery

The WaterfallLifecycle Workflow

Time

User Requirements Document

Software Requirements Document

Architectural DesignDocument

DetailedDesign & Code

phaseoutput

”Swimmingupstream”

Page 22

Comp6471 Software Design Methodologies

Advantages

1. Easy to understand and implement.2. Widely used and known (in theory!)3. Reinforces good habits: define-before-design,

design-before-code4. Identifies deliverables and milestones5. Document driven, URD, SRD, … etc. Published

documentation standards, e.g. PSS-05.6. Works well on mature products and weak teams.

Page 23

Comp6471 Software Design Methodologies

Disadvantages I

● Idealized, doesn’t match reality well.● Doesn’t reflect iterative nature of exploratory

development.● Unrealistic to expect accurate requirements so early

in project● Software is delivered late in project, delays

discovery of serious errors.

Page 6: L01web 2x2

Page 24

Comp6471 Software Design Methodologies

Disadvantages II

● Difficult to integrate risk management● Difficult and expensive to make changes to

documents, ”swimming upstream”.● Significant administrative overhead, costly for

small teams and projects.

Page 25

Comp6471 Software Design Methodologies

Code-and-Fix

This model starts with an informal general product idea and just develops code until a product is ”ready” (or money or time runs out). Work is in random order.

Corresponds with no plan!

Page 26

Comp6471 Software Design Methodologies

Advantages

● No administrative overhead● Signs of progress (code) early.● Low expertise, anyone can use it!● Useful for small “proof of concept” projects,

e.g. as part of risk reduction.

Page 27

Comp6471 Software Design Methodologies

Disadvantages

1. Dangerous! ● No visibility/control● No resource planning● No deadlines● Mistakes hard to detect/correct

2. Impossible for large projects,communication breakdown, chaos.

Page 7: L01web 2x2

Page 28

Comp6471 Software Design Methodologies

Spiral Model

Since end-user requirements are hard to obtain/define, it is natural to develop softwarein an experimental way: e.g.

1. Build some software2. See if it meets customer requirements3. If no goto 1 else stop.

Page 29

Comp6471 Software Design Methodologies

This loop approach gives rise to structurediterative lifecycle models.

In 1988 Boehm developed the spiral model asan iterative model which includes riskanalysis and risk management.

Key idea: on each iteration identify and solvethe sub-problems with the highest risk.

Page 30

Comp6471 Software Design Methodologies

Cumulative cost

Evaluate alternatives,Identify & resolve risks

Develop & verify next-level product

Plan next phase

Determine objectives,alternatives & constraints

Review & commitment

Prototypes

P1 P2 P3Operational PrototypeStart

End

Requirements plan

Development plan

Integration & Test plan

Requirements validation

Design, Validation & Verification

Detailed design

Coding

Unit & IntegrationTesting

Acceptance Testing

Concept Of Operation

Page 31

Comp6471 Software Design Methodologies

Each cycle follows a waterfall model by:

1. Determining objectives2. Specifying constraints3. Generating alternatives4. Identifying risks5. Resolving risks6. Developing next-level product7. Planning next cycle

Page 8: L01web 2x2

Page 32

Comp6471 Software Design Methodologies

Advantages

1. Realism: the model accurately reflects the iterative nature of software development on projects with unclear requirements

2. Flexible: incorporates the advantages of the waterfall and rapid prototyping methods

3. Comprehensive model decreases risk4. Good project visibility.

Page 33

Comp6471 Software Design Methodologies

Disadvantages

Needs technical expertise in risk analysis to really work

Model is poorly understood by non-technical management, hence not so widely used

Complicated model, needs competent professional management. High administrative overhead.

Page 34

Comp6471 Software Design Methodologies

Rapid Prototyping

Key idea: Customers are non-technical andusually don’t know what they want/can have.

Rapid prototyping emphasises requirementsanalysis and validation, also called: customer oriented development, evolutionary prototyping

Page 35

Comp6471 Software Design Methodologies

Requirements Capture

Quick Design

Build Prototype

Customer Evaluation ofPrototype

Engineer Final Product

The RapidPrototype Workflow

Iterate

Page 9: L01web 2x2

Page 36

Comp6471 Software Design Methodologies

Advantages

1. Reduces risk of incorrect user requirements2. Good where requirements are

changing/uncommitted3. Regular visible progress aids management4. Supports early product marketing

Page 37

Comp6471 Software Design Methodologies

Disadvantages I

1. An unstable/badly implemented prototype often becomes the final product.

2. Requires extensive customer collaboration– Costs customers money– Needs committed customers– Difficult to finish if customer withdraws– May be too customer specific, no broad market

Page 38

Comp6471 Software Design Methodologies

Disadvantages II

3. Difficult to know how long project will last4. Easy to fall back into code-and-fix without

proper requirements analysis, design, customer evaluation and feedback.

Page 39

Comp6471 Software Design Methodologies

Agile (XP) Manifesto

XP = Extreme Programming emphasizes: Individuals and interactions

– Over processes and tools

Working software– Over documentation

Customer collaboration– Over contract negotiation

Responding to change– Over following a plan

Page 10: L01web 2x2

Page 40

Comp6471 Software Design Methodologies

Agile Principles (Summary)

Continuous delivery of software Continuous collaboration with customer Continuous update according to changes Value participants and their interaction Simplicity in code, satisfy the spec

Page 41

Comp6471 Software Design Methodologies

XP Practices (Summary)

Programming in pairs Test driven development Continuous planning, change , delivery Shared project metaphors, coding standards and

ownership of code No overtime! (Yeah right!)

Page 42

Comp6471 Software Design Methodologies

Advantages

Lightweight methods suit small-medium size projects

Produces good team cohesion Emphasizes final product Iterative Test-based approach to requirements and quality

assurance

Page 43

Comp6471 Software Design Methodologies

Disadvantages

Difficult to scale up to large projects where documentation is essential

Needs experience and skill if not to degenerate into code-and-fix

Programming pairs is costly Test case construction is a difficult and specialized

skill.

Page 11: L01web 2x2

Page 44

Comp6471 Software Design Methodologies

COTS

COTS = Commercial Off-The-Shelf software Engineer together a solution from existing

commercial software packages using minimal software "glue".

E.g. using databases, spread sheets, word proccessors, graphics software, web browsers, etc.

Page 45

Comp6471 Software Design Methodologies

Advantages Fast, cheap solution May give all the basic functionality Well defined project, easy to run

Disadvantages Limited functionality Licensing problems, freeware, shareware, etc. License fees, maintainance fees, upgrade

compatibility problems

Com

p 64

71 Iterative Development and the Unified Process

Acknowledgement: These slides for the Iterative Development process were originally created by Dr. Constantinos Constantinides, CSE, Concordia

Page 47

Comp6471 Software Design Methodologies

Unified Process (UP)

Booch, Jacobson, Rumbaugh 1999. Lifetime of a software product in cycles:

– Birth, childhood, adulthood, old-age, death.

Product maturity stages Each cycle has phases, culminating in a new

release (c.f. Spiral model)

Page 12: L01web 2x2

Page 48

Comp6471 Software Design Methodologies

Iterative Development

The iterative lifecycle is based on the successive enlargement and refinement of a system though multiple iterations with feedback and adaptation.

The system grows incrementally over time, iteration by iteration.

The system may not be eligible for production deployment until after many iterations.

Page 49

Comp6471 Software Design Methodologies

Iterative Development[iteration N]Requirements – Analysis - Design- Implementation - Testing

[iteration N+1]Requirements – Analysis - Design- Implementation - Testing

Feedback from iteration N leads torefinement and adaptation of therequirements and design in iterationN+1.

The system growsincrementally.

Page 50

Comp6471 Software Design Methodologies

Iterative Development

The output of an iteration is not an experimental prototype but a production subset of the final system.

Each iteration tackles new requirements and incrementally extends the system.

An iteration may occasionally revisit existing software and improve it.

Page 51

Comp6471 Software Design Methodologies

Embracing Change

Stakeholders usually have changing requirements.

Each iteration involves choosing a small subset of the requirements and quickly design, implement and testing them.

This leads to rapid feedback, and an opportunity to modify or adapt understanding of the requirements or design.

Page 13: L01web 2x2

Page 52

Comp6471 Software Design Methodologies

Iteration Length and Timeboxing

The UP recommends short iteration lengths to allow for rapid feedback and adaptation.

Long iterations increase project risk. Iterations are fixed in length (timeboxed).If

meeting deadline seems to be difficult, then remove tasks or requirements from the iteration and include them in a future iteration.

The UP recommends that an iteration should be between two and six weeks in duration.

Page 53

Comp6471 Software Design Methodologies

Phases of the Unified ProcessInception Elaboration Construction Transition

A UP project organizes the work and iterations across four major phases:– Inception - Define the scope of project.– Elaboration - Plan project, specify features,

baseline architecture.– Construction - Build the product– Transition - Transition the product into end

user community

time

Page 54

Comp6471 Software Design Methodologies

Iterations and Milestones

Each phase and iteration has some risk mitigation focus, and concludes with a well-defined milestone.

The milestone review provides a point in time to assess how well key goals have been met and whether the project needs to be restructured in any way to proceed.

The end of each iteration is a minor release, a stable executable subset of the final product.

PreliminaryPreliminaryIterationIteration

Iter. #1Iter. #1 Iter. #2Iter. #2

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

Milestone Release Final productionrelease

Page 55

Comp6471 Software Design Methodologies

Management

Environment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Disciplines

Iterations

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

Supporting Disciplines

The UP Disciplines

Page 14: L01web 2x2

Page 56

Comp6471 Software Design Methodologies

Management

Environment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Disciplines

Iterations

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

Supporting Disciplines

In an iteration youwalk through alldisciplines.

The UP Disciplines

Page 57

Comp6471 Software Design Methodologies

Management

Environment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Disciplines

Iterations

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

Supporting Disciplines

Focus of thiscourse.The UP Disciplines

Page 58

Comp6471 Software Design Methodologies

Disciplines and Phases

Although an iteration includes work in most disciplines, the relative effort and emphasis change over time.– Early iterations tend to apply greater emphasis to

requirements and design, and later ones less so.– Figure illustrations are suggestive, not literal.

Note that activities and artifacts are optional (except code!)– Developers select those artifacts that address their particular

needs.

Page 59

Comp6471 Software Design Methodologies

Advantages of an Iterative Process

Reduce risks– Risks are identified early, progress is easier to see.

Get a robust architecture– Architecture can be assessed and improve early.

Handle evolving requirements– Users provide feedback to operational systems.– Responding to feedback is an incremental change.

Allow for changes– System can adapt to problems

Attain early learning– Everyone obtains an understanding of the different workflows

early on.

Page 15: L01web 2x2

Page 60

Comp6471 Software Design Methodologies

Unified ProcessSoftware Lifecycle

Cycle

Phase

Iteration

Artifact

Workflow

Management

Environment

Requirements

Design

Implementation

Assessment

Deployment

*

*

Inception

Elaboration

Construction

Transition

*

*

4

Product

releases

Page 61

Comp6471 Software Design Methodologies

Use Case Model

Analysis Model

Design Model

Deployment Model

Implementation Model

Test Model

specified by

real

ised

by

depl

oye

d b

y

implem

ented by verified by

All models are interdepedentbut this only shown for usecase model

UML class diagram!

Page 62

Comp6471 Software Design Methodologies

Inception

A number of questions need to be explored:– What is the vision and business case for this project?– Is it feasible?– Buy and/or build?– Rough estimate of cost.– Should we proceed or stop?

The intent is to establish some initial common vision for the objectives of the project, determine if it is feasible and decide if it is worth some serious investigation in elaboration.

Page 63

Comp6471 Software Design Methodologies

What artifacts may start in inception?

Vision and business case– Describes high-level goals and constraints.

Use Case model– Describes functional requirements and related non-functional

requirements. Supplementary specification

– Describes other requirements Glossary

– Key domain terminology Risk list and Risk Management Plan

– Describes business, technical, resource and schedule risks and ideas for their mitigation or response.

Page 16: L01web 2x2

Page 64

Comp6471 Software Design Methodologies

What artifacts may start in inception?

Prototypes and proof-of-concepts Iteration plan

– Describes what to do in the first elaboration iteration Phase Plan & Software development Plan

– Guess for elaboration phase duration. Tools, people, education and other resources.

Development Case– Description of the customized UP steps and artifacts for this

project. Artifacts will be partially completed in this phase and

will be refined in later iterations.

Page 65

Comp6471 Software Design Methodologies

Requirements Engineering:An Overview

Basic goal: To understand the problem as perceived by the user.

Activities of RE are problem oriented.– Focus on what, not how– Don’t cloud the RD with unnecessary detail– Don’t pre-constrain design.

After RE is done, do software design:– solution oriented– how to implement the what

Page 66

Comp6471 Software Design Methodologies

Requirements Engineering:An Overview

Key to RE is good communication between customer and developers.

Work from Requirements Document as guide.

Page 67

Comp6471 Software Design Methodologies

Requirements Engineering

The process of determining and establishing the precise expectations of the customer about the proposed software system.

Page 17: L01web 2x2

Page 68

Comp6471 Software Design Methodologies

The Two Kinds of Requirements

Functional: The precise tasks or functions the system is to perform.– e.g., details of a flight reservation system

Non-functional: Usually, a constraint of some kind on the system or its construction– e.g., expected performance and memory

requirements, process model used, implementation language and platform, compatibility with other tools, deadlines, ...

Page 69

Comp6471 Software Design Methodologies

The Purpose of RE

Raw user requirements are often:– vague– contradictory– impractical or impossible to implement– overly concrete– just plain wrong

The purpose of RE is to get a usable set of requirements from which the system may be designed and implemented, with minimal surprises.

Page 70

Comp6471 Software Design Methodologies

The RE ProcessRequirementsAnalysis

RequirementsDefinition

RequirementsSpecification

SoftwareSpecification

SystemModels

RequirementsDefinition

RequirementsSpecification

RequirementsDocument

SoftwareSpecification

included in

produces

leads to

Page 71

Comp6471 Software Design Methodologies

The Requirements Document

The official statement of what is required of the system developers.– Includes system models, requirements definition,

and requirements specification.– Not a design document. – States functional and non-functional requirements.

Serves as a reference document for maintenance.

Page 18: L01web 2x2

Page 72

Comp6471 Software Design Methodologies

Requirements Document “Requirements”

Should be easy to change as requirements evolve.

Must be kept up-to-date as system changes.

Page 73

Comp6471 Software Design Methodologies

The Requirements Document Should State ...

Foreseen problems: – “won’t support Win-3.x apps”

Expected evolution: – “will port to MacOS in next version”

Response to unexpected events/usage:– “if input data in old format, will auto-convert”

Page 74

Comp6471 Software Design Methodologies

Requirements Document Structure

Introduction (describe need for system) Functional Requirements Non-Functional Requirements System Evolution (describe anticipated changes) Glossary (technical and/or new jargon) Appendices Index

Page 75

Comp6471 Software Design Methodologies

A Story ...

Dear Mr. Architect,

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion.

My house should have between two and forty-five bedrooms. Just make sure the plans are such that bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also bring me the cost breakdown for each configuration so that I can arbitrarily pick one.

Page 19: L01web 2x2

Page 76

Comp6471 Software Design Methodologies

A Story … (Cont’d)

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don’t have nearly enough insulation in them).

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)

Page 77

Comp6471 Software Design Methodologies

A Story … (Cont’d)

Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.

To insure that you are building the correct house for our entire family, make certain that you contact each of our children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.

Page 78

Comp6471 Software Design Methodologies

A Story … (Cont’d)

Please don't bother me with small details right now. Your job is to develop the overall plans for the house: get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpet. However, keep in mind that my wife likes blue.

Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

Page 79

Comp6471 Software Design Methodologies

A Story … (Cont’d)

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features this house has.

I advise you to run up and look at my neighbor's house he constructed last year. We like it a great deal. It has many features that we would also like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.

Page 20: L01web 2x2

Page 80

Comp6471 Software Design Methodologies

A Story … (Cont’d)

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can't happen very often. Contact me as soon as possible with your complete ideas and plans.

Page 81

Comp6471 Software Design Methodologies

A Story … (Cont’d)

P.S. My wife has just told me that she disagrees with many on the instructions I’ve given you in this letter. As architect it is your responsibility to resolve these issues. I have tried in the past and have been unable to accomplish this. If you can’t handle this, I will have to find a new architect.

P.P.S. Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if that is the case.

(originally posted to the rec.humor.funny newsgroup in January 1993 -- but some things never change!)

Page 82

Comp6471 Software Design Methodologies

RE Summary

RE focuses on determining what the customer wants, and not how it will be implemented.

RE is hard to get correct; it requires good communication skills.

Requirements may change over time. RE requires iteration.

Page 83

Comp6471 Software Design Methodologies

RE Summary (Cont’d)

The customer often doesn’t have good grasp of what he wants.

Errors made at the requirements stage are very expensive to fix later.– You might well implement the stated requirements

correctly, but it won’t be the system the customer really wants.

Page 21: L01web 2x2

Page 84

Comp6471 Software Design Methodologies

Object-Oriented Analysis

An investigation of the problem (rather than how a solution is defined)

During OO analysis, there is an emphasis on finding and describing the objects (or concepts) in the problem domain.– For example, concepts in a Library Information

System include Book and Library.

Page 85

Comp6471 Software Design Methodologies

Back to Software Design ...

Page 86

Comp6471 Software Design Methodologies

Softwarearchitecture

Subsystemdecomposition

Subsystemdependencies

Subsysteminterfaces

module or classdecomposition

module or classdependencies

module or classinterfaces

Algorithms

Data structures

Low-Level(detailed)design

High-Level(abstract)

design

Page 87

Comp6471 Software Design Methodologies

Top-Down vs Bottom-Up Design

Top-down Design:– Start with a coarsely-grained view of system, and

repeatedly refine components until you have concrete sub-components.

Bottom-up Design:– Start with existing components and “glue” them

together to get what you want.

Page 22: L01web 2x2

Page 88

Comp6471 Software Design Methodologies

Top-Down vs Bottom-Up Design (Cont’d)

Top-down is the “ideal” of most design methods, but it’s rarely followed absolutely:– some branches of development are expanded

before others are even started– doesn’t adequately account for reuse of existing

components: COTS products, libraries, previous versions of the same

system.

Page 89

Comp6471 Software Design Methodologies

Design Quality

Software design “quality”, as with other ideas on quality, is an elusive concept: it depends on priorities of your company and the customers:

– fastest to implement– easiest to implement– easiest to maintain, “evolve”, port– most efficient/reliable/robust end-product.

Page 90

Comp6471 Software Design Methodologies

Discussion

What does “quality” mean to:– IBM?– Microsoft? – Mozilla? – FAA? – IRS?– Intel?– ...

Page 91

Comp6471 Software Design Methodologies

Object-Oriented Design

Emphasizes a conceptual solution that fulfils the requirements.

Need to define software objects and how they collaborate to fulfill the requirements.– For example, in the Library Information System, a

Book software object may have a title attribute and a getChapter method.

Designs are implemented in a programming language.– In the example, we will have a Book class in Java.

Page 23: L01web 2x2

Page 92

Comp6471 Software Design Methodologies

Software Design

Knowing an object-oriented language and having access to a library is necessary but not sufficient in order to create object software.

In between a nice idea and a working software, there is much more than programming.

Analysis and design provide software “blueprints”, illustrated by a modeling language, like the Unified Modeling Language (UML).

Blueprints serve as a tool for thought and as a form of communication with others.

Page 93

Comp6471 Software Design Methodologies

From Design to Implementation

Book

titleprint()

public class Book {public void print();private String title;

}

Book(concept)

Analysisinvestigation

of the problem

Designlogical solution

Constructioncode

Domain concept Representation inanalysis of concepts

Representation in anobject-orientedprogramming language.

Page 94

Comp6471 Software Design Methodologies

Software Design

How to implement the what. Requirements Document (RD) is starting point. Software design is a highly-creative activity. Good designers are worth their weight in gold!

– Highly sought after, head-hunted, well-paid.

Experience alone is not enough:– creativity, “vision”, all-around brilliance required.

Page 95

Comp6471 Software Design Methodologies

Software Design (Cont’d)

Some consider software design to be a “black art”:– difficult to prescribe how to do it– hard to measure a good design objectively – “I know a good design when I see it.”