.RU

Техническое задание 8 1 Содержание 8 2 Введение 8 3 Основание для разработки 9 4 Назначение разработки 9





Содержание


Введение 6

1 Техническое задание 8

1.1 Содержание 8

1.2 Введение 8

1.3 Основание для разработки 9

1.4 Назначение разработки 9

1.5 Требования к программе или программному изделию 9

1.5.1 Требования к функциональным характеристикам 10

1.5.2 Требования к надежности 11

1.5.3 Условия эксплуатации 11

1.5.4 Требования к составу и параметрам технических средств 11

1.5.5 Требования к информационной и программной совместимости 12

^ 1.6 Требования к программной документации 12

1.7 Технико-экономические показатели 12

1.8 Стадии и этапы разработки 12

2 Соглашение о требованиях 14

^ 2.1 Описание программного изделия 15

2.1.1 Наименование и шифры изделия 15

2.1.2 Краткое описание изделия 15

2.1.3 Сведения об авторском праве 16

2.1.4 Результирующие компоненты изделия 16

2.2 Цели 20

2.2.1 Согласование заявок на проверку 20

2.2.2 Согласование заявок на расширение 21

2.2.3 Согласование заявок на внесение исправлений 21

2.2.4 Согласование планов 22

2.2.5 Перечень требований пользователя 23

2.2.6 Рассмотренные альтернативы 23

2.2.7 Окупаемость капиталовложений 24

2.3 Стратегия 24

2.3.1 Соглашения относительно представления материала 24

2.3.2 Генерируемое программное обеспечение 25

2.3.3 Системное программное обеспечение 25

2.3.4 Внутренние ограничения 43

^ 2.4 Используемые материалы 44

2.4.1 Справочные документы 44

2.5 Передача заказчику и ввод в действие 45

2.5.1 Средства защиты права собственности на изделие 45

2.5.2 Ресурсы, обеспечивающие ввод в действие 45

2.5.3 Носители информации 46

2.6 Тактика 46

2.6.1 Взаимосвязи 46

2.6.2 Техническая ревизионная комиссия 48

2.6.3 Проверка изделия 48

2.6.4 Обеспечение поддержки 50

^ 2.7 Извещение об изменении календарных сроков 50

3 Написание спецификаций 52

4 Тестирование 55

4.1 Общие принципы тестирования 55

4.2 Организация испытаний программных изделий 58

^ 4.3 Виды испытаний программного изделия. Стадии испытаний 58

4.4 Режимы испытаний программ 59

4.5 Категории испытания программного изделия 60

4.6 Технология тестирования, классы эквивалентности 63

4.7 Построение тестов 65

5 Руководство системного программиста 69

5.1 ГОСТ 19.503-79 69

5.1.1 Общие положения 69

5.1.2 Содержание разделов 70

5.2 Пример 70

5.2.1 Общие сведения о программе 70

5.2.2 Структура программы 72

5.2.3 Настройка программы 73

5.2.4 Проверка программы 74

5.2.5 Дополнительные возможности 74

5.2.6 Сообщения системному программисту 75

Список литературы 77

Приложение А Оформление курсового проекта 78

Приложение Б Пример выполнения курсового проекта № 1 80

Приложение В Пример выполнения курсового проекта № 2 99



Введение

Учебной программой специальности 230105 в рамках изучения дисциплины «Технология разработки программного обеспечения» («ТРПО») для студентов дистанционной формы обучения предусмотрено выполнение двух лабораторных работ:

1. Составление технического задания и соглашения о требованиях.

2. Написание спецификаций и проведение тестирования ПO. Составление руководства системного программиста.

Подготовка курсового проекта является завершающим этапом изучения дисциплины «ТРПО». В период курсового проектирования закрепляются теоретические знания и приобретаются практические навыки разработки программного обеспечения (ПО) и программной документации.

Основной задачей курсового проектирования является разработка программной документации. Курсовой проект должен включать оттестированное программное обеспечение, соответствующее техническому заданию, и пояснительную записку. В состав курсового проекта входят результаты выполнения всех лабораторных работ. Т.о., пояснительная записка к курсовому проекту включает следующие разделы:

1. Техническое задание.

2. Соглашение о требованиях.

3. Внешняя и внутренняя спецификации.

4. Тестирование.

5. Руководство системного программиста.

При этом все замечания, оставшиеся после сдачи лабораторных работ, должны быть устранены.

Разрабатываемое ПО должно содержать не менее 300 операторов, работать в многооконном графическом режиме и поддерживать работу клавиатуры и манипулятора типа «мышь». Программная документация, входящая в состав курсового проекта, должна соответствовать требованиям стандартов Единой системы программной документации (ЕСПД).

Необходимо уделить внимание правильной нумерации разделов. Например, если выполняется лабораторная работа №2, то подраздел «Режимы испытаний программ» будет иметь номер 2.4 (т.к. раздел «Тестирование» будет вторым в данной лабораторной работе) или просто 4 (если основные разделы не нумеровать). Если же выполняется курсовой проект, то нужно нумеровать его основные разделы, тогда «Тестирование» будет четвертым разделом работы, следовательно, подраздел «Режимы испытаний программ» будет иметь номер 4.4 (как и в данном методическом пособии). Примеры см. в приложениях.

^ 1 Техническое задание

Составление технического задания — цель первой части первой лабораторной работы. Также техническое задание является первым разделом курсовой работы.

1.1 Содержание

Техническое задание оформляют в соответствии с ГОСТ 19.106-78. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.

Техническое задание должно содержать следующие разделы:

В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.

1.2 Введение

В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

Пример. Получение заготовок во многих отраслях, таких как судостроение, авиастроение, легкая промышленность, автомобилестроение и др., основано на вырезке необходимых контуров из листового материала с помощью термических устройств. Минимизация пути режущего инструмента обеспечивает существенную экономию энергии и трудозатрат.

Наименование — система минимизации пути режущего инструмента при раскрое листовых материалов (далее просто минимизатор).

Краткая характеристика — двумерный минимизатор с локальной базой сформированных маршрутов резки.

^ 1.3 Основание для разработки

В разделе «Основания для разработки» должны быть указаны:

Пример. Задание для проведения лабораторных занятий и выполнения курсовой работы, выдано кафедрой АСУ ТУСУРа 01.09.2007. Наименование темы разработки — «Минимизатор».

^ 1.4 Назначение разработки

В разделе «Назначение разработки» должно быть указано функциональное (чем является программное изделие) и эксплуатационное (область применения) назначение программы или программного изделия.

Пример. Минимизатор предназначен для формирования минимального пути вырезки многоугольных контуров, размещенных в прямоугольной области, а также для хранения полученных маршрутов в базе данных.

^ 1.5 Требования к программе или программному изделию

Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:



^ 1.5.1 Требования к функциональным характеристикам

В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.

Пример.

1. Редактор должен работать в многооконном графическом режиме и поддерживать работу как клавиатуры, так и манипулятора типа «мышь».

2. Пользователь, по своему желанию, должен иметь возможность установки масштабного поля для каждого окна.

3. Минимизатор должен обеспечивать нахождение минимального пути с проходом только один раз через каждое ребро каждого многоугольного контура детали в области размещения.

