1. Mission Science By Team 07

2. Team 07 Members Ashwini Ramesha : OCE Chen Li : Requirements Engineer Jiashuo Li : Prototyper Ritika Khurana : Project Manager Siddhesh Rumde : Life Cycle Planner Sowmya Sampath : Software Architect Yun Shao : Feasibility Analyst Farica Mascarenhas : IV & V

3. Team’s Strong points Operational view Efficient delegation Genuine commitment Technical view Diverse technical skills and background

4. Team’s Weak points Operational view Schedule mismatch Technical view Lack of experience in chosen technology (Visual Studio)

5. Technical Concern and Solution Concern Inexperience in COTS (Win AVR) Solution Identify feasibility evidence and conduct compatibility analysis Prototype interface with COTS product

6. Operational Risk and Mitigation Risk Potential difficulties of detecting conflicting instructions specified by end users Mitigation Identify specific action to be taken to avoid unpredictable behavior of robot

7. Observations Win-Win Shaping Status No duplicate WinCs All WinCs agreed upon by client and team Overall Project Evaluation Consideration Level of complexity not identified Skills/needs mismatches Knowledge/experience mismatches

8. O PERATIONAL C ONCEPT D ESCRIPTION Ashwini Ramesha

9. Current Workflow

10. Purpose, Vision & Proposed Workflow

11. Business Workflow

12. Benefit Chain Diagram

13. System Boundary Diagram -C # -C -Visual Studio

14. OC-1 Drag and Drop GUI for navigation: Fun-to-use interface to help elementary school children learn programming to control navigation of iRobot. OC-2 Error Detection and reporting: The system provides understandable error messages on ambiguous instructions OC-3 Drag and Drop GUI for sensor control: Fun-to-use interface to help elementary school children learn programming to control navigation of iRobot. OC-4 Drag & Drop programming constructs: The interface shall allow drag & drop of programming constructs like if-then- else, for and while loops. OC-5 Drag & Drop music and LED controls: The interface shall allow drag & drop of musical notes and LED on/off instructions. OC-6 Drag & Drop demo modes: The interface shall allow drag & drop of pre-programmed demo modes. Capability Goals

15. LOS-1: Reasonable response time of robots. (Win condition: The system shall enforce a tolerance limit of +/- 2 to 3% on sensor programmability.) LOS-2: Seamless interoperability between GUI and compiler. (Win condition: The system shall generate instructions for iRobot in C which is then later compiled for deployment on the microcontroller using the APIs of iRobot.) Measured by number of faults found in code generation & compilation modules. LOS-3: Detect and report ambiguous instructions in an understandable way. (Win condition: The system shall detect and show logic errors (conflicting/inconsistent instructions) in a easy-to-read way.) Measured by having a feedback from stakeholders like undergraduate students and elementary school teachers. LOS-4: Portability above Windows 7 (Win condition: The system shall be a native windows 7 and above application.) Measured by running regression tests on the windows versions above 7. Levels of Service Goals

16. OG-1: Improved understanding in students about logic and control systems. OG-2: Decrease time needed to program iRobot to execute complex instruction set. OG-3: Generate more excitement toward STEM fields. OG-4: Widen the user sector for iRobots. OG-5: Use of iRobots to improve funding opportunities for Mission Science. Organizational Goals

17. CO-1: Windows as an Operating System: The new system must be able to run on Windows 7/8/8.1 CO-2: Zero Monetary Budget: The selected NDI/NCS/COTS should be free or no monetary cost. CO-3: C# as a Development Language: Visual studio C# will be used as a development language for the Drag & Drop GUI interface. Constraints

18. P ROTOTYPE Jiashuo Li

19. What we have prototyped Drag & Drop Operation which is the main capability of the system Easy for kids to program Instruction with parameters FORWARD 0.3 1 Workflow Create (Open) Compile & Load Run Distance Time iRobotPrototypeWpf.exe

20. Interface Instruction Candidate 4 directions: ↑↓←→ Sensor LED Sound Instruction list Parameters

21. Workflow New file Save file Load file Error/Warning detection Compile

22. Main Risks & Mitigation Uneasy for kids to program iRobot Building prototype Get feedbacks from users Revise the system Unfamiliar with GUI development Study.NET WPF Unfamiliar with iRobot API Borrow iRobot hardware and lab Program and test iRobot

23. R EQUIREMENTS Chen Li

24. Project Requirement Schedule To be completed within 9 months (09/2014- 05/2015) First 4 months: To complete system Life Cycle Objectives (LCO/FCR) and Architecture (LCA/DCR) Last 5 months: To implement and deliver the system

