Virtual MechanicsGroup – 12, CMPT 275, Simon Fraser UniversityFall Semester 2009

Marc Lynch Tyler Shao

Jeffrey Limao Greg Steffensen Chien-Chi Chen

AGENDA

• Introduction to Virtual Mechanic• Demo• Architectural diagram and summary• QA steps and user acceptance

testing• Bugs in the software• Feedback from real users• Post-mortem analysis

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.

A QUICK DEMO

ARCHITECTURAL DIAGRAM

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

USER ACCEPTANCE TESTING• In early versions 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

• Zooming in the Machine view and in the view photo page

• Photo taking and uploading for sharing photos with other users

UNIMPLEMENTED FEATURES

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

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)

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

POST-MORTEMWorked 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

POST-MORTEMTechnical 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

POST-MORTEMWhat would we do 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 toWhat would we do the same?• Meeting with team members• Setting out agendas and deadlines for

each assignment

POST-MORTEMAdvice 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)

QUESTIONS?

THANKS

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