INF5180: Software Product- and Process Improvement in Systems Development

Part 07: Processes and Process Modeling Dr. Dietmar Pfahl

Spring 2008

INF5180 – Spring 2008 Part 07: Processes and Process Modeling What is a (Software Development) Process? A Process … • defines Who is doing What, When and How to reach a certain goal. – In software engineering the goal is to build a software product or to enhance an existing one An Effective Process … • provides guidelines for efficient development of quality software • reduces risk and increases predictability • promotes common vision and culture

(source: Rombach) Process Performance ≈ f (Process, Goals, Context)

can be determined by Product Availability and -empirical study (measurement) and Quality of Resources Project can be estimated by related Familiarity with - simulation Process and Application Domain

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

A Process Taxonomy Software Processes [Rombach & Verlage, 1995] Engineering Processes Non-Engineering Processes

Product-Engineering Process-Engineering Business Social Processes Processes Processes Processes

Technical Managerial Improvement Processes Processes Processes

Development Development Modeling and Processes Processes (Re-)Planning Processes

Life-Cycles Measurement Processes

Reuse Processes

Page 4 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling What is a (Software) Process Model? • “Software Process Model: An abstract software process description. It can be more or less formal.” [Lonchamp 93] • Key elements:

INF5180 – Spring 2008 Part 07: Processes and Process Modeling The Role Concept • Role – A role is in charge of one or more activities defined in one or more processes – A role has defined responsibilities – Possible relationships between agents and roles 1 : 1 1 : m n : 1 n : m Page 6 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Role Responsibilities RASCI Matrix R = Responsible Roles A = Approve S = Support Tester Quality assurer Moderator

Activities Module developer Tester Quality assurer Moderator Module developer Module R C = Consult development I = Inform Module R coding Module S A review S, R Module Module R testing I

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Characterization of Process Models

A Process Model defines:

27.Integration Test (Host) • an identifiable activity or a group of Customer Data Tools activities

APS TSPA (from P3) 30.Customer Data Upgrade Test Protocol / Tool-Upgrade • a hierarchy of activities Specification • the control flow between activities Customer Data

28.Integration Test (Target) Data Delta • the input/output products of activities Conformance Test Cases Regression Test Cases • the product flow • the relations between activities and techniques, methods, tools, and roles

Page 8 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling What are the Goals of Process Modeling? • To enable effective understanding and • To support project management communication – Transparency, tracking, ... – At one development site (developers, teams, • To guide the developers ...) – Incorporating new employees – Between development sites (distributed development, outsourcing, contractor-supplier • To support reuse of process relations, ...) knowledge • To improve software development activities • To support automatic process – Improving real processes requires enactment measurement and measurement requires – Workflow support defined processes – CASE tools – Evolving processes

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Descriptive vs. Prescriptive Process Models

27.Integration Test (Host) How is it done? Customer Data Tools

APS TSPA (from P3) 30.Customer Data Upgrade Test Protocol / Tool-Upgrade Specification

Customer Data

28.Integration Test (Target) Data Delta How should it be done?

Conformance Test Cases Regression Test Cases

Page 10 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Prescriptive vs. Descriptive Process Models • Prescriptive Models (theoretical) • Descriptive Models (empirical) – “Ideal” Process – Accurate elicitation of actual, – (Assumed) best practice real processes – Often requires instantiation and – Basis for the revision of existing detailing (prescriptive) process models – Deviations from real processes based on observation and are likely experience – Examples: waterfall, V-model, spiral model, incremental, iterative, evolutionary, agile process models

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Relationship between Descriptive & Prescriptive Process Modeling

Process enactment Real world

Model world Descriptive Prescriptive process modeling process modeling

Description of the Process Description of observed process analysis constraints and guidelines for the process enactment

Descriptive Process Modeling

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Goals of Descriptive Process Modeling • Understand the process • Support measurement – Explicit documentation – Describe, who can measure – Analyses (consistency, what and when completeness, complexity) – Collect quantitative information about processes, products and • Communicate (about) the resources process • Manage the process (and – Find agreement in case of conflicting opinions products) – Propagation of ‘Best Practices’ – Define goals (target values) and control the adherence to these goals.

