@(#)process.htm 3.3 03/10/01
The Generic UWF Maintenance Process (GUMP ++) 1994-2000 The University of West Florida. All rights reserved.
Permission is granted to reproduce and adapt this document provided credit is given to the University of West Florida. This documentation is provided "as is" and no warranty of fitness for any particular purpose is made or implied.
This document describes the Generic Process Architecture of the software maintenance procedures used in the Software Engineering graduate program at the University of West Florida (UWF). It is meant to be a starting point for an organization developing a maintenance process and should be refined to fit the needs of the project and as the process matures.
The Universal Model in Figure 1 shows an overview of the GUMP++ Process Architecture.
Each cell will be discussed more thoroughly in following sections.
TISKs are classified as either Code Changes or Product Administration,
with a somewhat different process for each case.
Code Changes involve typical software maintenance activities such as:
Product Administration is the term used for many other activities which may
not warrant as much testing and inspection, but which may have a significant
impact on the perception of the software product by its users. Some examples
of Product Administration TISK activities include:
It is a characteristic of most Product Administration activities that little
analysis is needed to decide what shall be done. The change request or DR
should usually indicate specifically the changes to be made.
In general, the GUMP++ Process should always be considered a guideline,
not a straight jacket. As can be seen from the wide range of
examples given above, software maintenance activities are very diverse.
The PC and the project class must have flexibility to adapt to different
circumstances.
When a TISK is carried out in a manner significantly different from the
standard GUMP++ process, a Variance Report should be written to
document the change. Reasons for writing a Variance Report include:
Variance Reports should not be used as short-cuts to save time at the
risk of quality. All Variance Reports must be approved by the CCB, and are
filed in the TISK directory.
2.1 Cell 100: Receive Change Request and Generate Deficiency Report
The Change Request Cell defines the steps necessary for identifying
changes to existing systems and reporting those changes to the development
activity. Changes may be identified by customers, developers, or others
involved with the system. A Change Request does not follow a 'formal
format'.
| Actions Required | Responsibility |
|---|---|
| Receive CR | PC |
| Complete Deficiency Report (DR) | PC |
| Assign DR Number | PC with SCM |
| Put DR into DR directory (DR Pool) | SCM |
| Add DR to DR Summary (drsumry.txt) | SCM |
2.2 Cell 200: Select Deficiencies for Analysis
The PC should review the deficiencies in the DR Pool to determine
which should be handled as a Code Change TISK and which
can be considered to be a Product Administration TISK.
2.2.1 Cell 201: Establish Set of Deficiencies
The purpose of the Establish Deficiencies Cell is to group the deficiencies logically.
| Actions Required | Responsibility |
|---|---|
| Group DRs in Logical Groups | PC |
2.2.2 Cell 202: Select Set of Deficiencies for Analysis
The Select Set of Deficiencies for Analysis Cell allows the PC to select
a group of DRs to be presented to the group as a possible TISK. Selection criteria should include the scope of the task, the experience level of the group, schedule constraints, and client priority.
| Actions Required | Responsibility |
|---|---|
| Select DR Set for Analysis | PC |
| Assign TISK Number | PC with SCM |
| Create TISK Directory | SCM |
| Initiate TISK Process Checklist - annotate with TISK Number and DR #(s) | SCM |
| Place TISK Process Checklist into TISK Directory | SCM |
| Create DR Link to TISK Directory | SCM |
| Update DR Summary (drsumry.txt) | SCM |
| Assign SE Team to TISK | PC |
| Assign Lead SE for TISK | PC |
2.3.1 Cell 301: Specification and Design
The Specification and Design Cell defines and clarifies the changes
specified in the DRs.
| Actions Required | Responsibility |
|---|---|
| Clarify Requirements (Contact Client or originator of DR) | SE |
| Develop Requirements and Specifications (if required) | SE/Client/PC |
| Analyze requested changes | SE |
| Analyze side effects of changes | SE |
| Identify files that require changes | SE |
| Identify required documentation changes | SE |
| Develop preliminary design for code changes | SE |
| Develop preliminary design for new tests | IV&V |
| Update TISK Process Checklist | SE |
2.3.2 Cell 302: Generate Analysis Report
The Generate Analysis Report Cell develops the Analysis Report
(AR) for the TISK.
| Actions Required | Responsibility |
|---|---|
| Estimate resources required to implement change | SE/IV&V |
| Decide if Delphi Estimation method to be used | PC |
| Estimate risk associated with implementation of changes | SE |
| Retrieve Analysis Report template from Forms Directory | SE |
| Generate Analysis Report IAW Analysis Report Standards | SE |
| Perform informal walk-through | SE |
| File AR in TISK directory | SE |
| Notify PC when ready for AR Inspection | SE |
| Update TISK Process Checklist | SE |
2.3.3 Cell 303: SQA Analysis Report Inspection
The SQA Analysis Report Inspection Cell insures that the AR adheres
to the standards defined in the Analysis Report Standards. Metrics
information is also collected for the TISK.
| Actions Required | Responsibility |
|---|---|
| Notify SQA - ready for inspection | PC |
| Assign Inspection Team and roles | PC |
| Conduct inspection IAW SQA Plan | Inspection Team |
| Update TISK Process Checklist | SQA/SE |
2.4 Cell 400: Convene Configuration Control Board
The Convene Configuration Control Board (CCB) Cell allows the team to determine
that the TISK can proceed. The SE will brief the CCB summarizing
the impact on the software and all the resources needed to
implement the change.
| Actions Required | Responsibility |
|---|---|
| Analysis Report given to PC | SE |
| Schedule CCB IAW Management Document | PC |
| Appoint CCB Members | PC |
| Review Analysis Report | CCB Members |
| Review AR Inspection Report | CCB Members |
| Brief problem and proposed solution to CCB | SE |
| Vote on status of TISK (accept,reject,defer) | CCB Members |
| Update TISK Process Checklist | PC/SE |
A rejection of the Analysis Report can mean that the AR is
sent back for re-work or that the TISK is cancelled. To cancel
a TISK, several actions are required to undo the TISK.
The DR Summary needs to be annotated and the TISK Process Checklist
needs to be commented that the TISK was stopped. The affected DR(s)
need to be returned to the DR pool.
2.5 Cell 500: Implement Change for Code
2.5.1 Cell 501: Check Out
In the Check Out Cell, the SCM checks the code or documents
out of the configuration management system so the SE Team can implement
the approved changes.
| Actions Required | Responsibility |
|---|---|
| Notify SCM to check out code and/or documents from the CM system | PC or SE |
| Check out code and/or documents | SCM |
| Update TISK Process Checklist | SCM |
2.5.2 Cell 502: Implement Change
In the Implement Change Cell, the SE implements the changes
as defined in the Analysis Report.
| Actions Required | Responsibility |
|---|---|
| Notify SE Team of location of "checked-out" code and/or documents | SCM |
| Implement changes IAW Analysis Report and Coding guidelines | SE |
| Develop new test cases | IV&V |
| Perform informal walk-through | SE |
| Update TISK Process Checklist | SE |
2.5.3 Cell 503: Unit Test
In the Unit Test Cell, the SE Team tests the changes prior to submitting to IV&V.
| Actions Required | Responsibility |
|---|---|
| Conduct Unit Testing IAW Unit Test Standards | SE |
| Perform informal walk-thorough IAW Unit Test Standard | SE |
| Update TISK Process Checklist | SE |
2.5.4 Cell 504: Check In and Prepare for Inspection
The Check In and Prepare for Inspection Cell concludes
the implementation phase and prepares for the implementation
inspection.
| Actions Required | Responsibility |
|---|---|
| Notify SCM to check in modified code and/or documentation | SE |
| Check in modified code and/or documentation | SCM |
| Generate diff file(s) | SE |
| Generate Implementation Form | SE |
| Diff file and Implementation Form files in TISK directory | SE |
| Notify PC when ready for Implementation Inspection | SE |
| Update TISK Process Checklist | SE |
2.5.5 Cell 505: Implementation Inspection
The Implementation Inspection Cell reviews the changes for omissions,
errors, good programming practices, and adherence to the standards.
| Actions Required | Responsibility |
|---|---|
| Notify SQA - ready for inspection | PC |
| Assign Inspection Team and roles | PC |
| Conduct inspection IAW SQA Plan | Inspection Team |
| Update TISK Process Checklist | SQA/SE |
2.6 Cell 500PA: Implement Change for Product Administration
2.6.1 Cell 501PA: Check Out
In the Check Out Cell, the SCM checks files out of the configuration
management system so the SE Team can implement the proposed changes.
| Actions Required | Responsibility |
|---|---|
| Notify SCM to check out files from CM system | PC or SE |
| Check out files | SCM |
| Update TISK Process Checklist | SCM |
2.6.2 Cell 502PA: Implement Change
In the Implement Change Cell, the SE implements the changes as
defined in the Deficiency Report.
| Actions Required | Responsibility |
|---|---|
| Notify SE Team of location of "checked-out" files | SCM |
| Implement changes IAW Deficiency Report | SE |
| Perform informal walk-through | SE |
| Check in files | SCM |
| Notify PC - ready for IV&V | Lead SE |
| Update TISK Process Checklist | Lead SE |
2.7.1 Cell 601: Integration and System Testing
The IV&V group performs system testing. System testing is performed
to ensure the integrity of the overall product and to decide whether
or not a new product version is ready for release to the users. System
testing will test the software as a whole to ensure that all features
produce the desired results. Each instance of system testing will
run the complete set of system test cases, including regression testing.
Any tests created during the TISK will be run to test new features and
verify bug fixes.
| Actions Required | Responsibility |
|---|---|
| Get Read-Only version of files | IV&V/SCM |
| Perform Integration & System Testing and documentation review IAW IV&V Standards | IV&V |
| Place Incident Report Form(s) in TISK directory | IV&V |
| Place IV&V Completion Form in TISK directory | IV&V |
| Update TISK Process Checklist | IV&V |
2.7.2 Cell 602: PC Verification and Mediation
Review IV&V system testing and mediate any action that must occur as a result of testing (e.g., approve, rollback to earlier cell for rework, reject, etc.).| Actions Required | Responsibility |
|---|---|
| Report results to PC | IV&V |
| Review IV&V results and mediate any action items | PC |
| Generate CR for any newly identified defects | PC |
| Update TISK Process Checklist | IV&V/PC |
2.8.1 Cell 601PA: Integrity and Correctness Testing
The IV&V Group will review all documentation, the web sites,
all links, builds - to include downloading and 'smoke-testing',
and other aspects of the TISK as appropriate.
| Actions Required | Responsibility |
|---|---|
| Perform Integrity and Correctness Testing of changes | IV&V |
| Place copy of the IV&V Completion report in TISK directory | IV&V |
| Update TISK Process Checklist | IV&V |
2.8.2 Cell 602PA: PC Verification and Mediation
Review IV&V system testing and mediate any action that must occur as a result of testing (e.g., approve, rollback to earlier cell for rework, reject, etc.).| Actions Required | Responsibility |
|---|---|
| Report completion of testing to PC | IV&V |
| Review IV&V results and mediate any action items | PC |
| Generate CR for any newly identified defects | PC |
| Update TISK Process Checklist | IV&V/PC |
In the Wrap Up Cell, the PC reviews the TISK process.
He or she should present to the class any Lessons Learned
that might enhance the process for the next TISK. During this cell,
all members of the group should reflect on possible process improvements.
| Actions Required | Responsibility |
|---|---|
| Conduct TISK Review | PC |
| Tabulate Metrics information | Metrics |
| Update TISK Process Checklist | PC/Metrics |
| Update DR Summary (drsumry.txt) | PC |
| Have a Coke and a Smile | ALL |
After completion of a TISK the PC and Client will make a
decision whether to build a new release of the product. If a new
release is warranted, a Product Administration TISK will be initiated
to prepare and distribute the new build.