Main Page: IS480 Team wiki: 2010T2 Good Mix
|Before a comparison of the project plan and actual schedule can be made, it is important to understand our development process. What is so special about our development process?
A user centric design process modified from Cartography 2.0, proposed by Robert E. Roth, Department of Geography, Penn State University
In main gist, this development process is a cycle that keeps repeating itself but each repeat (which we name it as phase) does not follow in sequence until the project is completed. An important key to note is that this is neither the “iterative” nor the “waterfall” approach that we learn in SIS. It emphasizes on iterating the process rather than the functionality. By the end of each phase, we will review all functionality after getting feedback from our stakeholders to determine the degree of change/improvement and decide which of the functionality (if any) is to be reflected into the next phase.
Having adopted this development process for about months now, we evaluated its advantages and disadvantages:
Pros & Cons of Development Process
Prototyping is both an internal and external communication tool. It helps us internally by allowing us to envision the different functionality that we want to develop for RIBA in the same frequency. This in turn gives us a common vision of the final achievements.
Its emphasis on vigorous interactions with users allow them to discover what they really want to achieve from RIBA via usability studies sessions. Prototypes and implementations are shown to the users during the sessions where they will feedback or illustrate what they would like RIBA to do. All these help to define our requirements more specifically too.
We discovered a disadvantage where we seem to be subjected to a high risk of requirement change rate. This might also mean that we have a risk of high expectations coming from our stakeholders, particularly our client and end users (National Parks). Having anticipated this risk, we implemented the following mitigation strategies to minimize this risk:
1. Dynamic Scheduling
2. The role of our sponsor
We are lucky to have a sponsor to help us facilitate amongst the tripartite parties. This reduces the number of requirement source to just 1. This becomes a great learning experience on how we can professionally handle external parties.
Conclusively, we decided to adopt this because we believe that it will most effectively help us achieve our goals.
|Overview of the schedule:
The phases are of different duration because it is determined by:
Estimated usability study sessions we would like to have with our stakeholders. As we would like to interact more with our stakeholders, particularly National Parks users, we have a total of 8 phases + taking off. This seems to be a lot of phases but it actually gives us more flexibility to the scheduling. Maximizing the number of interaction and usability sessions we can and want to have means that we will have a day of buffer if National Park end users are not able to meet us.
Major FYP Milestones such as Acceptance Presentation, Midterm Presentation and Final Presentation is reflected into the schedule as we need to focus on FYP deliverable during the phase.
- Try to get all the main requirements from requirement source at the beginning of the project
In our case, requirement source is Dr.Kam, our sponsor. We met up with him for 2 sessions to get the main requirements at the beginning of our FYP.
- Decide on the number of usability studies you would like to have with your stakeholders. Base on various factors that can affect your development, decide on the number of phases to have.
We would like to have 7 sessions with our stakeholders, particularly, National Parks. In addition, we decided to separate the period before we adopt this development process and name it as Taking Off as well as adding a phase used as preparation for final FYP project and pass our project over to our client. Other factors that affect the decision to have lucky 7 usability study sessions is the major milestones for our FYP. All these translate into a Taking Off phase with 8 other phases.
- Decide on the phase which you can be confident to maximally satisfy your stakeholders such that they will not give more requirements or changing any of them.
We got the date from KooPrime, our client, which RIBA has to be 90% functional. This is translated into the end of our Phase 6.
- Evenly spread your requirements across the number of phases targeted for development, placing the more important requirements first.
We divide the requirements across 6 phases (phase 1 - phase 6)
- Leave the rest of the time after allocating days for development and documentations as buffer for change requirement brought in by the previous phase.
As we discuss functional changes to our schedule, you might want to refer to our requirement specification to understand better.
At the taking off phase, we are still warming up to the different programming languages and development tools. We did more studying on the different areas and sharing of knowledge instead of jumping head in for coding. Here, we focused on setting up the environment and started slow but warm on getting the basic rich internet map application out which are the components listed under Navigation.
Moving on to Phase 1 is the stage where we decided to adopt our development process. We did basic prototyping and implementations. Storyboards are done up to illustrate how we comprehend the requirements given in Taking Off stage. This helps our team to have a common perception of the functionality. For the implementation, we did the components by means of hard coded values while we try database connection.
Both phases are well on track.
At phase 2, more concrete prototype and implementation was done as we get more confident with our development tools. Here we encountered a simple change in requirement which is not trivial to our schedule. Upon meeting up with our sponsor, he suggested changing the tooltip to pop up panel for the info window. We accepted this change request as tooltip is to be implemented later to guide our users around RIBA which can complicate our tooltip info window.
At phase 3, we did more development work. The attribute search prototype is entirely revamped even before proceeding to implementation. This is because our sponsor had a clearer idea of how the attribute should function and the analysis is should perform after seeing our first prototype.
The layer manager was entirely revamped because of logic construction change. We were plotting directly onto the map provider rather than on separate layers which prose us problems when we have to manage many layers.
The component most affected by this change was drawing polygons. We were initially using an external library (dreamingwell) to plot polygons but the performance was horrendous. The polygons were in fragments and would not stick to the correct positions when we zoom in and out of the man. In fact, they were flying everywhere as we navigate around RIBA. We thus change our logic construction to use make use of PHP and render the_geom, a geometry data for each polygon to return us a set of latitudes and longitudes. Finishing this is not the end. With this set of data, we have to construct several own methods at Flex side to draw the polygons. This is also an example of coding challenge where we have to write codes, test and debug on both PHP and Flex before synchronizing both sets of data so that they can work seamlessly together.
At this stage, all the data are grabbed from our database dynamically and parse over to Flex.
At phase 4, we did more implementations. There was an improvement work done on Layer Manager. This change was internal driven as we discovered a markerclip feature of the modestmap, our very important external open source geospatial API that helps us build the basic geospatial components of RIBA. Markerclip allows us to manage our layer better as each layer grabbed from the database is plot onto a markerclip. This concept is similar to photoshop where the different design components are on a layer. This means that we can switch the individual layers on and off easily by means of checkbox toggling. This suits the term "layer manager" well for our component!
Our end users request symbol customization to differentiate symbols from different layers. Therefore we decided to implement color randomization which automatically selects a random color for the layer that the user decides to load. We thought this will reduce the hassle for the users to individually select the color for each layer especially if they are loading 20 layers on RIBA.
Layer manager is even more dynamic in the sense of user experience. Checkbox rendering is implemented into the layer manager to allow users to toggle individual layers easily.
As we did code modularization at Phase 3, the simple implementation of heatmap at Phase 3 has to be adapted to the new modularized codes.
At Phase 5, we did as much implementations as Phase 6 as we are warmed up with the development tools. Firstly, we received some geospatial data from National Parks. We were all excited about it but we discovered that the layers are in the wrong projection. This affected our polygon drawing as it was plotting at the Philippines boundary. They also have meaningless IDs which do not link to other layers given to us.
Thus, we used Manifold, a desktop GIS application, to help us change the projection, rename attributes to more meaningful terms and generated unique IDs for each data.
Improvements were made to Snapshot function as we discovered methods in Flash Builder 4 that helped us to finish this functionality seamlessly. We also decided to save the snapshot as png file type because this is the highest resolution. This snapshot function was requested by National Parks team as they find it a hassle to print screen and crop the image. They want a function that allows them to conveniently put the image captured from RIBA into their reports, proposals and presentations.
Attribute search was improved from plotting the search result to expand into 3 different displays: filter, highlight and view data. This gives flexibility for the user to view it the way they want it. At this point, the PHP is also dynamic in the sense of auto attribute population when the user selects a layer.
Application UI is improved to apply Human Computer Interaction (HCI) theories we read up during Taking Off Phase. We minimize the number of clicks and streamline the function flow.
As of Midterm presentation, 27th September, we reached the end of Phase 5!
5 out of 6 development work is in progress now. Thus, we are a few days ahead of schedule. However, we still have to work hard to keep our schedule on track.
Info Window is changed from a popup panel to a speech bubble for aesthetics purposes. Tabs will be implemented to the Info Window to include Attributes and Video. We decided to grab youtube videos uploaded by our end users base on the marker's attribute.
Attribute search is to add in an analysis feature (graph analysis) into the "view data" result display. This is to further enhance analytical function of RIBA
Heatmap is not shown in midterm presentation as we are still working on its aesthetics. Heatmap is a geospatial analysis which we will evaluation more for final presentation.
Note that UAT is different from Usability Studies. Usability Studies are sessions which we will meet with our stakeholders to get their critics which are recorded in our minutes and reflected in our schedule. At this stage, our clients and end users will be familiar with RIBA and will have a good perception of what RIBA is supposed to do for them. Thus, the UAT will be the final session where they test RIBA our prior to the transfer of RIBA ownership to KooPrime.
After this phase, we will be buzzing around preparing for the final showdown!!!
Detailed Gantt Chart: Media:goodmix_schedule.xlsx
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