some thoughts on productivity in ict projects: measurable entities, requirements, possible impacts

www.eng.it WSPM/SGPS 2008 – Luigi Buglione © 2008

WSPM/SGPS 2008I° Workshop on Software Projects

Management Madrid, 25 de Septiembre 2008

Luigi Buglione

Some thoughts on Productivity in ICT projectsSome thoughts on Productivity in ICT projects:: measurable entitiesmeasurable entities, , requirementsrequirements, , possible impactspossible impacts

2www.eng.it WSPM/SGPS 2008 – Luigi Buglione © 2008

Goals of the PresentationGoals of the Presentation: G1. To look at the entities to be measured and to be related against stated information goals (project vsvs product) G2. to enlarge the possible project’s requirement taxonomy from ISO/IEC 14143-1 G3. From requirements to WBS: a process-oriented viewG4. Some thoughts on the Productivity definition

Source: • L.Buglione, Some thoughts on Productivity in ICT projects, White Paper, version 1.2, March 2008, URL: www.geocities.com/lbu_measure/fpa/fsm-prod-120e.pdf

http://www.geocities.com/lbu_measure/fpa/fsm-prod-120e.pdf


IntroductionA picture of your project

» Q: which level of control (granularity) has your project?

(a) (b)

or


G1G1. Entities to be measured IPO taxonomy

Resources ProductProcess

Measurement


Resources ProductProcess

Project

Organization/ SBU

Measurement

G1G1. Entities to be measured STAR taxonomy

FSU


G1G1. Entities to be measured Project && Product: another possible view

Container (Project)

Content (Product)


G1G1. Entities to be measured Project “entityentity”: possible dimensions of analysis

ProjectProject

Qu

alityQ

uality

Techn

icalTech

nical

Fun

ctional

Fun

ctional

Oth

erO

ther


G1G1. Entities to be measured Proposal & Side-Effects

• Proposal Clearly state the entity to which a FSM unit refers (product) and to which

dimension pertains (functional) Insert in the ISBSG Glossary of Terms (v. 5.9.1) a definition for “Project Size”

as a sub-item under the “Project” series of definition (currently there is only the “Software Size” definition) Possible inputs: PMBOK 2004

• Side-Effects Relate the “product (functional) size” to the project (functional effort) when

determining the productivity rates Currently there is no indication in the ISBSG data about the % of non-

functional effort expressed by a project; it can be indirectly derived from a certain PDR value by filtering the database according to technology, programming language, etc…


G2G2. Enlarging the ISO/IEC 14143-1 req. taxonomy ISO/IEC 14143-1:2007

SourceSource::

» ISO/IEC14143-1:2007, Information Technology-Software Measurement-Functional Size Measurement-Part 1: Definitions of Concepts: International Organization for Standardization, 2007

» IFPUG, Framework for Functional Sizing, Version 1.0, September 2003), International Function Point User Group, Westerville, Ohio, January 2004, URL: http://www.ifpug.org

• Functional User Requirements (FUR): “a sub-set of the user requirements. The Functional User Requirements represent the user practices and procedures that the software must perform to fulfil the users’ needs. They exclude Quality Requirements and any Technical Requirements” • Quality Requirements: “any requirements relating to software quality as defined in ISO 9126:1991” • Technical Requirements: “requirements relating to the technology and environment, for the development, maintenance, support and execution of the software”

“Functionality” char in ISO 9126-1

http://www.ifpug.org/

http://www.ifpug.org/

http://en.wikipedia.org/wiki/ISO_9126


G2G2. Enlarging the ISO/IEC 14143-1 req. taxonomy Implicit & Explicit Requirements

• Quality (ISO 9000:2005, §3.1.1): Degree to which a set of inherent characteristics fulfils requirements. Note 2: “inherent”, as opposed to “assigned”, means existing in something, especially a

permanent characteristic

• Project (ISO 9000:2005, §3.4.3): unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including the constraints of time, cost and resources.

CMMI, PP: SP1.1


G2G2. Enlarging the ISO/IEC 14143-1 req. taxonomy ISO/IEC 14143-1:2007: a possible fourth type

O

• O (Other req): implicit requirements often refers to other natures than F/Q/T. Typical processes to be considered could be the Organizational & Supportprocesses, in the SPI process models view (i.e. CMMI/ISO 15504)


G2G2. Enlarging the ISO/IEC 14143-1 req. taxonomy Proposal & Side-Effects

• Proposal Consider an enlarged view on ISO/IEC 14143-1 requirements taxonomy,

because the whole project scope should be taken into account. Analyzing a project classifying requirements by type would help to determine

which processes and related tasks should be included or not into a functional count for determining (functional) productivity rates.

Simplifying, the Q/T/O parts can be referred as “NF” (non-functional) Include these concepts and related definitions in the ISBSG Glossary of

