Feasibility Evidence Description (FED) for LADOT ScanningVersion 4.1
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
10/16/11 / AK / 2.3 / Section 1.2 & 5 changed / Bugs reported fixed
10/26/11 / AK / 3.0 / Sections 2,3,4,5 & 6 updated / DC package
10/31/11 / AK / 3.1 / Bugs fixed / Bugs reported resolved
11/04/11 / AK / 3.2 / Bugs fixed / Bugs reported resolved
11/20/11 / AK / 4.0 / Sections updated / Draft TRR package
12/04/11 / AK / 4.1 / Bugs fixed / Bugs reported resolved
Table of Contents
Feasibility Evidence Description (FED)......
Version History
Table of Contents
Table of Tables
1. Introduction
1.1Purpose of the FED Document
1.2Status of the FED Document
2. Business Case Analysis
2.1Cost Analysis...... 2
2.2Benefit Analysis...... 2
2.3ROI Analysis...... 2
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.2Evaluation Summary
Table of Tables
Table 1: Capability Requirements and Their Feasibility Evidence
Table 2: Rationales for Selecting Architected Agile Model
Table 3: Requirement Prioritization (Must Have Only)...... 6
Table 4: Risk Assessment
Table 5: NDI Products Listing...... 12
Table 6: NDI Evaluation...... 13
FED_TRR_F11a_T08_V4.11Version Date: 12/04/11
Feasibility Evidence Description (FED) for LADOT ScanningVersion 4.1
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
All sections are completed as per the requirements of the Draft TRR package.
In sections 3, we list out the Capabilities and the Level of Service goals, and determine their feasibility evidence.
In section 4, we give the rationale for selecting the Architected Agile Model.
The risks in section 5 are updated to identify the actual risks as closely as possible.
Section 6 is updated with information about COTS and NDI/NCS products we are using in the project.
2.Business Case Analysis
Not to be performed as per the discussion with Tip. As we are implementing the truck software this semester, therefore the amount of documentation to be performed has been reduced.
3.Architecture Feasibility
3.1Level of Service Feasibility
We currently have no well-known level of service requirements.
3.2Capability Feasibility
Table 1: Capability Requirements and Their Feasibility Evidence
Capability Requirement / Product SatisfactionCR-1: Error Checking / Software/Technology used:C#, ASP .NET
Feasibility Evidence:Error checking is an essential component and ensures all the work order codes, employee ids and other details are valid.
Referred use case diagram:N/A
CR-2: Log In / Software/Technology used:HTML, C#, ASP .NET
Feasibility Evidence:The field worker logs into the system through a login page by entering his credentials in a text box.
Referred use case diagram:FW-04
CR-3: Log Out / Software/Technology used: HTML, C#, ASP .NET
Feasibility Evidence: The field worker logs out by hitting the log out button on the web page.
Referred use case diagram: FW-05
CR-4: Export file / Software/Technology used: C#, ASP .NET, local SQL database
Feasibility Evidence: Also upon session log out, the work order code, the location code and other details get read into a local SQL database.
Referred use case diagram: N/A
CR-5: View Reports / Software/Technology used: N/A
Feasibility Evidence: When the field worker logs into his account, he can see a log of all the time he has spent on different jobs in the last fortnight.
Referred use case diagram: N/A
3.3Evolutionary Feasibility
We currently have no well known evolutionary requirements.
4.Process Feasibility
Table 2: 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.
Change Rate % /Month / Since we are developing the truck software for the project, there shouldn’t be too many changes. But even if the client changes his requirements, the change rate shouldn’t be too high, as we are constantly keeping in touch with the clients to assess their requirements.
Criticality /
- Criticality of the project would be medium as we are developing only the truck side of the software and not the entire application.
NDI Support /
- We are not using any NDIs in a prominent role at this stage of development but the client does want to use Sharepoint in the future.
Org/Personnel Capability /
- The personnel in this organization have medium capability which works fine for the Architected Agile process.They have the relevant technical expertise in order to carry out the system implementation.
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 the truck software and giving detailed documentation and prototypesfor the project. 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 3: Requirement Prioritization
Priority / Requirements / References / Increment #M / CR-1: Error Checking / CR-1 / 1
M / CR-2: Log In / CR-2 / 1
M / CR-3: Log Out / CR-3 / 1
M / CR-4: Export file / CR-4 / 2
C / CR-5: View Reports / CR-5 / 2
5.Risk Assessment
All possible risks to the project at this point of time have been identified and documented below in tabular form. Risk exposure identifies the extent of the risk, the higher the value of the Risk Exposure (Product of Potential Magnitude and Probability Loss), the higher the risk. Also, a corresponding Risk Mitigation plan has been identified and listed below.
Table 4: Risk Assessment
Risks / Risk Exposure / Risk MitigationsPotential Magnitude / Probability Loss / Risk Exposure
Time constraint / 5 / 6 / 30 / Discuss the scope and objective of the desired system with the client and assess if it can be completed in the allotted time period.
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.
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.
Team Fluidity / 2 / 3 / 6 / Regular communication and meetings ensure each and every team member is aware of the viewpoint and thought process of every other team member and helps in avoiding conflicts.
6.NDI/NCS Interoperability Analysis
6.1Introduction
Since the scope of the project has been changed after the ARB, and we are implementing the truck software, that has resulted in practically developing the system from scratch with very less reliance on any COTS or NDI/NCS products. But still few of these products are still being used and they are listed in the sections below.
6.1.1COTS / GOTS / ROTS / Open Source / NCS
Table 5: NDI Products Listing
NDI/NCS Products / PurposesASP.NET / Server side programming language to develop the website.
Microsoft SQL database (on the truck system) / Local database on the truck to store the data.
6.1.2Connectors
Microsoft SQL and ASP.NET framework is used to connect the local Microsoft SQL database on the truck to the UI that the field worker logs into.
6.1.3Legacy System
The FLAT file that is being generated should ideally be compatible with the existing DTIME timekeeping system in place or at least be developed in such a manner that its requires minimal modification for integration.
6.2Evaluation Summary
Table 6: NDI Evaluation
NDI / Usages / CommentsASP.NET / Server side programming language to develop the website. / Beneficial for efficient server side development.
Microsoft SQL database (on the trucks) / Local database on the truck to store data locally. / Extremely vital to store data locally.
FED_TRR_F11a_T08_V4.11Version Date: 12/04/11