Feasibility Evidence Description (FED)

Transcription

1 Feasibility Evidence Description (FED) Pediatric Trauma Society Research Investigator Databank (PTS-RID) Team 01 Kenda Albertson: Verification and Validation Georges Hatem: Project Manager, Life Cycle Planner Mehrdad Mahdavi Boroujerdi : Project Manager, Feasibility Analyst, Developer Nicholas McCall: Operational Concept Engineer, Requirement Engineer Junjian Wang: System Architect, Prototyper 05/03/13

2 Version History Date Author Version Changes made Rationale 10/10/12 MM 1.0 First Version VC Package 10/15/12 MM 1.1 Section 1 and 5 completed FC Package 10/22/12 MM 1.2 Bugs fixed 10/30/12 MM 1.3 Section 2-4 completed Bugs fixed Response to Evaluation of VC Package FCR ARB 11/05/12 MM 1.4 Section 2, 2.2, 2.3, 3 Fixed FCR ARB Comments 11/09/12 MM /26/12 MM 1.6 Benefits in Program Model Updated with more realistic concepts (Section 2) Section 2.2, 2.3 updated in regards to the new benefits. Bugs fixed New feasibility evidences added (Pulling information from PubMed module ) Instructor s Comment Bugs fixed based on TA Comments We have provided some feasibility evidences about our most risky module (Pulling information from PubMed module) 11/28/12 MM 1.7 RIO updated Instructor s Comments 12/03/12 MM 2.0 Bugs fixed Feasibility evidences updated 12/10/12 MM 1.2 FED updates based on ARB s comments 12/17/12 MM 2.2 RIO fixed Level of Service Feasibility, Capability Feasibility, Evolutionary Feasibility Updated Complete FED for DCR ARB (Final DC Package) Final DC Package TA s Comment Evaluation of Final DC Package 02/11/13 MM 3.0 Risk Assessment Updated Personal Turnover 02/20/13 MM 3.1 Similar to v3.0 04/01/13 MM 6.0 Add documentation for new development/coding in section3 05/03/13 MM 4.1 Section updated with last documentation about PubMed Module (pulling information from pubmed) Update version for Final RDCP OIC1 OCI6, Project Archive

3 Table of Contents Feasibility Evidence Description (FED)...i Version History... ii Table of Contents... iii Table of Tables...iv Table of Figures...iv 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/NCS Interoperability Analysis Introduction Evaluation Summary... 18

4 Table of Tables Table 1: Personnel Costs... 3 Table 2: Hardware and Software Costs... 3 Table 3: Benefits of xxx System... 4 Table 4: ROI Analysis... 4 Table 5: Level of Service Feasibility Table 6: Capability Requirements and Their Feasibility Evidence Table 7: Evolutionary Requirements and Their Feasibility Evidence Table 8: Rationales for Selecting Architected Agile Model Table 9: Risk Assessment Table 10: NDI Products Listing Table 11: NDI Evaluation Table of Figures Figure 1: ROI Analysis Graph... 4

5 1. Introduction 1.1 Purpose of the FED Document In this document we discuss about the evidence of feasibility in our projects. We use business case analysis, risk assessment, and etc. to have a better perspective of evidences. 1.2 Status of the FED Document - The risk assessment table reformed with more clear statements. - After reviewing team s analysis on process feasibility we decided to use Architected Agile model in our project. - All section updated for DC Package after team, TA, client and instructor s evaluation.

6 2. Business Case Analysis Assumptions People are willing to use an electronic system for collaboration Increased collaboration improves research Stakeholders (Who) Initiatives (What) Value Propositions (Why) Developers Develop System Increase research PTS marketing Market the project collaborations team and get people to between members PTS research team sign up. of PTS. Web master Promoting success Improve education Database stories. and research. administrator Collect statistics Reduce number of on injuries injuries for Perform outreach children. of new research Reduce the burden Train the web on hospitals and master. clinics. Beneficiaries (For Whom) Members of PTS The medical field Children Parents Hospitals, Clinics, Society Cost Development Personnel Training (Developers, Webmaster) Maintenance Infrastructure expenses (e.g. Web Hosting/Server) Benefits Number of members published papers (Rationale: This project is supposed to facilitate researchers (members) collaboration. So if in the future we find that the number of published paper increased, it means that this project has been useful.) Hours that each member spends on research.

7 2.1 Cost Analysis Personnel Costs Activities Table 1: Personnel Costs Time Spent (Hours) Development Period (24 weeks) Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks) Client: Meeting via , phone, and other channels [3 hrs/week * 12 weeks * 1 36 people] Client Representatives (Webmaster): Meeting via , phone, and other channels [1 12 hrs/week * 12 weeks * 1 people] Architecture Review Boards [1.5 hrs * 2 times * 2 people] 6 Development and Operation Phases: Time Invested (CS577b, 12 weeks) Client: Meeting via , phone, and other channels [5 hrs/week * 12 weeks * 1 60 people] Maintainer (Webmaster): Meeting via , phone, and other channels [3 hrs/week * weeks * 1 people] Architecture Review Boards and Core Capability Drive-through session [1.5 hrs * 3 9 times * 2 people] Deployment of system in operation phase and training 56 - Installation & Deployment [3 hrs * 4 times * 2 people (Client & Webmaster)] - Training & Support [2 hrs * 8 times * 2 people (Client & Webmaster)] Total 215 Maintenance Period (1 year) Maintenance [8 hr/week * 52 weeks] 416 Total Hardware and Software Costs Table 2: Hardware and Software Costs Development & Operation Type Cost Rationale Hardware Web Hosting and Domain Server $104/year A new web server is needed to serve our application, database and domain name.

8 2.2 Benefit Analysis Table 3: Benefits of PTS System Current activities & resources used % Change Time Saved (Hours/Year) Increase collaboration (reduce time that 10% each member needs to spend on (Decrease) researching) 1000 Total 1000 Benefit Analysis metrics Improve research quality (Increase the number of members published papers) Number of Published Paper Number of Collaborators 2.3 ROI Analysis Table 4: ROI Analysis Year Cost Benefit Cumulative (Effort Cost Saved) Cumulative Benefit ROI ( ) Figure 1: ROI Analysis Graph

9 ROI ROI = (Cumulative Benefit - Cumulative Cost) / Cumulative Cost ROI

10 3. Architecture Feasibility Feasibility Evidences for Pulling Information Module The most critical part of our project is communication with PubMed. PubMed is a database of members articles (members are the users of the project application). So before doing anything we should do some prototyping to make sure that this module is going to work properly. NCBI (National Center for Biotechnology Information which owns PubMed) provides an API (Entrez Programming Utilities) to work with PubMed database. This API consists of many tools which let us to have access to the articles XML files, search through PubMed and etc. At the beginning of the development phase we decided to use this Entrez API. Later we found that this API is very limited so we shifted to another API called PubMedAPI or PubMed Wrapper (discussed in the below). In the below we first describe the Entrez API and then we will discuss about PubMedAPI (PubMed Wrapper) which is the API that we actually used for fetching the information from PubMed. 1. Entrez Programming Utilities The Entrez Programming Utilities (E-utilities) are a set of eight server-side programs that provide a stable interface into the Entrez query and database system at the National Center for Biotechnology Information (NCBI). The E-utilities use a fixed URL syntax that translates a standard set of input parameters into the values necessary for various NCBI software components to search for and retrieve the requested data. All E-utility requests should be made to URLs beginning with the following string: To access these data, a piece of software first posts an E-utility URL to NCBI, then retrieves the results of this posting, after which it processes the data as required. The software can thus use any computer language that can send a URL to the E-utilities server and interpret the XML response; examples of such languages are Perl, Python, Java, and C++. Combining E-utilities components to form customized data pipelines within these applications is a powerful approach to data manipulation. Entrez Program Interfaces ESearch utilitiy

11 eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi Responds to a text query with the list of matching UIDs in a given database (for later use in ESummary, EFetch or ELink), along with the term translations of the query. ESummary (document summary downloads) eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi Responds to a list of UIDs from a given database with the corresponding document summaries. This part consists of some feasibility evidences about our most risky module (pulling information from PubMed). EFetch (data record downloads) eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi Responds to a list of UIDs in a given database with the corresponding data records in a specified format. ESpell (spelling suggestions) eutils.ncbi.nlm.nih.gov/entrez/eutils/espell.fcgi Retrieves spelling suggestions for a text query in a given database. Syntax and Initial Parsing of Entrez Queries term1[field1] Op term2[field2] Op term3[field3] Op Example: human[organism] AND topoisomerase[protein name] esearch.fcgi?db=<database>&term=<query> Input: Entrez database (&db); Any Entrez text query (&term) Output: List of UIDs matching the Entrez query Example: Get the PubMed IDs (PMIDs) for articles about breast cancer published in Science in nce[journal]+and+breast+cancer+and+2008[pdat] Pipelines Retrieving data records matching an Entrez query ESearch ESummary ESearch EFetch

12 Retrieving data records matching a list of UIDs EPost ESummary EPost EFetch Retrieving data records from a subset of an ID list defined by an Entrez query EPost ESearch ESummary EPost ESearch EFetch In the code below we used ESearch EFetch pipeline to first search for a query (by using Esearch) and then fetch the abstract of papers which contain that query (by using Efetch). <html> <head> <title> search script </title> <meta name="author" content="sepideh A., </head> <body> <form name="form" action="ptsrid-pubmed.php" method="get"> <input type="text" name="q" /> <input type="submit" name="submit" value="search" /> </form> <?php $var ; $trimmed = trim($var); //trim whitespace from the stored variable // rows to return $limit=10; // check for an empty string and display a message. if ($trimmed == "") { echo "<p>please enter a search...</p>"; exit; } // check for a search parameter if (!isset($var)) { echo "<p>we dont seem to have a search parameter!</p>"; exit; } $lastname = $var; $database = "pubmed"; //basic search: search term in databse $searchresult = " "esearch.fcgi?db=".$database."&term=".$lastname;

13 //create xml object $searchresultxml = simplexml_load_file($searchresult); //loop through all results(ids) for ($i=0; $i < $searchresultxml->retmax; $i++) { //get ids $articleidarray = $searchresultxml->idlist->id[$i]; //fetch abstracts based on ids $article = " "efetch.fcgi?db=".$database."&id=".$articleidarray."&retmode=xml"; $articeltxml = simplexml_load_file($article); //print abstract echo $articeltxml->pubmedarticle->medlinecitation->article->abstract- >AbstractText; echo "<br>"."<hr>"; }?> </body> </html> Here is the output of this part of Code:

14 The next things that we are going to do are some advance fetching/searching from and in PubMed database. 2. PHP-Pubmed-API-Wrapper PHP-PubMed-API-Wrapper This is a new developed API-Wapper which we used in our project as a new way in communication with PubMed. This API is developed by third party developers. They tried to solve some problems of PubMed original API (Entrez). This API gave us more reliability. This API is accessible through this link: A modified version of this API is also available in the project source code (PudMedAPI.php). This file is documented by the original authors. The PTS-RID developers also added comments for the modified parts of the code. We modified this API because we needed to fit this API with our project (e.g. the original version of this API doesn t pull all the information that we really needed so we had to modify this API to make it to pull all the information which we really needed)

15 Pubmed Module Codes: The Pubmed Module consists of two php files which are available in the PTS-RID source code: 1. PudMedAPI: Which is the modified version of the (PHP-Pubmed-API-Wrapper). 2. pudmed.php: Which does the whole functionality of pulling information: Reading User s information from local database (user table) The for each user the code goes to the Pubmed website and fetch all of hir/her article s information Then the code populated the relational local database. These two php files are well commented and are available in the PTS-RID source code. 3.2 Level of Service Feasibility Part 3.2, 3.3, 3.4 consist of products strategies and processes strategies that we can use to achieve each requirement. Table 5: Level of Service Feasibility Level of Service Requirement LOS-1: Support 200 users, 100 concurrently LOS-2: System shall be scalable LOS-3: Search time will be under one minute Product Satisfaction Product Strategies: Database Optimization (Code/Algorithm), Using well-known host/database server Process Strategies: Doing some prototypes to simulate a situation in which 100 concurrent users are working on the database (maximum 200 users) by using SQL procedures and optimized algorithms. Analysis: By using these strategies we can predict the possible burden of the database so we will be able to provide sufficient infrastructure and process for it. For example with prototyping we can estimate the optimistic and pessimistic bandwidth in which our application will work properly. Product Strategies: Modular Architecture Process Strategies: Prototype each module s scalability, Using powerful database which has good scalability. Analysis: If in all phases of software developing we pay attention to scalability then we can develop the system in a way that it would be more scalable. For example with prototyping we can know how our infrastructure should be scalable to help system s growth. On the other hand if we have a modular approach it would satisfy scalability so if in the future the system needs to be larger, working on small modules is easier that working on a big whole module. Product Strategies: Optimized code and algorithm, Using Powerful host and database server. Process Strategies: Modeling and Prototyping, Performance Analysis

