Mission Science By Team 07

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 1

Strong and Weak points Strengths Peer review Collaborative, supportive Online tools Client communication Weaknesses Remote student availability Time constraints due to heavy course load 2

Overall Project Evaluation Identified new requirements Identified new risks Developed functional prototype for navigation programmability Started Construction Phase 3

O PERATIONAL C ONCEPT D ESCRIPTION Ashwini Ramesha

Current Workflow 5

Purpose, Vision & Proposed Workflow 6

Business Workflow 7

Benefit Chain Diagram 8

System Boundary Diagram 9

OC-1 Navigation programmability: Fun-to-use interface to help elementary school children learn programming to control navigation of iRobot. OC-2 Sensor programmability: Fun-to-use interface to help elementary school children learn programming to control navigation of iRobot. OC-3 Loop and wait constructs: The interface shall allow drag & drop of programming constructs like if-then-else, for and while loops. OC-4 Sounds and light programmability: The interface shall allow drag & drop of musical notes and LED on/off instructions. OC-5 Demo mode programmability: The interface shall allow drag & drop of pre-programmed demo modes. Capability Goals 10

LOS-1: 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. Measure: Number & severity of faults found in code generation & compilation modules. LOS-2: 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-understand way. Measure: Feedback from stakeholders like undergraduate students and elementary school teachers on the framed help & error messages. LOS-3: Reasonable frequency of reading sensor data. Win condition: The system shall enforce a tolerance limit of +/- 2 to 3% error in angle of turning. Measure: Manual testing and recording results for variety of sample inputs. LOS-4: Portability above Windows 7 Win condition: The system shall be a native windows 7 and above application. Measure: Regression test results on the windows versions above 7. Levels of Service Goals 11

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

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 13

P ROTOTYPE Jiashuo Li

What we have prototyped Drag & Drop Operation which is the main capability of the system Easy for kids to program Instruction with parameters FORWARD Workflow (Functioning) Create (Open) Compile & Load Run Translate Program to C Win AVR Integration Debugging Interface Distance Time 15

4-Panel Interface Instruction Candidates Program Parameters: The parameters of each instruction Debugging Interface Load default program Show text source code More COLORS 16

Build and Load 17

Win AVR Integration 18

Risks, Problems and Mitigation Low sensor resolution -> Cannot rotate accurately Try using script command Find the sweet point for sensing Ineffective development tools Contact manufacturers Build Microcontroller simulation environment Kids may lost their interest Ask for what they want 19

R EQUIREMENTS Chen Li

ESS (Most significant Requirements) ScoreRequirementWin Condition 0.751OC-1(WC-3283) Use navigation drag and drop module to make the robot go forward, backward, turn left and right OC-2(WC-3285) Use sensing drag and drop module to detect cliffs/edges, speed, direction, elapsed time and infrared ray OC-5(WC-3283) Use built-in functions of the iRobot to control its behavior/movement 0.556OC-3(WC-3295) Drag and drop if-then-else and for/while loop in which instructions can be further dragged and dropped. 21

System ScoreRequirementWin Condition 0.751LOS-1(WC-3299) The system shall generates instructions for iRobot in C which is then later compiled for deployment on the microcontroller of iRobot 0.522LOS-2(WC-3297) The system shall detect and show logic errors (conflicting or inconsistent instructions) in an easy-to-read way LOS-3(WC-3302) The system shall enforce a tolerance limit of +/- 3% on sensor programmability LOS-4(WC-3298) The system shall be a native Window 7 and above application. 22

Implicit Requirements Prepare user guide Prepare troubleshooting guide 23

A RCHITECTURE Sowmya Sampath

Use Case diagram 25

Hardware Component Diagram 26

Software Component Diagram 27

Deployment Diagram 28

Design Class Diagram 29

Sequence Diagram 30

L IFE C YCLE P LAN Siddhesh Rumde

Overview Modified since FCR ARB Modules Estimation Plans for 577b Re-baseline Foundation Phase Iteration 1 Core Capability Iteration 2 Full Capability Transition Iteration 32

Prototype Module Name FunctionalityPrototype SLOCPercentageSLOCREVL Navigation Interface Design25050% % Translator20060% Win AVR Integration30070% Instruction Meta-Data00% Sensor Detection Interface Design25050% % Translator00% Win AVR Integration30070% Instruction Meta-Data00% Light and Sound Interface Design25050% 75010% Translator00% Win AVR Integration30070% Instruction Meta-Data00% 33

Modules 34

Estimation Total SLOC estimated : 3953 lines Most Likely effort: PM 11.51/1.67=6.89 person 7 members in 577b 35

Skillset of New Members UI/UX Design C and C# Programming Good Analytical Skills Visual Studio 36

Re-baseline Foundation (Jan 12 - Feb 11) Re-baseline the project (Jan 13-Jan17) RequirementRequirement Engineer PrototypePrototyper ArchitectureArchitect Plan for testingTester Prepare Products for RDCR (Jan 23-Feb 5) 37

