Safety Understandability Portability

Security Testability Usability

Reliability Adaptability Reusability
SQ Management Resilience
Robustness
Modularity
Complexity
Efficiency
Learnability

▪ Concerned with ensuring that the required level of quality is achieved in a software product.

▪ Software quality
▪ Quality, simplistically, means that a product should meet its specification.

▪ Software fitness for purpose

▪ Have programming and documentation standards been followed in the development process?
▪ Has the software been properly tested?
▪ Is the software sufficiently dependable to be put into use?
▪ Is the performance of the software acceptable for normal use?
▪ Is the software usable?
▪ Is the software well-structured and understandable?

2
Process and product quality
▪ The quality of a developed product is influenced by the quality of the production
process.
▪ This is important in software development as some product quality attributes are
hard to assess.

3
Software standards
▪ Standards define the required attributes of a product or process. They play an important
role in quality management.
▪ Standards may be international, national, organizational or project standards.
▪ Product standards define characteristics that all software components should exhibit e.g.
a common programming style.
▪ Process standards define how the software process should be enacted.
Product standards Process standards
Design review form Design review conduct
Requirements document structure Submission of new code for system building
Method header format Version release process
Java programming style Project plan approval process
Project plan format Change control process
Change request form Test recording process
4
ISO 9001 standards framework
▪ An international set of standards that
can be used as a basis for
developing quality management
systems.
▪ ISO 9001, the most general of these
standards, applies to organizations
that design, develop and maintain
products, including software.

5
ISO 9001 and quality management
▪ ISO 9001 certification
▪ Quality standards and procedures
should be documented in an
organisational quality manual.
▪ An external body may certify that an
organisation’s quality manual
conforms to ISO 9000 standards.
▪ Some customers require suppliers to
be ISO 9000 certified although the
need for flexibility here is increasingly
recognised.

6
 Fault class Inspection check
• Are all program variables initialized before their values are used?
• Have all constants been named?
• Should the upper bound of arrays be equal to the size of the array or Size -
Data faults
1?
• If character strings are used, is a delimiter explicitly assigned?
• Is there any possibility of buffer overflow?
• For each conditional statement, is the condition correct?
• Is each loop certain to terminate?
• Are compound statements correctly bracketed?
Control faults
• In case statements, are all possible cases accounted for?
• If a break is required after each case in case statements, has it been
included?
• Are all input variables used?
Input/output faults • Are all output variables assigned a value before they are output?
• Can unexpected inputs cause corruption?

Program •
•
Do all function and method calls have the correct number of parameters?
Do formal and actual parameter types match?
inspections Interface faults •
•
Are the parameters in the right order?
If components access shared memory, do they have the same model of the
checklist •
shared memory structure?
If a linked structure is modified, have all links been correctly reassigned?
Storage management
• If dynamic storage is used, has space been allocated correctly?
faults
• Is space explicitly deallocated after it is no longer required?
Exception
• Have all possible error conditions been taken into account? 7
management faults
Review with Agile Methods
▪ The review process in agile software development is usually informal.
▪ In Scrum, for example, there is a review meeting after each iteration of the
software has been completed (a sprint review), where quality issues and
problems may be discussed.
▪ In extreme programming, pair programming ensures that code is constantly being
examined and reviewed by another team member.
▪ XP relies on individuals taking the initiative to improve and refactor code. Agile
approaches are not usually standards-driven, so issues of standards compliance
are not usually considered.

8
Inspection with Agile Methods
▪ Agile processes rarely use formal inspection or peer review processes.
▪ Rather, they rely on team members cooperating to check each other’s code, and
informal guidelines, such as ‘check before check-in’, which suggest that
programmers should check their own code.
▪ Extreme programming practitioners argue that pair programming is an effective
substitute for inspection as this is, in effect, a continual inspection process.
▪ Two people look at every line of code and check it before it is accepted.

9
SCM Activities
1. Change management This involves keeping track of requests for changes to the software
from customers and developers, working out the costs and impact of making these changes,
and deciding if and when the changes should be implemented.
2. Version management This involves keeping track of the multiple versions of system
components and ensuring that changes made to components by different developers do not
interfere with each other.
3. System building This is the process of assembling program components, data, and libraries,
and then compiling and linking these to create an executable system.
4. Release management This involves preparing software for external release and keeping track
of the system versions that have been released for customer use.

10
SQM Process

11
SQM
Related
Important
Terms

12
Change Management
▪ Organizational needs and
requirements change during the
lifetime of a system, bugs have to be
repaired and systems have to adapt
to changes in their environment.
▪ Change management is intended to
ensure that system evolution is a
managed process and that priority is
given to the most urgent and cost-
effective changes.

13
Change Management and Agile Methods
▪ In some agile methods, customers are directly involved in change management.
▪ The propose a change to the requirements and work with the team to assess its
impact and decide whether the change should take priority over the features
planned for the next increment of the system.
▪ Changes to improve the software improvement are decided by the programmers
working on the system.
▪ Refactoring, where the software is continually improved, is not seen as an
overhead but as a necessary part of the development process.

14
Version Management System
▪ Version and release identification: Managed versions are assigned identifiers when
they are submitted to the system.
▪ Storage management: To reduce the storage space required by multiple versions of
components that differ only slightly, version management systems usually provide
storage management facilities.
▪ Change history recording: All of the changes made to the code of a system or
component are recorded and listed.
▪ Independent development: The version management system keeps track of
components that have been checked out for editing and ensures that changes made
to a component by different developers do not interfere.
▪ Project support: A version management system may support the development of
several projects, which share components.

15
Codelines and baselines
▪ A codeline is a sequence of versions of source code with later versions in the
sequence derived from earlier versions.
▪ Codelines normally apply to components of systems so that there are different
versions of each component.
▪ A baseline is a definition of a specific system.
▪ For example, a product line may be instantiated so that there are individual system
versions for different customers. You may have to recreate the version delivered to a
specific customer if, for example, that customer reports bugs in their system that have to
be repaired.

▪ The baseline therefore specifies the component versions that are included in the
system plus a specification of the libraries used, configuration files, etc.

16
Codelines and baselines

17
Check-in and check-out from a version repository

18
The Risk Management Process
▪ Risk Identification
▪ May be a team activities or based on the individual project manager’s experience.
▪ A checklist of common risks may be used to identify risks in a project
▪ Technology risks.
▪ People risks.
▪ Organizational risks.
▪ Requirements risks.
▪ Estimation risks.

19
The Risk Management Process
▪ RISK ANALYSIS
▪ Assess probability and seriousness of each risk.
▪ Probability may be very low, low, moderate, high or very high.
▪ Risk consequences might be catastrophic, serious, tolerable or insignificant.
▪ RISK PLANNING
▪ Consider each risk and develop a strategy to manage that risk.
▪ Avoidance strategies: The probability that the risk will arise is reduced;
▪ Minimization strategies: The impact of the risk on the project or product will be reduced;
▪ Contingency plans: If the risk arises, contingency plans are plans to deal with that risk;

▪ RISK MONITORING
▪ Assess each identified risks regularly to decide whether or not it is becoming less or more probable.
▪ Also assess whether the effects of the risk have changed.
▪ Each key risk should be discussed at management progress meetings.

20
Types of Risk

21
Types of
Risk

22
Thank You!