Presentation on theme: "SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3"— Presentation transcript:
1SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3
2SOFTWARE 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
3SOFTWARE METRICS FOR PROCESS AND PROJECTS 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
4SOFTWARE METRICS FOR PROCESS AND PROJECTS 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
5SOFTWARE METRICS FOR PROCESS AND PROJECTS REASONS FOR MEASURINGTo CharacterizeTo EvaluateTo PredictTo ImproveMeasurement is a Management Tool.Measurement provides a Project Manager with insight. It assists Manager and Project team in making sound decision.
6SOFTWARE METRICS FOR PROCESS AND PROJECTS 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 ProjectTrack potential RisksUncover Problem areas before they “Go critical”Adjust work flow or TasksEvaluate 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
7SOFTWARE METRICS FOR PROCESS AND PROJECTS The only Rational way to improve any Process is to:a) Measure Specific attributes of the Processb) Develop a set of meaningful Metrics based on these attributesc) Use Metrics to provide Indicator that will lead to strategy for improvementHowever it is important to note that Process is only one of a numberof ‘’Controllable Factors’’ in improving Software Quality andOrganizational performance.SOFTWARE METRICS FOR PROCESS AND PROJECTS
8SOFTWARE METRICS FOR PROCESS AND PROJECTS BUSINES CONDITIONSCUSTOMER CHARACTERISTICSDEVELOPMENT ENVIRONMENTPEOPLETECHNOLOGYPRODUCT
9SOFTWARE METRICS FOR PROCESS AND PROJECTS The Figure shows the Process in the centre of a triangle connecting threeFactors that have profound influence on Software Quality and OrganizationalPerformance.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 thatinclude the Development Environment (CASE TOOLS, Business Conditions(Deadlines, Business rules), and Customer Characteristics (ease ofcommunication and collaboration etc)
10SOFTWARE METRICS FOR PROCESS AND PROJECTS 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.)
11SOFTWARE METRICS FOR PROCESS AND PROJECTS 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.
12SOFTWARE METRICS FOR PROCESS AND PROJECTS Software Process Metrics can provide significant Benefits as an Organization works toimprove its overall level of Process Maturity.However like all Metrics,, these can be misused, creating more problems that they solve.SOFTWARE METRICS ETIQUETTESuggested by Grady that is appropriate for both Managers and practitioners as they institute aProcess 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 toachieve them5. Never use Metrics to threaten individual or Teams.6. Do not consider Metrics data that indicate a problem area asnegative. These data are merely an indicator for process improvement Consider it as andIndicator 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, thederivation of simple Indicators gives way to a more rigours approach called (SSPI) “StatisticalSoftware 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
13SOFTWARE 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
14SOFTWARE METRICS FOR PROCESS AND PROJECTS THE PURPOSES OF PROJECT METRICSa) 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
15SOFTWARE METRICS FOR PROCESS AND PROJECTS PROJECT METRICS APPLICATIONS - During ‘’Project EstimationMetrics 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 commencesOther 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.
16SOFTWARE METRICS FOR PROCESS AND PROJECTS 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 METRICSa) 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.
17SOFTWARE METRICS FOR PROCESS AND PROJECTS SOFTWARE MEASUREMENT Direct MeasurementIndirect MeasurementDirect 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 timeIndirect Measurements Of Product includes- Functionality- Quality- Complexity- Efficiency- Reliability- Maintainability and many others…SOFTWARE METRICS FOR PROCESS AND PROJECTS
18SOFTWARE METRICS FOR PROCESS AND PROJECTS Size Oriented Metrics are derived by normalizing Quality and/orProductivity Measures by considering the Size of Software that hasbeen produced.SIZE-ORIENTED METRICS Errors / KLOC Defect / KLOC - $ / KLOC - Page of Document / KLOCOther interesting Metrics can be computed such as:-- Errors / Person-Month- LOC / Person-Month- $ / Pages of DocumentationNote: KLOC (Thousand of Lines of Code)
19SOFTWARE METRICS FOR PROCESS AND PROJECTS SIZE-ORIENTED METRICSThe 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.
20SOFTWARE METRICS FOR PROCESS AND PROJECTS We can calculate the following Size Oriented Metrics from the table oreach 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 = )
21SOFTWARE METRICS FOR PROCESS AND PROJECTS WHY SIZE-ORIENTED METRICS ARE NOT UNIVERSALLY ACCEPTED?PROPONENTSArgues that LOC is an “Artifact” of Software Development Projects that can beeasily 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 existsOPPONENTSArgues that LOC measures are Programming Language dependent, that whenProductivity is considered, they penalize well designed but shorter Programs,that they can not easily accommodate Non-procedural Languages. Thus, theiruse 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
22SOFTWARE METRICS FOR PROCESS AND PROJECTS FUNCTION-ORIENTED SOFTWARE MERTICSFunction-Oriented Software Metrics use Measure of“Functionality” delivered by the Software Application asa Normalization value.The most widely used Function-oriented Metrics is FUNCTIONPOINT (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
23SOFTWARE METRICS FOR PROCESS AND PROJECTS The Arguments of Proponents and Opponents of Functional-Orientedmetrics:POPONENTSClaim that Function Point (FP) is Programming Language independent, thusmaking it ideal for applications using Procedural (conventional) and non-Procedural Programming Languages.OPPONENTSClaim that the method requires some ‘’slight of hands’’ in that Function Pointcomputation is based on subjective rather than objective data, that the countsof the Information Domain (and other dimensions) can be difficult tocollect after the fact, and that FP has no direct physical meaning; It’s just anumber.Function Points (FP) are derived using an Empirical Relationship.
24SO SOFTWARE METRICS FOR PROCESS AND PROJECTS Function Points (FP) are computed by completing the ‘’Five Information DomainCharacteristics’’ that are determined and Counts are placed in a table.THE FIVE INFORMATION DOMAINS for Function Points calculation1. Number of Inputs 2. Number of Outputs3. Number of User Enquiries4. No. Of Files5. No. of External InterfacesTHE COMPLEXITY FACTORS of the SystemFP = COUNT TOTAL * [ * ∑ ( fi )]Complexity Adjustment Factor
25SOFTWARE METRICS FOR PROCESS AND PROJECTS COMPLEXITY FACTOR ASSUMPTIONS (Based on the answers to the following14 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)
26SOFTWARE METRICS FOR PROCESS AND PROJECTS FUNCTION-ORIENTED METRICSERROR / FPDEFECTS / FP$ / FPPAGES / FP FP / PERSON- MONTHRELATIONSIONSHIP BETWEEN LOC AND FPThe relationship between LINES OF CODE (LOC) and FUNCTIONPOINTS (FP) depends on Programming Language that is used toimplement 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 AVERAGECCVISUAL BASICSQLAs you can see that one LOC of C++ provides approx. 2.4 times the Functionalityas one LOC of C.SOFTWARE METRICS FOR PROCESS AND PROJECTS
27SOFTWARE 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.
28SOFTWARE METRICS FOR PROCESS AND PROJECTS Within the context of Process and Project Metrics, we are concerned withProductivity and Quality measurers of ‘’Software Development Output’’ asa 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 0urinterest 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?
29SOFTWARE METRICS FOR PROCESS AND PROJECTS OBJECT- ORIENTED PROJECT METRICSConventional Software Project Metrics such as LOC and FP Metrics can be used to estimate O-O ProjectsHowever, 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
30SOFTWARE METRICS FOR PROCESS AND PROJECTS Number Of Scenario ScriptsA Scenario Script is a detailed sequence of steps that describes the interactionbetween the User and the Application.The number of Scenario Scripts directly correlated to the Size of the application andto the number of Test Cases that must be developed to exercise the System once it isconstructed.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 anindicator of”:The Amount of Effort required to develop the SoftwareThe potential Amount of Reuse to be applied during the development.
31SOFTWARE METRICS FOR PROCESS AND PROJECTS Number of Support ClassesSupport Classes are required to implement the System but are not immediatelyrelated to the Problem Domain. (e.g User Interface Classes, Database Access andManipulation 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 theSoftware and an indication of potential amount of Reuse to be applied during DevelopmentAverage 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.
32SOFTWARE METRICS FOR PROCESS AND PROJECTS Number of SubsystemsA Sub-system is an aggregation of Classes that support a Function that isvisible to the end-user of a system.Once Subsystems are identified , it is easier to lay out a reasonable Schedulein which work on Subsystems is partitioned among Project staff.
33SO SOFTWARE METRICS FOR PROCESS AND PROJECTS USE OF OBJECT-ORIENTED METRICSTo 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.
34SO SOFTWARE METRICS FOR PROCESS AND PROJECTS USE-CASE ORIENTED METRICSUse-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 systemUse-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.
35SO SOFTWARE METRICS FOR PROCESS AND PROJECTS CRITICISM ABOUT USE-CASE ORIENTED METRICSUse-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 deriveUse-case Metrics, much work remains to be done.
36SOFTWARE METRICS FOR PROCESS AND PROJECTS WEB ENGINEERING PROJECT METRICSMeasures and Metrics used for Traditional Software Engineering Project aredifficult to translate directly to Web-Apps. Yet a Web Engineering organization willhave to collect Measurers and build a Database that allow it to assess its internalProductivity and Quality over a number of Projects.Among the Measurers that can be collected for WEB Engineering Projects are:No. of Static Web PagesNo. of Dynamic Web PagesNo. of Internal Page LinksNo. of External System interfacesNo. of Persistent Data ObjectsNo. of Static Content ObjectsNo. of Dynamic Content ObjectsNo. of Executable Functions
37SOFTWARE METRICS FOR PROCESS AND PROJECTS WEB ENGINEERING PROJECT METRICSNO. OF STATIC WEB PAGESWeb Pages with Static content are the most common of all Web –Applications. These Pages represent ‘’Low relative complexity’’ andgenerally require less effort to construct than Dynamic pages.This measure provide the overall Size of the Application and the Effortrequired to develop it.NO. OF DYNAMIC PAGESAre essential for e-commerce Applications an Search Engines, FinancialApplications and may other WebApps. These pages represents‘’Higher relative Complexity’’ and thus require more Effort to constructthan Static pages.This measure also provide the overall Size of the Application and theEffort required to develop it.
38SOFTWARE METRICS FOR PROCESS AND PROJECTS NO. OF INTERNAL PAGE LINKSAre Pointers that provide a Hyperlink to some other Web pages within theWebApp. This measure provides an indication of the degree ofArchitectural coupling within the WebApp. As the Link pages increases,the Effort expended on designing and constructing Navigations.NO. OF EXTERNAL SYSTEMS INTERFACEDWebApps must often interface with ‘’Backroom Business Applications’’.As the requirements for External interfacing grow, System complexityand development effort increases.NO. OF PERSISTENT DATA OBJECTSOne or more Database files may be accessed by a WebApp. As the number ofrequired files grow, the complexity of WebApp also grow and Effort to Implementit increases proportionally.
39SOFTWARE METRICS FOR PROCESS AND PROJECTS NO. OF STATIC CONTENT OBJECTSA Static content objects may contain text, graphic, video, animation andaudio information. A Multiple content Objects may appear on a singleWeb Page increasing the complexity.NO. OF DYNAMIC CONTENT OBJECTSDynamic Content Object are generated based on User actions andencompasses internally generated text, graphic, video, animationand audio information that are incorporated within WebApp. Multiplecontent Objects may appear on a single Web Page.
40SOFTWARE METRICS FOR PROCESS AND PROJECTS WEB ENGINEERING PROJECT METRICSNO. OF EXECUTABLE FUNCTIONSAn Executable function (also called Script or Applet) provides someconceptual 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 ofthe Web Engineering Process. Web Application Metrics can be computedand 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 ProjectEstimation.
41SO SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITYThe overriding Goal of Software Engineering is to produce aHigh-quality Application System within a ‘’Time-frame that satisfya 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.
42SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITYThe Primary source of quality measurers at the Project-level is ‘Errors andDefects’.Metrics derived from Errors and Defects provide an indication of theeffectiveness 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
43SO SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITYMEASURING QUALITYThere are many Measures of Software Quality; But the following Fourmeasures provide useful indicators for the Project Team.- Software Correctness- Software Maintainability- Software Integrity- Software Usability
44SO SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY1. SOFTWARE CORRECTNESSCorrectness is the degree to which the software performs itsrequired function.Most common measures for Correctness is:-- DEFECTS / KLOC,Defects are these problems that are reported by Users afterthe Software has been released for general use.For Quality assessment, Defects are counted over a standard period oftime, typically for one year.
45SO SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY2. SOFTWARE MAINTAINABILITYMaintainability 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.
46SO SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY3. SOFTWARE INTEGRITYThis attribute measures a System ability to withstand bothaccidental 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
47SOFTWARE METRICS FOR PROCESS AND PROJECTS Threat Probability - that an attack of a specific type willOccur within a given timeSECURITY 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 theSystem’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
48SO SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY4. SOFTWARE USABILITYUsability is an attempt to quantify User-friendliness and can bemeasured in terms of the following four characteristics.USABILITY CHARACTERISTICSThe 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 functionsare valuable.SO SOFTWARE METRICS FOR PROCESS AND PROJECTS
49SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITYDEFECT REMOVAL EFFICIENCYDefect Removal Efficiency (DRE) in essence is a Measure of filtering ability of QualityAssurance 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 Processlevel.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 users8 Defects reported by Users after deliveryDRE = 20 / (20 + 8) => 20 / 28 = 0,714 or 71,4 %
50SOFTWARE METRICS FOR PROCESS AND PROJECTS DEFECT REMOVAL EFFICIENCYDRE 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
51SOFTWARE METRICS FOR PROCESS AND PROJECTS INTEGRATING METRICS WITHIN SOFTWARE PROCESSMajority of Software Developers still do not measure, and sadly, most have little desire tobegin - The problem is cultural ! Attempting to collect measures often precipitates resistance.In order to instituting a Metrics Program we have to consider some ArgumentsARGUMENTS FOR SOFTWARE METRICSWhy 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 andtheir 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
52SOFTWARE METRICS FOR PROCESS AND PROJECTS ARGUMENTS FOR SOFTWARE METRICS By using Measurement to establish a Project Baseline, each of these issues will become more manageableAdditionally, 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 BASELINEBy 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..
53SOFTWARE METRICS FOR PROCESS AND PROJECTS ESTABLISHING A BASELINETo be an effective aid in Process Improvement and/or Cost and EffortEstimation the Baseline data must have the following Attributes.BASELINE DATA ATTRIBUTTESData must be reasonable accurate (Avoid guestimates)Data should be collected from as many Projects as possibleMeasures 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’’.
54SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS COLLECTION AND EVALUATIONThe 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 andproduces a set of Indicators that guide the |Project or ProcessSOFTWARE METRICS FOR PROCESS AND PROJECTS
55SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SMALL ORGANIZATIONSoftware organization of all sizes should collect measures and use theresultant Metrics to help improve their local Software Process and theQuality 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 EvaluationTime (Hours / Days) Elapsed from completion of Evaluation to assignment of Change/ Systems Request to personnel.Effort Required to make the Required changeTime to make the ChangeErrors uncovered during work to make ChangeDefect uncovered after Change is released to the Customer base.
56SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SMALL ORGANIZATIONThe Cost of collecting Measures and computing Metrics for asmall organization, ranges from % of Project Budgetduring the Learning phase, and then drops to less then 1%of Project Budget after the Software Engineers and ProjectManagers 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 meaningfulProcess improvements for Software organization.
57SOFTWARE METRICS FOR PROCESS AND PROJECTS ESTABLISING A SOFTWARE METRICS PROGRAMThe Software Engineering Institute of America (SEI) has developed acomprehensive guidebook for establishing a ‘’Goal-Driven Software MetricsProgram’’ that suggests steps and prioritized business goals.See Software Engineering Book page 668 for further detail.SOFTWARE METRICS FOR PROCESS AND PROJECTS