Page 14 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Steps of Descriptive Process Modeling 1. Formulate goals and scope of the task 2. Choose a conceptual schema (meta-model) 3. Choose a process modeling language / notation 4. Select or adapt tools 5. “Elicitation” 6. Create process model 7. Analyze process model 8. Analyze process

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Process Elicitation • Structured interview, 1-2 Hours

Role 1 Role n • 2 interviewers • Separated by roles – no large groups – clear focus – manageable process models – no mutual interaction (horizontal and vertical hierarchic relations) Information Information • Perform interviews one after another, however not more than 3 interviews per day

Scope Project, process name, role Project

Activity Name Integration-Test (Target) Responsibility PL

Input Products Entry Criteria -TSPA - Possibly Integration Test (Host) Input products and - Customer Data (by Customer Data Delta) -Input complete -APS - Hardware available - Conformance Test Cases - APS and Customer Data loaded - Regression Test Cases - Test time available entry conditions

Activity Description - Conduct Integration Test on target according to TSPA Case A: Old Features (upgrade): - Regression Test (Tool: A8619 (PORIS) for SSW / USR for ASW) - Possibly, update of TSPA Test Cases Case B: New Features: - Manually conducted TSPA Test Cases Description of the process/activity - Recorded with A8619 (Poris) for SSW / USR for ASW - Conduct Conformance Test according to Standards with test tool K1197 - Defect correction

Output Products Exit Criteria - Test Protocol (Part of TSPA) - Feature runs correctly on host - Regression Test Cases (updated) - No more test time available (Rem. by QM: this criterium is not permitted!!) Output products and exit conditions

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Rules for Process Elicitation (1/3) • Obtain information about – the organization – the software domain • Analyze existing documents and products • Observe the relation between developers and quality assurance • Ask whether an ongoing or upcoming organizational restructuring impacts the process • Make sure that the interview partner is selected according to your instructions / guidelines • Begin the interviews with a quality manager or project manager

Page 18 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Rules for Process Elicitation (2/3) • Opening of Interview • Main part of Interview – Summary – Behave neutral – Explain goal and purpose – At first ask about the products – Stress confidentiality – Then ask about processes – General questions about the – What are typical (known) process, and existence of deviations from the prescribed variants processes? – Which other roles participate in the processes? (Cross-Check) – Always be precise – Try to identify process variants

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Rules for Process Elicitation (3/3) • Closing of Interview • Ask questions even when a noticed ambiguity seems to be small, often – Explain future steps big problems are hidden behind it – Agree on time for the review • Don't try to solve all ambiguities and – Thank your interview partner conflicts (during the interview) – but follow-up on observed inconsistencies afterwards • After the interview: give a quick feedback to the interview-partner about what you did with his/her information

• The number of products is higher (approx. twice as high) than the number of processes. • The complexity of product flow interfaces of processes is relatively high (most of the processes access more then a dozen of products). • Most of processes are undertaken by several roles (partly over five roles). • Most of roles are involved in execution of more then a third of the whole process. 30 Processes 66 Products Page 21 Copyright 2008 © Dietmar Pfahl

42 Resources process

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Process Modeling Tools • Commercial tools not dedicated to process modeling – E.g. ABC Flowcharter, Microsoft Visio, Statemate • Workflow Management Systems – E.g. ARIS Toolset (event-process chains) • Research prototypes – E.g., Spearmint

• SPEARMINTTM – Software Process Elicitation, Analysis, Review, and Management in an inTegrated Environment • Assists a process engineer in creating and maintaining complex process models. • Allows for efficient modeling of different views of the process model • Generates EPG (Electronic Process Guide)

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

