HeaderSIS.jpg

IS480 Team wiki: 2013T2 The CodeFather Final Project Management

From IS480
Revision as of 02:37, 14 April 2014 by Huishia.tay.2011 (talk | contribs) (→‎Risks and Mitigation Plans)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The CodeFather Logo.png

Back to Main Wiki   Progress Summary   Project Management   Development Overview   Quality of Product   Reflections

Overview of Updated Schedule

Our project schedule is divided into 10 iterations

  • As our project is self-proposed, we want to do as many user testing as possible so as to know the expectation of the users and improve the usability of the application.
  • Increase of scope has in iteration 6 and 7, details are shown below
  • Start date and end date of iteration 6 and 7 has changed, details are also described below
  • More emphasis will be placed on user testing so as to improve the usability of the application

Planned VS Actual

Center

Change 1:
As our first user testing was scheduled to be on Iteration 6, 29 January 2014, the team was required to stabilise the application in time for the user test. This has in turn caused a series of critical bugs to rise during the functional testing carried out during iteration 5. As our bug metrics in that particular iteration is in the critical zone, project manager has then reviewed the schedule and allocated more time during that period of time for user testing in iteration 6. This has in turn caused iteration 7 to begin on 10 February 2014 instead of 3 February 2014.

Change 2:
Iteration 7's end date was also pushed back to 24 February 2014 instead of 21 February 2014 due to the scheduling of our midterm presentation to be on the week 8, 24 February 2014, instead of week 7.

Change 3:
There was a change in scope after midterms as we made some important decisions regarding to the feedback by our reviewers, mentor and supervisor. However we managed to remain within the specific timeline for the changes. Below shows the feedback provided by our mentor and supervisor which lead to our decision metrics and hence the changes in red on the project timeline.

Screen Shot 2014-04-14 at 2.02.20 am.pngScreen Shot 2014-04-14 at 2.02.36 am.png

Screen Shot 2014-04-14 at 2.01.00 am.png

Center

In addition, we have also made some changes in our scheduled tasks and functions as shown above.

  1. Due to some technical difficulties faced with our XMPP service as we were using Xabber during that period of time, our team has found that Xabber Implementation had too many errors occurring and was having much more complications as per expected. Hence we then decided to change to Smack, as this was a team decision, project manager has then reviewed the schedule and allocated time in iteration 6 for the change from Xabber to Smack.
  2. During our user testing, we have discovered from our stakeholders that the user experience as well as professional design was lacking. In addition, many has commented that our mobile application did not have a visual paradigm. After evaluating all of our stakeholders comments, our team has come to decision to focus more on the mobile's application's usability. We have also did a revamp of our UI design.

Ant Role Change.png Hector Role Change.png

There are also some role changes in our project development progress. This is due to the fact of the steep learning curve of Android as well as the schedule changes of individuals.

Anthony switched from the Android developer role to a Web Developer role as he had to fly to Cambodia for OCSP during the winter break which is Iteration 4 in the project timeline. This has in turn cause him to lag behind others in terms of development and learning of the new programming language. While on the other hand, Hector has been implementing functions as well as frontend changes on the mobile side, this has in turn cause him to be proficient in the Android programming language.

After a team discussion, project manager has then reassigned the roles of the individuals and allocate work as accordingly.

Schedule Metrics

CodeFather time.png Current Iteration: 10

We have completed 10 iterations till Finals.
Click here to view the calculation of our Schedule Metrics

The Codefather Schedule Metrics.png

As seen from the graph above, the highlighted green area represents the healthy schedule range of 0.8-1.2.
Throughout the 10 iterations, our team's development progress has managed to remain within this healthy range.

Before planning of the next iteration's task, the Project manager would always consult the team on the following pointers:

  1. The number of tasks to be done
  2. Estimated time needed to complete the tasks
  3. Difficulty level of each task.


Taking into consideration the pointers above, as well as by reviewing the project schedule at the end of the iterations, relevant changes would be made for the following iterations to ensure better planning and execution of the tasks.

As you may have noticed, in our iteration 2 phase, there is a spike in our schedule metrics measuring 1.12 on the schedule ratio.
This is due to the fact that we have just started our development phase, 9 September 2013 - 6 October 2013, and our team had to adapt as well as learn the new technologies involved in building of our application.
Despite having additional time being factored in, the team was still unable to fulfil the time required to finish the tasks.
With the steep learning curve of Android development as well as the use of Laravel framework and the implementation of XMPP, this in turn caused a slight delay in our progress.



Below is the project progress across the various iterations for the first 6 iterations:

We can categorise the tasks accordingly to the number of hours needed to complete it.
You may have noticed that some of the tasks takes a large number of hours, this is because we have group the certain tasks together.
This includes:

  1. Backend system development
  2. Mobile application development
  3. Test Case Crafting
  4. Functional Testing & Bug Fixing

Center Center Center Center Center Center

Bug Metrics

