Feasibility Evidence Description (FED) for Architected Agile Template Version x.x
Feasibility Evidence Description (FED)
SWIM MEET SIGNUP
Team 03
Member Name / Role / EmailArchan Dutta / Project Manager, Life Cycle Planner /
Deepanshu Suneja / Software Architect, Developer /
Jenny Greer / IIV and V, Quality Focal Point /
Rasleen Sahni / Feasibility Analyst, Developer /
Swasti Sharma / Operational Concepts Engineer /
Vibhanshu Sharma / Software Prototyper /
10/16/2017
Version History
Date / Author / Version / Changes made / Rationale /08/20/05 / RS / 1.0 / · Original template for use developing Swim Meet Signup Website / · Initial draft for DC Package
Table of Contents
Feasibility Evidence Description (FED) i
Version History iii
Table of Contents iv
Table of Tables v
Table of Figures vi
1. Introduction Error! Bookmark not defined.
1.1 Purpose of the FED Document Error! Bookmark not defined.
1.2 Status of the FED Document Error! Bookmark not defined.
2. Business Case Analysis 2
2.1 Cost Analysis 3
2.2 Benefit Analysis Error! Bookmark not defined.
2.3 ROI Analysis 3
3. Architecture Feasibility 6
3.1 Level of Service Feasibility Error! Bookmark not defined.
3.2 Capability Feasibility Error! Bookmark not defined.
3.3 Evolutionary Feasibility Error! Bookmark not defined.
4. Process Feasibility 8
5. Risk Assessment 10
6. NDI/NCS Interoperability Analysis 11
6.1 Introduction 11
6.2 Evaluation Summary 11
Table of Tables
Table 1: Program Model 3
Table 2: Hardware and Software Cost Error! Bookmark not defined.
Table 3: Benefits of xxx System Error! Bookmark not defined.
Table 4: ROI Analysis Error! Bookmark not defined.
Table 5: Level of Service Feasibility Error! Bookmark not defined.
Table 6: Capability Requirements and Their Feasibility Evidence Error! Bookmark not defined.
Table 7: Evolutionary Requirements and Their Feasibility Evidence Error! Bookmark not defined.
Table 8: Rationales for Selecting Architected Agile Model 8
Table 9: Risk Assessment Error! Bookmark not defined.
Table 10: NDI Products Listing Error! Bookmark not defined.
Table 11: NDI Evaluation 11
IICSMSw_FED_Architected Agile_Template.doc 12 Version Date: 08/17/12
Feasibility Evidence Description (FED) for Architected Agile Template Version x.x
Table of Figures
Figure 1: ROI Analysis Graph Error! Bookmark not defined.
IICSMSw_FED_Architected Agile_Template.doc 12 Version Date: 08/17/12
Feasibility Evidence Description (FED) for Architected Agile Template Version 1.0
1. Introduction
1.1 Purpose of the FED Document
The purpose of the Feasibility Evidence Description evidence is to that the development project is feasible and to show that the other artifacts are consistent and compatible, in the sense that:
· Satisfaction of all the requirements specified in the SSRD will result in satisfaction of the Win-Win agreements made by the success-critical stakeholders, for all of the operational scenarios and goals (benefits, ROI, etc.) specified in the OCD.
· Demonstrate the compatibility and consistency of these elements in ensuring, with high probability, the feasibility of accomplishing the desired goals – both product-wise and project-wise.
· Encourage the development to regularly analyze the risk of the development project and prepare for risk mitigation and risk management plan.
The Feasibility Evidence Document (FED) provides a throughout analysis documenting the feasibility of the SwimMeetSignUp project to be completed according to schedule and budget constraints. Our conclusions are drawn from the different types of analysis presented in the following sections: Business Case, Architecture Feasibility, Process Feasibility, Risk Assessment and NDI/NCS Interoperability Analysis.
1.2 Status of the FED Document
The status of this FED is currently at the version number 1.0, which will be submitted along with Foundations Commitment Package. This version will be reviewed with the necessary stakeholders and if there are no changes to be made, the latest version of this document will be delivered to the client.
2. Business Case Analysis
Table 1: Program Model
Assumptions1. The developer should have access to the database of registration ids of the members.
2. The pdf format should be the same for different months.
3. The users are technically sound to operate the website on all devices.
Stakeholder
(Who is accountable for the information) / Initiatives
(What to do to realize
benefits) / Value Propositions
(Benefits i.e. Why) / Beneficiaries
(Who derives value)
1. Coach
2. Parent
3. Treasurer/Maintainer
4. Developer / 1. Develop the system
2. Maintain the system
3. Elicitate requirements
4. Negotiate with the client
5. Assign tasks
6. Test different technologies. / 1. Reduce incorrect event signups by the parents
2. Easy filter and signup events by the parents.
3. Easy access to total cost generated by signed up events.
4. Easy / 1. Children
2. Coach
3. Parents
4. Treasurer
Cost (Cost factors)
· Server Deployment Cost.
· Cost for planning and developing the software (in hours).
· There is no Hardware and Software Cost in this project.
· Maintenance Cost / Benefits (Key performance indicators- KPIs)
· The Head Coach will spend less time dealing with incorrect signups and creating reports; thus, increasing the productivity in other areas of work
· Parents signup correctly: Parents can easily signup using the website as they can only see events there kid is eligible for. Mobile devices can also be used as website is mobile responsive
· Treasurer can track the total revenue generated for each swim meet.
2.1 Cost Analysis
2.1.1 Personnel Costs
Table 2: Personnel Costs
Activities / Time Spent(Hours)Total Time Available (12 weeks)
Exploration Phase
• Client Meetings (2 hours*1 week*1 person)
• Win Win Session 1 (2 hours * 1 person) / 2 hours
2 hours
Valuation and Foundation Phase
• Win Win Session 2 (2 hours* 1 person)
• Weekly Discussion Remote Meetings (1 hour*3 weeks*1 person)
• ARB (2 hours* 2 times * 1 person) / 2 hours
3 hours
4 hours
Development, Foundations, Operations Phase
• Weekly Process Meetings (1hour*6 weeks*1 person)
• Handover Activities (2 hours* 6 weeks * 1 person)
• TRR (1 hours* 1 person)
• CCD (1 hours * 1 person) / 6 hours
12 hours
1 hour
1 hour
Total time spent / 33 hours
2.1.2 Hardware and Software Costs
Table 3: Hardware and Software Costs
Type / Cost / RationaleWindows / Free / Development operating system
Apache PDFBox / Free / PDF library
MySQL / Free / Database
Apache TOMCAT server / Free / Server
Adobe Photoshop / Free / Photo editing Tool
2.2 Benefit Analysis
Table 4: Benefits of SwimMeetSignUp System
Current activities & resources used / Current System (Hours/Year) / Proposed System (Hours/Year) / % Reduce / Time Saved (Hours/Year)Event Signup
Parent Sign-ups for the event online / 12 / 2 / 83.3% / 10
Change Signed Up Events
Parent can change the event online his kid is signed up for / 12 / 2 / 83.3% / 10
View and Edit Final Report
Head Coach can view and edit the final report and print in pdf/csv format / 60 / 2 / 96.6% / 58
Maintain Records
Head Coach maintains the records using file systems / 24 / 2 / 91.6% / 22
Total / 100
2.3 ROI Analysis
Table 5: ROI Analysis
Year / Cost / Benefit(Effort Saved) / Cumulative Cost / Cumulative Benefit / ROI
2017 / 33 / 0 / 33 / 0 / -1
2018 / 36.3 / 100 / 69.3 / 100 / 0.44
2019 / 39.93 / 100 / 109.23 / 200 / 0.83
2020 / 43.9 / 100 / 153.13 / 300 / 0.95
2021 / 48.3 / 100 / 201.43 / 400 / 0.98
Figure 1: ROI Analysis Graph
3. Architecture Feasibility
3.1.1 Level of Service Feasibility
Table 6: Level of Service Satisfiability Evidence
Level of Service Win Condition / RationaleLOS-1: The system shall be mobile responsive. / Use HTML media queries to define screen styling for different mobile screens and achieving mobile responsiveness.
Table 7: Level of Service Implementation Strategy
Level of Service Win Condition / Product SatisfactionLOS-1: The system shall be mobile responsive. / Product Strategies: Bootstrap, HTML, CSS
Process Strategies: Develop a prototype to produce a mobile responsive website using HTML media queries and Bootstrap features.
Analysis: Use Bootstrap and CSS to create a mobile responsive website.
3.1.2 Capability Feasibility
Table 8: Capability Feasibility Evidence
Capability Requirement / Product SatisfactionCR-1: PDF extraction / Software/Technology used: Apache PDFBox
Feasibility Evidence: Develop a prototype to implement PDF extraction using PDFBox-1.7.0.jar package to extract all the important information line by line from the PDF.
Referred use case diagram:
CR-2: Login / Software/Technology used: MySQL-PHP Connector
Feasibility Evidence: Develop a prototype to login to the system and authenticate the login details with the login credentials stored in MySQL database.
Referred use case diagram:
CR-3: View total cost / Software/Technology used: MySQL-PHP Connector
Feasibility Evidence: Develop a prototype to display the total cost the parent is supposed to pay for the signed-up events.
Referred use case diagram:
CR-4: Display eligible events / Software/Technology used: MySQL-PHP Connector
Feasibility Evidence: Develop a prototype to implement the filter functionality and display only those events for which the parent’s kid is eligible
Referred use case diagram:
CR-5: Close signups after deadline / Software/Technology used: MySQL-PHP Connector
Feasibility Evidence: Develop a prototype which only allows event signup before the deadline.
Referred use case diagram:
CR-6: Review event signup information before printing as a pdf/csv. / Software/Technology used: MySQL-PHP Connector
Feasibility Evidence: Develop a prototype to implement the function of reviewing all the signed-up events information by fetching data from MySQL database and displaying it on the website.
Referred use case diagram:
CR-7: Edit signed-up events before deadline / Software/Technology used: Angular JS and MySQL
Feasibility Evidence: Develop a prototype to make changes in the signed up events and store the edited information in the database.
Referred use case diagram:
CR-8: PDF and CSV file generation / Software/Technology used: MySQL, Angular JS
Feasibility Evidence: Develop a prototype to fetch the information from MySQL and store it in a PDF and CSV format using MySQL database and Angular JS.
Referred use case diagram:
3.1.3 Evolutionary Feasibility
At the time of this draft, no evolutionary requirements are negotiated.
4. Process Feasibility
Table 9: Requirement Prioritization
Priority / Requirements / Increment #Must have / Events Extraction from PDF / 1
Must have / Extraction of payee information from PDF / 1
Must have / System should be mobile responsive / 1
Must have / Easy to use user interface / 1
Must have / Report Generation / 1
Should have / Keep track of best times of all kids / 2
Must have / Event Signup / 1
Must have / View and Edit Reports / 1
Table 10: Rationales for Selecting Architected Agile Model
Criteria / Importance / Project Status / Rationales30 % of NDI/NCS features / 3 / 3 / All of NDIs (PHP, AngularJS, Apache PDFbox) are being used for the development.
Single NDI/NCS / 1 / 1 / More than one NDI is used for development
Unique/ inflexible business process / 1 / 1 / The business process is not unique. It is specific to a swimming organization and has little flexibility
Need control over upgrade / maintenance / 2 / 1 / Maintenance is required. Small upgrades might be required
Rapid deployment / 3 / 3 / It is a one semester project and therefore requires rapid deployment
Critical on compatibility / 2 / 3 / Since, all of NDIs are used, they must be compatible with each other
Internet connection independence / 3 / 3 / The website requires internet connection to be accessed.
Need high level of services / performance / 2 / 2 / The website requires web browsers and must run on desktop/laptop/mobile devices
Need high security / 1 / 1 / Security is required to keep records safe. This is done through MySQL and proper authentication
Asynchronous communication / 2 / 2 / System requires Asynchronous communication
Be accessed from anywhere / 3 / 3 / The system will be on the server and must be accessible from remote locations via the Internet
Critical on mass schedule constraints / 3 / 3 / Since, time period is short, the project has several schedule constraints
Lack of personnel capability / 2 / 2 / Members have some experience in web development but still unaware of some processes required for the development
Require little upfront costs / 4 / 4 / Most NDIs are free
Require low total cost of ownership / 3 / 3 / The system will be owned by Arcadia Riptides Swim Club and will increase their profits
Not-so-powerful local machines / 2 / 1 / The website is not performing complex computations and therefore does not require powerful machines
5. Risk Assessment
Table 11: Risk Assessment
Risks / Risk Exposure / Risk MitigationsPotential Magnitude / Probability Loss / Risk Exposure
Information extraction from PDF / 9 / 4 / 36 / 1- Research tools/technologies and procedures for PDF extraction
2- Run Prototype on a PDF to see if it works.
Easy to use UI/UX for the end-users / 5 / 4 / 20 / Develop prototypes for the UI and get feedback from the users on the UI
A lot depends on what PDF that being provided, the format of which is fixed. / 9 / 2 / 18 / Develop prototype which can extract information from various expected types of PDFs.
6. NDI/NCS Interoperability Analysis
6.1 Introduction
We chose NDI products based on what we need during the development. For our project, we used Apache PDFBox as development tool/library to extract the relevant information from the PDF and show up the events on the website. MySQL database is used to store information and generate final reports having all the data. AngularJS is used to manipulate and display the relevant data on the website. Apache Tomcat is used as the server and PHP is used for back-end work (server-side scripting).
6.1.1 COTS / GOTS / ROTS / Open Source / NCS
Table 12: NDI/NCS Products Listing
NDI/NCS Products / PurposesApache PDFbox / Extract Information from the Swimming Meet pdf.
PHP / Server-Side Scripting
MySQL / Database to store information of events and kids
AngularJS / Frontend Framework along with HTML and CSS
6.1.2 Connectors
Table 13: NDI/NCS Products Listing