Difference between revisions of "IS480 Team wiki: 2012T2 Team Tenacity Midterm Wiki"
(31 intermediate revisions by one other user not shown) | |||
Line 7: | Line 7: | ||
Please visit our website at: http://www.senghupauto.com | Please visit our website at: http://www.senghupauto.com | ||
− | Please view our midterm slides here: [[Media: | + | Please view our midterm slides here: [[Media:Team Tenacity Midterm Slides.pptx|Team Tenacity's Midterm Slides]] |
Our proposal can be found here: [[media:Team Tenacity Proposal.pdf|Project Proposal]] | Our proposal can be found here: [[media:Team Tenacity Proposal.pdf|Project Proposal]] | ||
Line 14: | Line 14: | ||
For more information on the functional specifications of the modules that we have built so far, please refer to: [[IS480 Team wiki: 2012T2 Team Tenacity Project Overview Functional Requirements Role|Functional Specifications]] | For more information on the functional specifications of the modules that we have built so far, please refer to: [[IS480 Team wiki: 2012T2 Team Tenacity Project Overview Functional Requirements Role|Functional Specifications]] | ||
+ | |||
+ | We have also added the questions that we asked our clients to determine the value that we are creating: [[media:Team Tenacity Client Questions.pdf|Questions for Clients]]. We will be explaining more about this in our presentation later. | ||
===='''Acceptance to Midterm'''==== | ===='''Acceptance to Midterm'''==== | ||
Line 23: | Line 25: | ||
Although, the whole fyp journey has been hectic thus far, nothing really drastic or serious has happened so far. Our project is generally going as planned. We are keeping to schedule and we are accommodating changes along the way. Our change management approach is listed below: | Although, the whole fyp journey has been hectic thus far, nothing really drastic or serious has happened so far. Our project is generally going as planned. We are keeping to schedule and we are accommodating changes along the way. Our change management approach is listed below: | ||
− | # Step 0: | + | # Step 0: Try to reject requests |
# Step 1: Assess Request (Classify whether it is of High, Mid or Low priority) | # Step 1: Assess Request (Classify whether it is of High, Mid or Low priority) | ||
## High - Will affect subsequent modules that are going to be built | ## High - Will affect subsequent modules that are going to be built | ||
Line 102: | Line 104: | ||
<tr> | <tr> | ||
− | <td>Implement Changes from | + | <td>Implement Changes from UT</td> |
<td align="center">0%</td> | <td align="center">0%</td> | ||
<td align="center">1</td> | <td align="center">1</td> | ||
Line 110: | Line 112: | ||
<tr> | <tr> | ||
− | <td>Analytics - | + | <td>Analytics - Cluster Analytics </td> |
<td align="center">0%</td> | <td align="center">0%</td> | ||
<td align="center">0.5</td> | <td align="center">0.5</td> | ||
− | <td>We have not started building it but we have obtained advice from Prof. Leong Thin Yin and our client on how we can go about building it</td> | + | <td>We have not started building it but we have obtained advice from Prof. Kam Ting Seong, Prof. Leong Thin Yin and our client on how we can go about building it</td> |
<td>[[IS480 Team wiki: 2012T2 Team Tenacity Project Overview Functional Requirements Analytics|Analytics]]</td> | <td>[[IS480 Team wiki: 2012T2 Team Tenacity Project Overview Functional Requirements Analytics|Analytics]]</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
− | <td>Analytics - | + | <td>Analytics - RFM</td> |
<td align="center">0%</td> | <td align="center">0%</td> | ||
<td align="center">0.5</td> | <td align="center">0.5</td> | ||
− | <td>We have not started building it but we have obtained advice from Prof. Leong Thin Yin and our client on how we can go about building it</td> | + | <td>We have not started building it but we have obtained advice from Prof. Kam Ting Seong, Prof. Leong Thin Yin and our client on how we can go about building it</td> |
<td>[[IS480 Team wiki: 2012T2 Team Tenacity Project Overview Functional Requirements Analytics|Analytics]]</td> | <td>[[IS480 Team wiki: 2012T2 Team Tenacity Project Overview Functional Requirements Analytics|Analytics]]</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
− | <td>Finishing Touch: Implement Changes from UAT | + | <td>Finishing Touch: Implement Changes from UAT</td> |
<td align="center">0%</td> | <td align="center">0%</td> | ||
<td align="center">1</td> | <td align="center">1</td> | ||
Line 262: | Line 264: | ||
|- | |- | ||
|} | |} | ||
+ | |||
==='''Project Metric'''=== | ==='''Project Metric'''=== | ||
Line 460: | Line 463: | ||
</tr> | </tr> | ||
</table> | </table> | ||
+ | |||
==='''Technical Complexity'''=== | ==='''Technical Complexity'''=== | ||
Line 467: | Line 471: | ||
## Assessing the usefulness of the models | ## Assessing the usefulness of the models | ||
## Judging the value created by the models | ## Judging the value created by the models | ||
+ | ## Please refer to our [[IS480 Team wiki: 2012T2 Team Tenacity Project Overview Functional Requirements Analytics|Analytics]] Page for more information on the specifics of the analytics modules that we are going to create | ||
# Formulating the Pricing Algorithm | # Formulating the Pricing Algorithm | ||
## Recommending minimum selling price | ## Recommending minimum selling price | ||
− | |||
## Implementing conceptualized idea into an algorithm | ## Implementing conceptualized idea into an algorithm | ||
#:For example, there is a 'calculator' within the Inventory module that automatically calculates the cost of parts based on prices when a car gets scrapped. This is based on the weights that are placed on each part. Within the Order module, there are business intelligence related features added throughout the process. First, there are price indicators, where appropriate, for each item that is added into the shopping cart. These include the minimum price, last ordered price, last quoted price and intelligence to hint to the sales staff if the quoted price needs to be dropped (based on the quote pattern of that particular item). Also, there are business rules that give rise to flags, that are being queried from the Inventory module. This enables the sales staff to make recommendations with more comprehensive information. | #:For example, there is a 'calculator' within the Inventory module that automatically calculates the cost of parts based on prices when a car gets scrapped. This is based on the weights that are placed on each part. Within the Order module, there are business intelligence related features added throughout the process. First, there are price indicators, where appropriate, for each item that is added into the shopping cart. These include the minimum price, last ordered price, last quoted price and intelligence to hint to the sales staff if the quoted price needs to be dropped (based on the quote pattern of that particular item). Also, there are business rules that give rise to flags, that are being queried from the Inventory module. This enables the sales staff to make recommendations with more comprehensive information. | ||
Line 521: | Line 525: | ||
<tr> | <tr> | ||
<td align="center" rowspan="5">Project Documentation</td> | <td align="center" rowspan="5">Project Documentation</td> | ||
− | <td align="center">Use Case</td> | + | <td align="center">Use Case (Acceptance and Midterm diagrams)</td> |
<td>[[IS480 Team wiki: 2012T2 Team Tenacity Project Documentation Use Case|Use Case (Link)]]</td> | <td>[[IS480 Team wiki: 2012T2 Team Tenacity Project Documentation Use Case|Use Case (Link)]]</td> | ||
</tr> | </tr> | ||
Line 545: | Line 549: | ||
</tr> | </tr> | ||
</table> | </table> | ||
− | |||
==='''Deployment'''=== | ==='''Deployment'''=== | ||
Line 553: | Line 556: | ||
** Client has to input username and password (sensitive information that cannot be placed here) to log into the system | ** Client has to input username and password (sensitive information that cannot be placed here) to log into the system | ||
* The security, business continuity and data backup will be fully taken care of by the service providers | * The security, business continuity and data backup will be fully taken care of by the service providers | ||
+ | |||
+ | |||
+ | '''Deployment Testing''' | ||
+ | |||
+ | <table border="1"> | ||
+ | <tr align="center" style="color:#FFFFFF; font-weight:bold"> | ||
+ | <th bgcolor="black">No. of Easy Bugs (1 point)</th> | ||
+ | <th bgcolor="black">No. of Moderate Bugs (5 points)</th> | ||
+ | <th bgcolor="black">No. of Hard Bugs (15 points)</th> | ||
+ | <th bgcolor="black">Total No. of Bugs Found </th> | ||
+ | <th bgcolor="black">Bugs Outstanding </th> | ||
+ | <th bgcolor="black">Bug Points</th> | ||
+ | </tr> | ||
+ | |||
+ | <tr> | ||
+ | <td align="center">4</td> | ||
+ | <td align="center">2</td> | ||
+ | <td align="center">0</td> | ||
+ | <td align="center">6</td> | ||
+ | <td align="center">0</td> | ||
+ | <td align="center">14</td> | ||
+ | </tr> | ||
+ | </table> | ||
+ | |||
==='''Testing'''=== | ==='''Testing'''=== | ||
+ | * Internal Testing (e.g. Unit, Integration and Regression) is conducted by team at the end of every sprint. | ||
+ | * Please refer to: [[IS480 Team wiki: 2012T2 Team Tenacity Project Management Testing|Testing Framework]] for details on our approach - it also contains bite sized information on Jacob Nielsen's 10 Heuristics | ||
+ | * [[IS480 Team wiki: 2012T2 Team Tenacity Project Management Test Plan|Test Plans & Usability Testing]] will give a good overview of our Test Plans and the UT that we conducted just before midterms | ||
+ | * We conducted one round of UT with 4 business users on 18 Feb 2013 and another round with 31 members of the public (mainly consisting of SMU students) on 22 Feb 2013 | ||
+ | * The users from both categories were aged between 23 and 30 | ||
+ | * The main purpose of the UT was to get feeback from both sets of users based on [[Media:Team Tenacity 10 Heuristic Standards.pdf|Jakob Nielsen's 10 Heuristic Standards]] | ||
+ | |||
+ | |||
+ | '''Clients UT Findings''' | ||
+ | |||
+ | System Template | ||
+ | |||
+ | [[Image:Team Tenacity System Template UT.png|400px]] | ||
+ | |||
+ | Order Management | ||
+ | |||
+ | [[Image:Team Tenacity Order Management UT.png|400px]] | ||
+ | |||
+ | Role Management | ||
+ | |||
+ | [[Image:Team Tenacity Role Management UT.png|400px]] | ||
+ | |||
+ | Subjective Evalution | ||
+ | |||
+ | [[Image:Team Tenacity Subjective Evaluation UT.PNG|400px]] | ||
+ | |||
+ | [[Image:Team Tenacity Subjective Evaluation 2 UT.png|400px]] | ||
+ | |||
+ | [[Image:Team Tenacity Subjective Evaluation 3 UT.PNG|400px]] | ||
+ | |||
+ | |||
+ | '''Public UT Findings''' | ||
+ | |||
+ | Subjective Evaluation | ||
+ | |||
+ | [[Image:Team Tenacity Public Subjective Evaluation 1 UT.png|400px]] | ||
+ | |||
+ | [[Image:Team Tenacity Public Subjective Evaluation 2 UT.png|400px]] | ||
+ | |||
+ | User Control and Freedom | ||
+ | |||
+ | [[Image:Team Tenacity User Control and Freedom UT.png|400px]] | ||
+ | |||
+ | [[Image:Team Tenacity User Control and Freedom UT 2.png|400px]] | ||
+ | |||
+ | [[Image:Team Tenacity User Control and Freedom UT 3.png|400px]] | ||
+ | |||
+ | Error Prevention | ||
+ | |||
+ | [[Image:Team Tenacity Error Prevention 1 UT.png|400px]] | ||
+ | |||
+ | [[Image:Team Tenacity Error Prevention 2 UT.png|400px]] | ||
+ | |||
+ | Help users recognise, diagnose, and recover from errors | ||
+ | |||
+ | [[Image:Team Tenacity Help users recognise, diagnose, and recover from errors UT.PNG|400px]] | ||
+ | |||
+ | Flexibility and Efficiency of Use | ||
+ | |||
+ | [[Image:Team Tenacity Flexibility and Efficiency of Use UT.PNG|400px]] | ||
=='''Reflections'''== | =='''Reflections'''== | ||
==='''Team Reflections'''=== | ==='''Team Reflections'''=== | ||
+ | |||
+ | # Coming to terms with the fact that FYP should be the priority | ||
+ | # Discuss and settle differences in expectations | ||
+ | # Resolving conflicts and miscommunication | ||
+ | # Presenting a unified position before stakeholders | ||
+ | # Striving to improve our project with more feedback and experience | ||
+ | |||
==='''Individual Reflections'''=== | ==='''Individual Reflections'''=== | ||
+ | |||
+ | <table border="1"> | ||
+ | <tr align="center" style="color:#FFFFFF; font-weight:bold"> | ||
+ | <th bgcolor="black">Name</th> | ||
+ | <th bgcolor="black">Picture</th> | ||
+ | <th bgcolor="black">Reflections</th> | ||
+ | </tr> | ||
+ | |||
+ | <tr> | ||
+ | <td align="center">Chua Eng Chang</td> | ||
+ | <td align="center">[[Image:Chua Eng Chang.jpg|150px]]</td> | ||
+ | |||
+ | <td> | ||
+ | <ul><li> Finding balance between getting tasks done and managing capacity of team members | ||
+ | </li><li> Managing expectations of client, supervisor, and teammates | ||
+ | </li><li> Learning the importance of resource allocation and buffer | ||
+ | </li></ul> | ||
+ | </td> | ||
+ | </tr> | ||
+ | |||
+ | <tr> | ||
+ | <td align="center">Sundaram S/O K.VALLIAPPAN</td> | ||
+ | <td align="center">[[Image:Sundaram2.jpg|150px]]</td> | ||
+ | |||
+ | <td> | ||
+ | <ul><li> Handle design and content management of the wiki page | ||
+ | </li><li> Completing allocated programming tasks on time by sourcing for relevant help | ||
+ | </li><li> Working hand-in-hand with the PM to monitor health of project | ||
+ | </li></ul> | ||
+ | </td> | ||
+ | </tr> | ||
+ | |||
+ | <tr> | ||
+ | <td align="center">Gabriel Lok</td> | ||
+ | <td align="center">[[Image:Gabriel.jpg|150px]]</td> | ||
+ | |||
+ | <td> | ||
+ | <ul><li> Effective communication with PM, having to sit down with the PM during task and resource allocation | ||
+ | </li><li> Coping with learning ‘R’ and JavaScript | ||
+ | </li><li> First experience in deployment | ||
+ | </li></ul> | ||
+ | </td> | ||
+ | </tr> | ||
+ | |||
+ | <tr> | ||
+ | <td align="center">Bryan Lim</td> | ||
+ | <td align="center">[[Image:one.jpg|150px]]</td> | ||
+ | |||
+ | <td> | ||
+ | <ul><li> Handle change requests from stakeholders | ||
+ | </li><li> Ability to be a disciplined coding unit (as a team) by instilling good teamwork habits | ||
+ | </li><li> To be able to search for relevant resources to support our coding capabilities | ||
+ | </li></ul> | ||
+ | </td> | ||
+ | </tr> | ||
+ | </table> |
Latest revision as of 22:02, 9 February 2014
Project Progress Summary
Project Highlights
General Information
Please visit our website at: http://www.senghupauto.com
Please view our midterm slides here: Team Tenacity's Midterm Slides
Our proposal can be found here: Project Proposal
A short description of our project can be found here: Project Overview & Description
For more information on the functional specifications of the modules that we have built so far, please refer to: Functional Specifications
We have also added the questions that we asked our clients to determine the value that we are creating: Questions for Clients. We will be explaining more about this in our presentation later.
Acceptance to Midterm
We did not develop extensively for Acceptance because we were only required to show a demonstration of our application. We had built the login and inventory management modules in part and concentrated on working on the mockups (you can also see the evolution of the UI from its inception - during Acceptance, to its current form - during Midterms) for the whole application. We also wanted to set up the project management documents, complete the requirements gathering and come up with the algorithms for the analytics modules before Acceptance. Beyond Acceptance, we have completed almost all the core functionalities (excluding analytics) for the Midterms. We will be demonstrating the capabilities of our application in this Midterm presentation.
Change Management
Although, the whole fyp journey has been hectic thus far, nothing really drastic or serious has happened so far. Our project is generally going as planned. We are keeping to schedule and we are accommodating changes along the way. Our change management approach is listed below:
- Step 0: Try to reject requests
- Step 1: Assess Request (Classify whether it is of High, Mid or Low priority)
- High - Will affect subsequent modules that are going to be built
- Mid - Important functions within modules will be affected
- Low - Cosmetic changes that do not affect functionality
- Step 2: Identify resources available
- Review schedule and see if there is resources available to cater for change management. Over a couple of sprints, we have learnt to be more conservative with our resource allocation so as to cater for possible request for change.
- Step 3: Final Decision
- Answer for each request = Yes or No. If yes - when?
A sample of our change management document is shown below:
Please refer to our change management document for more details: Change Management Document
Beyond Midterm
We will be making changes to the usability of our application based on the results of the first UAT that we had conducted. We will also be proceeding with the building of the analytic components. For more information on the analytics functions, please refer to: Analytics. A point to note is that we will be exploring the usage of 'R' programming to build our analytics components as well. We are proud to announce it as our X-Factor too!
Project Management
* Note that only sprints which involved development work are reflected in this section
Project Status
Functionality | Status | Confidence Level (0 - 1) | Comments | Links |
---|---|---|---|---|
Login and Inventory Management Functions | Fully deployed and tested 100% | 1 | Client has approved and is satisfied | Inventory |
Order Enquiry and Price Recommendation Functions | Fully deployed and tested 100% | 1 | Client has approved and is satisfied | Order, Analytics |
Order Fulfillment and Customer Management Functions | Fully deployed and tested 100% | 1 | Client has approved and is satisfied | Order, Customer |
Order Status Functions | Fully deployed and tested 100% | 1 | Client has approved and is satisfied | Order |
Role Based Access Control | 0% | 1 | We are confident of implement the RBAC function as we have thoroughly discussed it among ourselves and with our clients too | Role |
Implement Changes from UT | 0% | 1 | We are confident of changing all important aspects of usability based on the feedback received | |
Analytics - Cluster Analytics | 0% | 0.5 | We have not started building it but we have obtained advice from Prof. Kam Ting Seong, Prof. Leong Thin Yin and our client on how we can go about building it | Analytics |
Analytics - RFM | 0% | 0.5 | We have not started building it but we have obtained advice from Prof. Kam Ting Seong, Prof. Leong Thin Yin and our client on how we can go about building it | Analytics |
Finishing Touch: Implement Changes from UAT | 0% | 1 | We are confident of changing all important aspects of usability based on the feedback |
Project Schedule (Planned Vs Actual)
Project is going as planned. Sprint 2 ended quite badly because of bad planning. We exceeded our plan by 16 days. However, we managed to re-calibrate our schedule to accommodate higher workload and change requests for the later sprints. Although, we managed to stick to our schedule almost 100% of the time for sprints 3 - 5, we were overworked during a couple of the sprints. This is evident from our Effort Metrics in the next section. Our metrics are based on our re-calibrated schedule that was drawn up immediately after acceptance. Our sprint reports will give a good indication of our progress since Acceptance too: Progress Reports
Sprints | Functionality | Proposal Start | Proposal Finish | Sprints | Functionality | Midterm Start | Midterm Finish | Comments |
2 | Login and Inventory Management Functions | 26 Oct 2012 | 01 Nov 2012 | 2 | Login and Inventory Management Functions | 26 Oct 2012 | 20 Nov 2012 | 100% of the Login functions and 30% of the Inventory Management Functions were completed prior to Acceptance. They were demonstrated during the Acceptance too. The remaining 70% of the Inventory Management Functions were completed after Acceptance. |
4 | Order Management CRUD Functions | 06 Nov 2012 | 15 Nov 2012 | 3 | Order Enquiry, Price Recommendation Functions | 17 Dec 2012 | 17 Jan 2013 | Had to take a break to study for exams and complete school work. |
5 | Order Management Invoice & DO Generation | 17 Nov 2012 | 19 Nov 2012 | 4 | Order Fulfillment and Customer Management Functions | 18 Jan 2013 | 29 Jan 2013 | |
6 | Order Management, Order Tracking & Enquiry | 07 Dec 2012 | 13 Dec 2012 | 5 | Order Status Functions | 30 Jan 2013 | 07 Feb 2013 | |
7 | Customer Management CRUD | 16 Dec 2012 | 19 Dec 2012 | 6 | Implement Changes from UT | 27 Feb 2013 | 28 Feb 2013 | We have not started to work on the feedback yet. We are confident of changing all important aspects of usability based on the feedback. |
Nothing planned | Role Based Access Control | 01 Mar 2013 | 01 Mar 2013 | We are confident of implement the RBAC function as we have thoroughly discussed it among ourselves and with our clients too. | ||||
8 | Analytics - Warehouse Space Optimization | 23 Dec 2012 | 21 Jan 2013 | 7 | Cluster Analytics | 02 Mar 2013 | 12 Mar 2013 | We have not started building it but we have obtained advice from Prof. Kam Tim Seong, Prof. Leong Thin Yin and our client on how we can go about building it. |
9 | Analytics - Customer Behavioral Analysis | 02 Feb 2013 | 10 Feb 2013 | 8 | RFM | 13 Mar 2013 | 24 Mar 2013 | We have not started building it but we have obtained advice from Prof. Kam Tim Seong, Prof. Leong Thin Yin and our client on how we can go about building it. |
10 | Price Recommendation | 25 Feb 2013 | 07 Mar 2013 | 9 | Finishing Touch & Deployment | 05 Apr 2013 | 14 Apr 2013 | We are confident of changing all important aspects of usability based on the feedback after they have been collected. |
11 | Finishing Touch | 12 Mar 2013 | 31 Mar 2013 |
Project Metric
Schedule Metric
Sprints | Functionality | Tracker Index | Health Status |
---|---|---|---|
2 | Login and Inventory Management Functions | 0.56 | Poor - Planned schedule exceeded by 16 days. Underestimated available resources and existing workload when committing to tasks. |
3 | Order Enquiry and Price Recommendation Functions | 1.00 | Good - On time |
4 | Order Fulfillment and Customer Management Functions | 1.00 | Good - On time |
5 | Order Status Functions | 1.00 | Good - On time |
Effort Metric
Sprints | Functionality | Tracker Index | Health Status |
---|---|---|---|
2 | Login and Inventory Management Functions | 0.60 | Too many tasks and too few hours allocated to complete tasks. Over-utilization of resources. Project members were overworked. |
3 | Order Enquiry and Price Recommendation Functions | 0.98 | Fairly good allocation of resources |
4 | Order Fulfillment and Customer Management Functions | 1.05 | Fairly good allocation of resources |
5 | Order Status Functions | 1.08 | Fairly good allocation of resources |
Kindly refer to: Project Schedule for more details on our schedule, and schedule and bug metrics
Bug Metric
Sprints | Functionality | No. of Easy Bugs (1 point) | No. of Moderate Bugs (5 points) | No. of Hard Bugs (15 points) | Total No. Bugs Found | Bugs Oustanding | Bug Points |
---|---|---|---|---|---|---|---|
2 | Login and Inventory Management Functions | 4 | 0 | 4 | 8 | 0 | 64 |
3 | Order Enquiry and Price Recommendation Functions | 0 | 5 | 0 | 5 | 0 | 25 |
4 | Order Fulfillment and Customer Management Functions | 4 | 2 | 0 | 6 | 0 | 14 |
5 | Order Status Functions | 1 | 0 | 0 | 1 | 0 | 1 |
Kindly refer to: Bug Metric for more details on our bug metrics
Project Risks
Please refer to our Risks page for the risks that we had identified prior to Acceptance
Risk | Type | Probability | Impact | Mitigation |
---|---|---|---|---|
|
Skill | High | High |
|
|
Skill | Medium | High |
|
|
Resource | High | High |
|
Technical Complexity
- Integrating 'R' with PHP
- Evaluating what the ‘right’ models would be
- Assessing the usefulness of the models
- Judging the value created by the models
- Please refer to our Analytics Page for more information on the specifics of the analytics modules that we are going to create
- Formulating the Pricing Algorithm
- Recommending minimum selling price
- Implementing conceptualized idea into an algorithm
- For example, there is a 'calculator' within the Inventory module that automatically calculates the cost of parts based on prices when a car gets scrapped. This is based on the weights that are placed on each part. Within the Order module, there are business intelligence related features added throughout the process. First, there are price indicators, where appropriate, for each item that is added into the shopping cart. These include the minimum price, last ordered price, last quoted price and intelligence to hint to the sales staff if the quoted price needs to be dropped (based on the quote pattern of that particular item). Also, there are business rules that give rise to flags, that are being queried from the Inventory module. This enables the sales staff to make recommendations with more comprehensive information.
- AJAX implementations for search functionalities in order and inventory modules
- This allows a sales staff to find out more about a part with as little clicks or keystrokes as possible.
- Integrating FPDF external library into PHP application
- Understanding and utilizing the library to generate PDF invoices
Quality of Product
Intermediate Deliverables
Deployment
- Our application has been deployed on the server provided by Client via Cpanel Control Panel Interface and FTP transfer
- Client just has to access the link: Seng Hup Auto to access the system
- Client has to input username and password (sensitive information that cannot be placed here) to log into the system
- The security, business continuity and data backup will be fully taken care of by the service providers
Deployment Testing
No. of Easy Bugs (1 point) | No. of Moderate Bugs (5 points) | No. of Hard Bugs (15 points) | Total No. of Bugs Found | Bugs Outstanding | Bug Points |
---|---|---|---|---|---|
4 | 2 | 0 | 6 | 0 | 14 |
Testing
- Internal Testing (e.g. Unit, Integration and Regression) is conducted by team at the end of every sprint.
- Please refer to: Testing Framework for details on our approach - it also contains bite sized information on Jacob Nielsen's 10 Heuristics
- Test Plans & Usability Testing will give a good overview of our Test Plans and the UT that we conducted just before midterms
- We conducted one round of UT with 4 business users on 18 Feb 2013 and another round with 31 members of the public (mainly consisting of SMU students) on 22 Feb 2013
- The users from both categories were aged between 23 and 30
- The main purpose of the UT was to get feeback from both sets of users based on Jakob Nielsen's 10 Heuristic Standards
Clients UT Findings
System Template
Order Management
Role Management
Subjective Evalution
Public UT Findings
Subjective Evaluation
User Control and Freedom
Error Prevention
Help users recognise, diagnose, and recover from errors
Flexibility and Efficiency of Use
Reflections
Team Reflections
- Coming to terms with the fact that FYP should be the priority
- Discuss and settle differences in expectations
- Resolving conflicts and miscommunication
- Presenting a unified position before stakeholders
- Striving to improve our project with more feedback and experience