CSQA Sample Questions Answers

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.

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.

CobiT is generally applicable and an accepted standard for IT security and control practices that provides a reference framework for management, users, and IS audit, control and security practitioners. CobiT enables an enterprise to implement effective governance over IT that is pervasive and intrinsic throughout the enterprise.

There are four major uses of quantitative data (i.e., measurement):

1. Manage and control the process.

A process is a series of tasks performed to produce deliverables or products. IT processes usually combine a skilled analyst with the tasks defined in the process. In addition, each time a process is executed it normally produces a different product or service from what was built by the same process at another time. For example, the same software development process may be followed to produce two different applications. Management may need to adapt the process for each product or service built, and needs to know that when performed, the process will produce the desired product or service.

2. Manage and control the product.

Quality is an attribute of a product. Quality level must be controlled from the start of the process through the conclusion of the process. Control requires assuring that the specified requirements are implemented, and that the delivered product is what the customer expects and needs.

3. Improve the process.

The most effective method for improving quality and productivity is to improve the processes. Improved processes have a multiplier effect because everyone that uses the improved process gains from the improvement. Quantitative data gathered during process execution can identify process weaknesses, and, therefore, opportunities for improvement.

. Manage the risks.

Risk is the opportunity for something to go wrong - for example, newly purchased software will not work as stated, projects will be delivered late, or workers assigned to a project do not possess the skills needed to successfully complete it. Management needs to understand each risk, know the probability of the risk occurring, know the potential consequences if the risk occurs, and understand the probability of success based upon different management actions.

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

Target Audience

The target audience for ISO/IEC 12207 is:

Organizations acquiring a system that contains software or a stand-alone software product

Organizations that supply software products

Organizations involved in software operation or software maintenance

The standard is especially applicable for acquisitions, as it recognizes the distinct roles of acquirer and supplier. Its intended use is for the two parties of an agreement or contract that defines the development, maintenance, or operation of software. It does not apply to the purchase of commercial off-the-shelf software products. It is also intended for use with trained, experienced developers, managers, and acquirers of software.

Views of Software Development

Given the target audience, ISO/IEC 12207 includes several different points of view regarding software development:

Acquirers and suppliers see a contract view, which includes the acquisition and supply processes and begins with a contractual relationship to supply software. Depending on the contract, the supply process may use the development process to create new software, the operation process to provide software operation services, or the maintenance process to repair or improve the software.

Operators see an operating view, which includes the operations process. The operations process may use the maintenance process.

Developers and maintainers see the engineering view, which includes the maintenance and development processes. The maintenance process may also use the development process.

The employer of supporting processes sees the supporting view, which includes the eight supporting processes.

Managers see the corporate view, which includes the four organizational processes.

Independent monitoring are those monitoring activities, which are performed by individuals not employed by the organizational unit responsible for the work. Independent monitoring can be performed by:

An organizational unit established for the purpose of monitoring

For example, in health care units, an “HIPAA compliance group” might be established to monitor compliance to HIPAA requirements.

Internal auditors

An audit activity within the organization who is independent from the organization they monitor or audit, and generally independent from the management over the activity being monitored.

External auditors

Auditors engaged by the Board of Directors to evaluate the adequacy of the organization’s system of internal control and other activities governed by auditing standards.

The extensiveness of independent monitoring is normally determined by the adequacy of the organization’s system of internal controls. If those performing independent monitoring believe that the system of internal control is effective, the extent of their monitoring will decrease. On the other hand, if there’s significant weakness in the system of internal control, monitoring will be increased.

Automated Enforcementis normally viewed as the most fair of all methods of enforcement. It isnormally performed by a computer. The rules are included in the computer system, and whenthose rules are violated, enforcement is automatic.

Automated enforcement is a predetermined enforcement decision. The computer merely executes the action. For example, if you need a password to enter into a system and you do not enter a correct password, access is denied. If you are charging items on your credit card and you have exceeded your credit limit, the computer action is to disallow the purchase.

