SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3

SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3

SOFTWARE METRICS FOR PROCESS AND PROJECTS
Software Process Metrics and Project Metrics are Quantitative Measures that enable Software Professionals to gain insight into the efficacy of Software Process and the Project that are conducted using the Process as a Framework. Quality and Productivity data are collected, analysed and compared against past averages to :- - Assess Productivity improvements. - Pinpoint Problem areas

WHO DOES IT ? Software Measures are often collected by Software Engineers/ Software Practitioner. Software Metrics are analyzed and assesses by Software Managers. WHY METRICS IS IMPORTANT? If you do not measure, your judgment can be based only on subjective evaluations With Measurement:- - Trends can be spotted, - Better estimates can be made, - True improvement can be accomplished

WHAT ARE THE STEPS? 1. Defining a limited set of Process and Project that are easy to collect. 2. The result is analyzed and compared to ‘’Past Average’’ for similar Project performed within the organization Trends are assessed and conclusions are generated. WORK PRODUCT? A set of Software Metrics that provide insight into the Process and understanding of the Project. - Productivity Metrics - Quality Metrics

REASONS FOR MEASURING To Characterize To Evaluate To Predict To Improve Measurement is a Management Tool. Measurement provides a Project Manager with insight. It assists Manager and Project team in making sound decision.

Project Metrics are collected across all Projects and over long periods of time. Their intent is to provide a set of Process Indicators that lead to long term Software Process improvement. Project Metrics enable Project Managers to: Assess the status of an ongoing Project Track potential Risks Uncover Problem areas before they “Go critical” Adjust work flow or Tasks Evaluate the Project Team’s ability to Control Quality of Software Work Product. Measures that are collected by a Project team and converted into Metrics for use during a Project can also be transmitted to those with responsibility for Software Process improvement. For this reason, many of the same Metrics are used in both the Process and Project domain. SOFTWARE METRICS FOR PROCESS AND PROJECTS

The only Rational way to improve any Process is to: a) Measure Specific attributes of the Process b) Develop a set of meaningful Metrics based on these attributes c) Use Metrics to provide Indicator that will lead to strategy for improvement However it is important to note that Process is only one of a number of ‘’Controllable Factors’’ in improving Software Quality and Organizational performance. SOFTWARE METRICS FOR PROCESS AND PROJECTS

BUSINES CONDITIONS CUSTOMER CHARACTERISTICS DEVELOPMENT ENVIRONMENT PEOPLE TECHNOLOGY PRODUCT

