1. Software Engineering I Session 10
Configuration Management and Software Quality

2. Recap Project planning You are a software project manager
Not a software engineer (programmer, testing engineer, requirement analyst, …)
Project management aspects of SE
Risk management, Estimation (CoCoMo cost modelling)
Project planning
Project schedule, risk management (and resource allocation)
Quality assurance planning
Configuration management planning
Deployment planning
Maintenance planning

3. Learning objectives
Know the essential functionality of version control systems
Understand the fundamentals of systems building
Understand the basics of software release management
Understand the basics of quality management processes
Understand how measurement may be helpful in assessing some software quality measurements.

4. Configuration management

5. Configuration Management
Software systems are constantly changing during development and use
System requirements changes must be implemented
New components are added
New functionality is added
As changes are made to the software, a new version of the system is created
Several versions may be under development and in use at the same time
Configuration management is concerned with the policies, processes and tools for managing changing software systems.
As changes are made to the software, a new version of a system is created. Most systems can be thought of as a set of versions each of which may have to maintained and maintained.
Versions implement proposals for change, corrections of faults, and adaptations for different hardware and operating systems
May modify the wrong version, deliver the wrong version, or even forget where the software source code for a particular version of the system/component is stored.

6. Configuration Management
Key configuration management activities include:
Version management
Keeping track of multiple versions of system components ensuring changes made by different developers do not interfere.
Release management
Preparing software for external release. Keeping track of the system versions that have been released for customer use.
Change management
Managing requests for changes to the software from customers and developers.
System building
Assembling program components, data and libraries, then compiling these to create an executable system.
1 for individual project
2 essential for team project (sometimes these developers are working in the same place, but. Increasingly, distributed with members in different locations across the world
Change management: work out the costs and impact of making these changes, and decide if and when the changes should be implemented.
System building:
CM tools are essential

7. Version Management
Version management is the process of keeping track of different versions of
software components and the system
in which these components are used
The primary aim of version management is to:
Maintain the integrity of individual versions of project assets.
To make sure changes to one version of an asset does not interfere with other versions.
For large systems, there is never just one working version of a system; there are always several versions of the system in different stages. Several teams may be involved in the development of different system versions.

8. Version management – Codelines and Baselines
A codeline is a sequence of versions of component source code
with later versions in the sequence derived from earlier versions.
A baseline is a definition of a specific system
specifies the component versions that are included in the system
plus a specification of the libraries used, configuration files, etc.
Baselines are important because you may have to roll back to a specific version of a complete system.

9. Branching and Merging
Branching: rather than a single linear sequence of versions that reflect changes to a component over time, there may be several independent sequences.
At some stage, it may be necessary to merge codeline branches to create a new version of a component
that includes all changes that have been made.
A consequence of the independent development of the same component is that codelines may branch. Rather than a linear sequence of versions that reflect changes to the component over time, there may be several independent sequences.
This is normal in system development where different developers work independently on different versions of the source code and change it in different ways. It is generally recommended that a new branch should be created so that changes do not accidentally break a working system.
Branching is the creation of a new code line from a version in an existing codeline.

10. Version Control Systems
Version control systems identify, store, and control access to the different versions of components or general artefacts
There are two types of modern version control system
Centralised systems (e.g. Subversion).
Distributed systems (e.g. Git)
Key features:
Version and release identification
Change history recording
Independent development
Project support
Storage management
Have you ever used a version control system like Git and GitHub?
What advantages does distributed version control offer?
Version contro
Control access to organisational assets.
Allow storage of organisational assets.
Control the ability to change different versions of assets.
Record changes to organisational assets.
Allows the creation of baseline versions of systems.
l systems identify, store and control access to the different versions of components.

11. Centralised Version Control Systems
To support independent development without interference, centralised version control systems use the concept of a project repository and a private workspace.
The project repository maintains the master version of all components.
It is used to create baselines for system building.
When making modifications, developers check out assets from the repository into their private workspace.
When they have finished their changes, the changed assets are checked in to the repository.
Asset integrity is protected by controlling the check in/check out sequence.

12. Distributed Version Control Systems
In distributed version control systems, a master repository is hosted remotely on a server.
Instead of checking out the files that they need, developers create a local clone of the master repository.
Developers then work on checked out assets and maintain the new versions on their private repository on their own computer.
When changes are complete, they commit these changes and update their private server repository.
They can then push these changes to the project repository.

13. Distributed Version Control Systems
Provide a two-way backup mechanism for the repository. If the master repository is corrupted, work can continue and the project repository can be restored from local copies.
Allow for off-line working, so that developers can commit changes if they do not have a network connection.
Allow developers to compile and test an entire system on their local machines and test the changes that they have made.

14. Open source development
Distributed version control is essential for open source development.
Several people may be working simultaneously on the same system
without any central coordination
As well as a private repository on their own computer, developers also maintain a public server repository
to which they push new versions of components that they have changed.
It is then up to the open-source system ‘manager’ （Charlie) to decide when to pull these changes into the definitive system.

