Verification (VER) & Validation(VAL) : Goals and Practices

Validation (VAL)
An Engineering process area at Maturity Level 3
Purpose
The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.
Specific Practices by Goal
SG 1 Prepare for Validation
SP 1.1 Select Products for Validation
SP 1.2 Establish the Validation Environment
SP 1.3 Establish Validation Procedures and Criteria
SG 2 Validate Product or Product Components
SP 2.1 Perform Validation
SP 2.2 Analyze Validation Results

Verification (VER)
An Engineering process area at Maturity Level 3
Purpose
The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.
Specific Practices by Goal
SG 1 Prepare for Verification
SP 1.1 Select Work Products for Verification
SP 1.2 Establish the Verification Environment
SP 1.3 Establish Verification Procedures and Criteria
SG 2 Perform Peer Reviews
SP 2.1 Prepare for Peer Reviews
SP 2.2 Conduct Peer Reviews
SP 2.3 Analyze Peer Review Data
SG 3 Verify Selected Work Products
SP 3.1 Perform Verification
SP 3.2 Analyze Verification Results

Examples of Verification & Validation activities

What is the difference between Validation & Verification

Verification is a Quality Control process that is used to evaluate
whether or not a product, service, or system complies with
regulations, specifications, or conditions imposed at the start of a
development phase. Verification can be in development, scale-up, or
production. This is often an internal process.

Validation is Quality assurance process of establishing evidence
that provides a high degree of assurance that a product, service, or
system accomplishes its intended requirements. This often involves
acceptance of fitness for purpose with end users and other product
stakeholders.

Verification: “are we building the product right”
Validation: “are we building the right product”

eQuality Jokes

Versions/Variants/Releases

Versions/Variants/Releases : These terms are often confused. hence it is important to know the differnce between what each of these stands for.

Version-An instance of a system which is functionally distinct in some way from other system instances.
Variant-An instance of a system which is functionally identical but non-functionally distinct from other instances of a system.
Release-An instance of a system which is distributed to users outside of the development team.

Various Configuration Management Tools

Below are few examples of Configuration Management Tools :

• VSS – Visual Source Safe for documents.
• VSTS - Visual Studio Team System
• VAJ - Visual Age for Java for source files.
• RCE – Revision Control Engine.
• Software Manager – Information from virtual sky.
• QVCS – Quma Version Control System.
• Source Code Manager.
• SCLM – Software Configuration Library Manager.
• CVS – Concurrent Version System.

What is a Configuration Mangement(CM) Plan

• Defines the types of documents to be managed and a document naming scheme.
• Defines who takes responsibility for the CM procedures and creation of baselines.
• Defines policies for change control and version management.
• Defines the CM records which must be maintained.
• Describes the tools which should be used to assist the CM process and any limitations on their use.
• Defines the process of tool use.
• Defines the CM database used to record configuration information.
• May include information such as the CM of external software, process auditing, etc

Configuration Mangement - The CMMI Way

Configuration Management (CM)

A Support process area at Maturity Level 2

Purpose

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

Specific Practices by Goal

SG 1 Establish Baselines

SP 1.1 Identify Configuration Items

SP 1.2 Establish a Configuration Management System

SP 1.3 Create or Release Baselines

SG 2 Track and Control Changes

SP 2.1 Track Change Requests

SP 2.2 Control Configuration Items

SG 3 Establish Integrity

SP 3.1 Establish Configuration Management Records

SP 3.2 Perform Configuration Audits

eQuality Jokes

What is Configuration Management....

DEFINITION :
Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.

1) For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.

2) CM for information assurance, sometimes referred to a Secure Configuration Management, relies upon performance, functional, and physical attributes of IT platforms and products and their environments to determine the appropriate security features and assurances that are used to measure a system configuration state. For example, configuration requirements may be different for a network firewall that functions as part of an organization's Internet boundary versus one that functions as an internal local network firewall.

HISTORY :
Configuration management was first developed by the United States Air Force for the Department of Defense in the 1950s as a technical management discipline of hardware. The concepts of this discipline have been widely adopted by numerous technical management functions, including systems engineering (SE), integrated logistics support (ILS), Capability Maturity Model Integration (CMMI), ISO 9000, Prince2 project management methodology, COBIT, Information Technology Infrastructure Library (ITIL), product lifecycle management, and application lifecycle management. Many of these functions and models have redefined configuration management from its traditional holistic approach to technical management. Some treat configuration management as being similar to a librarian activity, and break out change control or change management as a separate or stand alone discipline. However the bottomline is and always shall be Traceability.

