Principles of Software and Requirements Engineering Software Configuration

Principles of Software and Requirements Engineering Software Configuration Management Francis Palma Department of Electrical & Computer Engineering Concordia University of Ontario Institute of Technology May 6 th 2016

A Brief Introduction

• 2015 - present (Canada) – Post-doctoral Research Fellow – Research Intern • 2011 - 2015 (Canada) – Ph. D Studies (SE) – Supervisors: Dr. Yann-Gaël & Dr. Naouel Moha • 2011 - 2011 (Italy) – Research Collaborator • 2008 – 2010 (Italy) – MSc in Computer Science (SE) – Supervisor: Dr. Paolo Tonella • 2006 – 2008 (Bangladesh) – Database Analyst & MIS Specialist • 2001 – 2005 (Bangladesh) – BSc in Computer Science and Engineering © Francis Palma, UOIT 2016 2 of 31

Academic-related Activities • Peer Reviewer – IJCIS 2016, SCAM 2015, ICSME 2015, SIMPAT 2014, SANER 2014, MCETECH 2014, IJBPIM 2014, PPAP 2013, CSMR-WCRE 2013, IEEE TSE 2012, So. Sy. M 2012, and AUSE 2012 • Conferences/Workshops Organizing – SANER (IEEE International Conference on Software Analysis, Evolution, and Reengineering) 2015 – PPAP (Patterns Promotion and Anti-patterns Prevention) 2015 • Conference/Workshop Research Talks – FSE (Hungary 2011), ICSOC (France 2014), ECSA (Austria 2014), ICSOC (China 2012), SSBSE (Italy 2010), SANER (Canada 2015), SOCA (Japan 2014), ICSME (Canada 2014), MRI-BP (Canada 2013), RSSE (Switzerland 2012), MCETECH (Canada 2015) • Students Co-supervising – 1 MSc Student’s thesis (now) – 6 Undergrad Students for their internship projects © Francis Palma, UOIT 2016 3 of 31

MAGIC Research Group • http: //users. encs. concordia. ca/~magic/ • Lead by Dr. Ferhat Khendek (Concordia), Dr. Maria Toeroe (Ericsson) • MAGIC Members – 1 RA, 1 PDF – 5 Ph. D Students – 3 MSc Students • Research Interests: – Investigate modeling languages for platforms, requirements, software and system characteristics in the cloud – Development of novel techniques for requirements decomposition and COTS components selection/configuration – Methodologies for the validation, deployment, monitoring, dynamic reconfiguration and upgrade of cloud systems, while maintaining critical characteristics, e. g. , high availability © Francis Palma, UOIT 2016 4 of 31

Software Configuration Management Topics Covered

• Basics of Software Configuration Management • Software Configuration Management Process • Configuration Management Data • Configuration Management in Practice • Tool Support for Configuration Management (Version Management) • Recent Trends in Software Configuration Management • Three Questions to Answer © Francis Palma, UOIT 2016 5 of 31

What is SCM? • “Software Configuration Management (SCM) is the control of the evolution of software systems” - Jacky Estublier, 2000 • “SCM is a practice that allows application developers and project managers to better identify potential problems, manage changes, and track the progress of software projects” - Anne Hass, Configuration Management Principles & Practice, 2002 • Standards (approved by ANSI) – IEEE 828: Software Configuration Management Plans – IEEE 1042: Guide to Software Configuration Management © Francis Palma, UOIT 2016 6 of 31

Why SCM? • The problem – Multiple people have to work on software that is changing – Different versions of the software have to be supported: • • Released systems Custom configured systems (different functionality) Systems under development Software on different machines & operating systems í Need for the Coordination… • Software Configuration Management (SCM) – Manages evolving software projects – Controls the costs involved in making changes to a system © Francis Palma, UOIT 2016 7 of 31

An Example Kim © Francis Palma, UOIT 2016 Tom 8 of 31

An Example Kim Tom 1. Ensure everyone is working with no conflicts in codes while changes are made 2. Ensure no communication gaps when code changes are made © Francis Palma, UOIT 2016 8 of 31

An Example Kim Tom Version Control System SCM Manager © Francis Palma, UOIT 2016 8 of 31

An Example Define Configuration Release Policies Items Define Activities & Responsibilities Setup Configuration Management System SCM Manager © Francis Palma, UOIT 2016 8 of 31

