Software Engineering I Session 9 Software Quality and

Software Engineering I Session 9 Software Quality and Configuration Management

Recap • You are a software project manager – Not a software engineer (programmer, testing engineer, requirement analyst, …) • Project management aspects of SE • Risk management, Project planning – – – Project scheduling Quality assurance Configuration management Deployment planning Maintenance planning

Configuration management

Configuration Management • Software systems are constantly changing during development/use – System requirements changes must be implemented – New components are added – New functionality is added • As changes are made, 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. (cf. Session 5)

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.

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

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.

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.

Elements of Software quality assurance • • • Standards. Testing. Reviews and audits. Error/defect collection and analysis Change management Education. Vendor management Security management. Safety. Risk management.

Inspections • Inspections involve a systematic, formal scrutiny of development artefacts (code, requirements specs, etc. ) – with the aim of discovering anomalies and defects earlier in the development lifecycle • Advantages over testing – Because inspection is a static process, there is no need to be concerned with interactions between errors. – Incomplete versions of a system can be inspected. – Can also be used to test non-functional attributes of a program (e. g. compliance with standards, portability and maintainability)

Code review • What is code review? • Kinds of code review • Example

Assuring software quality is hard … • What are we assuring? – Building the right system (validation) – Building the system right (verification) • correct, secure, reliable, available • usable, cost effective, maintainable • Why are we assuring it? – Business, legal, ethical, social reasons • How do we assure it?

Challenges of building large systems • Challenges of building large systems – How to ensure maintainable, DRY, readable, bug-free code? • Average defect detection rate for various testing approaches – Unit testing: 25% – Function testing: 35% – Integration testing: 45% • How can we do better?

Code reviews • Code review: A constructive review of a fellow developer’s code. A required sign-off from another team member before a developer is permitted to check in changes or new code. • Analogy: when writing articles for a newspaper, what is the effectiveness of … – spell-check/grammar check? – author editing own article? – others editing others’ articles?

Code reviews: mechanics • Who: original developer and reviewer, sometimes together in person, sometimes offline. • What: reviewer gives suggestions for improvement on a logical and/or structural level, to conform to a common set of quality standards. – Feedback leads to refactoring (to be discussed next week). – Reviewer eventually approves code. • When: code author has finished a coherent system change that is otherwise ready for checkin – Change shouldn't be too large or too small. – Before committing the code to the repository or incorporating it into the new build.

Code reviews: why do them? • Improved code quality – Prospect of someone reviewing your code raises quality threshold. – Forces code authors to articulate their decisions. • Hands-on learning experience from peers – Direct feedback leads to better algorithms, tests, design patterns. • Better understanding of complex code bases – Reviewing others’ code enhances overall understanding of the system, reduces redundancy.

Code reviews: studies • Average defect detection rates – – – Unit testing: 25% Function testing: 35% Integration testing: 45% Design and code inspections: 55% and 60%. Note: a rough estimation of efficiency • 11 programs developed by the same group of people – First 5 without reviews: average 4. 5 errors per 100 lines of code – Next 6 with reviews: average 0. 82 errors per 100 lines of code – Errors reduced by > 80 percent.

Code reviews: who does them? • Everyone: a common industry practice. • Made easier by advanced tools that – integrate with version control – highlight changes (i. e. , diff function) – e. g. , github pull requests

Common types of code review • Tool-assisted reviews • Formal inspections • Walkthroughs • Pair programming

Tool-assisted code reviews • Most common form of code review – Authors and reviewers use software tools designed for peer code review. – The tool gathers files, displays diffs and comments, enforces reviews. • Advantages – Lightweight, integrated into the workflow. • Disadvantages – Hard to ensure review quality and promptness

Formal inspections • A more formalised code review with – roles (moderator, author, reviewer, scribe, etc. ) – several reviewers looking at the same piece of code – a specific checklist of kinds of flaws to look for • flaws that have been seen previously • high-risk areas such as security • Advantages – High review quality with specific expected outcomes (e. g. report, list of defects) • Disadvantages – Heavyweight, time-consuming, expensive

Walkthroughs • An informal discussion of code between author and a single reviewer. – The author walks the reviewer through a set of code changes. • Advantages – Simplicity in execution: anyone can do it, any time. – In-person interaction, learning, and sharing. • Disadvantages – Not an enforceable process, no record of the review. – Easy for the author to unintentionally miss a change. – Reviewers rarely verify that defects were fixed.

Pair programming • Two developers writing code at a single workstation with – only one typing – continuous free-form discussion and review • Advantages – Deep reviews, instant and continuous feedback. – Learning, sharing, team-building. • Disadvantages – Some developers don’t like it. – No record of the review process. – Time consuming.

Example

Possible changes • • • Comment. Make fields private. Replace magic values (e. g. 365. 25) with constants. Use an enum for account types. Use consistent whitespace, line breaks, etc.

Improved code (1/2)

Improved code (2/2)