Методические указания по подготовке и защите отчетов на специализации "Прикладная математика. Системное программирование". Кленин А.С. - 16 стр.

UptoLike

Составители: 

16
библиотек допускается объединение разделов 5 и 6. Алгоритм следует называть только в
случае, если он фиксирован внешними требованиями (например, «решать систему линей-
ных уравнений», либо «решать систему линейных уравнений методом Гаусса»).
Раздел «6. Требования к интерфейсу»
Определить требования к общему виду и платформе интерфейса (например, «интер-
фейс командной строки» или «Windows-интерфейс», или «Web-интерфейс»). Если система
обладает несколькими интерфейсами, перечислить их и указать, какая часть функциональ-
ности доступна через каждый из них.
Указать специальные требования к интерфейсу, накладываемые составом целевой
аудитории, ограничениями технических средств либо требованиями заказчика. Например
:
«интерфейс должен быть доступен для использования слепыми людьми», «интерфейс
должен функционировать при использовании браузера Internet Explorer 3.0», «все функции
интерфейса должны быть доступны при использовании для ввода только клавиатуры» и
т. п.
Описать структуру интерфейса, основные команды или органы управления, наиболее
тесно связанные с функциональностью системы. При необходимости использовать модели
экрана.
Если описывается
интерфейс библиотеки подпрограмм, указать прототип каждой
доступной внешнему пользователю функции, класса или и структуры данных. Для каждой
функции указать назначение и, где необходимо, смысл и диапазон допустимых значений
параметров. В случае небольшого объёма библиотеки допустимо объединение с разделом
5, а для библиотеки классов и с разделом 4. В таком случае структурирование подразделов
производится по функциям или классам.
Привести одну или более динамическую диаграмму (например, диаграмму состоя-
ний).
Раздел «7. Прочие требования»
Указать требования к нефункциональным характеристикам системы, отличающиеся
от общепринятых либо имеющие критическое значения для успешной реализации проекта.
Любой из подразделов, а также и весь раздел можно опустить в случае отсутствия соответ-
ствующих требований.
Раздел «7.1. Требования к надёжности»
Оценить вероятность возникновения, возможные последствия и убытки от нештат-
ных ситуаций (рисков), могущих возникнуть в связи с использованием системы, в том
числе:
отказ оборудования;
обнаружение ошибок разной степени тяжести;
утеря или повреждение данных;
нарушение безопасности;
резкое изменение экономических условий или производственного процесса.
Сделать вывод о наличии
или отсутствии необходимости мероприятий по управле-
нию данными рисками. Перечислить и описать список мероприятий, для каждого меро-
приятия указать: процедуру проведения, предполагаемую периодичность, категории поль-
зователей, ответственных за его выполнение. Например: «ежедневное резервное копиро-
вание базы данных на магнитную ленту производится в конце рабочего дня Оператором»
библиотек допускается объединение разделов 5 и 6. Алгоритм следует называть только в
случае, если он фиксирован внешними требованиями (например, «решать систему линей-
ных уравнений», либо «решать систему линейных уравнений методом Гаусса»).

     Раздел «6. Требования к интерфейсу»
      Определить требования к общему виду и платформе интерфейса (например, «интер-
фейс командной строки» или «Windows-интерфейс», или «Web-интерфейс»). Если система
обладает несколькими интерфейсами, перечислить их и указать, какая часть функциональ-
ности доступна через каждый из них.
      Указать специальные требования к интерфейсу, накладываемые составом целевой
аудитории, ограничениями технических средств либо требованиями заказчика. Например:
«интерфейс должен быть доступен для использования слепыми людьми», «интерфейс
должен функционировать при использовании браузера Internet Explorer 3.0», «все функции
интерфейса должны быть доступны при использовании для ввода только клавиатуры» и
т. п.
      Описать структуру интерфейса, основные команды или органы управления, наиболее
тесно связанные с функциональностью системы. При необходимости использовать модели
экрана.
      Если описывается интерфейс библиотеки подпрограмм, указать прототип каждой
доступной внешнему пользователю функции, класса или и структуры данных. Для каждой
функции указать назначение и, где необходимо, смысл и диапазон допустимых значений
параметров. В случае небольшого объёма библиотеки допустимо объединение с разделом
5, а для библиотеки классов и с разделом 4. В таком случае структурирование подразделов
производится по функциям или классам.
      Привести одну или более динамическую диаграмму (например, диаграмму состоя-
ний).

     Раздел «7. Прочие требования»
     Указать требования к нефункциональным характеристикам системы, отличающиеся
от общепринятых либо имеющие критическое значения для успешной реализации проекта.
Любой из подразделов, а также и весь раздел можно опустить в случае отсутствия соответ-
ствующих требований.

     Раздел «7.1. Требования к надёжности»
     Оценить вероятность возникновения, возможные последствия и убытки от нештат-
ных ситуаций (рисков), могущих возникнуть в связи с использованием системы, в том
числе:
     • отказ оборудования;
     • обнаружение ошибок разной степени тяжести;
     • утеря или повреждение данных;
     • нарушение безопасности;
     • резкое изменение экономических условий или производственного процесса.
     Сделать вывод о наличии или отсутствии необходимости мероприятий по управле-
нию данными рисками. Перечислить и описать список мероприятий, для каждого меро-
приятия указать: процедуру проведения, предполагаемую периодичность, категории поль-
зователей, ответственных за его выполнение. Например: «ежедневное резервное копиро-
вание базы данных на магнитную ленту производится в конце рабочего дня Оператором»

                                             16