Difference between revisions of "IS480 Team wiki: 2011T1 Ascension/Ascension Finals Wiki"
Wk.peh.2009 (talk | contribs) |
Wk.peh.2009 (talk | contribs) |
||
Line 287: | Line 287: | ||
{| class="wikitable" style="text-align:left;background:SeaShell" | {| class="wikitable" style="text-align:left;background:SeaShell" | ||
|- | |- | ||
− | | | + | | |
+ | '''1. Enhanced Android Application Performance''' | ||
+ | |||
+ | Reduce scanning timing by 300%. From 1 min to 15 seconds (for a group of 4). | ||
+ | |||
+ | Kept in-processing and out-processing timing within 3 and 5 seconds respectively. | ||
+ | |||
+ | Total administration time required reduced from 3 minutes to 30 seconds. | ||
+ | |||
+ | |||
+ | '''2. Android User Interface''' | ||
+ | |||
+ | Interactive user interface with easy navigation. | ||
+ | |||
+ | Switch being commonly used modules which expedites tracking procedures. | ||
+ | |||
+ | Ease of switching and checking of instant messenger. | ||
+ | |||
+ | Overall background nature team with engraved buttons. | ||
+ | |||
+ | |||
+ | '''3. Self developed customized Instant Messenger''' | ||
+ | |||
+ | Communication between Traffic Manager and Facilitator – never as easy before. | ||
+ | |||
+ | Communication through messages initiated by Traffic Manager or System. | ||
+ | |||
+ | Simple to type, easy to respond. | ||
+ | |||
+ | Fully designed and customized by us. | ||
+ | |||
+ | |||
+ | '''4. Report Algorithm and Generation''' | ||
+ | |||
+ | Report can be generated as soon as a student step out of the maze. | ||
+ | |||
+ | Sleek integration of report configuration and BIRT tools. | ||
+ | |||
+ | Complicated algorithm to generate results for student report. | ||
+ | |||
+ | |||
+ | '''5. Traffic Management Algorithm''' | ||
+ | |||
+ | Simple and easy to understand algorithm. | ||
+ | |||
+ | Visibility of students within stations. | ||
+ | |||
+ | Decision support tools to highlight crisis maze management to Traffic Manager. | ||
|} | |} | ||
− | |||
===Project Management=== | ===Project Management=== |
Revision as of 14:27, 21 November 2011
Contents
Ascension Finals Wiki
This is Ascension's Finals Wiki page. Click to return to our team's Main Wiki Page.
Project Progress Summary
Project Highlights
Milestone D - Iteration 8
Why do we have a milestone directly after only 1 iteration? This is because iteration 8 which happens in recess week means that we would have the most time to work on our project. The speed of our development and the amount completed by end of this iteration would have high impact and effect on our planning of functionalities and the amount of stuff we can do, leading towards final presentation.
As the hosting manager of Sanctuary house does not allow installation of tomcat apache, we have to use alternative methods. We got a server from Sanctuary House and deployed our reporting server on it, integrate it with our current deployment at the hosting manager. We spent much time on it, to and fro Sanctuary House and was glad that by end of iteration, we already resolved this issue.
1. Changes from UAT C a) Progress report UI b) Android Contingency Plan (master resend and connection switch off)
3. Development Report
*Highlighted in red are functions that are fully completed. |
Milestone E - Iteration 9, 10, 11
In iteration 9, our core to do list is to settle the operations report (which is a core functionality) and to get Instant messenger on Android working. As this is a crucial period of development (before the SMU period closes in on project submission and presentation), we gave our best shot by pushing our development efforts to the maximum. We completed Operations report, Instant messenger on Android and as well our traffic management algorithm were ready, completing more than we have targeted. We have also created the pre-maze view screen to inform the next batch when they are able to go into the station.
*Highlighted in red are functions that are fully completed.
In iteration 10, our core do to list is to ensure that our Android User interface is totally revamped. After which vigorous testing on performance and functionality before we head for our UAT with our clients and facilitators. After revamping the UI, we started the UAT which further uncovered some bugs. During the testing, little suggestions and improvements were given as our clients were all very satisfied with the end to end maze optimization. The entire process now seems sleeker and time taken was reduced much to our clients satisfaction. In this iteration, we also managed to implement speech to text function, as we have some spare time on our timeline.
*Highlighted in red are functions that are fully completed.
The main task for this iteration is to prepare for finals and update our wiki. However, we have some bugs that was brought over from the last UAT. The 1 critical bugs that were brought over was the sending messages to multiple android devices from the portal’s IM. That was resolved in this iteration.
*Highlighted in red are functions that are fully completed. |
Project Challenges
We have faced strong challenges as we embark on this project.
Challenges can be summarized in the following.
Handling Android programming was definitely not easy as I have thought. On the contrary, it has gotten me stuck on many occasions because I simply have no idea how to code that particular function. What seems easy to do on the web becomes painstaking difficult when coding on the mobile platform. In addition to JAVA programming, the user interactions such as swiping left or right have to be handled. Moreover, coming up with an intuitive user interface on a mobile platform is very challenging. I am faced with not only space constraint but also the difficulty of presenting information or buttons in such a way that makes it easy to understand instantly. Integrating both user-friendliness with required functions was no mean feat. I am glad that in the process of learning, I have found and adopted a new form of learning methodology.
Team management was a difficult thing i face in this project. Different people have different expectations and their words mean different things. Hence, to ensure that things get on hand, i have to communicate differently with different people to get things done in the expected manner. Thus it was very important to keep open communication and bring about differences as soon as i realized it on table for everyone to discuss and resolve them.
|
Project Achievements
1. Enhanced Android Application Performance Reduce scanning timing by 300%. From 1 min to 15 seconds (for a group of 4). Kept in-processing and out-processing timing within 3 and 5 seconds respectively. Total administration time required reduced from 3 minutes to 30 seconds.
Interactive user interface with easy navigation. Switch being commonly used modules which expedites tracking procedures. Ease of switching and checking of instant messenger. Overall background nature team with engraved buttons.
Communication between Traffic Manager and Facilitator – never as easy before. Communication through messages initiated by Traffic Manager or System. Simple to type, easy to respond. Fully designed and customized by us.
Report can be generated as soon as a student step out of the maze. Sleek integration of report configuration and BIRT tools. Complicated algorithm to generate results for student report.
Simple and easy to understand algorithm. Visibility of students within stations. Decision support tools to highlight crisis maze management to Traffic Manager. |
Project Management
Project Schedule (Plan vs Actual)
Iterations | Planned | Actual | Schedule Metric | Comments | |
---|---|---|---|---|---|
1 | 1. Requirements gathering
2. Mock up on web-front |
12th May | 12th May | 1.0 | On Time |
2 | 1. Requirements gathering
2. Mock up on Android and Management Portal |
28th May | 28th May | 1.0 | On Time |
3 | 1. Revision of mock up
2. Finalized and developed web front 3. Proposal Submission |
21st June | 21st June | 1.0 | On Time |
4 | 1. Refinements of tracking module requirements
2. Developed node dollars, comment and MCQ 3. Report algorithm refinements 4. UAT A |
22nd July | 22nd July | 1.0 | On Time |
5 | 1. Developed Supermarket
2. Developed Traffic Management 3. Progress Report – Half completed 4. UAT B – Acceptance Presentation |
12th Aug | 12th Aug | 1.6 | The other half of progress report could be developed in time due to the learning curve in BIRT. We rescope after acceptance as the project idea was not focussed. |
6 | 1. Developed scenario and prioritization module
2. Developed progress report configurations 3. Improvements on Traffic Management |
2nd Sep | 2nd Sep | 1.0 | On Time |
7 | 1. Developed maze configurations
2. Completed Progress Report 3. Completed UAT C – Mid term presentation 4. Implemented Swype function |
29th Sep | 29th Sep | 1.0 | On Time. Replaced speech to text with swype function. |
8 | 1. Changes from UAT Feedback
- Traffic Management refreshing page issue - Report UI - Android contingency plans 2. Instant Messenger on Management Portal 3. Development Report |
15th Oct | 15th Oct | 1.0 | On Time. |
9 | 1. Android UI
2. Operations Report 3. Instant Messenger on Android 4. Traffic Management Algorithm 5. Customization of Instant Messenger with traffic management |
25th Oct | 25th Oct | 1.0 | On Time. Shift the designing of poster from iteration 11 to this iteration. |
10 | 1. Testing
2. Day in a life workshop 3. Speech to text function 4. Android Interface Enhancement |
11th Nov | 11th Nov | 1.0 | On time. All UAT except Noel has been completed. UAT with Noel scheduled on 14th Nov. |
11 | 1. Preparation for Presentation
|
21st Nov | 21st Nov | 1.0 | On time. Presentation slides done. presentation date scheduled on 24th Nov, 4pm. |
Project Metrics
Schedule Metrics Our first major road block comes in iteration 5, where we slipped our project timeline and was reminded that our scope was too wide and complex to follow.
|
Bug Metrics After the troubles in iteration 4/5 has blew past, we have always kept our bugs within control. Whenever the bug score increases, we will always re-prioritize and schedule more bug fixing time and meet up more often. After mid-terms, the bulk of the bugs that happens has to do with integration of Android and the portal. We realized the trend and put forward a plan to meet up more often for end to end testing and find out the integration issues that we were facing. With that, we managed to keep our bug portion in control.
Click to access our Bug Log |
Technical Complexity
The following are ranked accordingly to the level of difficulty. 1. Pushing of automated messages from the backend portal to Android Application. This includes the difficulty in trying to understand the push architecture of the technology, manipulating the data received and troubleshooting integration issues. 2. The need to integrate Instant Messenger with Traffic Management and Android Application. 3. Difficulty in retrieving the alarm set in database, configuring the alarm countdown timer and elapsed time in different pages and getting them to sync with each other. 4. Flexible adjustment of scores and weightages if student did not attempt the module. 5. Using BIRT technology to produce intuitive and flexible charts. 6. Algorithm behind the overall maze lapse timing to push suggestions to Traffic Manager. |
Quality of Product
Project Deliverables
Stage | Specification | Modules |
---|---|---|
Project Management | Minutes | Ascension_Meeting_Minutes |
Schedule | Schedule | |
Metrics (Incl. Bug and Change log) | Metrics | |
Presentation Slides | Acceptance Presentation Part I | |
LOMS | Team LOMS | |
Requirements | Functional Requirements | Storyboard v1.0 |
Analysis | Use Case | Use Case v1.0 |
Process Flow Diagram | Process Flow Diagram v1.0 | |
Solution Architecture Diagram | Architecture Diagram v1.0 | |
Design | ER Diagram | Implementation Schema |
Class Diagram | Class Diagram | |
Testing | Test Plan | Milestone A |
Handover | Manuals | User Manual |
Code | Client's Server | |
Deployment Diagram | Deployment Diagram |
Architecture Diagram
Overall
1. Pre/Post Maze
Before the actual implementation of the maze, the internal users are able to access the web application to do configurations to the maze and report, by giving scores to questions used in the maze. The web application is connected to the web hosting server via PHP scripts. AJAX and JavaScript are also used to refresh pages with updated data from the DB, as well as perform validation checks respectively.
After a maze implementation, internal users are able to generate individual reports for individual student’s progress within the maze, development reports for teachers or internal users for summary of the students’ progress in the maze, as well as operation reports for the internal users to analyse maze operations. Reports are done using BIRT and Java to connect to the Apache Tomcat Server located in the Sanctuary House Internal Server, as well as BIRT and Java to connect to the core DB located at the web hosting domain.
2. In Maze
During the maze implementation, the internal users are able to utilize the web application to monitor the traffic flow within the maze. This is connected to the web host server via PHP, AJAX and Javascript. The internal users are also able to send messages to facilitators within the maze by connecting to an internal server located in Sanctuary House, which is coded using PHP, AJAX and Javascript.
During the maze implementation, the internal users are able to utilize the web application to monitor the traffic flow within the maze. This is connected to the web host server via PHP, AJAX and Javascript. The internal users are also able to send messages to facilitators within the maze by connecting to an internal server located in Sanctuary House, which is coded using PHP, AJAX and Javascript.
Instant Messenger
Deployment
Our entire project has been deployed to Sanctuary house server. You may access it via Sanctuary House Server URL
|
User Acceptance Testing
UAT D General Client Feedback: 1. Configurations was nice, was what we wanted 2. Need to also perform the duplicate functions for comment module in configurations [We have done it] 3. Report configuration was easier to use 4. Student Management function is sleek, cool and easy 5. Android UI was so much nicer and better 6. Traffic Management was cool 7. Instant Messenger was sleek and very useful 8. Report was simple, nice and professional
|
Reflection
Team Reflection
We have come a long way since April this year.
We started off understanding and mapping the requirements from their business process and scenario. It was really difficult. Just as how it was difficult for both our supervisor and reviewer to understand, we met the same problem then. Eventually, we have to come out with technical solutions to resolve the business issues, which are hindsight, i do not know how did we achieve it.
During the requirements stage of our presentation, we needed more sessions to understand and map requirements. However, the extra amount of time was difficult as our clients were all working. We resolved this with the clients through a set of procedures to talk to different owners on different portions of the project and took on our initiative to propose and suggest options.
Throughout the project, we faced many difficulties ranging from Android, BIRT, Instant Messenger, deployment and many integration issues. One of those were our wrong deployment to realizing that the actual deployment with hosting manager does not support Tomcat Apache. We eventually resolve it through much communication with the hosting manager and our clients. We decided to re-use one of Sanctuary House server to publish and deploy our report server. Subsequently, as we are implementing our Instant Messenger, we needed to test the broker and port which took place on many nights (as late as till 4am).
We have our differences, disagreements over the course of 7 months, be it the technical aspect, project management, scope, datelines and many other different things we probably find it difficult to remember. But, we always make it a point to talk things out, understand each other and recover from it. Learning how to work together is an important lesson that we all have mastered. A good testament of our relationship is that after going through so much together, we are sticking together as we bid our modules together for next semester to continue working with one another. What really kept us together throughout the 7 months was one important thing that we have done at the start.
We lay out our common objectives, learning points and targets for the project, and when tough times occurs, we always remind ourselves of our goal to be one of the top project and continue to push on! All the way! |
Individual Reflection
Ng Choon Teck
I am so proud that we have completed the project at this stage. At one point it seems to me that it was an uphill struggle.
Honestly, I never thought and could imagined our product being the way it is. Absolutely amazing stuff.
|
Au Cheong Hing
This entire journey has been incredibly enriching for myself. There have been tough times and enjoyable ones of which many of these events has values and lessons to be drawn out of it. I remember the time when most of the members in the team were unhappy with the size of the scope. We felt that it was too big to handle given the amount of resources we had. I personally felt that we did not give ourselves enough time to perfect our solution. But then we learnt together as a team and worked the scope together. We also reduced risk very well by attempting all the unknown early and give ourselves time for progressive learning. For example, I started on BIRT technology early for simple text reporting. Thereafter, I moved on to chart creation using BIRT technology as well. Because BIRT is open source and is an unfinished product, there are many areas which I have to find an alternative solution to my problems. Furthermore, my business scenario is more complex than a simplistic sales figure reporting. All in all, I think I gained a lot in learning to learn, to be sensitive to the larger picture when I am confronted by a scenario and decision making. |
Chen Jun Fan
It has been a long journey since we started from April this year. This FYP project has pushed us to our limits, and made us realize that nothing is technologically impossible. Many a times, when a new suggestion is raised up by our PM to improve our system, we are always bounded by our individual technical capabilities, and would deem the suggestion impossible to be accomplished. However, in the end, most of these ‘impossible’ suggestions became the most value-adding functions of our system.
|
Chee Jing Hui
Tough times don’t last but tough teams do. I guess this sums up what I have thought of this team. We have certainly gone a long way. Like any other teams, we have had disagreements over the scope, functions, user interfaces etc. However, one thing that stands out is that at the end of the day, we will always come together and resolve these issues. And though each one of us has different responsibilities, we will always help one another in troubleshooting problems even if it falls outside of our own scope.
|
Peh Wei Kiat
Reflection here |
Prof Comments
Reflection here |
Client Commments
Didn't have the chance to say it yesterday, (it' so not "me" to say these out in words actually), but I just thought that I should have let the team know about this.. Sincerely a big thank you for a great job on this initaitive. Many thoughts and details have been put in, it's quite obvious - especially when there are initiatives that it's really "we don't know what we don't know" cataology kind of suggestions. (Example, the suggestion when >=50% of the maze is in the red alert, suggestions are prompt, little details like the keyboards of the android apps, drill down graphs etc) I guess it's the last milestone and last few weeks of this FYP project. Thanks guys, and sincerely; it's finishing so, hang it there. (:
|