UseCase	Dev.	Demo FinalReport 	Total
Battleship	45	45	45	30		28
CMESS		41	42	44	30		27
PIE		41	41	42	28		26
OSS		41	44	32	28		24
Crystal		42	42	48	30		27


Final Report 30
1. Any significant changes made to the design and reasoning for the change.
2. What principles and patterns, if any, you have used and again reasoning
	in terms of benefits, problems, issues, etc.
3. Any thing else that you think you should address or present.

Battleship 30
	Very well written. Good presentation of details and D'.
	I am not sure why the D' value is still high. Should be interesting to investigate.
PIE 28
	Fairly good report, though I expected to see metrics.
CMESS 30
	Aaaah, I hate seeing you start again with use case diagram.
	Good work showing D'though D' pretty high.
OSS 28
	You say you changed design to get better D'. What was the value and what is the value
	after change?
CT 30
	Good work

Demo
10 points each for items I, II, II total 50
I. Presentation
II. Handling critical issues well
III. Good layering of system
IV. Patterns and practices
V. Q & A clarity and forthcoming

Battleship 45
I. Presentation 10
	Very good.
II. Handling critical issues well 8
	Concurrency issues. May not have given thoughts to some design level non-functional issues.
III. Good layering of system 10
	Fairly good, though some mock could have been used.
IV. Patterns and practices 7
	Very nice work in using source control and unit testing, patterns and principles.
V. Q & A clarity and forthcoming 10
	Very quick and honest in saying what has not been done well. Though something are not
	perfect, quick recognition of those issues is a good quality.

PIE 42
I. Presentation 10
	Good presentation with different team members talking about their specific work.
II. Handling critical issues well 7
	A number of design critical issues missed, including threading/concurrency.
III. Good layering of system 10
	Fairly good work on this.
IV. Patterns and practices 5
	Use of source control lacking. Other critical practices missing. However,
	quite happy with priciples, OK use of patterns.
V. Q & A clarity and forthcoming 10
	Pretty good.

CMESS 44
I. Presentation 10
	Fairly good presentation.
II. Handling critical issues well 7
	Concurrency handled poorly. Too much redundancy at the data tier.
III. Good layering of system 10
	Fairly good work on this.
IV. Patterns and practices 7
	Lacks some of the critical practices and tools. OK use of principles and patterns. 
	Not entirely convinced at the modeling.
V. Q & A clarity and forthcoming 10
	Pretty good on this.

OSS 32
I. Presentation 8
	Not well organized in terms of ability to get into details. I think those who
	were familar with different modules should have presented.
II. Handling critical issues well 8
	Did not get opportunity to hit some critical issues as we got bogged down in
	misleading statements about how things were handled. Concurrency was not addressed
	at all.
