Risk Identification

The objectives of risk identification are to :
(1) identify and categorize risks that could affect the project and
(2) document these risks.
The outcome of risk identification is a list of risks. For non-complex, low-cost projects, the risks may be kept simply as a list of red flag items. The items can then be assigned to individual team members to watch throughout the project development process and used for risk allocation purposes, as described later in this document. For complex, high-cost projects, the risks can feed the rigorous process of assessment, analysis, mitigation and planning, allocation, and monitoring and updating described in this document.

The risk identification process begins with the team compiling the project's risk events. The identification process will vary, depending on the nature of the project and the risk management skills of the team members, but most identification processes begin with an examination of issues and concerns created by the project development team. These issues and concerns can be derived from an examination of the project description, work breakdown structure, cost estimate, design and construction schedule, procurement plan, or general risk checklists. Checklists and databases can be created for recurring risks, but project team experience and subjective analysis almost always will be required to identify project specific risks. The team should examine and identify project events by reducing them to a level of detail that permits an evaluator to understand the significance of any risk and identify its causes, (i.e., risk drivers).

One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories :
- Product size : risks associated with the overall size of the software to be built or modified.
- Business Impact : risks associated with constraints imposed by management or the marketplace.
- Customer characteristics : risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner.
- Process definition : risks associated with the degree to which the software process has been defined and is followed by the development organization.
- Development environment : risks associated with the availability and quality of the tools to be used to build the product.
- Technology to be built : risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.
- Staff size and experience : risks associated with the overall technical and project experience of the software engineers who will do the work.

Quick Overview of SQA Plan

The SQA plan provides a road map for instituting software quality assurance.

Basic components of a SQA:
- The purpose of the plan and its scope
- management
* organization structure, SQA tasks, their placement in the process.
* roles and responsibilities related to product quality.
- documentation
* project documents, models, technical documents, user documents.
- standards, practices, and conventions.
- reviews and audits.
- test - test plan and procedure.
- problem reporting, and correction actions.
- tools.
- code control.
- media control.
- supplier control.
- records collection, maintenance, and retention.
- training.
- risk management.

Statistical Quality Assurance - Overview

Statistical quality assurance reflects a growing trend throughout industry to become more quantitative about quality. And what does Statistical quality assurance means. Well, those big word imply the following series of steps steps that form the process:

- Information about software defects is collected and categorized.
- An attempt is made to trace each defect to its underlying cause.
- Using the Pareto principle (80 percent of the defects can be traced to 20 percent,
and isolate the 20 percent).
- Once the vital few causes have been identified, the defects are corrected.

Causes of errors:
- incomplete or erroneous specification (IES).
- misinterpretation of customer communication (MCC).
- intentional deviation from specification (IDS).
- violation of programming standards (VPS).
- error in data representation (EDR).
- inconsistent module interface (IMI).
- error in design logic (EDL).
- incomplete or erroneous testing (IET).
- inaccurate or incomplete documentation (IID).
- error in programming language translation of design (PLT).
- ambiguous or inconsistent human-computer interface (HCI).
- miscellaneous (MIS).

In conjunction with the collection of defect information, software developers can calculate an error index (EI) for each major step in the software engineering process. After analysis, design, coding, testing, and release, the following data are collected:
Ei = the total no. of errors uncovered during the ith step in the process.
Si = the no. of serious errors.
Mi = the no. of moderate errors.
Ti = the no. of minor errors.
PS = the size of the product at the ith step.
At each step in the software engineering process, a phase index (PI i ) is computed:
PI i = ws (Si/Ei) + wm(Mi/Ei) + wt(Ti/Ei)
Error index (EI) can be computed as follows:
EI = (PI 1 + 2 PI 2 + 3 PI 3 + iPI I)/PS

Introduction To Software Reviews

What are software reviews?
- serves as a “filter” for the software engineering process.

Purpose: Software reviews serve to uncover errors in analysis, design, coding, and testing and are hence invaluable.

Why do software reviews? The general principle behind doing reviews are:
- To err is human.
- It may not be easy to catch the errors in engineers’ work, the kind of errors that are not found in bugs.
- Finding errors early in the process is always more efficient than detecting errors much later in the cycle.

A review is a way to :
- identify needed improvements of the various parts and modules of a product.
- confirm the improvement areas of a product (if the improvements had been suggested by others).
- achieve technical work that can be more uniform, predicable, and manageable, making for a more better end result and a smoother cycle.

What are the different types of reviews:
- Informal reviews : informal meeting and informal desk checking.
- Formal reviews : Walkthrough, inspection, and round-robin reviews.

Formal Technical Reviews are used to improve work products. As a part of this process, any deliverable that is produced during the development life-cycle is eligible to be reviewed and should be picked up for review starting at an early stage, beginning in the specification stage and recurring at each identifiable milestone.

- A Review meeting is an important part of the of FTR (Formal Technical Review). There are are some essential parameters for the meeting, such as
1. There should be a reasonable number of persons conducting the meeting, not being a free-for-all
2. Each one of them should have done his/her homework and other preparation
3. The meeting should not be carried out for very long and should have a well defined agenda to avoid wastage of time. The duration should be just enough to churn out some constructive results.
4. The Formal Technical Review is effective when a small and specific part of the overall software is under scrutiny.
5. A review is more productive when the review artefacts have been broken down into small modules that can be reviewed independently. The target of the FTR (Formal Technical Review) is on a component of the project, a single module.

- Record keeping and reporting are additional quality assurance activities. They are applied to different stages of software development. During the FTR, it is the responsibility of reviewer (or recorder) to record all issues that have been raised.
At the end of review meeting, a review issue list that summarizes all issues, is produced. A simple review summary report is also compiled. A review summary report answers the following questions.
1. What was reviewed?
2. Who reviewed it ?
3. What were the findings and conclusions?

