Difference between revisions of "IS480 Team wiki: 2012T1 Evynty Project Progress"
Line 214: | Line 214: | ||
|} | |} | ||
− | === Quality:=== | + | === Quality: (Nik) === |
Explain the quality attributes (non functional) of your project deliverables. Have you designed the architecture, use a design pattern, etc? Does your architecture address scalability, performance, reliability, availability, fault tolerance, usability, etc. Does your design address maintainability, flexibility, configurability, etc. Be brief here but you can link to diagrams or code detail pages. Do not repeat the technical complexity part, link to it if necessary. | Explain the quality attributes (non functional) of your project deliverables. Have you designed the architecture, use a design pattern, etc? Does your architecture address scalability, performance, reliability, availability, fault tolerance, usability, etc. Does your design address maintainability, flexibility, configurability, etc. Be brief here but you can link to diagrams or code detail pages. Do not repeat the technical complexity part, link to it if necessary. |
Revision as of 10:08, 3 October 2012
Home | Team | Project Overview | Project Management | Usability Studies | Documentation | Resource & References |
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:
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 | |
1 | View | View | |
2 | View | View |
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 | |||||
Sprint Performance | |||||
Bug | |||||
Project Performance | |||||
Project Success |
Technical Complexity: (Nik)
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.
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: (Nik)
Explain the quality attributes (non functional) of your project deliverables. Have you designed the architecture, use a design pattern, etc? Does your architecture address scalability, performance, reliability, availability, fault tolerance, usability, etc. Does your design address maintainability, flexibility, configurability, etc. Be brief here but you can link to diagrams or code detail pages. Do not repeat the technical complexity part, link to it if necessary.
Deployment:
In an iterative approach, ready to use system should be available (deployed) for client and instructions to access the system described here (user name). If necessary, provide a deployment diagram link.
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.