16 LOS-4: Downtime: no more than four hours per month Analysis: These strategies help us to plan, test and simulate the system to make sure that its search module performance meets the project s target. For example using powerful search algorithms and frameworks and also having a powerful database engine would greatly help us to reach this approach. Product Strategies: Monitoring the system (after delivery), Regular Backup/ Recovery, Well design and test to reduce the system s bugs Process Strategies: Test Plans & Tools, Regular maintenance Analysis: By using these kinds of strategies we can use test-based developing to reduce downtime. For example we can simulate the system to examine its performance in different situation and queries. Another approach we are going to use is to design the system is a way that has the minimum amount of bugs so after delivery we can reduce the downtime chance. Using powerful test tools also help us in this approach. After delivering the project we also need to make sure that the system is monitored and maintenance regular so we told our client that they should assign an expert person as the webmaster. 3.3 Capability Feasibility Table 6: Capability Requirements and Their Feasibility Evidence Capability Requirement CR-1: Custom searchable database populated from PubMed CR-2: Search by keyword, MESH term, author CR-3: Search member directory CR-4: User profile page with list of personal Product Satisfaction Software/Technology used: Use algorithms for pulling information through PubMed API, Use MySQL database with powerful search procedures. Feasibility Evidence: We ve planned to use powerful search procedures (e.g. solr query) to connect to the database, search among its record and return the result. Software/Technology used: Using key-based search algorithm to search among database base. Feasibility Evidence: By using combined SQL algorithms (e.g using like keyword) we request for such query from the database. Referred use case diagram: UC-3, UC-13, UC-14, UC-15 Software/Technology used: Using a SQL search procedure to search user database. Feasibility Evidence: The user s information is stored into the database in the user table. By connecting to the database (using php and MySQL) we can create a dataset of user s information and after that we can show on the searchmember directory page. Software/Technology used: GUI developing Tools, PHP, HTML, MySQL

17 MESH interests, articles, CV CR-5: Discussion board (posting/responding to topics) CR-7: Personal topcollaborators list Feasibility Evidence: For having a good perspective about this capability we used some GUI prototyping. For developing this module since all user s information are stored into the user table into the database, after connecting to the database and getting a query of each user s information we can simply show each user s information into the Profile page. Referred use case diagram: UC-8, UC-12 Software/Technology used: Discussion Board COTS Feasibility Evidence: We analyzed different types of discussion board COTS product. We used their demo version. Also we used weighted matrix to have a better understanding of all COTS s capabilities. Referred use case diagram: UC-4, UC-5, UC-6 Software/Technology used: JavaScript Feasibility Evidence: This module s implementation is like CR-4. After connecting to the user table in our database, we have a list of all users. For this module we just need each user s collaboration field. Since we already did some prototyping for connecting to the database and creating some record sets, now we have good evidences which make us to feel that this module doable. Referred use case diagram: UC Evolutionary Feasibility Table 7: Evolutionary Requirements and Their Feasibility Evidence Evolutionary Requirement ER-1: Support more users Product Satisfaction Software/Technology used: PHP, SQL, Database Management As we discussed in the evidences for LOS-1, we are going to develop the system in a modular way so if in the future we need more use supports, the system will be scalable enough to achieve ss capability.

