Team eNable - Midterm Wiki
- 1 Project Progress Summary
- 2 Project Management
- 3 Quality of Product
- 4 Reflection
Project Progress Summary
Since after the acceptance stage, our team had made a significant progress with the project. During the 6-week time, we could accomplish 2 of our milestones set, resulting in a fully-functioning store front and most importantly, the simple and effective back end interface specially designed for the disabled friends.
There were no changes in scope of the project at that point of time.
|Functional Requirement||Status (% done)||Confidence Level (0~1)||Member in charge|
|Modifying Existing System||100% (fully deployed and tested)||1||Erene|
|Shopping Cart||100% (fully deployed and tested)||1||Din|
|Order History||100% (fully deployed and tested)||1||Erene|
|Manage Customer's Account Settings||100% (fully deployed and tested)||1||Kyaw|
|Donation||100% (fully deployed and tested)||1||Kyaw|
|Discount||100% (fully deployed and tested)||1||Soe Thet|
|Modify User Permission||100% (fully deployed and tested)||1||Kyaw|
|Back End UI||85%||0.95||Lu Mon|
|Customer Relationship Management||10%||0.85||Soe Thet|
|Tell Friends/A Friend||15%||0.9||Kyaw|
|New Front End UI||15%||0.85||Soe Thet|
|Mobile Interface||0%||0.7||Soe Thet|
As mentioned earlier, our team is using the SCRUM framework. So, all the sprints throughout the project have the fixed duration (15 days in our case). And each sprint has one or more iterations in it. As the lengths of each sprint is fixed, the start and end dates of the sprints will be the same for both Planned and Actual Schedules. The only timelines affected (if there is) will be the lengths of the iterations. So, here, we will compare the planned and actual schedules of the iterations involved from the start till the midterm stage of the project.
|Iteration||Functional Requirement||Planned End Date||Actual End Date||Comments|
|1||Research & Learning||11 Aug||11 Aug||As per planned|
|2||Modifying Existing System||16 Aug||16 Aug||As per planned|
|3||Shopping Cart||23 Aug||23 Aug||As per planned|
|4||Order History||25 Aug||27 Aug||Erene had to spend some time to look into the codes to edit|
|Manage Customer's Account Settings||27 Aug||31 Aug||Kyaw had to take some time to figure out the optimal layout for the page|
|5||Donation||7 Sept||10 Sept||Using PayPal for the very first time, it took Kyaw longer than expected to get it actually work|
|Discount||13 Sept||15 Sept||The client took some time to let us know the most suitable discount type for FDS products; so, Soe Thet could only start working on it a few days later than planned|
|6||Modify User Permission||20 Sept||20 Sept||As per planned|
|7||Back End UI||20 Sept||22 Sept||It took longer than expected for us to come up with the most intuitive and simplest UI for disabled friends|
Our Schedule Metric shows that we were behind the schedule by a significant extent during Iterations 4 and 7. This is mainly because Iteration 4 was our very first time looking deep into the codes and adding in our own. So, it took some time for us to figure out if it is the right action or not. And for Iteration 7, it fell during the midterm weeks and so, all of us were obviously occupied by midterms and proposal submissions for projects.
From our Bug Metric, we can observe that we had some bugs of higher severity as we added in new modules to the existing system. However, we believe these all will gradually become fewer as we move on to the second half of the project.
Detailed Calculation Methods and Action Plans for each metric can be seen here.
If you compare the following risks to those at the initial stage, you will see that only two out of four risks remained. We overcame the other two risks from the initial stage by employing the mitigation plans and we succeeded. For example, for being unfamiliar with php, our team did spend much time on learning it in depth while helping each other out for a faster learning. Similarly, we also set aside a specific time in our schedule to understand how OpenCart works which helped us a lot as we progressed.
Meanwhile, the last two risks from the intial stage remained to be there at the midterm stage as our team felt that those are the risks that cannot be completely removed. However, as we had learned more about the end users' behaviors, we understood more about the impact of each risk on them. For example, from our experience with the real users during UAT 1, we had observed that the look and feel is really crucial for our target users. So, the impact level was increased making the risk level higher than the one we thought at the intial stage.
|Risks||Likelihood||Impact||Risk Level||Mitigation Plans|
|Look and feel of the application does not meet the end users’ needs||Moderate||High||High||Perform heuristic tests and UAT with the real end users and gather feedbacks to ensure a design that appeals to them|
|Maintenance of the system by the client||High||Low||Moderate||Schedule some trainings for the client/admin of the system at the end of the project|
Quality of Product
UAT 1 with client and disabled friends
We had our very first UAT with the client while we were working on our second milestone. That UAT was focused more on the complete store front with partially done back-end interface. We got quite a lot of constructive feedback from the client and also from the disabled friends although there were no major changes demanded by them. However, negetive feedback outweigh the positive ones for our first UAT as you can see here.