Feasibility Evidence Description (FED)Version 1.1
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
09/19/2014
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
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 xxx System
Table 4: ROI Analysis
Table 5: Level of Service Feasibility
Table 6: Capability Requirements and Their Feasibility Evidence
Table 7: Evolutionary Requirements and Their Feasibility Evidence
Table 8: Rationales for Selecting Architected Agile Model
Table 9: Risk Assessment
Table 10: NDI Products Listing
Table 11: NDI Evaluation
IICSMSw_FED_F14a_T07.doc1Version Date: 09/28/14
Feasibility Evidence Description (FED)Version 1.1
Table of Figures
Figure 1: ROI Analysis Graph
IICSMSw_FED_F14a_T07.doc1Version Date: 09/28/14
Feasibility Evidence Description (FED)Version 1.1
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 second version of the document. Compared with the first version, the changes and improvements are listed as follow:
- The template of the document has been changed to be consistent with the template given on course website.
- The revised version of program model is presented.
- More exposed risks have been recorded and analyzed.
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)
Client: Meeting via email, phone and other channels [2 hr/week * 12 weeks * 2 people] / 48
Maintainer: Meeting via email, phone, and other channels [8 hr/week * 12 weeks * 2 people] / 192
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 / 440
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 / TBD / 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 xxx System
Current activities & resources used / % Reduce / Time Saved (Hours/Year)Drag and Drop GUI
Elementary Students (10 robots * ? min) / 90% / TBD
Total
2.3ROI Analysis
Since the project is a non-profitable project, the ROI analysis will not be launched there.
3.Architecture Feasibility
< Provide evidence or rationale of why do you think the following LOS, capability, and evolutionary requirements are satisfiable. Example of product and process strategies can be found in ICSM EPG> Task:Provide Feasibility Evidence for Architecture Agile project
3.1Level of Service Feasibility
Table 4: Level of Service Feasibility
Level of Service Requirement / Product SatisfactionLOS-1: LOS name / Product Strategies: <Identify product-related strategies that can make you achieve this requirement.
Process Strategies: <Identify process-related strategies that can make you achieve this requirement.
Analysis: < Provide rationale to support your strategies>
Product Strategies:
Process Strategies:
Analysis:
Product Strategies:
Process Strategies:
Analysis:
3.2Capability Feasibility
Table 5: Capability Requirements and Their Feasibility Evidence
Capability Requirement / Product SatisfactionCR-1: CR name / Software/Technology used: <identify the software/technology that is/are used to develop this capability requirement>
Feasibility Evidence: < briefly provide rationale of how this capability could be developed to satisfy the requirements. >
Referred use case diagram: < identify related use case diagram >
Software/Technology used:
Feasibility Evidence:
Referred use case diagram:
Software/Technology used:
Feasibility Evidence:
Referred use case diagram:
3.3Evolutionary Feasibility
Table 6: Evolutionary Requirements and Their Feasibility Evidence
Evolutionary Requirement / Product SatisfactionER-1: ER name / Software/Technology used: <identify the software/technology that is/are used to develop this capability requirement>
Feasibility Evidence: < briefly provide rationale of how this capability could be developed to satisfy the requirements. >
Referred use case diagram: < identify related use case diagram >
Software/Technology used:
Feasibility Evidence:
Referred use case diagram:
Software/Technology used:
Feasibility Evidence:
Referred use case diagram:
4.Process Feasibility
< Based on process decision table provided in ICSM EPG> Concept: Process Decision Selection Guidelines, Identify which process model you are following and provide rationale why that model would fit your development project. Note: Development team discusses with stakeholders on important drivers and project status
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
Single NDI/NCS
Unique/ inflexible business process
Need control over upgrade / maintenance
Rapid deployment
Critical on compatibility
Internet connection independence
Need high level of services / performance
Need high security
Asynchronous communication
Be accessed from anywhere
Critical on mass schedule constraints
Lack of personnel capability
Require little upfront costs
Require low total cost of ownership
Not-so-powerful local machines
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 unpredictible behaviorof the robot.
Team does not fully understand yet how to programthe robot's microcontroller and integrate the robot'sfunction with the interface. / 6 / 3 / 18 / Team will be consulting Robotics faculty to support building a prototyping.
Usage of Instant Messaging service is posing a risk ofmiscommunication among the members and affectingmeeting schedules. / 2 / 2 / 4 / Team plans to meet on this topic this week and arriveat a conclusion.
6.NDI/NCS Interoperability Analysis
6.1Introduction
Identify the Non-Developmental Item (NDI) and Net-Centric Services (NCS) including open source software or libraries that you are using/ plan to use in your project and analyze their interoperability. >
6.1.1COTS / GOTS / ROTS / Open Source / NCS
Identify all candidate commercial off-the-shelf, government-off-the-shelf, research-off-the-shelf, open source software, libraries, and net-centric services component that you are using/ plan to use. Also identify the purpose of each component. >
Table 10: NDI Products Listing
NDI/NCS Products / Purposes6.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 11: NDI Evaluation
NDI / Usages / CommentsIICSMSw_FED_F14a_T07.doc1Version Date: 09/28/14