Paolo Ciancarini

Architecture-centric processes

Agenda

  The role of sw architecture in the development process

  What is a software development process and how it is described

  Traditional vs iterative process models   Characteristics and benefits of

architecture-centric sw development   Agile Processes and Architecture

The role of architecture in sw lifecycle

Short History of Development Methods

WATERFALL (Royce) Requirements, design implementation, verification & maintenance

1960 85 91 1980 1970

V-MODEL (Anon) Aligns testing to Waterfall development

SPIRAL MODEL (Barry Boehm) Iterative

RAD (James Martin) Prototyping, iterative, time-boxed, user driven

RUP (Rational) Object oriented, iterative, time-boxed, user driven

AGILE e.g. XP (Kent Beck) Incremental, user driven, low process

98 99

Waterfall V-Model

Spiral Model

RAD

RUP

Traditional process

  Waterfall

Requirements

Design

Code

Test

Review

Review

Review

Deploy

Review

Waterfall characteristics   Delays confirmation of

critical risk resolution   Measures progress by

assessing work-products that are poor predictors of time-to-completion

  Delays and aggregates integration and testing

  Precludes early deployment

  Frequently results in major unplanned iterations

Code and unit test

Design

Subsystem integration

System test

Waterfall Process Requirements

analysis

V Model Level of Detail

Project Time

Low

High

Acceptance Testing

Requirements Elicitation

Analysis

Design

System Testing

Object Design Unit Testing

Integration Testing

The spiral model Determine objectives,alternatives, & constraints

Evaluate alternatives,identify & resolve risks

Develop & verifynext level productPlan next phase

Requirements

Development

Integration

plan

plan

plan

Requirements

Design

validation

validation

Software SystemProduct

Riskanalysis

Riskanalysis

Prototype1Prototype2

Prototype3

Riskanalysis

Concept ofoperation

RequirementsDesign

Code

Unit Test

Integration & TestAcceptance

DetailedDesign

P1

P2

Test

The spiral model: phases

  Determine objectives   Each phase has specific objectives

  Evaluate alternatives, reduce risks   Each risk has to be identified and managed

  Develop and verify   The process model can be generic   Each phase includes development and verification

  Plan next phase   Review the project and plan its future

Exercise

  Name the pros and cons of each of the following software process models   waterfall model   v-model   spiral model

  Specifically focus on their ability to solicit and react to customer requirement approval and changes

Iterative Development

Initial Planning

Planning

Requirements

Analysis & Design

Implementation

Deployment

Test

Evaluation

Management Environment

Each iteration results in an

executable release

Iterative process

  Iterative Requirements

Design

Code

Testing

Assess

Requirements

Design

Code

Testing

Assess

Requirements

Design

Code

Testing

Assess

Iteration 1 Iteration 2 Iteration 3

Deploy Deploy Deploy

Waterfall vs. iterative

Requirements

Design

Code

Test

Review

Review

Review

Deploy

Review

Requirements

Design

Code

Testing

Assess

Requirements

Design

Code

Testing

Assess

Requirements

Design

Code

Testing

Assess

Iteration 1 Iteration 2 Iteration 3

Deploy Deploy Deploy

Iterative Development

  Phase - the time between two major project milestones, during which a well-defined set of objectives is met, artifacts are completed, and decisions are made to move or not into the next phase. A phase includes one or more iterations.

  Iteration – a time period in which a number of predefined tasks are performed and results are evaluated to feedback to the next iteration. An iteration results in a release.

  Release (external) – a coherent set of completed functionalities (code and other artifacts) that is useful to the stakeholders of the system

  Release (internal) - a coherent set of completed functionalities that is used only by the development organization, as part of a milestone, or for a demonstration to users

Risk Reduction

Time

Ris

k

Waterfall Risk

Iterative Risk

Risk: waterfall vs iterative

UML Model and

Implementation

Tests

Iteration 1

Test Suite 1

Iteration 2

Test Suite 2

Iteration 4

Test Suite 4

Iteration 3

Test Suite 3

Test each iteration

Original RUP

RUP is iterative

http://www-306.ibm.com/software/rational/sw-library/

Discussion

Evaluate the pros and cons of iterative processes

Benefits of Iterative Development

A software project evolves in iterations to:   Mitigate risk   Accommodate change   Learn along the way   Improve the quality of the artifacts   Exploit reuse thus increasing productivity

Problems with iterative processes

  How iterative? How many rounds?   Agile or rigid?   Heavy weight (many rules, practices

and documents) vs. lightweight (few rules and practices)

  Disciplined vs ad hoc (or chaotic)

