Feasibility Evidence Description (FED)Version 2.0
Feasibility Evidence Description (FED)
Mission Science iRobots
Team 07
Ashwini RameshaOCE
Requirements Engineer
Chen LiRequirements Engineer
FeasibilityAnalyst
Farica MascarenhasIV&V
Quality Analyst
Jiashuo LiPrototyper
Software Architect
Ritika KhuranaProject Manager
Siddhesh RumdeLife Cycle Planner,
Requirements Engineer
Sowmya SampathSoftware Architect
Prototyper
Yun ShaoFeasibility Analyst
OCE
Version History
Date / Author / Version / Changes made / Rationale09/19/14 / FM / 1.0 /
- Original for CSCI577; Tailored from ICSM OCD Template
- To fit CS577 course content
09/28/14 / YS / 1.1 /
- update the program model
- identify more risks and their mitigation strategies
- To be consistent with template on course website
10/12/14 / CL, YS / 2.0 /
- Revise the cost analysis and benefits analysis
- complete the architecture feasibility analysis
- complete the process feasibility analysis
- some resolved risks have been removed
- complete the COTS analysis
- To prepare for FCR ARB
Table of Contents
Feasibility Evidence Description (FED)
Version History
Table of Contents
Table of Tables
Table of Figures
1.Introduction
1.1Purpose of the FED Document
1.2Status of the FED Document
2.Business Case Analysis
2.1Cost Analysis
2.2Benefit Analysis
2.3ROI Analysis
3.Architecture Feasibility
3.1Level of Service Feasibility
3.2Capability Feasibility
3.3Evolutionary Feasibility
4.Process Feasibility
5.Risk Assessment
6.NDI/NCS Interoperability Analysis
6.1Introduction
6.2Evaluation Summary
Table of Tables
Table 1: Personnel Costs
Table 2: Hardware and Software Costs
Table 3: Benefits of iRobot GUI
Table 4: Level of Service Feasibility
Table 5: Capability Requirements and Their Feasibility Evidence
Table 6: Evolutionary Requirements and Their Feasibility Evidence
Table 7: Rationales for Selecting Architected Agile Model
Table 8: Risk Assessment
Table 9: NDI Products Listing
Table 10: NDI Evaluation
1Version Date: 10/12/14
Feasibility Evidence Description (FED)Version 2.0
Table of Figures
Figure 1: Program Model
1Version Date: 10/12/14
Feasibility Evidence Description (FED)Version 2.0
1.Introduction
1.1Purpose of the FED Document
This document reports the evidence of project feasibility in term of Business Case Analysis, Risk Assessment, and NDI/NCS Interoperability Analysis.
1.2Status of the FED Document
This is the third version of the document. Compared with the second version, the changes and improvements are listed as follow:
- According to the requirement and suggestion of FCR ARB, we revised some parts of Cost Analysis and Benefits Analysis, and made it more accurate and specific.
- The Architecture Feasibility Analysis is completed based on the requirement of draft FC Package.
- The Process Feasibility Analysis is completed based on the requirement of draft FC Package.
- Some resolved risks are removed.
- The COTS Analysis in Section 6 is completed according to the feedback of FED provided in slides EC-16 to prepare for the FCR ARB presentation.
2.Business Case Analysis
The original version of program model has been discussed and revised during the first win-win negotiation. In the revised version, assumptions become more accurate, initiators and beneficiaries are defined clearer, and Initiatives tend to be more comprehensive.
Figure 1: Program Model
2.1Cost Analysis
In this section, various types of costs will be analyzed. Typically, costs can be generally divided in to two categories, personnel costs and hardware and software costs. The detail of these two kinds of costs are demonstrated Table 1 and Table 2, respectively.
2.1.1Personnel Costs
Table 1: Personnel Costs
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
2.1.2Hardware and Software Costs
Table 2: Hardware and Software Costs
Type / Cost / RationaleHardware - 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
2.2Benefit Analysis
The most important benefit of the project is to help elementary school students program iRobot more efficiently and understand the logic and control system more deeply. However, since it is the beginning of the project, it may be hard to give some quantized results of the benefits. Accordingly, in this version, only a basic outline is given in table 3, and some quantitative field is left "TBD".
Table 3: Benefits of iRobot GUI
Current activities & resources used / % Reduce / Time Saved (Hours/Year)Drag and Drop GUI
Elementary schoolstudents save time to programming iRobot / 80% / TBD
Undergraduate students can teach elementary students much easier / 70% / TBD
Elementary school students are highly possible to be interested in STEM / N/A / N/A
Total
2.3ROI Analysis
Since the project is a non-profitable project, the ROI analysis will not be launched there.
3.Architecture Feasibility
Evidence and analysis of architecture feasibility are provided in the section. Specifically, we divided architecture feasibility into three categories: level of service feasibility, capability feasibility and evolutionary feasibility.
3.1Level of Service Feasibility
Table 4: Level of Service Feasibility
Level of Service Requirement / Product SatisfactionReasonable response time of iRobot / Product Strategies:Optimization
Process Strategies:Simulation, Performance Analysis
Analysis:
Optimization: Due to the difference between reality and ideal, such as the fact that sensor data will be checked with time interval rather than continuously, we need to do some optimization to minimize the error.
Simulation: After we create the original optimizing mechanism, we need to do simulation and record the result so that we can analyze later.
Performance Analysis: According to the recorded simulation data, we will analysis the reason cause those result, and consider whether it can be further optimized.
Seamless interoperability between GUI and complier. / Product Strategies: Integrity Functions, Layering
Process Strategies: Interface Definition Tools
Analysis:
Integrity Functions: The essential work of our GUI application is to call specific functions and then assign parameter to them.
Layering: The whole application can be viewed as deployed in several different layers. Firstly, the GUI is the highest level, which takes interoperate with user. Then, the visual graphic will be turned into C code, regarded as the second layer. Lastly, C code will be turned into binary code in the third layer.
Interface Definition Tools: In our highest interface level, we need some interface definition tools to build the graphic user interface.
3.2Capability Feasibility
Table 5: Capability Requirements and Their Feasibility Evidence
Capability Requirement / Product SatisfactionDrag-and-drop GUI:Make a User-friendly drag-and-drop GUI on Windows operating system to help elementary school students program and control iRobot. / Software/Technology used:Visual Studio
Feasibility Evidence:Visual Studio is an IDE used to develop computer programs for Windows as well as website applications. Also, a forms designer used to build GUI application is integrated in Visual Studio. Since We only need to run our product on Windows operating system, we can use Visual Studio as our developing platform.
Referred use case diagram:
1. Elementary school students drag-and-drop the buttons into interface
2. GUI application turns the graphic view into C code, then calls G++ compiler to turn it into binary code.
3. Elementary school students can store compiled code into microcontroller
4. Elementary school students insert microcontroller into iRobot and enable iRobot it to complete specific tasks.
Instruction Error Detecting and Reporting: Integrate a instruction error detection mechanism that report the ambiguous or conflict error in a readable way / Software/Technology used:Integration of Artificial Intelligent algorithm
Feasibility Evidence: Since compiler cannot detect logic error during compiling process. We need to add error detecting and reporting mechanism. Basically, we can work out a list of potential errors and check it during compiling. An advance method is that we category the errors using some methods referring Artificial Intelligent so that the cost of checking decreases.
Referred use case diagram:
1. Elementary school students drag-and-drop the buttons into interface with potential conflicts
2. Error detection mechanism triggered during the compiling process and return the error or conflict in a readable way with leading to the drag-and-drop interface again
3. Elementary school students check the error and correct it.
3.3Evolutionary Feasibility
Table6: Evolutionary Requirements and Their Feasibility Evidence
Evolutionary Requirement / Product SatisfactionCompatibility with latest version of Windows: Latest version of Windows may be the most frequently used operating system in the future so that our GUI should be compatible with it. / Software/Technology used:.NET Framework
Feasibility Evidence:We build our project on.NET Framework, which is a virtual machine. Therefore, the program itself is independent to the platform it is running on.
Referred use case diagram:
1. Elementary do not need to turn latest version of Windows to an older one to run the GUI application.
Further improvement after test: After we produce the initial version, elementary student will get the chance to use it and give us feedback so that we can make further change to meet their needs more precisely. / Software/Technology used:Questionnaire, Survey, Interview
Feasibility Evidence: Since we cannot fully meets the need of elementary school students at first time, we can provide them with test demo and collect their feedback. According to the feedback, we can further improve our application to make it even easier to use for them. Due to highly reuse of previous code and comment recorded during the first developing process, the cost of upgrade the application will not be too high.
Referred use case diagram:
1. Developers provide questionnaire, survey and launch interview with elementary school students after they try our application.
2. Elementary school students give feedback through above approach.
3. Developers upgrade the application according to the collected feedback.
4.Process Feasibility
Out team follows the process model of architected agile. This is mainly because the technology used in the project is quite mature. Below are the rationales in more detail.
Note:
Decision Criteria Rating Scale: 0:Very Low; 1:Low; 2: Medium; 3:High; 4:Very High
Importance Rating Scale: 1:Low; 2: Medium; 3:High
Table 7: Rationales for Selecting Architected Agile Model
Criteria / Importance / Project Status / Rationales30 % of NDI/NCS features / 2 / Direct adoption / Based on our research, it is not crucial and decisive for our project.
Single NDI/NCS / 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.
Need control over upgrade / maintenance / 2 / Haven't been Scheduled / Based on win-win session, our client did not refer any specific requirement for upgrade and maintenance, but we believe it is necessary to do some upgrade and maintenance to some extent.
Rapid deployment / 1 / Haven't been Scheduled / Based on win-win session, our client did not propose relative for rapid deployment.
Critical on compatibility / 1 / Haven't been Scheduled / Based on win-win session, our project only need to be run on Windows7 or above version, so the compatibility is not a crucial issue.
Internet connection independence / 1 / Haven't been Scheduled / Based on win-win session, our project does not require an Internet connection.
Need high level of services / performance / 3 / In Schedule / Based on win-win session, our project requires high level of performance and accuracy, like the limit of error tolerance.
Need high security / 1 / Haven't been Scheduled / Based on win-win session, no security requirement is clarified.
Asynchronous communication / 1 / Haven't been Scheduled / Based on win-win session, the system does not need to deal with network issues.
Be accessed from anywhere / 1 / Haven't been Scheduled / Based on meeting with our client, the software is used for teaching in elementary school, so it does not need to be accessed from anywhere.
Critical on mass schedule constraints / 1 / Haven't been Scheduled / Based on win-win session, there is no specific requirement proposed for mass schedule.
Lack of personnel capability / 1 / Haven't been Scheduled / Based on our research and win-win session, only one window will be opened on a specific computer, so we do not need to consider system capability.
Require little upfront costs / 1 / Haven't been Scheduled / Based on our research and meeting with client, the system does not have any requirements on cost, as well as upfront costs.
Require low total cost of ownership / 1 / Haven't been Scheduled / The devices used for teaching are provided by USC, so cost of owner is not within consideration.
Not-so-powerful local machines / 1 / Haven't been Scheduled / Based on win-win session, our project requires a computer/laptop with Window 7 or above, which should not be a problem for today's technology.
5.Risk Assessment
Compared with the first version, we find more potential risks in the future developing process in this week. Detail records and corresponding mitigation about the exposed risks are demonstrated in table 8.
Table 8: Risk Assessment
Risks / Risk Exposure / Risk MitigationsPotential Magnitude / Probability Loss / Risk Exposure
Visual studio (VS) is decided to be used for designingthe GUI, but team has very less idea which compiler gels well withVS to compile C code. / 6 / 6 / 36 / Working on feasibility of having WinAVRcompiler working withVisualStudio next week.
Technical risk - potential difficulties of detecting conflicting instructionsgiven by the end users / 5 / 6 / 30 / Team needs to come up with a design where theconflicting instruction set are detected.
Team needs to come up with a design where aspecific action is taken to avoid unpredictable behaviorof the robot.
Team does not fully understand yet how to programthe robot's microcontroller and integrate the robot'sfunction with the interface. / 6 / 4 / 18 / Team will be consulting Robotics faculty to support building a prototyping.
6.NDI/NCS Interoperability Analysis
6.1Introduction
In the section, we introduce the NDI/NCS software that we currently using or are going to adopt.
6.1.1COTS / GOTS / ROTS / Open Source / NCS
In the section, candidate commercial off-the-shelf, government-off-the-shelf, research-off-the-shelf, open source software, libraries, and net-centric services component that our group are using/ plan to use are listed. And the purposes of using them are explained.
Table 9: NDI Products Listing
NDI/NCS Products / PurposesVisual 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
6.1.2Connectors
Identify the connector, for example
-“In this project, we use PHP/MySQL Connector to enable the PHP web application to retrieve and query data from the database”. >
6.1.3Legacy System
Identify the connector, for example
-“In this project, the development system has to be able to interoperate and works well with “BusinessWorks” version 5.2, which is a software system that the client is currently using.” >
6.2Evaluation Summary
Summarize the final selection of your interoperable NDI/NCS, its usage and its comment. Example can be found in ICSM EPG> Task: Analyze NDI Interoperability for NDI / NCS project.
Table 10: NDI Evaluation
NDI / Usages / Comments1Version Date: 10/12/14