Abran Project Management v5

8/8/2019 Abran Project Management v5

1/69

Gestion de Projectos de Softwarebasados en estandares ISO

By:Alain Abran

II Conferencia Internacional de Ingeniera de SistemasUniversidad Peruana Union

Octubre 18-19 2010

1 Copyrights 2010 Alain Abran


2/69

Managing Software Projectsw ith ISO standards

By:Alain Abran

II Conferencia Internacional de Ingeniera de Sistemas

Universidad Peruana Union

Octubre 18-19 2010



3/69


List of Topics

1. Standards & Software Engineering

2. ISO standards available to manage and control asoftware project.

3. Sizing standard in support of project management:COSMIC - ISO 19761

4. Examples of its use in software project estimation

5. Our strategy to introduce standards in organizations

Copyrights 2010 Alain Abran 3


4/69


List of Topics

1.Standards & Softw are Engineering2. ISO standards available to manage and control asoftware project.

3. Sizing standard in support of project management:

COSMIC - ISO 197614. Examples of its use in software project estimation




5/69

APEC 2010 F.Coallier 5

What is a Standard?

Guidelines that reflect agreements: on products, practices, or operations

by nationally or internationally

recognized: industrial

professional

trade associations

governmental bodies.


6/69

APEC 2010 F.Coallier 6

Types of Standards?Organization Standards Ex: internal company standards

Market Standards (De Facto) Ex: Microsoft Windows, or the CMMI

Professional Standards Developed by professional organizations (such as the IEEE)

Industry Standards Developed by industrial consortium (ex: OMG)

National Standards Developed by national standards organization (ex. ANSI)

International Standards Developed by a formal international standard organization

(ex: ISO)


7/69

Contents of Standards

Process standards: Collection of best practices

Sequences of steps & activities

Expected inputs and deliverables

Templates

Product standards

Baselines and criteria

Measurement standards

Definitions, rules (and talons) Copyrights 2010 Alain Abran 7


8/69

ISO: Software Engineering Standards

8 APEC 2010 F.Coallier


9/69

ISO: Working Groups Structure

Sub-committee SC7

Systems & SoftwareDocumentation

WG2

WG6

ProcessAssessment

WG10Tools And

Environment

WG4

Life CycleManagement

WG7

ArchitectureWG42Software and Systems

Bodies of Knowledgeand Professionalization

WG20

Techniques forSpecifying IT Systems

WG19

SoftwareAsset Management

WG21Software & SystemsMeasurement and

Evaluation

Systems QualityManagement

WG23

SLC Profiles and

Guidelines for VSE

IT ServiceManagement

WG25

WG24

CIF Usability

JWG ISO/ TC 54

S/ W Testing

WG26

IS GovernanceFrameworks

WG1A

9 APEC 2010 F.Coallier


10/69

Managing Software Projectw ith ISO Standards

List of Topics1. Standards & Software Engineering

2.ISO standards available tomanage and control a softwareproject.

3. Sizing standard in support of project management:

COSMIC - ISO 197614. Examples of its use in software project estimation




11/69


ISO Standards Integrated View

APEC 2010 F.Coallier


12/69

ISO: Standards to Software Quality


Tailored Process for

ProductDevelopment

Product Profile

Situation

Quality ReqsDefinition

Product QualityRequirements

Architectural

Design

Architecture

Description

Implementation Product

QualificationProduct Properties

Measurement Evaluation

12207

25020

25040

25010

25030

42010

15288

15939

RiskManagement

16085

WBS

Construction

Creation Information Flow Conformance

Figure 1. End-to-end approach to product quality achievement

Operations25012

25012



13/69

Key ISO Standards inProjects Management

Project Management: ISO 16326

Functional Size Measurement:

COSMIC: ISO 19761 IFPUG: ISO 20926

Others Risk Management (16085) Documentation

Etc.



14/69

ISO 16326: Project Management

Project planning Project initiation

Estimation plan

Staffing plan

Resource acquisition plan . Project staff training plan

Project w ork plans

Work activities.

Schedule allocation Resource allocation

Budget allocation

Procurement plan



15/69


Project assessment and control Requirements management plan

Scope change control plan

Schedule control plan

Budget control plan

Quality assurance plan

Subcontractor management plan

Project closeout plan



16/69


Supporting process plans Project supervision and work environment

Decision management

Risk management

Configuration management Information management

Documentation

Communication and publicity

Quality assurance

Measurement

Reviews and audits

Verification and validation



17/69


List of Topics1. Standards & Software Engineering

2. ISO standards available to manage and control a

software project.3.Sizing standard in support of

project management: COSMIC -

ISO 197614. Examples of its use in software project estimation5. Our strategy to introduce standards in organizations



18/69

