Feasibility Evidence Description (FED)
The Los Angeles Community Garden Inventory and Locator
Team 13
Ardalan Yousefi – Project Manager Cole Cecil – Integrated Independent Verification & Validation Jeff Tonkovich – Implementer Shi-Xuan Zeng – Tester
February 03, 2012
i Feasibility Evidence Description (FED) for Architected Agile Version 4.0
Version History Date Author Versio Changes made Rationale n 09/19/11 SHI-XUAN 0.1 Update section 5—Risk Identify the risks and mitigation ZENG assessment plans. 10/05/11 SHI-XUAN 1.0 Modify section 5—Risk Remove some risks that regard ZENG assessment as issues. Sort the risks to reflect the importance of the risks. 10/06/11 SHI-XUAN 1.1 Add contents in section 1. State the purpose and status in ZENG section 1. 10/10/11 SHI-XUAN 1.2 Add contents in section 2 and 3. Analyze some costs and ZENG architecture feasibilities. 10/13/11 SHI-XUAN 1.3 Modify some contents in section Analyze the business case, ZENG 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. 10/17/11 SHI-XUAN 1.4 Modify some contents in the Remove some defects from ZENG section 3.2 and 3.3 version 1.3, and add more details in the section 3.2 and 3.3. 10/20/11 SHI-XUAN 1.5 Modify the contents in section 5 We just briefly discuss two ZENG and 3.3. Add some contents in evolutionary requirements, but section 6.1.1. we did not have any further discussion. Introduce and list some NDI/NCSs in section 6.1.1. 10/24/11 SHI-XUAN 2.0 Modify the contents in section 2, Convert the calculation of ROI ZENG 4 and 5. 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. 11/16/11 SHI-XUAN 3.0 Modify section 3.2 and 4. Add Modify contents of section 3.2 ZENG some contents in section 6.1. and 4 to satisfy the SSRD. Add more NDI/NCS in section 6.1. 12/01/11 SHI-XUAN 3.1 Add contents in section 3.3. Mapping the CR-22~CR-28 to ZENG Modify the risks in section 5. evolutionary requirements. Put Update section 6. one risk to a solved risks table. Add contents in section 6. 12/03/11 SHI-XUAN 3.2 Modify the risk 3. Redraw the Change the description and ZENG system structure and add more rationale of risk 3. Add some browsers in section 6. browsers that widely used for most of the public. 02/03/12 SHI-XUAN 4.0 Modify and add some risks in Modify contents of section 3.2 ZENG section 5. Add CR-29 and LOS-2. and 4 to satisfy the SSRD. Identify new risks.
087ee5bc6158712edd3da5d38b60b2ee.doc ii Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0 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...... 1 1.1 Purpose of the FED Document...... 1 1.2 Status of the FED Document...... 1 2. Business Case Analysis...... 2 2.1 Cost Analysis...... 2 2.2 Benefit Analysis...... 3 2.3 ROI Analysis...... 4 3. Architecture Feasibility...... 5 3.1 Level of Service Feasibility...... 5 3.2 Capability Feasibility...... 5 3.3 Evolutionary Feasibility...... 8 4. Process Feasibility...... 10 5. Risk Assessment...... 12 6. NDI Interoperability Analysis...... 14 6.1 Introduction...... 14 6.2 System Structure...... 15 6.3 Evaluation Summary...... 15
087ee5bc6158712edd3da5d38b60b2ee.doc iii Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
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...... 11 Table 11: NDI/NCS Products Listing...... 12 Table 12: NDI/NCS Evaluation...... 14
087ee5bc6158712edd3da5d38b60b2ee.doc iv Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
Table of Figures
Figure 1: ROI Analysis Graph...... 4
087ee5bc6158712edd3da5d38b60b2ee.doc v Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
A.1. Introduction A.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. A.1.2 Status of the FED Document - This version (4.0) belongs to Draft 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.
087ee5bc6158712edd3da5d38b60b2ee.doc 1 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
A.2. Business Case Analysis A.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.
.2.1.1 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 email, phone, and other channels [3 hrs/week 36 * 12 weeks *1 person] Introduce community gardens and system requirements [2.5 hrs * 1 2.5 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 email, phone, and other channels [2 hrs/week * 24 12 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
087ee5bc6158712edd3da5d38b60b2ee.doc 2 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0 .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 $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 2012. Hardware – Web Domain name $10/year Although the LANLT already has its own domain name, this new system will have a new domain name.
A.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 80% 416 weeks) Output garden’s information report Manager ( 1.5 hr * 52 weeks) 80% 38.4
087ee5bc6158712edd3da5d38b60b2ee.doc 3 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
Mapping Manager ( 1 hr * 52 weeks) 60% 41.6 Total 496 A.2.3 ROI Analysis
The table below shows the cost and benefit of the website from 2012 to 2016. 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 = 3120. Hardware/Software cost: 70. Benefit: 30 x 496 = 14880.
Table 4: ROI Analysis
Benefit Cumulative Cumulative Year Cost ROI (Effort Saved) Cost Benefit 2012 2880 0 2880 0 -1.000 2013 3190 14880 6070 14880 1.451 2014 3190 14880 9260 29760 2.214 2015 3190 14880 12450 44640 2.586 2016 3190 14880 15640 59520 2.806
Figure 1: ROI Analysis Graph
3.2 2.8 2.4 2 1.6 1.2 ROI 0.8 0.4 0 -0.4 2012 2013 2014 2015 2016 -0.8 -1.2
087ee5bc6158712edd3da5d38b60b2ee.doc 4 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
A.3. Architecture Feasibility A.3.1 Level of Service Feasibility
Table 5: Level of Service Feasibility
Level of Service Requirement Product Satisfaction LOS-1: System Response Time 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. LOS-2: System Security 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.
A.3.2 Capability Feasibility
Table 6: Capability Requirements and Their Feasibility Evidence
Capability Requirement Product Satisfaction CR-1: Provide Web Software/Technology used: HTML, ASP.NET, Javascript Interface to Database Feasibility Evidence: Use the ASP.NET programming language to Accessible by Database query the SQL database. Provide database managers an easy used Managers interface to manage the data in the website. Referred use case diagram: N/A CR-2: Provide Web Software/Technology used: HTML, ASP.NET, Javascript Interface to Database Feasibility Evidence: Use the ASP.NET programming language to Accessible by End-Users 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 Software/Technology used: ASP.NET / Visual Studio 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
087ee5bc6158712edd3da5d38b60b2ee.doc 5 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
CR-4: Logout of the Software/Technology used: ASP.NET / Visual Studio System 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 CR-5: View Garden Software/Technology used: ASP.NET / Visual Studio Information 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 CR-6: Sort Garden Software/Technology used: ASP.NET / Visual Studio Information 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 CR-7: Search Garden Software/Technology used: SQL statement Information 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 CR-8: Export Garden Software/Technology used: SQL statement, ASP.NET Information 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 Software/Technology used: SQL statement Record 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 CR-11: Delete Garden Software/Technology used: SQL statement Record Feasibility Evidence: Use SQL DELETE statement to implement the function. Allow database manager delete any records of gardens. Referred use case diagram: UC-7 CR-12: Add Garden Table Software/Technology used: SQL statement Column Feasibility Evidence: Use SQL INSERT statement to implement the function. Provide the ability to extend the table in the database Referred use case diagram: N/A CR-13: Delete Garden Software/Technology used: SQL statement Table Column 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: N/A
087ee5bc6158712edd3da5d38b60b2ee.doc 6 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
CR-14: Add User 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 CR-15: Modify User 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: N/A CR-16: Delete User 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 CR-17: View Public Software/Technology used: ASP.NET / Visual Studio Garden Information Feasibility Evidence: Use the Gridview component to implement the Available to End-Users function. Shows limited information of gardens to the public users. Referred use case diagram: UC-4 CR-18: View Public Software/Technology used: Google API Garden Information Map Feasibility Evidence: Use the Google’s maps API to implement the Available to End-Users function. Provide public users to see the maps of gardens. Referred use case diagram: UC-3 CR-19: Search Public Software/Technology used: SQL statement Garden Information Feasibility Evidence: Use SQL SELECT statement to implement the Available to End-Users function. Provide a feature to search the gardens for the public. Referred use case diagram: UC-3 CR-20: View Public Software/Technology used: ASP.NET / Visual Studio Garden Information Detail Feasibility Evidence: Use the Gridview component to implement the Available to End-Users function. Public users can only view some limited information. Referred use case diagram: UC-5 CR-21: Download Garden Software/Technology used: ASP.NET/Visual Studio, SQL statement Report for End-Users 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: N/A CR-22: View Public Software/Technology used: ASP.NET / Visual Studio Garden Information with Feasibility Evidence: Use the Gridview component and provide Pictures to End-Users links to implement the function of displaying gardens’ pictures. Referred use case diagram: N/A CR-23: Weekly Backup of Software/Technology used: ASP.NET / Visual Studio the System Database Feasibility Evidence: Automatically generate reports to back up the database or use the backup service of hosting server. Referred use case diagram: N/A CR-24: Log Changes to Software/Technology used: ASP.NET / Visual Studio Database Records Feasibility Evidence: Save any changes to the database when modifying records. Referred use case diagram: N/A
087ee5bc6158712edd3da5d38b60b2ee.doc 7 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
CR-25: View Database Software/Technology used: ASP.NET / Visual Studio Log 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 CR-26: Add Picture to Software/Technology used: ASP.NET/Visual Studio, SQL statement Garden Record Feasibility Evidence: Provide a function to upload pictures and save the link in the database. Referred use case diagram: N/A CR-27: Delete Picture Software/Technology used: ASP.NET/Visual Studio, SQL statement from Garden Record Feasibility Evidence: Use the Gridview component to implement the function and delete the link in the database. Referred use case diagram: N/A CR-28: View Pictures of Software/Technology used: ASP.NET / Visual Studio Garden Record Feasibility Evidence: Use the Gridview component to retrieve the pictures of garden records in the database. Referred use case diagram: N/A CR-29: View Garden Software/Technology used: Google API Driving Direction 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: N/A
A.3.3 Evolutionary Feasibility
The eight evolutionary requirements (ER-1 ~ ER-8) are also the capability requirements (CR-22 ~ CR-29), so table 7 is a mapping of these capability requirements.
Table 7: Evolutionary Requirements and Their Feasibility Evidence
Capability Requirement Product Satisfaction ER-1: (CR-22) View Software/Technology used: ASP.NET / Visual Studio Public Garden Information Feasibility Evidence: Use the Gridview component and provide with Pictures to End-Users links to implement the function of displaying gardens’ pictures. Referred use case diagram: N/A ER-2: (CR-23) Weekly Software/Technology used: ASP.NET / Visual Studio Backup of the System Feasibility Evidence: Automatically generate reports to back the Database database. Referred use case diagram: N/A ER-3: (CR-24) Log Software/Technology used: ASP.NET / Visual Studio Changes to Database Feasibility Evidence: Save any changes to the database when Records modifying records. Referred use case diagram: N/A
087ee5bc6158712edd3da5d38b60b2ee.doc 8 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
ER-4: (CR-25) View Software/Technology used: ASP.NET / Visual Studio Database Log 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 ER-5: (CR-26) Add Software/Technology used: ASP.NET/Visual Studio, SQL statement Picture to Garden Record Feasibility Evidence: Provide a function to upload pictures and save the link in the database. Referred use case diagram: N/A ER-6: (CR-27) Delete Software/Technology used: ASP.NET/Visual Studio, SQL statement Picture from Garden Feasibility Evidence: Use the Gridview component to implement the Record function and delete the link in the database. Referred use case diagram: N/A ER-7: (CR-28) View Software/Technology used: ASP.NET / Visual Studio Pictures of Garden Record Feasibility Evidence: Use the Gridview component to retrieve the pictures of garden records in the database. Referred use case diagram: N/A ER-8: (CR-29) View Software/Technology used: Google API Garden Driving Direction 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: N/A
087ee5bc6158712edd3da5d38b60b2ee.doc 9 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
A.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 Rationales Size, Complexity 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. Change Rate % /Month 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 Criticality of the website would be medium to high. We have to develop the features with google maps and to generate pdf/xlsx report. NDI Support We need some open source codes to implement the feature of generating report. Org/Personnel Capability 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. Key Stage I Activities : Valuation Commitment Reviews, Incremental Definition Foundation Commitment Reviews, Development Commitment Review. Key Stage II Activities: Development/Rebase lined Development Reviews, Incremental Development, Core Capability Drive-through, Operations Transition Readiness/Operation Commitment Reviews. Time per Build; Time per Build would be 2-3 weeks, and Time per Increment 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
087ee5bc6158712edd3da5d38b60b2ee.doc 10 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
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 Provide Web Interface to Database Accessible by M CR-2 1 End-Users Provide Web Interface to Database Accessible by M CR-1 1 Database Managers View Public Garden Information Available to End- M CR-17 2 Users View Public Garden Information Map Available to M CR-18 2 End-Users Search Public Garden Information Available to End- M CR-19 2 Users View Public Garden Information Detail Available to M CR-20 2 End-Users 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 View Public Garden Information with Pictures to S CR-22 3 End-Users S Add Picture to Garden Record CR-26 3 S Delete Picture from Garden Record CR-27 3 S View Pictures of Garden Record CR-28 3 W Weekly Backup of the System Database CR-23 3 C View Garden Driving Direction CR-29 3 C Log Changes to Database Records CR-24 3 C View Database Log CR-25 3
087ee5bc6158712edd3da5d38b60b2ee.doc 11 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
A.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
Risk Exposure Risks Potential Probability Risk Risk Mitigations Magnitude Loss Exposure 1. Ability to maintain the - The organization has a web system developer with contrast, so the client The current system is built in might ask that developer to maintain FreeBSD, apache and MySQL. the prospect system. It’s hard to maintain for our client 8 9 72 - Find someone who has the ability to since there are no IT department. maintain the system in the four organizations. - Detailed document all the manuals and provide well-planed training. 2. Coding collaboration - Detailed document each changes The team members have to and comments on the source code. 8 7 56 collaborate on coding the website. - Synchronize the programs with a version control tool. 3. System Environment - Find any hosting server that is the The developing and testing most close to the developing and platforms may not be the same as 7 7 49 testing platforms. the actual environment of the - Carefully plan on how to test, and website, so it may cause some test the website in the actual system. unexpected problems. 4. Additional cost The system will be built in a new - Find some open source code to hosing server with a new domain achieve the required feature. name. Besides, it might have to 8 5 40 - Discuss with the client of the buy paid components to achieve potential costs and verify his budget. some features (for example, google spreadsheet-like gridview). 5. Backgrounds of new member. - Document fully and clearly, so he We lost three members, and one could quickly understand our goals new member joined to our team. 7 2 14 and ready to develop the system. He may not have enough - Frequently communicate to clarify backgrounds of what we have any uncertainties. done in the beginning.
087ee5bc6158712edd3da5d38b60b2ee.doc 12 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
Table 10.1: Solved Risks
Risk Exposure Risks Potential Probability Risk Risk Mitigations Magnitude Loss Exposure 1. Unfamiliar with Google Maps API - Find some books or online Team members have no resources about Google maps API. experiences using Google maps 9 5 45 - Ask some friends who have ever API in developing a web site, so developed a system with Google we might have some problems maps. occur when developing.
087ee5bc6158712edd3da5d38b60b2ee.doc 13 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
A.6. NDI/NCS Interoperability Analysis A.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.
.6.1.1 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 Purposes ASP.NET The server-side programming language to build the website. Microsoft .NET Framework A framework that provides some libraries to create the applications on the windows platform. Microsoft Visual Studio 2010 The tool used in developing the system. Microsoft SQL Server 2008 A database to store data for the website. Internet Information Services (IIS) The web service of the server. Google maps It is an interactive map that shows the map and any information. iText The library to implement the function of generating pdf files. EPPlus The library to implement the function of generating xlsx files. Microsoft Internet Explorer 9.0 Show the contents of the website. Mozilla Firefox 8.0 Show the contents of the website. Google Chrome 15.0 Show the contents of the website. Apple Safari 5.1 Show the contents of the website. Microsoft SqlMetal Create database and data access layer
087ee5bc6158712edd3da5d38b60b2ee.doc 14 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0 .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.
.6.1.3 Legacy System
The system does not have any legacy system. A.6.2 System Structure
A.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.
087ee5bc6158712edd3da5d38b60b2ee.doc 15 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
Table 12: NDI/NDS Evaluation
NDI/NCS Usages Comments ASP.NET Programming Positive Points: language -Very widely used. -Online MSDN support. -Fully compatible with SQL server. -Team members are familiar with. Negative Points: -No negative points. Microsoft .NET Framework Positive Points: Framework -Provide many libraries. Negative Points: -No negative points Microsoft Visual Studio Developing tool Positive Points: 2010 -Easily to use. -Team members are familiar with. Negative Points: -It is a licensed software. Microsoft SQL Server Database Positive Points: 2008 -Widely used. -Fast and flexible. -Stable and easily manage. Negative Points: -It is a licensed database server. Internet Information Web server service Positive Points: Services (IIS) - Commonly used. Negative Points: -Usually have to pay for the server. Google maps Interactive map Positive Points: -Most widely used. -Free and easily accessed Negative Points: -No negative points iText Library of generating Positive Points: pdf file -Free Negative Points: -No negative points EPPlus Library of generating Positive Points: xlsx file -Free -Ability to put pictures in the header and footer. Negative Points: -No negative points Microsoft Internet Web Browser Positive Points: Explorer 9.0 -Default browser of Windows OS.
087ee5bc6158712edd3da5d38b60b2ee.doc 16 Version Date: 02/03/12 Feasibility Evidence Description (FED) for Architected Agile Version 4.0
-Highly supported. Negative Points: - No negative points Mozilla Firefox 8.0 Web Browser Positive Points: -Fast and widely used. Negative Points: -No negative points Google Chrome 15.0 Web Browser Positive Points: -Fast and widely used. Negative Points: -No negative points Apple Safari 5.1 Web Browser Positive Points: -Default browser of Macintosh OS. Negative Points: -No negative points Microsoft SqlMetal Database tool Positive Points: -Easily generate classes. Negative Points: -Not easy to customize the classes.
087ee5bc6158712edd3da5d38b60b2ee.doc 17 Version Date: 02/03/12