Showing posts with label traceability. Show all posts
Showing posts with label traceability. Show all posts

01 February 2021

Data Migrations (DM): Quality Acceptance Criteria IV

Data Migration
Data Migrations Series

Reliability

Reliability is the degree to which a solution performs its intended functions under stated conditions without failure. In other words, a DM is reliable if it performs what was intended by design. The data should be migrated only when migration’s reliability was confirmed by the users as part of the sign-off process. The dry-runs as well the final iteration for the UAT have the objective of confirming solution’s reliability.

Reversibility

Reversibility is the degree to which a solution can return to a previous state without starting the process from the beginning. For example, it should be possible to reverse the changes made to a table by returning to the previous state. This can involve having a copy of the data stored respectively deleting and reloading the data when necessary. 

Considering that the sequence in which the various activities is fix, in theory it’s possible to address reversibility by design, e.g. by allowing to repeat individual steps or by creating rollback points. Rollback points are especially important when loading the data into the target system. 

Robustness

Robustness is the degree to which the solution can accommodate invalid input or environmental conditions that might affect data’s processing or other requirements (e,g. performance). If the logic can be stabilized over the various iterations, the variance in data quality can have an important impact on a solutions robustness. One can accommodate erroneous input by relaxing schema’s rules and adding further quality checks.

Security 

Security is the degree to which the DM solution protects the data so that only authorized people have access to the respective data to the defined level of authorization as data are moved through the solution. The security provided by a solution needs to be considered against the standards and further requirements defined within the organization. In case no such standards are available, one can in theory consider the industry best practices.

Scalability

Scalability is the degree to which the solution is able to respond to an increased workload.  Given that the number of data considered during the various iterations vary in volume, a solution’s scalability needs to be considered in respect to the volume of data to be migrated.  

Standardization

Standardization is the degree to which technical standards were implemented for a solution to guarantee certain level of performance or other aspects considered as import. There can be standards for data storage, processing, access, transportation, or other aspects associated with the migration processes. Moreover, especially when multiple DMs are in scope, organizations can define a set of standards and guidelines that should be further considered.  

Testability

Testability is the degree to which a solution can be tested in the respect to the set of functional and data-related requirements. Even if for the success of a migration are important the data in their final form, to achieve that is needed to validate the logic and test thoroughly the transformations performed on the data. As the data go trough the data pipelines, they need to be tested in the critical points – points where the data suffer important transformations. Moreover, one can consider record counters for the records processed in each such critical point, to assure that no record was lost in the process.  

Traceability

Traceability is the degree to which the changes performed on the data can be traced from the target to the source systems as record, respectively at entity level. In theory, it’s enough to document the changes at attribute level, though upon case it might needed to document also the changes performed on individual values. 

Mappings at attribute level allow tracing the data flow, while mappings at value level allow tracing the changes occurrent within values. 

04 March 2007

Software Engineering: Requirements Traceability Matrix (Definitions)

"A matrix describing the traceability between requirements and work products." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"A table that links requirements to their origin and traces them throughout the project life cycle." (Cynthia Stackpole, "PMP Certification All-in-One For Dummies", 2011)

"A grid that links product requirements from their origin to the deliverables that satisfy them." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"A two-dimensional table, which correlates two entities (e.g., requirements and test cases). The table is used to determine and achieve coverage, to trace back and forth from one entity to the other, and to assess the impact of proposed changes." (ISTQB)

"Is a document, usually in the form of a table, that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship." (IQBBA)

16 February 2007

Software Engineering: Traceability (Definitions)

"The evidence of an association between a requirement and its source requirement, its implementation, and its verification." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"A discernable association among two or more logical entities such as requirements, system elements, verifications, or tasks." (Sandy Shrum et al, "CMMI: Guidelines for Process Integration and Product Improvement" 2nd Ed., 2006)

"The quality of information to be linked to its background or sources." (Martin J Eppler, "Managing Information Quality" 2nd Ed., 2006)

[horizontal traceability:] "The tracing of requirements for a test level through the layers of test documentation (e.g., test plan, test design specification, test case specification, and test procedure specification or test script)." (Tilo Linz et al, "Software Testing Practice: Test Management", 2007)

[vertical traceability:] "The tracing of requirements through the layers of development documentation to components." (Tilo Linz et al, "Software Testing Practice: Test Management", 2007)

"Starting from requirements, traceability establishes a correlation between elements of different development steps." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"The degree to which each element of a product can be mapped back to the individual requirement or requirements, which in-turn, are linked back to the original validated market or customer need." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"Capability of linking artifacts produced by enterprise architecture or realization activities to other artifacts from which they originate or to which they refer." (Gilbert Raymond & Philippe Desfray, "Modeling Enterprise Architecture with TOGAF", 2014)

[traceable:] "Information that is sufficient to make a determination about a specific aspect of an individual's activities or status." (NIST SP 800-122)

"The ability to identify related items in documentation and software, such as requirements with associated tests. " (ISTQB)

"The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another" (IEEE 1233-1998)

Related Posts Plugin for WordPress, Blogger...

About Me

My photo
IT Professional with more than 24 years experience in IT in the area of full life-cycle of Web/Desktop/Database Applications Development, Software Engineering, Consultancy, Data Management, Data Quality, Data Migrations, Reporting, ERP implementations & support, Team/Project/IT Management, etc.