lecture1-2011dp-006handoutcs.lth.se/.../etsf01/lecture1-2011dp-006handout.pdf · • lecture 1:...

2011-03-08

1

ETSF01: Software Engineering Process –

Economy and Quality

Dietmar Pfahl Lund University

ETSF01 / Lecture 1, 2011

Welcome to ETSF01!

•  Mandatory for C and D •  Requires ETSA01 •  4 hp •  5 Lectures (Dietmar) •  5 Exercises (övningar)

–  Related to process / project (Dietmar) –  Related to project / final exam (Emelie, Richard)

•  1 Project (Dietmar) •  1 Final exam (Dietmar)


Course textbook and other material

Assignments Project instructions

cs.lth.se/etsf01

PROFES Manual


Lectures

•  Lecture 1: Course intro / SPI vs. SPM / Project Planning / Process selection

•  Lecture 2: Project Evaluation / SW Quality / GQM •  Lecture 3: Effort estimation / Activity planning •  Lecture 4: Risk management / Resource allocation / Monitoring

& control •  Lecture 5: Process assessment / People and teams

•  (Lectures 6 and 7: if needed, otherwise no lecture)


Final Exam

•  Written “traditional” exam •  More information will be presented after the Easter break


Project

•  The project should be conducted by groups of 4 (or 3) students

•  You will develop a software process improvement (SPI) plan for the processes used in ETSA01

•  A project template with detailed guidelines is available •  The scope of the SPI plan could be (examples):

–  complete process –  a sub-process of the complete process –  an activity of a sub-process –  a method/technique used in an activity –  …

2011-03-08

2


Exercises (övningar)

•  There are exercises in week 1, 2, 3, 5, and 6. •  Intended to prepare for the project and for the final exam •  You should read the material mentioned in the posted assignment

sheets before the related exercise sessions •  It is good if the whole project group can go to the same exercise

session •  There are four exercise sessions per week:

–  Session A, Thursday 13-15 –  Session B, Thursday 15-17 –  Session C, Friday 10-12 –  Session D, Friday 13-15

•  Select which exercise session to attend by writing your name on the list


Personnel

•  Dietmar Pfahl, [email protected], 046-222 41 41, E:2408, Lectures, Projects, Project Exercises, Exam

•  Richard Berntsson Svensson, [email protected], 046-222 0368 E:2410, Textbook Exercises

•  Emelie Engström, [email protected], 046-222 88 99, E:2112D, Textbook Exercises

•  Lena Ohlsson, [email protected], 046-222 80 40, E:2179, Course Secretary

•  Jonas Wisbrant, [email protected], 046-222 34 83, E:2193, ETSA01 Liaison and Wiki Support


Information

•  URL: cs.lth.se/etsf01 •  Notice board: 2nd floor at the south-west elevator


Course representatives (kursombud)

•  C: N. N. •  C: N. N. •  D: N. N. •  D: N. N.


Plan with concrete People, activities, artifacts (Products)


The six Ps in software engineering

•  Product •  Process •  People •  Program •  Project •  Plan

Process (prescriptive & descriptive)

People (abstract)

Products (abstract)

Model World

Real World


Project Program


Terminology /1

