Roskilde Business Academy
1st Semester, 2008
Project Charter
DiceGame
Project
Version 1.2
October 2008
Dice Game
Project Charter
Released in October 2008
Roskilde Business Academy
Advanced Computer Studies
1st Semester, Autumn 2008
Software Design
Software Construction
Authors:
Susanne Ruge,
Michael Claudius
Page 1 of 6
13/07/17
Roskilde Business Academy
1st Semester, 2008
Project Charter
DiceGame
Project
Version 1.2
October 2008
Table of Contents
1.
Introduction ...................................................................................................................... 2
2.
The case............................................................................................................................ 2
3.
Project Conditions ............................................................................................................ 4
3.1 Process Requirements ................................................................................................... 4
3.2 Product Requirements ................................................................................................... 5
3.3 Submission of Project Report........................................................................................ 5
Pair Evaluation form ................................................................................................................. 6
1. Introduction
The objectives of this first, small project are for you to:






be able to draw simple UML diagrams in NetBeans
be able to use NetBeans as your programming editor
be able to write and structure a study report using a word processor
get your first experience in PairLearning, PairProgramming and Pair Evaluation
be able to use NetBeans GUI Java coding
create a simple Java program
2. The case
This is about playing with dice.
You are to ‘develop’ a small sw-system simulating a dice game.
You just follow the example of chapter 1.5 in the Larman-book for the SW-design activities:




Define Use Cases
Define Domain Model
Define interaction Diagrams
Define Design Class Diagram
Page 2 of 6
13/07/17
Roskilde Business Academy
1st Semester, 2008
Project Charter
DiceGame
Project
Version 1.2
October 2008
Followed by the SW-construction activities:






Construct one model class Die
Test the Die class in a Main test class TMC_Die
Construct one controller class DiceGame
Test the DiceGame class in a Main test class TMC_DiceGame
Construct one GUI class DiceGameGUI
Test the GUI program
Start slowly and then add more and more features increasing your program level:
Level 0 (Not passed mark -3)
One player. The players name is read in. No play.
Classes: Die.
Level 1 (Not passed mark 00)
One player. One die. The players name is read in. One player can throw a die and the result is
shown. Textbased.
Classes: Die and TMC_Die.
Level 2 (Passed mark 2)
One player. One die. The players name is read in. One player can throw a die and the result is
shown. Textbased.
Classes: Die, TMC_Die, DiceGame & TMC_DiceGame.
Level 3 (Passed mark 4)
One player. One die. The players name is read in. One player can throw a die and the result is
shown. GUI-based.
Classes: Die, TMC_Die, DiceGame, TMC_DiceGame, DiceGameGUI.
Level 4 (Passed mark 7) Use Case 1: Play a DiceGame
One player. Two dice. The player’s name is read in. The player can throw two dice and the
result of each die and the sum are shown. GUI-based.
Classes: Die, TMC_Die, DiceGame, TMC_DiceGame, DiceGameGUI.
Level 5 (Passed mark 10)
Two players. Two dice each. The player’s name is read in. Both players can throw two dice and
the result of each die and the sum are shown.. GUI-based.
Classes: Die, TMC_Die, DiceGame, TMC_DiceGame, DiceGameGUI.
Level 6 (Passed mark 12)
Two players. Two dice each. The player’s name is read in. Both players can throw two dice and
the result of each die and the sum are shown. The name of the winner is visualised. GUI-based.
Classes: Die, TMC_Die, DiceGame, TMC_DiceGame, DiceGameGUI.
Page 3 of 6
13/07/17
Roskilde Business Academy
1st Semester, 2008
Project Charter
DiceGame
Project
Version 1.2
October 2008
3. Project Conditions
3.1 Process Requirements





The project takes place from Wednesday 1st October until Tuesday October 7th 2008.
The work must be carried on in pairs formed by the teachers.
Your teachers will supervise you during the project period. Their job is to show you the way, to
inspire and counsel your group. We will not provide you with absolute answers/solutions (nor
will we do your project!). Remember that there is often more than one answer to an aspect of a
problem
Every pair member must participate actively in the project
Each pair member must fill in the form ‘Pair Evaluation’
(http://laerer.rhs.dk/susanneru/e2008-1sem/Pair Evaluation.doc)
Page 4 of 6
13/07/17
Roskilde Business Academy
1st Semester, 2008
Project Charter
DiceGame
Project
Version 1.2
October 2008
3.2 Product Requirements



Your project is to be documented in a study report which may amount to max. 10 pages, excl.
of appendices.
Basically, theory should not be described.
The report should contain:
 Front page with the name of the project and pair member names
 Table of Contents (automatically generated)
 Page numbering
 Numbered Sections, e.g.:
1. Human resources
1.1. Names, telephone numbers and e-mail addresses of pair members.
2. SW-Design
2.1. Use case UC1: Play a Dice Game
2.2. Domain model
2.3. Sequence diagram
2.4. Design class diagram
3. SW-Construction
3.1. Class code
3.2. Screen dump of the running program
3.3. Screen dumps of GUI
3.4. Brief explanation of what the code does
4. Evaluation and Conclusion
4.1. How did you work together in your pair? (each member must fill in a form)
4.2. How good is the design?
4.3. How good is the program?
4.4. Was it fun?
3.3 Submission of Project Report

The Project Report is to be submitted not later than
Tuesday 12th October 2008 at 15.00

Hand in 2 copies (one for each teacher)
Page 5 of 6
13/07/17
Roskilde Business Academy
1st Semester, 2008
Project Charter
DiceGame
Project
Version 1.2
October 2008
Pair Evaluation form (http://laerer.rhs.dk/susanneru/e2008-1sem/Pair Evaluation.doc)
Project name
Your name
Partner’s name
Has the student attended your group meetings?
Has the student notified you if she/he would not
be able to attend the group meeting or fulfill a
responsibility?
Has the student made a serious effort at
assigned work before the group meetings?
Does the student attempt to make contributions
in group meetings when she/he can?
Does the student cooperate with the group
effort?
Never Rarely
Sometimes
Usually Always
Asses the technical competency of your
partner relative to yourself
Weaker than me
About the same
Better than me
Asses how compatible you and your
partner were
Very compatible
Ok
Not compatible
Overall rating:
Excellent
Marginal
Consistently went above and beyond – tutored teammates, carried more than
her/his fair share of the load
Consistently did what she/he was supposed to do, very well prepared and
cooperative
Usually did what she/he was supposed to do, acceptable prepared and
cooperative
Often did what she/he was supposed to do, minimally prepared and
cooperative
Sometimes failed to show up or complete assignments, rarely prepared
Deficient
Often failed to show up or complete assignments, rarely prepared
Very good
Satisfactory
Ordinary
Unsatisfactory Consistently failed to show up or complete assignments, unprepared
Superficial
Practically no participation
No show
No participation at all
Comments:
Page 6 of 6
13/07/17