Principles of Software Architecture & Design
Unit 1 - Quality, Tactics, Design & Documentation
Fall 2003 (2003-1)

News

Links have been (or will be) added to the bottom of this page to all the relevant document templates used in this exercise.

Problem Overview

For this unit the focus is on quality attributes (Chapter 4), quality tactics (Chapter 5), architecture design (Chapter 7), and architecture documentation (Chapter 7). In addition, there is a second architecture case study (Chapter 6).

The problem outlined below is designed to exercise the knowledge you gain from the material in these chapters. In concert with the unit questions associated with each chapter, the project should increase your ability to determine the critical qualities associated with a proposed system, to apply architecture tactics to help achieve these qualities, to design an architecture around the qualities and tactics, and to properly document the result.

Problem Statement

You are the architects for an up-and-coming software company that develops large scale information systems products, the majority of which are based on client/server technology. When entering a new market, the company's strategy is to contract the development of a system in that market, often at a discount, and then using the resulting system as the core product in the market.

The company has decided to enter the market for student information systems (SIS) at colleges and universities. In keeping with its strategy, the company has contracted to develop a new SIS for a medium sized technical university in upstate New York. The client was selected in part because it exhibits some unusual features: a quarter-based academic calendar, a large cooperative education program, and a wide variety of professional, technical curricula. It is assumed that an SIS architecture developed for this institution will provide a solid base for the general product.

The system will maintain academic information on each student (full time or part time), including:

• Basic identification information: Name, address, phone number, etc.
• Courses taken by term, along with grades for completed courses (as submitted by faculty).
• Grade point averages, as defined by the university's policies and procedures.
• Notations related to degree(s) conferred, minors (if any) academic actions (probation, Dean's list, etc.).

The system will not be used for registration per se, but will track the progress of students in the courses they do register for. That is, the SIS is not the registration system, but it must extract information from the registration system.

The client for the system (e.g., the organization footing the bill for its development) is the Registrar's Office at the university. Users of the system include students (to track their progress), faculty (to obtain class rosters and assign grades), department chairs & their staffs (to track progress towards the degree and to indicated academic actions), the registrar's staff (to confer degrees upon completion), and possibly others such as the alumni office.

Other stakeholders at the university include the university's information technology staff who will install and maintain the system. At your company, the stakeholders include the project manager, the developers, the quality assurance department, the maintenance group, and, of course, sales and marketing.

Among the objectives for the system defined by one or more of the stakeholders are:

• The system must be scalable so that it can be adapted to the needs of small colleges with fewer than 1,000 students as well as large state universities with 40,000 students or more.
• The system must be usable, though the definition of usability may depend on the class of user (students, faculty, staff, etc.)
• The system must prevent unauthorized changes to the information base.
• The system must be adaptable to the different reporting requirements imposed by different state education agencies.
• To expand the market, the system should allow the use of a wide-variety of backend database systems (so that universities need not purchase another database product just for SIS).
• Performance must be adequate - in particular, queries should be answered in under 2 seconds on average.
• Web access for viewing information (but not necessarily editing information) is important.
• To speed time to market, 3rd party systems and components should be considered wherever feasible.

Of course, these objectives are not independent, not mutually reinforcing, and not necessarily complete.

The Architectural Challenge

1. You must identify the key architectural qualities that the SIS system should exhibit, and come to an initial prioritization of these qualities based on discussions with the stakeholders.
2. You must identify a set of tactics that will help ensure the architecture you create does indeed meet the identified quality requirements.
3. You must design an architecture that embodies your understanding of the qualities, their tradeoffs, and the appropriate tactics.
4. You must document your architecture so that it can be presented and discussed by all stakeholders. Included in this documentation (either integrated throughout or relegated to appendices) must be the qualities you defined, their priority, and the tactics selected to address the quality issues.

Your instructor will assume the following roles as appropriate:

• Mentor & guide on material from the text.
• The various system stakeholders.

Document Templates

• Quality Scenario Template (MS/Word)