4. Найденный путь должен демонстрироваться на экране в различных режимах.

5. Информация о размещении контуров и сформированном маршруте может быть сохранена в локальной базе данных минимизатора.

6. Должен быть обеспечен графический просмотр базы данных с возможностью удаления из нее или копирования в активное окно указанного размещения с имеющимся маршрутом.

7. Информация о размещении и сформированном маршруте может быть выведена в форме файла геометрической информации следующей структуры: …

8. Перечисление вершин контуров деталей в соответствующем дескрипторе выходного файла должно соответствовать сформированному маршруту резки.

9. Программа должна использовать в качестве входной информации файл геометрической информации, первой деталью которого будет прямоугольник области размещения.

10. Программа должна обеспечивать просмотр выходного файла.

^ 1.5.2 Требования к надежности

В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (устойчивое функционирование, контроль входной и выходной информации, время восстановления после отказа и т.п.).

Пример. Программа должна обрабатывать ошибочные действия пользователя и сообщать ему об этом. Программа должна обеспечивать контроль входной и выходной информации в форме файлов геометрической информации.

^ 1.5.3 Условия эксплуатации

В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых обеспечиваются заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.

^ 1.5.4 Требования к составу и параметрам технических средств

В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств и их основные технические характеристики.

Пример. Программное обеспечение разрабатывается для персональной ЭВМ (IBM PC-совместимой) со следующими характеристиками:



^ 1.5.5 Требования к информационной и программной совместимости

В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой. При необходимости должна обеспечиваться защита информации и программ.

Пример. ЭВМ должна работать под управлением операционной системы не ниже, чем Windows 98/NT 4.0. Требование информационной совместимости должно быть обеспечено работой с файлами геометрической информации определенной структуры в качестве входной и выходной информации.

^ 1.6 Требования к программной документации

В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.

^ 1.7 Технико-экономические показатели

В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.

^ 1.8 Стадии и этапы разработки

В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, устанавливают сроки разработки и определяют исполнителей.

^ 2 Соглашение о требованиях

Составление соглашения о требованиях — цель второй части первой лабораторной работы. Также соглашение о требованиях является вторым разделом курсовой работы.

Ниже дается описание разделов, которые должны присутствовать в любом соглашении о требованиях (СТ) согласно ГОСТу. Все последующие упоминания о соглашении о требованиях имеют в виду соглашение о требованиях, разработанное в соответствии с данным разделом. Описываемый подход предполагает также декомпозицию проекта и дальнейшую детализацию, отражаемую во внешней спецификации изделия.

Предполагается, что все утверждения, включенные в соглашение о требованиях, являются требованиями, если они не определены как цели. Различие состоит в том, что требование должно быть обязательно выполнено, а цель допускает ее достижение с некоторым приближением.

Описание информации, содержащейся в СТ, дается ниже очень подробно, и, возможно, после чтения первых абзацев появится желание ограничиться беглым просмотром. Однако если вам когда-нибудь придется разрабатывать свой собственный стандарт СТ, вы, вероятно, оцените предлагаемый здесь со всеми подробностями пример и используете его как образец. С учетом того, что сжатость заголовков разделов и большой объем их описаний скрывают порядок и простоту, лежащие в основе результирующего документа, в конце каждого пункта приводится пример оформления на конкретное изделие. Вероятно, вам опять не захочется читать все приложение целиком, поэтому рекомендуется для начала бегло просмотреть его, чтобы получить представление, как выглядит типичное СТ в целом. Затем можно будет обращаться к отдельным его разделам, чтобы иметь дополнительные примеры, иллюстрирующие приводимый материал.


^ 2.1 Описание программного изделия


2.1.1 Наименование и шифры изделия 2.1.1.1 Полное наименование изделия
Указывается предлагаемое полное наименование изделия. После утверждения СТ не должны использоваться никакие другие наименования для данного изделия, кроме сокращенных наименований, которые приводятся ниже.

Пример. ASK (произносится «аск»).
^ 2.1.1.2 Сокращенные наименования
Указываются все предлагаемые сокращения, которыми разрешается заменять наименование, приведенное в пункте 2.1.1.1. После утверждения СТ не рекомендуется использовать никакие другие сокращения. В противном случае делается пометка «Отсутствуют».

^ 2.1.1.3 Шифры изделия
Указываются шифр или шифры изделия, присвоенные в соответствии с требованиями удобства управления его конфигурацией. Если предполагается выпуск печатных изданий и разработка планов поддержки, порядок присвоения шифров конечным результатам работы группы выпуска документации и группы поддержки может быть иным.

Пример. L301A.
^ 2.1.1.4 Шифры проекта
Приводятся все шифры проекта, используемые в процессе разработки изделия.

Пример. C013.

2.1.2 Краткое описание изделия

Описываются кратко и в общих понятиях основные функциональные свойства изделия. Если программное изделие является расширением уже существующего, характеризуются только его новые свойства.

Пример. ASK позволяет специалисту по финансовому анализу или другому лицу с аналогичными аналитическими задачами в интерактивном режиме и на расстоянии запрашивать ЭВМ серии Stella 100 выполнить поиск и обработку финансовой информации из DATABASE, которая содержит фундаментальные сведения и зависимости по данным за 20 лет для большого числа корпораций и отраслей. ASK может также формировать дополнительные общедоступные или частные сведения, файлы корпораций и отраслей, выражения и элементы и использовать их вместе с информацией из DATABASE.

Программное изделие ASK в совокупности с DATABASE образует сервисную систему ASK DATABASE; все три системы являются собственностью фирмы ABC Services.

^ 2.1.3 Сведения об авторском праве

Если предполагается заявить об установленной законом защите авторских прав на данное изделие, это должно реализоваться уже в CТ. В противном случае делается пометка «Не требуется».

Пример. Copyright © 1977 by ABC Computers Company.

^ 2.1.4 Результирующие компоненты изделия

В данном разделе приводится таблица, подобная или эквивалентная таблице 2.1. В данном случае использована заранее подготовленная печатная форма, что уменьшает время подготовки информации и обеспечивает ее согласованность.

В указанной таблице в строке «Тип изделия» ставится метка X против соответствующей характеристики «Основное» или «Вспомогательное». Если изделие не используется для создания других изделий, оно отмечается как основное. В противном случае (например, ассемблер, компилятор или генератор) оно отмечается как вспомогательное.

В графе «Уровень поддержки» выбирается метка 1, 2 или 3 в соответствии с пояснениями в бланке.

Каждый элемент изделия отмечается меткой X в графе «Формируется целиком», если он будет создаваться заново, или в графе «Модифицируется», если будут вноситься только дополнения или изменения. Метка X ставится в графе «Распространяется» (за пределы группы разработки) или «Не распространяется» (за пределы группы разработки) в зависимости от того, что является правильным. В графе «Ответственная группа» пишется Р, И, П или C — по ключу на бланке. Если предполагается выпуск нестандартных изделий, этот факт отмечается в графе «Другие спецификации» и описание соответствующих документов дается сразу после таблицы.


Таблица 2.1 — Результирующие компоненты изделия




Обозначения:


Основное изделие — не используется для создания других изделий