There are three COQ categories:

Prevention- Money required preventing errors and to do the job right the first time is considered prevention cost. This category includes money spent on establishing methodsand procedures, training workers and planning for quality. Prevention money is all spent before the product is actually built.

Appraisal– Appraisal costs cover money spent to review completed products against requirements. Appraisal includes the cost of inspections, testing and reviews. This money is spent after the product or subcomponents are built but before it is shipped to the user.

Failure– Failure costs are all costs associated with defective products. Some failure costs involve repairing products to make them meet requirements. Others are costs generated by failures, such as the cost of operating faulty products, damage incurred by using them and the costs incurred because the product is not available. The user or customer of the organization may also experience failure costs.

The following figure shows a few examples of the three costs of quality that illustrate the types of activities in each of the categories. Experience has shown that a small group of knowledgeable people can develop estimates for the COQ categories. The estimate does not have to be highly precise because the amounts will be so large that even errors of plus or minus 50% would not affect identifying the actions that need to be taken to reduce the COQ.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-10 at 7.41.23 PM.png

Industry accepted definitions of quality are “conformance to requirements” (from Philip Crosby) and “fit for use” (from Dr. Joseph Juran and Dr. W. Edwards Deming). These two definitions are not inconsistent.

Meeting requirements is a producer’s view of quality. This is the view of the organization responsible for the project and processes, and the products and services acquired, developed, and maintained by those processes. Meeting requirements means that the person building the product does so in accordance with the requirements. Requirements can be very complete or they can be simple, but they must be defined in a measurable format, so it can be determined whether they have been met. The producer’s view of quality has these four characteristics:

Doing the right thing

Doing it the right way

Doing it right the first time

Doing it on time without exceeding cost

Being fit for use is the customer’s definition. The customer is the end user of the products or services. Fit for use means that the product or service meets the customer’s needs regardless ofthe product requirements. Of the two definitions of quality, fit for use, is the more important. The customer’s view of quality has these characteristics:

Receiving the right product for their use

Being satisfied that their needs have been met

Meeting their expectations

Being treated with integrity, courtesy and respect

In business and accounting literature, the environment is referred to in many different ways. In accounting literature it is sometimes called the “control environment,” other times the “management environment,” and sometimes just the environment in which work is performed.

For the purpose of this skill category, we will refer to it as the “quality environment.” What is important to understand is that the environment significantly impacts the employee’s attitude about complying with policies and procedures. For example, if IT management conveys that they do not believe that following the system development methodology is important, project personnel most likely will not follow that system development methodology. Likewise, if IT management conveys a lack of concern over security, employees will be lax in protecting their passwords and securing confidential information.

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:

IT management creates a security awareness policy.

Develop the strategy that will be used to implement that policy.

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

Step 1 – Create a Security Awareness Policy

The CIO and/or the IT Director need to establish a security awareness policy. The policy needs to state management’s intension regarding security awareness. Experience has shown that unless senior management actively supports security awareness, there will be a lack of emphasis on security among the staff involved in using information technology and information.

Management support for security awareness begins with the development and distribution of a security awareness policy. Once that policy has been established, management makes security awareness happen through supporting the development of a strategy and tactics for security awareness, appropriately funding those activities, and then becoming personally involved in ensuring the staff knows of management’s support for security awareness.

Step 2 – Develop a Security Awareness Strategy

A successful IT security program consists of: 1) developing an IT security policy that reflects business needs tempered by known risks; 2) informing users of their IT security responsibilities, as documented in the security policy and procedures; and 3) establishing processes for monitoring and reviewing the program.

Security awareness and training should be focused on the organization’s entire user population. Management should set the example for proper IT security behavior within an organization. An awareness program should begin with an effort that can be deployed and implemented in various ways and is aimed at all levels of the organization including senior and executive managers. The effectiveness of this effort will usually determine the effectiveness of the awareness and training program. This is also true for a successful IT security program.

