smqa unit iv

UNIT- IV

•Software Documentation

Mr. M. E. Patil S.S.B.T COET, Bambhori

Software Documentation

• Identifies all relevant documentation which concerns development, verification, validation, use and maintainance of the software.

• It states how documents will be checked for accuracy and describes criteria for document distribution.



DocumentationDocumentation is often seriously neglected by software programmers. Many projects and companies have failed due to poor quality

documentation.If you find your programmer does not, or will not, document their

software, then it is best to get rid of them now. If the software is undocumented and they leave, the only option is to start

again and rewrite it all. Picking up the pieces of poorly documented software is a very expensive

and a time consuming exercise, it’s cheaper to start from scratch.

Reasons to document

• 1) So that you can understand the software • 2) So that the software can be understood by other people • 3) So that advanced projects can be undertaken • 4) So that you can use parts of the code for other projects • 5) To make life easier for your self


IEEE std 730, A minimum Documentation must include

• Software Requirement Specification (SRS) • Software Design Description.• Software verification and validation plan (SVVP)• Software verification and validation report. (SVVR)• User documentation • Software configuration management plan.• Software test plan.• Software test report


Software Requirement Specification (SRS)

• Describe the capabilities, states and functionality of all aspects of the system

• This includes major components, subcomponents and interface of the software and may include databases.

• It includes the specially required items by the users.• Documentation needs to be prepared for each

deliverables and non deliverable item of the software, firmware and hardware.


Software Design Description

• This includes major components, subcomponents and interface of the software and may include databases

• This process should be carried out by the standard procedure which has been agreed on.

• This process may include use of computerized tools.


Software Interface Documentation

• It describes capabilities and functionality of all interfaces between any two components of the system.

• This include the major components , subcomponents and external systems

• Both internal and external interfaces of the software should be described.


Software Test documentation

• It includes the test cases and test case specifications • The test case specification includes all information

directly needed for performing the actual testing of the various software modules.

• The software test documentation include – Test design specification.– Test log – Test summary report


Software Development Plan

• There is no good standard for this• Whatever format you choose to use, come

with a format , get everyone to agree on it , and stick to it.


User Documentation

• Ex. Manuals , Guides and so on.• It specifies and describe the required inputs, options

and other user activities necessary for the successful use and application of the system.

• The user documentation have two objectives– Tutorial objective -to train the user– To provide the on-going reference from the usage

of the system


Document distribution

• Process interface to configuration mgt.• Distribution to internal project personnel• Distribution to external project personnel• Security limitations of documents.


Types Of Documentation

• Architecture/Design – Overview of software. Includes relations to an environment and construction principles to be used in design of software components

• Technical – Documentation of code, algorithms, interfaces and APIs

• End User – Manuals for the end-user, system administrators and support staff

• Marketing – Product briefs and promotional collateral


Standards, Practices, Conventions and Metrics

Standrads

To be applied by every step of product development• Documentation• Variable and module naming• Software programming standards• Software inspection procedures• Software testing standards and procedure• Software quality metrics


MetricsMetrics refer to the collection and use of data which

reflect productivity and quality of the products produced

The unit of labour is LOCSoftware quality metrics must include• Branch metric• Decision point metric• Domain metric• Error message metric• Requirements demonstration metric


ISO 9000

Paragraph 4.4 of standard (ISO 9000) states following :

“ The supplier shall establish and maintain documented procedures to control and verify the design of the product in order to ensure that the specified requirements are met.”


ISO 9000The list includes :• Design and development planning (4.4.2)• Organizational and technical interfaces (4.4.3)• Design input (4.4.4)• Design Output (4.4.5)• Design Review (4.4.6)• Design Verification (4.6.7)• Design Validation (4.4.8)• Design Changes (4.4.9)


ISO 9000

• This is very broad coverage• The coverage is good, but it is difficult to

understand and implement


Are all standards, practices, conventions and metrics which are to be applied, identified?

- Is compliance with these items monitored and assured?

- Are the following standards all provided:• Documentation standards?• Logic structure standards?• Coding and commentary standards?


Quality Assurance Techniques

Nine Techniques

• Reviews• Standardization• Simulation• Testing• Analytical Modeling• Execution Analysis• Independent verification and validation technique

• Correctness proof


Reviews

• There are four review techniques• 1) Auditing

– Desk checking of development documents for accuracy, clarity and standards conformance as well as for errors by the individuals

– Least expensive– Excellent way to detect and correct the errors– It is very Talent dependent


Reviews

• 2) Inspection– It is a highly disciplined and formal technique of

