Project plan

toaststicksrifleΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 4 μέρες)

312 εμφανίσεις

Project plan

Preface

This document describes the plan for executing the Marker Software Gradebook.

1.0 Introduction

1.1 Project Overview

The purpose of the lab component of the course is to apply software engineering methods to
carrying out a software
development project. During CSC 309 we will do the implementation,
testing, and perform two releases of the system and then perform subsequent maintenance on the
released product.

1.2 Project Deliverables

1.2.1 CPE 309



Integration Plan (Implementation M
gr)



Source code for the finished application, documented according to the
class coding
standard
. Checkstyle reports 0 errors and warnings. Each student must contribute some
signific
ant portion of the source code. Use @author tags to identify code ownership. The
source code exists in the Subversion repository as a
NetBeans?

project.

Written
system test

case documentation including test case matrix (online).


The tests must be
evenly assigned to all developers.


Automated Unit Tests. Passing JUnit test
s for all non
-
gui classes along with test scaffolding that
exercises the target class in isolation. Each team member writes the Fakes and JUnit tests for
their class, and the QA or Test manager writes a shell script (optionally, Ant script) that runs all
t
he unit tests.

Demo: Checkout source repository, navigate to "tests" folder, run the unit test shell or Ant script
that runs the JUnit tests. The console user interface is tested with a script that redirects test
keystrokes from a data file.

Post on team
web site: A written set of directions for what actions the human tester should
manually perform on the GUI, and the expected output from the Fake underneath it. (Optionally,
write a Costello script for automated GUI testing).


An integration testing shell

script that demonstrate 95% statement coverage using Emma or other
coverage tool. Each person converts their unit test script into an integration test. For lowest level
classes, the unit test is the integration test. For intermediate level classes, replac
e the lower fakes
with the real classes and change the oracle to expect real output. May still require fake UI. For
the top level (application class) run with no fakes and a console ui. Use input data from a file
(redirection). Oracle expects real output.
The GUI can be tested separately as it will require
manual input and a written test plan with expected output. Coverage testing is not required for
GUI classes.


Daily build
script

(using Ant) that includes Checkstyle, Javadoc, and optionally LOC count, test
coverage, etc.. Daily build
reports

are updated after each build. (Implementation Mgr)


Dep
loyment script (may be integrated with daily build script) (Implementation Mgr)


Released product that passes all System Tests and customer Acceptance Test.


This
deliverables reso
urce page

has required document formats and quality standards.

2.0 Project Organization

2.1 Process Model

2.1.1 CPE 309

The process model to be followed by student teams
during CPE 309
is the
Staged Delivery
Model

explained in
Software Project Survival G
uide


by Steve McConnell.


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.


Process Diagram

(PDF)

Our Process:


1.

Perform review and repair of requirements and design from 308 (SRS/prototype, design
diagrams, javadocs, pseudocode,system

tests).

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 des
ign
for Stage 1 modules.

5.

Internal review / walkthrough of Stage 1 detailed design.

6.

(Recommended) Create an "executing architecture."

7.

Write Stage 1 System Test Cases

8.

Write unit (isolation) testing scaffolding.

9.

Implement Stage 1 modules (write but do not te
st source code).

10.

Internal Review (Stage 1) or Code Inspection (Stage 2) of source code.

11.

R
un unit tests (isolation tests) and correct any unit defects.

12.

Write integration tests.

13.

Integrate Stage 1 modules during lab, following Integration Plan, track defects.



14.

Run integration tests and track and repair any integration defects.

15.

Develop automated System Test Scripts for Stage 1 as appropriate.

16.

Run System Tests (manual and/or automated) and track and repair any defects.

17.

Release Stage 1 software when release crit
eria are met.

18.

Acceptance Testing by Customer

Repeat for Stage 2 with these additional steps:


1.

Formal white box unit test cases (Basis Path tests) are documented .

2.

Formal Code Inspections instead of Internal Reviews.

In parallel with the above Stage 2 tasks

the team must also:


Repair defects in Stage 1, respond to customer change requests in Stage 1, and release Stage 1
updates.

2.2 Organizational Structure

Our team consists of 5

students.


We are using the Controlled Decentralized

internal
management struc
ture.
The team has a defined leader who coordinates activities and secondary
leaders that have responsibilities for certain deliverables. (learn more about
team structures
.)



2.3 Organizational Boundaries and Interfaces



The Analyst is the liaison with the Customer.



The Team Manager reports to upper management (Course Instructor).

2.4 Project Responsibilities

The major responsibilities shown in the
Job Descriptions

are divided among the team members
so that each student has a significant role.


In CPE 309 each student
has

a
different role

than they
performed in CPE 308.



3.0 Managerial Process

3.1 Manage
ment Objectives and Priorities

3.1.1 Objectives

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
t
racked 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 ident
ifiable work units that are assigned to specific
individuals.

3.1.2 Priorities


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

The schedule is fixed.


All work must be submitt
ed by the last class meeting.

The budget (student hours worked) is not unlimited.


Assume 9
-
12 hours per week per student
outside of class.

Assume the customer will reply to e
-
mail or return phone calls once a day.

