PS Software-Engineering

SE-001-2000 20th October 2000

Aufgabe 1

Report

@cosy.sbg.ac.at @cosy.sbg.ac.at

@cosy.sbg.ac.at @cosy.sbg.ac.at

@cosy.sbg.ac.at

Academic Supervisor Mag. Dipl.-Ing. Schwaiger Roland

Department of Computer Science University of Salzburg

Correspondence to:

Universität Salzburg Institut für Computerwissenschaften und Systemanalyse Jakob–Haringer–Straße 2 A–5020 Salzburg Austria

Aufgabe 1

Department of Computer Science University of Salzburg A–5020 Salzburg, Austria @cosy.sbg.ac.at

Abstract

This document deals with the development of a software-system with the working title ”Archaeological Data System - ADS” for entering, administering and presenting archaeological data via the internet.

Contents

1 Productanalysis 2 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 General (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Entering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Virtual Museum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.6 General (II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

A Protocolls 7 A.1 11. October 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Bibliography 7

Chapter 1

Productanalysis

The productanalysis aims at clarifying topics such as our customer’s wishes and requirements concerning the software, it shall give restrictions what the software is not to do as well as point out questions which are to be discussed with our customer.

As R. Yeh and P. Zave describe [1], a great deal of time and money is invested in maintenance of a software-product. To reduce this in order to be more productive as you can concentrate on other projects, a very important part of software-developement is to specify exactly the system’s requirements. Yeh and Zave also mention 3 major steps which should be persued during this phase of the software-project:

1. Problem identification: One shall identify and describe the needs of a system for certain purposes;

2. Problem understanding: Collect and analyze information about the system and its environment, as well as their interaction;

3. Problem specification: Describe the behavior of the system.

The following sections of course will provide the software’s requirements - this will therefore satisfy step 1. In order to do this completey, we need more detailed information about our customer’s wishes; questioning our customer will therefore be the next main activity - this equals step 2. The 3rd step will be covered as soon as enough information is available.

This chapter will be the product of these 3 steps.

1.1 Introduction

Our company was engaged to develop a software-system with the working title ”Archaeological Data System - ADS” which first of all shall:

• Provide an interface via the world-wide-web enabling our customer to enter archaeological data such as tombs, settlements or artefacts into a central database.

• Enable third parties to query the database for information via the world-wide-web.

• Present the data also via a virtual museum.

We are responsible for the design and implementation of this system including the following points:

• Web-front-end to manipulate and display data.

• The design and implentation of the database itself.

• Maintain these services.

• Host the database on a server or at least administer this work.

1.2 General (I)

As the database shall be accessible via a standard web-browser, we will not develope an independant programme which could connect to the database for example via TCP/IP. Just the web-front-end for web-browsers will be designed and implemented.

• Has the customer already gained experience with a similar software or do they already use one?

• Is there currently a homepage or a special corporate design our software-system has to be adopted to?

• How much financial capital has been allocated for this project?

• Are there any time-frames for parts of or the whole software-system?

1.3 Database

Concerning the database as well as the data itself there are several questions:

• Approximately how many data-records will there be and what will they contain? Will there just be ASCII-based data or also non-text formats such as pictures, audio- or video-files?

• Approximately of how many entries will a record consist?

• As the database shall be searchable, which criteria will there be to be searched for? (This can be necessary to know concerning the possible different data-formats.)

• Can the visitors who query the database via the web-front-end search the whole database? Or will they just be able to access certain selections of it such as the objects of the museum’s current exhibition (see below for details concerning the museum).

• The data collectors can specify a record’s entries the visitor can or can not see when querying the database. Will these selections be global ones or apply to archaeological objects differently. E.g.: Imagine you have 50 tombs, each with the attributes place, who was burried there and when it was found. A data collector’s possible selection could be ”place” and ”who was burried”. Shall this apply on all 50 tombs, or shall there be some among them with other selections to present to the visitor?

1.4 Entering Data

There are two main groups who can enter data into the database:

1. Data collectors

2. Scientific data collectors

Members of the first group will enter general data concerning the archaeological object such as the place where it was found, while members of the second group will add additional information such as interpretations and publications concerning this object. Questions are:

• Have the data collectors the right to manipulate all currently available data?

• What rights do the scientific data collectors have?

• How many (scientific) data collectors will be working with the software?

• How about the administrators mentioned below?

• Who can create new rooms or showcases?

• Who can edit already collected data?

• How shall data be entered, especially if there are pictures or other non-text formats?

So far besides our maintaining-team probabely the following four groups will have contact with the software:

Data collectors: They will enter general data concerning the archaeological objects. They also can define relationships between different types of data or specific records. Data collectors also can edit the virtual museum where the objects are to be presented.

Scientific data collectors: They will enter more specific data such as publications concerning the archaeological objects. Again they have the option of defining relationships as mentioned before as well as editing the virtual museum.

Visitors: They will just have the option to query the database for information as well as to walk through the virtual museum.

Administrators: The administrators will be able to maintain and repair small but urgent concerns, perhaps via the internet.

1.5 Virtual Museum

The software-system shall include a virtual museum where the visitors can walk through and zoom into descriptions of archaeological objects and artefacts. The museum shall not host all the data collected as the customer wants to perform special exhibitions on current topics.

• What shall the museum look like?

We can exclude the option of (advanced) 3d-graphics as this definitely conflicts with the required compatability to standard-webbrowsers. Nevertheless, there are several options:

• Show photography-like pictures of the rooms, move within the museum by clicking on arrows or signs.

• Present the museum animated (via tools such as Quicktime, Flash, Shockwave, etc.)

• Just show a clickable room-map.

• Others.

Nevertheless we need to know:

• What extent will the museum be of? How many rooms will it consist of?

• Will there be several exhibitions at once?

• As the data collectors shall be able to design the final showcases, one option could be to offer them a given set of different showcases, frames and boards for their data they can choose from. Another option would be to just give them a list, which entries of the data-record will be shown. To what extent shall the data collectors be able to edit the final look?

At this point we want to remind the customer of the fact that also this virtual museum will be accessed via the internet. Unfortunately, still the majority of visitors will have lowspeed connections and therefore can not enjoy the museum if there is too much (graphical) data to be transferred.

1.6 General (II)

Having a good idea now of either what the software-system shall offer or what remains to be answered by the customer, there are some additional topics left to be dealt with:

The customer wants to produce represantative CD’s as well as catalogues with the virtual museum and its exhibitions.

• Shall these CD’s also contain the whole database and therefore offer full searchability or just the objects relevant to the exhibitions?

• Who will be responsible for producing the CD’s and the catalogues? How will this process be dealt with?

Our management demands the use of XML in order to be as platform-independant as possible. Besides the web-front-end, are there any other parts of the software which will be implemented in XML?

Perhaps the customer wishes to extract a set of, a single data-record or just some entries of such. This functionality would require an export-option. Is this necessary? If so, what shall be the data-format exported to (txt, xml, etc.)?

Appendix A

Protocolls

A.1 11. October 2000

In this first meeting our academic supervisor Mag. Dipl.-Ing. Schwaiger Roland introduced us to the project. Several groups will work on the project and each develope their own solutions. At the end of the semester, there will presentations in order to let the others know, how each group solved their problems.

Person responsible for protocoll: .

Participating persons: The whole PS-group.

Topics talked about: Introduction to the project. General Information.

New assignments: Start with the productanalysis and prepare questions for the upcoming meeting with our customer’s represantative.

Open questions: None yet.

Bibliography

[1] R. T. Yeh and P. Zave, Specifying Software Requirements. Proceedings of the IEEE, vol. 68 ed., 1980.