L01web 2x2

Software Design Motivation
Methodologies
Comp 6471

Comp 6471
COMP 6471/4 NN

Steven Winikoff …with proper design, the features come
cheaply. This approach is arduous, but
smw@alcor.concordia.ca continues to succeed.
H-966-2 - Dennis Ritchie
514-848-2424, ext. 7619

Page 7

What This Course is About Software Engineering
ca. 1968: Reasons for the software crisis were determined.
Comp 6471

simple questions: Software development should be treated as an engineering
activity and not as an ad-hoc activity => software development
should be a systematical activity.
What should go into a given piece of
software? Definition provided by the IEEE:
Software Engineering is the systematic approach to
development , maintenance, organization of software
How do you put it there? systems.

Starting point of the software crisis.
...with complex answers
Acknowledgement: These slides are based on work originally created by
Dr. Juergen Rilling, CSE, Concordia

Comp6471 Software Design Methodologies

Page 9

Goals of Software Engineering Software Life Cycle
The phases of a software development cycle.
Improve the productivity of the programming/development process  Analysis: Software Engineering
Improve the comprehension of the developed software system  Specification
Improve the maintainability of the systems 70

Improve the quality of the software system (software product)
 Design 60
50
Improve the “quality” of the software system.  Implementation
40 Without SE
- Reliability

Effort
 Testing 30 Applying SE
- Efficiency (Speed, resource usage)
 Delivery/Maintenance 20
- User-friendly (user acceptance)
10
0
General goal:

n

n
gn

g
s

io

t io

in
si
Produce software which is useful for people

si
at

st
y

ta
De
al

Te
f ic

en
An

i
ec

em
Sp

pl
Im
Software Life Cycle Phase

Comp6471 Software Design Methodologies Comp6471 Software Design Methodologies

Page 10 Page 11

Software Life Cycle Goals of Software Engineering
Products: External deliverables, internal products; software products: final
code, test drivers
 Feasibility study – WHY? Cost benefit analysis (is Paper documents: external: user manual, installation guide;
it worth doing the project) Internal: requirements document, specification document,
 Requirements analysis + specification: WHAT? design document, test plan
What should the software do, produce a document.
 Design - How? How should the software do it.
