1 / 38

Project Management

Project Management. Metrics. Introduction. Pressman identifies the key elements of software project management as: beginning a software project measures and metrics estimation risk analysis scheduling tracking and control. Beginning a Software Project.

brady-oliver
Download Presentation

Project Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project Management Metrics

  2. Introduction • Pressman identifies the key elements of software project management as: • beginning a software project • measures and metrics • estimation • risk analysis • scheduling • tracking and control

  3. Beginning a Software Project • Before a project can be planned, objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified. • Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, a realistic breakdown of project tasks, or a manageable project schedule that provides meaningful indication of progress.

  4. Project Objectives and Scope • The software developer and customer must meet to define project objectives and scope. • Objectives identify the overall goals of the project without considering how these goals will be achieved. • Scope identifies the primary functions that software is to accomplish, and more importantly, attempts to bound these functions in a quantitative manner.

  5. Statement of Requirements • Ince, Sharp and Woodman (Introduction to Software Project Management and Quality Assurance) identify the starting point of any project as a document which is prepared by the customer for a system, known as the statement of requirements. • This is in natural language, can be a few pages in length or a number of volumes, and is probably couched in terms of the customer's business.

  6. Requirements Analysis • Given the statement of requirements the developer has to carry out the processes of requirements analysis: analyse the statement of requirements and extract and clarify the functions and constraints. • This involves interaction with the customer and could be the most difficult part of the software project.

  7. Requirements analysis is difficult for two main reasons: • "culture gap" between customer and developer • statement of requirements may exhibit properties which make requirements analysis difficult; examples are:-

  8. functional and non-functional requirements (constraints) are intermingled • statement of requirements contains ambiguities • statement of requirements contains platitudes • statement of requirements contains design and implementation directives • statement of requirements is often incomplete • functions are described at different levels of detail

  9. System Specification • The aim of requirements analysis is to write down, in an unambiguous way, what a proposed system should do (its functions), and what the constraints are on the developer. • The document produced is often called the system specification. It is the key document on which all subsequent activities in the software project depend.

  10. Functional Specification • The functional specification should be • unambiguous • free of design and implementation directives • in a form which enables the developer to reason about the properties of the system it describes • partitioned • free of any extraneous detail • understandable by the customer • A system design document also has these properties (with the exception of the last one.)

  11. Measures and Metrics • In most technical endeavours, measurement and metrics help us to understand the technical process that is used to develop a product and the product itself. • The process is measured in an effort to improve it. • The product is measured in an effort to increase its quality.

  12. What to measure? • At first, it would seem that measurement is self-evident. After all, measurement enables us to quantify and therefore manage more effectively. But reality can be somewhat different. Measurement often leads to controversy and argument. • What are appropriate metrics for the process and the product? • How should the data that are collected be used? • Is it fair to use measurements to compare people, processes, or products?

  13. Why measure software? • to indicate the quality of the product • to access the productivity of the people who produce the product • to assess the benefits derived from new software engineering methods and tools • to form a baseline for estimation • to help justify requests for new tools or additional training

  14. Software Metrics • A software metric is a numerical measure of a product or process that is part of a software project. • Software metrics are useful to the project manager because they provide clear and precise information about the progress of a project, and so are useful for monitoring project progress. • "Once something can be measured, you move away from the world of opinion towards the world of fact."

  15. Useful software metrics • A truly useful software metric must be:- • measurable; based on facts not opinions • independent; project team members should not be able to alter its value without affecting the quality of the software • accountable; details about how and when the metric was measured should be documented • precise; the level of tolerance allowed when measuring it should be known

  16. Types of metric • result • predictor • direct • indirect • productivity • technical • quality

  17. Alternative categorisation • size-oriented metrics, used to collect direct measures of software engineering output and quality • function-oriented metrics,used to collect indirect measures of software engineering output and quality • human-oriented metrics, collect information about the manner in which people develop software and human perceptions about effectiveness of tools and methods.

  18. Size-oriented Metrics • Size-oriented software metrics are direct measures of software and the process by which it is developed. • If a software organisation maintains simple records, a table of size-oriented data can be created. • From the data contained in the table, a set of simple size-oriented productivity and quality metrics can be developed for each project.

  19. Productivity = KLOC/person-month • Quality = defects/KLOC • In addition, other interesting metrics may be computed: • Cost = $/LOC • Documentation = pages of documentation/KLO • Averages can be computed for all projects.

  20. LOC • Size-oriented metrics are controversial and are not universally accepted as the best way to measure the process of software development. Most of the controversy swirls around the use of lines of code as a key measure. • Proponents of the LOC measure claim that LOC is an "artifact" of all software development projects that can be easily counted, that many existing software estimation models use LOC or KLOC as a key input, and that a large body of literature and data predicated on LOC already exists.

  21. LOC • On the other hand, opponents claim that: • LOC measures are programming-language dependent, • they penalise well-designed but shorter programs, • they cannot easily accommodate nonprocedural languages, • their use in estimation requires a level of detail that may be difficult to achieve (i.e., the planner must estimate the LOC to be produced long before analysis and design have been completed)

  22. Function-oriented Metrics • Function-oriented software metrics are indirect measures of software and the process by which it is developed. Rather than counting LOC, function-oriented metrics focus on program "functionality" or "utility." • Function-oriented metrics were first proposed by Albrecht in 1979, who suggested a productivity measurement approach called the function point method.

  23. Function Points • Function points (FPs) are derived using an empirical relationship based on countable measures of software's information domain and assessments of software complexity. • Five information domain characteristics are determined and counts are provided in the appropriate table location.

  24. Domain Characteristics • Number of user inputs. • Number of user outputs. • Number of user inquiries. • Number of files. • Number of external interfaces.

  25. Number of user inputs • Each user input that provides distinct application-oriented data to the software is counted. • Inputs should be distinguished from inquiries which are counted separately.

  26. Number of user outputs • Each user output that provides application-oriented information to the user is counted. • In this context "output" refers to reports, screens, error messages, etc. • Individual data items within a report are not counted separately.

  27. Number of user inquiries • An inquiry is defined as an online input that results in the generation of some immediate software response in the form of an online output. • Each distinct inquiry is counted.

  28. Number of files • Each logical master file, i.e., a logical grouping of data that may be one part of a large database or a separate file, is counted.

  29. Number of external interfaces • All machine-readable interfaces (e.g. data files on tape or disk) that are used to transmit information to another system are counted.

  30. Computing FPs FP = count-total x [0.65 + 0.01 x SUM(Fi)] where • count-total is the sum of all FP entries obtained from the table, • Fi (i = 1 to 14) are "complexity adjustment values" based on responses to questions noted in the following table. • The constant values in the above equation and the weighting factors that are applied to information domain counts are determined empirically.

  31. Uses of FPs • Once function points have been calculated, they are used in a manner analogous to LOC as a measure of software productivity, quality, and other attributes: • Productivity = FP/personmonth • Quality = defects/FP • Cost = $/FP • Documentation = pages of documentation/FP

  32. Adjustment factors • Does the system require reliable backup and recovery? • Are data communications required? • Are there distributed processing functions? . • Is performance critical? • Will the system run in an existing, heavily utilized operational environment? • Does the system require online data entry? • Does the online data entry require the input transaction to be built over multiple screens or operations?

  33. Adjustment factors • Are the master files updated online? • Are the inputs, outputs, files, or inquiries complex? • Is the internal processing complex? • Is the code designed to be reusable? • Are conversion and installation included in the design? • Is the system designed for multiple installations in different organisations? • Is the application designed to facilitate change and ease of use by the user?

  34. Computing Function Points Rate each factor on a scale of 0 to 5 • 0= no influence • 1= incidental • 2= moderate • 3= average • 4= significant • 5= essential

  35. Proponents claim ... • The function point (or feature point) metric, like LOC, is controversial. • Proponents claim that FP is programming-language independent, making it ideal for applications using conventional and nonprocedural languages; • they also claim that it is based on data that are more likely to be known early in the evolution of a project, making FP more attractive as an estimation approach.

  36. Opponents claim ... • Opponents claim that the method requires some "sleight of hand" in that computation is based in part on subjective, rather than objective, data; • that information domain information can be difficult to collect after-the-fact; and • that FP has no direct physical meaning - it's just a number.

More Related