CRUD matrix technology. Practical experience

    Functional duplication example
    CRUD matrix technology is a good tool for every member of the Agile team throughout the entire product life cycle. CRUD-matrix allows you to establish an adequate dialogue with the client and identify duplication of functionality, as well as eliminate inconsistency of the model. As for the time evaluation, at this point the CRUD matrix is ​​significantly inferior to such a tool as “planning poker”, which allows for an adequate assessment taking into account objective reasons.


    A bit of theory: a description of the technique


    IIBA is responsible for the following technologies in the competence of a business analyst in the field of Agile (hereinafter referred to as the Agile analyst):
    - Definition of evaluation and acceptance criteria;
    - Brainstorm;
    - Various assessment methods (Delphi method, parametric method, analogy method, three-point method, etc.);
    - Prototyping;
    - Development of scenarios and a description of precedents;
    - Modeling areas for analysis or delivery of solutions;
    - Custom stories.

    IIBA does not attribute data modeling technology to the competence of an Agile analyst, but assigns it to the competency of the role of a business architect. At the same time, the competence of a business architect, as well as Agile analytics, includes technology for modeling areas for analysis or delivery of solutions.
    As a result of the fact that the business architect is mainly engaged in data modeling, the Agile analyst does not see the actual relationship between processes and data in the system, which can lead to the creation of conflicting entities or duplication of functionality in the system.
    To solve this problem, an Agile analyst develops a matrix called CRUD.

    Practical part: CRUD matrix development


    Developing a CRUD matrix helps the Agile team focus on significant use cases that describe the business process. The CRUD matrix is ​​formed in the form of a table in which all classes from the class diagram are listed in the upper part, and a list of use cases is displayed in the left part. The task of an Agile analyst is to fill the intersections between use cases and classes with the following combinations of access to class instances: create ( C reate), read ( R ead), update ( U pdate) or delete ( D elete).
    This describes all the use cases that create, read, update, or delete one or more instances of a class.
    As an example, I will give the experience of building a CRUD matrix in 2007-2008. when planning the development of an automated library information system for a scientific and technical library (hereinafter referred to as NTIS ABIS).


    Analysis of the CRUD matrix is ​​carried out in seven steps:
    1. Checking the completeness of model
    building 2. Determining the dependencies
    3. Determining the package of typical work for development
    4. Estimating the time required for development
    5.
    Checking the model for consistency 6. Determining the subsequent work and additions to the functional
    7 Prioritizing development and delivery

    Step 1. Checking the completeness of the model

    Based on the CRUD matrix, the completeness of the model construction is checked for the appropriateness of using classes or precedents in the developed system.
    For example, the creation or deletion of the “Book Form” class is not described in the framework of the listed precedents. This fact may of course mean that the “Book Form” is created and deleted outside the system being developed, or that the Agile analyst did not describe the precedent of “registering a book” or “writing off a book”, but for this you need to introduce another class “ inventory book. ”

    Step 2. Defining the dependencies

    When planning the system development process, the CRUD matrix helps determine the list of classes that are developed primarily to cover the maximum number of use cases. For example, for the development of ABIS NTB, the precedent “reader registration” will be implemented first, because the reader class according to the CRUD matrix is ​​used in 8 precedents, in contrast to the “reservation” class. Thus, the necessary and relevant data are determined.

    Step 3. Definition of a package of typical work for development

    CRUD-matrix helps determine a typical implementation and identify duplication of functionality in the system. For example, the “book form” class is implemented according to the type of the “librarian” class, and accordingly, less time will be required to implement the “book form” class. Thus, system development time is reduced.

    Step 4. Estimating Development Time

    The CRUD matrix provides the Agile team with a simple mechanism for estimating the time required to develop and test a specific piece of functionality.
    In a first approximation, each access combination is evaluated, and then each use case is evaluated. For example, creating a new instance of a class is required in 4 cases, reading information about an instance of a class in 7 cases, in 16 cases it is necessary to update the information of an instance of a class, and in 6 cases it is necessary to delete an instance of a class. Using the planned time for the development of each access combination, a table of the complexity of the implementation of each class, as well as the system as a whole, is formed:

    If necessary, the analyst can rank not only the complexity of the implementation of each class, but also each use case.
    As for 53 days, this period is reduced due to standard work, namely the implementation of the classes “librarian” and “book form”. To provide a more realistic estimate for the future, you can use the actual values ​​collected on the basis of a statistical analysis of the processes of implementing such functionality in previous projects. In any case, the last word should be behind the Agile team, because no statistics will help in the development of the system, and sometimes it even prevents the Agile team from correctly assessing its capabilities.

    Step 5. Checking the model for consistency

    In the process of iterative development of the CRUD matrix, consistency is maintained between use cases and those models that are the basis for the development and delivery of solutions. For example, within the model, there may be classes that are not used in any use case, which may be a decrease in system performance, and therefore this can directly affect customer satisfaction. Thus, the solution, which was developed using the CRUD matrix technology, will be as consistent as possible, which is a good basis for development.

    Step 6. Definition of the subsequent work and additions of functionality

    The CRUD matrix describes all the response actions of the system for each use case, which allows the developer to see the operation of the entire system as a whole. Based on the CRUD matrix, an Agile analyst, if necessary, can refine the model and build sequence diagrams, communication diagrams, interaction review diagrams, or synchronization diagrams. Also, a CRUD matrix can be used by a designer when designing interfaces or as a solution architect to develop a product specification. Thus, the CRUD matrix serves as a good tool for each member of the Agile team throughout the entire product life cycle.

    Step 7. Prioritizing development and delivery

    CRUD-matrix allows customers to adequately assess the priorities in the implementation of any functionality, and will not allow to move its implementation to the next iteration. For example, the precedents “issuing a library card” and “re-registering a reader” cannot be completely set until the classes are developed: reader, library card and librarian.

    Total


    CRUD matrix technology is a good tool for every member of the Agile team throughout the entire product life cycle. CRUD-matrix allows you to establish an adequate dialogue with the client (customer) and identify duplication of functionality, as well as eliminate inconsistency of the model. As for the time evaluation, at this point the CRUD matrix is ​​significantly inferior to such a tool as “planning poker”, which allows for an adequate assessment taking into account objective reasons. As for access combinations to instances of the class, it is not necessary to use a CRUD combination, other combinations are possible, for example, REST, RESTful, GET-PUT-POST-DELETE, etc.

    PS: Sources for inspiration:
    1. James Cadle, Debra Paul and Paul Turner Business Analysis Techniques: 72 Essential Tools for Success, 2010
    2. International Institute of Business Analysis (2009) Business Analysis Body of Knowledge (Version 2.0). International Institute of Business Analysis, Toronto.
    3. International Institute of Business Analysis (2011) Business Analysis Competency Model (Version 3.0). International Institute of Business Analysis, Toronto.
    4. unrealitymag.com/wp-content/uploads/2009/03/matrix.jpg

    Also popular now: