1 / 87

Software Quality and Metrics

Software Quality and Metrics. Software Quality. What is Quality ? Quality Characteristics Cost evolution : Software vs Hardware How to solve it ?. Software Quality. What it is not ! Zero errors A good GUI What it is ! Meeting the user ‘s needs . ISO Definition of Quality.

aviva
Download Presentation

Software Quality and Metrics

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

E N D

Presentation Transcript


  1. Software Quality and Metrics

  2. Software Quality • What is Quality ? • Quality Characteristics • Cost evolution : Software vs Hardware • How to solve it ?

  3. Software Quality • What it is not ! • Zero errors • A good GUI • What it is ! • Meeting the user ‘s needs

  4. ISO Definition of Quality • ‘The totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs’ Software Product Shouldfullfill has Is related to requirements characteristics (contributes to the fulfillments)

  5. ISO 9126 Characteristics • The objective of this standard is to provide a framework for the evaluation of software quality. ISO/IEC 9126 does not provide requirements for software, but it defines a quality model which is applicable to every kind of software. It defines six product quality characteristics and in an annex provides a suggestion of quality subcharacteristics.

  6. ISO 9126 Characteristics • Functionality is the set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. • Reliability is the set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. • Usability is the set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. • Efficiency is the set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions. • Maintainability is the set of attributes that bear on the effort needed to make specified modifications. • Portability is the set of attributes that bear on the ability of software to be transferred from one environment.

  7. Sub Characteristics

  8. Sub Characteristics

  9. Quality model • The relative weight of the characteristics depends on the type of software • Prototype • Critical (ex : nuclear power plant) • Long live (ex : Telecom switch) • …

  10. Quality model • What should be the ranked list of Quality characteristics (most important first) for a software used in a space shuttle ? • Give them a weight.

  11. NAVETTE HERMES • QUALITY CHARACTERISTICS IN DECREASING ORDER : • RELIABILITY CHANGEABILITY • ROBUSTNESS FLEXIBILITY • AVAILABILITY PORTABILITY • CONFORMANCE REUTILISABILITY • INTEGRITY ADAPTABILITY • USABILITY • ERGONOMY • EFFICIENCY • TESTABILITY

  12. Software Metrics • The Quality needs to be quantified Maintainability Testability Changeability Stability Analyzability Cyclomaticcomplexity Max nber of interleaving Nbre of input/output

  13. Metrics versus measurement • A measure f is a function f:A->B where for each object a belonging to A there exists a formal object (measure’s value) f(a) belonging to B • A function f is called a metric iff it has the three following properties: • f(x,y)=0 with x=y • f(x,y)=f(y,x) for each x and y • f(x,z)<=f(x,y)+f(y,z) for each x, y, z

  14. Metrics versus measurement • A measure should satisfy 4 criteria • Being in relation with well understood and significant attributes • Being supported by formal models or abstractions that capture the attributes • Respecting the relations and the existing order between objects (determined by the attributes of the models • Being mapped to the numeric system in order to maintain the order relationship. • Remark: if it doesn’t respect the three first criteria, it is a metric

  15. Type of measurement nominal ordinal interval ratio absolute

  16. Type of measurement (examples) • Nominal: number on the back of a football player • Ordinal: Richter scale • Interval: f(x)=ax+b. Temperature is of interval type • Ratio: f(x)=ax. A length is a ratio • Absolute: f(x)=x. Number of people working in a company

  17. Building of measures • Non terminal measures • Raw value => normative value Ex: v(G) < 15 => v(G) = 2 15<v(G)<=30 => v(G) = 1 v(G)> 30 => v(G) = 2 • Terminal measures Mes_1 = (mes_2 + 4*mes3)/5 • Qualitative expression: [0;0.5 ] => Mes_1 = 0 NOK ]0.5;1.5] => Mes_1 =1 Average ]1.5;2] =>Mes_1= 2 OK

  18. Software Metrics • Different levels of measurement • Architecture • Call Graph • Module • Control Graph • Textual

  19. Software Metrics • Architecture • Number of paths • Hierarchical complexity • Structural complexity • Component assessibility • Path testability • System testability • System entropy

  20. Software Metrics • Structural complexity • Cyclomatic number • Max number of degrees • Max number of interleaving • Textual • Halstead Software Science measures • Programming Norms

  21. Object-Oriented Software Metrics • Depth of inheritance tree (DIT) • DIT is defined as the maximum number of steps from the class node to the root of the inheritance tree • What it measures: Since in OO design, the application domain is modelled as a hierarchy of classes represented as a tree, the DIT metric is a measure of how many ancestor classes can affect a particular class. The depth of inheritance tree metric is an indication of the potential for reuse. Should be between 0 and 4

  22. Object-Oriented Software Metrics • Number of children (NOC) • NOC is defined as the number of immediate descendants of a class in the hierarchy. (1..4) • What it measures: NOC is an indicator of the potential influence a class can have on the design and on the system

  23. Object-Oriented Software Metrics • Coupling between object classes • : This is a count of the number of other classes to which a given class is coupled. • What it measures: Also known as message delivery channels, this metric counts the number of associations in a class and attributes whose parameters are of the class type. Messages can only be sent when an object of a class holds a reference to another object of a class Should be between 1 and 4

  24. Object-Oriented Software Metrics • Number of the associations linked to a class • The number of associations including aggregations is counted. • What it measures: This metric is useful for estimating the static relationships between classes.

  25. Object-Oriented Software Metrics • Number of the elements in the transitive closure of the subclasses of a class • What it measures: This is potentially useful for predicting the classes whose changes might affect this class.

  26. Object-Oriented Software Metrics • Number of the superclasses of a class • This counts the direct parents of a class • What it measures: In a single inheritance implementation like Java, the value of this metric is either 0 or 1, whereas under multiple inheritance scheme it is greater than or equal to 0.

  27. Object-Oriented Software Metrics • Number of use cases in a model • What it measures: A use case represents a coherent unit of functionality provided by a system, a subsystem, or a class.

  28. Object-Oriented Software Metrics • Number of system classes associated with a use case • This metric counts the number of classes whose objects participate in the scenario of a use case. • What it measures: NSCU is good for estimating the impact of a requirement change onto the system. Any changes of use cases spread to classes and the interactions of their objects, and vice versa

  29. Object-Oriented Software Metrics • Number of messages associated with a use case • This metric counts the number of messages comprising the scenario of a use case. • What it measures: A use case is further refined through its scenario. In UML, there are two scenario diagrams, i.e. sequence diagram and communication diagram. These two kinds of scenario diagrams are completely isomorphic meaning one kind of diagram can be automatically replaced with another kind without the loss of information contained in it. This metric is useful for tracing requirements into design-level elements.

  30. Object-Oriented Software Metrics • Number of actors in a model • This metric is the number of actors in a model, where an actor is a special class whose stereotype is “Actor”. • What it measures: This metric computes the number of actors in a model.

  31. Object-Oriented Software Metrics • Number of actors associated with a use case • : This metric is the number of actors that are associated with a use case. • What it measures: Normal system classes are not counted for this metric because this metric concerns the interactions between a system and its stakeholders.

  32. Object-Oriented Software Metrics • Number of classes in a model • What it measures: A class in a model is an instance of the metaclass “class”. This metric is comparable to the traditional LOC (lines of code) for estimating the size of a system. This metric can be used to compare sizes of systems.

  33. Object-Oriented Software Metrics • Number of inheritance relations in a model • What it measures: This metric counts the number of generalisation relationships between classes existing in a model.

  34. Object-Oriented Software Metrics • Number of packages in a model • What it measures: Package is a way of managing closely related modelling elements together. Also by using packages, naming conflicts can be avoided.

  35. Object-Oriented Software Metrics • Number of objects in a model • What it measures: In a similar manner that a class is an instance of the metaclass “Class”, an object is an instance of a class.

  36. Object-Oriented Software Metrics • Number of associations in a model • This metric measures the number of connections between classes • What it measures: An association is a connection, or a link, between classes. This metric is useful for estimating the scale of relationships between classes.

  37. Object-Oriented Software Metrics • Number of aggregations in a model • What it measures: An aggregation is a special form of association that specifies a whole-part relationship between the aggregate (whole) and a component part

  38. Object-Oriented Software Metrics • Number of messages in a model • What it measures: A message is an instance of the metaclass “Message”. Messages are exchanged between objects manifesting various interactions

  39. Object-Oriented Software Metrics • Number of methods (NOM) • NOM is defined as the total number of methods in a class, including all public, private and protected methods. • What it measures: It has been suggested that this metric is a useful indication of the classes that may be trying to do too much work themselves; i.e., they provide too much functionality. NOM cannot be viewed as an indicator of the effort to develop a class, since a class containing a single large method may take as long to develop as a class containing a large number of small methods.

  40. Object-Oriented Software Metrics • Number of methods added (NMA) • What it measures : The number of operations added plays a role in the specialization of the class and must be maintained in a proportion which continues to justify inheritance, otherwise known as generalization. Too many added operations signify too big a difference with the parent class.  The inheritance would then make less sense. The more added operations there are, the more the class must be redeveloped, and the less the inheritance is justified.

  41. Object-Oriented Software Metrics • Number of Methods Inherited (NMI) • What it measures: For a class, this metric gives the percentage of the number of non-redefined operations with regard to the number of operations inherited. The percentage of operations inherited should be high.  This is the opposite of the Number of Methods Overridden (NMO) threshold.  A low percentage of inherited operations indicates poor sub-classing. The maximum of 100 % is ideal, but is never attained, given the fact that we often need to adapt inherited services.

  42. Object-Oriented Software Metrics • Number of Methods Overridden (NMO) • What it measures: The number of redefined operations plays a role in the specialization of the class and must be maintained in a proportion that continues to justify inheritance. Too many redefined operations implies too big a difference with the parent class and inheritance then makes less sense. For a class, this is the count of the number of inherited operations that are redefined by the class. A class which inherits services must use them with a minimum of modifications.  If this is not the case, the inheritance loses all meaning and becomes a source of confusion.

  43. Object-Oriented Software Metrics • Response for a class • This is the size of the set of methods that can potentially be executed in response to a message received by an object. Class A A::m1() calls B::m1(), B::m2() A::m2() calls A::m1(),C::m1() A::m3() RFC = 7

  44. Object-Oriented Software Metrics • Lack of cohesion in methods • This is a measure of the number of disjoint sets formed by the intersection of the sets of instances variables used by methods.

  45. Object-Oriented Software Metrics • Lack of cohesion in methods (another one) The LCOM value for a class C is defined as LCOM(C) = 1 - |E(C)| / (|V(C)| x |M(C)|), where V(C) is the set of instance variables, M(C) is the set of instance methods, and E(C) is the set of pairs (v,m) for each instance variable v in V(C) that is used by method m in M(C).

  46. Object-Oriented Software Metrics • Number of attributes (NOA) • NOA is defined as the total number of attributes in a class. • What it measures: The ratio of private and protected attributes to total number of attributes indicates the effort required by that class in providing information to other classes. Private and protected attributes are therefore viewed merely as data to service the methods in the class

  47. Object-Oriented Software Metrics • Number of public attributes • Number of protected attributes • Number of private attributes • Number of class attributes • Number of public methods • Number of protected methods • Number of private methods • Number of class methods

  48. Software Analysis Process and Report • Architectural Level • Structural Level • Report

  49. Architectural Level • General view of the call graph • Depth, width, hierarchy, levels jump • Singularities • Isolated components, roots, strongly connected components, recursivity

  50. Call Graph examination

More Related