Software configuration Management as a Software Engineering Discipline

Transcription

1 Software configuration Management as a Software Engineering Discipline Lorenco Damjanic Ericsson Nikola Tesla Zagreb

2 Contents Product structures Software Engineering Software Configuration Management Software Development Paradigm Literature

3 Product structuring

4

5 Product Stuctures Different relations / structure views showing common ways of connecting products. System requirements Delivery/manufacturing structure Functional breakdown System (functional) structure Implementation (realization) structure HW 1 SW 1

6 The V-Model Technical SW perspective Logical Modules Realization Modules Configuration and Deployment Packages System (Company) Subsystem (Design center) Block (Team) Unit (Individual) Source Code

7 Software Intensive Systems software-intensive systems any system in which software development and/or integration are dominant considerations most complex systems these days. This includes computer-based systems ranging from individual software applications, information systems, embedded systems, product lines and product families and systems-of-systems.

8 Software Engineering

9 History and Rational of Software Engineering In the belief that software design, implementation and maintenance could be put on the same footing as traditional engineering discipline a NATO study group in 1967 coined the term: Software Engineering which should use philosophies and paradigms of established engineering discipline to solve what was termed the software crises namely, that the quality of software was generally unacceptably low and that deadlines and cost limits were not being met.

10 Software system A software system is a system based on software forming part of a compute system (a combination of hardware and software). The term software system is often used as a synonym of computer program or software. The term software system is related to the application of systems theory (Systems theory is an interdisciplinary field of science and the study of the nature of complex systems in nature, society, and science.) approaches in software engineering context. This approach is often used to study large and complex software, because it focuses on the major components of software and their interactions. The term software system is also related to the field of software architecture.

11 Software Software is a general term for the various kinds of programs used to operate computers and related devices. Software is often divided into application software (programs that do work users are directly interested in) and system software (which includes operating systems and any program that supports application software). The term middleware is sometimes used to describe programming that mediates between application and system software or between two different kinds of application software (for example, sending a remote work request from an application in a computer that has one kind of operating system to an application in a computer with a different operating system). Software can be purchased or acquired as shareware (usually intended for sale after a trial period), liteware (shareware with some capabilities disabled), Freeware (free software but with copyright restrictions), public domain software (free with no restrictions), and open source (software where the source code is furnished and users agree not to limit the distribution of improvements).

12 Software Types In computer science, real-time computing (RTC) is the study of hardware and software systems which are subject to a "real-time constraint" i.e., operational deadlines from event to system response. By contrast, a non-real-time system is one for which there is no deadline, even if fast response or high performance is desired or even preferred. The needs of real-time software are often addressed in the context of real time operating systems, and synchronous programming languages, which provide frameworks on which to build real-time application software. A real time system may be one where its application can be considered (within context) to be mission critical Fault-tolerance or graceful degradation is the property that enables a system (often computerbased) to continue operating properly in the event of the failure of (or one or more faults within) some of its components. If its operating quality decreases at all, the decrease is proportional to the severity of the failure, as compared to a naively-designed system in which even a small failure can cause total breakdown. Fault-tolerance is particularly sought-after in high-availability or life-critical systems.

13 Software Engineering Definition Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. Software engineering encompasses techniques and procedures, often regulated by a software development process with the purpose of improving the reliability and maintainability of software systems. A software development process is a structure imposed on the development of a software product.

14 Software Engineering Discipline The discipline of software engineering includes knowledge, tools, and methods for Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering tools and methods Software quality. Software engineering is related to the disciplines of Computer engineering Computer science Management Mathematics Project management Quality management Software ergonomics Systems engineering

15 Software Configuration Management

16 SCM Definition SCM is a set of activities designed to control change by: identifying the work products that are likely to change, establishing relationships among them, defining' for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made. Roger Pressman, Software Engineering: A Practitioner's Approach Configuration management practices include revision control and the establishment of baselines.

17 Software Configuration Management Software Configuration Management (SCM) is a practice within Software Engineering discipline which insures the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.

18 Revision control Revision control (version control or source control) is the management of changes to Documents, Programs, and other information stored as computer files. It is most commonly used in software development, where a team of people may change the same files.

19 Products, Documents and Files Documents Files (Not identified) Products All information must be identified, but keep the number of identified items low!

20 Change Identifications Changes are usually identified by: a number or letter code, "revision number", "revision level., For example: an initial set of files is "revision 1" after the first change is made, the resulting set is "revision 2", and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged.

21 Rules for Document Revision Preliminary Revisions Example Approved Ordinary Revisions PA1 PA2 PA3 A PB1 B PC1 PC2 C Table of contents

22 Purpose of SCM The goals of SCM are generally: Configuration identification - Identifying configurations, configuration items and baselines. Configuration control - Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline. Configuration status accounting - Recording and reporting all the necessary information on the status of the development process. Configuration auditing - Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals. Build management - Managing the process and tools used for builds. Process management - Ensuring adherence to the organization's development process. Environment management - Managing the software and hardware that host the system. Teamwork - Facilitate team interactions related to the process. Defect tracking - Making sure every defect has traceability back to the source.

