The UP is an architecture - centric iterative and evolutionary method. This does not mean a waterfall attempt to fully identify all architectural requirements before development, nor an attempt to fully design the "correct" architecture before program and test. Rather, it means that early iterations focus on programming and testing architecturally significant concerns (such as security) and using, proving, developing and stabilizing the key architectural elements (subsystems, interfaces, frameworks, and so on).
In the UP, the architecture evolves and stabilizes through early development and test with an architecture - focus, not through speculation on paper, or "PowerPoint Architecture." In the UP, the architectural factors - or requirements - are recorded in the Supplementary Specification, and the architectural decisions that resolve them are recorded in the Software Architecture Document (SAD). Because the UP is not the waterfall, the SAD is not fully created before programming, but rather, after programming - once the code has stabilized. Then, the SAD documents the actual system as a learning aid for others.
Architectural analysis starts early, during the inception phase, and is a focus of the elaboration phase; it is a high - priority and very influential activity in software development.
Architectural Information in the UP Artifacts
The architectural factors (for example, in a factor table) are recorded in the Supplementary Specification.
The architectural decisions are recorded in the SAD. This includes the technical memos and descriptions of the architectural views.
Inception— If it is unclear whether it is technically possible to satisfy the architecturally significant requirements, the team may implement an architectural proof - of - concept (POC) to determine feasibility. In the UP, its creation and assessment is called Architectural Synthesis. This is distinct from plain old small POC programming experiments for isolated technical questions. An architectural POC lightly covers many of the architecturally significant requirements to assess their combined feasibility.
Elaboration— A major goal of this phase is to implement the core risky architectural elements, thus most architectural analysis is completed during elaboration. It is normally expected that the majority of factor table, technical memo, and SAD content can be completed by the end of elaboration.
Transition— Although ideally the architecturally significant factors and decisions were resolved long before transition, the SAD will need a review and possible revision at the end of this phase to ensure it accurately describes the final deployed system.
Subsequent evolution cycles— Before the design of new versions, it is common to revisit architectural factors and decisions. For example, the decision in version 1.0 to create a single remote tax calculator service, rather than one duplicated on each POS node, could have been motivated by cost (to avoid multiple licenses). But perhaps in the future the cost of tax calculators is reduced, and thus, for fault toleragice or performance reasons, the architecture is changed to use multiple local tax calculators.
There is a growing body of architecture - related patterns, and general software architecture advice Suggestions:
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.