fredag 21 december 2007
Merry Christmas
torsdag 20 december 2007
A paper prototype of the system
The prototype can be found at: http://www.cs.umu.se/~c06een/SE/menu.pdf
Updated projectplan
The projectplan can be found at http://www.cs.umu.se/~c06een/SE/ProjectPlan.pdf
torsdag 13 december 2007
Our requirements specification
Requirements specification
Functional Requirements
GUI
1. The program should work on a cellular phone with MIDP
2. The program should work on a 240 x 389 pixel canvas
3. The program should work on 8 MB of memory
4. The user should interact through the buttons of the phone
5. The user should be able to select a chosen number of dice
6. The usr should be able to deselect an already selected die
7. There should be an indication which dice are selected
8. The user should be able to reroll selected dice
9. The user should be able to end the turn
10. The score of the user and contestants should be displayed
11. The user should have two displayes of scores visible:
11.1 One display should show the score from previous turns
11.2 One display should show the score of the current turn
12. The use should be notified if he "busts"
13. The user should be able to pick between one and three contestants
14. The user should be able to choose difficulty of each contestant
15. The user should be able to pick a winning score
16. The user should always be able to end the game
17. The rolled dice will only give points once per reroll
18. The user will always start
19. As soon a player ends a turn with enough score, he will win
20. The program should be in English
21. The random player should have a 50/50 percent chance whether he ends the
turn or keep playing
22. The coward should have a 90/10 percent chance whether he ends the turn or
keep playing
23. The gambler should have a 10/90 percent chance whether he ends the turn or
keep playing item The clever players moves should depends on the strongest
contestant
24. The clever player should have three different behaviours:
24.1 If he is leading, he should play more risky
24.2 If they have similar score, he should play more careful
24.3 If he is loosing, he should play even more risky
Non-functional requirements
25. Every computer player should have finished its move in 10 seconds
26. After reading the manual, the user should be able to start, play and end the
system independently
27. The program should start in 30 seconds
28. The code should follows Suns coding standard
29. The code should be in English
Inital risk analysis
Risk analysis
Risks
Risk: Risk probability influence
Bad time planning: medium low
Too advanced AI : low low
Doesn’t understand software: low low
Groupmembers prioritize other tasks: medium high
Computers unusable : low high
Requirements change : low medium
Doesn’t understand phone GUI : high medium
Misjudge suitable design: low high
Bad choice of process : low high
Fixes
Bad time planning: Remake time plan
Too advanced AI : Make a more simple AI
Doesn’t understand software: Find someone who does or cooperate with others
Groupmembers prioritize other tasks: Discuss the problem with member
Computers unusable : Find alternative computers
Requirements change : Update requirement specification
Doesn’t understand phone GUI: More resources, find help or make simpler
Misjudge suitable design : Modifiy design
Bad choice of process : Document for next project, eventually modify.
The first version of the projectplan
Project Plan
Team description
Responsibility Person Description
Main contact Erik c05esm, 070−2923332
Backup contact Eva c06een, 070−6735644
Other contact Peter c05psl, 070−2870297
Other contact Lovisa c04lpn, 070−6035086
Responsible for Documents Lovisa Will make sure documents are written.
Responsible for Coding Peter Will make sure all code gets written.
Responsible for Web page Erik Will make sure the homepage is updated.
Responsible for Oral Report Peter Will make sure the oral presentation is good.
Responsible for GUI Eva Will make sure the GUI is user friendly.
Responsible for Testing Erik Will make sure the system get tested.
Required Resources
1. Access to computers
2. Access to a CVS system
3. Access to the Sun Java Wireless Toolkit CLDC
4. Access to a program used to create an architectural diagram
5. 20 hours per week and person
6. Eventually a cellular phone for testing
Chosen approach
The chosen process is a modified version of the Waterfall model, with a recursive
step between coding and testing, and an ongoing documents phase. It borrows the
risk analysis from the spiral model.
Schedule
1. Week 50
1.1 Become familiar with the software.
1.2 Get hold of an CVS system.
1.3 Templates for reports created.
1.4 Homepage created and updated.
1.5 Get hold of a Gobby system.
1.6 Requirements specification written.
1.7 Risk analysis written.
1.8 First meeting done.
1.9 Individual time sheets written, compiled and sent to TA.
1.10 Requirements specification should have been verified.
2. Week 51
2.1 All code shall be planned.
2.2 The GUI shall be planned.
2.3 Comments to every part of the code shall be written.
2.4 Code should be divided between group members.
2.5 Risk analysis should be updated for current week.
2.6 Homepage should be updated.
2.7 At least one more meeting should have taken place.
3. Week 52
3.1 This week nothing is planned due to holidays.
4. Week 01
4.1 All code should be written.
4.2 All tests should be done.
4.3 System should be validated.
4.4 Homepage should be updated.
5. Week 02
5.1 The Manual should be written.
5.2 Final report should be done and handed in.
5.3 Homepage should be updated.
6. Week 03
6.1 Oral report should be prepared for,
6.2 Oral report should been presented.