IT organizations cannot protect the confidentiality, integrity, and availability of information in today’s highly networked systems environment without ensuring that all the people involved in using and managing IT:

Understand their roles and responsibilities related to the organizational mission

Understand the organization’s IT security policy, procedures, and practices

Have at least adequate knowledge of the various management, operational, and technical controls required and available to protect the IT resources for which they are responsible

Fulfill their security responsibilities.

As cited in audit reports, periodicals, and conference presentations, it is generally agreed by the IT security professional community that people are the weakest link in attempts to secure systems and networks.

While there is no one best way to develop a security awareness program, the process that follows is an all-inclusive process of the best security awareness training program. This example includes these three steps:

1. IT management creates a security awareness policy.

2. Develop the strategy that will be used to implement that policy. (Note that this practice focuses on that strategy. Other practices will explain how to implement the steps in that strategy.)

3. Assign the roles for security and awareness to the appropriate individuals.

A process can be measured by either of the following:

Attributes of the process, such as overall development time, type of methodology used, or the average level of experience of the development staff.

Accumulating product measures into a metric so that meaningful information about the process can be provided. For example, function points per person-month or LOC per person-month can measure productivity (which is product per resources), the number of failures per month can indicate the effectiveness of computer operations, and the number of help desk calls per LOC can indicate the effectiveness of a system design methodology.

There is no standardized list of software process metrics currently available. However, in addition to the ones listed above, some others to consider include:

Number of deliverables completed on time

Estimated costs vs. actual costs

Budgeted costs vs. actual costs

Time spent fixing errors

Wait time

Number of contract modifications

Number of proposals submitted vs. proposals won

Percentage of time spent performing value-added tasks

Using defects to improve processes is not done by many organizations today, but it offers one of the greatest areas of payback. NASA emphasizes the point that any defect represents a weakness in the process. Seemingly unimportant defects are, from a process perspective, no different from critical defects. It is only the developer’s good luck that prevents a defect from causing a major failure. Even minor defects, therefore, represent an opportunity to learn how to improve the process and prevent potentially major failures. While the defect itself may not be a big deal, the fact that there was a defect is a big deal.

Based on the research team findings, this activity should include the following:

Go back to the process that originated the defect to understand what caused the defect

Go back to the verification and validation process, which should have caught the defect earlier

Not only can valuable insight be gained as to how to strengthen the review process, these steps make everyone involved in these activities take them more seriously. This human factor dimension alone, according to some of the people the research team interviewed, can have a very large impact on the effectiveness of the review process.

Vision:

It states what the organization intends to achieve.

Senior Management (CIO)

“To become Global Top 10”

Value:

It states how to run the business.

Senior Management

“Will satisfy customer needs”

Goal:

It states how the vision will be achieved.

Senior Management

“Establish a customer vision group”

Principle:

It states the quality attribute of the organization.

Quality council

“Need for a quality function”

In the prioritization process, risks from the analysis process are ranked from highest to lowest. When possible, they should be ranked quantitatively; otherwise, it is done qualitatively. Items that have similar ranks may need to be ranked separately.

If the high-medium-low method was used to calculate risk, the analyst would need to determine how to rank the two scores of 5, the three scores of 4 and the two scores of 3. In other words, determine whether the value of the frequency or the value of the impact would be more important.

Risks may also be prioritized using a question-and-answer technique to filter out unimportant risks. Four filters are typically used: impact (significant or insignificant), likelihood of occurrence (very likely or not likely), time frame (short-term or long-term), and program control (within control or not within control).

When addressing security issues, some general information security principles should be kept in mind, as follows:

Simplicity

Security mechanisms (and information systems in general) should be as simple as possible. Complexity is at the root of many security issues.

Fail Safe

If a failure occurs, the system should fail in a secure manner. That is, if a failure occurs, security should still be enforced. It is better to lose functionality than lose security.

Complete Mediation

Rather than providing direct access to information, mediators that enforce access policy should be employed. Common examples include file system permissions, web proxies and mail gateways.

Open Design

