feasibility evidence description (fed) · that this api is very limited so we shifted to another...

Feasibility Evidence Description (FED) for Architected Agile Version 6.0

FED_IOC1_S13b_T01_V6.0 Version Date: 05/03/13

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


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 Response to Evaluation of VC

Package

10/30/12 MM 1.3 Section 2-4 completed

Bugs fixed FCR ARB

11/05/12 MM 1.4 Section 2, 2.2, 2.3, 3 Fixed FCR ARB Comments

11/09/12 MM 1.5

Benefits in Program Model

Updated with more realistic

concepts (Section 2)

Section 2.2, 2.3 updated in

regards to the new benefits.

Instructor’s Comment

11/26/12 MM 1.6

Bugs fixed

New feasibility evidences added

(Pulling information from

PubMed module )

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

Complete FED for DCR ARB

(Final DC Package)

12/10/12 MM 1.2 FED updates based on ARB’s

comments Final DC Package

12/17/12 MM 2.2

RIO fixed

Level of Service Feasibility,

Capability Feasibility,

Evolutionary Feasibility

Updated

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 Update “version” for Final

RDCP

04/01/13 MM 6.0 Add documentation for new

development/coding in section3 OIC1

05/03/13 MM 4.1

Section 3.1.1 updated with last

documentation about PubMed

Module (pulling information

from pubmed)

OCI6, Project Archive


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 .......................................................................................................................................................... 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 .................................................................................................................................................. 3

2.2 Benefit Analysis ............................................................................................................................................. 4

2.3 ROI Analysis .................................................................................................................................................. 4

3. Architecture Feasibility ........................................................................................................................................ 6

3.1 Level of Service Feasibility ......................................................................................................................... 11

3.2 Capability Feasibility .................................................................................................................................. 12

3.3 Evolutionary Feasibility .............................................................................................................................. 13

4. Process Feasibility .............................................................................................................................................. 14

5. Risk Assessment .................................................................................................................................................. 17

6. NDI/NCS Interoperability Analysis .................................................................................................................. 18

6.1 Introduction ................................................................................................................................................. 18

6.2 Evaluation Summary .................................................................................................................................. 18


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 ........................................................................................................................... 11

Table 6: Capability Requirements and Their Feasibility Evidence ............................................................................. 12

Table 7: Evolutionary Requirements and Their Feasibility Evidence ......................................................................... 13

Table 8: Rationales for Selecting Architected Agile Model ......................................................................................... 14

Table 9: Risk Assessment ............................................................................................................................................. 17

Table 10: NDI Products Listing .................................................................................................................................. 18

Table 11: NDI Evaluation ........................................................................................................................................... 19

Table of Figures

Figure 1: ROI Analysis Graph ...................................................................................................................................... 4



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.



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)

Beneficiaries

(For Whom)

Developers

PTS marketing

team

PTS research team

Web master

Database

administrator

Develop System

Market the project

and get people to

sign up.

Promoting success

stories.

Collect statistics

on injuries

Perform outreach

of new research

Train the web

master.

Increase research

collaborations

between members

of PTS.

Improve education

and research.

Reduce number of

injuries for

children.

Reduce the burden

on hospitals and

clinics.

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.



2.1 Cost Analysis

2.1.1 Personnel Costs

Table 1: Personnel Costs

Activities Time Spent (Hours) Development Period (24 weeks)

Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks)

Client: Meeting via email, phone, and other channels [3 hrs/week * 12 weeks * 1

people] 36

Client Representatives (Webmaster): Meeting via email, phone, and other channels [1

hrs/week * 12 weeks * 1 people]

12

Architecture Review Boards [1.5 hrs * 2 times * 2 people] 6

Development and Operation Phases: Time Invested (CS577b, 12 weeks)

Client: Meeting via email, phone, and other channels [5 hrs/week * 12 weeks * 1

people]

60

Maintainer (Webmaster): Meeting via email, phone, and other channels [3 hrs/week *

12 weeks * 1 people]

36

Architecture Review Boards and Core Capability Drive-through session [1.5 hrs * 3

times * 2 people]

9

Deployment of system in operation phase and training

- Installation & Deployment [3 hrs * 4 times * 2 people (Client & Webmaster)]

- Training & Support [2 hrs * 8 times * 2 people (Client & Webmaster)]

56

Total 215

Maintenance Period (1 year)

Maintenance [8 hr/week * 52 weeks] 416

Total 416

2.1.2 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.



2.2 Benefit Analysis

