IS480 Team wiki: 2010T1 Flexperts
|Area||Interactive Learning Material|
|Product||E-learning Resource System|
|Team members||Bryan Cheong Wen Cai|
|George Chen Kaidi|
|Harjani Bharat Gobindram|
|Yohann Yezdi Engineer|
|Faculty Supervisor||Kevin Steppe|
|Client||Soo Wai Man|
- 1 Complete Timeline
- 2 Project Progress Summary
- 3 Project Management
- 4 Quality of product
- 5 Reflection
Project Progress Summary
Highlights since the midterm.
Describe the project progress briefly here. Is the project completed?
The project was completed on time. It was deployed on our client's server before our final presentation. Our shippable product, Flexcellence, comprises the Flash Generator and Live Whiteboard applications. The client is very satisfied with our product, and even commented that the Whiteboard has a lot of potential in the field of remote learning, which is in line with CTE’s promotion of e-learning. Our project will be put into pilot testing phase next semester. Professor Kevin Steppe will be using the Live Whiteboard in his Architecture class. While CTE will be conducting training sessions for faculty members to get familiar with the Flash Generator. A dedicated server, apart from the current machine that we are using, will be set up soon. The necessary permissions and discussions are already in progress.
What unexpected events occurred and how were they handled?
- We dropped the delete function from CRUD of the flash generator, because it wasn’t the client’s requirement and was minute.
- We dropped the toolbox function from the Whiteboard, as our client, Prof Kevin, felt that there was no point in duplicating features that were already available to students with PowerPoint.
Describe areas of the project that were particularly difficult and how they were dealt with, whether successfully or not. Again, a few sentences are enough. If there are no challenges, remove this section.
With the help of our supervisor, we caught up after being behind schedule for weeks due to the unforeseen complexity in code. The method we used is by prioritizing by functions:
- We listed all the functions that we had promised to deliver on a board
- We rated them in order of importance, not by sequence
- We took into account precedence of functions in ordering
- Using the new numbering, we set new goals for each iteration
- Having set priorities, unimportant functions were taken out, and will only be completed if there is extra time
By changing our focus from delivering quantity to delivering quality, we found ourselves in a better position to meeting all our client’s requirements punctually. Teamwork wise, we did not limit ourselves to the specific job scope which we initially imposed. Instead, we were very flexible with it and filled in whichever gaps present. This agile teamwork dynamics that we put together often helped us help one another, thus aided us in working well with one another.
Provide more details about the status, schedule and the scope of the project. Describe the complexity of the project.
Project Schedule (Plan Vs Actual):
As you can notice we had certain rough patches. The following chart shows our mitigation strategies which helped overcome our problem in terms of being behind schedule.
The .xls version of the excel with all the formulae can be downloaded from here.
Advantage of the Bug Metric
- To keep track of bugs that can not be solved on the spot
- Severity > 6 in any case = bug fixing day
- Edit a flash object only by changing the xml
- Database feeding changing files at real-time which replaces Live-cycle data service
- Complex file structure due to the integration of 2 applications
- Efficient search without going through database
Quality of product
Our system is designed to take in multiple instances at a time. The flash generator evokes a bat file every time it is called, and these bat files are executed in the order they are queued, and thus supports multiple instances. The whiteboard application creates multiple sessions, and allows multiple ‘rooms’ to be created.
In essence, the target and source are loosely coupled.
We have a bat file that is scheduled to run at start up which performs the below actions: 1) Map our project folder to S:\ 2) Write the IP address to a html embedding a flash to redirect (until we get a static IP) 3) Start Mod Converter, which is a Open office Library 4) Start WAMP and tomcat With this bat file, it will automatically configure the runtime environment for our project.
We conducted a UAT with not only our client, but our end users as well, which includes the Professors and students as well. Our UAT Test plan can be found at [insert same link from Project Deliverables section] For the Flash Generator, we approached 4 Professors and 4 students, who were from SIS, SOB and Dean of Students office .In general, they found the system useful, and expressed an interest to use it in the future. Their suggestions were more on the UI than functionality based. The details of the feedback can be found in the following document.
Our client upon testing had very positive feedback and was very happy. For the Whiteboard, we asked [I don’t know who we asked to demo]. They were in general very happy with the application, although felt that 8 screens might not be enough for all students in the class, and therefore felt this was a limitation. Also, when uploaded to the Whiteboard, the diagrams are slightly small, so not very useful for all courses.
Compile common lessons and reflection for the team and for each team member. Be brief.
As project manager, I had two goals for this project. Firstly, I wanted my group members to work as a closely knitted and united team. The beginning was not easy because we had different opinions on the feasibility of this project. As the semester when by, there were times where progress was slow due to the complexity of our technology. Even when times got tough, we never gave up. I am immensely pleased that we worked together and pressed on to finish this project as a team. Secondly, I wanted my team to deliver a shippable product, something that could be used. Our professor Kevin Steppe showed great commitment in our whiteboard application and he intends to use it in his Architectural Analysis (AA) class next semester. Our client, Dr Soo Wai Man from Centre of Teaching Excellence (CTE) wants to pilot test our Flash Generator too. I am very proud of these achievements.
This project is more than just a technical project. The team got the chance to search for a sponsor, discuss the technicalities with him, gather feedback and improve on our product. I feel that this project is more than academic; it’s practical and puts everything we learnt in and out of classroom to practice. As I have had very good experience and learning outcome from this FYP, I will be doing another one next year.
The most important lesson I learnt from this project is that it’s very essential for business requirements to take into account technical possibilities. Sometime, what are good business requirements may not be able to be translated into technical requirements, so some way has to be figured out whereby the business requirement is addressed in some manner, without putting too much strain on the technical team. Working with a real client, and being able to deliver a working product at the end, was definitely very fulfilling, and really helped me to understand some of the concepts that we are taught in our courses.
The sponsor commented that our whiteboard has potential for remote learning, and is currently looking into that. He also expresses that our system is efficient, and commends our team efficiency in delivering the customized product