Software Engineering course

Software Engineering

Introduction

course objectives

• to understand the difference between traditional and agile
approaches to system development
• to understand the primary software engineering tools and
techniques and how and when to apply them
• to develop the capacity to use these understandings in
your own practice

• overview course – not learn this technique and learn how
to apply it in the exercises

SOE: introduction 2

course design

traditional

development tools,
approaches techniques, SPI
practices

agile (Ivan Aaen)
miniproject 1: miniproject 2: miniproject 3:
DA TTP evaluation

SOE: Introduction 3

the problem
• development project success rates in the US: 29%
• serious problems: 53%
• complete failure: 18%
• by budget
• <$750,000: success = 55%
• >$10,000,000 success = 0%
• England (public sector) 84% partial or total failure
• estimated overall: 20-30% projects are total failures
(abandoned)
• ”failure of large and complex information system
developments is largely unavoidable”

Source: Dangerous Enthusiams: Gauld and Goldfinch
SOE: introduction 4

the problem elaborated

• the requirements problem: the software does not match the needs of users
• the analysis problem: the software contains a model of the external world which
cannot be recognized or adapted to by its users
• the design problem: the software design inadequately solves the problem, creating
issues such as maintainability, adaptivity, portability, security
• the quality problem: the system is delivered with bugs, service and usability
problems that make it difficult to use
• the project management problem: the project becomes delayed and/or over
budget; in extreme cases so much so that it is aborted
• the change problem: changes in problem or solution, or the project’s environment
(such as an economic crisis, or market change) which affect the project
• the complexity problem: the interaction of any combination of the above

SOE: introduction 5

one answer:
• the application of engineering principles to software
development
• “the discipline, art and profession of acquiring and applying technical, scientific and
mathematical knowledge to design and implement materials, structures, machines,
devices, systems, and processes that safely realize a desired objective or
inventions” Wikipedia
• “the creative application of scientific principles to design or develop structures,
machines, apparatus, or manufacturing processes, or works utilizing them singly or
in combination; or to construct or operate the same with full cognizance of their
design; or to forecast their behavior under specific operating conditions; all as
respects an intended function, economics of operation and safety to life and
property” American Engineers Council
• “the application of scientific and mathematical principles to practical ends such as
the design, manufacture, and operation of efficient and economical structures,
machines, processes, and systems”

SOE: introduction 6

software engineering

“(1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.
(2) The study of approaches as in (1).”

- the IEEE Computer Society
- SWEBOK (the software engineering body of knowledge)

- (not clear that SE is a (natural) science)

SOE: introduction 7

SE - related disciplines

SWEBOK (2004):

SOE: introduction 8

SE in this course

• a development • a set of complimentary
approach SE tools, techniques
• process model and practices designed
• associated tools, to support the
techniques, practices underlying development
• a set of (unspoken) approach
assumptions about the • such as project
nature of software
development and its
management,
contexts configuration
• e.g. traditional management,
waterfall estimation

SOE: introduction 9

traditional development approach (process)

a.k.a
• SDLC (Systems Development Life Cycle)
• waterfall
• linear sequential
• big design up front
Requirements

Design

Implementation

Test

SOE: introduction 10

typical SDLC activities
 understand what the customer or user wants
(requirements)
 understand the context or work process that the
computer system will support (analysis)
 write a description of the system to be built
(specification)
 make a upfront paper design for the program (design)
 program the system (coding)
 debug the resulting program (test)
 install or implement the system
 support the system in use and redevelop as necessary
(operation and maintenance)


NATO-seminar in Garmisch 1968


waterfall model


Boehm’s Seven Principles (1976)

• manage using a sequential life cycle plan
• perform continuous validation
• maintain disciplined product control
• use enhanced top-down structured programming
• maintain clear accountability
• use better and fewer people
• maintain commitment to improve process


SWEBOK = traditional development approach


SWEBOK + associated tools and techniques


early waterfall
problems

NATO-seminar in Garmisch 1968

Rayleigh Curve

A rational design process (Parnas et al, 1986)

• ‘ideally, we would like to derive our programs from a statement of
requirements in the same sense that theorems are derived from axioms in
a published proof’
• impossible because of:
1. imperfect requirements
2. learning during design work
3. human cognitive limits
4. external change
5. human error
6. preconceived design ideas
7. economic considerations (e.g. reuse of software)
• solution: fake it: continuous requirements documentation


Poppendieck 2000: its time to stop faking it

• accept that the rational (traditional) model cannot be achieved
• focus on iterative and incremental development
• requirements and architecture (40%) first
• then construction and test


traditional approach: many alternatives
alternative examples perceived flaw in traditional software process
participatory ETHICS, Scandinavian school responds to lack of serious user involvement
development
context‐aware Contextual Design responds to heavy focus on computer system design
methods
rapid development RAD responds to poor speed of delivery
test driven TDD responds to lack of rigor in delivering bug free code
development
agile methods XP, SCRUM responds to process‐rigid, analysis‐heavy and programmer
unfriendly development style
open source LINUX, REDHAT projects responds to hierarchical and commercially oriented development
style
business‐focused Business Process Re‐ responds to inability to focus on business process innovation and
engineering automation of existing business process
systems theory‐ Soft‐Systems Methodology, responds to heavy focus on rational analysis and hard systems
focused User Centred Design tradition
formal methods Z, UPPAAL responds to perceived lack of mathematical or logical rigour in
traditional process

the Aalborg SE tradition
agile (Ivan Aaen)

development tools,
approaches techniques,
practices

traditional

• understand the meta-principles upon which traditional software
development is based (not learn how to do it again)
• learn agile methods and one alternative set of meta-principles which
respond to a particular set of concerns with the traditional
development approach
• learn software engineering tools, techniques and practices and how to
apply them in both situations



development approaches: process models

waterfall model

• linear sequential

SOE: process models 2

V-model


prototyping
Qu ick p lan

• throwaway Com m unicat ion

• evolutionary Mo d e lin g
Qu ick d e sig n

Deployment
De live r y
& Fe e dback Const r uct ion
of
pr ot ot ype


iterative


incremental

increment # n
Co m m u n i c a t i o n
Pl a nning

M ode li ng
analy s is Co n s t ru c t i o n
des ign
c ode De p l o y m e n t
t est d e l i v e ry
fe e dba c k

deliv ery of
nt h increment
increment # 2

Pl a nning

M ode ling
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
deliv ery of
increment # 1 2nd increment

Pla nni ng
M ode ling
des ign c ode De p l o y m e n t
t es t d e l i v e ry deliv ery of
fe e dba c k

1st increment

project calendar t ime


spiral model
(Boehm,
1988)


unified process


SCRUM


XP


linear v. iterative


Usage
Functions
Interfaces

Class
Structure
Behavior

Model Component
Function Component
Connecting components

OOAD – Criteria
Components
Mathiassen Processes

et al
13

lifecycle XP

Qu ick p lan

Com m unicat ion
increment # n
Pla nning Mo d e lin g
M od e lin g
a n a ly s is
d e s ig n
Co n s t ru c t i o n Q u ick d e sig n
c o de De p l o y m e n t
t est d e l i v e ry
fe e dba c k

deliv ery of
nt h increment
increment # 2

Pla nn in g

M ode ling
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
deliv ery of
increment # 1 2nd increment
Deployment
Pla nning
M ode ling
De live r y
an a ly s is
de s ig n
Co n s t ru c t i o n
c od e De p l o y m e n t & Fe e dback Const r uct ion
deliv ery of
t es t d e l iv e ry
fe e dba c k of
1st increment
pr ot ot ype

project calendar t ime

incremental prototyping


traditional: requirements

requirements

analysis

design

(
programming
)

test

early project activities
• objective: start the project and find out
what is to be built
• can include:
• feasibility study
• cost benefit analysis
• risk analysis
• project initiation
• system concept
• early planning
• team setup
• contract negotiation
• and requirements analysis/engineering

SOE: requirements 2

the problem addressed:

• the requirements problem: the software does not match the
needs of users
• software features are missing or incomplete
• (costly) features are provided which are unnecessary
• as a result the user struggles to complete their work task or achieve
their objectives, even though the software functions according to its
specification and is bug free

SOE: requirements 3

a requirement is:
• a specification for what should be implemented - a description of:
• how the system should behave
• application domain information
• constraints on the system's operation
• specification of a system property or attributes
• a system capability needed by the user 1.1 System Feature 1
to solve a problem or achieve an <Don’t really say “System Feature 1.” State the feature name in just a few words.>

objective, and/or a system capability 3.1.1 Description and Priority
<Provide a short description of the feature and indicate whether it is of High,
that must be met or possessed by a Medium, or Low priority. You could also include specific priority component
ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale

system or system component to satisfy
from a low of 1 to a high of 9).>
3.1.2 Stimulus/Response Sequences
a contract, standard, specification or <List the sequences of user actions and system responses that stimulate the
behavior defined for this feature. These will correspond to the dialog elements

other formally imposed document 3.1.3
associated with use cases.>
Functional Requirements
• acquired by dialogue with users <Itemize the detailed functional requirements associated with this feature. These
are the software capabilities that must be present in order for the user to carry out
• classical division between: the services provided by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or invalid inputs.
Requirements should be concise, complete, unambiguous, verifiable, and
• functional necessary. Use “TBD” as a placeholder to indicate when necessary information is
not yet available.>

• non-functional <Each requirement should be uniquely identified with a sequence number or a meaningful
tag of some kind.>

SOE: requirements 4

requirements analysis is
• a series of analysis techniques to address shortfalls in what
users/stakeholders are able to express as their needs and
wishes for the system including:
• many modelling techniques
• evolutionary or throwaway prototyping
• and to improve developers’ understanding of their users and
their users’ situations

SOE: requirements 5

requirements engineering is:
• the attempt to add scientific precision to users’ incomplete accounts of their needs
and wishes and developers flawed attempts to understand them
• ”Requirements engineering is the branch of software engineering concerned with
the real-world goals for, functions of, and constraints on software systems. It is also
concerned with the relationship of these factors to precise specifications of
software behaviour, and to their evolution over time and across software families."

SOE: requirements 6

the requirements
specification: the end
result
• the baseline for all future
project activities
• future contract negotiations
• project planning, estimation,
scheduling, cost planning, risk
management
• analysis and design
• acceptance testing
• tradeoffs
• change control
• and the beginning of most its
problems
SOE: requirements 7

requirements: problems
• from the user: incomplete,
contested, badly explained,
ambiguous, misunderstood, without
technical understanding, socially
contested
• by the developer: badly understood,
poorly interpreted through lack of
domain knowledge, poorly
documented, under negotiated
• churn – change over the
lifetime of the project
due to poor initial
analysis or natural
situational evolution

SOE: requirements 8

requirements: managing for change

SOE: requirements 9

requirements: iterative ‘good enough’ strategy

SOE: requirements 10

Requirements management tools


the requirements problem expressed visually

use domain

developer dialogue an agreed,
domain mutually
understood and
relatively stable
account of what to
build


difficult or inappropriate situations

• users are
• very many and/or
use domain
• very different
• difficult to communicate with (children)
• the use domain is
• unusually expert (eye surgery, investment
management)
• poorly defined (start-up consultancy)
• the software is not primarily determined by
user needs
• consider: embedded software, missile control
system, computer game, ERP system


classical requirements analysis - supplements
and alternatives
• domain engineering (overlaps with system analysis) – obtaining
a more precise understanding of the use domain through a
variety of domain modelling techniques e.g.:
• object modelling
• business process modelling
• ontology construction SessionVars

• and very many others mode: MODE
operator: OPERATOR
• formal specification language (e.g. Z) patient: PATIENT
field: FIELD
• prototyping, paper prototyping names: PATIENT
fields: FIELD PRESCRIPTION
• iterative process counters: FIELD ACCUMULATION

• use cases and user stories operator = no_operator operator operators
mode = experiment operator physicists
names = if mode = therapy then patients else
studies

supplements and
alternatives
• ethnography
• participatory development (e.g.
ETHICS, User-Centred Design,
Contextual Design, Joint
Application Design)
• low-tech models (e.g. rich
picture)
• user workshops, focus groups,
virtual communities
• on-site customer, product owner


the requirements problem

• traditional solution: application of greater engineering rigour
to requirements gathering by means of
• structured data gathering with users
• better planning
• comprehensive, structured documentation,
• additional modelling techniques
• management of requirements throughout development


a research roadmap: Nuseibah + Easterbrook

• better modelling and analysis of problem domains, as opposed to the behaviour of
software.
• development of richer models for capturing and analysing non-functional
requirements.
• bridging the gap between requirements elicitation approaches based on contextual
enquiry and more formal specification and analysis techniques.
• better understanding of the impact of software architectural choices on the
prioritisation and evolution of requirements.
• reuse of requirements models to facilitate the development of system families and
the selection of COTS (commercial off-the-shelf).
• multi-disciplinary training for requirements practitioners.


traditional: analysis

requirements

analysis

design

(
programming
)

test

the analysis (representation) problem

• the software contains a model of the external world which
cannot be recognized or adapted to by its users

