Measure

A measure is a single quantitative attribute of an entity. It is the basic building block for a measurement program. Examples of measures are lines of code (LOC), work effort, or number of defects. Since quantitative measures can be compared, measures should be expressed in numbers.

For example, the measure LOC refers to the “number” of lines and work effort refers to the “number” of hours, days, or months.

Metrics

A metric is a derived (calculated or composite) unit of measurement that cannot be directly observed, but is created by combining or relating two or more measures. A metric normalizes data so that comparison is possible. Since metrics are combinations of measures they can add more value in understanding or evaluating a process than plain measures. Examples of metrics are mean time to failure and actual effort compared to estimated effort.

The process model is not intended to reflect processes at the detailed level. However, quality management system requirements for achieving product or service conformity may be placed within the model. A domain model such as CMMI, a process reference model such as defined in ISO/IEC 12207, or a process model derived from good practices such as in the ITIL may be easily inserted into the Product Realization Clause of ISO 9001:2000.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-11 at 7.49.20 PM.png

There are four main testing stages in a structured software development process. They are:

Unit Testing

These tests demonstrate that a single program, module, or unit of code function as designed. For example, observing the result when pressing a function key to complete an action. Tested units are ready for testing with other system components such as other software units, hardware, documentation, or users.

Integration Testing

These tests are conducted on tasks that involve more than one application or database, or on related programs, modules, or units of code, to validate that multiple parts of the system interact according to the system design. Each integrated portion of the system is then ready for testing with other parts of the system.

System Testing

These tests simulate operation of the entire system and confirm that it runs correctly. Upon completion, the validated system requirements result in a tested system based on the specification developed or purchased.

User Acceptance Testing

This real-world test is the most important to the business, and it cannot be conducted in isolation. Internal staff, customers, vendor, or other users interact with the system to ensure that it will function as desired regardless of the system requirements. The result is a tested system based on user needs.

Quality is a multifaceted concept driven by customer requirements. The level of quality can vary significantly from project to project and between organizations. In IT, the attributes of quality are examined in order to understand the components of quality, and as a basis for measuring quality. Some of the commonly accepted quality attributes for an information system are described in the following figure.

Management needs to develop quantitative, measurable "standards" for each of these quality criteria for their development projects. For example, management must decide the degree of maintenance effort that is acceptable, the amount of time that it should take for a user to learn how to use the system, etc.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-11 at 2.39.38 PM.png

Measure defect rate in defects per thousand function points or defects per thousand lines of code. As processes become better defined, controls become more effective, and as people become more motivated, the defect rate drops significantly.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-12 at 3.24.25 PM.png

To map processes, executive management (Quality Council) must have identified the organization's mission, long and short-term goals, organizational structure, and deliverables. If formal strategic planning is not regularly performed, identifying an organization's mission and goals is difficult.

Processes should be mapped to mission and goals, to functional units (people), and to deliverables in separate matrices. The following generic process can be used for each mapping:

1. Create a matrix.

2. List processes across the top of the matrix.

3. On the left side of the matrix, list the goals, functional units or roles or deliverables.

4. Identify the linkages between the rows and columns, as follows:

A process may support multiple goals. Put an X in the intersection to acknowledge a linkage only if the stability or quality of the process could influence meeting goals. If all processes contribute to all goals, decompose the mission and goals further. The resulting Manage-by-Process matrix is a process map.

Processes have primary owners, suppliers and customers. Identify a linkage in this matrix by using “O”, “S” or “C” in the intersection to distinguish between the roles.

Deliverables can be internal such as design specifications, or external such as user manuals. In this matrix indicate the usage of the deliverable by placing a “C”, “R”, “U” and/or “D” in the intersection. “C” is used when the deliverable is created, or the service is provided through the process. “R” indicates the deliverable is referenced or used as input to the process. “U” indicates the deliverable is updated or revised in the process. “D” means the deliverable is deleted, or retired, etc.

5. For mission and goal mapping, look for gaps where goals are not supported by processes. Consider removing any processes that do not support goals, as they do not add value. For functional unit mapping, look for gaps where units do not have processes. For deliverable mapping, look for gaps where deliverables do not have processes or vice versa.

6. If the mapping identified any new processes, add them to the inventory.

Verification ensures that the system (software, hardware, documentation, and personnel) complies with an organization’s standards and processes, relying on review of non-executable methods. Validation physically ensures that the system operates according to plan by executing the system functions through a series of tests that can be observed and evaluated. Verification answers the question, “Did we build the right system?” while validation addresses, “Did we build the system right?”

Keep in mind that verification and validation techniques can be applied to every element of the computerized system. You’ll find these techniques in publications dealing with the design and implementation of user manuals and training courses, as well as in industry publications.

1

Brainstorming

