Difference between revisions of "IS480 Team wiki: 2012T2 Viaxeiros Project Management"
Line 3: | Line 3: | ||
===<center><b><font size="5">''Welcome to Viaxeiros FYP Wiki Page''</font></b></center>=== | ===<center><b><font size="5">''Welcome to Viaxeiros FYP Wiki Page''</font></b></center>=== | ||
− | < | + | <imagemap> |
+ | |||
+ | Image:Navigation 3.png|center|1400px | ||
+ | |||
+ | |||
+ | rect 62 273 428 528 [[IS480_Team_wiki:_2012T2_Viaxeiros|]] | ||
+ | rect 473 313 721 512 [[IS480_Team_wiki:_2012T2_Viaxeiros_Our Team|]] | ||
+ | rect 743 313 972 512 [[IS480_Team_wiki:_2012T2_Viaxeiros_Project_Overview|]] | ||
+ | rect 1009 312 1225 508 [[IS480_Team_wiki:_2012T2_Viaxeiros_Application_Development|]] | ||
+ | rect 1258 310 1497 509 [[IS480_Team_wiki:_2012T2_Viaxeiros_Project_Management|]] | ||
+ | rect 1528 310 1753 51 [[IS480_Team_wiki:_2012T2_Viaxeiros__Project_Documentation|]] | ||
+ | rect 1786 146 2071 523 [[IS480_Team_wiki:_2012T2_Viaxeiros_Learning_Outcomes|]] | ||
+ | |||
+ | rect 1176 251 1291 316 [[#Framework|]] | ||
+ | rect 1208 159 1346 232 [[#Milestones|]] | ||
+ | rect 1359 133 1466 210 [[#Schedule|]] | ||
+ | rect 1479 201 1581 251 [[#Metrics|]] | ||
+ | rect 1477 272 1604 333 [[#RiskAnalysis|]] | ||
+ | desc none | ||
+ | |||
+ | |||
+ | </imagemap> | ||
{| | {| | ||
|- | |- |
Revision as of 02:42, 18 January 2013
Welcome to Viaxeiros FYP Wiki Page
Home | Team Viaxeiros | Project Overview | Application Development | Project Management | Project Documentation | Learning Outcomes |
| | | | | | | | | | | |
Framework
Agile Unified Process Adapted from the Rational Unified Process (RUP), Agile Unified Process (AUP) provides a simplified framework catering primarily for companies with an agile environment. Documentations are prepared to be "barely just good enough" to enable the flexibility required in an agile process.The process is broken down into 4 phases : Inception, Elaboration, Construction and Transition.
In AUP, iterations tend to be small and many. In our team, each iterations spans for 3 weeks.
Due to the agile process, changes to the requirements of the projects are rapid and regular. In this case, it is necessary to track and manage changes of the sponsors. Our team implements a change request log that tracks the changes sponsors wants to have. As a team, we will decide the importance of this change and hence change our schedule accordingly.
As part of the request of the sponsor, the native application has to be deployed to Google PlayStore. However, the first deployment will take a much longer time than that of subsequent deployment as multiple testing. This concept is similar to the AUP. |
Milestones
|
Schedule
Schedules are done and managed in Google Docs: |
Metrics
Schedule Metric [Current Iteration's Metric] Each members are allocated with a few functions to complete. The schedule will then follow this metric:
Bug Metric Click here to view our bug tracking metrics. To manage the quality of the work, a bug metric will be used with the following formula: The bug metric will then follow this action plan:
Click here to view our work stress metric. In order to make sure each members are able to cope with their current workload, each members have to fill in their stress percentage based on the following table: This table will be gauged by the following action plan: |
Risk Analysis
In order to manage the probable risk involved in the project, our group takes into account 2 variables: Impact and Likelihood. Based on the criteria mentioned below, the risk rate for each risk is accessed and a mitigation cum action plan is created.
Impact High - Chances of the occurrence happening is almost regular (very high) Moderate - Chances of the occurrence happening is irregular (sometimes) Low - Chances of the occurrence happening is seldom (very little)
High - The occurrence has a very great detrimental effect on project Moderate - The occurrence has a significant effect on the project Low - The occurrence has a limited effect on the project
|