SOE: requirements 2

analysis

• many hundreds of systems analysis and design methods
aka:
• requirements analysis
• requirements modelling
• systems analysis (as in systems analysis and design)
• domain analysis
• structured analysis
• object-oriented analysis
• problem and application domain analysis (OOA+D)

SOE: analysis 3

use domain

code models
#include <functional>

/* class for the compose_f_gx adapter
*/
template <class OP1, class OP2>
class compose_f_gx_t
: public std::unary_function<typename OP2::argument_type,
typename OP1::result_type>
{
private:
OP1 op1; // process: op1(op2(x))
OP2 op2;
public:

domain models // constructor
compose_f_gx_t(const OP1& o1, const OP2& o2)
: op1(o1), op2(o2) {
}

// function call
typename OP1::result_type
operator()(const typename OP2::argument_type& x) const {
return op1(op2(x));
}
};

/* convenience function for the compose_f_gx adapter
*/
template <class OP1, class OP2>
inline compose_f_gx_t<OP1,OP2>
compose_f_gx (const OP1& o1, const OP2& o2) {
return compose_f_gx_t<OP1,OP2>(o1,o2);
}

SOE: analysis 4

analysis models
• abstractions
• contain:
• a set of terms, concepts and
relationships, often with a theoretical
background
• a standardised representation form or
modelling language (e.g. UML)
• a (usually hidden) set of assumptions
about the nature of reality, how it’s
understood and what’s important
• model forms:
• textual (system definition, event list)
• pictorial (rich picture)
• diagrammatic (entity model, object
model, dataflow diagram)
• algorithmic (pseudo code, Z)
SOE: analysis 5

an interpretation problem

users developers formalised

user-near program-
near
use domain

informal

analysis models

SOE: analysis 6

classical systems analysis
• a classical systems analysis is a description of
relevant parts of a use domain, not a plan for a
software implementation
use domain • ensures that a software design is based on a
sound understanding of the context that the
software will later be used in
• this understanding is often extremely difficult
for software engineers to acquire and share
• analysis provides a
• common communication language for developers
• process structure (what to do, when)
• consistency and completeness checking
• stepwise refinement
• programming-related modelling forms which can
be the basis for design
SOE: analysis 7

what is modelled:
• classical systems analysis - three types of analysis:
1. data structure (the structure of information) e.g. ERM
2. process (transformations or operations on data) e.g. dataflow diagram
3. sequence or dynamics (the behaviour of the system over time) e.g. state
transition diagram
• object orientation conflates the first two

D a t a O b jec t D e sc r ip t io n P r o c e s s S p e c ific a tio n (P S P E C )

E n t ity - D a t a F lo w
R e la tio n s h ip D ia g r a m
D ia g r a m

D a t a D ic tio n ar y

arch i ectur l
S t a te -T r a n s it io n
d e ig
D ia g r a m

d ata
C o n tro l S p e c if ica tio n (C S P E C )
d esign

SOE: analysis 8

a bewildering array of other analysis forms
29th Conference on Conceptual Modelling

Information Modeling Concepts, including Ontologies;
Ontological and Semantic Correctness in Conceptual Modeling;
Logical Foundations of Conceptual Modeling;
Cognitive Foundations of Conceptual Modeling;
Conceptual Modeling and Web Information Systems;
Business Process Modeling;
Conceptual Modeling and Enterprise Architecture;
The Semantic Web;
Semi-structured Data and XML;
Integration of Conceptual Models and Database Schemas;
Information Retrieval, Filtering, Classification, Summarization, and Visualization;
Methodologies and Tools for Conceptual Design;
Evaluation and Comparisons of Conceptual Models and Modeling Methods;
Requirements Engineering;
Reuse, Patterns, and Object-Oriented Design;
Reverse Engineering and Conceptual Modeling;
Quality and Metrics of Conceptual Models;
Empirical Studies of Conceptual Modeling;
Conceptual Change and Schema Evolution;
Maintenance of Conceptual Models;
Management of Integrity Constraints;
Active Concepts in Conceptual Modeling;
Spatial, Temporal, and Multimedia Aspects in Conceptual Models;
Metadata, its Interpretation and Usage;
Conceptual Models and Knowledge Management Systems;
Data warehousing, data mining, and business intelligence; and
Other Advanced and Cross-Disciplinary Applications of Conceptual Models

SOE: analysis 9

case tool support

• diagram support and debugging,
code generation, document
generation, tailored
development method support,
consistency and completeness
checking, reverse engineering,
import, model driven
architecture support, IDE diagrammer code generator

integration, integration with
estimation and scheduling tools repository

SOE: analysis 11

classical systems analysis: four critiques 1

XP

• classical systems analysis is unnecessary and time consuming
• it promotes the role of the analyst over the programmer
• the programmer can obtain the necessary domain understanding from the
customer and write it directly into the program

SOE: analysis 12


Soft Systems Methodology

• classical systems analysis does not capture what is really important in a
user domain (e.g. the underlying work system – only some minor things
which contribute to software design)
• it encourages a (false) impression that there is one correct view of a user
domain that the analyst can determine and later use as the basis for design

SOE: analysis 13


Contextual Design

• classical systems analysis is the
property of the expert systems
analyst
• it does not promote real dialogue
with the stakeholders and users or
involve them in any future work

SOE: analysis 14


Business Process Re-engineering

• classical systems analysis focuses on
automating an existing (manual)
system
• it provides no incentive for changing
or radically improving the underlying
work process

SOE: analysis 15

analysis: summary

problem: accurate representation of user domain
objective: understand the use domain and represent it in a software
friendly notation
tools and techniques various forms of semi-formal modelling
underlying theory systems theory +
purpose user domain understanding - develop accurate and
communicable domain models which can later be represented
as software
known weaknesses not always very close either to programmer or to user
scope limitation situational – access to a suitable use domain is required
principal danger goal displacement

SOE: analysis 16

SOE

requirements

traditional: test
analysis

design

(
programming
)

test

the quality problem
• the system is delivered with bugs, service and usability problems that make
it difficult to use
• software released too early - users run untested code, which crashes or
delivers system-generated error messages
• requested functionality is missing, the software runs slowly, interfaces
contain major usability errors
• calculations are wrong, data is lost or corrupted

SOE: test 2

generates 28
test cases (=
paths through
the code)

SOE: test 3

traditional engineering response
•validation
to demonstrate to the
developer and the system
why test? customer that the software
•problems with meets its requirements •unit test
requirements, •verification •integration test
analysis and to establish that the program •regression test
design revealed runs as intended without •GUI test
late defects •smoke test
•programmer •performance/load test
error in •a test strategy •interface test
executing the •a test plan •system test
design •a test suite with test •acceptance/operational
cases test
•test execution •alpha/beta test
•debugging
•test report

SOE: test 4

a testing-oriented development process:
v model

+ effective project management

SOE: test 5

a planned process

test test test test
cases data results reports

design test prepare test r un program compare results
cases data with test data to test cases

SOE: test 6

policies and guidelines

•exhaustive test is impossible on •define procedures for tests and
non-trivial systems test cases, e.g.:
•test policies define the approach •choose inputs that force the
system to generate all error
to be used in selecting system messages;
tests e.g.: •design inputs that cause buffers
•all functions accessed through to overflow;
menus should be tested; •repeat the same input or input
•combinations of functions series several times;
accessed through the same •force invalid outputs to be
generated;
menu should be tested;
•force computation results to be
•where user input is required, all too large or too small.
functions must be tested with
correct and incorrect input.

SOE: test 7

an experienced team

developer errors
requirements conformance
understands the system
but will test "gently" independent tester performance
and is driven by "delivery"
must learn about the system,
but will attempt to break it an indication
and is driven by quality of quality

• a professional testing team, with their own tools and
structured procedures

SOE: test 8

unit test designed environment

interface

driver local data structures
boundary conditions
independent paths
error handling paths
module

stub stub

RESULTS Test cases

SOE: test 9

structured testing: top down integration

A top module is tested with
stubs

B F G

stubs are replaced one at
a time, “depth or breadth first”
C

as new modules are integrated,
D E some subset of tests is re-run

SOE: test 10

white-box test

requirements

output
... our goal is to ensure that all
statements and conditions have
been executed at least once ...
input events

black-box test

SOE: test 11

mathematical and engineering techniques, e.g.:
basis path test
first, we compute the cyclomatic complexity:
number of simple decisions + 1
or
number of regions
or
1 number of edges – number of nodes + 2
in this case, v(g) = 4
2
next, we derive the independent paths:
4 3
5 6
since v(g) = 4, there are up to four paths

path 1: 1,2,3,6,7,8
7 path 2: 1,2,3,5,7,8
8 path 3: 1,2,4,7,8
path 4: 1,2,4,7,2,4, …7,8

finally, we derive test cases to exercise these
paths.

SOE: test 12

object class test
• complete test coverage
of a class involves
• test all operations
associated with an
object;
• setting and • define test cases for
interrogating all object reportWeather, calibrate, test,
attributes; startup and shutdown.
• exercising the object • using a state model, identify
in all possible states. sequences of state transitions to
• inheritance makes it be tested and the event
more difficult to design sequences to cause these
object class tests as the transitions
data to be tested is not • for example:
localised. • waiting > calibrating > test >
transmitting > waiting
SOE: test 13

test automation HP QuickTest Professional HP

IBM Rational Functional
IBM Rational
• test is an expensive Tester
process phase - test Rational robot IBM Rational
workbenches provide a Selenium OpenSource Tool
range of tools to reduce Silk Test Microfocus
the time required and total Test Complete AutomatedQA
test costs. TestPartner Micro Focus
• bug tracker Watir OpenSource Tool
• unit test: xUnit SilkCentral - Test Management
• record and play SilkTest - Automated functional and regression testing
SilkPerformer - Automated load and performance testing
• acceptance test: Fit, SilkMonitor - 24x7 monitoring and reporting of Web, application
FitNesse, EasyAccept and database servers
SilkPilot - Unit testing of CORBA objects
• ……. SilkObserver - End-to-end transaction management and
monitoring for CORBA applications
• ……….. SilkMeter - Access control and usage metering
SilkRealizer - Scenario testing and system monitoring
SilkRadar - Automated defect tracking

SOE: test 14

systematic debugging: symptoms & causes

• symptom and cause may be
geographically separated
• symptom may disappear when
another problem is fixed
• cause may be due to a
combination of non-errors
• cause may be due to a system
or compiler error
• cause may be due to
cause
symptom
assumptions that everyone
believes

SOE: test 15

traditional test ideals: summary

• a testing-oriented development process
• a planned process
• policies and guidelines
• an experienced team
• a designed environment
• white/black box testing
• test automation
• systematic de-bugging

SOE: test 16

traditional test: alternatives and supplements

• test driven development (agile)
• usability testing
• walkthrough/code review
• user satisfaction testing
• business performance evaluation
• model-driven testing (UPPAAL)

SOE: test 17


requirements

traditional:
design analysis

design

(
programming
)

test

SLOC
Operating System
(Million)
Windows NT 3.1 4-5
Windows NT 3.5 7-8
• the design problem: the Windows NT 4.0 11-12

software design Windows 2000
more
than 29
inadequately solves the Windows XP 40

problem, creating issues Windows Server
2003
50

such as maintainability,
adaptivity, portability, Debian 2.2 55-59
Debian 3.0 104
security Debian 3.1 215
Debian 4.0 283

SOE: design 2

why design?

• program structure
• completeness and consistency
• complexity management
• performance
• communication between
programmers
• planning and organization of
development work
• maintenance
• change readiness

SOE: design 3

traditional software design
design principals, patterns
architectural models
requirements

design process
analysis

design specification

SOE: design 4

some design tasks

• design strategies – priorities and tradeoffs
• architecture design
• sub-system/module/component design
• detailed component design
• data structure (database)
• user interface design
• processing design
• algorithm design
• logical/physical design

SOE: design 5

design strategy
• trade-off of different desirable program characteristics in relation
to design context and known principles, criteria, heuristics

system characteristics:
quality criteria:
•usable modular design principles: •performance
•secure •security
•information hiding
•efficient •safety
•cohesion (high) •availability
•correct •coupling (low) •maintainability
•reliable
•..... modular design heuristics:
•..... •evaluate the first design iteration to
•.... reduce coupling and improve cohesion
•strive for fan-in depth
•.........................
•...............................

SOE: design 6

the traditional ideal:
structured design, planned, top down,
sequential, output dependence
requirements
specification

design activities

architectural interface component data algorithm
abstract
design design design structure design
specification
design

software data
system interface component algorithm
specification structure
architecture specification specification specification
specification

design products

SOE: design 7

the traditional ideal – design derived from
analysis

Process Specification (PSPEC)
Data Object Description procedural
Entity-
design
Data Flow
Relationship Diagram
Diagram

interface
Data Dictionary
design

architectural
State-Transition design
Diagram

data
Control Specification (CSPEC) design

THE ANALYSIS MODEL THE DESIGN MODEL

SOE: design 8

in practice

