operational concept description (ocd) · assumptions related to the usefulness of the system, as...

Operational Concept Description (OCD)

Software Quality Analysis as a Service (SQAaaS)

Team No.1

Kavneet Kaur

Requirement Engineer

George Llames

IIV & V

Aleksandr Chernousov

Life Cycle Planner

Supicha Phadungsilp

Feasibility Analyst

Reza Khazali

Software Architect

Jincheng He

Quality Focus Point

Aditya Kathuria

Prototyper

Chris Harman

Operation Concept Engineer

October 15, 2017

Operational Concept Description (OCD) for SQUAaaS Version 1.0

OCD_FCP_F17a_T01 Version Date: 10/15/17 ii

Version History Date Author Version Changes made Rationale

10/15/17 CH 1.0 • Fill in text sections and add figures

from ARB presentation

• Initial version; FC Package

Submission


OCD_FCP_F17a_T01 Version Date: 10/15/17 iii

Table of Contents

Operational Concept Description (OCD) ...................................................................................................................i Version History ........................................................................................................................................................... ii Table of Contents ....................................................................................................................................................... iii Table of Tables ............................................................................................................................................................iv Table of Figures ........................................................................................................................................................... v

1. Introduction .......................................................................................................................................................... 1

1.1 Purpose of the OCD ................................................................................................................................. 1

1.2 Status of the OCD .................................................................................................................................... 1

2. Shared Vision ........................................................................................................................................................ 2

2.1 Benefits Chain .......................................................................................................................................... 3

2.2 System Capability Description................................................................................................................ 3

2.3 System Boundary and Environment ...................................................................................................... 4

3. System Transformation ........................................................................................................................................ 5

3.1 Information on Current System ............................................................................................................. 5

3.2 System Objectives, Constraints and Priorities ...................................................................................... 6

3.3 Proposed New Operational Concept ...................................................................................................... 9

3.4 Organizational and Operational Implications .................................................................................... 11


OCD_FCP_F17a_T01 Version Date: 10/15/17 iv

Table of Tables

Table 1: SQUAaaS Program Model .............................................................................................................................. 2

Table 2: Capability Goals ............................................................................................................................................. 6

Table 3: Level of Service Goals ..................................................................................................................................... 7

Table 4: Organizational Goals ...................................................................................................................................... 8

Table 5: System Constraints .......................................................................................................................................... 8

Table 6: Relation to Current System.............................................................................................................................. 9


OCD_FCP_F17a_T01 Version Date: 10/15/17 v

Table of Figures

Figure 1: SQUAaaS Benefits Chain Diagram ............................................................................................................... 3

Figure 2: SQUAaaS System Boundary .......................................................................................................................... 4

Figure 3: Current Business Workflow ........................................................................................................................... 6

Figure 4: SQUAaaS Element Relationship Diagram .................................................................................................. 10

Figure 5: SQUAaaS Business Workflow Diagram ...................................................................................................... 11


OCD_FCP_F17a_T01 Version Date: 10/15/17 1

1. Introduction

1.1 Purpose of the OCD

This document is meant to serve as the conceptual bedrock for the Software Quality

Analysis as a Service (SQUAaaS) system. The hope is to crystallize the current

understanding of project direction, as well as document the visions and goals of system

stakeholders. The current success-critical stakeholders are Pooyan Behnamghader, the

project owner, maintainer and client, development team 01 for CSCI577, and the

anticipated end-users of the system.

1.2 Status of the OCD

This is the initial version of the OCD. The project is nearing the end of the Valuation

Phase, and this version is a key artifact for the Foundations Commitment Review. The

SQUAaaS system has seen significant progress in narrowing the project scope,

prototyping high-risks requirements, and identifying core technologies to move forward

with.



2. Shared Vision

The below program model describes concisely the project’s overall vision. Some basic

assumptions related to the usefulness of the system, as well as accessibility are included along

