1 / 16

Experience from the maintenance phase in international projects

Experience from the maintenance phase in international projects. Dragan Boji ć University of Belgrade. General Projects Characteristics. Both for software market and for known customer (outsourcing) Geographically distributed development/testing/deployment

kaori
Download Presentation

Experience from the maintenance phase in international projects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Experience from the maintenance phase in international projects Dragan Bojić University of Belgrade

  2. General Projects Characteristics • Both for software market and for known customer (outsourcing) • Geographically distributed development/testing/deployment • 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 decide Sends request via 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. CR Submitter Project Manager Implementer Verifier Chg M. - Realization Updates plans Inititates implementation via #36CRNNNN/DEV# (form 4) Status Assigned Assesment, then implementation Completion report more activities needed (succeed fail) via #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) Verif. failed Status assesment 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

More Related