•stepwise refinement of existing analysis
model so that it can be programmed
Data Object Description Process Specification (PSPEC) •add many missing elements: plug-in procedural
design
Entity-
Relationship
Data Flow
Diagram
components, interface, navigation,
Diagram
network communication, database
Data Dictionary
communication etc interface
design
•partition into separate modules,
components architectural
State-Transition design
Diagram •structure program according to
data
Control Specification (CSPEC)
performance requirements design
•describe at several levels of abstraction
for different stakeholders
THE ANALYSIS MODEL THE DESIGN MODEL

SOE: design 9

system architecture

SOE: design 10

traditional ideal - deriving architectures from
analysis models
control hierarchy
example

transform mapping

transaction mapping

SOE: design 11

architecture trade-offs
traditional ideal: rationality
•using large-grain components
architecture in relation to design
strategy improves performance but reduces
maintainability.
performance •introducing redundant data improves
localise critical operations and availability but makes security more
minimise communications - use difficult.
large rather than fine-grain •localising safety-related features
components. usually means more communication
security so degraded performance.
use a layered architecture with
critical assets in the inner design considerations
layers.
safety •is there a generic application architecture that can be
localise safety-critical features in used?
a small number of sub-systems. •how will the system be distributed?
availability
•what architectural styles are appropriate?
include redundant components
and mechanisms for fault •what approach will be used to structure the system?
tolerance. •how will the system be decomposed into modules?
maintainability •what control strategy should be used?
use fine-grain, replaceable •how will the architectural design be evaluated?
components. •how should the architecture be documented?
SOE: design 12

traditional ideal: generic design structures
imposed externally
«component»

• OOAD – generic
Interface

«component»
User interface
«component»
System interface architecture
• matches
«component» problem/application
area division
Function

«component»
Model

«component»
Technical platform

«component» «component» «component»
UIS DBS NS

SOE: design 13

architectural styles client server

repository

function oriented pipelining (pipes and filters)

layered

SOE: design 14

traditional ideal – top down decomposition:
detailed component design
data
dictionary

<variable> = <expression>

if <condition>
do stuff;
else pseudocode
do other stuff;

while <condition>
do stuff;

for <variable> from <first value> to <last
value> by <step>
do stuff with variable;

function <function name>(<arguments>)
do stuff with arguments;
return something;

<function name>(<arguments>) // Function
call

SOE: design 15

the design document

SOE: design 16

alternatives and complementary techniques

• evolutionary design with refactoring (agile)
• low-tech design (contextual design)
• design pattern movement
• metaphors
• design standards
• guidebooks

SOE: design 17

the design problem: traditional engineering
solutions

• structured design, planned, sequential, output dependence
• top down design, decomposition
• design derived (quasi algorithmically) from earlier analysis
• rational argumentation of design trade-offs based on known
design principles
• generic design structures imposed from outside
• precise and detailed documentation that can later be used by a
programmer with no prior knowledge of analysis

SOE: design 18

SOE

Unified Process
Rational Unified Process

UP: iterative

not (necessarily) agile
SOE: Unified Process 2

• Unified Software Development Process – widely used industry standard software
engineering process
• commonly referred to as the "Unified Process" or UP
• generic process for the UML
• free - described in "The Unified Software Development Process", ISBN:0201571692"
• UP is:
• use case (requirements) driven
• risk driven
• architecture centric
• iterative and incremental
• UP is a generic software engineering process – must be customised (instantiated)
for your project
• in-house standards, document templates, tools, databases, lifecycle modifications, …
• Rational Unified Process (RUP) is the commercial instantiation of UP
• marketed and owned by Rational Corporation
• also has to be instantiated for your project


Unified Process at a glance
Phases
Process Workflows Inception Elaboration Construction Transition

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

Iterations within phases

SOE: Unified Process

iterations, phases, workflows, milestones

initial
milestone life-cycle life-cycle product
operational
objectives architecture release
capability

phase inception elaboration construction transition

iterations iter 1 iter 2 iter 3 iter 4 iter 5 iter 6

5 core
workflows r a d i t … … … … …


artefacts (work products), activities, workers (roles)

some prominent work products:

• vision: summary of objectives,
features, business case
• software architecture document:
short learning aid to understand the
system
• test plan: summary of goals and
methods of testing
• iteration plan: detailed plan for the
next iteration
• change request: uniform way to track
all requests for work, e.g. defects


instantiation agile
green-field maintenance hot fix
business modelling

requirements

analysis and design

implementation

test

deployment
configuration
management
management
environment

development................
 problems  causes  UP practice
 inaccurate understanding  insufficient requirements  develop software
of end-user needs specification and their ad hoc iteratively
 inability to deal with management  manage
changing requirements  ambiguous and imprecise requirements
 modules don’t integrate communication  use component-
 it is difficult to maintain or  brittle architecture based
extend the software  overwhelming complexity architectures
 late discovery of flaws  undetected inconsistencies in  visually model
 poor quality and requirements, design, and software
performance of the implementation  continuously verify
software  poor and insufficient testing software quality
 no coordinated team effort  subjective assessment of project  control changes to
 build-and-release issues status software
 failure to attack risk
 uncontrolled change propagation
 insufficient automation


develop iteratively, manage requirements:
case-driven development
in inception in elaboration
• use case model outlined • use cases are iteratively specified
• use cases briefly and realized
described
• use cases ranked
• elaboration iterations are elaboration elaboration elaboration
iteration 1 iteration 2 iteration 3
planned and organized on
the basis of the ranked
use cases
use case a use case a use case f
.........
sketch full version .........

use case b use case g
......... ......... .........
......... ......... .........


develop iteratively:
architecture-centric development
in inception • in elaboration
• software architecture gradually
• initial candidate architecture
defined
based on requirements
• software architecture finally
baselined

elabo- elabo- elabo-
ration ration ration
iteration 1 iteration 2 iteration 3

analysis of storing persistent access control and
architectural data security
factors

architectural control flow distribution
views


4+1 view model of architecture

implementation
logical view
view
an abstraction of the
an organization of static
design model that identifies
software modules (source
major design packages,
code, data files, components,
subsystems and classes
executables, and others …)
use-case view
key use-case and
scenarios

process view deployment view
a description of the concurrent various executables and
aspects of the system at other runtime components
runtime - tasks, threads, or are mapped to the underlying
processes as well as platforms or computing
their interactions nodes

11
soe: unified process

use component-based architectures

• component-based development
• resilient software architecture
• enables reuse of components from many available sources
• systems composed from existing parts, off-the-shelf third-party parts, (few)
new parts that address the specific domain and integrate the other parts
together.
• iterative approach involves the evolution of the system architecture.
• each iteration produces an executable architecture that can be measured,
tested, and evaluated against the system requirements.


visually model software (uml standard)

class
use-case diagrams
diagrams
object
sequence diagrams
diagrams

collaboration models component
diagrams diagrams

deployment
statechart diagrams
diagrams
activity
diagrams


continuously verify software quality
• software problems are exponentially more expensive to find and repair
after deployment than beforehand.
• verifying system functionality involves creating test for each key scenario
that represents some aspect of required behavior.
• since the system is developed iteratively every iteration includes testing =
continuous assessment of product quality.

cost

SOE: Unified Process time

control changes to software

• the ability to manage change - making certain that each change is
acceptable, and being able to track changes - is essential in an environment
in which change is inevitable.
• maintaining traceability among elements of each release is essential for
assessing and actively managing the impact of change.
• in the absence of disciplined control of changes, the development process
degenerates rapidly into chaos.


best practices summarized
visual modeling
time-boxed iterations • prior to programming, do
• avoid attempting large, up- at least some visual
front requirements modeling to explore
strive for cohesive architecture creative design ideas
and reuse existing manage requirements
components • find, organize, and track
on large projects: requirements & requirements iteratively
core architecture developed through skillful means with
by small co-located team; use tool support.
then early team members manage change
divide into sub-project • disciplined configuration
leaders management and version
continuously verify quality control, change request
• test early, often, and protocol, base-lined
realistically by integrating all releases at the end of each
software each iteration iteration


RUP - overview
Faser
Artifacts Process Workflows Inception Elaboration Construction Transition

Business Modelling
Analysis model
Requirements

Analysis & Design

Implementation
Design model
Use case model Test

User Deployment
Software
Architecture
Implementation Configuration Mgmt.
Document
model Project Management
Environment
 Architect
Test  Prelimenary
I-1 I-2 I-3 I-4 I-5 I-6 I-7 I-8 I-9
 iterations


Test model Iterations
Deployment
Risk list
model
1. Xxx xxx
2. Xx xx xxx
3. Xx xxxxxxx Risk & iterations
Iteration plan
$
Project Manager

RUP - philisophy RUP - key elements Contents of a workflow
- Iterations / Increments - Phases
Architecture & system
- Use case driven - Iterations Artifact
- Architecture centered - Workflows
- Visual (UML) - Activities Artifact
Artifact I1 I2 ...
- Configurable process - Roles
- Risk driven - Artifacts Role Activity
Domain knowledge


bottom-up design: patterns

the pattern movement

pattern
• a pattern addresses a recurring problem that arises in specific
situations
• patterns document existing, well-proven design experience
• patterns identify and specify abstractions that are above the level of
single classes and instances
• patterns provide a common vocabulary and understanding for design
principles
• patterns are a means of documenting software architectures
• patterns support the construction of software with defined properties
• patterns help you build complex and heterogeneous software
architectures
• patterns help you manage software complexity

SOE: refactoring and patterns 2

standard documentation form
pattern name and classification: a descriptive and unique name that helps in identifying and
referring to the pattern
intent: a description of the goal behind the pattern and the reason for using it
also known as: other names for the pattern
motivation (forces): a scenario consisting of a problem and a context in which this pattern can be
used
applicability: situations in which this pattern is usable; the context for the pattern
structure: a graphical representation of the pattern – class diagrams and interaction diagrams may
be used for this purpose
participants: a listing of the classes and objects used in the pattern and their roles in the design
collaboration: a description of how classes and objects used in the pattern interact with each
other
consequences: a description of the results, side effects, and trade offs caused by using the pattern
implementation: a description of an implementation of the pattern; the solution part of the
pattern
sample code: an illustration of how the pattern can be used in a programming language
known uses: examples of real usages of the pattern
related patterns: other patterns that have some relationship with the pattern; discussion of the
differences between the pattern and similar patterns

types of patterns

• analysis patterns
• design patterns/GRASP
• software architecture patterns
• organizational and process patterns


analysis patterns

• patterns that reflect
the generic conceptual
structure of business
processes rather than
analysis problem
actual software
implementations
• simple, specialized
notation (very similar
to entity-relationship
diagram notation)

analysis pattern
‘Analysis Patterns: Reusable
Object Models’, Martin Fowler

organisational and process patterns

• research into social and Coplien’s top ten patterns
behavioural patterns in
• unity of purpose
software firms which lead to
• engage customers
successful outcomes • domain expertise in roles
• architect controls product
• distribute work evenly
• function owner and
component owner
• mercenary analyst
• architect also implements
• firewalls
• developer controls process


design anti-patterns
• big ball of mud: a system with no recognizable structure
• database-as-ipc: using a database as the message queue for routine inter-process
communication where a much more lightweight mechanism would be suitable
• gas factory: an unnecessarily complex design
• gold plating: continuing to work on a task or project well past the point at which
extra effort is adding value
• inner-platform effect: a system so customizable as to become a poor replica of the
software development platform
• input kludge: failing to specify and implement handling of possibly invalid input
• interface bloat: making an interface so powerful that it is extremely difficult to
implement
• magic pushbutton: coding implementation logic directly within interface code,
without using abstraction
• race hazard: failing to see the consequence of different orders of events
• stovepipe system: a barely maintainable assemblage of ill-related components


design patterns

• design patterns provide abstract, reusable “micro-architectures” that
can be applied (“instantiated”) to resolve specific design issues
(forces) in previously-used, high-quality ways
• GoF (Gang of Four)
• creational - manage instantiation - can be further divided into class-
creation (use inheritance effectively) patterns and object-creational
(use delegation) patterns
• structural - concern class and object composition - use inheritance to
compose interfaces and define ways to compose objects to obtain new
functionality
• behavioural - concerned with communication between objects

GAMMA, E., HELM, R., JOHNSON, R. & VLISSIDES, J. (1995)
Design Patterns, Boston, Addison-Wesley.

GoF creational patterns:

• abstract factory groups object factories that have a common
theme
• builder constructs complex objects by separating construction
and representation
• factory method creates objects without specifying the exact
class to create
• prototype creates objects by cloning an existing object
• singleton restricts object creation for a class to only one
instance


GoF structural patterns:

• adapter allows classes with incompatible interfaces to work together by
wrapping its own interface around that of an already existing class
• bridge decouples an abstraction from its implementation so that the two
can vary independently
• composite composes zero-or-more similar objects so that they can be
manipulated as one object
• decorator dynamically adds/overrides behaviour in an existing method of
an object
• façade provides a simplified interface to a large body of code
• flyweight reduces the cost of creating and manipulating a large number of
similar objects
• proxy provides a placeholder for another object to control access, reduce
cost, and reduce complexity


