mission science by team 07. team 07 members ashwini ramesha : oce chen li : requirements engineer...
TRANSCRIPT
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
Team’s Strong points
• Operational view• Efficient delegation• Genuine commitment
• Technical view• Diverse technical skills and background
Team’s Weak points
• Operational view• Schedule mismatch
• Technical view• Lack of experience in chosen technology
(Visual Studio)
Technical Concern and Solution
• Concern• Inexperience in COTS (Win AVR)
• Solution• Identify feasibility evidence and conduct
compatibility analysis• Prototype interface with COTS product
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
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
OPERATIONAL CONCEPTDESCRIPTION
Ashwini Ramesha
Current Workflow
Purpose, Vision & Proposed Workflow
Program iRobot
USC Undergraduate Student
Elementary School Student
Control Program with GUI Interface iRobot
Ph
ase
Teach Elementary
school students to
use the Control
ProgramUse GUI to build the
instruction set
Compile and load the
executable to mind control
stick of iRobot
Executes the program
Detect conflicting
instructionsYes
No
Plug in mind control stick to
iRobot
Business Workflow
Contribution
Discovery of more functions
of iRobot
Easier to realize complex functions
Simplify the control of
iRobot
Develop a user-friendly GUI
Developers
Set up environment on elementary school's computers
Client, Elementary School teachers,
Potential maintainer
Ensure compatibility of developed GUI on school's computers
Developers, Client, Elementary School teachers,
Undergraduate students
Provide training to teachers and undergraduate students
Undergraduate students, Elementary School teachers, Elementary school students
Inspire elementary students to explore iRobot
Increment of interests in
STEM
More enjoyable in exploring and
discovering process
Increment of familiarity with developed GUI
Charge more complex functions gradually
Use developed GUI in teaching
Undergraduate students, Elementary
school students
More efficiently teaching activities
Assumptions:-Elementary schools are willing to adopt iRobot and Mission Science program-Elementary students like ͞Bhands-on͞C activities-Usability of iRobot can be increased with drag-and-drop GUI-Developers can build program based on understanding iRobot's instruction
Legend:
Initiative Outcome Stakeholder
Benefit Chain Diagram
System Boundary Diagram
- C #- C- Visual Studio
• 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
• 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
• 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
• 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
PROTOTYPEJiashuo 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 0.3 1
• Workflow• Create (Open)• Compile & Load• Run
Distance
Time
iRobotPrototypeWpf.exe
Interface
• Instruction Candidate• 4 directions: ↑↓←→• Sensor• LED Sound
• Instruction list• Parameters
Workflow
• New file• Save file• Load file• Error/Warning detection• Compile
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
REQUIREMENTSChen Li
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
Project Requirement
• Tools & Languages• Language: Visual Studio C#• Compiler: WinAVR• Platform: Windows 7 and above
Project Requirement
• General Requirement• (WC-3303) Users can drag and drop built-in
functions of the iRobot to control its behavior and movement.
Capability Requirements
Requirement CR-01
Description Navigation Programmability
Priority Must 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.
Capability Requirements
Requirement CR-02
Description Sensor Programmability
Priority Must have
Win-Win Agreements
WC-3285 Users can use sensing drag and drop module to detect cliffs/edges, speed, direction and elapsed time.
Capability Requirements
Requirement CR-03
Description Sounds and Lights Programmability
Priority Should 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.
Capability Requirements
Requirement CR-04
Description Loop and Wait Control
Priority Must 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.
Capability Requirements
Requirement CR-05
Description Basic Functions
Priority Must have
Win-Win Agreements
WC-3305 Users can create, save and load program files.
WC-3304 Users can copy and paste instructions.
LOS Requirements
Requirement LOS-1
Description Seamless Interoperability Between GUI and Compiler
Priority Must 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
LOS Requirements
Requirement LOS-2
Description Tolerance Limit
Priority Should have
Win-Win Agreements
WC-3302 The system should enforce a tolerance limit of +/- 3% on sensor programmability.
Solution Check sensing data based on the action of the robot
checking
LOS Requirements
Requirement LOS-3
Description Error Detection
Priority Should have
Win-Win Agreements
WC-3297 The system shall detect and show logic errors (conflicting or inconsistent instructions) in an easy-to-read way.
ARCHITECTURESowmya Sampath
System Context diagram
E-R Diagram
Behavior of the system
Student
Navigation Use Case
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.
Sensor
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.
Sound/Light
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
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.
Developer & IT Admin
Teacher and Undergrad Student
LIFE CYCLE PLANSiddhesh Rumde
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.
Tools for Monitoring Project Progress
• Winbook• Google Drive • Bugzilla• Microsoft Project Planner• Team review meetings• WinAVR• Client Interaction Reports
• 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
Foundations Phase
Roles and Responsibilities of Key Stakeholders
Roles Responsibilities Roles Responsibilities
Ritika Khurana Project Manager, Life Cycle Planner
Farica Mascarenhas IIV and V, Quality Focal Point
Ashwini Ramesha Operational Concept Engineer, Requirements Engineer
Siddhesh Rumde Life Cycle Planner, Requirements Engineer
Chen Li Requirements EngineerFeasibility Analyst
Yun Shao Feasibility AnalystOperational Concept Engineer
Sowmya Sampath System ArchitectPrototyper
Jiashuo Li PrototyperSystem Architect
Project Plan for 577A
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#
Scale Drivers
Scale Driver
Value Rationale
PREC NOM There is a considerable understanding of the product’s objectives, experience in developing such GUI and some need for innovative data processing and architectures.
FLEX VHI There is a very high need for GUI conformance with pre-established requirements and external interface specifications.
RESL NOM All 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.
TEAM VHI No extra efforts are needed to synchronize stakeholders and they are ready to accommodate other stakeholder’s objectives.
PMAT NOM (Level 2)
ICSM Principles and Guidelines are followed strictly by the developer team
Cost Drivers
Driver Value for Navigation
Value for Sensor Detection
Value for Light and Sound
RELY NOM NOM NOM
DATA NOM HI NOM
DOCU NOM NOM NOM
CPLX HI VHI HI
RUSE NOM NOM NOM
TIME NOM HI NOM
STOR HI VHI HI
PVOL LO LO LO
Cost Drivers
Driver Value for Navigation
Value for Sensor Detection
Value for Light and Sound
ACAP NOM NOM NOM
PCAP HI HI HI
PCON VLO VLO VLO
APEX VLO VLO VLO
LTEX LO LO LO
PLEX NOM NOM NOM
TOOL NOM NOM NOM
SITE HI HI HI
FEASIBILITY EVIDENCEYun Shao
Feasibility Analysis
●Business case analysis●Costs & Benefits analysis●Architecture feasibility analysis●Process feasibility analysis●Risk analysis●COTS analysis
Business Case AnalysisAssumption:• 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
Business Case Analysis
Business Case Analysis
Cost:• Development Costs• iRobot Hardware• Platform computer• Elementary school teachers and
students’ training• Visual Studio License etc
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
Costs & Benefits Analysis
●Costs Analysis●Personnel Costs●Hardware Costs
●Benefits Analysis
Activities Time 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
Hardware Costs
Type Cost Rationale
Hardware - iRobot Machine $0 Provide out-of-the-box opportunity for educators, students to program behaviors, sounds, and movements
Hardware - Platform computer
$0 Test and host the drag and drop GUI
Software - Visual Studio License
$0 Design interface for end users to program the iRobot
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)
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
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
Risk analysis
Risks
Risk Exposure
Risk MitigationsPotential Magnitud
e
Probability 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.
6 6 36 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
5 6 30 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.
6 4 18 Team will be consulting Robotics faculty to support building a prototyping.
COTS Analysis
NDI/NCS Products Purposes
Visual Studio Developing the GUI on Windows
Windows Platform running the GUI
Winform, .NET framework Provide interface for end-users to program the iRobot
iRobot APIs Take instructions from the interface and execute them on iRobot
winAVR compiler Compiles the C program that gets generated from the GUI
QUALITY FOCAL POINTRitika Khurana
Traceability Matrix
OCD Win Win Agreement
SSAD Test Case
OCD1 WC-3283 ATF: Navigation KeysUCD: 2.1.1
Uploading the compiled program to microcontroller chip
OCD2 WC-3297 ATF: SensorUCD: 2.1.2
Uploading the compiled program to microcontroller chip
OCD3 WC-3285 ATF: SensorUCD: 2.1.2
Uploading the compiled program to microcontroller chip
OCD4 WC-3303 ATF: Navigation KeysUCD: 2.1.1
Uploading the compiled program to microcontroller chip
OCD5 WC-3291 ATF: Sounds/LightUCD: 2.1.3
Uploading the compiled program to microcontroller chip
OCD6 WC-3305, WC-3304
ATF: Demo ModesUCD:2.1.1
Uploading the compiled program to microcontroller chip
Defect Identification Review
Evaluation of Scientific, academic and professional work by others working in the same field
Defect Identification Review
Client Feedback
Undergraduate students
Our Client
Team
Defect Injection and Removal Practice
DEFECTS REMOVAL 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
Quality Management Strategy
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