Architectural design (overall structures + organization Processes: How the software is created, how its quality is evaluated and
of objects/modules, choice of data structures, etc. ensured
 Coding/Implementation: Realize ! components. Tools: CASE tools, editors, project management tools
Code modules, prodcuts: software,
 Testing: Realize ! Test individual modules, test People: Technical, social and managerial skills
whether modules work together, test system as a
whole, document test results. Principles Providing permanency, guidelines and maturity in the software
 Delivery and maintenance: Evolve! development process.


Page 13

Skills of a Software Engineer Skills of a Software Engineer

 Programming: Design
 data structures and algorithms – be familiar with several approaches
 programming languages – be flexible and open to different application domains
 tools: compilers, debuggers, editors
– be able to shift between several level of abstraction
 Communication: – application domain jargon
 spoken, written, presentations
 teamwork
– requirements and specification: declarative model
 with external people (customers) – architectural design, high-level operational model
– detailed coding


Page 14 Page 15

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

Project specific parameters will include:
Definition.  size (person-years),
A (software/system) lifecycle model is a  budget,
description of the sequence of activities carried  duration.
out in a software engineering project, and the
relative order of these activities.
project plan = lifecycle model + project parameters


Page 17

There are many different lifecycle models to choose By changing the lifecycle model, we can
from, e.g:
improve and/or trade off:
 waterfall,
 code-and-fix  development speed (time to market)
 spiral  product quality
 rapid prototyping
 unified process (UP)
 project visibility
 agile methods, extreme programming (XP)  administrative overhead
 COTS …  risk exposure
 customer relations, etc, etc.
but many are minor variations on a smaller number of
basic models.


Page 18 Page 19

Normally, a lifecycle model covers the entire Note that we can sometimes combine
lifetime of a product. lifecycle models
e.g. waterfall inside evolutionary – onboard
From the birth of an idea to the final shuttle software
deinstallation of the last release
We can also change lifecycle model between
i.e. The three main phases: releases as a product matures,
 design,
 build, e.g. rapid prototyping → waterfall
 maintain.


Page 21
phase
User Requirements output User Requirements Document

The Waterfall Model
Software Requirements Software Requirements
Document
• Classic lifecycle model – widely known,
understood and (commonly?) used. Architecture Design Architectural Design
Document
• In some respect, waterfall is the "common
”Swimming
sense" approach upstream”
Detailed design & Coding Detailed
Design
(Introduced by Royce 1970) & Code
The Waterfall Testing
Lifecycle Workflow
Delivery
Time

Page 22 Page 23

Advantages
Disadvantages I
1. Easy to understand and implement.
2. Widely used and known (in theory!)
● Idealized, doesn’t match reality well.
3. Reinforces good habits: define-before-design, ● Doesn’t reflect iterative nature of exploratory
design-before-code development.
4. Identifies deliverables and milestones ● Unrealistic to expect accurate requirements so early
5. Document driven, URD, SRD, … etc. Published in project
documentation standards, e.g. PSS-05.
● Software is delivered late in project, delays
6. Works well on mature products and weak teams.
discovery of serious errors.


Page 25

Disadvantages II Code-and-Fix
● Difficult to integrate risk management This model starts with an informal general
● Difficult and expensive to make changes to product idea and just develops code until a
documents, ”swimming upstream”. product is ”ready” (or money or time runs out).
● Significant administrative overhead, costly for
Work is in random order.
small teams and projects.
Corresponds with no plan!


Page 26 Page 27

Advantages Disadvantages
● No administrative overhead 1. Dangerous!
● Signs of progress (code) early. ● No visibility/control
● Low expertise, anyone can use it!
● No resource planning
● Useful for small “proof of concept” projects,
● No deadlines
● Mistakes hard to detect/correct
e.g. as part of risk reduction.
2. Impossible for large projects,
communication breakdown, chaos.


Page 29

This loop approach gives rise to structured
Spiral Model
iterative lifecycle models.
Since end-user requirements are hard to
obtain/define, it is natural to develop software In 1988 Boehm developed the spiral model as
in an experimental way: e.g. an iterative model which includes risk
analysis and risk management.
1. Build some software
2. See if it meets customer requirements Key idea: on each iteration identify and solve
3. If no goto 1 else stop. the sub-problems with the highest risk.


Page 30 Page 31
Cumulative cost
Determine objectives, Evaluate alternatives,
alternatives & constraints Identify & resolve risks
Each cycle follows a waterfall model by:
1. Determining objectives
2. Specifying constraints
Prototypes Operational
Review & Start P1 P2 P3 Prototype 3. Generating alternatives
commitment Requirements Concept
Design, 4. Identifying risks
plan Detailed design
Of Operation
Development
Validation 5. Resolving risks
& Verification
plan Requirements 6. Developing next-level product
validation Coding
Integration & 7. Planning next cycle
Test plan Unit & Integration
Testing
End Acceptance
Plan next phase Testing Develop & verify
next-level product

Page 33

1. Realism: the model accurately reflects the  Needs technical expertise in risk analysis to really
iterative nature of software development on work
projects with unclear requirements  Model is poorly understood by non-technical
2. Flexible: incorporates the advantages of the management, hence not so widely used
waterfall and rapid prototyping methods  Complicated model, needs competent professional
management. High administrative overhead.
3. Comprehensive model decreases risk
4. Good project visibility.


Page 34 Page 35

Requirements Capture
Rapid Prototyping
Iterate
Quick Design
Key idea: Customers are non-technical and
usually don’t know what they want/can have.
Build Prototype
Rapid prototyping emphasises requirements
Customer Evaluation of
analysis and validation, also called: Prototype
 customer oriented development,
 evolutionary prototyping
The Rapid Engineer Final
Prototype Workflow Product


Page 37

Advantages Disadvantages I
1. Reduces risk of incorrect user requirements 1. An unstable/badly implemented prototype
2. Good where requirements are often becomes the final product.
changing/uncommitted 2. Requires extensive customer collaboration
3. Regular visible progress aids management – Costs customers money
4. Supports early product marketing – Needs committed customers
– Difficult to finish if customer withdraws
– May be too customer specific, no broad market


Page 38 Page 39

Disadvantages II Agile (XP) Manifesto
3. Difficult to know how long project will last XP = Extreme Programming emphasizes:
4. Easy to fall back into code-and-fix without  Individuals and interactions
proper requirements analysis, design, – Over processes and tools
customer evaluation and feedback.  Working software
– Over documentation
 Customer collaboration
– Over contract negotiation
 Responding to change
– Over following a plan


Page 41

Agile Principles (Summary) XP Practices (Summary)
 Continuous delivery of software  Programming in pairs
 Continuous collaboration with customer  Test driven development
 Continuous update according to changes  Continuous planning, change , delivery
 Value participants and their interaction  Shared project metaphors, coding standards and
 Simplicity in code, satisfy the spec ownership of code
 No overtime! (Yeah right!)


Page 42 Page 43

 Lightweight methods suit small-medium size  Difficult to scale up to large projects where
projects documentation is essential
 Produces good team cohesion  Needs experience and skill if not to degenerate
 Emphasizes final product into code-and-fix
 Iterative  Programming pairs is costly
 Test-based approach to requirements and quality  Test case construction is a difficult and specialized
assurance skill.


Page 45

Advantages
COTS  Fast, cheap solution
 May give all the basic functionality
 COTS = Commercial Off-The-Shelf software  Well defined project, easy to run
 Engineer together a solution from existing
commercial software packages using minimal Disadvantages
software "glue".  Limited functionality
 E.g. using databases, spread sheets, word  Licensing problems, freeware, shareware, etc.
proccessors, graphics software, web browsers,
 License fees, maintainance fees, upgrade
etc.
compatibility problems


Page 47

Unified Process (UP)
 Booch, Jacobson, Rumbaugh 1999.
Comp 6471

Iterative Development and the  Lifetime of a software product in cycles:
Unified Process 
– Birth, childhood, adulthood, old-age, death.
Product maturity stages
 Each cycle has phases, culminating in a new
release (c.f. Spiral model)

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

Comp6471 Software Design Methodologies

Page 49

Iterative Development Iterative Development
[iteration N]
Requirements – Analysis - Design- Implementation - Testing
 The iterative lifecycle is based on the
successive enlargement and refinement of a
system though multiple iterations with
feedback and adaptation. [iteration N+1]
 The system grows incrementally over time, Requirements – Analysis - Design- Implementation - Testing

iteration by iteration.
 The system may not be eligible for production Feedback from iteration N leads to
refinement and adaptation of the The system grows
deployment until after many iterations. requirements and design in iteration incrementally.
N+1.


Page 50 Page 51

Iterative Development Embracing Change
 The output of an iteration is not an  Stakeholders usually have changing
experimental prototype but a production requirements.
subset of the final system.  Each iteration involves choosing a small
 Each iteration tackles new requirements and subset of the requirements and quickly
incrementally extends the system. design, implement and testing them.
 An iteration may occasionally revisit existing  This leads to rapid feedback, and an
software and improve it. opportunity to modify or adapt understanding
of the requirements or design.


Page 53

Iteration Length and Timeboxing Phases of the Unified Process
Inception Elaboration Construction Transition

time
 The UP recommends short iteration lengths
to allow for rapid feedback and adaptation. A UP project organizes the work and iterations
 Long iterations increase project risk. across four major phases:
 Iterations are fixed in length (timeboxed).If – Inception - Define the scope of project.
meeting deadline seems to be difficult, then – Elaboration - Plan project, specify features,
remove tasks or requirements from the baseline architecture.
iteration and include them in a future iteration.
 The UP recommends that an iteration should – Construction - Build the product
be between two and six weeks in duration. – Transition - Transition the product into end
user community


Page 54 Page 55

Iterations and Milestones The UP Disciplines
Phases
Process Disciplines Inception Elaboration Construction Transition
Inception Elaboration Construction Transition
Business Modeling
Requirements
Preliminary Iter. #1 Iter. #2
Iteration Analysis & Design
Implementation
Milestone Release Final production Test
release
Deployment

 Each phase and iteration has some risk mitigation focus, and Supporting Disciplines
concludes with a well-defined milestone. Configuration Mgmt
 The milestone review provides a point in time to assess how Management
well key goals have been met and whether the project needs to
be restructured in any way to proceed. Environment
 The end of each iteration is a minor release, a stable executable Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
subset of the final product.
Iterations


Page 57

The UP Disciplines In an iteration you
walk through all The UP Disciplines Focus of this
course.
Phases disciplines. Phases
Process Disciplines Inception Elaboration Construction Transition Process Disciplines Inception Elaboration Construction Transition

Business Modeling Business Modeling
Requirements Requirements
Analysis & Design Analysis & Design
Implementation Implementation
Test Test
Deployment Deployment
Supporting Disciplines Supporting Disciplines
Configuration Mgmt Configuration Mgmt
Management Management
Environment Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations Iterations


Page 58 Page 59

Advantages of an
Disciplines and Phases
Iterative Process
 Although an iteration includes work in most
 Reduce risks
disciplines, the relative effort and emphasis change – Risks are identified early, progress is easier to see.
over time.  Get a robust architecture
– Early iterations tend to apply greater emphasis to – Architecture can be assessed and improve early.
requirements and design, and later ones less so.  Handle evolving requirements
– Figure illustrations are suggestive, not literal. – Users provide feedback to operational systems.
– Responding to feedback is an incremental change.
 Note that activities and artifacts are optional (except  Allow for changes
code!) – System can adapt to problems
– Developers select those artifacts that address their particular
needs.
 Attain early learning
– Everyone obtains an understanding of the different workflows
early on.


Page 61

Unified Process
Product UML class diagram!
Management Software Lifecycle
Use Case Model

Environment * * releases specified by

by
ed
Workflow Cycle

deployed by
lis
a
Analysis Model

re
Requirements

im
Inception

ple
4

me
Design Design Model

n te
Phase Elaboration

db
Deployment Model verified by

y
Implementation
Construction
*
Implementation Model
Assessment Iteration
Transition All models are interdepedent
but this only shown for use Test Model
Deployment *
case model
Artifact

Page 62 Page 63

What artifacts may start in
Inception
inception?
 A number of questions need to be explored:  Vision and business case
– What is the vision and business case for this project? – Describes high-level goals and constraints.
– Is it feasible?  Use Case model
– Buy and/or build? – Describes functional requirements and related non-functional
– Rough estimate of cost. requirements.
– Should we proceed or stop?
 Supplementary specification
– Describes other requirements
 Glossary
 The intent is to establish some initial common vision – Key domain terminology
for the objectives of the project, determine if it is
feasible and decide if it is worth some serious
 Risk list and Risk Management Plan
– Describes business, technical, resource and schedule risks
investigation in elaboration. and ideas for their mitigation or response.


Page 65

What artifacts may start in Requirements Engineering:
inception? An Overview
 Prototypes and proof-of-concepts  Basic goal: To understand the problem as
 Iteration plan perceived by the user.
– Describes what to do in the first elaboration iteration
 Phase Plan & Software development Plan
 Activities of RE are problem oriented.
– Guess for elaboration phase duration. Tools, people, – Focus on what, not how
education and other resources. – Don’t cloud the RD with unnecessary detail
 Development Case – Don’t pre-constrain design.
– Description of the customized UP steps and artifacts for this
project.  After RE is done, do software design:
 Artifacts will be partially completed in this phase and – solution oriented
will be refined in later iterations.
– how to implement the what


Page 66 Page 67

Requirements Engineering: Requirements Engineering
An Overview

The process of determining and establishing
 Key to RE is good communication between the precise expectations of the customer
customer and developers. about the proposed software system.

 Work from Requirements Document as guide.


Page 69

The Two Kinds of Requirements The Purpose of RE
 Raw user requirements are often:
 Functional: The precise tasks or functions – vague
the system is to perform. – contradictory
– e.g., details of a flight reservation system – impractical or impossible to implement
– overly concrete
 Non-functional: Usually, a constraint of – just plain wrong
some kind on the system or its construction  The purpose of RE is to get a usable set of
– e.g., expected performance and memory requirements from which the system may be
requirements, process model used, designed and implemented, with minimal
implementation language and platform, surprises.
compatibility with other tools, deadlines, ...


Page 70 Page 71

Requirements
Analysis
leads to The RE Process
The Requirements Document
Requirements
produces
Definition
 The official statement of what is required of
System Requirements the system developers.
Models Specification
– Includes system models, requirements definition,
and requirements specification.
Requirements – Not a design document.
Software
Definition
Specification – States functional and non-functional requirements.
included in
Requirements
Specification  Serves as a reference document for
maintenance.
Requirements
Software
Document
Specification

Page 73

Requirements Document The Requirements Document
“Requirements” Should State ...
 Foreseen problems:
– “won’t support Win-3.x apps”

 Should be easy to change as requirements  Expected evolution:
evolve. – “will port to MacOS in next version”

 Must be kept up-to-date as system changes.  Response to unexpected events/usage:
– “if input data in old format, will auto-convert”


Page 74 Page 75

Requirements Document A Story ...
Structure
Dear Mr. Architect,
 Introduction (describe need for system)
 Functional Requirements Please design and build me a house. I am not quite sure of what
I need, so you should use your discretion.
 Non-Functional Requirements
 System Evolution (describe anticipated changes) My house should have between two and forty-five bedrooms.
Just make sure the plans are such that bedrooms can be easily
 Glossary (technical and/or new jargon) added or deleted. When you bring the blueprints to me, I will
 Appendices make the final decision of what I want. Also bring me the cost
breakdown for each configuration so that I can arbitrarily pick
 Index one.


Page 77

A Story … (Cont’d) A Story … (Cont’d)
Please take care that modern design practices and the latest
Keep in mind that the house I ultimately choose must cost materials are used in construction of the house, as I want it to be a
less than the one I am currently living in. Make sure, showplace for the most up-to-date ideas and methods. Be alerted,
however, that you correct all the deficiencies that exist in my however, that kitchen should be designed to accommodate, among
current house (the floor of my kitchen vibrates when I walk other things, my 1952 Gibson refrigerator.
across it, and the walls don’t have nearly enough insulation in
them). To insure that you are building the correct house for our entire
family, make certain that you contact each of our children, and
As you design, also keep in mind that I want to keep yearly also our in-laws. My mother-in-law will have very strong feelings
maintenance costs as low as possible. This should mean the about how the house should be designed, since she visits us at
incorporation of extra-cost features like aluminum, vinyl, or least once a year. Make sure that you weigh all of these options
carefully and come to the right decision. I, however, retain the
composite siding. (If you choose not to specify aluminum, be right to overrule any choices that you make.
prepared to explain your decision in detail.)


Page 78 Page 79

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
Please don't bother me with small details right now. Your job is to should have appeal to a wide variety of potential buyers. Please
develop the overall plans for the house: get the big picture. At this make sure before you finalize the plans that there is a consensus of
time, for example, it is not appropriate to be choosing the color of the population in my area that they like the features this house has.
the carpet. However, keep in mind that my wife likes blue.
I advise you to run up and look at my neighbor's house he
Also, do not worry at this time about acquiring the resources to constructed last year. We like it a great deal. It has many features
build the house itself. Your first priority is to develop detailed that we would also like in our new home, particularly the 75-foot
plans and specifications. Once I approve these plans, however, I swimming pool. With careful engineering, I believe that you can
would expect the house to be under roof within 48 hours. design this into our new house without impacting the final cost.


Page 81

Please prepare a complete set of blueprints. It is not necessary at P.S. My wife has just told me that she disagrees with many on the
this time to do the real design, since they will be used only for instructions I’ve given you in this letter. As architect it is
construction bids. Be advised, however, that you will be held your responsibility to resolve these issues. I have tried in the
accountable for any increase of construction costs as a result of past and have been unable to accomplish this. If you can’t handle
later design changes. this, I will have to find a new architect.

You must be thrilled to be working on as an interesting project as P.P.S. Perhaps what I need is not a house at all, but a travel trailer.
this! To be able to use the latest techniques and materials and to be Please advise me as soon as possible if that is the case.
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. (originally posted to the rec.humor.funny newsgroup
in January 1993 -- but some things never change!)


Page 82 Page 83

RE Summary RE Summary (Cont’d)
 RE focuses on determining what the  The customer often doesn’t have good grasp
customer wants, and not how it will be of what he wants.
implemented.  Errors made at the requirements stage are
 RE is hard to get correct; it requires good very expensive to fix later.
communication skills. – You might well implement the stated requirements
 Requirements may change over time. correctly, but it won’t be the system the customer
really wants.
 RE requires iteration.


Page 85

Object-Oriented Analysis Back to Software Design ...

 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 86 Page 87
Software
architecture

Subsystem
decomposition
High-Level Top-Down vs Bottom-Up Design
(abstract)
Subsystem
dependencies design  Top-down Design:
Subsystem – Start with a coarsely-grained view of system, and
interfaces
repeatedly refine components until you have
module or class concrete sub-components.
decomposition

module or class
dependencies
 Bottom-up Design:
– Start with existing components and “glue” them
module or class
interfaces
Low-Level together to get what you want.
(detailed)
Data structures
design

Algorithms

Page 89

Top-Down vs Bottom-Up Design
(Cont’d) Design Quality
Software design “quality”, as with other ideas
 Top-down is the “ideal” of most design on quality, is an elusive concept: it depends
methods, but it’s rarely followed absolutely: on priorities of your company and the
– some branches of development are expanded customers:
before others are even started – fastest to implement
– doesn’t adequately account for reuse of existing – easiest to implement
components: – easiest to maintain, “evolve”, port
 COTS products, libraries, previous versions of the same
system. – most efficient/reliable/robust end-product.


Page 90 Page 91

Discussion Object-Oriented Design
What does “quality” mean to:  Emphasizes a conceptual solution that fulfils
– IBM? the requirements.
– Microsoft?  Need to define software objects and how they
– Mozilla? collaborate to fulfill the requirements.
– FAA? – For example, in the Library Information System, a
Book software object may have a title attribute and
– IRS? a getChapter method.
– Intel?  Designs are implemented in a programming
– ... language.
– In the example, we will have a Book class in Java.


Page 93

From Design to Implementation
Software Design
Analysis
Design Construction
 Knowing an object-oriented language and having investigation
logical solution code
access to a library is necessary but not sufficient in of the problem
order to create object software.
 In between a nice idea and a working software, there
is much more than programming. Book public class Book {
 Analysis and design provide software “blueprints”, Book public void print();
illustrated by a modeling language, like the Unified (concept) title private String title;
Modeling Language (UML). print() }
 Blueprints serve as a tool for thought and as a form of Representation in an
Domain concept Representation in
communication with others. object-oriented
analysis of concepts
programming language.


Page 94 Page 95

Software Design Software Design (Cont’d)

 How to implement the what.  Some consider software design to be a “black
 Requirements Document (RD) is starting point. art”:
 Software design is a highly-creative activity. – difficult to prescribe how to do it
 Good designers are worth their weight in gold! – hard to measure a good design objectively
– Highly sought after, head-hunted, well-paid. – “I know a good design when I see it.”
 Experience alone is not enough:
– creativity, “vision”, all-around brilliance required.


L01web 2x2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to L01web 2x2

Similar to L01web 2x2 (20)

L01web 2x2