Professional Documents
Culture Documents
Smu BC0049 - Software-Engineering-Spring-2012-Assignment-Set - 2
Smu BC0049 - Software-Engineering-Spring-2012-Assignment-Set - 2
Answer
The change management process should come into effects when the software or associated documentation is put under the control of the configuration management team. Change management procedures should be designed to ensure that the costs and benefits of change are properly analyzed and that changes to a system are made in a controlled way. Change management processes involve technical change analysis, cost benefit analysis and change tracking. The pseudo-code, shown in table below defines a process, which may be used to manage software system changes: The first stage in the change management process is to complete a change request form (CRF). This is a formal document where the requester sets out the change required to the system. As well as recording the change required, the CRF records the recommendations regarding the change, the estimated costs of the change and the dates when the change was requested, approved, implemented and validated. It may also include a section where the maintenance engineer outlines how the change is to be implemented. Once a change request form has been submitted, it is analyzed to check that the change is valid. Some change requests may be due to user misunderstandings rather than system faults; others may refer to already known faults. If the analysis process discovers that a change request is invalid duplicated or has already been considered the change should be rejected. The reason for the rejection should be returned to the person who submitted the change request. For valid changes, the next stage of the process is change assessment and costing. The impact of the change on the rest of the system must be checked. A technical analysis must be made of how to implement the change. The cost of making the change and possibly changing other system components to accommodate the change is then estimated. This should be recorded on the change request form. This assessment process may use the configuration database where component interrelation is recorded. The impact of the change on other components may then be assessed. Unless the change involves simple correction of minor errors on screen displays or in documents, it should then be submitted to a change control board (CCB) who decide whether or not the change should be accepted. The change control board considers the impact of the change from a strategic and organizational rather than a technical point of view. It decides if the change is economically justified and if there are good organizational reasons to accept the change.
Bottom-Up Testing If top-down development is combined with bottom-up testing, all parts of the system must be implemented before testing can begin. Architectural faults are unlikely to be discovered until much of the system has been tested. Correction of these faults might involve the rewriting and consequent re-testing of low-level modules in the system. A strict top-down development process including testing is an impractical approach, particularly if existing software components are to be reused. Bottom-up testing of critical, low-level system components is almost always necessary. Bottom-up testing is appropriate for object-oriented systems in that individual objects may be tested using their own test drivers they are then integrated and the object collection is tested. The testing of these collections should focus on object interactions.
Validation Test Criteria Software validation is achieved through a series of black box tests that demonstrate conformity with requirements. A test plan outlines the classes of tests to be conducted and a test procedure defines specific test cases that will be used to demonstrate conformity with requirements. Both the plan and the procedure are designed to ensure that all functional requirements are satisfied, all performance requirements are achieved, documentation is correct and human-engineered, and other requirements are met (e.g., transportability, compatibility, error recovery, maintainability).
Stress testing Stress testing continues these tests beyond the maximum design load of the system until the system fails. This type of testing has two functions: (1) It tests the failure behavior of the system.
(2) It stresses the system and may cause defects to come to light, which would not normally manifest themselves. Stress testing is particularly relevant to distributed systems based on a network of processors. These systems often exhibit severe degradation when they are heavily loaded as the network becomes swamped with data, which the different processes must exchange. Back-to-back testing Back-to-back testing may be used when more than one version of a system is available for testing. The same tests are presented to both versions of the system and the test results compared. Difference between these test results highlight potential system problems . Back-to-back testing is only usually possible in the following situations: (1) When a system prototype is available. (2) When reliable systems are developed using N-version programming. (3) When different versions of a system have been developed for different types of computers.
9. Explain why top-down testing is not an effective strategy for testing object oriented system. Answer
Top-Down Testing Top-down testing tests the high levels of a system before testing its detailed components. The program is represented as a single abstract component with sub components represented by stubs. Stubs have the same interface as the component but very limited functionality. After the top-level component has been tested, its stub components are implemented and tested in the same way. This process continues recursively until the bottom level components are implemented. The whole system may then be completely tested. The main disadvantage of top-down testing is that test out put may be difficult to observe. In many systems, the higher levels of that system do not generate output but, to test these levels, they must be forced to do so. The tester must create an artificial environment to generate the test results.
10. Explain why fault tolerance facilities are required if the system is failure. Answer
Fault-tolerance facilities are required if the system is to failure. There are four aspects to fault tolerance. 1. Failure detection: The system must detect a particular state combination has resulted or will result in a system failure. 2. Damage assessment: The parts of the system state, which have been affected by the failure, must be detected. 3. Fault recovery: The system must restore its state to a known safe state. This may be achieved by correcting the damaged state or by restoring the system the system to a known safe state. Forward error recovery is more complex as it involves diagnosing system faults and knowing what the system state should have been had the faults not caused a system failure. 4. Fault repair: This involves modifying the system so that the fault does not recur. In many cases, software failures are transient and due to a peculiar combination of system inputs. No repair is necessary as normal processing can resume immediately after fault recovery. This is an important distinction between hardware and software faults.