What is CMMi 6???

"Design Management" in an hour!

Introduction

Design management is concerned with the integration of design into management and vice versa. Simply put, design management is the business side of design. Design management encompasses the ongoing processes, business decisions, and strategies that enable innovation and create effectively-designed products, services, communications, environments, and brands that enhance our quality of life and provide organizational success.

On a deeper level, design management seeks to link design, innovation, technology, management and customers to provide competitive advantage across the triple bottom line: economic, social/cultural, and environmental factors. It is the art and science of empowering design to enhance collaboration and synergy between “design” and “business” to improve design effectiveness.

The architectural design and detailed design stage of the SDLC can be called the solution stage.

The architecture design is complete when the architectural design document is signed off by the PM and QA representative. Customer’s signature is also necessary if mentioned in the contract.
The detailed design describes the project implementation in the detailed design document. This includes coding conventions, screen, class and data storage specifications.

Architecture Design

1. Assimilate Documentation: Collect white papers, prototypes, case study and workshop results from both the client and the vendor for analyzing alternative solutions for the design.
   
2. Evaluate Alternate Solutions for Architecture Design: This is the make, buy and reuse stage. Following are the factors that drive the decisions here.
   
   -Product Functioning
   -Available resources and skills
   -Cost of acquiring versus developing internally
   -Critical deliver and integration dates
   -Strategic business alliance, including high level business requirements
   -Market research of available products, including COTS products
   -Functionality and quality of available products
   -Skills and capability of potential suppliers
   -Impact on core competencies
   -Product availability
   -Licenses, warrantees, responsibilities, and limitations of the product being acquired
   -Proprietary issues
   -Risk reduction


3. Define the selection criteria before evaluating the alternate solution: This encompasses Cost (Time, People, and Money), Benefits (Performance, Capability, and Effectiveness) and Risks. Important things to consider are as follows.
   
   -Type of the product
   -Reuse of existing components
   -Future plans of extending/enhancing the product
   -User interface
   -Hardware and software requirements
   -Error detection, reporting and recovery mechanism
   -Memory management policies
   -External database, storage management and persistence
   -Distributed data or control over the network
   -Concurrency and synchronization
   -Communication mechanism
   -Management of other resources
   -Performance requirements


4. Identify criteria for selection of physical organization: Following are the inputs to this stage:
   
   -Storage space
   -Operational efficiency
   -Response time
   -Costs
   -Database security and integrity
   -Identification of constraints and limitations


5. Construct Object Model: For almost all the projects, except for smaller ones, usage of CASE tools is highly recommended for building the Object Model/Domain Model.


6. Evolve Other Specific Requirements: These are the operational concepts such as,
   
   -Conversion Modules
   -Archive and Purge Module
   -Backup and Recovery Design
   -Security Architecture
   -System Interfaces
   -Batch Jobs
   -Performance and Response Time Considerations
   -Platform Dependencies and Installation Considerations
   -Localization Considerations
   
   
7. Prepare Architectural Design and Operation Scenario: We need to define following items to complete this stage.
   
   -Domain model
   -Functions
   -Behavior
   -Data
   -Design Model
   
   
8. Prepare Architecture Design Document: There are 10 steps to draft the architecture design document.
   
   -Derive functional definitions of the components
   -Define data structures
   -Describe user interface
   -Define control flow
   -Define the response requirement
   -Detailed data flow diagrams
   -Data dictionary
   -Entity relationship diagram
   -Define interface requirements
   -Define reusable components
   
   
9. Review and approve Architecture Design Document: First step is to conduct formal and technical review of the document, close all action items, get signoffs from the PM and the customer, and baseline the document.
   
10. Prepare Integration Test Plan: This stage is broken down as follows.
    
    -Identification of integration sequence, ensuring availability of tools and setting up test environment
    -Plan for resource and access permissions
    -Perform product integration after setting up the environment
    -Prepare integration test data
    -Prepare integration test plan

Detailed Design

