Page tree
Skip to end of metadata
Go to start of metadata

Enhancement node - Right hand panel


The Enhancement node has been designed in response to a specific issue. Please read below to find out more information.

Background

In previous versions of CAST, when examining Function Point data between successive snapshots it became clear that a large quantity of Function Points were being flagged as "modified" with a discrepancy compared to the actual number of artifacts that were flagged as modified. As such, this was preventing users from gathering reliable information about what had really changed between two snapshots. The Enhancement feature is a direct response to this issue.

The concept of items (Data Functions/Transactional Functions) that have been added and deleted between snapshots is relatively easy to comprehend, however, an item that is flagged as modified is more complex: in basic terms an item is flagged as modified when its checksum value is deemed to have changed since the previous snapshot. However, an item has a checksum value that is the sum of the checksum values for ALL of the objects that form the original item:

  • the initial object (the Data Function/Transactional Function)
  • the data function record objects that are used by the entry-point object (tables and persistence objects described as data entities or end-points)
  • all objects that are located on the call graph between the entry and end-point objects.

If any of these objects change between successive snapshots, then the overall item checksum value will change and the item will be flagged as modified. For example, an added or removed comma or white space would cause a change in the checksum value. Modified Function Points are the sum of the Function Point values for each modified item - as such it was not uncommon to find that changing something very trivial in one object that was shared between multiple items caused a large number of items to be flagged as modified between snapshots, thus making the Modified Function Point value also very high.

Enhancement feature

In essence the Enhancement feature provides a detailed presentation of both Data Functions / Transactional Functions in separate nodes:

Each node contains a list of snapshots (Upper left panel) and a list of all objects present in the selected snapshot (Upper right panel) allowing you to understand why certain items have been marked as modified/added/deleted between snapshots. The Enhancement feature will identify all the objects that form each item (displayed in the Lower panel) and between how many items each object is shared (only available for Transactional Functions: a Transactional Function can belong to more than one "item" - see the Shared Counter option below). Once the object identification is complete you can then decide whether an object or objects should be included or excluded in the checksum value calculation for all items (Data Functions/Transactional Functions). When you have included or excluded an object from the checksum value calculation, you can then re-calculate (using the Recompute checksums and snapshot statuses option) all checksums for all items and all snapshots. The metrics (in particular the modified function points metric) are then also re-calculated based on the new checksum values and will be redisplayed in the Upper left panel allowing you to check whether the value is more in line with expectations.

Measures used to calculate enhancement Function Points

CAST AIP uses two distinct measures to calculate enhancement Functions Points - these can be chosen when you generate a snapshot with the CAST Management Studio:

OMG Automated Enhancement Points (AEP)

Note that this measure is used by default from CAST AIP 8.2.x onwards.

CAST integrates the estimation of OMG Automated Enhancement Points (AEP). Like EFP, the feature helps to evaluate overtime the size of evolutions implemented by teams producing applications. It computes and displays data functions and transactional functions that have been modified, added, or deleted, and information on the technical components of applications that do not belong to any transaction. The unadjusted function points that are calculated are weighted with Complexity Factors based on the objects complexity.

The AEP measure considers both the functional and the technical sides of the application enhancement. Therefore, the computation of Automated Enhancement Points (AEP) is divided in two sections: Automated Enhancement Function Points (AEFP) and Automated Enhancement Technical Points (AETP). The total AEP will be the addition of these two: AEP = AEFP + AETP.

AEFP Computation

The total value of Automated Enhancement Function Points (AEFP) is calculated by adding the AEFP value of all Transactional Functions and Data Functions in the application. The AEFP of each individual Transactional Function / Data Function is calculated by multiplying its FP value by its Complexity Factor (AEFP = FP x CF). The Complexity Factor of a certain Transactional Function / Data Function is an adjustment factor (defined by an OMG-specification) which is calculated based on its status (added / modified / deleted) and the complexity of the objects inside the Transactional Function / Data Function.
NOTE: the value reported for AEFP includes only added, modified and deleted Functions. All unchanged Functions are automatically excluded from this value (their Complexity Factor is considered as 0, and thus their AEFP value will also be 0).