group of dynamics used for finding the errors in deliverables, such as documents and source code.

– All participants have well defined role, while management is specifically excluded from the participation .

– Most expensive but most effective at finding errors.


Reviews

• 3) Reviewing – Called as Peer reviews or management reviews

depending on the method used for selection of participants

– It is the technique of displaying results of a development process.

– The audience will usually consists of few developers , managers and user representatives

– Very expensive when large number of peoples are involved .


Reviews

• 4) Walkthrough– Intermediate deliverables can be tested for

completeness and verified against peer documents.

– Some times called as document testing – Least expensive .


Standardization

• It is the process of creation of formal operational criteria that establish a model against which deliverables and the procedures can be compared and measured.

• This is critical technique for any installation


Simulation

• This is the process of studying system behavior through use of measurable computer models

• Usually performed utilizing specialized tools such as simulation language.


Testing

• Most commonly used and misused verification method

• 45% or more budget are spent on testing.


Types of Testing

• Acceptance Testing

– Overall check of final products at and/or prior to delivery to ascertain that the product is according to the contractual requirements

– Is simply judged as more of a legal act than a technical one.


Types of testing

System Testing– Overall check of final products at and/or prior to

delivery and is the final technical survey and evaluation of the viability and quality of the system, as produced.

Functional Testing-- This is the technique to discover discrepancies

between the functional definitions of the system and the actual operating system.


Types of Testing

Logical testing– It is used to discover errors in the system

computation and logical functions.

.Path Testing--This testing is used to confirm test effectiveness(

coverage), based on control topology of the code.-- this technique demands the knowledge about the

internal structure of the source code.


Types of Testing

Stress Testing-Test to demonstrate at which point the system can be caused to overload ie. The extreme conditions.

Regression testing- This involves old tests to be run (previously run and achieved)-Is used to demonstrate that the new release still performs everything the old one did.


Analytical modeling

• Analytical modeling attempt to develop mathematical representations of the system.

• It is similar to (and frequently a part of ) simulation.


Execution Analysis

• Technique of analysis of an execution.

• Usually used to find the efficiency bottlenecks.


Independent verification, validation and testing

• This form of testing involves the utilization of totally independent agency to find critical errors during the development process.

• It is very expensive but very efficient technique.

• Used for large and/or critical projects. particularly involving the danger of loss of life

• Ex. Atomic reactor control system.


Correctness Proofs.

• These are the techniques used for formally prove the correctness of programs or algorithms, similar to mathematical theorems

• These are not suitable for the real-life systems.


Reviews and Audits

Reviews and Audits

• Reviews and audits are to ensure that the product meets all client needs and requirements and to find development anomolies as early and inexpensively as possible.


Reviews and Audits

• Management Review Process• Technical Review Process• Software Inspection Process• Walkthrough Process• Audit Process• Document Verification


Software Inspection Process


Software Inspection Objectives

• To detect and identify software element defects.

• It is conducted by a group of 3-6 participants.

• Defect data shall be systematically collected and stored in the inspection data base.

• Most powerful mechanism for finding defects in documents and the program code


Special Responsibilities

Moderator- He is the chief planner- Meet the manager for the inspection process.

Reader- At the meeting the reader leads the inspection

team through the software elements in comprehensive and logical fashion.



Recorder- The recorder is charged with documenting defects at

the meeting and recording inspection data required for process analysis.

Inspector- Identifies and describes defects in the software element.-Must be knowledgeable of the inspection process-should represent viewpoints at the meeting



Author-The author is responsible for the software

elements meeting its inspection entry criteria

-Responsible for contributing to the inspection based on special understanding of the software elements for performing any rework required


Software Inspection Input

• Software Elements to be inspected.

• Approved software element specification and inspection checklist.

• Standards and guidelines.

• Any inspection reporting forms.


Entry Criteria

Authorization- Inspections are planned for and documented in the appropriate project planning documents.

Initiating the Event- The inspection process is triggered by

-Software elements availability -Project plan compliance-SQAP or SVVP schedule compliance.-scheduled re-inspection-At the request of management


Minimum Entry Criteria.-The software elements must confirm to

project standard of content and format.-All prior milestones must be satisfied.-All required supporting documentation must be available- For re-inspection all items noted on the

defect list must be satisfied.


Software Inspection Procedure

Planning-The author assembles the inspection package materials for the moderator-The moderator is responsible for assuring that they meet the inspection entry criteria.

Overview-If scheduled an overview presentation of the software element is conducted by the moderator-The author makes the presentation.



Preparation-Each inspector must become thoroughly familiar with the software element.

