Feasibility Evidence Description (FED) for Architected Agile Version 2.2
Feasibility Evidence Description (FED)
Los Angeles Department of Transportation Scanning
Team #8
Team members / RoleAditya Kumar / Feasibility Analyst
Anirudh Govil / Project Manager
Corey Painter / IIV&V
Jeffrey Colvin / Prototyper
Niraj Brahmkhatri / Operational Concept
Nisheeth Joshi / Software Architect
Version History
Date / Author / Version / Changes made / Rationale09/30/11 / AK / 1.0 / First Draft / First Draft
10/07/11 / AK / 2.0 / Section 1.2 modified / Second Draft
10/07/11 / AK / 1.1 / Section 1.2 modified and
Font color changed to black / Second Draft
10/09/11 / AK / 2.1 / Font color changed to black / Font color modified
from blue
10/14/11 / AK / 2.2 / Sections 1 to 5 are completed / Draft FCP
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 Interoperability Analysis
6.1Introduction
6.2System Structure
6.3Evaluation Summary
Table of Tables
Table 1: Personnel Costs
Table 2: Hardware and Software Costs...... 3
Table 3: Benefits of xxx System
Table 4: ROI Analysis
Table 7: Level of Service Feasibility
Table 8: Capability Requirements and Their Feasibility Evidence
Table 9: Evolutionary Requirements and Their Feasibility Evidence...... 6
Table 10: Rationales for Selecting Architected Agile Model
Table 11: Requirement Prioritization (Must Have Only)
Table 12: Risk Assessment
FED_FCP_F11a_T08_V2.21Version Date: 10/14/11
Feasibility Evidence Description (FED) for Architected Agile Version 2.2
Table of Figures
Figure 1: ROI Analysis Graph
FED_FCP_F11a_T08_V2.21Version Date: 10/14/11
Feasibility Evidence Description (FED) for Architected Agile Version 2.2
1.Introduction
1.1Purpose of the FED Document
This document aims to validate the feasibility of the LADOT Scanning project. We try to achieve this by determining potential risks that the project faces and possible risk mitigation strategies to counter them. Afterwards, we will also determine the benefits and ROI of the project to instill commitment and progress
1.2Status of the FED Document
Sections 1 to 5 are completed as per the requirements of the Draft FC package.
The risks in section 5 are updated to identify the actual risks as closely as possible.
2.Business Case Analysis
2.1Cost Analysis
The cost that the Los Angeles Department of Transportation will possibly incur as a result of deployment of this project are indicated below:
2.1.1Personnel Costs
Table 1: Personnel Costs
Activities / Time Spent (Hours)Development Period (24 weeks)
Valuation and Foundations Phases: Time Invested
(CS577a, 12 weeks)
Client: Conference via email, phone, and other channels
[3 hrs/week * 12 weeks * 2 people] / 72
Client representatives: In-person meetings with USC Team
[2 hrs/week * 12 weeks * 3 people] / 72
Architecture Review Boards
[1.5 hrs * 2 times * 2 people] / 6
Development and Operations Phases: Time Invested
(CS577b, 12 weeks)
Client: Conference via email, phone and/or other channels
[4 hrs/week * 12 weeks * 1 person] / 48
Maintainer: communication via email, phone, and/or other channels
[8 hrs/week * 12 weeks * 2 people] / 192
Architecture Review Boards & Core Capability Drive-Through Session
[1.5 hrs * 3 times * 2 people] / 9
Deployment of System in Operation Phase & Training
[5 hrs * 3 times * 2 people]
Training & Support [5 hrs * 2 times * 2 people] / 50
Development Period Total / 449
Maintenance Period (1 year)
Maintenance
(2 hrs/week * 52 weeks) / 104
Maintenance Period Total / 104
2.1.2Hardware and Software Costs
Table 2.1: Hardware and Software Costs - Development
Type / Cost / RationaleHardware – Database Server / $0 / A Database server is needed for storing all the data items in the project. The client has informed us that they do have a database server and no additional investment is required to obtain a new one.
Hardware – Web Hosting / $0 / The LADOT has its own web hosting facility, and therefore no additional investment is required.
Software – Microsoft Sharepoint / $0 / The LADOT already possesses licenses to own Sharepoint and therefore no additional investment is needed.
Table 2.2: Hardware and Software Costs - Operation
Type / Cost / RationaleHardware – Database Server / $0 / The database is owned by the LADOT and no cost is required to maintain the database server.
Hardware – Web Hosting / $0 / LADOT provides web hosting facility and therefore no operation cost is needed.
2.2Benefit Analysis
Table 2: Benefits of LADOT Scanning System
Current activities & resources used / % Reduce / Time Saved (Hours/Year)Timesheet data entry
Personnel
(200 workers * 15min *52/2 weeks= 78,000 min) / 80 / 1040
Task Assignment
Personnel Staff
(200 workers * 7min * 52/2 weeks = 36,400 min) / 90 / 546
Error Checking and Validation
(Less labor intensive)
Personnel Staff
(2,00timesheets * 10 min * 52/2 weeks = 52,000 min) / 90 / 780
Log maintenance & Retrieval
for litigation purposes
Personnel Staff
(200 workers * 7min * 52/2 weeks = 36,400 min) / 90 / 546
Processing Leave of Absences
Personnel Staff
(30 min/leave * 250 leaves/year = 7500 min) / 70 / 87.5
Total / 2,999.5
2.3ROI Analysis
Return on Investment for our project the LADOT Scanning system is described in tabular form below. The exploration phase started in July of 2011, so the time period ranges from July to June of the following year. The year-to-year effort cost assumes a 10% increase in employee salary, for instance, the jump from an effort cost of 156 in the 2012-2013 year to 171.6 in the 2013-2014 year.
From the ROI Analysis graph below, it can be clinched that LADOT will get its return-on-investment almost immediately.
Table 3: ROI Analysis
Year / Cost / Benefit(Effort Saved) / Cumulative Cost / Cumulative Benefit / ROI
July 2011
to
June 2012 / 420 / 0 / 420 / 0 / -1.00
July 2012
to
June 2013 / 156 / 2999.5 / 576 / 2999.5 / 4.20
July 2013
to
June 2014 / 171.6 / 2999.5 / 747.6 / 5999 / 7.02
July 2014
to
June 2015 / 188.76 / 2999.5 / 936.36 / 8998.5 / 8.61
Figure 1: ROI Analysis Graph
3.Architecture Feasibility
3.1Level of Service Feasibility
Table 4: Level of Service Feasibility
Level of Service Requirement / Product SatisfactionLOS-1: Minimize Typing / Product Strategies: The use of a tablet or any other touch screen application can reduce typing effort.
Process Strategies: Using location codes and work order codes instead of typing the entire details will surely reduce typing effort.
Analysis: Reducing typing will make the process less cumbersome for data entry from the field workers’ perspective.
LOS-2: Possibility to run on tablet / Product Strategies: Use a tablet with Wifi access in order to connect to the central database.
Process Strategies: Tablets will ensure the data is populated reliably into a central database.
Analysis: More convenient and systematic way of entering data into the system than using handwritten sheets.
3.2Capability Feasibility
Table 5: Capability Requirements and Their Feasibility Evidence
Capability Requirement / Product SatisfactionCR-1: Can determine current location through GPS. / Software/Technology used: N/A
Feasibility Evidence: This capability is currently not implemented, and is a desired feature. By using this technology we can efficiently and quickly assign tasks to the workers.
CR-2: Employee can review their maintenance reports. / Software/Technology used: MS SQL
Feasibility Evidence: We use MS SQL as the backend database framework, which will allow us to easily index key fields based on column name such as employee name or other search qualifiers.
Referred use case diagram: SSAD Process Diagram
CR-3: Supervisors can see all activities for subordinates. / Software/Technology used: MS SQL
Feasibility Evidence:The use of MS SQL as the backend database framework allows us to easily index key fields based on column name such as subordinates workers working under a Supervisor or other search qualifiers.
Referred use case diagram: SSAD Process Diagram
CR-4: Send FLAT file to DTIME in DTIME format every two weeks. / Software/Technology used: Web-based application
Feasibility Evidence: The FLAT file is used for timekeeping purposes and is a convenient way of generating salaries for the employees after a fortnight.
Referred use case diagram: SSAD Process Diagram
CR-5: Export location codes and issue working codes and identification numbers. / Software/Technology used: MS SQL, Web-based application
Feasibility Evidence: The location codes, working order codes are sent from the field worker location through a web application and populated into the MS SQL database.
Referred use case diagram: SSAD Process Diagram
CR-6: Standardize tasks to be entered. / Software/Technology used: Web-based application (forms, etc.)
Feasibility Evidence: This will ensure that all the data entry is done following the same set of rules and ensure efficient data retrieval and easy to understand stored information.
Referred use case diagram: SSAD Process Diagram
CR-7: Sign on/off for work. / Software/Technology used: MS SQL, Web-based application
Feasibility Evidence: This is the major task of the project to ensure reliable data entry at the beginning and end of the project.
Referred use case diagram: SSAD Process Diagram
CR-8: Daily dumps should go into SQL server database. / Software/Technology used: Web-based application, MS SQL.
Feasibility Evidence: Daily dumps going into the centralized database ensure that the maintenance and issues, which need further attention are allocated and assigned efficiently.
Referred use case diagram: SSAD Process Diagram
3.3Evolutionary Feasibility
The project has no well renowned Evolutionary Requirements.
4.Process Feasibility
Table 6: Rationales for Selecting Architected Agile Model
Criteria / RationalesSize, Complexity /
- The system stores a medium to large amount of data and requires a medium amount of must-have win conditions. Its medium size makes the project ideally suited for the Architected Agile Model.
- The complexity for this system is mediocre. It essentially needs a web-application, which allows efficient time-keeping of all the field workers across the city of LA and populates a central database with all this information.
Change Rate % /Month
Criticality /
- LADOT Scanning project aims at automating the entire payroll process and getting read of the handwritten timesheets. Once the switch to digital is made, LADOT plans to phase out the handwritten timesheets ultimately. The handwritten documents contained in the system will contain high profile & confidential information about all LADOT employees.
NDI Support /
- The only NDIs we will be using to develop this system Sharepoint. This is a well established NDI, and works perfectly with the Architected Agile process.
Org/Personnel Capability /
- The personnel in this organization have medium capability which works fine for the Architected Agile process. This is applicable to the system engineers who are part of the client representatives. They have the relevant technical expertise in order to carry out the system implementation. The primary users of the system are the non-technical client representatives. They are also familiar with the other LADOTdigital systems and would easily transition to a web based system. The client representatives are keen in adapting agile methodology and are very flexible. These features of the team and the organization can only be satisfied well by an Agile process.
Key Stage I Activities : Incremental Definition /
- Initially the project would require a lot of planning & architecting because the system would digitize many LADOT personnel processes. Thus because of these requirements both Valuation and Architecting phases would be used. Hence an Architected Agile process would be used.
Key Stage II Activities: Incremental Development, Operations /
- The features must be added incrementally so that the system would be well developed. There are many capabilities, which are dependent on each other, so putting 1 capability at a time would help to reduce potential errors. This can be easily achieved by Architected Agile process during the development.
Time per Build;
Time per Increment / We are developing many unique database and interface components that need to be built completely from the beginning. It would take around 3-4 months for prototyping and development. We can divide the development span into increments of 2-3 weeks. Hence these figures would work well for the Architected Agile process where ideal time per build is 2-6 months and ideal time per increments is 2-4 weeks.
Table 7: Requirement Prioritization
Priority / Requirements / References / Increment #C / CR-1: Determine current location through GPS / 3
C / CR-2: Employee can review their maintenance reports / 2
S / CR-3: Supervisors can see all activities for subordinates / 2
M / CR-4: Send FLAT file to DTIME in DTIME format after every two weeks / 4
S / CR-5: Export location code and issue working codes and identification numbers / 1
S / CR-6: Standardize tasks to be entered / 1
S / CR-7: Sign on/off at the beginning of work using the truck / 1
S / CR-8: Daily dumps should go into SQL server database / 3
5.Risk Assessment
Table 8: Risk Assessment
Risks / Risk Exposure / Risk MitigationsPotential Magnitude / Probability Loss / Risk Exposure
Opposition from the Workers Union / 7 / 8 / 56 / Carry out surveys to determine what the workers union agrees on, provide them incentives, negotiate with them and reach a consensus.
Legal issues related to software package modification and updating / 6 / 7 / 42 / Discuss with the client and if possible also with the software manufacturer the extent to which the software can be tweaked and updated without running into legal issues.
Budget constraint / 4 / 6 / 24 / Discuss the budget and estimated financial cost that the client is willing to incur for the project.
Time constraint / 2 / 4 / 8 / Discuss the scope and objective of the desired system with the client and assess if it can be completed in the allotted time period.
Meeting constraint / 2 / 3 / 6 / Discuss meeting times with the client and other team members and come up with a weekly meet time ideal for everyone.
Change in Client Requirements / 3 / 4 / 12 / Discuss the requirements and needs of the clients at an early stage and make the system adaptable to accommodate late changes.
6.NDI/NCS Interoperability Analysis
6.1Introduction
6.1.1COTS / GOTS / ROTS / Open Source / NCS
Table 9: NDI Products Listing
NDI/NCS Products / Purposes6.1.2Connectors
6.1.3Legacy System
6.2System Structure
6.3Evaluation Summary
Table 10: NDI Evaluation
NDI / Usages / CommentsFED_FCP_F11a_T08_V2.21Version Date: 10/14/11