TEAM II- LEVELS OF SOFTWARE TESTING

*Unit testing tests the minimal software component, or module. Each unit (basic component) of the software is tested to verify that the detailed design for the unit has been correctly implemented.
*Integration testing exposes defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a whole.
*System testing tests an integrated system to verify that it meets its requirements, which can sometimes be sub-divided into:
1.Functional testing
2.Non-Functional testing
*System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements.
*Acceptance testing can be conducted by the end-user, customer, or client to validate whether or not to accept the product. Acceptance testing may be performed after the testing and before the implementation phase.

1. Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.
2. Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the company. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.

Team II-Image of Software Testinf Life Cycle

Team IV-Criticisms of Software Metrics

It is very difficult to satisfactorily define or measure "how much" software there is in a program, especially when making such a prediction prior to the detail design. The practical utility of software metrics has thus been limited to narrow domains where the measurement process can be stabilized.
Management methodologies such as the Capability Maturity Model or ISO 9000 have therefore focused more on process metrics which assist in monitoring and controlling the processes that produce the software.

Examples of process metrics affecting software:

• Number of times the program failed to rebuild overnight
• Number of defects introduced per developer hour
• Number of changes to requirements
• Hours of programmer time available and spent per week
• Number of patch releases required after first product ship

Risk management and business continuity- Team 6

Risk management is simply a practice of systematically selecting cost effective approaches for minimising the effect of threat realization to the organization. All risks can never be fully avoided or mitigated simply because of financial and practical limitations. Therefore all organizations have to accept some level of residual risks.

Figure shows an Unavoidable Risk that occurs in our day to day life

Whereas risk management tends to be pre-emptive, business continuity planning (BCP) was invented to deal with the consequences of realised residual risks. The necessity to have BCP in place arises because even very unlikely events will occur if given enough time. Risk management and BCP are often mistakenly seen as rivals or overlapping practices. In fact these processes are so tightly tied together that such separation seems artificial. For example, the risk management process creates important inputs for the BCP (assets, impact assessments, cost estimates etc). Risk management also proposes applicable controls for the observed risks. Therefore, risk management covers several areas that are vital for the BCP process. However, the BCP process goes beyond risk management's pre-emptive approach and moves on from the assumption that the disaster will realize at some point.

Benefits of using SCM. TEAM 5

Basically,you want to know the entire lifecycle of every line of code. You want to track who wrote it, what version it is of the larger product, and you must have the ability to recreate any build. As a software professional, you should strive to move software development from an art to a science. You want to imbed tools and processes into your SDLC process that will result in a more predictable software development and release cycle. Doing so will ensure a higher quality software product and reduce overall operating costs.
An SCM allows you to automate repetitive development tasks and manage the concurrent development process of multiple developers on the same project. SCMs enable you to develop software in a distributed environment regardless of the geographical location of your developers. Using an SCM helps you to create a more bug-free product, manage changes, manage bug fixes, and continue to build the next software release. Developer and manager productivity will increase when you use an SCM.

SCM Team5

Software configuration management

Software configuration management is a crucial activity for any software development effort. The software configuration management activity, however, must not delay or impede the rapid software development schedule necessary to meet the harsh time to market needs of the E-World.
Consequently, effective and time-efficient software configuration must be practiced with all efforts having a justification in functional value. The software configuration management theoretical model that is most commonly referred to in literature does not easily correspond to the functions that must be accomplished through software configuration management activities. A better model that is functional in derivation, and that will be clearly understood and will be easily scaleable is the subject of this paper.
A functional model of software configuration management is organized into the areas of 1) version control, 2) document control, 3) change management, 4) build management, and 5) release control. This typology corresponds directly to the functional tasks that must be performed for a project and also agrees with the typology of the major software configuration management tool vendors.

A better model for software configuration management that is clearly understood and is scaleable is the subject of this paper. Software configuration management can be functionally broken out into the areas of 1) version control, 2) document control, 3) change management 4) build management, and 5) release control.

TEAM II - NEED FOR SOFTWARE TESTING

Testing is usually performed for the following purposes:

• To improve quality.
  Quality means the conformance to the specified design requirement. Being correct, the minimum requirement of quality, means performing as required under specified circumstances. Debugging, a narrow view of software testing, is performed heavily to find out design defects by the programmer. The imperfection of human nature makes it almost impossible to make a moderately complex program correct the first time. Finding the problems and get them fixed is the purpose of debugging in programming phase.
• For Verification & Validation (V&V)
  Another important purpose of testing is verification and validation (V&V). Testing can serve as metrics. It is heavily used as a tool in the V&V process. Testers can make claims based on interpretations of the testing results, which either the product works under certain situations, or it does not work. We can also compare the quality among different products under the same specification, based on results from the same test.
  We can not test quality directly, but we can test related factors to make quality visible. Quality has three sets of factors -- functionality, engineering, and adaptability. These three sets of factors can be thought of as dimensions in the software quality space. Each dimension may be broken down into its component factors and considerations at successively lower levels of detail.
• Some of the most frequently cited quality considerations.
  Functionality (exterior quality)
  Engineering (interior quality)
  Adaptability (future quality)
  Correctness
  Efficiency
  Flexibility
  Reliability
  Testability
  Reusability
  Usability
  Documentation
  Maintainability
  Integrity
  Structure
  Good testing provides measures for all relevant factors. The importance of any particular factor varies from application to application.
• For reliability estimation
  Software reliability has important relations with many aspects of software, including the structure, and the amount of testing it has been subjected to. Based on an operational profile (an estimate of the relative frequency of use of various inputs to the program ), testing can serve as a statistical sampling method to gain failure data for reliability estimation.
  Software testing is not mature. It still remains an art, because we still cannot make it a science. We are still using the same testing techniques invented 20-30 years ago, some of which are crafted methods or heuristics rather than good engineering methods. Software testing can be costly, but not testing software is even more expensive, especially in places that human lives are at stake. Solving the software-testing problem is no easier than solving the Turing halting problem. We can never be sure that a piece of software is correct. We can never be sure that the specifications are correct. No verification system can verify every correct program. We can never be certain that a verification system is correct either.