HeaderSIS.jpg

IS480 Team wiki: 2011T1 Aperture - Final-Term Wiki

From IS480
Jump to navigation Jump to search
Pivotalexpert2-aperture-wiki-finalwikiupdate-header-v01-700px.jpg





Project Progress Summary

Project Highlights

  • The previous team's code had quite a few issues. So we had to start building the application from scratch.
  • PayPal required us to have a live application before allowing us to create a live PayPal account for Pivotal Expert.
  • Project Management
    • The front-end team took 7 weeks to learn Angular JS, which was much longer than expected.
    • We did not account and plan for a number of functionalities when we decided to build the application from scratch. In addition, The difficulties of several tasks were underestimated. In other words, we allocated too few points to tasks. This resulted in an overly-optimistic schedule. Eg. Completing basic functionalities by week 4.


Project Challenges

  • Client suggested that we explore Angular JS for our front-end views, while using Python for the back-end models, which communicated with each other through the RESTful interface. Although this allowed the team to develop both components as two independent applications, there were quite a few technical risks we had to overcome, such as learning new languages and technologies. We were not entirely successful in overcoming the technical complexity of integrating them, and we had to depend on the lead developer many times.
  • While building the application from scratch, we had ideas to add in new features to improve the application, on top of the requirements. This resulted in a bigger scope, and we had to prioritize the important improvements, while discarding the rest


Project Achievements

Methods, technologies, processes, teamwork, etc. which were particularly successful – highlight things which worked very well towards completing the project. A bulleted list of one to two sentences each will do. If there are no achievement, remove this section.

  • Successfully pushing PayPal live
  • Implementing new features, while rebuilding and redesigning the entire application from scratch.
  • Successfully designing and integrating an architecture which was entirely new to all of us


Project Management

Project Schedule (Planned vs Actual)

Planned Project Schedule

LINK Planned Project Schedule Page
3.. Project Management
3.1.. Planned Project Schedule
3.1.1.. Planned Project Timeline
3.1.2.. Planned Project Iteration Breakdown

Actual Project Schedule

LINK Project Management - Actual Schedule Page
3.. Project Management
3.2.. Actual Project Schedule
3.2.1.. Actual Project Iteration Breakdown

Project Metrics

Metrics

LINK Main Page - Project Metrics
4.4.. Metrics
4.4.1.. Velocity Metric
4.4.3.. Bug Metrics
4.4.3.. Bug Tracking

Technical Complexity

  • Utilizing two different programming platforms - AngularJS (on HTML, Javascript and CSS) for the views, and Python for the models and controllers. Many of us did not have any background in either of the platforms, and it took us a while to understand the basics. As most of us were interning as developers during the summer holidays, our learning progress was slow as we had other programming languages to learn during that time as well.
  • AngularJS, a new cutting-edge Javascript framework currently being developed made the learning curve steeper. Their documentation is not entirely completed and it is difficult to find solutions to problems online, as the Angular Community is still small. We had to post our questions on the Angular discussions in Google Groups. Building an application using AngularJS also broke many web-development norms: With AngularJS, the entire application could be designed to hardly rely on an application server. This means that the front-end developers and designers must begin thinking about things like routing controllers, something that traditionally was dependent on an application server.
  • Implementing PayPal payments required us to not only understand the PayPal API, but required us to get clearance from PayPal before being able to use it in our application. Since this API was going to involve money, getting that clearance was not as simple as just filling out a form. Also, the payment process we're using is the delayed-chain-payment, which is not a common type of PayPal transaction.
  • Developing an application that uses mainly REST was challenging. Although we were taught about the REST architecture in our previous module, we had no experience developing an entire application that relies on REST. We also had to learn to design JSON responses, not just how to create the responses from the back-end, but also how to take the data from the response and use it on the front-end. We also had to learn how to write a REST server on Google App Engine.
  • Figuring out how to deal with sessions was also a complicated process due to the following:
    • We were using a third-party service, Janrain, to handle log-ins. This means our system had to be able to retrieve a key from Janrain, then generate user instances and sessions.
    • We had to be able to tell the front-end AngularJS application, which does not rely on the back-end application in any way apart from REST responses and requests, about these sessions.
    • We had to find a way to ensure that people weren't able to abuse the site by sending their own REST responses and requests to our Python back-end.


Quality of Product

Project Deliverables

S/N Stage Specification Modules
1. Project Management Minutes

Project Summary - Minutes Repository Page

Metrics