Various SCM Roles • Configuration Manager – Responsible for identifying configuration items – Defines the procedures for creating products and releases • Change Control Board Member – Responsible for approving or rejecting change requests • Developer – Creates products triggered by change requests or perform normal development activities – The developer checks in changes and resolves conflicts • Auditor – Responsible for the selection and evaluation of products for release – Ensure the consistency and completeness of this release © Francis Palma, UOIT 2016 9 of 31

Software Configuration Management ? SCM ? 2. Design/Implementation ? 3. Verification ? © Francis Palma, UOIT 2016 Software Life Cycle 1. Requirements Analysis 4. Maintenance & Evolution 10 of 31

Configuration Management Activities • Version Management – Keeping track of the multiple versions of system components and ensuring that changes made to them by different developers do not conflict • 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 that should be implemented • Release Management – Preparing software for external release and keeping track of the system versions that have been released for customer use Change Management System Building Component Versions System Versions Version Management © Francis Palma, UOIT 2016 System Releases Release Management 11 of 31

Overview of Software Configuration Management (SCM) Process

SCM Terminology • Configuration Item – An aggregation of hardware, software, or both, designated for configuration management and treated as a single entity in the CM process (not only source files) • Baseline – A specification/product that has been formally reviewed and agreed to by responsible management, that thereafter serves as the basis for further development, and can be changed only through formal change control procedures (3 digits naming scheme, e. g. , 7. 5. 5) • Version – The initial release or re-release of a configuration item associated with a complete compilation or recompilation of the item (different versions might have different functionality) • Revision – Change to a version that corrects only errors in the design/code, but does not affect the documented functionality • Release – The formal distribution of an approved product version © Francis Palma, UOIT 2016 12 of 31

SCM Process Configuration Identification CM Planning CM Management Configuration Change Control Configuration Status Accounting Configuration Auditing Release Management Source: IEEE Std 828 -2012, IEEE Standard for Configuration Management in Systems and Software Engineering. © Francis Palma, UOIT 2016 13 of 31

SCM Process CM Planning Purpose: Outcomes: To produce and communicate effective and workable CM plans, whether for a project or for on-going CM services to an organization • The scope of the work for the CM project • The evaluated feasibility of achieving the goals of the CM project with available resources & constraints • The tasks to be undertaken & required resources • Plans for the execution of the CM project © Francis Palma, UOIT 2016 14 of 31

SCM Process Configuration Identification Purpose: Outcomes: To determine naming schemes for Configuration Items (CIs), identify the items that require control as CIs, and to apply appropriate names to them • The product configuration is defined • Items requiring configuration are identified • Internal and delivery baselines are established © Francis Palma, UOIT 2016 15 of 31

SCM Process Configuration Change Control Purpose: Outcomes: To maintain the integrity of the product in all of its states, from requirements to a validated working product, as changes to it are needed both under development and postrelease • CI change requests are recorded and classified • CI change requests are assessed using defined criteria • Approved changes to CIs are implemented • CI changes are verified • Unsuccessful CI changes are reversed or remedied © Francis Palma, UOIT 2016 16 of 31

SCM Process Configuration Status Accounting Purpose: Outcomes: To record, retrieve, and report critical information on assets under configuration control to management and the project team • CM reporting needs are identified • CM reports are prepared according to defined criteria • CM reports are made available to affected parties © Francis Palma, UOIT 2016 17 of 31

SCM Process CM Configuration Auditing Purpose: Outcomes: To objectively assess the integrity of the product both from the functional and physical perspective • The scope & purpose of each CM audit is defined • Conformity of functional, physical, baseline, and release configurations to requirements is determined • Non-conformities are recorded and communicated to those responsible for corrective action and resolution • Corrective actions for non-conformities are verified © Francis Palma, UOIT 2016 18 of 31

Software Configuration Management Data

Configuration Item in SCM • Configuration management is about communication among those who want items, those who produce them, and those who use them • A Configuration Item is any possible part of the development or delivery of a system that is required to identify, produce, store, use, and change individually Hardware Workstations Paperware Design Sheets Document Bug 02. txt Source Code Calc. java Physical Configuration Item Electronic © Francis Palma, UOIT 2016 19 of 31

Configuration Items in SCM • Software Project Management Plan • Requirements Analysis Document • Source Code • Unit Tests • Test Data • User Manual © Francis Palma, UOIT 2016 20 of 31

