Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents
maxLevel2
stylesquare

01 February 2021 - Updated Technical Debt computation (20.2.0)

The Technical Debt time cost for each remediation level has been revised, to produce a less costly Technical Debt result.

...

Note: It is possible to go back to the previous computation (for Squore versions prior to 20.2.0), by overloading the "remediation_costs.xml" file.
To overload this file:

...

  • Technical Debt values will produced lower values than in previous Squore versions (prior to 20.2.0)

  • Reapply Model will impact old versions of a project where Technical Debt is computed


03 December 2020 - Constant data counting has been included into the model (20.2.0)

  • Three metrics have been created (VPBL, VPRV, VPRT), to count scoped data (Public, Private, Protected) while ignoring constants
  • Constants are still counted by specific metrics (CPBL, CPRV, CPRT)


Potential Impact

  • The complexity (CPXT_OWN) for CLASS has been updated to use VPBL instead of APBL for types "JAVA_CLASS;CPP_CLASS;CSHARP_CLASS;JAVA_ENUM"
  •  Also, since VPBL is computed for types "ABAP_CLASSDEF;JAVA_INTERFACE", CPXT_OWN is also defined for these types (but the FCCENTROID computation only contains VPBL, all other indicators are CLASS-only)
  • In addition, the grammar for ABAP has been updated so rename the three metrics (DPBL, DPRV, DPRT) into (APBL, APRV, APRT)

06 March 2020 - Updated cloning metrics for backwards compatibility (20.0.0)

...

Their computations has been updated so that: if CCLC is not available (i.e. <0), LC is used instead

Potential Impact

  • No impacts on projects where CCLC is not available

  • Reapply Model will also have no impact on old versions of a project where CCLC is not available
  • If a project contains old versions where CCLC is not available, and is rebulid with a Squore version where CCLC is available, these three metrics will evidently be computed differently

...

The existing 'Testability detection mode' parameter has been extended. It now proposes a third option, which sets the Testable state for a Requirement as soon as it is linked to Tests artefacts.

This option is available in the Squore Form at project building scope.


Potential Impact

  • No impacts on existing projects, as it is a new option on an existing attribute.

Details

  • The associated tag 'REQ_TESTABILITY_MODE" corresponding values are 0, 1, 2 for the three modes.




04 February 2020 - Requirements 'Coverage override' added to Software Analytics (20.0.0)

It is now possible to manually set a requirement's coverage state. Three behaviors are available: 

  • Use the coverage computation based on linked Test Results (default behavior)
  • Force the coverage as 'Not Covered'
  • Force the coverage as 'Covered'

The user has to provide a justification for changing this behavior.

This option is available in the Squore Form at the Requirement artefact scope.


Potential Impact

  • No impacts on existing projects, as the default value for this new tag sets the old behavior (use the coverage computation)



04 February 2020 - Tests 'Status override' added to Software Analytics (20.0.0)

It is now possible to manually set a test status. Four behaviors are available: 

  • Use the status returned by the external tool which provided the test to Squore (default behavior)
  • Force the status to 'Passed'
  • Force the status to 'Inconclusive'
  • Force the status to 'Failed'

The user has to provide a justification for changing this behavior.

This option is available in the Squore Form at the Test artefact scope.


Potential Impact

  • No impacts on existing projects, as the default value for this new tag sets the old behavior (use the status provided by the external tool)



...

A new syntax is available to improve exports, so we remove the call to the old scripts "sqexport.pl" in Software Analytics model and Shared exports.

Potential Impact

  • The list of available exports by default.

...

  • Number of MISRA Rules
  • Number of MISRA Directives
  • Number of MISRA Rules or Directives per recommendation level
  • Number of MISRA Rules or Directives  per ISO characteristic

Potential Impact

  • The list of produced metrics contains now these additional "MISRA counting metrics" at APPLICATION level

...

To prepare for the upcoming Analysis Model Editor, the structure of the Software Analytics model as well as Shared environment have been reworked.

Potential Impact

  • Several objects (Requirements, Tickets, Tests) have been simplified in the Software Analytics model. Modelling objects that were only related to the Data Provider producing them have been removed from the Software Analytics model.
  • Several Data Providers shared configurations (located in Shared\data_provider) have been enhanced with modelling objects previously defined in the Software Analytics model.

...

