SOEN 6461-1-Intro - W2014

1
SOEN 6461
Software Design Methodologies:
Introduction
2

Course Orientation
Course Logistics
Prof: Dr. Nora Houari
Office: EV3.301
Email: houari@encs.concordia.ca
Office hours: Tuesdays 17:00-18:00, and by
appointment
Theory, here with me (H411) Mondays: 17:45-
20:15
Programmer-On-duty hours:TBA, room TBA

What this course about?
A (deep) look at OO design
Software architecture: where global
decision are made
Design process: domain model, use cases
design
Emphasis: model, architectural patterns,
GRASP principles, design patterns,
responsibility, collaboration

4
Give you in depth appreciation of S/W design
Elevate you skills beyond coding
Make sure you will not be offshored
Demand for software designers/architects is
high and of course for big paycheck

Understand the value of good design and apply it in
the software systems you build

Why take this course?
What the course is not?
Not a course in UML, Java
You should know the basics of these
And become expert (as needed) yourself
Not a course in tools: Eclipse, Visual studio
You can work through tutorials yourself
Not a course in UI, DB design, Games
Not a course in software engineering,
software management, software testing,
software reuse,

6
Most of our courses are taught using the Java
programming language for many reasons!
SOEN 6461 course: examples and exams code
using java
This course aims at teaching software design
methodologies to an audience well-trained in
computer programming and putting the newly
acquired knowledge into practice through a
challenging project
Project: you are free to use any OO language-
as long as your team member are comfortable
with that!

Rationale
Topic Coverage

Software Design Methodologies Overview
Domain Modeling
Design Objects with Responsibilities
Software Architecture: Views and Styles
Design Patterns
Software Architecture Analysis and Documentation
Anti-patterns
Refactoring
GoF Patterns
Service Oriented Architecture

Recommended References
Craig Larman, Applying UML and
Patterns: An Introduction to Object-
Oriented Analysis and Design and
Iterative Development, 3rd., Prentice
Hall

And many other resources listed each
week and made available via Moodle

Advice
Keep up as material is cumulative
study the practice examples in the
lectures and the PODs practice
examples/exercises and play with them
Study in groups
Evaluation
Four components of evaluation:

3 Assignments and 3 Quizzes 15%
Midterm exam 20%
Project (team of 5 members) 25%
Final exam 40%

Some thoughts
This course requires a fair amount of time
commitments!
Lectures: weekly/papers reading/
assignments/3 Quizzes/Midterm/Final
Do not take it if you cannot spare the time
Software design is part science and part art
You need to be steeped in to appreciate it
Some things you can only learn from
experience ( team project)
Intellectually rich and rewarding experience
Project individual teams having 5 members
Must work in groups in the real world
The completion of the project is divided into two separate builds
teams presentation in class for each build
Communicate with colleagues (team members)
Communication problems are natural!
What have you done?
You must document your work!
Everyone must keep an on-line notebook/Forum
Communicate with me
How is the teams plan/progress is going?
Short progress reports/meetings are required:
What is each members responsibility?
Peer evaluation
Project
To do from now on.
Sign up for this class on Moodle
Monitor the Moodle for course content and
announcement
Start thinking about project teams (5
members) right away..
You need to pick up your team by Jan 19
th
at
the latest
Structure how to work/communicate and have
fun!
Decide if you are willing and able to handle
the workload.

15
Things You Already Know(aka cheating)

It is an academic offence to give someone
your work
It is an academic offence to claim someone
else's work as your own
When it happens in industry, people are
fired, sued, or sent to jail!
Thank you
and welcome aboard
17
Software Design Methodologies:
Overview
Text book: chap. 1 and 2

18
Today
Important questions
1. What are software engineering difficulties?
2. What is an agile process?
3. What are the different existing agile
processes?Pitfalls/Challenges?
4. What do we do in Software Design
Methodologies?
The Unified Process (UP)
Iterative Development
Comments on Iterative Development and the UP

19
The Origins
Software Engineers have always employed software
architectures
Very often without realizing it!
Address issues identified by researchers and
practitioners
Essential software engineering difficulties
Unique characteristics of programming-in-the-large
Need for software reuse
Many ideas originated in other (non-computing)
domains
20
Today
Important questions
processes? Their Pitfalls/Challenges?
Methodologies?

