Preface

1.0 Introduction

1.1 Project Overview

1.2 Project Deliverables

2.0 Project Organization

2.1 Process Model

Since Analysis and Design were completed during the previous quarter, this quarter's process need only address implementation, testing, release, and maintenance.  Some teams may need to do detailed design before implementation.

In brief, the process goes like this:

Steps 1 - 9 must be performed in sequence.  Each step must be complete before proceeding.

1. Perform review and repair of requirements and design from 308 (SRS, design diagrams, javadocs, pseudocode).
2. Negotiate Stage 1 Delivery Plan and obtain Instructor (or customer) signoff.
3. Write or verify method headers (if necessary) for Stage 1 modules.
4. Write or verify detailed design (pseudocode) for Stage 1 modules.
5. Internal review of Stage 1 detailed design.
6. Write Stage 1 System Test Cases
7. Implement Stage 1 modules (write source code).
8. Internal Review of source code.
9. Write and run unit tests (using JUnit) and correct any unit defects.
10. Integrate Stage 1 modules, performing a daily build.
11. Write and Run integration tests and track and repair any integration defects.
12. Develop automated System Test Scripts for Stage 1 as appropriate.
13. Run System Tests (manual and/or automated) and track and repair any defects.
14. Release Stage 1 software when release criteria are met.

1. Formal white box unit test cases are documented (Basis Path tests).
2. Unit tests are written (as JUnit tests) BEFORE modules are implemented.
3. Public method javadoc comments include DBC or Error Checking comments.
   
4. Formal Code Inspections instead of Internal Reviews.
5. Coverage Testing

2.1.1 Staged Delivery Plan

If a feature is going to be partially implemented, you need to describe the character of the functionality you plan to implement. One of the most common sources of confusion on student projects is uncertainty about whether a certain feature is supposed to be working yet. It is the job of this document, along with the Integration Plan, to eliminate that confusion.

Staged Delivery is discussed throughout the text and a simplistic example is shown on page 165.  An example Staged Delivery Plan from a student project is available.  The Staged Delivery Plan is maintained by the analyst.

2.2 Organizational Structure

2.3 Organizational Boundaries and Interfaces

• The Analyst is the liaison with the Customer. (If there is no real Customer, the instructor may play this role).
• The Team Manager reports to upper management (Course Instructor).

2.4 Project Responsibilities

3.0 Managerial Process

3.1 Management Objectives and Priorities

1. Carry out this project plan.
2. There must be quantitative estimating, monitoring and controlling of the development process. Quantitative indicators of progress for cost, schedule, scope, and quality must be tracked and publicized on the team web page.
3. Equitable distribution of work.  All team members must share equally in all project tasks.  In particular, System Test Scripts, module designs and implementation, and Unit Tests must be divided into clearly identifiable work units that are assigned to specific individuals.

Since this project has a fixed schedule (the ten week quarter) Management's first priority must be to assure that the work is completed on time.  Quality is next priority as it most directly represents student learning.  When necessary, functionality must be sacrificed in order to meet the first two priorities.

Management should be on guard for the tendency of students to "gold plate" their work products with superficial "flash" such as clip art, graphics, or animation.  Insist on clean, neat, organized work, but beyond that put effort into technical content and not cosmetic appearance.

Management should try to offer opportunities for all students to learn a variety of software engineering skills.  Don't simply assign the most qualified student to a task.  Consider assigning students to unfamiliar tasks from which they could benefit.

3.2 Assumptions, Dependencies, and Constraints

3.3 Risk Management

How to Identify and Retire Risks

1. Each team member spends 10 minutes exploring his or her greatest fears for the project’s success.
2. Each member specifies these risks in concrete language, weights them, writes suggestions for how to mitigate or retire the risk and e-mails to the risk manager.
3. Risk manager integrates risks from team and performs calculations of risk priorities and creates a draft Risks List.
4. Group spends 10 minutes reviewing Risks List, seeking additional risks and proposing other retirement plans.
5. Team spends 10 minutes finalizing the Risks List and designates responsible risk retirement engineers for each item.
6. The risk manager and posts the Risks List on the team web page.
7. Responsible engineers do risk retirement work.
8. Team reviews risks for 10 minutes at weekly meetings. Responsible engineers report progress. Team discusses newly perceived risks and adds them to risks list.

3.4 Monitoring and Controlling Mechanisms

3.4.1 Team Meetings

Whenever the team (or part of the team) meets, a formal status meeting agenda is to be followed. This includes both scheduled lab periods and also outside of class meetings. The status meeting is NOT a problem solving session, it is a concise progress reporting meeting. It should take only 15 - 20 minutes. The meeting format is:

a) Report on tasks assigned at previous meeting

1.  Accomplishments
2.  Unfinished tasks

b) Identify problems encountered/solved (but don't discuss).

c) Compare estimated vs. actual progress data. Revise or update schedule, if necessary.

d) Risks discussion (see Risk Management Plan) (10 min/week)
e) Assign tasks (action items) for next period.

When the status meeting is finished, the team can proceed to their "working" meeting to discuss technical issues, solve problems, coordinate tasks, and carry out portions of the technical work that can not be done individually.  Also the Change Board should meet to consider submitted change requests.
 

3.4.2 Required Reports

Team Home Page

Make a copy of the team home page template and install it on your team account.  You may supply your own team logo, but do not waste any time with further cosmetic customizations.  The home page template provides links to many other project document templates which do require customizing.  Follow the italicized directions to tailor the templates for your team/project.

• Each developer's tasks will be tracked using the Trac ticket system.  You should track every task that takes longer to complete than 15 minutes.  It is essential that the ticket descriptions be complete, clear, and detailed.  If there isn't a ticket for a task, then as far as the instructor knows, you didn't do it.
• You should add two custom fields to your Trac tickets. Add a Due Date field and a Status field (with status codes as shown in the Action Item Template). Only one person on the team has the necessary privileges to login to a shell on wiki.csc.calpoly.edu and change the trac.ini file.

• Each team manager may require a weekly status report. The status report is where each individual documents their accomplishments for the week. It includes a timecard of hours spent and what activity they were engaged in.
• Follow the Status Report Template.

• The Progress Report is a summary of the team's progress for review by external stakeholders. Produced weekly, by project manager, submitted electronically to instructor posted to team web page by 5pm on Monday.  Use as a subject line: Progress Report: team name
  
• Follow the Progress Report Template.
• In a separate message, forward all the individual status reports (including your own). Use as a subject line: Status Reports: team name

• Use a bound "composition book" for the journal.  You can purchase one at the bookstore, they have a black and white speckled cover and a black binding.  Do not use a three ring binder or spiral binder. Record all entries chronologically and leave no blank pages. You must write legibly as the instructor will be reviewing your journal on a weekly basis.
• The purpose of the journal is to document the process the team went through in creating their product. It is a record of all team activities. It can be maintained by the manager or by a designated recorder.  See Ch 14 pg 209.
• The journal contains the complete minutes from every status meeting (see format above).  Be sure to record all action items assigned and their priority. See these sample meeting notes.
• Be sure to document significant management and technical decisions made during the meeting.
• Document problems encountered, alternate solutions proposed, pros and cons, action plans, and results.
• Alternatively you may choose to post meeting notes on the team web site; ask instructor for approval.
  

3.4.3 Project Visibility

3.4.4 Current Action Items

3.5 Staffing Plan

3.6 Training Plan

4.0 Technical Process

4.1 Methods, Tools, and Techniques

4.1.1 Tools
Each team is required to complete this table with a tool in each category ("none" might be OK) and have this list approved by their instructor.   The Resources page has more tool suggestions.
If the tool is already filled in, a team will need to argue persuasively if they want to change it.

4.1.2 Email Standards

Occasionally the instructor will mail announcements to the entire class by using an alias which sends mail to your OracleMail account. If you don't use OracleMail regularly, you should setup your OracleMail account to forward your mail to your regular email account.

