Tuesday, March 31, 2009

what about audit schedule?

  • Auditors keep a schedule
  • Keeps the audit on track and prevents auditors from getting too deep into details when it is unnecessary
  • The schedule is, however, a guideline
  • Auditors must be flexible and able to change the schedule if their original plan is not accurate
  • --Some things take less time than expected and others take more time than anticipated
  • Audits generally begin with an opening meeting to discuss the audit, and they end with a closing meeting to discuss the audit findings.
  • Audit findings are not secrets to be horded until the closing meeting. When an auditor believes he or she has identified a non-conformance, the auditee should be informed and allowed to provide additional information if possible

Example schedule

on one particular day e.g Monday 30th march,2007.

  • 8:00 - 8:30 Auditor Preparation
  • 8:30 - 9:00 Facility Tour
  • 9:00 - 9:30 Opening Meeting
  • 9:30 - 10:30 Management Review
  • 10:30 - 11:30 Control of Quality Records
  • 11:30 - 12:30 Working Lunch
  • 12:30 - 2:30 Product Realization
  • 2:30 - 4:30 Auditor Work Time
  • 4:30 - 5:00 Closing Meeting

what is an audit plan?

  • A formal document
  • A blueprint used by auditors to ensure that the audit is completed properly
  • should be part of the Documented Procedure for performing Internal Audits
The audit plan details a particular audit and includes:
  • The organization to be audited
  • Purpose and scope
  • Audit personnel
  • Activities to be audited
  • Organization/personnel that are to be audited
  • Applicable document/records
  • Audit checklist
  • Requirements for reporting results


The audit plan (ISO 19011 6.4.1)

  • Audit objectives
  • Audit criteria and reference documents
  • Audit scope (includes units and processes to be audited)
  • Dates and places where on-site activities are conducted
  • Time and duration of on-site activities, including meetings
  • Roles and responsibilities of audit team members
  • Allocation of resources to critical areas
  • Identification of auditee’s representative
  • Audit report topics
  • Logistic arrangements
  • Matters related to confidentiality
  • Any follow-up actions

what is there in audit planning?

Audits are formal activities and should be carefully planned

An Audit Plan defines
  • Agenda
  • Review Information
  • Date and Time
  • Work Hours
  • Distribution of Work

Working documents needed to facilitate the audit
  • Forms for documenting objective evidence
  • Forms for documenting audit findings
  • Procedures to be followed
  • Checklist format
  • Meeting topics
  • Meeting record format

what is the intent of an audit?

  • Audits verify the effectiveness of the Quality Management System.
  • Auditors do not audit people, only the Quality Management System.
  • Is the standard requirement being met?
  • Are the legal requirements being met?
  • An audit is not a test of how someone does his or her job.

what are skills and communication for auditors?

ISO 19011, a quality standard for auditors and audit programs defines the PERFECT auditor to be:
Ethical
  • Open-minded
  • Diplomatic
  • Observant
  • Perceptive
  • Versatile
  • Tenacious
  • Decisive
  • Self-reliant

what is not auditor's role?

Auditors are NOT


  • Fault finders
  • Rock throwers
  • Nit-pickers
  • An interrogation taskforce
  • Dishonest

what is auditor's role?

  • Look at the organization’s systems, procedures and records
  • --Determine if they are in conformance with their policy, procedures, agreed standard and appropriate standard and appropriate regulatory requirements.
  • Good auditor begins with the belief that the auditee is in conformance

what are the main qualifcations of auditor?

These qualifications must possess an auditor


  • Knowledge
  • Training
  • Independence
  • Communication skills

what is the objective evidence?

Qualitative or quantitative information, records, or statements of facts pertaining to the quality of an item or service or to the existence and implementation of a quality system element, which is based on observation, measurement or test and which can be verified.

  • Information, records, or statements of facts – must be based on evidence
  • Observation, measurement, or test which can be verified – again, must be based on tangible evidence.
  • Objective evidence may be obtained from an interview, but it must be substantiated by concurrence from one or more other people or by some kind of documentation.