21
Software Engineering
Difficulties
Software engineers deal with unique set of problems
(Relatively)Young field with tremendous
expectations
Building of vastly complex, but intangible systems
Software is not useful on its own e.g., unlike a car,
thus
It must conform to changes in other engineering
areas
Some problems can be eliminated
These are Brooks accidental difficulties
Other problems can be lessened, but not eliminated
These are Brooks essential difficulties
No Silver Bullet; Essence and Accidents of Software Engineering, Fred Brooks , 1986
22
Accidental Difficulties
Solutions exist
Possibly waiting to be discovered
Past productivity increases result of
overcoming
Inadequate programming constructs &
abstractions
Remedied by high-level programming languages
Increased productivity by factor of five
Complexity was never inherent in program at all
23
Accidental Difficulties (contd)
Past productivity increases result of
overcoming (contd)
Difficulty of using heterogeneous programs
Addressed by integrated software development
environments
Support task that was conceptually always possible
24
Essential Difficulties
Only partial solutions exist for them, if
any
Cannot be abstracted away

Complexity
Conformity
Changeability
Intangibility
25
Complexity
No two software parts are alike
If they are, they are abstracted away into one
Complexity grows non-linearly with size
E.g., it is impossible to enumerate all states of
program
Except perhaps toy programs
26
Conformity
Software is required to conform to its
Operating environment
Hardware
Often last kid on block
Perceived as most conformable
27
Changeability
Change originates with
New applications, users, machines, standards,
laws
Hardware problems
Software is viewed as infinitely malleable
28
Intangibility
Software is not embedded in space
Often no constraining physical laws
No obvious representation
E.g., familiar geometric shapes
29
Primacy of Design
Software engineers collect requirements,
code, test, integrate, configure, etc.
An architecture-centric approach to
software engineering places an emphasis on
design
Design pervades the engineering activity from
the very beginning
But how do we go about the task of
architectural design?
30
Today
Important questions
processes?Pitfalls/Challenges?
Methodologies?

Agile Processes
Development processes that address the problem of
volatile requirements:
requirements that change due to rapidly changing technology
or market,
requirements that are difficult to define in advance because
of the exploratory nature of the development.
They cope with change in the following ways:
1. they employ short iteration cycles, which permit incremental
delivery and rapid feedback for project management
purposes
2. they generally have low documentation overheads
3. they encourage an inclusive relationship with the customer,
often with flexible contract arrangements
Exemplar Agile Processes
Extreme Programming (XP)
based on Test-Driven Development (TDD).
Feature-Driven Development (FDD)
integrates ideas from plan-driven processes, too.
SCRUM
Crystal family
Agile Modelling
Dynamic Systems Development Method (DSDM)
33
Agile Project Management Features(1/5)
Agile Development :The manifesto for agile software
development has revolutionized the way companies
plan, develop, test and release software. Throwing
away years of accumulated orthodoxy, agile
development methods have now become the accepted
way to develop software.
Scrum :One of the most popular agile methodologies
in use today. Scrum is a lightweight software
development methodology that focuses on having
small time-boxed sprints of new functionality that
are incorporated into an integrated product baseline.
Scrum places an emphasis on customer interaction,
feedback and adjustments rather than documentation
and prediction.
34
Extreme Programming (XP) is a set of software
development principles that were designed to reduce
waste and better cope with changing requirements
during the software development lifecycle. XP
focuses primarily on engineering techniques and
approaches rather than project management.
Spiral / Iterative The spiral/iterative model of
development was one of the first approaches to
challenge the orthodoxy of waterfall software
development. It is based around having an initial
prototype that is subsequently refined in each new
spiral of functionality that is added to the initial
prototype
35
Agile Unified Process (AUP) The Agile Unified
Process (AUP) grew up out of the Rational Unified
Process (RUP). Both RUP and AUP specify that the
various activities of the software development
lifecycle occur in parallel during the lifecycle rather
than solely in specific phases.
Dynamic Systems Development Method The Dynamic
Systems Development Method (DSDM) is a well-
defined agile methodology managed by the DSDM
Consortium that provides a project delivery
framework that aids the development and delivery of
business solutions to tight timescales and fixed
budgets.
36
Kanban / Lean: Lean development practices are
based on the lean methodologies that have been used
successfully in manufacturing processes. Kanban is a
lean software development methodology that focuses
on just-in-time delivery of functionality and managing
the amount of work in progress (WIP)
Rapid Application Development (RAD) approaches
allowing developers to rapidly create functioning
prototypes during the requirements gathering
process to validate assumptions and provide initial
feedback.
37
Test-Driven Development (TDD) :a practice
espoused by XP whereby the unit and acceptance
tests become an upfront part of the requirements
definition and validation process. The tests are
written prior to development and the design is the
minimum necessary for the test to pass.
Feature-Driven Development (FDD) :Feature-Driven
Development (FDD) is an agile methodology that
blends a number of industry-recognized best
practices into a cohesive whole. The unifying theme
of the methodology is that all activities are organized
around client-valued functionality (features).
Classification of Agile Processes
Agile processes possess the following main
characteristics:
incremental, focusing on delivering small
releases;
cooperative, where the customer is embedded
in the team;
straightforward, where the processes are easy
to learn and sufficiently (and accurately)
documented;
adaptive, welcoming changes, even late in the
lifecycle.
39
Today
Important questions
Methodologies?