view view Views view Spearmint supports efficient modeling by supporting different views view view Entire process model • A view is a part of the process model – Spearmint describes not the whole process, but only parts of it in pre-defined and user-defined views. • A view highlights certain aspects – Working with views reduces the complexity of the process model. – Only those aspects of a model are contained, which are relevant for specific tasks. • SPEARMINT checks consistency of all views – Process elements in a certain view always reference to the whole process model.

Views Properties and Attributes views

Artifacts view

Activities view

Process view

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Product-Flow View

Refinement

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Process View

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Generation of Hypertext View (EPG)

e (e.g. developer) Process-user

Feedback, e.g. via annotations

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Consistency Checking • Process models should be complete and correct representations of reality. • Consistency checking has been partly automated in SPEARMINT. • Methodological prerequisites: – Process meta-model – Consistency rules

Prescriptive Process Modeling

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Pre-defined process Process models exist on Overview: models like Scrum, EVO, RUP, XP, Cleanroom... 3 levels: Prescriptive family/standard level, Inspires organizational level, Process Models and project level Generic Process model

Project (type) 1 Project (type) n process model Project (type) 2 process model process model

Page 34 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling An Example Process: The Waterfall Model • The most basic sequence of activities Require- Analyse ments needed to develop sizable software Design

Implement

Integrate

System test Product – Well tried, well documented model – Well suited to successive breakdown – Is simple to manage – Requires stability – Requires careful analysis and planning – Results in ”big-bang integration”

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Early Waterfall Model (1956) (Ref: Boehm, ICSE 2006 keynote)

OPERATIONAL PLAN

MACHINE SPECIFICATIONS OPERATIONAL SPECIFICATIONS

PROGRAM SPECIFICATIONS

CODING SPECIFICATIONS The SAGE Software CODING

Development PARAMETER TESTING (SPECIFICATIONS) Process (Benington, 1956) ASSEMBLY TESTING (SPECIFICATIONS)

SHAKEDOWN

Waterfall: Royce Model (1970) Prerequisites: Familiarity with application domains, SYSTEM REQUIREMENTS methods, techniques, Idea: tools, engineering SOFTWARE Sequential creation of REQUIREMENTS processes products on different Good understanding of PRELIMINARY levels of abstraction (e.g., PROGRAM the requirements precede code by design, DESIGN Stable requirements High capabilities for precede design by ANALYSIS requirements) and effort estimation

integration in reverse PROGRAM direction DESIGN PRELIMINARY Strictly sequential control DESIGN CODING flow can be weakened by ANALYSIS controlled iterations PROGRAM DESIGN TESTING

USAGE

INF5180 – Spring 2008 Part 07: Processes and Process Modeling The Waterfall Isn’t Dead Yet! • It is still a good approach for projects with – Well defined requirements – Possibly inexperienced developers – Known development environment – Small project size • It is often used for small maintenance tasks, for example

Page 38 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Often Waterfall is Bad • For many projects, the waterfall – Adversarial stakeholder model is a poor choice relationships • written definitions of requirements – Late risk resolution often lead to extended (and • can’t tell requirements or design heated) discussion of their risks exist until late in the life cycle interpretation – Requirements drive functional – Focus on documents and reviews decomposition • fulfilling the letter of a contract can • exhaustive requirements make it lead to the appearance of hard to tell if the design is viable; progress, but without real • hard to identify critical communication requirements – Inflexible!

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Code and Fix – An Evolutionary Model • Provides maximum flexibility • Has low complexity • Good model for prototyping But: • Yields low quality • Yields bad maintainability

Code Test Deliver

Exercise: • Alternative model to “Code & Fix”

Code Requirements Deliver

Test

• What are the advantages compared to ”code and fix” on previous slide? • Disadvantages?

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Fixing the Waterfall Model Customer Involvement Æ Prototypes Iterations Æ Risk Focus Increments Æ Staged Delivery Tailoring

System Requirements Testing Analysis

Integration System Design Testing

Unit Object Testing Design Implemen- tation adapted from [Royce 1970] Unit Testing

System Testing

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

System Requirements Is validated by Operation Analysis

