Mission Science. By Team 07

Transcription

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 1

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

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

5 Ashwini Ramesha OPERATIONAL CONCEPT DESCRIPTION

6 Current Workflow 5

7 Purpose, Vision & Proposed Workflow 6

8 Program irobot Elementary School Student Use GUI to build the instruction set Yes USC Undergraduate Student Control Program with GUI Interface irobot Teach Elementary school students to use the Control Program Business Workflow Detect conflicting instructions No Compile and load the executable to mind control stick of irobot Plug in mind control stick to irobot Executes the program Phase 7

9 Assumptions: -Elementary schools are willing to adopt irobot and Mission Science program -Elementary students like hands-on activities -Usability of irobot can be increased with drag-and-drop GUI -Developers can build program based on understanding irobot's instruction Developers Develop a user-friendly GUI Benefit Chain Diagram Client, Elementary School teachers, Potential maintainer Undergraduate students, Elementary school students Set up environment on elementary school's computers Use developed GUI in teaching Ensure compatibility of developed GUI on school's computers Simplify the control of irobot More efficient teaching Increase kids knowledge of complex irobot function and aspiration in STEM Easier to realize complex functions Increased familiarity with developed GUI Discover more complex functions gradually Provide training to teachers and undergraduate students Inspire elementary students to explore irobot Developers, Client, Elementary School teachers, Undergraduate students Undergraduate students, Elementary School teachers, Elementary school students Increased number of schools adopting irobots for kids Providing better chance of funding for Mission Science Legend: Contribution Initiative Outcome Stakeholder 8

10 System Boundary Diagram 9

11 Capability Goals 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. 10

12 Levels of Service Goals 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. 11

13 Organizational Goals 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. 12

14 Constraints 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. 13

15 Jiashuo Li PROTOTYPE

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

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

18 Build and Load 17

19 Win AVR Integration 18

20 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

21 Chen Li REQUIREMENTS

22 ESS (Most significant Requirements) Score Requirement Win Condition OC-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 OC-3 (WC-3295) Drag and drop if-then-else and for/while loop in which instructions can be further dragged and dropped. 21

23 System Score Requirement Win Condition LOS-1 (WC-3299) The system shall generates instructions for irobot in C which is then later compiled for deployment on the microcontroller of irobot LOS-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

24 Implicit Requirements Prepare user guide Prepare troubleshooting guide 23

25 Sowmya Sampath ARCHITECTURE

26 Use Case diagram 25

27 Hardware Component Diagram 26

28 Software Component Diagram 27

29 Deployment Diagram 28

30 Design Class Diagram 29

31 Sequence Diagram 30

32 Siddhesh Rumde LIFE CYCLE PLAN

33 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

34 Prototype Module Name Navigation Sensor Detection Light and Sound Functionality Prototype SLOC Percentage Interface Design % Translator % Win AVR Integration % Instruction Meta-Data 0 0% Interface Design % Translator 0 0% Win AVR Integration % Instruction Meta-Data 0 0% Interface Design % Translator 0 0% Win AVR Integration % Instruction Meta-Data 0 0% SLOC REVL % % % 33

35 Modules Module Name Brief Description Navigation Module Provide navigation for the irobot to move in any direction % 0 2 Sensor Module Provide sensation of the external environment to the irobot % 0 3 Light & Music Module No. 1 SLO REV C L Enable the light and music % feature of the irobot. 34

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

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

38 Re-baseline Foundation (Jan 12 - Feb 11) Re-baseline the project (Jan 13-Jan17) Requirement Requirement Engineer Prototype Prototyper Architecture Architect Plan for testing Tester Prepare Products for RDCR (Jan 23-Feb 5) 37

39 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

40 Detailed Plan 39

41 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

42 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

43 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

44 Yun Shao FEASIBILITY EVIDENCE

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

46 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] Architecture Review Boards [1.5 hr * 2 times * 1 people] 24 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] Undergraduate Students: Meeting via , phone, and other channels [1 hr/week * 12 weeks * 2 people] 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

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

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

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

50 ROI Analysis ROI

51 Process Feasibility Evidence 30 % of 3 NDI/NC S features Adoption 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 3 Direct adoption Based 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 3 In Prototyping Based on our research, there is some particular process we have to complete, such as transfer the graphic view to C code. 50

52 Technical Risk Analysis Risk Exposure Risks 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

53 Technical Risk Analysis Risk Exposure Risks 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". 52

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

55 NDI/NCS Analysis Connector None Legacy System Win AVR irobot 54

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

57 Ritika Khurana QUALITY FOCAL POINT

58 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

59 Defect Metrics No. of defects No. of defects Week Week Week Week Week Week

60 Defect Analysis Effect of Defect Effect of Defect 59

61 Progress Report Week 1/2: Stude t tea lear t a o er ie of the urre t syste s orki g. 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

62 Progress Report 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. Tea spe t ti e i k o i g 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. 61

63 Metrics Reporting Progress Indicator Progress Indicator Week Week Week Week Week Week

64 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

65 Effort Analysis Percentage of effort Percentage of effort Week Week Week Week Week Week

66 Effect of Effort Effect of Effort (%) Effect of Effort (%) WeekWeekWeekWeekWeekWeek

67 Technical Debt 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 iro ot s operatio al logi. 66

68 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

69 Test Cases ID TC-001 Title Navigation Controls Pre-Conditions Function 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 Results Movement of the irobot as expected. 68

70 Test Cases ID TC-002 Title Sensor Controls Pre-Conditions Function 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 Results Pop Up window showing an obstacle detected in front. 69

71 Test Cases ID TC-003 Title Sounds and Lights Pre-Conditions Function 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 Results Composition of the songs as expected. 70

72 Test Cases ID TC-004 Title Demo Modes Pre-Conditions Functional Testing Test-Step(s) Testing all the instructions related to demo modes. Expected Results Demo Modes working as expected. 71

73 Test Cases ID TC-005 Title Conflict Detection Pre-Conditions Navigation Functionality Test-Step(s) Providing the conflicting instructions in the drag and drop interface. Expected Results Pop Up showing conflicting instructions given. 72

74 Traceability Matrix OCD Win Condition SSAD Test Case OC1 WC-3283 ATF: Navigation Keys UCD: TC-001, TC-005 OC2 WC-3285 ATF: Sensor UCD: TC-002 OC3 WC-3291 ATF: Sounds/Light UCD: TC-003 OC4 WC-3296 ATF: Loop & Wait Constructs UCD: TC-004 OC5 WC-3305, WC-3304 ATF: Demo Modes UCD:2.1.1 TC

75 74