Upload
aoife
View
24
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Software Engineering. Software Configuration Management. Objectives. To make clear the inevitability of software change. To define the terminology of software configuration management. To cover the issues involved in effective change control. Dealing with Change. - PowerPoint PPT Presentation
Citation preview
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]
Configuration Object
[baseline version]
Ownership Info
Configuration Object
[extracted version]
Configuration Object
[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
analysis design code test
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
analysis design code test
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
analysis design code test
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