precedes Software Requirements Client Elicitation Acceptance

System Requirements Integration Analysis & Test

Component Preliminary Integration Design & Test Problem with the V-Model:

Detailed Unit Assumption that Design Test Developer Perception =

Sawtooth Model

Client

Requirements Prototype Prototype Client Elicitation Demonstration 1 Demonstration 2 Acceptance

Developer System Integration & Test

Requirements Analysis Integration & Test

System Design

Implementation

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Sharktooth Model

Client

System Requirements Prototype Prototype Client Elicitation Demo 1 Demo 2 Acceptance

Manager Design System Review Integration & Test

Developer Requirements Analysis Component Integration & Test

System Design

Unit Object Test Design

Implementation INF5180 – Spring 2008 Part 07: Processes and Process Modeling Prototyping: Overview • Idea: – Concentration on the development of an executable version of the system that fulfills a limited number of requirements – User interfaces are often simplified or performance requirements are reduced – A primary goal is to collect experiences from first prototypes (e.g., regarding unclear requirements, difficult design aspects) – Getting first versions of the final product is usually not a goal – Prototyping follows other process models • Prerequisites: – High level of experience with the used development techniques – Technical infrastructure for prototype creation must be available

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Prototyping Advantages Disadvantages • Can be applied without having yet a clear idea of (all) • Risk that “side effects“ are the properties of the final product not sufficiently considered – especially non-functional • Misunderstandings between developer and customer requirements such as can be detected early (and thus mitigated) reliability or safety • Inconsistent requirements are (somewhat) earlier to • Risk that customer considers detect prototype as first version of • Comprehensive version & configuration management is the system that will be not necessary (Æ prototype should be thrown away) evolved – prototype should NOT be • Risk of project failure is reduced (e.g., developing a seen as a first version of product that does not satisfy the customer expectations) the system • In some cases, prototypes are suitable for evaluating business models

Page 48 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Problems with V Model • The V model and its variants do not distinguish temporal and logical dependencies between requirements • In particular, the V model does not accommodate incremental development and iteration

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Spiral Model Æ Highly Iterative

• The spiral model proposed by Boehm (1988) is an iterative model with focus on risk resolution: – Determine objectives and constraints – Evaluate Alternatives – Identify risks – Resolve risks after assigning priorities to risks – Develop a series of prototypes for the identified risks starting with the highest risk – Use a waterfall model for each prototype development (“cycle”) – If a risk has successfully been resolved, evaluate the results of the “cycle” and plan the next round – If a certain risk cannot be resolved, terminate the project immediately

ProjectProject StartStart

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Activities & Cycles in Boehm’s Spiral Model • Concept of Operation • For each cycle go through these activities • Software Requirements – Quadrant IV: Define objectives, alternatives, constraints • Software Product Design – Quadrant I: Evaluate alternatives, identify and resolve risks • Detailed Design – Quadrant II: Develop, verify prototype • Code – Quadrant III: Plan next “cycle” •Unit Test • Integration and Test • The first 3 cycles are shown in a polar coordinate system. • Acceptance Test – The polar coordinates r = (l, a) of a point indicate the resource spent in the project and the type of activity • Implementation

Page 52 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Types of Prototypes used in the Spiral Model • Illustrative Prototype – Develop the user interface with a set of storyboards – Implement them on a napkin or with a user interface builder (Visual C++, ....) – Good for first dialog with client • Functional Prototype – Implement and deliver an operational system with minimum functionality – Then add more functionality – Order identified by risk • Exploratory Prototype ("Hacking") – Implement part of the system to learn more about the requirements. – Good for situations in which paradigm discontinuities occur

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Limitations of the Waterfall and Spiral Models • Neither of these model deals well with frequent change – The Waterfall model assume that once you are done with a phase, all issues covered in that phase are closed and cannot be reopened – The Spiral model can deal with change between phases, but once inside a phase, no change is allowed • What do you do if change is happening more frequently? (“The only constant is the change”)

