HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2012T2 Viaxeiros Project Management"

From IS480
Jump to navigation Jump to search
Line 112: Line 112:
  
 
The following are the links for the previous iterations:
 
The following are the links for the previous iterations:
#[http://bit.ly/RzHqsh Iteration 1]
+
* [http://bit.ly/RzHqsh Iteration 1]
  
'''Bug Metric'''
+
'''Bug Metric'''  
 +
 
 +
Click [http://bit.ly/R8ZSJB here] to view our bug tracking metrics.
  
 
To manage the quality of the work, a bug metric will be used with the following formula:
 
To manage the quality of the work, a bug metric will be used with the following formula:
Line 126: Line 128:
  
 
'''Work Stress Metric'''
 
'''Work Stress Metric'''
 +
 +
Click [http://bit.ly/Wx2CUk 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:
 
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:

Revision as of 12:24, 17 October 2012

Viaxerios Logo.jpg

Welcome to Viaxeiros FYP Wiki Page


HomeViaxeiros.png Home   TeamViaxeiros.png Team Viaxeiros   ProjOverviewViaxeiros.png Project Overview   AppDevViaxeiros.png Application Development   PMViaxeiros.png Project Management   DocumentationViaxeiros.png Project Documentation   ReferenceViaxeiros.png 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.


Our team models this framework heavily in our project management. Due to the agile environment our client currently has, it is necessary that our team is able to manage the fast pace working style our client has and match this project similar to their way.


Iteration

In AUP, iterations tend to be small and many. In our team, each iterations spans for 3 weeks.


Change Request Log

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.

Change Request Log


Deployment

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

Text here


Schedule

Schedules are done and managed in Google Docs:

Schedule Breakdown


Metrics

Schedule Metric [Current Iteration's Metric]

Each members are allocated with a few functions to complete. The schedule will then follow this metric:

ScheduleMetric.jpg


This metric will be tied to an action plan as follows:

ScheduleActionPlan.jpg


The following are the links for the previous iterations:

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:

Bug Metric.jpg

The bug metric will then follow this action plan:

BugActionPlan.jpg


Work Stress Metric

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:

Workload table.jpg

This table will be gauged by the following action plan:

Workloadactionplan.jpg


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.


Risk-MetricV.jpg

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)


Likelihood

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

S/N Risk Description Consequences Impact Likelihood Risk Rate Mitigation Strategy / Contingency Plan Status
1 Technical Risk
1.1 Team is unfamiliar with the technology used
  1. There might be a delay in project schedule
  2. longer time needed to create functions
High High A
  1. Team members are to start researching and trying the technology in advance before the iteration
  2. Share research documents and knowledge among members
Risk Strategy in place - Implemented
1.2 Conflict / issues during configuration and setup
  1. Delay in the project schedule
Moderate Moderate B
  1. All setup for the project should be done early
Risk Strategy in place - Implemented
1.3 Unfamiliar codes / API given by the company
  1. Longer time needed to implement functions
High High A
  1. Request for a detailed documentation of the API used from the company
  2. Ask the company directly and clarify the usage of the API
Not Implemented
2 Development Risk
2.1 Critical bug found during development
  1. Development of project will be stalled
High Moderate A
  1. Coders should consult the entire group about it to discuss for solutions
Not Implemented Yet
3 Client / Sponsor Risk
3.1 Additional requirements requested during implementation of codes
  1. Might not be able to finish requirements on time
  2. substandard work produced
High Moderate A
  1. Team members should discuss and decide if they can commit to the additional workload on time. If not, firmly reject the additional requirements/ol>
Risk Strategy in place - Implemented
3.2 Clients are uncertain what they want in the application
  1. Redundant functions done
  2. Delay and changes in schedule
Moderate High A
  1. Design a few prototypes for the company to view. Perhaps this might help the company to see what they want
Risk Strategy in place - Implemented
3.3 Frequent changes in requirements
  1. Frequent changes in schedule
High High A
  1. Team members should discuss and decide if they can commit to the changes needed on time. If not, firmly reject the changing requirements
  2. The schedule for the team has to be very flexible to take into account the frequent changes in requirements from the client.
Risk Strategy in place - Implemented
4 Team Risk
4.1 Team members may not be free during the critical period
  1. Delay in the project schedule
High Moderate A
  1. Push more work to be done before the the period where members are not free.
  2. Make sure the work intended for the missing member is fully covered.
  3. alter the schedule to fit the manpower available
Not Implemented Yet
4.2 Team members may have conflicts with each other during the project
  1. Delay in the project schedule
  2. Quality of work will deteriorate
Moderate Moderate B
  1. Project manager has to step in to be the mediator. Discuss the issue and work to solve the problems before continuing on the work
Not Implemented Yet
5 Project Management Risk
5.1 Over-estimate the days needed to build function
  1. Delay in the project schedule
Moderate High A
  1. Project manager to take note of the schedule and plan the future schedules more carefully
  2. Provide a longer time period for the next iteration to complete the functions.
Not Implemented Yet