Brainstorming is a technique used to quickly generate a quantity of creative or original ideas on or about a process, problem, product, or service. Brainstorming can be used to:

Develop a vision

Review inputs, outputs, and flows of existing processes

Create a list of products or services

Eliminate wasteful and redundant work activities

Reengineer a process, product, or service

Design a new or improved process

Establish standards, guidelines, or measures

Identify the internal and external customers served

Improve the work environment

Gather data for use with other tools

Affinity Diagram

The affinity diagram is an orderly extension of a structured brainstorming session. Teams use this tool to help create order out of chaos, by categorizing large numbers of ideas. Rather than having teams react logically to a group of ideas, this technique helps to identify more creative solutions or to structure ideas for a cause-and-effect diagram.

Nominal Group Technique

The nominal group technique is a structured, facilitated technique where all team members participate by individually ranking ideas, issues, concerns, and solutions, and then achieve consensus by combining the individual rankings.

Cause-and-Effect Diagram

Teams use cause-and-effect diagrams to visualize, clarify, link, identify, and classify possible causes of problems in processes, products, and services. They are also referred to as "fishbone diagrams," “why-why diagrams,” or "Ishikawa diagrams" (after Kaoru Ishikawa, a quality expert from Japan).

Baselines should be quantitative even if it is a subjective measure, but quantitatively subjective. For example, because quality conformance and nonconformance must be defined by people, we are looking for ways to put this information into a quantifiable format. This does not convey a lot of information, but it is indicative of a problem. However, if we develop a five-point scale for unresponsiveness, and ask your dissatisfied customer to complete that scale, we now have conveyed a lot more information. If our scale rates “1” as very poor service, and “5” as very good service, there is a great deal of difference between a “1” rating and a “3” rating for dissatisfaction.

If people are the key, but are also a weak link, more and better attention must be paid to this “component of security”. A robust and enterprise-wide awareness and training program is paramount to ensuring that people understand their IT security responsibilities, organizational policies, and how to properly use them to protect the IT resources entrusted to them.

This practice provides a strategy for building and maintaining a comprehensive awareness and training program, as part of an organization’s IT security program. The strategy is presented in a life cycle approach, ranging from designing, developing, and implementing awareness and training program, through post-implementation evaluation of the program. The document includes guidance on how IT security professionals can identify awareness and training needs, develop a training plan, and get organizational buy-in for the funding of awareness and training program efforts.

Processes should be mapped to mission and goals, to functional units (people), and to deliverables in separate matrices. The following generic process can be used for each mapping:

Create a matrix.

List processes across the top of the matrix.

On the left side of the matrix, list the goals, functional units or roles or deliverables.

Identify the linkages between the rows and columns, as follows:

A process may support multiple goals. Put an X in the intersection to acknowledge a linkage only if the stability or quality of the process could influence meeting goals. If all processes contribute to all goals, decompose the mission and goals further. The resulting Manage-by-Process matrix is a process map.

Processes have primary owners, suppliers and customers. Identify a linkage in this matrix by using “O”, “S” or “C” in the intersection to distinguish between the roles.

Deliverables can be internal such as design specifications, or external such as user manuals. In this matrix indicate the usage of the deliverable by placing a “C”, “R”, “U” and/or “D” in the intersection. “C” is used when the deliverable is created, or the service is provided through the process. “R” indicates the deliverable is referenced or used as input to the process. “U” indicates the deliverable is updated or revised in the process. “D” means the deliverable is deleted, or retired, etc.

For mission and goal mapping, look for gaps where goals are not supported by processes. Consider removing any processes that do not support goals, as they do not add value. For functional unit mapping, look for gaps where units do not have processes. For deliverable mapping, look for gaps where deliverables do not have processes or vice versa.

If the mapping identified any new processes, add them to the inventory.

Total quality management (TQM) is the term used by many to indicate an organization-wide effort of continuous process improvement. The Federal Quality Institute defines TQM as a strategic, integrated management system for achieving customer satisfaction, which involves all managers and employees and uses quantitative methods to continuously improve an organization's processes.

Some additional thoughts on TQM include:

The improved performance is directed toward satisfying such cross-functional goals as quality, cost, schedule, mission, need and suitability.

TQM is a process of controlled change.

Central to the TQM approach is the change in management philosophy regarding the "responsibility for quality." Formerly it rested with a separate group of individuals in a department/directorate/division often designated as quality assurance. Under TQM, the responsibility rests with every employee, beginning with top management. Skill Category 2 provides additional insight into the change in management philosophy, new behaviors for management and leadership.

TQM is accomplished using a team organization; both management and the employees are members of "quality teams" (also called process improvement or process action teams), that focus on continuous process improvement. Suggestions to improve the quality of a particular process should come from the employees and the managers who work in the process, as they know it best.

Communication must be encouraged to allow employees and management to work together to reach the mutual goal of continuous process improvement.