25. Project Requirement Tools & Languages Language: Visual Studio C# Compiler: WinAVR Platform: Windows 7 and above

26. Project Requirement General Requirement (WC-3303) Users can drag and drop built-in functions of the iRobot to control its behavior and movement.

27. Capability Requirements RequirementCR-01 DescriptionNavigation Programmability PriorityMust have Win-Win Agreements WC-3283 Users can use navigation drag and drop module to make the robot go forward, backward, turn left and right.

29. Capability Requirements RequirementCR-02 DescriptionSensor Programmability PriorityMust have Win-Win Agreements WC-3285 Users can use sensing drag and drop module to detect cliffs/edges, speed, direction and elapsed time.

30. Capability Requirements RequirementCR-03 DescriptionSounds and Lights Programmability PriorityShould have Win-Win Agreements WC-3291 Users can use sounds and lights module to turn LEDs on and off. WC-3290 Users can drag notes from sounds and lights module to create a song.

31. Capability Requirements RequirementCR-04 DescriptionLoop and Wait Control PriorityMust have Win-Win Agreements WC-3296 Users can drag and drop a wait condition in which instructions can be further dragged and dropped. WC-3295 Users can drag and drop if-then-else and for/while loop in which instructions can be further dragged and dropped.

32. Capability Requirements RequirementCR-05 DescriptionBasic Functions PriorityMust have Win-Win Agreements WC-3305 Users can create, save and load program files. WC-3304 Users can copy and paste instructions.