Construction Iteration 1 (Feb10 - Mar26) Duration: Feb 10  Mar 26 Modules: Navigation Sensor Light & Sound Capability: Navigation Sense-Navigate Play Sound Display LED Lights 38

Detailed Plan 39

Core Capability Drive-through CCD: an activity allows clients to try on must-have capabilities. Schedule: March 25 Preparation: Hardware & Software Dry Run Risk Management Usage Scenarios Feedback From Students 40

Construction Iteration 2 (Mar26 - Apr08) Duration: Mar 26  Apr 08 Modules: Export Capability: Enhance User Interface Integration testing and System testing Fix defect and prepare for release 41

Dates & Activities for Client Re-baseline Development Commitment Review: Feb 11 Core Capability Drive-through: March 25 Transition Readiness Review: Apr 8 Transition & Training: Apr 20 Operational Commitment Review: Apr 27 Client Evaluations: May 4 42

F EASIBILITY EVIDENCE Yun Shao

Business Case Cost analysis Personnel analysis Hardware and software analysis Benefit analysis ROI analysis 44

Development Period (12 weeks) Valuation and Foundations Phases: Time Invested (CS 577a, 12 weeks) Client: First meeting 2 Client: Win-win session 2 Undergraduate Students: Introduction to iRobot 2 Client: Meeting via , phone, and other channels [1 hr/week * 12 weeks * 1 people] 12 Undergraduate Students: Meeting via , phone, and other channels [1 hr/week * 12 weeks * 2 people] 24 Architecture Review Boards [1.5 hr * 2 times * 1 people] 3 Development and Operation Phases: Time Invested (CS 577b, 12 weeks) Client: Meeting via , phone, and other channels [1 hr/week * 12 weeks * 1 people] 12 Undergraduate Students: Meeting via , phone, and other channels [1 hr/week * 12 weeks * 2 people] 24 Maintainer: Meeting via , 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 * 1 people] 3 Deployment of system in operation phase and training - Installation & Deployment [5 hr/week * 3 times * 3 people] - Training & Support [5 hrs * 2 times * 3 people] 75 Total

Hardware & Software Analysis Hardware iRobot Platform computer Software Visual studio license Win AVR 46

Benefit Analysis More elementary school students interest in iRobot and STEM 50% increase More funding for Mission Science 10% increase 47

ROI Analysis YearCost Benefit (Effort Saved) Cumulative Cost Cumulative Benefit ROI 2014$1500$3000$1500$ $500$3000$2000$ $1500$3000$3500$ $500$3000$4000$

ROI Analysis 49

Process Feasibility Evidence 30 % of NDI/NC S features 3Adoption with customizing Based on our research, it cannot be ignored in our project. For example, we need to customize and use Win AVR in our project, which is the only tools to load C code to microcontroller of iRobot to the best of our knowledge. Single NDI/NC S 3Direct adoptionBased on our knowledge, we take advantage of the compatibility of.NET with Windows to develop our project, which is footstone of our project. Unique/ inflexible business process 3In PrototypingBased on our research, there is some particular process we have to complete, such as transfer the graphic view to C code. 50

Technical Risk Analysis Risks Risk Exposure Risk Mitigations S(L)P(L)RE GUI may generate C code that cannot be compiled ) The line of C code causing the compilation error and corresponding instruction from GUI can be highlighted. 2) A message to contact the maintainers with the exact program tried and the error message faced. The GUI may fail to detect conflicting instructions, so that the iRobot will run out of expectation, which decreases kids' interest ) Team needs to analyze the place where conflicts possibly happen for each function, and design a specific action to avoid unpredictable behaviors of iRobot. 51

Risks Risk Exposure Risk Mitigations S(L)P(L)RE The COM port may change when microcontroller is connected to computer, but the COM port changing function may fail to identify the COM port and customize "makefile" correspondingly ) Maintainer is given an option to manually select the COM port from all available candidates. 2) Add troubleshooting instructions with snapshots of how to identify the correct COM port and change the "makefile". Due to various hardware environments on different computers, incompatibility issue may arise while using default "firmware version" in "makefile" which will cause COM port time-out ) Maintainer is given an option to manually select the version of firmware. 2) Add troubleshooting instructions of how to edit "makefile" to change the "firmware version". Technical Risk Analysis 52

Risks Risk Exposure Risk Mitigations S(L)P(L)RE Final GUI may fail to interest elementary school kids towards programming iRobots. 4281) Make improvements based on the collection of feedback of kids who have tried our application. Non Technical Risk Analysis 53

NDI/NCS Analysis Connector None Legacy System Win AVR iRobot 54

Visual Studio 2013 Windows 8.1 WPF based on.NET framework 4.5 iRobot Open Interface Win AVR complier NDI/NCS Analysis 55

Q UALITY F OCAL P OINT Ritika Khurana

Metrics Reporting Defect Reporting Metric Unavoidable Defect(s): Week 1/2: Unable to discuss with the undergraduate students and elementary school kids as yet due to unavailabity of the contact information. Avoidable Defect(s): Week 3/4: Slot booking for win win session 2 got delayed due to miscommunication among team members. Week 5/6: Prototype presentation uploaded later than expected. Week 5/6: Choosing wrong category of documents in Bugzilla. Week 7/8: The documents with the team were incomplete & insufficient. Week 7/8: ARB documentation and presentation were not satisfactory. Week 7/8: Inadequate time management. Week 9/10: Team failed to update Bugzilla last week on time. Week 11/12: Some concepts in documents were not understood in time. 57