what is an observation in audit?

  • A statement of fact made during an audit by objective evidence.
  • An observation is the statement made by the auditor regarding information he or she sees or hears. It is part of the audit report and is usually presented as evidence in a finding.

who is the auditee?

  • An organization to be audited.
  • The auditee is someone inside your organization during an internal audit

who is the quality auditor?

"A person who has the qualifications to perform audits."

  • Note: To perform a quality audit, the auditor must be authorized for that particular audit. An auditor designated to manage a quality audit is called a “Lead Auditor.”
  • You must understand the requirements of the quality standard.
  • You must have some introduction to auditing activities.

what about internal audit?

  • Must be a planned activity and be documented.
  • Focused only on the quality system.
  • Must have specific requirements.
  • Frequency must be determined by management.
  • Must use objective evidence.
  • The extent of follow-up verification depends on the noncompliance
  • The degree to which a nonconformance or noncompliance affects the quality system determines the degree of follow up required.

what is the purpose of an audits?

Purpose of the audits

  • Audits aim to establish, by unbiased means, factual information on some aspect of performance
  • Audits are performed as a safeguard against a deterioration in standards
  • Audits are performed to establish facts rather than faults
  • Audits establish facts. They should never be directed toward an individual or group within the organization.

what are the benefit of auditing QMS(quality management system)?

There are a number of benefits

  • Assured of good business practices
  • Means of determining effectiveness of the QMS
  • Ensure customer & outside requirements met
  • Add discipline to QMS
  • Help identify opportunities for improvement
  • Audits and auditors perform service to a company. They are a way to establish information based on facts, not on suspicion, suggestion or assumption
  • They are a good way to keep an organization on top of the quality system, rather than letting the system ravel at the edges

what is software audit?

Software audit, is a type of software review in which one or more auditors who are not members of the software development organization conduct "An independent examination of a software product, software process, or set of software processes to assess compliance with specifications, standards, contractual agreements, or other criteria"

what is quality audit?

A systemic and independent examination to determine whether or not quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.

Explanation:


Systematic – the entire system must be audited
Independent – you can’t audit your own work
Quality activities and related results – what you do and the results
Comply with planned arrangements – meet your plans and the quality standard
Implemented effectively and achieve objective – are you doing as planned, have you met your objectives?

what are the most common test case review defects?

  • Incomplete Test Cases
  • Missing negative test cases
  • No Test Data
  • Inappropriate/Incorrect Test data
  • Incorrect Expected behavior
  • Grammatical errors
  • Typos
  • Inconsistent tense/voice
  • Incomplete results/number of test runs
  • Defect details not updated
  • Changes to requirements not updated in Test case

what is the methodolgy of test cases review?

Typically, reviews should be done during each phase in the Testing Life cycle

The phases involved in Software testing lifecycle are

  • Requirements understanding
  • Test preparation
  • Test Execution
  • Test Reporting


  • During the Requirements Understanding phase, review of requirements is an activity that should be undertaken with utmost care and such review should be done systematically to ensure the clarity, correctness and testability of the requirements.
  • During the Test preparation phase, after the test scenarios are identified and test conditions and cases are built for each scenario, it is advisable to do a thorough and detailed review.
  • Checklist for Test cases review during the Test Preparation Phase
  • During the test execution phase, doing a review after the cases are executed is very important .
  • During the Test Reporting phase, it would help to ensure that all the required documents are prepared, metrics are collated and all the project specific formalities are completed.

what is the importance of test cases review?

some points are here

  • Test cases are written with the intent to detect the defects
  • Understanding of the requirement is correct
  • Impact areas are identified and brought under test
  • Test data is correct and represent every possible class of the domain
  • Positive and negative scenarios are covered
  • Expected behavior is documented correctly
  • Test coverage is adequate

