Transcript Project Management - Monitoring and Control

Why Is Software Difficult to
Build?
 Lack of control
 Lack of monitoring
 Lack of traceability
 Uncontrolled changes
Conflicts in Team Software
Development
 Simultaneous updates – how to
prevent one person from undoing
the changes of another
 Shared and common code – how to
notify everyone who needs to
know about a change
 Versions – how to make changes to
all affected versions when needed
With a focus on:
Configuration management
Change management
OTHER SOFTWARE PROCESSES
Other Processes
3
Other Processes
 Development Process is the central process
around which others revolve
 Methods for other processes often influenced
by the dev process
Other Processes
4
Other Processes In the
context of Dev Processes
Other Processes
5
Monitoring and control
 Aspect of project management process
 Lasts for the duration of the project and
covers the development process
 Monitors all key parameters like cost, schedule,
risks
 Takes corrective actions when needed
 Needs information on the dev process – provided
by metrics
Other Processes
6
Communication Facilitation




Realistically no plan covers everything!
Additional decisions are made during development
Documents should be updated and communicated
Typical environment




Multiple teams
Multiple user groups
Multiple disciplines
Multiple locations
 In many setting PM is center of communication hub
 Planning and content meetings
Other Processes
7
Meeting Types
 Issues Meetings
 Regularly schedule meeting (ie. open in everyone’s
schedule)
 Issues gathered the day before and distributed
 Issue initiator indicates required attendance
 QA Meetings
 Planning
 Discussion with business
 Discussion with developers
 Regular Review of open tickets
Other Processes
8
Relationship with Dev Process
Other Processes
9
CONFIGURATION
MANAGEMENT PROCESS
Other Processes
10
Software Configuration
Management Basics
 Identification – identifying software
configuration items in a baseline
 Control – controlling the release of a product
and changes to it throughout its lifecycle
 Status Accounting – recording and reporting of
the status of components and changes
 Auditing and Reviewing – Validating the
completeness of a product and that SCM
procedures are being followed
SCM Definitions
 Baseline – One or more software
configuration items that have been formally
reviewed and agreed upon and serve as a
basis for further development
 Software Configuration Item – A collection of
software elements treated as a unit for the
purposes of SCM
 Configuration – A collection of all the
elements of a baseline and a description of
how they fit together
SCM Definitions (cont’d)
 Configuration Control Board – Group with the
responsibility for reviewing and approving
changes to baselines
 Software – All of the code, specifications,
plans, descriptions, processes, and
documents associated with a software
development effort
 Version – A specific instance of a baseline or
configuration item
Background
 A software project produces many items -
programs, documents, data, manuals, …
 All of these can be changed easily – need to
keep track state of items
 Software Configuration Management (SCM)
 Systematically control the changes
 Focus on changes during normal evolution (req
changes will be handled separately)
 CM requires discipline as well as tools
Other Processes
14
Background
 SCM often independent of dev process
 Dev process looks at macro picture, but not on
changes to individual items/files
 As items are produced during dev they are
brought under SCM
 SCM controls only the products of the
development process
Other Processes
15
Examples of Configuration
Items











Product concept specification
Software project plans
Software requirements specifications
Software design descriptions
Source code
Database descriptions
SCM procedures
Software release processes
Software test documents
User documentation
Maintenance documentation
SCM Process and Dev process
Other Processes
17
Need for CM
 CM needed to deliver product to the client
 What files should comprise the product?
 What versions of these files?
 How to combine these to make the product?
 Just for this, versioning is needed, and state
of different items has to be tracked
 There are other functions of CM also
Other Processes
18
Functionality Needed
 Capture current state of programs
 Capture latest version of a program
 Undo a change and revert back to a specified
version
 Prevent unauthorized changes
 Gather all sources, documents, and other
information for the current system
Other Processes
19
CM Mechanisms
 Configuration identification and baselining
 Version control
 Access control
 These are the main mechanisms, there are
others like
 naming conventions,
 directory structure,…
Other Processes
20
Configuration Items
 Sw consists of many items/artifacts
 In CM some identified items are placed under
CM control
 Changes to these are then tracked
 Periodically, system is built using these items
and baselines are established
 Baseline – logical state of the system and all
its items; is a reference point
Other Processes
21
Version Control
 Allows different projects to use the same
source files at the same time
 Isolates work that is not ready to be shared
by the rest of the project
 Isolates work that should never be shared
 Allows software engineers to continue
development along a branch even when a line
of development is frozen
Version and access control
 Key issues in CM
 Done primarily on source code through source
code control systems, which also provide access
control
 Allows older versions to be preserved and hence
can undo changes
 Examples:
 CVS – Original open source system (1986)
 Subversion – Open source CVS replacement (1999)
 Microsoft Visual SourceSafe (VSS) – targeted for
