Feasibility Evidence Description (FED)

Transcription

1 Feasibility Evidence Description (FED) The Los Angeles Community Garden Inventory and Locator Team 13 Ardalan Yousefi Cole Cecil Jeff Tonkovich Shi-Xuan Zeng Project Manager Integrated Independent Verification & Validation Implementer Tester February 15, 2012 i

2 Version History Date Author Version Changes made Rationale 09/19/11 SHI-XUAN 10/05/11 SHI-XUAN 10/06/11 SHI-XUAN 10/10/11 SHI-XUAN 10/13/11 SHI-XUAN 10/17/11 SHI-XUAN 10/20/11 SHI-XUAN 10/24/11 SHI-XUAN 11/16/11 SHI-XUAN 12/01/11 SHI-XUAN 12/03/11 SHI-XUAN 02/03/12 SHI-XUAN 02/15/12 SHI-XUAN 0.1 Update section 5 Risk assessment 1.0 Modify section 5 Risk assessment Identify the risks and mitigation plans. Remove some risks that regard as issues. Sort the risks to reflect the importance of the risks. 1.1 Add contents in section 1. State the purpose and status in section Add contents in section 2 and 3. Analyze some costs and architecture feasibilities. 1.3 Modify some contents in section Analyze the business case, 1.2. Add and modify contents in architecture and process section 2, 3 and 4. Add one risk in feasibilities. Remove some section 5. defects from version 1.1, and add one potential risk. 1.4 Modify some contents in the section 3.2 and Modify the contents in section 5 and 3.3. Add some contents in section Modify the contents in section 2, 4 and Modify section 3.2 and 4. Add some contents in section Add contents in section 3.3. Modify the risks in section 5. Update section Modify the risk 3. Redraw the system structure and add more browsers in section Modify and add some risks in section 5. Add CR-29 and LOS Remove one risk in section 5. Modified contents in section 3&4. Remove some defects from version 1.3, and add more details in the section 3.2 and 3.3. We just briefly discuss two evolutionary requirements, but we did not have any further discussion. Introduce and list some NDI/NCSs in section Convert the calculation of ROI from hour to dollar in section 2. Modify some contents of table 8 in section 4. Raise the probability loss of risk 4 in section 5. Modify contents of section 3.2 and 4 to satisfy the SSRD. Add more NDI/NCS in section 6.1. Mapping the CR-22~CR-28 to evolutionary requirements. Put one risk to a solved risks table. Add contents in section 6. Change the description and rationale of risk 3. Add some browsers that widely used for most of the public. Modify contents of section 3.2 and 4 to satisfy the SSRD. Identify new risks. Feedback from RDCR ARB. FED_RDCP_S12b_T13_V4.1.doc ii Version Date: 02/15/12

3 Table of Contents Feasibility Evidence Description (FED)...i Version History... ii Table of Contents... iii Table of Tables...iv Table of Figures... v 1. Introduction Purpose of the FED Document Status of the FED Document Business Case Analysis Cost Analysis Benefit Analysis ROI Analysis Architecture Feasibility Level of Service Feasibility Capability Feasibility Evolutionary Feasibility Process Feasibility Risk Assessment NDI Interoperability Analysis Introduction System Structure Evaluation Summary FED_RDCP_S12b_T13_V4.1.doc iii Version Date: 02/15/12

4 Table of Tables Table 1: Personnel Costs... 2 Table 2: Hardware and Software Costs... 3 Table 3: Benefits of LACGIL System... 3 Table 4: ROI Analysis... 4 Table 5: Level of Service Feasibility... 5 Table 6: Capability Requirements and Their Feasibility Evidence... 5 Table 7: Evolutionary Requirements and Their Feasibility Evidence... 8 Table 8: Rationales for Selecting Architected Agile Model... 9 Table 9: Requirement Prioritization (Must Have Only)... 9 Table 10: Risk Assessment Table 11: NDI/NCS Products Listing Table 12: NDI/NCS Evaluation FED_RDCP_S12b_T13_V4.1.doc iv Version Date: 02/15/12