Terms (v.5.9.1) Possible inputs: ISO 9000:2005, CMMI (PP, SP1.1), ISO/IEC

14143-1:2007

• Side-Effects The effort from the “O” part is a non-functional one. It could be initially

difficult to isolate such tasks and effort One misleading concept in some ICT professionals is that a FSM unit

measures the whole project


G3G3. From requirements to WBS Requirements, Processes, Tasks

• Project Management view on a project From high-level req (HLR) to tasks into a WBS, through a series of

refinements (RHRL). The “chain” would be:

• Process grouping and effort classification CMMI has four groups of processes: Project, Process, Support, Engineering) ISO 15504 has five groups: Customer, Engineering, Management,

Organizational, Support)

HRL RHLR (process) task

Rule of thumbRule of thumb: functional effort is mainly derived from EngineeringEngineering processes, excluding tasks related to Quality & Technical Requirements, as in ISO 14143-1, and also from the “Other” requirements.


G3G3. From requirements to WBS Proposal & Side-Effects

• Proposal Consider in the analysis the nature of the processes from which a task in the

WBS is derived: it will help in determining the nature of the task itself and, consequently, the nature of the effort (functional vs non-functional effort). Possible inputs: SPI process models (CMMI, ISO 12207/15504, …)

• Side-Effects Possible discussions about the level of granularity for a task, when not too

basic. In such case, a solution is to split a bigger task into two or more refined ones, clarifying the nature of each activity. Otherwise, from a PM-viewpoint, such tasks will be less checkable.

The reference point should be always the process classification applied in an organization, determining what does it mean “functional” and what not. A generic “Testing” activity could include both functional testing and non-functional

testing (i.e. performance tests), but the second one would not be in the scope of a functional counting and relating usages.