smaller dev projects
 IBM Rational ClearCase – Industrial strength solution
Other Processes
23
Version and Access Control
 When programmer developing code – is in
private area
 When code is made available to others, it goes in
an access-controlled library
 For making changes to an item in library, it has
to be checked out
 Changes made by checking-in the item –
versioning is automatically done
 Final system is built from the library
Other Processes
24
Version/Access Control
 Generally both version and access control
done through CM tools
 Tools limit access to specified people - formal
check in, check out procedures
 Automatic versioning done when a changed
file is checked-in
 Check-in, check-out control may
 be restricted to a few people in a project
 Require successful compile/build cycle
Other Processes
25
CM Process
 Defines the activities for controlling changes
 Main phases
 CM Planning
 Executing the CM process
 CM audits
Other Processes
26
CM Planning
 Identify items to be placed under CM
 Define library structure for CM
 Define change control procedures
 Define access control, baselining,
reconciliation, procedures
 Define release procedure
Other Processes
27
CM Audit
 During project execution CM procedures have
to be followed (e.g. moving items between
directories, naming, following change
procedures, …)
 Process audit has to be done
 CM audit can also check if items are where
they should be
Other Processes
28
Summary – CM
 CM is about managing the different items in the
product, and changes in them
 Developing a CM plan at the start is the key to
successful to CM
 CM procedures have to be followed; audits have to
be performed
 Requires discipline and tools
Other Processes
29
REQUIREMENTS CHANGE
MANAGEMENT PROCESS
Other Processes
30
Background
 Requirements change at any time during the
development
 Changes impact the work products and the
various configuration items
 Uncontrolled changes can have a huge
adverse impact on project in cost/sched
 Changes have to be allowed, but in a
controlled manner
Other Processes
31
Change Control
 Proposed changes to baselines must have some
level of review
 The impact of proposed changes must be
identified and understood.
 When appropriate the approval of the CCB, key
managers and project members must be
obtained
 Approved changes must be properly
implemented
 After changes are made all affected parties must
be notified
A Change Mgmt Process
 Log the changes
 Perform impact analysis on the work
products and items
 Estimate impact on effort and schedule
 Review impact with stakeholders
 Rework the work products/items
Other Processes
33
Changes
 Change often triggered by change request
 Change req log keeps a record of requests
 Impact analysis for a change request involves
identifying the changes needed to diff items,
and the nature of change
 The impact of changes on the project is
reviewed to decide whether to go ahead
 Cumulative changes also often tracked
Other Processes
34
http://www.marinebiodiversity.ca/COINAtlantic/development-implementation-sustainability/geoconnections-coinatlantic/webmapping-application/User%20Acceptance%20Test%20Plan%20and%20Change%20Request%20Process%20-%20Cur....pdf/view
35
Baseline CM
 Recall:
 A baseline is one or more software
configuration items that have been formally
reviewed and agreed upon and serve as a basis
for further development
Other Processes
36
Baseline Management
 What baselines are required to be defined
and managed?
 Typically aligned with major milestones
 Applies to documents as well as code
 How is the current software configuration
defined?
 A snapshot of everything the product has
produced at some point in time
Baseline Management (cont’d)
 Who must approve changes to baselines?
 Usually the Change Control Board (CCB)
 How and when are baselines created and
physically controlled?
 Through the use of document control systems,
code control tools, and procedures to prevent the
making of unapproved changes
Baseline Management (cont’d)
 How are people informed of changes?
 The CCB disseminates change information
 How are baselines verified?
 By reviews, inspections, and the testing of code
 Are baselines tied to project milestones?
 Many are, but during coding many may not be
Baseline Management
(cont’d)
 What information is required to process a change
to a baseline?
 A description of the proposed changes
 Reasons for making the changes
 List of other items affected by the changes
 What tools, resources, and training are required to
perform baseline change assessment?
 File comparison tools to identify changes
 Resources and training depend on size and complexity
of project
Baseline Management (cont’d)
 How are unauthorized changes to source
code prevented, detected, and corrected?
 No way to prevent unauthorized changes
 Provide software engineers with training
 A commercial available SCM systems provide
adequate protection
 Unauthorized changes should be caught during
assessment procedures
Baseline Management (cont’d)
 What tools, resources, and training are
required to perform baseline management?
 A fully featured SCM tool
 On large projects a separate SCM group may be
needed
 SCM training is required for all involved in the
process
For your project:
 Should have a configuration management
process defined
 Change management procedures
 Any changes to the baseline documents
should be documented and include a formal
change management request
Other Processes
43
Examples
 Collegiate Project Services
http://www.collegiateproject.com/articles/Pr
eliminaryChangeManagementPlan.pdf
 Eclipse:
http://www.eclipse.org/epf/process/change_r
equest_faq.php
Other Processes
44