Вспомогательное изделие — используется для создания других изделий


Уровень поддержки 1: удовлетворяются заявки на исправление дефектов; возможно сообщение об изменениях; принимаются заявки на расширение функциональных возможностей изделия


Уровень поддержки 2: удовлетворяются заявки на исправление дефектов; возможно сообщение об изменениях; заявки на расширение не принимаются


Уровень поддержки 3: удовлетворяются заявки на исправление дефектов


Р — группа разработки




Формируется целиком

Модифицируется

Распространяется

Не распространяется

Ответственная группа

Спецификации
















Внешняя спецификация

X







X

Р

Внутренняя спецификация

X







X

Р

Спецификация испытаний (не надо)
















Спецификация сопровождения (не надо)
















Другие спецификации
















Документация
















Техническое описание системы
















Справочное руководство

X




X




Б

С
Окончание табл. 2.1
правочный буклет

X




X




Б

Руководство оператора

X




X




Б

Тип изде­лия

Основное

X

Начальный уровень поддержки

Указатель системных сообщений

X




X




Б

Вспомогательное




Информационный листок выпуска



















1

X

Другие печатные издания
















2




Рекламные материалы
















3




























Программное обеспечение






















Листинги

X







X

Р







Исходные модули

X







X

Р







Объектные модули

X










Р







Контрольные примеры

X







X

Р

И







Средства разработки










X










Прочие средства

















Листинги представляют собой комплект распечаток, полученных при компоновке и трансляции программного изделия.

Исходные модули содержат совокупность операторов, которые должны быть ассемблированы или откомпилированы для получения готовой программы.

Объектные модули представляют собой редактируемые или загружаемые программы на машинном языке, получаемые в результате ассемблирования или компиляции исходных модулей, или программу, которая порождается некоторым генератором (если она пригодна для непосредственного выполнения или интерпретации).

Отладочный материал используется для доказательства того, что программное изделие может быть правильно ассемблировано, откомпилировано, отредактировано, загружено и выполнено. Отладочный материал может включать листинги, исходные модули, объектные модули и процедуры.

Средства разработки включают ассемблеры, компиляторы, загрузчики, процедуры получения дампов и тому подобные средства, разработанные в рамках данного проекта с целью получения программного изделия.

2.2 Цели

Формулировка цели создания программного изделия отвечает на вопрос «зачем?». Поэтому в данном разделе указываются все причины выпуска изделия. Часто такой причиной может быть выполнение плана или договора либо устранение недостатков предшествующего изделия.

Пример. Коммерческим планом финансовых служб предусматриваются создание в фирме ABC Services и поставка на рынок интерактивной системы финансового анализа с дистанционным доступом, предназначенной для финансовых кругов. Система ASK призвана удовлетворить требования к программному обеспечению, изложенные в коммерческом плане.

^ 2.2.1 Согласование заявок на проверку

Заявки на проверку представляют собой предписанные изменения изделия, которые являются результатом событий, находящихся вне сферы контроля разработчиков изделия. Если заявки на проверку отсутствуют, этот факт отмечается и пункты 2.2.1.1 и 2.2.1.2 опускаются.

^ 2.2.1.1 Отклоненные заявки
Обычно такие заявки отсутствуют, поскольку внесение изменений является обязательным. Однако учет какого-либо конкретного изменения все же может оказаться нецелесообразным, в этом случае отказ должен быть тщательно обоснован и документирован, начиная с данного раздела СТ.

^ 2.2.1.2 Принятые заявки
Здесь перечисляются все предлагаемые в заявках изменения, которые были одобрены и будут включены в изделие. Если таких заявок нет, следует дать пометку «Отсутствуют».

^ 2.2.2 Согласование заявок на расширение

Если заявок на расширение нет, этот факт отмечается и пункты 2.2.2.1 и 2.2.2.2 опускаются.

2.2.2.1 Отклоненные заявки
Перечисляются все предложения, касающиеся расширения изделия, которые были специально рассмотрены с точки зрения их реализации, но не могли быть приняты, указываются причины их отклонения. Если таких предложений нет, делается пометка «Отсутствуют».

^ 2.2.2.2 Принятые заявки
Перечисляются все предложения на расширение, которые были одобрены и будут реализованы в изделии. Если таких предложений нет, делается пометка «Отсутствуют».

^ 2.2.3 Согласование заявок на внесение исправлений

Если предметом рассмотрения СТ является новое изделие, которое не предназначается для замены другого изделия, внешних запросов на внесение исправлений быть не может. В этом случае делается пометка «Не требуется» и опускается пункт 2.2.3.1.

^ 2.2.3.1 Отклоненные заявки
Если целью является переработка или расширение изделия либо замена изделия с известными ошибками, следует планировать исправление ошибок, обнаруженных на данный момент времени. Поэтому в этом пункте пишется примерно следующее: «Все существенные ошибки, зарегистрированные до последнего срока подачи заявок на внесение исправлений (этап СТ), будут исправлены. Заявки, полученные в период между СТ и датой готовности продукта, будут удовлетворены по возможности». Здесь же отмечаются все существенные ошибки, зарегистрированные до появления СТ, которые не будут исправлены (как правило, в связи с технической сложностью), а также причины такого решения. По мере продвижения работы над проектом неудовлетворенные заявки на внесение исправлений могут накапливаться и фиксироваться. Если такие заявки накопятся, данный раздел СТ должен быть изменен.

^ 2.2.4 Согласование планов 2.2.4.1 Исключенные пункты плана
Если имеются какие-либо плановые указания, требующие особых свойств и возможностей программных средств, которые не могут быть обеспечены, если изделие разрабатывается в соответствии с другими требованиями, описанными в СТ, каждое такое указание необходимо рассмотреть отдельно и пояснить, почему оно будет исключено. Если таких указаний нет, делается пометка «Отсутствуют». Отмечаются также и все другие свойства (не фигурирующие в заявках на расширение), которые были детально рассмотрены и исключены.

Пример. Широкий набор терминальных устройств, требуемый в коммерческом плане финансовых служб, не будет обеспечен. С системой ASK будет эффективно работать только устройство Telcoscope 43 или электрически и функционально эквивалентные терминалы. Рассмотрение команд графического вывода (вместо выдачи таблиц) и сортировки файлов откладывается до следующей версии.

^ 2.2.4.2 Включенные пункты плана
Если необходимость создания изделия обоснована таким документом, как план выпуска изделия, план выпуска серии или описание задачи, то цитируется либо определенное место из каждого документа, либо приводится краткое содержание соответствующих разделов. Плановые указания устанавливают (в самых общих чертах), что должно делаться и почему. Эти указания отличаются от технических обоснований, определяющих в конкретных понятиях технические предпосылки осуществления того, что должно делаться. Для каждой цитаты делается отсылка к соответствующей записи в разделе 2.4.1 СТ.

Пример. Коммерческий план финансовых служб, раздел 5 (см. п. 2.4.1 а).

^ 2.2.5 Перечень требований пользователя

Указываются заказчики изделия и поясняется, почему оно им необходимо. В этом разделе указывается также предполагаемый срок использования изделия. Обычно это будет срок службы оборудования или время до выпуска изделия-преемника. Если данное изделие должно быть заменено, указывается наименование изделия-преемника. Цель этого раздела — дать некоторое представление о степени сложности условий работы программ.

