|Version 12 (modified by pmccormack, 3 years ago) (diff)|
Postmortem for Phase 2
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 refactored the majority of the code and added middle school friendly mouseover text. We also compiled into an executable a working alpha release. Overall we accomplished all of our goals, although some were less complete than others. One problem we had this week was waiting until the last minute to meet and put everything together. We will avoid this in the future by meeting earlier in the week.
In phase 2 we maintained the trend of completing all of our deliverables on time. We continue to believe that assigning specific tasks to team members during the Tuesday meeting and setting intermediate deadlines/meetings during the week is integral to our success. We are very pleased with what we have accomplished and are with our alpha release. Since we spent the last week reorganizing our code, we feel that we are very adequately prepared for moving into phase 3.
The majority of phase 2 was spent working on the main framework of our game. This was a headache on many levels, largely due to code organization issues and competing team desires. by the time phase 2 was well underway, the code had become a mega class monster and was very difficult to manage. We were constantly talking about how it needed to be reorganized. However this never would happen as no one in the group could agree upon any one way to move things around. Eventually the code was refactored at the end of phase 2, but not without considerable disagreement on how to do it. Overall though this lively discussion lead to a better model for our code and the final product is much more readable.
Implementing features has gone very smoothly and went without a hitch. We have continuously added new framework elements to the game. Since the game design is largely complete and now we are just working on implementation, there has been a lot less conflict than before. Ultimately the game is rapidly taking its final form and we expect that it will be very complete for the beta release. We have already covered all of our alpha use cases, and many of our beta ones. However we perhaps should have prioritized exiting the game as an alpha use case and not a beta one, as we have gotten strong negative feedback against not implementing this sooner.
We are continuing the trend of Friday meetings, which seems to work out well. It is anticipated that this will continue.
How good were your predictions on how long the goals would take to achieve?
Since the majority of the time was spent in refactoring, we never had a solid time estimate. The estimates we did have were underestimates. However refactoring is often something that can be continuously done and can take as long or as little time as is available, depending on how comprehensively it should be done. As a result it is not surprising that doing a good job took a while. Since we weren't sure how long we wanted to spend, we made small estimates, which was probably the best idea.
The predictions were fairly accurate for phase 2. The only things that took longer to create than expected were the class diagrams. These too several hours longer to make than was anticipated. Otherwise all of the deliverables were completed in the time we expected. We attribute this to splitting them into small, manageable pieces that only took a few hours to make.
Management Plan Phase III
The initial Phase III management plan will consist of a vague plan outline. Version 1 use cases and corresponding high priority goals are identified and put onto the goal stack. Overall Risk Analysis is performed. Management Plan for Week 8 are 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.
Beta/V1.0 Use Cases and Corresponding Goal Plan
Version 1.0 "should be a stable, playable game that your teacher can run (without installing any extra software) on their machines". (CS 121 Phase III site)
We believe that our Priority 3 and 4 Use Cases from our proposal meet this requirement and are within the Phase III time scope. Given our architectural framework, we think these goals will not be difficult to accomplish. Priority 3 Use cases will be completed for the beta release and Priority 4 use cases will be complete for the Version 1.0 release.
Priority 3 Use cases are essential in achieving primary learning objectives but are not necessary for initial game function.
Priority 4 Use cases add fun to the game. This includes AI events or other game events.
|Make Tariff Policy||3|
|Make Embargo Policy||3|
Use Cases are detailed in the Proposal. These use cases may be expanded.
In addition we would like to add the following use cases:
|AI Event Dialogs||4|
In order to ensure a complete V1.0 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 on the goal stack Main Page.
Risk Analysis for Phase 3
risks are prioritized by importance this week
- Students may not read text in the information panel. Currently, the text that appears in our info box is too long-winded and advanced for many middle school students. As a result, many students may not read any of it, which makes it hard to achieve the learning objectives. This week, we need to make the text as concise as possible while using simple language. As Greg Orr said during the customer elicitation, teaching the students what a tariff is will be beneficial even if they do not know more than that.
- Students may lose interest in the game. We will limit the amount of text in the game and continue to make the graphics more interesting. In addition we hope to
- All economic policies have pros and cons. It will take careful design to allow the player to advance forward in the game. In particular, it is hard to predict the results of enacting tariffs. If the resource is primarily produced internally, a tariff will mostly hurt exports and make producers unhappy. Our model can handle this type of distinction, but it will be hard to teach the students the difference. Currently, we plan to put some tips in the hover dialog for the policy buttons, suggesting how the policies will be most effectively used.
- Players could find ways to exploit the economic model. For example, a student might spend many turns raising money with high taxes and then increase happiness at the last minute. We have several strategies to prevent this sort of "cheating":
- We made the maximum money 2000 to prevent unrealistic hoarding of money
- The happiness levels increase at about the same rate as the money, so a sudden tax cut will only make people completely happy after a while (during which the money will decrease).
- There are lower limits on happiness (15% right now) to ensure the student does not make their constituency too unhappy (or they will be forced to leave office).
- Careful selection of level goals will ensure that the student choose policies to balance meter levels.
- We have not implemented the AI yet. Since the AI will only be important in the last level (and is not necessary in the learning objectives, it has taken lower priority over the last few weeks. We will discuss the framework this week.