18 4. Process Feasibility Based on our project s non-conformity points and comparing them to all 4 process patterns, we can see that the number of non-conformity points in Architected Agile process pattern (4 nonconformity points) is less than other patterns. It means that our project is more follow Architected Agile process pattern. On the other hand the importance of these 4 points is medium. So from all of these factors we can find that we should follow Architected Agile process. Table 8: Rationales for Selecting Architected Agile Model Criteria Importance Project Rationales Status 30 % of NDI/NCS features 2 1 Using one COTS that is small part of the whole project. Single NDI/NCS 1 0 There is no single NDI/NCS that satisfies a complete solution. Unique/ inflexible business process 2 2 The system business is not very unique and the requirements can Need control over upgrade / maintenance change in the future. 3 4 Because this system works with a lot of information which are stored in the database, it should be upgraded regularly. Rapid deployment 1 1 PTS is a non-profit organization and also there is no deadline for delivering the system (except 577 milestones). Critical on compatibility 3 4 However we use only one COTS, it should be fully integrated in to the system. Internet connection 2 1 It is a web application. independence Need high level of 2 1 The levels of service are not high. services / performance Need high security 2 1 There is no sensitive information. Asynchronous communication 1 1 All communications in the system should be synchronous. Be accessed from 3 4 It is a web application. anywhere Critical on mass schedule constraints 2 2 Schedule is important in our project. Lack of personnel capability 2 3 The webmaster probably has little experience about database maintenance and optimization and also web application developing

19 Require little upfront costs Require low total cost of ownership Not-so-powerful local machines 2 2 The major costs are about web hosting and servers. 2 3 PTS do not need to spend much money to own PTS-RID. 2 4 It is a web application.

20

21 5. Risk Assessment Table 9: Risk Assessment Risks Lack of developer skills would increase lifecycle plan. One Team member s turnover would affect estimations and increase lifecycle plan. Current PTS log-in page cannot be compatible with the project. Inability to connect to PubMed will fail the project. Client will not be satisfied if response time does not meet target. COTS products chosen do not meet the needs of the users. Staffing unavailability (database manager, moderator) would increase system downtime. Potential Magnitude Risk Exposure Probability Loss Risk Exposure Training Risk Mitigations Eliminate Low priority Modules Modify their current code Using PubMed API tools Consider Solr, Lucene solutions, Prototyping, Optimizing Code Get client and board feedback, COTS assessment, Prototyping Get client and board feedback, Business Case Analysis

22 6. NDI/NCS Interoperability Analysis 6.1 Introduction Member s collaboration is one of the important parts of our project. After negotiating with client, we decided to use a discussion board COTS product for this module. After analyzing many COTS product we found that two of them best match to the client s win condition, MyBB and phpbb. After negotiation with client and also analyzing these two COTS product we decided to use phpbb. In this section there are our assessments about these two COTS product. 6.2 COTS / GOTS / ROTS / Open Source / NCS Except disccution board COTS products, we are going to use phpmyadmin DBMS and Apache Web Server which give us ability to develop web applications. Table 10: NDI Products Listing NDI/NCS Products MyBB phpbb phpmyadmin Apache Purposes Discussion Board Discussion Board Database Management Web Server 6.3 Connectors Since our COTS product is an open source software based on PHP, we are going to use PHP to integrate phpbb into our project. Also for storing data which we retrieve from PubMed into our local database, we use MySQL. 6.4 Evaluation Summary As previously discussed, we are going to use phpbb for discussion board forum. This section contains our comparison assessments. phpbb satisty all project s win-conditions and level of services. phpbb is a popular Internet forum package written in the PHP scripting language. Available under the GNU General Public License, phpbb is free and open source software. Features of phpbb include support for multiple database engines (PostgreSQL, SQLite, MySQL, Oracle, Microsoft SQL Server), flat message structure (as opposed to threaded), hierarchical subforums,

23 topic split/merge/lock, user groups, multiple attachments per post, full-text search, plugins and various notification options ( , Jabber instant messaging, ATOM feeds) - Wikipedia Table 11: NDI Evaluation Criteria MyBB phpbb Notes Documentation O + Outdated, many dead links. Simply poor. Modding process + O without editing a single file. Built for modding. Additional features + O Minor. Ex: Inline moderation Security history O vs. 6 since 2003 Admin UI simplicity + O ex: drag-and-drop vs. dropdown menus Comprehensive settings O + advanced settings more easily accessible Adding Styles/Themes + O built-in vs. real-time preview website After analyzing MyBB and phpbb and trying demo versions of them and also after negotiating with client we found that both COTS are suitable for our project but phpbb has some minor advantage more than MyBB. So finally client decided to use phpbb. Here are some screen shots of MyBB and phpbb which we used in our negotiations.

24

25

26

27