3412ICT/7412ICT

Software Architecture

Group Project Assignment 1 - System Description

<Insert System Name >

Tutorial No: <#> Group No: <#>

Students: <Name, Student ID > <Name, Student ID > <Name, Student ID > <Name, Student ID >

BACKGROUND This template is based on the Software Engineering Institutes View and Beyond method for documenting software architectures, as described in Clements, et al., Documenting Software Architecture: Views and Beyond (Addison Wesley, 2002). The current version is available for free download from the SEIs architecture web site. This version of the template covers just the first phase of the group project assignment. TIPS FOR USING THIS TEMPLATE To create an instance of this document:

Insert relevant information on cover sheet and in placeholders throughout. Insert relevant information in page header: Move to a page of the body of the report, select View > Header and Footer from the main menu, and then replace relevant information in the header box at the top of the page.

To update the contents and page numbers in the Table of Contents, List of Figures, and List of Tables:

Position the cursor anywhere in the table to be updated. Click the F9 function key. Answer Update entire table.

To insert a figure or table caption: From the main menu, choose Insert > Reference > Caption and then either Figure or Table as needed. Click the OK button. Add a colon and a tab stop after the figure number in the caption itself. The caption should use the Caption style. Add a colon and a tab stop after the table/figure number in the caption itself. TIPS FOR MAKING YOUR DOCUMENT MORE READABLE

A gray box containing CONTENTS OF THIS SECTION is provided at the beginning of most sections and subsections. After determining what specific information will be included in your document, you can remove this gray box or leave it to serve as a quick-reference section overview for your readers. In the case that text has been provided in the template, inspect it for relevance and revised as necessary. Consider hyperlinking key words used in the document with their entries in the Glossary or other location in which they are defined. Choose Insert > Hyperlink. Dont leave blank sections in the document. Mark them To be determined (ideally with a promise of a date or release number by which the information will be provided) or Not applicable.

Table of Contents
1 Executive Summary..............................................................................................2 2 Introduction...........................................................................................................3 2.1 History 3

2.2 Stakeholders.......................................................................................................3 3 Architecture & Problem Background...................................................................4 3.1 System Overview................................................................................................4 3.2 Goals and Context..............................................................................................5 3.3 Significant Driving Requirements.....................................................................5 4 Competative Landscape.......................................................................................5 4.1 Strengths 5 4.2 Weaknesses........................................................................................................6 4.3 Opportunities......................................................................................................6 4.4 Threats 6

5 Referenced Materials............................................................................................7 6 Directory................................................................................................................8 6.1 Glossary 8 6.2 Acronym List......................................................................................................9

last saved: Sunday, March 18, 2012

7 Project Management Report...............................................................................10

ii

last saved: Sunday, March 18, 2012

List of Figures
Figure 1: Context Diagram.......................................................................................4

List of Tables
Table 1: SWOT Analysis Overview..........................................................................5

last saved: Sunday, March 18, 2012

1 Executive Summary
CONTENTS OF THIS SECTION: This section an overview of the content of the rest of the report, giving key facts that management would like to know about its contents. The executive summary should give the most important aspects of the report while omitting details and some supporting information. Generally speaking, the summary should be not longer than 1 page and preferably as short as possible while conveying the required information.

last saved: Sunday, March 18, 2012

2 Introduction
CONTENTS OF THIS SECTION: This section gives the name of the system and describes its high-level functions. This is expanded upon by the history and stakeholders sections.

2.1 History
CONTENTS OF THIS SECTION: This section provides the historical context for the system. It answers how the system was developed and by whom.

2.2 Stakeholders
CONTENTS OF THIS SECTION: This section provides a list of the stakeholder roles important to the system. For each, the section lists the concerns that the stakeholder has that can be addressed by the system.

Each stakeholder of a software systemcustomer, user, project manager, coder, analyst, tester, and so onis concerned with different characteristics of the system that are affected by its software architecture. For example, the user is concerned that the system is reliable and available when needed; the customer is concerned that the architecture can be implemented on schedule and to budget; the manager is worried (in addition to cost and schedule) that the architecture will allow teams to work largely independently, interacting in disciplined and controlled ways. The developer is worried about strategies to achieve all of those goals. The security analyst is concerned that the system will meet its information assurance requirements, and the performance analyst is similarly concerned with it satisfying real-time deadlines. This information is represented as a matrix, where the rows list stakeholder roles, the columns list concerns, and a cell in the matrix contains an indication of how serious the concern is to a stakeholder in that role
The list of stakeholders will be unique for each system. ANSI/IEEE 1471-2000 requires that at least the following stakeholders be considered: Users Acquirers Developers Maintainers.

You may wish to consider the following additional stakeholders.

Customer

Project manager

External organizations

last saved: Sunday, March 18, 2012

Application software developers Infrastructure software developers End users Application system engineers Application hardware engineers

Communications engineers Chief Engineer/Chief Scientist Program management System and software integration and test engineers Safety engineers and certifiers

Operational system managers Trainers Maintainers Auditors Security engineers and certifiers

3 Architecture & Problem Background

CONTENTS OF THIS SECTION: The sub-parts of Section 2.1 explain the constraints that provided the significant influence over the architecture.

