HeaderSIS.jpg

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:


Flash-Generator


This is an example of an output that students will see. This will be used out of classroom context for self learning.

Whiteboard Output:


Whiteboard


This animation shows snapshots of both the professor's and students' view. It shows the process of setting up, logging in, uploading, displaying and downloading of the image/powerpoint file in its life cycle.

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:

  • Project was more complex than we thought
  • Our initial scope was too large
  • We were way behind our schedule during mid-term.

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 did not limit ourselves to the specific job scope we initially imposed.
  • We were flexible and had showed agile teamwork dynamics.
  • We never gave up.

Project Achievements:

  1. CTE is piloting our Flash Generator
  2. Professor Kevin Steppe is going to use our whiteboard in his Architectural Analysis (AA) class next year.
  3. We met all of our client's requirements punctually.

Project Management

Project Schedule (Plan Vs Actual):

Plan vs Actual Schedule

Project Metrics:

Schedule Metric

Schedule Metrics

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

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
Property of CTE Code for entire solution
Documentation Comphensive documentation for CTE

Quality:

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.

Deployment:

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 for Flash Generator can be found here 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.

Our UAT Test plan for the Whiteboard can be found here.We asked our supervisor, Prof Kevin Steppe as 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 we should have given him the option of choosing how many student whiteboard rooms he would like. Currently, there are 8 fixed student rooms.

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


Reflection

Team Reflection:

Bobby's Reflection

Bobby.jpg

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

Bryan.jpg


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

George.jpg


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

Urmila.jpg


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

Yohann.jpg


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