I.e., User Manuals refer to the SPICE’s SUP.1 process (Documentation) and the effort to produce it cannot be the expression of a FUR, as meant in ISO/IEC 14143-1 (when misleading the ‘product’ with the ‘project’ entities.


G4G4. Some thoughts on the Productivity Definition Current view & issues

• Common definition of “Productivity” The amount of output created per unit input used Labour productivity is typically measured as output per labour-hour

• “Productivity” and FSMM In ICT project, a productivity figure is FSM unit / (project) work effort An example:

Project type: SAP R/3 enhancement project Application size: 980 FP (project) effort: 1200 man-days (F:850m/d; Q:100; T:150; O:100) Productivity = (FP / Effort) = (980 FP / 1200 m-d) = 0.82 FP/m-d

• Some first-level observations The upper part of the formula refers to a product size unit, valid for the

functional viewpoint, while the lower part of the formula to the whole project. What about the functional productivity? If the effort distribution by type (F/Q/T/O or – at least – F vs NF) is not

known, it could be difficult for a project manager to compare projects with potential different effort profiles, therefore not comparable for benchmarks lower R2 in next estimations



• Q1:Q1: is the ratio (as currently applied) meaningful or not? Overall productivity is underestimated (no “Quality | Technical points”) on the upper

part of the formula to counterbalance the overall project effort on the lower part



• Q2:Q2: what about technical impacts for a project manager? The current productivity value should be usable also for benchmarking

projects with different distributions of the overall effort (among the F/Q/T/O parts)

If the effort referred to Q/T/O tasks will increase: Planning issue: the number of FSM units will not increase, with a formal lower

productivity value Staffing issue:

other roles could be requested (i.e. SOA architects, usability expert, …) and with different costs on the project than traditional functional roles involved into the deployment of FURs.

A generic number of FTE (Full Time Equivalent) to be scheduled in terms of time and costs is only a first-level information to consider in a bid/RFP.



• Q3:Q3: what about the business impacts for a project manager? (project) Cost / FP (product) is a economical figure used in many ICT

contracts, heritage of the ’90s (yet included also in the first edition of IFPUG “Guidelines to Software MeasurementGuidelines to Software Measurement” – 1992)

Two not homogeneous portions in the formula The application of such derived measure for economic purposes could lead:

to do not recognized any economic value for non-functional (NF) tasks in a project or

to overestimate the economic value of a FSM unit in order to comprehend also the NF part of the software application under evaluation, but with a lower price (part of the Functional side)

while they (F/NF) are simply two separated but integrated parts of a project An indirect evidence from the Albrecht’s 1979-84 versions:

VAF’s GSCs reflect non-functional issues and… …the number of GSCs grew up from 10 up to 14, increasing the VAF incidence

from a ±25% to ±35% of UFP… …but ISO yet excluded from 1998 unadjusted versions from current FSM methods


G4G4. Some thoughts on the Productivity Definition Proposal & Side-Effects

• Proposal Three possible applications of the productivity formula:

FSM (product) unit /(project effort), but gathering at least the split of project effort data into F vs NF effort

F/Q/T/O (product) unit /(F/Q/T/O effort): more productivity figures per effort type

(project) unit /(project effort): one overall productivity figures for the whole project, using a unique project size unit

Project Delivery Rate (PDR) is the inverse of productivity (Effort/FP); modify accordingly the ISBSG Glossary of Terms (v.5.9.1)

Insert the “median” definition into the ISBSG Glossary of Terms, stressing its relevance when dealing with size, effort and productivity values in the estimation process, whatever the technique adopted

• Side-Effects More projects with the same productivity level (even if from the same cluster

of projects) could not necessarily represent homogeneous units to be considered for estimation purposes


G4G4. Some thoughts on the Productivity Definition Proposals: an example

Proposal #1: FSM (product) unit /(project effort), but gathering at least the split of project effort data into F vs NF effort

100.01200Total8.3100O

12.5150T8.3100Q

70.8850FEffort (%)Effort (m/d)Req. Type

• Functional (product) size: 980 IFPUG FPs• (project) effort: 1200 man-days as follows:

• Productivity: 980 FP / 1200 m-d = 0.82 FP/m-d• Functional productivity: 980 FP / 850 m-d = 1.15 FP / m-d



Proposal #2: F/Q/T/O (product) unit /(F/Q/T/O effort): more productivity figures per effort type

100.01200Total8.3100O

12.5150T8.3100Q

70.8850FEffort (%)Effort (m/d)Req. Type

• Same hypothesis than before, but having other size units for the Q/T/O parts it will be possible to calculate separately other productivity figures in parallel Q productivity, T productivity, O productivity

• Advantages for planning (effort/cost; a tester does not cost and does not work the same worked time as a project manager) and scheduling (the right role for the right effort) use both mean and median values



Proposal #3: (project) unit /(project effort): one overall productivity figures for the whole project, using a unique project size unit

• Same hypothesis than before, but having a unique size unit for the whole project it will be possible to calculate a high-level, overall productivity figure, to use jointly with detailed figure

• (project) size: 1450 project size units• (project) effort: 1200 man-days• Project productivity: 1450 project size units / 1200 m-d = 1.21 FP / m-d

• Up to day, PMBOK introduces the ‘project size’ term but it is neither defined into in its glossary, nor any suggestion about specific applications/techniques

• Issue to be investigated more (PSU – Project Size Unit - is a possible proposal)

http://www.geocities.com/lbu_measure/psu/psu.htm


Conclusions…

• A software system is one of the work products from a software project; the size units for each entity should be properly used accordingly to the entity and a certain informative goal. a FSU is a product, not a project size unit

• FSM methods pertain only to the functional side of a software system and do not measure the whole system productivity levels should discriminate the possible different parts composing a project ISO/IEC 14143-1 proposed the F/Q/T requirements taxonomy; a fourth group can

be added (“O”ther requirements), referring to those implicit but within the project scope

• Look at the project as composed by several sizes… The functional size is just one of these; other possible ones can be explored more

and more in order to have the right picture on the reality to be represented

• …producing therefore several possible productivity values Having a bird’s-eye-view on the project and crossing the functional size with the

other possible ones will help the project manager in executing a better and more granular control, simply having more info from the same base of project data


…&& Prospects

• Focus more on the measurement of non-functional perspectives i.e. IFPUG is going to propose by the end of 2008 its proposal for “Technical

Points”, with an overview presented last week in Washington at ISMA 2008 This proposal was done last year at ISBSG Workshop and main concepts could be

included in the next “Practical Project Estimation” guide (3°ed.) in 2009.

• Start to introduce a further effort data into project repositories Split (even roughly) effort values into Functional Effort and Non-Functional Effort It will help to have in your organization

• Gather more evidences about this view… If you have more evidences, please share them: the white paper “

Some thoughts on Productivity in ICT Projects” is a living document, updated periodically when new evidences are available and can be shared within the Software Engineering community, on forums and mailing list

A mailing list in Spanish is [calidaddelsoftware]

• …producing therefore several possible productivity values Now it’s time to refine our project data gathering at least on effort data, producing

not only a ‘nominal’ productivity value, but also a separated ‘functional’ productivity value and use the two for better estimates

http://www.geocities.com/lbu_measure/fpa/fsm-prod-120e.pdf

http://es.groups.yahoo.com/group/calidaddelsoftware/message/958


Q && A

¡Gracias por la atenciónGracias por la atención!Thanks for your attentionThanks for your attention!

www.eng.it WSPM/SGPS 2008 – Luigi Buglione © 2008

Engineering.it S.p.A.Via Riccardo Morandi, 32

I-00148 Rome (Italy)www.eng-it.it

LuigiBuglionet +39 06 83074472 m +39 335 [email protected]

http://www.eng-it.it/

some thoughts on productivity in ict projects: measurable entities, requirements, possible impacts

Documents