Software Development Process Models - shortened · 2013-05-29 · Software Development Process Models From classical notions to more agile approaches. 29/09/06 Torsten Hahmann Models

Torsten Hahmann

[email protected], BA8134

Software Development Process Models

From classical notions to more agile approaches

29/09/06Torsten Hahmann

Models of Software DevelopmentCSC444H, Fall 2006 – Software Engineering

2

“Code & Fix” or “Cowboy Coding”

1) Write program2) Test and fix program

Problems:• program users not satisfied with program:

definition phase (requirements & analysis)• fixing programs requires extensive program

redesign: design phase• ill-prepared tests: test phase

+ implementation phase



3

What defines a development process?

• Who does what at what time?• tasks

• starting condition• documents (artefacts) received• output from previous stage

• end conditions: finish criteria• final documents produced• input for next stage

• order of tasks • who is involved

• qualification• responsibility



4

Development process models

• Static process models• Waterfall model• V-Model

• Incremental process model

• Modern approaches• Iterative/Incremental process model• eXtreme Programming• Prototypic development• Test-driven development



5

Waterfall model

Software specification

Design document



6

Software specification I

• 1. Goal• MUST• MAY• MUST NOT

• 2. Use of the product• Purpose• Target Group• Environment

Software requirements

Analysis



7

Example: Use Case diagram

inform

cancel

settle up

<<actor>>Pegasus

ehotelclerk

book by phone

bookonline

cancelat Hotel

book

Hotelclerk

cancelonline

(ehotel)

cancel by phone

(ehotel)

ehotelhotel reservation system

Customer book byfax/email

cancel by fax/email (ehotel)



8

Software specification II

• 3. Functionality• Can do a time estimate per „feature“• Can track progress

• 4. Data (persistent)• 5. Performance• 6. User Interface• 7. Non-functional requirements & qualities

Not too much details:

-No implementation details (algorithms, data structure)

-No technical solution (database, language, infrastructure)

Software requirements

Analysis



9

V-model

Requirements

Moduletest

Coding (Modules)

Design

Analysis

Integration test

Systemtest

Acceptancetest

Test cases

Test cases

Test cases

Use-case scenarios

Verification

Validation



10

Classical process models in a nutshell

• problems of classical process models:• successive steps• document-driven• limited customers/users involvement• changing requirements in real world

• pros:• customer gets a defined process (feasibility study) at

the beginning of a project• can be good for large project-based developments

• cons:• hard to think of all requirements at the beginning• documentation seems more important than program



11

Scope

• Project-based: contract between customer and contractor• clearly-defined overall goal• requirements: system functionality• non-functional requirements & qualities• e.g. large-scale software, e.g. logistics, industry, etc.

• Commercial-of-the-shelf (COTS) product• constantly improving/changing releases• e.g. end-customer software (office, etc.)

• Open-goal projects• e.g. academic research, prototypes, demos



12

Incremental process model

Initial definition

complete software specification

Designversion X

X=0

partial architecture

Code & testversion X

Product version X

new ideas & wishes

Useversion X

changes

changes

Define extended functionalitymodefied model

X=X+1

changes



13

Agile development processes

• Practices for every-day development required• focus on small and medium-sized software projects

(small teams)• progressing, not spending too much time on design and

specifications that might be useless

• Agility• adaptable instead of predictable

• “light-weight methodology”

• minimizing risk by short-term focus (1-8 weeks)• being able to release a product after each cycle



14

„Agile Manifesto“

• Individuals and interactions over processes and tools• close, daily cooperation (possibly face-to-face)• self-organizing teams• trust in motivated individuals

• Working software over comprehensive documentation• Working software is the principle measure of progress• Simplicity

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

see http://www.agilemanifesto.org/



15

Development process models

• Static process models• Waterfall model• V-Model

• Incremental process models

• Modern approaches (Agile)• eXtreme Programming• Prototypic development• Test-driven development



16

eXtreme Programming (XP)

• Communication• questions instead of assumptions• „coach“ helps to overcome communication issues

• Simplicity• try not to think of every eventuality in future• just implement what is really necessary• refactoring after iterations

• Feedback• everybody gives and receives feedback• everybody is a little bit happier ☺

• Courage• try and compare alternative designs• no problem to throw away code



17

Planning in XP

• Plan by priorities (feature, defect tracking)

• Plan for the next iteration

• Take responsibility, do not delegate it

• Use techniques like “story cards”



18

Methods of XP

• Pair programming• Best form of communication• Coding and Thinking• „Two pairs of eyes see more“

• Testing• No feature without test• Independent, automated tests

• Extensive refactoring after each iteration• Strict coding conventions



19

Software Prototypes

• Software prototype different from „Productprototype“

• Help to elicit requirements• Paper prototypes (GUI)• Fake GUI

• Basis for discussion

• Experimental: can try & show alternatives

• Practical experience & feasibility



20

Categories of prototypes

• Demonstration• for project acquisition

• Explorative prototype• for analysis

• Experimental prototype• evaluate design alternatives• show technical feasibility

• Pilote system (evolutionary)• e.g. selected customer



21

Horizontal vs. vertical prototype

vertical prototype

horizontal prototype



22

Explorative Prototyping

• Paper• Usability Engineering• try to find a good user interface design with prospective

users• use: paper, post-it notes, colors• one developer: „plays“ software• one developer: takes notes

• Software• fake GUI (Visual Basic, C#)• discuss it with customers

• what do they expect will happen• what do they miss



23

Test-driven development (TDD)

• Principle 1: Test-First-Development (TFD)• For each feature:

• write test first (including automation)• code afterwards

• Principle 2: Refactoring• try to remove duplicate code• essential for keeping code simple• improve code quality• make it maintainable



24

Test-driven development

If it's worth building, it's worth testing.If it's not worth testing, why are you wasting your time working on it?



25

Test-driven development (TDD)

• Advantages of TFD• immediate checking gives more confidence• can write several tests at the beginning of each release

cycle• give a good overview of remaining effort

• forces developers to write tests

• But requires: Refactoring• otherwise software becomes unmaintainable

TDD = TFD + Refactoring



26

When using agile methods?

• Previously just „Code & Fix“• A little bit more order, planning• Easier step than introduction of classical model

• Small- & Medium-sized teams• About a dozen developers• Approaches

• Volatile requirements• Motivated developers• Customers wish to be integrated



27

Classical vs. agile processes

• Classical processes (anticipating)• Disciplined, detailed plan• Emphasis on long-term planning

Focus: processPlan-driven

• Agile processes (adaptive)• Compromise between no and too much process• Short-term focus• Less documentation, code is documentation

Focus: humansAgile

Documents

Software Development Process Models - shortened · 2013-05-29 · Software Development Process Models From classical notions to more agile approaches. 29/09/06 Torsten Hahmann Models