1 / 18

DDGJS presents A User Interface for the Apple inc. iTime Device

DDGJS presents A User Interface for the Apple inc. iTime Device. Overview. Overview – What Is the iTime? Requirements & Validation Plan – A Review of the formal requirements for the iTime Software Designs – Design Overview and Choices Schedule – The iTime Implementation Schedule

telyn
Download Presentation

DDGJS presents A User Interface for the Apple inc. iTime Device

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. DDGJS presents A User Interface for the Apple inc. iTime Device

  2. Overview Overview – What Is the iTime? Requirements & Validation Plan – A Review of the formal requirements for the iTime Software Designs – Design Overview and Choices Schedule – The iTime Implementation Schedule Lessons Learned – Insight into the Team Process and how we can make it better next time.

  3. The iTime and DDGJS Ever want to travel through time? Well have we got a product for you!? The iTime is a new device that will revolutionize the world as we know it. The iTime is a portable, personal, pocket sized Time Machine. The iTime is built by Apple inc. and has a physical look and feel identical to the wildly successful iPhone.

  4. DDGJS Involvement • DDGJS has been contracted by Apple inc. to build the User Interface software for the iTime device. • Specifically we will be implementing the following software functionality: • Allows the user to travel back and forth in time quickly and easily • Store and use bookmarks of favorites times • Research specific times using the built in Encyclopedia of Time • Review detailed logs of your past time travel activities • And it all has to meet Apple’s extremely high quality for a useable system!

  5. Assumptions made for the iTime project • DDGJS made the following assumptions regarding the iTime project: • The device does not travel in time, but instead creates a visual and audible experience for the user. • We are not responsible for the physics of how the iTime works. Apple provides us with an API and we use it. • We are not responsible for the ethical or moral concerns that come from using the device. • Beyond the functionality mentioned in the previous slide, we are not building any additional functionality. • Apple provided us with the User Interface components available on the iPhone.

  6. Requirements diagrams - Use cases • Basic Functionality • U01: Unlock the device • U02: Lock device • Time travel • U03: Travel to a selected segment in time • U04: Travel to the Last Place • U05: Travel to the home location • U11: Travel to bookmark Encyclopedia • U06: Use Encyclopedia • U07: Search of people • U08: Search for places • U09: Search for events • U10: Create Bookmarks

  7. Requirements diagrams - Use cases • Device Maintenance • U12: Check Battery level • U13: Check Memory information • U14: Review/Manage Log • U15: Update device software • U16: Update encyclopedia content • U17: Export log information

  8. Validation plan • Affected Parties • Customers (Apple’s management or marketing groups) • Hardware development group • End-user customers • External Variables • iTime hardware design • Scope of development • How do requirements get created? • How do requirements get validated?

  9. Validation plan • Safety Concerns • Is going to a specific time and place easy and accurate enough, or does it need fine-tuning? • Is the encyclopedia information helpful? • Does it feel safe (not too disorienting, easy to return “home”)? • Does the user interface meet your expectations for use, and storing personal settings and bookmarks?

  10. Software Design – Class Diagram

  11. Software Design – State Diagram

  12. Implementation Schedule • Implementation broken up into unrelated tasks: Controls, Encyclopedia, Hardware Interface, Logging and Security. • Dependencies based on worker time and availability, not functionality. • Three iterations of Design, Development and Testing, before final Testing phase and Deployment. • Very tight and optimistic schedule.

  13. Implementation Schedule • Total project length ~ 3 months. • Five workers would require 2624 hours, $262,400 at $100/hr. • Highest risk in first Design & Development iteration, was given the most time. • High impact by schedule changes at any point past Requirements, some slack in Testing phases.

  14. Lessons learned - Communications Better Communication. Meet as often as possible Get a better understanding of the relationship of what the team is building.  I think we were not really clear about the specific features we were going for. Have some sort of email response/input from each member each week to make sure everyone is up to date and knows what's going on. More defined roles of everyone on the team which play to their particular assets.

  15. Lessons learned - Planning There should be discussions for a projects final destination and feasibility. Even if the project is a theoretical one, there should be a decent effort made to attempt to answer all or most questions asked about it. It is important to understand and focus on the use cases. Decide length and breathe of what the user will do before continuing with the project.Having a prototype is invaluable. Even if we just have a phone that looks like the final iTime it is a wonderful thing to be able to convey ideas by simply showing or clicking around.Read project spec and come up with customer requirements (aka what the professor wants). Straying off and working on something incorrect costs time and effort.

  16. Lessons learned – Assigning Tasks Assign things as soon as they are possible and more importantly get confirmations that the respective individuals are aware of their tasks. Just sending an email is not enough and the lack of confirmation may mean having to do a bunch of work myself at the last minute. Assign more people and therefore less of a workload to each person for each phase of the project. Perhaps assign 2-3 people per piece so no large chunk is entirely dependant on one person. More defined roles of everyone on the team which play to their particular assets.You need a strong leader. It is the difference between all the work getting done or sputtering to a stop.

  17. Lessons learned – Things to do Differently Might've been helpful to go into more detail about the effects of seeing the future, why or how it couldn't be changed, or what the effects would be if it was changing all the time. Try to understand what everyone's strengths are ahead of time so that assignments and assignees fit perfectly. There should not be amentality that since someone didn't do "enough" during the last iteration, they should be assigned leader or something they would have trouble with during the next. Do not get caught up in the implementation of detail. More up front planning and requirement definition is a must. Maybe something like the XP Planning Game to facilitate that.

  18. Thank You Questions?

More Related