Software Engineering I Session 10

1. Software Engineering ISession 10 Configuration Management and Software Quality

2. Recap • 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.

6. Configuration Management • Key configuration management activities include:

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.

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.

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

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

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)

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:

20. Release Planning • Release management should be designed to minimise risk and ensure business continuity.

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:

23. Software Quality Management • Software quality management is important at both an organisational and project level.

24. Software Quality Management Team • The quality management team will engage in several quality assurance activitiesto ensure the quality of deliverables: • Quality planning • Reviews • Inspections • Ensuring process adherence • Change control • 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.

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.

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

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.

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.

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

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. Chapter 24 Quality management Static software product metrics

44. Chapter 24 Quality management Static software product metrics

45. Chapter 24 Quality management The CK object-oriented metrics suite

46. Chapter 24 Quality management The CK object-oriented metrics suite