Пример. Система ASK предназначается для специалистов по финансовому анализу или других лиц с аналогичными аналитическими задачами, как, например, управляющий по контролю и регулированию портфеля заказов. Ожидается, что пользователи не знакомы с программированием и не имеют подготовленных операторов терминалов.

В соответствии с документом, указанным в пункте 2.4.1 a, первая версия ASK должна быть готова для продажи через 6—12 месяцев, а вторая версия — не позже, чем через 18 месяцев.

^ 2.2.6 Рассмотренные альтернативы

Кратко описываются альтернативы данной разработки, которые были рассмотрены и отклонены, а также причины отклонения. Если программы должны быть закуплены, поясняется, почему они не могут быть разработаны собственными силами, и наоборот. Лица, критически анализирующие СТ, могут потребовать весомых доказательств необходимости разработки программ, поэтому следует всегда убеждаться, что в данном разделе имеется такой материал.

Пример. Поскольку в распоряжении фирмы ABC Services нет ни одного программного изделия, которое может выполнять функции ASK, должно быть разработано новое изделие. Действующих аналогов в готовом виде не существует. Фирма ABC Services решила заключить единственный договор с фирмой ABC Computers о создании и сопровождении ASK; это решение основывается на прошлом положительном опыте заключения договоров с фирмой ABC Computers.

^ 2.2.7 Окупаемость капиталовложений

Определяется прибыль, которую даст создание изделия, в понятиях, соответствующих целевому назначению организации.

Пример. Фирма ABC Services ожидает, что объем сбыта в финансовой сфере увеличится на 10% в течение 3-х месяцев с момента выпуска изделия и достигнет примерно 170% в течение первого года с момента выпуска. В результате ожидаемой большой прибыли от такого увеличения объема сбыта затраты на разработку изделия ASK окупятся через 8 месяцев после выпуска, что без новой версии ASK даст полную валовую прибыль, в три раза превышающую суммарные затраты на его разработку и сопровождение.

2.3 Стратегия

Формулировка стратегии предполагает ответ на вопрос «что?». Поэтому в данном разделе указывается, что будет представлять собой предлагаемое изделие.

^ 2.3.1 Соглашения относительно представления материала

Для краткого описания изделия может понадобиться специальная терминология. Данный раздел предназначен для того, чтобы представить читателям СТ специальный словарь. И если в пунктах 2.3.1.1 и 2.3.1.2 внешней спецификации можно делать дополнения, то в данном разделе СТ ни одна формулировка не должна меняться.

2.3.1.1 Обозначения
Определяются все обозначения, используемые в СТ. Например, если применяются индексы, дается пример их использования и определяется принцип индексации. В противном случае делается пометка об отсутствии специальных обозначений.

2.3.1.2 Терминология
Четко определяется вся терминология, которая может оказаться специфической для данного изделия.

Пример. Вся специальная терминология определяется в контексте данного документа.

^ 2.3.2 Генерируемое программное обеспечение

Генерируемое программное обеспечение — это то, что получается на выходе компилятора, ассемблера, загрузчика, редактора связей или генератора прикладных программ. Генерируемое программное обеспечение классифицируется как вспомогательное и порождается изделием, описываемым в СТ.

^ 2.3.3 Системное программное обеспечение

Системное программное обеспечение — это все остальное программное обеспечение, включающее операционные системы, компиляторы, утилиты, пакеты прикладных программ и др. Это программное обеспечение относится к основному типу и является изделием, описываемым в СТ.

Разделы 2.3.2 и 2.3.3 строятся одинаково. Там, где слова «программное обеспечение» или «изделие» появляются без определений, они относятся как к генерируемому, так и к системному программному обеспечению. Выражение (a, b) означает a или b. Если это выражение появляется дважды, например (a1, b1)… (a2, b2), выбирается a1 и a2 или b1 и b2.

Поскольку большинство программных изделий являются основными, может появиться желание поменять местами разделы 2.3.2 и 2.3.3, а затем опустить раздел 2.3.3 для основного изделия. Причина выдвижения здесь генерируемого программного обеспечения на первое место состоит в том, что при правильном проектировании сверху вниз генерируемое программное обеспечение является основной целью проектирования и должно быть описано раньше, чем его генератор. Другими словами, структура генерируемых программ должна определять структуру генератора, а не наоборот. Если изделие является основным, под заголовком «2.3.2. Генерируемое программное обеспечение» делается пометка «Не используется» и опускаются пункты 2.3.2.1—2.3.2.3.

^ 2.3.3.1 Общие характеристики функций
Необходимо рассматривать все изделие как один функциональный модуль, чтобы число подразделов было небольшим. Если невозможно адекватно описать изделие без разбиения его на отдельные функциональные модули, следует дать схему, показывающую, как связаны между собой функциональные модули, и присвоить каждому модулю собственное обозначение. Затем для каждого функционального модуля отводится подраздел раздела 2.3.(2,3), в заглавии которого используется слово «функция» с последующим именем функционального модуля (рис. 2.1).



Рис. 2.1 — Структурная схема из соглашения о требованиях
для изделия ASK


Пример.

2.3.3.1 Общие характеристики функций ASK.

2.3.3.1.1 Внешние ограничения ASK.

Отметим, что здесь выполняется именно функциональная декомпозиция, поскольку СТ является функциональным документом и не указывает, как предлагаемое изделие будет физически разбито на модули. Во внутренних спецификациях, создаваемых на основе СТ, обязательно должно быть описано физическое разбиение на модули. Чтобы было легче сопоставлять внутренние спецификации с предшествующими им соглашениями о требованиях, удобно представить какое-либо конкретное физическое разбиение и попытаться определить функциональные модули, которые могут быть реализованы как физические модули. Но, поступая так, следует помнить, что в CТ более важным является четкое разбиение по функциям, а физическое разбиение только подразумевается, но не диктуется СТ.

Разделы 2.3.(2,3).Х организуются по иерархическому принципу, чтобы охватить как можно больше вопросов в первой группе подразделов. Это позволяет при отсутствии новой существенной информации просто ссылаться на подразделы более высокого уровня, как это сделано в разделе 2.3.3.2 для системы, показанной на рисунке. Здесь и далее X — номер модуля системы. В рассмотренном примере X = 1 для общих функций ASK, X = 2 для интерфейса пользователя и X = 3 для процессора корректировок. В других проектах количество и состав модулей могут различаться.
^ 2.3.3.1.1 Внешние ограничения
Перечисляются все ограничения, сфера действия которых шире, чем сфера действия СТ; сюда входят, например, промышленные ограничения или ограничения, касающиеся серии изделий. Может быть разрешено введение дополнительных ограничений во внешней и внутренней спецификации, сфера действия которых ограничена рамками данного изделия, например ограничения на распределение памяти.

В разделе 2.3.(2,3).1.1 перечисляются все возможные ограничения, относящиеся ко всем функциям. Однако, если список оказывается длинным и некоторые ограничения относятся не ко всем функциям, они должны приводиться по ходу изложения как можно раньше.

