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 :)