IS480 Team wiki: 2011T1 Geographia Final

From IS480
Jump to navigation Jump to search

Project Progress Summary

After the midterm presentation, we negotiated with the sponsor and managed to convince him to accept the Advanced Admin Module. Since this module was initiated by us, we proposed the features of this module, taking into consideration of the time that we left and communicated with the sponsor. After the requirements were settled, we put our effort to come up with not only the work flow for this module for different teachers for different schools but also for the data format, storage and retrieval as we would also need to solve the performance issue arose from the Development module.

With our utmost commitment and effort, we were able to overcome all these hardships and successfully completed our project, proudly providing three front end modules, namely, Climograph, Global Climate and Geography of Development, together with the Advanced Admin Lesson Customization, Super Admin and back end application: User Behavior Tracking.

Project Highlights and Challenges

As in every endeavor, we faced challenges in our learning journey and to our surprise, the three most major challenges stem from project management but not from the new technology adoption, which came under our control gradually. The three challenges we faced which also made us grow together during our journey are: 1) Taking up a project filled with vague requirements 2) Negotiating with sponsor to accommodate advanced admin module, and 3) Technology change request.

1. Taking up a project filled with vague requirements - entering a real world

Our project sponsor engaged us first approached us to materialize his ideas on creating an interactive and effective geography course-ware for 4 geography modules , namely climograph, global climate, historical storms, and urbanization, with one back-end user behavior tracking module. However, he was still in liaison stage with the pilot user group and was not very certain of detailed requirements except for the first module. Moreover, we were warned that historical storms and urbanization modules are likely to be changed. It was hard for us to gauge our scope and to prepare ourselves with technical skill during the summer.

1.1 Attempting to live with uncertainties - Incremental requirement gathering and building quick prototypes

In the beginning, as none of us have worked on a real world project, we were uncomfortable with not being able to know all the requirements from the start and to expect the big changes. We even tried to get to know the detailed requirements for at least two modules in advance. But to no avail. Gradually, our group tried to live with the uncertainties by

  1. meeting up with our sponsor weekly
  2. asking for detailed requirements for the next module only near the end of the previous iteration
  3. making prototypes to let our sponsor and client look and feel while avoiding costly changes
  4. designing flexible system

Although our approach could not get rid of the uncertainty in scope risk, we are more or less sure that we are delivering what our client and sponsor really need.

1.2 Module Change Request for 2 times & we were cushioned

As expected, we were requested to change the Historical Storm module to Climate Change module and later to Geography of development especially between Acceptance and Midterm Presentation. We kind of wasted about two weeks because of the changes in researching the concepts, building prototypes and equipping ourselves with new technical skills. However, because of these changes, we have also learnt how to better manage the sponsor uncertainties while not wasting too much of our effort and time.

We have also learnt along the way the importance of choosing the appropriate prototyping software. At first, we built the draft interface in flex and it takes usually about one week to let the sponsor get the look and feel. The changes made were very costly as we needed to throw some codes completely. Later, we tried several wireframing softwares such as mockflow , Pencil Project to better communicate with the Sponsor. However, as those softwares were emphasizing more on website building while our focus is on each module user interaction and transition, we needed to look for an alternative and it is Microsoft Powerpoint. Although we in general use it for presentation purpose, because of our project challenges and Flex nature we have found that powerpoint is also a good software to mock up an interactive application. In it, we can show how the transition would be when the user click certain button, before and after stage of a component due to user’s interaction. We managed to stimulate like a real Flex application without committing ourselves to coding the uncertain parts.

We have as well learnt to appreciate the importance of prototyping prior to implementation and frequent communication especially when our sponsor changed the historical storm module to the climate change module and later to geography of development. The 2 module change request comes only after we have built our prototypes but these two incident only costed us about one week and we did not have to throw a single line of code. If we were to build the prototype in flex, our group would have been reluctant to accept the change as building the prototype will usually take at least one week and the opportunity cost is high.

2.Technology Change Suggestion – choosing the road less travelled

With the geography of development module request, being a GIS Prof. and having handled thematic map in Flex, our sponsor suggested us to change the whole project to javascript. He reasoned that Flex has severe performance issue when it comes to thematic map as they are very detailed and large in file size. Our detailed decision making and our team management during that time could be found hereunder Crossroad I and II.

3. Negotiating with sponsor to accommodate advanced admin module

3.1 Getting to know the real users’ need & proposing admin module

