1. SPM UNIT 2 - Prof S. S. Deshmukh

2. Software measurements  Measurement gives us the insight by providing mechanism for evaluation.  There are four reasons for measuring s/w process, product: to characterize, to evaluate, to predict, to improve

3. Measure, Metric, Indicator Measure:  Measure provides the quantitative indication of extent, amount, dimension, size of some attribute of product or process  Measurement is an act of determining the measure.  When a single data point (ex: no. of errors found in single module) is collected the we can say that the measure has been established  Measurement occurs when more than one data points are collected (ex: no of modules tested to collect measure of no. of errors in single module)

4. Measure, Metric, Indicator Metric  A s/w metric relates the individual measure in some way (ex: no of error found per testing)  Metrics means measure of degree to which system, process has some given attribute.  S/w engineer collects the measure and develop the metrics so that indicator will be obtained.

5. Measure, Metric, Indicator Indicator  An indicator is a metric or combination of metrics which provide the insight of the s/w process, project.  These insights helps the s/w engineer and the project manager to adjust and make the things better.

6. Metrics in process and project  Physical quantities like light, pressure, wind, power can me measure easily but measure of s/w is not simple  Process indicator helps the s/w engineer to gain the insight of the existing process, it helps the manager to know what works and what does’nt  Project indicators helps the proj manager to:  Assess the ongoing proj  Track the risk  Adjust the work or task  Evaluate the project team ability

7. Process Metrics  We want some metrics to assess the process which can help to get insights from the process and to improve the process.  We derive the metrics based on outcome that can be derived from the process.  The outcome may include errors found before release, defects after delivery, human n time expended  We also derive process metrics by measuring time required by s/w engg task such as umbrella activity

8. Process Metrics  There are two data related to process: Private and Public  Ex: Private data like defects rate (by individual), error found in one module  Private data serve as indicator for an individual only  Public data contains defects rates, efforts, and data related to proj which is common to all member of s/w team

9. Project Metrics  These metrics are used by project managers and s/w team to adjust the project related activities.  1 st application of proj metrics occurs during the proj estimation  As the development is done the measures of current efforts and time are compared with the estimated ones.  Any s/w project should measure: Input, Output, Results

10. Software Measurements  Software measurements are of two types:  Direct measure: It include cost, efforts, LOC produced, execution speed, defects reported.  Indirect measure: It includes functionality, quality, complexity, efficiency, relaiability.

11. Size oriented approach  A s/w organization maintains record, like a table of size oriented approach like following figure

12. Size oriented metrics  In order to develop the metric common to all project we choose the LOC as the metric.  By using which we created the following metrics:  Error per LOC  Defects per LOC  Cost per LOC  Pages per LOC  Advantage and Disadvantage???

13. Function oriented metrics  Functionality cant be measured directly, hence it must be derived from the other direct measures.  Function points are calculated using the following table:

14. Function oriented metrics By using FP we created the following metrics:  Error per LOC  Defects per LOC  Cost per LOC  Pages per LOC  Advantage and Disadvantage???

15. Metrics for software quality  Overriding goal of s/w engg is to produce the high quality system, but quality of s/w cant be measured directly.  We need to use the indirect measure for quality metrics.  For checking the s/w quality we can use the following indicators: Correctness Maintainability Integrity Usability

16. Correctness – SQ metric  The program must operate correctly for which it has been developed  Correctness is the degree to which the s/w performs its required function.  The measure for correctness is the Defects per LOC  For quality assessment defects are counted over long period ex: for 1 year

17. Maintainability- SQ metric  This activity cost more than any other s/w engg activity  Maintainability is the ease with which the program can be corrected if error occurred, adapted if its environment is changed or enhanced on customer demand  There is no direct measure available to measure maintainability, so we use indirect measure.  A simple time oriented metric is mean-time-to-change (MTTC)  MTTC means time taken to analyze the change request, design an modification, implement it, test itand distribute it to all users.

18. Maintainability- SQ metric  Hitachi has cost oriented metric called spoilage – the cost to correct the defects encountered after the s/w has been released to the customers.  Ratio of spoilage and total project cost is plotted over the time to find maintainability.

19. Integrity- SQ metric  This has been more important in the age of hackers and firewalls.  This attribute measures the system ability to with stand the attacks (both accidental and intentional) to its security.  Attacks can be made to three components: Program, Data, Documents.  To measure integrity two additional attributes are defined: Threat and Security

20. Integrity- SQ metric  Threat is the probability that an attack of specific type can occur within given time.  Security is probability that attack of specific type will be repelled.  The integrity of system is defined as, Integrity= ∑ [(1- Threat) x (1- Security)] Where threat and security are summed over each type of attack

21. Usability- SQ metric  If a program is not user friendly then it is often doomed to failure, even if the function that it performs are valuable.  Usability is a attempt to quantify user friendly and can be measured in terms of four characteristics: Physical and intellectual need to learn the system Time required to get moderately efficient with the use of system Net increase in productivity when system is used by someone who is moderately efficient. Subjective assessment of user toward the system.

22. Defect Removal Efficiency [DRE]  It is the standard quality metric that provide the benefit for process and project.  To calculate DRE for whole project we use, DRE= E/(E + D) where E is no of error found before delivery of s/w and D is no of defect found after delivery of s/w Ideal value of DRE is 1  DRE can be applied between two s/w activities by DRE i = E i / (E i + E i+1 ) E i is the no of error found s/w activity i E i+1 is the no of error found during s/w activity i+1,ie which were not found in i

