Difference between revisions of "Team eNable - Midterm Wiki"
|Line 191:||Line 191:|
====Facebook / Twitter sharing====
====Facebook / Twitter sharing====
Revision as of 20:31, 27 November 2010
- 1 Project Progress Summary
- 2 Project Management
- 3 Quality of Product
- 4 Reflection
- 5 Go To
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 UAT with the real end users and gather feedback 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|
Technical Complexity(Details to be added ASAP)
AJAX auto-population of fields
Using AJAX technologies, we help increase the efficiency and decrease error when entering artist information. When the top admin / admin assistant enter the artist name, auto-suggestion using name's already in the database will be done. This increase their efficieny when they have to enter another product by the same artist as it reduce time to enter the same artist information again. And it decrease repeated artist information in the database.
It is complex as AJAX is completely new to most of the team members and it took a while for us to realise that it is done using AJAX even though we've seen something similar done in places such as facebook's search function
Done with the help of TCPDF, PDF files can now be generated for our reports. This will help the client when they need to archieve their statistics or whenever it is needed to be produced.
As OpenCart does not have PDF generation module, we have to start from scratch in terms of researching the available solutions, how to plug it into OpenCart, how to use it to generate the report as we want it to be.
Facebook / Twitter sharing
Quality of Product
Deployments to production site are made after each Sprint (refer to SCRUM framework). No testing server is given for this project so we also use production server as testing server since there will be no real transactions or activities before the website actually goes live. The URL for e-commerce homepage is http://shop.fds.org.sg/ and the URL for admin interface is http://shop.fds.org.sg/admin/ . Since the website is hosted on a shared hosting account with cPanel and no svn is setup on it, the deployment process is manual uploading of the files using FTP.
UAT 1 with client and disabled friends
Testers - Client, Disabled friend from FDS
Location - FDS
Duration - 3 hours
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.
Working together as a team on this project throughout these weeks, our team has learned learned how to manage the stakeholders (Supervisor/Client/Sponsor) and the team itself. We learnt how to manage client's expectations and how to wisely plan the limited resources (Manpower/Time) while applying the IT knowledge in real-life business.
And specifically from this FDS project, we have gained a lot of improvements in the aspects of php and creating simple and intuitive UI designs for disabled friends. Furthermore, we also have enhanced our soft skills like project management skills, research skills and learning-to-learn skills.
Benjamin Gan Reflection