AETP Computation

Automated Enhancement Technical Points calculation considers all technical objects in the application, i.e. those computational elements which are not the Automated Enhancement Function Point scope.

OMG Enhancement Function Points (EFP)

In addition to AEP, CAST also integrates the estimation of Enhancement Function Points (EFP) also called Project Function Points, so that CAST provides both baselining, e.g sizing an entire application using Automated Function Points and Enhancement Function Points. With the Enhancement Function Points feature, CAST AIP is in a position to display detailed information about the changes between two versions of an application and between two snapshots of the same application.

This feature helps to evaluate overtime the efficiency of teams producing applications. It is particularly useful in outsourcing contexts as many outsourcing contracts are based on FP when it comes to determine the size of the deliverables. This feature computes and displays data functions & transactional functions that have been modified, added or deleted. For each application, CAST AIP will provide 3 different pieces of information:

  1. Added FPs: FPs identified from the functions identified as created in the Vn+1 (i.e. that is added by the enhancement project)
  2. Modified FPs: FPs counted because existing function is changed during the enhancement project
  3. Deleted FPs: function points counted for function deleted during the enhancement project. 

Differences between the two measures

The main differences between the legacy Enhancement Function Points (EFP) mode and the Automated Enhancement Points (AEP) mode (introduced in CAST AIP 8.2) are as follows:

  • EFP does not consider the technical side of the application evolution; AEP does (calculating Automated Enhancement Technical Points, AETP)
  • EFP uses a transaction reduced call graph (from Entry Points to End Points / Data Entities); whereas AEP considers the transaction full call graph (it covers also the paths that do not reach an End Point / Data Entity). This means that the number of objects in the transaction call graph for AEP is higher.
  • The adjustment factor used to calculate Enhancement Function Points (EFP) is called "Impact Factor", and it is based on fixed user-defined formulas; on the contrary, the adjustment factor to calculate Automated Enhancement Function Points is called "Complexity Factor", and it is based on dynamic OMG-defined formulas.

The table below summarizes these differences:

Mode Transaction Call Graph Adjustment Factor Evolution
EFP Reduced Impact Factor (fixed user-defined formula) Only Functional
AEP Full Complexity Facto r(dynamic OMG-defined formula) Functional and Technical

Note about switching between measurement modes

When changing the measurement mode it is important to take into consideration the impact this will have on the analysis/snapshot results and that it will introduce a disruption into the measurement trending. There are important differences between the two measures (AEP and EFP) that must be understood:

  • The EFP mode does not manage the technical part of application whereas AEP does.
  • When using EFP mode, Transactional Functions are based on the reduced call graph whereas for AEP, Transactional Functions are based on the full call graph.
  • The AEP specification defines Complexity Factors based on artifacts' complexity or changes made to data entities.

When moving from EFP to AEP to get more precise values, results will show objects that do not belong to the reduced transaction call graph as "added" and this will impact the measure, even if these objects have not really been added. Points related to the technical part of the Application will also appear in the results. Moreover, taking in to account object complexity to weight the FP values will impact the results as well.

Moving in the opposite direction from AEP to EFP will result in having objects that do not belong to the full transaction call graph to be considered as "deleted". This will also impact the results, even if those objects have not been really removed. In addition, Complexity Factors will be replaced by Impact Factors that are set to 1 by default and points related to the technical part of the application will disappear.

If you plan to change the measurement mode, it is necessary to recreate a new baseline snapshot. To do that, after you change the measure you must generate a new snapshot for the same Application version but it must not be considered as consistent for the new measure. The next snapshot you generate for the Application will be consistent and can be used as the first snapshot using the new enhancement measure.

Enhancement panel

The data in this panel is automatically fetched from the database server and displayed when selecting the node. The data presented here represents the "evolution" of the Function and Technical Points between successive snapshots.

