GENERIC

MANAGEMENT DOCUMENT

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.

ABSTRACT

This document is the Management Document for the Software Engineering graduate program of the University of West Florida (UWF). It is intended to incorporate management level items not found in other documents and to serve as single reference point for all documents.

TABLE OF CONTENTS

LIST OF FIGURES

1.0 INTRODUCTION

1.1 GENERIC PROCESS HISTORY

In lieu of a thesis, Software Engineering graduate students may elect to take a group project in partial fulfillment of degree requirements for the UWF Masters of Science degree in Computer Science-Software Engineering option. It is the desire of the UWF Computer Science Department to introduce important process concepts into the academic curriculum.

To this end, students were introduced to process concepts during a software engineering management class. To facilitate ease of learning process concepts, the students of the UWF-Fort Walton Beach summer 1994 management class developed an initial process to be used in a follow-on project class. The process was designed specifically for use with a project (in this case, Recon) developed over several years by the students of the UWF-FWB campus. This process was then modified over the course of the project.

This initial process has been used as a basic outline for this generic process. The generic process is intended for use by any UWF project class maintaining existing software.

The generic process is divided into the following documents:

1.2 PROJECT DEVELOPMENT PLANS

It is recommended that all projects have a top-level development plan. This plan should take into account many key factors, to include class project goals, team strengths and weaknesses, and current client wants/needs. The plan should include proposed fixes (based on goals), release dates of the project, and any other important general overview information. The project development plan becomes your contract with the client as to what you plan to accomplish. This plan needs to be developed by the PC in conjunction with the client as soon as possible to start providing direction to the team.


1.3 PROJECT GOALS

Every project should have goals to strive for. It has been said, "if you don't know where you are going, how will you know when you get there?" Goals help you define where you are going with the project. Your goals will define what deficiencies you decide to fix (as outlined in the development plan) and the relative priorities you set on the deficiencies. It is recommended you state a definite and measurable completion criteria for each goal. The goal "improve quality" is vague and you will never know when you have truly attained this goal. This goal is better stated "reduce the number of deficiencies found per inspection by 25% by the end of the semester." For an example of a previous projects' goals, please see Appendix B, paragraph 2.0.

1.4 PROJECT QUALITY ISSUES

It is always desired to produce a high quality product that will not only meet the needs of your users, but also exhibit other positive software engineering principles. Several quality issues you may want to address are as follows:

Your team should determine if these quality issues, or others, should be included in your goals. At the very least, these quality issues should provide general guidance for your organization in establishing priorities. The nature of each proposed modification should be balanced against these issues when deciding what tasks to undertake.

2.0 ORGANIZATION

2.1 ORGANIZATION STRUCTURE

The project is an academic endeavor. Due to limitations on class size and time constraints, certain artificialities are induced in the organization and operation of the project.

The suggested primary organization for the project team is outlined in figure 1. This assumes a class size of 22 students. Numbers in parenthesis indicate the number of members desired for the group. This structure should be used while running a TISK through the software maintenance process. [NOTE: A TISK is one cycle in the software improvement process. It may involve one or more deficiency reports which are grouped together for that particular modification to the product. The PC shall consider the team approved goals and development plans when planning TISKs.]

The summary below attempts to outline the major responsibilities of each portion of the organization during TISK processing. All project team members will also need to review the Process Architecture document and their corresponding functional documents for specific information on duties. It is recommended that each member become intimately familiar with the sections in this material that pertains to their individual area of responsibility and generally familiar with the other roles.

There are many functions which will need to be performed between TISKs to maintain or modify the process itself. These functions include such items as updating training units, modifying standards, changing process documents such as this one, etc. The spectrum of possible duties precludes assigning one of the above groups to each possibility. Each member of the organization must realize that their duty title applies to TISK processing, and may not reflect what they are required to do during process improvement activity between TISKs. The Project Coordinator (with input and assistance of all team members) is ultimately responsible for determining what jobs need to be performed before the next TISK cycle and assigning those duties as required.

Professor/Client - Serve as the 'client' during the project. He/she will provide external change requests and clarify user requirements. During requirements elicitation, the 'client' provides clarification to the SE.