23 Software Development Paradigm

24 Software Intensive Systems software-intensive systems any system in which software development and/or integration are dominant considerations most complex systems these days. This includes computer-based systems ranging from individual software applications, information systems, embedded systems, product lines and product families and systems-of-systems.

25 Agile Software Development Agile Software Development is a conceptual framework for software development that promotes development iterations throughout the life-cycle of the project. There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which typically lasts from one to four weeks. Each iteration passes through a full software development cycle: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.

26 Agile Software Development Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a Scrum. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, a business annalists, or the clients). The office may include software testers, interaction designers, technical writers, and managers.

27 Agile Software Development Some of the principles behind the Agile Manifesto are: Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication (Co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances

28 SCM tools- Open source Concurrent Versions System (CVS) originally built on RCS, licensed under the GPL. CVSNT cross-platform port of CVS that allows case insensitive file names among other changes OpenCVS CVS clone under the BSD license, with emphasis put on security and source code correctness Subversion (svn) versioning control system inspired by CVS Vesta build system with a versioning file system and support for distributed repositories

29 SCM tool- Preparatory AccuRev source configuration management tool with integrated issue tracking based on "Streams" that efficiently manages parallel and global development; replication server is also available CA Software Change Manager (originally Harvest/CCC) change and configuration management tool by Computer Associates Autodesk Vault Version control tool specifically designed for Autodesk applications managing the complex relationships between design files such as AutoCAD and Autodesk Inventor. ClearCase SCC compliant configuration management system by IBM Rational Software codebeamer Collaboration and application lifecycle management platform IBM Configuration Management Version Control (CMVC) version control system, no longer available. IC Manage Global Design Platfomr (GDP) design data management for IC design and Perforce infrastructure support. MKS Integrity Perforce Free for use in open source projects. Polytron Version Control System (PVCS) originally developed by Don Kinzer at Polytron, first released in 1985 Quma Version Control System StarTeam coordinates and manages software delivery process by Borland; centralized control of digital assets and activities Telelogic Synergy SCC compliant integrated change management and task-based configuration management system,proprietary of IBM. Vault version control tool by SourceGear (First installation can be used for free) Visual SourceSafe version control tool by Microsoft; oriented toward small teams Visual Studio Application Lifecycle Management (previously Team System) process-based client-server suite of tools by Microsoft for larger development organizations, incorporating work item tracking, reporting, build automation, unit and web testing, and integration with Microso

30 Subversion (svn) Apache Subversion (often abbreviated SVN, after the command name svn) is a software versioning and a revision control system founded and sponsored in 2000 by CollabNet Inc. Developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS). One can view the Subversion filesystem as "two-dimensional". Two coordinates are used to unambiguously address filesystem items: Path (regular path of Unix-like OS filesystem) Revision Each revision in a Subversion filesystem has its own root, which is used to access contents at that revision. Files are stored as links to the most recent change; thus a Subversion repository is quite compact. The system consumes storage space proportional to the numberof changes made, not to the number of revisions. The Subversion filesystem uses transactions to keep changes atomic. A transaction operates on a specified revision of the filesystem, not necessarily the latest. The transaction has its own root, on which changes are made. It is then either committed and becomes the latest revision, or is aborted. The transaction is actually a long-lived filesystem object; a client does not need to commit or abort a transaction itself, rather it can also begin a transaction, exit, and then can re-open the transaction and continue using it. Multiple clients can access the same transaction and work together on an atomic change, though no existing clients expose this capability.

31 SVN basic concepts The commit operation is usually the most critical in this sense. Commits are operations which tell the revision control system you want to make a group of changes you have been making final and available to all users. The Trunk is a unique line of development that is not a branch (sometimes also called Baseline or Mainline) A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other. A tag or label refers to an important snapshot in time, consistent across many files. These files at that point may all be tagged with a user-friendly, meaningful name or revision number. A merge or integration is an operation in which two sets of changes are applied to a file or set of files. A user, working on a set of files, updates or syncs their working copy with changes made, and checked into the repository, by other users A user tries to check-in files that have been updated by others since the files were checked out, and the revision control software automatically merges the files. A set of files is branched, a problem that existed before the branching is fixed in one branch, and the fix is then merged into the other branch. A branch is created, the code in the files is independently edited, and the updated branch is later incorporated into a single, unified trunk.

32 Development Environment Subclips Eclipse Subversion FIT/IssueTrack Flex Builder Release Tool MySQL IDE JDK GWT Hibernate Flex SDK Compile Environment Spring Framework Libraries Clover JUnit Test Environment

33 Software Release Process A software release is the distribution of software code, documentation, and support materials. The software release life cycle is composed of discrete phases that describe the software's maturity as it advances from planning and development to release and support phases.

34 30 year later The software crises is still with us which force us to rename it to the software depression in view of its long duration and poor prognosis. The question is does the software production process, while resembling traditional engineering in many respect has its own unique properties and problems. Could SCM Help?!

35 Literature

36 Literature Wikipedia