Identify the problem being solved
Examine the problem statement or software requirement specifications for your chosen system. Think carefully about the problem and identify problem actually being solved. Express the problem in problem frame diagram(s), evaluating fit to frame and/or tension among multiple aspects of the problem. Make sure that you have identified the make- or- break issue that will drive your design choices.Propose and critique architectural alternatives
Based on what you now know about architectural level design, propose two or more software architectural designs that meet this requirement. Discuss the significant features of those proposed architectures and explain how they to address the system requirements. In your discussion pay special attention to the tradeoffs in design that are made in a given architecture: for example, some architectural features may support certain requirements at the expense of others.If you choose Option 1 (one of the model problems), you will almost certainly have to refine the problem statement to make the requirements clear (see how the Calendar Scheduler Problem of section 1.9 is refined in Section 3.2). Section 3.3 of [SG95] provides a good examples for the presentation part of your solution; it is perhaps a trifle terse. Your comparison and analysis should go well beyond that of Section 3.3.
If you choose Option 2 (London Ambulance System), you will be expected to take the problem analysis and design beyond the materials presented in lecture.
If you choose Option 3, you will need to find a statement of requirements and scope the system to a size suitable to this exercise. This will almost certainly involve refining some requirements and eliminating others. Another possibility is to add requirements that systems are not actually to satisfy in order to make the project more interesting (a what if we had to do this scenario).
For all options, you are encouraged to research real systems when you refine requirements. Have a reason for all details which must be added to the problems as stated.
Compare the alternatives
Discuss the relative strengths and weaknesses of your designs.
- Under what circumstances would one be preferable to another?
- Think of three new requirements not included in the current specification, but which might be incorporated in a future version of the system. Analyze which of the new requirements can be easily accommodated by the architectural designs. Be specific: for example, what components and connectors would be impacted by the new requirements? For Option 2, you must select new requirements not present in the original description of either phase, and consider their impact on both architectural designs for both phases.
- In view of the above analysis, which (if either) of your architectures is better regarding their ability to handle the anticipated changes?
Teams:
The project is a team effort with no individual write-ups so it is in your interest to find a way to cooperate with your team members and enable everyone to contribute. We expect you to find your own way to use skills of project members wisely and organize responsibilities fairly, but we will step in if necessary.
Architecture Vocabulary and General Hints:
You should use the vocabulary of the course to characterize the architectures when appropriate. However, you do not need to consider architectural styles that are clearly irrelevant, nor do you need to force your characterizations to conform to any of the ``pure'' architectural styles introduced in the course. For example, you may find that some of interactions are best described in terms of dataflow connectors, while others are better viewed as client-server connectors.
Special Note on Model Problems:
We are developing a collection of problems and solutions. The only solutions we have in a format appropriate to include in this collection are KWIC and Mobile Robot (which were deleted from [Shaw+95] only because they already appear in [SG95]). If groups in this class produce more solutions of suitable quality, we may invite you to include them in a future version of the collection and, of course, receive credit.
Preliminary presentation:
To help you make progress and to give you early feedback we introduce two intermediate milestones.A team progress report is due on March 19. It need not be long or elaborate; about 5 pages should be plenty. However, it must indicate what problem you’re working on, problem frames you’ve chosen and their analysis, make-or-break issue and initial sketches of your designs.
We would also like your team to develop a 15-minute presentation of your preliminary results. The dates for these presentations are April 2, April 7, and April 9. Two groups will present on April 2 and April 9 and one group will preset on April 7. This need not be a polished analysis, but it should contain enough substance for us to comment on whether you seem to be on the right track. Be sure to leave half of your alloted time for questions on your presentation. This analysis and presentation will not be graded and will not affect your final grade on the project.
Final write-up:
The final write-up is due at the beginning of class, April 23. The total number of pages for this write-up should be on the order of 20 pages, but should not exceed 25 pages.
Final presentation:
During the classes of April 28 and April 30 each group will present its results in a half-hour presentation. Three groups will present on the first day and two groups will present on the second day. Remember to reserve half of your time for questions and discussion. Time limits will be strictly enforced.A suggested outline for your presentation follows:
- title slide
- informal statement of problem
- analysis of the frame
- driving design issues--make it VERY clear, what the make-or-break issue is
- criteria you will use to compare your alternatives
- slides on alternative #1
- slides on alternative #2
- slides evaluating/comparing the alternatives
Grading:
Your final grade will be based on the final write-up and the final presentation.