An effective IT security awareness and training program explains proper rules of behavior for the use of an organization’s IT systems and information. The program communicates IT security policies and procedures that need to be followed. This must precede and lay the basis for any sanctions imposed due to noncompliance. Users first should be informed of the expectations. Accountability must be derived from a fully informed, well-trained, and aware workforce.

This step describes the relationship between awareness, training, and education – the awareness training-education continuum. An effective IT security awareness and training program can succeed only if the material used in the program is firmly based on the IT security awareness policy and IT issue-specific policies. If policies are written clearly and concisely, then the awareness and training material – based on the policies – will be built on a firm foundation.

Step 3 – Assign the Roles for Security Awareness

While it is important to have a policy that requires the development and implementation of security and training, it is crucial that IT organizations understand who has responsibility for IT security awareness and training. This step identifies and describes those within an organization that have responsibility for IT security awareness and training.

Some organizations have a mature IT security program, while other organizations may be struggling to achieve basic staffing, funding, and support. The form that an awareness and training program takes can vary greatly from organization to organization. This is due, in part, to the maturity of that program. One way to help ensure that a program matures is to develop and document IT security awareness and training responsibilities for those key positions upon which the success of the program depends.

1 – The major advantages are”

Relinquishment of control -The software is developed by individuals who are not employees of the organization,and thus it is difficult to oversee the development process. The contractingorganization cannot direct the employees of the other organization, nor have controlover the many day-to-day decisions that are made in developing software.

Loss of control over reallocation of resources -If work needs to be done to correct problems and/or speed up development, thecontractor cannot take workers off one project and assign them to another project.

2 – The major disadvantages are:

Cultural differences -There may be a significant difference in the culture and values between the contractorand the offshore organization.

Communication barriers -The language of the offshore organization may be different or difficult to comprehendwhich causes difficulty in communicating the needs and desires of the contractor.

LOC is the most common way of quantifying software size; however, this cannot be done until the coding process is complete. Function points have the advantage of being measurable during the design phase of the development process or possibly earlier.

J. Albrecht proposed a metric for software size and the effort required for development that can be determined early in the development process. This approach computes the total function points (FP) value for the project, by totaling the number of external user inputs, inquiries, outputs, and master files, and then applying the following weights: inputs (4), outputs (5), inquiries (4), and master files (10). Each FP contributor can be adjusted within a range of ±35% for a specific project complexity.

Common Causes of Variation

All processes contain some inherent variation, or common causes of variation. The amount of variation in a process is quantified with summary statistics (the mean and standard deviation).

A process is defined as stable when its mean and standard deviation remain constant over time. Processes containing only common causes of variation are considered stable. As a stable process is predictable, future process values can be predicted within the control limits with a certain amount of belief. A stable process is said to be in a state of statistical control.

One researcher1 provides the following thoughts on common causes of variation:

"Process inputs and conditions that regularly contribute to the variability of process outputs.”

“Common causes contribute to output variability because they themselves vary.”

Special Causes of Variation

Special causes of variation are not present in a process. They occur because of special or unique circumstances. In the IT example of abnormal terminations in a computer operation, special causes might include operator strikes, citywide power outages, or earthquakes.

If special causes of variation exist, the process may be unpredictable, and therefore unstable. A state of statistical control is established when all special causes of variation have been eliminated (the operator strike ends, citywide power returns or business returns to normal operations after an earthquake).

Brian Joiner summarized special causes of variation as follows:

"Process inputs and conditions that sporadically contribute to the variability of process outputs.”

“Special causes contribute to output variability because they themselves vary.”

Joiner outlined this strategy for reducing common causes of variation:

"Talk to lots of people including local employees, other managers, and staff from various functions.”

“Improve the measurement processes if measuring contributes too much to the observed variation.”

“Identify and rank categories of problems by Pareto analysis.”

The IT Quality Plan should include the following:

A reference to the organization's quality policy

An assessment of where the organization currently stands in relation to accomplishing the quality policy