Sizing ContextAn analogy...

200 m2

400 m 2

400 m2


19/69

An analogy...

200 m2

400 m 2

Software ASoftware B

Size = ???? Size = ????

400 m2


20/69

1980 1985 1990 1995 2000 2009

AllanAlbrecht

FP A

IFPUG4.0

IFPUG4.x

MkIIFP A

MkIIFPA 1.3

Full FPsV.1

3-DFPs

FeaturePoints

ISO FSMStandards

COSMIC ISO 19761

History of Functional SizeMeasurement Methods

----- Usecase Points ------------

+ 30 variants



21/69

ISO Standards on Functional Size

Meta-standards on functional size: ISO14143 Part 1: Definitions & Concepts

Part 2: Conformity Assessment

Part 3: Verification Guide

Part 4: References Functional User Requirements Part 5: Software Domains

Specific standards: 1st generation measurement methods:

MKII: ISO 20698

IFPUG: ISO 20926

NESMA: ISO 24570

2nd generation: COSMIC ISO 1976121 Copyrights 2010 Alain Abran


22/69

An analogy...

200 m2

400 m2

SoftwareFunctionality

SoftwareFunctionality

200 CFP 400 CFP

CFP = COSMIC Function Points



23/69

ISO 14143-1 definition:

Functional Size =

A size of software derived by quantifying theFunctional User Requirements FUR

A measure of the amount of information processing

(required to be) carried out by the software:What the User wants the software to do,

not How

The Functional Size of software



24/69

Functional Users Requirements - FUR

Definition:

A subset of the User Requirements in terms of tasks & serv ices.

Include (but not l imited to):Data transfer (ex: Input customer data; Send control signal)

Data transformation (ex: Calculate bank interest; Derive average temperatu re)

Data storage (ex: Store customer order; Record temperature over time)

Data retrieval (ex : List current employees; Retrieve latest aircraft position)

Exclude (but not l imited to):Quality constraints (ex: usability, reliability, efficiency and por tability)

Organizational constraint s (ex: locations for operation, target hardware &

compliance to standards)Environmental constraints (ex: interoperability, security, privacy and safety)

Implementation constraint s (ex: development language, delivery schedule)

Source: ISO 14143-1



25/69

Functional Users Requirements

Functional User Requirements (FUR) can be identified &

measuredAFTER the software has been built

Physical

programs and

screens

Functional

UsersRequirements

Physical

data storage

artifacts

Users operation

manuals andprocedures



26/69

An analogy: After construct ion

200 m2

200 CFPCFP = COSMIC Function Points

MonitoringPanel

Temperature& pressure

sensors

ControlValves

Input &Display

Office PC

Process control

computer


27/69

Functional Users Requirements

Functional User Requirements (FUR) can be

identified & measured BEFORE the software exists

(using UML diagrams, for instance)

Requirements

Specifications

Functional

UsersRequirementsFunctional

decomposition

lists

Models

Ex.:UML diagrams



28/69

An analogy: Measurementfrom P lans

200 m2

UMLDiagrams

200 CFPCFP = COSMIC Function Points

MainHouse Plan

KitchenPlan

BedroomsPlans

BathroomsPlans


29/69

COSMIC ISO 19761: User View ofSoftware Functional Requirements

Users

OR

Engineered

devices

OR

Other

Software

Boundary

DATA MANIPULATIONOR TRANSFORMATION

Software

DATA IN

DATA OUT

STORE PERSISTENT DATA

RETRIEVE PERSI STENT DATA



30/69

COSMIC Function Point

COSMIC Measurement Unit =

1 Data Movement of a Single Data Group

= 1 CFP = 1 COSMIC Function Point



31/69

User View ofSoftware Functional Requirements

Users

OR

Engineered

devices

OR

Other

Software

Boundary

DATA MANIPULATIONOR TRANSFORMATION

Software

DATA IN

ENTRY

DATA OUT

EXIT

STORE PERSISTENT DATA

WRITE

RETRIEVE PERSI STENT DATA

READ



32/69


The COSMIC Functional Size Measurement Method

Version 3.0

Method Overview

September 2007


33/69

International Status

The Measurement Manual available for free in:

English

Spanish

Chinese French

Japanese

Arabic

The Measurement Manual has been down-loaded

from over 40 countriesMany active COSMIC groups in various countries



34/69

Avai lable resources on COSMIC

Complete documentation on the WebMeasurement Manual

Business Application Guidelines

Case studies on measuring with COSMIC

Publications on the use of COSMIC

www.cosmicon.com



35/69

Managing Software Projectw ith ISO standards

List of Topics

1. Standards & Software Engineering

2. ISO standards available to manage and control asoftware project.

3. Sizing standard in support of project management:COSMIC - ISO 19761