23. Software Scope  This is the first activity in the SE project planning, which assess the function and performance to be allocated to the project.  The project scope describes the data and control to be processed, function, interfaces and reliability.  Scope defines the limit of the project.  For ex: scope of student management system project is that it may not handle data of faculty or it may not handle data of more than 100 students.

24. Resources  The second task in the SE is resource estimation required for the project.

25. Human Resource  The planner begins by evaluating the scope and selecting skills required to complete the project.  Both organizational position and specialty are specified.  The no. of people required for s/w project can be determined after the estimation of development effort is made.

26. Reusable s/w resource  Component based SE makes it possible to have reusability ie reuse of s/w building blocks, such blocks are called as components.  Following are the types of components:  Off shelf components  Full experience components  Partial experience components  New Components

27. Reusable s/w resource  Off shelf components  Existing s/w that can be acquired from third party or that has been developed internally for previous projects.  Third party components are purchased for use in current project and are fully validated.

28. Reusable s/w resource  Full experience components  Existing specification, design, code, or test data developed for past project that are same to s/w built for current project.  Member of current s/w team have full experience in application area.  Modification required for full experience components will be relatively low risk.

29. Reusable s/w resource  Partial experience components  Existing specification, design, code, or test data developed for past project that are related to s/w built for current project but will require some modification.  Member of current s/w team have limited experience in application area.  Modification required for full experience components will be relatively fair risk.

30. Reusable s/w resource  New components  The s/w components that are built for current project by the s/w team are the new components.  They are developed based on the customer requirement.

31. Environmental Resources  The environment that supports s/w project is called software engineering environment.  It incorporates hardware and software.  Hardware provide the platform that supports the tools (s/w) required for development of s/w.  Software consist of the actual tools used for develoment.

32. Software sizing  Software cost and effort estimation is not exact science.  Too many variables like human, technical, environmental, political can affect the ultimate cost of project.  However project cost can be estimated with minimum risk using the systematic steps.  The first step of cost estimation is determining the size of project.

33. Software sizing  Following are the approaches for sizing of software: Fuzzy logic sizing Function point sizing Standard point sizing Change sizing

34. Empirical Estimation model  These estimation model makes use of formulas to predict the cost and effort needed for the s/w development.  COCOMO model is the most used empirical estimation model.

35. COCOMO model  Barry Boehm introduced COnstructive COst MOdel.  This model consist of following series of models which addresses the following area: Application composition model: Used during early stage of s/w engg, when prototyping user interfaces, evaluation of s/w technology. Early design stage model: Used once requirement have been established and basic s/w architecture is finalized. Post architecture stage model: Used during the construction of software

36. COCOMO model  Like all estimation model COCOMO requires the sizing information.  COCOMO uses three different sizing information: Object point, Function Point, LOC  Object point is an indirect s/w measure that is composed of number of counts: (1) Screen (2) Reports (3) Components likely to be required by application

37. COCOMO model  Each object instance is then classified into one of the three complexity level (i.e. simple, medium, difficulty)  Once the complexity is determined the number of screen, report, and components are weighted according to below table

38. COCOMO model  The object point is the determined by multiplying the original number of object instances by weighting factor in previous table and summing to obtain the total object point count.  When component are reused then New object point is obtained by : NOP= (Object point) x [(100- % reuse) / 100]

39. COCOMO model  To derive estimate of effort based on the components NOP value a productivity rate must be derived PROD = NOP / Person - month

40. COCOMO model  Once the productivity rate has been determined, a estimate of project effort can be derived as Estimated effort = NOP/ PROD

41. Automated estimation tools  Automation estimation allows the planner to estimate cost and effort and to perform “what if” analysis for important project variables like delivery date or staffing.  Automated tools perform following six functions 1) Sizing of project deliverables 2) Selecting project activities 3) Predicting staffing levels 4) Predicting software effort 5) Predicting s/w cost 6) Predicting s/w schedule

42. Risk strategies  Reactive risk strategies Monitor the project for the risk. Resources are set aside to deal with actual problems. S/w team does nothing about risk until something goes wrong. Then team tries to fix problem rapidly. When this fails the “crisis management” take over and the project is in real danger.

43. Risk strategies  Proactive risk strategies This strategy begins long before technical work is initiated. Potential risk are identified, their probability and impact is assessed and then they are ranked by their importance. Then the s/w team establishes the plan for managing the risk. The primary objective here is to avoid the risk.

44. Software Risks -- Types Project risk This risk threatens the project plan. If project risk become real then project schedule will slip and proj cost will increase. Technical risk This risk threatens quality and timeliness of s/w to be produced. If technical risk become real then implementation may become difficult or impossible.

45. Software Risks -- Types Business risk This threatens viability of s/w to be built. Business risk often jeopardizes project or product.  Building excellent product that no one wants (market risk)  Building product that no longer fits in business strategy for company (strategic risk)  Building product that sales force doesn’t know how to sell  Losing support of senior management due to change in focus or change in people (management risk)  Losing budgetary or personnel commitment (budget risk)

46. Risk Identification Risk checklist is the simplest way to identify the risk Product size Business impact Customer characteristic Process identification Development environment Technology to be built Staff size and experience

47. Risk Projection / Risk table

48. THE RMMM PLAN  The risk management steps can be organized into a separate Risk Mitigation, Monitoring and Management Plan  The RMMM plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan.  Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence.  Risk monitoring is a project tracking activity with three primary objectives: (1) to assess whether predicted risks do, in fact, occur; (2) to ensure that risk aversion steps defined for the risk are being properly applied (3) to collect information that can be used for future risk analysis.