|Version 53 (modified by pmccormack, 4 years ago) (diff)|
Tuesday Meeting , September 20th, 2011 at 11:00 AM
Sprague Memorial Center Lab
Attendees: Paul, Stephen, Helen, Colin
Scribe: Helen, Paul
- Complete Management Plan 9/20
- Discuss Phase II plan and update goal stack
Postmortem for Phase I
What went right and what went wrong? Did you achieve the goals you had set out? What can you do to avoid similar problems in the future?
We completed all the deliverables and developed a more extensive prototype than we even thought possible. We created an economic model that will serve as the basis for our alpha release, with a few modifications. Our proposal turned out well, according to our classmates. The game treatment clearly describes the game in a fun video-game-box-like manner, and we hope the prototype animations will turn the middle school students toward our game from the beginning. We accomplished all of the goals itemized in the September 13th notes.
In general, we completed all of our deliverables on time. We believe that assigning specific tasks to team members during the Tuesday meeting and setting intermediate deadlines/meetings during the week was the key to our success in completing all our planned goals. Every member contributed highly to the project thus far and we are very pleased with our results.
The beginning of Phase I was met with some confusion in terms of requirements and expectations. We didn't quite understand what the management plan had to include. In addition, we also misunderstood the requirements for the use case documents due to differences between the rubric and the phase I description. However, after talking to the grutors and professors we came to understand these deliverables better. As a result, our management plans are much more organized now. They include a clear goal stack and goal plan with time estimates and assignments. We believe that this also results in much better organization within the team. In addition, we have updated our use cases in our proposal, which are prioritized with rationale. In the future, we will make sure to understand requirements through the rubric and/or communication with the grutors or and professors. We have also started proofreading documents within the group, which will also avoid similar problems.
At the beginning of Phase I, our trac was not completely organized. However, throughout the phase, we have been modifying the trac so that our management plan and deliverables are easy to find and follow. We have also been deciding on the best format for our goal stack. Given that we can always improve our organization, we may further improve our trac to prevent any future organizational problems.
Game design has been a large portion of weekly meeting discussions. Our idea of our game design isn't the same as it was at the beginning of phase I, and the design is always changes. Given our development methodology[agile], we do not think this is a bad thing. We believe that we are constantly determining better ways to design and implement features, while throwing away previous ideas that involved certain weaknesses. However, we do not have an extremely clear design for some elements including AI. These topics may need further discussion during the next phases.
Lastly, we are starting to notice that finding common meeting times during the week is getting harder as the semester progresses. However, this is fine as long as we use our lab time on Tuesday efficiently to create a good management plan for the week.
How good were your predictions on how long the goals would take to achieve?
In the Sept. 14 notes, we make predictions about how long the goals will take to achieve. The management plan and treatment definitely took the predicted amount of time, but the prototype and proposal both took longer than expected.
The prototype took longer than 4-7 hours for a few reasons. First, Stephen wisely spent a long time (3-4 more hours) developing the button class so that the resource and policy buttons could inherit from it easily. Second, Paul spent an extra 4-5 hours creating the economic model and improving the art. Both tasks were entirely unnecessary at this stage, but both will make our game seem more attractive in the prototype and will make it easier to develop the alpha release in the next few weeks.
The proposal was predicted to take 5 hours. Our estimate was due to believing that many parts of the proposal would be copy and paste. However, our proposal contains a large amount of new content, and therefore took approximately 14 hours combined. In particular, we rewrote the use cases now that we have a better idea of our game. Requirements were similar to ones in previous documents but more rationale and thorough risk analysis/risk mitigation plans are provided. We also revised our technology assessment form the previous version in order to incorporate the grader's comments. Finally, a group effort was made to edit and proofread the proposal.
Although we went over our time estimates for the proposal and prototype, we believe that it is very reasonable. These two documents give us a strong foundation for the rest of our project, and we are glad that we allocated more time to them.
Although we estimated approximately 3 hours or less for all week 1 and week 2 deliverables, we didn't explicitly state them in our goal stack. Given that, most of the deliverables in Phase I were completed within time estimates with the exception of the proposal and prototype.
Management Plan Phase II
The initial Phase II management plan will consist of a vague plan outline. Alpha use cases and corresponding high priority goals are identified and put onto the goal stack. Overall Risk Analysis is performed. Management Plan for Week 4 is described thoroughly, but plans for following weeks will be less detailed, but give a feel of the overall plan. These plans will be updated every week in a more detailed manner in the Management Plan Updates.
Alpha Use Cases and Corresponding Goal Plan
The alpha release should "incorporate core architecture and provide a playable experience" (CS 121 Phase II site)
We believe that our Priority 1 and Priority 2 Use Cases from our proposal meet this requirement and are within the Phase II time scope. The prototype has already completed two of the priority 1 Use Cases [Initialize game and Initial trade setup], and has set up the framework for other use cases. Therefore, given our experience with the prototype, we believe that these use cases are feasible for alpha release.
Priority 1 Use cases are defined as absolutely necessary for the player to start the game.
Priority 2 Use cases are defined as essential in achieving primary learning objectives as well as providing initial function to the game.
|Initial Trade Setup||1||Completed|
|Play Game||1||to do|
|Make Policy||2||to do|
|Make Tax Policy||2||to do|
Use Cases are detailed in the Proposal. These use cases may be expanded during our architectural designs. However, these are our core use cases and give a good idea of our alpha release.
In order to ensure a functional alpha release, we break up the core use cases into subtasks. Since some subtasks for each use case are more important [e.g. main tasks vs enhancements], we further prioritize these subtasks in the following table. Priority A is the highest, priority C is the lowest. A* are our goals for the next prototype (9/27).
The priority A subtasks will make the game playable and setup a core game architecture. There needs to be a turn mechanism, a way to implement policy, and a way to see the effects of that policy in the meters. Although educational goals may not be reached at this point, completing these subtasks will provide us with a functional prototype and therefore minimizes risk for the alpha release.
The priority B subtasks primarily focus on the educational goals. There should be more info about policies, and the game will allow more specific policies to be enacted.
The priority C subtasks are extra features we could add if we have time. In particular, adding event dialogs, highlighting icons to assist in enacting a policy, and creating meter popups are all not necessary at this point but would improve the quality of the game.
Use Case SubTask Priority Status Time Play Game create turn mechanism, button A* to do 1-2 hrs add initial game instructions, tutorial in info box B to do 1 hr include additional event dialogs C to do 4-5 hrs Make Policy write instructions in info box for implementing policy A to do 1 hr highlight appropriate icons when choosing a policy C to do 1 hr create popup window describing policy details A* to do 1-2 hrs add adjustable policy components to above window C to do 3-4 hrs apply generic policy to country or resource A* to do 1 hr Make Tax Policy (follows directly from Make Policy), determine meters/resource consequences A* to do 1 hr Meters choose concrete level goals for each meter (quantify) A to do 1-2 hrs implement functions to set meter levels A to do 2-3 hrs update meters from country stats during turn A to do < 1 hr Hover provide information about resources/capitols hovered over B to do 1-2 hrs provide information about buttons hovered over B to do < 1 hr provide information [includes reason] about meters hovered over B to do 2-4 hrs
Our goals for the tasks are as follows:
The prototype goals are written out in Prototype.
Week 4 Plan 9/20/2011 to 9/27/2011 [Start Phase II]
1 is highest priority
|Deliverable||Due Date||Time Estimate||Priority||Mainly Assigned to||Reasoning|
|Management Plan Update||9-22||1-2 hours||1||Helen, Paul||Management Plan was discussed in the Tuesday meeting. We still need to write up a goal plan, update our goal stack with respect to Phase II goals, and do risk analysis|
|1st Architectural Design Draft: Use cases||9-27||0.5 hours||2||Helen||Use cases are already outlined in the proposal. However, we might need to expand them a bit, but it shouldn't take much time.|
|1st Architectural Design Draft: Domain Diagram||9-27||0.5 hours||2||Helen||Domain diagram was also already created for the proposal. Again, we may need to reconsider aspects of the design, but it will only take a small amount of time.|
|1st Architectural Design Draft: Initial Class Diagram||9-27||1-2 hours||2||Stephen||New diagram: Depending on how detailed our class diagrams may be this will take approximately 1-2 hours. This may take more time than estimated since we would really like a good basis to build our game on.|
|1st Architectural Design Draft: Sequence Diagrams||9-27||1 hour||2||Paul||Also new diagrams. However, most sequences present in our game are known, but not detailed. Therefore we estimate one hour.|
|1st Architectural Design Draft: Design Analysis||9-27||1 hours||2||Colin||The design analysis will be discussed by everyone during a late week meeting (Sunday or Monday). Writing this document up should take less than 1 hour after the discussion.|
|Prototype Update 9/27: A* Tasks||9-27||5-8 hours||2||Everyone||Our goal for week 4 is to implement A* use cases. These use cases are the higher priority use cases in group A. They are necessary to make the game playable.|
|Play Game: create turn mechanism, button||9-27||1-2 hours||2.1||somebody|
|Make Policy: create popup window describing policy details||9-27||1-2 hours||2.2||somebody|
|Make Policy: apply generic policy to country or resource||9-27||1 hr||2.3||somebody|
|Make Tax Policy||9-27||1 hour||2.4||somebody|
We split up the Architectural Design Draft among group members. We would like everyone to work on the Prototype this week. This way, people who worked on the proposal last week can familiarize themselves with the code.
Week 5 Plan 9/27/2011 to 10/4/2011
|Management Plan Update||9-27|
|Second Architectural Design Draft||10-4|
|Initial UI Design||10-4|
|User test||10-4 [in class]|
|Prototype Update 10/4: A Tasks||10-4|
|Meters: implement functions to set meter levels||10-4|
Week 6 Plan 10/4/2011 to 10/11/2011
|Management Plan Update||10-4|
|Architectural Design Review Package||10-6|
|Final UI Design||10-11|
|Prototype Update 10/11: B Tasks||10-11|
Week 7 Plan 10/11/2011 to 10/18/2011 Fall break Week
|Management Plan Update||10-11|
Week 8 Plan 10/18/2011 to 10/25/2011
|Management Plan Update||10-18|
|Test plan implementation Stage I||10-20|
|Test plan implementation stage II||10-25|
|Alpha release Executable: C Tasks||10-25|
Week 9 Plan 10/25/2011 to 11/01/2011 [End Phase II]
|Management Plan Update||10-25|
|Alpha release Class presentation||10-27|
|Alpha release Documentation||10-27|
Longterm risks are outlined and prioritized in Proposal.
This section discusses risks specific to Phase II Alpha Release.
Time is always a major risk. We need to have our Alpha release ready by October 25, which gives us approximately a month to implement a playable game that contains a core architecture that is easy to build on. As a result, a major risk is not having a functional and playable game by this point in time. We have planned out our alpha development to minimize these risks. Alpha Use cases are chosen so that two objectives will be completed: the game will be functional and will achieve at two or more sub-learning objectives [see Proposal Nonfunctional Requirement 2.1, 2.3]. In order to minimize risk further, we divide up Alpha Use Cases in to prioritized subtasks. Highest priority tasks will guarantee functionality to the game. Thus, our game should be playable from a very early stage in the Phase II. We do not have a great backup plan for our priority A tasks as these are core to game play. However, given our initial prototype, we are confident that we will succeed in implementing these tasks. If we get stuck on priority B or C tasks, we can: 1) work on other tasks first, as most tasks are not dependent on other B or C tasks 2) redesign our approach, as these tasks are much more flexible in the method of implementation.