HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2011T1 Aperture - Final-Term Wiki"

From IS480
Jump to navigation Jump to search
Line 86: Line 86:
 
===<span style="color: #797979; padding: 0px 30px 0px 29px;">Technical Complexity</span>===
 
===<span style="color: #797979; padding: 0px 30px 0px 29px;">Technical Complexity</span>===
 
<div style="border-left: #797979 solid 12px; padding: 0px 30px 0px 18px; font-family: Arial, Helvetica;">
 
<div style="border-left: #797979 solid 12px; padding: 0px 30px 0px 18px; font-family: Arial, Helvetica;">
*TEXT TEXT
+
*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.
  
*TEXT TEXT
+
*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.
 
<br />
 
<br />
 
</div>
 
</div>

Revision as of 22:42, 19 November 2011

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.
  • Client suggested that we explore Angular JS for our front-end views. We divided the team into 2 separate teams. The front-end team would develop the views, while the back-end team developed the models and controllers.
  • PayPal required us to have a live application before allowing us to create a live PayPal account for Pivotal Expert.
  • We met Andy Croll, a talented designer, for his feedback on the design and usability of our website.
  • 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

Describe areas of the project that were particularly difficult and how they were dealt with, whether successfully or not. Again, a few sentences are enough. If there are no challenges, remove this section.

  • TEXT TEXT
  • TEXT TEXT


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.

  • TEXT
  • TEXT


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

<<link to metrics section on main wiki>>


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 <<link to User Experience Testing (UET)>>
System tests <<link to "Testing" section below>>
6. Handover Deployment Instructions <<link to "Deployment" section below>>

Quality Achieved

<<link to midterm wiki "Quality Achieved">>

Testing

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

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

Deployment

TEXT TEXT

TEXT TEXT

Reflection

[ TEAM ] Aperture

TEXT TEXT

TEXT TEXT



[ 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