HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2010T2 CrusNitor MidTerm"

From IS480
Jump to navigation Jump to search
Line 201: Line 201:
 
! Mitigation Type
 
! Mitigation Type
 
! Risk Impact after Mitigation
 
! Risk Impact after Mitigation
!Comments
 
 
|-
 
|-
 
| 1
 
| 1
Line 208: Line 207:
 
<li> Conduct peer tutoring </li>
 
<li> Conduct peer tutoring </li>
 
<li> Pair programming by pairing stronger coder with a weaker one</li>
 
<li> Pair programming by pairing stronger coder with a weaker one</li>
<li> </li></ul>
+
<li> Walk the team through the codes of newly developed features</li></ul>
 +
| Reduction
 
| Medium
 
| Medium
| High
+
|-
| Likelih
+
| 2
 +
| <ul style="line-height: 140%;">
 +
<li> Leverage on Jaryl's past experiences in game development.</li>
 +
<li> Leverage on Clement's past experiences interning for LucasFilm. </li>
 +
<li> Research and read up on game development with specific to iOS games and Cocos2D framework</li></ul>
 +
| Reduction
 +
| Medium
 +
|-
 +
| 3
 +
| <ul style="line-height: 140%;">
 +
<li> Work overtime to meet deadlines and milestones.</li>
 +
<li> Rescope parts of the project, focusing on the essentials and leaving the additional parts for later development. </li>
 +
<li> Reuse available assets to facilitate development and replace these assets when the actual assets are ready</li>
 +
<li>Work closely with the design team and always do a followup on their progress so as to be able to preemptive possible unforeseen circumstances</li></ul>
 +
| Reduction
 +
| Medium
 +
|-
 +
| 4
 +
| <ul style="line-height: 140%;">
 +
<li> Be involved in the planning and conceptualization process.</li>
 +
<li> Maintain clear and open channels with the design team so that we are always on the same page. </li>
 +
<li> Share the ownership of the project with the design team</li></ul>
 +
| Retention
 +
| Low
 
|}
 
|}
 +
 +
 

Revision as of 01:22, 17 February 2011

Project Progress Summary

The following are the chronicles of our IS481 journey up till the mid terms.

Project Highlights

Steep Learning Curve

We had underestimated the initial time we needed to learn and get fully accustomed with the programming language of Objective C. Initially we had estimated that we will need about 2 weeks to master the language. However, we took about 5 weeks to grasp the basics and concepts of Objective C. The difficulty arises from stark difference between the syntax of Objective C and Java, the language we are most familiar with. Further complicating the learning process was due to the fact that we also had to learn the frameworks of OpenGL and later on Cocos2D.


Freelance Designers for Game Art

One of the most major concerns of our project was the apparent problem of not having any graphic designers in the team. This is a critical area as besides the game play, the aesthetics of the game also forms a major component and attractiveness of any games. We are fortunate enough to link up with a group of freelance designers. They were kind enough to design and develop the animation for our game characters for free, on the condition that they are entitled to the ownership of the game assets. Thus we developed an agreement where we will own the codes of the games and will feature a credit page within the game to give the designing team the due recognition for the game art.


Increased risk in terms of schedule and project control

While the collaboration with the freelance design team was a boon for us, it also presented us with increased risks. We have to re-factor our timeline and produce a more agile development schedule. This is because the game art and asset production takes time. This means that we have to possess the flexibility of working on other aspects of the game while waiting for the assets to be produced. Subletting the asset development out to the design team also means that we have increased the risk of not having full control over one of the main aspects of game development. As such, we will have to take this new risk into account and come out with mitigation strategies.


Project Management

Project Status

We have restructured our scheduling and development plans to induce more flexibility. This is so as to allow us to continue developing the game concurrently while the designers are developing the game arts assets. We aim to work on other aspects of the game whenever we experience waiting time from the asset development. This is to ensure that the project will keep on progressing. This also allows us to periodically analyze our game system and conceptualize development areas that we have overlooked during our preliminary planning sessions in the Inception and Elaboration phases.

Features Status Confidence Level Comment
Wireless connectivity Fully deployed and tested 1 May install a heartbeat mechanism to enhance it.
Directional-Pad Fully deployed and tested 1
Primary attack In progress 10% 0.9
Special ability In progress 5% 0.8
Artificial Intelligence In progress 15% 0.8
Game score Not yet started 0
Health Started 5% 0.2
Basic UI Server-side In progress 10% 0.8

Project Schedule (Planned Vs Actual)

Among the main realizations that we have made is that the development of the game artificial intelligence (AI) and game physics will have to be developed incrementally as the project progresses. This is very different from our initial conceptualization where we figured that we can develop these two components in a one-time off basis. These components will be continually build upon and revisited at the start of other iterations so as to ensure that the development is in line with our vision for the final game product.

The 14 March deadline takes into account of our Alpha game version milestone and gives us some time allowance to factor in feedbacks from our UATs before we freeze our development work before the code freeze milestone is induced.

Iteration Feature Planned Date Actual Date Comments
Construction Iteration 2 Milestone First Playable Version 11 Feb 2011 25 Feb 2011 Delays in game asset production
Construction Iteration 2 Game AI Development 28 Jan 2011 14 Mar 2011 Development will be ongoing instead of one-time off task. Will be revisited at the start of each iteration.
Construction Iteration 2 Game Physics Development 8 Feb 2011 14 Mar 2011 Development will be ongoing instead of one-time off task. Will be revisited at the start of each iteration.


Project Metrics

Schedule Metric

We had set aside a buffer time of about 10 days within the project schedule. This buffer time acts as a safeguard to give us time allowance in the event that we go behind time. This buffer time can also act as the spare time for us to work on extra features that we would like to develop in the future or introduce features that we have overlooked during our preliminary planning. We designed a schedule metric that takes into account the number of buffer days left.


Optimally, we would want to leave the amount of buffer time we have untouched for rainy days. However, realistically we may experience delays throughout the project. The highest risk of this situation occurring is getting the game arts asset production to keep pace with the speed of development.


Thus whenever we go beyond schedule, we will deduct the number of days that we have gone beyond the schedule from the buffer day bank. We have color coded the status of the balance to reflect the gravity of the situation as follows:


Green – 8 days or more left
Yellow – 4-7 days left
Orange – 0 – 3 days left
Red – less than zero days left


We would want our schedule status to remain at least in the yellow zone. Should we ever hit the orange or red zone, we would then know that we have to take drastic measures to overcome the predicament. This portion will be covered within the risk assessment and mitigation strategies section.


Bug Metric

We have designed a metric that helps us to track and trace the bugs encountered. The main units of measurement for the metric are the total number of bugs raised, resolved and closed.


  • Bugs raised – Refers to the bugs that are found by the tester and referred to the developer team for resolution.
  • Bugs resolved – Refers to the bugs that have been solved by the developer team.
  • Bugs closed – Refers to the authentication that the resolved bugs have ceased to produce the failed test case outcome and the bug report closed. This acts as a 2nd layer of check.


Bugs found will be prioritized by the tester in the test case documentation. Bugs that have higher priority will be put in front of the queue so that it can be resolved first. The priority level are assigned by the following guideline:

  • Priority 1 bug - Bugs that affects core functionalities of the application critically and in need of urgent resolution
  • Priority 2 bug - Bugs that affect the game play of the application but not in a critical way.
  • Priority 3 bug - Bugs that are minor in nature and does not cause major disruption to the game play


The statistics we can derived from the number of bugs raised, resolved and closed will allow us to forecast on any possible delays that we may encounter during the course of the project. For instance, having numerous unresolved Priority 1 or 2 bugs would signify possible bottlenecks in the development work, as these bugs would not allow nor facilitate the later development works to function properly.


Project Risks

Risk Assessment

Risk ID Risk Likelihood Risk Impact Comments
1 Slow progress due to steep learning curve of Objective C Medium High Likelihood raised to 'medium' from previously 'low'. We had underestimated the complexity of learning the language and relevant frameworks needed for the game development. Even at this stage, we are still learning many new things with regards to the Objective C language.
2 Lack of experience in game development Medium High Likelihood lowered to 'medium' from 'high'. We have coped well with the development work. Our main developers Jaryl and Clement had been spearheading the direction and coached the team with the mechanisms of game development. Referring to books and online forums has helped to mediate this risk.
3 Fall behind schedule High Medium This risk came about as the game art assets production will take time and not keep pace with the development work.
4 Lack of control over game art asset production Low Medium This risk comes about as we have let out the design portion of the project to the design team.


Risk Mitigation Strategy

Risk ID Mitigation Strategy Mitigation Type Risk Impact after Mitigation
1
  • Initiate a familiarization and training period during Inception Phase.
  • Conduct peer tutoring
  • Pair programming by pairing stronger coder with a weaker one
  • Walk the team through the codes of newly developed features
Reduction Medium
2
  • Leverage on Jaryl's past experiences in game development.
  • Leverage on Clement's past experiences interning for LucasFilm.
  • Research and read up on game development with specific to iOS games and Cocos2D framework
Reduction Medium
3
  • Work overtime to meet deadlines and milestones.
  • Rescope parts of the project, focusing on the essentials and leaving the additional parts for later development.
  • Reuse available assets to facilitate development and replace these assets when the actual assets are ready
  • Work closely with the design team and always do a followup on their progress so as to be able to preemptive possible unforeseen circumstances
Reduction Medium
4
  • Be involved in the planning and conceptualization process.
  • Maintain clear and open channels with the design team so that we are always on the same page.
  • Share the ownership of the project with the design team
Retention Low