The SRS document is the "artifact", and should be presented professionally. The remainder is internal materials to be used by the SQA group, and may be scanned hand-written notes and such.
Each team member should individually email Dr. Boult their "team assessment" where you comparatively state perceived differences from the team official schedule, and then provide your assessment of the appropriate splits of the overall team grade.
wincvs is hard to "show" you here, but this is a transcript of
checking out a repository, showing you my readme.txt, adding it to the
repository, then committing it. (You do not see my "log comments"
entered after the "commit" as a separate window popped up for them.)
The follow approach will work under bash/cygwin on the windows PC. Note the "cd" to the directory after the checkout!
Also note that when you "commit" it will pop up a "VI" editor by default.
or, before you do this you can say
export EDITOR=emacs
and it will use emacs. You can also save all the -d :....:
typing by saying
export CVSROOT= :pserver:USENAME@livingston.vast.uccs.edu:/var/cs330cvs
with your username filled in
tboult:tmp->cvs -d :pserver:tboult@livingston.vast.uccs.edu:/var/cs330cvs login Logging in to :pserver:tboult@livingston.vast.uccs.edu:2401/var/cs330cvs CVS password: tboult:tmp->cvs -d :pserver:tboult@livingston.vast.uccs.edu:/var/cs330cvs co Securics cvs checkout: Updating Securics tboult:tmp->cd Securics tboult:tmp->cp /tmp/Readme.txt . tboult:Securics->cvs -d :pserver:tboult@livingston.vast.uccs.edu:/var/cs330cvs add Readme.txt cvs add: scheduling file `Readme.txt' for addition cvs add: use `cvs commit' to add this file permanently tboult:Securics->cvs -d :pserver:tboult@livingston.vast.uccs.edu:/var/cs330cvs update cvs update: Updating . A Readme.txt tboult:Securics->cvs -d :pserver:tboult@livingston.vast.uccs.edu:/var/cs330cvs commit cvs commit: Examining . /var/cs330cvs/Securics/Readme.txt,v <-- Readme.txt initial revision: 1.1 tboult:Securics->Where my sample Readme file contains
tboult:Securics->cat Readme.txt This is the CVS repository for the CS330 Securics Team Requirements. The primary files in the directory include: ???? The primary Requirements Document ??? The list of questions for first interview ??? The list of questions for second interview ???? Notes from from First interview ???? Notes from from Second interview ???? Excel spreadsheet with schedule as planned ???? Excel spreadsheet with schedule as executed and hours workedObviously you need to replace the ????, and may have a different list of files.
In a separate document, each team member, without discussing it with the other SQA team members, should provide their grading assessments of the SRS project and the individuals on that team. In particular you need to
Introduce yourself to the customer as the design team, and get them to "signoff" (i.e. formally accept) the requirements document and your schedule, (they should have gotten the requirements doc that they should have been provided after final SRS. Turn in your schedule and an email from the client.
Add a Design-overview-readme.txt, which says what files are in the design document with a 1-sentence description of each
Develop your architectural model and document it in drawings/text. This document should be the first thing people read to understand how you are solving the problem.
Document the primary flows needed to solve the problem in activity or sequence diagrams.
Develop your primary class/object/procedure list and document it in UML. The Class list should be reasonably complete with descriptions, attributes (members) and operations (methods)
Begin sketching the implementation of the core operations/methods and/or storyboards for any GUI components.
Email to tboult a short synopses of what you did and w your perceived split of the design grade (and why).
Both the updated/commented files and the SQA overview should be checked into the appropriate CVS repository.
Very important, each person (not each SQA team), email tboult a grade (and justificaiton) for the inital design on which you did SQA as well as what you think your design team's grade should be. All grades on a 4.0 scale. So if you think your team deserved a 3.3 and after the review think the team for which you did SQA, deserves a 3.5. To make it simpler than before just tell me the grade you think your team and your SQAed team should get. (not the diffreence).
Also Email to tboult a short synopses of what you did on the SQA team and your perceived split of the SQA grade (and why). This can be combined with your grading of the design docs from SQA.
Email to tboult a short synopses of what you did and w your perceived split of the design grade (and why).