Page 54 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Iterative Enhancement: Overview • Origin: Basili und Turner, 1975 • Idea: – Develop each increment (i.e., a product part that fulfills a subset of requirements) in a Waterfall style; integrate increment by increment into the product until delivery – The focus of the development of an increment might be completion of functionality or structure, but it can also be refinement and improvement – Strictly sequential control flow can be weakened by controlled iterations • Prerequisites: – Structure of the problem permits incremental development

Problem Used INF5180description – Spring 2008 Part 07: Processes and Processsystem Modeling

Customer Usable requirements system

Developer AusführbaresExecutable requirements Systemsystem

System design

Unit Executable requirements units

Unit design

Iterative Enhancement Model (Ref: Rombach) INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Iterative Enhancement (or Incremental Development)

Advantages: Disadvantages: • Efficient learning during the project; thus, • Risk that, by ignoring specific experience level can be low requirements, the product will be • Early availability of a product, with the essential designed in such a way that properties of the final product. fulfilling future requirements becomes difficult/expensive • Allows for early customer involvement and feedback – particularly problematic are non- functional requirements • Applicable when parts of requirements are unclear or unstable • Comprehensive version and configuration management is • Supports integration testing necessary • Good applicability in case of fixed delivery dates (Æ prioritize requirements with the customer)

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Unified Process •Family:Iterative Enhancement • Characteristics: • Origin: – use case driven – architecture-centric – Ivar Jacobson, James Rumbaugh, Grady Booch, 1998 • Provides only rudimentary instructions • Defines process framework that is adaptable to • Refined version: – Rational Unified Process (Ph. – various application domains Kruchten) – different organizations – different competence levels – different project sizes

Page 58 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Rational Unified Process Process Workflows Phases Inception Elaboration Construction Transition Business modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Change & Configuration Mgmt Project Management Environment

INF5180 – Spring 2008 Part 07: Processes and Process Modeling MSF (Microsoft Solution Framework)

Process View

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Iterative Process Models Properties

Sequential (waterfall) process model

Level of influence Cost of changes

Customer involvement Management involvement

Plan /Analyse Phase_1 Phase_2 ..... Phase_n Delivery

Highly iterative process model

Level of influence Cost of changes

Customer involvement Management involvement

Plan /Analyse Iteration_1 Iteration_2 ..... Iteration_n Delivery

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Process Standards

Page 64 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling DOD Standard 2167A • Required by the Department of Defense for all software contractors in the 1980-90s • Waterfall-based model with the software development activities – System Requirements Analysis/Design – Software Requirements Analysis – Preliminary Design and Detailed Design – Coding and CSU testing (CSU = Computer Software Unit) – CSC Integration and Testing (CSC = Computer Software Component, can be decomposed into CSC's and CSU's) – CSCI Testing (CSCI = Computer Software Configuration Item) – System integration and Testing

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

ISO 12207: Standard for Information Technology- Software Life Cycle Processes

• This standard officially replaced MIL-STD-498 for the development of DoD software systems in August 1998. • This standard defines a comprehensive set of processes that cover the entire lifecycle of a software system — from the time a concept is made to the retirement of the software. • The standard defines a set of processes, which are in turn defined in terms of activities. The activities are broken down into a set of tasks. • The processes are defined in three broad categories — Primary Life Cycle Processes, Supporting Life Cycle Processes and Organisational Life Cycle Processes.

Page 66 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling ISO 12207 Processes • Primary life cycle • Supporting life cycle • Organisational processes: processes: processes: – Acquisition process – Audit process – Management process – Supply process – Configuration – Infrastructure process – Development Management – Improvement process process – Joint review process – Training process – Operation process – Documentation process – Maintenance – Quality assurance process process – Problem solving process – Verification process – Validation process

INF5180 – Spring 2008 Part 07: Processes and Process Modeling V-Modell® XT (XT = Extreme Tailoring)

