System Modeling - The Hatley Pirbhai Modeling

System models are hierarchical or layered as a system is represented at different levels of abstraction. The top level of hierarchy presents the complete system. The data objects, functions, behaviors are represented. As the hierarchy is refined or layered, component level detail is modeled and finally system models evolve into engineering models.
Hatley-Pirbhay modeling is an extension of the concept that every computer system can be modeled through the usage of an input-processing-output model by including the two additional features of user interface process and maintenance/self testing. These five components are added to a system model template to allow for modeling of the system which allows for proper assignment to the processing regions.

THE HATLEY-PIRBHAI MODELING
- The Hatley-Pirbhai model depicts input processing, and output along with the user interface and maintenance or self-test.
- It includes two more system features: user interface processing and maintenance and self-test processing.
- A system engineer can create a model of system components that sets a foundation for later steps.
- The system engineer allocates system elements to each of five processing regions within the template: user interface, input, system function and control, output, maintenance and self-test.
- A system context diagram(SCD) resides at the top level of hierarchy which defines all external producers of information used by the system,all external consumers of information created by the system and all entities that communicate through interface or perform maintenance and self-test.
- All the major subsystems are defined in a system flow diagram (SFD) which is derived from SCD.
- Information flows across the regions of system context diagram is used to guide the system engineer in developing system flow diagram.
- System flow diagram shows major subsystems and important lines of information.

What comprises Test Ware Development : Test Strategy Continued...

Test ware development is the key role of the testing team. Test ware comprises of:

Test Strategy

Before starting any testing activities, the team lead will have to think a lot and arrive at a strategy.The following areas are addressed in the test strategy document:
- Test Groups: From the list of requirements, we can identify related areas, whose functionality is similar. These areas are the test groups. We need to identify the test groups based on the functionality aspect.

- Test Priorities: Among test cases, we need to establish priorities. While testing software projects, certain test cases will be treated as the most important ones and if they fail, the product cannot be released. Some other test cases may be treated like cosmetic and if they fail, we can release the product without much compromise on the functionality. This priority levels must be clearly stated.

- Test Status Collections and Reporting:
When test cases are executed, the test leader and the project manager must know where exactly we stand in terms of testing activities. To know where we stand, the inputs from the individual testers must come to the test leader. This will include, what test cases are executed, how long it took, how many test cases passed and how many failed etc. Also, how often we collect the status is to be clearly mentioned.

- Test Records Maintenance: When the test cases are executed, we need to keep track of the execution details like when it is executed, who did it, how long it took, what is the result etc. This data must be available to the test leader and the project manager, along with all the team members, in a central location.This may be stored in a specific directory in a central server and the document must say clearly about the locations and the directories.

- Requirements Traceability Matrix: Ideally, each software developed must satisfy the set of requirements completely. So, right from design, each requirement must be addressed in every single document in the software process. The documents include the HLD, LLD, source codes, unit test cases, integration test cases and the system test cases. In this matrix, the rows will have the requirements. For every document, there will be a separate column. So, in every cell, we need to state what section in HLD addressed in every single document, all the individual cells must have valid section ids or names filled in.

- Test Summary: The senior management may like to have a test summary on a weekly or monthly basis. If the project is very critical, they may need it on a daily basis also. It addresses what kind of test summary reports will be produced for the senior management along with the frequency.

Different testing activities in Programming/Construction and Operations and Maintenance Phase

The main testing points in this phase are:
- Check the code for consistency with design
The areas to check include modular structure, module interfaces, data structures, functions, algorithms and I/O handling.

- Perform the testing process in an organized and systematic manner with test runs dated, annotated and saved.
A plan or schedule can be used as a checklist to help the programmer organize testing efforts. If errors are found and changes are made to the program, all tests involving the erroneous segment must be re-run and recorded.

- Asks some challenges for assistance
Some independent party, other than the programmer of the specific part of the code should analyze the development product at each phase. The programmer should explain the product to the party who will then question the logic and search for errors with a checklist to guide the search. This is needed to locate errors the programmer has overlooked.

- Use available tools
The programmer should be familiar with various compilers and interpreters available on the system for the implementation language being used because they differ in their error analysis and code generation capabilities.

- Apply stress to the program
Testing should exercise and stress the program structure, the data structures, the internal functions and the externally visible functions or functionality. Both valid and invalid data should be included in the test set.

- Test one at a time
Pieces of code, individual modules and small collections of modules should be exercised separately before they are integrated into the total program, one by one. Errors are easier to isolate when the number of potential interactions should be kept small. Instrumentation-insertion of the some code into the program solely to measure various program characteristics can be useful here.

- Measure testing coverage/ When should testing stop?
If errors are still found every time the program is executed, testing should continue. Because errors tend to cluster, modules appearing particularly error-prone require special scrutiny. The metrics used to measure testing thoroughness include statement testing, branch testing and path testing. Statement testing is the coverage metric most frequently used as it is relatively simple to implement.

Testing Activities in Operations and Maintenance Phase

Correctness, modifications and extensions are bound to occur even for small programs and testing is required every time there is a change. Testing during maintenance is termed regression testing. The test set, test plan, and the test results for the original program should exist. Modifications must be made to accommodate the program changes, and then all portions of the program affected by the modifications must be re-tested. After regression testing is complete, the program and test documentation must be updated to reflect the changes.