Table 3: Benefits of PTS System

Current activities & resources used % Change Time Saved (Hours/Year)

Increase collaboration (reduce time that

each member needs to spend on

researching)

10%

(Decrease) 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

Cost

Cumulative

Benefit

ROI

(Effort

Saved)

2012 319

(215+104)

0 319 0 -1

2013 416 500 735 500 -0.32

2014 458 1000 1193 1500 0.26

2015 503 1050 1696 2550 0.50

2016 554 1103 2250 3653 0.62

2017 609 1158 2859 4810 0.68

Figure 1: ROI Analysis Graph



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

-1.2

-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

2011 2012 2013 2014 2015 2016 2017 2018

ROI

ROI



3. Architecture Feasibility

3.1.1 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:

http://eutils.ncbi.nlm.nih.gov/entrez/eutils/

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

http://www.ncbi.nlm.nih.gov/books/NBK25500/



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 2008

http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=pubmed&term=scie

nce[journal]+AND+breast+cancer+AND+2008[pdat]

Pipelines Retrieving data records matching an Entrez query

ESearch → ESummary

ESearch → EFetch



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> http://PediatricTraumaSociety.org/ search script </title>

<meta name="author" content="Sepideh A., http://PediatricTraumaSociety.org/">

</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 = @$_GET['q'] ;

$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 = "http://eutils.ncbi.nlm.nih.gov/entrez/eutils/".

"esearch.fcgi?db=".$dataBase."&term=".$lastName;



//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 = "http://eutils.ncbi.nlm.nih.gov/entrez/eutils/".

"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:



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:

https://github.com/asifr/PHP-PubMed-API-Wrapper

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)

https://github.com/asifr/PHP-PubMed-API-Wrapper



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

Product Satisfaction

LOS-1: Support 200 users,

100 concurrently

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.

LOS-2: System shall be

scalable

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.

LOS-3: Search time will

be under one minute

Product Strategies: Optimized code and algorithm, Using Powerful host

and database server.

Process Strategies: Modeling and Prototyping, Performance Analysis



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.

LOS-4: Downtime: no

more than four hours per

month

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 Product Satisfaction

CR-1: Custom searchable

database populated from

PubMed

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.

CR-2: Search by keyword,

MESH term, author

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

CR-3: Search member

directory

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.

CR-4: User profile page

with list of personal

Software/Technology used: GUI developing Tools, PHP, HTML,

MySQL



MESH interests, articles,

CV

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

CR-5: Discussion board

(posting/responding to

topics)

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

CR-7: Personal top-

collaborators list

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-7

3.4 Evolutionary Feasibility

Table 7: Evolutionary Requirements and Their Feasibility Evidence

Evolutionary

Requirement

Product Satisfaction

ER-1: Support more users 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.



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 non-

conformity 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

Status

Rationales

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

change in the future.

Need control over

upgrade / maintenance

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

independence

2 1 It is a web application.

Need high level of

services / performance

2 1 The levels of service are not high.

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

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



Require little upfront

costs

2 2 The major costs are about web

hosting and servers.

Require low total cost of

ownership

2 3 PTS do not need to spend much

money to own PTS-RID.

Not-so-powerful local

machines




5. Risk Assessment

Table 9: Risk Assessment

Risks

Risk Exposure

Risk Mitigations Potential

Magnitude

Probability

Loss

Risk

Exposure

Lack of developer skills

would increase lifecycle plan. 3 6 18 Training

One Team member’s turnover

would affect estimations and

increase lifecycle plan. 3 6 18

Eliminate Low priority

Modules

Current PTS log-in page

cannot be compatible with the

project. 6 3 18 Modify their current code

Inability to connect to

PubMed will fail the project. 8 2 16 Using PubMed API tools

Client will not be satisfied if

response time does not meet

target. 8 2 16

Consider Solr, Lucene

solutions, Prototyping,

Optimizing Code

COTS products chosen do not

meet the needs of the users. 4 2 8

Get client and board feedback,

COTS assessment, Prototyping

Staffing unavailability

(database manager,

moderator) would increase

system downtime.

4 1 4 Get client and board feedback,

Business Case Analysis



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 Purposes

MyBB Discussion Board

phpBB Discussion Board

phpMyAdmin Database Management

Apache 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,



topic split/merge/lock, user groups, multiple attachments per post, full-text search, plugins and

various notification options (e-mail, 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 + 151 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.

feasibility evidence description (fed) · that this api is very limited so we shifted to another...

Documents