5 Table of Figures Figure 1: ROI Analysis Graph... 4 FED_RDCP_S12b_T13_V4.1.doc v Version Date: 02/15/12

6 1. Introduction 1.1 Purpose of the FED Document This document analyzes the feasibility of the future website. In section 2, we evaluate the business case including costs, benefits, and ROIs. It estimates the costs of personnel, hardware, and software, so the probability of loss could be reduced. We also analyze the feasibility of level of service, capability, evolutionary and process in section 3 and 4. Any feasibility will be reviewed in these two sections. In section 5, we identify some risks, rank them, and plan to mitigate these risks. In the last section, we compare some possible NDIs and NCSs, so we can choose the adequate COTS for the website. The FED document will provide us some evidences based on some analyses and evaluations; therefore, we could ensure the project s achievements. 1.2 Status of the FED Document - This version (4.1) belongs to Rebaselined Development Commitment Package. - The first version list some risks and mitigation plans in section 5, but we removed some risks which regards as issues in this project. However, it could be added some risks if the development team identified any risks. - We sort the risks (from high to low) to show the importance of the risks in section 5, so it is easier to identify the level of risks. - Some contents added to state the purpose and status of the FED document in section 1 of this version. - Analyze the business case, architecture and process feasibilities in section 2, 3 and 4. - List some NDIs and NCSs used in the system in section 6. FED_RDCP_S12b_T13_V4.1.doc 1 Version Date: 02/15/12

7 2. Business Case Analysis 2.1 Cost Analysis We provide the cost analysis of the project in personnel, hardware and software. It includes any possible costs to build the website. The detail cost will show at the table below Personnel Costs The personnel costs include the time effort of the client, user and maintainer of the project. The effort of the development team was not being considered. Table 1: Personnel Costs Activities Time Spent (Hours) Development Period (24 weeks) Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks) Client: Discussing via , phone, and other channels [3 hrs/week 36 * 12 weeks *1 person] Introduce community gardens and system requirements [2.5 hrs * time *1 person] WinWin negotiation session [1.5 hrs * 2 times *1 person] 3 Architecture Review Boards [2 hrs * 2 times * 1 person] 4 Development and Operation Phases: Time Invested (CS577b, 12 weeks) Client: Meeting via , phone, and other channels [2 hrs/week * weeks * 1 person] Architecture Review Boards and Core Capability Drive-through 4.5 session [1.5 hrs * 3 times * 1 person] Deployment of system in operation phase and training 22 - Installation & Deployment [6 hrs * 2 times * 1 person] - Training & Support [5 hrs * 2 times * 1 person] Total 96 Maintenance Period (1 year) Maintenance [2 hr/week * 52 weeks * 1 person] 104 Total 104 FED_RDCP_S12b_T13_V4.1.doc 2 Version Date: 02/15/12

8 2.1.2 Hardware and Software Costs Our client is in a non-profit organization. They do not have their dedicated server and a domain name for the new website. Besides, the development team will use academic license tools to build the system. Table 2: Hardware and Software Costs Type Cost Rationale Development Hardware Web Hosting $0 The development team would run the system at a free hosting server. Software Microsoft Visual Studio $0 Used in developing the system. The license is academic from school, so it will cost zero. Operation Hardware Web Hosting Hardware Web Domain name $60/year Although the LANLT already has its own host, this new system will not use the current server. It still to find a new hosting server, so it requires annual fee. This is a basic amount fee starting from spring $10/year Although the LANLT already has its own domain name, this new system will have a new domain name. 2.2 Benefit Analysis Easier to manage the database: the database manager will be easier to modify the data of gardens. Reduce the effort to generate reports of the gardens: easier to provide the gardens information report. Increase in the availability to the up-to-date information from the website: the newest information would provide by database manager. Easier to get the maps of the gardens form the website: the database managers will reduce effort to manage gardens on the maps. Table 3: Benefits of The Los Angeles Community Garden Inventory and Locator Current activities & resources used % Reduce Time Saved (Hours/Year) DB management Manager(4 organizations) (4 * 2.5 hr * 52 weeks) 80% 416 Output garden s information report Manager ( 1.5 hr * 52 weeks) 80% 38.4 FED_RDCP_S12b_T13_V4.1.doc 3 Version Date: 02/15/12

9 Mapping Manager ( 1 hr * 52 weeks) 60% 41.6 Total ROI Analysis The table below shows the cost and benefit of the website from 2012 to Further, we can see that the ROI is increasing from the ROI graph. Besides, we convert 1 hour to 30 dollars. Cost: Development period: 30 x 96 = 2880; Maintenance Period: 30 x 104 = Hardware/Software cost: 70. Benefit: 30 x 496 = Table 4: ROI Analysis Year Cost Benefit Cumulative Cumulative (Effort Saved) Cost Benefit ROI Figure 1: ROI Analysis Graph ROI FED_RDCP_S12b_T13_V4.1.doc 4 Version Date: 02/15/12

10 3. Architecture Feasibility 3.1 Level of Service Feasibility Table 5: Level of Service Feasibility Level of Service Requirement LOS-1: System Response Time LOS-2: System Security Product Satisfaction Product Strategies: Minimal required components and elements. Process Strategies: Benchmarking, Performance Analysis, Prototyping, Simulation. Analysis: With minimal components, the speed of transferring files could be faster and reduce the system response time. Product Strategies: Use hash to encrypt the password and coding to prevent SQL injection attack. Process Strategies: Security Analysis, Simulation. Analysis: Encrypt the passwords will prevent them being caught directly, and use security testing tools could easily find weaknesses and solve the problems. 3.2 Capability Feasibility Capability Requirement CR-1: Provide Web Interface to Database Accessible by Database Managers CR-2: Provide Web Interface to Database Accessible by End-Users Table 6: Capability Requirements and Their Feasibility Evidence Product Satisfaction Software/Technology used: HTML, ASP.NET, Javascript Feasibility Evidence: Use the ASP.NET programming language to query the SQL database. Provide database managers an easy used interface to manage the data in the website. Referred use case diagram: N/A Software/Technology used: HTML, ASP.NET, Javascript Feasibility Evidence: Use the ASP.NET programming language to query the SQL database. Provide users an easy way to access and view the data of gardens. Referred use case diagram: N/A CR-3: Login to the System Feasibility Evidence: Use the Login Control component to implement this function. The component provides login feature with authentication; thus, the administrator can manage the system. Referred use case diagram: UC-1 FED_RDCP_S12b_T13_V4.1.doc 5 Version Date: 02/15/12

11 CR-4: Logout of the System CR-5: View Garden Information CR-6: Sort Garden Information CR-7: Search Garden Information CR-8: Export Garden Information Feasibility Evidence: Use the Login Control component to implement the function. After login the system, the administrator can log out too. Referred use case diagram: UC-2 Feasibility Evidence: Use the Gridview component to implement the function. Provide a table to show the garden information for users. Referred use case diagram: UC-4 Feasibility Evidence: Use the Gridview component to implement the function. Provide user an easy way to sort columns by alphabet. Referred use case diagram: N/A Software/Technology used: SQL statement Feasibility Evidence: Use SQL SELECT statement to implement the function. Allow users to search the gardens and their information. Referred use case diagram: UC-3 Software/Technology used: SQL statement, ASP.NET Feasibility Evidence: Use SQL SELECT statement to query the database, and use itext/epplus to implement the export function. The database manager could generate garden report in pdf/xslx file. Referred use case diagram: UC-9 CR-9: Add Garden Record Software/Technology used: SQL statement Feasibility Evidence: Use SQL INSERT statement to implement the function. Allow database manager add new record of garden into the database. Referred use case diagram: UC-6 CR-10: Modify Garden Record CR-11: Delete Garden Record CR-12: Add Garden Table Column CR-13: Delete Garden Table Column Software/Technology used: SQL statement Feasibility Evidence: Use SQL UPDATE statement to implement the function. Allow database manager modify any fields of records in the database. Referred use case diagram: UC-8 Software/Technology used: SQL statement Feasibility Evidence: Use SQL DELETE statement to implement the function. Allow database manager delete any records of gardens. Referred use case diagram: UC-7 Software/Technology used: SQL statement Feasibility Evidence: Use SQL INSERT statement to implement the function. Provide the ability to extend the table in the database Referred use case diagram: UC-14 Software/Technology used: SQL statement Feasibility Evidence: Use SQL DELETE statement to implement the function. Provide the ability to delete the columns of a table in database. Referred use case diagram: UC-15 FED_RDCP_S12b_T13_V4.1.doc 6 Version Date: 02/15/12

12 CR-14: Add User CR-15: Modify User CR-16: Delete User CR-17: View Public Garden Information Available to End-Users CR-18: View Public Garden Information Map Available to End-Users CR-19: Search Public Garden Information Available to End-Users CR-20: View Public Garden Information Detail Available to End-Users CR-21: Download Garden Report for End-Users CR-22: View Public Garden Information with Pictures to End-Users CR-23: Log Changes to Database Records CR-24: View Database Log Software/Technology used: SQL statement Feasibility Evidence: Use SQL INSERT statement to implement the function. Allow the administrator to add new users. Referred use case diagram: UC-10 Software/Technology used: SQL statement Feasibility Evidence: Use SQL UPDATE statement to implement the function. Allow the administrator to modify the user accounts. Referred use case diagram: UC-12 Software/Technology used: SQL statement Feasibility Evidence: Use SQL DELETE statement to implement the function. Allow the administrator to delete the user accounts. Referred use case diagram: UC-11 Feasibility Evidence: Use the Gridview component to implement the function. Shows limited information of gardens to the public users. Referred use case diagram: UC-4 Software/Technology used: Google API Feasibility Evidence: Use the Google s maps API to implement the function. Provide public users to see the maps of gardens. Referred use case diagram: UC-3 Software/Technology used: SQL statement Feasibility Evidence: Use SQL SELECT statement to implement the function. Provide a feature to search the gardens for the public. Referred use case diagram: UC-3 Feasibility Evidence: Use the Gridview component to implement the function. Public users can only view some limited information. Referred use case diagram: UC-5 Software/Technology used: ASP.NET/Visual Studio, SQL statement Feasibility Evidence: Use SQL SELECT statement to query the database, and use itext and EPPlus to generate report in pdf and xlsx for user to download when they click the download button. Referred use case diagram: UC-13 Feasibility Evidence: Use Gridview component and bubble of google maps to display gardens pictures. Referred use case diagram: N/A Feasibility Evidence: Save any changes to the database when modifying records. Referred use case diagram: N/A Feasibility Evidence: Use the Gridview component to implement the function. Provide a table to view the changes of database. Referred use case diagram: UC-20 FED_RDCP_S12b_T13_V4.1.doc 7 Version Date: 02/15/12

13 CR-25: Add Picture to Garden Record CR-26: Delete Picture from Garden Record CR-27: View Pictures of Garden Record CR-28: View Garden Driving Direction Software/Technology used: ASP.NET/Visual Studio, SQL statement Feasibility Evidence: Use the Gridview component to implement the feature and add pictures URLs in the database. Referred use case diagram: UC-17 Software/Technology used: ASP.NET/Visual Studio, SQL statement Feasibility Evidence: Use the Gridview component to implement the feature and delete pictures URLs the database. Referred use case diagram: UC-18 Feasibility Evidence: Use the Gridview component to retrieve the pictures URLs of garden records in the database. Referred use case diagram: UC-19 Software/Technology used: Google API Feasibility Evidence: Use the Google s maps API to implement the function. Provide public users to find the driving direction of a selected garden. Referred use case diagram: UC Evolutionary Feasibility The two evolutionary requirements (ER-1 ~ ER-2) are also the capability requirements (CR-23 ~ CR-24), and table 7 is a mapping of these capability requirements. Table 7: Evolutionary Requirements and Their Feasibility Evidence Capability Requirement ER-1: (CR-23) Log Changes to Database Records ER-2: (CR-24) View Database Log Product Satisfaction Feasibility Evidence: Save any changes to the database when modifying records. Referred use case diagram: N/A Feasibility Evidence: Use the Gridview component to implement the function. Provide a table to view the changes of database. Referred use case diagram: N/A FED_RDCP_S12b_T13_V4.1.doc 8 Version Date: 02/15/12