1. Assimilate Documentation: Collection functional specifications, detailed customer requirement specification, architecture design, and data model documentation.
   
2. Frame the Selection Criteria for Evaluation of Solution Alternatives:
   
   -Type of the product
   -Reuse of existing components
   -Future plans of extending/enhancing the product
   -User interface
   -Hardware and software requirements
   -Error detection, reporting and recovery mechanism
   -Memory management policies
   -External database, storage management and persistence
   -Distributed data or control over the network
   -Concurrency and synchronization
   -Communication mechanism
   -Management of other resources
   -Performance requirements


3. Decompose Lower Level Components:
   
   -Start from the interface and interface specification
   -Concentrate on the control flow
   -Defer data declaration until the coding stage
   -Keep step of refinement small for easy verification
   -Review each step as and when completed
   
   
4. Prepare Detailed Design: Steps involved in detailed design are as follows.
   
   -Presentation
   -Naming programs, files, variables and data
   -Limiting the size of modules
   -Using library routines
   -Defining constraints
   -Defining constants
   -Using compiler specific features
   -Error handling
   -Definition of standards for development


5. Review and Approve Detailed Design Document: We need to define following items to complete this stage.
   
   -Domain model
   -Functions
   -Behavior
   -Data
   -Design Model
   
   
6. Review and Approve Test Plan
   
7. Component Reuse

Design Models

1. Static Object Model: Such as Use Case and Class diagrams
2. Dynamic Object Model: Such as Activity and State diagrams
3. Storage Object Model: Such as Entity Relationship diagrams

Service Design

This include activities such as below.

1. Data Migration
2. Training
3. System Deployment and Management

Alternate Design Evaluation

During SDLC the following structured design methods can be adopted.

1. Architecture Tradeoff Analysis Method (ATAM):
   Inputs: System’s business/mission drivers, existing architectural documents
   Outputs: List of architectural approaches, scenarios, attributes, utility tree, risks, non-risks, risk themes


2. Cost-Benefit Analysis Method (CBAM):
   Inputs: System’s business/mission drivers, list of scenarios, existing architectural documents
   Outputs: List of architectural strategies with cost-benefits-schedule-ROI, risks related to each architectural strategy


3. Active Review for Intermediate Designs (ARID):
   Inputs: List of seed scenarios, existing architectural documents
   Outputs: List of issues and problems preventions


4. Attribute Driven Design (ADD)
   Inputs: Requirements, Constraints, Quality Attribute documents
   Output: Module decomposition, concurrency and deployment documents

Reviews

Reviews are conducted on the design process and documentation. Following are types of review conducted.

1. Formal Technical Review
   
   -Prepare the work product
   -Identify review team and their roles and responsibilities
   -Plan review
   -Review work product
   -Rework
   -Signoff work product


2. Internal Peer Review
   

Templates created at the organizational level

• General Design
• Object Oriented Design
• Feasibility Study
• Program Specification
• Proof of Concept
• Signoff
• Tool Evaluation
  

Types of Checklists created at the organizational level

• Design checklist
• Program specification checklist

eQuality Jokes

Don't we all just love Dilbert :)

Software Design vs Software Engineering...

In some engineering disciplines; the concepts of "design" and "engineering" are segregated. It is occasionally argued that such separation is beneficial to software systems, as well...

Design consists of the specification of requirements (functional, etc.) needed to satisfy the customer and other relevant external parties (the law, etc.) The job of a designer is to gather such requirements from various sources; asking customers directly, market research, academic research into relevant fields, domain knowledge, study of the law and of relevant standards and practices, and a bit of intuition and produce a specification of some sort.

The designer is concerned with many human factors; aesthetics, functionality, ease-of-use, fitness for purpose and quality; the designer is less concerned with implementation details.Engineering consists of the translation of these requirements into a technical specification describing a system which conforms to these requirements. In many traditional engineering disciplines, the role of engineer is generally not concerned with things such as aesthetics or fitness-for-purpose; instead the engineer is concerned with coming up with a system (or specification) which is correct, safe, and cost-effective.

The chief distinction between an engineer and a designer is that the engineer is personally (legally speaking) responsible for knowing said correctness and safety of the system. The processes of technical specification and other standard procedures exist so that the engineer can convince himself and others of this knowledge. In many fields it is possible for the engineer to be completely unrelated to the design process and only be responsible for the validation of the design...