The Figure shows the Process in the centre of a triangle connecting three Factors that have profound influence on Software Quality and Organizational Performance. The Skills and the Motivation of people has been shown to be the single influential factor in Quality and Performance. The Complexity of Product can have a substantial impact on Quality and Project Team Performance. The Technology (Methods and Tools) that populates the Process has an impact. The Process Triangle exists within a circle of Environmental Conditions that include the Development Environment (CASE TOOLS, Business Conditions (Deadlines, Business rules), and Customer Characteristics (ease of communication and collaboration etc)

We measuring the efficacy of Software Process “indirectly”. We derive a Set of Metrics based on the Outcomes that can be derived from Process. Outcomes include Measures of:- - Errors uncovered before release of Software, - Defects delivered to and reported by end-users, Work Products delivered (Productivity), - Human effort expanded, - Calendar time expanded, - Schedule conformance - Other measures. We also derive Process Metrics by measuring the Characteristics of specific Software Engineering Task. (E.g. we might measure the Effort and Time spent performing the Generic Software Engineering Activities.)

There are ‘’Private’’ and ‘’Public’’ use of Different Types of Process Data . It is natural that individual Software Engineers might be sensitive to use Metrics collected on an individual basis, these data should be Private to the individual and serve as an Indicator for the Individual only. e.g. Defect Rates by individual, Defect Rates by Software components, and error found during Development. Some Process Metrics are Private to the Software Project Team but Public to all Team members. (e.g. Defects reported for major Software functions that have been developed by a number of Engineers. Errors found during Technical Reviews, and Lines Of Code (LOC) or Function Point (FP) per Component or Function. These data are received by the Project Team to uncover Indicators that can improve Team performance. Public Metrics generally assimilate information that originally was private to an individual or a Project Team. (e.g. Project level defect rates, , Effort, Calendar Times, and Related data are collected and evaluated in an attempt to uncover Indicators that can improve Organizational Process Performance.

Software Process Metrics can provide significant Benefits as an Organization works to improve its overall level of Process Maturity. However like all Metrics,, these can be misused, creating more problems that they solve. SOFTWARE METRICS ETIQUETTE Suggested by Grady that is appropriate for both Managers and practitioners as they institute a Process Metrics Program. 1. Use common sense and organizational sensitivity, when interpreting Metrics. 2. Provide regular feedback to the individual and Teams who collect measures and Metrics. 3. Do not use Metrics to appraise individual. 4. Work with Practitioners and Teams to set clear goals and Metrics that will be used to achieve them 5. Never use Metrics to threaten individual or Teams. 6. Do not consider Metrics data that indicate a problem area as negative. These data are merely an indicator for process improvement Consider it as and Indicator for Process improvement. Don’t obsess on a single Metric to the exclusion of other important Metrics. As an Organization becomes more comfortable with the collection and use of Process Metrics, the derivation of simple Indicators gives way to a more rigours approach called (SSPI) “Statistical Software Process Improvement (SSPI). SSPI uses Software Failure Analysis to collect information about all errors and defects. Encountered as an Application, System, or Product is developed and used. SOFTWARE METRICS FOR PROCESS AND PROJECTS

Software Project Metrics are tactical as opposed to the Software Process Metrics which are used for Strategic purposes.. Project Metrics and Indicators are used by a Project manager and a Software Team to adapt Project Workflow and technical activities. The first application of Project Metrics on most Software Projects occur during Estimation. Metrics collected from past Projects are used as a basis from which ‘’Effort’’ and ‘’Time’’ Estimates are made for current Software work. As a Project proceeds, measures of ‘’Effort’’ and ‘’Calendar Time’’ expended are compared to original Estimates. The Project Manager uses data to monitor and Control progress. As Technical work commences, other Project Metrics begin to have significance Production Rates represented in terms of Models created, Review Hours, Function Points, and Delivered Source Code lines are measured. Errors uncovered during each Engineering tasks are tracked. As the Software evolves from Requirements into Design, Technical Metrics are collected to assess Design Quality and provide Indicators that will influence the approach taken to Software code generation and Testing. SOFTWARE METRICS FOR PROCESS AND PROJECTS

THE PURPOSES OF PROJECT METRICS a) To Minimize the Project Development Schedule by making the necessary adjustments to avoid delays and mitigate potential problems and risks. To Asses Product Quality on an ongoing basis and, when necessary, modify the Technical approach to improve Quality. As Quality improves the Defects are minimized, and as the Defect counts goes down, the amount of rework required during the Project is also reduced. This leads to a reduction in overall Project Costs. SOFTWARE METRICS FOR PROCESS AND PROJECTS

PROJECT METRICS APPLICATIONS - During ‘’Project Estimation Metrics collected from the past Projects are used as a basis from which ‘‘Effort and Time Estimates’’ are made for current Software work. - As Project proceeds, Measures of Effort and Calendar Time expended ( Actual Times) are compared to Planned (Original) Estimates. As Technical work commences Other Project Metrics rates begin to have significance. Such rates include:- - Production Rates - Review Hours, - Function Points - Delivered Line of Source Codes (LOC) As the Software evolves from Requirements into Design, Technical Metrics are collected to assess Design Quality and to provide indicators that influence approach taken to Code Generation & Testing.

Software Project Metrics are tactical as opposed to the Software Process Metrics. Project Metrics and Indicators are used by a Project manager and a Software Team to adapt Project Workflow and technical activities. The first application of Project Metrics on most Software Projects occur during Estimation. THE PURPOSES OF PROJECT METRICS a) To Minimize the Project Development Schedule by making the necessary adjustments to avoid delays and mitigate potential problems and risks. To Asses Product Quality on an ongoing basis and, when necessary modify the technical approach to improve Quality. As Quality improves the Defects are minimized and as the Defect counts goes down, the amount of rework is also reduced. This leads to a reduction in overall Project Costs.

SOFTWARE MEASUREMENT Direct Measurement Indirect Measurement Direct Measurements of Software Process includes: - Cost and Effort applied. Direct Measurements of Product includes: - Lines of Code (LOC) Produced, - Execution Speed Memory size Defect reported over a set period of time Indirect Measurements Of Product includes - Functionality - Quality - Complexity - Efficiency - Reliability - Maintainability and many others… SOFTWARE METRICS FOR PROCESS AND PROJECTS

Size Oriented Metrics are derived by normalizing Quality and/or Productivity Measures by considering the Size of Software that has been produced. SIZE-ORIENTED METRICS Errors / KLOC Defect / KLOC - $ / KLOC - Page of Document / KLOC Other interesting Metrics can be computed such as:- - Errors / Person-Month - LOC / Person-Month - $ / Pages of Documentation Note: KLOC (Thousand of Lines of Code)

SIZE-ORIENTED METRICS The Table below lists each Software Development Project that has been completed over the past few years and corresponding Measures for that Project. REFERRING TO Project A , Lines of Code (LOC) were developed with in 24 Person- Months of Effort at a cost of $ The Effort and Cost recorded in the table represents all Software Engineering Activities i.e. Analysis, Design, Code, and Test) Project A also indicates that 365 Pages of Documentation were developed, 134 Errors were recorded before the Software released, and 29 Defects were encountered after release to the Customer within the first year of operation. 3 Software Engineer worked on Project A development.

