ФЕДЕРАЛЬНОЕ КАЗЕННОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ СРЕДНЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«КИНЕШЕМСКИЙ
ТЕХНОЛОГИЧЕСКИЙ ТЕХНИКУМ-ИНТЕРНАТ»
МИНИСТЕРСТВА ТРУДА РОССИИ
Методические
указания к созданию функциональной спецификации программного компонента для
специальности 230115
Автор: преподаватель Тумина И.Б.
Кинешма,
2013
1.Теоретические
сведения.
С учетом
назначения функциональной спецификации ПС и тяжелых последствий неточностей и
ошибок в этом документе, функциональная спецификация должна быть математически
точной. Это не означает, что она должна быть формализована настолько, что по
ней можно было бы автоматически генерировать программы, решающие поставленную
задачу. А означает лишь, что она должна базироваться на понятиях, построенных
как математические объекты, и утверждениях, однозначно понимаемых
разработчиками ПС. Достаточно часто функциональная спецификация формулируется
на естественном языке. Тем не менее, использование математических методов и
формализованных языков при разработке функциональной спецификации весьма
желательно, поэтому этим вопросам будет посвящена отдельная лекция.
Функциональная
спецификация как правило состоит из трех частей:
- описания
внешней информационной среды, к которой должны применяться программы
разрабатываемой ПС;
- определение
функций ПС, определенных на множестве состояний этой информационной среды
(такие функции будем называть внешними функциями ПС);
- описание
нежелательных (исключительных) ситуаций, которые могут возникнуть при
выполнении программ ПС, и реакций на эти ситуации, которые должны
обеспечить соответствующие программы.
В первой части
должны быть определены на концептуальном уровне все используемые каналы ввода и
вывода и все информационные объекты, к которым будет применяться разрабатываемое
ПС, а также существенные связи между этими информационными объектами. Примером
описания информационной среды может быть концептуальная схема базы данных .
Во второй
части вводятся обозначения всех определяемых функций, специфицируются все
входные данные и результаты выполнения каждой определяемой функции, включая
указание их типов и заданий всех соотношений (или ограничений), которым должны
удовлетворять эти данные и результаты. И, наконец, определяется семантика
каждой из этих функций, что является наиболее трудной задачей функциональной
спецификации ПС. Обычно эта семантика описывается неформально на естественном
языке - примерно так, как это делается при описании семантики многих языков
программирования. Эта задача может быть в ряде случаев существенно облегчена
при достаточно четком описании внешней информационной среды, если внешние
функции задают какие-либо манипуляции с ее объектами.
В третьей части
должны быть перечислены все существенные случаи, когда ПС не сможет нормально
выполнить ту или иную свою функцию (с точки зрения внешнего наблюдателя).
Примером такого случая может служить обнаружение ошибки во время взаимодействия
с пользователем, или попытка применить какую-либо функцию к данным, не
удовлетворяющим соотношениям, указанным в ее спецификации, или получение
результата, нарушающего заданное ограничение. Для каждого такого случая должна
быть определена (описана) реакция ПС.
2.
Содержание отчета функциональной спецификации программного компонента
Документ
должен содержать следующие разделы:
Введение
1. Видение и рамки
2. История
проекта
3. Цели дизайна
3.1. Требования пользователя
3.2. Системные требования
3.3. Пользовательский
интерфейс и поведение программы
4. Требования
к инсталляции и деинсталляции
5. Риски
Информация по разделу
видению/рамкам проекта должна сконцентрировать внимание читателя на
ключевых элементах решения. Данная информация – стратегический элемент решения,
который необходимо понять, прежде чем начинать вникать в детали функциональной
спецификации. Включение этой информации формирует общее видение проекта и общие
ожидания от его реализации.
Приведите здесь
обзор концепции (видения) и рамок проекта.
Например, наш
проект направлен на удовлетворение нужд заказчика. Для удовлетворения нужд мы
пишем программную систему, которая позволит заказчику:
- Управлять
рейсами и аэропортами
- Даст
возможность клиентам компании подбирать маршруты в зависимости денных
критериев
Первую версию
системы мы должны сдать в течении трех месяцев.
На первую систему
есть существенные ограничения:
- Система
не распределена
- Нет
разграничения прав между менеджерами и пользователями
- Весь
интерфейс представлен в одном окне
Система должна
демонстрировать визуальные формы и способы хранения и взаимодействия данных.
Раздел «История проекта» перечисляет ключевые
события в процессе создания решения в хронологической последовательности, так,
как их видит команда. Перечисляются важные принятые решения. Данная информация
может оказаться полезной для оценки того, почему проект был успешным (или, напротив,
провальным) и почему. Подобный анализ будет крайне полезен при создании
подобных решений в будущем.
Приведите здесь
основные события и важные решения в процессе реализации проекта.
Например,
|
день
от начала проекта
|
События
|
|
1
|
принято
решение о начале проекта
|
|
2
|
организованно
обучение
|
|
2
|
ядро
проектной группы сформировано
|
|
15
|
Черновой
вариант концепции проекта составлен
|
|
25
|
Верификация
технологий
|
|
32
|
Базовая
версия функциональной спецификации создана
|
Раздел “Цели
дизайна “ обобщает выполненный ранее анализ требований.
Формулируются требования с точки зрения заказчика, пользователей, аппаратного и
программного окружения. Данные требования, сформулированные ранее в общем виде,
должны быть скорректированы в требования к решению и его отдельным компонентам
в терминах команды разработчиков. В результате происходит уточнение целей
проекта, сформулированных ранее в видении/рамках.
Раздел «Требование пользователя» перечисляет выявленные
требования к решению с точки зрения заказчика и конечных пользователей.
Приведите здесь
требования заказчика и конечных пользователей.
Пример оформления
этого раздела:
С точки зрения
менеджеров
- Наличие
опции добавления/удаления
аэропортов
- Наличие
опции добавления/удаления
рейсов
- Наличие
опции просмотра данных аэропорта
- Данные
о наличии рейсов
- Информация
о рейсах
- Просмотр
количества забронированных билетов на рейсы
С точки зрения
покупателей
- Наличие
опции поиска маршрута по заданным параметрам
- Простой
диалог заказа
-
В разделе “Системные требования” сформулируйте
здесь требования к аппаратному и программному окружению.
Пример оформления
этого раздела:
На
стороне менеджеров:
- P4 300 MHz или
аналогичный
- RAM
256 Mb
- Video
RAM 32 Mb
- Установленный
java
Runtime
На
стороне клиентов:
- P4 300 MHz или
аналогичный
- RAM
128 Mb
- Video
RAM 32 Mb
- Установленный
java
Runtime
Пользовательский интерфейс и поведение программы.
·
В этом разделе вы описываете, как функция будет доступна
пользователю. Т.е. вы тут указываете все интерфейсные решения, с помощью
которых пользователь будет использовать функцию. Это видимая, для пользователя,
часть функции. Здесь, как правило, описывается:
·
- команды меню
- кнопки на панели инструментов
- диалоговые окна
- новые элементы в существующих диалогах
- элементы документа программы, и т.д.
В разделе “Требования
к инсталляции и деинсталляции” следует привести
информацию по тому, как будет осуществляться инсталляция/деинсталляция
решения. Сформулируйте требования к этим процессам.
Этот раздел можно
оформить следующим образом:
Для инсталляции
первой системы необходимо чтобы у пользователя стоял java Runtime.
Если java Runtime
стоит, то для демонстрации системы необходимо просто скопировать в одну папку
исполняемые файлы и запустить jar
пакет.
Для удаления
системы необходимо просто удалить папку с программой.
В разделе “Риски “ необходимо указать риски,
ассоциированные с функциональной спецификацией. Для этих рисков имеет смысл
привести информацию о мерах по их предотвращению, а также способы реагирования,
если неприятность все-таки произойдет.
Пример оформления
в таблице 1.
Таблица
1.
|
Первопричина
|
Условие
|
Последствие
|
Приносимый
ущерб
|
|
Организация
работы
|
Не успеем сдать
проект во время
|
Теряем доверие
заказчика
|
Не получаем
дальнейшее финансирование
|
|
Заказчик может
менять требования
|
Заказчик изменит
требования
|
Изменение
технического задания
|
Вследствие
введенного плана управления изменениями ущерб должен отсутствовать
|
|
Плохо
организованный процесс тестирования
|
Из-за
необнаруженной вовремя ошибки система нанесет урон заказчику
|
На
время устранения ошибки пассажиры не смогут заказывать билеты через систему.
Потребуется “ручная” работа персонала. Компания потеряет возможных клиентов и
часть прибыли.
|
Потеря денег со
стороны нашей компании и потеря доверия заказчика
|
Оставьте свой комментарий
Авторизуйтесь, чтобы задавать вопросы.