ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9501
Скачиваний: 184
при
возникновении
сбоя
продолжить
вычисления
с
данными
,
записанными
в
последней
контрольной
точке
.
Передача
информации
по
сетям
также
аппаратно
контролируется
,
кроме
того
,
обычно
применяется
специальное
помехозащитное
кодирование
,
которое
позволяет
находить
и
исправлять
ошибки
передачи
данных
.
Однако
полностью
исключить
ошибки
технических
средств
невозможно
,
поэтому
в
тех
случаях
,
когда
требования
к
надежности
высоки
,
обычно
используют
дублирование
систем
,
при
котором
две
системы
решают
одну
и
ту
же
задачу
параллельно
,
периодически
сверяя
полученные
результаты
.
Часто
самым
«
ненадежным
элементом
»
современных
систем
являются
люди
.
Уже
хорошо
известно
,
что
в
условиях
монотонной
работы
за
пультом
вычислительной
установки
операторы
допускают
большое
количество
ошибок
.
Известны
и
средства
,
позволяющие
снизить
количество
ошибок
в
конкретных
ситуациях
.
Так
,
там
,
где
это
возможно
,
используют
ввод
избыточной
информации
,
позволяющий
выполнять
проверки
правильности
вводимых
данных
(
ввод
контрольных
сумм
и
т
.
п
.,
см
. § 2.7).
Кроме
этого
,
широко
используют
всякого
рода
подсказки
,
когда
информацию
необходимо
не
вводить
,
а
выбирать
из
некоторого
списка
и
т
.
п
.
Повышенные
требования
к
надежности
предъявляют
при
разработке
систем
управления
,
функционирующих
в
режиме
реального
времени
,
когда
вычисления
выполняются
параллельно
с
технологическими
процессами
.
Существенно
это
требование
и
для
научно
-
технических
систем
и
баз
данных
.
Для
обеспечения
проверяемости
следует
документально
фиксировать
исходные
данные
,
установленные
режимы
и
прочую
информацию
,
которая
влияет
на
получаемые
результаты
.
Особенно
это
существенно
в
случаях
,
когда
данные
поступают
непосредственно
от
датчиков
.
Если
такие
данные
не
выводить
вместе
с
результатами
,
то
последние
нельзя
будет
проверить
.
Точность
или
величина
погрешности
результатов
зависит
от
точности
исходных
данных
,
степени
адекватности
используемой
модели
,
точности
выбранного
метода
и
погрешности
выполнения
операций
в
компьютере
.
Требования
к
точности
результатов
обычно
наиболее
жесткие
для
систем
управления
технологическими
процессами
(
например
,
химическими
)
и
систем
навигации
(
например
,
система
управления
стыковкой
космических
аппаратов
).
Обеспечение
защищенности
(
конфиденциальности
)
информации
,
используемой
проектируемой
системой
,
отдельная
и
в
условиях
наличия
сетей
достаточно
сложная
задача
.
Помимо
чисто
программных
средств
защиты
,
таких
как
кодирование
информации
и
идентификация
пользователя
,
для
обеспечения
защищенности
используют
также
специальные
организационные
приемы
.
Наиболее
жесткие
требования
предъявляются
к
системам
,
в
которых
хранится
информация
,
связанная
с
государственной
и
коммерческой
тайной
.
Требование
программной
совместимости
может
варьироваться
от
возможности
совместной
установки
с
указанным
программным
обеспечением
до
обеспечения
взаимодействия
с
ним
,
например
обмена
данными
и
т
.
п
.
Чаще
всего
приходится
обеспечивать
функционирование
программного
обеспечения
под
управлением
заданной
операционной
системы
.
Однако
может
потребоваться
предусмотреть
получение
данных
из
какой
-
то
программы
или
передачу
некоторых
данных
ей
.
В
этом
случае
необходимо
точно
оговорить
форматы
передаваемых
данных
.
Требование
аппаратной
совместимости
в
основном
формулируют
в
виде
минимально
возможной
конфигурации
оборудования
,
на
котором
будет
работать
программное
обеспечение
.
Если
предполагается
использование
нестандартного
оборудования
,
то
для
него
должны
быть
указаны
интерфейсы
или
протоколы
обмена
информацией
.
При
этом
для
операционных
систем
класса
Windows
нестандартными
считают
устройства
,
для
которых
в
системе
отсутствуют
драйверы
-
программы
,
обеспечивающие
взаимодействие
устройства
с
операционной
системой
.
Эффективность
системы
обычно
оценивается
отдельно
по
каждому
ресурсу
вычислительной
установки
.
Часто
используют
следующие
критерии
:
•
время
ответа
системы
(
обычно
отнесенное
к
быстродействию
используемого
оборудования
) -
для
систем
,
взаимодействующих
с
пользователем
в
интерактивном
режиме
,
и
систем
реального
времени
;
•
объем
оперативной
памяти
-
для
продуктов
,
работающих
в
системах
с
ограниченным
объемом
оперативной
памяти
,
например
MS DOS;
•
объем
внешней
памяти
-
для
продуктов
,
интенсивно
использующих
внешнюю
память
,
например
баз
данных
;
•
количество
обслуживаемых
внешних
устройств
-
для
продуктов
,
осуществляющих
интенсивное
взаимодействие
с
внешними
устройствами
,
например
датчиками
.
Требования
эффективности
могут
противоречить
друг
другу
.
Например
,
чтобы
уменьшить
время
выполнения
некоторого
фрагмента
программы
,
может
потребоваться
дополнительный
объем
оперативной
памяти
.
Адаптируемость
,
по
сути
дела
,
оценивает
технологическое
качество
программного
обеспечения
,
поэтому
оценить
эту
характеристику
количественно
практически
невозможно
.
Можно
только
констатировать
,
что
при
создании
продукта
использованы
технологии
и
специальные
приемы
,
облегчающие
его
модернизацию
.
Требование
повторной
входимости
обычно
предъявляется
к
программному
обеспечению
,
резидентно
загруженному
в
оперативную
память
,
например
драйверам
.
Для
обеспечения
данного
требования
необходимо
так
организовать
программу
,
чтобы
никакие
ее
исходные
данные
не
затирались
в
процессе
выполнения
или
восстанавливались
в
начале
или
при
завершении
каждого
вызова
.
Требование
реентерабельности
является
более
жестким
,
чем
повторная
входимость
,
так
как
в
этом
случае
все
данные
,
изменяемые
программой
в
процессе
выполнения
,
должны
быть
выделены
в
специальный
блок
,
копия
которого
создается
для
каждого
процесса
при
вызове
программы
.
Сложность
многих
программных
систем
не
позволяет
сразу
сформулировать
четкие
требования
к
ним
.
Обычно
для
перехода
от
идеи
создания
некоторого
программного
обеспечения
к
четкой
формулировке
требований
,
которые
могут
быть
занесены
в
техническое
задание
,
необходимо
выполнить
предпроектные
исследования
в
области
разработки
.
3.3.
Предпроектные
исследования
предметной
области
Целью
предпроектных
исследований
является
преобразование
общих
нечетких
знаний
о
предназначении
будущего
программного
обеспечения
в
сравнительно
точные
требования
к
нему
.
Существуют
два
варианта
неопределенности
:
•
неизвестны
методы
решения
формулируемой
задачи
-
такого
типа
не
определенности
обычно
возникают
при
решении
научно
-
технических
задач
;
•
неизвестна
структура
автоматизируемых
информационных
процессов
-
обычно
встречается
при
построении
автоматизированных
систем
управления
предприятиями
.
В
первом
случае
во
время
предпроектных
исследований
определяют
возможность
решения
поставленной
задачи
и
методы
,
позволяющие
получить
требуемый
результат
,
что
может
потребовать
соответствующих
научных
исследований
как
фундаментального
,
так
и
прикладного
характера
,
разработки
и
исследования
новых
моделей
объектов
реального
мира
.
Во
втором
случае
определяют
:
•
структуру
и
взаимосвязи
автоматизируемых
информационных
процессов
;
•
распределение
функций
между
человеком
и
системой
,
а
также
между
аппаратурой
и
программным
обеспечением
;
•
функции
программного
обеспечения
;
внешние
условия
его
функционирования
и
особенности
его
интерфейсов
,
как
с
пользователями
,
так
и
при
необходимости
-
с
аппаратной
частью
;
•
требования
к
программным
и
информационным
компонентам
,
необходимые
аппаратные
ресурсы
,
требования
к
базам
данных
и
физические
характеристики
программных
компонент
.
Результаты
предпроектных
исследований
предметной
области
используют
в
процессе
разработки
технического
задания
.
3.4.
Разработка
технического
задания
Техническое
задание
представляет
собой
документ
,
в
котором
сформулированы
основные
цели
разработки
,
требования
к
программному
продукту
,
определены
сроки
и
этапы
разработки
и
регламентирован
процесс
приемно
-
сдаточных
испытаний
.
В
разработке
технического
задания
участвуют
как
представители
заказчика
,
так
и
представители
исполнителя
.
В
основе
этого
документа
лежат
исходные
требования
заказчика
,
анализ
передовых
достижений
техники
,
результаты
выполнения
научно
-
исследовательских
работ
,
предпроектных
исследований
,
научного
прогнозирования
и
т
.
п
.
На
рис
. 3.2
схематически
показаны
основные
факторы
,
определяющие
характеристики
разрабатываемого
программного
обеспечения
.
Такими
факторами
являются
:
•
исходные
данные
и
требуемые
результаты
,
которые
определяют
функции
программы
или
системы
;
•
среда
функционирования
(
программная
и
аппаратная
) -
может
быть
задана
,
а
может
выбираться
для
обеспечения
параметров
,
указанных
в
техническом
задании
;
•
возможное
взаимодействие
с
другим
программным
обеспечениеми
/
или
специальными
техническими
средствами
-
также
может
быть
определено
,
а
может
выбираться
исходя
из
набора
выполняемых
функций
.
Разработка
технического
задания
выполняется
в
следующей
последовательности
.
Прежде
всего
,
устанавливают
набор
выполняемых
функций
,
а
также
перечень
и
характеристики
исходных
данных
.
Затем
определяют
перечень
результатов
,
их
характеристики
и
способы
представления
.
Далее
уточняют
среду
функционирования
программного
обеспечения
:
конкретную
комплектацию
и
параметры
технических
средств
,
версию
используемой
операционной
системы
и
,
возможно
,
версии
и
параметры
другого
установленного
программного
обеспечения
,
с
которым
предстоит
взаимодействовать
будущему
программному
продукту
.
В
случаях
,
когда
разрабатываемое
программное
обеспечение
собирает
и
хранит
некоторую
информацию
или
включается
в
управление
каким
-
либо
техническим
процессом
,
необходимо
также
четко
регламентировать
действия
программы
в
случае
сбоев
оборудования
и
энергоснабжения
.
На
техническое
задание
существует
стандарт
ГОСТ
19.201-78 «
Техническое
задание
.
Требования
к
содержанию
и
оформлению
».
В
соответствии
с
этим
стандартом
техническое
задание
должно
содержать
следующие
разделы
:
•
введение
;
•
основания
для
разработки
;
•
назначение
разработки
;
•
требования
к
программе
или
программному
изделию
;
•
требования
к
программной
документации
;
•
технико
-
экономические
показатели
;
•
стадии
и
этапы
разработки
;
•
порядок
контроля
и
приемки
.
При
необходимости
допускается
в
техническое
задание
включать
приложения
(
см
.
правила
оформления
программной
документации
в
§ 11.5).
Рассмотрим
более
подробно
содержание
каждого
раздела
.
Введение
должно
включать
наименование
и
краткую
характеристику
области
применения
программы
или
программного
продукта
,
а
также
объекта
(
например
,
системы
)
в
котором
предполагается
их
использовать
.
Основное
назначение
введения
-
продемонстрировать
актуальность
данной
разработки
и
показать
,
какое
место
эта
разработка
занимает
в
ряду
подобных
.
Раздел
Основания
для
разработки
должен
содержать
наименование
документа
,
на
основании
которого
ведется
разработка
,
организации
,
утвердившей
данный
документ
,
и
наименование
или
условное
обозначение
темы
разработки
.
Таким
документом
может
служить
план
,
приказ
,
договор
и
т
.
п
.
Раздел
Назначение
разработки
должен
содержать
описание
функционального
и
эксплуатационного
назначения
программного
продукта
с
указанием
категорий
пользователей
.
Раздел
Требования
к
программе
или
программному
изделию
должен
включать
следующие
подразделы
:
•
требования
к
функциональным
характеристикам
;
•
требования
к
надежности
;
•
условия
эксплуатации
;
•
требования
к
составу
и
параметрам
технических
средств
;
•
требования
к
информационной
и
программной
совместимости
;
•
требования
к
маркировке
и
упаковке
;
•
требования
к
транспортированию
и
хранению
;
•
специальные
требования
.
Наиболее
важным
из
перечисленных
выше
является
подраздел
Требования
к
функциональным
характеристикам
.
В
этом
разделе
должны
быть
перечислены
выполняемые
функции
и
описаны
состав
,
характеристики
и
формы
представления
исходных
данных
и
результатов
.
В
этом
же
разделе
при
необходимости
указывают
критерии
эффективности
:
максимально
допустимое
время
ответа
системы
,
максимальный
объем
используемой
оперативной
и
/
или
внешней
памяти
и
др
.
Примечание
.
Если
разработанное
программное
обеспечение
не
будет
выполнять
указанных
в
техническом
задании
функций
,
то
оно
считается
не
соответствующим
техническому
заданию
,
т
.
е
.
неправильным
с
точки
зрения
критериев
качества
(
см
. § 2.2).
Универсальность
будущего
продукта
также
обычно
специально
не
оговаривается
,
но
подразумевается
.
В
подразделе
Требования
к
надежности
указывают
уровень
надежности
,
который
должен
быть
обеспечен
разрабатываемой
системой
(
см
. § 3.2)
и
время
восстановления
системы
после
сбоя
.
Для
систем
с
обычными
требованиями
к
надежности
в
этом
разделе
иногда
регламентируют
действия
разрабатываемого
продукта
по
увеличению
надежности
результатов
(
контроль
входной
и
выходной
информации
,
создание
резервных
копий
промежуточных
результатов
и
т
.
п
.).
В
подразделе
Условия
эксплуатации
,
указывают
особые
требования
к
условиям
эксплуатации
:
температуре
окружающей
среды
,
относительной
влажности
воздуха
и
т
.
п
.
Как
правило
,
подобные
требования
формулируют
,
если
разрабатываемая
система
будет
эксплуатироваться
в
нестандартных
условиях
или
использует
специальные
внешние
устройства
,
например
для
хра
-
нения
информации
.
Здесь
же
указывают
вид
обслуживания
,
необходимое
количество
и
квалификация
персонала
.
В
противном
случае
допускается
указывать
,
что
требования
не
предъявляются
.
В
подразделе
Требования
к
составу
и
параметрам
технических
средств
указывают
необходимый
состав
технических
средств
с
указанием
их
основных
технических
характеристик
:
тип
микропроцессора
,
объем
памяти
,
наличие
внешних
устройств
и
т
.
п
.
При
этом
часто
указывают
два
варианта
конфигурации
:
минимальный
и
рекомендуемый
.
В
подразделе
Требования
к
информационной
и
программной
совместимости
при
необходимости
можно
задать
методы
решения
,
определить
язык
или
среду
программирования
для
разработки
,
а
также
используемую
операционную
систему
и
другие
системные
и
пользовательские
программные
средства
,
с
которым
должно
взаимодействовать
разрабатываемое
программное
обеспечение
.
В
этом
же
разделе
при
необходимости
указывают
,
какую
степень
защиты
информации
необходимо
предусмотреть
.
В
разделе
Требования
к
программной
документации
указывают
необходимость
наличия
руководства
программиста
,
руководства
пользователя
,
руководства
системного
программиста
,
пояснительной
записки
и
т
.
п
.
На
все
эти
типы
документов
также
существуют
ГОСТы
.
Правила
их
составления
рассмотрены
в
гл
. 11.
В
разделе
Технико
-
экономические
показатели
рекомендуется
указывать
ориентировочную
экономическую
эффективность
,
предполагаемую
годовую
потребность
и
экономические
преимущества
по
сравнению
с
существующими
аналогами
.
В
разделе
Стадии
и
этапы
разработки
указывают
стадии
разработки
,
этапы
и
содержание
работ
с
указанием
сроков
разработки
и
исполнителей
.
В
разделе
Порядок
контроля
и
приемки
указывают
виды
испытаний
и
общие
требования
к
приемке
работы
.
В
приложениях
при
необходимости
приводят
:
перечень
научно
-
исследовательских
работ
,
обосновывающих
разработку
;
схемы
алгоритмов
,
таблицы
,
описания
,
обоснования
,
расчеты
и
другие
документы
,
которые
следует
использовать
при
разработке
.
В
зависимости
от
особенностей
разрабатываемого
продукта
разрешается
уточнять
содержание
разделов
,
т
.
е
.
использовать
подразделы
,
вводить
новые
разделы
или
объединять
их
.
В
случаях
,
если
какие
-
либо
требования
,
предусмотренные
техническим
заданием
,
заказчик
не
предъявляет
,
следует
в
соответствующем
месте
указать
«
Требования
не
предъявляются
».
Разработка
технического
задания
-
процесс
трудоемкий
,
требующий
определенных
навыков
.
Наиболее
сложным
,
как
правило
,
является
четкое
формулирование
основных
разделов
:
введения
,
назначения
и
требований
к
программному
продукту
.
В
качестве
примеров
рассмотрим
два
технических
задания
на
выполнение
курсового
проектирования
,
составленных
по
сокращенной
схеме
,
и
сравнительно
полное
техническое
задание
на
выполнение
госбюджетной
научно
-
исследовательской
работы
.
Пример
3.1
.
Разработать
техническое
задание
на
программный
продукт
,
предназначенный
для
наглядной
демонстрации
школьникам
графиков
функций
одного
аргумента
у
= f (x).
Разрабатываемая
программа
должна
рассчитывать
таблицу
значений
и
строить
график
функций
на
заданном
отрезке
по
заданной
формуле
и
менять
шаг
аргумента
и
границы
отрезка
.
Кроме
этого
,
программа
должна
запоминать
введенные
формулы
.
На
рис
. 3.3
представлен
пример
титульного
листа
технического
задания
на
учебный
программный
продукт
.
Ниже
приведен
его
текст
.
1.
ВВЕДЕНИЕ
Настоящее
техническое
задание
распространяется
на
разработку
программы
построения
графиков
и
таблиц
значений
функций
одной
переменной
,
предназначенной
для
использования
школьниками
старших
классов
.
В
школьном
курсе
элементарной
алгебры
тема
анализа
функций
является
одной
из
самых
сложных
.
При
изучении
данной
темы
школьники
должны
научиться
исследовать
и
строить
графики
функций
одной
переменной
,
используя
все
известные
характеристические
точки
функции
,
включая
корни
,
точки
разрыва
первого
и
второго
рода
и
т
.
д
.
Существующее
программное
обеспечение
,
которое
может
решать
подобные
задачи
,
является
универсальным
,
например
Eurica
или
MathCad.
Оно
имеет
сравнительно
сложный
пользовательский
интерфейс
,
ориентированный
на
пользователя
,
прослушавшего
,
как
минимум
,
институтский
курс
высшей
математики
,
что
делает
использование
подобных
средств
школьниками
невозможным
.
Разрабатываемая
программа
позволит
школьникам
проверить
свои
знания
при
изучении
указанной
темы
.