2. 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

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

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

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 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 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.