Give me a Name

I am two week old and its now time to give me a name......

Post your enteries as comments to this post and win a prize

eQuaility Quiz 2:

eQuaility Quiz 2:

1. REQM stands for

a) Requirement Equality Management
b) Requirement Management
c) Requires Equal Maintenance
d)Request Management
****************************************************

2. REQM process area belongs to following Maturity level:
a) One
b) Two
c) Three
d) Four
****************************************************

3. Which of the following is not the specific practice of the Goal of Manage Requirements
a) Obtain Commitment to Requirements
b) Maintain Bidirectional Traceability of Requirements
c) Analyze Requirements
d) Identify Inconsistencies Between Project Work and Requirements

***********************************************************

4. The purpose of requirements management:
a) Manage Changing Requirements
b) Ensure that requirements are complete
c) Obtain Sign off of Requirements
d) All of the above
****************************************************

5. What is Bidirectional Traceability:
a) Tracing Requirements sources to the product
b) Tracing each unique work product to its associated requirement
c) Tracing Requirements sources to the product and back to its associated requirement.
d) None of the above

*************************************************************

Post your answers as comment to this post !!!

eQuality Jokes

eQuality Jokes

A new vacuum cleaner salesman knocked on the door on the first house of the street.
A tall lady open the door.

Before she could speak, the enthusiastic salesman barged into the living room and opened a big black plastic bag and poured all the cow droppings onto the carpet.

"Madam, if I could not clean this up with the use of this new powerful Vacuum cleaner in the next 10 mins, I will EAT all this dung!"

Exclaimed the eager salesman.

"Do you need chilly sauce or ketchup with that" asked the lady.

The bewildered salesman asked, "Why, madam?? "

"There's no electricity in the house..." said the lady.

Moral of the story: Gather all requirements and resources before working on any project and committing to the client...!!!

eQuality Jokes

This is the result of IMPROPER Requirements Management in a Project !!!

To create something ,
Meaningful..
make sure U know,
What to MAKE !!!

Requirment Management for DUMMIES !

The purpose of requirements management is to assure the organization documents, verifies and meets the needs and expectations of its customers and internal or external stakeholders. Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization.

Requirements management further includes supporting planning for requirements, integrating requirements and the organization for working with them (attributes for requirements), as well as relationships with other information delivering against requirements, and changes for these. The traceabilities thus established are used in managing requirements to report back fulfillment of company and stakeholder interests, in terms of compliance, completeness, coverage and consistency.

Traceabilities also support change management as part of requirements management in understanding the impacts of changes through requirements or other related elements (e.g., functional impacts through relations to functional architecture), and facilitating introducing these changes.

Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical.

For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases, the user requirements are being taken care of.

So, basically,, This will happen to U if you dont implement requirements management :

Requirement Management...The CMMi way

You do not want to be in our Dilbert's position, so what will you do? We suggest follow the CMMi way? What is CMMi way? To know..Read On....

Each Process Areas in CMMi has Specific Goals and Common Goals. These goals can be achieved by following the specific and general practices respectively

Requirement Management is one of the Process Areas of CMMi Level 2. It has a specific goal of "Manage Requirements" and it can be achieved by following below mentioned specific practices.

SG 1 Manage Requirements

• SP 1.1 Obtain an Understanding of Requirements
• SP 1.2 Obtain Commitment to Requirements
• SP 1.3 Manage Requirements Changes
• SP 1.4 Maintain Bidirectional Traceability of Requirements
• SP 1.5 Identify Inconsistencies Between Project Work and Requirements
  
  
  

Requirement Management (REQM)

The requirements are the foundation, upon which the software process is built, and the Requirements Management (RM) process emerges as a systematic approach to find, document, organize, and track all system's requirements during the life cycle.

According to a SEI’s Study, the top two out of ten factors that contribute to the failure of system
development projects are requirements problems. These problems are mainly associated with an inadequate requirements specification and/or an insufficient requirements change management. Also the Standish Group's CHAOS report found that the major factors that cause software projects to fail are:

• Lack of user input
• Incomplete requirements specifications
• Changing requirement specifications.
  