A story A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved."#

Committed vs involved

  The core roles in development teams are those committed to the project in the process - they are the ones producing the product: product owner, team, project manager

  The ancillary roles in teams are those with no formal role and infrequent involvement in the process - and must nonetheless be taken into account

The Planning Spectrum

Source: B. Boehm “Get Ready For Agile Methods, With Care”, IEEE Computer, Jan 2002

Agile developments methods

Some agile sw development methods   Dynamic System Development Methodology and

RAD (www.dsdm.org, 1995)   Scrum (Sutherland and Schwaber, 1995)   XP - eXtreme Programming (Beck, 1999)   Feature Driven Development (DeLuca, 1999)   Adaptive Sw Development (Highsmith, 2000)   Lean Development (Poppendieck, 2003)   Crystal Clear (Cockburn, 2004)   Agile Unified Process (Ambler, 2005)

Agile ethics

  www.agilemanifesto.org

  Management can tend to prefer the things on the right over the things on the left

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation

Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on

the right, we prefer the items on the left.

Traditional vs agile team

Agile development

  Agile development uses feedback to make constant adjustments in a highly collaborative environment

  There are many agile development methods; most minimize risk by developing software in short amounts of time#

  Software developed during one unit of time is referred to as an iteration, which typically lasts from hours or few days#

  Each iteration passes through a full software development cycle

Agile development: architecture-centric

The Generic Agile Lifecycle

Agile practices

Agile Unified Process

Architectural Effort During the Lifecycle

time

Inception Elaboration Construction Transition

Majority of architectural design activities

Little dedicated architectural effort

time

Inception Construction Transition

Minimal pure Architectural

Activities

Ideal realm of agile practices

An architectural iteration focuses on major architectural elements, resulting in a baseline architectural prototype at the end of elaboration

Preliminary Iteration

Architect. Iteration

Architect. Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

Transition Iteration

Transition Iteration

Inception Elaboration Construction Transition

Internal Releases with focus on architecture

Iterations and Phases

Releases with main focus on features

Working Software Delivered

Requirements Prioritised Requirements & Features “Backlog” Requirements

Requirements Requirements

Requirements

Prioritised Iteration Scope

Daily Scrum Meeting: 15 minutes Each teams member answers 3 questions: 1) What did I do since last meeting? 2) What obstacles are in my way? 3) What will I do before next meeting?

Team-Level Planning Every 24hrs

Every Iteration 4-6 weeks

Applying Agile: Continuous integration; continuously monitored progress

SCRUM

Agile: eXtreme Programming The ethic values of eXtreme Programming   Communication   Simplicity   Feedback   Courage   Respect (added in the latest version)

eXtreme Programming (XP)   “Extreme Programming is a discipline of software

development based on values of simplicity, communication, feedback, and courage”

  Proponents of XP and agile methodologies regard ongoing changes to requirements as a natural and desirable aspect of sw projects

  They believe that adaptability to changing requirements at any point during the lifecycle is a better approach than attempting to define all requiremenmts at the beginning and then expending effort to control changes to the requirements

! ! !www.extremeprogramming.org!

Kent Beck

The 12 Practices of XP

1.  Metaphor 2.  Release Planning 3.  Testing 4.  Pair Programming 5.  Refactoring 6.  Simple Design 7.  Collective Code

Ownership 8.  Continuous Integration 9.  On-site Customer 10.  Small Releases 11.  40-Hour Work Week 12.  Coding Standards

Metaphor

  Programmers define a handful of classes and patterns that shape the core business problem and solution, like a primitive architecture

  Gives the team a consistent picture of describing the system, where new parts fit, etc.

  Example: payroll . . . The paycheck goes down an assembly line and pieces of information are added

  Sometimes, you just can’t come up with a metaphor

Exercise

  Find other useful metaphors

Release Planning • Requirements via User Stories • Short (index-card length) natural language

description of what a customer wants • A commitment for further conversation

• Prioritized by customer • Resource and risk estimated by developers

•  “The Planning Game” • Highest priority, highest risk user stories

included in early “time boxed” increments •  Play the Planning Game after each

increment

User stories: examples

Good:   A user can post her cv   A user can search for jobs   A company can post new job openings   A user can limit who can see her resume Bad:   The software will be written in C++   The program will connect to the database

through a connection pool

User story: example

User story testing: example

Testing

  Test-Driven Development (TDD)   Write tests before code   Tests are automated   Often use xUnit

framework   Must run at 100% before

proceeding

  Acceptance Tests   Written with the

customer   Act as “contract”   Measure of progress

