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 a detailed description of the structure of the system. This document is built upon the architecture document [Johansson, 2003] and the requirement specification [Larsson, 2003] and will be the foundation of the implementation of the system.
The reader should familiarize himself/herself with the words listed in
section 1.8. The design specification is divided into a number of chapters and in the end of the document you can find an index. The chapters are described here:
Describes the structure and substance of the document.
This chapter describes how the system works on a more detailed level than was given in the architecture document, but more general than the detailed class descriptions in chapter
8.
This chapter describes the design method used.
This chapter describes design decisions made in case they differ from, or need more details than the decisions made in the architecture document.
This chapter describes the states a project can be in and the possible transitions between states.
The directory structure plays an important role in the system. This chapter covers that.
This chapter describes critical parts of the system that are of special importance.
This chapter contains class descriptions that stand as a basis for implementation.
This chapter describes file formats that will be used.
The appendix contains an example of how report files can look.
1.3 Connection to architecture
This document is heavily based on the architecture document. The two should be seen as a unit rather than two separate entities. The design document however, goes in much deeper detail. Despite that fact, references are given to the architecture document. This is for its necessity to be able look up something there in order to understand a specific issue completely.
1.4 Connection to implementation
The goal of this document is to give, together with the architecture document, a description so detailed of the AudioJury system that it can be implemented by a group of programmers who have no other information source than these two documents. Each chapter contains different details which are necessary to know about, in order to make a correct implementation.
For a programmer that is directly involved in writing code for AudioJury, the whole document must be read at least once. After that it can be used as a reference for looking up details when needed.
If the reader only wants an overview of the design of the system, only the following chapters in this document need to be read:
The reader should know about the architectural design of the system, which can be found in the architecture document [Johansson, 2003].
Other than that, chapter 5, "Functional requirements" and chapter 6, "Non-functional requirements" in the requirement specification [Larsson, 2003] should be read.
1.6 Document dependencies
Alterations in this document may require changes in the following documents:
· Technical documentation [Akhvlediani, 2003].
· User manual [Årstrand, 2003].
· Programming handbook [Akhvlediani & Årstrand, 2003].
· Test plan [Svärd, 2003].
1.7 Document distribution
This document will be distributed to:
· The customer Sony Ericsson Mobile Communications AB.
· The project group's mentor Mustapha Skhiri.
· The examiners of this document Jonas Wallgren and Joakim Lord.
Here follows a definition list of terms and abbreviations that are used throughout this document:
|
|
A person that manages listening tests by using the administrator part of the system.
|
|
|
A person that 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 give 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 sound`s 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.
|
|
|
Originally a Microsoft Windows concept. It is a directory on a computer that is available to other computers on the same network via the Microsoft Windows Network Protocol.
|
