UKSMA 2005 Lessons Learnt from introducing IT Measurement Peter Thomas –

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Configuration Management
Test Automation Success: Choosing the Right People & Process
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
Project management Project manager must;
How to Document A Business Management System
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Supporting people with a learning disability Introduction to Project Management Presenter: Steve Raw FInstLM, FCMI.
W5HH Principle As applied to Software Projects
Chapter 24 - Quality Management
Welcome ISO9001:2000 Foundation Workshop.
Learning with a Purpose: Learning Management Systems Patti Holub, Director District Initiatives and Special Projects Miguel Guhlin, Director Instructional.
What is Business Analysis Planning & Monitoring?
CS 4310: Software Engineering
Solution Overview for NIPDEC- CDAP July 15, 2005.
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
N By: Md Rezaul Huda Reza n
CO2403 and CO3808 – Quality Management Systems Quality process definition, administration and accreditation.
Chapter 6 : Software Metrics
Quality Control Project Management Unit Credit Value : 4 Essential
Quality Management.  Quality management is becoming increasingly important to the leadership and management of all organisations. I  t is necessary.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 1 Software cost estimation 1.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Chapter 23 Software Cost Estimation.
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Software Estimation How hard can it be? Peter R Hill.
Software cost estimation Predicting the resources required for a software development process 1.
This chapter is extracted from Sommerville’s slides. Text book chapter
BSBPMG505A Manage Project Quality Manage Project Quality Project Quality Processes Diploma of Project Management Qualification Code BSB51507 Unit.
Project monitoring and Control
Overall Quality Assurance, Selecting and managing external consultants and outsourcing Baku Training Module.
Software Project Management Lecture # 3. Outline Chapter 22- “Metrics for Process & Projects”  Measurement  Measures  Metrics  Software Metrics Process.
Georgia Institute of Technology CS 4320 Fall 2003.
IT Infrastructure Management IT Infrastructure Library Best Practice.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 3 1 Software Size Estimation I Material adapted from: Disciplined.
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
1 Chapter 3 1.Quality Management, 2.Software Cost Estimation 3.Process Improvement.
Business Functions, Processes, and Data Requirements
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
Prince 2 and Project Management By Sayed Ahmed Just E.T.C.Technologies Inc. Just E.T.C Education Inc.
Computing and SE II Chapter 15: Software Process Management Er-Yu Ding Software Institute, NJU.
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
©Ian Sommerville 2000Software Engineering, 7th edition. Chapter 26Slide 1 Software cost estimation l Predicting the resources required for a software development.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Version 10.0  The High Performance Organisation Ltd Creating A Process Based Management System 1 Welcome Creating a Process Based Management.
A Metrics Program. Advantages of Collecting Software Quality Metrics Objective assessments as to whether quality requirements are being met can be made.
Software cost estimation. Fundamental estimation questions How much effort is required to complete an activity? How much calendar time is needed to complete.
Project management Topic 1 Project management principles.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Metadata By N.Gopinath AP/CSE Metadata and it’s role in the lifecycle. The collection, maintenance, and deployment of metadata Metadata and tool integration.
The Implementation of BPR Pertemuan 9 Matakuliah: M0734-Business Process Reenginering Tahun: 2010.
Continual Service Improvement Methods & Techniques.
Company LOGO. Company LOGO PE, PMP, PgMP, PME, MCT, PRINCE2 Practitioner.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
“Supply Chain Management Handbook” Supplier Selection and Capability Assessment Model IAQG Leader: Christian Buck – Safran Updated: June 2008.
Software Project Configuration Management
Integrated Management Systems
The Five Secrets of Project Scheduling A PMO Approach
Managing the Project Lifecycle
Identify the Risk of Not Doing BA
The Systems Engineering Context
TechStambha PMP Certification Training
CMMI – Staged Representation
Draft OECD Best Practices for Performance Budgeting
Presentation on Knowledge Management by John Njiri for KATTI
Chapter 13 Quality Management
Project Management Process Groups
Portfolio, Programme and Project
Contemporary Issues of HRM
Presentation transcript:

UKSMA 2005 Lessons Learnt from introducing IT Measurement Peter Thomas –

Topics The IT organisation Measurement – in particular Function Points Lessons Learnt The future Summary

The IT organisation As is –Dedicated local staff committed to customer departments –Little formal Project Management discipline, need to react to customers needs and wants To be –Delivery split between own and IT Services companies –Move work to more formally controlled projects with a measured project delivery rate