GoF behavioral patterns: concerned with communication
between objects

• chain of responsibility delegates commands to a chain of processing objects
• command creates objects which encapsulate actions and parameters
• interpreter implements a specialized language
• iterator accesses the elements of an object sequentially without exposing its
underlying representation
• mediator allows loose coupling between classes by being the only class that has
detailed knowledge of their methods
• memento provides the ability to restore an object to its previous state (undo)
• observer is a publish/subscribe pattern which allows a number of observer objects
to see an event
• state allows an object to alter its behavior when its internal state changes
• strategy allows one of a family of algorithms to be selected on-the-fly at runtime
• template method defines the skeleton of an algorithm as an abstract class, allowing
its subclasses to provide concrete behavior
• visitor separates an algorithm from an object structure by moving the hierarchy of
methods into one object


pattern use example
Movie Price
1
charge() charge()

<<code>> ChildrensPrice 1 RegularPrice 1 NewRelease 1
return priceCode.charge() Price
charge() charge()
charge()

state pattern
singleton pattern


GRASP (General Responsibility Assignment Software Patterns)

• information expert: allocating responsibilities (methods, computed fields etc.) by
determining which class has the most relevant data variables
• creator: determines which class should govern creation of new instances of classes
in non-trivial situations. Given two classes (A,B), class B should be responsible for
the creation of A if class B contains or compositely aggregates, records, closely
uses or contains the initializing information for class A (see also factory)
• controller: assigns the responsibility of dealing with system events to a non-UI class
that represents a use case scenario(s) - the first object beyond the UI layer that
receives and coordinates a system operation. The controller should delegate to
other objects the work that needs to be done
• low coupling: determines low dependency between classes, low impact in a class of
changes in other classes and high reuse potential


GRASP 2

• high cohesion: the responsibilities of a given element are strongly related and highly
focused
• polymorphism: responsibility for defining the variation of behaviors based on type is
assigned to the types for which this variation happens
• pure fabrication: a class that does not represent a concept in the problem domain
but is added to achieve low coupling, high cohesion, and the reuse potential thereof
• indirection: supports low coupling between two elements by assigning the
responsibility of mediation between them to an intermediate object e.g. controller
in MVC.
• protected variations: protects elements from variations on other elements by
wrapping the focus of instability with an interface and using polymorphism to
create various implementations of this interface.


architectural patterns
“.....an architectural pattern expresses a fundamental structural organisation
schema for software systems. It provides a set of predefined subsystems,
specifies their responsibilities, and includes rules and guidelines for
organizing the relationships between them”

• from mud to structure • interactive systems
• layers • model-view-controller
• pipes and filters • presentation-abstraction-
• blackboard control
• distributed systems • adaptable systems
• broker • microkernel
• reflection

BUSCHMAN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P. & STAL, M. (1996) Pattern-
oriented Software Architecture, Chichester, Wiley.

architectural patterns: from mud to structure
layers
example OSI model pipes and filters

problem large system with high and low example
level functions requiring problem process or transform a data
decomposition stream
structure layer j provides services used by structure •filter: collects, transforms and
j+1, delegates subtasks to j-1 outputs data supplied by pipe
known use TCP protocol, IS •pipe: transfers, buffers data
and synchronizes with
neighbours
presentation
•data source: delivers data to
application logic pipe
•data sink: consumes output
domain layer known use UNIX program compilation
and documentation creation
database


architectural patterns: from mud to structure
blackboard
problem no feasible deterministic
solution for transforming data
into high level structures
(diagrams, tables, language
phrases)
structure a collection of independent
programs that work co-
operatively on common data
•blackboard: central data store
•knowledge source: evaluates
its own applicability, computes
a result, updates blackboard
known use speech and image recognition,
vision, surveillance


architectural patterns: distributed systems
broker
problem manage distributed and possibly
heterogeneous systems with
independent operating components
structure •client: implements user functionality
•server: implements services
•broker: locates, registers and
communicates with servers,
interoperates with other brokers
through bridges
•client side proxy: mediates between
client and broker
•server side proxy: mediates between
server and broker
•bridge: mediates between local broker
and bridge of a remote broker
known CORBA, WWW
use


architectural patterns: interactive systems

model-view-controller
problem interactive systems with flexible
and change prone user interface
structure •model: provides central data and
function logic
•view: displays information to the
user
•controller: accepts inputs and
makes service requests for the
model, display requests for view
known Smalltalk systems
use


architectural patterns: interactive systems
presentation-abstraction-
control
problem interactive systems as a set of
cooperating agents
structure tree hierarchy of PAC agents,
with one top level agent –
each agent has:
•presentation: visible
behaviour of the agent
•abstraction: maintains data
and provides core
functionality
•control: connect
presentation and abstraction
and communicate with other
agents
known use network traffic control


architectural patterns: adaptable systems
microkernal
problem application domains with broad spectrums of standards and programming technologies,
continuous hardware and software evolution. Software should be portable, extensible,
adaptable
structure •microkernal: provides core services, manages resources and communication
•internal server: implements additional services
•external server: provides programming interfaces for clients
•client: represents an application
•adapter: hides system dependencies, invokes methods of external servers on behalf of
clients
known use Windows NT


architectural patterns: adaptable systems
reflection
problem systems exposed to changing
technology and requirements, and
support their own modification
structure •base level: implements the application
logic using information from meta level
•meta level: encapsulates system
internals that may change and provides
interface to facilitate modifications to
meta-level
•metaobject protocol: interface for
specifying and performing changes to
meta level
known OLE 2.0
use


potential benefits of patterns

• provides a common vocabulary and
understanding of design elements for software
designers
• increases productivity in design process due to
design reuse
• promotes consistency and high quality of system
designs and architectures due to application of
tested design expertise and solutions embodied
by patterns
• allows all levels of designers, from novice to expert,
to gain these productivity, quality and consistency
benefits


concerns
• benefits are dependent upon architects, analysts and
designers understanding the patterns to be used – the
common “design vocabulary”
• such training can be costly, and in many cases is
proprietary and cannot be obtained externally
• specific funding and effort must be directed toward
maintenance and evolution of patterns as reusable assets
or they tend to devolve into project/application-specific
artifacts with dramatically reduced reusability
characteristics
• promotes design culture at the expense of analysis culture
– less focus on responding adequately and accurately to
specific user domains


patterns and refactoring work together:
bottom up design

refactoring to patterns

pattern
through refactoring
development


design style,
abstraction level architecture

architectural
patterns
agile

design as model design as code
GRASP

design
refactoring
patterns

detailed design


traditional and agile design styles compared
design assumptions traditional agile
style top down bottom up
starts with modelling programming
process grand design up front evolutionary design
responsible architect, designers programmers
based upon user domain analysis generic design patterns
models
outcome design document program
weakness separation of design and absence of early
programming overview, unspecific
user domain
understandings


SOE

bottom-up design - refactoring and patterns

architecture
components
modules
architecture
screen sketch
object model
ERM

screen code
object code
design style database tables

algorithm design
data validation
exception handling

detailed design
abstraction level


design style,
abstraction level architecture

traditional

agile


detailed design


top down design - MDA executable UML
(Model Driven Architecture)

compiler J2EE
.NET
archetype


bottom-up design – refactoring

’Refactoring: improving the design of existing code’
Marting Fowler, Addison Wesley

bottom up design: refactoring
• refactoring (noun): a change made to the
internal structure of software to make it easier
to understand and cheaper to modify without
changing its observable behavior
• refactor (verb): to restructure software by
applying a series of refactorings
• refactoring is not:
• debugging
• mending business logic
• adding new functionality

Martin Fowler (and Kent Beck, John Brant, William Opdyke, Don Roberts), Refactoring - Improving the
Design of Existing Code, Addison Wesley, 1999


refactoring example: duplicated code
case 0:
activePiece = RightHookgetRightHook(); case 0:
ml = new MoveListener(activePiece); activePiece = RightHookgetRightHook(); break;
gameBoardaddKeyListener(ml); case 1:
break; activePiece = LeftHookgetLeftHook(); break;
case 1: case 2:
activePiece = LeftHookgetLeftHook(); activePiece = RightRisegetRightRise(); break;
ml = new MoveListener(activePiece); case 3:
gameBoardaddKeyListener(ml); activePiece = LeftRisegetLeftRise(); break;
break; case 4:
case 2: activePiece = HillgetHill(); break;
activePiece = RightRisegetRightRise(); case 5:
ml = new MoveListener(activePiece); activePiece = StraightPiecegetStraightPiece(); break;
gameBoardaddKeyListener(ml); case 6:
break; activePiece = SquaregetSquare(); break;
case 3: }
activePiece = LeftRisegetLeftRise(); ml = new MoveListener(activePiece);
ml = new MoveListener(activePiece); gameBoardaddKeyListener(ml);
gameBoardaddKeyListener(ml);
break; //more


why refactor?

refactoring improves design
without refactoring, even a well designed program will decay (‘go sour’) as
programmers make changes
refactoring makes software easier to understand
understandable code is easier to update and maintain
refactoring helps find bugs
refactoring involves clarification and re-shaping through better
understanding
refactoring speeds up programming
good design ensures comprehensibility and fewer changes as new
functionality is added


bad smells
• duplicate code: identical or very similar code exists in more than one location
• large method: a method, function, or procedure that has grown too large
• large class: a class that has grown too large (god object)
• feature envy: a class that uses methods of another class excessively
• inappropriate intimacy: a class that has dependencies on implementation details of
another class
• data clumps: a set of variables that seem to “hang out” together – e.g. often passed as
parameters, changed/accessed at the same time
• primitive obsession: all subparts of an object are instances of primitive types (int, string,
bool, double, etc)
• refused bequest: a class that overrides a method of a base class in such a way that the
contract of the base class is not honored by the derived class
• lazy class: a class that does too little
• duplicated method: a method, function, or procedure that is very similar to another
• contrived complexity: forced usage of overly complicated design patterns where simpler
design would suffice
• …………

refactoring (n): a standard way of improving poor code Preserve Whole Object
Add Parameter Pull Up Constructor Body
Change Bidirectional Association to Unidirectional Pull Up Field
Change Reference to Value Pull Up Method
Change Unidirectional Association to Bidirectional Push Down Field
Change Value to Reference Push Down Method
Collapse Hierarchy Reduce Scope of Variable by Mats Henricson
Consolidate Conditional Expression Refactor Architecture by Tiers (Link Only)
Consolidate Duplicate Conditional Fragments Remove Assignments to Parameters
Convert Dynamic to Static Construction by Gerard M. Davison Remove Control Flag
Convert Static to Dynamic Construction by Gerard M. Davison Remove Double Negative by Ashley Frieze and Martin Fowler
Decompose Conditional Remove Middle Man
Duplicate Observed Data Remove Parameter
Eliminate Inter-Entity Bean Communication (Link Only) Remove Setting Method
Encapsulate Collection Rename Method
Encapsulate Downcast Replace Array with Object
Encapsulate Field Replace Assignment with Initialization by Mats Henricson
Extract Class Replace Conditional with Polymorphism
Extract Interface Replace Conditional with Visitor by Ivan Mitrovic
Extract Method Replace Constructor with Factory Method

bad smell Extract Package by Gerard M. Davison
Extract Subclass
Extract Superclass
Replace Data Value with Object
Replace Delegation with Inheritance
Replace Error Code with Exception
Form Template Method Replace Exception with Test
Hide Delegate Replace Inheritance with Delegation
Hide Method Replace Iteration with Recursion by Dave Whipp
Hide presentation tier-specific details from the business tier (Link Replace Magic Number with Symbolic Constant
Only) Replace Method with Method Object
Inline Class Replace Nested Conditional with Guard Clauses
Inline Method Replace Parameter with Explicit Methods
Inline Temp Replace Parameter with Method
Introduce A Controller (Link Only) Replace Record with Data Class
Introduce Assertion Replace Recursion with Iteration by Ivan Mitrovic
Introduce Business Delegate (Link Only) Replace Static Variable with Parameter by Marian Vittek
Introduce Explaining Variable Replace Subclass with Fields
Introduce Foreign Method Replace Temp with Query
Introduce Local Extension Replace Type Code with Class
Introduce Null Object Replace Type Code with State/Strategy
Introduce Parameter Object Replace Type Code with Subclasses
Introduce Synchronizer Token (Link Only) Reverse Conditional by Bill Murphy and Martin Fowler
Localize Disparate Logic (Link Only) Self Encapsulate Field
Merge Session Beans (Link Only) Separate Data Access Code (Link Only)
Move Business Logic to Session (Link Only) Separate Query from Modifier
Move Class by Gerard M. Davison Split Loop by Martin Fowler
Move Field Split Temporary Variable
Move Method Substitute Algorithm
Parameterize Method Use a Connection Pool (Link Only)
Wrap entities with session (Link Only)


very simple example

title

titleText
titleX
titleY
titleColour

bad smell: data clump

refactoring: extract class

