HeaderSIS.jpg

IS480 Team wiki: 2012T1 Evynty Project Progress

From IS480
Jump to navigation Jump to search
Logo 2 - confirmed.png


  Home   Team   Project Overview   Project Management   Usability Studies   Documentation   Resource & References


 

Project Progress Summary

 

Project Management

 

Quality of product

 

Reflection


Project Progress Summary


Since our Acceptance Presentation, Evynty has embarked 2 Sprints of Development. Sprint 1 was planned to take place from '20 August 2012 to 9 September 2012' and Sprint 2 took place from '10 September 2012 to 30 September 2012'. With the completion of these two sprints, with improvements in design still needed, the following functions have been developed:

  • Login/ Register
  • Forgot Username/Password
  • Access Dashboard
  • Manage Account Settings
  • Receive Notifications
  • List Venues
  • Manage Venue
  • Manage Schedule
  • Manage Venue
  • Manage Packages
  • Project Highlights:

    The project ran into a few problems along the way. Obstacles were faced and they were overcame. Click here to view all the events that happened.

    Project Challenges:

    Our project went wrong at the acceptance stage, we were rejected after our acceptance presentation.

    It was a smooth sailing journey all the way to our acceptance. The team did a mock presentation to our supervisor 1 week before our presentation, and got the green light that it was ready for our idea to be accepted as a FYP project. Though we did not get accepted after our acceptance presentation, the team was determined to make it work as we know that we had the capabilities to. Thus we identified what went wrong and what was missing from our project and started work on it immediately. The team stayed together for three days straight to work on Evynty, delivering functions such as homepage, login, register, dashboard management, search results and sample venue profile. An acceptance appeal was held to our supervisor afterwards, and our project was then accepted.

    The team learnt a valuable lesson from this experience. That we should never assume that things will go our way, and we should always be prepared for the worst scenario, anticipate it and make sure mitigation plans are in place to make it work.

    Project Achievements:

    Beta Partners:
    Believing in our project, the team was able to secure several beta partners who are venue owners, who will be with us throughout our journey; idea sharing -> development -> launch. These venue owners will witness the progress of our product and service since the beginning, and providing us valuable feedback to make Evynty better.


    Methods and processes:
    Bi-weekly updates: The team found that the bi-weekly updates of current status and progress of individuals and the team as a whole allows them to understand the current situation better. As the SCRUM framework is adopted, the team only meet on a need basis. Thus by having the bi-weekly updates, it allows everyone to be be aware of critical activities.


    Teamwork:
    Team Bonding: The team meets for badminton every Wednesday of the week, and this allowed everyone to take time off school and work on the project to relax our brains and body. After the session every week, the team feel much refreshed to continue work again.


    Project Management


    This section describes briefly some of the project management aspects of Evynty. For full description of Evynty's Project Management, tools and progress, click here.

    Project Schedule (Plan Vs Actual):

    The project was planned with 6 Sprints in total. Except for Sprint 0 and 5, most Sprints are a duration of 3 weeks. Sprint 0 is development planned for acceptance, where things did not turned out as they were planned. Evynty were rejected due to the lack of specificity and development progress. An appeal was planned after that, which triggered the first change of plans, causing Sprint 0 to be stretched to include development for the appeal presentation. In Sprint 1; first 3 weeks of 2012-13 Term 1, there was a change of plan, where the implementation of backbone was decided to be delayed till Sprint 3. There were no major change of plans in Sprint 2, though both Sprints had its own delays. Refer below

    Click here to see what features were planned for the Sprint, and which were completed. View also the planned and actual project schedule through gantt charts of Evynty below:

    Sprint Planned Schedule Actual Schedule Comments
    0 View View
  • Acceptance Appeal
  • 1 View View
  • Xueting being overseas
  • Under estimation of time required for tasks
  • Postponing implementation of backbone
  • 2 View View
  • User Testing to be done before Mid Term Presentation

  • You can also follow our progress bi-weekly by downloading our bi-weekly progress updates here.

    Project Metrics:

    For a full view of the set of Project Management Tools of now Evynty Tracks its performance and progress, click here.

    Below is a list of public metrics that Evynty uses you can follow:

    Metric Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
    Feature Selection Feature Ranking.png Feature Selection Sprint 2.png
    Sprint Performance Sprint Velocity.png Screen Shot 2012-10-03 at 2.39.13 PM.png
    Bug
    Project Performance Project Velocity.png Evynty 2 Project Progress.png
    Project Success Project Success after Sprint 1.png Evynt 2 Project Success.png

    Technical Complexity:

    Describe and list the technical complexity of your project in order of highest complexity first. For example, deploying on iPhone using Objective-C, customizing Drupal with own database, quick search for shortest flight path, database structure, etc.

    Customizing Django's core apps to meet Evynty's needs Django's core apps come with a lot of useful functionality. They are also a dependency for several 3rd party apps. Thus, it makes sense to use them. An example of a core app would be auth.user that implements the SessionMiddleware. However, implementing it as it comes is not sufficient for our needs and we have to make customizations such as using emails instead of usernames, ensuring emails are unique and verified and extending the length of the certain fields. Yes, all this sounds extremely simple to change. However, the challenge is in doing all of this without touching the source code of django's apps! It is not recommended to touch django's source code for the obvious reason that a lot of things in django might break if you unknowingly start to customize it for your own needs.

    So, we had to use a signals system to implement these changes. By adding a signals layer, we essentially have a middleware that listens to signals which tell us when a particular type of object is saved or retrieved. We then modify the data in order to trick django into thinking it is getting what the core app wants but we are actually customizing the data for our needs. This was a challenge.

    Mimicking a Google Calendar-like functionality for venue schedules For the venues to mark their schedules as available or not, we had to mimic the functionality that one sees in google calendar. We used a highly optimal database structure to store availability events that could be recurring. We then had to use complex processing to get, edit or split these events. A lot of cases had to be considered and carefully thought out before they could be functional.

    Building an app on Django and deploying it on a Unix environment This is rather less complex but learning a huge framework like Django was a challenge for all of us. Also, learning how to deploy an app on Nginx and Apache required reading alot of documentation and a lot of trial and error. This was a big complexity that we faced during the early days of our project as none of us had used a framework/moved a language other than java before.

    Quality of product


    Provide more details about the quality of your work. For example, you designed a flexible configurable system using XML.config files, uses Strategy Design Pattern to allow plugging in different strategy, implement a regular expression parser to map a flexible formula editor, etc.

    Project Deliverables:

    Stage Specification Modules
    Project Management Minutes Refer to Minutes Table here
    Metrics Refer to the list of metrics above
    Requirements Storyboarding Refer to Feature Requirements here
    Analysis Use case Refer to the list of use cases here
    Business Process Diagram to do
    UI Evolution Follow our Design Evolution here
    Design ER Diagram Refer to our ER Diagram here
    System Diagram Refer to our System Diagram here here
    Testing Test plan Download the Test cases we perform internally
    Consumers Manuals here

    Quality:

    Scalability - Scaling can be easily done by the webhosting service that we use. This is abstracted away from our responsibilities. We are using a well renowned hosting service called Webfaction that can scale our apps to our needs.

    Performance - The use of the django framework and its best practices ensures a reasonable level of performance on the website. Besides that, much thought is given to the number of database calls made and all possible attempts are made to minimize the calls. Also, django has a built in cache setup that is used to improve performance. Once again, from the user experience point of view, browsing the website should be speedy and smooth. If a need arises and if this get feedback at UATs saying that the website is slow, attempts will be made to improve performance.

    Reliability, Availability, Fault Tolerance - This is handled by our web hosting client Webfaction. Webfaction is well known and reliable. It has a good reputation in the industry. All responsibility for these requirements is abstracted away from us and towards their managed hosting service.

    Usability - Usability is one of our top priorities and we try to ensure a high level of usability on our website via user-testing and feedback from our beta customers.

    Maintainability - The code is being written in a clean manner strictly adhering to pep8 standards of coding in python. Also django best practices are being followed. Great effort is put into the avoidance of editing code in core or 3rd party apps. Workarounds are used in user apps so that there are no unexpected breaks in the code when additional 3rd party apps are added in the future or if a django version is upgraded.

    Deployment:

    The website is deployed at http://evynty.com via FTP before the end of every sprint. There is always a user with the username/email: nikunj.handa@evynty.com that has superuser access to the website under a secure password that will not be revealed on this wiki. If a supervisor needs this password please contact any member of our group.

    Testing:

    Describe the testing done on your system. For example, the number of user testing, tester profile, test cases, survey results, issue tracker, bug reports, etc.

    Reflection


    Compile common lessons and reflection for the team and for each team member. Be brief.

    Team Reflection:

    Key lessons learned – indicating where the team improved, or would do things differently next time. You may refer to the learning outcome summary in your proposal. A very short checklist style will suffice. It would be very convincing if the knowledge is share at the wiki knowledge base and linked here.

    Individual Reflection:

    Describe in a paragraph, the key areas of learning or improvement. These should be personal areas of growth or learning. Each individual should list his/her effort, responsibility, actual contributions and personal reflection. Do not repeat team project contributions or member roles. Link if necessary.