Examination-The Inspection meeting follows this agenda

-Introduce meeting-Establish preparedness-Review the inspection checklist-Read s/w elements & record defects.-Review the defect list.-Make the exit decision.



Rework-The author revises the materials, addressing all items on the inspection defect list.

Follow-up-It provides follow-up on two levels.

-Verifying rework per inspection-Reporting inspection data


Software Inspection Exit Criteria

• All the defects that have been detected are resolved.

• This single exit criteria is applied to all inspections.

• Each project shall develop its own criteria to meet the needs of its specific products and development environment.


Software Inspection Output

• Defect list containing the defect location , description, categorization .

• Inspection defect summary.• Inspection report containing

number of participants, meeting duration, the size of material inspected, the total preparation time of the inspection team, the estimate of the rework effort and the rework completion date


Software Inspection Audit ability

• It is provided by the following

-Documented inspection procedures

-Retained inspection reports

-Retained inspection defect data.


Data Collection Requirements

• Defects are categorized by the followingType- It identifies s/w element attributesClass- It characterize evidence of nonconformance,

and for example may be categorized as missing, wrong, or extra.

Other Classes- Additional defect classes used when inspecting documents could include ambiguous and inconsistent.

Severity- All defects are ranked by severity, such as major severity and minor severity.


Walkthrough Process

Walkthrough Objective• To evaluate software for defects , omissions, and

contradictions & to consider alternative implementations.

• The author makes an overview presentation of the software elements under review.

• This is followed by the discussion from the participants after which the presenter walks through the software elements in detail.

• It is useful but less effective than inspection



Moderator-Is responsible for conducting specific

walkthrough

Recorder-Responsible for writing all comments made during the walkthrough that pretend to

-error found

- question of style


- omissions - contradictions- suggestions for improvements or

alternative approaches.

Author

-The author is responsible for the software elements being examined and presents the materials.


Walkthrough Input

• Statement of objectives for the walkthrough

• The software element under examination.

• Standards

• Specifications for the software elements.


Entry Criteria

Authorization– Walkthrough are planed for, and documented in

the appropriate project planning documents.

Initiating Event- it is conducted when the author indicates that the

software element is ready and when the moderator is appointed.


Walkthrough Procedures

1) Planning– Moderator identifies the team– Schedules the meeting – Distributes all necessary materials.2) Overview-presentation is made by the author3)Preparation -Each member must review the input materials

during this phase.


4) Examination-The presenter makes an overview presentation -The author walks through the specific software

elements so that the walkthrough team may ask questions or raise issues regarding the software element.

5) Exit Criteria-It will be complete when the entire software

elements have walked through.-all the deficiencies , omissions , and suggestions

for improvement have been noted and the walkthrough report has been issued.


Walkthrough Output

• It contains statement of objectives, a list of– deficiencies, – omissions, – contradictions – suggestions and any recommendations regarding

how to overcome the deficiencies


Auditability

• The walkthrough report meeting minutes, and other materials on which conclusions are based, shall become part of he project documentation


Software Audit

Audit Objective

• Compliance confirmation of products and processes to certify adherence to standards, guidelines, specifications and procedures

• Audits are performed in accordance with documented plans and procedures

• Two kinds of audits- individual, desk check type and- audit performed by a teamIt is the responsibility of the audit team leader to organize and direct the audit


Audit Input

Following inputs are required• Purpose and scope of the audit• Objective audit criteria• The software elements and processes to be

audited• Background information for the products and

processes being audited


Entry Criteria

• A special project milestone has been reached• External parties demand an audit• A local organizational element has requested

the audit


Audit Procedures

• Planning• Overview• Preparation• Examination• Reporting


Planning• Project processes to be examined• Software required to be examined• Reports shall be identified• Report distribution• Required follow-up activities• Requirements• Objective audit criteria• Audit procedures and checklists• Audit personnel• Organizations involved in the audit• Date, time, place, agenda and intended audience of overview

session


Overview

• Overview meeting with the audited organization is recommended


PreparationPreparations required by the audit team

• Understand the organization• Understand the products and processes• Understand the objective audit criteria• Prepare for the audit report• Detail the audit plan

Audit team leader should make arrangements for• Team orientation and training as needed• Facilities for audit interviews• Materials, documents and tools required• The software elements to be audited• Scheduling interviews


Examination

• Review procedures and instructions• Examine the work breakdown structures• Examine evidence of implementation and

balanced controls• Interview personnel to ascertain the status

and functioning of the processes and the status of the product

• Examine element documents• Test the elements


Reporting