2.3.3.1.1.1 Действующие стандарты
Перечисляются все промышленные стандарты и собственные технические условия организации, которые должны быть учтены при изготовлении изделия. При этом следует убедиться, что ссылки на эти стандарты имеются в разделе 2.4.1 соглашения о требованиях.

Пример. 2.3.3.1.1.1. Действующие стандарты: Стандарт ABC на программирование (см. п. 2.4.1 д).

2.3.3.1.1.2 Ограничения на совместимость
Всегда должно рассматриваться несколько аспектов совместимости: исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов, форматы листингов и форматы языка управления заданиями (управляющие карты, структура команд и т.п.). Специально должна оговариваться совместимость со следующими программными изделиями:

В каждом случае должно указываться, является ли данное изделие расширением или частным случаем другого продукта, и должна даваться соответствующая ссылка в разд. 2.4.1 СТ. Описываются также условия получения данного изделия из других версий или других изделий.

Пример. Не существует программных изделий или баз данных, совместимых с системой ASK. Файлы, генерируемые системой ASK, будут VSOS-файлами прямого доступа (см. п. 2.4.1 б) и поэтому могут быть непосредственно использованы другими программами.

2.3.3.1.1.3 Программные ограничения
Указывается, если это необходимо, операционная система, с которой должно работать предлагаемое программное изделие, а также другие программные средства, с которыми оно должно стыковаться в процессе работы. Следует убедиться, что указаны все средства, необходимые для загрузки программного изделия либо передачи управления ему или от него.

Если имеются программы, которые должны быть исключены из операционной системы, необходимо указать их и объяснить, почему они исключаются.

Пример. ASK работает с системой VSOS версии 4 (см. п. 2.4.1 б). Любой компонент семейства VSOS может работать одновременно с ASK столько времени, сколько будет доступна конфигурация устройств, описанная в пункте 2.3.3.1.1.4. Процессор корректировок может работать параллельно с интерфейсом пользователя, но интерфейсу пользователя закрыт доступ к файлу, который используется в данное время процессором корректировок.

2.3.3.1.1.4 Аппаратные ограничения
Приводится таблица устройств, используемых при работе программного изделия. Для каждого устройства указывается минимальное, номинальное и максимальное требуемое число. Номинальным является оптимальное число устройств или наиболее вероятное, если оптимум не определен. В случае необходимости каких-либо дополнительных устройств они должны быть отмечены отдельно.

Пример. Помимо устройств, требуемых системами, указанными в пункте 2.4.1 б, для системы ASK потребуются устройства, перечисленные в таблице 2.2.


Таблица 2.2 — Необходимые для работы ASK устройства


Устройство

Минимальное число

Номинальное число

Максимальное число

M103 Блок операций с плавающей точкой

1

1

1

M107 Резервный блок питания

1

1

1

M1100 Модуль памяти

1

2

2

M3100 Дисковый модуль

1

3

8

M210 Пульт

1

1

1

Терминал Telcoscope 43

1

128

256



^ 2.3.3.1.2 Внешние характеристики
Информация данного раздела должна быть расширена (но не изменена) во внешней спецификации, а в СТ должны быть представлены лишь самые основные ее аспекты. Если предлагаемое изделие является расширением какого-либо существующего изделия, описываются главным образом его дополнительные характеристики. Этот раздел должен иметь иерархическую структуру, в которой, прежде всего, должно уделяться внимание наиболее важным для конечного пользователя вопросам.

2.3.3.1.2.1 Результаты работы
Описываются все выходные данные программного изделия или функционального модуля с точки зрения их содержания и назначения — отчеты, файлы, записи, поля данных, сообщения, таблицы, флажки. Должны быть рассмотрены все возможные носители и средства отображения информации, в том числе программно опрашиваемые индикаторы, каналы прерывания, панельные индикаторы и т.п.

Пример. Записи в общедоступных и частных файлах, являющихся VSOS-файлами прямого доступа (см. п. 2.4.1 б). Записи в DATABASE для ведения системы индексно-пос­ле­до­ва­тель­ных файлов (см. п. 2.4.1 б) под управлением VSOS (см. п. 2.4.1 б). Поля и записи данных, передаваемые на терминалы и на пульт. Все результаты должны выдаваться под контролем модуля логического доступа VSOS.

2.3.3.1.2.2 Процессы обработки
Описываются операции, выполняемые программным изделием, которое при этом рассматривается в целом или по функциональным модулям как черный ящик (или совокупность черных ящиков). Как минимум, устанавливается соответствие входной и выходной информации, а если обсуждение идет на уровне модулей или этапов обработки, указываются также модули или этапы, которые требуются для получения определенной выходной информации. Определяются все параметры, необходимые для генерации и выполнения программ.

Пример. Рабочий режим состоит в интерактивном поиске, вычислении, выдаче сообщений и построении диаграмм на запросы специалистов по финансовому анализу.

Режим обслуживания состоит в интерактивном анализе базы данных, ее реорганизации и корректировке, производимых системными аналитиками, прошедшими курс обучения обслуживанию баз данных.

2.3.3.1.2.3 Входы системы
Описываются входные данные так же, как результаты работы в пункте 2.3.3.1.2.1.

Пример.

1. Блоки записей из DATABASE и файлов корректур DATABASE (а также файлы системы VSOS).

2. Записи из общедоступных и частных файлов системы ASK.

3. Поля данных с клавиатуры терминалов и пультов.

4. Все входные данные контролируются модулями логического доступа VSOS.
^ 2.3.3.1.3 Эргономические характеристики
Эргономическими характеристиками изделия являются такие свойства, которые обеспечивают надежность, комфорт и продуктивность работы пользователей и операторов. В данном разделе описываются прикладные аспекты эргономики применительно к данному изделию и определяется, насколько разнообразным будет режим его работы.

2.3.3.1.3.1 Безопасность и секретность системы
Описываются в общих чертах характеристики изделия, обеспечивающие безопасность и секретность данных и программ.

Пример. Никакие общедоступные файлы, в том числе DATABASE, не могут быть записаны с терминала. Все секретные файлы защищены паролем в соответствии с соглашениями VSOS. Все операции записи в общедоступные файлы, включая DATABASE, должны выполняться с пульта.

2.3.3.1.3.2 Надежность
Под надежностью программных средств понимается способность к восстановлению нормальной работы при ошибках и сбоях в работе оборудования. Первостепенную важность имеет защита данных пользователя. Следует указать, могут ли ошибки в данных быть исправлены оператором, или определить, как должна продолжаться обработка после обнаружения ошибки, а также установить степень потери информации в различных ситуациях, включая сбои в работе оборудования.

Затем определяется степень защиты программ от ошибок, возникающих в других частях системы. Если некоторая программа должна работать в мультипрограммном режиме, необходимо рассмотреть возможные ошибки в других программах наряду с ошибками в работе оборудования. Если мультипрограммный режим не предусматривается, этот вопрос затрагивать не нужно. В противном случае необходимо рассмотреть защищенность от ошибок, которые возникают в программах, находящихся в памяти одновременно с данной программой.

Следует рассмотреть, как могут повлиять на работу предлагаемых программных средств ошибки в этих сопутствующих программах. При этом учитываются следующие моменты:

а) Операции распределения ресурсов, при которых другим программам может выделяться некоторая область памяти на том же самом устройстве или в той же его части, что и для данной программы. Следует указать, как программные средства изолируются друг от друга во избежание перекрытия отводимых им областей памяти. Если такая изоляция обеспечивается операционной системой или загрузчиком, достаточно сослаться на эти возможности.

б) Ошибки выполнения других программ. Здесь также можно ограничиться указанием соответствующих возможностей (если таковые имеются) аппаратных средств и операционной системы.

Пример. Многие ошибки фиксируются системой ASK, регистрируются в файле ошибок и обрабатываются соответствующими средствами восстановления, имеющимися в составе VSOS.

ASK не изменяет базы данных DATABASE; для псевдо­кор­рек­ти­ров­ки базы данных используются виртуальные файлы.

ASK подчиняется всем ограничениям интерфейса VSOS и поэтому не вызывает сбоя в работе параллельно функционирующих программных средств, и наоборот, параллельно работающие средства, которые также подчиняются соглашениям, не вызовут сбоя в работе ASK.

Каждый блок записей в DATABASE содержит контрольную сумму, которая вычисляется и сравнивается системой ASK для проверки целостности данных.

Виртуальный телекоммуникационный метод доступа (VTAM) системы VSOS используется на логическом уровне 4, наивысшем уровне восстановления при ошибках (который регистрирует все сбои оборудования, допускающие восстановление).

2.3.3.1.3.3 Рестарт
Указываются возможности, обеспечивающие сохранение и использование данных при возобновлении работы после аварийного прерывания, например при рестарте из контрольной точки.

Пример 1. Программы, генерируемые ASK, могут запускаться с любого этапа обработки данных.

Пример 2. Модуль SORT обеспечивает автоматическую или ручную регистрацию параметров и данных, необходимых для рестарта, из последней или любой предыдущей контрольной точки. Вся необходимая для этого информация при выключении электропитания сохраняется, чтобы отказы блока питания не влияли на рестарт.

2.3.3.1.3.4 Соответствие требованиям заказчика
Указываются свойства, которые позволяют программному изделию или его выходным данным удовлетворять конкретным требованиям. Перечисляются, если это возможно, модули, которые могут не удовлетворять требованиям заказчика. Указывается также, какие ресурсы машинного времени и памяти резервируются для учета требований заказчика и какие средства предусматриваются для обслуживания выходных каналов пользователя.

Пример. ASK характеризуется параметрами времени компоновки и времени запуска, позволяющими определять требуемую конфигурацию вычислительной системы. Параметры компоновки определяются для различного числа модулей памяти и дисковых модулей, а также для разного количества и типов контроллеров связи. Параметры запуска определяются для различного числа линий и терминалов, а также для различных структур идентификаторов терминалов и паролей. В систему встроены алгоритмы для оптимизации распределения дисковой памяти и для оценки ситуации, в соответствии с которой следует просто подтвердить прием команды вместо немедленного ее выполнения. Обеспечиваются служебные программы для корректировки, анализа и реорганизации общедоступных файлов ASK и файлов пользователя.

2.3.3.1.3.5 Рабочие характеристики
Приводится основная переменная или основной принцип, по которому должна измеряться эффективность работы программы; указывается соответствующее значение или диапазон значений для этой переменной. Главным здесь является установление количественной меры. Нельзя, например, писать «скорость работы генерируемой программы будет соответствовать быстродействию программы, написанной вручную на ассемблере». Такое утверждение нельзя проверить или использовать при принятии решений относительно внутренней структуры программного изделия. Фраза должна быть определенной, например «производительность будет составлять, как минимум, 21 сообщение в 1 минуту». Характеристики, включенные в данный раздел, должны быть доступны для измерения пользователем. Ими могут быть быстродействие, пропускная способность, скорость передачи данных, скорость компиляции, генерации или ассемблирования, расход машинных ресурсов, время реакции и т.п.

Пример 1. Каждое периферийное устройство должно работать с максимальной производительностью в предположении отсутствия других параллельных операций.

Пример 2. Для 16 активных терминалов будет обеспечиваться время реакции в пределах 5 секунд и меньше по 90% всех тривиальных операций взаимодействия, где тривиальное взаимодействие определяется как передача с терминала одно­сим­воль­ного запроса, поиск на диске односимвольного ответа и прием односимвольного ответа на том же терминале. Время ответа не будет увеличиваться более чем на 100% (до 10 секунд) при увеличении числа активных терминалов с 16 до 180.

Пример 3. Изделие не накладывает никаких ограничений на конфигурацию, помимо ограничений, определяемых оборудованием.

2.3.3.1.3.6 Удобство эксплуатации
Описываются свойства, которые делают взаимодействие «человек — машина» удобным для человека. Примерами являются свободный формат входных данных, диалоговый режим, синтаксическая совместимость, возможность ввода сокращенных команд и т.д. Если существуют другие программные средства, с которыми предполагаемые пользователи могут быть знакомы и которые имеют идентичные или похожие операции, операторы, команды, сообщения об ошибках или другие структуры, следует указать, что соответствующие структуры предлагаемого программного изделия будут такими же, когда они одинаковы, или похожими, когда они сходны. Учитываются также состав специалистов, требуемых для использования тех или иных компонентов программного изделия, и уровень их квалификации, например специалисты в области сбыта, системные программисты, операторы. Необходимо стремиться использовать простой стандартный способ выделения уровней квалификации, например высокий (семь и более лет работы), средний (от двух до шести лет работы) или низкий (один год и менее).

Должно быть показано, как начинается и как заканчивается работа программного изделия. Для таких функций, как сбор, ввод и вывод данных, связь, вычисление, компиляция или генерация, необходимо указать соответствующие типы режима работы:



2.3.3.1.3.7 Мобильность
Описываются требования и цели обеспечения переноса программного изделия из одних рабочих условий в другие.

Пример. В ASK соблюдаются все условия интерфейса VSOS и используется модуль логического доступа VSOS для всех операций ввода-вывода. Поэтому ASK может работать без модификаций с любой операционной системой, для которой VSOS является подсистемой.

^ 2.3.3.1.4 Внутренние характеристики 2.3.3.1.4.1 Удобство сопровождения
Описываются меры, гарантирующие идентифицируемость модулей, если этот вопрос не решен с помощью стандарта.

Пример 1. Каждый исходный и объектный модуль будет снабжаться шифром программного изделия и категорией выпуска, а также, если позволяет место, шифром проекта и идентификатором изделия. Эта информация должна располагаться таким образом, чтобы каждый модуль можно было идентифицировать на любом диске, ленте или в дампе памяти.

Описываются все встроенные средства отладки и компоновки, включая сопряжения с мониторами; указывается, воз­мож­но или нет их выборочное отключение. Чтобы можно было позднее оценить удобство сопровождения, следует указать языки, с которыми способно работать данное программное изделие, а также затраты машинных ресурсов на исправление ошибок.

Пример 2. В системе ASK используются средства программирования BIL3 (см. п. 2.4.1, е), предусматривающие коэффициент резервирования памяти, равный 10%. В соответствии с разделом 2.1.4 пользователям будут передаваться объектные программы. Для коррекции объектных программ используется программа UPDATE (см. п. 2.4.1, ж).