Problems and Pitfalls/Challenges
Wide skepticism at the moment:
XP claimed to be suitable for projects in the low criticality
band, but this view is not widely shared.
The lack of process fits badly with current
standards.
Though there are views that CMMI etc are to a point
compatible with XP practices.
Criticisms about effectiveness of project
management in agile processes.
Hard to extract data; data is of less value as it is much more
difficult to extrapolate.
Unsuitable for long-lived projects.
No documentation, reuse is difficult.
Problems and Pitfalls
Customer participation
Theres no single, clear role for customers in some systems;
no one customer can know everything (aerodynamics,
materials, structure, propulsion ...)
Also, independence may be an issue for safety
Without a customer, management of the agile process will be
hard.
Scaling issues
We need new means of enabling communication (or need to
adapt the means we use already).
How do we manage 300 people? Sub-teams of domain
experts?
Testing
White box testing is often ignored.
Also acceptance testing for some safety critical systems is
usually expensive, and in some cases one-off.
Problems and Pitfalls
Simple design may be incompatible with
the naturally long life of many systems.
Incremental development:
Agile proposes deprecating low priority
requirements; critical systems normally have
large numbers of inflexible requirements of
high priority.
Can a safe but incomplete design be
incrementally certified?
43
Today
Important questions
Methodologies?

44

What do we do in Software Design Methodologies?
Think in Objects

Analyze requirements with
use cases

Create domain models

Apply an iterative & agile
Unified Process (UP)

Relate analysis and design
artifacts

Read & write high-frequency
UML
Practice
Apply agile modeling

Design object solutions
Assign responsibilities to
objects

Design collaborations

Design with patterns

Design with architectural
layers

Understand OOP (e.g.,
Java) mapping issues

45

UML: Whats Important?

Harmful is knowing
how to read and
draw UML diagrams,
but not being an
expert in design and
patterns.
Important is object and
architectural design skills, not
UML diagrams, drawing, or
CASE tools.

46

UML: Whats Important?

47

UML vs. Thinking in Objects
Unified Modeling Language (UML)

Just a diagramming notation standard.

Trivial and relatively unimportant.

Not a method, process, or design guide.
InterfaceX
Abstract
ClassX
...
interface
InterfaceX
operation1()
ClassA ClassB
Association-name
role-1 role-2
1 1
zero or
more;
"many"
one or
more
one to
forty
exactly
five
Class Class Class Class *
1..* 1..40 5
Whole
Part
1
*
AssociationClass
Composition
Multiplicity:
Associations:
ClassX
classAttribute
+ publicAttribute
- privateAttribute
attributeWithVisibilityUnspecified
attribute1 : type
burgers : List of VeggieBurger
attribute2 : type = initial value
finalConstantAttribute : int = 5 { frozen }
/derivedAttribute
classMethod()
+ constructor ClassX(int)
signal CaughtException1()
methodWithVisibilityUnspecified()
methodReturnsSomething() : Foo
abstractMethod()
abstractMethod2() { abstract } // alternate
+ publicMethod()
- privateMethod()
# protectedMethod()
~ packageVisibleMethod()
finalMethod() { leaf }
methodWithoutSideEffects() { query }
synchronizedMethod() { guarded }
exceptions
ThrownException1
AlternateUMLFor
AbstractClass
{abstract}
...
ClassY
operation1()
...
generalization
interface
implementation
AlternateUMLFor
ImplOfInterfaceX
operation1()
FinalClass
{leaf}
...
48
The Need for Software Blueprints
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.

OOD: Principles and Patterns
Priority

1. Assign responsibilities to objects

The GRASP patterns are the key learning aid

After that. . . ?
50
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.

51
Object-Oriented Design
Emphasizes a conceptual solution that
fulfils the requirements.
Need to define software objects and how
they collaborate to fulfil 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.

