What is assessment
Assessment is the process of understanding a given situation around an existing system to support decision making.
Tudor Girba
What does that mean? What kind of decisions? Here are some examples of assessment problems encountered during software development.
Engineers and architects might need to answer questions such as:
- Are all calls to the server interface error handled on the client side?
- Which dependencies violate the desired architecture?
- Where is this component used in the system?
- From where in the code is a certain database table accessed?
- Which entities from the domain model are not annotated with a certain meta-data?
Managers might battle with problems like:
- Is the current system good enough to build the next release on, should it be refactored, or should it be replaced?
- How much does it cost to migrate a system to a new technology?
- How difficult is it to replace a part of the business logic with another one?
All these questions look at various aspects of software systems. They require answers so that the responsible people can make decisions.
Assessment vs. reverse engineering
The definition of assessment is similar to the one of reverse engineering, yet it is significantly different:
Reverse engineering is the process of analyzing a subject system to create representations of the system at a higher level of abstraction.
Chickofsky & Cross
They are both processes, but the main difference is given by the goal. Essentially, the artifacts that result from reverse engineering are high level views that do away with details. In other words, reverse engineering is concerned with the technicality of producing the views.
The end goal of assessment is decision making. If an assessment does not lead to a decision it is not useful. To get to decisions we do need the summaries provided by the high level views because we cannot deal with all the details of the system by ourselves. But, the views alone are not enough. We need to take the extra step of interpreting them. Reverse engineering is an integral part of the overall assessment process.
The second difference stems from the input to the process. In reverse engineering, we talk about a system. In assessment we talk about a situation. While a system is well defined, a situation can be vaguer. Why should we allow for this? Because humans are not machines. While it is great to deal with clear-bounded systems, in reality we most often cannot define the situations we encounter with outmost exactness.
Reverse engineering has been a concern for a long time. It was and still is a challenging task, and it managed to capture our imagination and efforts for several decades. Some great tools and approaches came out of all this effort.
But, that is not enough. It turns out that all this good work is rendered almost useless when facing fuzzy and contextual real-world problems. If we want a real impact we have to go the extra mile and leave the beauty of clearcut systems. We have to accept the inconvenient untidiness of reality.
In summary, due to our human nature we need both contextual information to make appropriate decisions, and tools that help us deal with the size of data. Hence, we need a humane method: humane assessment.
Assessment vs. quality assurance
Another related set of concepts is formed by the family of issues around software quality and software quality assurance (or more formally known as software quality management). Quality assurance is concerned with managing the quality of a system.
The concern of quality assurance is to answer the question: does the system have a good quality or not. The answer is typically either yes or no. In contrast, assessment is a process that takes a step further and looks to find the path to action. Quality can be a goal, but the end result should also reveal how to get there. Thus, quality assurance is a subprocess of assessment.