with a detailing of system stakeholders, initiatives, value propositions, beneficiaries, costs, and

benefits.

Table 1: SQUAaaS Program Model



2.1 Benefits Chain

The benefits chain diagram shows at-a-glance how the components of the program interact,

culminating in the system’s primary benefit: Analyzed software increases in overall quality

and value.

Figure 1: SQUAaaS Benefits Chain Diagram

2.2 System Capability Description

• The system will be a web application, meant to function properly on a Chrome browser,

on a desktop system, and geared toward dynamic visualization of software quality data.

• The system is aimed primarily at the following groups:

o Researchers interested in evaluating trends in software quality throughout the

development process.

o Project Managers looking for a tool to aid in quantifying developer contributions

to software quality.

o Project contributors hoping for a way to see how their own commits have affected

software quality.

o Software investors seeking a better understanding of the value of their investment.



• SQUAaaS satisfies a need in the market for a comprehensive tool providing at-a-glance

visualization of the evolution of a project’s software quality throughout the development

process.

• Sonarqube – SonarCloud (https://sonarcloud.io/projects) is the system’s closest

competitor.

• The system is compelling because it presents multiple software quality analysis

algorithms in a novel way, allowing for cross-comparison capabilities not found in

existing software quality analysis systems.

2.3 System Boundary and Environment

The system boundary shows the stakeholders expected to interface with the system, also details

the high-level system capabilities, and depicts the external Project Analyzer System SQUAaaS

will be required to interface with.

Note: The system must be accessible over the internet.

Figure 2: SQUAaaS System Boundary

https://sonarcloud.io/projects



3. System Transformation

3.1 Information on Current System

3.1.1 Infrastructure

• Front End Web Application:

o AngularJS

o D3

• Backend Project Analyzer System is the same SQUAaaS will interface with

• Hosted on USC Hercules Server

3.1.2 Artifacts

• Front End Web Application

• Backend Project Analyzer System



3.1.3 Current Business Workflow

Figure 3: Current Business Workflow

3.2 System Objectives, Constraints and

Priorities

3.2.1 Capability Goals

Table 2: Capability Goals

Capability Goals Priority Level

SP-1: Statistical Page – View Project Contribution (WC_4509) -

Users must be able to examine the evolution of software quality

using a visualization of statistical data for projects they have

contributed to.

<< Must have>>



SP-2: Statistical Page – Compare Multiple Metrics (WC_4608,

WC_4453) - Users must be able to cross-examine various software

quality metrics for a project simultaneously.

<< Must have>>

SP-3: Statistical Page – Export Statistics (WC_4341) - Users

should be able to export software quality statistics as CSV. << Should have>>

PS-1: Profiling System - Open Source Access (WC_4508) – Users

must have access to statistics for all open-source projects in the

system.

<< Must have>>

PS-2: Profiling System – Contributor Access (WC_4499) – Users

must have access to statistics for all projects they have contributed

to.

<< Must have>>

PS-3: Profiling System – Password Reset (WC_4425) – Users

must have access to statistics for all projects they have contributed

to.

<< Must have>>

PS-4: Profiling System – Admin Access Control (WC_4452,

WC_4300, WC_4339, WC_4338) – Admin users must have the

ability to control access to analyzed projects.

<< Must have>>

PS-5: Profiling System – Admin Password Reset (WC_4501) –

Admin users should have the ability to reset other users’ passwords. << Should have>>

PS-6: Profiling System – Email Confirmation (WC_4337) – Users

must receive an email confirming their registration. << Must have>>

PS-7: Profiling System – Project Request (WC_4449) – Users

must be able to request that their project is analyzed. << Must have>>

PS-8: Profiling System – Deactivate User (WC_4503) – Admin

users must be able to deactivate users. << Must have>>

PS-9: Profiling System – Request on Behalf (WC_4424) – Users

should be able to request access to a project on behalf on another

user.

<< Should have>>

DASH-1: Dashboard – Projects Overview (WC_4509) – Users

must see all projects contributed to, granted access to, or any open

source projects.

<< Must have>>

HTTPS-1: HTTPS Certificate (WC_4426) – The system must be

secured with HTTPS. << Must have>>

3.2.2 Level of Service Goals

Table 3: Level of Service Goals

Level of Service Goals Priority

Level

Referred WinWin Agreements

Smooth interaction with statistical

analysis view with 10000 data points,

and 4 metrics viewed simultaneously.

High WC_4608

Load statistical in less than or equal to 2

seconds.

High WC_4609



20 users should be able to access the

system simultaneously.

High WC_4607

System shall be hosted using HTTPS. High WC_4426

Hosted site should have availability

consistent with industry standards.

High Aiming to host using AWS.

3.2.3 Organizational Goals

Table 4: Organizational Goals

Organizational Goals

OG-1: Improve Analyzed Software – Analyzed software increases

in overall quality and value. OG-2: Remedy Software Issues – Provide an opportunity to

address issues in software codebase uncovered by using system.

OG-3: Understand Investment – Give investors in software a better

understanding of their investment.

OG-4: Evaluate Development Team – Provide project managers a

way to evaluate development team member contributions to software

quality.

OG-5: Increase System Use – Grow system’s user base.

3.2.4 Constraints

Table 5: System Constraints

System Constraints

CO-1: HTTPS Security – The system must be secured using

HTTPS (WC_4426). CO-2: React Front-end – The front end web framework must be

React (WC_4553).

CO-3: Node Backend – The backend shall be implemented using

Node.js.

CO-4: PostgreSQL Database – The database technology must be

PostgreSQL.

CO-5: Publicly Available – The system shall be available over the

internet.



3.2.5 Relation to Current System

Table 6: Relation to Current System

Capabilities Current System New System

Roles and

Responsibilities

Client has developed system in

tandem with graduate students.

Current system strategy will

remain consistent in new system.

User Interactions Login; access to basic software

quality visualization.

User access control system will be

implemented; visualization will be

improved.

Infrastructure Front-end framework

implemented in AngularJS;

backend in Node.js; PostgreSQL

database; hosted on USC Hercules

server.

Front-end framework in React;

backend in Node.js; PostgreSQL

database; hosted on AWS.

Stakeholder

Essentials and

Amenities

Open-source projects only; basic

data visualization.

User access control to enable

closed-source projects to be

hosted in system; analysis

download; analysis request;

HTTPS; more sophisticated data

visualization.

Future

Capabilities

N/A Meta-level analysis of how

various software metrics co-

evolve during the development

process of a project.

3.3 Proposed New Operational Concept

The new operational concept is meant to provide a facelift for the existing statistical analysis,

improve the level of sophistication in data visualization, add HTTPS security to the system, give

users the option to request analysis of their project, and implement a user access control module

to allow for closed-source projects to be hosted by the system. These factors combine to create

what we hope will be a legitimate web application, accessible by Desktop on Chrome.



3.3.1 Element Relationship Diagram

Figure 4: SQUAaaS Element Relationship Diagram



3.3.2 Business Workflows

Figure 5: SQUAaaS Business Workflow Diagram

3.4 Organizational and Operational

Implications

3.4.1 Organizational Transformations

• The addition of the admin user will inject a need for manual intervention to ensure that

permissions are allocated properly within the system. We expect that the client will take

over this responsibility once the system has been completed.

• Maintainer responsibilities will increase with the change in hosting strategy.

3.4.2 Operational Transformations

• HTTPS certificates will need to be updated periodically.

• Admin user will need to configure permissions properly.



• Closed-source projects will need to be handled with extra attention.

• Requests for new project analysis will need to be addressed in the client-maintained

project analyzer system, as well as alerts for completed software quality analysis for

requested projects.

operational concept description (ocd) · assumptions related to the usefulness of the system, as...

Documents