Data Model, Process Model, and the Linkage

The logical design phase establishes a detailed system framework for building the application. Three major deliverables from this phase are the data model, also known as an entity relationship diagram, a process model, and the linkage between the two.

A data model is a representation of the information needed or data object types required by the application. It establishes the associations between people, places, and entities of importance to the application and is used later in physical database design, which is part of the physical design phase. A data model is a graphical technique used to define the entities and the relationships. An entity is something about which we want to store data. It is a uniquely identifiable person, place, object, or event of interest to the user, about which the application is to maintain and report data. Examples of entities are customers, orders, offices, and purchase orders.

Each entity is a table divided horizontally into rows and columns. Each row is a specific occurrence of each entity, much like records in a file. Each column is an attribute that helps describe the entity. Examples of attributes include size, date, value, and address. Each entity in a data model does not exist by itself; it is linked to other entities by relationships. A relationship is an association between two or more entities of interest to the user, about which the application is to maintain and report data. There are three types of relationships: a one-to-one relationship links a single occurrence of an entity to zero or one occurrence of another entity; a one-to-many relationship links one occurrence of an entity to zero or more occurrences of an entity; and a many-to-many relationship links many occurrences of an entity to many occurrences of an entity. The type of relationship defines the cardinality of the entity relationships. See Appendix G10, “Database Testing,” for more details about data modeling.

A process is a business activity together with the associated inputs and outputs. Examples of processes are accept order, update inventory, ship orders, and schedule class. A process model is a graphical representation and should describe what the process does but not refer to why, how, or when the process is carried out. These are physical attributes of a process that are defined in the physical design phase.

A process model is a decomposition of the business. Process decomposition is the breakdown of the activities into successively more detail. It starts at the top until elementary processes, the smallest unit of activity that has meaning to the user, are defined.

A process decomposition diagram is used to illustrate processes in a hierarchical structure showing successive levels of detail. The diagram is built iteratively as processes and nonelementary processes are decomposed. The root of a process is the starting point of the decomposition. A parent is the process at a higher level than lower levels. A child is the lower level that is joined to a higher level, or parent. A data flow diagram is often used to verify the process decomposition. It shows all the processes, data store accesses, and the incoming and outgoing data flows. It also shows the flows of data to and from entities external to the processes.

An association diagram, often called a CRUD matrix or process/data matrix, links data and process models (see Figure 8.1). It helps ensure that the data and processes are discovered and assessed. It identifies and resolves matrix omissions and conflicts, and helps refine the data and process models, as necessary. It maps processes against entities, showing which processes create, read, update, or delete the instances in an entity.

This is often called “entity life-cycle analysis.” It analyzes the birth and death of an entity and is performed by process against the entity. The analyst first verifies that there is an associated process to create instances in the entity. If there is an entity that has no associated process that creates it, a process is missing and must be defined. It is then verified that there are associated processes to update, read, or delete instances in an entity. If there is an entity that is never updated, read, or deleted, perhaps the entity may be eliminated. See Appendix G9, “CRUD Testing,” for more details of how this can be applied to software testing.

Testing the Logical Design with Technical Reviews

The logical design phase is verified with static techniques, that is, nonexecution of the application. As utilized in the requirements phase, these techniques check the adherence to specification conventions and completeness of the models. The same static testing techniques used to verify the requirements are used in the logical design phase. The work products to be reviewed include the data model, the process model, and CRUD matrix.

Each defect discovered during the logical design review should be documented. A defect trouble report is designed to assist in the proper recording of these defects. It includes the defect category and defect type. The description of each defect is recorded under the missing, wrong, or extra columns. At the conclusion of the logical design review, the defects are summarized and totaled. Table 8.1 shows a sample logical design phase defect recording form (see Appendix F2, “Logical Design Phase Defect Checklist,” for more details).

Refining the System/Acceptance Test Plan

System testing is a multifaceted test that evaluates the functionality, performance, and fit of the whole application. It demonstrates whether the system satisfies the original objectives. During the requirements phase, enough detail was not available to define these types of tests. The logical design provides a great deal more information with data and process models. The scope of testing and types of tests in the Test Approach and Strategy section (see Appendix E2, “System/Acceptance Test Plan”) can now be refined to include details concerning the types of system-level tests to be performed. Examples of system-level tests to measure the fitness of use include functional, performance, security, usability, and compatibility. The testing approach, logistics, and regression policy are refined in this section. The rest of the items in this section, such as the test facility, test procedures, test organization, test libraries, and test tools, are begun. Preliminary planning for the software configuration management elements, such as version and change control and configuration building, can begin. This includes acquiring a software configuration management tool if it does not already exist in the organization.

The Test Execution Setup section deals with those considerations for preparing for testing and includes the system test process, test facility, required testing resources, the testing tool plan, and test organization.

In the Test Specifications section, more functional details are available from the data and process models and added in the requirements/test matrix. At this point, system-level test case design is started. However, it is too early to complete detailed test development, for example, test procedures, scripts, and the test case input/output data values associated with each test case. Acceptance test cases should be completed during this phase.

In the Test Procedures section, the items begun in the previous phase are refined. Test items in the Test Tools and Test Schedule sections are begun.