This chapter gives the background to and the overview of the rest of this document. Dependencies between this and other project documents are listed and finally the terminology that has been used is explained.
The purpose of this document is to give an overview of the structure of the system. The document describes and motivates what has been decided regarding the architecture. The main components of the system are defined and the decisions that affect the architecture are dealt with.
Describes the structure and substance of the document.
Motivates and states the decisions made concerning the architecture. of the system
Presents detailed use cases and shows how the architecture fulfils the requirements.
Presents the identified modules and places them in layers.
Describes the graphical user interface.
Shows how the design facilitates extension of the system.
The reader should get familiarized with the words listed in
section 1.7. It is recommended to have the requirement specification [Larsson, 2003] and the design document [Johansson, 2003] at hand when reading. The whole document should be read to get a general overview of the architecture.
See the requirement specification [Larsson, 2003] to get a functional overview of the system.
1.4.1 Hardware and software requirements
The system will run on a regular PC with Windows XP or Windows 2000 installed. The recommended requirements of Windows XP apply. In addition a soundcard capable of playback at least 16 bits at 44 kHz is mandatory. Java Runtime Environment v1.4 should also be installed on the system.
1.4.2 Data distribution and collection
To transfer projects and results between the client and the administration program either a windows network ("shared folder"), or any removable media with sufficient capacity can be used. Typically this will be CD-RWs or USB mass storage devices (i.e.ThumbDrive, USBstick and others).
Figure 1: Data distribution and collection
1.5 Document dependencies
1.5.1 Documents that effect the architecture
· Requirement specification [Larsson, 2003]
Modification of the requirements can effect the architecture.
1.5.2 Documents effected by the architecture
·
Design specification [Johansson, 2003]
Modification of the architecture means major modifications of the design.
· Test documentation [Svärd, 2003]
Modification of the architecture might alter some of the test cases.
· Technical documentation [Akhvlediani, 2003]
Modification of the architecture effects the design which effects the implementation. This means that the technical documentation needs alterations.
1.6 Document distribution
This document will be distributed to:
· The customer: Sony Ericsson Mobile Communications AB.
· The project group's mentor and the examiner of this document: Mustapha Skhiri.
Here follows a definition list of terms and abbreviations that are used throughout this document:
|
|
A person who manages listening tests by using the administrator part of the system.
|
|
|
A person who takes listening tests by using the client part of the system.
|
|
|
A unit consisting of a set of tests and a number of attributes.
|
|
|
A set of judgements based on sounds.
|
|
|
A judgement is a sequence of events where a participant first listens to one or two sounds and then gives a rating of the sounds on a certain scale.
|
|
|
A set of recommendations for subjective determination of transmisson quality issued by the telecommunication standardization sector of the International Telecommunication Union (ITU). These recommendations includes the methods described below, ACR, DCR, and CCR.
|
|
|
A sound sample that has been processed, typically by a telecommunication system, in any way.
|
|
|
An original sound sample that has not been processed in any way. This is used as a reference when judging a processed version of the same sample.
|
Absolute Category Rating (ACR)
|
A standardized method for subjective determination of transmission quality. Used for judgements of one sound at a time, typically rated on a scale from one to five.
|
Degradation Category Rating (DCR)
|
A standardized method for subjective determination of transmission quality. Used for judgements of pairs of sounds, where one of the samples is unprocessed and the other has been processed in some degrading way. The sounds are compared and the degradation of the processed sample is typically rated on a scale from one to five.
|
Comparison Category Rating (CCR)
|
A standardized method for subjective determination of transmission quality, similar to DCR. The difference is that this method can assess sound processing that either degrades or improves sound quality. The second sounds quality compared to the first sound is typically rated on a scale from minus three to three.
|
|
|
Any test where each judgement is based on a comparison of two different sounds at a time.
|
|
|
A general form of paired comparison test where you for example can compare two completely different sounds by preference.
|
|
|
A paired comparison test where all possible combinations between the included sounds are judged.
|
|
|
The complete Audio Jury system. The system consists of an administrator program and a client program.
|
|
|
The non-visible parts and components of the product.
|
|
|
A high level compound of several still unidentified Java classes.
|
|
|
Rectangular area (window) on the screen that presents information and action choices to the user. Only one view can be visible and possible to interact with at a time. Typically a view has many interaction choices.
|
|
|
A smaller rectangular area which may in part cover a view. A dialog typically has limited interaction capabilities and only asks the user for some simple input or confirmation.
|
|
|
Acronym for "Application Programming Interface"
|