Don't assume that work can be complete
d on student home computers.


There may be certain
equipment or software that is only available in the campus computing labs.

3.3 Risk Management

One person on the team will be identified as the Risk Manager.


It is his/her duty to lead the team
through t
he following Risk Management procedures. The Risk Manager's responsibilities are
further explained in Stiller Chapter 9.7
-

9.10.

How to Identify and Retire Risks

1.

Each team member spends 10 minutes exploring his or her g
reatest fears for the project’
s
su
ccess.

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 propos
ing
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 Controlli
ng Mechanisms

This section explains how project cost, schedule, quality, and functionality will be tracked
throughout the project.

3.4.1 Team Meetings

The team will meet during regularly scheduled lab periods to organize and coordinate activities.


Effec
tive groups should find the designated lab time to be adequate for team meetings.


Smaller
working groups may meet outside of class to accomplish specific technical tasks.

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) Repo
rt on tasks assigned at previous meeting

1.


Accomplishments

2.


Unfinished tasks

b) Problems encountered/solved.

c) Revise or update schedule, if necessary.


d) Assign tasks (action items) for next period and create Trac tickets.

The manager (or whoever is le
ading the meeting) is to document the status meeting by recording
all the above items in the project journal (see Reporting Plan, below). Also record if anyone was
absent, excused, or tardy.

When the status meeting is finished, the team can proceed to the
ir "working" meeting to discuss
technical issues, solve problems, coordinate tasks, and carry out portions of the technical work
that can not be done individually.

3.4.2 Project Visibility


Team Home Page


The
team home page

is the primary place where the current team status will be made visible to
project stakeholders.


It is the team manager's responsibility to see that the home page status
indicators are kept updated on
a weekly basis.


Action items and similar timely information will
need to be updated daily.
Follow the directions on this page of
visibility calculations
.





Trac tickets
and time logging




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.


If it takes longer than 2 hours it
should be decomposed into multiple tickets. It is essenti
al 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.



Each developer will log all time spent on the project using the
Time Accounting Process
.


Individual Status Reports




The status report is where each person documents their accomplishments for the week. It
includes a time log of hours spent and what activity they were engaged i
n. Submitted
every week (Suggested Due: Monday 8:00 a.m.). Submitted to quality assurance (see QA
plan) and to the team leader. (Electronic submission is fine).



Follow the
Stat
us Report Template
.



If developers use Trac effectively, the manager may find that the Trac Timeline feature is
an adequate substitute for status reports.

Progress Reports




The Progress Report is a summary of the team's progress for review by external
stak
eholders. Produced weekly, by project manager, submitted electronically to instructor

b
y 9am on Monday.


Use as a subject line:
Progress Report:
team name



Follow the
Progress

Report Template
.

Project Journal




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.



The journal c
ontains the complete minutes from every status meeting (see format above).


Be sure all action items have a Trac ticket created. See these
sample meeting notes.




Be su
re to document significant management and technical decisions made during the
meeting.



Document problems encountered, alternate solutions proposed, pros and cons, action
plans, and results.



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.



You may negotiate any alternate format for the Project Journal
--

see the instructor.

3.5 Staffing Plan

The "staff" for this project are the student team members.


It is assumed the students have met
the course prerequisite
s.


Specific names and roles are shown on the team home page.


3.5.1 Nametags

Team nametags must be worn at our weekly team meetings.


3.6 Training Plan

(insert link to our training plan)

4.0 Technical Process

4.1 Methods, Tools, and Techniques

4.1.1 Team

Tool List

Each team is required to specify a tool in each category ("none" might be OK) and have this list
approved by their lab instructor.


If the tool is already filled in, a team will need to argue
persuasively if they want to change it.







Catego
ry


Tool


Notes


Project Tracking

Trac

Home page template
.

Class Skeletons

Javadoc




Design by Contract
(DBC
teams only)


Javadoc

or
Java asserts

and a strong human specification enforcer


Analysis Model
Drawing

Violet or Visio



Java Integrated
Development
Environment




NetBeans

The software must build and execute using NetBeans
on the CSL lab machines running Linux.

Development
can be done on personal computers.

User Interface
prototyping

paper &
pencil, HTML,

Netbeans GUI
builder

Prototype

Metrics




Refer to QA plan to see what metrics we must gather.



TimeLogger

is recommended for time recording

Project Schedule



ASCII table

Optional: Fedora "Planner" is installed on lab machines
under "Applications
-
> Office
-
> Project Management".

Also,
GanttProject

or
Gnome Planner
. Use Microsoft
Project only if you have a trained teammember.


Class Diagram drawing


team choice

Tools can draw clean diagrams and some can generate
code from UML.



Suggestions:


Violet, ArgoUML, NetBeans UML
module

HTML WYSIWYG
edi
tor



team choice

Mozilla Composer Recommended.Must be viewable in
Mozilla 1.4, IE 5.0 browsers.
Don't use Microsoft
word to generate HTML
2
.





Unit/Integration
Testing

JUnit

HttpUnit

Also unix shell scripting language, or
Ant


Coverage Measurement