- Review Guidelines : A minimum set of guidelines for FTR:
* Review the product, not the producer.
* Set an agenda and maintain it.
* Limit debate and rebuttal.
* Enunciate problem areas, but don’t attempt to solve every problem noted.
* Take written notes.
* Limit the number of participants and insist upon advance preparation.
* Develop a checklist for each work product that is likely to be reviewed.
* Allocate resources and time schedule for FTRs.
* Conduct meaningful training for all reviewers.
* Review your early reviews.

Software Quality Assurance - SQA

Software Quality Assurance (SQA) is defined as a planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes, and procedures. SQA includes the process of assuring that standards and procedures are established and are followed throughout the software acquisition life cycle. Compliance with agreed-upon standards and procedures is evaluated through process monitoring, product evaluation, and audits. Software development and control processes should include quality assurance approval points, where an SQA evaluation
of the product may be done in relation to the applicable standards.

STANDARDS AND PROCEDURES :
Establishing standards and procedures for software development is critical, since these provide the framework from which the software evolves. Standards are the established criteria to which the software products are compared. Procedures are the established criteria to which the development and control processes are compared.
Standards and procedures establish the prescribed methods for developing software; the SQA role is to ensure their existence and adequacy. Proper documentation of standards and procedures is necessary since the SQA activities of process monitoring, product evaluation, and auditing rely upon unequivocal definitions to measure project compliance.

SQA ACTIVITIES :
Software quality assurance is composed of a variety of tasks associated with two different constituencies - the software engineers who do technical work and an SQA group that has responsibility for quality assurance planning, oversight, record keeping, analysis, and reporting. Product evaluation and process monitoring are the SQA activities that assure the software development and control processes.
Product evaluation is an SQA activity that assures standards are being followed. Product evaluation assures that the software product reflects the requirements of the applicable standard(s) as identified in the Management Plan.
Process monitoring is an SQA activity that ensures that appropriate steps to carry out the process are being followed.
A fundamental SQA technique is the audit, which looks at a process and/or a product in depth, comparing them to established procedures and standards. Audits are used to review management, technical, and assurance processes to provide an indication of the quality and status of the software product.

ROLE OF AN SQA GROUP :
- Prepares an SQA plan for a project.
- Participates in the development of the project's software process description.
- Reviews software engineering activities to verify compliance with defined software process.
- Audits designated software work products to verify compliance with those defined as part of software process.
- Ensures that deviations in software work and work products are documented and handled according to a document procedure.
- Records any noncompliance and reports to senior management.

Quality Management - Overview

Software quality management is an umbrella activity - incorporating both quality control and quality assurance - that is applied at each step in the software process. SQA encompasses procedures for the effective application of methods and tools, formal technical reviews, testing strategies and techniques, procedures for change control, procedures for assuring compliance to standards, and measurement and reporting mechanisms.
SQA is complicated by the complex nature of software quality - an attribute of computer programs that is defined as "conformance to explicitly and implicitly specified requirements. But when considered more generally, software quality encompasses many different product and process factors and related metrices.

Software reviews are one of the most important quality control activities. Reviews serve as filters throughout all software engineering activities, removing errors while they are relatively inexpensive to find and correct. The formal technical review is stylized meeting that has been shown to be extremely effective in uncovering errors.
To properly conduct software quality assurance, data about the software engineering process should be collected, evaluated, and disseminated. Statistical SQA helps to improve the quality of the product and the software process itself. Software reliability models extend measurements, enabling collected defect data to be extrapolated into projected failure rates and reliability predictions.

Software quality assurance is the mapping of the managerial precepts and design disciplines of quality assurance onto the applicable managerial and technological space of software engineering. The ability to ensure quality is the measure of a mature engineering discipline. When the mapping is successfully accomplished, mature software engineering is the result.

Software Configuration Management Process

The SCM repository is the set of mechanisms and data structures that allow a software team to manage change in an effective manner. It provides the obvious functions of a DBMS but in addition, the repository performs or precipitates functions such as :
- data integrity.
- information sharing.
- tool integration.
- data integration.
- methodology.
- document standardization.
To achieve these functions, the repository is defined in terms of a meta-model.

Software Configuration Management Process :
A process defines the steps by which you perform a specific task or set of tasks. An SCM process is the way SCM is performed on your project—specifically, how an SCM tool is applied to accomplish a set of tasks.
- Identification of Artefacts
Early identification and change control of artefacts and work products is integral to the project. The configuration manager needs to fully identify and control changes to all the elements that are required to recreate and maintain the software product.
- Version Control
The primary goal of version control is to identify and manage project elements as they change over time. The Configuration Manager should establish a version control library to maintain all lifecycle entities. This library will ensure that changes (deltas) are controlled at their lowest atomic level eg documents, source files, scripts and kits etc.
- Change Request Management
Change Request management can be described as management of change/enhancement requests. Typically the Configuration Manger should set up a repository to manage these requests and support activities like status tracking, assignment etc.
- Configuration audit
Identification, version control, and change control help the software developer to maintain order in what would otherwise be a chaotic and fluid situation. But how can we ensure that the change has been properly implemented?
A software configuration audit complements the formal technical review by addressing the following questions :
- Has the change specified in the ECO been made? Have any additional modifications been incorporated.
- Has a formal technical review been conducted to assess technical correctness.
- Has the software process been followed?
- Has the change been highlighted in SCI?
- Have SCM procedures for noting the change, recording it, and reporting it been followed?
- Have all related SCIs been properly updated?