HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2014T1 Team Epsilon MidTerm"

From IS480
Jump to navigation Jump to search
Line 228: Line 228:
 
==Reflection==
 
==Reflection==
  
===Team Reflection===
+
===Team Reflection & Learning Outcome===
  
 
Our team learnt that communication between team members and the sponsor is vital in a developing a software project. Managing changing requirements is something that we should be expecting to encounter in every project we do, but the key is in evaluating the change requirement proposed, and see how it can be fit into the current planned schedule. If the change requirement is important to the business process, and is of high business value, then some other parts of the scope has to give way. Besides prioritizing the functions and scope, we should also have mitigation plan in place to handle change and risk management.
 
Our team learnt that communication between team members and the sponsor is vital in a developing a software project. Managing changing requirements is something that we should be expecting to encounter in every project we do, but the key is in evaluating the change requirement proposed, and see how it can be fit into the current planned schedule. If the change requirement is important to the business process, and is of high business value, then some other parts of the scope has to give way. Besides prioritizing the functions and scope, we should also have mitigation plan in place to handle change and risk management.

Revision as of 17:55, 6 October 2014

Team Epsilon Logo.png.png

Home   Project Overview   Project Management   Documentation   Team

Current   Mid-Term   Final

Project Progress Summary

Mid-Term Presentation Slides: Click Here

For the rest of our submission deliverables, Click Here

Project Highlights

  1. Project Business Value
    1. Crowdsourcing feedback platform
    2. Island-wide implementation
    3. Caters to current user's needs
  2. List of requirement changes
    1. Added Edit Agency under non-core functionality in iteration 7
    2. Added Audit Log under non-core functionality in iteration 7
  3. Schedule Updates since Acceptance
    1. App Store Submission delayed from 7th Sep 2014 to 5th Oct 2014
    2. App submitted to App Store for approval on 4th Oct 2014
    3. Used up buffer period after iteration 6 to complete unfinished core functions
    4. Additional requirements requested are scheduled in iteration 7 where the team will try to complete as much functions as possible

Project Management

Project Status

There are a total of 9 iterations for our project. As of Mid-Term, we have just embarked on the start of iteration 7.

This is the last feature-development iteration, where we will be attempting to complete as many secondary functions as possible before wrapping up the development with System and User Interface refinements in iteration 8.

Iteration 9 will be the time period where we attempt to gather real public user and feedback data from users who download our app from the App Store.

A marketing campaign is also currently in discussion with our sponsor, where we plan to attract public users to use our system by offering incentives such as the chance to win vouchers.

The iOS application has been submitted to Apple App Store and is currently pending approval.

Project Schedule (Plan Vs Actual)

Project Metrics

Absolute Days Delayed

Epsilon Midterm Absolute Days Delayed.png

This is a snapshot of the mid-term absolute days delayed.

For the most updated absolute days delayed, Click Here


Schedule Index

Schedule Index Chart Epsilon.png

All iterations so far are on time, except for iteration 6.

However, we have a buffer period scheduled right after iteration 6 to catch up on unfinished functions.

After factoring the buffer period into the equation, iteration 6 is on-time too.

This is a snapshot of the mid-term schedule index.

For the most updated schedule index and how it is calculated, Click Here



Effort Metric

Epsilon Midterm Effort Metric.png

This is a snapshot of the mid-term effort metric.

For the most updated effort metric, Click Here


Bug Metric

Epsilon Midterm Bug Metric.png

This is a snapshot of the mid-term bug metric.

For the most updated bug metric and how it is calculated, Click Here


Project Risks

Risk Consequences Likelihood Impact Level (Derived) Mitigation Strategy Status
Updates to iOS Project schedule may be delayed to support the new iOS version release High High A Research into iOS update roadmap to better gauge when new versions will be released (Apple often seeds beta versions to developers early) as well as what changes will come with it.

Evaluate if there is a need to allocate time to support the new update. If there is, adjust the schedule accordingly, taking into account the overall development progress using the critical path.

Mitigated
Change or increase in requirements Project schedule may be delayed to accommodate the changes to the project.

Increase in project requirements may lead to scope creep.

Medium High A Work with the sponsor to create a requirement document that both parties agree on. Come to an understanding that any change requests would be subject to the other party’s approval based on his/their judgement of the necessity of the change.

Create a change management metrics to help with the change management decision. Keep track of all change requests.

Mitigated
Team member pulls out of project Team might be overwhelmed with project scope due to the sudden reduction in manpower Low High B Reshuffle roles and responsibilities to fill up the gap created by the team member’s exit.

Source for another suitable team member if possible and bring him/her up to speed.
Consider scoping down to make the project more manageable for the smaller team.

Mitigated

This is a snapshot of the top 3 most interesting mid-term risk management list.

For the most updated and full list of risks, Click Here

Technical Complexity

Information Exchange between Ruby & iOS

iOS Annotation Design Process

Apple Push Notifications

Quality of product

Intermediate Deliverables

Stage Specification Modules
Project Management Minutes Meeting Minutes
Metrics

Schedule Metric, Bug Metric, Effort Metric, Change Log, Product Backlog

Risk

Risk Management

Requirements Storyboard Comic Storyboard
Design Priority Diagram Priority Circle, Priority Table
Analysis Use Case Use Case Diagram, Use Case Description
Prototype User Flow

iOS User Flow, Admin User Flow, Agency User Flow

Design ER Diagram E-R Diagram
System Architecture System Architecture
Testing Usability Testing 1 UT 1 Details & Follow-Up Actions

Deployment

iOS App: Awaiting App Store Approval

Website:

Testing

User Testing 1: Click Here

Reflection

Team Reflection & Learning Outcome

Our team learnt that communication between team members and the sponsor is vital in a developing a software project. Managing changing requirements is something that we should be expecting to encounter in every project we do, but the key is in evaluating the change requirement proposed, and see how it can be fit into the current planned schedule. If the change requirement is important to the business process, and is of high business value, then some other parts of the scope has to give way. Besides prioritizing the functions and scope, we should also have mitigation plan in place to handle change and risk management.