FPs enable Productivity Measurement, but other measurements are required to ensure overall delivered quality. Function Points may be used to measure the productivity of the software delivery process –Productivity = FP/100 Hours of project effort Note there is no measure against people A basket of measurements should be put in place to indicate when action is required to keep the software delivery process in balance. –A minimum set of measurements in the basket are: Schedule eg Schedule Days/1000FP Defect Rates eg Defects per delivered FP Customer Satisfaction –Focusing on one element in the basket can lead to aberrant behaviour

Function Point Analysis have more than one flavour A fully auditable value – expensive and not really required for tracking trend line behaviour A reasonable approximation – this is much easier and cheaper if all data and transactions are treated as Average (FP Light) A rough guess – this is of limited value other than an indicator of the effort to produce a better value

FP Light was chosen as the output product Sizing Measure Advantages –Less effort to count Saving is around 50% compared to full IFPUG count Disadvantages –Less accurate as a sizing metric Accuracy is within % Comment: –The accuracy of the FP light number is sufficient since the accuracy obtained on many other measures which go to make up the required metrics set is often even less.

Each Data Flow and Data Store has a set number of FPs. Content Management Product History Update Product Maintain Policy Product Inquiry Administrator Customer Products Policy Agent Select Sales Product Information Policy Information Data Flows Data ILF = 10 FP EIF = 7 FP EI = 4 FP EO = 5 FP EQ = 4 FP Function Point Light Definitions Administrator Policy Details internal external

Lessons Learnt - Training FP training for IT professionals is available from a number of suppliers but staff churn means that the training requirement is an on-going requirement

culture, comparison Culture –The management team using the metrics needs to provide sponsorship, promotion and direction to enable them to be successfully embedded in the culture –(This presentation is a variant of the one shared with them) Comparison –When using productivity to assess the software process (and/or setting productivity targets), areas of the organisation with similar project attributes should be chosen. There are hard and easy function points – compare with care –Many factors affect the productivity achieved on any given project. Project Type, Platform, Architecture, Software framework, None coding effort, Skill and experience levels, Process, Tools etc etc etc

Exceptions & Effort Exceptions –FP Lite Not a useful metric for every component or every project must decide how to handle these exceptions Project effort –It is important for consistency that the set of activities for which the effort is measured against FP size is the same on a project by project basis within component areas. –For accurate assessment of productivity the resource must correspond to the delivery FP counted.  a suitable level of detail to allow analysis by role and stage where appropriate “non countable” activities and their resource should be excluded from the measurement Event / Milestone which determines the start and end of the project and or phase also needs agreeing. These should fit with the hand off and hand in of work given to the external teams.

Process To count FPs, the analysis workshops need to be built into the standard development lifecycles. Metrics group must have a method of recognising when a project is due an FP count. A FP number should be required before project closure is accepted. The metrics group and FP Analysts provide but do not own the data. They are not in a position to make decisions based on the measurements, ie to change the software development lifecycles. Techniques to utilise the data must developed What are the questions? Is the data sufficient? What can be safely compared & summed

Human Resources –If project staff fear that they are not producing enough Function Points, they will be tempted to inflate the value whenever possible to make the figures reflect themselves in a positive light. –If FP counting is applied inappropriately it will lose credibility The Metrics group will need management support to ensure –counts are performed according to the rules. –exceptions are recognised –inappropriate comparisons are avoided –analysis is appropriate »not simply a global average

Boundaries & documentation Boundaries –FPs need to count flows across and data within application boundaries The setting of a standard set of boundaries within NUL is therefore vital for consistency of FP counts Process Documentation –FP counting is made easier with FP friendly documentation. Every effort should be made to make the standard documentation set FP friendly.

The future use of Function Points can be expanded to provide project support Requirements validation –Function Point analysis tests the requirements (and high level design) documentation and models for usability and completeness. The Analyst can raise queries and issues which can avoid the project becoming troubled. Need an early FP count and a repeat count for each major change Help in the validation of project estimates. –Carrying out an early Function Point estimate will allow project estimates to be validated based on historical productivity figures. Need a database of historical project data and an early FP count. Help in tracking of projects using a modified Earned Value process. –Function points delivered during the project lifecycle may be reported against expected delivery.

Summary The FP rollout is going well –The organisation now has the capability to size projects and software –Therefore can implement the correct measures to decide whether initiatives are improving or worsening the IT capability Lessons Learnt –Executive and management support can resolve these Future holds additional benefits –Better estimating –Better project management discipline, particularly requirements & test management