• Published in January 2005 • Predecessor: V-Model (1997) for military authorities in Germany • Structured in a modular way • Mandatory for IT projects in public and military domains in Germany • Goals: – Enhance support for adaptability, scaleability, changeability, and expandability of V-Model 97 – Consider state of the art and adapt to current regulations and standards – Expand application range considering the complete system lifecycle of development projects – Introduce a process of organizational process improvement

Page 68 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling V-Model XT – Purpose and Scope • The V-Model XT is a guideline for the Planning and Management of IT Development Projects. • Scope of the V-Model are: – Improvement of Planning and Tracking of IT Development Projects, – Minimization of Project Risks, – Improvement and Quality Assurance, – Improvement of Communication between Project Stakeholders, – Containment of Total Costs over the Project and System Life Cycle. • The V-Model supports different Project Execution Strategies and the Concept of Decision Points. • The V-Model can be tailored according to the specific conditions and needs of an ICT Project • The V-Model addresses the Customer and the Contractor. Page 69 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Customer vs. Contractor View Customer Decision Points 12 345 68 Project Project Requirements Project Project Tested for Project approved defined established put out to tender contracted Acceptance closed

Change Plan established 7 12 Change Plan established 1234 11 13 Project Offer Project Project Acceptance Project approved tendered contracted defined declared closed System Delivery 5 specified performed 10 AuftragnehmerContractor System System Page6 70 drafted integrated 9 Copyright 2008 © Dietmar Pfahl

Detailed Design Systemelements 78completed realised INF5180 – Spring 2008 Part 07: Processes and Process Modeling V-Model: The Big Picture

The V-Model compises four sub-models: System Development (SD) Quality Assurance (QA) Configuration Management (CM) Project Management (PM)

Kapitel 4.2

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

V-Model: Project Management (PM) Sub-Model

Activity Types: • Management-related – Initialization/Finalization – Periodically Required • Placement/Procurement-related • Planning-related • Resource-related

V-Model: “Handling” Project (Refinement) Management (PM) Sub-Model

PM1: Project Initialization

INF5180 – Spring 2008 Part 07: Processes and Process Modeling V-Model: System Development (SD) Sub-Model

V-Model: System Development (SD) Sub-Model

SD2: System Design

INF5180 – Spring 2008 Part 07: Processes and Process Modeling V-Model: System Development (SD) Sub-Model

SD2: System Design “Handling” Page 76 (Refinement)Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling IEEE Std 1074 • Institutional standard (‘least common denominator’) published in 1997 • Process description comparable with V- Modell® XT (on a high level), but no statements about products, roles • Offers only little guidance for developers

INF5180 – Spring 2008 Part 07: Processes and Process Modeling IEEE Std 1074: Standard for Software Lifecycle

”Light-Weight” Processes (Evolutionary Development)

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Requirements and Customers

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 value the items on the left more. http://www.agilemanifesto.org/

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Extreme Programming • Origin: Kent Beck, Ward Cunningham, Ron Jeffries (end of 1990s) • Idea: “light weight” process model, agile process •Characteristic: – “Minimum” of accompanying measures (documentation, modeling , …) – Team orientation (e.g., common responsibility for all development artifacts) – Small teams (12-14 persons) – Involvement of user/client at an early stage – Social orientation • Scope: Prototype projects, small projects, low criticality of the results

Extreme Planning Programming: Overview 1. User stories (something like use cases) are written by the customer. 2. Complex stories are broken down into Iterative Phase simpler ones (like a WBS). 3. Stories are used to estimate the required amount of work. 4. Stories are used to create acceptance tests. 5. A release plan is devised that determines which stories will be available in which release. 6. Don’t hesitate to change what doesn’t work. http://www.extremeprogramming.org/rules.html

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Extreme Programming: Planning

1. Each release is preceded by a release planning meeting. 2. Each day begins with a stand-up meeting to share problems and concerns. 3. CRC cards are used for design. [XP and CRC were created by the same person, Kent Beck.] 4. Spike solutions are done to assess risks. 5. The customer is always available.

Extreme Programming: Iterative Phase