Main Page - Velocity Metrics, Main Page - Bug Metrics

2. Client's Requirements List of functionalities Project Overview - Client Requirements Page
3. Analysis Use case

Main Page - Use Case, Project Overview - Use Case Description Page

4. Design Class Diagram <<Upload doc by Daniel/Raymond>>
5. Testing UET test results User Experience Testing (UET) Page
System tests Final-Term Wiki Page - Testing
6. Handover Deployment Instructions Final-Term Wiki Page - Deployment

Quality Achieved

We've achieved a very unique design with this application. The application itself has two major components. The front-end component is written entirely upon the AngularJS framework, a Javascript framework that allows the use of the MVC concept on nothing other than HTML, CSS and Javascript, while the back-end component is written entirely on Python, and provides a REST server for the front-end Angular component to get and put data.

The Front-End's responsibility is to control the different views a user can access depending on the URL, and controls how the data is presented to the user. It's architecture is designed to have its own MVC component. The views are essentially a whole set of HTML templates, while the controllers are a set of JavaScript functions that route the templates and data based on the URL, and the data retrieved from the Python server. The Models are objects created from the JSON responses received from the Python server which the front-end controllers and views can use to decide where to route, and to display.

We have also designed the front-end component to run entirely off a single HTML file, using our AngularJS controllers to dynamically change portions of this HTML file. This means that the entire website loads almost just once. Except on a few occasions, the user is capable of navigating through the application without ever seeing the page reload. This also means many components such as the JavaScript files and the CSS stylesheets only have to be downloaded by the browser once. This results in a significantly snappier performance for the user, as well as reduced bandwidth costs for our client.

The Back-End's responsibility is to control the business logic of the application. It too has been elegantly redesigned to be easily maintainable and extendable. The back-end's architecture includes it's own Models and Controllers. Our Models are Google App Engine Datastore Objects. We have four main controllers. The first is a RESTful controller that provides all the REST actions that the front-end is capable of calling to retrieve data. The second is a POST controller that provides the REST actions that the front-end submits data to. The third is a Janrain controller that controls the log-ins as well as the sessions. And finally, we have a PayPal controller that communicates with PayPal during payment actions.

This architecture has helped us achieve the ability to very neatly see where data flows out from and where data will flow into. This helps the front-end AngularJS team be able to introduce new sections onto the application concurrently with the back-end Python team.

In terms of the deliverable to the client, besides successfully rebuilding the application on AngularJS, we have also completely redesigned the look and feel of the application with a much more pleasant colour scheme and a much more logical UI. We've also introduced the Dashboard, a functionality that brings together all of the user's activities in a single place to allow the user to quickly view all his workrooms, projects, bids and messages. This dashboard did not exist in the original application. The new design also makes it easy for new users to know where to start, while providing frequent users with a design that let's them jump to their work quickly from anywhere in the application. At the same time, the way projects and bids work has been completely changed by the request of the client, and these changes are reflected in the application's new business logic.

Testing

Back end tests
<<Description and instructions by Raymond>>

Front end tests
<<Description and instructions by Kenneth>>

Deployment

<<Daniel's deployment instructions>>

Reflection

[ TEAM ] Aperture

As a team, we learnt the following:

  • Communication - While working on two separate components within the application, communication was a challenge between the front-end team and back-end team. Sometimes, one team wasn't aware that the other team was waiting for things from them, resulting in delays. We learnt to be clear and specific with our instructions, as there were times where instructions were misinterpreted.
  • Compromise - Having talented and strong individuals within the team, it was inevitable that there were disagreements on how certain things. It was necessary for us not to enforce our opinions, but yet agree to solution which does not compromise the quality of our application.
  • Changes are good, but not always necessary - While building the application from scratch, we had ideas to add in new features to improve the application. In addition, we also had many useful feedback on the usability of our application during our UET. We had to learn how to select and prioritize the changes, while keeping our scope manageable.


[ INDIVIDUAL ] Mark Chen

TEXT TEXT

TEXT TEXT

[ INDIVIDUAL ] Robert Chai

TEXT TEXT

TEXT TEXT

[ INDIVIDUAL ] Kenneth Kok

TEXT TEXT

TEXT TEXT

[ INDIVIDUAL ] Daniel Tsou

TEXT TEXT

TEXT TEXT

[ INDIVIDUAL ] Raymond Chua

TEXT TEXT

TEXT TEXT



[ SPONSOR ] Comments

TEXT TEXT

TEXT TEXT

Project Sitemap