Agenda. Introduce new members 5 minutes. CISQ status 5 minutes. AEFP work 45 minutes. Assignments and adjourn 5 minutes

Transcription

1 AEFP Meeting #4 1

2 2 Agenda Introduce new members 5 minutes CISQ status 5 minutes AEFP work 45 minutes Assignments and adjourn 5 minutes

3 Status CISQ Quality Characteristic Measures: Reliability, Performance Efficiency, Maintainability have entered their 40-day public review period Anticipate approval during at OMG meeting in March Current standards work: Enhancement function points launched Technical debt launch in April Quality adjusted productivity launch in April Certifications: Individual knowledge under discussion CISQ compliance for product and service launch in April 3

4 Study approach - Summary

5 5 Wiki AEFP Project 5: Complexity of the modification AEFP Project 3: Complexity of the transaction AEFP Project 2: What: Composition of the transaction AEFP Project 4: Consider a transaction as modified AEFP Project 1: Identification of transaction AEFP Project 6: Weight of the transaction AEFP data collection tooling AEFP Project 7: Impact of shared components AEFP Project 8: Nature of the modification

6 AEFP data collection tooling New version of the tool We really need to gather more data Available tooling - Toolkit description As of , the toolkit is composed of 2 executable files, compatible with CAST Storage Service implementations: extendedtransactions.exe evolutions.exe Their execution syntaxes are: Notes: replace "-process" with "-reset" to ensure you use the latest implementation tables, etc. replace "-process" with "-delete" to delete results and therefore remove the added volume of data the execution log is stored in DSS_HISTORY (default) and can be externalized into a file can be enriched with JDBC debug information evolutions.exe -url jdbc:postgresql://pdow7lap:2280/postgres -driver org.postgresql.driver -AS_schema cisqxfp_local -DS_schema cisqxfp_central -password CastAIP -process extendedtransactions.exe -url jdbc:postgresql://pdow7lap:2280/postgres -driver org.postgresql.driver -schema cisqxfp_local -password CastAIP -process 6

7 Project 1: What: Identification of transaction Rely on the AFP definition for functional transaction Recommended approach Status update All technical transaction should be track as well under a separate aggregation number Technical modification which not belong to functional transaction or technical transaction can be consider as well under a separate aggregation number or metric since the function point will not be applicable. This will be named as dark matter on the following project. Application + + Functional Transaction Technical Transaction Other components (Dark matter)

8 Project 2: What: Composition of the transaction Recommended approach Transaction should be composed by the artifacts which contain modification and functionality. Consider all branches of a transaction. Actual identification of transaction Deprecated Expanded identification of transaction via reference path on artifacts Require to add some additional file to the artifacts to be complete. Expanded identification of transaction via reference path on all objects Include all object will not make too much sense Artifact as part of the transaction Artifact as part of the transaction Artifact as part of the transaction Artifact not part of the transaction None artifact part of the transaction Artifact not part of the transaction None artifact part of the transaction Artifact not part of the transaction None artifact part of the transaction

9 Project 3: What: Complexity of the transaction The complexity of the transaction should follow the AFP definition. This value is use as input of the AEFP in order to apply the weight of the transaction. If a transaction is added, the AFP definition and value will be apply. If a transaction is deleted, the AFP definition and value will be apply. If a transaction is updated, the AFP definition and value will be apply. For all activity on the code, a weight can be apply based on some other complexity measure. This will be study on some other project Recommended approach Rely on the AFP definition for functional transaction No additional update. Apply the AFP definition we have on functional transaction but on technical transaction Dark matter TBD.

10 Project 4: How: Consider a transaction as modified Recommended approach Technical components should not activate a transaction as modified. Selection of technical components should be define separately by a specific inheritance, name, or group. Shared components should not be activate a transaction as modified. All other artifacts updated should automatically flag the transaction as modified. Threshold should not be a good approach since this will make the rules less predictable.

11 Project 5: How much: Complexity of the modification Recommended approach Delta of RET / DET, FTR between two points of measure will not be enough to track the complexity of the modification. Complexity of the modification as a delta of the effort complexity (mixed of metrics to define) seems the preferred approach. Shared components and technical components should not be considered as part of the delta of modification.

12 Project 5: How much: Complexity of the modification Complexity Asset At the component level (CC, SQL, OO, Fan in, Fan out, Granularity, Documentation) At the transaction level (Sum(component level), RPF, # of links between different technology, # of technology involve) At the application level (Sum(component level), RPF, # of links between different technology, # of technology involve) On a release (delta of snapshots) At the component level Delta (v2-v1) and status (added, updated, deleted) with a weight At the transaction level Delta (v2-v1) and status (added, updated, deleted) with a weight At the application level Delta (v2-v1) and status (added, updated, deleted) with a weight Note on the Productivity Formula: The positive adjustment factor should be based on two concept. The complexity asset of the updated components The complexity of the modification result of the component A.U.D during the period of time 12

13 Project 5: How much: Complexity of the modification Approach under study: Sum of Risk Propagation Factor a.k.a. sum of the number of distinct call paths to artifacts Sum of Fan-In a.k.a. sum of the number of direct calls to artifacts Number of distinct object types Sum of Fan-In x Cyclomatic Complexity (quite similar to CAST Cost complexity itself, but with no upper limit) or Fan-In x CAST Cost Complexity... (similar to a coupling-boosted CAST Cost complexity, with no upper limit) Sum of Cyclomatic Complexity or... minus Sum of Cyclomatic Complexity or... of related test code Number of distinct cross-technologies interfaces Number of distinct interfaces Number of "serving hatch" (should lead to a quality check as well) Sum of Data complexity (Not limited to 7 max. as with FP data entities. E.g.: number of columns) to account for the complexity of the processed data, functional or not Sum of Data complexity x Fan-in or RPF or... to account for store-them-all tables Sum of (Data Complexity + Algorithmic Complexity) x RPF to be able to assess application subset without data entities Call graph complexity Sum of Cyclomatic Complexity a.k.a. sum of the number of decision points of artifacts Sum of CAST Cost Complexity

14 Project 6: How much: Weight of the transaction Recommended approach TBD, but as of now Nesma weight should be apply 100% for added, 40% for deleted, 100%, 75%, 50%, 25% for modified. Categories of updated ratio should come from project 5.

15 Project 7: How much: Impact of shared components Should we exclude them Should we include them as technical transaction Should we include them as part of the transaction but apply funnel algorithm or other filter Recommended approach TBD. But we should define some specific category of components based on inheritance or dependency in order to define pure technical components. Those components have a high statistic ratio to be shred components between transactions. Transaction impacted by only some shared components should be considered but with a low weight.

16 Project 8: When: Nature of the modification Modification on the Dark matter should be considered but on the side of the AEFP Modification on technical components should be considered but on the side of the AEFP Instead of exclusion of technical transaction in the AFP we should exclude them from the sizing information but consider those as activity of those transaction are modified Recommended approach TBD.

17 17 Future Activities Next call April 7? Face-to-face meeting Asia week of May 12? Assignments: