Feasibility Evidence Description (FED)

Size: px

Start display at page:

Download "Feasibility Evidence Description (FED)"

Amos Anthony
5 years ago
Views:

1 Feasibility Evidence Description (FED) United Direct Marketing Team 9 Fall Semester Chun-Ling Chen Project manager/ Prototyper Chun-Pei Su Lifecycle Planner Shao-yen Cheng System Architect Yuan-Chang Chang Feasibility Analyst Stewart Allen IIV&V/ Requirements Engineer Yen-Kuo Kao Operational Concept Engineer Spring Semester Chun-Pei Su Trainer / Document Maintainer Shao-yen Cheng Chief Developer Stewart Allen Tester / IIV&V / Quality Focal Point Kelvin Zhu Project Manager / Developer March 29, 2013 FED_FCP_S13b_T09_V5.0.doc i

2 Version History Date Author Version Changes made Rationale 10/03/12 10/04/12 10/09/12 10/22/12 10/22/12 11/15/12 11/24/12 12/2/12 Yuan Chang Chang Shao Yen Cheng Yuan Chang Chang Yuan Chang Chang Shao Yen Cheng Yuan Chang Chang Yuan Chang Chang Yuan Chang Chang 1.0 Update section 5:Risk Assessment 1.1 Correct information on header and footer sections. 1.2 Update section 5:Risk Assessment Add contents in section Add contents in section 2,3,4 2.1 Section 1.2, footer and header /27/13 Kelvin Zhu 3.2 2/20/13 Kelvin Zhu 4.0 Update section 5:Risk Update section 2:business case analysis Update section 4:Process Feasibility Add contents in section 6 Update section 2:business case Correct the bugs in section 6. Update the risks in section 5 Fixed spelling and grammar typos throughout document Updated team member list with members from Spring semester Rearranged sections to match Single NDI template (4>2, 5>3, 6&3>4, 2>5) Created Section 6 Updated Section 2 with new Process Feasibility values and rationales Added Section 5.1: Market Trend and Product Line Analysis 3/29/13 Chun-Pei Su 5.0 Fixed some defects and errors through all sections Identify the risks and mitigation plans Delete legacy information from the template file and correct version numbers. Correct reported errors and vague points in risk assessment section and add new contents in section 1 Add business case study, capability feasibility and evaluate the best developing process, Update the document status and correct typos. Correct defects and update risks Add content and correct reported defects. Correct the bugs and update the risks. Correcting typos Updating with new team roster Updating document to reflect change from Architected Agile to Single NDI Satisfied the IOC#1 exit criteria FED_FCP_S13b_T09_V5.0.doc ii

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 Process Feasibility Risk Assessment NDI/NCS Feasibility Analysis Assessment Approach Assessment Results Evaluation Summary Feasibility Evidence Capability Feasibility Evolutionary Feasibility Business Case Analysis Market Trend and Product Line Analysis Cost Analysis Benefit Analysis ROI Analysis Conclusion and Recommendations FED_FCP_S13b_T09_V5.0.doc iii

4 Table of Tables Table 1: Rationales for Selecting Single NDI Model... 3 Table 2: Risk Assessment... 6 Table 3: NDI/NCS Products Listing... 7 Table 4: NDI/NCS Evaluation... 8 Table 5: Level of Service Feasibility... 9 Table 6: Capability Requirements and Their Feasibility Evidence... 9 Table 7: Market Trend and Product Line Analysis Table 8: Personnel Costs Table 9: Hardware and Software Costs Table 10: Benefits of UDI System Table 11: ROI Analysis FED_FCP_S13b_T09_V5.0.doc iv

5 Table of Figures Figure 1: ROI Analysis Graph FED_FCP_S13b_T09_V5.0.doc v

6 1. Introduction 1.1 Purpose of the FED Document This document is to analyze the feasibility of this project. In section 2, we provide a business case study including analysis of cost, benefit, and ROI to evaluate its market value so that we can decide whether it is worthwhile to make or not. In section 3 and 4, we go into the analysis of the level of service, capability, evolution, and process. This document evaluates the feasibility of the functions that we would implement and helps us prioritize the implementing order. In section 5, we provide risk assessment, a list of the potential risk, rank, and a mitigation plan. In the last section, we list the NDI s and NCS s that we might use in this project and briefly describe their use. The FED document is a report for us to evaluate the risk of the whole project. We can adjust our development plan in advance according to it, assuring its success. 1.2 Status of the FED Document - This version (5.0) belongs to Development Commitment Package, and has been updated with our change from the Architected Agile methodology to the Single NDI methodology. FED_FCP_S13b_T09_V5.0.doc 1

