This document discusses configuration management (CM) and version control. It covers topics like version management, system building, change management, and release management. CM is important for software development as it allows tracking of changing software systems and components. Version control systems are key to CM, identifying and storing different versions. They support independent development through a shared repository and private workspaces. Developers check components in and out to make changes separately without interfering with each other.
This document discusses quality management in software development. It covers topics like software quality, standards, reviews/inspections, quality management in agile development, and software measurement. Regarding quality management, the key points are that it provides an independent check on the development process, ensures deliverables meet goals/standards, and the quality team should be independent from developers. Quality plans set quality goals and define assessment processes and standards to apply. Quality management is important for large, complex systems and focuses on establishing a quality culture for smaller systems.
The document discusses chapter 7 of a software engineering textbook which covers design and implementation. It begins by outlining the topics to be covered, including object-oriented design using UML, design patterns, and implementation issues. It then discusses the software design and implementation process, considerations around building versus buying systems, and approaches to object-oriented design using UML.
The document discusses different types of software testing:
- Development testing includes unit, component, and system testing to discover bugs during development. Unit testing involves testing individual program units in isolation.
- Release testing is done by a separate team to test a complete version before public release.
- User testing involves potential users testing the system in their own environment.
The goals of testing are to demonstrate that software meets requirements and to discover incorrect or undesirable behavior to find defects. Different testing types include validation testing to check correct functionality and defect testing to uncover bugs. Both inspections and testing are important and complementary methods in software verification.
This document provides an introduction to software engineering topics including:
1. What software engineering is, its importance, and the software development lifecycle activities it encompasses.
2. The many different types of software systems that exist and how software engineering approaches vary depending on the application.
3. Key fundamentals of software engineering that apply universally, including managing development processes, dependability, and reusing existing software components.
This document discusses key topics in systems engineering, including:
1) Systems engineering involves procuring, designing, implementing, and maintaining sociotechnical systems that include both technical and human elements.
2) Software systems are part of broader sociotechnical systems and software engineers must consider human, social, and organizational factors.
3) Sociotechnical systems have emergent properties that depend on the interactions between system components and cannot be understood by examining the components individually.
The chapter discusses software evolution, including that software change is inevitable due to new requirements, business changes, and errors. It describes how organizations must manage change to existing software systems, which represent huge investments. The majority of large software budgets are spent evolving, rather than developing new, systems. The chapter outlines the software evolution process and different approaches to evolving systems, including addressing urgent changes. It also discusses challenges with legacy systems and their management.
The document discusses architectural design and various architectural concepts. It covers topics like architectural design decisions, architectural views using different models, common architectural patterns like MVC and layered architectures, application architectures, and how architectural design is concerned with organizing a software system and identifying its main structural components and relationships.
The document discusses software processes and activities. It describes common process models like waterfall, incremental development, and configuration management. The key activities involved in most processes are specification, development, validation, and evolution. Specification defines system requirements while development includes design, implementation, and debugging. Validation ensures the system meets requirements through testing. Processes also evolve to adapt to changing needs.
This document discusses quality management in software development. It covers topics like software quality, standards, reviews/inspections, quality management in agile development, and software measurement. Regarding quality management, the key points are that it provides an independent check on the development process, ensures deliverables meet goals/standards, and the quality team should be independent from developers. Quality plans set quality goals and define assessment processes and standards to apply. Quality management is important for large, complex systems and focuses on establishing a quality culture for smaller systems.
The document discusses chapter 7 of a software engineering textbook which covers design and implementation. It begins by outlining the topics to be covered, including object-oriented design using UML, design patterns, and implementation issues. It then discusses the software design and implementation process, considerations around building versus buying systems, and approaches to object-oriented design using UML.
The document discusses different types of software testing:
- Development testing includes unit, component, and system testing to discover bugs during development. Unit testing involves testing individual program units in isolation.
- Release testing is done by a separate team to test a complete version before public release.
- User testing involves potential users testing the system in their own environment.
The goals of testing are to demonstrate that software meets requirements and to discover incorrect or undesirable behavior to find defects. Different testing types include validation testing to check correct functionality and defect testing to uncover bugs. Both inspections and testing are important and complementary methods in software verification.
This document provides an introduction to software engineering topics including:
1. What software engineering is, its importance, and the software development lifecycle activities it encompasses.
2. The many different types of software systems that exist and how software engineering approaches vary depending on the application.
3. Key fundamentals of software engineering that apply universally, including managing development processes, dependability, and reusing existing software components.
This document discusses key topics in systems engineering, including:
1) Systems engineering involves procuring, designing, implementing, and maintaining sociotechnical systems that include both technical and human elements.
2) Software systems are part of broader sociotechnical systems and software engineers must consider human, social, and organizational factors.
3) Sociotechnical systems have emergent properties that depend on the interactions between system components and cannot be understood by examining the components individually.
The chapter discusses software evolution, including that software change is inevitable due to new requirements, business changes, and errors. It describes how organizations must manage change to existing software systems, which represent huge investments. The majority of large software budgets are spent evolving, rather than developing new, systems. The chapter outlines the software evolution process and different approaches to evolving systems, including addressing urgent changes. It also discusses challenges with legacy systems and their management.
The document discusses architectural design and various architectural concepts. It covers topics like architectural design decisions, architectural views using different models, common architectural patterns like MVC and layered architectures, application architectures, and how architectural design is concerned with organizing a software system and identifying its main structural components and relationships.
The document discusses software processes and activities. It describes common process models like waterfall, incremental development, and configuration management. The key activities involved in most processes are specification, development, validation, and evolution. Specification defines system requirements while development includes design, implementation, and debugging. Validation ensures the system meets requirements through testing. Processes also evolve to adapt to changing needs.
This document discusses software reuse and application frameworks. It covers the benefits of software reuse like accelerated development and increased dependability. Application frameworks provide a reusable architecture for related applications and are implemented by adding components and instantiating abstract classes. Web application frameworks in particular use the model-view-controller pattern to support dynamic websites as a front-end for web applications.
This document discusses component-based software engineering (CBSE). It covers topics like components and component models, CBSE processes, and component composition. The key points are:
- CBSE relies on reusable software components with well-defined interfaces to improve reuse. Components are more abstract than classes.
- Essentials of CBSE include independent, interface-specified components; standards for integration; and middleware for interoperability.
- CBSE is based on principles like independence, hidden implementations, and replaceability through maintained interfaces.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Rapid and iterative development is emphasized to quickly adapt to changing requirements. Methods like Extreme Programming (XP) use practices like user stories, test-driven development, pair programming, and continuous refactoring to develop working software in short iterations.
The document discusses dependability in systems. It covers topics like dependability properties, sociotechnical systems, redundancy and diversity, and dependable processes. Dependability reflects how trustworthy a system is and includes attributes like reliability, availability, and security. Dependability is important because system failures can have widespread impacts. Both hardware and software failures and human errors can cause systems to fail. Techniques like redundancy, diversity, and formal methods can help improve dependability. Regulation is also discussed as many critical systems require approval from regulators.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Agile development aims to rapidly develop and deliver working software through iterative processes, customer collaboration, and responding to changing requirements. Extreme programming (XP) is an influential agile method that uses practices like test-driven development, pair programming, frequent refactoring, and user stories for requirements specification. The key principles of agile methods are also outlined.
This document discusses software processes and process models. It covers topics such as the waterfall model, incremental development, integration and configuration, process activities including specification, design, implementation, validation and evolution. It also discusses coping with change through techniques like prototyping and incremental delivery. The key aspects of software process models, activities, and improvement are summarized.
System modeling involves creating abstract models of a system from different perspectives, such as context, interactions, structure, and behavior. These models help analysts understand system functionality and communicate with customers. Context models show a system's external environment and relationships. Interaction models, such as use case and sequence diagrams, depict how users and systems interact. Structural models, like class diagrams, represent a system's internal organization. Behavioral models, including activity and state diagrams, illustrate a system's dynamic response to events or data. Model-driven engineering aims to generate implementation from system models.
This document provides an introduction and overview of key topics in software engineering. It discusses what software engineering is, the importance and costs of software development, different types of software projects and applications, and issues like complexity, security and scale that affect software. It also introduces software engineering processes, methods, and ethics. Common questions about the field are addressed. The document is the first chapter of a book on software engineering.
This chapter discusses system modeling and different types of models used, including:
- Context models which illustrate the operational context of a system.
- Interaction models which model interactions between a system and its environment.
- Structural models which display the organization of a system's components.
- Behavioral models which model a system's dynamic behavior in response to events or data.
- Model-driven engineering is discussed as an approach where models rather than code are the primary outputs.
The document discusses project planning, including topics like software pricing, plan-driven development, project scheduling, and agile planning. It covers the different stages of planning, from initial proposals to ongoing development. Project planning involves breaking work into parts, anticipating problems, and communicating the plan. Regular updates allow the plan to reflect new information and changes throughout the project.
Software evolution involves making ongoing changes to software systems to address new requirements, fix errors, and improve performance. There are several approaches to managing software evolution, including maintenance, reengineering, refactoring, and legacy system management. Key considerations for legacy systems include assessing their business value and quality to determine whether they should be replaced, transformed, or maintained.
This document discusses system modeling and different types of models used in system modeling. It covers context models, interaction models, structural models, behavioral models, and model-driven engineering. Some key points include:
- System modeling involves developing abstract models of a system from different perspectives or views. Models are often developed using the Unified Modeling Language (UML).
- Common model types include use case diagrams, sequence diagrams, class diagrams, state diagrams, and activity diagrams.
- Structural models show the organization and structure of a system. Behavioral models show the system's dynamic behavior and responses to events.
- Model-driven engineering is an approach where models rather than code are the primary outputs and code is generated
This chapter discusses distributed software engineering and distributed systems. It covers topics like distributed system characteristics including resource sharing, openness, concurrency, scalability and fault tolerance. Some key issues with distributed systems are their complexity, lack of single control, and independence of parts. The chapter addresses design issues for distributed systems such as transparency, openness, scalability, security, quality of service, and failure management. It also covers models of interaction, middleware, and client-server computing.
The document discusses several topics related to software project management including risk management, managing people, and teamwork. It describes the key activities of a project manager including planning, risk assessment, people management, reporting, and proposal writing. Specific risks at the project, product, and business levels are defined and strategies for risk identification, analysis, planning, monitoring, and mitigation are outlined. Effective people management is also emphasized, including motivating team members through satisfying different human needs and personality types. A case study demonstrates how addressing an individual team member's motivation issues can improve project outcomes.
Architectural design involves identifying major system components and their communications. Architectural views provide different perspectives of the system, such as conceptual, logical, process, and development views. Common architectural patterns include model-view-controller, layered, client-server, and pipe-and-filter architectures. Application architectures define common structures for transaction processing, information, and language processing systems.
Ian Sommerville, Software Engineering, 9th Edition Ch1Mohammed Romi
The document provides an introduction to software engineering concepts. It discusses what software engineering is, the importance of ethics in software development, and introduces three case studies that will be used as examples throughout the book. Specifically:
[1] It defines software engineering as an engineering discipline concerned with all aspects of software production. Professional and ethical practices are important.
[2] It discusses software engineering ethics and introduces the ACM/IEEE code of ethics for software engineers.
[3] It provides an overview of three case studies that will be referenced in later chapters: an insulin pump system, a patient management system, and a weather station system.
The document discusses various types of software testing:
- Development testing includes unit, component, and system testing to discover defects.
- Release testing is done by a separate team to validate the software meets requirements before release.
- User testing involves potential users testing the system in their own environment.
The goals of testing are validation, to ensure requirements are met, and defect testing to discover faults. Automated unit testing and test-driven development help improve test coverage and regression testing.
The document discusses reliability engineering and fault tolerance. It covers topics like availability, reliability requirements, fault-tolerant architectures, and reliability measurement. It defines key terms like faults, errors, and failures. It also describes techniques for achieving reliability like fault avoidance, fault detection, and fault tolerance. Specific architectures discussed include redundant systems and protection systems that can take emergency action if failures occur.
Ian Sommerville, Software Engineering, 9th EditionCh 8Mohammed Romi
The document discusses different types of software testing including unit testing, component testing, and system testing. Unit testing involves testing individual program components in isolation through techniques like partition testing and guideline-based testing. Component testing focuses on testing interactions between components through their interfaces. System testing integrates components to test their interactions and check for emergent behaviors that are not explicitly defined. The document also covers test-driven development, which involves writing tests before code in incremental cycles.
The document discusses architectural design, including:
- Architectural design determines how a software system is organized and structured. It identifies the main components and relationships.
- Architectural views show different perspectives of a system, such as logical, process, development, and physical views. Common patterns like model-view-controller and layered architectures are also covered.
- Architectural decisions impact system characteristics like performance, security, and maintainability. Common application architectures are also discussed.
The document discusses requirements engineering for software systems. It covers topics like functional and non-functional requirements, the requirements engineering process, elicitation, specification, validation, and change. It defines what requirements are, their different types and levels of abstraction. It also discusses stakeholders, and provides examples of functional and non-functional requirements for a healthcare management system called Mentcare.
This document discusses service-oriented software engineering and RESTful web services. It covers topics like service-oriented architectures, RESTful services, service engineering, and service composition. Key points include that services are reusable components that are loosely coupled and platform independent. Service-oriented approaches allow for opportunistic construction of new services and pay-per-use models. Web services standards like SOAP, WSDL, and WS-BPEL are also discussed. The document provides an example of a service-oriented in-car information system.
This document discusses software reuse and application frameworks. It covers the benefits of software reuse like accelerated development and increased dependability. Application frameworks provide a reusable architecture for related applications and are implemented by adding components and instantiating abstract classes. Web application frameworks in particular use the model-view-controller pattern to support dynamic websites as a front-end for web applications.
This document discusses component-based software engineering (CBSE). It covers topics like components and component models, CBSE processes, and component composition. The key points are:
- CBSE relies on reusable software components with well-defined interfaces to improve reuse. Components are more abstract than classes.
- Essentials of CBSE include independent, interface-specified components; standards for integration; and middleware for interoperability.
- CBSE is based on principles like independence, hidden implementations, and replaceability through maintained interfaces.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Rapid and iterative development is emphasized to quickly adapt to changing requirements. Methods like Extreme Programming (XP) use practices like user stories, test-driven development, pair programming, and continuous refactoring to develop working software in short iterations.
The document discusses dependability in systems. It covers topics like dependability properties, sociotechnical systems, redundancy and diversity, and dependable processes. Dependability reflects how trustworthy a system is and includes attributes like reliability, availability, and security. Dependability is important because system failures can have widespread impacts. Both hardware and software failures and human errors can cause systems to fail. Techniques like redundancy, diversity, and formal methods can help improve dependability. Regulation is also discussed as many critical systems require approval from regulators.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Agile development aims to rapidly develop and deliver working software through iterative processes, customer collaboration, and responding to changing requirements. Extreme programming (XP) is an influential agile method that uses practices like test-driven development, pair programming, frequent refactoring, and user stories for requirements specification. The key principles of agile methods are also outlined.
This document discusses software processes and process models. It covers topics such as the waterfall model, incremental development, integration and configuration, process activities including specification, design, implementation, validation and evolution. It also discusses coping with change through techniques like prototyping and incremental delivery. The key aspects of software process models, activities, and improvement are summarized.
System modeling involves creating abstract models of a system from different perspectives, such as context, interactions, structure, and behavior. These models help analysts understand system functionality and communicate with customers. Context models show a system's external environment and relationships. Interaction models, such as use case and sequence diagrams, depict how users and systems interact. Structural models, like class diagrams, represent a system's internal organization. Behavioral models, including activity and state diagrams, illustrate a system's dynamic response to events or data. Model-driven engineering aims to generate implementation from system models.
This document provides an introduction and overview of key topics in software engineering. It discusses what software engineering is, the importance and costs of software development, different types of software projects and applications, and issues like complexity, security and scale that affect software. It also introduces software engineering processes, methods, and ethics. Common questions about the field are addressed. The document is the first chapter of a book on software engineering.
This chapter discusses system modeling and different types of models used, including:
- Context models which illustrate the operational context of a system.
- Interaction models which model interactions between a system and its environment.
- Structural models which display the organization of a system's components.
- Behavioral models which model a system's dynamic behavior in response to events or data.
- Model-driven engineering is discussed as an approach where models rather than code are the primary outputs.
The document discusses project planning, including topics like software pricing, plan-driven development, project scheduling, and agile planning. It covers the different stages of planning, from initial proposals to ongoing development. Project planning involves breaking work into parts, anticipating problems, and communicating the plan. Regular updates allow the plan to reflect new information and changes throughout the project.
Software evolution involves making ongoing changes to software systems to address new requirements, fix errors, and improve performance. There are several approaches to managing software evolution, including maintenance, reengineering, refactoring, and legacy system management. Key considerations for legacy systems include assessing their business value and quality to determine whether they should be replaced, transformed, or maintained.
This document discusses system modeling and different types of models used in system modeling. It covers context models, interaction models, structural models, behavioral models, and model-driven engineering. Some key points include:
- System modeling involves developing abstract models of a system from different perspectives or views. Models are often developed using the Unified Modeling Language (UML).
- Common model types include use case diagrams, sequence diagrams, class diagrams, state diagrams, and activity diagrams.
- Structural models show the organization and structure of a system. Behavioral models show the system's dynamic behavior and responses to events.
- Model-driven engineering is an approach where models rather than code are the primary outputs and code is generated
This chapter discusses distributed software engineering and distributed systems. It covers topics like distributed system characteristics including resource sharing, openness, concurrency, scalability and fault tolerance. Some key issues with distributed systems are their complexity, lack of single control, and independence of parts. The chapter addresses design issues for distributed systems such as transparency, openness, scalability, security, quality of service, and failure management. It also covers models of interaction, middleware, and client-server computing.
The document discusses several topics related to software project management including risk management, managing people, and teamwork. It describes the key activities of a project manager including planning, risk assessment, people management, reporting, and proposal writing. Specific risks at the project, product, and business levels are defined and strategies for risk identification, analysis, planning, monitoring, and mitigation are outlined. Effective people management is also emphasized, including motivating team members through satisfying different human needs and personality types. A case study demonstrates how addressing an individual team member's motivation issues can improve project outcomes.
Architectural design involves identifying major system components and their communications. Architectural views provide different perspectives of the system, such as conceptual, logical, process, and development views. Common architectural patterns include model-view-controller, layered, client-server, and pipe-and-filter architectures. Application architectures define common structures for transaction processing, information, and language processing systems.
Ian Sommerville, Software Engineering, 9th Edition Ch1Mohammed Romi
The document provides an introduction to software engineering concepts. It discusses what software engineering is, the importance of ethics in software development, and introduces three case studies that will be used as examples throughout the book. Specifically:
[1] It defines software engineering as an engineering discipline concerned with all aspects of software production. Professional and ethical practices are important.
[2] It discusses software engineering ethics and introduces the ACM/IEEE code of ethics for software engineers.
[3] It provides an overview of three case studies that will be referenced in later chapters: an insulin pump system, a patient management system, and a weather station system.
The document discusses various types of software testing:
- Development testing includes unit, component, and system testing to discover defects.
- Release testing is done by a separate team to validate the software meets requirements before release.
- User testing involves potential users testing the system in their own environment.
The goals of testing are validation, to ensure requirements are met, and defect testing to discover faults. Automated unit testing and test-driven development help improve test coverage and regression testing.
The document discusses reliability engineering and fault tolerance. It covers topics like availability, reliability requirements, fault-tolerant architectures, and reliability measurement. It defines key terms like faults, errors, and failures. It also describes techniques for achieving reliability like fault avoidance, fault detection, and fault tolerance. Specific architectures discussed include redundant systems and protection systems that can take emergency action if failures occur.
Ian Sommerville, Software Engineering, 9th EditionCh 8Mohammed Romi
The document discusses different types of software testing including unit testing, component testing, and system testing. Unit testing involves testing individual program components in isolation through techniques like partition testing and guideline-based testing. Component testing focuses on testing interactions between components through their interfaces. System testing integrates components to test their interactions and check for emergent behaviors that are not explicitly defined. The document also covers test-driven development, which involves writing tests before code in incremental cycles.
The document discusses architectural design, including:
- Architectural design determines how a software system is organized and structured. It identifies the main components and relationships.
- Architectural views show different perspectives of a system, such as logical, process, development, and physical views. Common patterns like model-view-controller and layered architectures are also covered.
- Architectural decisions impact system characteristics like performance, security, and maintainability. Common application architectures are also discussed.
The document discusses requirements engineering for software systems. It covers topics like functional and non-functional requirements, the requirements engineering process, elicitation, specification, validation, and change. It defines what requirements are, their different types and levels of abstraction. It also discusses stakeholders, and provides examples of functional and non-functional requirements for a healthcare management system called Mentcare.
This document discusses service-oriented software engineering and RESTful web services. It covers topics like service-oriented architectures, RESTful services, service engineering, and service composition. Key points include that services are reusable components that are loosely coupled and platform independent. Service-oriented approaches allow for opportunistic construction of new services and pay-per-use models. Web services standards like SOAP, WSDL, and WS-BPEL are also discussed. The document provides an example of a service-oriented in-car information system.
This document discusses safety engineering for systems that contain software. It covers topics like safety-critical systems, safety requirements, and safety engineering processes. Safety is defined as a system's ability to operate normally and abnormally without harm. For safety-critical systems like aircraft or medical devices, software is often used for control and monitoring, so software safety is important. Hazard identification, risk assessment, and specifying safety requirements to mitigate risks are key parts of the safety engineering process. The goal is to design systems where failures cannot cause injury, death or environmental damage.
The document summarizes topics related to real-time software engineering including embedded system design, architectural patterns for real-time software, timing analysis, and real-time operating systems. It discusses key characteristics of embedded systems like responsiveness, the need to respond to stimuli within specified time constraints, and how real-time systems are often modeled as cooperating processes controlled by a real-time executive. The document also outlines common architectural patterns for real-time systems including observe and react, environmental control, and process pipeline.
This document provides an overview of topics in chapter 13 on security engineering. It discusses security and dependability, security dimensions of confidentiality, integrity and availability. It also outlines different security levels including infrastructure, application and operational security. Key aspects of security engineering are discussed such as secure system design, security testing and assurance. Security terminology and examples are provided. The relationship between security and dependability factors like reliability, availability, safety and resilience is examined. The document also covers security in organizations and the role of security policies.
This document summarizes key concepts from Chapter 15 on resilience engineering. It discusses resilience as the ability of systems to maintain critical services during disruptions like failures or cyberattacks. Resilience involves recognizing issues, resisting failures when possible, and recovering quickly through activities like redundancy. The document also covers sociotechnical resilience, where human and organizational factors are considered, and characteristics of resilient organizations like responsiveness, monitoring, anticipation, and learning.
This document discusses systems of systems and complexity. It begins by defining systems of systems and providing examples. Key characteristics of systems of systems include operational and managerial independence of elements, and evolutionary development. The document then covers sources of complexity, including technical, managerial and governance complexity. It discusses how reductionism has traditionally been used to manage complexity in engineering but has limitations for large systems of systems.
This document discusses software processes and models. It covers the following key points:
1. Software processes involve activities like specification, design, implementation, validation and evolution to develop software systems. Common process models include waterfall, incremental development and reuse-oriented development.
2. Processes need to cope with inevitable changes. This can involve prototyping to avoid rework or using incremental development and delivery to more easily accommodate changes.
3. The Rational Unified Process is a modern process model with phases for inception, elaboration, construction and transition. It advocates iterative development and managing requirements and quality.
Chapter 25 – Configuration Management
Chapter 25 Configuration management
1
11/12/2014
Topics covered
Version management
System building
Change management
Release management
Chapter 25 Configuration management
2
11/12/2014
Configuration management
Software systems are constantly changing during development and use.
Configuration management (CM) is concerned with the policies, processes and tools for managing changing software systems.
You need CM because it is easy to lose track of what changes and component versions have been incorporated into each system version.
CM is essential for team projects to control changes made by different developers
Chapter 25 Configuration management
3
11/12/2014
CM activities
Version management
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.
System building
The process of assembling program components, data and libraries, then compiling these to create an executable system.
Change management
Keeping track of requests for changes to the software from customers and developers, working out the costs and impact of changes, and deciding the changes should be implemented.
Release management
Preparing software for external release and keeping track of the system versions that have been released for customer use.
Chapter 25 Configuration management
4
11/12/2014
Configuration management activities
Chapter 25 Configuration management
5
11/12/2014
Agile development and CM
Agile development, where components and systems are changed several times per day, is impossible without using CM tools.
The definitive versions of components are held in a shared project repository and developers copy these into their own workspace.
They make changes to the code then use system building tools to create a new system on their own computer for testing. Once they are happy with the changes made, they return the modified components to the project repository.
11/12/2014
Chapter 25 Configuration management
6
Development phases
A development phase where the development team is responsible for managing the software configuration and new functionality is being added to the software.
A system testing phase where a version of the system is released internally for testing.
No new system functionality is added. Changes made are bug fixes, performance improvements and security vulnerability repairs.
A release phase where the software is released to customers for use.
New versions of the released system are developed to repair bugs and vulnerabilities and to include new features.
11/12/2014
Chapter 25 Configuration management
7
Multi-version systems
For large systems, there is never just one ‘working’ version of a system.
There are always several versions of the system at different stages of development.
There may be several teams involved in the development of different system versions.
11/12/2014
Chap ...
The document summarizes key aspects of configuration management discussed in Chapter 25, including change management, version management, system building, and release management. Version management involves tracking different versions of software components to prevent interference between changes made by different developers. System building is the process of compiling and linking components to create an executable system. Release management prepares software for external distribution and tracks released system versions.
Configuration management involves change management, version management, system building, and release management. It ensures changes to software systems are managed and tracked. Version management tracks different versions of components to prevent interference. System building compiles components into executable systems. Release management prepares software for distribution and tracks released versions.
BSG SE4201 Software Configuration Management and Maintenance Lesson 1 Novembe...ZaharaddeenAbubuakar
This document provides an introduction to a course on software configuration management and maintenance. It outlines the topics that will be covered in the course, including why configuration management is important, what the key activities are, and some terminology. The course will examine how to manage changing software systems and evolving versions using configuration management tools and practices. It will also explore concepts like version control, multi-version systems, baselines, and maintaining different versions for development, testing, and release.
SE2018_Lec 21_ Software Configuration Management (SCM)Amr E. Mohamed
Configuration management is a software engineering discipline that involves identifying and managing the configuration of software assets such as code, documents, and other project artifacts. It aims to control modifications to software and maintain integrity and traceability throughout the development and maintenance lifecycles. Key aspects of configuration management include configuration identification, change control, configuration management planning, builds, and tools.
Software configuration management (SCM) is necessary to manage evolving software systems and coordinate changes. A SCM plan defines configuration items, responsibilities, and policies for promotions and releases. It also identifies activities, schedules, and tools. Following a standard like IEEE 828 helps ensure all necessary elements are addressed. Tailoring the standard to the project allows balancing bureaucracy with success.
SE2_Lec 22_Software Configuration ManagementAmr E. Mohamed
The document discusses software configuration management. It defines key terms like configuration item, version, revision, and baseline. It describes the main functions of configuration management as configuration identification, configuration control, configuration audits, and configuration status accounting. Configuration management is used to identify and track changes to software components, control access to components, and help integrate product parts.
Software Configuration Management And CVSRajesh Kumar
The document discusses software configuration management (SCM) and the Concurrent Versions System (CVS) tool. It provides an overview of SCM processes and activities, including configuration control, change management, and versioning. It also summarizes how CVS can be used to check files in and out of a central repository and record changes over time.
Software configuration management (SCM) is the process of managing changes to software code throughout the development lifecycle. SCM tools provide version control, tracking of code changes, and facilitate collaboration between developers. Key SCM concepts include configuration items, change requests, versions, promotions, and releases. SCM activities involve configuration identification, control of changes, tracking configuration status, auditing, and management of the development environment and process. Common SCM tools include SVN, CVS, Perforce, Clearcase, and TFS.
The document discusses software process models. It describes the waterfall model, which involves requirements analysis, design, implementation, testing, and maintenance phases completed sequentially. However, the waterfall model is inflexible and doesn't adapt well to changing requirements. The document then introduces incremental development as an alternative, delivering the system in prioritized increments to allow for adapting to changes more easily.
The document discusses software processes and provides an overview of key concepts:
1) It describes different software process models including waterfall, incremental development, and reuse-oriented processes.
2) It covers important process activities like requirements specification, design/implementation, validation, and evolution.
3) It discusses approaches for coping with changing requirements like prototyping and incremental delivery.
The Rational Unified Process (RUP) is presented as a modern generic software process that incorporates elements of other process models.
The document discusses software configuration management. It defines configuration management as activities that manage changes throughout the software life cycle. The key goals are to systematically control changes to the configuration and maintain integrity and traceability. Important concepts discussed include software configuration items, baselines, version control, change control processes, and content management for web applications. Secure coding practices are also summarized to develop software that is protected against security vulnerabilities.
The document discusses software configuration management. It defines configuration management as activities that manage change throughout the software life cycle. The key goals are to systematically control changes to the configuration and maintain integrity and traceability. Important concepts discussed include software configuration items, baselines, version control, change control processes, auditing and the configuration management repository.
The document describes different software development processes and models. It discusses the waterfall model, incremental development, reuse-oriented development, and the spiral model. The waterfall model involves sequential phases from requirements to maintenance. Incremental development interleaves specification, development and validation. Reuse focuses on assembling systems from existing components. The spiral model is iterative with risk assessment at each loop. The Rational Unified Process combines elements of these models into phases of inception, elaboration, construction and transition.
The document discusses software processes and process models. It covers key topics like the waterfall model, incremental development, and reuse-oriented processes. The main activities involved in any software process are specification, design and implementation, validation, and evolution. Specification defines what the system should do, design implements the system structure, validation checks it meets requirements, and evolution handles changing needs. Process models organize these activities differently, like sequentially in waterfall or interleaved in incremental development.
Version control systems track changes to files over time. They allow developers to work simultaneously and integrate their work. Changes are recorded to a central repository, allowing developers to view historical versions and undo mistakes. Popular version control systems include Git and Subversion. Git is a distributed version control system where each developer has their own repository, unlike centralized systems with a single shared repository.
Configuration management is concerned with managing changing software systems. It involves tracking changes, versions, system builds, and releases. Effective configuration management uses tools and processes to ensure the right versions are modified and delivered and software components are properly stored and tracked. It is important for quality and involves activities like change management, version management, system building, and release management.
The document discusses software configuration management (SCM), which is the process of managing changes to software during development and maintenance. It defines SCM and describes common features of SCM tools, such as controlling file types, managing changes, and tracking releases. The document also covers important SCM concepts like configuration items, change requests, versions, and repositories. It discusses SCM roles and activities in the software development lifecycle.
This document provides an introduction to CI/CD concepts and tools. It defines continuous integration as automatically building and testing code changes. Continuous delivery automates deploying changes but may involve manual approval. Continuous deployment fully automates all stages. Benefits include faster releases and issue detection. Popular tools like Jenkins can automate building pipelines. Version control systems like Git track changes and enable collaboration. CI/CD aims to streamline software delivery through automation and collaboration across teams.
- Traditionally, separate teams handled software development, release, and support, which caused delays. The DevOps approach combines these roles into a single multi-skilled team.
- Three factors drove DevOps adoption: Agile reduced development time but introduced bottlenecks; Amazon improved reliability with single teams; software could be released as a service.
- DevOps benefits include faster deployment, reduced risk, and faster repair through collaboration between development and operations teams.
Covers security and privacy issues for software product developers including attacks and defenses, encryption, authentication, authorisation and data protection
Discusses the microservices architectural style for cloud-based systems. Explains what is meant by microservices and architectural choices for microservices
Introduces some fundamentals of cloud based software and discusses architectural issues for product developers. Covers containers, databases and cloud architecture choices
The document discusses software products and product engineering. It defines software products as generic systems that provide functionality to a range of customers, from business systems to personal apps. Product engineering methods have evolved from custom software engineering techniques. The key aspects of product development are that there is no external customer generating requirements, and rapid delivery is important to capture the market. Product managers are responsible for planning, development, and marketing software products throughout their lifecycle.
TrustArc Webinar - Your Guide for Smooth Cross-Border Data Transfers and Glob...TrustArc
Global data transfers can be tricky due to different regulations and individual protections in each country. Sharing data with vendors has become such a normal part of business operations that some may not even realize they’re conducting a cross-border data transfer!
The Global CBPR Forum launched the new Global Cross-Border Privacy Rules framework in May 2024 to ensure that privacy compliance and regulatory differences across participating jurisdictions do not block a business's ability to deliver its products and services worldwide.
To benefit consumers and businesses, Global CBPRs promote trust and accountability while moving toward a future where consumer privacy is honored and data can be transferred responsibly across borders.
This webinar will review:
- What is a data transfer and its related risks
- How to manage and mitigate your data transfer risks
- How do different data transfer mechanisms like the EU-US DPF and Global CBPR benefit your business globally
- Globally what are the cross-border data transfer regulations and guidelines
An All-Around Benchmark of the DBaaS MarketScyllaDB
The entire database market is moving towards Database-as-a-Service (DBaaS), resulting in a heterogeneous DBaaS landscape shaped by database vendors, cloud providers, and DBaaS brokers. This DBaaS landscape is rapidly evolving and the DBaaS products differ in their features but also their price and performance capabilities. In consequence, selecting the optimal DBaaS provider for the customer needs becomes a challenge, especially for performance-critical applications.
To enable an on-demand comparison of the DBaaS landscape we present the benchANT DBaaS Navigator, an open DBaaS comparison platform for management and deployment features, costs, and performance. The DBaaS Navigator is an open data platform that enables the comparison of over 20 DBaaS providers for the relational and NoSQL databases.
This talk will provide a brief overview of the benchmarked categories with a focus on the technical categories such as price/performance for NoSQL DBaaS and how ScyllaDB Cloud is performing.
MySQL InnoDB Storage Engine: Deep Dive - MydbopsMydbops
This presentation, titled "MySQL - InnoDB" and delivered by Mayank Prasad at the Mydbops Open Source Database Meetup 16 on June 8th, 2024, covers dynamic configuration of REDO logs and instant ADD/DROP columns in InnoDB.
This presentation dives deep into the world of InnoDB, exploring two ground-breaking features introduced in MySQL 8.0:
• Dynamic Configuration of REDO Logs: Enhance your database's performance and flexibility with on-the-fly adjustments to REDO log capacity. Unleash the power of the snake metaphor to visualize how InnoDB manages REDO log files.
• Instant ADD/DROP Columns: Say goodbye to costly table rebuilds! This presentation unveils how InnoDB now enables seamless addition and removal of columns without compromising data integrity or incurring downtime.
Key Learnings:
• Grasp the concept of REDO logs and their significance in InnoDB's transaction management.
• Discover the advantages of dynamic REDO log configuration and how to leverage it for optimal performance.
• Understand the inner workings of instant ADD/DROP columns and their impact on database operations.
• Gain valuable insights into the row versioning mechanism that empowers instant column modifications.
This time, we're diving into the murky waters of the Fuxnet malware, a brainchild of the illustrious Blackjack hacking group.
Let's set the scene: Moscow, a city unsuspectingly going about its business, unaware that it's about to be the star of Blackjack's latest production. The method? Oh, nothing too fancy, just the classic "let's potentially disable sensor-gateways" move.
In a move of unparalleled transparency, Blackjack decides to broadcast their cyber conquests on ruexfil.com. Because nothing screams "covert operation" like a public display of your hacking prowess, complete with screenshots for the visually inclined.
Ah, but here's where the plot thickens: the initial claim of 2,659 sensor-gateways laid to waste? A slight exaggeration, it seems. The actual tally? A little over 500. It's akin to declaring world domination and then barely managing to annex your backyard.
For Blackjack, ever the dramatists, hint at a sequel, suggesting the JSON files were merely a teaser of the chaos yet to come. Because what's a cyberattack without a hint of sequel bait, teasing audiences with the promise of more digital destruction?
-------
This document presents a comprehensive analysis of the Fuxnet malware, attributed to the Blackjack hacking group, which has reportedly targeted infrastructure. The analysis delves into various aspects of the malware, including its technical specifications, impact on systems, defense mechanisms, propagation methods, targets, and the motivations behind its deployment. By examining these facets, the document aims to provide a detailed overview of Fuxnet's capabilities and its implications for cybersecurity.
The document offers a qualitative summary of the Fuxnet malware, based on the information publicly shared by the attackers and analyzed by cybersecurity experts. This analysis is invaluable for security professionals, IT specialists, and stakeholders in various industries, as it not only sheds light on the technical intricacies of a sophisticated cyber threat but also emphasizes the importance of robust cybersecurity measures in safeguarding critical infrastructure against emerging threats. Through this detailed examination, the document contributes to the broader understanding of cyber warfare tactics and enhances the preparedness of organizations to defend against similar attacks in the future.
DynamoDB to ScyllaDB: Technical Comparison and the Path to SuccessScyllaDB
What can you expect when migrating from DynamoDB to ScyllaDB? This session provides a jumpstart based on what we’ve learned from working with your peers across hundreds of use cases. Discover how ScyllaDB’s architecture, capabilities, and performance compares to DynamoDB’s. Then, hear about your DynamoDB to ScyllaDB migration options and practical strategies for success, including our top do’s and don’ts.
QA or the Highway - Component Testing: Bridging the gap between frontend appl...zjhamm304
These are the slides for the presentation, "Component Testing: Bridging the gap between frontend applications" that was presented at QA or the Highway 2024 in Columbus, OH by Zachary Hamm.
An Introduction to All Data Enterprise IntegrationSafe Software
Are you spending more time wrestling with your data than actually using it? You’re not alone. For many organizations, managing data from various sources can feel like an uphill battle. But what if you could turn that around and make your data work for you effortlessly? That’s where FME comes in.
We’ve designed FME to tackle these exact issues, transforming your data chaos into a streamlined, efficient process. Join us for an introduction to All Data Enterprise Integration and discover how FME can be your game-changer.
During this webinar, you’ll learn:
- Why Data Integration Matters: How FME can streamline your data process.
- The Role of Spatial Data: Why spatial data is crucial for your organization.
- Connecting & Viewing Data: See how FME connects to your data sources, with a flash demo to showcase.
- Transforming Your Data: Find out how FME can transform your data to fit your needs. We’ll bring this process to life with a demo leveraging both geometry and attribute validation.
- Automating Your Workflows: Learn how FME can save you time and money with automation.
Don’t miss this chance to learn how FME can bring your data integration strategy to life, making your workflows more efficient and saving you valuable time and resources. Join us and take the first step toward a more integrated, efficient, data-driven future!
Enterprise Knowledge’s Joe Hilger, COO, and Sara Nash, Principal Consultant, presented “Building a Semantic Layer of your Data Platform” at Data Summit Workshop on May 7th, 2024 in Boston, Massachusetts.
This presentation delved into the importance of the semantic layer and detailed four real-world applications. Hilger and Nash explored how a robust semantic layer architecture optimizes user journeys across diverse organizational needs, including data consistency and usability, search and discovery, reporting and insights, and data modernization. Practical use cases explore a variety of industries such as biotechnology, financial services, and global retail.
Guidelines for Effective Data VisualizationUmmeSalmaM1
This PPT discuss about importance and need of data visualization, and its scope. Also sharing strong tips related to data visualization that helps to communicate the visual information effectively.
Conversational agents, or chatbots, are increasingly used to access all sorts of services using natural language. While open-domain chatbots - like ChatGPT - can converse on any topic, task-oriented chatbots - the focus of this paper - are designed for specific tasks, like booking a flight, obtaining customer support, or setting an appointment. Like any other software, task-oriented chatbots need to be properly tested, usually by defining and executing test scenarios (i.e., sequences of user-chatbot interactions). However, there is currently a lack of methods to quantify the completeness and strength of such test scenarios, which can lead to low-quality tests, and hence to buggy chatbots.
To fill this gap, we propose adapting mutation testing (MuT) for task-oriented chatbots. To this end, we introduce a set of mutation operators that emulate faults in chatbot designs, an architecture that enables MuT on chatbots built using heterogeneous technologies, and a practical realisation as an Eclipse plugin. Moreover, we evaluate the applicability, effectiveness and efficiency of our approach on open-source chatbots, with promising results.
Introducing BoxLang : A new JVM language for productivity and modularity!Ortus Solutions, Corp
Just like life, our code must adapt to the ever changing world we live in. From one day coding for the web, to the next for our tablets or APIs or for running serverless applications. Multi-runtime development is the future of coding, the future is to be dynamic. Let us introduce you to BoxLang.
Dynamic. Modular. Productive.
BoxLang redefines development with its dynamic nature, empowering developers to craft expressive and functional code effortlessly. Its modular architecture prioritizes flexibility, allowing for seamless integration into existing ecosystems.
Interoperability at its Core
With 100% interoperability with Java, BoxLang seamlessly bridges the gap between traditional and modern development paradigms, unlocking new possibilities for innovation and collaboration.
Multi-Runtime
From the tiny 2m operating system binary to running on our pure Java web server, CommandBox, Jakarta EE, AWS Lambda, Microsoft Functions, Web Assembly, Android and more. BoxLang has been designed to enhance and adapt according to it's runnable runtime.
The Fusion of Modernity and Tradition
Experience the fusion of modern features inspired by CFML, Node, Ruby, Kotlin, Java, and Clojure, combined with the familiarity of Java bytecode compilation, making BoxLang a language of choice for forward-thinking developers.
Empowering Transition with Transpiler Support
Transitioning from CFML to BoxLang is seamless with our JIT transpiler, facilitating smooth migration and preserving existing code investments.
Unlocking Creativity with IDE Tools
Unleash your creativity with powerful IDE tools tailored for BoxLang, providing an intuitive development experience and streamlining your workflow. Join us as we embark on a journey to redefine JVM development. Welcome to the era of BoxLang.
Radically Outperforming DynamoDB @ Digital Turbine with SADA and Google CloudScyllaDB
Digital Turbine, the Leading Mobile Growth & Monetization Platform, did the analysis and made the leap from DynamoDB to ScyllaDB Cloud on GCP. Suffice it to say, they stuck the landing. We'll introduce Joseph Shorter, VP, Platform Architecture at DT, who lead the charge for change and can speak first-hand to the performance, reliability, and cost benefits of this move. Miles Ward, CTO @ SADA will help explore what this move looks like behind the scenes, in the Scylla Cloud SaaS platform. We'll walk you through before and after, and what it took to get there (easier than you'd guess I bet!).
QR Secure: A Hybrid Approach Using Machine Learning and Security Validation F...AlexanderRichford
QR Secure: A Hybrid Approach Using Machine Learning and Security Validation Functions to Prevent Interaction with Malicious QR Codes.
Aim of the Study: The goal of this research was to develop a robust hybrid approach for identifying malicious and insecure URLs derived from QR codes, ensuring safe interactions.
This is achieved through:
Machine Learning Model: Predicts the likelihood of a URL being malicious.
Security Validation Functions: Ensures the derived URL has a valid certificate and proper URL format.
This innovative blend of technology aims to enhance cybersecurity measures and protect users from potential threats hidden within QR codes 🖥 🔒
This study was my first introduction to using ML which has shown me the immense potential of ML in creating more secure digital environments!
In our second session, we shall learn all about the main features and fundamentals of UiPath Studio that enable us to use the building blocks for any automation project.
📕 Detailed agenda:
Variables and Datatypes
Workflow Layouts
Arguments
Control Flows and Loops
Conditional Statements
💻 Extra training through UiPath Academy:
Variables, Constants, and Arguments in Studio
Control Flow in Studio
So You've Lost Quorum: Lessons From Accidental DowntimeScyllaDB
The best thing about databases is that they always work as intended, and never suffer any downtime. You'll never see a system go offline because of a database outage. In this talk, Bo Ingram -- staff engineer at Discord and author of ScyllaDB in Action --- dives into an outage with one of their ScyllaDB clusters, showing how a stressed ScyllaDB cluster looks and behaves during an incident. You'll learn about how to diagnose issues in your clusters, see how external failure modes manifest in ScyllaDB, and how you can avoid making a fault too big to tolerate.
The Department of Veteran Affairs (VA) invited Taylor Paschal, Knowledge & Information Management Consultant at Enterprise Knowledge, to speak at a Knowledge Management Lunch and Learn hosted on June 12, 2024. All Office of Administration staff were invited to attend and received professional development credit for participating in the voluntary event.
The objectives of the Lunch and Learn presentation were to:
- Review what KM ‘is’ and ‘isn’t’
- Understand the value of KM and the benefits of engaging
- Define and reflect on your “what’s in it for me?”
- Share actionable ways you can participate in Knowledge - - Capture & Transfer
2. Topics covered
Version management
System building
Change management
Release management
Chapter 25 Configuration management 211/12/2014
3. Configuration management
Software systems are constantly changing during
development and use.
Configuration management (CM) is concerned with the
policies, processes and tools for managing changing
software systems.
You need CM because it is easy to lose track of what
changes and component versions have been
incorporated into each system version.
CM is essential for team projects to control changes
made by different developers
Chapter 25 Configuration management 311/12/2014
4. CM activities
Version management
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.
System building
The process of assembling program components, data and libraries,
then compiling these to create an executable system.
Change management
Keeping track of requests for changes to the software from customers
and developers, working out the costs and impact of changes, and
deciding the changes should be implemented.
Release management
Preparing software for external release and keeping track of the system
versions that have been released for customer use.
Chapter 25 Configuration management 411/12/2014
6. Agile development and CM
Agile development, where components and systems are
changed several times per day, is impossible without
using CM tools.
The definitive versions of components are held in a
shared project repository and developers copy these into
their own workspace.
They make changes to the code then use system
building tools to create a new system on their own
computer for testing. Once they are happy with the
changes made, they return the modified components to
the project repository.
11/12/2014 Chapter 25 Configuration management 6
7. Development phases
A development phase where the development team is
responsible for managing the software configuration and
new functionality is being added to the software.
A system testing phase where a version of the system is
released internally for testing.
No new system functionality is added. Changes made are bug
fixes, performance improvements and security vulnerability
repairs.
A release phase where the software is released to
customers for use.
New versions of the released system are developed to repair
bugs and vulnerabilities and to include new features.
11/12/2014 Chapter 25 Configuration management 7
8. Multi-version systems
For large systems, there is never just one ‘working’
version of a system.
There are always several versions of the system at
different stages of development.
There may be several teams involved in the
development of different system versions.
11/12/2014 Chapter 25 Configuration management 8
10. CM terminology
Term Explanation
Baseline A baseline is a collection of component versions that make up a system.
Baselines are controlled, which means that the versions of the
components making up the system cannot be changed. This means that
it is always possible to recreate a baseline from its constituent
components.
Branching The creation of a new codeline from a version in an existing codeline.
The new codeline and the existing codeline may then develop
independently.
Codeline A codeline is a set of versions of a software component and other
configuration items on which that component depends.
Configuration
(version) control
The process of ensuring that versions of systems and components are
recorded and maintained so that changes are managed and all versions
of components are identified and stored for the lifetime of the system.
Configuration item or
software configuration
item (SCI)
Anything associated with a software project (design, code, test data,
document, etc.) that has been placed under configuration control. There
are often different versions of a configuration item. Configuration items
have a unique name.
Mainline A sequence of baselines representing different versions of a system.
Chapter 25 Configuration management 1011/12/2014
11. CM terminology
Term Explanation
Merging The creation of a new version of a software component by merging
separate versions in different codelines. These codelines may have
been created by a previous branch of one of the codelines involved.
Release A version of a system that has been released to customers (or other
users in an organization) for use.
Repository A shared database of versions of software components and meta-
information about changes to these components.
System building The creation of an executable system version by compiling and linking
the appropriate versions of the components and libraries making up the
system.
Version An instance of a configuration item that differs, in some way, from other
instances of that item. Versions always have a unique identifier.
Workspace A private work area where software can be modified without affecting
other developers who may be using or modifying that software.
Chapter 25 Configuration management 1111/12/2014
13. Version management
Version management (VM) is the process of keeping
track of different versions of software components or
configuration items and the systems in which these
components are used.
It also involves ensuring that changes made by different
developers to these versions do not interfere with each
other.
Therefore version management can be thought of as the
process of managing codelines and baselines.
Chapter 25 Configuration management 1311/12/2014
14. 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.
The baseline therefore specifies the component versions
that are included in the system plus a specification of the
libraries used, configuration files, etc.
Chapter 25 Configuration management 1411/12/2014
15. Baselines
Baselines may be specified using a configuration
language, which allows you to define what components
are included in a version of a particular system.
Baselines are important because you often have to
recreate a specific version of a complete 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.
Chapter 25 Configuration management 1511/12/2014
17. Version control systems
Version control (VC) systems identify, store and control
access to the different versions of components. There
are two types of modern version control system
Centralized systems, where there is a single master repository
that maintains all versions of the software components that are
being developed. Subversion is a widely used example of a
centralized VC system.
Distributed systems, where multiple versions of the component
repository exist at the same time. Git is a widely-used example of
a distributed VC system.
11/12/2014 Chapter 25 Configuration management 17
18. Key features of version control systems
Version and release identification
Change history recording
Support for independent development
Project support
Storage management
11/12/2014 Chapter 25 Configuration management 18
19. Public repository and private workspaces
To support independent development without
interference, 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 modifying components, developers copy (check-
out) these from the repository into their workspace and
work on these copies.
When they have finished their changes, the changed
components are returned (checked-in) to the repository.
11/12/2014 Chapter 25 Configuration management 19
20. Centralized version control
Developers check out components or directories of
components from the project repository into their private
workspace and work on these copies in their private
workspace.
When their changes are complete, they check-in the
components back to the repository.
If several people are working on a component at the
same time, each check it out from the repository. If a
component has been checked out, the VC system warns
other users wanting to check out that component that it
has been checked out by someone else.
11/12/2014 Chapter 25 Configuration management 20
22. Distributed version control
A ‘master’ repository is created on a server that
maintains the code produced by the development team.
Instead of checking out the files that they need, a
developer creates a clone of the project repository that is
downloaded and installed on their computer.
Developers work on the files required and maintain the
new versions on their private repository on their own
computer.
When changes are done, they ‘commit’ these changes
and update their private server repository. They may
then ‘push’ these changes to the project repository.
11/12/2014 Chapter 25 Configuration management 22
24. Benefits of distributed version control
It provides a backup mechanism for the repository.
If the repository is corrupted, work can continue and the project
repository can be restored from local copies.
It allows for off-line working so that developers can
commit changes if they do not have a network
connection.
Project support is the default way of working.
Developers can compile and test the entire system on their local
machines and test the changes that they have made.
11/12/2014 Chapter 25 Configuration management 24
25. 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’ to decide
when to pull these changes into the definitive system.
11/12/2014 Chapter 25 Configuration management 25
27. Branching and merging
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 so change it in different ways.
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.
If the changes made involve different parts of the code, the
component versions may be merged automatically by combining
the deltas that apply to the code.
Chapter 25 Configuration management 2711/12/2014
29. Storage management
When version control systems were first developed,
storage management was one of their most important
functions.
Disk space was expensive and it was important to
minimize the disk space used by the different copies of
components.
Instead of keeping a complete copy of each version, the
system stores a list of differences (deltas) between one
version and another.
By applying these to a master version (usually the most recent
version), a target version can be recreated.
11/12/2014 Chapter 25 Configuration management 29
31. Storage management in Git
As disk storage is now relatively cheap, Git uses an
alternative, faster approach.
Git does not use deltas but applies a standard
compression algorithm to stored files and their
associated meta-information.
It does not store duplicate copies of files. Retrieving a
file simply involves decompressing it, with no need to
apply a chain of operations.
Git also uses the notion of packfiles where several
smaller files are combined into an indexed single file.
11/12/2014 Chapter 25 Configuration management 31
33. 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.
Chapter 25 Configuration management 3311/12/2014
34. 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, which is 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.
Chapter 25 Configuration management 3411/12/2014
36. Build system functionality
Build script generation
Version management system integration
Minimal re-compilation
Executable system creation
Test automation
Reporting
Documentation generation
Chapter 25 Configuration management 3611/12/2014
37. System platforms
The development system, which includes development
tools such as compilers, source code editors, etc.
The build server, which is used to build definitive,
executable versions of the system. This server maintains
the definitive versions of a 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)
11/12/2014 Chapter 25 Configuration management 37
39. Agile building
Check out the mainline system from the version
management system into the developer’s private
workspace.
Build the system and run automated tests to ensure that
the built system passes all tests. If not, the build is
broken and you should inform whoever checked in the
last baseline system. They are responsible for repairing
the problem.
Make the changes to the system components.
Build the system in the private workspace and rerun
system tests. If the tests fail, continue editing.
Chapter 25 Configuration management 3911/12/2014
40. Agile building
Once the system has passed its tests, check it into the
build system but do not commit it as a new system
baseline.
Build the system on the build server and run the tests.
You need to do this in case others have modified
components since you checked out the system. If this is
the case, check out the components that have failed and
edit these so that tests pass on your private workspace.
If the system passes its tests on the build system, then
commit the changes you have made as a new baseline
in the system mainline.
Chapter 25 Configuration management 4011/12/2014
42. Pros and cons of continuous integration
Pros
The advantage of continuous integration is that it allows
problems caused by the interactions between different
developers to be discovered and repaired as soon as possible.
The most recent system in the mainline is the definitive working
system.
Cons
If the system is very large, it may take a long time to build and
test, especially if integration with other application systems is
involved.
If the development platform is different from the target platform, it
may not be possible to run system tests in the developer’s
private workspace.
11/12/2014 Chapter 25 Configuration management 42
43. Daily building
The development organization sets a delivery time (say
2 p.m.) for system components.
If developers have new versions of the components that they are
writing, they must deliver them by that time.
A new version of the system is built from these components by
compiling and linking them to form a complete system.
This system is then delivered to the testing team, which carries
out a set of predefined system tests
Faults that are discovered during system testing are documented
and returned to the system developers. They repair these faults
in a subsequent version of the component.
Chapter 25 Configuration management 4311/12/2014
44. Minimizing recompilation
Tools to support system building are usually designed to
minimize the amount of compilation that is required.
They do this by checking if a compiled version of a
component is available. If so, there is no need to
recompile that component.
A unique signature identifies each source and object
code version and is changed when the source code is
edited.
By comparing the signatures on the source and object
code files, it is possible to decide if the source code was
used to generate the object code component.
Chapter 25 Configuration management 4411/12/2014
45. File identification
Modification timestamps
The signature on the source code file is the time and date when
that file was modified. If the source code file of a component has
been modified after the related object code file, then the system
assumes that recompilation to create a new object code file is
necessary.
Source code checksums
The signature on the source code file is a checksum calculated
from data in the file. A checksum function calculates a unique
number using the source text as input. If you change the source
code (even by 1 character), this will generate a different
checksum. You can therefore be confident that source code files
with different checksums are actually different.
Chapter 25 Configuration management 4511/12/2014
46. Timestamps vs checksums
Timestamps
Because source and object files are linked by name rather than
an explicit source file signature, it is not usually possible to build
different versions of a source code component into the same
directory at the same time, as these would generate object files
with the same name.
Checksums
When you recompile a component, it does not overwrite the
object code, as would normally be the case when the timestamp
is used. Rather, it generates a new object code file and tags it
with the source code signature. Parallel compilation is possible
and different versions of a component may be compiled at the
same time.
Chapter 25 Configuration management 4611/12/2014
49. 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.
The change management process is concerned with
analyzing the costs and benefits of proposed changes,
approving those changes that are worthwhile and
tracking which components in the system have been
changed.
Chapter 25 Configuration management 4911/12/2014
51. A partially completed change request form (a)
Chapter 25 Configuration management 51
Change Request Form
Project: SICSA/AppProcessing Number: 23/02
Change requester: I. Sommerville Date: 20/07/12
Requested change: The status of applicants (rejected, accepted, etc.) should be
shown visually in the displayed list of applicants.
Change analyzer: R. Looek Analysis date: 25/07/12
Components affected: ApplicantListDisplay, StatusUpdater
Associated components: StudentDatabase
11/12/2014
52. A partially completed change request form (b)
Chapter 25 Configuration management 52
Change Request Form
Change assessment: Relatively simple to implement by changing the display
color according to status. A table must be added to relate status to colors. No
changes to associated components are required.
Change priority: Medium
Change implementation:
Estimated effort: 2 hours
Date to SGA app. team: 28/07/12 CCB decision date: 30/07/12
Decision: Accept change. Change to be implemented in Release 1.2
Change implementor: Date of change:
Date submitted to QA: QA decision:
Date submitted to CM:
Comments:
11/12/2014
53. Factors in change analysis
The consequences of not making the change
The benefits of the change
The number of users affected by the change
The costs of making the change
The product release cycle
Chapter 25 Configuration management 5311/12/2014
55. 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.
Chapter 25 Configuration management 5511/12/2014
57. Release management
A system release is a version of a software system that
is distributed to customers.
For mass market software, it is usually possible to
identify two types of release: major releases which
deliver significant new functionality, and minor releases,
which repair bugs and fix customer problems that have
been reported.
For custom software or software product lines, releases
of the system may have to be produced for each
customer and individual customers may be running
several different releases of the system at the same
time.
Chapter 25 Configuration management 5711/12/2014
58. Release components
As well as the the executable code of the system, a
release may also include:
configuration files defining how the release should be configured
for particular installations;
data files, such as files of error messages, that are needed for
successful system operation;
an installation program that is used to help install the system on
target hardware;
electronic and paper documentation describing the system;
packaging and associated publicity that have been designed for
that release.
Chapter 25 Configuration management 5811/12/2014
59. Factors influencing system release planning
Factor Description
Competition For mass-market software, a new system release may be
necessary because a competing product has introduced new
features and market share may be lost if these are not
provided to existing customers.
Marketing
requirements
The marketing department of an organization may have made
a commitment for releases to be available at a particular date.
Platform changes 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 of
the system
If serious system faults are reported which affect the way in
which many customers use the system, it may be necessary to
issue a fault repair release. Minor system faults may be
repaired by issuing patches (usually distributed over the
Internet) that can be applied to the current release of the
system.
Chapter 25 Configuration management 5911/12/2014
60. Release creation
The executable code of the programs and all associated data files
must be identified in the version control system.
Configuration descriptions may have to be written for different
hardware and operating systems.
Update instructions may have to be written for customers who need to
configure their own systems.
Scripts for the installation program may have to be written.
Web pages have to be created describing the release, with links to
system documentation.
When all information is available, an executable master image of the
software must be prepared and handed over for distribution to
customers or sales outlets.
11/12/2014 Chapter 25 Configuration management 60
61. Release tracking
In the event of a problem, it may be necessary to
reproduce exactly the software that has been delivered
to a particular customer.
When a system release is produced, it must be
documented to ensure that it can be re-created exactly in
the future.
This is particularly important for customized, long-lifetime
embedded systems, such as those that control complex
machines.
Customers may use a single release of these systems for many
years and may require specific changes to a particular software
system long after its original release date.
Chapter 25 Configuration management 6111/12/2014
62. Release reproduction
To document a release, you have to record the specific
versions of the source code components that were used
to create the executable code.
You must keep copies of the source code files,
corresponding executables and all data and
configuration files.
You should also record the versions of the operating
system, libraries, compilers and other tools used to build
the software.
Chapter 25 Configuration management 6211/12/2014
63. Release planning
As well as the technical work involved in creating a
release distribution, advertising and publicity material
have to be prepared and marketing strategies put in
place to convince customers to buy the new release of
the system.
Release timing
If releases are too frequent or require hardware upgrades,
customers may not move to the new release, especially if they
have to pay for it.
If system releases are too infrequent, market share may be lost
as customers move to alternative systems.
Chapter 25 Configuration management 6311/12/2014
64. Software as a service
Delivering software as a service (SaaS) reduces the
problems of release management.
It simplifies both release management and system
installation for customers.
The software developer is responsible for replacing the
existing release of a system with a new release and this
is made available to all customers at the same time.
11/12/2014 Chapter 25 Configuration management 64
65. Key points
Configuration management is the management of an evolving
software system. When maintaining a system, a CM team is put in
place to ensure that changes are incorporated into the system in a
controlled way and that records are maintained with details of the
changes that have been implemented.
The main configuration management processes are concerned with
version management, system building, change management, and
release management.
Version management involves keeping track of the different versions
of software components as changes are made to them.
Chapter 25 Configuration management 6511/12/2014
66. Key points
System building is the process of assembling system components
into an executable program to run on a target computer system.
Software should be frequently rebuilt and tested immediately after a
new version has been built. This makes it easier to detect bugs and
problems that have been introduced since the last build.
Change management involves assessing proposals for changes
from system customers and other stakeholders and deciding if it is
cost-effective to implement these in a new version of a system.
System releases include executable code, data files, configuration
files and documentation. Release management involves making
decisions on system release dates, preparing all information for
distribution and documenting each system release.
Chapter 25 Configuration management 6611/12/2014