Smqa 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.

Mr. M. E. Patil

Documentation
Documentation 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.

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

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.

Mr. M. E. Patil

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.

Mr. M. E. Patil

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.

Mr. M. E. Patil

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

Mr. M. E. Patil

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.

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

Metrics
Metrics refer to the collection and use of data which
reflect productivity and quality of the products
produced
The unit of labour is LOC
Software quality metrics must include
• Branch metric
• Decision point metric
• Domain metric
• Error message metric
• Requirements demonstration metric

Mr. M. E. Patil

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.”

Mr. M. E. Patil

ISO 9000
The 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)

Mr. M. E. Patil

ISO 9000
• This is very broad coverage
• The coverage is good, but it is difficult to
understand and implement

Mr. M. E. Patil

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?

Mr. M. E. Patil

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

• Correctness proof

Mr. M. E. Patil

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

Mr. M. E. Patil

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.

Mr. M. E. Patil

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 .

Mr. M. E. Patil

Reviews
• 4) Walkthrough
– Intermediate deliverables can be tested for
completeness and verified against peer
documents.
– Some times called as document testing
– Least expensive .

Mr. M. E. Patil

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

Mr. M. E. Patil

Simulation

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

• Usually performed utilizing specialized tools such as
simulation language.

Mr. M. E. Patil

Testing

• Most commonly used and misused verification
method

• 45% or more budget are spent on testing.

Mr. M. E. Patil

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.

Mr. M. E. Patil

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.

Mr. M. E. Patil

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.

Mr. M. E. Patil

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.

Mr. M. E. Patil

Analytical modeling

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

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

Mr. M. E. Patil

Execution Analysis

• Technique of analysis of an execution.

• Usually used to find the efficiency bottlenecks.

Mr. M. E. Patil

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.

Mr. M. E. Patil

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.

Mr. M. E. Patil

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.

Mr. M. E. Patil

Reviews and Audits
• Management Review Process
• Technical Review Process
• Software Inspection Process
• Walkthrough Process
• Audit Process
• Document Verification

Mr. M. E. Patil

Software Inspection Process

Mr. M. E. Patil

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
Mr. M. E. Patil

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.

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

Software Inspection Input
• Software Elements to be inspected.

• Approved software element specification and
inspection checklist.

• Standards and guidelines.

• Any inspection reporting forms.

Mr. M. E. Patil

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

Mr. M. E. Patil

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.

Mr. M. E. Patil

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.
Mr. M. E. Patil

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.

Mr. M. E. Patil

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

Mr. M. E. Patil

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.

Mr. M. E. Patil

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

Mr. M. E. Patil

Software Inspection Audit ability
• It is provided by the following

-Documented inspection procedures

-Retained inspection reports

-Retained inspection defect data.

Mr. M. E. Patil

Data Collection Requirements
• Defects are categorized by the following
Type- It identifies s/w element attributes
Class- 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.

Mr. M. E. Patil

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

Mr. M. E. Patil


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

Mr. M. E. Patil

- omissions
- contradictions
- suggestions for improvements or
alternative approaches.
Author

-The author is responsible for the software
elements being examined and presents the
materials.
Mr. M. E. Patil

Walkthrough Input

• Statement of objectives for the walkthrough

• The software element under examination.

• Standards

• Specifications for the software elements.

Mr. M. E. Patil

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.

Mr. M. E. Patil

Walkthrough Procedures
1) Planning
– Moderator identifies the team
– Schedules the meeting
– Distributes all necessary materials.
2) Overview
-presentation is made by the author
3)Preparation
-Each member must review the input materials
during this phase.
Mr. M. E. Patil

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.

Mr. M. E. Patil

Walkthrough Output
• It contains statement of objectives, a list of
– deficiencies,
– omissions,
– contradictions
– suggestions and any recommendations regarding
how to overcome the deficiencies

Mr. M. E. Patil

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

Mr. M. E. Patil

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 team
It is the responsibility of the audit team leader to
organize and direct the audit
Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

Audit Procedures
• Planning
• Overview
• Preparation
• Examination
• Reporting

Mr. M. E. Patil

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

Mr. M. E. Patil

Overview
• Overview meeting with the audited
organization is recommended

Mr. M. E. Patil

Preparation
Preparations 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

Mr. M. E. Patil

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
Mr. M. E. Patil

Reporting
• Audit team will issue a draft report for review
and comments
• It will have deficiencies, findings and
recommendations

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

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
Mr. M. E. Patil

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 ”.

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

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
Mr. M. E. Patil

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
Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

ISO 9000 Weaknesses
Issue 1 : Complexity
• ISO 9000 itself is not simply a standard but a
set of standards
Issue 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
Mr. M. E. Patil

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 to
ISO 9001

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

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

Mr. M. E. Patil

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 Quality
Useful
On time and within budgets

Mr. M. E. Patil

CMM Weaknesses
Issue 3 : CMM Focus
• The focus of the CMM is still on technology,
not problem solving

Mr. M. E. Patil

CMM Weaknesses
Issue 4 : Site Comparisions
The following must be proven for validity
• Graduating to the next level
• Improvements in productivity
• Quality and customer satisfaction

Mr. M. E. Patil

CMM Weaknesses
Issue 5 : Objective measurements
• The model does not sufficiently include
objective measurements of real things

Mr. M. E. Patil

CMM Strengths
• Very strong control over the auditors
• The SEI is maintaining a “public database” of
the data collected by it’s accredited auditors

Mr. M. E. Patil

Smqa unit iv

Recomendados

Recomendados

Más contenido relacionado

Similar a Smqa unit iv

Similar a Smqa unit iv (20)

Último

Último (20)

Smqa unit iv