7 2. Process Feasibility From the process evaluation website, the most suitable process for this project would be architected Agile. Importance Rating Scale: How importance is this criteria for this project? 1 (Low), 2 (Medium) and 3 (High) Criteria Rating Scale: How likely the given criteria fits the project? 0 (Very Low),1 (Low),2 (Medium),3 (High) and 4 (Very High) FED_FCP_S13b_T09_V5.0.doc 2

8 Table 1: Rationales for Selecting Single NDI Model Criteria Rationales 30 % of NDI/NCS features Part of this project will be built by NDI to speed up the development process. Single NDI/NCS Using just one NDI/NCS simplifies the interoperability aspect. However, whether we use one NDI/NCS or multiple is optional. Unique/ inflexible business process Need control over upgrade / maintenance Rapid deployment Critical on compatibility Very few functions of the website are unique. The client must be able to handle the maintenance of the website herself so control over upgrading and maintenance of the site is of high priority. The website and the information on it should be deployed rapidly, assuring its customers are able to receive latest information. It must be a cross browser website as the customers will use different browsers to surf the website. Internet connection independence Need high level of services / performance Need high security Asynchronous communication Be accessed from anywhere Critical on mass schedule constraints Lack of personnel capability Require little upfront costs Require low total cost of ownership Not-so-powerful local machines There is no need for internet independence, as the system to be developed is an online CMS. While support for higher performance is nice, there are no features in the CMS that inherently require high performance. Need electronic signature mechanism. It involves several security issues. It doesn t need a real time communication function. Its customers come from all over the world. The project should be completed within the two semester time of the CSCI 577 class. It s a small company with only a few people, many of which have limited technical expertise. Its budget is very limited, so has to be built with minimal cost. The budget for the project is limited, so continued cost over time must be low.. Local machines are basic laptops/desktops. FED_FCP_S13b_T09_V5.0.doc 3

9 FED_FCP_S13b_T09_V5.0.doc 4

It would be best to follow the Single NDI process for the

10 The Single NDI process has only two non-conforming points, which is lower than any others. It would be best to follow the Single NDI process for the benefits of improved speed of development without sacrificing compatibility. FED_FCP_S13b_T09_V5.0.doc 5

11 3. Risk Assessment Table 2: Risk Assessment Risks The person who implements the website might not take 577b next semester. It would take extra time for others to take over it. The interface designer is not a member of our team. The designer may not be able to deliver her product in time, which may delay the whole project. Our current project is running on our member s own host. It hasn t been tested on our client s host or a test server outside. Failure of transferring it to other host may occur in the next semester. The database size of our client s server is very limited and would not be enough to contain all the data of this project. To increase the size, our client would need to pay more to the database company. Risk Exposure Potential Probability Risk Risk Mitigations Magnitude Loss Exposure The people who would take 577b should be familiar with the code as well Develop the capability first. After the designer finishes it, we integrate it into our project Transfer it to a test server as soon as possible. We will fully test it on a test server then transfer it to our client s server Notify our client of this problem. Our client can choose to either pay more to upgrade the size or change to another company with a larger free database size. FED_FCP_S13b_T09_V5.0.doc 6

12 4. NDI/NCS Feasibility Analysis 4.1 Assessment Approach We originally considered ourselves as using an Architected Agile approach. However, during semester of work on the UDM website, it became clear that our usage of the Fuel CMS system was actually closer to a Single NDI approach than an Architected Agile approach as we were using the Fuel NDI to handle some of the major functionality for us such as the user accounts, templating system, and CMS functionality. Due to this change happening in the middle of the development phase when we already had a portion of the features developed in Fuel, we did not go through an assessment of NDI alternatives and instead chose to remain with our initial NDI choice. 4.2 Assessment Results NDI/NCS Candidate Components (Combinations) Table 3: NDI/NCS Products Listing NDI/NCS Products PHP MYSQL database CodeIgniter Framework Fuel Microsoft Internet Explorer 9.0 Mozilla Firefox 8.0 Google Chrome 15.0 Purposes The server-side programming language to build the website. The database used to store users information. A framework that is useful for us to develop the website. Fuel is a CMS that utilizes the CodeIgniter framework and already implements lots of manager interface for users to use. This leaves us with only custom sections to implement. Show the contents of the website. Show the contents of the website. Show the contents of the website Connectors The system will be built with PHP and SQL Server. Therefore, the connector between these two is the ODBC Connector Legacy System The system does not have any legacy system. FED_FCP_S13b_T09_V5.0.doc 7

13 4.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. PHP Table 4: NDI/NCS Evaluation NDI/NCS Usages Comments Programming language Positive Points: -Very widely used. -Fully compatible with SQL server. -Team members are familiar with. Negative Points: -No negative points. MYSQL database Developing tool Positive Points: - Easy to use. -Team members are familiar with.. Negative Points: -No negative points CodeIgniter Framework Framework Positive Points: -Very widely used. -Provides powerful libraries to use Negative Points: -Not all team members are familiar with it. Fuel CMS, Blog Positive Points: -Provides powerful CMS interface ready to use. -FUEL is integrated with CodeIgnitor -FUEL has a number of capabilities that fit to our requirements so that we don t need to develop everything from scratch. Negative Points: -Lack of experience using it. Microsoft Internet Explorer 9.0 Web Browser Positive Points: -Default browser of Windows OS. -Highly supported. Negative Points: - No negative points Mozilla Firefox 8.0 Web Browser Positive Points: FED_FCP_S13b_T09_V5.0.doc 8

14 -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 4.4 Feasibility Evidence Level of Service Feasibility Table 5: Level of Service Feasibility Level of Service Requirement LOS-1: Compatible to the browsers used by the majority of users. Product Satisfaction Product Strategies: Focus on the major browsers that users in this domain use to view the website. Process Strategies: Use as much of cross-template programming language as possible. Test this project on the major browsers. Analysis: The major browsers used by users in this domain are Chrome, IE8 and IE9. Our team has related experience on these browsers. 4.5 Capability Feasibility Table 6: Capability Requirements and Their Feasibility Evidence Capability Requirement UC-1: User Login UC-2: User Logout UC-3: Create marketing director account UC-4: Delete marketing Product Satisfaction Feasibility Evidence: Store the account and password in the database in advance. Every time users try to login, validate them with the stored information. Software/Technology used: HTML, Javascript, PHP Feasibility Evidence: We can use session to record user s login state. To logout, just mark the session state to logout. Feasibility Evidence: Use SQL statement insert into to add an account. : FED_FCP_S13b_T09_V5.0.doc 9

15 director account UC-5: View marketing director accounts UC-6: Create micro website UC-7: Edit Micro Website UC-8: Delete Micro Website UC-9: List Micro Websites and hit rates UC-10: View micro website UC-11: Viewing a package illustration on a micro website UC-12: Viewing case studies on a micro website UC-13: micro website link UC-14: Edit website content Feasibility Evidence: Use SQL statement delete to delete an account. Feasibility Evidence: Use SQL statement select * from tablename to view director accounts in table. Feasibility Evidence: Use SQL statement to retrieve the related user information and show it in HTML. Feasibility Evidence: Use SQL statement update to edit the data stored in the database. Feasibility Evidence: Use SQL statement delete to delete the data stored in the database. Feasibility Evidence: Retrieve users information in the database and show them as a list of micro websites. Furthermore, to implement the hit counter, we leave a column in table to store this information which would increase each time when users click on the button linking to their own micro website. Feasibility Evidence: Retrieve user information from the database and show them in micro website form. Feasibility Evidence: Upload the proposal to the database and relate it to the corresponding micro website. Feasibility Evidence: Upload the case studies to the database and relate them to the corresponding micro website. Software/Technology used: , HTML, Javascript Feasibility Evidence: Create a button to send the containing the micro website link. Feasibility Evidence: Store website content in the database, which makes it editable by administrator. FED_FCP_S13b_T09_V5.0.doc 10

16 UC-15: Attaching files to the website content UC-16: View proposal UC-17: Comment proposal UC-18: Sign an electronic signature on a proposal UC-19: Confirm electronic signature UC-21: Search the content of the website Feasibility Evidence: Create a uploading section for administrator to upload their files, and bind these files to the place they want to put.. Software/Technology used: HTML Feasibility Evidence: Incorporating the proposal link into the micro website. Feasibility Evidence: Build proposal table in the database to manage the files and leave a column to store the comments relating to it. Software/Technology used: RSA Feasibility Evidence: Users generate their own private key to sign their proposals and give their public key to the website to validate their signature. Software/Technology used: RSA Feasibility Evidence: The website manages users public key. When users upload their files to the website, the website validate their signature with the public key. Feasibility Evidence: We can create a table to store all the website content. When we do search, we can just search this table. 4.6 Evolutionary Feasibility There is no evolutionary requirement as of now. FED_FCP_S13b_T09_V5.0.doc 11

17 5. Business Case Analysis 5.1 Market Trend and Product Line Analysis Table 7: Market Trend and Product Line Analysis Market Trend Product Line Fuel CMS It is not as popular as others like Wordpress or Drupal and does not provide as much base functionality as them. However, it provides a lot of flexibility and control to the developers that many of the other popular CMS s abstract away or make somewhat more convoluted to change. Fuel CMS has some problems with its documentation, but the community is highly responsive and helpful for figuring things out. It also provides many modules that can provide helpful functionality along with an easy means to write our own modules to create our own custom functionality. 5.2 Cost Analysis 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 8: Personnel Costs Activities Development Period (24 weeks) Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks) Client: Time spent to discuss with the developing team via , phone, and other channels [3 hrs/week * 12 weeks *1 person] WinWin negotiation session [1.5 hrs * 2 times *1 person] Architecture Review Boards [2 hrs * 2 times * 1 person] Development and Operation Phases: Time Invested (CS577b, 12 weeks) Client: Meeting via , phone, and other channels [2 hrs/week * 12 weeks * 1 person] Architecture Review Boards and Core Capability Drive-through session Time Spent (Hours) $ Equivalent ($35/hour) 36 $ $105 4 $ $ $157.5 FED_FCP_S13b_T09_V5.0.doc 12

18 [1.5 hrs * 3 times * 1 person] Deployment of system in operation phase 12 $420 [6 hrs * 2 times * 1 person] Training & Support 10 $350 [5 hrs * 2 times * 1 person] Total 93.5 $ Maintenance Period (1 year) Maintenance [2 hrs/week * 52 weeks * 1 person] 104 $3640 Total 104 $ Hardware and Software Costs Table 9: Hardware and Software Costs Development phase Type Cost Rationale Software Notepad++ 0 Free software Software Aptana 0 Free software Hardware Web Host 0 In developing process, developing team would build everything on the USC server which is free. Operation phase Type Cost Rationale Hardware Web Hosting $60/year The client needs to apply a web host for this website. Usually the fee is less than $5/month. Hardware Web Domain name $10/year To apply and keep a domain name for a website comes with a fee. 5.3 Benefit Analysis Following table summarizes the benefits in terms of number of hours of work saved mainly through automation of activities. Note that the values used are yet to be confirmed by the clients. Thus there will be changes after incorporating client's input. Table 10: Benefits of UDI System Current activities & resources used It would be easier to change the content of the website dynamically % Reduce Time Saved (Hours/Year) 80% 38.4 $ Equivalent ($35/hour) 1344 FED_FCP_S13b_T09_V5.0.doc 13

19 (4hr/month) Reduce the effort to trace clients latest requests. The system will notify the owner if there is a change in requests. 90% (0.5hr/time*12times/month) Reduce the time to produce detailed information through . The website would generate a template dedicated to each client to view 70% their product related information. (owner: 1.5hr/product * 5products/month) The client will not need to manage their outlook box with all of the attachments in there. 90% (15hr/month ) Total ROI Analysis The following table shows the cost and the benefit in the following 5 years. We can see that our client would achieve positive balance starting from Cost (developing): personnel cost = Cost (operation) : maintenance cost + hardware & software cost = 3710 Benefit : benefit analysis =11487 Table 11: ROI Analysis Year Cost Benefit Cumulative Cumulative (Effort Saved) Cost Benefit ROI FED_FCP_S13b_T09_V5.0.doc 14

20 Figure 1: ROI Analysis Graph FED_FCP_S13b_T09_V5.0.doc 15

21 6. Conclusion and Recommendations C1: Fuel CMS will be the main NDI that we will use for development. R1: Fuel CMS provides us with more of the basic functionality that we will need than just CodeIgniter. The manager interface with all of the user account, templating, and CMS-webpage connection functionality is already implemented and available for us to create custom functionality around. C2: PHP will be the programming language used R2: Fuel CMS is a PHP framework C3: MySQL will be the database that will be utilized R3: It is the database that all of the developers have the most familiarity with along with being the same database that the current system is on, making migration at time of transition slightly easier. C4: User Interface will be implemented as client s expectation R4: Due to all members and clients keep discussing the detail of web design, and sharing experience from each other. FED_FCP_S13b_T09_V5.0.doc 16

Feasibility Evidence Description (FED)

Feasibility Evidence Description (FED) United Direct Marketing Team 9 Chun-Ling Chen Project manager/ Prototyper Chun-Pei Su Lifecycle Planner Shao-yen Cheng System Architect Yuan-Chang Chang Feasibility