Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-184

SonarQube Quality Model with three characteristics

    XMLWordPrintable

    Details

    • Type: EPIC
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:
      None
    • Epic Name:
      Quality Model

      Description

      SonarQube currently provides two Quality Models :

      • The first one available out-of-the box is simplistic : all issues impact a Technical Debt amount from which we deduce a Technical Debt Ratio, from which we can infer the "Maintainability" level of the application
      • The second one, based on the SQALE quality model, contains 9 characteristics, 43 characteristics and there is an advanced concept of inheritance between characteristics -> for instance all testability issues should be considered also as some maintainability issues, which should be considered as security issues, which ... (see the SQALE pyramid)

      At the end we think that the first one is too simple and the second one too complex for most users. So out-of-the-box, the SonarQube Quality Model should become :

      • Three characteristics (orthogonal) :
        • Maintainainability
        • Reliability
        • Security
      • One type of issue associated to each characteristic :
        • Code Smell -> Maintainability
        • Bug -> Reliability
        • Vulnerability -> Security
      • The remediation function associated to each rule allows to compute an effort to fix a code smell, a bug or a vulnerability.
        • "effort" must become the world used to talk about "remediation effort" - whereas before "technical debt" or "debt" were used for that purpose
        • The "Technical Debt" must only be used when dealing with maintainability: this is the remediation effort to fix code smells
      • The rating of the Maintainability characteristic should depend upon the density of code smells. So only code smells should impact the total amount of Technical Debt and so the ratio of Technical Debt and so the Maintainability Rating.
      • The rating of the Security and Reliability characteristics should depend upon the worst severity of existing vulnerabilities and bugs :
        • At least one blocker: E
        • At least one critical: D
        • At least one major: C
        • At least one minor : B
        • No vulnerability or bug: A (green)
      • Moreover for each characteristic, it should be easy to understand what is the required remediation effort to come back to green (rating A):
        • Maintainability : amount of code smells to be fixed
        • Reliability and Security : total number of bugs and vulnerabilities to be fixed

        Attachments

          Activity

            People

            Assignee:
            freddy.mallet Freddy Mallet (Inactive)
            Reporter:
            freddy.mallet Freddy Mallet (Inactive)
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: