DDGJSpresents

A

User Interfacefor the

Apple inc.

iTime Device

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

The iTime and DDGJSEver 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.

DDGJS InvolvementDDGJS 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!

Assumptions made for the iTime projectDDGJS 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.

Requirements diagrams - Use casesBasic 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

Requirements diagrams - Use casesDevice 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

Validation planAffected 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?

Validation planSafety 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?

Software Design – Class Diagram

Software Design – State Diagram

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

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

Lessons learned - CommunicationsBetter 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.

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.

Lessons learned - Planning

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.

Lessons learned – Assigning Tasks

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.

Lessons learned – Things to do Differently

Thank You

Questions?