We can calculate the following Size Oriented Metrics from the table or each Projects: e.g. for Project A - Errors / KLOC (134 / 12.1 = 11.07) Defect / KLOC (29 / 12.1 = 2.4 ) - $ / KLOC ( / 12.1= ) - Page of Document / KLOC (365 / 12.1 = 31.7) Note: KLOC (Thousand of Lines of Code. (eg LOC = 12.1 KLOC) Other interesting Metrics can be computed such as:- - Errors / Person-Month (134 / 24 = ) - LOC / Person-Month ( / 24 = 504 ) - $ / Pages of Documentation ( / 365 = )

WHY SIZE-ORIENTED METRICS ARE NOT UNIVERSALLY ACCEPTED? PROPONENTS Argues that LOC is an “Artifact” of Software Development Projects that can be easily counted. Many existing software Estimation Models use LOC or KLOC as the input and that a large body of literature and data predicted on LOC already exists OPPONENTS Argues that LOC measures are Programming Language dependent, that when Productivity is considered, they penalize well designed but shorter Programs, that they can not easily accommodate Non-procedural Languages. Thus, their use in Project Estimation require a level of detail that may be difficult to achieve. (i.e . The Project Planner must Estimate the LOC to be produced long before Analysis and Design have been completed. SOFTWARE METRICS FOR PROCESS AND PROJECTS

FUNCTION-ORIENTED SOFTWARE MERTICS Function-Oriented Software Metrics use Measure of “Functionality” delivered by the Software Application as a Normalization value. The most widely used Function-oriented Metrics is FUNCTION POINT (FP) Computation of Function Point is based on characteristic of the Software’s Information Domains and the complexity F actors. The Function Point Measure is also controversial like LOC Measures. SOFTWARE METRICS FOR PROCESS AND PROJECTS

The Arguments of Proponents and Opponents of Functional-Oriented metrics: POPONENTS Claim that Function Point (FP) is Programming Language independent, thus making it ideal for applications using Procedural (conventional) and non- Procedural Programming Languages. OPPONENTS Claim that the method requires some ‘’slight of hands’’ in that Function Point computation is based on subjective rather than objective data, that the counts of the Information Domain (and other dimensions) can be difficult to collect after the fact, and that FP has no direct physical meaning; It’s just a number. Function Points (FP) are derived using an Empirical Relationship.

SO SOFTWARE METRICS FOR PROCESS AND PROJECTS
Function Points (FP) are computed by completing the ‘’Five Information Domain Characteristics’’ that are determined and Counts are placed in a table. THE FIVE INFORMATION DOMAINS for Function Points calculation 1. Number of Inputs 2. Number of Outputs 3. Number of User Enquiries 4. No. Of Files 5. No. of External Interfaces THE COMPLEXITY FACTORS of the System FP = COUNT TOTAL * [ * ∑ ( fi )] Complexity Adjustment Factor

COMPLEXITY FACTOR ASSUMPTIONS (Based on the answers to the following 14 Questions) FACTOR VALUE ( fi ). 1. Back-up and Recovery ? 2. Data Communication ? 3. Distributed Processing ? 4. Performance Critical ? 5. Existing Operational Environment ? 6. On-line Data Entry ? 7. Input transactions over multiple Screens? 8. Online Updates ? 9. Information Domain Values Complex ? 10. Internal Processing Complex? 11 Code Designed for reuse? 12. Conversion / installation in Design? 13. Multiple Installations? 14. Application Designed for change ? ============================================================ ∑ (fi) (52)

FUNCTION-ORIENTED METRICS ERROR / FP DEFECTS / FP $ / FP PAGES / FP FP / PERSON- MONTH RELATIONSIONSHIP BETWEEN LOC AND FP The relationship between LINES OF CODE (LOC) and FUNCTION POINTS (FP) depends on Programming Language that is used to implement the Software and the Quality of the Design. The Average number of Lines of Code required to build one Function Point in various Programming Languages. Programming Language LOC/FP AVERAGE C C VISUAL BASIC SQL As you can see that one LOC of C++ provides approx. 2.4 times the Functionality as one LOC of C. SOFTWARE METRICS FOR PROCESS AND PROJECTS

LOC and FP measure are often used to derive Productivity Metrics. However it is debatable to appraise the Performance of individual by using these Metrics, since many factors influence Productivity. FP and LOC based Metrics have been found to be relatively accurate Predictors (Estimates) of Software Development Effort and Cost.. In order to use LOC and FP for Estimation, a historical baseline of Information must be established.

Within the context of Process and Project Metrics, we are concerned with Productivity and Quality measurers of ‘’Software Development Output’’ as a Function of Effort and Time applied and measures of the ‘’Fitness For Use’’ of the Work Products that are produced. However, for the Process improvement and Project Planning purposes 0ur interest is historical. What was the Software Development Productivity on past Projects? What was the Quality of the of Software that was produced? How can the Past Productivity and Quality data extrapolated to present? How can it help us improve the Process and Plan new Projects more accurately?

OBJECT- ORIENTED PROJECT METRICS Conventional Software Project Metrics such as LOC and FP Metrics can be used to estimate O-O Projects However, Conventional Metrics do not provide enough granularity for the Project Schedule and Effort Adjustments that are required as we iterate through Evolutionary incremental Process Method for O-O Projects. Object-Oriented Project Metrics Set :- - No. Of Scenario Scripts - No. Of Key (Foundation) Classes - No. of Support Classes - Average No. Of Support Class / Key Class - No. Of Sub-systems

Number Of Scenario Scripts A Scenario Script is a detailed sequence of steps that describes the interaction between the User and the Application. The number of Scenario Scripts directly correlated to the Size of the application and to the number of Test Cases that must be developed to exercise the System once it is constructed. Number Of Key Classes (Foundation Classes) Key or Foundation Classes are highly independent Components that are defined in Object- Oriented Analysis. Because Key Classes are central to the Problem Domain , the Number of such Classes is an indicator of”: The Amount of Effort required to develop the Software The potential Amount of Reuse to be applied during the development.

Number of Support Classes Support Classes are required to implement the System but are not immediately related to the Problem Domain. (e.g User Interface Classes, Database Access and Manipulation Classes , Computation Classes) In addition a Support Class can be developed for each of the Key Classes. Thus, the Number of Support classes is an indication of the amount of Effort to develop the Software and an indication of potential amount of Reuse to be applied during Development Average Number of Support Class per Key Class - Key Classes are usually known early in the Project. - Support Classes are defined during the development. If the Average number is known for a given Problem Domain, estimating would be much simpler. Lorenz and Kidd suggest that:- Applications with a GUI have between 2 and 3 times the number of Support Classes as Key Classes. Applications with Non-GUI have between 1 and 2 times the number of Support Classes as Key Classes.

Number of Subsystems A Sub-system is an aggregation of Classes that support a Function that is visible to the end-user of a system. Once Subsystems are identified , it is easier to lay out a reasonable Schedule in which work on Subsystems is partitioned among Project staff.

USE OF OBJECT-ORIENTED METRICS To use Metrics effectively in an Object-Oriented Software Engineering Environment, metrics must be collected along with the Project Measurers such as: Effort Expended - Errors and Defects uncovered - Models or Document Pages produced. As the Project Database grow with Object-oriented Projects, relationships between O-O Measures and Project Measures will provide Metrics that can aid in Project Estimation.

USE-CASE ORIENTED METRICS Use-Case can be used as a Normalization Measurers similar to LOC or FP. Like the FP Use-Case, is defined early in the Software Process allowing it to be used for Project Estimation before significant Modeling and Construction activities are initiated. Use Cases describe User-visible functions and futures that are basic requirements for a system Use-case is also independent of Programming Languages. Also the Number of Use-Case is directly proportional to the Size of the Application in LOC and the Number of Test Cases that will have to be designed to fully exercise the Application.

CRITICISM ABOUT USE-CASE ORIENTED METRICS Use-case can be created at many different levels of abstraction thus, there is no standard Size for a Use-case. - Without a Standard Measure of what a Use-case is, its application as a Normalization measure (e.g. Effort expanded per Use-case) is suspect. Although a number of researchers have attempted to derive Use-case Metrics, much work remains to be done.

WEB ENGINEERING PROJECT METRICS Measures and Metrics used for Traditional Software Engineering Project are difficult to translate directly to Web-Apps. Yet a Web Engineering organization will have to collect Measurers and build a Database that allow it to assess its internal Productivity and Quality over a number of Projects. Among the Measurers that can be collected for WEB Engineering Projects are: No. of Static Web Pages No. of Dynamic Web Pages No. of Internal Page Links No. of External System interfaces No. of Persistent Data Objects No. of Static Content Objects No. of Dynamic Content Objects No. of Executable Functions

WEB ENGINEERING PROJECT METRICS NO. OF STATIC WEB PAGES Web Pages with Static content are the most common of all Web – Applications. These Pages represent ‘’Low relative complexity’’ and generally require less effort to construct than Dynamic pages. This measure provide the overall Size of the Application and the Effort required to develop it. NO. OF DYNAMIC PAGES Are essential for e-commerce Applications an Search Engines, Financial Applications and may other WebApps. These pages represents ‘’Higher relative Complexity’’ and thus require more Effort to construct than Static pages. This measure also provide the overall Size of the Application and the Effort required to develop it.

NO. OF INTERNAL PAGE LINKS Are Pointers that provide a Hyperlink to some other Web pages within the WebApp. This measure provides an indication of the degree of Architectural coupling within the WebApp. As the Link pages increases, the Effort expended on designing and constructing Navigations. NO. OF EXTERNAL SYSTEMS INTERFACED WebApps must often interface with ‘’Backroom Business Applications’’. As the requirements for External interfacing grow, System complexity and development effort increases. NO. OF PERSISTENT DATA OBJECTS One or more Database files may be accessed by a WebApp. As the number of required files grow, the complexity of WebApp also grow and Effort to Implement it increases proportionally.

NO. OF STATIC CONTENT OBJECTS A Static content objects may contain text, graphic, video, animation and audio information. A Multiple content Objects may appear on a single Web Page increasing the complexity. NO. OF DYNAMIC CONTENT OBJECTS Dynamic Content Object are generated based on User actions and encompasses internally generated text, graphic, video, animation and audio information that are incorporated within WebApp. Multiple content Objects may appear on a single Web Page.

WEB ENGINEERING PROJECT METRICS NO. OF EXECUTABLE FUNCTIONS An Executable function (also called Script or Applet) provides some conceptual service to the end-user. As the number of Functions increases, Modeling and construction Effort also increases. Each of the above Measures can be determined at a relatively early stage of the Web Engineering Process. Web Application Metrics can be computed and correlated with Project Measures such as :- - Effort Expanded - Errors and Defects uncovered - Models or Document Pages produced. WebApp Measures and Project Measures provide Metrics that can aid in Project Estimation.

METRICS FOR SOFTWARE QUALITY The overriding Goal of Software Engineering is to produce a High-quality Application System within a ‘’Time-frame that satisfy a market need. HOW TO ACHIEVE THIS GOAL, By applying effective Methods coupled with modern Development Tools within the context of a mature Software Process. Taking measures continuously to ensure high quality.

METRICS FOR SOFTWARE QUALITY The Primary source of quality measurers at the Project-level is ‘Errors and Defects’. Metrics derived from Errors and Defects provide an indication of the effectiveness of Software Quality assurance and Control activities. Error data can also be used compute the ‘Defect Removal Efficiency (DRE)’ QUALITY METRICS that are derived from Errors / Defects - Product Errors Per Function Point - Errors uncovered per review hours - Errors uncovered per Testing hour

METRICS FOR SOFTWARE QUALITY MEASURING QUALITY There are many Measures of Software Quality; But the following Four measures provide useful indicators for the Project Team. - Software Correctness - Software Maintainability - Software Integrity - Software Usability

METRICS FOR SOFTWARE QUALITY 1. SOFTWARE CORRECTNESS Correctness is the degree to which the software performs its required function. Most common measures for Correctness is:- - DEFECTS / KLOC, Defects are these problems that are reported by Users after the Software has been released for general use. For Quality assessment, Defects are counted over a standard period of time, typically for one year.

METRICS FOR SOFTWARE QUALITY 2. SOFTWARE MAINTAINABILITY Maintainability is the ease with which a program can be corrected when an error is encountered, adapted if its environmental changes, or enhanced if the customer desires a change in requirements. There is no way to measure Maintainability directly so we must use indirect measurements. Mean Time To Change Time-(MTTC), which is a simple Time- oriented Metrics can be used to Analyze the changes required, Design the appropriate modification, Test, Implement and distribute the changes to all users. Programs that are maintainable have a lower MTTC than the programs that are not maintainable.

METRICS FOR SOFTWARE QUALITY 3. SOFTWARE INTEGRITY This attribute measures a System ability to withstand both accidental and intentional attacks to its security. Attacks can be made on all three components of a Software (i.e. Programs, Data and Documents.) Integrity has become extremely important in the age of ‘’Hackers and Firewalls’’ To measure Integrity two other attributes need to be defined THREAT Probability - SECURITY Probability

Threat Probability - that an attack of a specific type will Occur within a given time SECURITY Probability - that the attack of a specific type will be repelled. INTEGRITY = ∑ [1 – (THREAT Probability * (1 – SECURITY))] Where Threat and Security are summed Over each type of attack. Example1 :- If Threat Probability is 25% and Security (Likelihood of repelling an attack) is 95% the integrity of System is % Which is Very High. Example 2 If Threat Probability is 50% and the Security is 25% then the System’s Integrity is 62.5%, which is unacceptably low. Integrity = ∑ [1 - (0,50 * (1 – 0,25))] = [1 - (0,50 * (0,75))] = [1 - (0,375)] = 0,625 or 62,5 % SOFTWARE METRICS FOR PROCESS AND PROJECTS

METRICS FOR SOFTWARE QUALITY 4. SOFTWARE USABILITY Usability is an attempt to quantify User-friendliness and can be measured in terms of the following four characteristics. USABILITY CHARACTERISTICS The physical and / or intellectual skill required to learn the System. The time required to become moderately efficient in the use of the system. The net increase in productivity measured when the system is used by someone who is moderately efficient. A subjective assessment of Users’ attitudes towards the System. If a Program is a not User-friendly it is doomed to failure, even its functions are valuable. SO SOFTWARE METRICS FOR PROCESS AND PROJECTS

METRICS FOR SOFTWARE QUALITY DEFECT REMOVAL EFFICIENCY Defect Removal Efficiency (DRE) in essence is a Measure of filtering ability of Quality Assurance and Control activities as they are applied through all Process Framework Activities. DRE is a Quality Assurance Metrics that provides benefits of both the Project and Process level. DRE = E / (E + D) Where: (E) No. of Errors before delivery to User. (D) No. of Defects found by users after delivery. The ideal DRE value is “1” or 100% That is no Defect found in Software. Realistically (D) will be greater than 0, but the value of DRE can still approach 1. As (E) increases, it is likely that the overall Value of (D) will decrease. Example : 20 errors before delivery to users 8 Defects reported by Users after delivery DRE = 20 / (20 + 8) => 20 / 28 = 0,714 or 71,4 %

DEFECT REMOVAL EFFICIENCY DRE encourages a Software Project team to institute technique for finding errors before delivery. DRE can also be used within the Project to Asses a Team’s ability to find Errors before they are passed to the next Process Framework activity of Software Engineering task. For example: Errors that are not found during the Reviews of Analysis Phase are passed on to the Design Phase. When DRE is used in this context:- DREi = Ei / (Ei + E i+1) say (Ei + 1) = y DREi = Ei / (Ei + Ey) (Ei) N0. of errors found deriving Analysis Activity. Ey: No. of errors that were not discovered in Design activity. A Quality objective for a Software team is to achieve a DRE that approximates to 1. SOFTWARE METRICS FOR PROCESS AND PROJECTS

INTEGRATING METRICS WITHIN SOFTWARE PROCESS Majority of Software Developers still do not measure, and sadly, most have little desire to begin - The problem is cultural ! Attempting to collect measures often precipitates resistance. In order to instituting a Metrics Program we have to consider some Arguments ARGUMENTS FOR SOFTWARE METRICS Why is it so important to Measure the Process of Software Engineering and Product that is Produced? The answer is relatively obvious: If we do not measure, there is no real way of determining weather we are improving! And if we are not improving, we are lost! By requesting and evaluating Productivity and Quality Measures, a Software Team and their Managers can establish meaningful goals for improvement of the Software process. The day-to-day rigors of Software Project work leave little time for strategic thinking.. Software Project Managers are concerned with more mundane (but equally important) issues:- - Developing meaningful Project estimates, - Producing higher-quality Systems, - Getting product out of door on time. . SOFTWARE METRICS FOR PROCESS AND PROJECTS

ARGUMENTS FOR SOFTWARE METRICS By using Measurement to establish a Project Baseline, each of these issues will become more manageable Additionally, The collection of Quality Metrics enables an organization to ‘’Tune’’ its Software Process to remove the vital few causes of Defects that have the greatest impact on Software Development. ESTABLISAHING A BASELINE By establishing a Metrics Baseline, benefits can be obtained at the Process, Project and Product levels. The same Metrics can serve many masters. The Metrics Baseline consisted of data collected from past Software Development Projects and can be as simple a simple table or a comprehensive Database containing dozens of Project measurers and the metrics derived from them. .

ESTABLISHING A BASELINE To be an effective aid in Process Improvement and/or Cost and Effort Estimation the Baseline data must have the following Attributes. BASELINE DATA ATTRIBUTTES Data must be reasonable accurate (Avoid guestimates) Data should be collected from as many Projects as possible Measures must be consistent. Application should be similar to work that is to be estimated. Project Baseline serves as a basis for ‘’Cost and Effort Estimation’’.

METRICS COLLECTION AND EVALUATION The ideal way of collecting Baseline data should be an ongoing activity. Sadly, this is rarely the case. Data collection requires a historical investigation of Past Project to reconstruct required data. Once, Measures have been collected Metrics computation is possible. Depending on the collected Measures, Metrics can span a broad range of Application-Oriented Metrics, (e.g. LOC or FP, O-O Metrics , WebApp etc.) as well as Quality and Project-Oriented Metrics. Metrics must be Evaluated and Applied during; Project Estimation, - Technical work, (Analysis, Design, Programming etc….) - Project Control - Process Improvement. Metrics Evaluation focuses on the underlying reasons for the results obtained and produces a set of Indicators that guide the |Project or Process SOFTWARE METRICS FOR PROCESS AND PROJECTS

METRICS FOR SMALL ORGANIZATION Software organization of all sizes should collect measures and use the resultant Metrics to help improve their local Software Process and the Quality and Timeliness of Products they produce. Small organizations might selected the following set of easily collected measures:- Time (Hours / Days) Elapsed from the time a Change or new Systems Request is made until Evaluation is complete. Effort ( Person/ hours) to perform the Evaluation Time (Hours / Days) Elapsed from completion of Evaluation to assignment of Change/ Systems Request to personnel. Effort Required to make the Required change Time to make the Change Errors uncovered during work to make Change Defect uncovered after Change is released to the Customer base.

METRICS FOR SMALL ORGANIZATION The Cost of collecting Measures and computing Metrics for a small organization, ranges from % of Project Budget during the Learning phase, and then drops to less then 1% of Project Budget after the Software Engineers and Project Managers have become familiar with the Metrics program. These Costs can show a substantial Return On Investment (ROI) if the insight derived from Metrics data lead to meaningful Process improvements for Software organization.

ESTABLISING A SOFTWARE METRICS PROGRAM The Software Engineering Institute of America (SEI) has developed a comprehensive guidebook for establishing a ‘’Goal-Driven Software Metrics Program’’ that suggests steps and prioritized business goals. See Software Engineering Book page 668 for further detail. SOFTWARE METRICS FOR PROCESS AND PROJECTS

SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3

Similar presentations

Presentation on theme: "SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3

Similar presentations

Presentation on theme: "SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3"— Presentation transcript:

Similar presentations

About project

Feedback