class Customer extends DomainObject
{
public Customer(String name) {
_name = name;
}
public String statement() {
double totalAmount = 0;
int frequentRenterPoints = 0;
Enumeration rentals = _rentals.element s();
String result = "Rental Record for " + name() + "n" ;
while (rentals.hasMoreElements()) {
double thisAmount = 0;
Rental each = (Rental) rentals.nex tElement();

//determine amounts for each line
switch (each.tape().movie().priceC ode()) {
case Movie.REGULA R:
thisAmount += 2;
if (each.daysRented() > 2)
thisAmoun t += (each.da ysRented() - 2 ) * 1.5;
break;
case Movie.NEW_RE LEASE:
thisAmount += each.daysRen ted() * 3;
break;
case Movie.CHILDR ENS:

Fowler’s video shop
thisAmount += 1.5;
if (each.daysRented() > 3)
thisAmoun t += (each.da ysRented() - 3 ) * 1.5;
break;

}
totalAmount += thisAmount; example
// add frequent renter points
frequentRenterPoints ++;
// add bonus for a two day new rel ease rental
if ((each.tape().movie().priceCode() == Movie.NEW_RELEASE) && each.daysRented()
> 1) frequentRenterPoints ++;

//show figures for this rental
result += "t" + each.ta pe().movie() .name()+ "t" + String .valueOf(thisA mount) +
"n"; refactor: replace condition with polymorphism
}
//add footer lines
Movie Price
result += "Amount owed is " + String. valueOf(totalA mount) + "n ";
1
result += "You earned " + String.valueOf(fre quentRenterPo ints) + " frequent renter
points";
return result;
charge() charge()
}
public void addRental(Rental arg) {
_ren tals.addEleme nt(arg);
}
public static Customer get(St ring name) {
<<code>> rn (Customer) Registrar.ge t("Customers" , name);
retu ChildrensPrice 1 RegularPrice 1 NewRelease 1
return priceCode.charge()
} Price
public void persist() {
Regi strar.add("Cu stomers", thi s); charge() charge()
} charge()
private Vector _rentals = new Vector();

common refactorings

• push down method - behaviour on a super class is relevant only for some of
its subclasses’ - the method is moved to those subclasses
• extract subclass - ‘a class has features that are used only in some instances’
- a subclass is created for that subset of features
• encapsulate field - the declaration of a field is changed from public to
private
• hide method - ‘a method is not used by any other class’ (the method should
be made private)
• pull up field - ‘two subclasses have the same field’ - the field in question
should be moved to the super class
• extract super class – ‘two classes with similar features’ - in this case, create
a super class and move the common features to the super class


common refactorings

• push down field - a field is used only by some subclasses’ - the field is
moved to those subclasses
• pull up method - methods with identical results in subclasses’ - methods
should be moved to the super class
• move method - a method is, or will be, using or used by more features of
another class than the class on which it is defined’
• move field - a field is, or will be, used by another class more than the class
on which it is defined’
• rename method - a method is renamed to make its purpose more obvious.
• rename field - field is renamed to make its purpose more obvious


refactoring principles

• make changes small and methodical
• follow design patterns
• have your test suites ready
• refactoring introduces new bugs
• sometimes in unrelated parts of the
programme
• run test suites each time you refactor
• clean before you add new functionality


two dubious refactoring practices

refactoring the architecture
refactoring: ‘extract package’, ‘refactor architecture by tiers’

• large scale decisions about the organisation of the program taken too late in
the construction because of insufficient overview
• liable to cause chaos unless extremely well thought out

the refactoring sprint(s)

• some weeks in the life of the project, paid for by the customer, where the
only purpose is to rectify relatively serious design problems caused by lack of
real understanding of the user domain and too early commitment to
programming


traditional view of refactoring

• refactoring reflects poor analysis and design
work – do it right first time
• refactoring is expensive – all prior
documentation must be altered
• refactoring introduces new errors in
unpredictable places
• refactoring threatens architectural integrity
• customers expect new functionality and will
not pay for rework
• refactoring does not extend value – if it ain’t
broke don’t fix it



participative design:
contextual design – Beyer + Holtzblatt

overview

• a system design method designed • problem analysis tools
and used by software consultants • solution design strategies
• focused on users’ work
• small learning curve
• empirically-based
analysis tools
• participative (Scandinavian
tradition) • design/re-design of
• simple analysis and design systems: work,
techniques information,
• designing user environments communication, computer
• simple prototyping strategy

problem analysis: work oriented

five analysis models:
• (information) flow
• sequence
• (information) artifacts
• culture
• physical workspace

flow model

actors
- task, responsibility

artifact

information flow

sequence

intent:
trigger:

task, step
sequence,
order

breakdown

information artifact model

•information, data

•distinct parts

•structure

•annotations, informal
use

•presentation

•usage

•breakdown

culture

influencer

influence
direction

extent and nature of
influence

roles, norms, values

contextual design

• vision
• storyboard
• work redesign
• user environment design
• paper prototype

vision

• a diagrammatic
representation of the
new way of working
and communicating
when the new systems
and services are
implemented
• can include; users,
other actors,
information flows,
screens, databases and
other things as required

storyboard
• a sequential depiction
of the use of the new
system and services,
divided into its
principle stages
• can include; users,
other actors,
information flows,
screens, databases and
other things as
required

work design (modified use case)

the major actors (user,
citizen, role)
work
process their interaction with
role system
function the major functions
work
process
system role
in the system
function the work process
behind the
work
process role system
function interactions
work
process
system
function
work
process

user environment
design
• a graphical representation
of the major focus areas of
the system, usually divided
by function
• functions: what the user can
do in the system
• overview: information
displayed on screen
• links: connections to other
places in the system
• objects: principle work
”objects” which may later
be coded

paper
prototype

• drawing of a screen
• shows divisions of screen, menu items, data entry
possibilities, buttons, scroll bars, links, pictures,
graphics, computer visualizations (or any thing else that
a user can see in a system)


agile or traditional?

a development approach

traditional agile
• process model linear, iterative iterative
• associated tools, analysis and design stand-up meeting, pair
techniques, practices techniques, case tool, programming, time-
• characteristics etc boxing, etc
• a set of (unspoken)
assumptions about the
nature of software
development and its
contexts

SOE: traditional v. agile 2

a project situation
• development project circumstances,
factors, conditions
• size (FP, LOC, developers, project length, no. of
developers)
• complexity
• environmental dynamism
• technology platform
• software type
• developer organization history
• team members’ work style
• customer organization history
traditional
• user domain complexity agile
• user profile and accessibility
• contracting and delivery needs
• maintenance expectations
development
• .......... approach

development approach characteristics:
ceremony and cycles (Larman)

waterfall strict (no iteration)

few steps, few formal steps,
documents many documents

SCRUM
ceremony
XP UP
many short iterations

cycles

soe: agile or traditional 4

project characteristics: uncertainty


project characteristics: complexity


project situation: complexity, uncertainty

high

uncertainty

low

low high
complexity


project situations: complexity and uncertainty

8
From: Little
SOE: traditional v. agile

commonly used development approaches
traditional development evolutionary development prototyping
(waterfall) • iteratively • quick initial working model
• single pass, sequential • expanding increments • cycle: partial requirements
Analysis Design

of operational product gathering with (some)
• progresses through stakeholders - quick design –
requirements analysis, • evolution determined prototyping – evaluation
design, coding, testing, by operational Implemen-
integration experience • full-scale model and
Evaluation tation
functional form – but only on
• document-based • development begun on part of the system
criteria between stages the most visible aspect
• I’ll Know It When I See It
(IKIWISI)
incremental development spiral model agile development
• all requirements and • risk-driven variation of • iterative
preliminary evolutionary
architectural design development • adaptive process
determined up front • can function as a • light-weight
• separate increments superset process • intensive communication
addressing subsets of model between developers and
requirements • risk-based transition customer
criteria between stages • programming focus
• XP, SCRUM …


development approaches in one dimension
(Boehm and Turner)

agile
methods

prototyping Unified
Process
code and fix spiral model waterfall

evolutionary
adaptive
undisciplined predictive
linear
disciplined
(agile) (traditional – plan-driven)

10


agile v. traditional (plan-driven) differences

• application
• project goals, size, environment; velocity
• management
• customer relations, planning and control, communications
• technical
• how the software is developed
• personnel
• the type and competency of developers and stakeholders

From: Boehm & Turner

agile vs. traditional characteristics

characteristics agile traditional (plan-driven)
application
primary goals rapid value; responding to change predictability, stability, high assurance

size smaller teams and projects larger teams and projects

environment turbulent; high change; project-focused stable; low-change; project/organization
focused
management
customer dedicated on-site customers, where as-needed customer interactions; focused
relations feasible; focused on prioritized on contract provisions; increasingly
increments evolutionary
planning/control internalized plans; qualitative control documented plans, quantitative control

communications tacit interpersonal knowledge explicit documented knowledge

12


characteristics agile traditional (plan-driven)
technical
requirements prioritized informal stories and test formalized project, capability, interface,
cases; undergoing unforeseeable quality, foreseeable evolution requirements
change
development simple design; short increments; architect for parallel development; longer
refactoring assumed inexpensive increments; refactoring assumed expensive
test executable test cases define documented test plans and procedures
requirements
personnel
customers dedicated, collocated crack* crack* performers, not always collocated
performers
developers at least 30% full-time Cockburn level 50% Cockburn level 3s early; 10%
2 and 3 experts; no level 1b or -1 throughout; 30% level 1b’s workable; no
personnel** level -1s**
culture comfort and empowerment via many comfort and empowerment via framework
degrees of freedom (thriving on of policies and procedures (thriving on
chaos) order)
* collaborative, representative, authorized, committed, knowledgeable
** these numbers will particularly vary with the complexity of the application 13


sweet spots

From: Boehm
14


Boehm: critical factors
Factor Agility discriminators Plan-driven discriminators

Well matched to small products and teams; Methods evolved to handle large products and
Size
reliance on tacit knowledge limits scalability. teams; hard to tailor down to small projects.

Untested on safety-critical products; potential Methods evolved to handle highly critical products;
Criticality difficulties with simple design and lack of hard to tailor down efficiently to low-criticality
documentation. products.
Simple design and continuous refactoring are
Detailed plans and “big design up front” excellent
excellent for highly dynamic environments, but
Dynamism for highly stable environment, but a source of
present a source of potentially expensive rework
expensive rework for highly dynamic environments.
for highly stable environments.
Need a critical mass of scarce Cockburn Level 2
Require continuous presence of a critical mass of and 3 experts during project definition, but can
Personnel scarce Cockburn Level 2 or 3 experts; risky to work with fewer later in the project—unless the
use nonagile Level 1B people. environment is highly dynamic. Can usually
accommodate some Level 1B people.

Thrive in a culture where people feel comfortable Thrive in a culture where people feel comfortable
Culture and empowered by having many degrees of and empowered by having their roles defined by
freedom; thrive on chaos. clear policies and procedures; thrive on order.

polar chart of factors


development approach assumptions
assumption
make (internal) locus of effort (external) buy
linear process model cyclical (iterative)
rational analytical approach experimental
specification expression form prototype
all at once delivery incremental
expert-driven user involvement user-driven
process developer focus product
delivery developer-customer relationship co-operation
predictive uncertainty management adaptive
all lifecycle phases completeness chosen lifecycle phases
experienced developer maturity naive


NERUR, S., MAHAPATRA, R. K. & MANGALARAJ, G. (2005) Challenges of
migrating to agile methodologies. Communications of the ACM, 48, 72-78.


broader assumptions

traditional agile
the world (user stable and governed by rules changing and governed by
domain) is .......... (natural science) relationships between people
(social science)
development is application of an externally stepwise refinement of a local
the .............. imposed algorithm (the design design solution
method)
a complex rational analysis informed trial and
problem is solved error/experiment
by ...................
knowledge formal and documented informal by direct
exchange is .......... communication
.............................


the normative ideals v. software development in
practice

• normative ideal – designers of development approach direct
engineers’ actions
• in practice – engineers make informed decisions about their
practice

• in theory - traditional and agile methods incompatible
• in practice – much overlap

• now its up to you 


SOE

scope
project management and planning

estimating and scheduling control estimate

manage
schedule
risk

the economics of software

the prime objective of a software firm = make software
the prime objective of a software firm = make money
project cost = fixed costs + developer person days
project income = actual revenue – actual project cost
expected revenue = estimated project cost + desired profit margin
actual project cost = estimated project cost – all overspend
current project value = code value to date – all other costs

conclusion: in order to make money the project must be correctly
estimated and scheduled, and managed without significant overspend

SOE: project management 2

reminder: the project management problem

• nearly two thirds of project significantly overrun their cost
estimates (Lederer and Prasad 1992)
• the average project exceeds its schedule by 100% (Standish
2001)

• good project management is a question of business survival
• many software firms have as their primary goal: deliver on
time


the project start

• what will we get?
scope
• what will it cost?
(features,
customer
• when will it be finished? functionality)

• the prime PM objectives:
schedule resources
1. make money
(cost,
2. keep the customer happy (time) budget)
3. deliver on time
4. build good quality software
5. keep the team happy

the purpose of planning

• reduce uncertainty
• ensure efficient resource
use
• monitor progress uncertainty
• establish confidence and
trust
• allocate roles and tasks
• support future decision
making
• ensure the project earns
money
• improve future planning time
• generate and communicate
overview of project the planning horizon

the plan and its execution
adaptive planning

traditional
adaptation

agile

prediction

predictive planning

the tasks • scope - understand the
problem and the work that
must be done
scope • estimate - how much effort?
how much time?
• manage risk - what can go
wrong? how can we avoid it?
control estimate what can we do about it?
• schedule - how do we allocate
resources along the timeline?
what are the milestones?

manage
• control - how do we control
schedule quality? how do we control
risk change? how do we manage
developments in schedule
and estimate and unforeseen
risks

predictive planning scope

(traditional)
control estimate

manage
schedule
risk


software scoping scope

• functionality decomposition control estimate

• data and processing demands
• interfaces and reports
• performance, security and reliability constraints schedule
manage
risk

• understand the customers’ needs
• understand the business context
• understand the project boundaries
• understand the customer’s motivation
• understand the likely paths for change

• feasibility report
• 2 part contracting
• preliminary requirements analysis
• the more information, the more accurate the estimation
• scoping and contract documentation


estimation scope

control estimate

• the intelligent anticipation of the amount of
work that needs to be performed and the
resources needed to perform it schedule
manage
risk

• software size (LOC, function or object points)
• development
• effort (person days, hours, months)
• cost
• time
• for example:
• how big is the software
• how much effort is needed for this much software?
• what will that much effort cost and how long will it take?

software size metrics scope

• Lines Of Code control estimate

• Function Points
n.......user inputs schedule
manage
risk
n.......user outputs
n.......user inquiries function point to lines of code:
n.......files
ada 95 49
n.......external outputs assembly 320
• adjust for weighting and ‘complexity c 128
c++ 55
adjustment values’, empirically derived
fortran 95 71
constants java 53
• Feature Points (where algorithmic pascal 91
visual basic 5.0 29
complexity is high) ………………
• Object Points Jones: ”Applied Software Measurement ..”
Mcgraw-Hill 1996

scope
baseline metrics:
control estimate

• local historical – collected from a series of
projects manage

• researcher produced – collected from analysis
schedule
risk

of many projects
• constants
• adjustment factors

SOE: scheduling and estimating 12

estimation strategies scope

control estimate

• process-based estimation
• use case based estimation manage

algorithmic (empirical) cost modelling
schedule
• risk

• expert judgement
• estimation by analogy
• Parkinson’s law
• pricing to win

• error margins can be large: use two methods


scope

process-based decomposition
and estimation control estimate

Risk manage
Activity CC Planning Engineering Release Totals schedule
analysis risk

Function Anal. Design Code Test

a 0.75 2.50 0.40 5.00 8.65

b 0.50 4.00 0.60 2.00 7.10

c 0.50 4.00 1.00 3.00 8.50

d 0.50 3.00 1.00 1.50 6.00

e 0.25 2.00 0.75 1.50 4.50

f 0.50 2.00 0.50 2.00 5.00

Totals .25 .25 .25 3.00 17.50 4.25 15.00 34.80

% effort 1% 1% 1% 7% 45% 12% 40%


use case based estimation scope

control estimate

• highly structured use cases divided into scenarios
manage
schedule
risk

LOC = N × LOCavg + [(Sa/Sh - 1) + (Pa/Ph - 1)] × LOCadjust

N = actual number of use-cases
LOCavg = historical average LOC per use-case for this type of system
Sa = actual scenarios per use-case
Sh = average scenarios per use-case for this type of system
Pa = actual pages per use-case
Ph = average pages per use-case for this type of system
LOCadjust = represents an adjustment based on n percent of LOC where n is defined
locally and represents the difference between this project and “average” projects


algorithmic (empirical) modelling scope

control estimate

• empirically derived constants from research-
oriented historical baseline data manage

• example structure: E = A + B x (ev)
c schedule
risk

• E = effort
• ev = estimation value (e.g. FP)
• A,B,C are empirically derived constants
• various research-based models in the
literature with considerable outcome variation


COCOMO 2
Boehm et al: ”Software Cost Estimation with Cocomo II” Prentice Hall 2000


expert estimation scope

control estimate

• variations of Delphi technique
• combine and improve the estimation estimates manage

of several experienced estimators
schedule
risk


estimation by analogy scope

control estimate

similar past
project schedule
manage
risk

similar past similar past
project project

• similarities
size
current • differences

project project team
• similarities
• differences
programming • similarities
technologies • differences
.......................
.........................


estimation & politics: scope

control estimate

• competitive bidding produces (unrealistically)
low estimates manage

• estimation is not an exact science
schedule
risk

• a professional will not conform to wishful
thinking
• managers are entitled to an early estimate
• your challenge is to make them understand
uncertainty


scheduling scope

control estimate

• decide who does what and when
• a good schedule: schedule
manage
risk

describes an effective process - succeed
describes an efficient process - fast and cheap
describes a realistic process - estimate
respects stakeholders’ interests - motivate
enables partition of labour - coordinate
enables measurement of progress - control
can be communicated - simplicity


top-down + bottom up scope

control estimate

• situation • resource
allocation schedule
manage
risk

• strategy
• resources

• process model
• task
• phases & decomposition
deliverables


phases, deliverables, milestones scope

control estimate

manage
schedule
risk


hierarchical task decomposition scope

control estimate

requirements
r1 schedule
manage
risk

r2
r3
r3.1 Task definition: Task I.1 Concept Scoping
I.1.1 Identify need, benefits and potential customers;

r3.2 Begin Task I.1.2
I.1.2 Define desired output/control and input events that drive the application;

analysis I.1.2.1 FTR: Review written description of need9
I.1.2.2 Derive a list of customer visible outputs/inputs

a1 case of: mechanics
mechanics = quality function deployment

a2 meet with customer to isolate major concept requirements;
interview end-users;

design observe current approach to problem, current process;
review past requests and complaints;

d1

dependencies scope

control estimate

identify tasks and dependencies, estimate

e.g. from a design (work breakdown structure) schedule
manage
risk

• design a
• code & test a S
• design b
• code & test b
• integrate & test s
A B it S

dA ct A dB ct B


tasks, durations, dependencies scope

control estimate
activity duration (days) dependencies
T1 8
T2 15 schedule
manage
risk
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)