Pair Programming • Two software engineers work on

one task at one computer

• One engineer, the driver, has control of the keyboard and mouse and creates the implementation

• The other engineer, the navigator, watches the driver’s implementation to identify defects and participates in on-demand brainstorming

• The roles of driver and observer are periodically rotated between the two software engineers

Simple Design •  No Big Design Up Front (BDUF) •  “Do The Simplest Thing That Could Possibly

Work” •  Including documentation

•  “You Aren’t Gonna Need It” (YAGNI) •  CRC cards (optional)

Refactoring  Refactoring: as you write code, there are

times when you need to change its structure - usually to conform to a pattern, to facilitate extensibility, or just because your code got long and messy

 Improve the design of existing code without changing functionality   Simplify code, remove duplicate code   Search actively all opportunity for abstraction

 Relies on testing to ensure nothing breaks in the process of refactoring

Collective Code Ownership

  Code to belongs to the project, not to an individual engineer

  As engineers develop required functionality, they may browse into and modify any class

Continuous Integration

  Each pair writes up its own unit test cases and code for a task (part of a user story)

  Pair tests units of code to 100%   Pair integrates   Pair runs ALL integrated unit test cases to

100%   Pair moves on to next task with clean slate and

clear mind   Should happen once or twice a day; prevents

“Integration Hell”

On-Site Customer   Customer available on site to clarify

stories and to make critical business decisions

  Developers don’t make assumptions   Developers don’t have to wait for

decisions   Face to face communication minimizes

the chances of misunderstanding

Small Releases

•  Timeboxed •  As small as possible, but still delivering

business value •  No releases to ‘implement the database’

•  Get customer feedback early and often Do the planning game after each iteration •  Do they want something different? •  Have their priorities changed?

40h work per week (sustainable pace)

•  Kent Beck says, “ . . . fresh and eager every morning, and tired and satisfied every night”

•  Burning the midnight oil kills performance •  Tired programmers write poor code and make

more mistakes, which slows you down more in the long run

•  If you mess with people’s personal lives (by taking it over), in the long run the project will pay the consequences

Coding standards and conventions

  Use Coding Conventions   Considering Pair Programming, Refactor Mercilessly,

and Collective Code Ownership . . . need to easily find your way around (other people’s) code

  Method Commenting   Priority placed on intention-revealing code

  If your code needs a comment to explain it, rewrite it   If you can't explain your code with a comment, rewrite it

The 13th Practice: The Stand Up Meeting

Start day with 15-minute meeting •  Everyone stands up (so the meeting stays

short) in circle •  Going around the room everyone says

specifically: •  What they did the day before •  What they plan to do today •  Any obstacles they are experiencing

•  Can be the way pairs are formed

Research findings on XP   Strong anecdotal evidence from industry

  “We can produce near defect-free code in less than half the time.”

  Empirical Study   Pairs produced higher quality code

  15% more test cases passed (difference statistically significant)   Pairs completed their tasks in about half the time

  58% of elapsed time (difference not statistically significant)

  Most programmers reluctantly embark on pair programming

  Pairs enjoy their work more (92%)   Pairs feel more confident in their work products (96%)

Agile Misconceptions

  Agile means: “letting the programming team do whatever they need to with no project management, and no architecture, allowing a solution to emerge, the programmers will do all the testing necessary with Unit Tests…”

Process control variables

  Time – duration of the project   Quality – the requirements for ‘correctness’   Resources – personnel, equipment, etc.   Scope – what is to be done; the features to

be implemented

  These process control variables are very difficult to control all; the simplest and most effective to control is scope

Self-test questions

  What are the advantages of an iterative process?

  What is an agile process?   Which are the potential problems and

risks with user involvement?   What is the planning game?   What is a user story?   What are the major best practices in XP?

References

  Ambler, Agile Modern Driven Development with UML2 (The Object Primer 3ed.), Cambridge Univ. Press, 2004

  Beck and Fowler, Planning Extreme Programming, Addison Wesley, 2000

  Cockburn, Agile Software Development, 2000   Larman, Agile and Iterative Development: a

managers’ guide, Addison Wesley, 2003   Schwaber, Agile Project Management with Scrum,

Microsoft Press, 2004   Shore and Warden, The Art of Agile Development,

O’Reilly, 2007

Useful sites

  www.agilemanifesto.org!  www.agilemodeling.com!  www.agilejournal.com!  www.agilealliance.org!  www.agilekiwi.com!  www.extremeprogramming.org!  www.controlchaos.com!  www.implementingscrum.com!

Questions?