A list of descriptions were imported but not used. Many mnemonics similar to IDs are removed too.

Potential Impact

  • None

Details

  • Remove useless lines on descriptions bundle: <Properties src="..." />

...

  • the Technical Debt 'Changeability' computation has been updated
  • some violation occurrences counting metrics are now restricted to 'Non conformity' and 'Risky practice' natures

Potential Impact

  • The Changeability Technical Debt value is now more accurate, and may increase

  • The 'Coding Rule Violations' chart ('Quality Assurance' dashboard) is more accurate, and may display fewer values

...

  • Generate findings of 'Risky Construction' nature based on ORANGE, RED, GRAY type RTE checks
  • Take into account derogations from Polyspace (both on RTE checks and MISRA checks)

Potential Impact

  • The Violation density, which now takes into account Risky Construction findings, might increase

  • The Compliance, since MISRA derogations are now taken into account, might decrease if some MISRA violations are derogated in Polyspace

...

New highlight is available: 

Potential Impact

  • None

Details

Technical Debt is the "own" technical debt of every modules. Modules without Technical debt are filtered. 

...

Graphs have been reworked so they can be lifterable.




Potential Impact

  • Metrics which were used to compute the graphs have been removed from the models.

...

  • UNKNOWN_AGREGATED_STATUS
  • UNKNOWN_TYPE

Potential Impact

  • This will mark existing Software Analytics projects as obsolete because of the new 
  • When the violation disappears, your project rating may improve

...

The rule provided false positives for C#

Potential Impact

  • Removing the rule will remove the false positives findings for C# projects
  • When the violation disappears, your project rating may improve

...

20 Mar 2018 - Remove obsolete files (18.0.0)

Potential Impact

Missing xml or properties files on customers configuration.

...

6 Mar 2018 - Add a Test Gap Analysis Treemap (18.0.0)

Potential Impact

This works only for project which have Test artifact (from VectorCAST, RTRT, GoogleTest...)

...

6 Mar 2018 - Removing confusing NSI (18.0.0)

Potential Impact

NSI measure and indicator have been removed to avoid confusing statement for end user. 

...

In order to make it easier to add more languages to Squan Sources (documentation), the GENERIC_FILE and GENERIC_FILES types were added by default in Configuration/models/Shared/data_provider/squan_sources/artefact_types.xml

Potential Impact

You configuration may report errors if you have not added these types as well.

...

13 Feb 2018 - Old models removed (18.0.0)

Potential Impact

If your model is based on the following model list, please, contact us to retrieve a package that contains the old model files.

...

30 Jan 2018 - Color Update in Technical Debt trend (18.0.0)

Potential Impact

None. This is only a GUI feature. 

...

29 Jan 2018 - Adding Background color in highlight (18.0.0)

Potential Impact

None. This is only a GUI feature. 

...

18 Jan 2018 - New Technical Debt computation in Software Analytics (18.0.0)

Potential Impact

Functionality and results are completely identical but in order to reduce the number of impacted measures in the formula, some optimisation have been implemented. 

...

18 Jan 2018 - Artefact Status update (18.0.0)

Potential Impact

Formula has been updated due to update of SI into PERCENT format. 

...

15 Dec 2017 - Update Automotive Ruleset (18.0.0)

Potential Impact

The MISRA rules from Squore have been set as MISRA rules (and not considered as information anymore). 

...


01 Dec 2017 - Add a new Productivity KPI (18.0.0)

Potential Impact

The KPI is based on the changes (lines added, modified or removed) regarding the number of elapsed days.

...

28 Nov 2017 - Add a new Report for Automotive Standard Compliance (18.0.0)

Potential Impact

A modification (=fix) has been operated in Shared\Analysis\product_quality\automotive\stats\function_stats.xml

...

11 Dec 2017 - providedBy attribute in Rulesets (17.0.9, 17.1.4)

Potential Impact

We are changing the way the Rule Compliance indicator is computed, and you may need to replicate this change to get this feature if you are overriding:

...

11 Dec 2017 - General Cleanup (17.0.9, 17.1.4)

Potential Impact

None, we are just tightening the XSD schema and ensuring that all files in the configuration pass validation

...

24 Nov 2017 - Add a Project Status tag at application level (18.0.0)

Potential Impact

A tag "Project Status" has been added into Automotive model so the end user can filter project in the portfolio view. 

...

24 Nov 2017 - Update of Project Summary Table (18.0.0)

Potential Impact

The project summary table (model level) has been reworked so it displays "?" if the KPI is not activated. 

...

24 Nov 2017 - Integration of Test Effectiveness in automotive model (18.0.0)

Potential Impact

The score can be impacted because Test Effectiveness has been introduced in the rating formula.

...

22 Nov 2017 - Remove duplicated FindBugs rules definitions (18.0.0)

Potential Impact

The score can be impacted because the categories are changed and the counting of rules by category changed.

...

22 Nov 2017 - Remove duplicated FindBugs rules definitions (18.0.0)

Potential Impact

The score can be impacted because the categories are changed and the counting of rules by category changed.

...

21 Nov 2017 - Remove useless level dependent metrics in Software Analytics Model (17.0.8, 17.1.3)

Potential Impact

N/A

Details

Remove A_STAT, B_STAT, C_STAT, ... measures of the Software Analytics Model, these metrics were only used in temporal distribution, advantageously replaced by a TESStackedBar on the "LEVEL" indicator weighted by the STAT measure.

...

21 Nov 2017 - Remove useless language dependent metrics in Software Analytics Model (17.0.8, 17.1.3)

Potential Impact

N/A

Details

Remove all <language>_LC and <language>_SLOC measures of the Software Analytics Model, these metrics were only used in languages distribution, advantageously replaced by a SimplePie on the "LANGUAGE" information weighted by the SLOC measure.

...

15 Nov 2017 - New Metrics in Software Analytics Model (17.1.2)

Potential Impact

N/A

Details

The following metrics have been added:

...

15 Nov 2017 - New Metrics in Squore Automotive Model (17.1.2)

Potential Impact

N/A

Details

The following metrics have been added:

...

13 Sept 2017 - Add a new "Off" level (17.1.0)

Potential Impact

Default rating shall be identical. The graphical changes remains in the icon of the rating. "?" is replaced by "Off". 

...

12 Sept 2017 - Integration of Clone Tracker "Suspicious Detection" Feature  (17.1.0)

Potential Impact

Default rating shall be identical. 

...

6 Sept 2017 - Correct the relaxation mechanism for SDESCR (17.0.6)

Potential Impact

Default rating shall be identical. 

...

31 Aug 2017 - Added support for COBOL paragraphs and sections (16.3.4, 17.0.5)

Potential Impact

The new artefact types (COBOL_SECTION and COBOL_PARAGRAPH) are not used by default, but including them in the model causes previous analyses to be marked as obsolete.

...

31 Aug 2017 - Added rulesets for FxCop and StyleCop (16.3.4, 17.0.5)

Potential Impact

More rules are enabled in Software Analytics, which may result in your projects having a different Rule Compliance than before.

...

20 Jan 2017 - New findings for Squan Sources (16.2.4)

Potential Impact

Changed rule count for projects using Squan Sources (all languages)

...

19 Dec 2016 - Moved code_review module (16.2.3)

Potential Impact

update your <xi:includes /> in your bundles

...

19 Dec 2016 - Updated System Engineering modules (16.2.3)

Potential Impact

Modified metrics if you previously included the modules in your model

...

19 Dec 2016 - Removed default value for rules in pylint ruleset (16.2.3)

Potential Impact

N/A

Details

Removed default value for rules in pylint ruleset in Shared/data_provider/pylint/ruleset.xml

...

19 Dec 2016 - New ScaleLevel in SCALE_NATURE (16.2.3)

Potential Impact

N/A

Details

Added a new ScaleLevel to SCALE_NATURE in Shared/basic_scales.xml

...

3 Nov 2016 - Removal of non-multi-language models (16.2.0)

Potential Impact

If your model included any of the files in these folders, retrieve them from your current installation before you upgrade so you can move them to your custom configuration.

...

3 Nov 2016 - New Modules (16.2.0)

Potential Impact

N/A

Details

  • Shared\Analysis\product_quality\generic
  • Shared\Analysis\product_quality\function_point

3 Nov 2016 - Squore Cloning Ruleset and SCALE_NATURE Update (16.2.0)

Potential Impact

N/A

