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

 

Advertisements

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

Choosing the right Software development life cycle model

Featured

Selecting a Software Development Life Cycle (SDLC) methodology is a challenging task for many organizations. What tends to make it challenging is the fact that few organizations know what criteria to use in selecting a methodology to add value to the organization. Fewer still understand that a methodology might apply to more than one Lifecycle Model. Before considering a framework for selecting a given SDLC methodology, we need to define the different types and illustrate the advantages and disadvantages of those models (please see Software Development Life Cycle Models and Methodologies).

How to select the right SDLC

Selecting the right SDLC is a process in itself that organization can implement internally or consult for. There are some steps to get the right selection:

STEP 1: Learn the about SDLC Models

SDLCs are the same in their usage, advantages, and disadvantages. In order to select the right SDLC, one must have experience and be familiar with the SDLCs that will be chosen.

STEP 2: Assess the needs of Stakeholders

We must study the business domain, user requirements, business priorities, and technology constraints to be able to choose the right SDLC against their selection criteria.

STEP 3: Define the criteria

Some of the selection criteria or questions that you may use to select an SDLC are:

  • Is the SDLC appropriate for the size of our team and their skills?
  • Is the SDLC appropriate with the selected technology we use for implementing the solution?
  • Is the SDLC appropriate with client and stakeholders need and priorities
  • Is the SDLC appropriate for the geographical situation (co-located or geographically dispersed)?
  • Is the SDLC appropriate for the size and complexity of our software?
  • Is the SDLC appropriate for the type of projects we do?
  • Is the SDLC appropriate for our engineering capability?

What are the criteria?

Here is my recommended criteria, what will be yours?

Factors Waterfall V-Shaped Evolutionary Prototyping Spiral Iterative and Incremental Agile Methodologies
Unclear User Requirement Poor Poor Good Excellent Good Excellent
Unfamiliar Technology Poor Poor Excellent Excellent Good Poor
Complex System Good Good Excellent Excellent Good Poor
Reliable system Good Good Poor Excellent Good Good
Short Time Schedule Poor Poor Good Poor Excellent Excellent
Strong Project Management Excellent Excellent Excellent Excellent Excellent Excellent
Cost limitation Poor Poor Poor Poor Excellent Excellent
Visibility of Stakeholders Good Good Excellent Excellent Good Excellent
Skills limitation Good Good Poor Poor Good Poor
Documentations Excellent Excellent Good Good Excellent Poor
Component reusability Excellent Excellent Poor Poor Excellent Poor

References

Selecting a Software Development Life Cycle (SDLC) Methodology.(2012, 3 18). Retrieved from http://www.smc-i.com/downloads/sdlc_methodology.pdf

Software Development Life Cycle Models. (2012, 3). Retrieved from Codebetter.com: http://codebetter.com/raymondlewallen/2005/07/13/software-development-life-cycle-models/

Software security testing in SDLC?

When to perform Software security analysis and tests?

Most of software security practitioners would agree that the common practice of postponing security analysis and tests after the software implementation phase and even after it has been deployed (i.e., during its acceptance phase), makes it extremely difficult to address in a cost-effective, timely manner any vulnerabilities and weaknesses discovered during the analysis and testing process.

Figure [1] illustrates the relation between cost and time in security testing process which may be doubled or tripled due to lack of this testing coverage during its proper time.

image image

Figure [1][i] Security testing cost vs. time – cost of fixing software bugs

Source: OSSTMM – Open Source Security Testing Methodology Manual

So, Security testing involves in software developing life cycle to ensure the implementation of security requirements. It is worth mentioning that Security testing is not a phase only in SDLC but it involves also in many system components and processes as illustrated in figure [2] below.

image

Figure [2]Security in system components

Source: OSSTMM – Open Source Security Testing Methodology Manual

So, each component of the system has different methodologies and techniques to assure the security, while our focus here on software development life cycle. The Figure [3] and Figure[4] below illustrate the security testing existence at SDLC

image

Figure [3] Describes each of the formal methods activities in the diagram, indicating the SDLC phases to which each activity pertains

Source: Information Assurance Technology Analysis Center (IATAC)

image

Figure [4] Security testing in SDLC – 7 touchpoints

[ii]Figure [4] illustrates the software security touchpoints (a set of best practices) and shows how software practitioners can apply the touchpoints to the various software artifacts produced during software development.

These best practices first appeared as a set in 2004 in IEEE Security & Privacy magazine. Since then, they have been adopted (and in some cases adapted) by the U.S. government in the National Cyber Security Task Force report, by Cigital, by the U.S. Department of Homeland Security, and by Ernst and Young.

So here in table [1] a range of security reviews, analysis, and tests can be mapped to the different software life cycle phases starting with the requirements phase:

Life Cycle Phase Reviews/tests
Requirements Security review of requirements and abuse/misuse cases
Architecture/Product Design Architectural risk analysis (including external reviews)
Detailed Design Security review of the design. Development of test plans, including security tests.
Coding/Unit Testing Code review (static and dynamic analysis), white box testing
Assembly/Integration Testing Black box testing (fault injection, fuzz testing)
System Testing Black box testing, vulnerability scanning
Distribution/Deployment Penetration testing (by software testing expert), vulnerability scanning, impact analysis of patches
Maintenance/support (Feedback loop into previous phases), impact analysis of patches and updates
Security testing in software test plan

The security test plan should be included in the overall software test plan, and should define:

  1. Security test cases or scenarios (based on misuse and abuse cases)
  2. Test data, including attack patterns
  3. Test oracle
  4. Test tools (white box and black box, static and dynamic)
  5. Analysis to be performed to interpret, correlate, and synthesize the results from the various tests and outputs from the various tools.

The security test plan should acknowledge that the security assumptions that were valid when the software’s requirements were specified; will probably have changed by the time the software is deployed. The threat environment in which the software will actually operate is unlikely to have remained static. New threats and attack patterns are continually emerging. Also, emerging has new versions of non-developmental components and patches to those components. All these changes have the potential to invalidate at least some of the security assumptions under which the original requirements were specified.


[i] http://www.agitar.com/solutions/why_unit_testing.html

[ii] http://www.swsec.com/resources/touchpoints/

What is Software security testing?

Secure Software

In Software industry, Most of clients have a main requirement which is “we want the system to be secured”. Security is a non functional property of system, the main goal for securing the system to make this system dependable. So, we can depend on this system and it can perform its excepted functions as required and specified.

Therefore, it is mandatory to run the security testing procedures to insure that we can depend on this system, but we need also to consider some functional requirements on writing requirements specifications document that helps to obtain this goal.

Definition of Security testing

“Security testing is a process to determine that an information system protects data and maintains functionality as intended” Wikipedia

We can summarize that we need security testing on the following:

  1. Information and access security. Security tests help to find out loopholes that can cause loss of important information or allow intruder into the systems.
  2. System stability and availability. Security testing helps to improve the system and finally helps it to work for longer time (or it will work without hassles for the estimated time).
  3. System integrity. If involved on the early stages of development life cycle, security testing allows eliminating possible flaws in system design and implementation. We need to consider security aspects in architecture phase.
  4. Economic efficiency. It’s much cheaper to prevent the possible problem rather than to strive for resolving it and its consequences.

The main objective of software security analysis and testing is the verification that the software exhibits the following properties and behaviors:

  1. Its behavior is predictable and secure.
  2. It exposes no vulnerabilities or weaknesses (ideally it contains no vulnerabilities or weaknesses, exposed or not).
  3. Its error and exception handling routines enable it to maintain a secure state when confronted by attack patterns or intentional faults.
  4. It satisfies all of its specified and implicit nonfunctional security requirements.
  5. It does not violate any specified security constraints.
  6. As much of its runtime-interpretable source code and byte code as possible has been obscured or obfuscated to deter reverse engineering.

Software Security testing

What did they say about Software security testing?

“Over 70 percent of security vulnerabilities exist at the application layer, not the network layer” Gartner.

Hacking has moved from a hobbyist pursuit with a goal of notoriety to a criminal pursuit with a goal of money” Counterpane Internet Security.

“64 percent of developers are not confident in their ability to write secure applications” Microsoft Developer Research.

“Losses arising from vulnerable web applications are significant and expensive – up to $60 billion annually”IDC/IBM Systems Sciences Institute.

“If 50 percent of software vulnerabilities were removed prior to production use, enterprise configuration management and incident response costs would be reduced by 75 percent each.”Gartner.

General Statistics

The figures below illustrate that lake of software security allows data breaches. These breaches have been categorized by sector, this has been illustrated in figure [1] and figure [2].

clip_image001

Figure (1) Data breaches that could lead to identity theft and identities exposed, by sector
Source: Based on data provided by OSF DataLossDB (due to rounding, percentages may not total 100 percent)

clip_image002

Figure (2) Average number of identities exposed per data breach, by notable sector
Source: Based on data provided by OSF DataLossDB

The figures below illustrate that lake of software security allows data breaches. At these figures, these breaches have been categories by cause.

clip_image003

Figure (3) Data breaches that could lead to identity theft and identities exposed, by cause
Source: Based on data provided by OSF DataLossDB (due to rounding, percentages may not total 100 percent)

clip_image004

Figure (4) Average number of identities exposed per data breach, by cause
Source: Based on data provided by OSF DataLossDB

Below figure illustrates type of information exposed in deliberate breaches.

clip_image005

Figure (5) Type of information exposed in deliberate breaches
Source: Based on data provided by OSF DataLossDB (due to rounding, percentages may not total 100 percent)

The Impact of unsecured application

The impact of unsecured software application can vary from organization to another based on importance of the system and its related data as following:

The potential impact is LOW if:

The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, assets, or individuals.

The potential impact is MODERATE if:

The loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, assets, or individuals.

The potential impact is HIGH if:

The loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, assets, or individuals.

Types of application need to have security testing

  • Web-applications
  • Applications with sensitive commercial or personal information
  • Payment and statistic systems
  • Applications, sensitive to data distortion
  • Social applications
  • Applications with expensive licensing

The need for security testing

It is important to recognize that there are three key quality components to software assurance as shown in Figure [6]; reliability, resiliency, and recoverability.

  • Reliable software is that which functions as needed by the end user.
  • Resilient software is that which is able to withstand the attempts of an attacker to compromise confidentiality, and/or impact integrity, or availability (CIA).
  • Recoverable software is software that is capable of restoring itself or being restored to expected normal operations when it has failed in its reliability or resiliency.

clip_image006

Figure (6) [i] Software Quality component

Most commonly, when software is said to be of “quality”, it essentially means that the software is working as designed and expected. This is primarily a consideration of software functionality and not its assurance capabilities. However the reliability aspect of software quality today, it is also imperative to take into account the security of the software. This two-pronged approach to software quality testing ensures that software is not only reliable but resilient to withstand attacks that impact CIA.

Therefore, Security testing is necessary because it has a distinct relationship with software quality. The software may meet quality requirements related to the functionality and performance, but it does not necessary mean that this software is secure. The inverse, however, is true.

So, software called secure when it is software with added resiliency, thus software of higher quality, for example, when the “Add to cart” button on a web page is clicked and the selected product is added to the cart (functionality) in less than the expected two-second requirement (performance). It can be urged that this software met the reliability quality requirements as established by the business, but if the software is not tested for security, there is no guarantee that the product code that is added to the cart has not been tampered by an unauthorized user.

Moreover, poor architecture and implementation of the web application cannot assure the CIA aspect of software assurance.

This was an introduction for software security testing; I will add more posts to illustrate more about the definition of Security testing, its relation with the software developing life cycle, and its techniques.

References


[i]Assuring Software security through testing, White, Black and Somewhere in between by Mano Paul https://www.isc2.org/uploadedFiles/(ISC)2_Public_Content/Certification_Programs/CSSLP/Software%20Security%20Through%20Testing.pdf