Project Plan Regrade
Team: Jestre (finally!)
Grade: (95 out of 100)
The following is a breakdown of the grading.
Document presentation (10/10 pts)
Important points:
- Organization - OK, but you need to show the history of versions
of documents clearly in the notebook. Also, please put a link to your
current project schedule in your notebook.
- Name/logo - OK
- Document author - OK
- project team members/roles - OK
- use of English
Desirable features:
Comments: Why such a nice graphic at the bottom of pages and such a
cheesy looking logo? :)
Project Description (18/20 pts)
Important points:
- length (approx one page) I previously suggested that you include
links to other information sources in the project description, such as
the information that Ian Smith provided in the
copious documentation and rationale he provided you at the beginning
of the project. You haven't done that, so I took a couple points off.
- clarity (use of English) - good
- specificity (Can I tell what you are going to do?) OK
Comments:
Important points:
- clarity (Can I interpret the table?) OK, I can read it now (after
pulling up a link), but having spoken with you about this, I don't
really see any compelling reason to do the schedule this way instead
of using an HTML table. Using the graphic, you lose the ability to
link to other information in the document. Sure, it might look a
little nicer, and if you were actually using a project management tool
to create this I would have suggested that you stick with it, but I
don't see much of an advantage to the way you have done it now.
- completeness (enough activities indicated?) -OK
- indication of milestones - shown in the blown up version
Extra bonus:
- innovative use of table to indicate schedule information - not
really.
- good use of links - as suggested above, I think you are better
off using an HTML table for the schedule and linking to activities,
but that is really not a big issue here.
Comments:
Activities description (35/35 pts)
Important points:
- completeness (all scheduled activities described; descriptions
are detailed enough to indicate what work is done) - OK
- time estimates for activities - OK, but be sure to keep track of
actual time spent on activities so that you can adjust the schedule as
the quarter progresses.
- role assignment - OK
Comments: Now that you know what is involved with Requirements and Design,
you can probably be a lot more specific about what activities you have
done or will be doing. For example, you could list storyboarding,
scenario determination, object modeling, class template definition, as
explicit activities to further subdivide activities such as
Requirements Gathering, Architecting, etc.