Product Metrics SEII - Lecture 22

Product MetricsSEII-Lecture 22Dr. Muzafar KhanAssistant ProfessorDepartment of Computer ScienceCIIT, Islamabad.RecapVersion controlProject repository, version management capability, make facility, issue/bug trackingChange controlConfiguration auditcompliments technical reviewsStatus reportingConfiguration management for WebAppContent, people, scalability, politics2ImportanceMeasurement is a key element of any engineering processAssessment of qualitySE is different than other disciplinesOften indirect metricsDebate on “unmeasurable” softwareSystematic way to assess qualityDiscover and correct potential problems before they become serious defects3Framework for Product Metrics [1/4]Measure, measurement, and metrics are often used interchangeablyMeasureQuantitative indication of the extent, amount, dimension, size, or capacity of some attributeExample: number of errors uncovered within a single componentMeasurementThe act of determining a measureExample: number of components reviewsMetricAn indicator“a quantitative measure of the degree to which a system, component, or process possesses a given attribute”Example: average number of errors found per review4Framework for Product Metrics [2/4]The Challenge of Product MetricsAttempts to develop single metricIf we want to evaluate an attractive carMeasurement process involves five activitiesFormulationCollectionAnalysisInterpretationFeedback5Framework for Product Metrics [3/4]Principles for metrics characterization and validationA metric should have desirable mathematical propertiesWhen a metric represents a software characteristic that increases when positive traits occur or decreases when undesirable traits are encountered, the value of the metric should increase or decrease in the same mannerEach metric should be validated empirically in a wide variety of contexts before being published or used to make decisionsPrinciples to conduct the activitiesData collection and analysis should be automatedValid statistical techniques should be appliedInterpretative guidelines should be established6Framework for Product Metrics [4/4]Goal-oriented software measurementGoal, question, metric paradigmEstablish explicit measurement goalDefine a set of questions that must be answeredIdentify well-formulated metricsAttributes of effective software metricsSimple and computableEmpirically and intuitively persuasiveConsistent and objectiveConsistent in its use of units and dimensionsProgramming language independentAn effective mechanism for high-quality feedback7Metrics for Requirements ModelFew analysis and specification metricsProject estimation metrics may be usedPrediction of the “size” of the resultant systemFunction-based metricsEstimate the cost and effortPredict the number of errorsForecast the number of components and/or the number of project source lines8Function-Based Metrics [1/4]Number of external inputs (EIs)Originates from user or other applicationOften used to update internal logical filesInquiries are differentNumber of external outputs (EOs)Derived data within the applicationReports, screens, error messagesIndividual data items within a report are not considered9Function-Based Metrics [2/4]Number of external enquiries (EQs)An online input that generates online outputNumber of internal logical files (ILFs)Logical grouping of data within the application’s boundaryNumber of external interface files (EIFs)Logical grouping of data external to the applicationFP = count total * [0.65 + 0.01 * ∑ (Fi)]10Function-Based Metrics [3/4]11Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 621Function-Based Metrics [4/4]FP = count total * [0.65 + 0.01 * ∑ (Fi)]Fi (i = 1 to 14) are value adjustment factorsDoes the system require reliable backup and recovery?Are specialized data communications required to transfer information to or from the application?Are there distributed processing functions?Is performance critical?Will the system run in an existing, heavily utilized operational environment?12Metrics for Specification Quality [1/3]Characteristics to assess requirements qualitySpecificityCompletenessCorrectnessUnderstandabilityVerifiabilityConsistencyAchievabilityConcisionTraceabilityModifiabilityPrecisionReusability13Metrics for Specification Quality [2/3]High quality requirements areStored electronicallyInterpretableAnnotated by relative importanceStableVersionedOrganizedCross-referencedRight level of detail14Metrics for Specification Quality [3/3]Total number of requirementsnr = nf + nnfSpecificity of requirementsQ1 = nui / nrIf value is closer to 1, lower ambiguityCompleteness of functional requirementsQ2 = nu / (ni * ns)nu (number of unique functional requirements), ni (number of inputs defined), ns (number of states specified)Completeness of functional and nonfunctional requirementsQ3 = nc / (nc * nnv)nc (number of validated requirements)15Metric for Design ModelDesign of new aircraft, computer chip etc.Design measures are always thereSometimes opposite the case in software designArchitectural design metricsStructural complexityS(i) = fout (i)Data complexityD(i) = v(i) / (fout (i) + 1)System complexityC(i) = S(i) + D(i)16Architectural Design Metrics [1/2]Simple morphology metricsSize = n + an: number of nodesa: number of arcsDepth: longest path from root to leaf nodeWidth: maximum number of nodes at any one levelConnectivity density: arc-to-node ratio17Architectural Design Metrics [2/2]n = 17, a = 18r = a/n = 1.0618Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 625Metrics for Object-Oriented Design [1/4]Nine distinct and measurable characteristicsSizePopulationStatic count of entities e.g. classesVolumePopulation measure at a given time instantLengtha chain of interconnected design elementsFunctionalityIndication of the value delivered to customer19Metrics for Object-Oriented Design [2/4]ComplexityIn terms of structural characteristicsHow classes are interrelated with each otherCouplingPhysical connections between elementsSufficiencyDegree of abstractionDesign component is sufficient if it fully reflects all properties of the application domain object20Metrics for Object-Oriented Design [3/4]CompletenessMultiple points of view "What properties are required to fully represent theproblem domain object?”CohesionAll operations working together to achieve a single, well-defined purposePrimitivenessSimilar to simplicityThe degree to which operation is atomic21Metrics for Object-Oriented Design [4/4]SimilarityThe degree to which two or more classes are similarVolatilityLikelihood of possible change22SummaryMeasurement and quality assessmentFramework for product metricsMeasure, measurement, and metricsFormulation, collection, analysis, interpretation, feedbackPrinciples for metrics characterization and validationMetrics for requirements modelFunction-based metricsMetrics for specification qualityMetric for design modelArchitectural design metricsMetric for object-oriented design23