HeaderSIS.jpg

Difference between revisions of "Goodmix Final Wiki"

From IS480
Jump to navigation Jump to search
 
(46 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
== Project Progress Summary ==
 
== Project Progress Summary ==
  
<font size=3 color=#0000FF>Project Highlights:</font>
+
===<font size=3 color=#0000FF>Project Highlights:</font>===
  
This section is about sudden requirement changes or requests since midterm which we took up. More information on how requirement changes are handled here.
+
RIBA is a highly interactive and robust geospatial application!!!
  
 
{|cellspacing="0" cellpadding="10" align="center" text-align="center" style="font-size:100%; border: 2px solid darkgray;"
 
{|cellspacing="0" cellpadding="10" align="center" text-align="center" style="font-size:100%; border: 2px solid darkgray;"
 
|- style="background:#FFF8C6;"
 
|- style="background:#FFF8C6;"
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:30px;" align="center"|S/N
+
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:25px;" align="center"|S/N
 
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:200px;" align="center"|Event
 
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:200px;" align="center"|Event
 
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:200px;" align="center"|Evaluation
 
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:200px;" align="center"|Evaluation
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:300px;" align="center"|Action
+
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:400px;" align="center"|Action
 
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:200px;" align="center"|Result
 
! style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;width:200px;" align="center"|Result
  
 
|-
 
|-
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" align="center" | 1
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" align="center" | 1
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | User request customizing symbols by choosing from a list of images
+
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | [[Requirement Specification#Symbol Customization with Icon List|User request customizing symbols by choosing from a list of images]]
  
 
| style=" border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Impact: high as it affects many other functionality <p> Difficulty: high as no research about this is done before.
 
| style=" border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Impact: high as it affects many other functionality <p> Difficulty: high as no research about this is done before.
  
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Team consulted sponsor with the following options:
+
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Team decided to implement this although it affects [[Goodmix Final Wiki#Project Schedule (Plan vs. Actual):|our schedule]] because it helps to bring user experience to another level by adding fun elements to RIBA. We would also like to stretch our abilities and push ourselves for this FYP.
  
1. Implement change but outcome is not the responsibility of Goodmix
+
Thus we communicated the possible outcomes to our sponsor and gave ourselves 1 full week to get it up:
  
 
a. Might have major bugs that cannot be solved and have to revert  
 
a. Might have major bugs that cannot be solved and have to revert  
  
b. Less time to work on existing bugs but able to pass UAT
+
b. Accomplished with slight delay to schedule
  
2. Do not implement change and focus on debugging
 
 
Sponsor chose option 1.
 
  
 
| style="border-bottom:1px solid darkgray;" | Team split into coding team (Bernard, Shazlee and George) and project management team (Naresh and Jess) to work concurrently.  
 
| style="border-bottom:1px solid darkgray;" | Team split into coding team (Bernard, Shazlee and George) and project management team (Naresh and Jess) to work concurrently.  
  
Scenario 1(b) occurred.
+
Scenario (b) occurred.
  
 
|-
 
|-
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" align="center" | 2
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" align="center" | 2
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | New “find coordinates” function requested on 8th November to be up by 10th November for UAT
+
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | New [[Requirement Specification#Find Coordinates|“find coordinates”]] function requested on 8th November to be up by 10th November for UAT
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" |Impact: low because it is a standalone function  
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" |Impact: low because it is a standalone function  
 
Difficulty: low because similar techniques are used before
 
Difficulty: low because similar techniques are used before
  
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Went ahead with the request but tight deadline is a challenge so collaboration is critical. Bernard had to finish the coding and UI before passing it to Naresh to update Test Plan and Shazlee to update User Guide.
+
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Went ahead with the request but deadline is tight although it did not affect [[Goodmix Final Wiki#Project Schedule (Plan vs. Actual):|our schedule]]. So, collaboration is critical. Bernard had to finish the coding and UI before passing it to Naresh to update Test Plan and Shazlee to update User Guide.
 
| style="border-bottom:1px solid darkgray;" | Request completed and RIBA tested before UAT
 
| style="border-bottom:1px solid darkgray;" | Request completed and RIBA tested before UAT
  
 
|-
 
|-
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" align="center" | 3
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" align="center" | 3
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Client failed the spatial error handling for the UAT conducted on 10 November 2010. If this is not addressed, it means that the UAT failed.
+
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Client failed the spatial error handling for the UAT conducted on 10 November 2010.  
 +
 
 +
If this is not addressed, it means that our UAT failed.
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Impact: low because it does not implicate other codes  
 
| style="border-bottom:1px solid darkgray;border-right:1px solid darkgray;" | Impact: low because it does not implicate other codes  
 
Difficulty: medium as previous attempts to give specific errors had failed.
 
Difficulty: medium as previous attempts to give specific errors had failed.
Line 53: Line 52:
 
1.Fix it
 
1.Fix it
 
2.Not fix it and write a statement as explanations which will be submitted back to the client who graded fail for approval.
 
2.Not fix it and write a statement as explanations which will be submitted back to the client who graded fail for approval.
| style="border-bottom:1px solid darkgray;" | Jess thought of an idea and managed to accomplish the specific error handling.
+
| style="border-bottom:1px solid darkgray;" | Jess thought of an idea and managed to accomplish the [[Requirement Specification#Improved Spatial Error Handling | specific error handling]].
 
|}
 
|}
  
  
<font size=3 color=#0000FF>Project Challenges:</font>
+
===<font size=3 color=#0000FF>Project Challenges:</font>===
  
 
'''1) Expectations of end users from different departments in biodiversity center'''
 
'''1) Expectations of end users from different departments in biodiversity center'''
Line 66: Line 65:
 
'''2) Managing many milestones and deliverables'''  
 
'''2) Managing many milestones and deliverables'''  
  
Other than FYP milestones, there are biweekly sponsor meetings and client usability sessions where different deliverable for RIBA is expected. “Just keep going” attitude to deliver what is expected to our best. We will first meet our sponsor to show him what we have done before he organizes the usability study sessions with KOOPrime and National Parks. This is both a challenge and a benefit for GoodMix. With many milestones, we are able to keep our schedule on track regularly.
+
Other than FYP milestones, there are biweekly sponsor meetings and client usability sessions where different deliverables for RIBA is expected. “Just keep going” attitude is the attitude we adopt to deliver what is expected with our best effort. We will first meet our sponsor to show him what we have done before he organizes the usability study sessions with KOOPrime and National Parks. This is both a challenge and a benefit for GoodMix. Our [[Goodmix Final Wiki#Project Metrics:|project metric]] had helped us to determine internal deadlines to cope with these milestones and communicate with our sponsor so that he knows what to expect at each session. Conclusively, we feel that having many milestones also helps to keep our schedule on track regularly.
 +
 
 +
 
 +
===<font size=3 color=#0000FF>Project Achievements:</font>===
  
 +
[[Goodmix Final Wiki#Project Schedule (Plan vs. Actual):|Scheduling the project]] is the most complex task for this project. Due to the nature of our [[Time Tracker#Development Process|development process]], we design our own method to mitigate the disadvantage of adopting this process which we called it [[Goodmix Final Wiki#Dynamic Scheduling:|dynamic scheduling]]. This method was effective as it successfully helped us overcome many milestones to satisfy our stakeholders.
  
<font size=3 color=#0000FF>Project Achievements:</font>
 
  
Scheduling the project is the most complex task for this project. Due to the nature of our development process, we design our own method to mitigate the disadvantage of adopting this process which we called it dynamic scheduling. This method was effective as it successfully helped us overcome many milestones to satisfy our stakeholders.
+
Although we make use of external libraries, we create methods to access them and integrate them with our functionalities i.e. our codes are customized to model each functionality. We do modify the libraries or seek other alternatives such as using PostGIS functions when we discovered that the external libraries are not what we want.  
  
  
Although we make use of external libraries, we create methods to access them and logics to integrate them with functionalities. When the libraries cannot perform what we hope they will, we modify them or seek other alternatives such as using PostGIS functions.
+
For example, although Flex has draw circle function and modestmap has draw great circle method, they do not do what we want to achieve for spatial search. We wanted to allow users to draw buffers base on their specified radius and markers indicated on the map. These buffers should be drawn in accuracy to the map measurements too i.e. they should minimize and maximize in size as user zooms in and out because the map measurement changes as user zooms. We discovered after much research that PostGIS has the best function for this highly customized function. We designed the whole logic and integrate PostGIS functions into our entire modularized code design. In the end, we did an in-depth study of geospatial terms such as "geometry", "projection" and used a span of programming languages- PHP which returns XML, actionscript and mxml to achieve this function.
  
  
Line 80: Line 82:
  
 
== Project Management ==
 
== Project Management ==
<font size=3 color=#0000FF>Project Schedule (Plan vs. Actual):</font>
+
===<font size=3 color=#0000FF>Project Schedule (Plan vs. Actual):</font>===
 +
 
 +
Changes to project schedule were elaborated up to midterm. Therefore comparison will start at phase 6 where we face some of the most turbulent phases. However, even with many changes to the schedule, we are on track!
  
 +
[[Image:phase6.png|700px]]
  
Changes to project schedule were elaborated up to midterm. Therefore comparison of the plan and actual schedule will start at phase 6. Although there are many changes to the requirements, schedule is well on track. Most of the time, while we include change to the requirements, we also removed some that got prioritized lower after the change request. Hence, the net effect is neutralized.
 
  
[[Image:phase6.png|700px]]
+
Phase 6 has a total of 12 changes which is more than the usual. This increase is actually a good news for us. It indicates that our users are getting more familiarized with RIBA and know what they want better.
  
We increased our “working hours” where we met up on weekdays from 10am to 6pm during week 8 midterm break. While working hard, we did not forget to relax a little by having weekends off. This allowed us accomplish many new requirements on top of the allocated tasks and even brought some tasks forward. However, we were quite concerned about the 1 week delay for our last usability session.  
+
In this phase, we increased our “working hours” during midterm break where we met up on weekdays from 10am to 6pm. Although the last usability session is delayed and pushed to phase 7, it allowed us accomplish new requirements on top of the existing ones and even brought some activities forward. Thus, we ended this phase on time.  
  
 
[[Image:phase7.png |700px]]
 
[[Image:phase7.png |700px]]
  
We feel that this is the most stressful phase as we are approaching presentation week for other modules. Sponsor UAT is also delayed for a week due to phase 6 usability session delay. This is to give us time to implement feedback from the usability session.
+
In phase 7 we have slightly less changes which is 10 of them but is one of the most turbulent phase for 2 main reasons!
  
After UAT with sponsor, client made a sudden request that we implement [[Requirement Specification#Symbol Customization with Icon List| symbol customization]] for layers otherwise our UAT might fail. This situation was addressed at the [[Goodmix Final Wiki#Project Progress Summary|project challenge section]].
+
1) The sponsor UAT was delayed by a week to give us time to implement feedback from the usability session which was delayed in phase 6 and polish up RIBA.
 +
 
 +
2) The sudden request resulted in a 5 days delay for phase 7 but was spilled over to phase 8 because we decided to regard it as part of the buffer we catered for phase 8.
 +
 
 +
Thus we divided ourselves into project development and project management teams so that we’re able to do both type of tasks concurrently.
  
 
[[Image:phase8.png|700px]]
 
[[Image:phase8.png|700px]]
  
On a happier note, we are glad to see our hard work paid off in this phase. By pushing ourselves to make all the changes, there is a significant drop of changes to schedule and requests.  
+
Here, there is a significant drop in changes as we’re approaching closure. Our buffer for this phase is not much utilised except for the 5 days spilled over from phase 7 for the sudden request and “find coordinates” function which we implemented because it can be done without affecting our schedule and improve user experience further. Now, RIBA is prepared and ready for handover.
 +
 
 +
 
 +
You can download our latest detailed Gantt Chart [http://dl.dropbox.com/u/284008/GoodMix_final.mpp here.]
 +
 
 +
If you are interested to know more about [[Time Tracker#Project Schedule | how we plan our project schedule]], [[Time Tracker#Midterm Schedule | schedule evaluation for midterm]] or [[Time Tracker#Development Process | our special development process]], visit the linkages :)
 +
 
 +
===<font size=3 color=#0000FF> Dynamic Scheduling:</font>===
 +
 
 +
We decided to include this section in our final wiki because this is a process which we innovated for our FYP. We hope that any future groups who requires user-centric design development process and is adventurous to try our new things can adopt our development process and dynamic scheduling :)
 +
 
 +
[[Image:dynamicSchedule.png|600px]]
 +
 
 +
1. We selected the [[Time Tracker#Development Process | user centric development process]].
 +
 
 +
2. We gathered project requirements during the Taking Off phase which is before we implement this dynamic scheduling. We ranked them from Basic to Advance functionality.
 +
 
 +
3. We decided to factor in the major FYP milestones, namely the acceptance, midterm and final presentations.
 +
 
 +
4. We also decided on having 8 uability sessions with our clients which seems a lot but is part of our schedule mitigation. In this way we get to maximize the amount of interactions with our end users and clients too. This is important as they are truly the ones who know what is user experience.
 +
 
 +
5. Steps 4 and 5 will translate into the total number of phases for the project with is 9 phases including the Taking Off phase with different durations.
 +
 
 +
6. last but not least, we spread the functionalities in a linear format:
 +
 
 +
[[Image:schedule.png|400px]]
  
Although week 12’s National Parks road show is canceled, UAT with client is still delayed by a week due to the rolling effect of delay at phase 6 and sudden request mentioned above. However, we managed to polish up RIBA and made it to the UAT where we can finally stop the development work.
+
This tactic allows us to have buffer time at every phase to cater for change requests. At phase 7 & 8, we should focus on documentation and final presenation while channeling more effort into packaging RIBA and get it ready for handover.
  
 +
===<font size=3 color=#0000FF> Project Metrics:</font>===
  
<font size=3 color=#0000FF> Project Metrics:</font>
+
There are 3 metrics but this section only covers the special metrics which we created after midterm to help us cope with an increase of change requirements.
  
These are the 3 metrics that Goodmix use: [[Project Metrics#Requirement Evaluation Metric|requirement evaluation metric]], [[Project Metrics#Risk Assessment |risk assessment]] and [[Project Metrics#Bug Tracking |bug tracking]].
+
We call this the Change Evaluation Metric!
  
Here is the summary of the metrics collected:
+
[[Image:reqEvaluation.png|400px]]
  
'''Requirement Evaluation Metric:'''
+
We first gather all the feedbacks from usability study sessions and filter out contradictory feedbacks because the net user experience is neutralized. E.g. the officer from informatics will prefer us to retain attribute search results to use it for spatial search while the officer from biodiversity is satisfied with these functions separated for ease of use.
  
123
 
  
'''Bugs Tracking:'''
+
Impact here refers to the impact on RIBA architecture and difficulty refers to technical difficulty such as if any prior research was done before.
  
[[Media:Final Bug Matrix.xlsx]]
 
  
 +
We find this metric very helpful in 3 main areas:
  
'''Risk Assessment:'''
+
'''1. Work allocation'''
  
Comparison of the midterm and final risks:
+
This is where change requests with high scores of 6 and 9 will lead to pair programming for change implementation.
  
(to be filled up)
+
'''2. Better estimation for internal deadlines'''
  
(what does this comparison mean?)
+
This is important to allow us to achieve intermediate stable RIBA versions during each meeting with our sponsor especially during usability study session with our client and end users.
  
 +
'''3. A good communication tool'''
  
<font size=3 color=#0000FF> Technical Complexity:</font>
+
This is mainly with our sponsor who is our source of requirements where we are able to evaluate the situation of the change requests better. This can be observed in our [[Goodmix Final Wiki#Project Highlights:| project highlight section]].
 +
 
 +
 
 +
This is our informal way of implementing this metric during one of our meetings:
 +
 
 +
[[Image:reqEvaluation2.png|500px]]
 +
 
 +
 
 +
All the change requirements from midterm onwards (phase 6 - 8) are being mapped onto the grid for easy viewing:
 +
 
 +
[[Image:reqEvaluation3.png|600px]]
 +
 
 +
* Yellow boxes = change requests for UI
 +
 
 +
* Green boxes = change requests for search functions
 +
 
 +
* Dark purple boxes = change requests for other functions
 +
 
 +
 
 +
This also explains the evaluation column at the [[Goodmix Final Wiki#Project Highlights:|project highlight section]]. As you may observe, the symbol customization has the highest impact and difficulty which we decided to push ourselves for it.
 +
 
 +
 
 +
For 2 other metrics, visit them at these pages: [[Project Metrics#Risk Assessment |Risk Assessment]] and [[Project Metrics#Bug Tracking | Bug Tracking]]
 +
 
 +
===<font size=3 color=#0000FF> Technical Complexity:</font>===
  
 
We ranked the technical complexity by functions and provided explanations for top 3 choices:
 
We ranked the technical complexity by functions and provided explanations for top 3 choices:
Line 222: Line 280:
  
 
2) Specifications
 
2) Specifications
|style="border:1px solid darkgray;"|story
+
|style="border:1px solid darkgray;"|[[Media:story.pdf]]
  
 
[[Requirement Specification |Scope Requirements]], [[It is all about the system#Technical Specifications  |Technical Requirements]]
 
[[Requirement Specification |Scope Requirements]], [[It is all about the system#Technical Specifications  |Technical Requirements]]
Line 262: Line 320:
 
|}
 
|}
  
<font size=3 color=#0000FF> Quality:</font>
+
===<font size=3 color=#0000FF> Quality:</font>===
  
 
We've built RIBA that strives to be dynamic not just for usage but also for deployment and ease of maintenance. For example, clients request for icon customisation for different data layers. Instead of asking them to add codes, all the administrator has to do is drop the icons into the icon folder.  
 
We've built RIBA that strives to be dynamic not just for usage but also for deployment and ease of maintenance. For example, clients request for icon customisation for different data layers. Instead of asking them to add codes, all the administrator has to do is drop the icons into the icon folder.  
Line 276: Line 334:
  
  
<font size=3 color=#0000FF> Deployment:</font>
+
===<font size=3 color=#0000FF> Deployment:</font>===
  
 
Deployment was done on a test server instead of the client server. We tried our best to get RIBA deployed on our client’s server but they could not confirm this possibility by week 11. However, as RIBA is a flash enabled application, a successful deployment to test server meant that it is possible on client server.
 
Deployment was done on a test server instead of the client server. We tried our best to get RIBA deployed on our client’s server but they could not confirm this possibility by week 11. However, as RIBA is a flash enabled application, a successful deployment to test server meant that it is possible on client server.
Line 287: Line 345:
  
  
<font size=3 color=#0000FF> Testing:</font>
+
===<font size=3 color=#0000FF> Testing:</font>===
  
 
Bug reporting was significantly improved after our midterm feedback that we might be under reporting the bugs. As we get more alert, members took turn to do debugging to test and report RIBA bugs to bug tracking document immediately.  
 
Bug reporting was significantly improved after our midterm feedback that we might be under reporting the bugs. As we get more alert, members took turn to do debugging to test and report RIBA bugs to bug tracking document immediately.  
Line 295: Line 353:
  
 
== Reflection ==
 
== Reflection ==
<font size=3 color=#0000FF> Team Reflection</font>
+
===<font size=3 color=#0000FF> Team Reflection</font>===
 +
This is our team reflection to conclude our project:
 +
 
 +
*'''Understanding what the Client wants'''
  
<font size=3 color=#0000FF> Benjamin Gan Reflection </font>
+
This is also in relation to helping them know what they want to. Thus, we gained the real life experience and witnessed how our users grow to be more expectant of RIBA which in turn makes us happy as we know we are building a helping tool for them and not a hassle-to-use tool.
 +
 
 +
 
 +
*'''Relating it from Business Problems to IT Solutions'''
 +
 
 +
When designing IT solutions, it is important to keep in check that the functions we plan to build helps to solve their business problems. Otherwise the function will be left idle or even reduce user experience. For example, we wanted to put animations when RIBA plots the point layers. However, we discovered that it slows down performance and as user gets familiar with RIBA, the animation might even irritate them especially when the researchers just want the results fast.
 +
 
 +
 
 +
*'''Managing Risk in the best possible way'''
 +
 
 +
When managing risk, the mitigation strategy has to be carefully thought through without jeopardizing the overall schedule. For example, we decided to have a maximum of 8 sessions with our clients because upon mapping out the schedule, the legth of each phase is reasonable to cope (each phase is about 2 weeks which is our bi-weekly meeting with sponsor too)
 +
 
 +
 
 +
*'''User Experience is vital to any IS Project'''
 +
 
 +
This is particularly true to our project because RIBA is built with the intention to be user centric - high user interactivity and robust.
 +
 
 +
 
 +
* '''Matching Technology needs'''
 +
 
 +
Knowing that they are looking for geospatial application, we recommended [[It is all about the system#System Architecture|our architecture]] and the related software and open source that will best serve their needs.
 +
 
 +
 
 +
* '''Making our Clients Happy!'''
 +
 
 +
 
 +
===<font size=3 color=#0000FF> Benjamin Gan Reflection </font>===
  
  
Line 316: Line 403:
 
<font color=#04B404>'''Naresh:'''</font>
 
<font color=#04B404>'''Naresh:'''</font>
  
123
+
This FYP has been a remarkable journey. 6 months thru good and bad times and finally we came thru. During this period, I have learnt how it is to embark on a IS project dealing with real people who are your clients and inevitable changes that will keep bouncing to and fro. Change is the only constant in Life. As such so is our project, though I recognized much changes was needed in our project to give the client, the "user experience". Working on a project that looks into HCI, User Experience is very important and viral. How many clicks, does the name make sense, where the function is placed at, the buttons used..etc As much as possible, we should make it easy and intiutive for end users to use at their comfort.
 +
 
 +
 
 +
Apart from User Experience, I have also learnt to understand Business Problems that clients faced and providing IS solutions with the right technologies incorporated into the project. Managing the expectations of various stakeholders is also one thing I have learnt. We had multiple tiers of clients and with that sponsor, vendor and client. It is important to establish a good working relationship and understand each other expectations and objectives of the project so that you will be able to deliver what has been required.
 +
 
 +
 
 +
I have enjoyed working these 6 months with awesome team mates who make things happen thru thick and thin!
  
  
Line 341: Line 434:
  
 
|}
 
|}
 
 
<font size=3 color=#0000FF> Sponsor Comment</font>
 
  
 
----
 
----

Latest revision as of 01:25, 28 November 2010

Main Page: IS480 Team wiki: 2010T2 Good Mix

Project Progress Summary

Project Highlights:

RIBA is a highly interactive and robust geospatial application!!!

S/N Event Evaluation Action Result
1 User request customizing symbols by choosing from a list of images Impact: high as it affects many other functionality

Difficulty: high as no research about this is done before.

Team decided to implement this although it affects our schedule because it helps to bring user experience to another level by adding fun elements to RIBA. We would also like to stretch our abilities and push ourselves for this FYP.

Thus we communicated the possible outcomes to our sponsor and gave ourselves 1 full week to get it up:

a. Might have major bugs that cannot be solved and have to revert

b. Accomplished with slight delay to schedule


Team split into coding team (Bernard, Shazlee and George) and project management team (Naresh and Jess) to work concurrently.

Scenario (b) occurred.

2 New “find coordinates” function requested on 8th November to be up by 10th November for UAT Impact: low because it is a standalone function

Difficulty: low because similar techniques are used before

Went ahead with the request but deadline is tight although it did not affect our schedule. So, collaboration is critical. Bernard had to finish the coding and UI before passing it to Naresh to update Test Plan and Shazlee to update User Guide. Request completed and RIBA tested before UAT
3 Client failed the spatial error handling for the UAT conducted on 10 November 2010.

If this is not addressed, it means that our UAT failed.

Impact: low because it does not implicate other codes

Difficulty: medium as previous attempts to give specific errors had failed.

Team is offered 2 options from sponsor

1.Fix it 2.Not fix it and write a statement as explanations which will be submitted back to the client who graded fail for approval.

Jess thought of an idea and managed to accomplish the specific error handling.


Project Challenges:

1) Expectations of end users from different departments in biodiversity center

Even though our source of requirements is our sponsor, we attended all usability study sessions to get direct feedback from them. This means indirectly managing users’ expectations which can be different and sometimes contradictory. After each usability study sessions, we will discuss with our sponsor during the next meeting to prioritize the changes requested for the next deliverable. We also make use of our project metrics to help us evaluate the requests. This plan had worked well for us.


2) Managing many milestones and deliverables

Other than FYP milestones, there are biweekly sponsor meetings and client usability sessions where different deliverables for RIBA is expected. “Just keep going” attitude is the attitude we adopt to deliver what is expected with our best effort. We will first meet our sponsor to show him what we have done before he organizes the usability study sessions with KOOPrime and National Parks. This is both a challenge and a benefit for GoodMix. Our project metric had helped us to determine internal deadlines to cope with these milestones and communicate with our sponsor so that he knows what to expect at each session. Conclusively, we feel that having many milestones also helps to keep our schedule on track regularly.


Project Achievements:

Scheduling the project is the most complex task for this project. Due to the nature of our development process, we design our own method to mitigate the disadvantage of adopting this process which we called it dynamic scheduling. This method was effective as it successfully helped us overcome many milestones to satisfy our stakeholders.


Although we make use of external libraries, we create methods to access them and integrate them with our functionalities i.e. our codes are customized to model each functionality. We do modify the libraries or seek other alternatives such as using PostGIS functions when we discovered that the external libraries are not what we want.


For example, although Flex has draw circle function and modestmap has draw great circle method, they do not do what we want to achieve for spatial search. We wanted to allow users to draw buffers base on their specified radius and markers indicated on the map. These buffers should be drawn in accuracy to the map measurements too i.e. they should minimize and maximize in size as user zooms in and out because the map measurement changes as user zooms. We discovered after much research that PostGIS has the best function for this highly customized function. We designed the whole logic and integrate PostGIS functions into our entire modularized code design. In the end, we did an in-depth study of geospatial terms such as "geometry", "projection" and used a span of programming languages- PHP which returns XML, actionscript and mxml to achieve this function.


To make RIBA interactive and getting the architecture right, it takes a lot of planning, research, learning, explorations and testing at the backend.

Project Management

Project Schedule (Plan vs. Actual):

Changes to project schedule were elaborated up to midterm. Therefore comparison will start at phase 6 where we face some of the most turbulent phases. However, even with many changes to the schedule, we are on track!

Phase6.png


Phase 6 has a total of 12 changes which is more than the usual. This increase is actually a good news for us. It indicates that our users are getting more familiarized with RIBA and know what they want better.

In this phase, we increased our “working hours” during midterm break where we met up on weekdays from 10am to 6pm. Although the last usability session is delayed and pushed to phase 7, it allowed us accomplish new requirements on top of the existing ones and even brought some activities forward. Thus, we ended this phase on time.

Phase7.png

In phase 7 we have slightly less changes which is 10 of them but is one of the most turbulent phase for 2 main reasons!

1) The sponsor UAT was delayed by a week to give us time to implement feedback from the usability session which was delayed in phase 6 and polish up RIBA.

2) The sudden request resulted in a 5 days delay for phase 7 but was spilled over to phase 8 because we decided to regard it as part of the buffer we catered for phase 8.

Thus we divided ourselves into project development and project management teams so that we’re able to do both type of tasks concurrently.

Phase8.png

Here, there is a significant drop in changes as we’re approaching closure. Our buffer for this phase is not much utilised except for the 5 days spilled over from phase 7 for the sudden request and “find coordinates” function which we implemented because it can be done without affecting our schedule and improve user experience further. Now, RIBA is prepared and ready for handover.


You can download our latest detailed Gantt Chart here.

If you are interested to know more about how we plan our project schedule, schedule evaluation for midterm or our special development process, visit the linkages :)

Dynamic Scheduling:

We decided to include this section in our final wiki because this is a process which we innovated for our FYP. We hope that any future groups who requires user-centric design development process and is adventurous to try our new things can adopt our development process and dynamic scheduling :)

DynamicSchedule.png

1. We selected the user centric development process.

2. We gathered project requirements during the Taking Off phase which is before we implement this dynamic scheduling. We ranked them from Basic to Advance functionality.

3. We decided to factor in the major FYP milestones, namely the acceptance, midterm and final presentations.

4. We also decided on having 8 uability sessions with our clients which seems a lot but is part of our schedule mitigation. In this way we get to maximize the amount of interactions with our end users and clients too. This is important as they are truly the ones who know what is user experience.

5. Steps 4 and 5 will translate into the total number of phases for the project with is 9 phases including the Taking Off phase with different durations.

6. last but not least, we spread the functionalities in a linear format:

Schedule.png

This tactic allows us to have buffer time at every phase to cater for change requests. At phase 7 & 8, we should focus on documentation and final presenation while channeling more effort into packaging RIBA and get it ready for handover.

Project Metrics:

There are 3 metrics but this section only covers the special metrics which we created after midterm to help us cope with an increase of change requirements.

We call this the Change Evaluation Metric!

ReqEvaluation.png

We first gather all the feedbacks from usability study sessions and filter out contradictory feedbacks because the net user experience is neutralized. E.g. the officer from informatics will prefer us to retain attribute search results to use it for spatial search while the officer from biodiversity is satisfied with these functions separated for ease of use.


Impact here refers to the impact on RIBA architecture and difficulty refers to technical difficulty such as if any prior research was done before.


We find this metric very helpful in 3 main areas:

1. Work allocation

This is where change requests with high scores of 6 and 9 will lead to pair programming for change implementation.

2. Better estimation for internal deadlines

This is important to allow us to achieve intermediate stable RIBA versions during each meeting with our sponsor especially during usability study session with our client and end users.

3. A good communication tool

This is mainly with our sponsor who is our source of requirements where we are able to evaluate the situation of the change requests better. This can be observed in our project highlight section.


This is our informal way of implementing this metric during one of our meetings:

ReqEvaluation2.png


All the change requirements from midterm onwards (phase 6 - 8) are being mapped onto the grid for easy viewing:

ReqEvaluation3.png

  • Yellow boxes = change requests for UI
  • Green boxes = change requests for search functions
  • Dark purple boxes = change requests for other functions


This also explains the evaluation column at the project highlight section. As you may observe, the symbol customization has the highest impact and difficulty which we decided to push ourselves for it.


For 2 other metrics, visit them at these pages: Risk Assessment and Bug Tracking

Technical Complexity:

We ranked the technical complexity by functions and provided explanations for top 3 choices:

Rank Function
1 Symbol Customization

This is the most technical component for us because attempts to customize the symbols of the layers with color picker was made before but failed. This is why we modified it to become randomized color symbols and no prior research was done specific to this function. Furthermore, this feature affects most of the functionalities since they were built on top of the marker population algorithm. Achieving dynamic icon list where administrators just need to upload icons to the symbol folder is one of the most satisfying feeling.

2 Layer Control Manager

This function is considered a basic feature but it is one of the most difficult function particularly trying to implement this in the early stages. This means that if we don't get this feature out in time, it will be a critical bottleneck for the rest of RIBA development. This feature is also the one that morphed the most throughout the project - from changing UI to changing logic.


This function being one of the toughest is not just because our skills are not well developed then but also because it involves deep understanding of the concept of geometry in PostGIS. This concept is geospatial related and not many materials can be found online about the usage of it. Thus we have a hard time trying to figure this out which we also learned how to explode "the_geom" to load polygon layers using PHP. Item rendering using actionscript is also one of the proud creation which the logic is modified from our intense research.

3 Spatial Search

Spatial search is both difficult and special at the same time. Through our usability sessions, our end users seem to be most awed by this function. This is also another function that transformed a lot through the phases - from single point buffer to multiple point buffer to polygon buffers. A lot of hiccups were met during the development of this function. As this is a geospatial concept search, a lot of careful considerations and revisions are made for its UI.


Technical complexity includes the usage of PostGIS geospatial functions such as ST_Buffer, ST_UNION, ST_DWITHIN, etc which are very new to the team. Deeper understanding of geometry in PostGIS is also required here. For example, geometry column for polygon does not accept geometry of point type, transformation to the correct SRID affects the accuracy of your result, etc. On top of this, flex coding logic such as placing markers when user double clicks on the map, drawing buffers from the parameters passed in by PHP in the form of XML, etc are created by us.

4 Attribute Search
5 Highlight
6 Heatmap
7 Data Loading
8 Dynamic Legend
9 Area Calculation
10 User Interface
11 Map Export to Images (Snapshot)
12 Distance Calculation
13 Find Coordinates
14 Map Navigation
15 Map Scale
16 Map Provider

Quality of Product

Project Deliverable:

Stage Specification Modules
Project Management 1) Minutes

2) Metrics

Client, Sponsor, Supervisor & Internal

Metrics

Requirements 1) Storyboard

2) Specifications

Media:story.pdf

Scope Requirements, Technical Requirements

Analysis Use Case & Description Use Case Materials
Design 1) System Architecture

2) UI Design Changes

3) Database Schema

Architecture

Media:DesignChanges.pdf

Media:DataSchema.pdf of NParks_DB

Testing UAT Test Plan & UAT Details
Handover 1) Guides

2) Code

3) Deployment

Media:User Guide.pdf for National Parks, Deployment Guide for KOOPrime

On Test Server

Deployment Materials

Quality:

We've built RIBA that strives to be dynamic not just for usage but also for deployment and ease of maintenance. For example, clients request for icon customisation for different data layers. Instead of asking them to add codes, all the administrator has to do is drop the icons into the icon folder.


In terms of user interface, it is being revised from time to time as we created them from scratch. It can be as trivial as setting transparency to background or as tedious as presenting the function such that it is idiot-proof and a handy tool at the same time e.g. spatial function.


For coding wise, external libraries are clearly separated from our codes which are modularized into different classes. This is also applied to PHP which can be as seemingly trivial as having a configuration file so that password change is only required once. Comments are done in details for all methods that we built.


We've also designed the database architecture which our administrators must use it for RIBA to function and for them to maintain geospatial layers.


Deployment:

Deployment was done on a test server instead of the client server. We tried our best to get RIBA deployed on our client’s server but they could not confirm this possibility by week 11. However, as RIBA is a flash enabled application, a successful deployment to test server meant that it is possible on client server.


For this FYP, GoodMix tries to model the project such that it is as dynamic and close to the will-be live project as possible. In the upcoming demonstration during presentation, we will be accessing a URL that contains the IP address of the test server remotely. A step-by-step deployment guide is created just for our client to build, deploy and maintain RIBA. It comes together with an installation guide pack containing all the codes and installers.


Navigate to this page for deployment materials: Deployment Details


Testing:

Bug reporting was significantly improved after our midterm feedback that we might be under reporting the bugs. As we get more alert, members took turn to do debugging to test and report RIBA bugs to bug tracking document immediately.


On top of bug tracking, we've also done UAT. We achieved all passed for the UAT except a section from an end user on the spatial error handling. He felt that the error is not helpful enough for the users. Our team has rectified this and sent him the end product for his approval. Once he approves, we will achieve 100% UAT pass :)

Reflection

Team Reflection

This is our team reflection to conclude our project:

  • Understanding what the Client wants

This is also in relation to helping them know what they want to. Thus, we gained the real life experience and witnessed how our users grow to be more expectant of RIBA which in turn makes us happy as we know we are building a helping tool for them and not a hassle-to-use tool.


  • Relating it from Business Problems to IT Solutions

When designing IT solutions, it is important to keep in check that the functions we plan to build helps to solve their business problems. Otherwise the function will be left idle or even reduce user experience. For example, we wanted to put animations when RIBA plots the point layers. However, we discovered that it slows down performance and as user gets familiar with RIBA, the animation might even irritate them especially when the researchers just want the results fast.


  • Managing Risk in the best possible way

When managing risk, the mitigation strategy has to be carefully thought through without jeopardizing the overall schedule. For example, we decided to have a maximum of 8 sessions with our clients because upon mapping out the schedule, the legth of each phase is reasonable to cope (each phase is about 2 weeks which is our bi-weekly meeting with sponsor too)


  • User Experience is vital to any IS Project

This is particularly true to our project because RIBA is built with the intention to be user centric - high user interactivity and robust.


  • Matching Technology needs

Knowing that they are looking for geospatial application, we recommended our architecture and the related software and open source that will best serve their needs.


  • Making our Clients Happy!


Benjamin Gan Reflection

Jess:

As project manager, in terms of schedule, I am lucky to have our developers helping out in managing the deliverables, particularly in the project development aspect. On top of this, FYP is probably the longest project, about 6 months, for SMU undergraduates so sometimes, the team does get tired or less motivated. However, I truly experienced the spirit of “keep moving on” from this team which enabled us to deliver what we were set out to. To me, this is a journey of stamina, management and motivation.


Personally, I try to help out as much as I can in project development too. This is because I have been through GIS course and I wanted to learn more about Flex and Geospatial functions. Having done user interface works for GIS project, I focused more on database connection and PostGIS functions for FYP project to diversify my learning. It was a great sense of achievement as I grow to be better skilled in these aspects.


All in all, this FYP allows me to take a peak of how the real world project is like since we are working with real clients. With multiple stakeholders, requirements can be a real headache because some are contradictory, some are tedious and others can be too difficult. We are lucky to have our sponsor, Dr Kam, as our requirement source which filtered most of the requirements and get us to do those that are critical, impressive and/or manageable ones.


Naresh:

This FYP has been a remarkable journey. 6 months thru good and bad times and finally we came thru. During this period, I have learnt how it is to embark on a IS project dealing with real people who are your clients and inevitable changes that will keep bouncing to and fro. Change is the only constant in Life. As such so is our project, though I recognized much changes was needed in our project to give the client, the "user experience". Working on a project that looks into HCI, User Experience is very important and viral. How many clicks, does the name make sense, where the function is placed at, the buttons used..etc As much as possible, we should make it easy and intiutive for end users to use at their comfort.


Apart from User Experience, I have also learnt to understand Business Problems that clients faced and providing IS solutions with the right technologies incorporated into the project. Managing the expectations of various stakeholders is also one thing I have learnt. We had multiple tiers of clients and with that sponsor, vendor and client. It is important to establish a good working relationship and understand each other expectations and objectives of the project so that you will be able to deliver what has been required.


I have enjoyed working these 6 months with awesome team mates who make things happen thru thick and thin!


Bernard:

Initially in our team, only Jess and George are exposed to Flex coding while the rest (Bernard, Naresh and Shazlee) do not have any background knowledge about it. Therefore, the initial learning curve is extremely steep for me but with the help of reference books and examples from the web, and slowly I come to terms with Flex coding. Then for the rest of the coding of the project, it would be basically more of reading what each APIs can do and applying programming logic into it. Besides Flex coding, I also has to understand PHP programming as well as using APIs from our PostGreSQL database in order to achieve some of the spatial functions (spatial query, area calculation and etc) in our project. All in all, through this project, I have been exposed to several programming languages and also the interaction between each phase of our architecture.


As the team has adopted a new development framework, more usability tests were conducted before the final UAT as our application is more user-centric and therefore we would constantly need to get feedbacks from our users with regards to our application. In this way, we were able to cater to their needs and wants with the notion that the basic user requirements were still intact. Therefore when the final UAT was conducted, we achieved good results and expectations from the users. Through the numerous usability tests conducted with the users, I understood what they really want and we try our best to give them what they want but sometimes, some of the stuffs we are not able to comply due to the time constraints we have.


Shazlee:

After a grueling 6 months, the FYP is finally coming to an end. It has been a long and tough journey, especially having to juggle other modules, external classes and work. Personally, I feel that the challenge in this project is the new programming language of which made it hard to search the Web for information on it. That aside, having to handle the client’s request proved to be a challenge as well. Due to the various constant changes requested, it was hard having to keep up with it. Something which I loved about this project was coming up with some of the algorithms to make it work. I felt a sense of completion seeing some of the things work in the project such as the randomization of color for the markers, which unfortunately was removed after one of the usability session with the end user.


Due to the nature of our project, we had lots of usability tests with our users. This was an eye-opener as we had to constantly tweak our user interface to meet their demands. But this was beneficial as the users would be able to own something that they would actually be comfortable in using.


George:

I personally think that IS480 is a good educational channel for me to experience a real project life cycle, from gathering requirements to project management and to completion. As an educational environment, I have a chance to learn from my mistakes and amend from it, so that I am more prepared when I enter the business world. Apart from the technicality aspect of our application, the takeaways from this project are mostly the soft-skills that I learnt; managing stakeholders’ opinions, addressing internal conflicts, and how we can convey our ideas more effectively. I have also learnt how to advice stakeholders by presenting different outcomes from various implementations and our recommendations, balance tough decisions and strive for a win-win situation. I would like to thank our project sponsor and supervisor for giving me keen insights in project development and management.


Disclaimer: All images and content on this page are done by Good Mix and should not be published without their permission.

Main Page: IS480 Team wiki: 2010T2 Good Mix