1. The primary life cycle process of acquisition, supply, development, operation and maintenance of software.
2. The organization life cycle processes of management, infrastructure, improvement and training.
3. The supporting life cycle processes of documentation, configuration management, verification, validation, joint review, audit and problem resolution, which are needed to implement the primary and organizational.

This QMS shall be implemented and continuously improved. The improvement of QMS can result in:

• Increased control of the existing processes like Business Development, Project Management, and Change Management etc.
• Improvement of results achieved through the defined processes. The examples of results can be Defect Density, Schedule Variance, and Requirements Creep etc.

All applicable processes such as Business Development Process, Contract Process, Project Management Process, Requirements Management Process, Design and Development Process, Configuration Management Process, Release Process etc. shall be identified.

These processes shall have interaction with each other and this shall be mentioned in the processes. This could be done via flow charts or some other diagrams as appropriate. The software organizations, should define the sequence and interaction of the life cycle processes in:

• Procedures that define life cycle models for development such as waterfall, incremental or evolutionary.
• Development Plans, which should be based upon a life cycle model.

The outsourced process must also have interaction with other Quality management systems process. Examples:

• The output of Requirement Management Process is approved requirement document which is input for Design and Development Process.
• The output of feasibility study (Feasibility Report) going as an input into design stage.
• Approved detail design document going as an input into coding phase.

The criteria and methods should be defined to ensure the successful completion and effectiveness of the process. E.g. defining the process through ETVX (Entry, Task, Verification, and Exit) for all the tasks.

The availability of resources (human resources, infrastructure, environment, information etc.) should be ensured for successful implementation and monitoring of processes. E.g. successful execution of the project shall require human resources with some specific skills, computers, software tools etc. These resources shall be identified by the Project Planning and Project Management Process. Monthly SIR (Structured in-depth Review) or WSR (Weekly Status Report) could be the information to monitor the project status.

There shall be monitoring, measuring and analysis of the defined processes. The tolerance limits shall be set for pre-defined parameters which shall be monitored and action taken when they are exceeded. E.g. Schedule and Effort Variance could be the parameters which could be measured, monitored and analysed at pre-defined intervals or at each phase end. The goals and targets shall be defined for these parameters. When these parameters exceed the limit, the root cause shall be analysed and accordingly correction, corrective and preventive actions shall be applied. These actions shall be initiated to achieve continuous improvement.

If the organization outsources any of its process that has an impact of the product quality, the same should also be controlled. The outsourcing policy should be defined and implemented. E.g. if testing the product is to be outsourced, then the same shall be identified in the Quality Management System as well as in the Project Management Plan of the concerned project.

If a software organization chooses to outsource any process like testing or database design or even some part of coding which affects product / service conformity with requirements, the organization shall ensure control over such processes. These processes must be part of the quality management system.

The supplier / service provider can be of two types:

• Outside from the organization: An outsourced process generally performed by a supplier or service provider who is totally independent from the software organization.
• Within same organization but from a separate department: Supplier / service provider can also be part of the same organization but from a separate department that is not subject to the same quality management system. For example if an organization have multiple offices in different cities having different Quality management systems, then supplier can be from any other location.

In both cases, for the selection of supplier / service provider, the ISO 9001:2008 clause 7.4 Purchasing is applicable. Some kind of controls needs to be in place to ensure that the outsourced activities or tasks are performed according to the

• Requirements of ISO 9001
• Requirements of the organization’s quality management system

The type and extent of controls depend on the:

• Risk or impact of the outsourced process on the organization’s capability to provide product that conforms to the requirements.
• The competence of the supplier / service provider to meet the process requirements

If the software producing organization does not have the enough competence to carry out the process itself, and chooses to outsource it; then the organization may involve external specialists to ensure that the controls proposed by the supplier of the outsourced process are adequate. The controls have to be based on the need for product conformity to requirements including statutory and regulatory requirements.

However, if it is not possible to verify the output of the outsourced process, then a control needs to be in place for the validation of the output. For this validation, the ISO 9001:2008 clause 7.5.2 Validation of processes for production and service provision is applicable.

Engineering processes shall include analysis, design, and coding.  Quality Assurance processes include verification and validation processes.  Products include documents and code. If the scope of the audit is limited; then planning will be within the defined limits.  During a limited audit, the auditor may verify or check only few processes or some set of work products. Planning and preparation phase is very important in a limited audit. The auditor/lead auditor must be very careful while identifying the processes or product.

First of all, the auditor must understand the business logic or objective of the software project and what end products are to be produced. The auditor must need to understand the contractual requirements for the deliverable software, documentation, project management, software engineering and quality assurance practices. After understanding these requirements, the auditor should review the software project plan, configuration management plan, quality assurance plan, risk tracker, staffing and training plan, development processes etc. to understand the processes or procedures being followed for the software development.