Project Coordinator (PC) - The PC will serve as the godfather (gender neutral term, of course!) of the software maintenance process. The PC is ultimately responsible for insuring the project proceeds in a orderly fashion. His/Her duties will include (but are not limited to!):

• Serve as primary point of contact for the team to 'client'.
• Schedule/organize training as necessary during the project (see Training Plan for details).
• Provide SCM with an authorization list for Version Control Tool (VCT) controlled files.
• Lead all meetings; selecting facilitator, recorder, critic, etc. (IAW "Software Teams" by Mark Rettig, Appendix F). These responsibilities may be rotated within the organization at the discretion of the PC.
• Identify a scribe for each meeting, and coordinate dissemination of minutes to all class members documenting the proceeding, decisions, and action items of each class meeting.
• Perform all PC specific duties identified in the Process Architecture document and other process documents.
• Receive, process, and maintain all change requests IAW Process Architecture procedures.
• Monitor progress of TISKs by reviewing the 'TISK Process Checklist' (see Appendix B) for each active TISK at least once a week. An electronic checklist for each TISK should be placed in the TISK's directory.
• Chair the CCB.
• Assigns inspection teams.
• Receive/review all reports.
• Conduct additional debriefings as necessary to determine if the process needs to be changed between TISKs. If an adjustment is required, work with the SEPG expert to develop and implement process changes prior to the next TISK.
• The PC shall have the final say in determining which change requests (CR) and deficiency reports (DR) are handled by the team.
• Approve all variance reports.
• 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.).
• Serve as the single point of contact for the Delphi estimation documents dissemination and collection. Conduct the balloting process for each round of Delphi estimation.
• Leap tall buildings in a single bound. Running start is allowed.

IV&V - Perform integration and system level testing of the completed product as intended for delivery to the customers. Perform Integrity and correctness testing for Product Administration TISKs. Provide at least one representative to serve on each Delphi estimation team.

METRICS - Collect and review timecards weekly from project members. Maintain timecard data on the UWF system. Be the sole collector, maintainer, and analyzer of any and all metric data. Serve as SCM backup when necessary.

SQA - Monitor software maintenance process to ensure all standards are correctly being applied. Serve as moderator for inspections. Report all findings to PC. Ensure that the TISK Process Checklist is kept up to date. Serve as Documentation Engineer backup when necessary.

SEPG - Work with PC to develop and implement changes in the process itself. Provides guidance on the process.

SCM - Manage the product to ensure proper CM control of all items. Responsible for change control. Manages use of VCT. Maintains configuration management policies. Prepares back-ups of controlled directories. Prepares product for release. Serve as Metrics backup when necessary.

Software Engineer Leads - Responsible for management functions during a TISK Cycle. Attend all meetings, including inspections for all TISKs. Work directly with the PC to ensure that schedules are being met. Work directly with other SE Leads to ensure that work is not being duplicated between TISKs. Work directly with SEPG and SQA to ensure that the process is being followed. The Software Engineer Lead should work only in a managerial role and should not participate in any hands-on modifications to the code.

Software Engineers - Responsible for the actual modifications to the product source code. Perform unit testing and other testing as appropriate. Serve as peer advisors to one another for walk-throughs. Provide at least two representatives to serve on each Delphi estimation team.

Documentation Engineer - Complete understanding and structure knowledge of all software documentation in existence, documentation in progress, and any recorded document change suggestions. Perform all the document modifications in accordance with the approved AR for each TISK. Serve as SQA backup when necessary.

2.1.2 CCB procedures

The CCB will be comprised of the 'client', Project Coordinator, and one member from each of the following IV&V, SQA, SEPG, SCM, and Software Engineers. At his/her discretion, the PC may elect to appoint additional members as required. The CCB will be chaired by the PC, with the 'client' serving as a facilitator and referee in the case of actual fisticuffs. Details on the CCB process are as follows:

2.1.2.1 Overview

The CCB shall decide what deficiency or set of deficiencies will be worked by the Software Engineers to fix and or enhance the software. The CCB is needed to ensure that every change is properly considered by all parties and that every change is authorized and coordinated before implementation.

2.1.2.2 Resources

The CCB needs the Analysis Report summarizing the impact to the software and all the resources needed to implement the change.

2.1.2.3 Decision criteria

The CCB should consider the following items if applicable:

