COMP3053.SQA
¡ Some of the materials we use may come directly from previous teachers of this module, and other sources …
¡ Thank you to (amongst others):
Copyright By PowCoder代写 加微信 powcoder
▪ , , , , , , T.Y. Chen,
COMP3053.SQA.03: Software Quality
¡ Many people think Software Quality is managed at
the Release/Acceptance Testing stage § It’s not
¡ If Quality Management is a process (and a culture) § then the software won’t fail Release/Acceptance Testing
▪ (as often)
¡ You can take some measures of quality
§ but they only indicate characteristics
COMP3053.SQA.03: Software Quality
COMP3053.SQA.03: Software Quality
¡ We need to do it ALL well!
¡ To do Release/Acceptance Testing well § need to have done Reqs & Specs well
§ otherwise dev team won’t know the goals
¡ To do Unit Testing well
§ need clear specifications and models
¡ To do Coding well
§ need agreement on coding standards
COMP3053.SQA.03: Software Quality
COMP3053.SQA.03: Software Quality
¡ Software Engineering Processes were introduced
in the 1960s
§ because software was (often still is) poor quality § in order to add process, methods, and quality
¡ All SE Processes are designed to improve software quality
¡ The Software Quality Team aim to make sure: § A good SE Process is chosen for the project
§ All aspects of that SE Process are all done well
COMP3053.SQA.03: Software Quality
¡ 1) Defining standards and procedures for the whole company
¡ 2) Checking that projects conform to
company standards
§ so company doesn’t release ‘below its standard’
¡ 3) Help create Project Plans – § so that quality goals are set
COMP3053.SQA.03: Software Quality
¡ The SQM team is often called the Quality
Assurance (QA) Team
§ ideally this team should be separate from dev
§ and report to the managers above the project
COMP3053.SQA.03: Software Quality
“The QA process checks the project deliverables to ensure that they are consistent with organisational standards and goals.” – p.653
Software development process
Quality management process
Standards and Quality
procedures
Quality review reports
Figure 24.1 Quality management and software development
COMP3053.SQA.03: Software Quality
Software development process
Quality management process
Standards and Quality
procedures
Quality review reports
Figure 24.1 Quality management and software development
COMP3053.SQA.03: Software Quality
Requirements Docs
Specification Docs
Code Documentation
¡2) Agreeing/Using Standards ¡3) Inspecting for Quality
¡4) Measuring Quality
COMP3053.SQA.03: Software Quality
Planning for Quality
¡ A Project Quality Plan
§ sets the bar for the team to achieve
§ means everyone knows what will be acceptable at the end
§ “It therefore defines what ‘high-quality’ software actually means
for a particular system” – p.653
¡ Key Sections of a Quality Plan Document for a Project § Introduction – intended market, etc.
§ Plans – critical release dates, maintenance, etc.
§ Process description – what process to be followed for this project § Quality goals – critical quality attributes for final product
§ Risks & Risk Management – expected key risk areas
COMP3053.SQA.03: Software Quality
¡Identify standards that must be met ¡Recommend quality-promoting
processes for the project
¡Identify what will count as good quality
for that project
§So everyone knows the target quality
▪ (vs. the target functionality (from Reqs/Specs))
COMP3053.SQA.03: Software Quality
¡1) Planning for Quality
¡3) Inspecting for Quality ¡4) Measuring Quality
Agreeing/Using Standards
COMP3053.SQA.03: Software Quality
¡ Many people think QA is about prescribing standards
¡ “In practice, however, I think that there is much more to quality management than standards and the associated
bureaucracy to ensure that these have been followed”
¡ The risk is that the Quality Assurance Team become the
nasty people that make you have to do unnecessary work
¡ Good for teams to be in charge of what excellence is for
themselves
§ and the QA team holds them to it
COMP3053.SQA.03: Software Quality
¡ Product Standards
§ e.g. documentation standards, coding conventions, class
structure, etc.
¡ Process Standards
§ e.g., when reviews / testing etc. are done
§ defined good practices at each stage of the SE process
COMP3053.SQA.03: Software Quality
¡ ISO 9000 standards
§ focus on Software Engineering processes
§ including formalised quality measurements
¡ ISO 9001: standards for measuring software quality
¡ IEC 61508: standards for safe & secure systems
¡ For various projects, depending on the context, you might
need specific standards
§ medical software standards
§ government software standards § encryption standards, etc.
COMP3053.SQA.03: Software Quality
¡1) Planning for Quality
¡2) Agreeing/Using Standards
¡4) Measuring Quality
Inspecting for Quality
COMP3053.SQA.03: Software Quality
¡ Quality Reviews (and Reports)
§ reviews/inspections of the quality at each stage
Software development process
Quality management process
Standards and Quality
procedures
Quality review reports
Figure 24.1 Quality management and software development
COMP3053.SQA.03: Software Quality
¡ Inspections during coding process
¡ Paired coding does informal code inspections
¡ Fagan (1986) estimated that 60%+ of bugs can be found
by inspecting code
¡ Prowell (1999) claims they found more than 90% of
COMP3053.SQA.03: Software Quality
¡ A group of 3-7 people examine a concrete SE output § specific reviewers from QA team
§ project manager (or not?), senior designer,
§ 1 or 2 persons who led/built the thing being reviewed § About 2 hours
¡ Focus on
§ finding problems and non-conformance to standards
§ checking for completeness
§ or missing or incorrect logical steps
§ do code segments, diagrams, tests, reqs, specs make sense?
¡ Produce documentation
§ evidence of quality for client acceptance
COMP3053.SQA.03: Software Quality
¡ Review Leader
§ chairs the meeting
¡ Recorder
§ keeps track of issues – the documentation
§ reads through the design or code
¡ 1 or more Reviewers § identify the problems
COMP3053.SQA.03: Software Quality
¡Fagan, IBM (1986)
¡ A special form of Formal Inspections
§ specialised for inspecting code ¡ More Specific Roles:
§ Moderator (Review leader)
§ Designer – person who designed the code
§ Coder/Implementer – person responsible for code § Tester – person who has/will test it
COMP3053.SQA.03: Software Quality
¡ Ideally people independently examine the doc in advance § and are familiar with it
¡ The review should take place –
§ a person reads through the document/code § focusing on finding, not solving, problems
¡ Output is a list of problems that need fixing § and should then be fixed
§ and fixes audited for completion
COMP3053.SQA.03: Software Quality
¡ Introduction
§ what is being inspected, why, and by whom
¡ Inspector/Reader
§ reviews the document/code, step by step
¡ People announce/query problems that they spot § people judge severity and importance of the problem § do not discuss how to solve the problem
§ tabulates: problem, severity, and importance
¡ Finally, at the end
§ strategies for resolving problems are proposed
COMP3053.SQA.03: Software Quality
COMP3053.SQA.03: Software Quality
¡ Criticising the person who built the document
§ not discussing how to make the document better
§ the moderator should make sure this doesn’t happen
¡ People worry that their performance will be judged § e.g., by managers or employers
§ avoid inviting people’s line managers to the inspection
¡ People don’t properly prepare before inspection
§ make sure people have carefully read the document first
¡ People try to discuss every problem as they find it § and very little gets actually inspected
COMP3053.SQA.03: Software Quality
¡ Used to judge quality at all SE Process Stages
§ including Reqs and Specs – which can’t be unit tested
¡ Can find a large number of errors (~80%)
§ including problems that aren’t found by testing
¡ Should be ~2hrs, involving 3-7 people ¡ Should focus on finding problems
§ not solving them
¡ Should produce tabulated problems
§ including descriptions, and ratings of severity/importance
COMP3053.SQA.03: Software Quality
¡1) Planning for Quality
¡2) Agreeing/Using Standards ¡3) Inspecting for Quality
Measuring Quality
COMP3053.SQA.03: Software Quality
¡ Another aim of the QA Team
§ is to improve the process between projects § documenting what worked well
¡ Aim: to improve the QA standards in the company
COMP3053.SQA.03: Software Quality
¡ Different to other Engineering disciplines § harder to specify everything about software,
than, e.g., a bridge
¡ Software Quality is subjective rather than
§ May include elegance and experienced usability
¡ Quality characteristics are hard to measure § E.g., how maintainable is it? 42?
COMP3053.SQA.03: Software Quality
¡ Instead, we try to ask/answer:
§ have code and documentation standards been followed? § has the software been properly tested?
§ is the software sufficiently dependable/reliable?
§ is the performance acceptable?
§ is the software usable?
§ is the software well structured and understandable?
¡ QA Team help define how to answer these qs § in a way that is corporately acceptable/agreeable
COMP3053.SQA.03: Software Quality
¡ These non-functional aspects often define quality
¡ They are hard to measure, and sometimes conflict
¡ Part of a Quality Plan is to set the Quality Goals § this is to consider which are most important
COMP3053.SQA.03: Software Quality
¡ Some of the subjective measures of quality
can be indirectly inferred from objective
§ These are things that can be actually counted: ▪ number of lines of code
▪ Fog Index (readability of comments)
▪ number of reported faults reported after delivery
▪ number of person days for coding ▪…
COMP3053.SQA.03: Software Quality
¡ Some of the subjective measures of quality
can be indirectly inferred from objective
§ These are things that can be actually counted:
▪ number of lines of code
Code/Predictor Measures
▪ Fog Index (readability of comments)
▪ number of reported faults reported after delivery
▪ number of person days for coding
Control/Process Measures
COMP3053.SQA.03: Software Quality
¡ Control/Process Measures
§ measuring the success of your SE Process
§ help decide whether to improve processes later § (We’ll see this later)
¡ Code/Predictor Measures
§ help you to judge aspects of code quality
§ but they are only predictors of quality ▪ e.g., predictors of maintainability
▪ e.g., predictors of substandard quality
COMP3053.SQA.03: Software Quality
Software metric
Description
Fan-in/Fan-out
Fan-in is a measure of the number of functions or methods that call another function or method (say X). Fan-out is the number of functions that are called by function X. A high value for fan-in means that X is tightly coupled to the rest of the design and changes to X will have extensive knock-on effects. A high value for fan-out suggests that the overall complexity of X may be high because of the complexity of the control logic needed to coordinate the called components.
Length of code
This is a measure of the size of a program. Generally, the larger the size of the code of a component, the more complex and error-prone that component is likely to be. Length of code has been shown to be one of the most reliable metrics for predicting error-proneness in components.
Cyclomatic complexity
This is a measure of the control complexity of a program. This control complexity may be related to program understandability.
Length of identifiers
This is a measure of the average length of identifiers (names for variables, classes, methods, etc.) in a program. The longer the identifiers, the more likely they are to be meaningful and hence the more understandable the program.
Depth of conditional nesting
This is a measure of the depth of nesting of if-statements in a program. Deeply nested if-statements are hard to understand and potentially error-prone.
This is a measure of the average length of words and sentences in documents. The higher the value of a document’s Fog index, the more difficult the document is to understand.
COMP3053.SQA.03: Software Quality
Object-oriented metric
Description
Weighted methods per class (WMC)
This is the number of methods in each class, weighted by the complexity of each method. Therefore, a simple method may have a complexity of 1, and a large and complex method a much higher value. The larger the value for this metric, the more complex the object class. Complex objects are more likely to be difficult to understand. They may not be logically cohesive, so cannot be reused effectively as superclasses in an inheritance tree.
Depth of inheritance tree (DIT)
This represents the number of discrete levels in the inheritance tree where subclasses inherit attributes and operations (methods) from superclasses. The deeper the inheritance tree, the more complex the design. Many object classes may have to be understood to understand the object classes at the leaves of the tree.
Number of children (NOC)
This is a measure of the number of immediate subclasses in a class. It measures the breadth of a class hierarchy, whereas DIT measures its depth. A high value for NOC may indicate greater reuse. It may mean that more effort should be made in validating base classes because of the number of subclasses that depend on them.
Coupling between object classes (CBO)
Classes are coupled when methods in one class use methods or instance variables defined in a different class. CBO is a measure of how much coupling exists. A high value for CBO means that classes are highly dependent, and therefore it is more likely that changing one class will affect other classes in the program.
Response for a class (RFC)
RFC is a measure of the number of methods that could potentially be executed in response to a message received by an object of that class. Again, RFC is related to complexity. The higher the value for RFC, the more complex a class and hence the more likely it is that it will include errors.
Lack of cohesion in methods (LCOM)
LCOM is calculated by considering pairs of methods in a class. LCOM is the difference between the number of method pairs without shared attributes and the number of method pairs with shared attributes. The value of this metric has been widely debated and it exists in several variations. It is not clear if it really adds any additional, useful information over and above that provided by other metrics.
COMP3053.SQA.03: Software Quality
¡ Can only make limited assumptions about code measures
¡ What a metric predicts can depend on the
language used
§ So, hard to compare across projects/languages
¡ Still unsure whether all these metrics are useful
¡ Metrics can only be used as predictors
§ once correlated with past project success
§ Firms develop metrics over time that work for them
COMP3053.SQA.03: Software Quality
¡1) Planning for Quality
¡2) Agreeing/Using Standards ¡3) Inspecting for Quality
¡4) Measuring Quality
COMP3053.SQA.03: Software Quality
¡ Quality Assurance is a lot more than
release/acceptance testing
§ it’s about planning for high quality goals
§ it’s about everyone aiming for high quality
§ it’s about inspecting for quality at each stage
§ it’s about taking / learning from metrics ▪ of software quality
▪ and process quality
COMP3053.SQA.03: Software Quality
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com