System security should not depend on the secrecy of the implementation or its components. “Security through obscurity” does not work.

Separation of Privilege

Functions, to the degree possible, should be separate and provide as much granularity as possible. The concept can apply to both systems and operators and users. In the case of system operators and users, roles should be as separate as possible. For example, if resources allow, the role of system administrator should be separate from that of the security administrator.

There is a high correlation between process maturity and cycle time. As shown in the figure below, as processes mature, there is a decrease in the cycle time to build software products. The maturity of processes, people, and controls has associated with it a search for the root cause of problems. It is these problems that lead to rework which, in turn, extends the cycle time. Thus, improvements also focus on facilitating transitions of deliverables from work task to work task, which also significantly reduces cycle time.

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

Control charts provide a way of objectively defining a process and variation. They establish measures on a process, improve process analysis and allow process improvements to be based on facts. Note: variation is briefly described here to put control charts in perspective. Skill Category 8 provides additional details on the topic of variation.

The intent of a control chart is to determine if a process is statistically stable and then to monitor the variation of stable process where activities are repetitive. There are two types of variation:

Common or random causes of variation

These are inherent in every system over time, and are a part of the natural operation of the system. Resolving common cause problems requires a process change.

Special causes of variation

These are not part of the system all the time. They result from some special circumstance and require changes outside the process for resolution.

Control charts are suitable for tracking items such as:

Production failures

Defects by life cycle phase

Complaint/failures by application/software

Response time to change request

Cycle times/delivery times

Mean time to failure

A histogram requires some understanding of the data set being measured to consolidate or condense it into a meaningful display. To create a histogram, perform the following steps:

Gather data and organize it from lowest to highest values.

Calculate the range, which is the largest value – smallest value.

Based on the number of observations, determine the number of cells, which is normally between 7 and 13.

Calculate the interval or width of the cells, which is the range divided by number of cells.

Sort the data or observations into their respective cells.

Count the data points of each cell (frequency) to determine the height of the interval, and create a frequency table.

Plot the results.

Define the Scope of the Process

Use the Process Inventory, Process Maps, and existing standards and procedures to clarify the scope of the process. This involves developing a high-level process flow (major workbenches and interfaces with other processes), major inputs and outputs (deliverables), and major customers and their requirements.

Develop the Workflow

Brainstorm the tasks and deliverables in the process and then group the tasks. Select the current best practices, adding missing tasks or deliverables and correcting flaws in the workflow. Define the workbenches internal to the process, their sequence, and major interim deliverables. Typically processes contain 3-5 workbenches, with each workbench containing 3-7 process steps or task procedures.

Develop Policies

A policy states why the workbench or deliverable exists, and indicates desired results (desirable attributes of process performance or desirable product quality characteristics). Policies should link to the organization’s strategic goals, and support customer needs or requirements. A policy should be realistic, stating a desire that the organization is currently capable of accomplishing.

Develop Standards

A standard states what must happen to meet the intent of the policy. Standards are more specific than policies in that they convert intentions into specific rules. Workbench standards deal withperformance issues related to time frames, prerequisites, or sequencing of tasks while deliverable standards typically specify content.

Develop Procedures

Procedures describe how work is done, and indicate the "best current way" to meet standards. Ideally, if the procedures are followed, the standards will automatically be followed and the intent of the policy will be met.

A task is a single step in a procedure. Procedures may have many tasks. Task procedures should refer to people, accessible tools, known techniques or methods, and templates for deliverables. If appropriate, tasks can also refer to more detailed work instructions, such as training or user’s manuals.

If you want to develop a baseline of customer satisfaction, you might ask your customer to rate the following factors using “very satisfied” to “very dissatisfied” as a scale:

Availability– Accessible to the customer, as agreed (e.g., product is available when you need it).

Correctness– Accurate and meets business and operational requirements (e.g., automated information is accurate).

Flexibility– Easy to customize for specific needs (e.g., easy to enhance product with new features).

Usability– Easy to learn, easy to use, and relevant (e.g., the way you interact with components of the product is consistent).