Указывается, какие лица, не входящие в группу сопровождения, могут вносить изменения. При этом необходимо определить условия их подготовки и требуемые ресурсы.

Пример 3. Инженер, являющийся специалистом по системам и успешно освоивший базовую версию VSOS, сможет затрачивать на внесение изменений в объектный модуль не более 2 часов своего времени и 0,5 часа машинного времени.

Следует убедиться в том, что усилия, затрачиваемые на достижение удобства сопровождения, согласуются со временем жизни изделия, определенным в разделе 2.2.4 СТ.

2.3.3.1.4.2 Алгоритмы
Если какие-то используемые алгоритмы или методы играют особую роль в обеспечении успеха или неудачи изделия в смысле его надежности и требуемых характеристик, отмечаются принимаемый риск или ожидаемые преимущества. В противном случае констатируется, что они подлежат описанию во внутренней спецификации.
^ 2.3.3.2 Интерфейс пользователя 2.3.3.2.1 Внешние ограничения 2.3.3.2.1.1 Стандарты для интерфейса пользователя
Пример. ANSI ХЗ.28-1971 (см. п. 2.4.1, г).
2.3.3.2.1.3 Программные ограничения на интерфейс пользователя
Пример. Необходимо наличие модулей VSOS DAM, ILSAM и VTAM (см. п. 2.4.1, б).
2.3.3.2.1.4 Аппаратные ограничения на интерфейс пользователя
Пример. Помимо устройств, указанных в разделе 2.3.3.1.1.4, интерфейсу пользователя требуются минимальные конфигурации, необходимые для VSOS ILSAM, DAM и VTAM (см. п. 2.4.1, б).
^ 2.3.3.2.2 Внешние характеристики 2.3.3.2.2.1 Результаты работы интерфейса пользователя
Пример. Результаты такие же, как в разделе 2.3.3.1.2.1, исключая записи в DATABASE.
2.3.3.2.2.2 Процессы интерфейса пользователя
Пример. Интерфейс пользователя дает возможность:
2.3.3.2.2.3 Входы интерфейса пользователя
Пример. Такие же, как в разделе 2.3.3.1.2.3, кроме данных из файлов корректировки DATABASE.
^ 2.3.3.2.3 Эргономические характеристики 2.3.3.2.3.3 Рестарт интерфейса пользователя
Пример. Состояние системы для всех активных пользователей (в том числе отключенных, но еще обслуживаемых) периодически запоминается на диске (с интервалом, оговариваемым в рамках определения времени компоновки). Обеспечиваются автоматическая и ручная процедуры рестарта на основе использования этих данных.

1. Автоматический рестарт. При использовании вспомогательного блока питания M l07 интерфейс пользователя обеспечивает автоматическое восстановление питания. Все пользователи, активные в момент отключения питания, оповещаются о сбое. Эти активные пользователи опрашиваются и по их желанию либо выводятся из работы, либо их обслуживание продолжается, начиная с последней контрольной точки. Для неактивных пользователей восстановление не производится; работа с ними прекращается, за исключением случаев запоминания результатов выполнения команд, которые были выданы перед отключением питания. Такая же процедура выполняется и после любого другого сбоя, если это может быть сделано достаточно надежно.

2. Ручной рестарт. В каждой контрольной точке производится полный дамп памяти интерфейса пользователя. При каждом старте интерфейса пользователя оператор опрашивается с целью выяснения, выполнять ли новый старт или осуществлять пуск с контрольной точки. Если выбирается пуск с контрольной точки, интерфейс пользователя загружается из файла контрольной точки и вызывается процедура восстановления при сбое питания. Если же возникает сбой, при котором не может быть надежно инициирован автоматический рестарт, на пульт посылается диагностическое сообщение и оператору системы VSOS дается возможность предпринять ручной рестарт.
2.3.3.2.3.5 Характеристики интерфейса пользователя
Пример. При допущении, что на вычислительной машине выполняется только ASK и что параметр восстановления характеризуется одной контрольной точкой в 1 минуту, каждая команда должна выполняться или подтверждаться не более чем за 5 секунд с момента ее ввода (при среднем значении 3 секунды). Все команды, подтверждаемые, но не исполняемые при первой реакции, должны выполняться в течение 2 секунд (на каждый элемент данных по одной фирме и за один период).

В контексте данного раздела отметка «Выполнено» означает, что начался вывод данных на терминал, но команда при этом может быть отработана не полностью. Весь вывод на терминал должен выполняться со скоростью не менее 2 строк в секунду при проектной скорости 200 визуальных символов в секунду (при надлежащем использовании возможности табулирования).
2.3.3.2.3.6 Область применимости интерфейса пользователя
Пример. В типичном сеансе с ASK пользователь, не имеющий опыта программирования, подключается к системе с помощью терминала и вступает в диалог, в котором он определяет:

ASK будет отвечать на каждую команду либо диагностическим сообщением, в котором указываются ошибки и несоответствия в данных, вводимых пользователем, либо ответом на команду, либо подтверждением, что система начинает выполнение команды. Последний случай возникает, когда генерация ответа требует так много времени, что пользователь может предположить какую-либо неисправность, если не получит подтверждения (например, когда вводится команда создания файла). Когда ответ на такую команду готов, ASK посылает его на терминал, если только пользователь не выключился из работы. Если же пользователь уже отключился, ASK сохраняет результат и информирует пользователя о готовности данных при следующем подключении.

Доступны два типа информации из файлов: табличный и графический. Когда объем запрошенной информации превышает емкость экрана устройства Telcoscope 43, данные автоматически разбиваются на страницы. Терминалы оборудованы печатающими устройствами, способными печатать страницы по выбору.
^ 2.3.3.2.4 Внутренние характеристики 2.3.3.2.4.2 Алгоритм интерфейса пользователя
Пример. ASK выполняет каждую команду в режиме интерпретации и немедленно; таким образом, накопление команд не разрешается (за исключением команд запоминания, которые будут рассмотрены ниже).

В системе используется концепция виртуального файла с сохранением дисковой памяти и присущих ей характеристик извлечения данных. Когда пользователь будет описывать некоторый файл как более высокий уровень какого-либо существующего файла (определенного пользователем или системой), никакие существующие данные не будут храниться в этом новом файле. Если в конце сеанса работы на терминале пользователь захочет сохранить такие созданные во время сеанса файлы, выполнение команды запоминания приведет к копированию и сохранению всех элементов данных. Если непосредственно за этой командой последует команда выхода из сеанса, команда запоминания будет выполняться после выхода, освобождая тем самым пользователя и терминал для другой работы.

Программа общего синтаксического анализа просматривает каждую запись, чтобы выполнить ее проверку по диапазону значений, типу и количеству символов и т.п. перед передачей управления процессору команд или любому другому процессору входа. Это дает возможность пользователю сразу корректировать ошибки во вводимой информации.

