types of testing

Black box testing and white box testing

SOFTWARE QUALITY ASSURANCE

1. Definition:

SQA is the planned and systematic set of activities that ensure that software process and products conform to requirements, standards, and procedures.

"Processes" include all activities involved in designing, coding, testing and maintaining; "products" include software, associated data, documentation, and all supporting and reporting paperwork.

The role of SQA is to give management the assurance that the officially established process is actually being implemented. It ensures that:
An appropriate development methodology is in place.
The projects use standards and procedures in their work.
Reviews and audits are conducted.
Documentation is produced to support maintenance and enhancement.
Software Configuration Management is set up to control change.
Testing is performed and passed.
Any deficiencies and deviations are identified and brought to management's attention.

2. Goals of SQA:
he software development is a complex process full risks. There are technical risks such as software will not perform as intended or be too hard to operate, modify, and/or maintain; there are programmatic risks such as the project will overrun cost or schedule.

The goals of SQA is to reduce these risks by:

Appropriately monitoring the software and the development process.
Ensuring full compliance with standards and procedures for software and process.
Ensuring that inadequacies in product, process, or standards are brought to management's attention so that they can be fixed.
SQA is not responsible for producing quality products or for making quality plans. They are responsible for auditing the quality actions and for alerting management to any deviations.
3 Responsibilities of SQA:

To achieve its goals, SQA is responsible for:
Review all development and quality plans for completeness.
Participate as inspection moderators in design and code inspections.
Review all test plans for adherence to standards.
Review samples of all test results to determine adherence to plans.
Periodically audit SCM performance to determine adherence to standards.
Participate in all project phase reviews and write down any nonconformance.

Systems Engineering

Systems Engineering (SE) is an interdisciplinary approach and means for enabling the realization and deployment of successful systems. It can be viewed as the application of engineering techniques to the engineering of systems, as well as the application of a systems approach to engineering efforts. Systems Engineering integrates other disciplines and specialty groups into a team effort, forming a structured development process that proceeds from concept to production to operation and disposal. Systems Engineering considers both the business and the technical needs of all customers, with the goal of providing a quality product that meets the user needs.




Closely related fields:
Many related fields may be considered tightly coupled to systems engineering. These areas have contributed to the development of systems engineering as a distinct entity.

• Cognitive systems engineering: This is Systems Engineering with the human integrated as an explicit part of the system. It draws from the direct application of centuries of experience and research in both Cognitive Psychology and Systems Engineering. Cognitive Systems Engineering focuses on how man interacts with the environment and attempts to design systems that explicitly respect how humans think, and works at the intersection of problems imposed by the world; needs of agents (human, hardware, and software); and interaction among the various systems and technologies that affect (and/or are affected by) the situation. Sometimes referred to as Human Engineering or Human Factors Engineering, this subject also deals with ergonomics in systems design.



• Control engineering: The design and implementation of control systems, used extensively in nearly every industry, is a large sub-field of Systems Engineering. The cruise control on an automobile and the guidance system for a ballistic missile are two examples. Control systems theory is an active field of applied mathematics involving the investigation of solution spaces and the development of new methods for the analysis of the control process.



• Industrial engineering: It is a branch of engineering that concerns the development, improvement, implementation and evaluation of integrated systems of people, money, knowledge, information, equipment, energy, material and process. Industrial engineering draws upon the principles and methods of engineering analysis and synthesis, as well as mathematical, physical and social sciences together with the principles and methods of engineering analysis and design to specify, predict and evaluate the results to be obtained from such systems.



• Interface design: This design and it's specification are concerned with assuring that the pieces of a system connect and inter-operate with other parts of the system and with external systems as necessary. Interface design also includes assuring that system interfaces be able to accept new features, including mechanical, electrical, and logical interfaces, including reserved wires, plug-space, command codes and bits in communication protocols. This is known as extensibility. Human-Computer Interaction (HCI) or Human-Machine Interface (HMI) is another aspect of interface design, and is a critical aspect of modern Systems Engineering. Systems engineering principles are applied in the design of network protocols for local-area networks and wide-area networks.



• Operations research: Operations research supports systems engineering. The tools of operations research are used in systems analysis, decision making, and trade studies. Several schools teach SE courses within the operations research or industrial engineering department[citation needed], highlighting the role systems engineering plays in complex projects. operations research, briefly, is concerned with the optimization of a process under multiple constraints.



