Technical Documentation

Development Schedule	Stakeholders	Communication Plan

Data Flow Diagram	Use Cases	Administrator Roles

Development Schedule

Implementation for the plugin has been divided into four separate milestones each with different due dates and objectives:

• Milestone 1 (February 2nd, 2015)
• Milestone 2 (March 4th, 2015)
• Milestone 3 (April 17th, 2015)
• Milestone 4 (April 29th, 2015)

Stakeholders

The SPDX Eclipse Plugin has a few primary stakeholders who can significantly influence the plugins development and a couple secondary stakeholders who may be indirectly impacted by the plugins outcome.

Primary Stakeholders

• Gary O’Neall (goneall)
• As the Founder and Principal Consultant for Source Auditor, Gary O'Neall is a primary stakeholder for the SPDX Eclipse Plugin because his general interest in SPDX Tools and other software compliance tooling.
• Linux Foundation's SPDX Workgroup

Secondary Stakeholders

• Source Auditor
• Because of Source Auditor's interests in software compliance, they are a secondary stakeholder because they may utilize the SPDX Eclipse Plugin utilizing many SPDX tools Gary O’Neall developed.
• Eclipse IDE Users
• Individuals who utilize Eclipse and are also interested in software compliance may use the SPDX Eclipse Plugin to find and add licenses to software projects.

Communication Plan

A communication plan plays an integral role in keeping a project on task. In order to promote project efficiency for the SPDX Eclipse Plugin the project administrators developed their own.

Project Management Methodology

To make project communication easier between project administrators and collaborators, the agile scrum project management methodology is used by the team because it promotes rapid development with little documentation required. Learn more, here.

Team Meetings & Communication

The project administrators currently host 3 types of meetings to gauge project progress, outlined below:

Topic	Information	Media	Frequency	Days & Times
Status	Weekly Status Issues and Challenges	In-Person	2x / Week	Mon / Wed, 4:15 pm - 4:30 pm
Backlog Refinement	Backlog Grooming	In-Person	Weekly	Mon, 4:30 pm - 5:30 pm
Retrospective		In-Person	Monthly	1st Mon of Month, 4:45 pm - 5:30 pm

If you would like to take part in team meetings, please contact rbeasley@unomaha.edu.

Administrator Roles

Listed below are the current administrators for the SPDX Eclipse Plugin and their respective roles and responsibilities for the project:

####Tyler Filkins (TCF-30)

Systems Architect	Database Administrator	Application Developer
Maintain System Requirements Establish Source Code Hierarchy Manage System Backups Manage System Nightly Builds	Database Point of Contact Optimize Database Performance Modify Database Structure (As Needed)	Develop Source Code Maintain Existing Source Code Unit Test Developed Source Code Maintain Documentation for Source Code

####Ryan Beasley (ryanbeaz)

Project Manager	User Experience Designer	Application Developer
Manage Issues and Backlog Maintain Development Schedule Maintain Project Documentation Organize Team Meetings	Develop an Intuitive Plugin Interface Exceed User Needs While Designing Plugin Interface	Develop Source Code Maintain Existing Source Code Unit Test Developed Source Code Maintain Documentation for Source Code

Use Cases

Format

TITLE: [USE CASE TITLE]

1. NAME: [some variation of the title]
   
2. DESCRIPTION: [brief description of situation, use to provide necessary background]
   
3. PRIMARY ACTOR(S): [who's goal is being met, has primary interest in outcome]
   
4. PRE-CONDITIONS: [required conditions for the use case to occur]
   
5. POST-CONDITIONS
   

• END ON SUCCESS: [condition required to be met]
  
• END ON FAILURE: [condition for which the primary actor's goal was not achieved]
  

6. MAIN SUCCESS SCENARIO [the most straight-forward scenario where the primary actor(s) accomplishes their goal]
   

• FLOW OF EVENTS:
  1. step 1
  2. step 2
  3. step 3
  ...

Cases

#1

######TITLE: A User Installs SPDX Eclipse Plugin

1. NAME: Install SPDX Eclipse Plugin
   
2. DESCRIPTION: A developer using Eclipse IDE for open source software projects installs the SPDX Plugin for maintaining lincensing & copyright information within their source code.
   
3. PRIMARY ACTOR(S): The developer/user
   
4. PRE-CONDITIONS:
   - User must have Eclipse IDE installed
5. POST-CONDITIONS
   

• END ON SUCCESS: SPDX Eclipse plugin installed successfully and is available for use
  
• END ON FAILURE: Install failed for SPDX Eclipse plugin
  

6. MAIN SUCCESS SCENARIO
   

• FLOW OF EVENTS:
  1. User downloads source files in .zip format from the SPDX Eclipse Plugin Github repository
  2. User opens up the Install wizard in the Eclipse IDE using the following path starting from the Menu bar: Help -> Install New Software -> Add -> Archive 3. User travels to where the source files were downloaded and selects the .zip file for install
  

#2

######TITLE: A User Creates an SPDX File for a new Eclipse Project

1. NAME: Create SPDX File for new Eclipse project
   
2. DESCRIPTION: The user has open source software within an Eclipse IDE project repository and would like to create an SPDX file for the licensing & copyright information in the project source code
   
3. PRIMARY ACTOR(S): The developer/user
   
4. PRE-CONDITIONS:
   - User must have FOSSology installed and running locally - User must have DoSOCS installed and running locally - User must have Eclipse IDE installed - User must have licensing and/or copyright information in the Eclipse project source code
5. POST-CONDITIONS
   

• END ON SUCCESS: The Eclipse project contains an SPDX file for all licensing & copyright information discovered within the project
  
• END ON FAILURE: No SPDX file is created and/or no legitimate licensing or copyright information was found during the project repository scan
  

6. MAIN SUCCESS SCENARIO
   

• FLOW OF EVENTS:
  1. User executes the SPDX Eclipse plugin and the plugin's UI is displayed
  2. User specifies the path to the Eclipse project to be scanned in the SPDX plugin target input field and clicks 'Start'
  3. The SPDX plugin commands FOSSology+SPDX to scan the project with the options set for SPDX file output
  4. The SPDX plugin receives the project SPDX file from FOSSology+SPDX and places it in the projects directory

#3

######TITLE: A User Updates an SPDX File for an Eclipse Project

1. NAME: Update SPDX File for Eclipse Project
   
2. DESCRIPTION: The user has open source software within an Eclipse IDE project repository and would like to update an existing SPDX file for the licensing & copyright information in the project source code
   
3. PRIMARY ACTOR(S): The developer/user
   
4. PRE-CONDITIONS:
   - User must have FOSSology installed and running locally - User must have DoSOCS installed and running locally - There must be an existing SPDX document within the project repository to update
5. POST-CONDITIONS
   

• END ON SUCCESS: The project contains an updated SPDX document accurately reflecting the changes made in the source code, overwriting the original SPDX document that was already there.
  
• END ON FAILURE: No SPDX document is found in the project or the original SPDX document has not been modified to reflect the licensing & copyright information change(s)
  

6. MAIN SUCCESS SCENARIO
   

• FLOW OF EVENTS:
  1. User executes the SPDX Eclipse plugin and the plugin's UI is displayed
  2. User specifies the path to the Eclipse project to be scanned in the SPDX plugin target input field and clicks 'Start'
  3. The SPDX plugin commands DoSOCS and FOSSology to scan the project with the options set for SPDX file output
  4. The SPDX plugin receives the new SPDX file from DoSOCS and places it in the project's directory, overwriting the original SPDX file.

Data Flow Diagram