Content deleted Content added
No edit summary |
m Moved the text to another section to make this more coherent. |
||
Line 13:
[[Software documentation|Documenting software]] architecture facilitates communication between [[Stakeholder (corporate)#In management|stakeholders]], captures early decisions about the high-level design, and allows the reuse of design components between projects.<ref name="SAP2">{{cite book|last=Bass|first=Len|author2=Paul Clements |author3=Rick Kazman |title=Software Architecture in Practice, Third Edition|publisher = Addison-Wesley|year=2012|___location=Boston|isbn=978-0-321-81573-6}}</ref>{{rp|29–35}}
It's [[software architect]]'s responsibility to match [[List of system quality attributes|architectural characteristics]] (aka [[non-functional requirement]]s) with business and user requirements. For example "[[Customer satisfaction|user satisfactions]]" requires availability, fault tolerance, security, testability, recoverability, agility and performance in the system. As another example, [[Time to market|time-to-market]] requires maintainability, testability and deplorability. <ref name="O'Reilly Media" />▼
Software architecture design is commonly juxtaposed with [[software application design]]. Whilst application design focuses on the design of the processes and data supporting the required functionality (the services offered by the system), software architecture design focuses on designing the infrastructure within which application functionality can be realized and executed such that the functionality is provided in a way which meets the system's [[non-functional requirement]]s.
Line 84 ⟶ 82:
==Architecture activities==
There are many activities that a [[software architect]] performs. A software architect typically works with project managers, discusses [[architecturally significant requirements]] with stakeholders, designs a software architecture, evaluates a design, communicates with designers and stakeholders, documents the architectural design and more.<ref name="Kruchten 2008">{{Cite journal | last1 = Kruchten | first1 = P. | title = What do software architects really do? | doi = 10.1016/j.jss.2008.08.025 | journal = Journal of Systems and Software | volume = 81 | issue = 12 | pages = 2413–2416 | year = 2008 }}</ref>
▲It's [[software architect]]'s responsibility to match [[List of system quality attributes|architectural characteristics]] (aka [[non-functional requirement]]s) with business and user requirements. For example "[[Customer satisfaction|user satisfactions]]" requires availability, fault tolerance, security, testability, recoverability, agility and performance in the system. As another example, [[Time to market|time-to-market]] requires maintainability, testability and deplorability. <ref name="O'Reilly Media" />
There are four core activities in software architecture design.<ref name="hofmeister07" /> These core architecture activities are performed iteratively and at different stages of the initial software development life-cycle, as well as over the evolution of a system.
'''Architectural analysis''' is the process of understanding the environment in which a proposed system will operate and determining the requirements for the system. The input or requirements to the analysis activity can come from any number of stakeholders and include items such as:
| |||