After we have built the first two modules, climograph and global climate, we let our pilot user group including teachers to test out and welcomed any form of feedback and request. The most prominent and consistent teachers’ request in global climate module was to change some weather stations. At that time, the teachers needed to email us with the data to make the changes. Our team immediately anticipated that the application owner, currently our sponsor, will need to cater to all these kind of request if we do not provide the functionality for teachers to customize the lesson content or data on their own. Hence, our team tried to persuade our sponsor to let us substitute urbanization module with admin module, which will reduce unproductive workload on him in case the software is brought to the commercialization stage. However, our sponsor had strong strategic reasons and was reluctant to change his mind.

3.2 Sponsor point of view

As this is our sponsor’s first time in initiating a geography courseware for secondary students, he just had an intention of proving his concepts and hence he first requested us to focus on front end designs. Our sponsor would like to take up our suggestion only when there is a favorable acceptance of the courseware. Moreover, our sponsor was quite reluctant to let his server used by the teachers.

3.3 Supervisor Suggestion – the turning point

When we brought up the same dilemma to our supervisor Prof. Jason, he asked us to respect our sponsor’s concern but at the same time, pointed out to capitalize the data load and save from local disk functionality from climograph module and allow Prof. Kam to switch it off if he really does not want it. Although the suggestion sounds simple and commonsense, we were at first blind from this option as we were in a developer mindset,who just look out to fulfill what are requested, and not that of an application owner who welcome new feature if it was value add. Indeed, a turning point for all of us. Hence, before midterm we duplicated the data load from local disk function within climograph module and integrated it into the global climate module. Certainly, we were aware that the uploading from local disk function to make content changes come with shortcomings- teachers would need to share the new content in thumbdrive or via email but we felt that we should not nag our sponsor further.

3.4 IS480 review panel request during the midterm presentation

As expected, we faced critical feedback from the IS480 review panel for our admin module at that time, for global climate module only, during our midterm presentation. The two main points were to

  1. Instead of XML, the web native data format let the users use CSV, the more user friendly data format which they can use to edit the data in excel instead of using the data grid we built. Although our data grid, which we replicated from climograph module, in Global Climate module could give more precise and detailed error messages side by side, teachers need to have internet connection to edit data which usually turns out to be a lot and data has to be manually keyed in - copy pasting the whole chunk of data was not there.
  2. The second feedback was to make the admin more advanced so that the updated data by the teacher could be retrieved at one click -refreshing the browser.

Hence, after our midterm presentation, we brought up the same request to our sponsor to let us do the advanced admin in which teachers can upload the data to the server and share easily with the students and other teachers. Our sponsor finally allowed. We have also managed to change our front-end data editing format to CSV.

Thanks to IS480 review panel candid feedback and our sponsor open-mindedness, our system can now be used to teach related geography concepts effectively, collaborate in lesson planning, and the content is easily sharable. We are also proud that we have managed to merge the feedback coming from two different ends and have come up with a better and more flexible system. Moreover, during our sponsor’s workshop with 16 Geography teachers from 7 different schools, there was a consistent positive feedback on the flexibility that the admin module gives them as Ministry of Educational provide general syllabus and allow each school to adopt its own curriculum. During the workshop, we have found out that teachers from different school focus on different regions such as tropical region, asia pacific or world in general.

Project Management

Project Schedule (Plan vs Actual)


IS480 Team Geographia:Weekly Schedule

Project Metrics

Bug Metric


During iteration 5 that we developed advanced admin, the number of bugs was the highest due to the integration of Development module with Advanced Admin Module for retrieving the indicator file for different classes from the server set by different teachers.

Schedule Metric


There is a significant delay during iteration 4 (the development cycle for the Geography of Development module) as we needed to incorporate the performance optimization. We experienced the unexpected major performance issue for that module due to the large data which could not be handled by the preferred data format (XML) for Flex application. Thus, we had to sit back and brainstorm on how we want to store the data format and optimize the way we retrieve the data for faster loading time.



Technical Complexity

  • Click here to view the detailed explanation on the project's technical complexity


Currently, our application is deployed on UPL machine. However, we will also deploy our application on the sponsor server.

Click here to access the test plan that we conducted with our SMU friends.


UAT User Groups


UAT Comments from User Group 1 (Teachers)


FinalUAT2.png Comment.png


UAT Result from User Group 2 (SMU Friends)

1st Day

No. of testers: 4

Result: 1 failed, 15 passed (Out of 16 tasks)

2nd Day

No. of testers: 4

Result: 16 passed (Out of 16 tasks)

UI Improvements based on the feedback