1. All code must pass unit tests, which are coded before the code being tested (test-driven design). 2. Refactoring is done constantly. 3. Integration is done by one pair. 4. Integration is done frequently. 5. Optimization is done last.

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Extreme Programming – Evolutionary Process Model

Defined by VTT for the mobile phone industry in Finland

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Scrum

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Scrum Sprint Backlog - Example

Core Sprint 16 Burndown Estimated Hours Remaining

400

350

300

250 Estimates Linear 200 Support Time

150 Max Support Time

100

25.09.2006 26.09.2006 27.09.2006 28.09.2006 29.09.2006 02.10.2006 03.10.2006 04.10.2006 05.10.2006 06.10.2006

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Choosing the Right Process Model

• What you should first decide is whether you actually need a prescriptive process model. Wholeheartedly! • To make the choice it is important to know your organization/project. – What characteristics are we going to look for? – What is it that means most for choice of process model? Main process model categories: – Can we use the same model everywhere, or do we need variants (a repertoire of different models)? Waterfall Incremental Iterative/evolutionary (sequences) (dividing) (repeating)

INF5180 – Spring 2008 Part 07: Processes and Process Modeling How Much Structure?

Hohmann: Process discipline Low High Formalism on the product

U Low Strict

T C Communication

T Informal Formal

E Number of check points

L H

T Few Many

L Experience M Much Little

How Much Structure?Size (organization) Hohmann: Small Big Size (product)

R R Small Big

C C Age (team)

R R High Low

Problem complexity

T Little Big

I Demand for precision M

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Alistair Cockburn

• One of the initiators behind The Agile Alliance • Known for the books Writing effective Use-cases and Agile Software Development • Has published a series of articles about Object orientation, Use-cases and ”human-oriented methods”. • Started the company Humans and Technology where he now works as consultant. • Quotation from article in Crosstalk, October 2002*: – Being agile is a declaration of prioritizing for project maneuverability with respect to shifting requirements, shifting technology, and a shifting understanding of the situation. Other priorities that might override agility include predictability, cost, schedule, process-accreditation, or use of specific tools.

*) http://www.stsc.hill.af.mil/crosstalk/2002/10/index.html INF5180 – Spring 2008 Part 07: Processes and Process Modeling Alistair Cockburn - tradeoffs

• Different projects need different methodology trade-offs. • A light methodology does a lot of good; after all, weight is costly. • Larger teams need more communication elements. • Projects with greater potential damage risk need more validation elements. • Formality, process, and documentation are not substitutes for discipline, skill, and understanding. • Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information. • Increased communication and feedback reduce the need for intermediate work products. • Concurrent and serial development exchange development cost for speed and flexibility. • Efficiency is expendable in non-bottleneck activities. • Sweet spots speed up development.

INF5180 – Spring 2008 Part 07: Processes and Process Modeling AC – Localising ”sweet-spot”

Planning is ”bad” and should be minimized

Too little Too much planning planning

“Any one methodology is likely to be appropriate for only one of the boxes lity gi f A on one of the planes. o ee gr Thus, at least 150 or De so methodologies are needed!”

INF5180 – Spring 2008 Part 07: Processes and Process Modeling Adjustments Based on ”skills”

”Formalism, Process and Documentation can not replace discipline, competency and understanding”

• Source: Boehm, B.; Turner, R.; Observations on balancing discipline and agility, Proceedings of the Agile Development Conference, 2003. ADC 2003. Page(s):32 - 39

INF5180 – Spring 2008 Part 07: Processes and Process Modeling What is Coming Next? • The selection of (more or less) well-defined process models is a big issue! • The most important parameters influencing the process choice are project size and criticality, but also the other factors mentioned by Cockburn and Boehm are worth taking into consideration. • The desire to introduce new, modern process models is increasing in industry; the believe that the ”Silver Bullet” has finally been found is spreading (once again). • Question: What happened to the wish for stability? Isn’t it possible to be too change-willing? Change results in restructuring (”rework”), doesn't it?