Software Engineering I Session 10 Configuration Management and

Software Engineering I Session 10 Configuration Management and Software Quality

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

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.

Configuration management

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.

Configuration Management • Key configuration management activities include: Version management Release management Change management System building Keeping track of multiple versions of system components ensuring changes made by different developers do not interfere. Preparing software for external release. Keeping track of the system versions that have been released for customer use. Managing requests for changes to the software from customers and developers. Assembling program components, data and libraries, then compiling these to create an executable system.

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.

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.

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.

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

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.

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.

Distributed Version Control Systems • 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.

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.

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.

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)

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

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

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.

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 Medium risk until the new system is running smoothly. Phased The new version is released in increments, gradually replacing the old system. Lower risk

Software Quality Management

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: Safety Security Reliability Resilience Robustness Understandability Testability Adaptability Modularity Complexity Portability Usability Reusability Efficiency Learnability

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.

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 • •

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.

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.

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 7925 -1) • Or internal: – Organisational – Project

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.

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.

Product and process standards

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.

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

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

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.

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.

Software Measurement

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.

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.

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.

Relationships between internal and external software

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!

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).

1 C 4 h 3 0 /a p 1 t 2 /e r 2 0 2 1 4 Q u a l i t y m a n a g e 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). Fanout 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.

1 C 4 h 4 0 /a p 1 t 2 /e r 2 0 2 1 4 Q u a l i t y m a n a g e 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 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.

1 C 4 h 5 0 /a p 1 t 2 /e r 2 0 2 1 4 Q u a l i t y m a n a g e 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 This represents the number of discrete levels in the inheritance tree where tree (DIT) 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.

1 C 4 h 6 0 /a p 1 t 2 /e r 2 0 2 1 4 Q u a l i t y m a n a g e 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.