4.Examples of its use in softwareproject estimation




36/69

Historical data = Basis for Estimation

Effort/Cost

Size: Function Points

In most industries there is a strong relationship between size and

effort/cost

If you know the size of the software to be developed, then yourhistorical data can help you estimateEffort (& related Cost).


D l t M d l ith


37/69

Development Model w ith:

Fixed & Variable costs

Effort = Variable Cost + Fixed cost = a x Size + b

Effort (in hours)

Size (in Function Points)

b

a



38/69

Multiple Development Processes !

Size (in Function

Points)

a3

a2

a1b3b2

Effort (in hours)

b1

ZONE 3

ZONE 2

ZONE 1



39/69

Projects from a Single Organization

Fixed effort = 2,411 hoursVariable effort = 30.7 hrs / CFP & R2 = 0,4



40/69

Graphical Analysis

Key Findings:

5 projects above the line:

Tw ice as much effort as projects of similar

size (i.e. 100% more effort!!)

11 projects below the line:

They represent the normal situation in this

organization (i.e. the capabili ty to deliverprojects within this effort-size ratio)



41/69

Process Capability Model

Fixed costs = 3,208 hoursVariable Costs = 17.1 hrs / PF & R2 = 0,6



42/69

Least Productive Projects

Fixed effort = 8,257 hoursVariable effort = 33.4 hrs / PF & R2 = 0,6



43/69

What Caused this 100% Increase in Effort?

From interviews w ith project managers:

Key major +100% cost drivers:

- Schedule Compression

- Users did not master their requirements

- Software with numerous links to othersoftware

(M os t a re qu a l it a t i ve i ndependent v a r i ab l e s, ou t s i de o fthe con t ro l o f the p ro jec t m anag e r : cons t ra in t sm anda t ed b y s en io r m anagemen t )



44/69

Follow up in this Organization

Modification to their Estimation Process:

1. Functional Sizing

2. Risk Analysis see factors in previous page

3. Selection of 1 of the 2 estimation modelsbased on risks identified

I f risks present: project budget must betw ice larger than proven capability of thesoftware development team in this

organization!

4. Risks monitoring



45/69

Key Insights

A lot of organizations think that they need to take avery large number of cost drivers to explain productivityand to prepare an estimate.

Many examples from industry illustrate that: A very few key selected factors (i.e. size) explain

the major part of the costs!

All other factors combined together explain the

congruent part of the effort variation in a softwareproject!

Of course, when the development process isunder control!



46/69

Key Insights

For productivity analysis and estimation,you need to understand the bigpicture!

Once you know the productivity-capabilityof your development process (orprocesses): you can work out on the details

And high risks situations!

Use ISO standards for measurement!


P j t S C t l ith Si


47/69

Project Scope Control w ith Size


Type ofImpact

Project PhaseIntroduced

% of FPPrice to

Apply

Comment

Added Build

Testing

100%

110%

Treated as new functionality. Anyimplications for existing functions areassessed as changes to those functions.Additional factor to compensate for moredetailed impact investigation and possiblerequirement to retest other associatedfunctions to ensure no impact.

Deleted Build

Testing

50%

90%

At start of build 35% of development effortexpended. At end of build 66%. A midvalue has been taken.Assume all effort bar implementation hasbeen expended.

Changed Build

Testing

40%

70%

Original function points are included in theBFPC. This is an additional weighting forrebuild.Additional factor for requirement to rebuildand retest the changed function.


48/69

Project Data w ithStandards in the

InternationalRepository of Industry Data



49/69

ISBSG

ISBSG: International Software Benchmarking

Standards Group (Non for profit)

Organizations are strongly encouraged to sent data to the

International Repository of ISBSG:

Directly: www.isbsg.org

or through a COSMIC international member to add

another layer for anonymity



50/69

ISBSG Data Collection Process

Planning

Gain commitment

Select projects

Data Collection

COSMIC standards

ISBSG Standards

Preparation

Training

Repeatability Exercise

Analysis

Measurement quality controls

Validation

Data recording

Data analysis

Comparative analysis

Analysis Report

OrganizationalFeedback



51/69

350 COSMIC projects: Key benchmarks

0 10 20 30 40 50

Bus App enhancements

Bus App 3GL new devts.

Bus App 4GL new devts.

Real-time enhancements

Real-time new devts.

PDR (work-hours/CFP)



52/69

Business- New development:Median Productivity per Size Band

0.0

1.0

2.0

3.0

4.0

5.0

6.0

7.0

8.0

9.0

10.0

0 - 50 50 - 100 100 - 200 200 - 300 300 - 500 500 - 1000 1000+

SIze Band (CFP)

MedianProductivity

(CFP/Work-mon

th)



53/69

