List view
**Time** 1 days **Time Taken** 14 hours **Aims** - Revisit the Constructors in the Classes and assess appropriateness for testing - Reassess the creation of cards - Remove interdependency - Assess redundancies in initial parameterisation - Care *must* be taken to ensure improvements are small and regular to minimise risk **Result** Constructors have to go. As does the creation of cards in its current format. Moved all settings to external file. Created method to pass parameters using python `**kwargs` directly. Significant issues in testing as the test structure had to be rewritten. Lots of car taken to ensure that each addition was a small addition and was tested thoroughly.
Due by March 20, 2016•6/6 issues closed**Time** 3-4 days **Time Taken** **Aims** - Document Issues for Future Work - Document Aims - Document Issues Faced - Document Lessons Learned **Result** Created an image documenting the key relationships in the code. Demonstrated high level changes in the game structure with the game instance flow.
Due by March 24, 2016•4/4 issues closed**Time** 4 hours **Time Taken** 10 hours **Aims** - Test on clab - ensure packages are all working as they should be - Run tests created and on cplvab - Use external parties to test - record results and use for UI improvement **Result** Tested on CPLAB and everything works lovely. The packages all import as hoped and so there is no need to do any workarounds. This was perhaps a bit of a risky move not checking at each stage. However, the CPLAB computers are notoriously slow and so it would have probably been more tedious to `ssh` in every time something significant was added than to implement a workaround. Fundamentally, this action can be defended as non-standard packages were avoided (see logging routines) so the only issues that may had arose would be related to terminal colour encodings. Some minor oversights were picked up in the final tests, however, the real value comes from getting external parties to use the code.
Due by March 21, 2016•3/3 issues closed**Time** 1 days **Time Taken** 20 hours **Aims** - Finish tidying up stylistic / elegance issues in code - Further encapsulate code - Testing - Try not get carried away with implementing overly extravagant solutions. **Result** Several issues were identified in the earlier development and moved into this milestone. It became necessary to exert some self control to focus on the task at hand. The priority flags greatly helped with this and shows the effectiveness of a good plan. The code was encapsulated into manageable routines and as the functions were broken down it became more obvious how to subdivide the messy code.
Due by March 21, 2016•36/36 issues closed**Time** 6 hours **Time Taken** 20 hours **Aims** - Assess the state of the UI - Control Flow - Draw up plans for a new UI - Implement new UI - Testing This stage is the beginning of the enhancements. Must check spelling etc. **Delays** Lack of a coherent development plan for the UI **Result** The UI was assesses by using third parties and a new UI was implemented. The control flow was drawn up. The main issues encountered in the UI phase was that there was no clear route of development and this led to a significant increase of defects. This was possibly one of the most challenging parts of the development cycle. Significant effort had been put into the rest of the project and so this phase was often at risk of over engineering the final product. It was consequently difficult to determine when to do a feature freeze and this is a failure of the aims for this milestone. A final iterative series of testing and coding aimed to iron out the last of the bugs and caught a large number of defects after spending time away from the code.
Due by March 22, 2016•42/42 issues closed**Time** 3 days **Time Taken** 4 days **Aims** - Migrate code to OO class structure - Testing - Play the game again Disjoint and non-interacting classes of variables are: - User - PC - Central Cards Suggest therefore, 3 classes containing the functionality for each. Will contain initial parameters in a constructor. **Delays** - Deciding how best to implement tests - Evaluating / reassessing the class structure for appropriateness - Decided to revisit initial data creation and remove the bad constructors **Result** - Migrated code to OO class structure (User, Computer, Game Engine) - Reassessed appropriateness of keeping dictionary format in the classes `pC` and `pO` - Beginnings of bad code creeping into the development cycle in order to test against the initially bad structure. - Tested extensively through gameplay and inspection - Need to build testable structures such that tests can persist through development: - Milestone `Building Testable Structures` created.
Due by March 18, 2016•6/6 issues closed**Time** 2 days **Actual Time** *Abandoned* **Aims** - Re-work a basic control flow from a code perspective - Migrate similar code to functions - Testing - Play the game again This stage will be the point at which I will begin to make minor improvements e.g. adding comments to code and renaming badly named variables etc. **Delays** - Severe delays due to unexpected lengths of two coursework hand-ins **Result** - A defunct milestone when it came to implementation - Made no sense to repeat the workload and force a solution in a function that could be more naturally represented in a class structure. - Multiple aims and goals in one milestone = bad plan
Due by March 16, 2016**Time** 3hrs **Time Taken** ~8hrs **Aims** - Import initial parameters from external file using cPickle - testing This is just a copy/paste job. Some code will be left inside the main structure if it requires OO to remove to outside of the code base (for now). **Delays** - Severe delays due to unexpected lengths of two coursework hand-ins - Delays as this was a fundamentally bad idea implementing bad code to conform to a bad milestone. **Result** - Implemented pseudo-class structure to be immediately absorbed into an OO solution
Due by March 15, 2016•1/1 issues closed**Time** 6 hrs **Time Taken** ~6 hrs **Aims** - Fixing urgent bugs - Testing - Focus on getting the code functional **Delays** - Severe delays due to unexpected lengths of two coursework hand-ins **Result** - Fixed all serious errors - Code and Game is functional - Moved some non-critical issues to other milestones - Documented other issues uncovered
Due by March 16, 2016•14/14 issues closed**Time** 2 hours (+ 6 hours extension for docs) **Time Taken** ~ 10hrs **Aims** - Migrating bugs into GitHub. - Usage of Milestones for project management rather than TeamWeek - Detailed issues - Document code **Delays** None **Result** - Migrated all bugs to Github using milestones and issues - Created control flow to document original code - Heavily commented code - Detailed issue tracking
Due by March 15, 2016•2/2 issues closed