Caring– Demonstrating empathy, courtesy, and commitment (e.g., project team is sensitive to your needs).

Select Process and Team

The process to be improved may be selected by the improvement team or assigned by management. Leaders of improvement teams are usually process owners, and members are process users and may be cross-functional. Organizational improvement team members are usually volunteers; however, if subject experts are required and none volunteer, management will assign them. After the process has been selected and the improvement team formed, customers of, and suppliers to, the process are determined. If not already on the team, customer and supplier representatives should be added when practical.

Describe the Process

Two simultaneous actions are initiated in this step: defining customer-supplier relationships and determining actual process flow. The customer's requirements are defined using operational definitions to assure complete understanding between those providing the product or service and the customer. The customer's quality characteristics are defined and the current state of satisfying these, determined. In most instances, the customer referred to is the internal customer. This same idea is applied to the suppliers in the process. The process owner's expectations are defined for suppliers of inputs to the process. The customer and supplier must then agree on the specifications to be met and how quality will be measured.

Assess the Process

To assure that decisions are being made using precise and accurate data, the measurement system used to assess the process must be evaluated. If the measurement is counting, care should be taken to assure that everyone is counting the same things in the same manner. Once it has been determined that the measurement system accurately describes the data of interest, the input and output should be measured and baselines established.

Brainstorm for Improvement

The team should review all relevant information, such as the process flowchart, cause-and-effect diagrams, and control charts. A brainstorming session may be held to generate ideas for reducing input variation. It may help to visualize the ideal process. Improvement ideas must be prioritized and a theory for improvement developed. The what, how, and why of the improvement should be documented so everyone agrees to the plan. All statistical tools should be used in this step, although brainstorming is used the most.

Plan How to Test Proposed Improvement(s)

In this step a plan for testing the proposed improvement developed in the preceding step is created. This process improvement plan specifies what data is to be collected, how the data is to be collected, who will collect the data, and how the data will be analyzed after collection. The specific statistical tools to be used for analysis are defined. Attention is given to designing data collection forms that are simple, concise, and easy to understand. The forms should be tested before being put into use. The process improvement plan is a formal document that is approved by the improvement team.

Analyze Results

The plan developed in the prior step is implemented. The required data is collected using the previously tested forms, and then analyzed using the statistical tools noted in the process improvement plan. The plan is reviewed at improvement team meetings to track progress on process improvement. The tools usually used in this step are data collection methods, flowcharts, run charts, scatter diagrams, histograms, measurement capability, control charts, process capability, and advanced statistical techniques.

Compare Results

This step uses the same statistical tools as in Step 3 to compare the test results with that predicted in Step 4. Has the process been improved? Do the test results agree with scientific or engineering theory? If the results are not as expected, can they be explained? When results are not as expected, it is not a failure - something is still learned about the process and its variation. The new information will be used to develop a new theory. Care is taken to document lessons learned and accomplishments. A set of before and after Pareto charts, histograms, run charts, or control charts are generally used in this step.

Change Process or Redo Steps 4-8

If the results are not as expected, then based on what was learned, a new method for improvement must be developed by reverting back to Step 4. If the results are as expected, and are practical and cost effective, the change recommended in the process improvement plan is implemented. The implementation should be monitored to assure that the gains made in reducing variation are maintained. The team then returns to Step 2 to update the process documentation.

In this planning process, a response or strategy is developed for each item in the prioritized risk listing. It may include a primary choice and a backup option.

Responses to risk can be categorized in one of three ways:

Accepting the consequences if the event occurs

Active acceptance would involve developing a contingency plan that would be executed if the risk occurs

Passive acceptance would allow the risk event to occur (e.g., making less money if the project is a few weeks late)

Avoiding the consequences by eliminating possibility of the event occurring

Mitigating the risk (reducing it's expected value) by:

Minimizing the probability of occurrence

Minimizing the value of the impact

Deflecting (or transferring) the risk elsewhere (in a software project this might mean passing the risk onto a subcontractor or to the customer).