Операционные системы. Задание. Техническое задание явля ется первым разделом курсовой работы. 1
 Скачать 0.67 Mb.
|
|
2.3.4 Внутренние ограничения Важно определить не только то, каким будет изделие, но также и каким оно не будет. Ограничение — это свойство (или возможность), которое пользователю логично ожидать, но кото- рое по тем или иным причинам исключено. Перечисляются все ограничения, упоминаемые в различных разделах СТ. Включа- ются также ограничения, не упоминаемые в СТ, но касающиеся таких свойств или возможностей, которые пользователь спра- ведливо ожидает найти и исключение которых может вызвать его неудовлетворенность изделием. Не следует скрывать такие ограничения, как неполная взаимозаменяемость носителей, от- сутствие поддержки для каких-либо возможностей оборудова- ния, вынужденная имитация некоторых дополнительных уст- ройств, невозможность одновременной работы или нахождения в памяти с изделиями-компаньонами. Как потенциальные пере- числяются все такие ограничения, которые могут быть оставле- ны на усмотрение группы разработки. Пример. Структура ASK предполагает, что пользователь за- хочет использовать максимально возможное число команд в ин- терактивном режиме и что «команды выдачи отчетных доку- ментов будут наиболее часто используемыми». Поэтому он должен формировать все критерии, зависимости и файлы до вы- дачи команд, которые их используют, чтобы избежать наруше- ния дисциплины ожидания для продолжительных процедур, вы- полняемых в процессе анализа. См. также раздел 2.3.3.2.1.3. 2.4 Используемые материалы Этот раздел должен быть расширен в спецификации сопро- вождения, поэтому в СТ содержится только один подраздел. 2.4.1 Справочные документы Отдельно указывается каждый плановый или технический документ, на который имеется ссылка в СТ. Каждый такой до- кумент должен реально существовать (а не подразумеваться в 41 будущем) и должен быть зарегистрирован и принят на хранение группой контроля документации в целях управления конфигу- рацией программного изделия. Чтобы избежать неточностей, ссылки на документы, описывающие программы, должны со- держать шифры проектов и шифры изделий. Если в основе изделия лежит какой-либо стандартный язык или код связи, следует указать документ, определяющий этот стандарт. Если выпускается новая версия существующего про- граммного изделия, должны быть перечислены все соответствую- щие ему проектные документы и публикации. Если использование программного изделия связано со специальным оборудованием, необходимо указать соответствующую документацию. Пример. Справочные документы: а) Коммерческий план финансовых служб, Дж. Э. Очинк - лосс, 13.6.77 (проект), разд. 5; б) Интерфейс операционной системы с виртуальной памя- тью. Руководство, 12-6643-43; в) Спецификация содержания и формата DATABASE, 1230711, редакция 7.2.77; г) Американский национальный стандарт. Процедуры для использования управляющих символов стандартного кода обме- на информацией в специальных каналах передачи данных, ANSI ХЗ.28-1971, разд. 5.2, 5.4, 5.7; д) Стандарт корпорации ABC на программирование, утвер- жденный 14.2.73 либо в последней редакции; е) Язык BIL 3. Справочное руководство, 07-5411-67; ж) Модуль UPDATE. Руководство оператора, 06-4160-36. 2.5 Передача заказчику и ввод в действие 2.5.1 Средства защиты права собственности на изделие Указывается один из следующих уровней: − засекречивание не требуется; − промышленный секрет; − авторское право; − патент. 42 2.5.2 Ресурсы, обеспечивающие ввод в действие Определяются ресурсы, требуемые для установки системы, наряду с ресурсами, описанными в разделе 2.5.3 (здесь имеются в виду машинное время, трудозатраты и необходимая квалифи- кация персонала). Объемы и качество этих ресурсов должны быть определены в терминах наиболее вероятных потребностей. Пример. Любой оператор, знакомый с системой VSOS и имеющий опыт работы 6 месяцев (или при эквивалентном обу- чении), сможет осуществить ввод в действие изделия ASK, ис- пользуя модуль UPDATE, в течение 15 минут работы за пультом машины. После получасового ознакомления с процедурами ве- рификации по информационному листку выпуска он сможет выполнить процедуру проверки в течение 10 минут работы в интерактивном режиме за терминалом. Все сказанное предполагает, что необходимые устройства работают нормально и на машине не выполняются параллель- ные работы. Указываются все условия (в том числе технические и программные средства), необходимые для генерации и ввода программного изделия в действие и не описанные в разделах 2.3.(2,3).X.1.4. 2.5.3 Носители информации Определяется тип запоминающих устройств для всех распро- страняемых компонентов программного изделия (например, маг- нитная лента, характеризуемая количеством дорожек и плотностью записи; пакет дисков, отдельные диски и т.п.). Если данное про- граммное изделие должно работать совместно с другими изделия- ми, то последние должны быть названы либо должна даваться ссылка на соответствующее CТ. Необходимо убедиться в том, что требуемые формы представления данных и запоминающая среда позволяют осуществить ввод программного изделия в действие при наличии любой минимальной конфигурации устройств. Пример. Объектные программы ASK будут распространяться на дисках по формату UPDATE (см. п. 2.4.1, ж). Исправления объ- ектных программ будут распространяться в том же виде. 43 2.6 Тактика Тактика определяет, каким образом будет реализовываться стратегия. Следовательно, в этом разделе говорится о том, как должно создаваться программное изделие. 2.6.1 Взаимосвязи 2.6.1.1 Т РЕБУЕМЫЕ ВЗАИМОСВЯЗИ Определяются требования, выдвигаемые данным про- граммным изделием к другим проектам или функциям. Дается краткая характеристика каждого требования и указывается этап, на котором может быть установлен факт выполнения постав- ленного условия. Пример 1. Отдел электронных интерфейсов должен обеспе- чивать проверку каналов с помощью диагностической програм- мы, которую группа испытаний должна иметь на этапе О10 (раздел 7). Фирма ABC Services должна обеспечить доступ к нормаль- но функционирующей минимальной конфигурации ЭВМ серии Stella 100 в промежутке между этапами Р20 и П3О. Пример 2. Интерфейс Electronics должен обеспечивать раз- ветвление канала, используя диагностическую программу, кото- рую группа испытаний должна иметь на этапе О10 (см. раздел 7). Пример 3. На этапе Р3О необходимо иметь компилятор РПГ 11, настроенный на выполнение объектных программ. 2.6.1.2 О БЕСПЕЧИВАЕМЫЕ ВЗАИМОСВЯЗИ По структуре этот раздел аналогичен предыдущему, но со- держит требования, налагаемые другими изделиями на данное изделие. Каждому требованию в разделе 2.6.1.2 должно соответ- ствовать требование в разделе 2.6.1.1 со стороны другого изде- лия. Здесь же описывается влияние, оказываемое данным изде- лием на другие функции. Указываются все требования, которым должно соответствовать данное изделие, чтобы обеспечить ра- боту других программных средств. Примером могут служить требования к обеспечению диагностики или сопряжению с ди- 44 агностическими испытательными средствами, такими, как файл ошибок или средства профилактического контроля в режиме on-line. Пример. Структура изделия ASK полностью описывается во взаимосвязанных внешних спецификациях интерфейса поль- зователя ASK (C013/L321) и процессора корректировок ASK (C013/L331). Справочное руководство и справочный буклет должны быть готовы в окончательном виде в большом количестве (мож- но ксерокопии) на этапе Д21 (раздел 7). Это требуется фирме ABC Services для проведения обучения. 2.6.2 Техническая ревизионная комиссия В каждом СТ следует рекомендовать создание технической ревизионной комиссии (ТРК) с указанием места работы каждого члена комиссии и его фамилии, если это возможно, а также на- значение председателя этой комиссии. Пример. От каждого из следующих лиц было получено личное согласие работать в ТРК: − Боб Уилбур (отдел испытаний программ) — председа- тель; − К.В. Гаррисон (фирма ABC Services); − Роберт Вонг (отдел выпуска документации); − Боб Симе (отдел разработки прикладных программ). 2.6.3 Проверка изделия 2.6.3.1 У РОВНИ ИСПЫТАНИЙ Испытания программ могут быть организованы в три этапа, проводиться в трех режимах и насчитывать десять категорий (см. раздел 5 «Тестирование»). Эта информация представляется в виде таблицы. Для каждого этапа и категории указывается, кто будет проводить испытания. Определяется роль группы испыта- ний посредством установления режимов испытаний. Пример. Уровни испытаний приведены в таблице 2.4. 45 Таблица 2.4 — Уровни испытаний Класс испытаний Категория испытаний A B C Демонстрация в действии / / Аттестация Р / / Полная функциональная проверка Р И / Проверка новых свойств / Эксплуатационные испытания Р И Испытания надежности Р И / Проверка устойчивости / Возвратная проверка / Пусковые испытания Р И О Испытания конфигураций Р И О Режимы испытаний: I — проводятся группой испытаний ( ) II — контролируются группой испытаний ( X ) III — группа испытаний не участвует ( ) Подразделения, проводящие испытания: Р — группа разработки И — группа испытаний О — группа обслуживания / — испытания исключены Фирма ABC Services в течение части периода испытаний класса B выделяет двух специалистов, имеющих опыт работы в области финансового анализа, для работы за терминалами. Ис- пытания в условиях минимальной конфигурации, описанной в разделе 2.3.3.1.1.4, проводятся на реальном оборудовании; ана- логичным образом проверяется базовая конфигурация, за ис- ключением контроллеров связи, линий связи и терминалов. Максимальная конфигурация должна содержать одно устройст- во типа M442, одно устройство типа M443, предположительно семь телефонных каналов и терминалы. Число контроллеров ограничено имеющейся аппаратурой, а число линий связи и терминалов — имеющимся персоналом. Отдел испытаний программных средств разрабатывает имитатор терминалов, а отдел электронных интерфейсов — раз- ветвленные каналы для работы с этой моделью. Для проверки изделия ASK одновременно имитируются до 144 устройств типа 1024 Telcoscope путем подключения имитатора на входы кана- 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; 51 4 ТЕСТИРОВАНИЕ Проведение тестирования — цель второй части второй ла- бораторной работы. Также результаты тестирования являются четвертым разделом курсовой работы. 4.1 Общие принципы тестирования Этап тестирования обычно в финансовых затратах состав- ляет половину расходов на создание системы. Плохо спланиро- ванное тестирование приводит к существенному увеличению сроков разработки системы и является основной причиной сры- вов графиков разработки. В процессе тестирования используются данные, характер- ные для системы в рабочем состоянии, т.е. данные для тестиро- вания выбираются случайным образом. План проведения испы- таний должен быть составлен заранее, обычно на этапе проекти- рования. Тестирование подразумевает три стадии: − автономное; − комплексное; − системное. При автономном тестировании модуль проверяется с помо- щью данных, подготовленных программистом. При этом про- граммная среда модуля имитируется с помощью программ управления тестированием, содержащих фиктивные программы вместо реальных подпрограмм, к которым имеется обращение из данного модуля (заглушки). Подобную процедуру называют про- граммным тестированием, а программу тестирования — UUT (тестирующей программой). Модуль, прошедший автономное тестирование, подвергается комплексному тестированию. В процессе комплексного тестирования проводится совме- стная проверка групп программных компонентов. В результате имеем полностью проверенную систему. На данном этапе тес- тирование обнаруживает ошибки, пропущенные на стадии авто- номного тестирования. Исправление этих ошибок может состав- лять до четверти от общих затрат. 52 Системное (или оценочное) тестирование — это завер- шающая стадия проверки системы, т.е. проверка системы в це- лом с помощью независимых тестов. Независимость тестов яв- ляется главным требованием. Обычно Заказчик на стадии при- емки работ настаивает на проведении собственного системного тестирования. Для случая, когда сравниваются характеристики нескольких систем (имеется альтернативная разработка), такая процедура известна как сравнительное тестирование. В процессе тестирования для определения правильности выполнения программы вводится ряд критериев: 1) каждый оператор должен быть выполнен, по крайней ме- ре, один раз для заданного набора тестов, и программа должна выдать правильный результат; 2) каждая ветвь программы должна быть опробована, и про- грамма при этом должна выдать правильный результат; 3) каждый путь в программе должен быть испытан хотя бы один раз с использованием набора тестовых данных, и програм- ма должна выдать правильный результат; 4) для каждой спецификации программы необходимо рас- полагать набором тестовых данных, позволяющих установить, что программа правильно реализует данную спецификацию. Хотя критерии п.п. 1 и 2 кажутся схожими, в действитель- ности они сильно разнятся. Например, арифметический опера- тор |