Dragan Bojic

1
Experience from the maintenance phase in
international projects

• Dragan Bojic
• University of Belgrade

2
General Projects Characteristics

• Both for software market and for known customer
  (outsourcing)
• Geographically distributed development/testing/dep
  loyment
• Most communication via Internet (emails, ftp,...)
• Offline integration (no web VCS)
• Iterative development
• Alpha release (Prototype)
• Beta release
• Production release 1.0
• Production release 1.0.1 (patch for user XY)
• Production release 1.1 (new functionality)
• ...
• maintenance moving from one release to another

3
Supporting processes for the maintenance phase

• Configuration management
• Change Request Management
• Purpose control change to, and maintain
  integrity of, project artifacts (Rational
  Unified Process)
• Artifact intermediate or final work products
  produced and used during a project
• Models
• Documents
• Source code
• ...

4
Configuration Management

• Process organization at RistanCASE, GmbH
• About 30 team members
• Telejob working environment
• Offline integration

5
CM with offline integration team member actions
baseline
1 Store baseline
DAC_5_0_A100
from delivery
Local CM
media to local
baseline
repository with
repository
DAC_5_0_A100
tailoring
2 Checkout to
Team
branch
local workspace
Member
A100NN1
NN
delta file
3 Verify resolve
integration conflicts
4 Make some
5 Checkin to
6 Send delta for
changes
repository
integration
NN's
Workspace
FTP server
6
CM with offline integration
2 Store deltas to
local repository
1 Send
integration notice
FTP server
3 Checkout to
baseline
workspace
DAC_5_0_A100
Integrator
branch
4 Merge NN1
A100NN1
changes
delta file
branch
5 Merge XY4
A100XY4
changes
Integration
delta file
Workspace
6 Resolve
7 Checkin new
baseline
Local CM
integration conflicts
baseline
repository
DAC_5_0_A101
8 Create
distribution
7
Configuration Management- Access Control

• A Workspace defines access rights to individual
  artifacts (not accessible at all, read only,
  read-write).
• Associated with groups of team members
• wDEV developers workspace (source code files,
  models, etc)
• wDEV_SubsystemX part od wDEV assoc with a
  particular subsystem (component)
• wTST test team member workspace (test specs,
  test cases, etc)
• wDOC user documentation workspace
• wMGR manager workspace (plans, reports, etc)
• .access file for mapping project directories and
  individual artifacts to workspaces
• di\adg\di\cadg\lib wDEV wDEV_ADG
• di\adg\di\cadg\mdl\configuration.cat wDEV_ADG
• .workspace file for mapping workspaces to team
  members
• DB wMNG wDEV wDEV_SA wDEV_MTR wDOC
• DG wDEV wDEV_PM wDEV_UDA wDEV_SUP wDEV_SC
• Chmod like tool for integrator to manage access
  rigths

8
Configuration Management- Baseline and branch
identification

• DAC_5_0_A001NN2
• Project Name (DAC)
• Mayor release (5)
• Minor release (0)
• Promotion level (explained below) (A)
• Baseline identifier (001)
• For branches, initials of team member and branch
  number (NN2)
• Promotion level
• an attribute of the baseline
• Indicates its quality or stability
• A alpha (internal integration, instable working
  baseline)
• B beta (distributed to selected outside users)
• R release candidate (released after testing and
  decision of product team)

9
Change Management

• Change Request submitted request for new
  features, enhancements, defect elimination,...
• Submitted by customers (via support), developers,
  testers, managers,...
• Several hundred change requests between two mayor
  releases
• Need to formalize and systematically process each

10
Change M. - Assesment
CR Submitter
Project Manager
Product Team
Assigns id NNNN,
Sends RCLS mail -
opens topic
topic 50CRALL
36CRNNNN
Forms 1 and 2
Status Open
need
Assesment
more info
PT
Form 1-3
decides
Status PT to
Study CR
Sends request via
decide
topic 36CRNNNN
Submitter replies
deferred
forms 1 i 2
Status Open
rejected
accepted
rejected
Decision
deferred
Fills in form 3,
Fills in form 3,
status Dissaproved
status Deffered
Status Approved,
accepted
fills in form 3
Sends notice via
topic 36CRNNNN
Planning the
realization
11
Chg M. - Realization
CR Submitter
Project Manager
Implementer
Verifier
Updates plans
Inititates implementation
via 36CRNNNN/DEV
(form 4)
Status Assigned
Assesment, then
implementation
Completion report
(succeed fail) via
more activities needed
36CRNNNN/DEV
form 4
Status Assesment
Success
Status Completed
Failure
form 5 u
36CRNNNN/SQA
Sends report (Form 4)
Verification
via 36CRNNNN
Status Rejected
Completion report
(succed, fail) via
36CRNNNN/SQA
(form 2)
Status assesment
Verif. failed
Sends Report
Verification Passed
(form 4) via
36CRNNNN/
Send report (Form 4)
DEV
via 36CRNNNN
Status Verification
Status Closed
Failed
12
Chg M. Change Request States
13
Form 1 for CR Submitter
14
Form 2 for Verifier
15
Form 3 for Managers
16
Form 4 for Implementer