• Audit team will issue a draft report for review and comments

• It will have deficiencies, findings and recommendations


Audit Exit Criteria

• Each element is examined• Findings are presented• Response to draft audit is received• Final findings are formally presented• The audit report is prepared and submitted• The recommendation report is prepared• The follow-up actions have been performed


Audit Output

The draft and final audit report shall contain• Audit identification• Scope• Conclusions• Synopsis• Follow-up


ISO 9000 Quality Standards

ISO 9000

• Is a family of standards for quality management systems

• It is maintained by ISO, the International Organization for Standardization and is administered by accreditation and certification bodies


ISO 9000

Some of the requirements in ISO 9001 would include :

• A set of procedures that cover all key processes in the business

• Monitoring processes to ensure they are effective• Keeping adequate records• Checking output for defects, with proper corrective

action• Regularly reviewing individual processes and the

quality system itself for effectiveness• Facilitating continual improvement


ISO 9000

• A company or organization that has been independently audited and certified to be in conformance with ISO 9001 may publicly state that it is “ ISO 9001 certified ” or “ ISO 9001 registered ”.


ISO 9000

• Certification to an ISO 9000 standard does not guarantee the compliance i.e. quality of end products and services, rather it certifies that consistent business processes are being applied


ISO 9000

ISO 9001 : 2000 is the standard that provides a set of standardized requirements for a quality management system regardless of

• What the user organization does• It’s size• Whether it is in the private or public sector


ISO 9000

Why an organization should implement ISO 9001 : 2000

• Without satisfied customers, an organization is in peril!

• To keep customers satisfied, the organization needs to meet their requirements

• The ISO 9001 : 2000 standard provides a tried and trusted framework for taking a systematic approach to managing the organization’s processes so that they consistently turn out product that satisfies customers’ expectations


Comparison of ISO 9000 Model with SEI’s CMM

Both models deal with methods of accessing the ability of suppliers to

meet their commitments

Capability Maturity Model, CMM• CMM is a five level framework for measuring

Software Engineering Practices• They determine the degree of technological maturity

of an organization- by answers to some 101 questions

• A CMM assessment usually takes five working days• It is conducted by a team of four people• The assessors must be highly-trained professionals

with great development experience• The SEI takes care to control over who an assessor is

and what rights the person may have


ISO 9000

• It defines a minimum level of generic attributes for a quality management program

• CMM addresses only software, while ISO 9000 addresses the entire organization


Model’s Orientations

• Orientation of CMM is software development process

• The CMM was specifically developed for software management and engineering process issues

• The model describes a series of levels, five in number : key process areas (KPA) and their usages

• Software QA is (a KPA of) level 2• Software quality management is (a KPA of) level 4


Model’s Orientations

• The Orientation of ISO 9000-3 is a quality system management

• The objective of ISO 9000 series is the structure and auditability of QA of organization


ISO 9000 Weaknesses

Issue 1 : Complexity• ISO 9000 itself is not simply a standard but a

set of standardsIssue 2 : Repeatability (Reliability of Audit)

• One of the most pressing weakness is who audits the auditor?

• There is no universally accepted system for certifying an ISO 9000 auditor


ISO 9000 Weaknesses

Issue 3 : Inherent Structure• A software organization is not audited

according to ISO 9000-3 but only according to ISO 9001

• The quality audit is performed according toISO 9001


ISO 9000 Weaknesses

Issue 4 : Key audit factors• They are very limited and most KPAs are not

even mentioned• E.g. requirements, design, testing, project

management• There are no agreed-upon metrics for any

area


ISO 9000 Weaknesses

Issue 5 : Process/product improvement• Some concepts are nonexistent• ISO 9000 has become a very important

marketing issue


CMM Weaknesses

Issue 1 : Granularity• It is too small• It allows some sort of shading for instances

when a site excels in one technology but lacks in another


CMM Weaknesses

Issue 2 : People/process/technology• The CMM is based on

people/process/technology• This is insufficient• What is demanded to produce software is :

High QualityUsefulOn time and within budgets


CMM Weaknesses

Issue 3 : CMM Focus• The focus of the CMM is still on technology,

not problem solving


CMM Weaknesses

Issue 4 : Site ComparisionsThe following must be proven for validity

• Graduating to the next level• Improvements in productivity• Quality and customer satisfaction


CMM Weaknesses

Issue 5 : Objective measurements• The model does not sufficiently include

objective measurements of real things


CMM Strengths

• Very strong control over the auditors• The SEI is maintaining a “public database” of

the data collected by it’s accredited auditors


smqa unit iv

Education