Part of the software architect’s job and next CPSA topic is defining what the quality is and easing providing the quality in the project. It’s important to ensure touch the topic of quality on the beginning because different projects and stakeholders can have different requirements regarding quality. In most project, people have implicit assumptions regarding quality, but when we ask about it we have so many answers as responders. It’s crucial to have this formally specified right on the beginning.
What is quality?
Quality mostly is more than a single property or attribute. Quality is a generic term and need to be specified by using more detailed way. It is a set of desired, required or given properties of the system for example response times, performance, portability, ease of usage etc.
To standardize the approach to quality, some experts defined a quality model. It’s a collection of attributes that software systems might have or need to have.
When talking about the quality characteristics, we have to remember that many of them are conflicting to each other. Some of them make another difficult to reach, that’s why I would say, that defining quality aspects is the art of trade-offs.
Quality scenarios
The best way to define the quality are quality scenarios. It’s something like user story but not in the same form, but also describes the situation and the concrete requirement.
Examples:
- the system have to be available 24/7 (99,9% of time)
- agreement have to be generated under 1 minute
- Credit decision have to be made automatically within 5 minutes
The pattern for writing such scenarios should contain the following information:
- event
- response
- system
- Metric (response measure)
We have 3 types of scenarios:
- usage scenarios
- change scenarios
- failure scenarios
We can also define our quality scenarios in form of tree. See more about quality trees here.
Qualitative analysis
ATAM is one of the commonly known way for qualitative analysis of software architecture.
Evaluation of this process in a simplified way consists of the following steps:
- creating clear quality requirements, for instance using quality scenarios or trees,
- identify architectural approaches to support chosen quality requirements,
- Compare the approaches and identify risk or problems with respect to specific quality requirements,
The process of qualitative analysis delivers the following results:
- Quality requirements
- Risks
- Non-risks
- Trade-offs
- Sensitivity points
Artifacts useful in qualitative analysis:
- Quality requirements
- Architecture documentation
- Architecture and design model
- Source code
- Metrics
- Other documentation
- Stakeholder interviews
To make a qualitative analysis we should involve in this process other stakeholders such as evaluators, product owners, architects, developers and optionally operations hardware engineers, QAs, support and users.
Quantitative analysis
Quantitative analysis maps certain elements or aspects of a system to numbers. Things that we might want to measure are for instance coupling, cyclomatic complexity, lines of code, coverage, or violation count but also less technical like bugs per component, effort needed to fix bug in component, developer sympathy per component etc.
Summary
As we can see, the quality is not only the coverage and clean code but much more. To define this “much more” we have a set of tools and processes we can use. It’s important to make such analysis as early as possible to avoid redefining requirements, redesigning architecture and rebuilding the system.
That’s all or today. It seems to be the last topic relevant for the CPSA-F examination. So now I take my time to refresh the knowledge, do some example tests and try to pass it.