Process: When Do We Start Architectural Analysis? - UML

In the UP, architectural analysis should start even before the first development iteration, as architectural issues need to be identified and resolved in early development work. Failure to do so is a high risk. For example, deferring an architecturally - significant factor such as "must be internationalized to support English, Chinese, and Hindi" or "must handle 500 concurrent transactions with on - average one - second response time" until late in development is a recipe for pain and suffering.

However, since the UP is iterative and evolutionary - not the waterfall - we start programming and testing in early iterations before all the architectural analysis is complete. Analysis and early development proceed hand - in - hand.

But this important topic was deferred until this point of the book so that fundamentals of QOA/D could be first presented.

First, two points of change in a software system (first introduced in the Protected Variations pattern) are worth reiterating:

  1. variation point— Variations in the existing current system or requirements, such as the multiple tax calculator interfaces that must be supported.
  2. evolution point— Speculative points of variation that may arise in the future, but which are not present in the existing requirements.

As will be seen, variation and evolution points are recurring key elements in architectural analysis.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics