Requirements of Quality are often risky. Such decisions are normally expensive to revert. So this decisions often relevant for architecture.
This article describe patterns for the identify, categories and maintenance requirements which are essential for Softwarearchitecture. This article base on the book „Vorgehensmuster für Softwarearchitektur“ written by Stefan Toth (embarc GmbH) and published by the Carl Hanser Verlag GmbH & Co. KG.
The below Diagramm shows the patterns which are recommend to implement the agile approach to the process of Softwarearchitecture.
Initial requirement Workshop
Addressed problem
How can requirements of architecture effective detect and communicate?
Requirements for the Scope of Architecture must be Architecture-Scop rough known at the beginning of a project. This is necessary to have the capability to estimate the cost of time and money. In this phase the important issues for architecture must be identify to make them transparent
The base of architecture work are requirements. The following pattern will help to extract the requirements which are essential for the architecture of a Software.
Requirements maintenance workshop
Addressed problem
How it is possible to create a continue flow of iterative processable stories, on the base of a list of requirements with issues which are relevant for the architecture?
In Scrum the requirements maintenance workshop is calling ‚Backlog maintenance‘ or ‚Grooming‘. The workshop should happen in the middle of an iteration to prepare the requirements which should implement in the following iteration. The duration of the workshop should take 30 Minutes for dicuss all issues which opinion as relevant for the next iteration. The discussion contains the splitting in case of big issues, enriche the requirement with more informations if necessary and estimate the cost of implement the story.
Scenario as requirement of architecture
Adressed problem
How it is possible to express requirements of quality, so that work of architecture can be useful to lead and stakeholder justly communicate?
Scenarios of quality or abbreviation scenario are concrete statements about the behavior of a system by normale use or in relation to corner cases. At that not the functionality but the quality is the focus: How often, how fast, how secure must functions be available. Properties of quality like reliability, efficiency and security must be describe more detailed.
For supporting to detect quality scenarios the following table is helpful :
| Scenariotyp | Question | Quality attribute |
| Use-Case scenario | What happens by normal usage of the system | Usability, efficienc |
| Expansion scenario | Where and how will the system extends in the future | scability, extensibility, portability |
| Stress scenario | How the system react to unexpected incidents | reliability, security, behavior under last |
The scenariotypes and answers to the questions contains in the table, address all issues of the ISO 9126/25000 represent below.
For more informations i recommend you the book Vorgehensweise für Softwarearchitektur from Stefan Toth. Published by the Hanser Verlag
Categorize Scenarios
Addressed problem
How can scenarios in an iterative and/or agile process handle, without delay or hinder?
Not all scenarios effort the same workload on architecture. Some scenarios must decide soon at the beginning of a project and communicate to a large group of colleagues other must observe together with functionality. By categorization the dependencies between functionality and quality are manageable and the effort reduces. Only the architecture relevant topics get own stories, the other topics will be weave with the stories of funtionality.
There exist three types of scenarios of quality:
- criteria of acceptance
The direct extension of functionality requirements. Those issues can note on the backside of the story-card. They suit for qualities which the user feel in relation to exact this functionality. Usability, performance etc. such criteria can find ad-hoc also. The criteria of acceptance normally not lead to fundamental questions of architecture.
- tale of quality
This are requirements which are independent from single functionality requirements and can realize independent. For sample scalability and availability like detection of server breakdown, rollback mechanism or solutions for monitoring. Will only search for criteria of acceptance such aspects will be overlook.
- common reminder
Omnipresent reminder for the project employees. This reminder are use for communicate to be used principles or defined rules. Samples are maintainability, portability or scalability. To prohibit the use of a framework because an security consider exits is such case.
The criteria of acceptance have dependencies directly to functionality requirements. The Scenarios of the two other categories can handle independent from functionality requirements.
Technical depts as requirement of architecture
Addressed problem
By which way problems and omissions of architecture can efficient, transparent and in the remaining architecture evolution handle integrated?
Like requirements of architecture so can technical depts detect need of work of architecure. But this happens at a moment where business requirements were implement and decisions in relation to the architecture were missing. There are exists different types of technical depts:
- Code (code conventions failed and code-smells)
- Architecture (wrong choice of technology, framework, Components etc.)
- Test (missing, incomplete or defocus tests)
Depts of the category architecture are for sample inconsistencies, complicated concepts in the implementation. Depts of architecture occurs if imported quality properties and framework conditions are disregarded. The search for technical depts should be a continual process which should execute by the developer.
Not all detected technical depts must be solve. It exits three options for activity:
- continued payment, the technical depts stay
- repayment, the technical depts will be remove
- refinancing, an option will be implement which is better then the current solution but not perfect.
Which kind of of this three options should choice depend from the relationship investment effort to the effectiveness.
Work of Architecture in Backlog
Addressed problem
How work of architecture can iterative, continue prioritize and with functional tasks realize by a weaved way?
Work of Architecture on Kanban
Addressed problem
By which way the work of architecture from the idea to the release can be optimize, so that a story with a weaved, continued and visible flow of tasks will be create?
Kanban (kan- visual signal, ban- card or table) is one by Taiichi Oho developed method for control the production by Toyota. Kanban implements central ideas of lean.Essential are the pull approach. Stories will not be push to the next step. Stories will be pull by the next step if the next step is ready. The effect is, that a work step overflow if the following work steps stuck. Thats fine because it is necessary to solve problems in following steps before it make sense to implement more and more stories before problems in the later work steps not solved.
The average count of elements in a queue is equal to the average resting time in the queue multiply with the average arrival rate. This sound logic.
Adapt to the process of Software-development we can extract following issues:
- Split Big Stories into smaller one, increase the time of implementation and so the resting time. The result is that in the same time, with the same resources more Stories can realize. So the average time increase. The result is a faster flow of realized requiremens with more frequent feedbacks. So it is recommend to work with little stories.
- If you hold, the work which is concurrent in work, constant, you get the ability, based on the average work time, exact determine how much requirements you could accept. This gives save in planning and makes assertions related to time of implementation more easy. Accordingly delimitate and planning stories which are concurrently in work.
Neueste Kommentare