From a recent IEEE software article we are looking for those legs that make architectural design decisions sustainable in terms of documentation effort, maintainability and trace links to other software artifacts, balancing the items describing a decision and the capturing effort needed to maintain such knowledge evolvable over time.
The same thing that makes any decision sustainable: that with hindsight it seems inevitable.
See "Farrell-Vinay, Peter, An approach to axioms of the iteration process" in Dowson, Mark, 'Iteration in the software process" Proceedings ot the 3rd Software Process workshop, IEEE/ACM, 1987."
Beware: capturing the decisions you take in software development can be complex. We tried it in Logica years ago and gave up when we realised we couldn't determine which were major and which minor decisions.
What we realised was essential was the baseline of a requirements specification sufficiently complete to allow design decisions to be taken. This remains true even in Agile where you might have (to maintain) a set of feature cards.
To conclude: if in Agile you must always be able to generate a tested version of the system so you should always be able to determine why some design decision was taken in terms of some need to satisfy some requirement. This need only be some set of comments of an "added this section to enable/interface/support some Y facility which is used by requirements/cards/whatever A, B and C".
Yes this is bureaucratic - so is gettting paid.
So your idea of free is "RRP: Paperback £19.99 (ISBN 9781844076437) and Hardback £75.00 (ISBN 9781844076420)"
Why do I think you have never read the book?
Hi Peter, Michael
Thank you for the input. I will check the references mentioned.
In addition, and regarding decisions in Agile contexts, there are some ideas using a minimalistic approach you can find in the following article: Uwe Zdun, Rafael Capilla, Huy Tran, Olaf Zimmermann: Sustainable Architectural Design Decisions. IEEE Software 30(6): 46-53 (2013)
Also, Olaf Zimmermann when we worked for IBM distinsguished between 3 types of decisions (strategic, technical and 1 more I can't remember) but it seems not easy to know which decisions aremore relevant than others. From our view, we limit the granularity o f the decisiones to the level of package and class in order to limit the number of dependencies between decisions. However, there are some recent attempts from Olaf for capturing decisions at the code level using a semi-automatic approach.
Cheers
Rafa
in addition to Rafael Capilla I recommend to take a look at Cobit 5. The framework highly correlates the decisions in different abstraction levels which can serve as a basis for your question in general.
- Badges
- Science topic
- Similar topics
- Agriculture