1 / 17

Virtual Mechanics

Virtual Mechanics. Group – 12, CMPT 275, Simon Fraser University Fall Semester 2009 Marc Lynch Tyler Shao Jeffrey Limao Greg Steffensen Chien -Chi Chen . AGENDA. Introduction to Virtual Mechanic Demo Architectural diagram and summary

nhu
Download Presentation

Virtual Mechanics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Virtual Mechanics Group – 12, CMPT 275, Simon Fraser University FallSemester 2009 Marc Lynch Tyler Shao Jeffrey Limao Greg Steffensen Chien-Chi Chen

  2. AGENDA • Introduction to Virtual Mechanic • Demo • Architectural diagram and summary • QA steps and user acceptancetesting • Bugs in the software • Feedback from real users • Post-mortem analysis

  3. INTRODUCTION • Users can utilize the Virtual Mechanic application to dismantle and learn about complex machines and organisms in a graphical user environment; all without having to get their hands dirty. • They can drag and drop pictures of various systems, post comments and photos and take part in discussions about each component and the system overall.

  4. A QUICK DEMO

  5. ARCHITECTURAL DIAGRAM

  6. INTEGRATION TESTING STEPS • Step 1 - Verify menu controls and help function • Step 2 - Opening new machines • Step 3 - Manipulating the machine • Step 4 - Viewing and posting new comments, for a component or the machine • Step 5 - Viewing photos for a component, or the machine

  7. USER ACCEPTANCE TESTING • In earlyversions of the software (versions 1 and 2), UA tests were only partial success’ (not enough features to test) • Later versions the UA tests were a complete success, and we were given compliments on our “intuitive” UI • Users were given a set of simple objectives with no guidance at all, as well as a time limit to complete those objectives • All of our UA test subjects were able to complete the objectives with time to spare

  8. UNIMPLEMENTED FEATURES • Zooming in the Machine view and in the view photo page • Photo taking and uploading for sharing photos with other users

  9. POTENTIAL SOFTWARE ISSUES • If the user has no connection to the internet, then they cannot view comments or photos • Offensive comments are not filtered and deleted

  10. Drawbacks from implementation choices • Comments, or photo information is not stored on the device (an efficiency or time issue) • User names are not necessarily unique (an identity issue)

  11. FEEDBACK • Very clear and understandable user interface, very easy to use • It would be nice to have a feature where users may make their own machines • Build more machines for this application • Machines can be more detailed, more components

  12. POST-MORTEM Worked well: • Giving out specific positions to members (i.e. Minutes manager, Lead Coder, etc.) • Weekly meetings • working together in groups, frequent meetings, updates using text-messaging, keeping record of everyone’s schedules Didn’t work well: • Google wiki made it confusing keeping track of changes to documentation • Conflicting schedules; needed better time management • No permanent project manager

  13. POST-MORTEM Technical Problems: • No set formatting techniques for documents until later in the project • Personal computer didn’t support programming environment • No SDK or old SDK in libraries at one point, no personal Mac computers for everyone, some unfamiliar with iPhone technology Human Problems • Conflicting schedules • Poor communication with members • Members not showing up for meetings

  14. POST-MORTEM What would wedo differently? • At least two meetings a week • Set up a better method for communication • Take home numbers as well as cell numbers • Communicate with calling when texts are not responded to What would we do the same? • Meeting with team members • Setting out agendas and deadlines for each assignment

  15. POST-MORTEM Advice for future cmpt 275 students • Learn Objective-C early and thoroughly! • Communicate with each other VERY often! • Always have a backup plan • Have at least two members working together on any given task, in case one has to drop out or step back. • Make sure that your documentation specialist is comfortable with word (headings, sections, page breaks… do a little research it’ll make life easier)

  16. QUESTIONS?

  17. THANKS That is the end of the presentation. Thanks for your time and your consideration.

More Related