• Reliability engineering: This is the discipline of ensuring a system will meet the customer's expectations for reliability throughout its life; i.e. it will not fail more frequently than expected. Reliability engineering applies to all aspects of the system. It is closely associated with maintainability, availability and logistics engineering. Reliability engineering is always a critical component of safety engineering, as in failure modes and effects analysis (FMEA) and hazard fault tree analysis, and of security engineering. Reliability engineering relies heavily on statistics, probability theory and reliability theory for its tools and processes.



• Performance engineering: This is the discipline of ensuring a system will meet the customer's expectations for performance throughout its life. Performance is usually defined as the speed with which a certain operation is executed or the capability of executing a number of such operations in the unit of time. It may be degraded where operations queue to be executed whenever the capacity is of the system is limited. For example, the performance of a packed-switched network would be characterised by the end-to-end packet transit delay or the number of packets switched within an hour. The design of performant systems makes use of analytical or simulation modeling, whereas the delivery of performant implementation involves thorough performance testing. Performance engineering relies heavily on statistics, queuing theory and probability theory for its tools and processes.



• Safety engineering: The techniques of safety engineering may be applied by non-specialist engineers (e.g., EEs or SEs) in designing complex systems to minimize the probability of safety-critical failures. The "System Safety Engineering" function helps to identify "safety hazards" in emerging designs, and may assist with techniques to "mitigate" the effects of (potentially) hazardous conditions that cannot be designed out of systems.



• Security engineering: This can be viewed as an interdisciplinary field that integrates the community of practice for control systems design, reliability, safety and systems engineering. It may involve such sub-specialties as authentication of system users, system targets, and others: people, objects, and processes.



• Software engineering: From its beginnings Software engineering has shaped modern Systems Engineering practice to a great degree.[citation needed] The techniques used in the handling of complexes of large software-intensive systems has had a major effect on the shaping and reshaping of the tools, methods and processes of SE (e.g., see SysML, CMMI, Object-oriented analysis and design, Requirements engineering, Formal methods and Language theory).



• Supportability engineering: Any system, when operational and providing the requirements defined in the design, needs degrees of support to maintain the operational functions. Supportability engineering is an analytical process that determines the optimal mix and distribution of support resources. By using the reliability aspects of the system and through isolating failure modes, causes and effects, the system's maintainability can be designed. A properly designed maintenance plan determines support resource capacities, such as trained support staff, documentation, spare parts, test equipment, repair facilities and contracted support, necessary to reduce the mean system downtime.

synchronization

The process of maintaining one operation in step with another. The commonest example is the electric clock, whose motor rotates at some integral multiple or submultiple of the speed of the alternator in the power station. In television, synchronization is essential in order that the electron beams of receiver picture tubes are at exactly the same spot on the screen at each instant as is the beam in the television camera tube at the transmitter

1. The arrangement of military actions in time, space, and purpose to produce maximum relative combat power at a decisive place and time.
2. In the intelligence context, application of intelligence sources and methods in concert with the operation plan.

Synchronization is a problem in timekeeping which requires the coordination of events to operate a system . The familiar conductor of an orchestra serves to keep the orchestra in time. Systems operating with all their parts in synchrony are said to be synchronous.

synchronization

In computer science, synchronization refers to one of two distinct, but related concepts: synchronization of processes, and synchronization of data. Process synchronization refers to the idea that multiple processes are to join up or handshake at a certain point, so as to reach an agreement or commit to a certain sequence of action. Data synchronization refers to the idea of keeping multiple copies of a dataset in coherence with one another, or to maintain data integrity. Process synchronization primitives are commonly used to implement data synchronization.

Process Synchronization
Process synchronization refers to the coordination of simultaneous threads or processes to complete a task in order to get correct runtime order and avoid unexpected race conditions

Data Synchronization
A distinctly different (but related) concept is that of data synchronization. This refers to the need to keep multiple copies of a set of data coherent with one another

Degrees of rigor

Degrees of Rigor

The degree of rigor is a function of many project characteristics. As an example, small, non-mission critical projects can generally be addressed with somewhat less rigor than large, complex mission critical applications. It should be noted, however, that all projects must be conducted in a manner that results in timely, high quality deliverables.

Four different degrees of rigor are defined for the APM:

Casual. All APM framework activities are applied, but only a minimum task set is required. In general, umbrella tasks will be minimized and documentation requirements will be reduced. All basic principles of software engineering are still applicable.

Structured. The APM framework will be applied for this project. Framework activities and related tasks appropriate to the project type will be applied and umbrella activities necessary to ensure high quality will be applied. SQA, SCM, documentation and measurement tasks will be conducted in a streamlined manner.

