Curriculum for

Certified Professional for
Software Architecture (CPSA)^®
Advanced Level:
Module
IMPROVE

Evolution and Improvement of Software Architectures

Extending and changing features

Change in quality requirements and goals

Changes in technical or business context (e. g., change in external interfaces)

Bug fixing

Changes in organisation (e. g., changes of legal conditions or requirements; organisational structure of business units, development or operations)

Reduce of costs or efforts, especially with respect to:

Costs or efforts of development

Costs or efforts of operations

Costs of bug fixing and consequential damage

Costs of involved processes

Opportunity costs

Intrinsic motivation of stakeholders, especially software developers and architects.

Update of applied technology such as operating systems, middleware, libraries, frameworks, hardware or similar.

Conceptual weaknesses, e. g., violation of conceptual integrity, redundancy, use of inappropriate technology, incorrect use of technology.

Structural problems in data or data structures.

Structural problems in source code, such as:

Missing or inadequate modularisation,

Tight coupling,

High complexity,

Low cohesion,

Flaws in programming, e. g., non-idiomatic use of languages or tools.

Runtime problems in systems, like instability, lack of robustness or reliability, insufficient performance or extensive resource demands, insufficient scalability, insufficient transparency of system processes

“Legacy” gathered by frequent changes of requirements made under time and/or cost pressure.

Recognize and name different kinds of technical debts.

Problems to achieve quality goals or requirements, e. g., insufficient changeability or maintainability, low flexibility, insufficient security or lack of portability.

Problems in development, operations or other involved processes (e. g., requirements management, test/QA, configuration, deployment, monitoring/alerting).

Problem (issue),

Solution approach (opportunity for improvement),

Costs (of problems, solution approaches, measures),

Root cause versus symptom,

Risk.

Ad-hoc improvement, one-off improvement,

Stepwise improvement (mid- to long-term),

Improvement by newly developed system or system parts (rewrite),

Purely structural improvements (refactoring),

Conceptual/structural improvements (re-architecting, reengineering).

Distinguish “problem analysis” from “problem solution”

Form m:n relation between problems and solution approaches

Decomposition of complex problems

Stakeholder analysis and interview,

Contextual analysis,

Qualitative analysis (e. g., ATAM), in particular, analysis of quality goals,

Analysis of structural deviations between target and current architecture,

Quantitative analysis methods and practices, such as:

Code metrics (size metrics, coupling, complexity, cohesion),

Organisational metrics, such as costs, time, and countable items. Example: error counts and failure rates, development speed, cost per feature, cost per fixed bug, etc.,

Runtime metrics, e. g., time and resource demands as well as tools to measure these metrics.

Data analysis: examination of data structures and contents,

Documentation analysis,

Analysis of technical environment (runtime and operations: hardware, operations environment, networks, operating systems involved and infrastructure software)

Analysis of development processes (requirements engineering, design/implementation, test/QA and handover to operations)

Analysis of operation processes

Analysis of further processes and tasks that may influence development problems and system changes, e. g.,: management, budgeting, support, governance, outsourcing/offshoring, procurement.

Participant shall be able to initiate an adequate documentation of problems (issues) and risks that have been identified by an improvement- and change process.

Tools and examples for problem documentation.

Plan, perform, and document a stakeholder analysis to identify essential people involved, their roles, and intents.

Know methods to structure and execute stakeholder interviews.

Being able to create preparatory questionnaires.

React flexibly to new relevant information obtained during interviews; incorporate these in the analysis.

Define and document contextual boundaries: demarcate systems with respect to their technically and logically related neighbours, identify external interfaces.

Identify connections between external interfaces and stakeholders and use this information for problem analysis.

Elaborate problems and risks of external interfaces (e. g., via interviews, analysis of known failures, runtime analysis, protocol or log analysis, analysis of organisational dependencies, analysis of quality attributes and/or service levels).

Perform and document (static) analysis of existing source code and its structure. (For this purpose, tools may be used in the training. However, these are not a prerequisite).

Plan and perform (dynamic) analysis of existing systems, e. g., with respect to runtime behaviour, resource utilization, load response. (For this purpose, tools may be used in the training. However, these are not a prerequisite).

Explain costs and value as linked concepts.

Name and classify different kinds of economic dimensions, such as:

Direct costs, education costs, capital expenditures (direct and indirect cost of investment), operating expenditures, opportunity cost, and cost of delay

Investment and operating expenses (OPEX), Run-the-Company (RTC) and Develop-the-Company (DTC)

ROI, break-even, depreciation and amortisation

One-time and reoccurring costs, known and estimated costs.

Explain the terms “estimation“, “observation“ and “measurement“ and apply them to the evaluation of problems and solution approaches.

Be able to estimate efforts in intervals. Know different approaches for interval estimates:

Confidence interval,

Minimum/maximum interval,

Worst-/Average-/Best-Case estimation.

Be able to assess and communicate the probability of the correctness of the estimation.

Identify and name items to be estimated, e. g., hours of work.

Identify parameters and influencing factors of estimations

explicit assumption to be able to define estimation parameters in value ranges.

Issue tracker,

Tables,

Data bases.

Long-term continuous improvement,

Improving releases,

Application strangling,

Encapsulation of (localised) problems or risks in black-boxes,

Extraction of business aspects, separation of technical aspects,

Incremental replacement of problematic parts of system,

Rewrite,

Outsourcing,

Business process reengineering.

Decentralisation vs. centralisation of development processes.

Employment of iterative processes to reduce risks.

Reduce idle times and buffers to accelerate development processes.

Identify critical parts (people, organisational units) in development processes, and possible ways to relieve them.

Know and being able to apply typical technology/programming language specific refactorings (semantics preserving simplification measures in source code). Trainings should conduct exercises if required.

Better use of technology or use better technology (change of technology).

Explain the connection between technical debts and refactoring.

Know and be able to apply measures and patterns to reduce coupling at source code level.

Know and be able to apply measures and patterns to make source code more comprehensible, e. g., Clean-Code principles.

Know and being able to autonomously apply automated tests (unit-, integration-, acceptance-, regression-tests) as a means of early detection of defects in change or improvement projects. (Trainings should provide exercises if required.)

Being able to autonomously identify adequate locations/interfaces/components where the introduction of automated tests will be suitable for specific change scenarios.

Continuous integration,

Continuous delivery,

Model driven development/generative development.

Know and be able to apply typical patterns to reduce coupling (e. g., modularisation/component building, decoupling via interfaces, dependency injection, encapsulation, adapter, wrapper, gateway, decoupling of control flow with asynchronous invocation).

Understand the impact of typical patterns (possibly by using appropriate tools).

Compliance with established document structures (e. g., templates)

Targeted reduction of documentation volume through abstraction or focussing on essential topics.

Top-down communication,

Separation of structural (specific) and conceptual (overarching) contents.

Modularisation of documentation.

Participants should be able to identify and understand the problems and risks of at least one example of a mid- or large-size IT system. Therefore, the trainings should at least describe the system’s main functional and non-functional requirements, quality goals, usage and change scenarios, essential implementation structures as well as important cross-cutting concepts.

Participants should be able to understand the evaluation of problems or solution approaches in a given example.

Participants should know and be able to understand the (short-, mid- and/or longterm) planning of an improvement project in a given example.

Participants should know and be able to understand possible or implemented improvement measures in a given example.