15. System building System building is the process of
creating a complete, executable system
by compiling and linking
the system components, external libraries,
configuration files, etc.
System building tools and version management tools must communicate
as the build process involves checking out component versions from the repository managed by the version management system.
The configuration description used to identify a baseline is also used by the system building tool.
System building involves assembling a large amount of information about the software and its operating environment.
The project repository maintains the master version of all components, which is used to create baselines of system building.

16. Build platforms The development system
which includes development tools such as
compilers, source code editors, etc.
Developers check out code from the
version management system into a private
workspace before making changes to the system.
The build server
used to build definitive, executable versions of the system.
Developers check-in code to the version management system before it is built
The system build may rely on external libraries that are not included in the version management system.
The target environment
which is the platform on which the system executes.
For real-time and embedded systems, the target environment is often smaller and simpler than the development environment (e.g. a cell phone)
Building is a complex process, which is potentially error-prone, as three different system platforms may be involved.

17. Tools for system integration and building
Build script generation
Analyse the program being built, identify dependent components, generate a build script (configuration file)
Version management system integration
Minimal re-compilation
Set up compilations
Executable system creation
Test automation
Reporting
Documentation generation

18. Release Management
A system release is a version of a software system that is distributed to customers.
For mass market software, there are two types of release:
Major releases (deliver significant new functionality).
Minor releases (repair bugs and fix reported problems).
As well as executable code, a release may also include one or more of
Configuration files
Data files
An installation program
Electronic and hard-copy documentation
Packaging and associated publicity

19. Release Drivers
There are several key drivers that determine the need for a version release, including:
Competition
A new system release may be necessary because a competing product has introduced new features.
Marketing
The marketing department of an organisation may have made a commitment for releases to be available at a particular date.
Platform
You may have to create a new release of a software application when a new version of the operating system platform is released.
Technical quality
If serious system faults are reported, it may be necessary to issue a fault repair release.

20. Release Planning
Release management should be designed to minimise risk and ensure business continuity.
Plunge
The new version replaces the old version in its entirety with immediate effect.
Higher risk
Parallel
The two versions operate side-by-side for a period until the new system is running smoothly.
Medium risk
Phased
The new version is released in increments, gradually replacing the old system.
Lower risk
Why is the plunge strategy high risk?
Are there any circumstances where the use of the plunge strategy might be justified?

21. Software Quality Management

22. Software Quality Software quality is a measure of the degree to which
software components, systems or processes meet specified requirements and/or user/customer needs and expectations.
The extent to which software meets its functional requirements is a key measure of its quality.
Software quality can also be measured using a range of key non-functional system attributes:
(IEEE Standard for Software Quality Assurance Processes).
1. Is it ever possible to ensure high levels of all the quality attributes listed above?
Safety
Understandability
Portability
Security
Testability
Usability
Reliability
Adaptability
Reusability
Resilience
Modularity
Efficiency
Robustness
Complexity
Learnability

23. Software Quality Management
Software quality management is important at both an organisational and project level.
Organisational
Aims to establish a framework of organisational processes and standards that will lead to the production of high-quality software.
Project
The application of organisational processes and standards to individual projects.
1. What would be the key inputs into organisational quality management practice?

24. Software Quality Management Team
The quality management team is responsible for:
Creating and updating organisational standards and quality assurance processes
Checking project deliverables to ensure they are consistent with organisational standards.
Reviewing project documentation to check for omissions and/or errors.
Carrying out product release testing.
To ensure objectivity, the quality management team should always be independent of the software development process.
The quality management team will engage in several quality assurance activities to ensure the quality of deliverables:
Quality planning
Reviews
Inspections
Ensuring process adherence
Change control
1. Why should the QM team be independent of the development team?

25. Software Quality Planning
In larger projects or plan-driven projects, project planning should include a quality plan.
A quality plan should:
Describe the product being built.
Set out the most important quality attributes for a product.
Set out the QA processes and standards that should be applied, and the mechanisms for applying them.
Quality plans should be short and succinct to ensure they are read.

26. Quality Assurance Processes
The quality of a software product is significantly influenced by the quality of the quality assurance processes ;-) used in development.
Particularly in large plan-driven projects, there is thus a strong emphasis on quality processes and process refinement.
1. Why are robust QA processes more important in large, plan-driven projects?

27. Software Standards
Standards define the required attributes of a product or process. They play an important role in quality management.
Standards may be derived from sources external to an organisation:
International (e.g. ISO 9001)
National (e.g. BSI )
Or internal:
Organisational
Project
1. What are the possible advantages and disadvantages of adherence to international standards such as ISO 9001?

28. Software Standards – Importance and Issues
The use of software standards is important for several reasons:
They encapsulate best (or the most appropriate) practice of the organisation.
They provide a framework for defining organisational quality practices.
They provide continuity – new staff can understand the organisation and its expectations by understanding the standards that are used.
However, the use of standards can present a number of problems:
They may be out of step with fast evolving technologies.
They may add tasks that do not directly contribute to value (e.g. bureaucratic form filling).
They are not easily applicable to small projects and agile methods.
1. Why are software standards not easily applicable to agile methods?