14 4. Process Feasibility After exam the process decision table in the ICM-EPG website, the most suitable process of this project would be Architected Agile. Table 8: Rationales for Selecting Architected Agile Model Criteria Size, Complexity Change Rate % /Month Criticality NDI Support Org/Personnel Capability Key Stage I Activities : Incremental Definition Key Stage II Activities: Incremental Development, Operations Time per Build; Time per Increment Rationales The system size is medium and the data size is small. The website will have a map and information of the community gardens. The database manager could generate reports of the gardens, and the administrator could manage user accounts. Therefore, the complexity would be medium. If there are additional requirements or the client change his requirements, the prototype will also change. The change rate would not be high, because the development team was clarifying requirements in beginning phases. Criticality of the website would be medium to high. We have to develop the features with google maps and to generate pdf/xlsx report. We need some open source codes to implement the feature of generating report. The team members have some experiences to design and develop a website. Further, the website requires the google maps, but the developers are not familiar with its APIs. Valuation Commitment Reviews, Foundation Commitment Reviews, Development Commitment Review. Development/Rebase lined Development Reviews, Core Capability Drive-through, Transition Readiness/Operation Commitment Reviews. Time per Build would be 2-3 weeks, and Time per Increment would need 2-3 months. The development team has to make some documents for the project. Table 9: Requirement Prioritization Priority Requirements References Increment # M Sort Garden Information CR-6 1 M View Garden Information CR-5 1 M Add Garden Record CR-9 1 M Modify Garden Record CR-10 1 M Delete Garden Record CR-11 1 FED_RDCP_S12b_T13_V4.1.doc 9 Version Date: 02/15/12

15 M Login to the System CR-3 1 M Logout to the System CR-4 1 M Add User CR-14 1 M Delete User CR-16 1 M Modify User CR-15 1 M Provide Web Interface to Database Accessible by End-Users CR-2 1 M Provide Web Interface to Database Accessible by Database Managers CR-1 1 M View Public Garden Information Available to End- Users CR-17 2 M View Public Garden Information Map Available to End-Users CR-18 2 M Search Public Garden Information Available to End- Users CR-19 2 M View Public Garden Information Detail Available to End-Users CR-20 2 M Export Garden Information CR-8 2 M Search Garden Information CR-7 2 M Download Garden Report for End-Users CR-21 2 M Add Garden Table Column CR-12 2 M Delete Garden Table Column CR-13 2 S View Public Garden Information with Pictures to End-Users CR-22 2 C Add Picture to Garden Record CR-25 2 C Delete Picture from Garden Record CR-26 2 C View Pictures of Garden Record CR-27 2 C View Garden Driving Direction CR-28 2 W Log Changes to Database Records CR-23 3 W View Database Log CR-24 3 FED_RDCP_S12b_T13_V4.1.doc 10 Version Date: 02/15/12

16 5. Risk Assessment In this section of the Feasibility Evidence Document, the table below shows some potential risks of the system. We identified the risks and estimated their exposures. Further, we listed some plans to mitigate them. Table 10: Risk Assessment Risks 1. Coding collaboration The team members have to collaborate on coding the website. 2. System Environment The developing and testing platforms may not be the same as the actual environment of the website, so it may cause some unexpected problems. 3. Additional cost The system will be built in a new hosing server with a new domain name. Besides, it might have to buy paid components to achieve some features (for example, google spreadsheet-like gridview). 4. Backgrounds of new member. We lost three members, and one new member joined to our team. He may not have enough backgrounds of what we have done in the beginning. Risk Exposure Potential Probability Magnitude Loss Risk Exposure Risk Mitigations - Detailed document each changes and comments on the source code. - Synchronize the programs with a version control tool. - Find any hosting server that is the most close to the developing and testing platforms. - Carefully plan on how to test, and test the website in the actual system. - Find some open source code to achieve the required feature. - Discuss with the client of the potential costs and verify his budget. - Document fully and clearly, so he could quickly understand our goals and ready to develop the system. - Frequently communicate to clarify any uncertainties. Table 10.1: Solved Risks Risks 1. Unfamiliar with Google Maps API Team members have no experiences using Google maps API in developing a web site, so we might have some problems occur when developing. Risk Exposure Potential Probability Magnitude Loss Risk Exposure Risk Mitigations - Find some books or online resources about Google maps API. - Ask some friends who have ever developed a system with Google maps. FED_RDCP_S12b_T13_V4.1.doc 11 Version Date: 02/15/12