Defect Metrics 58

Defect Analysis 59

Progress Report Week 1/2: Student team learnt an overview of the current system’s working. Student team witnessed end-to-end working of a similar product developed in past – A scribbler robot. Source code of the existing complex functionalities and other documentation related to iRobot were asked from the client. Student team plans to meet up with the actual users of the product(Undergraduate students) in the coming week. Student team learnt about the vision statement of the project and its long term goals. Week 3/4: Acquired the soft copies of the existing documentation of the iRobot from client. Had a discussion with undergraduate students about their experiences working with current system and problems. Team has started familiarizing on Visual Studio and working on the prototyping. Team along with the client, updated functionality level requirements on Winbook. 60

Week 5/6: Team combined the MMF on Winbook as suggested by the client. iRobot given by the client for implementing and testing. Team has starting building the GUI on Visual Studio. Team prototyped GUI for the prototype presentation. Team spent time in knowing the priorities of the MMF’s. Team attended the win win session#2 and learnt to estimate to estimate MMFs. Week 7/8: Team prepared and delivered the ARB Presentation. Improved GUI prototype with graphical navigation errors. Client and professors feedback were integrated into Foundation Commitment Package. Team prepared the Foundation Commitment Package Documents. Week 9/10-11/12: Team delivered the Prototype Presentation. Improved GUI prototype with graphical interface for all buttons. Team successful in generating a C code from the instructions of GUI as a part of prototype. Progress Report 61

Metrics Reporting 62

Effort Report Week 1/2: Getting extensive functional requirements and system level requirements in the form of user stories from client. Had a meeting with undergraduate students; the users who will be teaching the Elementary school students to use the iRobot. Team managed to take the iRobot Machine from the client. Risk Analysis for the project based on the understanding the team gains from PC-3 Assignment. Week 3/4: Prototype of the GUI completed. Acquired the iRobot machine to get hands-on experience. Week 5/6: Developed the aesthetic look of GUI prototype required. Added functionality to the buttons and tried to compile the code using Win AVR. Presented ARB and acquired quality management strategies to be used for the project. Week 7/8-9/10-11/12: Generated actual C code and compiled using Win AVR. 63

Effort Analysis 64

Effect of Effort 65

Solved Technical Debts Team decided to use Visual Studio to design the GUI but did not know which compiler would be compatible with it to compile C code. Later decided to try WinAVR. Team decided to work on feasibility of Win AVR. For a while team also decided to use GTK for the compilation of the C code but that did not seem viable. Because of insufficient time, took help from the undergraduate students in understanding the hardware programming and debugging. Developers now have better understanding of the iRobot’s operational logic. Technical Debt 66

Technical Debt Remaining Technical Debts Code of prototype is not modular. Team still not clear about how navigation and sensors work with each other, which may cause difficulties in the development at a later stage. 67

IDTC-001 TitleNavigation Controls Pre-ConditionsFunction calls in C Coding for forward & backward controls on User Interface Test-Step(s)Drag the navigation buttons, Compile the code, Load onto the microcontroller chip and Test on the iRobot. Expected ResultsMovement of the iRobot as expected. Test Cases 68

IDTC-002 TitleSensor Controls Pre-ConditionsFunction Calls in C Code to activate sensors like for cliff detection and obstacle detection on User Interface Test-Step(s)Drag the sensor buttons, Select the sensor check frequency, Compile the code, Load onto the microcontroller chip and Test on the iRobot. Expected ResultsPop Up window showing an obstacle detected in front. Test Cases 69

IDTC-003 TitleSounds and Lights Pre-ConditionsFunction Calls in C Coding for aggregating sounds and making songs using drag and drop functionality on User Interface Test-Step(s)Drag the sound and light buttons, Chose the sounds, Compile the code, Load onto the microcontroller chip and Test on the iRobot. Expected ResultsComposition of the songs as expected. Test Cases 70

IDTC-004 TitleDemo Modes Pre-ConditionsFunctional Testing Test-Step(s)Testing all the instructions related to demo modes. Expected ResultsDemo Modes working as expected. Test Cases 71

Test Cases IDTC-005 TitleConflict Detection Pre-ConditionsNavigation Functionality Test-Step(s)Providing the conflicting instructions in the drag and drop interface. Expected ResultsPop Up showing conflicting instructions given. 72

Traceability Matrix OCDWin Condition SSADTest Case OC1WC-3283ATF: Navigation Keys UCD: TC-001, TC-005 OC2WC-3285ATF: Sensor UCD: TC-002 OC3WC-3291ATF: Sounds/Light UCD: TC-003 OC4WC-3296ATF: Loop & Wait Constructs UCD: TC-004 OC5WC-3305, WC-3304 ATF: Demo Modes UCD:2.1.1 TC

74