ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 9294
Скачиваний: 10
46
лов системы VSOS, а изделия ASK — на выходы каналов. Этот
же режим имитации обеспечивает моделирование работы одно-
го устройства типа 43-1 на каждое устройство типа 43.
2.6.3.2
Э
ТАЛОНЫ ДЛЯ СРАВНЕНИЯ
Определяются эталонные системы, относительно которых
должно выполняться сравнение. Указываются характеристики
данной системы в относительных единицах. Если эталона для
сравнения нет, приводятся абсолютные значения характеристик.
Пример. Поскольку ASK является новым изделием, нет ба-
зы для корректировки ошибочных решений. Критериями при
проведении испытаний класса B будут лишь документ, в кото-
ром описывается назначение изделия ASK и требования к нему,
и внешняя спецификация изделия ASK.
2.6.4 Обеспечение поддержки
Для каждого подраздела указываются конкретные меро-
приятия; при этом делаются ссылки на план поддержки или кон-
статируется, что соответствующие меры отсутствуют.
2.6.4.1
М
ЕРОПРИЯТИЯ
,
ОБЕСПЕЧИВАЮЩИЕ ПРОДВИЖЕНИЕ
ПРОГРАММНОГО ИЗДЕЛИЯ НА РЫНОК
Могут указываться, например, экспозиции, которые следует
подготовить для торговых выставок или для определенного за-
казчика.
2.6.4.2
М
ЕРОПРИЯТИЯ
,
СВЯЗАННЫЕ С ОБУЧЕНИЕМ
Описываются формы обучения различных категорий слу-
шателей и относительное время его проведения (например, в
фазе оценки). Указывается требуемый уровень начальной под-
готовки и требуемая квалификация.
2.6.4.3
С
РЕДСТВА
,
ОБЕСПЕЧИВАЮЩИЕ МОДЕРНИЗАЦИЮ
ПРОГРАММНОГО ИЗДЕЛИЯ
Можно сослаться на раздел 2.3.(2,3).X.1.2.
47
2.7
Извещение
об
изменении
календарных
сроков
Пример.
Наименование проекта: Разработка изделия ASK
Шифр проекта: C013. Шифр изделия: L301A.
Наименование изделия: ASK
Шифр
этапа
Наименование этапа
Прежний
срок
Новый
срок
Примеча
-
ния
П10
Утверждение бюджетной
заявки
29.09.77
Р10
Определение назначения
изделия и требований к
нему
03.11.77
П20
Утверждение назначения и
требований к изделию
15.12.77
Р20
Составление внешней спе-
цификации
09.01.78
И10
Утверждение плана испы-
таний
09.02.78
Р30
Утверждение внешней
спецификации
15.03.78
06.02.78
О10
Установка аппаратуры,
необходимой для разра-
ботки
31.03.78
Д10
Утверждение плана под-
держки
02.03.78
Р41
Демонстрация в действии
15.05.78
И30
Начало испытаний класса
B
03.07.78
08.05.78
Д20
Рассылка рекламных мате-
риалов
15.07.78
Д21
Подготовка учебных посо-
бий
01.08.78
С20
Подготовка спецификации
сопровождения
15.08.78
О20
Начало распространения
изделия
01.09.78
17.07.78
Подготовил С. Девис
Утвердил
Старая дата 06.01.78
Утвердил К. Андерсен
Утвердил
Новая дата 13.01.78
48
3
НАПИСАНИЕ
СПЕЦИФИКАЦИЙ
Написание спецификаций — цель первой части второй ла-
бораторной работы. Также спецификации являются третьим раз-
делом курсовой работы.
На этапе определения спецификаций осуществляется точ-
ное описание функций, реализуемых ЭВМ, а также задаются
структуры входных и выходных данных, методы и средства их
размещения. Определяются алгоритмы обработки данных.
Центральным вопросом определения спецификаций являет-
ся проблема организации базы данных. При этом решается ком-
плекс вопросов, имеющих отношение к структуре файлов, орга-
низации доступа к ним, модификации и удаления.
В случае, когда новая система создается на основе сущест-
вующих, составной частью спецификаций является схема (алго-
ритм) приведения существующей базы данных к новому форма-
ту. Такое преобразование может потребовать разработку специ-
альной программы, которая становится ненужной после ее пер-
вого и единственного использования.
Все эти вопросы должны быть отражены в функциональных
спецификациях, которые представляют собой документ, являю-
щийся основополагающим в процессе разработки системы, так
как содержит конкретное описание последней. Чем подробней
составлены спецификации, тем меньше вероятность возникно-
вения ошибок.
В спецификациях должны быть представлены данные для
тестирования элементов системы и системы в целом. Это требо-
вание является объективным и обязательным, так как на данном
этапе на параметры тестирования не будет оказывать влияние
конкретная реализация системы.
Так как функциональные спецификации описывают приня-
тые решения в целом, данный документ можно использовать
для начальных оценок временных затрат, числа специалистов и
других ресурсов, необходимых для проведения работ.
В общем случае спецификации определяют те функции, ко-
торые должна выполнять система, не указывая, каким образом
это достигается. Составление подробных алгоритмов на этом
49
этапе преждевременно и может вызвать нежелательные ослож-
нения.
Пример. Далее приводится пример оформления специфика-
ции на программу «Электронный каталог».
Внешняя спецификация:
main: procedure (File);
declare 1 File;
2 Name: string [20];
2 Album: string [15];
2 Genre: string [15];
2 Year: string [4];
if File not found then
begin
put (‘
ошибка открытия файла’);
call Create;
end;
if length (File)=0 then
put (‘
файл не содержит записей’);
do case (
кнопка)
//
Вывод содержимого файла на экран
«
Просмотр»: call View;
//
Поиск записи в файле
«
Поиск»: call Search;
//
Добавление записи
«
Добавить»: call Add;
//
Удаление записи из файла
«
Удалить»: call Del;
//
Выход из программы
«
Выход»: call Exit;
end;
end main.
Внутренняя спецификация:
procedure View (File);
begin
do while EOF(File)
begin
get (
запись);
put (
запись);
50
end;
end View;
procedure Search (File);
begin
get (
искомое значение);
do while EOF(File)
begin
if (
искомое значение)=true then
put (Name, Album, Genre, Year);
end;
end Search;
procedure Add (File);
begin
get (
запись);
put (
запись в файл);
end Add;
procedure Del (File);
begin
get (
запись);
put (
удаление записи из файла);
end Del;
procedure Create (File);
begin
get (
создание файла);
end Create;