Thursday, March 1, 2012

What are Lehmanʼs Laws and how were they derived?

What are Lehmanʼs Laws and how were they derived?
Answer: Continuing change: A program that is used in a real-world environment must necessarily change, or else become progressively less useful in that environment.
Increasing complexity: As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure.
Large program evolution: Program evolution is a self-regulating process. System attributes such as size, time between releases, and the number of reported errors is approximately invariant for each system release.
Organizational stability: Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development.
Conservation of familiarity: Over the lifetime of a system, the incremental change in each release is approximately constant.
Continuing growth: The functionality offered by systems has to continually increase to maintain user satisfaction.
Declining quality: The quality of systems will decline unless they are modified to reflect changes in their operational environment.
Feedback system: Evolution processes incorporate multi-agent, multi-loop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.

Why might it sometimes be necessary to bypass the normal change management system and make urgent changes to a system?

Why might it sometimes be necessary to bypass the normal change management system and make urgent changes to a system?
Answer: It might be necessary to bypass the normal change management system and make urgent changes to a system due to following three reasons:
1. If a serious system fault occurs that has to be repaired to allow normal operation to continue.
2. If changes to the systems operating environment have unexpected effects that disrupt normal operation.
3. If there are unanticipated changes to the business running the system, such as the emergence of new competitors or the introduction of new legislation that affects the system.

What are the stages in the system evolution process and what triggers that process?

What are the stages in the system evolution process and what triggers that process?
Answer: Release Planning, Change Implementation, System Release, Impact Analysis, Change Requests, Platform Adaptation and System Enhancement.
            System change proposals are the driver for system evolution in all organizations. Change proposals may come from existing requirements that have not been implemented in the released system, requests for new requirements, bug reports from system stakeholders, and new ideas for software improvement from the system development team.

Why is software evolution important?

Why is software evolution important?
Answer: Software evolution is important because organizations have invested large amounts of money in their software and are now completely dependent on these systems. Their systems are critical business assets and they have to invest in system change to maintain the value of these assets. Consequently, most large companies spend more on maintaining existing systems than on new systems development.

What are the three types of user testing?

What are the three types of user testing?
Answer: In practice, there are three different types of user testing:
1. Alpha testing, where users of the software work with the development team to test the software at the developer’s site.
2. Beta testing, where a release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.
3. Acceptance testing, where customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment.

What is stress testing and why is it useful?

What is stress testing and why is it useful?
Answer: Experience has shown that an effective way to discover defects is to design tests around the limits of the system. In performance testing, this means stressing the system by making demands that are outside the design limits of the software. This is known as ‘stress testing’. 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. The network becomes swamped with coordination data that the different processes must exchange. The processes become slower and slower as they wait for the required data from other processes. Stress testing helps you discover when the degradation begins so that you can add checks to the system to reject transactions beyond this point.

What is scenario testing?

What is scenario testing?
Answer: Scenario testing is an approach to release testing where you devise typical scenarios of use and use these to develop test cases for the system. A scenario is a story that describes one way in which the system might be used. Scenarios should be realistic and real system users should be able to relate to them. If you have used scenarios as part of the requirements engineering process, then you may be able to reuse these as testing scenarios.