Archive

Posts Tagged ‘Quality Assurance’

Tailoring Vs Waivers / Exceptions

April 13, 2011 2 comments
S.No Tailoring Exceptions / Waivers

1

Accounting of an SDLC activity in an alternate method. Justification and approval for required SDLC activities to not be performed on a project.

2

Allows the standard guidelines to be modified to fit the need of the individual project.

 Provides flexibility in standard processes.

A formal exemption from the specific activities beyond standard guidelines.

Allow software development processes to be adapted to meet the needs of individual projects.

3

Example of Process tailoring

Project request document is not documented in the standard SDLC template, instead documented in project inventory repository or part of the scope document.

Example of process waivers

 Unit test plans and cases will not be documented for the project. Team accepts the risk of not documenting the test plans and cases.

Advertisements

Implementation of QMS (Part4)

October 3, 2009 Leave a comment

Learn From Others & Share Your Experiences

As it was trail or test ride, implement the same across the organization at full fledge, since the procedures / process is matured one now. For implementation of the procedures / process to the full fledge the existing team which is already had used, need to spend time to share their experience with others and help them to get learned.

Quality is a team work rather than individual one.

Implementation of QMS (Part3)

October 3, 2009 Leave a comment

Have periodic reviews and Audit Trails

Before go for the audit, let have some pre-audits in terms of SQA reviews. Identify couple of resources of different teams to take up audit. Train them to the level of internal auditor and prepare a checklist for the reviews. This may help the organization to know the performance of the QMS as well the gaps in the QMS. Consolidate the SQA review report and send for analysis to the subject expert. If the identified gaps are addressed as risk in the procedures then rise PCR (Process Change Request) and make changes according as the direction of CCB ( Change Control Board). By this way the established procedures get maturity.

On maturity of the procedures, plan for audit. Have a deep discussion and identify the gaps in the practice (ground) and procedure (theory). Again consolidated it and review the same. If the identified gaps are risk then address them at high priority. Since it’s a continual process improvement, address the same with enthusiasm rather frustration.

Implementation of QMS (Part2)

October 3, 2009 Leave a comment

Define, establish and implement procedures

On avail of policy and objectives, define procedures across the organization. Procedures are nothing but the systematic way of doing something. As said it’s systematic, so rather you define the procedures / process allow the team who is going to work on to define. On definition of the process / procedures by the team, identify the gaps and analysis the same with the quality standards or models (ISO, CMMI & etc). Prepare review comments and go for discussion, so that procedures / Process get tuned. Once it’s been accepted on either side (You & team), incorporated the review comments with the existing procedures.

 On establishment of procedures we need to implement the same across the organization on different projects. For implementation, select one or more projects for the test ride. Once the projects are been selected, prepare a plan for the training to the required resources, so that they may effectively use the QMS. Allow the team to use the QMS for while with the plan stating that met up somewhere after three or fours months later for audit trail.

Functional Audit vs Physical Audit

December 16, 2008 2 comments
 

Functional Audit

Physical Audit

 

Objective: To provide an independent evaluation of software products, verifying that its configuration items’ actual functionality and performance is consistent with the requirement specifications.

 

 

Objective: To provide an independent evaluation of a software product configuration item to confirm that components in the built version map to their specifications.

 

Audit Requirements:

 

1. Software Requirements Specification (SRS), System Specification (SS)

2.  Waiver or Deviation List Prepared

3.  Verification Test Procedures Prepared.

4.  Verification Test Procedures Reviewed and Approved.

5.  Verification Test Data and Results Reviewed and Approved

6.  Test Results submitted.

7.  Test Readiness Review completed

8.  Test Readiness Review minutes and open action items from past reviews available

9.  Copy of baseline and database change requests with their associated status accounting records along with all design provided

Audit Requirements:

 

1.  Approved final draft of the configuration item (CI) product specification.

2.  A list delineating both approved and outstanding changes against the configuration item.

3.  Acceptance test procedures and associated test data.

4.  Findings / Status of quality assurance programs.

5.  Manuscript copy of all software CI manuals.

6.  Computer Software Version Description Document.

7.  Current set of listings and updated design descriptions or other means of design portrayal for each software CI.

8.  FCA (Functional Configuration Audit) minutes for each configuration item.

Process of Software / System Design (Part 2)

Process of Software / System Design

 

Purpose:

  1. To describe design goals set.
  2. To define system architecture and detailed design of the system.

Process Requirement:

 

1. System Architecture:

 

Entry Criteria: Approved SRS

  

Activity:

Ø     On approval of SRS from internally and externally the team which is involved with design activity start to prepare HLD (High Level Design).

Ø     The same as to be review and approved by Project Head / manager

Ø     Refer: http://en.wikipedia.org/wiki/Software_Design_Description

 

Record Retention: HLD

 

Exit Criteria: Approved HLD

 

2. Detailed Design Document:

 

Entry Criteria: Approved HLD

  

Activity:

Ø     On approval of High Level Design, the team involve in the low level design start to prepare (LLD)

Ø     LLD involves web page design and Usability (Navigation)

Ø     The same as to be review and approved by Project Head / manager

 

Record Retention: LLD

 

Exit Criteria: Approved LLD

 

3. Validation

 

Entry Criteria: HLD & LLD

 

Activity:

Ø     Conducting informal reviews and walkthroughs or inspections of the detailed software and data base designs.

Ø     The Critical Design Review (CDR) that completes the software detailed design phase.

 

Record Retention: HLD & LLD

 

Exit Criteria: Approved HLD & LLD

 

Implementation of process in SDLC

April 29, 2008 1 comment

Implementation of process in SDLC

 

As all our previous post is about Software Development Life Cycles, so this is the time to have next few posts is on process implementation in SDLC’s.

 

Different Phases of SDLC:

  1. Requirement
  2. Design & Coding
  3. Testing
  4. Implementation

Requirement Management:

 

A requirement is a “function or characteristic of a system that is necessary…the quantifiable and verifiable behaviors that a system must possess and constraints that a system must work within to satisfy an organization’s objectives and solve a set of problems”.

 

 Similarly, “requirement” has the following definitions [IEEE 90]:

 

  1. A condition or capability needed by a user to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents
  3. A documented representation of a condition or capability as in (1) or (2).

 

Different authors will present different definitions, but there are clearly nonfunctional requirements as well as functional requirements. Requirements are classified as follows

 

  1. Functional requirements

 

Functional requirements define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs.  These are generally listed, as “shall” statements starting with “The system shall… 

 

These include:

 

·        Validity checks on the inputs

·        Exact sequence of operations

·        Responses to abnormal situation, including

·        Overflow

·        Communication facilities

·        Error handling and recovery

·        Effect of parameters

·        Relationship of outputs to inputs, including

·        Input/Output sequences

·        Formulas for input to output conversion

 

     2.  Nonfunctional requirements

 

 In systems engineering and requirements engineering, non-functional requirements are requirements, which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that specify specific behavior or functions. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints”, “quality attributes”, “quality goals” and “quality of service requirements”. Non-functional requirements can be divided into two main categories.

 

                                             i.            Execution qualities, such as security and usability, are observable at run time.

                                           ii.            Evolution qualities, such as extensibility and scalability, embody in the static structure of the software system.

Key aspects of the process are:

Requirement Process

 

a.      Requirement Elicitation

 

This concerned with where software requirements come from and how the software engineer can collect them. It includes requirement sources and elicitation techniques.

                 

                 Activities

                                                               i.      Elicit requirements from various individual sources;

                                                             ii.      Insure that the needs of all users are consistent and feasible; and

                                                            iii.      Validate that the requirements so derived are an accurate reflection of  user

 

                   b. Requirement Analysis

 

The very purpose of the analysis is to identify the requirements in a complete, accurate, consistent, and unambiguous manner.

 

Activities

                                                           i.          Detect and resolve conflicts between requirements

                                                          ii.          Discover the bounds of the software and how it must interact with its environment

                                                        iii.          Elaborate system requirements to software requirements

 

                  c. Requirement Specification

 

Requirements specification typically refers to the production of a document, or its electronic equivalent, that can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced:

1.      System definition,

2.      System requirements specification, and

3.      Software requirements specification.

 

    Activities

                                                           i.          Preparation of SRS from the requirements collected

 

 

                       d. Requirement Validation

 

Requirements validation is concerned with the process of examining the requirements documents to ensure that they are defining the right system (that is, the system that the user expects). It is subdivided into descriptions of the conduct of requirements reviews, prototyping, and model validation and acceptance tests.

 

      Activities

                                                          ii.          Conduct Review Meetings

                                                        iii.          Closing Issues identified in the review meeting

                                                        iv.          Approval & Kick off

 

                  e. Changes Request Management

 

On receive of any change list from the client or stakeholders that has to be discussed and reviewed with the team.

 

Activities

                                                           i.          Analysis major and minor changes

                                                          ii.          Made corrections in the SRS on approval of CCB

                                                        iii.          Version updated

                                                        iv.          Moved to production