By default the data for the most recent snapshot will be displayed when the node is selected. If there is only one snapshot present for the selected Application, then data will show Added Function Points for both Transactional Functions and Data Functions. When more than one snapshot is present, the data show is a comparison between the current and previous snapshot. In this case, you may see Modified and Deleted Function Point data as well as Added.

Prev. / Next buttons

It is possible to see data from a previous/next snapshot by clicking the Previous or Next buttons - data in the panel will refresh automatically.

Export List of Objects

This button can be used to export the list of technical objects that are involved in the Automated Enhancement Technical Points (AETP) calculation for a given snapshot (note that this feature will be available only for the snapshots computed using AEP measure). The output CSV file will contain the following values:

  • Object ID

  • Name

  • Full name

  • Type

  • Status

  • Effort Complexity

For example:

Note about Automated Enhancement Technical Points (AETP)

AETP is the count of added / modified / deleted technical points, which are calculated based on the added / modified / deleted technical objects (i.e. objects which are not part of any transaction). In other words, AETP summarize the evolution performed in the application, but outside the functional scope (these objects are not taken into account in the functional points, so the new AEP measure introduces the concept of "technical points" to assess the enhancement done in these types of objects).

AETP data is not available when the EFP measure has been used to calculate the snapshot.

Data Functions/Transactional Functions sub nodes

Data is then presented in a node specific to Data Functions or Transactional Functions:

Each node is identical - each panel is explained in more detail below:

Upper left panel (Evolution)

This panel lists all existing snapshots stored in the CAST Dashboard Service managed by the CAST Management Service you are connected to:

  • A sortable table listing the snapshot name, date it was calculated, the date chosen prior to generating the snapshot and the Measure mode (Automated Enhancement Points (AEP) or Enhancement Function Points (EFP)) chosen in the CAST Management Studio:

  • In addition, data is listed under the list of snapshots with regard to the AEP/EFP statistics and artifacts in the selected snapshot. Added/Modified/Deleted statistics are generated by comparing the currently selected snapshot and the immediately preceding snapshot.
  • Selecting a snapshot in this panel will display all items that match the criteria you have set up in the Templates node or System node in the Upper right panel (see below).
  • The Recompute checksums and snapshot statuses option will recalculate all checksum values for all items listed in the Upper right panel. This should be used when you have excluded/included certain objects that form an item - this will regenerate Function Point data listed in this panel.

Please note that:

- the value reported for "Total AEFP" or "Total EFP" is an EFP (Enhanced Function Point) value - in other words, it only includes added, modified and deleted Function Points. All Unchanged Function Points are automatically excluded from this value.
- the value reported for "Deleted AEFP/EFP" and "Deleted Data Entities" is relative to the value displayed for "Total AEFP/EFP" and "Total Changed Entities" in the previous snapshot (not in the current snapshot).

Upper right panel (Data Functions or Transactional Functions)

This panel lists all Data Functions/Transactional Functions that match the criteria you have set up in the Templates node or System node that are present in the snapshot selected in the Upper left panel:

  • For each item, its Name, Type, Status in the current snapshot (ADDED, MODIFIED, DELETED, UNCHANGED), FP (Function Point) value, Impact Factor / Complexity Factor and AEFP / EFP value are displayed.

Note that:

- all items are listed as ADDED in the very first snapshot.
- in case the selected snapshot uses the EFP enhancement measure, Impact Factor and EFP value will be displayed.
- In case the selected snapshot uses the AEP enhancement measure, Complexity Factor and AEFP value will be displayed.

  • Selecting an item in this panel will display (in the Lower panel) all the objects that are part of the original item. This enables you to see whether a certain object is relevant for the total checksum value calculation and either include it (default position) or exclude it from the total checksum calculation. The checksum value of an object between snapshots determines whether the object has changed. Some very trivial code changes between snapshots can heavily impact the Modified EFP value (listed in the Upper left panel), so excluding certain objects will allow this value to be more in line with expectations.
  • The Shared object exclusions option (only available for Transactional Functions) allows you to exclude objects from the total checksum value calculation based on the number of Transactions an object is shared between:

Exclude objects shared by at least X transactions in current snapshot Use this option to determine which objects you want to exclude from the total checksum calculation. By default, all objects that are shared between at least 10 transactions will be excluded when you click the OK button. You can modify the number of transactions manually.

You can find out how many Transactions an object is part of by looking in the Lower panel:

Keep existing exclusions Activate this option if you have defined exclusions by hand on a "per object basis" (see Lower panel) and you want to keep these exclusions.

If you leave the option in the default inactivated position, any exclusions you have defined by hand on a "per object basis" will be removed when you click the OK button.

Lower panel (Details)

This panel lists all objects belonging to a Data Function/Transactional Function selected in the Upper right panel:

  • The panel lists each object with:
    • name
    • full name
    • type
    • role in the Transactional Function / Data Function, for example:
      • Data Functions: DATA_ENTITY_PRIMARY, DATA_ENTITY_SECONDARY
      • Transactional Functions: DATA_RECORD, FORM, OBJECT, FULL_GRAPH_OBJECT
    • status in the TF (Transactional Function) or in the DF (Data Function) - either Added, Deleted, Modified, Unchanged
    • status of the object itself - either Added, Deleted, Modified, Unchanged
    • whether it is excluded or not
    • the shared counter (Transactional Function only: the number of Transactional Functions to which the object contributes)
    • EC Level (Effort Complexity Level): category that assesses the complexity of adding, modifying, or deleting an Artifact based on a composite score of five software metrics that assess the complexity of the software environment in which the Artifact is embedded; that is, its size, comment level, algorithmic complexity, data access complexity, and coupling. Their possible values are: LOW, AVERAGE, HIGH, VERY HIGH.
    • EC (Effort Complexity): numerical value assigned to an Artifact based on its Effort Complexity Level and its technology.

Note with regard to the EC Level and EC columns:

- these columns are only relevant for Artifacts. The objects in this table which are not Artifacts, will not have neither EC nor EC Level ("N/A" will be displayed).
- these columns are only relevant for AEP enhancement measure. In case the selected snapshot uses EFP, they will be Non-Aplicable ("N/A" will be displayed in both columns).

Note with regard to FULL_GRAPH_OBJECT in the Role column:

- the FULL_GRAPH_OBJECT role listed for Transactional Functions indicates objects that appear in the Full Call Graph (used by the AEP mode) but are not visible in the reduced Call Graph (used by the EFP mode) - see View call graph / View full call graph for more information. In other words these are objects which are only taken into account when the snapshot has been generated in AEP mode. When EFP mode is use to generate the snapshot, these objects are ignored.
- in most circumstances, an object with the role FULL_GRAPH_OBJECT should not appear in the lower panel for a snapshot that has been calculated in EFP mode. However, one exception to this rule is where the most recent snapshot has been generated in EFP mode, and the immediately preceding snapshot has been generated in AEP mode. This results in a situation where the lower panel will list FULL_GRAPH_OBJECT objects in the EFP calculated snapshot, but they will be marked as DELETED - i.e. not taken into account in the current snapshot, but were included in the previous AEP generated snapshot:

To manually exclude an object, right click the object in question and select Exclude <object_name>. A tick will be placed in the Excluded column as shown above and the object will not be taken into account when you click the Recompute checksums and snapshot statuses option (see Upper left panel).

  • An object is automatically included in the Recompute checksums and snapshot statuses option when no tick exists in the Excluded column for the object in question. To manually re-include an object that you have previously excluded manually or via the global exclude option (see Upper right panel): right click the object in question and select Un-exclude <object_name>. A tick will be removed from the Excluded column as shown above and the object will be taken into account when you click the Recompute checksums and snapshot statuses option (see Upper left panel).
  • Use the Hide unchanged objects option to remove any objects that have the status Unchanged (in the Object status column). These objects are of no relevance with regard to the Evolution feature.

CAST Website

  • No labels