Therefore, RM process is considered the cornerstone of the software lifecycle and CMMI identifies the enormous importance of the RM, granting the category of “Process Area” and placing it in the CMMI, staged representation, maturity level two. According to the CMMI, the Requirements Management major aim is establishing an agreement between the customer and the software team on the meaning of the requirements.

eQuality Quiz 1:

1) eQuality stands for ____________

a) Encouraging Quality
b) Ensuring Quality
c) Emerging Quality
d) Ending Quality

***********************************
2) eQuality punch line

a) It's not about what, it’s about why
b) It's not about why, it’s about what
c) Lets learn CMMi
d) CMMi awareness drive

***********************************
3) Select the correct sequence of Levels in CMMi

a) Initial, Defined, Managed, Quantitatively managed, Optimized
b) Initial, Defined, Managed, Optimized, Quantitatively managed
c) Initial, Managed, Defined, Optimized, Quantitatively managed
d) Initial, Managed, Defined, Quantitatively managed, Optimized

***********************************
4) Our organization is getting reassessed for CMMi Level 5 in year

a) 2010
b) 2011
c) 2012
d) None of above

***********************************
5) CMMI (Capability Maturity Model Integration) is a __________ improvement approach

a) Quality
b) Coding
c) Process
d) None of above

Post your answers as comment to this post !!!

Quick description of CMMI level 5 process areas

Quick description of CMMI level 5 process areas

OID – Organizational Innovation and DeploymentThe purpose of OID is to select and deploy improvements that measurably improve the organization’s processes. The improvements support the organization’s quality and process performance objectives as derived from the organization’s business objectives. Keep in mind that you need to prove that the proposed innovations has improved organization’s process.

CAR – Causal Analysis & ResolutionThe purpose of this process area is to identify causes of defects and take action to prevent them from occurring in the future. Tip: A Six Sigma initiative can help a lot high maturity.

The question "WHY" is very powerful...

A preety self explanatory graphics to show the first step of initiating a CMMi process...

eQuality Jokes

Levels of the Capability Maturity Model (CMMi)

There are five levels defined along the continuum of the CMM, and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."


1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new process.
2. Managed - the process is managed according to the metrics described in the Defined stage.
3. Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions).
4. Quantitatively managed
5. Optimized - process management includes deliberate process optimization/improvement.


Within each of these maturity levels are Key Process Areas (KPAs) which characterise that level, and for each KPA there are five definitions identified:
1. Goals
2. Commitment
3. Ability
4. Measurement
5. Verification


The KPAs are not necessarily unique to CMM, representing — as they do — the stages that organizations must go through on the way to becoming mature.


The CMM provides a theoretical continuum along which process maturity can be developed incrementally from one level to the next. Skipping levels is not allowed/feasible.


Level 1 - Initial (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.


Level 2 - Managed
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.


Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.


Level 4 - Quantitatively Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.


Level 5 - Optimized
It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.
At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the process (for example, to shift the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.





(For More Info : http://en.wikipedia.org/wiki/Capability_Maturity_Model#Levels_of_the_Capability_Maturity_Model)

Five Levels of CMMi

CMMi (Capability Maturity Model Integration)

What Is CMMI?

CMMI (Capability Maturity Model Integration) is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance.
CMMI can be used to guide process improvement across a project, a division, or an entire organization.
It helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.

Is not about what, it’s about why.

"Is not about what, it’s about why."

We all know that Hexaware is getting reassessed for CMMi Level 5 in year 2011.But the question which may be coming to everyone mind will be “ Why our Organization need to be CMMi 5 certified?”

CMMi allows:

• Detailed coverage of the product life cycle than other process-improvement products used alone


• CMMi provides an opportunity to eliminate the stovepipes and barriers that typically exist in different parts of an organization and that typically are not addressed otherwise
  

• CMMi products incorporate lessons learnt that were learnt as a result of many other standard processes. Therefore they inherently, handle some of the common problems faced by other process improvement approaches

• Promotes collaboration between systems and software engineering
  

• Allows users to choose model representation that best suits them and their objectives
  
  
  
  

  

eQuality Team

Is not about what, it’s about
why.

eQuality stands for “ensuring Quality”. We are one of the CMMi awareness team of E&Y DDC-Mumbai. We aim to make everyone CMMi aware so that we can incorporate CMMi approach in our work.