Strict. The APM will be applied for this project with a degree of discipline that will ensure high quality. All umbrella activities will be applied and robust documentation will be produced.

Quick Reaction. The APM will be applied for this project, but because of an emergency situation, only those tasks essential to maintaining good quality will be applied. "Back-filling" (e.g., developing a complete set of documentation, conducting additional reviews) will be accomplished after the application/product is delivered to the customer.

SOFTWARE METRICS-TEAM4

Software Metrics

Metrics are management tools which are used to estimate the cost and resource requirements of a project.

In order to conduct a successful software project we must understand the scope of work to be done, the risks incurred, the resources required, the tasks to be accomplished, the milestones to be tracked, the cost, and the schedule to be followed. Project management provides this understanding.

Before a project can be planned, objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified. This information is required to estimate costs, project tasks, and a project schedule.

Metrics help us understand the technical process that is used to develop a product. The process is measured to improve it and the product is measured to increase quality.

Measuring software projects is still controversial. It is not yet clear which are the appropriate metrics for a software project or whether people, processes, or products can be compared using metrics.

Estimates for project cost and time requirements must derived during the planning stage of a project. Experience is often the only guide used to derive these estimates, but it may be insufficient if the project breaks new ground. A number of estimation techniques exist for software development. These techniques consist of establishing project scope, using software metrics based upon past experience are used to generate estimates, and dividing the project into smaller pieces which are estimated individually.

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.

Project planning-team3

Project Planning Software for Pocket PC and Handheld PC
Pocket Plan is a Microsoft Project compatible project planning application for the Pocket PC and Handheld PC. Providing the same project planning capabilities as the desktop version of Plan, but running on a Pocket/Handheld PC!
Pocket Plan is a fully usable project planning tool in its own right, providing all the essential features you would expect to find in a PC based planning tool.
Using Pocket plan you can update your project plans on the move!
Use Pocket Plan stand-alone or use it along side desktop project planning tools such as Plan for Windows or Microsoft Project. Two-way synchronization is supported via ActiveSync allowing plans to be edited and recalculated on either device with subsequence re-synchronisation.

Team II-Definition of Software Testing

• The process of devising a set of inputs to a given piece of software that will cause the software to exercise some portion of its code. The developer of the software can then check that the results produced by the software are in accord with his or her expectations.
  
• Software testing is a process used to identify the correctness, completeness and quality of developed computer software. Actually, testing can never establish the correctness of computer software, as this can only be done by formal verification (and only when there is no mistake in the formal verification process). It can only find defects, not prove that there are none.

Steps in the risk management process - Team 6

Create a risk mitigation plan

The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing anti virus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions.

Review and evaluation of the plan

1.To evaluate whether the previously selected security controls are still applicable and effective, and
2.To evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment.

Risk management activities as applied to project management

In project management, risk management includes the following activities:
Planning how risk management will be held in the particular project. Plan should include risk management tasks, responsibilities, activities and budget.
Assigning a risk officer - a team member other than a project manager who is responsible for foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism.
Maintaining live project risk database. Each risk should have the following attributes: opening date, title, short description, probability and importance. Optionally a risk may have an assigned person responsible for its resolution and a date by which the risk must be resolved.
Creating anonymous risk reporting channel. Each team member should have possibility to report risk that he foresees in the project.
Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation plan is to describe how this particular risk will be handled – what, when, by who and how will it be done to avoid it or minimize consequences if it becomes a liability.
Summarizing planned and faced risks, effectiveness of mitigation activities and effort spend for the risk management

What is SCM?????????

Current definition would say that SCM is the control of the
evolution of complex systems. More pragmatically, it is the
discipline that enable us to keep evolving software products
under control, and thus contributes to satisfying quality and
delay constraints.
SCM emerged as a discipline soon after the so called
« software crisis » was identified, i.e. when it was
understood that programming does not cover everything in
Software Engineering (SE), and that other issues were
hampering SE development, like architecture, building,
evolution and so on.
SCM emerged, during the late 70s and early 80s, as an
attempt to address some of these issues; this is why there is
no clear boundary to SCM topic coverage. In the early 80s
SCM focussed in programming in the large (versioning,
rebuilding, composition), in the 90s in programming in the
many (process support, concurrent engineering), late 90s in
programming in the wide (web remote engineering).
Currently, a typical SCM system tries to provide services in
the following areas:

• Managing a repository of components
• Help engineers in their usual activities
• Process control and support
  

software configuration management(Architecture)

Software Development Metrics- Team IV