how to work within the Coverage Explorer fixed width?

Options
[Deleted User]
[Deleted User] Posts: 17
edited April 2017 in
We have requirements to be able to assess coverage.  We want to use Jama to achieve this via traceability and the coverage explorer.  The use case is
- examine each requirement,
  -look at the description,
- review the corresponding traced items
  -assess whether they are sufficiently covering the requirement in question.

The Coverage Explorer looks like a perfect tool for this use case, however it's not useable in its current form.  it seems like I can configure a column's width, however for each level, I can't seem to expand the view beyond the fixed width that is provided.  Without this capability, it is essentially impossible to review traceability in this view.  I could export to a 3rd party application (e.g. excel, google sheets, etc.), but isn't the idea to have Jama be the basis for 

I raised this issue with customer support and they advised me that "most users simply have the ID and Name columns configured which fits into fixed columns"

I'm curious if anyone is presently using this feature based on the limited view that Jama is providing?  

Looking at the message boards, it looks like others are exporting to a 3rd party to work around this (and to work around the limitation of how many items can be displayed per page).  

If Jama intends to be an all encompassing tool with respect to requirements traceability, then this feature needs to be improved significantly.  

Anyone else struggling with this?

Comments

  • [Deleted User]
    [Deleted User] Posts: 0
    edited September 2015
    Options
    I agree. Coverage explorer is an awesome concept, poorly implemented. We have ended up building custom reports to solve these problems, but i think minor modifications to coverage explorer would have been all that was needed.
  • [Deleted User]
    [Deleted User] Posts: 17
    edited June 2016
    Options
    Thanks, Bob.  I did see your discussion to note that others are using 3rd party tools to utilize this tool.  We have a similar use case, in that we have different levels of tracing up to a single requirement (also different types - test cases, sub-system requirements, etc.), however presently I'm less interested in analyzing the tree depth as you are.  

    I think the capability I'm looking for is more about assessing coverage.  I'd like to be able to select a requirement, ask for a set of items that trace to it (of any, or a specific type), and display those items in a consumable format for analysis.

    You're right in that I could presently use Jama to show me if I don't have anycoverage, but my goal is to know that I havecomplete coverage.

    Coverage analysis is essential in many safety critical disciplines.  I've used other requirements tools (e.g. DOORS, RequisitePro) that allow me to achieve this, without the need for a 3rd party tool like Excel.  

    Thanks for the feedback, I appreciate it!
  • [Deleted User]
    [Deleted User] Posts: 911
    edited June 2016
    Options
    Mike, thanks for bringing this up. I'm glad to see Bob and Tom popped into offer some like experience. I wanted to jump in here because I just connected with my Product team about this issue. Apparently the design of Coverage Explorer is a reflection of the constraints of our particular UI architecture, and that didn't allow for much flexibility. (IIRC you are on a hosted instance of Jama, so you would have seen the changes we've made to our List View—this is a result of switching our UI to React, and we're doing this piece-by-piece in Jama, so you'll eventually see the flexibility elsewhere in Jama.) I can't provide any sort of timeline, but improving both the UX and performance of the Coverage Explorer is on our plate.
  • [Deleted User]
    [Deleted User] Posts: 17
    edited June 2016
    Options
    Thanks Kristina, that's great news!  
  • [Deleted User]
    [Deleted User] Posts: 64
    edited June 2016
    Options
    Adding my input to provide a little more weight to Coverage Explorers limitations.

    We're just run into these issues too (fixed width & 500 row limit).

    What's caused this to arise now is we're rolling out the use of Jama to all of our development centers. As part of this activity we've created standard Coverage Views (this are created by OA as they're not project artifacts). One of these views is a top level view, showing:
    • Customer Requirements >> System Requirements >> Sub System Requirements >> Test Cases (with testCaseStatus) 
    All items show their relationship status (e.g. suspect links). This view is very powerful (for us) and is light years ahead of manually updated spreadsheets. This view sold the use of Jama to our remote project managers (although is was demonstrated on a smaller sample project).

    Now we're using Jama for our largest project, the limitations are an issue.

    Having to export to Excel feels like a step backwards.

    We run SAP, which is impossible to run without external spreadsheets & the user experience suffers. 
  • [Deleted User]
    [Deleted User] Posts: 911
    edited June 2016
    Options
    Thanks for adding more context to the need, George. I'm going to change this topic to an Idea since it's run its course as a question.
  • [Deleted User]
    [Deleted User] Posts: 64
    edited October 2015
    Options
    If you have an On-premise installation, you can change the Coverage View column width.
    On the server open:
    Tomcatwebappscontourjsjx.js

    Search for something similar** to "jx.view.trace.TraceView.TIER_COL_WIDTH = 400"

    **Note the whitespace differs across different versions of Jama.

    For us (we deploy a standard set of coverage views) a value of 522 is perfect.

    Refresh your browser to pick up the modification.

    Usual disclaimer:
    1. I'm not a Jama employee, so this modification is no approved.
    2. Modifying the Javascript is done at your own risk. 

Categories