Software%20Engineering

1
Software Engineering

• Software Configuration Management

2
Objectives

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.

3
Dealing 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

4
What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
other documents
user requirements
software models
Project
Plan
data
Tests
code
5
Software 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 SCIs.
• Once reviewed an approved they are placed in a
  project database (also called a project library
  or software repository)

6
The 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 Engineering
SCM
identification
tools
version control
methods
change control
procedures
auditing
a TQM foundation
reporting
7
Version 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
8
Change Control Process
Need for change is recognized
Change request from user
Developer evaluates
Change report is generated
Change control authority decides
Change request is denied
Request is queued for action
User is informed
Change control process proceeds
9
Change Control Process Continued
Assign people to SCIs
Include all changes in release
Check-out SCIs
Make the change
Review/audit the change
Review/audit the change
Rebuild appropriate version
Establish a baseline for testing
Promote SCI for inclusion in next release
Perform SQA and testing activities
Check-in the changed SCIs
10
Check-in and Check-out Procedure
Configuration Object extracted version
Configuration Object baseline version
Check-In
Unlock
Audit Info
Ownership Info
Project Database
Software Engineer
Access Control
Lock
Configuration Object extracted version
Configuration Object baseline version
Check-Out
11
Auditing 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.

Change Requests
SQA Plan
SCIs
SCM Audit
12
Software Engineering

• Summary

13
The 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 doesnt wear out.
• Software is complex.

14
The 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.

15
The 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.

16
Process 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
17
Analysis
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
design
code
test
18
Analysis 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)

19
Use Case Diagrams

• Graphically shows use-cases, actors and their
  relationships.

Uses Relationship
Analyze Risk
ltltusesgtgt
Actor
Price Deal
ltltusesgtgt
Capture Deal
Communication Relationship
Use Case
ltltextendsgtgt
Extends Relationship
Limits Exceeded
20
Class Responsibility Collaborator Cards

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

21
Example CRC Card
class name Sensor
class type external entity
class characteristics tangible, atomic,
concurrent, guarded
responsibilities
collaborators
keep sensor information
assign sensor information
signal sensor event
22
Class 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.

23
Example Class Diagram
Label and Navigability
control panel
system
contains u
polls u
sensor
1..
1
1
1
1
1
Multiplicity
recognizes q
produces q


Association
audible alarm
sensor event
Class
24
Object-Behavioural Modelling

• CRC and object-relationship model ? static
• Object-behaviour model ? dynamic (function of
  specific events and time)
• Process
• Evaluate use-cases to understand the sequence of
  system interaction
• Identify events that drive the interaction
  sequence and relate these to specific objects
• Create an interaction diagram for each use-case
• Build a state diagram for the system
• Review model to verify accuracy and consistency

25
Example Sequence Diagram
Control Panel
Object
System
system ready
enters password
initiates beep
ready for activation/deactivation
Event
Active
selects stay or away
activate/deactivate sensors
Life Line
red light on request
ready for next action
26
Basic UML State Diagram
State
Ready
Event
/ctr 0
stop user quits
Initial Pseudostate
Transition
Done
Guard
Action
Final State
27
Design 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
analysis
design
code
test
28
Testing 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
analysis
design
code
test
29
Steps in Project Planning

• Scopeunderstand the problem and the work that
  must be done.
• Estimationhow much effort? how much time?
• Riskwhat can go wrong? how can we avoid it? what
  can we do about it?
• Schedulehow do we allocate resources along the
  timeline? what are the milestones?
• Control strategyhow do we control quality? how
  do we control change?

Project Scope Estimates Risks Schedule Control
strategy
Software Project Plan