AzureDevops

Azure Devops Plugin

The Azure Devops plugin expects certain workitems and fields in the workitems to be defined in the Azure Devops system. Without these, the system will not work. In this document we'll take a look at the way Azuredevops should be configured.

Azure Devops Plugin Setup

First we'll take a look at how to configure the Azure Devops plugin once all work items types are in place and you are ready to start using RoboClerk with Azure Devops. The configuration file contents are as follows:

# This is the RoboClerk AzureDevOps plugin configuration

AccessToken = "<THE ACCESS TOKEN>"
OrganizationName = "<ORGANIZATION NAME>"
ProjectName = "<NAME OF PROJECT>"

# The following allows you to indicate the work item names that map
# to various entities in the RoboClerk software

SystemRequirement = "Epic"
SoftwareRequirement = "User Story"
DocumentationRequirement = "Documentation"
DocContent = "DocContent"
SoftwareSystemTest = "Test Case"
Risk = "Risk"
Anomaly = "Bug"
SOUP = "SOUP"

# certain items in azure devops should be ignored because they are no longer
# relevant. Indicate which item statuses should be ignored.

Ignore = [ "Removed" ]

As you can see, the configuration file contains a lot of the documentation you will need to understand it. Some things to note. In order to obtain an access token, you must login to Azure Devops and follow the instructions here. Enter the name of the organization and the project and then create your mapping. The mapping shows how Azure Devops work items map to trace entities in RoboClerk. For example, in the above, the workitem called "Documentation" maps to the "DocumentationRequirement" trace entity in RoboClerk. The reason to have a mapping like this is to enable organizations to use their own names for the various ISO62304 entities. If you would like to call a "SystemRequirement" a "ProductRequirement", in the case of SaMD for example, then this mapping allows you to do that.

Azure Devops Workitem Setup

Unfortunately, Azure Devops only allows processes (i.e. the set of workitem types and their configuration) to be exported and imported in a very specific system configuration. I have been unsuccessful trying to export my RoboClerk customized process from Azure Devops, please contact me with suggestions. I've created a public project on azure devops that has examples of each type of workitem in it. This can be used as an overall example, it also shows how RoboClerk expects the different workitems to be connected to each other. Below is a list of the workitems and the required custom fields (with the field type) that should help you recreate the process. The field names should match exactly. Remember that you can name these work item types any way you like as long as you provide the mapping in the configuration file. I will be using the names as provided above in the sample configuration.

• Workitem: Epic
  • Fieldname: Category of Requirement
    • Type: Text (single line)
• Workitem: User Story (Note: acceptance criteria are not used)
  • Fieldname: Category of Requirement
    • Type: Text (single line)
• Workitem: Documentation
  • Fieldname: Category of Requirement
    • Type: Text (single line)
• Workitem: DocContent
  • Fieldname: Category of Content
    • Type: Text (single line)
• Workitem: Test Case
  • No custom fields, automation status is used to indicate if a test is automated or not. To indicate a test is manual, enter "Not Automated" into the text field.
• Workitem: Risk (note: RoboClerk assumes an FMEA based approach to risk assessment)
  • Fieldname: Risk Type
    • Type: Picklist (string)
      • Items in this picklist can indicate the category of risk
  • Fieldname: Hazard
    • Type: Picklist (string)
      • This depends on what the primary hazards are associated with your device(s). I like to use a picklist as it can help guide people to picking the right hazard. For a diagnostic device this could be false positive, false negative, no result, etc.
  • Fieldname: Hazard Severity
    • Type: Picklist (integer)
      • The range of values here depends on the way you perform your risk assessment. This could be 1 to 5 or 1 to 10 or anything you'd like to use.
  • Fieldname: Hazard Probability
    • Type: Picklist (integer)
      • Similar to severity, the actual range used here depends on your process.
  • Fieldname: Detection Method
    • Type: Text (single line)
      • Describe how the hazardous situation could be detected.
  • Fieldname: Detection
    • Type: Picklist (integer)
      • The range used here depends on your process. The easier to detect, the lower the number.
  • Fieldname: Risk Control Category
    • Type: Picklist (string)
      • How is the risk controlled? E.g. Documentation, Software Design, System Design, User Training, Transfer to Production
  • Fieldname: Residual Probability
    • Type: Picklist (integer)
      • This range will depend on your process. This is meant to indicate the likelihood that a hazardous situation will occur after the risk has been mitigated.
  • Fieldname: Residual Detectability
    • Type: Picklist (integer)
      • This range will depend on your process. This is meant to indicate how detectable a hazardous situation is after the risk has been mitigated.
• Workitem: Bug
  • Fieldname: Justification
    • Type: Text (multiple lines)
      • This is a field from the CMMI process that I added. It is meant to capture the justification of why the bug/anomaly is ok to leave open (if this bug has not been closed at the end of the development).
• Workitem: SOUP (the title of this workitem should be the name of the SOUP)
  • Fieldname: End User Training
    • Type: Text (multiple lines)
      • Describe how the end users will be trained. Only applicable if the end user needs training to use the SOUP.
  • Fieldname: Version
    • Type: Text (single line)
      • The version indicator for the SOUP, e.g. 1.0.2
  • Fieldname: Linked Library
    • Type: Boolean
      • True if the SOUP is a library linked into the medical device software
  • Fieldname: Critical for Performance
    • Type: Picklist (string)
      • Whether this SOUP can directly impact the essential performance of the device, this usually indicates a high risk SOUP. Roboclerk will record both the text provided in the picklist as well as a boolean value based on the fact if the word "not" is present in the text (not means false, not critical for performance).
  • Fieldname: Critical for Cybersecurity
    • Type: Picklist (string)
      • Whether this SOUP can directly impact the Cybersecurity of the medical device. Handled in the same way as the "Critical for Performance" field.
  • Fieldname: Anomaly List Examination
    • Type: Text (single line)
      • Describe the result of the examination of the anomaly list for the SOUP. Depends on your process if/when this needs to happen.
  • Fieldname: End User Installation Required
    • Type: Picklist (string)
      • Either end user installation of the SOUP is required or not. Handled in the same way as the "Critical for Performance" field.
  • Fieldname: License
    • Type: Picklist (string)
      • A list of different licenses that a SOUP may have. Recording the license is not important for ISO62304 compliance but it is a good idea for a variety of reasons.
  • Fieldname: Manufacturer
    • Type: Text (single line)
      • The manufacturer of this SOUP.

Once both Azure Devops and the RoboClerk plugin are configured correctly, you can attempt to run RoboClerk. Good luck!