task network with milestones, durations scope

control estimate

manage
schedule
risk


gant chart scope

control estimate

manage
schedule
risk


task assignment scope

control estimate

manage
schedule
risk


program evaluation and review technique scope

(PERT) control estimate

manage
schedule
risk

tasks, calendar days, dependencies, milestones

critical path method (CPM)

• the critical path is the longest path through a network (defines the
minimum project completion time)
• slack is the amount of time an activity can be delayed without
delaying the project


controlling projects scope

control estimate

manage
schedule
risk

• check (monitor):
• resource use (developer
hours)
• schedule (overrun)
• progress (deliverables)
• act
• enforce or modify plan


the project manager’s dilemma scope

control estimate

scope manage
schedule
risk
(features,
functionality)

• decrease scope (risk contract
breech)
• alter schedule (risk late delivery
schedule resources
and contract breech)
(cost,
(time) budget) • increase resources (risk making a
loss or having to go to the
customer for more money)


project management tool support


adaptive planning scope

(agile)
control estimate

manage
schedule
risk


an adaptive plan (Larman)
scope

control estimate

manage
schedule
risk

scope

control estimate

manage
schedule
risk


two contract phase plan
scope


estimate
• planning poker (a simplified version
of Delphi techniques
• story points (a simplified application
of the FP idea)
• velocity: story points per iteration
• estimation improves as velocity
becomes known
• ideal days
• shared estimation generates
commitment


schedule

• prioritize user stories for:
• customer functionality
• business value
• risk
• must-haves, exciter-delighters
user • feature benefit v. cost of absence
• story decomposition
story • release planning (stories, points velocity)
• iteration planning (iteration length, activities)
• buffering


control
• story self-selection generates commitment
• burndown chart
• velocity monitoring
• time-boxing


primary control locus scope
requirements
specification

scope
(features, schedule resources
functionality)

scope

schedule resources time-boxed
(cost,
(time) budget)

schedule resources


comparison

planning assumptions traditional agile
style predictive adaptive
team managed self-organizing
team manager leader facilitator
expression detailed plans instrumental sketches
driving force professional responsibility commitment
management focus complexity uncertainty
fixed point scope schedule
techniques analytical, quantitative simple, pragmatic


“Prediction is very difficult –
especially about the future” “To be uncertain is to be
uncomfortable, but to be
Niels Bohr certain is ridiculous”

“Planning is everything. Plans Chinese proverb
are nothing”

“No plan survives contact
with the enemy” “You improvise, you adapt,
you overcome”
Field Marshal Helmuth Graf
von Moltke Clint Eastwood


project managers’ competence priorities at WM Data

Take tough decisions with little information and without being sure of the consequences
Work to reduce uncertainty, for example through risk management
Focus on the uncertainties and act as the leader in these areas

Build a relationship
Develop understanding and trust uncertainty management
Handle differences professionally
Educate the customer
customer management
Compensate for contracting
Record agreements
Understand strategic goals business management
Estimate realistically
Quickly build a functioning team
Compensate for poor communication
team management
Manage team stress
Handle crises and rebellion process management

core competences
technical competences


SOE

managing change in system development projects:
configuration management

understanding the problem of change

• change is one of the most fundamental characteristics in any
software development process (Leon 2000) – it is intrinsic and
must be accepted as a fact of life (Lehman 1980)
• changing software is very easy, but if it is done at will, results
in chaos (Leon 2000)
• effective projects control changes, whereas ineffective
projects allow changes to control them (McConnell 1998)
• the level and formality of control should vary according to
project conditions (Whitgift 1991)

SOE: configuration management 3

sources of change

• requirements change through misunderstanding, better
customer understanding or situational change (= requirements
churn)
• analysis clarification with improving developer understanding
• design improvements, evolutionary design changes, code
improvement, refactoring
• bug fixes during test
• improvements and new functionality after release
• version, variant and implementation change
• component and code reuse


change sources: system evolution

system variants mobile server
Windows
XP
initial PC desktop
system Linux

SUN ...

alpha beta
bug + issue fixes 1.0 1.1 1.3
version evolution new functionality 2.0 2.1 2.3


SAP to 2006


change sources: system evolution

implementation 1

implementation 2
implementation 1
..........
implementation 2
implementation n
.......... SAP r7.0
SAP r6.20 implementation n

standard system


example: a simple requirements specification

(but late) change design specification

request test plan

system documentation

user manual

the customer change
requests a new request
field on a screen presentation code

model code

database

reports

test scripts and cases

XML

component and system interfaces


a simple (but late) change request

the customer
change
requests a new request
field on a screen

document
-ation
change
test system system
unit test debug
rewrite build test

recode


change problems

• change inherent in the life of the system
• many developers working concurrently on many (hundreds or
thousands of) documents and files
• probability of introduction of further errors and
communication problems
• system must be built and tested, preferably early
• many possible combinations of version, implementation and
variant releases


software configuration management (SCM)
“the purpose of Software Configuration Management is to establish and maintain the
integrity of the products of the software project throughout the project's software life
cycle. Software Configuration Management involves identifying configuration items for
the software project, controlling these configuration items and changes to them, and
recording and reporting status and change activity for these configuration items.” SEI
2000a


some simple CM scenarios

• developer A wants to see latest version of foo.c and its change history
since last week
• B needs to revert foo-design.doc to its version two days ago
• B makes a release of the project and he needs to know what items to
include and which version
• A lives in New Dehli, India and B lives in Boston, US - they want to work
on HelloW.java together
• in the latest release, a serious bug is found and manager C wants to track
what changes caused the bug, who made those changes and when
• an innocent-looking change 2 days before release causes major test
problems – the whole design is rolled back to its state before the change
• C wants to get reports about current project progress to decide if she
needs to hire more programmers and delay the alpha release

a set of practices:
supported by tools:
- change control
- configuration database
- version control
- source code repository
- release management
- build tools


SCM terminology

• configuration item – any development output for which change control is
considered necessary
• baseline – a collection of configuration item(s) which is reviewed and
approved, and thus under change control – often a project milestone
• revision – a change to a baseline
• configuration – a particular assembly of configuration items (such as all the
source code files for release 3.0)
• version – a configuration adding repair or new functionality
• variant – a configuration with similar functionality on a different platform
• release – a version or variant distributed to users

CM activities
• identification
• identifying the items to be managed, establishing
naming conventions (e.g. PCL-
tools/edit/forms/display/AST-interface/code),
storage and access
identification control • control
• change evaluation
• change coordination
• change approval
status
accounting audit • change implementation
• status accounting
• tracking of status of configuration items
• audit
• verifying that a configuration conforms to its
specification

CM practice example


change request form
change
Change Request Form
control board
Project: Proteus/PCL-Tools Number: 23/02
Change requester: I. Sommerville Date: 1/12/02 (CCB) review
Requested change:When a component is selected from the structure, display
the name of the file where it is stored.
Change analyser: G. Dean Analysis date: 10/12/02
Components affected: Display-Icon.Select, Display-Icon.Display
change
Associated components: FileTable
implementation:
Change assessment: Relatively simple to implement as a file name table is
available. Requires the design and implementation of a display field. No changes code,
to associated components are required.
documentation
Change priority: Low
Change implementation:
Estimated effort: 0.5 days
Date to CCB: 15/12/02 CCB decision date: 1/2/03 baseline update
CCB decision: Accept change. Change to be implemented in Release 2.1.
Change implementor: Date of change:
Date submitted to QA: QA decision:
Date submitted to CM:
Comments
verification, audit


managing collaborative working: version
control, revision control

• solutions:
• pessimistic: file locking
• optimistic: version merging


version control: terminology

• checkout – creates local working copy of file
• change (diff, delta) – modification to a file under version control
• commit – write or merge changes to repository
• merge – 2 or more sets of changes applied to repository file
• delta compression – retains the only the differences between successive
versions of files
• trunk – mainline development stream
• branch – an alternative development stream
• tag/label – point in time snapshot of group of files


version management tools

• version and release identification
• system assigns identifiers automatically when a new version is submitted to
the system
• storage management
• system stores the differences between versions rather than all the version
code
• change history recording
• record reasons for version creation
• independent development
• parallel working on different versions
• project support
• can manage groups of files associated with a project rather than just single
files


trunk and branch, forward and
reverse integration


example version control tool: Subversion


system building

version
s ystem management c ompilers l inker
builder system

s ource code o bject code e xecutable
b uild component
script components system
versions

• compiling and linking software components into an executable system
• different systems built from different combinations of components
• invariably supported by automated tools driven by ‘build scripts’

system building tools

• building a large system is
computationally expensive and may comp

take several hours
• hundreds of files may be involved
system building tools may provide: scan.o syn.o sem.o cgen.o
•
• a dependency specification language
and interpreter
scan.c syn.c sem.c cgen.c
• tool selection and instantiation
support
• distributed compilation
• derived object management defs.h

Example: SCons

release management
• release: not just a set of executable programs, may also include:
• configuration files defining how the release is configured for a particular
installation;
• data files needed for system operation;
• an installation program or shell script to install the system on target
hardware;
• electronic and paper documentation;
• packaging and associated publicity
• release creation involves collecting all files and documentation required to
create a system release
• configuration descriptions for different hardware and installation scripts
• the release must be documented to record exactly what files were used
to create it - this allows it to be re-created if necessary


many varieties of integrated tool support

Rational ClearCase Rational BuildForge


traditional configuration management
• configuration management is the management of system change to
software products
• a formal document naming scheme should be established and documents
should be managed in a database
• the configuration data base should record information about changes and
change requests
• a consistent scheme of version identification should be established using
version numbers, attributes or change sets
• system releases include executable code, data, configuration files and
documentation
• system building involves assembling components into a system
• case tools are available to support all CM activities
• case tools may be stand-alone tools or may be integrated systems which
integrate support for version management, system building and change
management


Agile CM automated release
daily build environment

test scripts
version continuous
control integration

code

sandbox


traditional and agile configuration management
traditional agile
focus documents and code code
activities CM practice, change version control,
management, version automated build
control, automated build
responsible CM team, CM board programmers
process formal, managed informal and integrated
with practice
environment
outcome CM audit (documented next release
product control)
importance indispensible in medium indispensible
and large projects


managing SE practice across the software organisation:

- software metrics
- Capability Maturity Model Integrated (CMMI)
- Software Process Improvement (SPI)

the problem – the SE answer
• the requirements problem
• the analysis problem • development project success rates in
• the design problem the US: 29%
• the quality problem • by budget
• the project management problem • <$750,000: success = 55%
>$10,000,000 success = 0%
• the change problem •
• England (public sector) 84% partial or
• the complexity problem total failure
• estimated overall: 20-30% projects are
total failures (abandoned)
• ”failure of large and complex
information system developments is
software engineering largely unavoidable”

traditional agile

SOE: metrics and SPI 2

SE improvement styles
internal: own experience

qualitative:
description and quantitative:
experience- metrics-based
based

external: professional norms, research


improving software engineering practice

• how do you improve your
metrics:
establishing a practice in software
knowledge
baseline engineering? not as an
individual, not as a team, but
as a company?

CMMI: orienting
SE practice after SPI: improving SE
professional practice
norms



Software Metrics

definitions

• measure - quantitative indication of extent, amount, dimension, capacity, or
size of some attribute of a product or process.
• e.g., number of errors
• metric - quantitative measure of degree to which a system, component or
process possesses a given attribute
• e.g., number of errors found per person hours expended
• indicator - group of metrics pointing towards a desirable end
• e.g. product quality
• a defined and commonly understood language
• defect
• error
• failure
• fault (bug)

motivation for metrics

• estimate the cost & schedule of future projects
• evaluate the productivity impacts of new tools and techniques
• establish productivity trends over time
• improve software quality
• forecast future staffing needs
• anticipate and reduce future maintenance needs
• ………………………
• ………………………………

example metrics

• bug and analysis design code test maintain
defect rates
• measured by
individual,
module,
project
• defect
removal process project
efficiency

product

size-oriented metrics

• measures
• LOC - Lines Of Code
• KLOC - 1000 Lines Of Code
• SLOC – Statement Lines of Code (ignore whitespace)
• FP
• OP
• typical metrics:
• Errors/KLOC, Defects/KLOC, Cost/LOC, Documentation
Pages/KLOC

program complexity metrics
• example - cyclomatic complexity – defines
the set of independent paths through a 1
programme
• V(G) = E – N + 2 2
• E is the number of flow graph edges
• N is the number of nodes
• V(G) is the number of (enclosed) 3
regions/areas of the planar graph
• a quantitative measure of testing difficulty 7 4 5
and an indication of ultimate reliability
• experimental data shows value of V(G)
should be no more then 10 - testing is very
6
difficulty above this value control flow graph:
sequence, selection, repetition

design metrics

• structural complexity • example: structural
• data complexity complexity S(i) of a module
• system complexity i.
• coupling • S(i) = fout2(i)
• fan out is the number of
modules immediately
subordinate (directly invoked).

object-oriented metrics

• weighted methods per class
• depth of inheritance tree
• number of children
• coupling between classes
• response for a class
• lack of cohesion in methods (LCOM)
• class size
• number of operations overridden
• method inheritance factor
• coupling factor
• polymorphism factor

software quality and metrics

product

operation revision transition

reliability efficiency usability maintainability testability portability reusability

metrics

a measurement data baseline – so what?

• reduce the time to implement change requests
goal

• how long do change requests take, what factors
question delay implementation?

• tqueue, Weval, teval, Wchange, tchange, Echange,
metric Dchange


Motorola’s metric programme

• goal 1: improve project
planning • adherence to schedule • goal 1: improve project
• goal 2: increase defect • delivered defects and planning
containment delivered defects per size • question 1.1: what was
• goal 3: increase software • total effectiveness the accuracy of estimating
reliability throughout the process the actual value of project
• goal 4: decrease • accuracy of estimates schedule?
software defect density • number of open customer • metric 1.1: schedule
goal 5: improve estimation accuracy (SEA)
• problems
customer service • time that problems remain •
• goal 6: reduce the cost open
of nonconformance • cost of nonconformance
• goal 7: increase software • software reliability
productivity


independent metrics consultancy

Users
Y. User Satisfaction

analysis
A. Development B. Production

A1 Study A5 Installation B1 Application Processing & Quality

A2 Analysis A6 User Documentation B2 User Support B3 Repair

A3 Design A7 Project Management B4 Upgrade B5 Technical Enhancement bench-marking
Quality Assurance etc.

ALL APPLICATIONS ALL ENVIRONMENTS
A4 Implementation & Test
D. Management & Administration

D1 Management & Administration
ALL PROJECTS ALL ENVIRONMENTS

C. Development Services E. Customer Services reporting
C1 Development C2 Standards C3 Quality E1 Contracting & Consulting
C4 Training
Tools & Technologies & Methods Assurance


metrics: formal baseline of knowledge
establishing a
knowledge of software engineering
baseline practice in place

CMMI: orienting
SPI: improving SE practice after
SE practice professional
norms


professional norms

• professional norms:
• embody professional knowledge
• facilitate exchange of experience through standard nomenclature
• increase predictability in processes and results
• facilitate evaluation and certification of professionals
• are maintained by international or national authorities or by professional
organisations


CMMI: a norm for software processes

• Capability Maturity Model Integration

• initiated by the US Dept. of Defense, late 1980’s
• Watts Humphrey, Software Engineering Institute, Carnegie-Mellon University

• purpose 1: qualification - identify reliable software suppliers
• purpose 2: road map to increased professionalism in software organisations

• key document (573 pages):
http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html

• other norms: ISO quality standards, project management standards
(IPMA)…


process maturity levels


example: requirements management
Purpose
The purpose of Requirements
Management (REQM) is to manage the Typical Work Products
1. Requirements status
requirements of the project’s products
2. Requirements database
and product components and to identify 3. Requirements decision database
inconsistencies between those
requirements and the project’s plans Subpractices
and work products. 1. Document all requirements and requirements
changes that are given to or generated by the
Specific Goal and Practice Summary project.
2. Maintain the requirements change history with the
SG 1 Manage Requirements
rationale for the changes. Maintaining the
SP 1.1 Obtain an Understanding of change history helps track requirements
Requirements volatility.
SP 1.2 Obtain Commitment to Requirements 3. Evaluate the impact of requirement changes from
SP 1.3 Manage Requirements Changes the standpoint of relevant stakeholders.
SP 1.4 Maintain Bidirectional Traceability of 4. Make the requirements and change data available
Requirements to the project.
SP 1.5 Identify Inconsistencies Between
Project Work and Requirements


statistical process control:
– the level five software organisation

• software processes
documented and
institutionalized
quantitatively measured,
benchmarked and
statistically evaluated
continually improved and
re-evaluated


assumption description
process orientation What is important about a software organisation is the way the work is organised (a
process). Good (mature) software organisations have defined and repeatable processes
which govern the way that they work (their capability) and lead to success.
hierarchical management: planning, Management has the responsibility for process standardization, learning and
monitoring, control improvement. Software developers should execute the organization’s processes
according to the standardized models and descriptions.
externally imposed generic process Software processes leading to effective software development are well understood and
models share generic features which can be externally documented. These generic process
models are suitable for implementation in all software organisations.
documentation, standardization and Good software organizations not only have standardized and documented processes,
institutionalization but those processes are institutionalized; that is, carried out throughout the
organization. Software projects are therefore conducted in a similar fashion according
to pre-defined process models

organizational progression to Software organisation improvement is understood as the movement from immaturity
maturity (undefined processes) to maturity (standardized and institutionalized processes) through
a series of management led change initiatives.
objective measurement, external The extent of process standardization and institutionalization can be measured, and the
verification and certification measurements used to achieve 1) better standardization 2) enforcement of processes,
3) process learning leading to process improvement. Measurement represents objective
knowledge about software processes, and maturity can be externally certified

goal-directed change through Organizational learning is achieved by the rational analysis and optimization of processes
rational analysis and learning which sets the goals for organizational development and change
management-sponsored Software process improvement initiatives follow the principles outlined above: defined
improvement initiative and documented externally imposed process, management –led, focused on maturity,
objectively measured, analysis-oriented. Thus the CMMI model is an extensive,
externally imposed process plan

Capability
Immaturity Model

0 : Negligent
lip service only to implementing software engineering processes. CMM
level 0 organizations generally fail to produce any product, or do so by
abandoning regular procedures in favor of crash programs.

-1 : Obstructive
Processes, however inappropriate and ineffective, are implemented with rigor and tend to
obstruct work - adherence to process is the only measure of success. Any actual creation of
viable product is incidental - quality of the product is not assessed

-2 : Contemptuous
While processes exist, they are routinely ignored by engineering staff and those charged with overseeing the
processes are regarded with hostility. Measurements are fudged to make the organization look good.

-3 : Undermining
Not content with faking their own performance, undermining departments routinely work to downplay and sabotage the efforts of rival teams,
especially those successfully implementing processes common to CMM level 2 and higher. This is worst where company policy causes 28
departments to compete for scarce resources, which are allocated to the loudest advocates.

SOE: metrics and SPI

establishing a

CMMI: orienting software organisation
SPI: improving SE practice after has institutionalized SE
SE practice professional processes that match
norms professional norms


software engineeering

Software Process Improvement (SPI)

SPI: Software Process Improvement

• generic name for initiatives to improve software development and
management in a software company
• the movement towards good software engineering practice - as
experienced and as industry good practice (norm)

assessment education selection installation
and gap and and and
analysis training justification migration


IDEAL


traditional SPI:
- the CMMI project
Learn by
measuring
results

Act to
Initiate CMMI project improve
process
control

Establish
Diagnose
CMMI
current
team and
maturity
process
level
areas


establishing a

software organisation
has organized
improvement initiatives

CMMI: orienting software organisation
SPI: improving SE practice after has institutionalized SE
SE practice professional processes that match
norms professional norms


the Scandinavian approach – a critique of
traditional CMMI

1. focus on problems – not on a specific solution (e.g. CMMI level 2)

2. emphasize knowledge creation – not knowledge deployment

3. encourage participation – not expert solution

4. integrate leadership – do not rely on staff work

5. plan for continuous improvement – a portfolio, not a project

(Mathiassen et al., 2002)


Industry Knowledge model Network model
Model (CMMI) (Agile)
Underlying metaphor Factory Learning organization Community
Focus/orientation Process Knowledge Software challenge
Management style Hierarchical management: Facilitation and team Self-organisation in
planning, monitoring, learning networks
control
Guiding principle Generic process models Experiential learning Technical mastery
Organizational form Machine bureaucracy Professionalised Virtually enabled
knowledge work community
Motivation for Market pressure Individual self-motivation Self-realisation in the
improvement through professionalism technological meritocracy
Improvement focus Internal efficiency, Customer satisfaction, Software solution
software quality market accommodation
Improvement strategy Goal-directed change Continuous learning, Code sharing, peer
through rational analysis knowledge sharing, feedback, development
of process knowledge, individual and collective and sharing of
process documentation, competence development programming skills and
standardization and techniques
institutionalization
Improvement objective Process maturity, Adaptation to market Technology leadership
organizational discipline
Improvement assessment Objective measurement, Responsiveness to Code quality, intellectual
method external verification and market, improved sales, property rights
certification of process profitability
adherence
Improvement champions Top managers Project managers Programmers 36

control
adherence

SPI manifesto (agile)


`
internal: own experience

metrics programmes
Scandinavian SPI
qualitative:
description and quantitative:
experience- metrics-based
based

traditional SPI(CMMI)

external: professional norms, research


Metrics for the Object Oriented

Chidamber & Kemerer ’94 TSE 20(6)

Metrics specifically designed to address object oriented software

Class oriented metrics

Direct measures

Weighted Methods per Class

n

WMC = c
i 1
i

ci is the complexity (e.g., volume, cyclomatic complexity, etc.) of each method
Viewpoints: (of Chidamber and Kemerer)
-The number of methods and complexity of methods is an indicator of how much time and
effort is required to develop and maintain the object
-The larger the number of methods in an object, the greater the potential impact on the
children
-Objects with large number of methods are likely to be more application specific, limiting
the possible reuse

Depth of Inheritance Tree

DIT is the maximum length from a node to the root (base class)

Viewpoints:
Lower level subclasses inherit a number of methods making
behavior harder to predict
Deeper trees indicate greater design complexity

Number of Children
NOC is the number of subclasses immediately
subordinate to a class
Viewpoints:
As NOC grows, reuse increases - but the abstraction may be diluted
Depth is generally better than breadth in class hierarchy, since it promotes reuse
of methods through inheritance
Classes higher up in the hierarchy should have more sub-classes then those lower
down
NOC gives an idea of the potential influence a class has on the design: classes
with large number of children may require more testing

Coupling between Classes
CBO is the number of collaborations between two classes (fan-
out of a class C)
• the number of other classes that are referenced in the class
C (a reference to another class, A, is an reference to a
method or a data member of class A)
Viewpoints:
As collaboration increases reuse decreases
High fan-outs represent class coupling to other classes/objects and thus are
undesirable
High fan-ins represent good object designs and high level of reuse
Not possible to maintain high fan-in and low fan outs across the entire system

Response for a Class

RFC is the number of methods that could be called in
response to a message to a class (local + remote)

Viewpoints:
As RFC increases
testing effort increases
greater the complexity of the object
harder it is to understand

Lack of Cohesion in Methods

LCOM – poorly described in Pressman

Class Ck with n methods M1,…Mn

Ij is the set of instance variables used by Mj

LCOM

There are n such sets I1 ,…, In
• P = {(Ii, Ij) | (Ii  Ij ) = }
• Q = {(Ii, Ij) | (Ii  Ij )  }
If all n sets Ii are  then P = 

LCOM = |P| - |Q|, if |P| > |Q|
LCOM = 0 otherwise

Example LCOM

Take class C with M1, M2, M3
I1 = {a, b, c, d, e}
I2 = {a, b, e}
I3 = {x, y, z}
P = {(I1, I3), (I2, I3)}
Q = {(I1, I2)}

Thus LCOM = 1

Explanation

LCOM is the number of empty intersections minus the
number of non-empty intersections
This is a notion of degree of similarity of methods
If two methods use common instance variables then
they are similar
LCOM of zero is not maximally cohesive
|P| = |Q| or |P| < |Q|

Class Size

CS
• Total number of operations (inherited, private, public)
• Number of attributes (inherited, private, public)

May be an indication of too much responsibility for a class

Number of Operations
Overridden
NOO

A large number for NOO indicates possible problems with the
design
Poor abstraction in inheritance hierarchy

Number of Operations Added

NOA

The number of operations added by a subclass
As operations are added it is farther away from super class
As depth increases NOA should decrease

Method Inheritance Factor
n

 M (C )
i 1
i i

MIF = n
.
 M a (Ci )
i 1
Mi(Ci) is the number of methods inherited and not overridden in
Ci
Ma(Ci) is the number of methods that can be invoked with Ci
Md(Ci) is the number of methods declared in Ci

MIF

Ma(Ci) = Md(Ci) + Mi(Ci)
All that can be invoked = new or overloaded + things inherited

MIF is [0,1]
MIF near 1 means little specialization
MIF near 0 means large change

Coupling Factor

 is _ client (C , C )
i j i j

CF= (TC 2  TC ) .
is_client(x,y) = 1 if a relationship exists between the
client class and the server class. 0 otherwise
(TC2-TC) is the total number of relationships possible
CF is [0,1] with 1 meaning high coupling

Polymorphism Factor
M
i
(Ci )o

PF =  M (C )  DC (C ).
i n i i

Mn() is the number of new methods
Mo() is the number of overriding methods
DC() number of descendent classes of a base class
The number of methods that redefines inherited methods, divided by
maximum number of possible distinct polymorphic situations


course summary

course objectives

• to understand the difference between traditional and agile
approaches to system development
• to understand the primary software engineering tools and
techniques and how and when to apply them
• to develop the capacity to use these understandings in
your own practice

• overview course – not learn this technique and learn how
to apply it in the exercises

SOE: course summary 2

course design

agile

development tools,
approaches techniques, SPI
practices

traditional
miniproject 1: miniproject 2: miniproject 3:
DA TTP evaluation


the problem – the SE answer
• the requirements problem
• the analysis problem • development project success rates in
• the design problem the US: 29%
• the quality problem • by budget
• the project management problem • <$750,000: success = 55%
>$10,000,000 success = 0%
• the change problem •
• England (public sector) 84% partial or
• the complexity problem total failure
• estimated overall: 20-30% projects are
total failures (abandoned)
• ”failure of large and complex
information system developments is
software engineering largely unavoidable”

traditional agile


one answer:

• apply engineering principles to software development

“(1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.
(2) The study of approaches as in (1).”


no – two answers

software
engineering

traditional agile


traditional agile
the requirements problem requirements management, on-site customer, user stories,
requirements engineering, iteration, test driven
change control development
the analysis problem formal analysis techniques dialogue with customer
the design problem top down formal design evolutionary design
the quality problem formal test strategies, quality test-driven design, continuous
programmes, SPI + CMMI, integration
metrics
the project management estimation, scheduling, iteration, planning poker,
problem predictive planning, project velocity
control, change management,
risk management
the change problem configuration management, iteration, version control,
risk management continuous integration
the complexity problem anticipate and plan experiment and adapt


literature

agile viewpoint

deepening articles –
thematically organised

(traditional viewpoint)


literature
compulsory reading:
Craig Larman: Agile Iterative Development: A Manager's Guide, Addison-Wesley , chapters 1-9 (buy this one)
Boehm, B. & Turner, R. (2003) Observations on balancing discipline and agility. Agile Development Conference (ADC '03), Salt Lake
City, Utah
Gray, M. M. (1999) Applicability of Metrology of Information Technology. Journal of Research - National Institute of Standards and
Technology, 104(6), 567-578.
Heemstra, F. (1992) Software cost estimation. Information and Software Technology, 34(10), 627-639.
Nerur, S., Mahapatra, R. K. & Mangalaraj, G. (2005) Challenges of migrating to agile methodologies. Communications of the ACM,
48(5), 72-78.
Nuseibeh, B. & Easterbrook, S. (2000) Requirements engineering: a roadmap. In: ICSE '00: Proceedings of the Conference on The
Future of Software Engineering, 35-46. ACM.
Parnas, D. & Clements, P. (1985) A rational design process: How and why to fake it. Formal Methods and Software Development, 80-
100.
Poppendieck, M. B. & Poppendieck, T. D. (2010) A Rational Design Process–It’s Time to Stop Faking It.
Schuh, P. (2008) Agile Configuration management for large organizations. In: The Rational Edge, IBM.
Talby, D., Hazzan, O., Dubinsky, Y. & Keren, A. (2006) Agile software testing in a large-scale project. IEEE SOFTWARE, 30-37.
Tiwana, A. & Keil, M. (2004) The one-minute risk assessment tool. Communications of the ACM, 47(11), 73-77.
Whittaker, J. A. (2000) What is software testing? And why is it so hard? Software, IEEE, 17(1), 70-79.

supplementary reading:
Pressman, R.S. Software Engineering: A Practitioner's Approach European Adaption (Paperback) fifth edition, Parts 1-3. Use this to
deepen your understanding of traditional topics where you find it necessary (you can find it online). You can also use
another edition (there are several) but be careful you read the corresponding chapters. The chapter numbering systems can
be quite different.


course content: mindmap


course content by ten revision topics

comparison of iterative and agile methods: UP, SCRUM, XP
traditional and agile development approaches: similarities and differences
requirements: traditional and agile
analysis and design: traditional and agile
test: traditional and agile
risk analysis: traditional (and agile)
project management, scheduling and estimation: traditional and agile
top down and bottom up design: refactoring and design patterns
configuration management: traditional and agile
metrics and software process improvement: traditional and agile


comparison of iterative and agile methods: UP, SCRUM, XP
Phases
Process Workflows Inception Elaboration Construction Transition

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

Iterations within phases

• work products, roles, practices
• UP – iterative not necessarily agile
• SCRUM – team management
• XP – programmer orientation


traditional and agile development approaches:
similarities and differences
• T or A development approach
• T or A software engineering


requirements: traditional and agile on-site customer,
product owner

user stories,
product backlog

iteration, sprint

requirements
specification: an agreed,
mutually understood and test
relatively stable account cases
of what to build


analysis and design: traditional and agile

use domain CRC cards

requirements
specification continuous
metaphor design
improvement
high level
design

refactoring


test: traditional and agile
• XP: test-driven development

test
automation
test
cases

iteration, sprint

acceptance continuous
testing integration


risk analysis: traditional (and agile)

risk analysis change risk
response = iteration
risk risk
identification prioritisation

one minute risk management
risk risk
management mitigation

risk
monitoring

SOE: course summary
? 17

project management, scheduling and estimation:
traditional and agile
two contract phase
plan
predictive
planning
adaptive iteration
and release planning
technique-
corrective based planning
control estimation velocity poker
monitoring
time-boxing

story points
ideal days
burndown
formal chart
predictive
scheduling risk
analysis


top down and
bottom up design: architecture
refactoring and
design patterns traditional
architectural
patterns
agile

GRASP

design
refactoring
patterns

detailed design


configuration management: traditional and agile

identification control

status
accounting audit


metrics and software process improvement:
traditional and agile


perspectives
• with standard shortcomings
• traditional SE - a • limits creativity and developer
standard response to initiative
difficult problems • distributes responsibility
• discipline and rational • expensive and goal-displacing
analysis • standard one-size-fits-all
• quantitative and scientific solutions which are hard to
• rules, routines and adapt to changing conditions
procedures • creates many products with
• documentation and no direct value
bureaucracy • complexity analysis limited by
• hierarchy and control human understanding

• agile – a serious
• taken to extremes - flight
response to the
from things that
shortcomings of
developers find unpleasant
traditional SE
• discipline, standardization,
• minimal bureaucracy and
documentation
hierarchy
• authority
• focus on software
production and quality • serious investigation of
customer domain
• improvement through
experimentation replaces • non-coding tasks
rational analysis • delivery deadlines
• developers regain • contractual responsibilities
control and responsibility

• exploit freedom and • find the discipline in
flexibility in traditional agility and use traditional
SE and scale to task tools where appropriate


Software Engineering course

More Related Content

What's hot (18)

Viewers also liked (20)

Similar to Software Engineering course (20)

Recently uploaded (20)

Software Engineering course