52
From Design to Implementation
Book
title
print()
public class Book {
public void print();
private String title;
}
Book
(concept)
Analysis
investigation
of the problem
Design
logical solution
Construction
code
Domain concept Representation in
analysis of concepts
Representation in an
object-oriented
programming language.
53
Today
Important questions
Methodologies?

54
A process is a set of partially ordered steps
intended to reach a goal.
In Software Engineering, the goal is to
efficiently and predictably deliver a software
product that meets the needs of your business.
A software development process is an approach
to building, deploying and maintaining software.
The Unified Process (UP) is a process for
building object-oriented systems.
The goal of the UP is to enable the production
of high quality software that meets users needs
within predictable schedules and budgets.
55
For simple systems, it might be feasible to
sequentially define the whole problem,
design the entire solution, build the
software, and then test the product.
For complex and sophisticated systems,
this linear approach is not realistic.
The UP promotes iterative
development:The life of a system
stretches over a series of cycles, each
resulting in a product release.
56
Old days: Waterfall Model
57
Today
Important questions
Methodologies?

58
Development is organized into a series of
short fixed-length mini-projects called
iterations.
The outcome of each iteration is a tested,
integrated and executable system.
An iteration represents a complete
development cycle: it includes its own
treatment of requirements, analysis, design,
implementation and testing activities.

59
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.
60
Iterative Development (1/2)
[iteration N]
Requirements Analysis - Design- Implementation - Testing
[iteration N+1]
Requirements Analysis - Design- Implementation - Testing
Feedback from iteration N leads to
refinement and adaptation of the
requirements and design in iteration
N+1.
The system grows
incrementally.
Iterative Development (2/2)
Requirements
Design
Implementation &
Test & Integration
& More Design
Final Integration
& System Test
Requirements
Design
3 weeks (for example)
The system grows
incrementally.
Feedback from
iteration N leads to
refinement and
adaptation of the
requirements and
design in iteration
N+1.
Iterations are fixed in
length, or timeboxed.
Time
Implementation &
Test & Integration
& More Design
Final Integration
& System Test
62
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.

63
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.
64
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.
65
Phases of the Unified Process
Inception 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
66
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.
Preliminary
Iteration
Iter. #1 Iter. #2
Inception Elaboration Construction Transition
Milestone Release
Final production
release
67
The UP Disciplines
Management
Environment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary
Iteration(s)
Iter.
#1
Phases
Process Disciplines
Iterations
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Deployment
Configuration Mgmt
Requirements
Elaboration Transition Inception Construction
Supporting Disciplines
68
The UP Disciplines
Management
Environment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary
Iteration(s)
Iter.
#1
Phases
Process Disciplines
Iterations
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Deployment
Configuration Mgmt
Requirements
In an iteration you
walk through all
disciplines.
69
The UP Disciplines
Management
Environment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary
Iteration(s)
Iter.
#1
Phases
Process Disciplines
Iterations
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Deployment
Configuration Mgmt
Requirements
Focus of this
course.
70
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.