Details

  • The ruleset for cloning has been modified: Shared\data_provider\squan_sources\ruleset.xml

     SCALE_NATURE.NON_CONFORMITY;SCALE_SEVERITY.INFORMATION 
     =>  SCALE_NATURE.CLONING;SCALE_SEVERITY.xxx
    

    The associated scale SCALE_NATURE has been modified, with the addition of a CLONING scale level:

     \Shared\Analysis\basic_scales.xml
    
        <Scale scaleId="SCALE_NATURE">
            <ScaleLevel levelId="NON_CONFORMITY" bounds="];0[" rank="0" />
            <ScaleLevel levelId="RISKY_PRACTICE" bounds="[0;0]" rank="1" />
            <ScaleLevel levelId="RELAXATION" bounds="]0;1]" rank="2" />
            <ScaleLevel levelId="TEST" bounds="]1;2]" rank="3" />
            <ScaleLevel levelId="GUIDELINE" bounds="]2;3]" rank="4" />
            <ScaleLevel levelId="METRIC" bounds="]3;4]" rank="5" />
            <ScaleLevel levelId="CLONING" bounds="]4;5]" rank="6" />
        </Scale>



3 Nov 2016 - Code Status Moved (16.2.0)

Potential Impact

Update your includes

Details

Folder has been moved from Shared\Analysis\product_quality\automotive\code_status to Shared\Analysis\product_quality\generic\code_status

Info: generic should contain generic definition for software KPI such as "criticality" (=ASIL)



3 Nov 2016 - Risk Index deprecation - Software Analytics introduction (16.2.0)

Potential Impact

N/A

Details

With the addition of the Software Analytics model, which will become the standard model in Squore 17), the older Risk Index model is now hidden by default.

If you used it to create some projects, reactivate it by editing your properties.xml (at the root of your top configuration folder by copying the one from the standard configuration and removing the line:

...
<hideModel name="risk_index" />
...


If you do not want to see this wizard when you create a new project, update your properties.xml at the top of your configuration folder and add the line:

...
<hideModel name="software_analytics" />
...

27 Jun 2016 - Supporting Meta Projects (16.1.0)

Potential Impact

A new artefact type is necessary to work with meta projects in your model

Details

If you plan to use meta-projects and are not using the standard artefact types included in Squore, you will need to change your models to add the SUB_APPLICATION type, as described here




6 Apr 2016 - Renamed Analysis Model Editor file (16.0.0)

Potential Impact

A new artefact type is necessary to work with meta projects in your model

Details

If you previously used the Analysis Model Editor to turn off some rules in your model, the Bundle.xml file in the Analysis folder of your model looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<Bundle xmlns:xi="http://www.w3.org/2001/XInclude">
  <xi:include href="AMEBundle.xml" />
  (...)
</Bundle>

AMEBundle.xml is the file where the rules that were turned off were located.

With the changes made to improve the Analysis Model Editor in Squore 16:

  • it is no longer necessary to include the AMEBundle.xml in your Bundle.xml
  • AMEBundle.xml must be renamed to editor.xml

If you do not make these changes, the modifications defined in AMEBundle.xml will be treated as part of the model, not as modifications to the existing model anymore.


7 Oct 2015 - Renamed C alias to CTYPES (15-A-SP2)

Potential Impact

The minimum length for IDs in the configuration is 2 characters from now on. We renamed the C alias in the configuration to CTYPES in the configuration to comply with this new requirement. You may have to do the same if you use IDs under 2 characters.

Details

The main breaking change in since Squore 2015-A-SP2 is that it is now forbidden to use measure names and artefact types that are under 2 characters.

This means that if you had defined an artefact type called "C", this is no longer allowed.

For example, where previous versions defined an artefact type called "C":

<ArtefactType id="C" heirs="C_FILE;C_HEADER;C_FUNCTION" />

and used it in various rulesets as shown below:

<Measure measureId="BUFFERACCESSOUTOFBOUNDS" type="RULE" toolName="CPPCHECK" targetArtefactTypes="C;MINDC;CPP" />

This now needs to be rewritten as:

<ArtefactType id="CTYPES" heirs="C_FILE;C_HEADER;C_FUNCTION" />

and referenced as shown below:

<Measure measureId="BUFFERACCESSOUTOFBOUNDS" type="RULE" toolName="CPPCHECK" targetArtefactTypes="CTYPES;MINDC;CPP" />

...