It is recommended that you use the Computer Science department machine "falcon" or Central Unix or OracleMail as your primary email account. 

The instructor will not read email whose "Sender" field is not an actual student name. Don't use nicknames in mail you send to the instructor or it will be returned to you unread.

In general, do not send attachments to the instructor.  Instead, put all your correspondence in the message body.

If the instructor is playing the role of customer for your team, any email intended for the customer must have "To Customer" in the Subject line.

4.3 Project Support Functions

4.3.1 Quality Assurance Plan

4.3.2 Change Control Plan

The Change Manager is responsible for customizing the Change Control Plan for your project. Read McConnell Chapter 6 and Pressman Chapter 9. Some basic strategies are outlined in Change Control Considerations.  You need to list all the work products you intend to place under change control (see list in table 6-1). Then for each work product, specify the procedures which will control changes to the document.

For source code control the team will use CVS on Falcon.  See the course resources page for directions on setup and use.

During Stage 2 the source code repository must maintain at least two branches: one for new development towards the next release and one for repairs on the current release.  The branches are merged during integration testing for the new release. (See Branch and Merge Tutorial).

At some point during Stage 2 your team will be asked to demonstrate that your team is using both branches appropriately.  At some random time during lab the instructor will check these items:

•  The cvs admin must show that the repository is indeed branched.
•  The web page for source code control includes directions to developers about how to use both branches of the repository.
•  A randomly selected developer will be asked to demonstrate making a fix to a stage 1 module in one branch of cvs, and making an enhancement to the same module in the stage 2 branch to verify they are indeed separate branches.
•  The daily build procedure web page has been modified to show how TWO builds are done, one in each branch. (Implementation Manager's job).
•  The daily build report shows BOTH build reports.
•  There is a link to download BOTH builds on the team home page.
•  The implementation manager will be asked to do a build on the spot and then a randomly selected developer will be asked to run each build and highlight the differences.

5.0 Schedule and Budget

5.2 Schedule

5.2.2 Detailed Schedule

How "detailed" should the detailed schedule be?  It doesn't need to show individual action items; those appear in the Current Action Items list. It should show every task that requires the coordination of efforts of two or more people.  There are enough tasks in the project that the detailed schedule should probably show something due every day of the quarter. 

The schedule should be extremely detailed for the immediate future (e.g., two weeks) and may be less detailed for the distant future.

5.2.2 Integration Plan

5.3 Budget

The major tasks for which you should estimate effort are:

• Developing New Product Features
• Correcting Defects
• Writing System Test Scripts
• Writing Unit Tests

Budget Computation

In order to maintain product quality at a level that will meet the Release Criteria and stay within budget you may have to be selective about product Scope, which is dictated in your Staged Delivery Plan.  Bonus points will be awarded to teams that stay within their allocated budget.
 

Estimating new development costs

To estimate the cost of new development, divide the total lines of code by your team productivity rate.
For example, 350 LOC / 15 LOC/hr = 23 hours.

Your team productivity rate is determined from your historical data on Stage 1 (dividing total LOC by total implementation hours).  If that is not available, use a number between 10 and 20 LOC/hr.

You may need to update your estimates several times as you gather more accurate productivity data.  Include a link to all previous estimates.
 

Estimating testing and maintenance costs

In a similar manner, estimate maintenance costs.  You may not have reliable historical data upon which to base your estimates.  In that case, use a productivity rate of 1 hour per defect.

In order to predict how many defects you will have to repair, consult your project history data from Stage 1 or use a figure consistent with industry standard of 50-100 defects per KLOC.
 

Budget Summary Table

Place a summary table like this one as well as all the above computations on your team web page.
 

Release 2 Recalibration

Revision Chart

The above template is based on IEEE 1058.1-1987.
This material is copied and/or adapted from the Survival Guide Website at www.construx.com/survivalguide/. This material is copyright © 1993-1998 Steven C. McConnell. Permission is hereby given to copy, adapt, and distribute this material as long as this notice is included on all such materials and the materials are not sold, licensed, or otherwise distributed for commercial gain.