Summary
    Baseline v2
    Empty

    Overview

    The following section is the result of tests, demo, exchanges with early deliveries of baseline.

    Use case: know the content of a Delivery

    Context ASPICE (Automotive Software Process Improvement and Capability dEterminitation)

    A Delivery is made of an umbrella artifact, linked to "many" others (up to 200) that corresponds to parts of a system (components, blocks, etc). In this context the data are "medium size" (enough elements to make manual selection painful but not enough to make automated processing expensive) but mostly flat (2 levels of hierarchy).

    The Delivery is an ad-hoc structure that cannot map to current Baseline based Scrum Milestone organization. In this context Baseline will help teams because it can answer the question "what was the status at this point of the time". The "point of the time" in this case could be an audit, a delivery to customer, etc.

    When bugs are identified they should also be part of a Delivery, the key point here is to be able to know the status of bugs regarding Deliveries. It should be possible to have a baseline information when browsing the list of bugs (as column in tracker report ?). With such a feature it's easy to identify the bugs that are not part of a baseline to affect them.

    1776-image-20190524162814-2.png

    In this context, the most important feature is the baseline itself, the comparison is nice but not really useful.

    In addition to that, Baseline should be extended outside the scope of artifacts. Extract of ASPICE :

    1775-image-20190524162619-1.png

    Baseline evolutions:

    • Propose an alternative way to select the content of a baseline (artifact cherry-picking, no automated recursion)
    • Display a "Baseline" column in tracker table reports that would list all the baseline an artifact belongs to
    • Have the information about the baseline in artifact view as well (field ?)
    • Rendering of the baseline: text view not really useful. A table (like tracker reports) would be more helpful.
      • As the data are hierarchical, it will be hard to be able render a tree as a table. Possible solutions
        • render the table only when a given type of tracker is selected (to have consistent columns)
        • finalize and re-use what is planned to extend to more columns cross tracker search results
    • Integrate Documents, Code (svn, git) and Files inside baselines

    Use case: Convert people to collaborative project management

    In segment with heavy regulation, the Document (aka .docx) is king but a .docx is hardly a collaborative tool, it's mostly owned (edited & updated) by one person. That doesn't corresponds to common work practices (team, collaboration, etc). The goal would be to get the benefit of a collaborative system (always up, visible, realtime updates, notifications) while remaining compliant with regulation (.docx/pdf at the end of the day).

    There are 2 common use case:

    • Based on a delivery, being able to do a traceability follow-up of what was delivered
    • Based on a plan, keep track of what is supposed to be delivered and roadmap evolutions

    Baseline evolutions:

    • Build the baseline out of a TQL or XTQL query
    • The textual representation of Baseline should be exported to a document (PDF ?) into the Document module.
    Progress
    Empty
    Empty
    Closed
    Details
    #13407
    Manuel Vacelet (vaceletm)
    2020-06-05 10:52
    2019-05-24 13:22
    Attachments
    References

    Follow-ups

    User avatar
    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes