<commit_before>[[Analyze]]

== Analyze

image::analyze.jpg["analyze-phase", title="Analyze-Phase"]

=== Goals

. Obtain overview of intent, purpose and quality requirements of the system (<<SuD>>).

. Develop and document an understanding of internal structures, concepts and architectural approaches.

. Find all problems, issues, symptoms, risks or technical debt within the system (<<SuD>>), its operation, maintenance or otherwise related processes.

. Understand root causes of the problems found, potential interdependencies between issues


=== How it works

Systematically look for such issues at various places and with various people.

TIP: To effectively find issues, you need an appropriate amount of _understanding_ of the system under design (<<SuD>>), its technical concepts, code-structure, inner workings, major external interfaces and its development process.


. Start <<Capture-Quality-Requirements, capturing current quality requirements>> from the _authoritative_ stakeholders of the systems.
. Conduct a <<Qualitative-Analysis, qualitative analysis>> of the system, its architecture and surrounding organization, based upon the specific quality requirements 
. Perform <<Static-Code-Analysis, static code analysis>>
. Conduct <<Stakeholder-Interview, stakeholder interviews>>
. Perform a number of *runtime 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
. Inspect and analyze all involved organizational processes
(development, project-management, operations, requirements-analysis)   


WARNING: Never start solving problems until you have a thourough understanding of current stakeholder requirements. Otherwise you risk wasting effort in areas that no influential stakeholder cares about.




=== Patterns and Practices for Analysis
(given in alphabetical order)

* Architecture Analysis, see <<Qualitative-Analysis>> and <<ATAM>>.
* <<Architecture-Documentation>>
* <<ATAM>>
* <<Capture-Quality-Requirements>>
* <<Context-Analysis>>
* <<Data-Analysis>>
* <<Debugging>>
* <<Development-Process-Analysis>>
* <<Documentation-Analysis>>
* <<Instrument-System>>
* <<Issue-Tracker-Analysis>>
* <<Profiling>>
* <<Qualitative-Analysis>>
* <<Quantitative-Analysis>>
* <<Questionnaire>>, especially <<Pre-Interview-Questionnaire>>
* <<Requirements-Analysis>>
* <<Root-Cause-Analysis>> - finding the root cause of problems
* <<Runtime-Artifact-Analysis>> 
* <<Separate-Cause-From-Effect>>
* <<Software-Archeology>>
* <<Stakeholder-Analysis>>
* <<Stakeholder-Interview>>, see also <<Pre-Interview-Questionnaire>>.
* <<Static-Code-Analysis>> (Structural analysis)
* <<Structural-Analysis>>
* <<Take-What-They-Mean>> (not what they say, as it may differ).
* <<Use-Case-Cluster>>
* <<View-Based-Understanding>><commit_msg>applied new style to pattern names (just in analyze.adoc)<commit_after>:linkattrs:

[[Analyze]]

== Analyze

image::analyze.jpg["analyze-phase", title="Analyze-Phase"]

=== Goals

. Obtain overview of intent, purpose and quality requirements of the system (<<SuD>>).

. Develop and document an understanding of internal structures, concepts and architectural approaches.

. Find all problems, issues, symptoms, risks or technical debt within the system (<<SuD>>), its operation, maintenance or otherwise related processes.

. Understand root causes of the problems found, potential interdependencies between issues


=== How it works

Systematically look for such issues at various places and with various people.

TIP: To effectively find issues, you need an appropriate amount of _understanding_ of the system under design (<<SuD>>), its technical concepts, code-structure, inner workings, major external interfaces and its development process.


. Start <<Capture-Quality-Requirements, capturing current quality requirements>> from the _authoritative_ stakeholders of the systems.
. Conduct a [pattern]#<<Qualitative-Analysis, qualitative analysis>># of the system,
its architecture and surrounding organization, based upon the specific quality requirements
. Perform [pattern]#<<Static-Code-Analysis, static code analysis>>#
. Conduct [pattern]#<<Stakeholder-Interview, stakeholder interviews>>#
. Perform a number of *[pattern]#runtime 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
. Inspect and analyze all involved organizational processes
(development, project-management, operations, requirements-analysis)


WARNING: Never start solving problems until you have a thourough understanding of current stakeholder requirements. Otherwise you risk wasting effort in areas that no influential stakeholder cares about.




=== Patterns and Practices for Analysis
(given in alphabetical order)

* Architecture Analysis, see [pattern]#<<Qualitative-Analysis>># and
[pattern]#<<ATAM>>#.
* [pattern]#<<Architecture-Documentation>>#
* [pattern]#<<ATAM>>#
* [pattern]#<<Capture-Quality-Requirements>>#
* [pattern]#<<Context-Analysis>>#
* [pattern]#<<Data-Analysis>>#
* [pattern]#<<Debugging>>#
* [pattern]#<<Development-Process-Analysis>>#
* [pattern]#<<Documentation-Analysis>>#
* [pattern]#<<Instrument-System>>#
* [pattern]#<<Issue-Tracker-Analysis>>#
* [pattern]#<<Profiling>>#
* [pattern]#<<Qualitative-Analysis>>#
* [pattern]#<<Quantitative-Analysis>>#
* [pattern]#<<Questionnaire>>#, especially [pattern]#<<Pre-Interview-Questionnaire>>#
* [pattern]#<<Requirements-Analysis>>#
* [pattern]#<<Root-Cause-Analysis>># - finding the root cause of problems
* [pattern]#<<Runtime-Artifact-Analysis>>#
* [pattern]#<<Separate-Cause-From-Effect>>
* [pattern]#<<Software-Archeology>>#
* [pattern]#<<Stakeholder-Analysis>>#
* [pattern]#<<Stakeholder-Interview>>#, see also [pattern]#<<Pre-Interview-Questionnaire>>#.
* [pattern]#<<Static-Code-Analysis>># (Structural analysis)
* [pattern]#<<Structural-Analysis>>#
* [pattern]#<<Take-What-They-Mean>># (not what they say, as it may differ).
* [pattern]#<<Use-Case-Cluster>>#
* [pattern]#<<View-Based-Understanding>>#
{'fraction_non_alphanumeric': 0.12935645971794457, 'fraction_numerical': 0.0, 'mean_word_length': 6.250293772032903, 'pattern_counts': {'":': 0, '<': 151, '<?xml version=': 0, '>': 151, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4799952', 'n_tokens_mistral': 1676, 'n_tokens_neox': 1601, 'n_words': 566}