•  The following definitions are taken from the NASA Goddard Space Flight Center’s glossary (http://software.gsfc.nasa.gov/glossary.cfm)

–  Program: •  A major activity within an Enterprise having defined goals,

objectives, requirements, and funding levels, and consisting of one or more projects [NPG 7120.5B]

–  Project: •  An activity, designated by a program, characterized as having

defined goals, objectives, requirements, a Life-Cycle Cost (LCC), a beginning, and an end [NPG 7120.5B]

–  Product –  Process

2011-03-08

3


Terminology /2

•  The following definitions are taken from the NASA Goddard Space Flight Center’s glossary (http://software.gsfc.nasa.gov/glossary.cfm)

–  Product: •  The output of a task, whether deliverable or internal. Products

may include hardware, software, documentation, services, mission data, science, and technology output [ISD Process Team]

–  Process: •  (1) A set of interrelated activities, which transform inputs into

outputs [IEEE/EIA 12207.0-1996] •  (2) A sequence of tasks performed for a given purpose; for

example, the software development process [Adapted from IEEE Std 610.12-1990]


Process taxonomy

•  What are typical processes in a software project?

Processes

Engineering Processes Non-Engineering Processes

Product-Engineering Processes

Process-Engineering Processes

Business Processes

Social Processes

Technical Processes

Managerial Processes

Development Processes

Maintenance Processes

Project Mgmt Processes

Quality Mgmt Processes

Conf Mgmt Processes Product Line

Processes

Improvement Processes

Process Modeling Processes

Measurement Processes


Software process examples

Waterfall

SCRUM

RUP

V-Model

Spiral


Descriptive vs. prescriptive process models

How is it done?

How should it be done?


A systematic approach to Software Process Improvement (SPI)

•  PLAN what you want to accomplish over a period of time and what you might do, or need to do, to get there

•  DO what you planned to do •  CHECK the results of what you

did to see if the objective was achieved

•  ACT on the information – standardize or plan for further improvement


PROFES

2011-03-08

4


PROFES – Product-Focused Process Improvement in Software Engineering



Plan-Do-Check-Act à “Plan” Where are we today?

How do we get there?

Where do we want to be?

How do we monitor?

How do we check whether we got to where we wanted to get to?

What have we learnt and how do we follow-up?

Characterize

Set Goals

Plan

Execute

Analyse

Package


Project Organization Experience Factory

1. Characterize 2. Set Goals 3. Choose Process

Execution plans

4. Execute Process

Project Support

5. Analyze

products, lessons learned, models

6. Package

Generalize

Tailor

Formalize

Disseminate

Experience Base

environment characteristics

tailorable knowledge, consulting

project analysis, process

modification

data, lessons learned

Organisational framework for SPI

Project Learning Organisational Learning


Relation between ETSF01 and ETSA01

Project Organization Experience Factory

1. Characterize 2. Set Goals 3. Choose Process

Execution plans

4. Execute Process

Project Support

5. Analyze

products, lessons learned, models

6. Package

Generalize

Tailor

Formalize

Disseminate

Experience Base

environment characteristics

tailorable knowledge, consulting

project analysis, process

modification

data, lessons learned

ETSA01 ETSF01 (& Jonas Wisbrant)


Software Project Management

Textbook chapters related to today’s lecture: 1, 3, 4

2011-03-08

5


Characteristics of projects

A task is more ‘project-like’ if it is: •  Non-routine •  Planned •  Aiming at a specific target •  Carried out for a customer •  Carried out by a temporary work group •  Involving several specialisations •  Made up of several different phases •  Constrained by time and resources •  Large and/or complex


Are software projects really different from other projects?

Not really … but •  Invisibility (i.e., not tangible) •  Complexity (i.e., can be enhanced easily) •  Flexibility (i.e., can be changed easily)

… make software more problematic to build than other engineered artefacts.


What is management?

This involves the following activities: •  Planning – deciding what is to be done •  Organizing – making arrangements •  Staffing – selecting the right people for the job •  Directing – giving instructions •  Monitoring – checking on progress •  Controlling – taking action to remedy hold-ups •  Innovating – coming up with solutions when problems emerge •  Representing – liaising with clients, users, developers and other

stakeholders


Management control


Project planning steps

0.Select project

1. Identify project objectives

2. Identify project infrastructure

3. Analyse project

characteristics

4. Identify products and activities

5. Estimate effort for activity

8. Review/ publicize plan

6. Identify activity risks

7. Allocate resources

9. Execute plan

10. Lower level planning

Review

Lower level detail

For each activity


The software development life-cycle (ISO 12207)

2011-03-08

6


Software process examples

Waterfall

SCRUM

RUP

V-Model

Spiral


Example Process: The Waterfall Model •  The most basic sequence of

activities needed to develop sizable software

–  Well tried, well documented model –  Well suited to successive breakdown –  Is simple to manage –  Requires stability (“one-shot”) –  Requires careful analysis and planning –  Results in ”big-bang integration”

Analyse

Design

Implement

Integrate

System test

Product

Require-ments


Waterfall: Royce Model (1970)

SYSTEM REQUIREMENTS

TESTING

CODING

PROGRAM DESIGN

ANALYSIS

PRELIMINARY PROGRAM

DESIGN

SOFTWARE REQUIREMENTS

OPERATIONS

PRELIMINARY DESIGN

ANALYSIS

PROGRAM DESIGN

CODING

TESTING

USAGE

Idea: Sequential creation of products on different levels of abstraction (e.g., precede code by design, precede design by requirements) and integration in reverse direction Strictly sequential control flow can be weakened by controlled iterations

Prerequisites: Familiarity with application domains, methods, techniques, tools, engineering processes Good understanding of the requirements Stable requirements High capabilities for effort estimation


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


German V-Model: System Development (SD) Sub-Model SD2: System Design

“Handling” (Refinement)


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

2011-03-08

7


German V-Model: The Big Picture

Kapitel 4.2

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


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

Activity Types: •  Management-related

–  Initialization/Finalization –  Periodically Required

•  Placement/Procurement-related

•  Planning-related •  Resource-related


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

“Handling” (Refinement)


Prototyping

‘An iterative process of creating quickly and inexpensively live and working models to test out requirements and assumptions’ (Sprague and McNurlin)

•  Main types:

–  ‘throw away’ prototypes –  evolutionary prototypes

•  What is being prototyped? –  human-computer interface –  functionality


Project Start

Boehm’s Spiral Model


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

2011-03-08

8


Iterative Enhancement (Incremental Delivery)

•  Origin: Basili und Turner, 1975 •  Idea:

–  Split functionality into several increments –  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


Incremental delivery

design build install evaluate



increment 1

increment 2

increment 3

first incremental delivery

second incremental delivery

third incremental delivery

delivered system


The incremental process


Unified Process

•  Family: Iterative Enhancement •  Origin:

–  Ivar Jacobson, James Rumbaugh, Grady Booch, 1998

•  Defines process framework that is adaptable to

–  various application domains

–  different organizations –  different competence

levels –  different project sizes

•  Characteristics: –  use case driven –  architecture-centric

•  Provides only rudimentary instructions

•  Refined version: –  Rational Unified Process

(Ph. Kruchten)


Rational Unified Process (RUP)

Phases

Iterations

Process Workflows

Environment Project Management

Change & Configuration Mgmt

Elaboration Transition Inception Construction

Implementation Test

Analysis & Design

Deployment

Requirements Business modeling

Preliminary Iteration(s)

Iter. #1

Iter. #2

Iter. #n

Iter. #n+1

Iter. #n+2

Iter. #m

Iter. #m+1

Supporting Workflows

Organization along content

Organization along time


RUP Phases and Iterations ― The Time Dimension

•  This is the dynamic organization of the process along time. •  The software lifecycle is broken into cycles, each cycle working on a new

generation of the product. The Rational Unified Process divides one development cycle in four consecutive phases.

–  Inception phase –  Elaboration phase –  Construction phase –  Transition phase

•  Each phase is concluded with a well-defined milestone--a point in time at which certain critical decisions must be made, and therefore key goals must have been achieved.

2011-03-08

9


RUP – Static Process

Static Structure of the Process •  A process describes who is

doing what, how, and when. •  The RIP is represented using

four primary modeling elements:

–  Workers (Roles), the "who" –  Activities, the "how" –  Artifacts, the "what" –  Workflows, the "when"

Activities, Artifacts, and Workers


RUP – Resources and Workers (Roles)

•  A worker defines the behavior and responsibilities of an individual, or a group of individuals working together as a team.

•  You could regard a worker as a "hat" an individual can wear in the project.

•  One individual may wear many different hats. This is an important distinction because it is natural to think of a worker as the individual or team itself, but in the Unified Process the worker is more the role defining how the individuals should carry out the work.

•  The responsibilities we assign to a worker include both to perform a certain set of activities as well as being owner of a set of artifacts.


RUP Workflow – Example: Analysis & Design

Workflows •  A mere enumeration of all workers,

activities and artifacts does not quite constitute a process. We need to describe meaningful sequences of activities that produce some valuable result, and to show interactions between workers.

•  A workflow is a sequence of activities that produces a result of observable value.

•  In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram (cf. activity diagram on the right hand side).


Iterative Enhancement (Incremental Delivery)

Advantages: •  Efficient learning during the

project; thus, experience level can be low

•  Early availability of a product, with the essential properties of the final product.

•  Allows for early customer involvement and feedback

•  Applicable when parts of requirements are unclear or unstable

•  Supports integration testing •  Good applicability in case of fixed

delivery dates (à prioritize requirements with the customer)

Disadvantages: •  Risk that, by ignoring specific

requirements, the product will be designed in such a way that fulfilling future requirements becomes difficult/expensive

–  particularly problematic are non-functional requirements

•  Comprehensive version and configuration management is necessary


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


XP – Rules and Practices

Planning User stories are written (by the customer!). Release planning creates the schedule. Make frequent small releases. The Project Velocity is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks.

Designing

Simplicity. Choose a system metaphor. Use CRC* cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible.

Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimization till last. No overtime.

Testing

All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found (acceptance) tests are created. Acceptance tests are run often and the score is published.

http://www.extremeprogramming.org/rules.html

* CRC = Class Responsibility Collaborator

2011-03-08

10


Extreme Programming – Evolutionary Process Model


Scrum

http://www.scrumforteamsystem.com/processguidance/v1/Scrum/Scrum.html


Scrum – Roles: ”Pigs” and ”Chicken”

"Pig" roles •  Pigs are the ones committed to the

project in the Scrum process; they are the ones with "their bacon on the line".

–  Product Owner –  Scrum Master (or

Facilitator) –  Team

"Chicken" roles •  Chicken roles are not part of the

actual Scrum process, but must be taken into account.

–  Users –  Stakeholders (customers,

vendors) –  Managers

•  Note: An important aspect of an Agile approach is the practice of involving users, business and stakeholders into part of the process. It is important for these people to be engaged and provide feedback into the outputs for review and planning of each sprint.


Product Owner

•  Define the features of the product •  Decide on release date and

content •  Be responsible for the profitability

of the product (ROI) •  Prioritize features according to

market value •  Adjust features and priority every

iteration, as needed •  Accept or reject work results


The Scrum Master

•  Represents management to the project

•  Responsible for enacting Scrum values and practices

•  Removes impediments •  Ensure that the team is fully

functional and productive •  Enable close cooperation across

all roles and functions •  Shield the team from external

interferences


The Team

•  Typically 5-9 people •  Cross-functional:

–  Programmers, testers, user experience designers, etc.

•  Members should be full-time –  May be exceptions (e.g.,

database administrator) •  Teams are self-organizing

–  Ideally, no titles but rarely a possibility

•  Membership should change only between sprints

2011-03-08

11


Scrum Iterations and Sprints

Daily Scrum

Sprin

t Rev

iew

Mee

ting

Sprin

t Ret

rosp

ectiv

e Sp

rint P

lann

ing

Mee

ting

Sprin

t Pla

nnin

g M

eetin

g

15 min daily

~1 hour

1 day for a 4 week Sprint


Sprint planning meeting

Sprint prioritization

•  Analyze and evaluate product backlog

•  Select sprint goal

Sprint planning

•  Decide how to achieve sprint goal (design)

•  Create sprint backlog (tasks) from product backlog items (user stories / features)

•  Estimate sprint backlog in hours

Sprint goal

Sprint backlog

Business conditions

Team capacity

Product backlog

Technology

Current product


Sprint Planning Meeting

•  Team selects items from the product backlog they can commit to completing

•  Sprint backlog is created –  Tasks are identified and each is estimated (1-16 hours) –  Collaboratively, not done alone by the Scrum Master

•  High-level design is considered

As a vacation planner, I want to see photos of the hotels.

Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4)


Daily Scrum

•  Parameters –  Daily –  15-minutes –  Stand-up

•  Not for problem solving –  Whole world is invited –  Only team members,

Scrum Master, product owner, can talk

•  Helps avoid other unnecessary meetings


Daily Scrum – 3 Questions

NB: •  These

questions are not status reports for the Scrum Master

•  They are commitments in front of peers

What did you do yesterday? 1

What will you do today? 2

Is anything in your way? 3


Sprint Review Meeting

•  Team presents what it accomplished during the sprint

•  Typically takes the form of a demo of new features or underlying architecture

•  Informal –  2-hour prep time rule –  No slides

•  Whole team participates •  Invite the world

2011-03-08

12


Sprint Retrospective

•  Periodically take a look at what is and is not working •  Typically 15–30 minutes •  Done after every sprint •  Whole team participates

–  Scrum Master –  Product Owner –  Team –  Possibly customers and others


Scrum – Main Artifacts

•  Product backlog •  Sprint backlog •  Burn down chart

Backlog item Estimate

Allow a guest to make a reservation 3

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports (revenue-per-available-room) 8

Improve exception handling 8

... 30

... 50

Tasks!Code the user interface!

Code the middle tier!

Test the middle tier!

Write online help!

Write the foo class!

Mon!8!

16!

8!

12!

8!

Tues!4!

12!

16!

8!

Wed! Thur!

4!

11!

8!

4!

Fri!

8!

8!

Add error logging!

8!

10!

16!

8!

8!


Product Backlog

•  The requirements •  A list of all desired work on the

project •  Ideally expressed such that

each item has value to the users or customers of the product (à user story)

•  Prioritized by the product owner

•  Re-prioritized at the start of each sprint

This is the product backlog


Backlog item Estimate

Allow a guest to make a reservation 3

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports (revenue-per-available-room) 8

Improve exception handling 8

... 30

... 50


The Sprint Goal

•  A short statement of what the work will be focused on during the sprint

Database Application

Financial services

Life Sciences

Support features necessary for population genetics studies.

Support more technical indicators than company ABC with real-time, streaming data.

Make the application run on SQL Server in addition to Oracle.


Managing the Sprint Backlog

•  Individuals sign up for work of their own choosing –  Work is never assigned!

•  Estimated work remaining is updated daily •  Any team member can add, delete or change the sprint

backlog •  Work for the sprint emerges •  If work is unclear, define a sprint backlog item with a

larger amount of effort and break it down later •  Update work remaining as more becomes known

2011-03-08

13


Hou

rs

40

30

20

10

0 Mon Tue Wed Thu Fri

Tasks Code the user interface

Code the middle tier

Test the middle tier

Write online help

Mon 8

16

8

12

Tues Wed Thur Fri 4

12

16

7

11

8

10

16 8

50


Sprint Backlog – Example (with more detail)


Scalability of Scrum •  Typical individual team is 7

± 2 people –  Scalability comes from

teams of teams •  Factors in scaling

–  Type of application –  Team size –  Team dispersion –  Project duration

•  Scrum has been used on multiple 500+ person projects (e.g., SAP)

Scrum of Scrums of …


‘Rules of thumb’ for selecting process

•  IF uncertainty is high – THEN use agile process

•  IF complexity is high but uncertainty is not – THEN use incremental process

•  IF uncertainty and complexity both low – THEN use waterfall process

•  IF schedule is tight/fixed – THEN use agile or incremental approach

• …


Rest of this week

•  Read textbook chapters 1, 3, 4

•  Familiarise with PROFES Handbook

•  Familiarise with ETSA01 wiki

•  Form project groups •  Attend Exercise 1

(mandatory) ETSF01 / Lecture 1, 2011

Next week

•  Read textbook chapter 2 •  Define project scope

•  Meet project supervisor Appointment by email: [email protected]

•  Exercise 2

lecture1-2011dp-006handoutcs.lth.se/.../etsf01/lecture1-2011dp-006handout.pdf · • lecture 1:...

Documents