Quality Function Deployment

Introduction

Quality Function Deployment was developed by Yoji Akao in Japan in 1966. By 1972 the power of the approach had been well demonstrated at the Mitsubishi Heavy Industries Kobe Shipyard [1]and in 1978 the first book on the subject was published in Japanese and then later translated into English in 1994. [2]

The QFD methodology can be used for both tangible products and non-tangible services, including manufactured goods, service industry, software products, IT projects, business process development, government, healthcare, environmental initiatives, and many other applications.

What is Quality Function Deployment QFD

Definition

Quality function deployment (QFD) is a “method to transform user demands into design quality, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process.” as described by Dr. Yoji Akao, who originally developed QFD

Moreover, Quality Function Deployment is a systematic approach to design based on a close awareness of customer desires, coupled with the integration of corporate functional groups. It consists in translating customer desires (for example, the ease of writing for a pen) into design characteristics (pen ink viscosity, pressure on ball-point) for each stage of the product development.  [1] [2]

Goals

There are 3 main goals in implementing QFD [1]:

  1. Prioritize spoken and unspoken customer wants and needs.
  2. Translate these needs into technical characteristics and specifications.
  3. Build and deliver a quality product or service by focusing everybody toward customer

Usage of QFD

Since its introduction, Quality Function Deployment has helped to transform the way many companies:

  • Plan new products
  • Design product requirements
  • Determine process characteristics
  • Control the manufacturing process
  • Document already existing product specifications
  • Reduce time to market
  • Reduce product development time by 50%

The Quality Function Deployment Process

  • Identify the Customers
  • Determine Customer Requirements/Constraints
  • Prioritize each requirement
  • Competitive Benchmarking
  • Translate Customer Requirements into Measurable Engineering specifications
  • Set Target values for each Engineering Specification

QFD uses some principles from Concurrent Engineering in that cross-functional teams are involved in all phases of product development.  Each of the four phases in a QFD process uses a matrix to translate customer requirements from initial planning stages through production control.

Each phase, or matrix, represents a specific aspect of the product’s requirements. Relationships between elements are evaluated for each phase.  Only the most important aspects of each phase are deployed into the next matrix [1].

  • Phase 1, Product Planning: mainly it is building the House of Quality. Initiated by the marketing Phase 1 is also called The House of Quality. Many organizations only get through this phase of a QFD process. Phase 1 documents customer requirements, warranty data, competitive opportunities, product measurements, competing for product measures, and the technical ability of the organization to meet each customer requirement. Getting good data from the customer in Phase 1 is critical to the success of the entire QFD process.
  • Phase 2, Product Design: This phase 2 is initiated by the engineering department. Product design requires creativity and innovative team ideas. Product concepts (goals and objectives) are created during this phase and part specifications are documented. Parts that are determined to be most important to meeting customer needs are then deployed into process planning, or the next Phase 3.
  • Phase 3, Process Planning: Process planning comes next and is owned by manufacturing engineering. During process planning, manufacturing processes are flowcharts and process parameters (or target values) are documented.
  • Phase 4, Process Control: And finally, in production planning, performance indicators are created to monitor the production process, maintenance schedules, and skills training for operators. Also, in this phase decisions are made as to which process poses the most risk and controls are put in place to prevent   The quality assurance department in concert with manufacturing leads Phase 4.

picture1

Figure illustrates QFD phases

QFD Tools

The House of Quality

House of Quality is a diagram [3], resembling a house, used for defining the relationship between customer desires and the firm/product capabilities. It is a part of the Quality Function Deployment (QFD) and it utilizes a planning matrix to relate what the customer wants to how a firm (that produces the products) is going to meet those wants.

House of Quality appeared in 1972 in the design of an oil tanker by Mitsubishi Heavy Industries. Akao has reiterated numerous times that a House of Quality is not QFD, it is just an example of one tool.

picture2

Figure illustrates house of quality matrix

Decision-matrix method

Invented by Stuart Pugh the decision-matrix method [4], also Pugh method, Pugh Concept Selection is a quantitative technique used to rank the multi-dimensional options of an option set. It is frequently used in engineering for making design decisions but can also be used to rank investment options, vendor options, product options or any other set of multidimensional entities.

picture3

Figure illustrates Decision matrix

Modular Function Deployment

Modular Function Deployment [5]uses QFD to establish customer requirements and to identify important design requirements with a special emphasis on modularity.

Example of QFD using house of quality

This particular QFD example was created for an imaginary Chocolate Chip Cookie Manufacturer (a.k.a. a “Bakery”). The example maps customer requirements to parts/materials to be purchased in order to meet and/or exceed the customer expectations. (The prioritization comes into play when assuming the limited availability of funds for making purchases.) [6]

The example can be accessible using URL: http://www.qfdonline.com/qfd-tutorials/house-of-quality-qfd-example/

This slideshow requires JavaScript.

Findings of the example:

  • The QFD ends with HOQ #3. This is due primarily to the fact that all of its parts/materials are purchased rather than manufactured. Had a different product been chosen, a 4th HOQ could have been added that mapped parts/materials attribute to processes and/or initiatives for manufacturing the parts that met those specifications.
  • The “Weight” requirement (column #4) in HOQ #1 may not be a valuable requirement. You can tell that this requirement is suspect by the fact that its “Max Relationship Value in Column” is only 1. (Note: the template auto-highlights warning values).
  • The “Weight” requirement (row #4) in HOQ #2 is not being addressed. Similarly, “Tensile Ultimate Strength” (Row #3) and “Size (diameter)” (Row #5) are not being substantially addressed. (Note their “Max Relationship Value in Row” values).
  • HOQ #3 has examples of both of the issues listed in #1 & 2 above.

 

References

[1] Sullivan, 1986.

[2] Mizuno and Akao, 1994.

[3] I. R. Institute, “Quality Function Deployment,” Creative Industries Research Institute.

[4] Wikipedia, “Quality function deployment,” Wikipedia, [Online]. Available: http://en.wikipedia.org/wiki/Quality_function_deployment. [Accessed 7 1 2012].

[5] Wikipedia, “House of Quality,” Wikipedia, [Online]. Available: http://en.wikipedia.org/wiki/House_of_Quality. [Accessed 1 7 2012].

[6] Wikipedia, “Decision matrix method,” Wikipedia, [Online]. Available: http://en.wikipedia.org/wiki/Decision-matrix_method. [Accessed 1 7 2012].

[7] Wikipedia, “Modular Function Deployment,” Wikipedia, [Online]. Available: http://en.wikipedia.org/wiki/Modular_Function_Deployment. [Accessed 1 7 2012].

[8] Q. Online, “House of Quality (QFD) Example,” QFD Online, [Online]. Available: http://www.qfdonline.com/qfd-tutorials/house-of-quality-qfd-example/. [Accessed 4 7 2012].

 

Difference between Software Architecture, Software Structure, and Software Design

Introduction

Over the past 10-15 years, Software architecture has been widely spread in software engineering community, To the extent that there are currently many career positions for software architect like Technical Architect and Chief Architect. Also, Architecture has involved in many different domains, for example, the architecture used to describe and refer to the internal structure of microprocessor and structure of machines or Network. For that matter, Trying to find one widely accepted definition for software architecture is not easy, and this issue has been introduced in many books when the authors start defining software architecture.

“Trying to define a term such as software architecture is always a potentially dangerous activity. There really is no widely accepted definition by the industry.”

(Gorton, 2011)

This post shall highlight the difference between Software Architecture, Software Design and Software Structure and the interrelation between them.

Software Architecture vs. Software Structure

Software architecture

The most widely accepted definition comes from work done in the Software Architecture group of the Software Engineering Institute (SEI) at Carnegie-Mellon University in Pittsburgh.

“The architecture of a software-intensive system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”

(Bass, Clements, & Kazman, 2003)

Software Structure

Software structure may be a little confusing and seems that no difference between it and software architecture, also there is no solid definition for system structure. Software structure has two types, static and dynamic.

“The static structures of a software system define its internal design-time elements and their arrangement”

“The dynamic structures of a software system define its runtime elements and their interactions“

(Bass, Clements, & Kazman, 2003)

The following example of Human Body will illustrate what is meaning of software structure? The Human Body is structuring the body structure, so the neurologist, the orthopedist, the hematologist, and the dermatologist all take a different perspective on the structure of a human body. Ophthalmologists, cardiologists, and podiatrists concentrate on subsystems. And the kinesiologist and psychiatrist are concerned with different aspects of the entire arrangement’s behavior. Although these perspectives are pictured differently and have totally different properties, all are related together, describe the architecture of the human body. (Maya & Merson, 2008)

The same example can be taken from Engineering structure of a simple home. Some structures made for Electric purposes, others for Sanitation purposes and others for Structural purposes. Each one of them represents a different structure for a specific role and specific purpose. All of these structures shall be consistent to create the architecture, and only one of them cannot represent the architecture.

The same is the software, it contains different views for various purposes and stakeholders. Each view is a structure. The developer needs to have a software structure to help him in developing the requirements. The System integrator needs to know the interrelation between components and its properties and behavior. The tester needs to know what are the inputs and expected outputs. The below-quoted paragraph completes the relation between the structures and the architecture.

“None of these structures alone is the architecture, although they all convey architectural information. The architecture consists of these structures as well as many others. This example shows that since architecture can comprise more than one kind of structure, there is more than one kind of element (e.g., implementation unit and processes), more than one kind of interaction among elements (e.g., subdivision and synchronization), and even more than one context (e.g., development time versus runtime). By intention, the definition does not specify what the architectural elements and relationships are.”

(Maya & Merson, 2008)

 

It is worth mentioning that, structures have a more detailed level of information regarding each component, for example, the structure of deployment infrastructure may include many details regarding processing power, storage and shared memory. This detailed information may be not introduced in the level of architecture.

It can be argued that structure is architecture as it describes the elements and component from the perspective of stakeholders, which achieves their goals. So it is architecture from their own perspective.

“If structure is important to achieve your system’s goals, that structure is architectural. But designers of elements, or subsystems, that you assign may have to introduce structure of their own to meet their goals, in which case such structures are architectural: to them but not to you.”

(Clements, et al., 2010)

Software Architecture vs. Software Design

Software Design

The design is used in many fields and has no generally widely accepted definition. However work experience shows that design is making a plan for the software developing activity to accomplish its requirements and its related quality attributes.

Architecture is mainly a design, while not all designs are architecture. This concept has been explained in (Clements, et al., 2010). As the architecture is a set of main design decisions which will affect the software and its quality attributes, while any other design decisions left for downstream developer and designer is a nonarchitectural design, these designs are left because it will not affect the overall decisions that have been taken by the architect to document the software architecture.

For example, in a service-oriented architecture, the architect is interested in defining the main services and component and their connections with each other, while he is not interested in how one of these services will be implemented as this can be left for nonarchitectural design methods and implementations, as defining these interfaces between the components and the data exchanged between them is more important and cannot be left to any element design decision. As software components and its quality depend on these main decisions.

It is worth mentioning that, there is a wrong view by understanding that architecture is focused on high level and conceptual framework, and it is followed by a step of detailed design, also that architecture document shall be limited to number of pages (50 pages) and it is just a small set of only big decisions. Authors of (Clements, et al., 2010) advises the readers to stamp out these thoughts as they are nonsense and asks them to eliminate the terminology of detailed design and using the nonarchitectural design. As Architecture may be detailed or high level based on the global decisions.

To summarize, architecture is design, but not all design is architectural. The architect draws the boundary between architectural and nonarchitectural design by making those decisions that need to be bound in order for the system to meet its development, behavioral, and quality goals. All other decisions can be left to downstream designers and implementers. Decisions are architectural or not, according to context. If structure is important to achieve your system’s goals, that structure is architectural. But designers of elements, or subsystems, that you assign may have to introduce structure of their own to meet their goals, in which case such structures are architectural: to them but not to you.

 

And (repeat after me) we all promise to stop using the phrase “detailed design.” Try “nonarchitectural design” instead.

(Clements, et al., 2010)

This perspective is not similar with the perspective of Author of (Budgen, 2003) who illustrated the design as phase of the software lifecycle after architecture phase and it is interested in the level of deep details and description of system elements.

Architectural design. Concerned with the overall form of solution to be adopted (for example, whether to use a distributed system, what the major elements will be and how they will interact).

 

Detailed design. Developing descriptions of the elements identified in the previous phase, and obviously involving interaction with this. There are also clear feedback loops to earlier phases if the designers are to ensure that the behavior of their solution is to meet the requirements.

(Budgen, 2003)

Conclusion

To sum up, it can be argued that the three terminologies; Software Architecture, Software Design and Software Structure have no widely agreed definition nor a remarkable difference between them. Therefore, they have many perspectives according to their purposes. In my own perspective, software architecture and software design are the same concept, while they are different on the level of details needed to be shared with stakeholders based on the global architectural decisions.

In addition, software structure is set of architecture to characterize a set of actions and component from the perspective view of the software in specific depth. Software architecture is a group of these structures. These structures are organized in a manner to fulfill the software requirements and its quality attributes. Also, the software Structure of specific view is architecture as it describes the elements, its properties, and behavior to meet this specific view goal for the specific stakeholder.

Above all, in order to reach a remarkable difference between the three terminologies, we have to decide which viewpoint we are looking from.

Bibliography

“SEI”, S. E. (2011). Software Engineering Institute. (Carnegie Mellon University) Retrieved 10 7, 2011, from http://www.sei.cmu.edu/architecture/start/definitions.cfm

Bass, L., Clements, P., & Kazman, R. (2003). Software Architecture in Practice (2nd edition). Addison Wesley 2003.

Budgen, D. (2003). SOFTWARE DESIGN (2nd ed.). Addison Wesley.

Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., . . . Stafford, J. (2010). Documenting Software Architectures (2nd Edition). Addison-Wesely.

D. Garlan, M. S. (1993). An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume I. World Scientific. Retrieved from D. Garlan, M. Shaw, An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume I, World Scientific, 1993

Design. (n.d.). Retrieved October 14, 2011, from Wikipedia: http://en.wikipedia.org/wiki/Design

Gorton, I. (2011). Understanding Software Architecture. In I. Gorton, Essential Software Architecture (2nd ed., p. 2). Springer.

Maya, L. D., & Merson, P. (2008). Documentation Roadmap and Overview. Retrieved October 7, 2011, from Software Architecture Document: https://wiki.sei.cmu.edu/sad/index.php/Documentation_Roadmap_and_Overview