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

From IS480
Jump to navigation Jump to search
Line 204: Line 204:
===<span style="color: #797979; padding: 0px 30px 0px 29px;">Testing</span>===
===<span style="color: #797979; padding: 0px 30px 0px 29px;">Testing</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;">
<b>Back end tests</b><br />
<<Description and instructions by Raymond>>  
1) Owner needs to install the problem Coverage.py.
2) Going to terminal, owner just needs to type python coverage-update-report.py
3) Going to the folder htmlcov, and open the file index.html and the report will be shown
<br /><br />
<br /><br />
<b>Front end tests</b><br />
<b>Front end tests</b><br />

Revision as of 14:18, 23 November 2011


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 issues
    • Required us to have a live application before allowing us to create a live PayPal account for Pivotal Expert.
    • Issue with client's PayPal account had to be resolved before they verify our applications.
    • PayPal API does not support our business payment flow
  • 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.
  • The client also requested that we do Code Coverage for our unit tests, as well as end-2-end tests. These were also something new to us, adding to our technical complexity. We had to allocate resources to tackle them, resulting in less resources for the development of our application.

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


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


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.


1) Owner needs to install the problem Coverage.py. 2) Going to terminal, owner just needs to type python coverage-update-report.py 3) Going to the folder htmlcov, and open the file index.html and the report will be shown <<Install>>

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


Our application is hosted on Google App Engine, with one GAE application for the development server, and another for the live server. The code itself is stored on our client's own GitHub account right now, so the client only needs to download the latest build from GitHub, and deploy it using the GAE Launcher. A settings.py file located in the backend folder in our application switches between live code (which connects to the live PayPal service) and the sandbox code (which connects to the sandbox PayPal service) before deployment.


[ 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

This FYP has been a challenging, yet fruitful experience. Although I did not learn as much technical stuff as I would have liked, I picked up valuable soft skills, such as working with people with different working styles. Being the Project Manager, I could have demanded many things from the team, but that would have resulted in a poor relationship with them. I had to learn to be people-oriented while achieving the goals set by the team.

Another rather painful lesson I learnt is the importance of making a firm decision based on the interests of the team, and not just to please certain team members. One example was the decision to build the application from scratch. Initially when we discussed as a team, I suggested that we build the application from scratch, as I knew the difficulties on building on an existing application, having interned as a developer. However, when the team wanted to build on the existing application, I did not try to persuade them. On hindsight, if I had been bold enough to try to convince the team, our project may have progressed faster.

[ INDIVIDUAL ] Robert Chai

This journey has been a long, challenging yet fulfilling story, in a chapter of my SMU life. Though the many needs and requirements of the project, I had the opportunity to put myself through learning many new and different techniques, tools and languages, such as AngularJS, HTML5, CSS3, jQuery, JavaScript and Wiki.

The lessons as a front-end team has taught me interesting lessons of how the successful decoupling of job scopes and tasks with proper foundational architecture in place, will significantly improve the efficiency and job capabilities of each team mate, through the experience of our roles-specific front-end and back-end teams. More importantly, associating with these techniques has also taught me that communication and compromise between team mates have became more essential than ever; a step which can either make or break a team. Through proper experimentation and trial-and-error, our teams have also perfected task-workflows that have significantly cut down on time wastage and has enabled us to create better code faster.

Being exposed to AngularJS and its simplistic ability to build web applications, has opened up my eyes to the boundless possibilities and opportunities it can bring to developers like us, in enabling us to create simple yet powerful web applications without the complexities of existing techniques.

Pivotal Expert has also opened new opportunities to further experiment my interest in design and into the intricacies of designing a web application, as well as the various mediums of collateral required for our project submission. I've learnt that "Simplicity is Always the Best Policy", however in combination of design and technological implementations, simple would meant that the job is twice as challenging, as many more hours of brainstorming, planning and trial-and-error have to be spent, in an attempt to attain a clean and simple user interface flow or layout.

Last but not least, the use of Pivotal Tracker as well as GitHub, has given me a bigger window at testing and improving how I manage my priorities and job scopes within our project. These tools has been very useful throughout my project journey and the design of each tool has covered and simplified key project maintenance chores such as Bug Tracking, Progress Effectiveness Tracking, Task Re-scheduling and many others.

In my journey so far, I'm thankful for the many opportunities that I've gained throughout this FYP journey. I've also learnt to better manage work relationships with my team mates, as well as learnt a great deal about myself, my potential and my limitations.

[ INDIVIDUAL ] Kenneth Kok



[ INDIVIDUAL ] Daniel Tsou

This project has been extremely fruitful for me with regards to technical skills. I've learnt how to take advantage of the AngularJS framework, which is a cutting edge JavaScript framework to quickly build AJAX applications, as well as familiarise myself with tons of other 3rd party APIs and frameworks including PayPal, having built my first application where really money flowed. This is quite a big deal, since my experience with PayPal has taught me the restrictions PayPal has, and how I should be communicating with PayPal's support people properly to get the most out of them quickly. It's also taught me how to architect a proper MVC design, as well as think about analytics and game achievement algorithms, and understand the limitations of Google App Engine's APIs.

With regards to project management, besides the effective use of tools such as GitHub for versioning and issues tracking, and Pivotal Tracker for effective project scheduling, I've learnt how to communicate and understand the needs of different types of people in a development team.

All in all I've learnt a lot in this project and I'm grateful for the journey.

[ INDIVIDUAL ] Raymond Chua

This journey has been very fruitful for me learning the python, using new User Experience Testing that is new to all the teammates and doing code coverage. We have been trying our new things as a team with new technology, daring to try and went on to find out out more information regarding them that has decreased the risk that we face greatly. We are proud to see most of them being implemented, and we are so glad that we did it! Many times when we face with challenges, we have a team that stand by each other and never once said quit on each other. I've learnt that working as a team requires much communication, as it has often led to problems when we thought, assume things and it did not work out as planned.

It is a great deal and achievement seeing Pivotal Expert going LIVE now and I would strongly encourage my peers to make use of it. Pivotal Expert isn't just a project chuck aside to me, it is a fruit of our labor that I know will achieve much and seeking to see it being one of the most used websites by entreprenuers and developers.

[ SPONSOR ] Comments

"The new PivotalExpert.com website delivered by the Aperture FYP team will enable us to provide many more technical internships for students in Singapore. The innovative architecture and development model adopted by the team will also make it much easier to optimize and maintain the website in the future." - Sandra Boesch, CEO PivotalExpert

Project Sitemap