Московский Государственный Технический Университет им. Н. Э. Баумана УТВЕРЖДАЮ _________________________________________

Московский Государственный Технический Университет им. Н. Э. Баумана
наименование организации-разработчика
УТВЕРЖДАЮ
_________________________________________
руководитель (должность, наименование предприятия-заказчика)
Власов А.И.
личная подпись
.
расшифровка подписи
_________________________________________
печать
_________________________________________
дата
ИСПОЛНИТЕЛЬ
Качанов В.И. .
личная подпись
расшифровка подписи
_________________________________________
печать
_________________________________________
дата
УНИВЕРСАЛЬНЫЙ XML КОНВЕРТОР ВИЗУАЛЬНЫХ СХЕМ
СЛОЖНЫХ СИСТЕМ
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
На 8 листах
Действует с ____________
2
СОДЕРЖАНИЕ
1 ВВЕДЕНИЕ
3
1.1 Наименование программного изделия
3
1.2 Краткая характеристика области применения Конвертора
3
2 ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ
3
3 НАЗНАЧЕНИЕ РАЗРАБОТКИ
3
3.1 Функциональное назначение Конвертора
3
3.2 Эксплуатационное назначение Конвертора
3
4 ТРЕБОВАНИЯ К ПРОГРАММЕ
3
4.1 Требования к функциональным характеристикам
3
4.1.1 Требования к структуре и функционированию системы
3
4.1.2 Требования к защите информации от несанкционированного доступа
3
4.1.3 Требования к эргономике и технической эстетике
3
4.1.4 Требования к функциям, выполняемым модулем просмотра и редактирования
визуальных схем
4
4.1.5 Требования к функциям, выполняемым модулем логического представления
4
4.1.6 Требования к функциям,
визуальных схем в файлы
выполняемым
модулем
экспорта/импорта 4
4.2 Требования к надежности
4
4.3 Условия эксплуатации
4
4.4 Требования к составу и параметрам технических средств
4
4.5 Требования к информационной и программной совместимости
5
4.6 Требования к маркировке и упаковке
5
4.7 Требования к транспортированию и хранению
5
5 ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
5
6 ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ
5
7 СТАДИИ И ЭТАПЫ РАЗРАБОТКИ
5
8 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ
6
3
1 ВВЕДЕНИЕ
1.1 Наименование программного изделия
Универсальный XML конвертор визуальных схем сложных систем (далее Конвертор).
1.2 Краткая характеристика области применения Конвертора
Конвертор предоставляет единую систему программных средств для создания структурнофункциональных и информационных моделей технологических процессов сложных технических
систем, накопления и редактирования знаний об этих процессах, охватывая таким образом все
этапы проектирования и формализуя процесс проектирования, и может быть использован в
конструкторско-технологической деятельности, характеризующейся применением визуальных
схем на всех этапах процесса проектирования.
2 ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ
Основанием для разработки является задание на дипломную работу, подписанное
руководителем проекта и исполнителем.
3 НАЗНАЧЕНИЕ РАЗРАБОТКИ
3.1 Функциональное назначение Конвертора
Конвертор должен обеспечивать создание, редактирование и хранение знаний и данных о
сложных технических системах в формате XML, объединяющем структурно-функциональную,
информационную и объектную составляющие.
Под сложной технической системой понимается система, модель которой не содержит
достаточной для эффективного управления этой системой информации.
3.2 Эксплуатационное назначение Конвертора
Конвертор должен предоставлять графический редактор для создания, редактирования
визуальных схем технологических процессов сложных систем в виде IDEF и UML диаграмм,
создания пользовательских визуальных схем сложных систем, сохранения результатов работы в
формате XML, загрузки и конвертации шаблонов в формате XML в визуальные схемы.
4 ТРЕБОВАНИЯ К ПРОГРАММЕ
4.1 Требования к функциональным характеристикам
4.1.1 Требования к структуре и функционированию системы
Конвертор должен обеспечивать создание, редактирование и хранение данных о сложных
технических системах в универсальном XML формате, объединяющем структурнофункциональную, информационную и объектную составляющие.
Конвертор должен состоять из следующих основных модулей:
−
модуль просмотра и редактирования визуальных схем;
−
модуль логического представления;
−
модуль экспорта/импорта визуальных схем в файлы.
4.1.2 Требования к защите информации от несанкционированного доступа
Не предъявляются.
4.1.3 Требования по эргономике и технической эстетике
Интерфейс пользователя должен обеспечивать выполнение всех функций Конвертора,
доступных данному пользователю. Интерфейс должен быть единообразным для всех подсистем,
быть удобным и интуитивно понятным, должен базироваться на графическом оконном
интерфейсе.
4
Пользователь
Конвертора
должен получать информацию как об успешном
завершении операций, так и о возникновении сбоев в ходе их выполнения или невозможности
выполнения.
4.1.4 Требования к функциям, выполняемым модулем просмотра и редактирования
визуальных схем
Модуль предоставляет пользователю интерфейс для взаимодействия с Конвертором.
Должен обеспечивать представление и навигацию по визуальным схемам структурных,
информационных и объектных моделей, а также синхронизацию моделей и их параметризацию:
при изменении параметров в модели одной группы это изменение отражается в связанных
моделях других групп. Навигация включает в себя навигацию по моделям первого уровня
(структурно-функциональные модели, информационные модели, объектные модели), второго
уровня (для структурных – IDEF0, IDEF3; для информационных – IDEF1x; для объектных – Use
Case Diagram, Class Diagram, Activity Diagram, Package Diagram, Deployment Diagram).
Модуль должен иметь встроенные инструменты для редактирования указанных выше
моделей и диаграмм для структурных, информационных и объектных групп. Также должен быть
реализован блок создания и редактирования не специфицированных визуальных схем
пользователей, который позволяет создавать любые пользовательские графические элементы и их
описания, объединять их в диаграммы и модели.
4.1.5 Требования к функциям, выполняемым модулем логического представления
Центральный модуль Конвертора, осуществляющий связь между всеми остальными.
Модуль должен представлять из себя логическое представление визуальных схем в виде
архитектуры классов на языке Java.
4.1.6 Требования к функциям, выполняемым модулем экспорта/импорта визуальных
схем в файлы
Модуль должен обеспечивать конвертацию визуальных схем в шаблоны формата XML,
экспорта и импорта файлов шаблонов формата XML.
4.2 Требования к надежности
Конвертор должен обеспечивать корректную обработку ситуаций, вызванных неверными
действиями пользователей, неверным форматом или недопустимыми значениями входных
данных. В указанных случаях Конвертор должен выдавать пользователю соответствующие
сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной
(недопустимой) команде или некорректному вводу данных.
4.3 Условия эксплуатации
Требования к условиям эксплуатации не предъявляются.
4.4 Требования к составу и параметрам технических средств
Программное обеспечение, используемое во всех компонентах Конвертора, должно быть
совместимо с ОС Windows/Unix.
Конвертор должен работать на компьютерном оборудовании с Intel-совместимой
архитектурой.
Программная реализация должна быть осуществлена с использованием современных
языков и технологий программирования.
Компьютерное оборудование должно иметь установленную JVM Hotspot версии 6 или
выше.
5
4.5 Требования к информационной и программной совместимости
Конвертор создается на языке Java версии 6. Конвертор должен поддерживать разработку
визуальных
схем,
используемых
в
конструкторско-технологической
деятельности,
удовлетворяющих следующим стандартам:
−
IDEF0 (ГОСТ Р 50.1.028-2001);
−
IDEF1x (FIPS Publication 184. IDEF1X Standard December 1993 by the Computer
Systems Laboratory of the National Institute of Standards and Technology (NIST));
−
IDEF3;
−
UML (ISO/IEC 19501:2004).
4.6 Требования к маркировке и упаковке
Не предъявляются.
4.7 Требования к транспортированию и хранению
Не предъявляются.
5 ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
Разрабатываемые программные модули должны быть самодокументированными, т. е.
тексты программ должны содержать комментарии.
Пояснительная записка объемом 100 страниц оформляется согласно ГОСТ 7.32-91 (ИСО
5966-82) «Отчет о научно-исследовательской работе. Структура и правила оформления», а также
согласно учебному пособию «Применение положений технического регламента» (Москва,
Издательство МГТУ имени Н.Э. Баумана, 2011) с использованием компьютерных текстовых
редакторов на белой бумаге формата А4 (210х297 мм) на одной стороне листа.
Используемые в документации UML, IDEF0, IDEF1x, IDEF диаграммы должны быть
выполнены по стандартам ISO/IEC 19501:2004 и ГОСТ Р 50.1.028-2001.
Графическая часть должна выполняться и оформляться в соответствии с требованиями
систем Государственных стандартов:
−
Единой системы конструкторской документации (ЕСКД);
−
Единой системы технологической документации (ЕСТД);
−
Единой системы технологической подготовки производства (ЕСТПП).
6 ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ
6.1 Основные технико-экономические требования
Результаты работы должны быть применимы в конструкторско-технологической
деятельности, характеризующейся применением визуальных схем на всех этапах процесса
проектирования.
Разработка Конвертора должна осуществляться на основе современных моделей и методов
формализованного представления знаний и обеспечивать функции автосохранения материалов
при возникновении программно-аппаратных сбоев.
7 СТАДИИ И ЭТАПЫ РАЗРАБОТКИ
Стадии и этапы разработки Конвертора определяются календарным планом выполнения
дипломной работы, подписанным руководителем проекта и исполнителем.
Исполнитель – Качанов Владимир Игоревич, студент группы ИУ4-121 МГТУ им.
Н.Э.Баумана.
Начало работ – 7 марта 2013 г.
Окончание работ – 31 мая 2013 г.
6
8
ПОРЯДОК
КОНТРОЛЯ
И ПРИЕМКИ
8.1 Порядок сдачи-приемки работ
Документация по выполненным работам представляется Заказчику на бумажном носителе в
одном экземпляре и в электронном виде на оптическом носителе в одном экземпляре.
Этап 1. Анализ технической документации на весь программный продукт.
Действия:
а) собрать всю имеющуюся по тестируемому продукту техническую документацию
(техническое задание, описания, спецификации, требования, внутренние алгоритмы работы
отдельных приложений и всей системы в целом),
б) изучив всю собранную документацию, четко сформулировать основное назначение всего
продукта,
г) с использованием информации, приведенной в теоретической части – составление тестов
и выделение тестовых случаев, выделить базовые операции каждого приложения и всего продукта
в целом, проранжировать их по частоте и степени критичности,
д) на основе пункта
г) сформировать тесты и тестовые случаи для тестирования функциональности отдельных
модулей и всего продукта в целом.
Результат Этапа 1
Подготовлены тесты (и тестовые случаи) для тестирования функциональности отдельных
модулей и всего продукта в целом.
Этап 2. Проверка запуска приложения
Действия: выполнить запуск модуля по всем предусмотренным в техническом задании
путям.
Результат Этапа 2
Запуск приложения по всем возможным путям осуществляется корректно: - если
приложение не может и не должно быть загружено по каким-либо объективным причинам
(например, для текущего сеанса нет необходимых данных), то выдается адекватное сообщение,
информирующее пользователя об ошибке и предлагающее правильный вариант ее устранения
(например, создание данных в другом приложении), система ждет ответа пользователя (например,
не пытаться открыть текущее приложение, запустить для создания данных другое и т.д.), т.е. не
происходит беспричинного с точки зрения пользователя останова или «вылета» приложения; запуск приложения, которое должно быть доступно пользователю для работы при самом первом
запуске системы или после перевхода, не сопровождается неадекватными сообщениями,
системными ошибками или последующим остановом; - после запуска приложение готово для
работы, в нем согласно технического задания установлен стартовый режим (например, режим
запроса или ожидания ввода информации, правильно расположен курсор).
Этап 3. Проверка ввода данных
Действия:
а) во все предусмотренные для ввода значений поля приложения ввести данные, формат
которых как соответствует заявленному для данного поля в техническом задании, так и не
соответствует (проверка реакции системы на «неожиданные» входные значения);
б) выполнить действие, приводящее к использованию системой введенных значений
(сохранение, поиск, переход в другое поле, расчет и т.д.).
7
Результат Этапа 3
Входные данные, удовлетворяющие формату, который указан для данного поля в
техническом задании, корректно обрабатываются (сохраняются, учитываются при поиске
информации пр.). Входные данные, НЕ удовлетворяющие формату, который указан для данного
поля в техническом задании, НЕ обрабатываются - система не производит их сохранения, не
принимает в расчеты и пр., причем она информирует пользователя о некорректных входных
данных.
Этап 4. Проверка работы списочных полей приложения
Действия:
а) проверить доступность для просмотра и выбора значений поля приложения,
поддерживающие списки,
б) выполнить действие, приводящее к использованию системой данных из списочных
полей (сохранение, поиск, переход в другое поле, расчет и т.д.),
в) проверить возможность пополнения значений списочных полей.
Результат Этапа 4
Списочные поля доступны для просмотра и выбора значения, они корректно
обрабатываются системой (сохраняются, учитываются при поиске информации, расчете пр.).
Списочные поля являются словарными терминами или именованными терминами – пополнение
списка их значений напрямую из рассматриваемого приложения возможно только в специально
оговоренных в техническом задании случаях.
Этап 5. Проверка обработки граничных значений
Действия:
а) все предусмотренные для ввода, например, числовых значений поля проверить на
граничные значения: ввести максимальное/минимальное допустимые значения, значения из их
окрестностей
б) выполнить действие, приводящее к использованию системой данных из этих полей
(сохранение, поиск, переход в другое поле, расчет и т.д.).
Результат Этапа 5
Максимальные и минимальные значения полей и значения из их окрестностей корректно
обрабатываются системой (сохраняются, учитываются при поиске информации, расчете пр.).
Этап 6. Проверка выполнения приложением/системой базовых операций
Действия: запустить приложение и выполнить все предусмотренные для него техническим
заданием базовые операции, возможный перечень операций: - создание/изменение/удаление
объекта, - выполнение поиска и режим просмотра, - работа вертикальных и горизонтальных
тулбаров, кнопок, заполнение чек-боксов, - выполнение расчетов с использованием введенной
информации и информации из БД, - и т.д.
Примечание:
фактически Этап 6 представляет собой выполнение тестов и тестовых случаев,
разработанных в Этапе 1, для проверки функциональности отдельных модулей.
Результат Этапа 6
Все базовые операции в модуле/приложении выполняются согласно техническому заданию.
Этап 7. Проверка перехода из приложения в связанные модули
Действия: выполнить переход из тестируемого модуля во все доступные по техническому
заданию связанные приложения.
8
Результат Этапа 7
Все доступные по техническому заданию переходы из текущего модуля в связанные
приложения осуществляются корректно – не выдаются никакие неадекватные сообщения или
системные ошибки, не происходит останова.
Этап 8. Проверка корректного предоставления выходных значений/результатов работы
приложения
Действия: выполнить в приложении операции, результатом которых является наглядный
результат, предоставляемый либо в самом модуле (например, результат расчета числового
значения), либо в отдельном приложении (например, файл-отчет, автоматически сохраняемый в
указанную пользователем директорию).
Результат Этапа 8
Результат выполнения каждой операции корректен (например, верный алгоритм
вычислений, верная последовательность вывода данных в файле-отчете). Причем формат и тип
выходных данных либо соответствует формату и типу входных данных, либо преобразован
согласно алгоритму работы приложения.
Этап 9. Проверка недопустимости выполнения нетехнологичных операций
Действия: попробовать выполнить в приложении операции, напрямую незапрещенные
техническим заданием, но являющиеся нетехнологичными (например, если приложение
рассчитывает курсы валют, то попробовать перевести одну валюту в саму себя, или, если это
калькулятор, то разделить на ноль).
Результат Этапа 9
Система не только предупреждает пользователя о том, что он пытается выполнить
нетехнологичную операцию, но и делает это на самых ранних этапах ее реализации, не давая
тратить время на выполнение бессмысленных действий.
Этап 10. Проверка выполнения бизнес-операций
Действия: в едином технологическом цикле провести все бизнес-операции, для выполнения
которых предназначен продукт (задействованы должны быть все реализованные приложения
системы).
Примечание:
фактически Этап 10 представляет собой выполнение тестов и тестовых случаев,
разработанных в Этапе 1, для тестирования функциональности всего продукта в целом.
Результат Этапа 10
Все бизнес-операции выполняются согласно техническому заданию.
Этап 11. Проверка переносимости продуктом различных программно-аппаратных
платформ
Действия: - запустить все стартовые приложения продукта по всем возможным путям
запуска; - в едином технологическом цикле провести самые критичные бизнес-операции, для
выполнения которых предназначен продукт. Примечание: Этап выполняется для каждой
рассматриваемой программно-аппаратной платформы.
Результат Этапа 11
Все приложения продукта корректно запускаются (нет неадекватных сообщений и
системных ошибок). Все бизнес-операции выполняются согласно техническому заданию.
9
Этап 12. Проверка эргономичности диалоговых и информационных сообщений
Действия: выполнить в модуле базовые операции, предусмотренные техническим заданием.
Результат Этапа 12
Все диалоговые и информационные сообщения, выдающиеся пользователю при работе в
приложении, адекватны и корректны, нет избыточности.
Этап 13. Проверка единообразия интерфейса приложения
Действия: сравнить реализованный интерфейс модуля с предусмотренным по техническому
заданию и интерфейсом других приложений продукта.
Результат Этапа 13
Интерфейс приложения соответствует заявленному в техническом задании, внешний вид
модуля корректно соотносится с интерфейсом остальных приложений продукта. Все стандартные
функциональные надстройки модуля (например, главное меню, кнопки перехода в связанные
модули, вертикальные и горизонтальные тулбары) выполнены в рамках поддержания
единообразия составляющих продукта.
Этап 14. Проверка логичности, адекватности и интуитивной понятности интерфейса модуля
Действия: проследить процесс выполнения основных операций, реализуемых в
приложении.
Результат Этапа 14
Интерфейс модуля реализован согласно логике выполнения его основных операций: - поля
ввода данных и списочные поля расположены согласно порядку их заполнения при подготовке к
выполнению операции (сверху вниз, слева направо), - кнопки действия сгруппированы или
рассеяны в зависимости от того, разбито ли приложение на функциональные блоки, - если
результат выводится напрямую в модуле, то, как правило, поля вывода расположены под
входными данными. Названия полей приложения и доступных действий адекватны их реальной
сущности (например, если в результате нажатия на кнопку инициируется операция изменения
объекта, то кнопка не должна назваться «Добавить», если в поле заносится информация о
стоимости оборудования, то оно не может называться «Валюта»). Интерфейс модуля интуитивно
понятен пользователю – в нем можно четко разделить область (перечень полей) для ввода данных,
выбора действия и просмотра результата (например, если в приложении рассматриваются два
связанных, но различных объекта, и есть кнопка/действие «Удалить», то должно быть однозначно
понятно, к какому объекту и каким образом ее можно отнести). Присутствуют и во всех модулях
корректно и единообразно оформлены всплывающие подсказки к рисункам, кнопкам, полям и пр.
Этап 15. Проверка эргономики всего продукта в целом
Действия: в едином технологическом цикле провести все бизнес-операции, для выполнения
которых предназначен продукт (задействованы должны быть все реализованные приложения
системы) и проверить этапы 12-14.
Результат Этапа 15
Результат аналогичен результату Этапов 12-14.
Примечание.
Тестирование проводится для программных продуктов - информационных систем, в
которых: - используется защита приложений от несанкционированных доработок путем генерации
уникальных ключей, - осуществляется формирование и хранение конфиденциальной информации
(коды доступов, пароли и т.д.).
10
Этап 16. Проверка недоступности приложений продукта при отсутствии ключа
доступа
Действия: проверить возможность запуска всех приложений продукта при закрытых
ключах доступа.
Результат Этапа 16
Ни одно из приложений системы запущено не будет. Выдается сообщение об отсутствии
ключевого доступа.
Этап 17. Проверка шифрования конфиденциальной информации в приложениях продукта
Действия: проверить, что конфиденциальная информация (например, PIN-коды или пароли)
хранятся в БД и отображается в приложениях программного продукта в зашифрованном виде.
Результат Этапа 17
Конфиденциальная информация, загружаемая или получаемая с помощью приложений
программного обеспечения (например, PIN-коды или пароли), хранится в БД и отображается в
приложениях только в зашифрованном виде.
Этап 18. Проверка мультиязычности
Действия: - запустить все стартовые приложения продукта по всем возможным путям
запуска; - в едином технологическом цикле провести основные бизнес-операции, для выполнения
которых предназначен продукт.
Примечание:
Тестирование проводится для продуктов, поддерживающих режимы просмотра и работы на
нескольких языках. Этап выполняется для каждого поддерживаемого языка.
Результат Этапа 18
Все модули продукта корректно запускаются (нет неадекватных сообщений и системных
ошибок). На рассматриваемый язык правильно переведены: - названия всех полей,
отображающихся в приложениях, и допустимых действий, - диалоговый и информационный
потоки системы, - названия самих приложений, описания и сопровождающая ссылочная
документация, - всплывающие подсказки и пр.
Этап 19. Выявление перечня операций, требующих тестирования на производительность
Действия: на основе информации полученной в ходе выполнения Этапа 1 и требований к
производительности выделить перечень операций, выполняемых в отдельных приложениях, и
бизнес-операций, по которым и на основании которых, можно сделать выводы о
производительности, как отдельных операций, так и всей системы в целом. Примечание: для того,
чтобы можно было сравнить реальные и требуемые значения параметров производительности,
должны быть поддержаны методы для их фиксации при тестировании.
Примечание.
Данный этап имеет смысл для программных продуктов, в техническом задании или прочей
исходной документации которых, заданы конкретные (или сравнительные) требования к
производительности. Причем эти требования представляют собой набор значений критичных или
принципиальных параметров производительности для данного программного продукта.
Результат Этапа 19
Выделен перечень операций, выполняемых в отдельных приложениях, и бизнес-операций,
по которым и на основании которых, можно сделать выводы о производительности, как отдельных
11
операций, так и всей системы в целом. Определены
параметры,
которые
фиксироваться при тестировании производительности, для сравнения с требованиями.
будут
Этап 20. Тестирование производительности отдельных приложений
Действия: выполнить в приложении выделенные на Этапе 19 операции и зафиксировать
значения тестируемых параметров производительности. Примечание: при тестировании
производительности отдельных операций могут фиксироваться не только значения параметров,
исследуемых в целях проверки соблюдения технического задания, но и значения параметров,
важных для внутреннего контроля производителем собственного продукта. Это параметры,
которые видны только «снизу» (например, планы запросов), но о многом могут «рассказать»
разработчику приложения.
Результат Этапа 20
Полученные значения параметров производительности лежат в пределах, заданных
техническим заданием.
Этап 21. Нагрузочное тестирование
Действия: выполнить бизнес-операции, предусмотренные продуктов, в режиме
нагрузочного тестирования (см. описание нагрузочного тестирования в теоретической части).
Примечание.
Как правило, выполняется для крупных программных комплексов, объемных
информационных систем и программных продуктов, предусматривающих режимы обработки
больших объемов информации
Результат Этапа 21 Полученные значения параметров производительности лежат в
пределах, заданных техническим заданием.
Этап 22. Стрессовое тестирование
Действия: выполнить бизнес-операции, предусмотренные продуктов, в режиме стрессового
тестирования (см. описание стрессового тестирования в теоретической части).
Результат Этапа 22
Полученные значения параметров производительности лежат в пределах, заданных
техническим заданием.