deanbrandon.com - Dean Brandon

The Unified Modeling Language (UML) state diagram can describe a lot of things, from computer programs to business processes. State diagrams are used to describe the behavior of a system.  State diagrams describe all of the possible states of an object as events occur.  Each diagram usually represents objects of a single class and track the different states of its objects through the system. The following are the basic notational elements that can be used to make up a diagram:

• Filled circle, pointing to the initial state
• Hollow circle containing a smaller filled circle, indicating the final state (if any)
• Rounded rectangle, denoting a state. Top of the rectangle contains a name of the state. Can contain a horizontal line in the middle, below which the activities that are done in that state are indicated
• Arrow, denoting transition. The name of the event (if any) causing this transition labels the arrow body. A guard expression may be added, enclosed in brackets( [] ) denoting that this expression must be true for the transition to take place. If an action is performed during this transition, it is added to the label following a “/”. eventName[guardExpression]/action
• Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line entering and x>1 lines leaving. These denote join/fork, respectively.

Source: http://en.wikipedia.org/wiki/State_diagram

Tutorial: http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/state.htm

Mean time between failures (MTBF) is the mean (average) time between failures of a system, and is often attributed to the “useful life” of the device. Calculations of MTBF assume that a system is “renewed”, i.e. fixed, after each failure, and then returned to service immediately after failure. The average time between failing and being returned to service is termed mean down time (MDT) or mean time to repair (MTTR).

Source: http://en.wikipedia.org/wiki/MTBF

Tutorial: http://www.evaluationengineering.com/archive/articles/0500analyz.htm

A swim lane (or swimlane) is a type of process flow diagram that depicts what or who is working on a particular subset of a process.

The swim lane flowchart differs from other flowcharts in that processes and decisions are grouped visually by placing them in lanes. Parallel lines divide the chart into lanes, with one lane for each person, group or subprocess. Lanes are arranged either horizontally or vertically, and labeled to show how the chart is organized.

The longitudinal direction represents the sequence of events in the overall process, while the lateral divisions depict what subprocess is performing that step. Arrows between the lanes represent how information or material is passed between the subprocesses.

When used to diagram a business process that involves more than one department, it can clarify not only the steps and who is responsible for each one, but how delays, mistakes or cheating are most likely to occur.

Source: http://en.wikipedia.org/wiki/Swim_lane

Tutorial: http://www.infomanagementcenter.com/enewsletter/200603/fourth.html

The Sarbanes-Oxley Act of 2002 (Pub. L. No. 107-204, 116 Stat. 745), also known as the Public Company Accounting Reform and Investor Protection Act of 2002 and commonly called SOX or Sarbox; is a United States federal law signed into law on July 30, 2002 in response to a number of major corporate and accounting scandals including those affecting Enron, Tyco International, Peregrine Systems and WorldCom. These scandals resulted in a decline of public trust in accounting and reporting practices. Named after sponsors Senator Paul Sarbanes (D-MD) and Representative Michael G. Oxley (R-OH), the Act was approved by the House by a vote of 423-3 and by the Senate 99-0. President George W. Bush signed it into law, stating it included “the most far-reaching reforms of American business practices since the time of Franklin D. Roosevelt.”

The legislation is wide-ranging and establishes new or enhanced standards for all U.S. public company boards, management, and public accounting firms. The Act contains 11 titles, or sections, ranging from additional Corporate Board responsibilities to criminal penalties, and requires the Securities and Exchange Commission (SEC) to implement rulings on requirements to comply with the new law. Supporters of these reforms believe the legislation was necessary and useful while critics believe it does more economic damage than it prevents.

The Act establishes a new quasi-public agency, the Public Company Accounting Oversight Board, or PCAOB, which is charged with overseeing, regulating, inspecting, and disciplining accounting firms in their roles as auditors of public companies. The Act also covers issues such as auditor independence, corporate governance, internal control assessment, and enhanced financial disclosure.

The most contentious aspect of SOX is Section 404, which requires management and the external auditor to report on the adequacy of the company’s internal control over financial reporting (ICFR). This is the most costly aspect of the legislation for companies to implement, as documenting and testing important financial manual and automated controls requires enormous effort.

Both management and the external auditor are responsible for performing their assessment in the context of a top-down risk assessment, which requires management to base both the scope of its assessment and evidence gathered on risk. Both the PCAOB and SEC recently issued guidance on this topic to help alleviate the significant costs of compliance and better focus the assessment on the most critical risk areas.

The recently released Auditing Standard No. 5 of the Public Company Accounting Oversight Board (PCAOB), which superseded Auditing Standard No 2., has the following key requirements for the external auditor:

• Assess both the design and operating effectiveness of selected internal controls related to significant accounts and relevant assertions, in the context of material misstatement risks;
• Understand the flow of transactions, including IT aspects, sufficiently to identify points at which a misstatement could arise;
• Evaluate company-level (entity-level) controls, which correspond to the components of the COSO framework;
  Perform a fraud risk assessment;
• Evaluate controls designed to prevent or detect fraud, including management override of controls;
• Evaluate controls over the period-end financial reporting process;
• Scale the assessment based on the size and complexity of the company;
• Rely on management’s work based on factors such as competency, objectivity, and risk;
• Evaluate controls over the safeguarding of assets; and
• Conclude on the adequacy of internal control over financial reporting.

 Source: http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act

Failure Mode and Effects Analysis (FMEA) is a risk assessment technique for systematically identifying potential failures in a system or a process. It is widely used in the manufacturing industries in various phases of the product life cycle. Failures are any errors or defects, especially ones that affect the customer, and can be potential or actual. Failure modes are characterizations of the ways a product or process can fail. Effects analysis refers to studying the consequences of those failures.

Source: http://en.wikipedia.org/wiki/FMEA

Example FMEA procedure: http://www.asq.org/learn-about-quality/process-analysis-tools/overview/fmea.html

Further information: http://www.fmeainfocentre.com/

Poka-yoke (pronounced “POH-kah YOH-keh”) means “fail-safing” or “mistake-proofing” avoiding (yokeru) inadvertent errors (poka) is a behavior-shaping constraint, or a method of preventing errors by putting limits on how an operation can be performed in order to force the correct completion of the operation. The concept was originated by Shigeo Shingo as part of the Toyota Production System.

Source: http://en.wikipedia.org/wiki/Poka-yoke

Tutorial: http://facultyweb.berry.edu/jgrout//tutorial.html

Capability Maturity Model® Integration (CMMI®) is a process improvement approach that provides organizations with the essential elements of effective processes. [1] The latest release of CMMI — CMMI for Development (CMMI-DEV), Version 1.2 — was released in August 2006. CMMI for Development addresses product and service development processes.

Another release of CMMI — CMMI for Acquisition (CMMI-ACQ), Version 1.2 — will be released in November 2007. CMMI for Acquisition addresses acquisition and outsourcing processes in government and industry.

CMMI for Development Version 1.2 consists of 22 process areas with capability or maturity levels. CMMI was created and is maintained by a team consisting of members from industry, government, and the Software Engineering Institute (SEI) and is available for download from the SEI.

CMMI should be adapted to each individual organization according to its business objectives. Organizations cannot be CMMI “certified.” Instead, an organization is appraised (e.g., using an appraisal method like SCAMPI) and is awarded a 1-5 level rating. The rating results of such an appraisal can be published if released by the appraised organization.

The CMMI v1.2 contains 22 process areas:

Causal Analysis and Resolution
Configuration Management
Decision Analysis and Resolution
Integrated Project Management
Measurement and Analysis
Organizational Innovation and Deployment
Organizational Process Definition
Organizational Process Focus
Organizational Process Performance
Organizational Training
Product Integration
Project Monitoring and Control
CMMI Project Planning
Process and Product Quality Assurance
Quantitative Project Management
Requirements Development
Requirements Management
Risk Management
Supplier Agreement Management
Technical Solution
Validation
Verification

Source: http://en.wikipedia.org/wiki/CMMI

Kaizen is a daily activity whose purpose goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work (both mental and physical) “muri“, and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes.

To be most effective Kaizen must operate with three principles in place:

• consider the process and the results (not results-only);
• systemic thinking of the whole process and not just that immediately in view (i.e. big picture, not solely the narrow view); and
• a learning, non-judgmental, non-blaming (because blaming is wasteful) approach and intent.

People at all levels of an organization participate in kaizen, from the CEO down, as well as external stakeholders when applicable. The format for kaizen can be individual, suggestion system, small group, or large group.

Source: http://en.wikipedia.org/wiki/Continuous_improvement

A use case is a technique used in software and systems engineering to capture the functional requirements of a system. Use cases describe the interaction between a primary actor the initiator of the interaction and the system itself, represented as a sequence of simple steps. Actors are something or someone which exist outside the system under study, and who (or which) take part in a sequence of activities in a dialogue with the system, to achieve some goal: they may be end users, other systems, or hardware devices. Each use case is a complete series of events, from the point of view of the actor.

According to Bittner and Spence:

“Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful.”

Each use case describes how the actor will interact with the system to achieve a specific goal. One or more scenarios may be generated from each use case, corresponding to the detail of each possible way of achieving that goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by systems analysts and end users. The UML use case diagram can be used to graphically represent an overview of the use cases for a given system.

Source: http://en.wikipedia.org/wiki/Use_case

Dean Brandon

Statistical process control is an effective method of monitoring a process through the use of control charts. By collecting data from samples at various points within the process, variations in the process that may affect the quality of the end product or service can be detected and corrected, thus reducing waste and as well as the likelihood that problems will be passed on to the customer. With its emphasis on early detection and prevention of problems, SPC has a distinct advantage over quality methods, such as inspection, that apply resources to detecting and correcting problems in the end product or service.

In addition to reducing waste, SPC can lead to a reduction in the time required to produce the product or service from end to end. This is partially due to a diminished likelihood that the final product will have to be reworked, but it may also result from using SPC data to identify bottlenecks, wait times, and other sources of delays within the process. Process cycle time reductions coupled with improvements in yield have made SPC a valuable tool from both a cost reduction and a customer satisfaction standpoint.

Source: http://en.wikipedia.org/wiki/Statistical_process_control