HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2012T2 box.us Final"

From IS480
Jump to navigation Jump to search
Line 93: Line 93:
 
** <b>Medium Priority</b>:  UI suggestions that changes the understanding of the system
 
** <b>Medium Priority</b>:  UI suggestions that changes the understanding of the system
 
** <b>High Priority</b>:  Usability Catastrophe or Software Bugs
 
** <b>High Priority</b>:  Usability Catastrophe or Software Bugs
* Discussed with client what could be done and what could not be done
+
* Discussed with client what were the focuses
 
|-
 
|-
 
|}
 
|}

Revision as of 20:34, 20 April 2013

degree=90
HOME   PROJECT OVERVIEW     PROJECT MANAGEMENT   DOCUMENTATION  
         


What Is This Project About?

TopPartForWiki.png

Check out our 1 min ++ video pitch to find out what this project is about at Youtube

Final Presentation Slides: coming soon

Deployed Site: Empact ACT

Demonstration Site: Empact ACT(Staging)

Initial Proposal: Proposal



Project Highlights:

What unexpected events occurred and how were they handled?

style="width:100%"

Managing the Great Amount of Issues being Highlighted during Deployment

  • Ranked the Issues based on their Priority
    • Low Priority: Minor UI suggestions and issues
    • Medium Priority: UI suggestions that changes the understanding of the system
    • High Priority: Usability Catastrophe or Software Bugs
  • Discussed with client what were the focuses
  • Managing the Great Amount of Issues Being Highlighted
  • Refining the Quality of the Application
  • Technical Challenges faced with the Statistics
    • Took longer than expected to work it out
  • Notifications requirements gathering took longer than expected

Project Challenges:

  • Gathering requirements
  • Dealing with constant changes
  • Meeting the needs of the client and balancing with the workload of the individual team members

Project Achievements:

  • Issue Tracker - Implementing the issue tracker has helped us in a few ways:
    • Systematic way of keeping track of issues being raised up along the way
    • A good way for the team of keep track of what had been completed and track back again

Provide more details about the status, schedule and the scope of the project. Describe the complexity of the project.

Project Schedule (Plan Vs Actual):

Compare the project plan during midterm with the actual work done at this point. Briefly describe a summary here. Everything went as plan, everything has changed and the team is working on a new project with new sponsors or the supervisor is missing. A good source for this section comes from the project weekly report.

Provide a comparison of the plan and actual schedule. Has the project scope expanded or reduced? You can use the table below or your own gantt charts.

Iterations Planned Actual Comments
1 Customer CRUD 1 Sept 2010 25 Aug 2010 Fiona took the Sales CRUD as well.
Trend Analytic 1 Sept 2010 15 Sept 2010 Ben is too busy and pushed iteration 1 back
2 User tutorial 1 Oct 2010 Removed proposed by Ben
Psycho analysis 1 Oct 2010 New module proposed by sponsor

Project Metrics:

  • Schedule Metrics
  • Bug Metrics
  • Issue Metrics

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.

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:

List the artifacts produced for this project. The entire deliverable can be submitted in a separate thumb drive, web repository or place in the IS480 team wiki.

Stage Specification Modules
Project Management Minutes Meeting Minutes
Metrics Bug metrics
Requirements Story cards CRUD Customer, Trend Analytic
Analysis Use case Use Case Diagram
System Sequence Diagram client, server
Business Process Diagram Process Diagrams
Screen Shots CRUD Customer, Trend Analysis
Design ERD Diagrams V1,V2,V3,V4,V5
Class Diagram 1, 2, 3
Testing User Testing 1 Test Plans Test Plans used
User Testing 2 Test Plans Test Plans used
Heuristic Evaluation User Scenarios User Scenarios used
Integration Testings Integration Testings
Handover Manuals User tutorial, Developer manual, Setup manual
Code client server
Deployment Diagram instructions

Not all parts of the deliverables are necessary but the evidence should be convincing of the scope.

Quality:

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:

Release 0.1
Key Changes


Feedback Collected


Release 0.2
Key Changes


Feedback Collected


Release 0.3
Key Changes


Feedback Collected


Release 0.4
Key Changes


Feedback Collected


Release 0.5
Key Changes


Feedback Collected


Testing:

User Testing Integration Testing Deployment Testing
Objective: To collect feedback concerning usability of our application Objective: To test the quality of our application Objective: To collect feedback when application is being used in live environments
When: When: When:
How: How: How:
Findings: Findings: Findings:

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

Team Reflection:

  • Managing client expectations
  • Learning to collaborate more effectively in a team
  • Leveraging one another's strength and weaknesses
  • Being a good team player within the team
  • Learning to have fun as a team!
  • Our IS modules have helped to prepare us for the demands of an IT project

Individual Reflection:

Kevin
As I review through my initial learning outcomes that I set out to learn, I felt that I have managed to meet these outcomes in the following way:

  • Motivating IT Project teams: Bringing together people from different walks of life together to work on an IT project has sharpened my skills in handling with people and being more cognisant of people management issues and how to deal with group cultures and team norms
  • Evaluating IT project ideas: FYP has taught me how to be aware of what are the current issues facing IT projects. It has taught me how to evaluate these and adopt a T-model by being able to think about what are the broad issues that are going to affect IT decisions and what are the deep issues that are specific to the issue being raised.
  • Time Management Skills: FYP has taught me to be aware of the time that I spend managing the team, managing my own workload within the team and juggling my workload with my other modules that I was taking in school.
  • Client Negotiation skills: I was able to apply the negotiation skills that I learnt from a module to achieve integrative outcomes for the client and the team, and what are the tactics that are readily available to deal with such situations.
  • Applied Project Management Skills: The FYP experience has been an extension of what I have learnt in Software Engineering and I was able to refine my skills in scope management, schedule management and further extend the practicality of metrics being used within a project.

Sometimes, the client writes a report to feedback on the system; this sponsor report can be included or linked from here.