33. LOS Requirements RequirementLOS-1 DescriptionSeamless Interoperability Between GUI and Compiler PriorityMust have Win-Win Agreements WC-3299 The system shall generate instructions for iRobot in C which is then later compiled for deployment on the microcontroller of iRobot GUI (C#) Instructions (C) Language used by iRobot Compiler

34. LOS Requirements RequirementLOS-2 DescriptionTolerance Limit PriorityShould have Win-Win Agreements WC-3302 The system should enforce a tolerance limit of +/- 3% on sensor programmability. SolutionCheck sensing data based on the action of the robot checking

35. LOS Requirements RequirementLOS-3 DescriptionError Detection PriorityShould have Win-Win Agreements WC-3297 The system shall detect and show logic errors (conflicting or inconsistent instructions) in an easy-to- read way.

36. A RCHITECTURE Sowmya Sampath

37. System Context diagram

38. E-R Diagram

39. Behavior of the system

40. Student

41. Navigation Use Case

42. Use Case Description-Navigation ● Identifier UC-1 Create Navigation Instructions ● Purpose Enable the Elementary School Student to create navigation instructions such as moving forward, backward, turn left or right based on the angle specified. ● Requirements To be able to program iRobot with instructions to move forward, backward, turn left /right based on the angle. ● Development Risks Resolving of Incompatible navigation instructions, frequency of checking the angle of turning so as to perform accurately. ● Pre-conditions Knows about the parameters for each navigation ● Post-conditions Give meaningful Navigation instructions.

43. Sensor

44. Use Case Description-Sensor ● Identifier UC-2 Create Sensor Instructions ● Purpose Enable the Elementary School Student to create sensor instructions to detect cliffs, bumps, find the elapsed time and distance covered. ● Requirements To be able to program sensor instructions so as to detect cliffs or bumps, calculate time and distance. ● Development Risks Intervals of checking for the time and distance sensors. ● Pre-conditions Knows about the purpose of each sensor. ● Post-conditions Appropriate Sensor instructions based on the requirement.

45. Sound/Light

46. Use Case Description-Sound ● Identifier UC-3 Create Sound Instructions ● Purpose Enable the Elementary School Student to compose a song ● Requirements To be able to compose a song ● Development Risks None ● Pre-conditions Knows how to use GUI ● Post-conditions Set of Musical notes forms a song

47. Use Case Description-Light ● Identifier UC-4 Create Light Instructions ● Purpose Enable the Elementary School Student to give instructions to turn light on / off ● Requirements To be able to give instructions to switch on / off led lights ● Development Risks None ● Pre-conditions Knows how to use the drag and drop GUI ● Post-conditions Turning on / off lights as per the task.

48. Developer & IT Admin

49. Teacher and Undergrad Student

50. L IFE C YCLE P LAN Siddhesh Rumde

51. Life Cycle Strategy Current Status The Current Status of the LCP in the valuation phase for developing the FC package will include all the tools and methods and also approx resource estimates. Assumptions The duration of the project is 2 semesters, which are 12 weeks in Fall 2014 and 12 weeks in Spring 2015. There are eight people working on the project including one DEN student. The elementary schools will like the GUI which has been developed for the iRobot. There will be regular meetings with the client, to discuss the progress, issues and other concerns. Licensed Software.

52. Tools for Monitoring Project Progress Winbook Google Drive Bugzilla Microsoft Project Planner Team review meetings WinAVR Client Interaction Reports

53. Duration: 10/20/2014– 12/1/2014 Concept: In this phase, the feasibility of each requirement (Win condition) is determined and development starts with, usually, the most feasible and required conditions. Continue risk assessment process, regular stakeholder meetings are to be taken every week, regular progress reports and effort reports to be submitted every alternate Monday, project plans are to be prepared and released on project web-page, risk resolution, assessing project status, sharing implementation jobs Deliverables: Draft DC Package, DC Package. Milestone: Development Commitment Review. Strategy: One Incremental Commitment Cycle Foundations Phase

55. Roles and Responsibilities of Key Stakeholders RolesResponsibilitiesRolesResponsibilities Ritika KhuranaProject Manager, Life Cycle Planner Farica MascarenhasIIV and V, Quality Focal Point Ashwini RameshaOperational Concept Engineer, Requirements Engineer Siddhesh RumdeLife Cycle Planner, Requirements Engineer Chen LiRequirements Engineer Feasibility Analyst Yun ShaoFeasibility Analyst Operational Concept Engineer Sowmya SampathSystem Architect Prototyper Jiashuo LiPrototyper System Architect

56. Project Plan for 577A

57. Resources and COINCOMO Our current resources: ● Estimated CSCI 577A/B Effort: 8 team members at 12 hrs./week ● Total estimated effort: 2304 hours ● Project duration: 24 weeks ● Component modules in the development project: ● Navigation Module ● Sensor Detection Module ● Light and Sound Module ● Primary Programming language used: Visual Studio C#

58. Scale Drivers Scale Driver ValueRationale PRECNOMThere is a considerable understanding of the product’s objectives, experience in developing such GUI and some need for innovative data processing and architectures. FLEXVHIThere is a very high need for GUI conformance with pre-established requirements and external interface specifications. RESLNOMAll major risks are documented with mitigation plans for each module; however there is a considerable amount of uncertainty pertaining to the success of User Interface and COTS software. TEAMVHINo extra efforts are needed to synchronize stakeholders and they are ready to accommodate other stakeholder’s objectives. PMATNOM (Level 2) ICSM Principles and Guidelines are followed strictly by the developer team

59. Cost Drivers DriverValue for Navigation Value for Sensor Detection Value for Light and Sound RELYNOM DATANOMHINOM DOCUNOM CPLXHIVHIHI RUSENOM TIMENOMHINOM STORHIVHIHI PVOLLO

60. Cost Drivers DriverValue for Navigation Value for Sensor Detection Value for Light and Sound ACAPNOM PCAPHI PCONVLO APEXVLO LTEXLO PLEXNOM TOOLNOM SITEHI

62. F EASIBILITY E VIDENCE Yun Shao

63. Feasibility Analysis ● Business case analysis ● Costs & Benefits analysis ● Architecture feasibility analysis ● Process feasibility analysis ● Risk analysis ● COTS analysis

64. Business Case Analysis Assumption: Elementary school teachers are comfortable with the iRobot and are willing to let us do the Mission Science program at their school Kids of elementary school are interested in these “hands-on” science and technology activities, projects, experiments, and demonstrations though which they will aspire for careers in Science, Technology, Engineering and Mathematics (STEM) The capability of the iRobot will be greatly improved using GUI with drag and drop operation

65. Business Case Analysis

66. Cost: Development Costs iRobot Hardware Platform computer Elementary school teachers and students’ training Visual Studio License etc

67. Business Case Analysis ● Benefits: ● Decreasing the difficulty of programming iRobot and time needed to program iRobot to execute complex instruction set ● Increasing elementary school students’ interests and understanding of complex function of iRobot and aspiration in STEM ● Providing better chance of funding for Mission Science

68. Costs & Benefits Analysis ● Costs Analysis ● Personnel Costs ● Hardware Costs ● Benefits Analysis

69. ActivitiesTime Spent (Hours) Development Period (12 weeks) Valuation and Foundations Phases: Time Invested (CS 577a, 12 weeks) Client: Meeting via email, phone, and other channels [2 hr/week * 12 weeks * 2 people] 48 Client Representatives: Meeting via email, phone, and other channels [2 hr/week * 12 weeks * 2 people] 48 Architecture Review Boards [1.5 hr * 1 times * 8 people] 12 Development and Operation Phases: Time Invested (CS 577b, 12 weeks) Developer: Spending hours to developing the GUI application [5 hr/week * 10 week * 4 people] 200 Client: Meeting via email, phone and other channels [2 hr/week * 12 weeks * 2 people] 48 Maintainer: Meeting via email, phone, and other channels [2 hr/week * 12 weeks * 2 people] 48 Architecture Review Boards and Core Capability Drive-through session [1.5 hrs * 2 times * 4 people] 12 Deployment of system in operation phase and training - Installation & Deployment [5 hr/week * 3 times * 4 people] - Training & Support [5 hrs * 2 times * 2 people] 80 Total 496 Maintenance Period (1 year) Maintenance [2 hr/week * 52 weeks] 104 Total 104

70. Hardware Costs TypeCostRationale Hardware - iRobot Machine$0Provide out-of-the-box opportunity for educators, students to program behaviors, sounds, and movements Hardware - Platform computer $0Test and host the drag and drop GUI Software - Visual Studio License $0Design interface for end users to program the iRobot

71. Benefits Analysis ● Elementary school students save time to programming iRobot ● Undergraduate students can teach elementary students much easier ● Elementary school students are highly possible to be interested in STEM (Science, Technology, Engineering, Mathematics)

72. Architecture Feasibility Analysis ● Level of Service Feasibility ● Reasonable response time of iRobot ● Seamless interoperability between GUI and complier. ● Capability Feasibility ● Drag-and-drop GUI ● Instruction Error Detecting and Reporting ● Evolutionary Feasibility ● Compatibility with latest version of Windows ● Further improvement after test

73. Process Feasibility Analysis ● Single NDI/NCS (.NET framework) ● Adopt it directly ● Ensure the compatibility ● Unique/inflexible business process ● Start in Prototyping ● Transfer from graphic view to C code ● Need high level of service/performance ● In schedule ● Ensure some specific feature, i.e., limit tolerance of error

74. Risk analysis Risks Risk Exposure Risk Mitigations Potential Magnitude Probabilit y Loss Risk Exposur e Visual studio (VS) is decided to be used for designing the GUI, but team has very less idea which compiler gels well with VS to compile C code. 6636 Working on feasibility of having WinAVR compiler working with Visual Studio next week. Technical risk - potential difficulties of detecting conflicting instructions given by the end users 5630 Team needs to come up with a design where the conflicting instruction set are detected. Team needs to come up with a design where a specific action is taken to avoid unpredictible behavior of the robot. Team does not fully understand yet how to program the robot's microcontroller and integrate the robot's function with the interface. 6418 Team will be consulting Robotics faculty to support building a prototyping.

75. COTS Analysis NDI/NCS ProductsPurposes Visual StudioDeveloping the GUI on Windows WindowsPlatform running the GUI Winform,.NET frameworkProvide interface for end-users to program the iRobot iRobot APIsTake instructions from the interface and execute them on iRobot winAVR compilerCompiles the C program that gets generated from the GUI

76. Q UALITY F OCAL P OINT Ritika Khurana

77. Traceability Matrix OCDWin Win Agreement SSADTest Case OCD1WC-3283ATF: Navigation Keys UCD: 2.1.1 Uploading the compiled program to microcontroller chip OCD2WC-3297ATF: Sensor UCD: 2.1.2 Uploading the compiled program to microcontroller chip OCD3WC-3285ATF: Sensor UCD: 2.1.2 Uploading the compiled program to microcontroller chip OCD4WC-3303ATF: Navigation Keys UCD: 2.1.1 Uploading the compiled program to microcontroller chip OCD5WC-3291ATF: Sounds/Light UCD: 2.1.3 Uploading the compiled program to microcontroller chip OCD6WC-3305, WC- 3304 ATF: Demo Modes UCD:2.1.1 Uploading the compiled program to microcontroller chip

78. Defect Identification Review Evaluation of Scientific, academic and professional work by others working in the same field

79. Defect Identification Review Client Feedback Undergraduate students Our Client Team

80. Defect Injection and Removal Practice DEFECTSREMOVAL STRATEGIES Prototype presented was not a fun to use Team decided to add better symbols for the buttons Team not sure which testing method to use Team will contact client regarding the test cases that can be developed Team unsure if the architecture provided is correct Team will update the architecture with time as and when required

81. Quality Management Strategy

82. Software Documentation & Testing Improves Generalizability Lead to more prominent factors Increases understandability of the project Improved Defect Detection Scope of improvement of the results on testing Testing modules constitute low cost Defects identified at each stage