^ 2.3.3.3 Функция «Процессор корректировок»
Для всех пропущенных подразделов см. соответствующие подразделы раздела 2.3.3.1.
2.3.3.3.1 Внешние ограничения 2.3.3.3.1.3 Программные ограничения для процессора корректировок
Пример. Требует только VSOS ILSAM.
2.3.3.3.1.4 Аппаратные ограничения
Пример. Помимо устройств, нужных для VSOS ILSAM (см. п. 2.4.1, б и в), процессору корректировок потребуются устройства, перечисленные в таблице 2.3.


Таблица 2.3 — Устройства, необходимые процессору корректировок


Устройство

Минимальное число

Номинальное число

Максимальное число

M103 Блок операций с плавающей точкой




1




M107 Резервный блок питания




1




M1100 Модуль памяти




2




M3100 Дисковый модуль




3




M210 Пульт




1




sushestvuyut-dve-osnovnih-gruppi-koncepcij-pribilnosti-na-osnove-teorij-stoimosti-i-na-osnove-neopredelennosti-oni-sushestvenno-razlichayutsya-v-otvete-na-vopros.html
sushestvuyut-li-predeli-poznaniya-brajana-grina-elegantnaya-vselennaya.html
sushestvuyut-razlichnie-klassifikacii-yazikov-programmirovaniya.html
sushka-detalej-referat-po-discipline-tehnologicheskie-processi-mikroelektroniki-na-temu-tehnologicheskie-processi.html
sushnost-adresati-i-zadachi-stimulirovaniya-sbita.html
sushnost-boleznej-glava-illyuzii-i-realnosti-sovremennoj-stranica-3.html
  • learn.bystrickaya.ru/filosofiya-vnutri-i-vne-shkolnih-sten-kniga-predstavlyaet-soboj-istoriko-kulturnij-ocherk-klassicheskogo-perioda.html
  • tetrad.bystrickaya.ru/urok-po-okruzhayushemu-miru-v-3-m-klasse-po-teme-ohrana-rastenij.html
  • textbook.bystrickaya.ru/harakteristicheskie-granichnie-zadachi-dlya-linejnih-uravnenij-visokogo-poryadka-so-starshimi-chastnimi-proizvodnimi.html
  • znanie.bystrickaya.ru/agacci-e-chelovek-kak-predmet-filosofii-voprosi-filosofii-1989-2.html
  • nauka.bystrickaya.ru/ulozhenie-carya-i-velikogo-knyazya-alekseya-mihajlovicha-i-zemskij-sobor-1648-1649-goda-rech-proiznesennaya-v-torzhestvennom-godichnom-sobranii-imperatorskogo-kazansko-stranica-5.html
  • college.bystrickaya.ru/2-vozmesheniya-vreda-prichinennogo-prestupleniem-po-zakonodatelstvu-gosudarstv-anglo-amerikanskoj-pravovoj-sistemi.html
  • predmet.bystrickaya.ru/research-educational-collaboration-between-russian-and-u-s-universities.html
  • vospitanie.bystrickaya.ru/zhilyo.html
  • universitet.bystrickaya.ru/statya-osnovnie-ponyatiya-statya-mestnie-publichnie-finansi.html
  • notebook.bystrickaya.ru/kak-najti-nedorogoj-variant-metodicheskoe-posobie-kak-kupit-kvartiru-za-6-mesyacev-s-dohodom-semi-20-000-rublej.html
  • knigi.bystrickaya.ru/sekretnie-vojni-sovetskogo-soyuza-stranica-6.html
  • assessments.bystrickaya.ru/delo-hodorkovskogo-chto-v-suhom-ostatke-radio-12-mayak-novosti-24-05-2005-16-00-00-12.html
  • reading.bystrickaya.ru/mentalnij.html
  • knigi.bystrickaya.ru/russkoyazichnaya-literatura-belarusi-minsk-2010-stranica-8.html
  • doklad.bystrickaya.ru/vesennij-6-semestr-rabochaya-programma-f-tpu-1-2101-disciplini-inostrannij-yazik-v-sfere-professionalnoj-kommunikacii.html
  • institute.bystrickaya.ru/glava-2-zhertva-neskolko-slov-o-nazvanii-naprashivalis-neskolko-variantov-kakoe-to-vremya-v-golove-u-menya-zhuzhzhala.html
  • uchitel.bystrickaya.ru/pyatij-doklad-kassel-28-iyunya-1909-g-rudolf-shtajner.html
  • esse.bystrickaya.ru/programma-vstupitelnogo-ekzamena-v-magistraturu-po-napravleniyu-istoriya.html
  • knowledge.bystrickaya.ru/mezhpredmetnie-svyazi-vazhnejshij-faktor-kachestva-uchebnoj-deyatelnosti-formirovaniya-samostoyatelnoj-i-poznavatelnoj-deyatelnosti-uchashihsya.html
  • books.bystrickaya.ru/beskrajni-prostori-neba-nad-mirom-mislyu-chelovecheskoj-ne-obyat-ih-no-rasskazivayut-chto-prestol-gospoden-vozdvignut-pryamo-nad-ispaniej-stranica-18.html
  • lecture.bystrickaya.ru/7-desnica-bozhiya-kniga-sedmaya.html
  • report.bystrickaya.ru/indoevropejci-perevod-s-anglijskogo-g-a-nikolaev.html
  • kolledzh.bystrickaya.ru/akcentuacii-haraktera-chast-2.html
  • student.bystrickaya.ru/33-tezist-na-kant-za-bitieto-uvodni-belezhki.html
  • textbook.bystrickaya.ru/irina-kizilova-sluzhba-dlya-nastoyashih-muzhchin.html
  • spur.bystrickaya.ru/kontrolnie-voprosi-i-zadaniya-sokolova-m-v-s594-istoriya-turizma-ucheb-posobie.html
  • textbook.bystrickaya.ru/integracionnie-obedineniya-ekonomicheskih-subektov-chast-3.html
  • student.bystrickaya.ru/34-spisok-osnovnoj-i-dopolnitelnoj-literaturi-po-kursu-uchebno-metodicheskij-kompleks-moskva-2010-uchebno-metodicheskij.html
  • literature.bystrickaya.ru/diagnostika-uchebnoe-posobie-dlya-oficerov-vmf-kursantov-i-studentov-obuchayushihsya-po-programmam-podgotovki-oficerov-zapasa.html
  • composition.bystrickaya.ru/otchetnij-doklad-rektora-tgu-g-vmajera.html
  • education.bystrickaya.ru/16-tipovedenie-s-devyati-do-pyati-otto-kreger-dzhenet-tyuson-hajl-ratledzh.html
  • college.bystrickaya.ru/37klassifikaciya-schetov-buhgalterskogo-ucheta-po-ekonomicheskomu-soderzhaniyu.html
  • knowledge.bystrickaya.ru/obem-uchebnoj-nagruzki-36-chas-lekcii-36-chas-laboratornie-raboti-36-chas-samostoyatelnaya-rabota-kursovaya.html
  • knowledge.bystrickaya.ru/neofrejdizm-eriha-fromma.html
  • university.bystrickaya.ru/glava-pervaya-kniga-prednaznachena-dlya-teh-kto-stremitsya-ovladet-novoj-unikalnoj-sistemoj-kouchinga-koaktivnim.html
  • © bystrickaya.ru
    Мобильный рефератник - для мобильных людей.