Is your CMMI adoption ensuring product/application quality?

With IT systems/applications becoming more and more complex and larger, the quality of the underlying software is essential for business success. The critical nature of software systems and also user expectations has increased enormously and become a significant success factor. With increasing demands of web & cloud applications, companies are facing major challenges in fulfilling various aspects of product quality (quality attributes e.g. portability, compatibility, performance, flexibility, security etc.), which has evolved exponentially.

Following are the key expectations of a user:

  • Interactive customer software should cater to high needs of usability and co-existence (interoperability)
  • Internet and open source systems should cater to high needs of security and interoperability
  • Mission critical systems should cater to high needs of functional correctness and reliability.

The fundamental aspect of quality differs to each stakeholder as,

  • Software systems/application have many stakeholders including those who develop, acquire, use, or who are customers of businesses using these systems/application. (Refer Software Quality Requirements and Evaluation SQuaRE, defines systems’ quality as “the degree to which the system satisfies the stated and implied needs of its various stakeholders.)
  • Product specifications and quality in use of software systems/application is a key factor in ensuring value to stakeholders

CMMI ® defines Quality attribute as “a property of a product or service by which its quality will be judged by relevant stakeholders

 Quality attributes can be characterized by some appropriate measure. Quality attributes are non-functional, such as timeliness, throughput, responsiveness, security, modifiability, reliability, and usability. They have a significant influence on the architecture.

Software quality attributes are the most neglected category of overall project scope on software projects, and finally result in system failure in terms of delivering the stakeholder value

During various client engagements, I observed the following typical challenges:

  1. Inadequate requirements elicitation – During requirements gathering sessions, most focus was given in collecting and understanding functional requirements only. Though SRS template has a section for non functional requirement, it was not populated in some projects.  In some cases, nonfunctional requirements are collected at qualitative level. For e.g. we expect web portal to respond fast. This was not elicited further to understand what is fast? (6 sec, 6-mili sec, 6-micro sec etc.)  This was not caught either in SME review or PPQA audit.
  2. Lack of Business Analysis skills – BA (business analyst) was not aware of non-functional requirements, as there was lack of domain skills and experience.
  3. Difficult to implement & test – though some project teams are aware about non-functional requirements but it was difficult to implement and even test them.
  4. 4. Lack of acceptance criteria – customers with assumption that everybody knows and it is common sense do often not specify quality attributes.

Organizations, which have adopted CMMI model, and sustained best practices, have greater chance to avoid such challenges and successfully deliver systems/applications according expectations of relevant stakeholders. Refer following table showing CMMI Process areas (specifically engineering PAs) and corresponding specific practices and sub practices ensure consideration of quality attributes.

 

CMMI PA

Specific Practice

Sub-Practice (sub practice Number)

REQM SP 1.1 Understand Requirements

 

2. Establish objective criteria for the evaluation and acceptance of requirements.

Examples of evaluation and acceptance criteria include the following:

·  Consistent with architectural approach and quality attribute priorities

RD SP1.1 Elicit Needs Examples of techniques to elicit needs include the following:

·  Quality attribute elicitation workshops with stakeholders


SP 1.2 Transform Stakeholder Needs into Customer Requirements 3. Establish and maintain a prioritization of customer functional and quality attribute requirements.

·  Having prioritized customer requirements helps to determine project, iteration, or increment scope. This prioritization ensures that functional and quality attribute requirements critical to the customer and other stakeholders are addressed quickly.

SP 2.1 Establish Product and Product Component Requirements 4. Develop architectural requirements capturing critical quality attributes and quality attribute measures necessary for establishing the product architecture and design.

·  Examples of quality attribute measures include the following:

o   Respond within 1 second

o   System is available 99% of the time

o   Implement a change with no more than one staff week of effort

SP 3.1 Establish Operational Concepts and Scenarios 1. Develop operational concepts and scenarios that include operations, installation, development, maintenance, support, and disposal as appropriate.

·  Identify and develop scenarios, consistent with the level of detail in the stakeholder needs, expectations, and constraints in which the proposed product or product component is expected to operate. 
Augment scenarios with quality attribute considerations for the functions (or other logical entities) described in the scenario.


SP 3.2 Establish a Definition of Required Functionality and Quality Attributes 2. Identify desirable functionality and quality attributes.

·  Functionality and quality attributes can be identified and defined through an analysis of various scenarios with relevant stakeholders as described in the previous specific practice.

3. Determine architecturally significant quality attributes based on key mission and business drivers.

6. Partition requirements into groups, based on established criteria (e.g., similar functionality, similar quality attribute requirements, coupling), to facilitate and focus the requirements analysis.

SP 3.3 Analyze Requirements

 

Analyze requirements to ensure that they are necessary and sufficient.

·  As requirements are defined, their relationship to higher-level requirements and the higher-level definition of required functionality and quality attributes should be understood.

SP 3.4 Analyze Requirements to Achieve Balance

 

2. Perform a risk assessment on the requirements and definition of required functionality and quality attributes.

4. Assess the impact of the architecturally significant quality attribute requirements on the product and product development costs and risks.

TS SP 1.1 Develop Alternative Solutions and Selection Criteria

 

·  Alternative solutions should be identified and analyzed to enable the selection of a balanced solution across the life of the product in terms of cost, schedule, performance, and risk. These solutions are based on proposed product architectures that address critical product quality attribute requirements and span a design space of feasible solutions.

o   Achievement of key quality attribute requirements, such as product timeliness, safety, reliability, and maintainability

3.  Identify candidate COTS products that satisfy the requirements.

The supplier of the COTS product will need to meet requirements that include the following:

·  Product functionality and quality attributes

SP 1.2 Select Product Component Solutions

 

4. Establish the functional and quality attribute requirements associated with the selected set of alternatives as the set of allocated requirements to those product components.
SP 2.1 Design the Product or Product Component 1 Establish and maintain criteria against which the design can be evaluated.

·  Examples of quality attributes, in addition to expected product performance, for which design criteria can be established, include the following: Modular Clear Simple Maintainable Verifiable Portable Reliable Accurate Secure Scalable Usable

SP 2.2 Establish a Technical Data Package ·  It includes all applicable technical data such as drawings, associated lists, specifications, design descriptions, design databases, standards, quality attribute requirements, quality assurance provisions, and packaging details.

What about your CMMI Implementation? Are these above practices helping you? Let me know your experience.

 

-Kiran Chaudhari

 

Leave a Reply

Your email address will not be published. Required fields are marked *