FinalUAT3.png FinalUAT4.png


Individual Reflection

Eaint Myet Chyal

From this enriching IS480 journey, I learnt a valuable lesson that good negotiation is an important aspect in delivering a project, where many stakeholders are involved and the development team is confined under a time constraint. I believe that one of the success factors for our project is that every team member as well as sponsor and our supervisor ensured open communication at all stages of development and listened to each other’s concern to adjust expectations, requirements and commitments levels. We did not lingered on wishful thinking of promising and hoping to do everything but instead emphasized on delivering the best we can to all the stakeholders involved in close watch to the project timeline.I came to realize that the hard work on preparation for FYP during summer time alongside of internship commitment was a worthy effort because I was able to cope better with scope changes that pushed us to pick up a step deeper development expertise on Flex, a language I had no prior experience before doing FYP. All in all, I learned a lot in terms of technical as well as personal development aspects because I attained an invaluable experience of working with a real client in a real world situation with my four other teammates, who made not only the destination more reachable but also the journey all the more worthwhile.

Khine Su Mon

FYP gave me bitter sweet experience. Despite many stumbling blocks that we have to overcome throughout this journey, I am glad that I learnt invaluable lessons and proud of my united team going through thick and thin together with me along this journey. I am also happy that from peer to peer learning I managed to pick up Flex and PHP.

I would like to highlight two most important lessons that I learnt from this FYP journey.

Firstly, I learnt that managing the project scope is not only about receiving sponsor's requirements passively and follow them strictly all the time. Sometimes, when we could anticipate the need for the end users although they may not need 'now', we have to be active to communicate with the sponsor and explain the value-add features which are good to have for future use. Of course, in reality, suggestion does not necessarily turn into actual implementation at least for our project. This is where I learnt that it was important to know what we want out of this project at the end and tried to achieve win win situation while maintaining good relationships with stakeholders.

Secondly, I learnt to live with uncertainties in our project due to vague requirements. It was sometimes frustrating for me to plan the project timeline because the plan that I did just in a few days ago became expired when we faced with lots of changes in our project. I managed to overcome this by planning weekly and set the rough period for the development of each module.

Overall, this learning journey was going to be unforgettable experience for me and I would like to thank to our supervisor who guided us all along the way, our sponsor who accepted our suggestion and my team members who have given their best for this.

Min Thu Han

FYP journey has been both physically and mentally challenging nonetheless rewarding experience with many skills attained. One paramount importance learning outcome is the importance of communication. From FYP experience of working together with different personalities of teammate , supervisors and sponsor , I realize more on one thing. People are different on how to understand things and response differently. When communicating complex technical issues with different people, I learned that I have to cater to each person differently. Some works well with pure logic flow, some need visualized explanation approach ( flow chart / graph / sketches and actual examples from outside ).

Next, sitting down to think through do give more benefit. Due to the nature of our project, we have much pressure as we need to deliver each iteration according to the sponsor and clients milestone. So, we did not have luxury to lose time and we have to push on with development. But pausing for a while to make sure we layout the development and modularization plan ahead of time before diving into the coding really helps. We found that it is easier to allocate work as well as to integrate. Urgency should not out weigh systematic approach.

Furthermore, it is needless to say that I learned a lot in terms of hardskill. FYP has become the melting pot of all of the IS mods I have learned. It tested understanding as basic as proper variable instantiation from IS200 , SE to encryption and architecture planning from AA and IST.

Thiri May

From this challenging FYP, I have learnt that it is important to have the application owner mindset. When we faced the dilemma of whether we should go ahead with implementing the advanced admin functionality while the sponsor was really reluctant and had strong strategic reasons, we gave in easily and gave priority to fulfill sponsor requirements as we were in developer's mindset. I learnt that should we had the thinking perspective of an application owner, we would have proposed and negotiated with sponsor more firmly and took the responsibility of architecting a good system since the beginning though not required by the sponsor.

Ye Min Naing

Towards the end of the FYP journey, I have learnt a lot of things in picking up new technical skills, managing time, project scope and meeting the sponsor’s requirements in the best ways possible. It was a wonderful opportunity for me to work with the sponsor, supervisor who give us lots of hand-on management and problem solving skills and most importantly, with my team members with amazing talents and determination. During UATs, It is really satisfying and encouraging for me to see that our application is in the hand of real users and adding values to students’ Geography learning. Hope our application will continue making success by making impacts in Geography classrooms in secondary schools.

Project Sitemap

  • Go back to Homepage
  • Go to Midterm Wiki