17 6. NDI/NCS Interoperability Analysis 6.1 Introduction The website will have a map for the public to search community gardens and find some information about these gardens, so we will compare the widely used Google maps and Microsoft Bing maps. Besides, it is a web-based system, so the platform will be a server side platform. We consider the PHP with MySQL database in an apache server, or an ASP.NET with Microsoft SQL Server in IIS. After the team compared between the NDIs / NCSs, we decided to use the ASP.NET with Microsoft SQL Server. We use the Google maps and some free libraries to implement the function of generating reports COTS / GOTS / ROTS / Open Source / NCS We list some NDIs / NCSs we used in the table below and briefly describe their purposes. Table 11: NDI/NCS Products Listing NDI/NCS Products ASP.NET Microsoft.NET Framework Microsoft Visual Studio 2010 Microsoft SQL Server 2008 Internet Information Services (IIS) Google maps itext EPPlus Microsoft Internet Explorer 9.0 Mozilla Firefox 8.0 Google Chrome 15.0 Apple Safari 5.1 Microsoft SqlMetal Purposes The server-side programming language to build the website. A framework that provides some libraries to create the applications on the windows platform. The tool used in developing the system. A database to store data for the website. The web service of the server. It is an interactive map that shows the map and any information. The library to implement the function of generating pdf files. The library to implement the function of generating xlsx files. Show the contents of the website. Show the contents of the website. Show the contents of the website. Show the contents of the website. Create database and data access layer FED_RDCP_S12b_T13_V4.1.doc 12 Version Date: 02/15/12

18 6.1.2 Connectors The system will be built with ASP.NET and SQL Server. Therefore, the connector between these two is the Microsoft ODBC Connector Legacy System The system does not have any legacy system. 6.2 System Structure 6.3 Evaluation Summary The table 11 lists some the NDI and NCS that we are going to use, and it provides the positive and negative points of each NDI/NCS. FED_RDCP_S12b_T13_V4.1.doc 13 Version Date: 02/15/12

19 Table 12: NDI/NDS Evaluation NDI/NCS Usages Comments ASP.NET Programming language Positive Points: -Very widely used. -Online MSDN support. -Fully compatible with SQL server. -Team members are familiar with. Microsoft.NET Framework Microsoft Visual Studio 2010 Microsoft SQL Server 2008 Internet Information Services (IIS) Framework Developing tool Database Web server service -No negative points. Positive Points: -Provide many libraries. -No negative points Positive Points: -Easily to use. -Team members are familiar with. -It is a licensed software. Positive Points: -Widely used. -Fast and flexible. -Stable and easily manage. -It is a licensed database server. Positive Points: - Commonly used. -Usually have to pay for the server. Google maps Interactive map Positive Points: -Most widely used. -Free and easily accessed -No negative points itext EPPlus Microsoft Internet Explorer 9.0 Library of generating pdf file Library of generating xlsx file Web Browser Positive Points: -Free -No negative points Positive Points: -Free -Ability to put pictures in the header and footer. -No negative points Positive Points: -Default browser of Windows OS. FED_RDCP_S12b_T13_V4.1.doc 14 Version Date: 02/15/12

20 -Highly supported. - No negative points Mozilla Firefox 8.0 Web Browser Positive Points: -Fast and widely used. -No negative points Google Chrome 15.0 Web Browser Positive Points: -Fast and widely used. -No negative points Apple Safari 5.1 Web Browser Positive Points: -Default browser of Macintosh OS. -No negative points Microsoft SqlMetal Database tool Positive Points: -Easily generate classes. -Not easy to customize the classes. FED_RDCP_S12b_T13_V4.1.doc 15 Version Date: 02/15/12