Long-term quality goals - these are discussed below

Short-term quality objectives (i.e., programs) - these are discussed below

The means of implementing the quality objectives

Resources required in order to accomplish the short-term objectives and long term-goals

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

Static testing is another name for in-process reviewing. It means that the test is being performed without executing the code. Static testing occurs throughout the development life cycle; however, a large part of it takes place during the requirements and design phases in the form of walkthrough inspections, and system reviews. Other examples of static testing include code analyzers or writing analyzers.

There are two types of static tests:

Validation

Validation is testing the software in an operational state. While there are several iterations of testing, they do not occur until the latter part of the system development life cycle. Thus, validation does not take advantage of the control theory stating that the control should be placed as close as possible to where the defect occurs. The most common types of validation are unit testing, integration testing, and system testing. Unit testing tests the smallest operating module ofa system; integration testing tests the connecting logic between the modules/units; and the systemtesting validates that the system executes in the organization's operating environment.

Verification

Verification is the static testing of the system in a nonoperational status. It primarily tests the documentation produced by the project team. The documentation includes requirements, design, code, test, and operating documentation. Verification is performed through a variety of processes, including code analyzers, walkthroughs, reviews, and inspections. These verification processes also interact with the project team, end users, and other interested parties. Level 2 also incorporates acceptance testing, in which the end users define the criteria, which the system must meet in order to, be acceptable, and then test against those criteria.

Management Tools

These tools are based on logic rather than mathematics, to address idea generation and organization, decision-making and implementation. The examples are brainstorming and affinity diagram.

Statistical Tools

These tools have a mathematical focus, usually related to data collection, organization, or interpretation. They may also be separated into tools used for counting and tools used with measures. The examples are check sheet and histogram.

Presentation Tools

These tools are used during presentations to summarize or graphically illustrate data. These tools may be used in the development of written materials, such as proposals or reports, or to accompany oral presentations. The examples are table and line chart.

Objective measurement uses hard data that can be obtained by counting, stacking, weighing, timing, etc. Examples include number of defects, hours worked, or completed deliverables. An objective measurement should result in identical values for a given measure, when measured by two or more qualified observers.

Subjective data is normally observed or perceived. It is a person's perception of a product or activity, and includes personal attitudes, feelings and opinions, such as how easy a system is to use, or the skill level needed to execute the system. With subjective measurement, even qualified observers may determine different values for a given measure, since their subjective judgment is involved in arriving at the measured value. The reliability of subjective measurement can be improved through the use of guidelines, which define the characteristics that make the measurement result one value or another.

Following are a few other examples of objective and subjective measures:

The size of a software program measured in LOC is an objective product measure. Any informed person, working from the same definition of LOC, should obtain the same measure value for a given program.

The classification of software as user-friendly is a subjective product measure. For a scale of 1-5, customers of the software would likely rate the product differently. The reliability of the measure could be improved by providing customers with a guideline that describes how having or not having a particular attribute affects the scale.

Development time is an objective process measure.

Level of programmer experience is a subjective process measure.

Level 2 organizations have installed basic management controls. Policies for managing a software project and procedures to implement those policies are established. Planning and managing projects is based on experience with similar projects. Realistic project commitments are based upon the results observed on previous projects and on the requirements of the current project. Project managers track software costs, schedules, and functionality. Problems in meeting commitments are identified when they arise. Software requirements and the work products developed to satisfy them are baselined and their integrity is controlled.

The capability of Level 2 organizations is summarized as disciplined, because the ability to successfully repeat planning and tracking of earlier projects results in stability. To be certified at Level 2, organizations must document (define), practice, enforce, train, measure, and improve the following six key process areas:

Requirements Management

Software Project Planning

Software Project Tracking

Software Subcontract Management

Software Quality Assurance

Software Configuration Management

A list of five critical success factors required to evaluate COTS software is as follows:

Assure Completeness of Needs Requirements

Define Critical Success Factor