• Benefit of change versus expected cost
• Scheduling conflicts (files to be changed/used)
• Level of design (based on SE brief)
• Alternative Solutions
• Analysis of risk
• Appropriateness of solution
• Relationship to other changes

2.1.2.4 Waiver of the CCB

The CCB process should never be waived except in extreme circumstance to be determined by the PC, SCM, the client, and the SQA.

2.1.2.5 CCB process

1. The PC will schedule a CCB upon receipt of an Analysis Report.

2. The PC will appoint the board members.

3. All members will review the deficiency or set of deficiencies and the corresponding Analysis Report.

4. The meeting will be run IAW "Software Teams" by Marc Rettig.

5. The SE's will briefly outline the problem and proposed solution and will answer any questions from other CCB members.

6. The decision to accept, reject or defer will be reached by majority vote on each deficiency or set of deficiencies. Each member has an equal vote except for the PC who will not vote except in the case of a tie.

7. The PC will take the action required to implement the decision.

Once an overall development plan and team goals have been decided, a detailed project schedule can be generated. It is expected this schedule will change over time as new TISKs are started, current TISKs run into delays (yes, Virginia, this will happen), and other TISKs are completed. A detailed TISK schedule will be included in the TISK's analysis report. Each TISK's schedule should be compared against the current schedule and checked for sanity (e.g., is the SE trying to complete the TISK in 10 weeks with only seven left?). If the CCB approves the TISK for implementation, the PC should update the schedule to include the new TISK's schedule.

The project schedule should represent anticipated start and end dates for the major process cells (as depicted in the Universal Model in the PA doc.) as well as real world items such as holidays. Remember to keep in mind work load of members (most have full-time careers and possibly other classes) and other class duties (e.g., papers) when determining schedules.

It is recommended that the Delphi Estimation Process be used when planning TISK completion dates.

3.0 MANAGEMENT ITEMS

3.1 GENERAL POLICIES

The following guidelines are given for running an effective project. Adherence to these policies will allow the team to function in the most productive fashion. As a minimum, the following policies are recommended:

• Team members will read the discussion log daily.
• Team members will attempt to be present at all meetings. If unable to attend, you must coordinate the absence ahead of time with the PC and are responsible for catching up on any missed items.
• Team members will log time spent on project development on timecards. These should include the activity performed and duration, and will be used as a metric to check the process and estimation capabilities. Timecards will be turned in to the Metrics guru weekly.

3.2 DISTRIBUTION/MARKETING PLAN

It is recommended a very liberal distribution policy be adopted. Making your product available to any individual, group, and/or organization will not only enhance the reputation of UWF, but of those students involved.

The following should be distributed with every version of the product:

• All source code.
• All documentation.

The preferred distribution media is the Internet. Use of the Internet best insures the widest possible distribution of your product to a number of sites worldwide. For those few not having access to the Internet, 3.5" PC formatted disks can be supplied upon request.

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, procedures in the SCM document will be followed to build a new baseline for release.

3.3 GENERIC PROCESS QUESTIONS

If you have questions concerning the development of the generic process, or the process architecture in general, please contact:

REVISION HISTORY

APPENDIX A - GLOSSARY

APPENDIX B - RECON SPECIFIC PARAGRAPHS

1.0 HISTORY OF RECON

Recon is a tool for 'software reconnaissance', that is, for finding where program features and functions are implemented in source code. You are directed to several articles on Recon and software reconnaissance which are available from Dr. Norman Wilde (see paragraph 3.3). All Recon team members should read the documentation for Recon found on the UWF-Fort Walton Beach Campus UNIX system. The files include the Readme, Overview and User manuals. This documentation provides a general understanding of Recon and its function.

2.0 PROJECT GOALS

The goals for Recon software development are:

1. To produce and distribute innovative software engineering tools of high quality that will have wide acceptance among software professionals. [Target: Increase Recon customer base by 25% a semester.]

2. To allow organization members to acquire documented expertise in the practical application of Software Engineering techniques that can help them achieve career goals. [Target: All organization members will be credited in Recon documentation distributed to customers.]

3. To strengthen the reputation of the University of West Florida Masters Degree in Software Engineering and of its graduates. [Target: One article published per semester concerning either Recon or a related topic.]