2D1363, Mjukvarukonstruktion, 8 poäng

Aktuell kursomgång: period 2-4 06/07

Kursledare: Rand Waltzman
Datorpostadress(er): rand@nada.kth.se

 

Project Overview Document (POD)

The purpose of the POD is to give an introductory overview of the project.  After reading this fairly brief document, the reader should have an idea of:

1.      Who are the users and what problem does the system solve for them?

2.      The main uses of the system.

3.      The context/environment in which the system is to be used.

4.      The scope of the system.

5.      The main factors that need to be taken in to account when designing and building the system.

6.      Technologies and Risks

It should be between 3 and 5 pages in length and contain 6 sections corresponding to the 6 points listed above.

In Section 2, you must include at least 2 usage narratives in addition to a general description of the main uses of the system.  A usage narrative is a situated example of the use of the system.  It is a brief paragraph in which you invent a fictional but specific actor and briefly capture the mental state of that person – why he wants what he wants or what conditions drive him to act as he does.  Capture how the world works in that particular case, from the start of the situation to the end.  These narratives should give the reader a good general idea of what the system is about.  Here is an example of a usage narrative for the famous Automated Teller Machine (Bankomat) – ATM – example:

“Mary, taking her two daughters to the day care center on the way to work, drives up to the ATM, runs her card across the card reader, enters her PIN code, selects FAST CASH, and enters $35 as the amount.  The ATM issues a $20 bill and three $5 bills, plus a receipt showing her account balance after the $35 is debited.  The ATM resets its screens after each transaction wit FAST CASH, so Mary can drive away and not worry that the next driver will have access to her account.  Mary likes FAST CASH because it avoids the many questions that slow down the interaction.  She comes to this particular ATM because it issues $5 bills, which she uses to pay the day care provider, and she doesn’t have to get out of her car to use it.” 

-         taken from Writing Effective Use Cases by Alistair Cockburn

In Section 4, you must include an in/out list.  The purpose of an in/out list is to help manage the scope of your project where scope refers to what is covered by or included in your system.  Scope is an important element of defining the boundaries of your system.  The boundaries of your system are made even clearer by describing not only what is covered by the system, but what might be reasonably included in the system and is not.  The in/out list is a simple but amazingly useful device for helping to clarify the boundaries of your system.  Basically, it is a table with 3 columns.  The first column contains topics or functions that one might reasonably expect your system to cover.  The second column is the in column and the third column is the out column.  For each “line” in the table, if the topic or function described in column 1 is within the scope of the system, then you put a check in the in column, otherwise you put a check in the out column.  You will find this list useful during the course of your project to help keep your team focused and not stray or get bogged down in irrelevant issues.  You should refer to it whenever a group discussion seems to be getting off track or some requirement is creeping in that does not really belong.  You can update the table as you go – but at least any changes to it are documented and agreed on by the group and the customer (if applicable).  Here is an example in/out list for a hypothetical purchase request tracking system:

Topic                                                   In         Out

Invoicing in any form                                         X
Producing reports about                        X
requests
Merging requests into one                     X
purchase order
Partial deliveries, late                            X
deliveries, wrong deliveries
All new system services,                       X
software
Any non-software parts                                    X
of the system
Identification of any                               X
preexisting software that can be used
Requisitions                                          X

Here is an example of the factors that need to be taken into account when designing and building your system as you will show in Section 5:

A fire and security alarm monitoring system:

 

A large building may require an automated alarm system which monitors and controls all fire and security alarms in the building. Normally, the building is divided into zones and a number of alarms are associated with each zone.  Alarms alert a central manned control area who may pass these on to the emergency services or may respond personally.  Factors which have to be taken into account in building such a system are:

 

-         If the control area is unmanned and an alarm is activated this alarm should not be ignored if it is potentially serious. Emergency services should be automatically called. 

-         Some but not all parts of the building may be equipped with sprinkler systems or systems to shut down electrical equipment. These should be activated if a fire alarm is confirmed. They should not be activated if there are people in the same room.

-         The building may be equipped with direction indicators which illuminate the route to the nearest exit. These should be activated when a fire alarm is confirmed. At the same time, an audible signal should sound alerting occupiers to leave the building.

-         A security alarm may cause some internal doors to be locked automatically. It should be possible to isolate complete zones by automatic door locking.

-         False alarms are common and it might be normal practice to have an alarm confirmed before alerting emergency services. There are different ways of confirming an alarm. In the case of a fire alarm, it may be confirmed by multiple sensors detecting a problem.

 

Section 6 should contain a description of the technologies that you plan to use together with possible risks associated their use.  For example, suppose you plan to build a web-based application using the Ruby on Rails web application development framework.  A possible risk could be the group’s lack of familiarity with Ruby on Rails and the Ruby programming language.  Another possible risk is that the third party software you plan to use is known to be unstable – like some open source software that sounds really great but is in the early stages of development.

 

^Upp till Nadas kurser.

Sidansvarig: <rand@nada.kth.se>
Tekniskt stöd: <webmaster@nada.kth.se>