Determine Compatibility with Hardware, Operating System, and other COTS Software

Assure the Software can be Integrated into Your Business System Work Flow

Demonstrate the Software in Operation

Just-in-time principles can be used in IT in the following ways:

Systems development and maintenance tasks become driven when the user of an internal or external product or service needs them. Programs would not be developed before they are needed for test or production.

Systems analysts and programmers would not be given information and documents to store until they need them.

Internal information processes would be designed so individuals can move from job to job with minimal delay. For example, programmers should be able to stop working on one program and start another within the JIT ten-minute turnover standard.

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

Assure Completeness of Needs Requirements

This step determines whether you have adequately defined your requirements. Your requirements should be defined in terms of the following two categories of outputs:

1. Output Products and Output Reports -Output products and output reports are specific documents that you want produced by the computer system. In many instances, such as the previous payroll check example, the style and format of these output products is important. This does not mean that the specific location of the check has to be defined but, rather, the categories of information to be included on the check. Computer-produced reports may also be important for tax information (e.g., employee withholding forms sent to governmental units), financial statements where specific statements are wanted (e.g., balance sheets or statements of income and expense), or customer invoice and billing forms which you might want preprinted to include your logo and conditions of payment.

2.Management decision information. This category tries to define the information needed for decision-making purposes. In the computer product/report category you were looking for a document; in this case you are looking for information. How that information is provided is unimportant. Thus, the structure of the document, what the documents are, or their size, frequency, or volume are not significant. All you need is information.

Define Critical Success Factor

This step tells whether the COTS software will be successful in meeting your requirements. Critical success factors (CSFs) are those criteria or factors that must be present in the acquired software for it to be successful. You might ask whether the needs are the same as the critical success factors. They are, but they are not defined in a manner that makes them testable, and they may be incomplete. Often the needs do not take into account some of the intangible criteria that make the difference between success and failure. In other words, the needs define what we are looking for, and the critical success factors tell us how we will evaluate that product after we get it. They are closely related and complementary, but different in scope and purpose.

The following list indicates the needs or requirements for the automobile, and is then followed by the CSFs on which the automobile will be evaluated:

Seats six people

Four doors

Five-year guarantee on motor

Gets 20 miles per gallon or greater

Costs under $12,000

Critical success factors:

Operates at 20.5 cents or less per mile

Experiences no more than one failure per year

Maintains its appearance without showing signs of wear for two years

Some of the more common critical success factors for COTS you may want to use are:

Ease of use - The software is understandable and usable by the average person.

Expandability - The contractor plans to add additional features in the future.

Maintainability - The contractor will provide support/assistance to help utilize the package in the event of problems.

Cost-effectiveness - The software package makes money for your business by reducing costs, and so on.

Transferability - If you change your computer equipment the contractor indicates that they will support new models or hardware.

Reliability - In computer language, the system is friendly, meaning that it will help you get your transactions entered into the system so that you can produce your results readily.

Security - The system has adequate safeguards to protect the data against damage (for example, power failures, operator errors, or other goofs that could cause you to lose your data).

Determine Compatibility with Hardware, Operating System, and Other COTS Software

This is not a complex step. It involves a simple matching between your processing capabilities and limitations, and what the contractor of the software says is necessary to run the software package. The most difficult part of this evaluation is ensuring the multiple software packages can properly interface.

This step is best performed by preparing a checklist defining your compatibility needs. Software contractors are generally good about identifying the needed hardware and operating system compatibility. They are generally not good in identifying compatibility with other software packages.

Quality Council

A Quality Council is composed of the organization’s top executive and his or her direct reports. It may also be referred to as an Executive Council. The Quality Council acts as the steering group to develop the organization’s mission, vision, goals, values, and quality policy. These serve as critical input to process mapping, planning, measurement, etc. Some large companies opt for more than one level of Quality Council. When multiple levels exist, each organization’s mission and vision tie into that specified by the top council.

Management Committees

