Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Eosp fall 2010

482 views

Published on

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

Eosp fall 2010

  1. 1. Team HandSimDroidJustin KillianPeter FoldesAnar HuseynovIshwinder Singh
  2. 2. 2Agenda• Project Overview• Operations• Planning & Tracking• Requirements Elicitation• Project Risks• Notional Architecture• Reflections & Next Semester
  3. 3. 3Agenda• Project Overview• Operations• Planning & Tracking• Requirements Elicitation• Project Risks• Notional Architecture• Reflections & Next Semester
  4. 4. 4Team HandSimDroid Justin Anar Peter Ishwinder Killian Huseynov Foldes Singh Team Lead Support Process Planning Manager Manager Manager
  5. 5. 5Stakeholders• Bosch Research & Technology (Client) ▫ Automotive calibration and embedded systems design ▫ Model-driven development• Ptolemy Project (Collaborators) ▫ Developers at University of California Berkeley• Mentors ▫ Phil Bianco ▫ Dave Root
  6. 6. 6Ptolemy Desktop Application Model Output
  7. 7. 7Business Drivers• Act as a proof of concept for ASCET tool ▫ Inspire innovation at Bosch• Improve operations & reduce cost of calibration ▫ Running simulation on the handheld on the go ▫ Customizable UI for different purposes & different users• Freely extend open source software
  8. 8. 8Project Goals• Show simulations running on the handheld• Enable UI customization by model and per user• Create demonstrations that showcase usefulness to engineers
  9. 9. 9Paper Prototypes UI Layout Designer Handheld Ptolemy
  10. 10. 10Known Constraints• Must use the Android Platform• Must run simulations on a handheld device• Must not use any GPL code within solution• Must use Ptolemy
  11. 11. 11Agenda• Project Overview• Operations• Planning & Tracking• Requirements Elicitation• Project Risks• Notional Architecture• Reflections & Next Semester
  12. 12. 12Process: Why Scrum?• Team wanted to learn it• Research project with unknowns ▫ Agile project management framework• Evaluated TSP and OpenUP
  13. 13. 13 Operational ChallengesChallenge MitigationNobody knew Scrum Scrum Master learns and coachesCOTS Scrum tools had problems Excel ScrumSheetLittle affordance for long-term WBS, Wideband Delphi andplanning and tracking tracking chartsLong team meetings Standard meeting agenda template with time boxingNot done with all tasks per sprint, • Track actual hours worked forwhile everyone puts in the hours better estimations & priority • Established common timeAmbiguous tasks Add task descriptions and definition of exit criteria
  14. 14. 14Agenda• Project Overview• Operations• Planning & Tracking• Requirements Elicitation• Project Risks• Notional Architecture• Reflections & Next Semester
  15. 15. 15Work Breakdown Structure
  16. 16. 16Plan – Fall 2010 2010 Fall September October November December Process Selection Tools Setup Role Assignment SRE Management WBS Project Plan EOSP Team Estimation Building Proposals Paper prototypes Contextual Design Experiment-2 QAW Requirement & Notional Use Cases Experiment-1 Architecture Design SOW Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Milestone EOSP Ad hoc Scrum
  17. 17. 17 Long Term Plan 2010 Fall (732 hours) 2011 Spring (720 hours) 2011 Summer (2304 hours) Sep. Oct. Nov. Dec. Jan. Feb. March April May June July Aug. SOW Training Planning SRSDone Design Proposals SRE Tool Setup PlanningTodo Proposals High level Design Implementation Requirements • Ptolemy on • Contextual design Implementation Android • Use cases proposal • UI Layout Tool • Paper prototypes Experiments • Actor Framework Design Detailed Design Integration • Notional and testing Architecture • Experiment 1 • Experiment 2 User Guide QAW Milestone EOSP MOSP EOSP EOSP
  18. 18. 18 Semester Progress 50 45 40 35Person Hours 30 25 20 15 Remaining Complete 10 5 0
  19. 19. 19Product Burndown SRE & Bad Time Experiment Thanksgiving Tracking Added
  20. 20. 20 Estimated vs. Actual 70 60 50Person Hours 40 30 20 Estimated Actual 10 0
  21. 21. 21Time Breakdown Training Configuration 4% 8% Design 19% Requirements 45% Documentation 24%
  22. 22. 22Agenda• Project Overview• Operations• Planning & Tracking• Requirements Elicitation• Project Risks• Notional Architecture• Reflections & Next Semester
  23. 23. 23Requirements Elicitation Elicitation Method Time # Reqs Grade (hrs) Contextual Design 50 3  Use Cases 30 9  Paper Prototypes 17 7  Client Meetings 48 10  Quality Attribute 16 16  Workshop
  24. 24. 24Agenda• Project Overview• Operations• Planning & Tracking• Requirements Elicitation• Project Risks• Notional Architecture• Reflections & Next Semester
  25. 25. 25Major Risks• Desktop Ptolemy is heavy on resources and handheld has limited resources; ▫ We may not be able to meet quality attribute benchmarks• We don’t know underlying complexities and dependencies of Ptolemy; ▫ the learning curve can be steep and may delay our schedule ▫ core modifications may cause undesired effects in other portions of the system and result in schedule delays
  26. 26. 26Major Risks (cont.)• Historically the team does not finish every task that is defined in a sprint ▫ We don’t finish some important tasks that affect project milestones
  27. 27. 27Agenda• Project Overview• Operations• Planning & Tracking• Requirements Elicitation• Project Risks• Notional Architecture• Reflections & Next Semester
  28. 28. 28Quality Attributes• Wow-ability ▫ Client demonstrates the system in front of executives and inspire them• Usability ▫ Handheld user can operate it without training• Reliability ▫ Demonstration does not crash for 15 minutes• Extensibility ▫ New actors could be added within 2 weeks• Performance ▫ Real time data is processed at correct rate
  29. 29. 29Notional Architecture• Context Diagram• Component & Connector Diagram• Sequence Diagram
  30. 30. 30Context Diagram
  31. 31. 31Dynamic View
  32. 32. 32Sequence Diagram
  33. 33. 33Decision Backlog• UI Layout Designer ▫ COTS component (Eclipse framework) ▫ Self developed• Network communications ▫ Sockets ▫ Jabber Protocol
  34. 34. 34Agenda• Project Overview• Operations• Planning & Tracking• Requirements Elicitation• Project Risks• Notional Architecture• Reflections & Next Semester
  35. 35. 35Positives• Daily Scrums ▫ Easy way to track daily progress and be on the same page• Short term iterations were effective ▫ Allowed to re-plan easily ▫ Tailor the process ▫ Easy to react to unknowns• Software Experiments ▫ Removed unknowns• Notional Architecture ▫ Got out of period of uncertainty
  36. 36. 36Less Positives• Scrum is not prescriptive enough for a new team ▫ We don’t have enough trust to rely on volunteered work• Scrum is short-sighted ▫ Had to come up with our own method for long term tracking• Must have a good description and exit criteria for each task ▫ People have different understanding what task is and when it is done• Need to have deadlines for tasks within sprint ▫ Student syndrome pushed all tasks completion to the sprint end
  37. 37. 37Lessons Learned• Do experiments to minimize unknowns• Do create notional architecture early to get out period of uncertainty and gain common understanding of the project• Do identify, manage, and control your risks• Do more team building activities• Don’t use contextual design for greenfield project• Don’t start with agile process with unknown team in plan-driven development
  38. 38. 38Next Semester• TSP ▫ Want to learn it – Another point of view on PM ▫ Well prescribed process  Don’t need to tailor it as much as Scrum• ACDM ▫ Want to learn it ▫ Approach architecture with an iterative process
  39. 39. 39Next Semester• Requirements ▫ Approve SRS• Architecture ▫ High-level by MOSP ▫ Refined by EOSP• Experiments ▫ Communication Protocols ▫ UI Tool• Domain knowledge ▫ Explore Ptolemy in depth - Analysis course will help• Implementation ▫ Setup development tools by middle of semester
  40. 40. 40Accomplishments Notional Architecture ✔ Software Experiments ✔ QAW ✔ SRE ✔ SoW ✔ Use Cases ✔ Paper Prototypes ✔ Contextual Design ✔ SRS ✗
  41. 41. 41AccomplishmentsGOT GADGETS ✔
  42. 42. 42Questions and Comments
  43. 43. 43Backups
  44. 44. 44Wideband Delphi
  45. 45. 45Prototypes• Helped eliminate design alternative• Shaped architecture• Do early and often• Size it correctly ▫ Don’t spend too much time on them
  46. 46. Effort Left 20 120 0 80 60 100 40 10/2/10 10/4/10 10/6/10 10/8/10 10/10/10 10/12/10 10/14/10 10/16/10 10/18/10 10/20/10 10/22/10 10/24/10 10/26/10 10/28/10 10/30/10 11/1/10 11/3/10 Sprint BurndownsDate 11/5/10 11/7/10 11/9/10 11/11/10 11/13/10 11/15/10 11/17/10 11/19/10 11/21/10 11/23/10 11/25/10 11/27/10 11/29/10 12/1/10 12/3/10 12/5/10 12/7/10 Sprint 1 Sprint 5 Sprint 3 Sprint 2 Sprint 4 46
  47. 47. 47 Project Burndown 3500 3000 2500 2000Total Effort Left Ideal burndown 1500 Velocity Modified Velocity 1000 500 0 -500 Date
  48. 48. 48Risk Exposure Very Likely Likely UnlikelyCatastrophic 3 1 1Critical 6 3 1Marginal 8 5 7Negligible 1 1 3
  49. 49. 49Risk Statements# Risk Statement TF Impact ProbabilityR7 The Ptolemy repository and NT Catastrophic Very Likely structure is large in size; • the learning curve can be steep and may delay our schedule • core modifications may cause undesired effects in other portions of the systemR17 Roles are not clearly specified NT Marginal Very Likely and followed; • Work may not get done on time • The team might end up duplicating work
  50. 50. 50Use Case Diagrams
  51. 51. 51Product Backlog• How did we use Scrum? ▫ Held sprint kickoff meetings ▫ Held daily scrums (standup meetings) ▫ Reviewed weekly/project burndown charts ▫ Maintained product backlog ▫ Planned according to sprints and milestones
  52. 52. 52Scrum Sheet
  53. 53. 53 Quality Attribute Scenarios RTC gives a demo with the sound spectrum model to the Schwieberding teams using the Android device and providing a sound1 HIGH (file). The tool shows an analysis and suggests correctly the plausible cause. The Ptolemy interface designer creates an interface using the desktop2 tool. The end user uses the handheld device, downloads the interface, HIGH and the interface looks exactly like the desktop preview. The handheld end user, untrained, unfamiliar with the Ptolemy tool3 but familiar with handheld devices, runs the demo with minimal HIGH interactions and gets the results without making any mistakes. The handheld user, untrained, unfamiliar with the ptolemy tool but4 familar with handheld devices, explores the demo with no further HIGH instruction for 15 minutes and the demo does not crash. A Ptolemy developer adds an existing graphical actor to be used for the handheld application, its incorporated into the desktop interface5 HIGH design and its displayable on the handheld within two (2) person weeks.
  54. 54. 54 Quality Attribute Scenarios (cont.) A Ptolemy develop add an existing input actor to be used for the handheld application and incorporated into desktop interface6 HIGH designer, and the handheld connects datasource to the model within two (2) person weeks. RTC ports the system from Android to iPhone once Android7 version exists. RTC implements iPhone specific parts with zero MEDIUM changes changes to the systems architecture. An interface designer is building a layout for a new android device8 with different dimensions and capabilities once the initial android MEDIUM version exits; user can design a layout with no code changes. Version 3.0 of Android comes out and layout builder and handheld9 MEDIUM application supports it without any code changes. Version 3.0 of Android comes out with new features, RTC can10 MEDIUM implement these features with no change to the architecture.
  55. 55. 55 Quality Attribute Scenarios (cont.) A Ptolemy developer needs to maintain this system by making a change to the11 code and effort to understand and identify where the change needs to be made MEDIUM is 0 person/days. The handheld user runs the sound spectrum model, the visualization feedback12 MEDIUM is not more than 20% slower than the desktop application. The handheld user runs the sound spectrum model, the sensor data is captured13 HIGH at the correct rate and fed into the simulation with the order preserved. The handheld user runs a model that requires a wifi input and there is trouble14 connecting and/or data loss, the handheld notifies the user about the error and MEDIUM the user understands the problem. The handheld user is running a model that experience an error that stops the15 normal execution, the handheld provides the user a way to cancel execution HIGH and return a default state and logs the error for future debugging. A Ptolemy developer modifies either handheld application or layout interface16 designer code. Any new defects that affect current code are caught by the MEDIUM existing tests.
  56. 56. 56Software Experiments• Code Generation ▫ Proposed by client and collaborator• Porting complete Ptolemy to Android ▫ Too slow on handheld ▫ Switched to Client / Server based on the results
  57. 57. 57Team Roles• Justin ▫ Team Lead ▫ Client Liaison ▫ Product Owner• Anar ▫ Support Manager• Peter ▫ Process Manager ▫ Scrum Master• Ishwinder ▫ Planning Manager

×