IS480 Team wiki: 2013T2 Change-Makers Final Wiki
|Home||Team||Project Overview||Factor||Project Management||Project Documentation||Project Resources||Team Reflections|
- 1 Project Progress Summary
- 2 Project Management
- 2.1 Project Schedule (Planned versus Actual)
- 2.2 Project Metrics
- 2.3 Technical Complexities
- 2.4 Going Beyond Sponsor's Requirements
- 3 Quality of Product
- 4 Reflection
Project Progress Summary
Download our Final Presentation Slides in:
View our web application here.
Log in Information:
Converting Paper Forms to Web Forms
The current business process of our client is done through the use of a paper-based system; which means, all forms that Envisage Education creates for the students to use are printed onto hard copy to be filled in via paper and pen. These forms are created and customized specifically by Envisage Education for the purpose of the Youth Social Entrepreneurship Programmes (YSEP) they conduct. Due to the fact that our clients themselves did not have a specific idea and were not sure of how the forms should look, our team had to customized and design the forms from scratch for them, which creates some technical complexity when we design the forms.
Conducting user test was dependent on programmes available
As our team wanted to conduct our user tests with the real users of our system, we had to coordinate with Envisage Education to ensure our user test dates would match with the programmes they have running. Unfortunately, the dates that Envisage Education would be running their programmes would be too late for our team to gather any substantial feedback and data. Therefore, our team chose to conduct our User Test with Yishun Town Secondary School, which had done their programme on paper and ended in early March.
Underestimating the time needed to conduct our second user test
When our team initially planned for our user test with Yishun Town Secondary School, we thought that a testing period of 2 weeks was more than enough time for the participants to use the system and provide their feedback on it as the YSEP programme had already ended and the participants were simply transferring their documents from paper to the system. However, we did not expect that the students would be busy with their school and external activities and therefore, take a much longer time to complete the user test. In the end, we extended our user test an additional week which gave the students enough time to provide feedback for us.
- As of 18 March 2014, our system was live in beta mode for our user testing with Yishun Town Secondary School.
- As of 9 April 2014, Nan Chiau High School has started using our system for their YSEP programme that has just started.
- As of 16 April 2014, Yuying Secondary School started their YSEP programme with the system.
- As of 17 April 2014, we have a total of 128 user accounts in our system.
- As of 22 April 2014, our team has completely handed over our project to Envisage Education Singapore.
Project Schedule (Planned versus Actual)
|0||Gathering Requirements||23 Aug 2013||Gathering Requirements||23 Aug 2013||Went as planned|
|1||System Login||23 Sept 2013||System Login||23 Sept 2013||Went as planned|
|Manage Organizations||23 Sept 2013||Manage Organizations||23 Sept 2013||Went as planned|
|Manage Admin||23 Sept 2013||Manage Admin||23 Sept 2013||Went as planned|
|2||Manage Beneficiaries||07 Oct 2013||Manage Beneficiaries||07 Oct 2013||Went as planned|
|Manage Supervisors||07 Oct 2013||Manage Supervisors||07 Oct 2013||Went as planned|
|Manage Participants||07 Oct 2013||Manage Participants||07 Oct 2013||Went as planned|
|3||Manage Programmes||21 Oct 2013||Manage Programmes||21 Oct 2013||Went as planned|
|4||Manage Projects||04 Nov 2013||Manage Projects||04 Nov 2013||Went as planned|
|5||Manage Sections||18 Nov 2013||Manage Sections||18 Nov 2013||Went as planned|
|6||Manage Forms - Section 1||02 Dec 2013||Manage Forms - Section 1||02 Dec 2013||Went as planned|
|7||Manage Forms - Section 2||16 Dec 2013||Manage Forms - Section 2||16 Dec 2013||Went as planned|
|8||Manage Forms - Section 3||30 Dec 2013||Manage Forms - Section 3||30 Dec 2013||Went as planned|
|9||Manage Forms - Section 5||13 Jan 2014||Manage Forms - Section 5||13 Jan 2014||Went as planned|
|Manage Forms - Section 7||13 Jan 2014||Manage Forms - Section 7||13 Jan 2014||Went as planned|
|10||Gamification - Points System, Progress Bar, Leaderboard||27 Jan 2014||Gamification - Points System, Progress Bar, Leaderboard||27 Jan 2014||Went as planned|
|Manage Sections - Approve, Reject Sections||27 Jan 2014||Manage Sections - Approve, Reject Sections||27 Jan 2014||Went as planned|
|Manage Forms - Section 4, Upload/Download Files||27 Jan 2014||Manage Forms - Section 4, Upload/Download Files||27 Jan 2014||Went as planned|
|11||Gamification - Points System, Positive Messages||10 Feb 2014||Gamification - Points System, Positive Messages||10 Feb 2014||Went as planned|
|Update Account Settings||10 Feb 2014||Update Account Settings||10 Feb 2014||Went as planned|
|Notifications||10 Feb 2014||Notifications||10 Feb 2014||Went as planned|
|Manage Stage Photos||10 Feb 2014||Manage Stage Photos||10 Feb 2014||Went as planned|
|12||Manage Tasks||24 Feb 2014||13 March 2014||Swapped Create Multiple Accounts due to UT|
|Manage Appointments||24 Feb 2014||Manage Appointments||24 Feb 2014||Went as planned|
|Manage Email Notifications||24 Feb 2014||Manage Email Notifications||24 Feb 2014||Went as planned|
|13||User Testing & Final Revision||10 Mar 2014||User Testing & Final Revision||10 Mar 2014||Went as planned|
|Manage Statistics||10 Mar 2014||Removed||Functionality merged under Manage Task|
|Create Multiple Accounts||10 Mar 2014||24 Feb 2014||Swapped with Manage Task due to UT|
|14||User Testing & Final Revision||24 Mar 2014||User Testing & Final Revision||24 Mar 2014||Went as planned|
Sprint Backlog Metrics
Click here to find out how we calculate our sprint backlog score and the action plan.
View our Sprint Backlog:
Click here to find out how we calculate our bug score and the respective plan of action.
Click here to download our bug logs.
Our bug metrics only quantifies the bugs that were found during our internal user testing after the end of each sprint.
Overall breakdown of bug score
Distribution of bug severity
Bug severity per sprint
Due to the different functionalities and views needed to be displayed to different users within each Project Section page, the page requires many different checks to identify who the current user is in order to display the correct functions and views to them. This is due to the nature of the business activity and rules. Each section requires the approval of the administrator, supervisor and beneficiary; except Sections 1 and 2 which only requires the approval of the administrator and supervisor. The checks and rules are:
- If user is a participant in the project (i.e. team member), he/she will be provided with functionalities to submit the section.
- If the section has been submitted by a participant in the project,
- If the user is an administrator, he/she will be provided with functionalities to approve or reject the section as the administrator, or on behalf of the supervisor or beneficiary.
- If the user is a supervisor in charge in the organisation of the project, he/she will be provided with functionalities to approve or reject the section on behalf of the supervisor.
- If the user is a supervisor in the project, he/she will be provided with functionalities to approve or reject the section as the supervisor.
- If the user is a beneficiary in the project, and if the section is neither Section 1 nor 2, he/she will be provided with functionalities to approve or reject the section as the beneficiary.
- All other users that do not fall into any of the user relations above are not allowed to view the section.
These business rules may look straight forward in vague pseudocodes but due to the required complexity of the database design, the programming needs more than a simple, direct query.
As one of the forms by Envisage Education require a Gantt Chart, our team found an external jQuery plugin to customized and use. However, the jQuery plugin has a unique way of recognizing the data inputs, therefore, we had to convert the data we retrieve from our database to the format which the plugin can understand, and then convert that data back to the original format of our database for the editing of tasks. Further, because Envisage required the functionality to allow the assigning of participants to be in charge of the various tasks, we had to built upon the jQuery plugin to allow a task page that would list out all the tasks and the users that are assigned to them.
Different points are allocated to different projects rather than to the individual users. However, all point notifications are notified to all participants in the selected project with the points when they log into the system. Points are also allocated when a participant submits the different project sections and different points are allocated when the different sections are approved. In order to allocate the points to the different approved sections, there is a need to first check if the section had been submitted before.
Due to the fact that Project Budget Form is a form that is interlinked to the other form which allows the users to create new products, this requires multiple SQL queries that have to be joined and retrieved from multiple tables in order to display out the necessary information for the form.
Create Multiple Participants and Add to Programme
For good usability, this functionality is designed to allow administrators and supervisors in charge to copy inputs directly from spreadsheets (e.g. Microsoft Excel) or type them in manually. To allow both inputs copied from spreadsheets and manually entered inputs to be interpreted/delimited correctly by the system, checks for different types of delimiters (e.g. tabs, semicolons, line breaks) have to be used. Each record to save into the database (i.e. each line/row) is to contain the participant's username (i.e. NRIC/FIN number) (mandatory), full name (mandatory) and e-mail address (optional). Validation checks are in place to ensure that for each row entered, the username is entered and is of a valid Singapore NRIC/FIN format; full name is entered; and optional e-mail address is of a valid e-mail address format and does not already exist in the database.
If the validation checks passes, the participant account will be created and the participant will be added to the programme. If the username (i.e. NRIC/FIN number) already exists in the database (e.g. the participant is an ex-participant of a past programme), it will be added to the new programme without the account being recreated.
After the bulk insertion operation is complete, the system will check the database to ensure the accounts now exist. The result is displayed in a tabular format for easy reading and so that it can be easily copied out to be sent to the administrator in case of persistent failures. The result page is designed to provide the system administrator useful information that can help him diagnose errors (e.g. does the record exist in the Users database table, does the record exist in the Participants table, is the record added to the programme). This will let the system administrator know at which point did the insertion operation fail at. For accounts that failed to be created, the reasons why they failed will be specified in the remarks column.
The complexities are from the smartness of the system to interpret different formats of inputs correctly, performing validation checks on the inputs, performing the bulk operation (and skipping insertion to a table if user already exists and insert to the other tables that the user has yet to exist in), and querying the database to check whether insertion is successful in the required tables and displaying diagnosis-friendly check result.
Initially we decided to use the code from http://www.jquery4u.com/animation/jquery-wheel-fortune-demo/ to do our wheel of fortune as it already contained the logic for randomly spinning to different degrees and resulting in different outputs as expected for a fortune wheel. The only problem we identified was that when we change the image of the wheel, we would have to stick to the precise dimensions of the image in the jsfiddle.
Going Beyond Sponsor's Requirements
To improve the usability of the system, the team went the extra mile to propose and implement several important functionalities that the sponsor did not request for. This is because we view these as important if we really want the system to be really usable.
Create Multiple Participants and Add to Programme
This allows administrators and supervisors in charge of the organisation to create multiple participant and add them to a programme in bulk. When learning more about our sponsor's business processes and operations, we learnt that each programme has tens to hundred over participants and we felt that creating a participant account then adding it to a programme for each participant one by one will be tedious and time consuming. This functionality reduced time and effort greatly, and introduced convenience to users.
The smartness of this functionality allows it to interpret different formats of inputs correctly (spreadsheet friendly and manual entry friendly), performing validation checks on the inputs, performing the bulk operation (and skipping insertion to a table if user already exists and insert to the other tables that the user has yet to exist in), and querying the database to check whether insertion is successful in the required tables and displaying diagnosis-friendly check result. Read more about its complexities in Technical Complexities section.
NRIC/FIN Number Validation
As usernames of participants are the NRIC/FIN number of the participant for unique identification, we implement validation checks to ensure that the NRIC/FIN number is of a valid Singapore NRIC/FIN format. This prevents input of false NRIC/FIN numbers which may cause wrong identification.
Quality of Product
|Use Case Diagram|
|User Testing Documentations|
|User Test 2 Results|
|User Acceptance Test Documentations|
The system is build on the coding practices of the framework (Laravel). As such components of the system such as the queuing service could be easily replaced from the In memory service beanstalkd deployed in the server to Amazon SQS with only one line of configuration changes. Thus possible future demands could be met easily.
As the team also followed Object-oriented Programming (OOP), the concept of inheritance was used in defining classes for functions such as image uploading. And leveraging on the power of IOC containers of the framework, SimpleImageUploader (which uploads images to the application server) was registered to be created whenever an instance of ImageUploaderInterface is requested at any location in the application code. Therefore, switching to Amazon S3 would only require the defining of an AmazonImageUploader class that inherits the ImageUploader and registering the class as the instance for the application.
As there is unpredictability in the number of users using the system at any one time (due to the different programme sizes), we deployed our application together with beanstalkd(Queuing service) on the Digital Ocean cloud. Together with our code flexibility and options of a fast upgrade offered by Digital Ocean, expanding for future demand would be possible with little effort.
To cater for future development, the configurations (database connection, Queue connection and other settings ) are defined for localhost and production separately. The framework would automatically identify if the application is running on localhost or the production environment and apply the required settings accordingly. This would allow future developers of Envisage Education to easily work on the project.
Through our prototyping and user testing, our team has iteratively progressed on the user interface by carefully considering the feedback provided by the various stake holders to come up with a user-friendly application.
System has been deployed onto a cloud server (DigtialOcean) at http://18.104.22.168/ (staging server).
Log in Information
Click here to learn more about how we conduct our internal and user tests.
In additional to our unit testing and integration testing, based on the feedback we received during our mid-term presentation, our team has implemented our Regression Test through the help of Selenium IDE which creates HTML scripts (Selenium Tests) that can quickly perform a browser-based regression automation. We have also done load testing. Click here to learn more about our load testing.
Since mid term, we have conducted an additional user test with real users of the system (Yishun Town Secondary School). As the participants of the user test had previously done their work on paper, the user test was aimed at comparing the new system with the paper-based system.
Summary of Findings
- Users found the system easy to use and intuitive
- Participants generally enjoy the gamification functions of the system
- Participants who used the online appointment function with their beneficiary found it useful
- Participants found filling in the forms online much easier and more organized compared to the paper-based
- Photos which are extremely large could not be uploaded into the system
- Admin and Supervisors prefer the online approval method versus the paper-based methods
- Admin and Supervisors found it easier to track the project progress via the system than on paper
- Users of the system said they would use it in the future
Click here to view more on our results from our user test.
User Acceptance Test
Our team has conducted a User Acceptance Test with our client on 15 April 2014. The objective of this UAT is to ensure all functionalities developed are aligned to the requirements that were initially proposed and agreed upon at the Requirement Gathering and Design/Prototype Stages of our project. It is also the objective of this UAT to act as a form of closure to the project. While we will still provide maintenance for the system till 27 April 2014, the UAT sign off acts as an agreement between our client and our team that no additional functionalities will be added.
Click here to learn more about our User Acceptance Test with our client.
Our team completed our project handover to Envisage Education on 22 April 2014. During this session, we had Stanley, the CEO of Envisage Education to change all necessary information of the various accounts and systems used during this projects, which includes but not limited to, the DigitalOcean server, system admin password, bitbucket repo and passwords.
We also conducted a user training session with some of the staff of Envisage to explain to them how to use the system and how to technical configurations were configured for the project.
|User Guide, Developer and Setup Guide (containing Web Application Access Control Specification), Points and Prizes|
|Administrator, Beneficiary, Supervisor IC, Supervisor, Participant|
|E-mail, YouTube, application super_admin, server, database, codes repository accounts|
Despite our project being a small to medium sized project and only lasting a total of 8 months, the team has learnt that communication is really an extremely key factor for a successful project. Also, we've learnt that with multiple primary and secondary stakeholders in our project, it is important that we properly managed the interests of each stakeholder but at the same time, continuously build a positive relationship with each of them. Lastly, it brings the greatest satisfaction to our team when we see the system we have painstakingly developed over the last few months being used and our client pleased and excited about the future of Envisage Education.
Qian Bi's Reflection
There is no one best way to manage the team members in a project. Everyone has different working styles and have different schedule. Sometimes, unforeseen incidents might occur as well. It takes accumulated experience and lots of communication to lead a team well.
When conducting user tests, no matter how hard you plan for the unforeseen circumstances, it is almost impossible to escape the clutches of Murphy's Law. I've learnt that I need to remain calm, composed but think quick when things do not go according to plan so that I can best come up with a strategy to fix or counter the issue. Also, I've also learnt that every stakeholder in any project has their own interests to protect, therefore, it is important to manage the expectations of the various stakeholders to ensure a successful project.
Working in a team and being lead developer I learn the need to manage between requirements and development and allocating tasks according to the expertise of my developers. Because my developers have no prior expertise in the framework we are using, I pave way and lead them by providing them with the learning resources and guidance needed.I also understood the importance of a proper workflow when working on project’s with multiple developers.
As a front-end developer, this project has given me the opportunity to build a user-friendly system from scratch that will benefit not just our client, but also the community. And when I see students creating projects on our system to help the under-privileged in our society, that is the greatest satisfaction.
Keng Theng's Reflection
I experienced what it is like to work with real clients and in a development team for a real system that is going to be deployed to improve a real business. I have learnt to consider system design pros and cons when trying to meet client’s requests. The backend design should provide good efficiency while trying to achieve good frontend functionalities. My exposure to Laravel framework and development of a complete web application will be useful to my future developments.
The team thoroughly considered the needs of various stakeholders and thought of various ideas on how users will be effectively engaged and utilize the system. They managed to develop a system that would be employed throughout the programs we run in schools, playing a significant role in making the students learning process more meaningful.