Business - New development:Average percentage effort distr ibution

11%

18%

44%

27%

SpecifyDesign

Build

Test



54/69

ISO Standards Integrated View


55/69


SO Sta da ds teg ated e



56/69

Major Issues in ImplementingStandards

Multiplicity of standards

Which ones are needed, when?

How to design an implementationstrategy

The organizational knowledge &

expertise about standardsPeople issues


A C t St t t


57/69

A Corporate Strategy toIntroduce Standards

Through the Project Management Office(MPO):

PMI body of Knowledge for the genericmanagement concepts

ISO-IEEE standards directly tied to theplanning and control of projects


Our Educational Strategy to


58/69

Our Educational Strategy toIntroduce Standards

Introduce the standards culture beforethe staff gets hired in organizations

Software Engineering Curriculum basedon (and supported by):

Software Engineering Body of Knowledge:

SWEBOK ISO 19759



59/69

G id t th S ft E i i


60/69

60

Guide to the Software EngineeringBody of Know ledge (SWEBOK)

Leadership: IEEE Computer Societyy

International participation from industry,professional societies, standards bodies, academia

& authorsOver 500 software engineering professionals havecontributed

Adopted by ISO: 19759Available on www.swebok.org

Update in progress
http://www.swebok.org/http://www.swebok.org/


61/69

61

Knowledge Areas and RelatedDisciplines

Software Requirements

Software Design

Software Construction

Software Testing

Software Maintenance

Software Configuration Management

Software Eng. Management Software Eng. Tools & Methods

Software Engineering Process

Software Quality

Computer Engineering

Computer Science Mathematics

Project Management

Management

Quality Management Software Ergonomics

Systems Engineering

Related Disciplines


62/69

62

SWEBOK & Education

Every Knowledge Area is based on:

(1) The best authors

(2) The relevant ISO and IEEE standards

Teaching is based on SWEBOK +

(1) Access to all standards for all students

(2) Mandatory usage of standards in courseassignments


63/69


64/69



65/69



66/69

GRACIAS !

[email protected] Copyrights 2010 Alain Abran

Guide to the Software Engineering Body of KnowledgeV i


67/69

67

2004 Version

SoftwareConstruction

Software

MaintenanceSoftware Testing

Basic Concepts

of Construction

Managing

Construction

Software

MaintenanceFundamentals

Key Issues in

Software

Maintenance

Techniques for

Maintenance

Sofware

TestingFundamentals

Test Levels

Test Techniques

Test Related

Measures

TestProcess

Software Design

Software DesignFundamentals

Key Issues in

Software Design

Software Structure

and Architecture

Software Design

Quality Analysis

and Evaluation

Software DesignNotations

Software

Requirements

Software

RequirementsFundamentals

Requirements

Process

Requirements

Elicitation

RequirementsSpecification

Requirements

Validation

Requirements

Analysis

Software Design

Strategies andMethods

Practical

Considerations

PracticalConsiderations

MaintenanceProcess

Guide to the Software Engineering Body of Knowledge

(2004 V i )


68/69

Copyrights 2010 Alain Abran68

Related

Disciplines

ComputerScience

Management

Mathematics

Project

management

Quality

management

SoftwareErgonomics

Systemsengineering

Closure

Process

Assessment

Software Design Tools

(2004 Version)

SoftwareConfigurationManagement

SoftwareEngineering Tools

and Methods

SoftwareEngineering

ProcessSoftware Quality

Software

ConfigurationManagement

Fundamentals

KeysIssues in

SCM

SoftwareConfiguration

Control

Software

ConfigurationStatus Accounting

Software

ConfigurationAuditing

Software Release

Management andDelivery Software Methods

Software ToolsProcess

Implementation

and Change

Process andProduct

Measurement

Software QualityFundamentals

Software QualityManagement

Processes

Heuristic Methods

Formal Methods

Prototyping Methods

Software RequirementsTools

Software Testing Tools

Software MaintenanceTools

Software EngineeringProcess Tools

Process

Definition

Practical

Considerations

Software ConstructionTools

Software Quality Tools

Software ConfigurationManagement Tools

Software EngineeringManagement Tools

Infrastructure SupportTools

Miscellaneous ToolIssues

Miscellaneous Method

Issues

SoftwareEngineeringManagement

Initiation andScope

Definition

Software

ProjectPlanning

Software Project

Enactment

Review and

Evaluation

SW Engineering

Measurement

Computer

Engineering


69/69

Software Engineering

IEEE 610.12*:

The application of a systematic, disciplined,

quantifiable approach to the development,operation, and maintenance of software:

i.e. the application of engineering to software.

* IEEE Standard Glossary of Software EngineeringTerminology, 1990.

Documents

Abran Project Management v5