HeaderSIS.jpg

IS480 Team wiki: 2012T1 Timber Werkz MidTerm Wiki

From IS480
Jump to navigation Jump to search

MID-TERM WIKI

<< MAIN WIKI          << FINAL WIKI


Twa6.png


Project Progress Summary

Overview

Presentation Slides

Timberwerkz has completed Sprint 8 on 3 October and Miletone 4 (6 in total) on 5 October 2012.
There are several key accomplishments since the project inception on 7 May 2012:

  • Development using php Yii framework with little prior knowledge
  • Completed our first Usability Test and currently implementing solutions to given feedback
  • Systematic management of change requests and usability test feedback

Timberwerkz is confident of completing the project within the stipulated schedule shown below:

Milestonesv4.jpg

Project Highlights

Event (#) Highlights / Issue Description
Sprint 1
Unexpected delays in schedule in the last 6 days of Sprint 1

During the first sprint, we realised that we did not schedule sufficient buffer time for change requests from the client. Towards the last week of the sprint, we have several change requests for the View Artiste Portfolio and Edit Artiste General Information stories that resulted in a delay of schedule. Since then, we made sure that there is 25-35% of buffer time scheduled for each sprint duration to handle change requests, bug fixing etc.

Sprint 2
Request from Client to adopt Joomla over Yii Framework

During Sprint 2, the client had suddenly raised a change request to switch from using Yii Framework to Joomla CMS as it will provide them with a non-technical interface to edit pages of the web application. However, after a thorough analysis of the two technologies, we came to the conclusion that Joomla CMS is better catered to the development of websites, which have limited user interactivity - such as blogs, new feeds and product catalogues.

Secondly, while additional features can be introduced to the CMS by installing from Joomla’s suite of extensions, the implementation of these extensions will still need to be customized so as to suit the requirements of the clients, and will still ultimately take up time. Most importantly, as Oak3’s business process of managing auditions is very complex, the automation of this process using Joomla CMS will prove to be a challenge.

Hence, after discussing these concerns with Oak3, we have decided to remain on using the Yii Framework, which will allow us to implement features according to their requirements, as we are essentially masters of our own code.


Sprint 7
Discovered the need for a new User Management story under Manage Account Chapter

The purpose of the User Management system is to improve accountability and communication between a Casting Manager and an applicant. Suppose a scenario: there is an Artiste X who was invited by a first Casting Manager A and both parties have made some correspondence. If Artiste X would like to communicate with Casting Manager A in private, this message can be viewed by more than one users of the same Production House account and this may lead to potential miscommunication.

Thus, we decided to introduce a feature where a main Casting Manager serves as an administrator to add/remove a user account within the production house account.


Back to Top

Technical Complexity

Technical complexity listed in order of highest complexity:

Complexity Description
1. Audition Assignment Algorithm (Scheduling Auditions)
  • What the feature is
  • The decision by the system to allocate the best possible slot for an interviewee based on his/her top 3 preferences
  • What was complex
  • Implementing an Audition Assignment Algorithm (based on Hungarian Algorithm) to allocate audition slots to be based on interviewees’ top 3 preferences
  • The Hungarian Algorithm is chosen because it can help us optimally assign these slots to the top 3 preferences of all interviewees
  • This is done by drawing up a Interviewee-Slot Matrix. The matrix consists of interviewees' priority numbers (ranges from 0 to 2, where 0 has the highest priority and 2 has the lowest priority)
  • The program will then allocate each interviewee a slot, such that the sum of the allocation will be the smallest
  • Refer to this document for complete details
2. Photo Upload Plugin
  • What the feature is
  • A Production House or an Artiste can set a profile picture to best represent himself/herself when the portfolio is edited
  • What was complex
  • Process considerations & implementation such as:
  1. Select Photo (using HTML5 Canvas API)
  2. Cropping (JavaScript API, ebserver crops photo)
  3. Uploading Photos to Amazon S3 Bucket
  4. Cross browser support and Cropping aspect ratio
3. Search Feature
  • What the feature is
  • A Casting Manager can search for Artistes or have Artiste suggested to him/her by the system in the search page
  • An Artiste can search for a Casting Call or have one which is suggested by the system in the search page
  • What was complex
  • Embedding of search query to URL, so that the URL link can be copied to other users
  • Search results are generated simultaneously as user is typing a search entry; and the frequency of querying the server will also be controlled to once every 1.5 seconds so as to reduce overheads on server.
4. Uploading YouTube Video
  • What the feature is
  • An artiste is required to upload a YouTube Video attachment when s/he is applying for a role in a Casting Call
  • What was complex
  • Challenging process of making use of the YouTube API to retrieve an access token that will give permission to upload videos from external sites


Back to Top

Project Management

Project Status

Chapters Status Confidence Level (0-1) Member In-Charge
Manage Portfolio 100% developed and deployed 1 Genevieve
Manage Account 70% developed 1 Calvin
Manage Search 90% developed 1 Nikita
Manage Casting Calls 100% developed and deployed 1 Wee Kiat & Regina
Manage Applications 100% developed and deployed 1 Jun Ru
Manage Messages Not Started 0.9 Wee Kiat
Manage Landing Page 50% developed but deployed 1 Waiting for Client to complete landing page design

Scope (Planned Vs Mid Term)


TW ScopeChanges.png

1. Original scope (Version 1)

  • Chapters are categorized in priority circles:
  • Core, Secondary and Tertiary Features: Developed by TimberWerkz during IS480
  • Good-to-have Features: Features of lower priority; can be implemented in future beyond this project

2. Version 2 Scope

  • During Sprint 3, Manage Experiences (highlighted by red boxes) is replaced by Manage Messages
  • Reason: client felt that Manage Messages has a greater importance that Mange Experiences
  • Original Manage Experiences scaled down to a simpler feature and is classified under Manage Portfolio

2. Latest Scope (Version 3)

  • New User Management feature proposed under Manage Account (Core Features)
  • User Management feature enables the creation of one Production House account unique to the company
  • With the approval from the client, Manage System (highlighted by blue box) is shifted from tertiary features to Good-to-have features so that we can have a more manageable scope


Schedule (Planned Vs Mid Term)

TWSchChange.png

No changes to proposal and acceptance milestones; and only milestones after them have significant changes to the schedule.
Refer to the full current timeline.

Change #1: Schedule an Interview, Select and confirm audition availability stories shifted to Mid Term
Change #2: Manage Experience chapter is simplified to a story under Manage Portfolio
Change #3: Manage Systems chapter is removed, shifted to Good-to-have features
Change #4: New User management stories added under manage account and Manage Messages chapter takes the place of Manage Systems


Project Metrics

Schedule Metric

The diagram below shows the burn-down charts of the 8 sprints we have completed thus far.



Key Issues

1. Sprint 1:

  • There was a delay in the last 6 days of the Sprint as we did not schedule buffer time for change requests.
  • Since then we have allocated 25-35% of the time in the sprint as a buffer to fix issues such as bugs or change requests.

2. Sprint 3:

  • There was also a delay on the last day of Sprint 3 as a last minute change in requirements of UI
  • This is because there was some last minute requirement changes and our developer required more time to work on the task.


Links
1. Schedule Metric Calculation
2. Schedule Metric Documentation for Sprint Number:(Not Locked) 1, 2, 3,4, 5, 6, 7, 8


Burn-down Charts

Schedule 1.pngSchedule 2v2.png

Schedule Ratio Charts

ScheduleRatioChart1.pngScheduleRatioChart2.png

Bug Metric

TW Number of bugs.png
TW BugSeverity.png





Number of Bugs Found

There was a pike in the number of bugs found in Sprint 5. This is due to the more rigorous testing conducted on our application in preparation for UT1 in Sprint 6. We began testing at least one week before the end of the sprint, as compared to a few days before for other sprints.

Also, there was one bug that is carried over from Sprint 6 to 7 because we did not have sufficient time to resolve it








Bug Score Value Response
6 and below Developers resolve issues within the Sprint
7 - 9 If bug is discovered in a feature that is not a core feature, schedule debugging in the buffer of the sprint
10 and above Developers attempt to resolve bug immediately. Project Manager relieves member of his current task and set him in charge to resolve bug
Bug Metric Severity Chart

This Chart shows the corresponding severity score with the number of bugs found. Again, the impact was the highest in Sprint 5 because of UT1 preparation.

Links

1. Bug Metric Calculation
2. Bug Metric Documentation




Risk Management

Prioritised Risks as at mid-term. Full entries as shown under the Project Management and Technological Implementation headings in the Risk Management Table.

S/N Risk Description Impact Impact Level
(High/Med/Low)
Likelihood
(High/Med/Low)
Mitigation Strategy Status

2

Client Management

2.1

  • Change requests expected from client as Casting3 application is built from scratch
  • Scope and schedule of the project affected

High

High

  • A Change Request Log is created to manage change requests more effectively

Mitigation strategy
in force

2.2

  • Clients do not know the exact requirements of the new application
  • Application may not serve the needs of the company effectively

High

Medium

  • Using Low fidelity prototype (UI mockups) to communicate and ensure that requirements are properly understood.

Mitigation strategy
in force



Change Request Management

  • In every meeting with the client, change requests raised are logged into the change request log as shown below.
  • The red box shows an example entry. A decision of whether to implement the change is based on the priority of the request and time needed to develop the request.
  • Priority is categorised as MUST, SHOULD, COULD or WON'T
  • Time is categorised as VERY SHORT, SHORT, MEDIUM, LONG or VERY LONG
  • View Change Request Log


TWChangeRequestLog.png


ChangeRequestDecision.png







  • The following chart on the right shows our Change Management Decision Process (How we decide an implementation based on the priority and time)

  • Scenario #1: If a priority level is a MUST, then we will implement the request

  • Scenario #2: If a priority level is a SHOULD, then we will implement the request if the time to do so is VERY SHORT - MEDIUM

  • Scenario #3: If a priority level is a COULD, then we will implement the request if the time to do so is VERY SHORT

  • Scenario #4: If a priority level is a WON'T, then we will not implement the request


Back to Top


Quality of Product

Intermediate Deliverables

Stage Specification Modules
Project Management Minutes
Metrics
Requirements Product Backlog
Change Requests Log
UI Mockups & Videos
Analysis Use Case
Design Deployment Diagram
Logical Diagram
Testing User Test Plan


Deployment

  • Staging & Development Environment: deployed on Amazon EC2 Micro Instance
  • Database: Amazon RDS Instance
  • Web Services: Amazon Simple Email Service & Amazon Storage Web Services
  • Web Links:
  1. Casting3 Staging Environment
  2. Casting3 Development Environment
  3. Deployment diagram v0.4




Back to Top

Usability Test 1

Objectives

1. Determine that the usage of the features in the application are consistent to the expectations of the users (acting as of Casting Managers & Artistes)

2. Obtain feedback from users such as to improve the usability (learnability, efficiency, errors, satisfaction) and aesthetics of our application



Scope of Test

Usability Test 1: A basic set up of the test at the office of Oak3 Films
S/N Features Artiste Prod. House
1 Registration / Log in / Log out Greentick.png Greentick.png
2 Change / Reset password Greentick.png Greentick.png
3 View / Edit Artiste Portfolio Greentick.png -
4 Search for casting calls / View suggested casting calls / Favourite a casting call Greentick.png -
5 Apply for a casting call / View all applications Greentick.png -
6 View / Edit Production Portfolio - Greentick.png
7 Search for artistes / View suggested artistes / Favourite an artiste - Greentick.png
8 Create / Edit a Casting Call / View all applicants of a Casting Call - Greentick.png
9 Invite an artiste to a Casting Call - Greentick.png


Session 1 (Casting Mgrs)


Session 1 was successfully conducted on 7 Sept 2012, 2 – 6pm at the office of Oak3 Films.
A total of 7 staff members from Oak3 Films assumed the role of a Casting Manager participated: #Dennis (Head of Production)

  1. Jonathan (Producer)
  2. Jeremy (Production Assistant)
  3. PeiHua (Production Assistant)
  4. Jazz (Graphics)
  5. Dinesh (IT Executive)
  6. Ana (Secretary)



Feedback from Session 1 of the Usability Test is recorded in the User Feedback Document
View also our Response Plan to Feedback (Casting Mgrs).

Most common feedback:

Solution: Display all tooltips by default to users on the first time they create casting calls
Solution: Automatically scroll to bottom of page when date input is selected
Solution: Bring users directly to "edit portfolio" page the first time they sign up


Results from Casing Managers End-of-Test Qualtrics Survey (Extract):

Chart 1: 2 candidates expressed possibility that the system is unnecessarily complex
Watch how we conducted Session 1 HERE

Session 1 Conclusion

Inferring from the above table, we identified that some functions of the application may not be sufficiently intuitive (E.g. Items #2, 3 and 4). Perhaps this explains why some testers felt that the system is slightly complex (as shown in Chart 1).

One of the solutions to get around this is to introduce some simple tooltips to allow the user to get familiarized in using the system. We have also implemented some changes to improve the overall usability and intuitiveness of the application. View our Response Plan to Feedback (Casting Mgrs).

Nevertheless, many users expressed that on the whole, the system is easy to use, streamlined, is “time-saving” and user-friendly.




Session 2 (Artistes)

Session 2 was conducted from 9 - 14 Sept 2012
A total of 18 testers who assumed the role as Artistes participated.

Feedback from Session 2 of the Usability Test: Artiste User Feedback
View also our Response Plan to Feedback (Artistes).

Most common feedback:

Solution: Bring user to edit page on the first visit to the account and change all edit buttons to blue colour
Solution: Add label to each information row
Solution: Use 3 conventional drop down number selection
Solution: Change the layout to look more like a form


Results from Artiste End-of-Test Qualtrics Survey (Extract):

Chart 3: around 8 candidates felt that the system is unnecessarily complex
Chart 4: 6 candidates believed that they need assistance to use this system

Session 2 Conclusion

Session 2 provided us with much insights especially to the overall intuitiveness of using the system. The top few feedback involves how candidates had difficulties in navigating and using the system; and we have since made changes to the feedback given. Charts 3 and 4 further support this issue, where many candidates believe that the system is either slightly complex or they would need the help of a person to fully exploit the system.
View our Response Plan to Feedback (Artistes)



View our testing methodology and supporting documents.



Reflections

Member Reflections Member Reflections
TWjunru.png
  • Managing the trade-off between project scope and constraints (i.e. time available and manpower) as there were at least 2 major scope changes
  • Had to prioritise tasks effectively at hand and communicate them to the team so that deadlines are met
TWwk.png
  • Learnt the importance of engaging with actual users to ensure that the system is designed according to their expectations
  • Keep the design of new features consistent with existing conventions to reduce users' learning curve in using the feature
TWnikita.png
  • Realised that getting real users has more effective and accurate results than getting testers to "act" as a particular test role
  • Learnt to analyse the issues and proposing appropriate solutions to the results from the Usability Test
TWgen.png
  • Learnt the importance of client management i.e. managing their expectations of final deliverables and, making sure that requested changes are clearly stated and understood by client
  • Understood more about javascript and jquery development while implementing tooltips
TWreg.png
  • Felt that good communication with the client is critical so as to develop application to their expectations (i.e. understanding their requirements, clarifying business processes)
  • Gained deeper understanding about good UI practices (e.g. placement/colour of buttons, layout etc)
TWcal.png
  • Managing and prioritising change requests is critical to keep project on schedule
  • Everyone is pretty new to each other; in fact, some of us are working together for the first time. Learn to make use of each other’s strengths and weaknesses when certain help is needed
Back to Top