Emma


Others: Brian McCain's
CT
, or
Clover

System/GUI Testing

Costello


Selenium

Co
stello is used for desktop apps.

Selenium for web apps (browser
-
based).

Also unix shell scripting language.

SwingRobot

may be useful in some situations.

Defect Report
ing /
Tracking


Trac


Source code control


Subversion


Tortoise CVS/SVN on Windows

RapidSVN On Linux.

NetBeans Integrated SVN on all systems

Build tool

Ant


Source code formatter

NetBeans
formatter

Astyle

is a quick stand
-
alone tool.

Code Standard Checker

CheckStyle

Here's the configuration file

for our course:
308style.xml


Here are the custom checks for our course:


308checks.jar


Web Serv
er

Tomcat

Available in instructor account.

Database

SQLite

or
MySQL

SQLite is vailable on CSL lab machines.

A decision needs to be made soon on which database.





2
Prohibited tools
:


Microsoft Word, Rational Rose.

(Any work product submitted as a Microsoft
Word document will receive a zero, unless pre
-
approved by instructor.)




4.1.2 Email Standards


Occasionally the instructor will mail announcements to the entire class by using an alias which
sends mail to your

Cal Poly mail account. If you don't use Cal Poly mail regularly, you should
setup your account to forward your mail to your regular 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, an
y email intended for the
customer must have "To Customer" in the Subject line.

4.3 Project Support Functions

4.3.1 Quality Assurance Plan

The QA manager is responsible for executing the
Software Quality Assurance Plan

(SQAP).


4.3.2 Change Control Plan

(309)

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 t
o 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 Subversion, integrated with Trac.

During Stage 2 the source cod
e 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 ch
eck these
items:




"Browse Source" 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 svn, 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 build
s 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 the
n a randomly
selected developer will be asked to run each build and highlight the differences.


5.0 Work Packages, Schedule, and Budget

5.1 Work Breakdown

A work breakdown statement (WBS) is a categorized list of tasks with an estimate of resources
requir
ed to complete the task.



Sample Work Breakdown Statement


5.2 Schedule

5.2.2 Detailed Schedule

Each team maintains a
detailed schedule

as a separate document linked from their home page.
The schedule is a chronological table showing due dates for all the milestones for the entire
project.


As a general starting point refer to the course s
chedule on the course home page.


Then
read
Table 5
-
1 to see a good set of milestones from which you can select the ones relevant to
your project. Then add in the details for the activities for the current stage. That is, schedule all
the team meetings for

this stage and specify what tasks should be completed on each of those
dates.


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 (e.g., day to day) for
the immediate future (e.g., two
weeks) and may be less detailed (lab to lab) for the distant future.

5.2.3 Integration Plan

The
Integration Plan

is maintained and administered by
the Implementation Manager.

5.3 Budget

A major management objective for CPE 309 is to have all schedules be driven by quantitative
cost estimates.


Perform the estimates below and show all calculations on your team web page.

The major tasks for which you

should estimate effort are:



Writing Source Code



Unit and Integration Testing



System Testing



Maintenance (defects found by customer)

The manager will have to determine how resources should be allocated among these different
taks. Consult the project deli
verables (sec 1.2) and process model (sec 2.1) for sources of other
significant tasks. Use your best judgement to include effort estimates for these tasks.



Budget Computation

Find the total of

(Programmer 1's available hours / week) +

(Programmer 2's a
vailable hours / week) +

...

(Programmer n's available hours / week).

Multiply by 10 weeks to find the total hours available in your budget for the project.

In order to maintain product quality at a level that will meet the Release Criteria and stay wi
thin
budget you may have to be selective about product Scope, which is dictated in your Staged
Delivery Plan.




Estimating new development costs

You may use an estimation procedure similar to what you used in CSc 308.


However, now you
have detailed desi
gns on which to base your LOC estimates, so your estimates should be more
accurate.


Create a table showing the names of all the new methods to be developed.


For each one make an
estimate of its size as lines of code.


(This table is the beginning of the
Integration Plan
).

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 ho
urs.

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 the costs for writing system and unit tests.


You may not have
reliable historical data upo
n which to base your estimates.


In that case, use a productivity rate of
1.5 hour per System Test Script and 2 hours per class Unit test.

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 KL
OC.




Budget Summary Table

Stage

Activity

Est Hours

Actual Hours

Stage 1





System Testing

25




Unit Testing

35




Implementation

30



Defect Repair

25



other tasks ...



Stage 2







System Testing

15



Unit Testing

25




Implementation

2
0



Inspections


10



Defect Repair

20



other tasks ...






TOTAL

n



Available hours

x


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





Release 2 Recalibration

Project estimates are recalibrated

at the end of Release 1 and posted on the team web site. (See
pg 239).

5.5 Schedule

Each team maintains a detailed schedule as a separate document linked to from their home page.


Refer to the textbook to find out what a schedule should contain. As a gen
eral starting point refer
to the course schedule on the course home page.


Importantly, each team must decide the date each major deliverable is due.


Once they commit to
these dates, there will be significant penalty for late submission.


Estimation Process