3.1 System Overview

CONTENTS OF THIS SECTION: This section describes the general function and purpose for the system or subsystem whose architecture is described in this SAD. Include a high-level context diagram of the system and summarize major inputs and outputs.

Figure 1: Context Diagram

User

System

Output Files

Input Files

last saved: Sunday, March 18, 2012

3.2 Goals and Context

CONTENTS OF THIS SECTION: This section gives the name of the system and describes its high-level functions

3.3 Significant Driving Requirements

CONTENTS OF THIS SECTION: This section describes behavioral and quality attribute requirements (original or derived) that shaped the software architecture. Included are any scenarios that express driving behavioral and quality attribute goals

4 Competative Landscape
CONTENTS OF THIS SECTION: This section lists and briefly describes the major competitors of the system. Competitors are those systems that do the same thing as the system or those systems that could otherwise be used in place of the system. It also gives a high level overview of the strengths, weaknesses, opportunities and threats of the system explained in more detail in the following sections.

Table 1: SWOT Analysis Overview

Strengths One-sentence description of strength one One-sentence description of strength two Yet another strength. Perhaps this one requires more than one sentence to describe; but try to keep it short. Threats One-sentence description of threat one One-sentence description of threat two Perhaps there are three threats Weaknesses One-sentence description of weakness one One-sentence description of weakness two

Opportunities One-sentence description of opportunity one One-sentence description of opportunity two

4.1 Strengths
CONTENTS OF THIS SECTION: This section describes the functions that the system does well either in comparison with its competition or in absolute terms.

last saved: Sunday, March 18, 2012

4.2 Weaknesses
CONTENTS OF THIS SECTION: This section describes the functions that the system does poorly in relation to its competitors or in absolute terms. Also included could be features that competitors have but the system does not, or features that the system should have but does not given the stakeholders and high-level requirements described in the previous section.

4.3 Opportunities
CONTENTS OF THIS SECTION: This section describes what the opportunities are for the system. Opportunities are factors external to the system (e.g., in the overall environment) such as general trends or actions of competitors that enable the system to increase its market share or usefulness to stakeholders.

4.4 Threats
CONTENTS OF THIS SECTION: This section describes the threats that the system is likely to experience. Threats are factors external to the system such as general trends or actions of competitors that decrease the market share of the system or its usefulness to stakeholders; in the extreme case, threats might render the system obsolete.

last saved: Sunday, March 18, 2012

5 Referenced Materials
CONTENTS OF THIS SECTION: This section provides citations for each reference document. Provide enough information so that a reader of the SAD can be reasonably expected to locate the document.

Bass 2003 Clements 2001 Clements 2002

Bass, Clements, Kazman, Software Architecture in Practice, second edition, Addison Wesley Longman, 2003. Clements, Kazman, Klein, Evaluating Software Architectures: Methods and Case Studies, Addison Wesley Longman, 2001. Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures: Views and Beyond, Addison Wesley Longman, 2002. ANSI/IEEE-1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, 21 September 2000.

IEEE 1471

last saved: Sunday, March 18, 2012

6 Directory
6.1 Glossary
CONTENTS OF THIS SECTION: This section provides a list of definitions of special terms and acronyms used in the SAD. If terms are used in the SAD that are also used in a parent SAD and the definition is different, this section explains why.

Term software architecture

Definition The structure or structures of that system, which comprise software elements, the externally visible properties of those elements, and the relationships among them [Bass 2003]. "Externally visible properties refer to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. A representation of a whole system from the perspective of a related set of concerns [IEEE 1471]. A representation of a particular type of software architectural elements that occur in a system, their properties, and the relations among them. A view conforms to a defining viewpoint. The smallest package of architectural documentation that could usefully be given to a stakeholder. The documentation of a view is composed of one or more view packets. A specification of the conventions for constructing and using a view; a pattern or template from which to develop individual views by establishing the purposes and audience for a view, and the techniques for its creation and analysis [IEEE 1471]. Identifies
last saved: Sunday, March 18, 2012

view

view packet

viewpoint

the set of concerns to be addressed, and identifies the modeling techniques, evaluation techniques, consistency checking techniques, etc., used by any conforming view.

6.2 Acronym List

API ATAM CMM CMMI CORBA COTS EPIC IEEE KPA OO ORB OS QAW RUP SAD SDE SEE SEI Application Programming Interface; Application Program Interface; Application Programmer Interface Architecture Tradeoff Analysis Method Capability Maturity Model Capability Maturity Model Integration Common object request broker architecture Commercial-Off-The-Shelf Evolutionary Process for Integrating COTS-Based Systems Institute of Electrical and Electronics Engineers Key Process Area Object Oriented Object Request Broker Operating System Quality Attribute Workshop Rational Unified Process Software Architecture Document Software Development Environment Software Engineering Environment Software Engineering Institute Systems Engineering & Integration Software End Item SEPG SLOC SW-CMM CMMI-SW UML Software Engineering Process Group Source Lines of Code Capability Maturity Model for Software Capability Maturity Model Integrated - includes Software Engineering Unified Modeling Language

last saved: Sunday, March 18, 2012

7 Project Management Report

10

last saved: Sunday, March 18, 2012