Goals
- Obtain an overview of intent, purpose and quality requirements of the system.
- Develop and document an understanding of internal structures, concepts and architectural approaches.
- Find all problems, issues, symptoms, risks or technical debt within the system, its operation, maintenance or otherwise related processes.
- Understand root causes of the problems found, and potential interdependencies between issues.
How it works
Look systematically for such issues at various places and with support of various people.
Tip: To effectively find issues, you need an appropriate amount of understanding of the system under design, its technical concepts, code structure, inner workings, major external interfaces and its development process.
One serious risk in this phase is a premature restriction to certain artifacts or aspects of the system: if you search with a microscope, you’re likely to miss several aspects.
Always begin with a Stakeholder Analysis, then conduct Stakeholder Interviews with important stakeholders.
Improve your architectural understanding of the system by
- context analysis,
- documentation analysis — read especially the architecture documentation, focus on view-based understanding,
- development-process analysis,
- static code analysis, to learn about code structure in the large; this also helps to identify risky code.
Then
- capture quality requirements from the authoritative stakeholders of the system,
- conduct a qualitative analysis of the system, its architecture and the associated organization, based upon the specific quality requirements — inspect and analyze all involved organizational processes (development, project management, operations, requirements analysis),
- perform runtime analysis or quantitative analysis, e.g. performance and load monitoring, process and thread analysis — inspect the data created, modified and queried by the system for structure, size, volume or specialities.
Finally, conduct a root cause analysis for the discovered major issues in close collaboration with the appropriate stakeholders.
Warning: Never start solving problems until you have a thorough understanding of the current stakeholder requirements. Otherwise you risk wasting effort in areas which no influential stakeholder cares about.
Patterns and practices for analysis
-
Apply the ATAM method to evaluate the software architecture regarding its compliance with quality goals.
-
Improve the structure of a system or its documentation so that the organisation is not at risk if certain key people leave.
-
Make the specific quality requirements of a system explicit.
-
Analyse external interfaces for risk, technology, business value and other factors.
-
Analyze and inspect the data created and manipulated by the system for its content, structure, quantity and size.
-
Identify the source of an error (bug) or misbehavior by observing the flow of execution of a program in detail.
-
Analyse and inspect the development process (as documented or described by stakeholders) for appropriateness, problems or problem-areas.
-
Analyse existing documentation for availability, correctness, actuality, problems or problem-areas.
-
Decompose the overall goal of “high quality” into more detailed and precise requirements, finally resulting in a tree-like structure. See ATAM and [Quality-Requirements].
-
Analyze the technical infrastructure of the system, e.g. with respect to time and resource consumption or creation. Part of Runtime Analysis.
-
Find out how the system is really used and what the runtime relationships are, as well as other facts that can not be easily determined by Static Code Analysis even in situation where the system under design is largely undocumented and the architecture work thus mostly relies on assumptions, interviews and lore.
-
Analyse entries from issue tracker to identify critical areas, components or stakeholders.
-
Analyse and inspect organization(s) responsible for the system.
-
Prior to interviewing stakeholders, present them with a written questionnaire, so they can reflect in advance.
-
Identify issues that could let become the current project a huge disaster.
-
Analyze which quality goals of the system are at risk and which are met by the current implementation.
-
Measure artifacts or processes within the system, e.g. source code.
-
Support interviews with guidance and hints for appropriate questions.
-
Analyze and document (current) requirements: required features and required constraints
-
Explicitly differentiate between symptom and cause: identify root causes of symptoms, problems or issues.
-
Analyze the runtime behavior of the system, e.g. with respect to time and resource consumption or creation.
-
Runtime Artifact Analysis stub
Artifacts that were created by a running system are a gold mine. They allow you to get a deeper understanding of the inner workings of a software system. Use log management, aggregators and monitoring tools to gather log files. Then analyze usage patterns, stack traces or errors to see what the system is really doing.
-
Evaluate and track the welfare and health of a software development and operation organization or community such that additional project cost can be avoided or somehow managed.
-
Understand software by examining existing source code.
-
Ensure that all concerned parties are addressed.
-
Learn from the people who know or care about the system and everything around it.
-
Analyse source code to identify building blocks and their dependencies, determine complexity, coupling, cohesion and other structural properties.
-
Structural Analysis stub
Analyze the static structures (e.g. building block structure) of the system, e.g. package or module dependencies, runtime- and/or deployment dependencies. See the more specific Static Code Analysis, Context Analysis and Data Analysis.
-
Take What They Mean, Not What They Say
Find out the real meaning/intention of stakeholders
-
Use Case Cluster stub
Understand system functionality by grouping functionality into clusters to reduce complexity.
-
Get an overview of user categories or groups, their goals, requirements and expectations. Find out about issues users have with the system.
-
Understand the inner workings and internal (code) structure of of the systems. Document (and communicate) this via architectural views, especially the building-block view.