CodeFather time.png Current Iteration: 7

We have completed 6 iterations till Midterms.

At the end of each iteration, we track the project's bug occurrence on a excel sheet.
View our Bug Metric Documentation here!

We will then rank them by severity and assign points for each bug.
Click here to view the calculation of our Bug Metrics

Center
Center

As seen from the graph above, the highlighted blue area represents the healthy bug points of less than 20 points.
Our team has managed to remain within the healthy range with the exception of iteration 2 and 5.

We have categorise our bugs into 3 different levels, low impact, high impact and critical impact. Through the breakdown of the bugs within each iteration, you may have noticed that Iteration 2 and 5 has the most number of critical impact bugs. This would also explains the high bug score respectively.

In iteration 2, we have just started our development phase, 9 September 2013 - 6 October 2013. Hence due to adaption and learning of new technologies, there have been more critical bugs found during this period. Project Manager has then reviewed the schedule so as to allocate more time for bugs fixing in the next iteration.

Whereas in iteration 5, our main focus was to prepare and stabilise our application in time for our first user testing in iteration 6, 29 January 2014, it has in turn resulted in a series of critical bugs being found. This has in turn resulted in the project manager reviewing the schedule and after consulting the team, decided to install Crashanalytics so as to track our application crashes thereby able to fix and solve all the bugs appropriately. This has in turn improve our application's software quality.

Wellness Metrics

CodeFather time.png Current Iteration: 10

We have completed 10 iterations till Finals.
However this metric was only added at Iteration 3, 6 October 2013.

The overall well-being score on an excel sheet before the start of every meeting.
Click here to view our Wellness Metrics Documentation

Click here to view the calculation of our Wellness Metrics

Overall Wellness Metric.png

The rationale of this wellness metric would allow the project manager to see the overall well-being of the team. This is especially crucial so as to provide support for each other as well as keeping the team's morale up. With this, we can be able to ensure maximum productivity in the project development.

Below is the overall wellness metric across the various iterations:
Center
Center
Center
Center
Center
Center
Center

Decision Making Metrics

CodeFather time.png Current Iteration: 10

We have completed 10 iterations till Finals.
Click here to view the calculation of our Decision Making Metrics

We have made a total of 2 decisions till Midterms.

On 14 October 2013, our mentor introduced us to a company called EventClique, which was a event ticketing company. As their scope and intentions were very similar to ours and we could in turn benefit from each other in the process, they were inclined to create a collaboration with us. However, after some discussion within the team, we have decided that this would not be the focus of our project. We have also consulted our supervisor as well as mentor in this issue. Below shows the decision making metrics.

Despite this, we have plans to collaborate and integrate with EventClique in the future should we have sufficient time within our schedule.

Center

After our first user testing, we have gotten the comments that our design did not have a visual paradigm. This in turn cause usability to be affected as users were unable to identify what steps to do next. In order to focus on the user experience that our application provides, we have then seek the opinions of our various stakeholders on whether to revamp our UI design.

Center


As the total score given by the various stakeholders adds up to 7, we have decided to implement the UI design changes and project manager has then reschedule this into our project scope.

Below are the decision we made aft midterms

Center

Collaboration with Vendors

Being a self proposed project, we wanted to create a business value for our application. As Schedulous is a social meeting application that allows people to organize their meetings, our team has decided to leverage on this point to secure as many vendors as we want to increase the business value of our application. However due to the limited resources as well as the timeframe of the FYP, we have then decided to select a representative group of users with close proximity with SMU thereby posting promotions on our application. This would then allow us to evaluate the business suitability of our application in the corporate world. In addition, as mentioned in the midterms, we have also gotten a vendor validation from EventClique, social ticketing gateway that would like to integrate as well as provide white labels for our application. However weighing our options and resources in our decision metrics, we had to have a fully functional application before integration, hence we decided to focus more on the development of a usable application.

Below shows our Mentor and Supervisor's comments on this decision

Center

Click to view our Vendor Testing here!


Marketing Strategy and SMU Calendar

We have highlighted PR Marketing as our main strategy inviting 1st degree friends as beta tester for our application. As Schedulous has a in-build marketing mechanism which is having the users to invite their friends so as to organize a meeting, it would in turn promote a viral effect to get more 2nd degree friends on board the application. We have since conducted a user testing highlighting the effectiveness of our PR Marketing in achieving our goal of 200 users as well as a retention rate of 20%. In addition, in order to make our application attractive to SMU students, we have incorporate a function which is the syncing of a student's SMU timetable into the calendar allowing users to know their occupied timeslots more clearly allowing them to plan meetings more effectively.

Click to view the effectiveness of our PR marketing here!

Risks and Mitigation Plans

During acceptance, we have identified the Viability Risk.
However as our project progress in the midterm, we have also identified one more risk which is the Misalignment Risk as well as the Technical Risk in the finals.

Click here to view the calculation of our Risk Metrics

Center

Center

Center

Center

Center

Center