Related to this assignment is a peer assessment of each of its sections. This is to be performed each week during the normal tutorial time. Professional work is normally reviewed or critiqued by your colleagues or peers since they are best qualified. Not only does this provide an opportunity for you to clarify your thoughts and decisions but it also provides a chance to overcome our very human tendency to seek evidence that our decisions and views of the world are correct. Too often they are less than correct.
Participation in a review is required in order to receive marks for your presented work for that section of the assignment.
You demonstrate your knowledge of the topic by being able to understand and critique someone else’s work. If you do not submit a useful review, there is no evidence that you understand the topic. The aggregate marks for all reviews will be scaled to 20% of the subject marks.
This assignment reflects industry practice in which software architectures are developed in teams.
- Understand and describe the factors that affect the architectural context and requirements, including stakeholders and their interests, architectural qualities, business requirements, and usage scenarios.
- Develop and refine multiple views of a software system architecture, based on the conceptual, execution, and implementation architecture.
- Understand the key issues in choosing and implementing architectural patterns, including performance, testing, security, usability, maintainability, and reliability qualities.
- Provide rationales for architectural decisions.
- Reason about alternative architectures that may better suit a changing business and problem context.
The Software Architecture Document describes the design of the architecture and provides the basis on which further design and implementation work takes place. It should:
- Summarise the system’s purpose
- Describe the system context including the major stakeholders, their characteristics, and their interests in this architecture.
- Describe elaborated customer needs as a set of usage and quality narratives.
- Provide a set of views (conceptual, execution, and implementation views) that describe and progressively develop the architecture, including its structure, behaviour, implementation, constraints, and so on.
- Provide a rationale for all major architectural decisions. Refer to the system context, stakeholder input, results of prototypes, and so on.
- Provide an evaluation of how well the proposed architecture achieves its business objectives.
- Provide alternative architectures that could also meet the business objectives (but only if you want high marks).
- The Software Architecture Document’s primary purpose is both to capture the reasoning behind the architecture, and to enable further development in the construction phase. To that end:
- Make sure that the document is no longer or more verbose than needed. Remember that the document will be read (amongst others) by impatient software developers.
- Make sure that the document and your design are realistic. Do not design some fancy unfeasible architecture that the software development teams can’t or won’t build. Everything in the architecture must be feasible, and that feasibility must be supported by reasoning or prototypes.
本网站支持淘宝 支付宝 微信支付 paypal等等交易。如果不放心可以用淘宝交易！
E-mail: firstname.lastname@example.org 微信:itcsdx