why a test cases review?

  • Software Testing plays a vital role in ensuring the quality of a Software product.
  • Test cases are the key tools for testing.
  • Test cases review has to be thorough in order to ensure that effective and adequate testing is done

what is reviwed in design reviewed?

  • Is preliminary design conforms to the architecture
  • Is OOP principles followed
  • Is detailed design conforms to the preliminary design
  • Is all functional flows (defined in use cases) requirements are covered in the design
  • --All main scenarios, alternate and failure scenarios are supported by the application design and DB design
  • --Concurrency and Performance needs are catered
  • Is design implement-able and maintainable

what is testability in specification content review?

  • Are all features testable
  • Are simulators supported if not testable

what is modifiable in specification content review?

  • Are changes can be easily incorporated
  • Is maximum configuration provided
  • --Configurable Initialization Parameters
  • --Configurable Access Privileges
  • --Dynamic Reference Data

what is traceable in specification content review?

  • Are all requirements can be uniquely identifiable
  • Are Requirement trace back to user need (source can be any document or person)

what is Implement-able in specification content review?

  • Does all Requirements implement able and does not have any issue in implementation due to
  • --Technology/Tool constraint
  • --Dependency on External System
  • --Constraints mentioned in other requirements

what is Unambiguous in specification content review?

  • Clearly stating the purpose
  • Not open for interpretations

what is Consistent in specification content review?

  • Is same pattern followed for similar requirements and inter-function of same requirement
  • Are requirements complements other requirements
  • --No contradictions between characteristics of objects
  • --Logical or Temporal Conflicts
  • Consistency in terminologies used for objects

what is correctness in specification content review?

Is each functional requirement specify user action and as well as function, as appropriate. And Should be
--Based on logic, industry standard, matches with similar functionality
Are Cross Reference to other related requirements correct
--provide required data or interface
--provide valid data

what is completeness in specification content review?

  • Are all Type of requirements covered e.g. Functional, Security, Performance, etc
  • Are User Requirements covered
  • --Are User different classes covered
  • --Are User characteristics described
  • Are derived requirements plus the implicit requirements included
  • Are business requirement or set of business requirement depicting the full flow of a business process or transaction.
  • --No open ended requirements
  • --No broken paths
  • Are Application Initialization and Configuration functionalities provided
  • Are Recovery and Backups mechanism provided
  • Are Operation Needs included

Monday, March 30, 2009

what is evaluated at specification content review?

Following characteristic should be evaluated

  • Completeness
  • Correctness
  • Consistent
  • Unambiguous
  • Implement-able
  • Traceable
  • Modifiable
  • Testable

how does document review?

Following things are checked for document review

Compliance with the Standard Template
  • Presence of all sections/sheets
  • Document Formatting as per template
-Heading Styles
-Font Size, Color and Style
-Indentation
Header and Footer Values
-Understandability
-TOC verification
-Navigation between the Document
-Spelling and Grammar
-Naming Convention of the file

How does the technical review conducted?

Work Product Reviews:

Reviewing any work product comprises of two parts

Document Review

--Quality Document Characteristics are evaluated.

Specification Content Review


--Work Items/Solution are evaluated.

what is the effectiveness of reviews?

There are different sayings of different people..


  • Walkthroughs found between 30 and 70 percent of errors in a program. (McConnell, 73)
  • Code reading found twice as many defects per hour of effort as testing. (McConnell, 74)
  • Inspections found 60-90% of defects in a program. (McConnell, 75)
  • Inspections produced a net schedule savings of 10-30%. (McConnell, 75)
  • An hour of inspection avoids 33 hours of maintenance; inspections are 20 times more efficient than testing. (McConnell, 75)
  • The introduction of inspections in software maintenance reduced production crashes by 77%. (Humphrey, 186)
  • Inspections increased productivity 14%-25%. (Humphrey, 186-187)
  • A study of 2019 user-found problems that resulted in code changes, found 57.7% of the problems could have been detected by design inspections, 62.7% with code inspections. (Humphrey, 187)
  • When programmers know their work will be critically examined, inspections motivate better work -- that is, developers take more pride in quality and avoid sloppy mistakes. (Humphrey, 171)
  • Reviews provide visibility into the state of the project. It provides an opportunity for discussion, intermediate milestones, and an assessment of the adequacy of some aspect of the project. (Christensen and Thayer, 291)

what is the followup and exit for an inspection?

  • Moderator checks that all defects have been addressed (and all non-defect issues addressed if required).
  • Moderator must also ensure that any defects found in a source document during inspection are forwarded to the owner of that document for correction.
  • Moderator may calculate certain metrics in this stage to be analyzed to assess the effectiveness of an inspection.
  • May also be used to hold a meeting to evaluate and recommend inspection process improvement
  • An inspection will be exit when pre-defined set of inspection exit criteria have been satisfied.

what is logging meeting for an inspection?

  • A planned and moderated meeting with the primary purpose of logging the issues found by the reviewers.
  • All reviewers should be given a chance to raise their issues as a scribe logs the issues being raised
  • It is important that an issue is only logged once.
  • Moderator should ensure that discussion about issues is kept to a minimum in order to maintain the continuity of the meeting.
  • Some variations of this process include group defect finding as an activity at the end of this meeting.

what is individual checking of an inspection?

  • The final stage of preparation is individual checking (although it could also be considered the main stage of collection).
  • The majority of defects found in inspection processes are found in the individual checking stage.
  • During this stage an individual reviewer reads the artifact and with the guidance of an inspection checklist attempt to find defects in the artifact.
  • The reviewer should record any issues found.
  • The reviewer should also make some effort to determine what they consider the severity of a defect to be and classify the defect.

what is done at kickoff meeting of an inspection?

Following are the steps that are performed at this stage

  • Roles for the inspection team are assigned and clarified (generally the moderator does this).
  • Documents, including the artifact, its source document (e.g. SRS for Design), the inspection checklist, and inspection rules are distributed and checked (Defects in the source document and checklist are sometimes found in these meetings, however, this meeting should be kept short).
  • In some variations, the author(s) of the artifact may be required to give a quick walkthrough of the artifact to be inspected and its relation to the other documentation.

what are main consideration while planning an inspection?

The moderator determines the practical aspects of the inspection. This may include:

  • Determining the size and composition of the inspection team
  • Determining the goals of the inspection.
  • Determine the timing and purpose of the meetings.

how does start for inspection?

For start or entry for inspection

  • The author of the artifact requests that it be inspected.
  • The artifact to be inspected is checked by the inspection moderator to ensure that certain entry criteria are met.
  • The primary purpose of this stage is to ensure that inspection time is not wasted on artifacts that contain defects which the author should rightly have found.

what are the main steps for inspection process?

An inspection has five formal steps

  • Overview
  • Preparation, aided by statistics of fault types
  • Inspection
  • Rework
  • Follow-up

what are the types of walkthroughs?

Here are the types of walkthroughs

Specification walkthroughs

  • System specification
  • Project planning
  • Requirements analysis
Design walkthroughs
  • Preliminary design
  • Design
Code walkthroughs

Test walkthroughs
  • Test plan
  • Test procedure
Maintenance reviews

what are the main guidelines for a walkthrough?

Following guidelines will help while conducting a walkthrough

  • First set an agenda and keep to it
  • Identify problem areas, but don't attempt to solve every problem
  • Limit the number of participants
  • Insist upon advance preparation
  • Train reviewers
  • Develop a checklist for each reviewable product

what are the results after a walkthrough?

At the end of the review, all attendees must decide whether to
  • --Accept the product without further modification
  • --Reject the product due to severe errors
  • --Accept the product provisionally
All attendees complete a sign-off, indicating...
  • --Their participation in the review
  • --Concurrence with the review team's findings

what are main things to be recorded in a walkthrough?

Review issues list
  • Identify problem areas within the product
  • Action Item checklist for corrections to be made
Review summary report
  • What was reviewed?
  • Who reviewed it?
  • What were the findings and conclusions?

how does walk through conducted?

  • Coordinator chairs the meeting
  • Walkthrough structure
  • Author's overview?
  • --Reviewers should be able to understand the product without assistance
  • -Author's overview may "brainwash" reviewers into making the same logical errors as did the author
  • Author's detailed walkthrough
  • --Based on logical arguments of what the design or code will do at various stages
  • Requested specific test cases
  • Coordinator resolves disagreements when the team can not reach a consensus

what are roles in a walk through?

these are following roles

  • Coordinator: he/she is review leader
  • Author:he/she is producer
  • Reviewers: these are the actual reviewers
  • Recorder: this role records the review's main points

how much time for preparation of a walkthrough?

For advance preparation (no more than 2 hours) should be required of and performed by each reviewer

this is a two step informal process

  • Preparation
  • Analysis

how many persons should conduct a walk through?

It could vary from 4 to 5 people maximum

when should walkthrough schedule?

Walkthroughs should be conducted frequently

  • Focuses on a specific and small piece of work.
  • Increases the likelihood of uncovering errors.
  • Scheduled only when the author is ready

what are benefits of walkthroughs?

There are a lot of benefits, some of them are

  • Consciousness-raising-Senior people get new ideas and insights from junior people.
  • Enables observation of different approaches to software analysis, design, and implementation
  • "Peer pressure" improves quality
  • Promotes backup and continuity-Reduces risk of discontinuity & "useless code" since several people become familiar with parts of software that they may not have otherwise seen

Friday, March 27, 2009

what are the objectives of walkthroughs?

  • Finding Errors:Uncover errors in function, logic, or implementation for any representation of the software
  • Look for weaknesses or errors of style
  • Verify that the software meets its requirements
  • Ensure that the software has been represented according to predefined standards
  • Make projects more manageable -achieve software that is developed in a uniform manner

what is the importance of reviews?

There are many reasons

  • Applying Quality Assurance from the start
  • Early Identification of defects and issues
  • Less Redo Effort
  • Ensures smooth execution of subsequent activities
  • Increases manageability of the development process
  • Team Synchronization
  • Process Improvement
  • Reliability on Project Plan

where in SDLC reviews are performed?

Various Reviews are applied during different phases of SDLC covering the following artifacts

  • Requirements Specifications
  • Functional Specifications
  • Architecture and Design
  • Code
  • Test Plan and Test Specifications

  1. Other then above reviews on going Reviews conducted for Activity Monitoring

what are main roles in technical reviews?

These are as follows.

Moderator- this is Leader
Author- this is Producer of the work product to be reviewed
Reviewer-this is Inspector of the product
Recorder-this Subscribes the reviews
Observer- this observes the review

what is management review?

Management Review
A review to determine the project status as it applies to project plans, schedules, budget, staffing, training, and so forth

what is code reading?

Code Reading
A code walkthrough of two or more reviewers who read the code and report errors back to the developer.

What about peer reviews?

Peer Reviews
A semi formal to formal evaluation technique in which software requirements, design, or code are examined in detail by a person or group other than the originator to detect faults, violations of development standards, and other problems.  The review members are peers (equals) of the designer or programmer or Tester

How does Deskcheck?

Deskcheck
  • Unlike an inspection, a deskcheck does not produce written logs which can be archived with the document for later reference.
  • Deskchecks can be used as predecessors to inspections.
  • --In many cases, having an author of a work product pass his work to a peer for an informal review will significantly reduce the amount of effort involved in the inspection.

How we do formal and informal reviews?

Formal reviews are performed by Inspection.

Informal reviews are performed by Walkthrough

what are informal main reviews?

These are

  • Deskcheck
  • Peer Review
  • Code reading
  • Management reviews
  • Audits

How many types of reviews?

There are two main types of reviews

  • Formal Review
  • Informal Review

what is the difference between static and dynamic testing?

Static Testing:
  • Static testing is performed using the software documentation. The code is not executed during static testing.
  • Most verification techniques are static tests.

Dynamic Testing:

  • Dynamic testing requires the code to be in an executable state to perform the tests.
  • Most validation test are dynamic tests

What is the difference between verification and validation,V & V?

Verification

According to CMMI
The purpose of Verification is to ensure that selected work products meet their specified requirements

Validation

According to CMMI
The purpose of Validation is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment

More about V & V.

Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings.

Validation typically involves actual testing and takes place after verifications are completed.

  • Both verification and validation use similar approaches i.e. reviews and testing

  • Both validation and verification activities often run concurrently and may use portions of the same environment.

When reviews are needed? or What are the reasons for reviews?

Reviews are necessary due to following reasons:


  • Reviews are useful not only for finding and eliminating defects, but also for gaining consensus among the project team, securing approval from stakeholders, and aiding in professional development for team members.
  • Reviews help teams find defects soon after they are injected making them cost less to fix than they would cost if they were found in test.
  • All work products in a software project should be either reviewed or tested.
 For Example :Software requirements specifications(SRS) Software Functional Specifications(SFS), schedules, design documents, code, test plans, test cases, and defect reports should all be reviewed.

Wednesday, March 25, 2009

Why review? or What is the worth of review?

 Worth of review::
                          Reviews provide a powerful way to improve quality by providing a means by which defects can be detected (and corrected) early in development.

What is review?

Review:
            A review is any activity in which a work product is distributed to reviewers who examine it and give feedback

What is the purpose of software quality assurance or why sqa?

The main purpose of the software quality assurance or sqa is
  • To monitor and improve the process.
  • To make sure that any agreed-upon standards and procedures are followed.
  • To ensure that problems are found and dealt with.

Additional Benefits
  • SQA provides Improved Customer Satisfaction.
  • It has also Reduced Cost of Development.
  • Reduced Cost of Maintenance.

What is Software Quality Assurance?

Software Quality Assurance

“A planned and systematic pattern of all actions necessary to provide adequate confidence that the item or product conforms to established technical requirements.”

IEEE STD 610.12-1990

SQA ensures
  • An application is error-free and there is no bug,
  • Dependable,
  • Fully documented,
  • Maintainable down the line,
  • Entirely functional according to every specification and requirement.
  • Make sure that ordinary people, regular users, will be able to do everything that the application is supposed to empower them to do.

What is the difference between quality control(QC) and quality assurance(QA)?

First of all we should know what QC and QA is
 
Quality Control

IEEE define QC as:

A set of activities designed to evaluate the quality of developed or manufactured products.

Quality Assurance

IEEE define QA as:

A set of activities designed to evaluate the process by which products are developed or manufactured

QA
  • QA is all about Process,
  • It is Proactive approach
  • It is Staff function, all team is involved
  • It Prevents Defects from occurring
QC
  • QC is related to Product only
  • It is Reactive approach
  • It is specific to Line Function
  • QC is for to Find Defects

 Examples
QC Vs QA

QA

  • Quality Audit is QA
  • Defining Process is also QA
  • Selection of tools it comes under QA
  • Training is QA activity
  • etc

QC


  • Walkthrough is QC
  • Testing is also QC
  • Inspection is QC activity
  • Checkpoint review also in QC

What are changing views about quality in past and present ?

Quality in past vs quality in present


Quality in past:
  • Quality is the responsibility of blue collar workers and direct labor employees working on the product
  • Quality defects should be hidden from the customers and management
  • Quality problem lead to blame, faulty justifications and excuses
  • Increased quality will increase project cost
  • Quality is internally focused


Quality in present:
  • Quality is everyone's responsibility, including white-collar workers
  • Defects should be highlighted and brought to the surface for corrective action
  • Quality problems lead to co-operative solutions
  • Improved quality saves money and increases business
  • Quality is customer focused

What are prevention, appraisal and failure costs?

We can describe these costs as follows

Prevention cost:
•Quality planning
•Formal technical reviews
•Testing equipment
•Training
Appraisal cost:
•In-process and inter-process inspection
•Equipment calibration and maintenance
•Testing
Failure cost:
Internal failure cost: rework, repair, and failure mode analysis
External failure cost: complaint resolution, product return and replacement, help line support, warranty work

What is cost of quality?

Cost of Quality includes:

  • Includes all costs incurred in the pursuit of quality or perform quality related work.
  • It is more than 50% of the total project cost
There are three types of cost
Prevention cost: It is  incurred to prevent defects from occurring.
Appraisal cost: It is  incurred for reviewing and testing the work product.
Failure cost:It is the cost  incurred in correcting the defects found during appraisals or reported by the customer.

Tuesday, March 24, 2009

How can achieve high levels of software quality?

High levels of quality are possible by following methods
  • Enterprise-wide quality programs
  • Quality awareness and training methods
  • Quality standards and guidelines
  • Quality analysis methods
  • Quality measurement methods
  • Defect prevention methods
  • Testing methods
  • User-satisfaction methods
  • Post release quality control

What are six root causes of poor software quality?

These are the causes
  • Inadequate training of managers and staff
  • Inadequate defect and cost measurement
  • Excessive schedule pressure
  • Insufficient defect removal
  • High complexity levels
  • Ambiguous and creeping requirements and design (feature race & gimmicks)

  • Inadequate training of managers and staff
When training is not as the managers and staff needed then software may have lack of quality
  • Inadequate defect and cost measurement
If defect and cost measurement is not according to the needs
  • Excessive schedule pressure
If there is pressure for delivery of the software in short time.
  • Insufficient defect removal
When defects are not fixed properly
  • High complexity levels
When software is very complex then misunderstanding is one cause for the poor quality
  • Ambiguous and creeping requirements and design
When there is ambiguity in requirements and also in design of the software

What are six software defect origins?

These are the defect origins
  • Requirements
  • Design
  • Source code
  • User manuals/training material
  • “Bad fixes” or mistakes made during repairs
  • Flawed test cases used by the application

  • Requirements
There may ambiguous or unclear or unrelated requirements later which produce defects in the saoftware
  • Design
If the design is not proper then it may arise the software defects
  • Source code
The source code may not be proper or buggy against requirements
  • User manuals/Training material
If the user manual or training materials are not according to business then defect can come in the software
  • “Bad fixes” or mistakes made during repairs
If bugs reported are not fixed properly or when when repairing does not care for the ripple effects or dependency
  • Flawed test cases used by the application
When test cases written for testing were not proper as per requirement of the software.

Achieving Software Quality

Definition:

“For a software application to achieve high quality levels, it is necessary to begin upstream and ensure that intermediate deliverable s and work products are also of high quality levels. This means that the entire process of software development must itself be focused on quality”
Capers Jones

From above definition we can conclude that
A high quality software only can be achieved when follow software quality assurance .Which says that start from the root and continue all the process till the end of development of a software. Monitor all the activities and fix the issue as it arises.

Why we need quality?

There may be several reason that why we need quality

  • Order qualifiers VS. Order winners... Just not qualify for order but win it

  • A competitive issue now... There is huge competition in the market

  • Must for survival... You can not survive if you don't provide quality to the customer

  • Gives you the global reach...If you are providing quality to the customer you will have global access for clients

  • Quality is cost effective... Quality makes the cost effective

  • Helps retain customers and increase profits... It gains customer attraction and you get more profit

  • The hallmark of world-class business... It is needed for world class business

  • Minimizes the risk of serious litigation... reduces risk of litigation

  • Minimizes the risk of serious operating failures and delays... Quality software or nay thing minimizes risk for failures and delays

  • Minimizes the risk of bankruptcy or business failures, which may be attributed directly to poor quality or poor software quality

  • For customer satisfaction

What are five quality perspectives?

These are the five quality perspectives

  • Development based: Confroms to requirements.
while developing developers are concerned to conformance to requirements
  • Product based: Posses the desired features.
In a product all the desired features are there in the product
  • User based: fit for use.
User says quality is if it is fit to the user needs
  • Trancendent: I know it when i see it.
I can get when i see it
  • Value based: Developed at an acceptable cost.
This is the perspective that quality is that software is developed in economical budget.

How many quality factors?

There are 11 quality factors

  • Correctness:Extent to which a program satisfies its specifications and full fills the user's mission objectives.
  • Reliability: extent to which a program can be expected to perform its intended with required precision.
  • Efficiency: the amount of computing resources and code required by a program to perform a function.
  • Integrity: extent to which access to software or data by unauthorized persons can be controlled.
  • Usability: effort required learning, operating, preparing input and interpreting output of a program.
  • Maintainability: effort required locating and fixing an error in an operational program.
  • Testability: effort required testing a program to ensure that it performs its intended function.
  • Flexibility: effort required modifying an operational program.
  • Portability: effort required to transfer from one configuration to another.
  • Reusability: extent to which a program can be used in other applications related to the packaging and scope of the the functions that program performs.
  • Interoperability: effort required to couple one system with an other.

what are quality attributes and quality factors?

There are three types of quality attributes:
  1. Product Operations
  2. Product Revision
  3. Product Transition
Quality factors are related to attributes which are:


1.Product Operations:
  • Correctness: does it do what i want?
Operation are correct and according to requirement.
  • Reliability: does it do accurately all the time?
The operations performed, are all the time correct and mean if now is 1+2=3 all the time it should be 3.
  • Efficiency: will it run on my machine as well as it can?
My program is efficient and it runs in same on all machines
  • Integrity: is it secure?
My software is secure and it is not accessible to spamers
  • Usability: can i run it?
My software is easy to use or user friendly.

2.Product Revision:
  • Maintainability: can i fix it?
Software can maintained easily.
  • Flexibility: can i change it?
When needed can be changed.
  • Testability: can i test it?
We can test it as it developed

3.Product Transition:
  • Portability: will i be able to use on another machine?
It means that our software can be run on windows as well as linux or per required
  • Reusability:will i be able to reuse some of the software?
If we have developed a software then its components are reuse able can adjusted to other software or separately if needed.
  • Interoperability: will i be able to interface it with another machine?
for example my software is running on windows, then can i work with system which is running on linux etc

*I have explained for understandability of the reader

How software quality can be achieved?

Achievement of quality would be easy if we are doing the things
  • Apply software engineering methods in effective manner
  • Perform formal technical reviews as per required
  • Software metrics and measurements
  • By testing the software on the right time
  • SCM(Software Configuration Management) and SQA(Software Quality Assurance)
  • and by following standards and procedures.
After doing the above steps you would be able to get a quality product

what is software quality?

There are two definitions by IEEE and ISO.

According to IEEE
  • The degree to which a system, component, or process meets specified requirements
  • The degree to which a system, component, or process meets customer or user needs or expectations
ISO says:
  • The totality of features and characteristics of a product or service that bear on its ability to satisfy specified or implied needs.

Thursday, March 19, 2009

What is quality?

Quality
Quality has a lot of definitions. But some famous definitions are


1.It is not the “goodness” or “elegance” but “conformance to requirements".
(Crosby)

2.Fitness for use.
(Juran)