29. Product and process standards
Product standards
Apply to the software product being developed.
include document standards, such as the structure of requirements documents,
documentation standards, such as a standard comment header for an object class definition,
coding standards, which define how a programming language should be used.
Process standards
These define the processes that should be followed during software development.
include definitions of specification,
design and validation processes,
process support tools
a description of the documents that should be written during these processes.

30. Product and process standards

31. ISO 9001 Standards Framework
ISO 9001 is a framework used to develop specific quality standards and processes across a range of industries, including the software development industry.
It is NOT a standard per se
It details:
A set of general quality principles.
A set of core areas where quality processes should be applied.
Organisational standards and procedures that should be defined.
The latest revision to ISO 9001 was in 2015.
Organisations can apply for ISO 9001 certification via an external accrediting body.
1. What advantages would ISO certification confer on a software development enterprise?

32. ISO 9001 – Core Processes
ISO 9001 identifies a set of core areas where quality processes should be developed and applied.
Organisation must document how the process relate to these core processes

33. ISO Use
ISO 9001 is instantiated as organisational quality practice.
In turn, organisational quality practice is used to develop quality plans for individual projects.

34. Quality Management in Agile Methods
Quality management in agile methods is informal rather than document-based.
It relies on establishing a quality culture, where all team members feel responsible for software quality and take actions to ensure that quality is maintained.
The agile community is fundamentally opposed to what it sees as the bureaucratic overheads of standards-based approaches and quality processes as embodied in ISO 9001.
Why are agile practitioners fundamentally opposed to standards based approaches to SD?
What is meant by a quality culture?

35. Quality Management in Agile Methods
Specific QA measures in agile methods include:
Pair programming (Extreme programming).
Sprint reviews (Scrum).
Check before check-in.
Never break the build.
Fix problems when you see them.
TDD.
Customer participation.

36. Software Measurement

37. Software measurement and metric
Software measurement is concerned with deriving a numeric value for an attribute of a software product or process.
This allows for objective comparisons between techniques and processes.
A software metric is a characteristic of a software system, process or related documentation
Lines of code in a program, the Fog index, number of person-days required to develop a component.
Allow the software and the software process to be quantified, may be used to predict product attributes or to control the software process.

38. Control/process metric
Control metrics are associated with software processes
The time taken for a particular process to be completed
E.g., the total time devoted to the process, calendar time, the time spent on the process by particular engineers, and so on.
The resources required for a particular process
Resources might include total effort in person-days, travel costs or computer resources.
The number of occurrences of a particular event
Examples of events that might be monitored:
the number of defects discovered during code inspection,
the number of requirements changes requested,
the number of bug reports in a delivered system and
the average number of lines of code modified in response to a requirements change.

39. Product metrics
Product metrics are predictor metric used to qualify internal attributes of a software system.
associated with the software itself, such as system size (line of code), number of methods associated with each class, …
Product metrics can be used for general predictions or to identify anomalous components.
To assign a value to system quality attributes
By measuring the characteristics of system components and then aggregating these measurements, you can assess system quality attributes, such as maintainability.
To identify the system components whose quality is sub-standard
Measurements can identify individual components with characteristics that deviate from the norm.

40. Relationships between internal and external software

41. Metrics assumptions
The internal attribute must be measured accurately.
The relationship exists between what we can measure and what we want to know.
We can only measure internal attributes but are often more interested in external software attributes.
This relationship has been formalised and validated.
It may be difficult to relate what can be measured to desirable external quality attributes!

42. Product metrics
A quality metric should be a predictor of product quality.
Static metrics
are collected by measurements made of the system representations
Static metrics help assess complexity, understandability and maintainability.
have an indirect relationship with quality attributes
need to try and derive a relationship between these metrics and properties such as complexity, understandability and maintainability.
Dynamic metrics
are collected by measurements made of a program in execution
Dynamic metrics help assess efficiency and reliability
are closely related to software quality attributes
It is relatively easy to measure the response time of a system (performance attribute) or the number of failures (reliability attribute).

43. Static software product metrics
10/12/2014
Chapter 24 Quality management
Static software product metrics
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.

44. Static software product metrics
10/12/2014
Chapter 24 Quality management
Static software product metrics
Software metric
Description
Cyclomatic complexity
This is a measure of the control complexity of a program. This control complexity may be related to program understandability. I discuss cyclomatic complexity in Chapter 8.
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.
Fog index
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.

45. The CK object-oriented metrics suite
10/12/2014
Chapter 24 Quality management
The CK object-oriented metrics suite
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.

46. The CK object-oriented metrics suite
10/12/2014
Chapter 24 Quality management
The CK object-oriented metrics suite
Object-oriented metric
Description
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.