The review of status reports from the development team is helpful to understand the stage of completeness of products and may contain useful information from the audit point of view. After understanding the project and its current status, the auditor needs to define the critical areas that require the detailed attention. The source of this information may be status reports, minutes of meeting of the review meetings with client or management, non-conformance reports and results of previous audits.

The auditor / lead auditor must inform the auditee team about the intent / scope of audit including the date and time of audit.

Now, the next task for the auditor is to prepare a checklist. Basically, the checklists act as a road map during the actual audit. So, the checklists must include all checkpoints and questions to be asked from the auditee.

Generally, the checklist is already available in the Quality Management System. However, the checklist must be tailored for the specific project to be audited.

Regarding the checklists, my views are:

• General Audit – a comprehensive and less detailed checklist
• Limited Audit – a more detailed checklist in the specific area
• Internal Quality Audit – a detailed checklist in all the relevant areas

The quality of the audit is directly proportional to the quality of the checklist prepared. The checklists are very critical to the success of audit. These checklists are also very helpful for the auditee to understand the type of questions and records the auditor will examine.

Product Defects: Product Defects are the defects that are introduced and detected during the various stages of software development life cycle. While the defects get introduced during the various activities of the phase, the detection occurs during reviews and various types of testing efforts.

The various types of defects occuring during the SDLC activities can be categorized as follows:

- Functionality Errors
- External Interface Errors
- Performance Problems
- Environment Errors

Examples of SDLC defects:

Requirements: Performance Exceptions of the system not properly defined
Design: Program Specifications did not specify of number of decimal places
Design: Architecture was not perperly planned
Coding: Variable no initialized, Missing if condition

Process Defects: Process defects are caused during execution of project and usually detected during audits. While such defects get introduced during various project activities and get detected during various conducted during the project life cycle. All such defects are of the nature of deviations in process implementations of the organization or the project. Though it is difficult to draw a co-relation between process and product defects, however, the existence of process defects are indicative of larger number of product defects. Also, existence of such defects raise a question mark about the quality of the software product.

Examples of Process Defects:

- Risk Management Plan is not in place
- Change request impact on schedule and effort not reflected
- Project Management Plan not kept up to date with current status of the project
- Requirements tracking is incomplete
- Review Plan is not adequate
- Requirements gathering strategy not defined for the product
- Quality goals are not tracked
- Issue tracking mechanism is adhoc

Location: Pune

Education & Experience: Any Graduate with 4-6 years of experience

Position: Asst Manager-  Quality (Black Belt)

Desired skills:

• Completed BB Training or Black belt certified.
• Completed at least 1 BB project successfully.
• Mentoring the GB, Lean & YB projects.
• Training the GBs.
• Should be from quality department only. Not from Operations.

If you are interested, please mail your resume at vinod@viaah.in along with the following details:

• Academic Background:
• Current Salary:
• Expected Salary:
• Joining time:
• Current contact no:
• Reason for Looking Change:
• The tools used for implementing projects:

====================================================

Nothing is constant in this world. The environment, vulnerabilities and business models are continuously changing. So, it becomes important to continually review the information security policy.

Information security policy should be continually monitored with respect to continuing suitability, adequacy and effectiveness. To ensure the effectiveness of information security policy, a formal information security review and evolution process can be created which measures the levels of effectiveness for each of the 133 controls. If some controls are not implemented with effectiveness, then impact analysis should be done. Impact analysis should be done while considering risks to environment, organization and business models.

Management review and approval records for the review of information security policy should be maintained.

Following actions can result in review and evolution of information security policy document:

• Changes in information systems
• Change in Environments – Technical / organizational
• Change in Operational Processes
• New Business Objectives / Models
• New known vulnerabilities
• Resource Availability
• Change in Contractual, Statutory, Regulatory and Legal requirements / conditions
• Findings of Management Review
• Preventive & Corrective Actions
• Feedback from all interested parties & authorities
• Reviews within a team / workgroup
• Trends related to risks / threats / vulnerabilities
• Reported information security incidents

Important questions to be answered while implementing this control:

• Is owner or owners are identified for information security policy document and process who is responsible for development, review & evaluation and updating of policy document?
• How often is the information security reviewed for effectiveness and applicability?
• Does the management engage qualified external matter experts to review the information security policy?
• Does the policy owner operate from a defined and documented review process to revise and update the policy?
• How are qualifying events reviewed to determine if a policy revision or update is required?
• Is a formal management approved process is required for policy changes and updates?
• Is the revised policy reviewed and approved from senior management?
• Are the records of management review are available?