IS480 Team wiki: 2010T1 Flexperts/final page

From IS480
Jump to navigation Jump to search

Click here to go back to our Midterm Wiki.

Complete Timeline

Timeline following the Rational Unified Process (RUP) process

Timeline following the RUP process

Project Progress Summary

Highlights since the midterm.

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.

Project Demonstration:

Flash Generator's Output:



Project Highlights:

  • 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.
  • We moved from using the Live Cycle Data Services (LCDS) technology to database technology for our whiteboard.

Project Challenges:

  1. Project was more complex than we thought
  2. Our initial scope was too large

How We Overcame These Challenges

  • We had constant communication with our supervisor and client.
  • We revamped our schedule after advise from our supervisor Prof Kevin.
  • We prioritised our features, and did the important ones first.
  • We focused on quality, rather than quantity.
  • We dropped certain functions that were not part of the client's requirements.
  • We worked as a team and never gave up.

Project Achievements:

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:

  1. We listed all the functions that we had promised to deliver on a board
  2. We rated them in order of importance, not by sequence
  3. We took into account precedence of functions in ordering
  4. Using the new numbering, we set new goals for each iteration
  5. 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.

Project Management

Project Schedule (Plan Vs Actual):

Plan vs Actual Schedule

Project Metrics:

Schedule Metric

Schedule Metrics

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.

Mitigation Strategy

Advantage of the Schedule Metric
  • Assist us to determine whether the progress is behind time / on time /ahead of time
  • Helps us to prioritise our features based on our progress.
  • Helps us to take important mitigation steps such as dropping functions should the progress be behind time.

Bug Metric

The .xls version of the excel with all the formulae can be downloaded from here.

The graph below shows the number of bugs and their severity for an iteration.

Screenshot of the bug listing

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

Technical Complexity:

  1. Learning a new programming language (Action Script)
  2. Complex System Architecture
  3. Editing a flash object only by changing the xml
  4. Database feeding changing files at real-time which replaced Live Cycle Data Services
  5. Complex file structure due to the integration of 2 applications
  6. Efficient search without going through database

System Architecture

Quality of product

Project Deliverables:

Stage Specification Modules
Project Management Minutes Supervisor and Client Meetings
Metrics Bug metric, Schedule metric
Requirements Fact UI Design UI Design
Concept UI Design UI Design
Principle UI Design UI Design
Process UI Design UI Design
Procedure UI Design UI Design
Analysis Business Process Flash Generator Business Process Diagram
Business Process Whiteboard Business Process Diagram
Technical Diagram Flash Generator Technical Diagram
Technical Diagram Whiteboard Technical Diagram
System Architecture Overall System Architecture Diagram
Testing Test plan Test cases
Handover Flash Generator User Manual User manual for the Flash Generator
White Board User Manual User manual for Whiteboard
Code Code for entire solution
Documentation Comphensive documentation for CTE


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.

Open only in SMU domain (Use VPN if at home)

  1. Flash Generator Professor Login
  2. Whiteboard Professor Login
  3. Whiteboard Student Login

Template Outputs

  1. Principle Template Output
  2. Blank Fact Template Output

Development Environment

  1. Flash IDE : Adobe Flash Builder 4 (Student licensing)
  2. Flash Generator : Adobe Flex SDK 3.5 (Open source)
  3. Webapps IDE : Netbeans 6.8 (Open source)
  4. Database : mySQL (Open Source)
  5. Server : Apache Tomcat (Open Source)
  6. Repository: Dropbox

Testing and Feedback:

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 here 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 our supervisor, Prof Kevin Steppe this product was primarily for him. He showed great enthusiasm and commitment in seeing this application become a reality. He was very happy with the application. However, he 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.

Flexperts UAT prof.png Flexperts UAT stu.png
Mockup showing suggestions of Professors Mockup showing suggestions of Students
Flexperts Flashgen(prof)-positive.png Flexperts Flashgen(stu)-positive.png
Mockup showing benefits pointed out by Professors Mockup showing benefits pointed out by Students

The Professors we asked:

  • Jason Woodard
  • Li Yingjiu
  • Jiang Lingxiao
  • Timothy Hsi
  • Ong Hong Seng
  • Vandana Ramachandra
  • Tan Swee Liang


Team Reflection:

Bobby's Reflection


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.

Bryan's Reflection


It is almost impossible to develop a truly finished product. There will always be side details of about how the project can be further enhanced. However, these enhancements must be prioritized and not be allowed to overtake the main functionalities in importance. I learnt that in order to have a working product, we must put aside thoughts of ultimate expansion on concentrate on the functionalities at hand and how to deliver them.

George’s Reflection


This project is more than just a technical project. Our 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. At the end of the day, we do not just submit our project for grading, but actually implement and maintain the product. In fact, what delights me is that we are actually going to use a part of our project for next semester's AA class! That will really meet our client's objective of promoting e-learning in SMU. We believe that what we have done will eventually lead to a movement and for faculty, a shift in paradigm to use e-learning resources to teach.
One key lesson I learnt is to never give up; never be afraid to fail. If we have to fail, fail fast, recover, and rise up to improve. Ultimately, we will reap success, and as we did.
As I have had very good experience and learning outcome from this FYP, I will be doing another one next year.

Urmila’s Reflection


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.

Yohann's Reflection


This project has helped me develop holistically. It has not only helped me to hone my skills at software development but has allowed me think beyond. To list a few things -

  • How to deal with or present your product to a client
  • When to stop trying and change strategies completely
  • How to make a good presentation

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