71
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.
Scenario(1/3)
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
20%
2%
r
e
q
u
i
r
e
m
e
n
t
s
s
o
f
t
w
a
r
e
30%
5%
r
e
q
u
i
r
e
m
e
n
t
s
s
o
f
t
w
a
r
e
50%
8%
90% 90%
20%
10%
requirements workshops
Imagine this will
ultimately be a 20-
iteration project.
In evolutionary iterative
development, the
requirements evolve
over a set of the early
iterations, through a
series of requirements
workshops (for
example). Perhaps
after four iterations and
workshops, 90% of the
requirements are
defined and refined.
Nevertheless, only
10% of the software is
built.
1 2 3 4 5 ... 20
week 1
M T W Th F
week 2
M T W Th F
week 3
M T W Th F
kickoff meeting
clarifying iteration
goals with the team.
1 hour
team agile
modeling &
design,
UML
whiteboard
sketching.
5 hours
start
coding &
testing
a 3-week iteration
de-scope
iteration
goals if
too much
work
final check-in
and code-
freeze for the
iteration
baseline
demo and
2-day
requirements
workshop
next
iteration
planning
meeting;
2 hours
Most OOA/D and
applying UML during
this period
Use-case modeling
during the workshop
Scenario(2/3)
inc. elaboration construction transition
iteration
phase
development cycle
release
A stable executable
subset of the final
product. The end of
each iteration is a
minor release.
increment
The difference
(delta) between the
releases of 2
subsequent
iterations.
final production
release
At this point, the
system is released
for production use.
milestone
An iteration end-
point when some
significant decision
or evaluation occurs.
Sample
UP Disciplines
Business
Modeling
Requirements
Design
Implementation
...
The relative effort in
disciplines shifts
across the phases.
This example is
suggestive, not literal.
incep-
tion
elaboration construction
transi-
tion
...
Scenario(3/3)
The NextGent POS System (1/2)
A POS system computerized application used to record
sales and handle payments typically used in retail stores.
POS includes:
Hardware components(computer and bar code scanner
Software
POS interfaces to various service application (e.i. Tax
calculator and inventory control)
POS system supports multiple client-side terminals and
interfaces
POS a commercial system for different clients with
disparate needs in terms of business rule processing:
flexibility and customization

76
Case Study Focus
Many systems can be divided into 3 layers
User interface
Business logic (application)
Integration (DB & other systems)

Focus is on business layer because
Its design is less technology dependent
OOAD skills can be applied to other layers
More likely to have stable design
The NextGen POS System (2/2)
User Interface
Sale Payment
Logging ... Database Access ...
application
logic layer
other layers or
components
minor focus
explore how to connect to
other layers
primary focus
of case studies
explore how to
design objects
secondary
focus
Iteration 1
Iteration 2
Iteration 3
Introduces just those
analysis and design
skills related to
iteration one.
Additional analysis and
design skills introduced.
Likewise.
SOEN6461: Learning path through iterations
Inception
(req. Analysis)
OOA/D and
responsibilities'
assignment to
objects
Object design,
Design Patterns
Architectural
analysis,
framework
design
79
Today
Important questions
Methodologies?

80
Comments on Iterative
Development and the UP
81
Additional UP Best Practices and
Concepts
The central idea behind the UP is short
timeboxed iterative, adaptive development.
Tackle high-risk and high-value issues in
early iterations.
Leave easier work in later iterations.
This way the project does not fail late
Better to fail early if at all.
82
Concepts
Continuously engage users.
Development involves taking small steps and
getting feedback.
The majority of failed projects are correlated
with lack of user engagement [Standish, 1994]
Early iterations focus on core
architecture.
Continuously verify quality.
No big surprises near the end of the project.
83
Concepts
Apply Use Cases.
Use Cases explore and record functional requirements.
Capture requirements, used for design, testing and
writing end-user documentation.
UML supports abstract (and visual) models of
software.
Carefully manage requirements.
Poor requirements management is a common factor on
troubled projects [Standish, 1994]
Control changes.
UP embraces change, not chaos.
84
The Construction and Transition
Phases
During Elaboration most requirements
are understood.
Elaboration builds the risky and architecturally
significant core of the system.
Construction builds the remainder.
Development proceeds through a series of
timeboxed iterations.
Testing during Construction is referred to as
alpha testing.
85
The Construction and Transition
Phases
Construction ends when the system is
ready for operational deployment and all
supporting materials are complete (user
guides, training material etc.)
The purpose of Transition phase is to put
the system into production use.
Testing during Transition is referred to as
beta testing
86
Motivations for Timeboxing an
Iteration
Development team has to focus to produce
a tested executable partial system on-
time.
Timeboxing forces developers to prioritize
work and risks, as well as identify tasks of
high business and high technical value.
Complete mini projects build team
confidence and stakeholder confidence.
87
The Sequential Waterfall
Lifecycle
Clarify, record and commit to a set of final
requirements.
Design a system based on these
requirements.
Implement based on design.
Integrate different modules.
Evaluate and test for correctness and
quality.
88
Some Problems with the Waterfall
Lifecycle
Tackling high-risk or difficult problems late.
In a waterfall lifecycle there is no attempt to identify
and tackle riskiest issues first.
In an iterative development (like the UP) early
iterations focus on driving down the risk.
Requirements speculation and inflexibility.
The waterfall process assumes that requirements can
be fully specified and then frozen in the first phase of
the project.
Stakeholders want to see something concrete very early.
Market changes.
In iterative development requirements tend to stabilize
after several iterations.
89
Some Problems with the Waterfall
Lifecycle
Design speculation and inflexibility.
The waterfall lifecycle dictates that the
architecture should be fully specified once
the requirements are clarified and before
implementation begins.
Since requirements usually change, the original
design will not be reliable.
Lack of feedback on design until long after
design decisions are made.
90
Succeeding with Agile
Agile Succeeds Three Times More Often
Than Waterfall
91
Today
Important questions
Methodologies?

SOEN 6461-1-Intro - W2014

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SOEN 6461-1-Intro - W2014

Hochgeladen von

Copyright:

Verfügbare Formate

1

Das könnte Ihnen auch gefallen