Management committees (also called Process Management Committees) are composed of middle managers and/or key staff personnel, and are responsible for deploying quality management practices throughout the organization. One or more committees may be needed depending on the organization’s size and functional diversity. Committees should represent all the skills and functions needed to work on the specific processes or activities.

Teams and Work Groups

Teams are formed under any number of names depending on their purpose. Common names and functions are:

Process Development Teams develop processes, standards, etc.

Process Improvement Teams improve existing processes, standards, etc.

Work Groups perform specific tasks such as JAD, inspection, or testing.

The process teams are composed of a representative group of process owners. Members of work groups will vary depending on the purpose, but suppliers and customers are likely to participateas team members or as reviewers. It may also be desirable for a QA analyst to participate on the team.

Process teams use standard approaches (such as flowcharts, checklists, Pareto analysis) to define, study, and improve processes, standards, procedures, and quality control methods. They may pilot new or revised processes help deploy them to the rest of the organization, and provide process training. They may also serve as process consultants to process owners and others using the process. Approaches and tools used by the team depend on its purpose.

Some guidelines for selecting and sequencing change approaches are:

Select approaches that are most acceptable to the culture (poor approaches that are acceptable may be more effective than optimal approaches that are resisted).

Select approaches that have the highest probability of success, first.

Select approaches that will provide both short-term and long-term results. Select an implementation strategy that will use the best people and the best projects, as opposed to trying to improve the poorest projects with the least effective staff.

Implement the prerequisites to the approach before implementing the approach.

Use tools such as risk ranking, analysis, or return on investment.

Risk has five distinguishing characteristics:

Situational

Changes in a situation can result in new risks. Examples include, replacing a team member, undergoing reorganization, or changing a project's scope.

Time-Based

Considering a software development life cycle, the probability of risk occurring at the beginning of the project is very high (due to the unknowns), whereas at the end of the project the probability is very low. In contrast, during the life cycle, the impact (cost) from a risky event occurring is low at the beginning (since not much time and effort have been invested) and higher at the end (as there is more to lose).

Interdependent

Within a project, many tasks and deliverables are intertwined. If one deliverable takes longer to create than expected, other items depending on that deliverable may be affected, and the result could be a domino effect.

Magnitude Dependent

The relationship of probability and impact are not linear, and the magnitude of the risk typically makes a difference. For example, consider the risk of spending $1 for a 50/50 chance to win $5, vs. the risk of spending $1,000 for a 50/50 chance of winning $5,000 vs. the risk of spending $100,000 for a 50/50 chance of winning $500,000. In this example, the probability of loss is all the same (50%) yet the opportunity cost of losing is much greater.

Value-Based

Risk may be affected by personal, corporate or cultural values. For example, completing a project on schedule may be dependent on the time of year and nationalities or religious beliefs of the work team. Projects being developed in international locations where multiple cultures are involved may have a higher risk than those done in one location with a similar work force.

Please see the explanation image for this.

Explanation

Image:

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-13 at 12.40.33 AM.png

Nominal Data

This data can be categorized. For example, a program can be classified as database software, operating system, etc. Nominal data cannot be subjected to arithmetic operations of any type, and the values cannot be ranked in any "natural order." The only possible operation is to determine whether something is the same type as something else. Nominal data can be objective or subjective, depending on the rules for classification.

Ordinal Data

This data can be ranked, but differences or ratios between values are not meaningful. For example, programmer experience level may be measured as low, medium, or high. For ordinal data to be used in an objective measurement the criteria for placement in the various categories must be well defined; otherwise, it is subjective.

Interval Data

This data can be ranked and can exhibit meaningful differences between values. Interval data has no absolute zero, and ratios of values are not necessarily meaningful. For example, a program with a complexity value of 6 is four units more complex than a program with a complexity of 2, but it

Process management is a PDCA cycle. Process management processes provide the framework from within which an organization can implement process management on a daily basis. The following figure shows how this set of practices can be viewed as a continuous improvement cycle.

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