Configuration Item Meta-data Product belongs to produced by under responsibility of People approval by may be distributed to has been distributed to © Francis Palma, UOIT 2016 Configuration Item Name Version Status Date Storage Location Storage Medium traces to produced with derived from Other Configuration Items consists of 21 of 31

Configuration Management in Practice “Best Practices”

SCM Best Practices • Workspaces (where developers build, test, and debug) – – Don’t share workspaces Don’t work outside of managed workspace Stay in sync with the codeline Check in often • Codelines (the canonical sets of source files) – Give each codeline a policy – Give each codeline an owner – Have a mainline • Branches (variants of the codeline) – – Branch only when necessary Don’t copy when you mean to branch Branch on incompatible policy Branch late © Francis Palma, UOIT 2016 22 of 31

SCM Best Practices (cont. ) • Change Propagation (getting changes from other codelines) – Make original changes in the branch that has evolved the least – Propagate early and often – Get the right person to do the merge (e. g. , an Integrator) • Builds (turning source files into products) – – – Source + tools = product Check in all original source (no mock/test code) Segregate built objects from the original source Use common build tools and build often Keep build logs and build output • Process (the rules for all of the above) – – – Track change packages Track change package propagations Distinguish change requests from change packages Give everything an owner Use living documents © Francis Palma, UOIT 2016 23 of 31

Tool Support for Configuration Management (Version Management)

Tool Support for SCM • What is “Version Control System (VCS)” and why should we care? – VCS records changes to a file or set of files over time so that you can recall specific versions later ? • Why VCS? – Keeps every version of software artifacts – Revert files/entire project back to a previous state – Compare changes over time – See who last modified something that might be causing a problem © Francis Palma, UOIT 2016 24 of 31

Local Version Control System • Copy files into another (timestamped) directory – Very simple but incredibly error prone • Local VCS has a simple database that keeps all the changes to files under revision control – Revision Control Systems (RCS) tool, e. g. , rcs command Mac OSX – Maintains patch sets © Francis Palma, UOIT 2016 *www. git-scm. com 25 of 31

Centralized Version Control System • Developers need to collaborate – Subversion, Concurrent Versions System (CVS), Perforce • Single Server and Multiple Clients model • Benefit: – Everyone knows about everyone else’s work • Drawback: *www. git-scm. com – Single point of failure © Francis Palma, UOIT 2016 26 of 31

Distributed Version Control System • If any server dies, any of the client repositories can be copied back up to the server to restore it © Francis Palma, UOIT 2016 *www. git-scm. com • Check out the latest snapshot of the files and fully mirror the repository 27 of 31

Few Version Management Operations Centralized Subversion (SVN) Distributed Git svn checkout pull an SVN tree git init create a new local repository svn add create and add a new file/directory git clone check out a repository svn delete git add delete a file/directory from local & repository add files svn status of working directories and files git commit changes to local (not in repository) svn update syncs local sand box with the repository git push send changes to the remote repository svn commit recursively sends changes to the server git checkout <branchname> create a new branch svn diff compare changes between two revisions git pull fetch & merge changes from the remote server © Francis Palma, UOIT 2016 28 of 31

Recent Trends in SCM

Version Management Source: Google Trends © Francis Palma, UOIT 2016 29 of 31

Continuous Integration (CI) • Maintain a single source repository • Automate the build • Make your build self-testing • Every commit should build on an integration machine • Test in a clone of the production environment • Make it easy for anyone to get the latest executable • Everyone can see what’s happening • Automate deployment • Popular tools: © Francis Palma, UOIT 2016 *Source: Software Engineering Institute, Carnegie Mellon University 30 of 31

Three Questions to Answer • SCM is an umbrella activity during software development and operation. (True or False? ) – True • SCM planning is not part of the overall project planning. (True or False? ) – False • Source code files, requirements documents, acceptance criteria, design models, test cases, and external libraries are Configuration Items that must be versioned. (True or False? ) – False © Francis Palma, UOIT 2016 31 of 31

Additional Materials

Topics for Next Lecture • Build Management – process of converting source code files into standalone software artifact(s) • Change Management – process of selecting which changes to encourage, which to allow, and which to prevent, according to project constraints • Release Management – process of managing, planning, scheduling, and controlling a software release (including testing and deploying)

Thank You