½ day:
What is software architecture? What is the role of architecture in the development process? Going step by step through the definition of software architecture to get an understanding of what it is and what it brings.
½ day:
The architecture domain (IEEE/ISO 42010). The major concepts and their relations. This standard will be used throughout the course as a framework
2 days:
Architecting in its context:
- Environment and system analysis: understanding the environment and the role of the system in its environment.
- Software development as a series of decisions: what to architect? How do you know you have enough architecture? Relation with Scrum.
- The dominant decomposition (also known as main architecture styles).
- Family architectures: the process, artefacts and software mechanisms in the development of families of software systems.
- Quality attributes: what are quality attributes? Why are they important? How to find them?
½ day:
Theory of Good Architecture and the Architecture Reasoning Model. These two topics are a redline throughout the whole course.
To establish, manage, and convey a good software architecture, the architect determines how much attention to pay to certain stakeholders, concerns, models and other architectural aspects. To make meaningful choices, the architect must first determine what a good software architecture is in this situation. If the architect has a clear picture of when the software architecture is good for a specific system and its environment, it becomes easier to actually achieve that good software architecture. To check if an architecture is good and to give direction to the architectural activities, the architect can focus on answering a given set of questions related to correctness, consistency, and communication. These questions and their answers help to identify improvement areas for the architecture.
The architecture reasoning model (ARM) supports reasoning about a system in its environment along three dimensions: Application, Design and Process.
- Application dimension: reasoning about the system’s meaning and value for the customer.
- Design dimension: reasoning about the resources out of which the system is built and how it uses them.
- Process dimension: reasoning about the processes and organization for the development and maintenance of the system.
½ day:
In the second module we discuss the results of the homework assignments such that the students can reflect on the application of the theory to their own work and can learn form each other.
Remarks:
- Knowledge of modeling (preferably UML, or at least OO, is required);
- Small exercises based on simple existing examples;
- Large exercises are preferably performed on cases brought by the participants;
- In between the two modules you will receive homework assignments which will take about one day to complete. The homework assignment will focus on your own case. During this period, you will also receive online personal coaching from the trainer during approximately 1 hour.
- Also reserve in total about one day for reading documents.
