software engineering software configuration management

Software EngineeringSoftware Engineering

Software Configuration Management

ObjectivesObjectives

1. To make clear the inevitability of software change.

2. To define the terminology of software configuration management.

3. To cover the issues involved in effective change control.

Dealing with ChangeDealing with Change

“No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.”

Configuration management is the art of identifying, organizing, and controlling modifications to software so as to keep mistakes and confusion to a minimum.

Software Configuration Management is an umbrella activity (much like SQA) applied throughout the software process.

Tasks: Identify change Control change Ensure that change is being properly implemented Report changes to others who might have an interest

What Are These Changes?What Are These Changes?

data

otherdocuments

codeTests

ProjecttPlan

changes in technical requirements

changes in business requirements

changes inuser requirements

software models

Software Configuration TerminologySoftware Configuration Terminology

Baseline: A specification or product that has been formally reviewed an

agreed upon. Can only be changed through formal control procedures.

Software Configuration Items: The objects that make up a baseline. Information created during

the software engineering process. For example: a suite of test cases, a program component, an

analysis model. May also include specific versions of editors, compilers and case

tools, which need to be “frozen”. Must also specify dependencies and relationships between SCI’s. Once reviewed an approved they are placed in a project database

(also called a project library or software repository)

The SCM ProcessThe SCM Process

Identification: SCI must be separately named and related.

Version Control: recording different versions of an SCI.

Change Control: managing the way in which changes are carried out.

Auditing: making sure that change is properly implemented.

Reporting: ensuring accountability

A balancing act (creativity vs. control)Software EngineeringSoftware Engineering

a TQM foundation

procedures

methods

tools

SCMSCM• identification• version control• change control• auditing• reporting

Version ControlVersion Control

Allows management of configurations through selection of variants or versions.

Associate attribute-tuples with each SCI. Can be as complex as a string of Boolean switches indicating functionality.

Variant: A set of SCI at the same version level with different functionality.

Version: A change in an SCI spawns a new version.

Variants

SCI

Versions

Change Control ProcessChange Control Process

Change request from user

Developer evaluates

Change report is generated

Change control authority decides

Request is queued for action

Change request is denied

User is informed

Need for change is recognized

Change control process proceeds

Change Control Process ContinuedChange Control Process Continued

Assign people to SCIs

Check-out SCIs

Make the change

Review/audit the change

Establish a “baseline” for testing

Perform SQA and testing activities

Promote SCI for inclusion in next release

Rebuild appropriate version

Review/audit the change

Include all changes in release

Check-in the changed SCIs

Check-in and Check-out ProcedureCheck-in and Check-out Procedure

Access Control

Check-In

Check-Out

Unlock

Lock

Project Database

Software Engineer

Configuration Object

[baseline version]


[baseline version]

Ownership Info


[extracted version]


[extracted version]

Audit Info

Auditing and ReportingAuditing and Reporting

Auditing: Considers change aspects not covered by a formal technical review. Ensures change management is being applied.

Reporting: Places in an on-line database information such as what happened, who instigated the change, when it occurred and what else was affected.

SCIs

ChangeRequests SQA

Plan

SCM Audit

Software EngineeringSoftware Engineering

Summary

The Nature of SoftwareThe Nature of Software

Software is a set of items or objects that form a “configuration” that includes: Programs Documents Data

Software Characteristics: Software is developed or

engineered, rather than being manufactured.

Although the industry is moving toward component-based assembly, most software continues to be custom built.

Software doesn’t wear out. Software is complex.

The ProductThe Product

Software Myths: Managers are under pressure, tend to grasp at myths.

Myths held by customers often lead to false expectations and, ultimately, dissatisfaction.

Early attitudes to programming have become entrenched among practitioners.

Professional and ethical responsibilities: Software engineering involves wider responsibilities

than simply the application of technical skills.

Confidentiality, competence, intellectual property rights, computer misuse.

The ProcessThe Process

Software Engineering defined: The establishment and use of sound engineering principles in order

to obtain economically software that is reliable and works efficiently on real machines.

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

Generic Phases: Definition (“what”): Establish what the requirements of the system

are. Development (“how”): Establish how the system is to be realized –

design and build Support: Handle changes as the software environment evolves

This process is complemented by a number of umbrella activities.

Process ModelsProcess Models

A framework of tasks applied during software engineering: Linear (Waterfall): Based on conventional engineering

Prototyping: Build a system to clarify requirements

Rapid Application Development (RAD): Well defined 60-90 day projects

Incremental: Deliver increasing functionality at each iteration

Spiral (Boehm): Similar set of tasks applied for each turn of the spiral.

Component based: Aimed at producing and reusing OO components

analysis design code test

AnalysisAnalysis


Process Model Output

1. Elicit customer requirements and identify use-cases

Use-Case Diagrams

2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy

Class Responsibility Collaborator (CRC) Cards

3. Build an object-relationship model (structural)

Conceptual Class Diagram

4. Build an object-behaviour model (dynamic)

Interaction and State Diagrams

Analysis PrinciplesAnalysis Principles

begin by focusing on the essence of the problem without regard to implementation details

Examine “What” rather than “how” Understand the problem before you begin to create the

analysis model. Develop prototypes that enable a user to understand how

human-machine interaction will occur. Record the origin of and the reason for every requirement. Use multiple views of requirements. Prioritize requirements. Work to eliminate ambiguity. (Primary advantage of

Formal Mathematical Specification)

Use Case DiagramsUse Case Diagrams

Graphically shows use-cases, actors and their relationships.

Use CaseCommunication

Relationship

Actor

Analyze Risk

Trader

Price Deal

Capture Deal

Valuation

Limits Exceeded

<<extends>>

<<uses>>

<<uses>>

Uses Relationship

Extends Relationship

Class Responsibility Collaborator Class Responsibility Collaborator CardsCards

Benefits: They are portable. No computers are required so they can be used

anywhere. Even away from the office.

They allow the participants to experience first hand how the system will work.

Stages: Identify potential classes with a grammatical parse for nouns.

Apply a set of requirement to determine acceptable classes.

Determine class types, characteristics, responsibilities (attributes and methods) and collaborators.

Do a CRC review (walkthrough) of the model.

Example: CRC CardExample: CRC Card

class name: Sensor

class type: external entity

class characteristics: tangible, atomic, concurrent, guarded

responsibilities: collaborators:

keep sensor informationassign sensor informationsignal sensor event

Class DiagramsClass Diagrams

Descendent of Entity-Relationship Diagrams Show the static structure of the model

the entities that exist internal structure relationship to other entities

Static View Do not show temporal information

Used in both analysis (conceptual) and design (specification and implementation).

Conceptual class diagrams only require a subset of the full UML notation.

Derived from CRC Cards.

Example: Class DiagramExample: Class Diagram

Class

Association

Label and Navigability

Multiplicity

system

audible alarm

control panel sensor

sensor event

contains polls

recognizes produces

1 1 1 1..*

1

*

1

*

Object-Behavioural ModellingObject-Behavioural Modelling

CRC and object-relationship model static Object-behaviour model dynamic (function of

specific events and time) Process:

1. Evaluate use-cases to understand the sequence of system interaction

2. Identify events that drive the interaction sequence and relate these to specific objects

3. Create an interaction diagram for each use-case

4. Build a state diagram for the system

5. Review model to verify accuracy and consistency

Example: Sequence DiagramExample: Sequence Diagram

Homeowner Control Panel

System

system ready

enters password

ready for activation/deactivation

selects stay or away

ready for next action

initiates beep

activate/deactivate sensors

red light on request

Object

Life Line

Active Event

Basic UML State DiagramBasic UML State Diagram

stop

/ctr := 0stop [user quits]

Final State

Done

Ready

Transition

Initial Pseudostate

Action

Event

State

Guard

Design SummaryDesign Summary


Process Model Output

1. Subsystem Design: partition the system into components

A Package Diagram

2. Class and Object Design: define class hierarchies

Specification Class Diagram

3. Message Design: convert the object-relationship model into a set of class messages

Message Descriptions

4. Responsibility Design: specify the internal structure of classes

Specification Class Diagram with full attribute and method syntax

C++ Class Headers

Testing SummaryTesting Summary


Process Technique

1. Class Testing: test methods and state behaviour of classes

Random, Partition and White-Box Tests

2. Integration Testing: test the interaction of sets of classes

Random and Behavioural Testing

3. Validation Testing: test whether customer requirements are satisfied

Use-case based black box and Acceptance tests

4. System Testing: test the behaviour of the system as part of a larger environment

Recovery, security, stress and performance tests

Steps in Project PlanningSteps in Project Planning

Scope—understand the problem and the work that must be done. Estimation—how much effort? how much time? Risk—what can go wrong? how can we avoid it? what can we do

about it? Schedule—how do we allocate resources along the timeline?

what are the milestones? Control strategy—how do we control quality? how do we

control change?

SoftwareProject

Plan

Project ScopeEstimatesRisksScheduleControl strategy