Home

#Welcome to the sw360rest wiki!

##1. Use Cases

###1.1 Checks of the available data

• Have all newly entered projects (of the last month) all required data fields filled in (especially pre-evaluation date, end of implementation date, system test start date, delivery start date, phase-out date)?
• Have all newly entered components all required data field filled in (meaningful description, vendor/community URL, quality information) or in other words: are the newly entered components ready to start the clearing process?
• Have all newly entered releases all required data field filled in (source code, CPE, source download URL, release date)?
• For which components/releases do we still lack clearing reports?
• For which components/releases do we still lack CLI files?

###1.2 Key Performance Indicator (KPI)

The KPIs reported to management are currently generated via Excel exports or manually. We need the API to get the following information:

• Number of projects with components/releases in clearing state 'open', including the number of cleared and open components.
• Number of components with different clearing states (open, mainline, specific, phase-out, denied) broken down by Business Unit or Business Segment.
• Number of newly added requests in a given time frame.
• Number of newly added components/releases in a given time frame.
• Number of newly cleareded requests in a given time frame, i.e. number of components where the clearing state has changed from 'none' to another state.
• Number of newly cleareded components/releases in a given time frame, i.e. number of components where the clearing state has changed from 'none' to another state.
• Number of components/releases of type OSS, COTS, INTERNAL in a given time frame.

###1.3 Status Reporting

The status information reported to management are currently generated via Excel exports or manually. We need the API to get the following information:

• PSD reporting: List of projects with components in clearing state 'open', including the number of cleared and open components.
• Monthly reporting: List of all projects per Business Unit including the information about the number of cleared and open components, the availability of Readme_OSS or Product Clearing documents and the project milestone dates.

###1.4 Product Clearing

For product clearing the following functionality is needed:

• List of components/releases per project.
• List of security vulnerabilities per components/releases per project.
• List of export control information per components/releases per project.
• List of licenses (including obligations, risks and totos) per components/releases per project.
• It should be possible to add todos to releases as well as to components as well as to projects.
• Licenses, obligations, risks and todos must be unambiguously identifiable.
• It should be possible to aggregate the Licenses, obligations, risks and todos of components/releases and product level.

###1.5 Statistics/Data Analysis

Besides the monthly reporting (to management) there is also a yearly analysis of the software clearing activities:

• List of project added per business year.
• List of requests/components/releases added per business year.
• List of processing time (step from one software clearing step to another) per request/component/release/product.

###1.6 Build Chain Integration

The R&D teams have requested more possibilities to access and/or modifiy information in SW360 in an automated way:

• Download and upload component source code.
• Download of clearing reports.

###1.7 Sync project BOM via Maven Build

1. Maven plugin reads, project name, list of dependencies of project
2. Maven plugin requests list of releases for project with name from sw360
3. If no project available on sw360 create a new one (for requested user)
4. Maven plugin updates list of releases of project according to list of dependencies. A dependency corresponds to a release if vender = groupId, name = name and version = version

##2. Technical Notes

(see Readme of project)

##3. Important Links