III. Good layering of system 4
	Very poor layering (looked like C code written using C#)
IV. Patterns and practices 4
	Lacks any sign of good tools, techniques, though the team suspects use of one pattern.
V. Q & A clarity and forthcoming 8
	Very misleading in presentation. Very counter productive.

CT 48
I. Presentation 10
	Pretty good work
II. Handling critical issues well 8
	Mostly good job. Need to get some more code stability.
III. Good layering of system 10
	Good job on this.
IV. Patterns and practices 10
	Good work on use of tools, techniques. Consistent weekly demo following good Agile practices.
V. Q & A clarity and forthcoming 10

Dev. Report
10 points each for items I, II, III, IV, and V. Total out of 50 points.
I. Design diagram (UML) and details/discussions
II. Development approach
III. Problems faced and solved.
IV. Other details and discussions
V. Report overall

Battleship 45
I. Design diagram (UML) and details/discussions 10
	Separation of concern in layering,
II. Development approach 10
	Good qualities reported: Iterative, paired programming, communication, motivation, Mock objects,
	unit testing.
III. Problems faced and solved 7
	Postponing integration is not a good idea, but honest reporting of the fact is nice to see.
	Expected to see more consistent discussion of this, but too scattered.
IV. Other details and discussions 10
	Sketch description of source control system lacks specifics. (OK, found more details in
	a later paragraph. Nice to see some of those screen shots!)
V. Report overall 8
	Very good report. Nice overall details (though report is a bit bumpy... not consistent in
	flow). Also lacks a few details on "why?" Good job overall.

CMESS 42
I. Design diagram (UML) and details/discussions 10
	Good discussion on design issues. Good job. Nice to see the discussions and deliberations.
II. Development approach 8
	Good qualities reported: TDD, code reviews, coding convention.
III. Problems faced and solved 6
	Not much presented other than design deliberations and some points in other sections.
IV. Other details and discussions 10
	Good to see discussions on XML storage vs. Access. I am wondering about 
	concurrency, however.
V. Report overall 8
	Too much details on use case and task allocation. 
	About 45% of report covers not much information. 
	Details could have been in appendix or tabularized.


PIE 41
I. Design diagram (UML) and details/discussions 10
	Enough information presented thouch the details on collaboration diagrams was
	not necessary.
II. Development approach 8
	Good qualities reported: IID, (your iterations are flawed if you are following
	the way you have reported. It appears like you are simply calling what you have done
	as iteration!), Agile, layering/tiering, 
III. Problems faced and solved. 5
	Not much information on this (other than design level problems, which is not what
	I expected for this part)
IV. Other details and discussions 10
	Good discucssion on selection of database - nice to see the discussions.
V. Report overall 8
	I asked you *not* to present UML diagrams per use case. So, not sure why you choose to
	do just the opposite.

OSS 44
I. Design diagram (UML) and details/discussions 10
	Sufficient details presented on this.
II. Development approach 10
	Good qualities reported: Recognition of need for MVC, paired programming, testing,
	refactoring, code reviews, communication, coding conventions.
III. Problems faced and solved. 8
	Curisous to know about your success with NUniitASP.
IV. Other details and discussions 8
	I would expect control to be lower than aspx.cs though. Also, too much discucssion 
	on MVC.
V. Report overall 8
	Discussion on use case not relevant for this report (one third of the report redundant).

Crystal Thought 42
I. Design diagram (UML) and details/discussions 6
	Lacks some design details.
II. Development approach 10
	Good qualities reported: IID, TDD, Refactoring, weekly demo and discussions, agile,
III. Problems faced and solved. 8
	Expected to see more details.
IV. Other details and discussions 10
	Sufficient information presented on related technologies and tools.
V. Report overall 8


Use case Report
10 points each for items I, II, III, IV and V. Total out of 50 points.
I. Use case Diagram
II. Flow of Events
III. Description of functionality
IV. Discussions/presentation of interfaces
V. Report overall

Battleship
I. Use case Diagram 9
	Could have given separate diagrams instead of grouping use cases
	in one diagram.
II. Flow of Events 7
	Start Game use case - does the user name have to be unique?
	End condition "Saves user name" indicates an action and not state.
	Quit use case - inconsistent base and alternate path. System
	does not give an option to the user to change mind.
	Help use case - Alternate path is actually a normal flow.
	Use cases basic flow has branching and goes about more
	like an algorithm in places.
III. Description of functionality 10
	Very well described. Good job.
IV. Discussions/presentation of interfaces 10
	These were presented fairly well as part of
	the functionality discussion.
V. Report overall 9
	I like how you have illustrated various situations in
	the game using figures. However, a caption to the figure
	that says what you are showing in the figure will be useful.
Total: 45

CMESS
I. Use case Diagram 9
	Reading the report up until the use case diagram part
	leaves some unanswered questions. You claim no more
	than on meeting can be held at the same time. This seems
	too restrictive. You probably mean for the same manager.
	Can a manager add a memeber to a meeting? Drop a member?
	What does the employee have to do - I am not sure.
II. Flow of Events 5
	Add an employee use case:
	What does it mean by administrator is logged on?
	The steps are a bit high level and missing a few details.
	You are mixing terms - highly inconsisent. You say employee
	and then you say user. Are they the same, if so, why do you
	call them user?
	Your Post condition is a list of actions, not the state.
	Report non-working days use case (holidays would be simpler).
	The use of word iteration - use of technical jorgan in 
	description. Alternate path does not make sense. Why can't I
	declare a holiday within six months?
	Scheduling a meeting: What is difference between Earliest and
	latest dates and time of the meeting? In step 6, why does the
	system show venues that do not have the required capacity?
	Cancel a meeting. Step 1 talks about manager, step 2 and
	initiator. Are they the same?
III. Description of functionality 9
	Description leave a few unanswered questions. Would have been
	nice if someone in your team took time to read this carefully
	before it was submitted.
IV. Discussions/presentation of interfaces 10
	Shows various details that may be of interest to me as a user.
	Good job on this.
V. Report overall 8
	Errors in document. Would have helped to read once before
	submitting.
Total: 41

PIE
I. Use case Diagram 8
	What does figure 1 tell me? Is there a one way interaction?
	You start of with use case description, but a figure that
	shows the use case at this point is missing.
	Name use case as verb phrase (Member registration can be
	register new member).
II. Flow of Events 7
	Browse use case leave OB hanging.
	Member registration post case describes action instead of state.
	Alternate condition ignores cases like existing user information.
	Member login use case says: Includes: Member Registration use case.
				Precondition:  OB is a member in system. 
	Why?
	Alternate path is not telling me what really happens.
	Use Case 5: REQUEST BOOK
	Description: This use case provides a facility to the user to request a book. 
	Description has not really helped me understand what this is?
	Why would a OB request a book. He would want to buy a book, place order
	for a book, etc. right? Again the post condition is not really post condition.
	Figure 3 should have been much earlier near or replacing Figure 1.
III. Description of functionality 7
	Who is a member? He suddenly springs up in use case, but
	there was no description. Not much of description at all.
IV. Discussions/presentation of interfaces 10
	Only one screen per use case?
V. Report overall 9
	You report does not contain list of team members. Please
	submit the participants in each report. Not much of
	description of functionality. Jumping right into use case
	description. Diagrams should appear before you drag me 
	into details.

*********** You have too many use cases. Submit a short list of use cases that you
	will actually implement. The list must include only most important use
	cases. Only take on what you can complete. ***********
Total: 41

OSS
I. Use case Diagram 10
	Fairly descriptive and the brief description 
	supports the diagram. Good job.
II. Flow of Events 1
	Student Registration. Basic flow too coarse grained.
	No need for any password. Enter one piece of information,
	two. What is the interaction?
	Drop Course: Basic flow shows something like brief description
	of the use case.  ...
	Not useful at all.
III. Description of functionality 10
	Enough details presented.
IV. Discussions/presentation of interfaces 10
	Enough details presented.
V. Report overall 10
	Report organized well and good writing. The flow of
	events is missing from the report in my opinion.
Total: 41

Crystal Thought
I. Use case Diagram 10
	Enough details though you may want to use verb phrase.
II. Flow of Events 3
	You are talking about web services. Poor user has no clue.
	He is running away screeming...
	Your user is not exposed to web service. The client application
	interacts with web service. You are missing the fundamental
	of use case description.
III. Description of functionality 10
	Have used other documents submitted to sustantiate this.
IV. Discussions/presentation of interfaces 10
	Have used other documents submitted to sustantiate this.
V. Report overall 9
	Details too coarse grained.
Total: 42