РЕДАКТОР UML ACTION ДИАГРАММ

Исполнители: Гусев А.П. [Главный программист] Шатеев И.В. [Архитектор] Меркулов А.А. [Прожект-менеджер](ИВТ-461)

ВОЛГОГРАДСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

КУРСОВОЙ ПРОЕКТ

ЦЕЛИ И ЗАДАЧИЦель - сократить время создания диаграмм

классов за счет удобного интерфейса и соответствующего набора инструментов.

Для достижения поставленной цели были поставлены следующие задачи: 

- анализ предметной области - выбор методов  - кодирование и тестирование- внедрение

РАСПРЕДЕЛЕНИЕ РОЛЕЙ Роль Основная

задачаИсполнитель

План работ

Главный программист

Определяет реализацию программного продукта

Гусев А.П. План работ Гусев А.П.

Архитектор Разрабатывает архитектуру системы…, проводит тестирование.

Шатеев И.В. План работ Шатеев И.В.

Прожект-менеджер

Контролирует разработку продукта, проводит тестирование.

Меркулов А.А.

План работ Меркулов А.А.

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

Главная функция Создание UML action диаграммы

Основные функции Сохранение action диаграммы в файл Загрузка action диаграммы из файла Редактирование диаграммы: добавление,

удаление, перемещение элементов диаграммы

Редактирование свойств компонентов Экспорт диаграммы в картинку (формата jpg)

НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

1. Собственный формат файла для хранения сцены диаграммы

2. Установщик, позволяющий запуск программы на «чистой» ОС

3. Редактор должен работать под управлением ОС Windows XP и выше

4. Сроки: I-й релиз - 02.11.11, II-й релиз - 10.12.11;5. Адекватный интерфейс6. Технология разработки – объектно-

ориентированная7. Безотказность системы при неадекватных

действиях адекватного пользователя

ВЫБОР ТЕХНОЛОГИИРазработка ведется на языке высокого уровня С++ в среде

Visual Studio 2008. Используется платформа .NET. Выбор языка и платформы обусловлен: Легкостью разработки, Малой требовательностью, Отказоустойчивостью, Нехваткой времени для проведения углубленного анализа.Средства командной разработки: MercurialДля согласованности работы используется репозиторий

(code.google.com). Тестирование проводятся вручную по заданиям на

тестирование. Средства коммуникации: Skype, Qip.

ОСНОВНЫЕ РЕШЕНИЯ ПРИ РАЗРАБОТКЕ

Составление плана работ.В организационной части важным пунктом

было составление плана работ. Он оформлялся в виде таблицы с задачами,

сроками и исполнителями выполнения.

Разработка структуры программы.Для разработки была спроектирована

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

ПРОЕКТНЫЕ РЕШЕНИЯ: USE-CASE ДИАГРАММА

ПРОЕКТНЫЕ РЕШЕНИЯ: ДИАГРАММА КЛАССОВ

ИНТЕРФЕЙС ПРОГРАММЫ

ТЕСТИРОВАНИЕТестирование проводилось тремя способами:

1. Общее тестирование после очередного обновления. 2. Тестирование по заданиям. Составлялись задания на тестирование. Тестирование мог выполнить любой участник команды. 3. Тестирование сторонними лицами. Редактор тестировался участниками других команд.

Результаты

Результаты тестирования заносились в репозиторий.

ВНЕДРЕНИЕУстановкаРедактор был установлен на несколько машин, в том числе и с чистой ОС Windows. Проверка Была произведена проверка на: •Надежность

•Проводились тесты на полный цикл программы и на отдельные функции. Дефекты не обнаружены.

•Функциональность•Функционал программы соответствует заявленному

в документации (для I-го релиза). •Удобство

•Есть недостатки из-за некоторых ограничений (описанных в документации)

•Эффективность•В редакторе можно быстро создать диаграмму классов, но с некоторыми ограничениями (обусловленными заданием и рамками ограничений проекта)

ВКЛАД В КОМАНДНУЮ РАЗРАБОТКУ

Гусев А.П. Разработка программного продукта, основного функционала.

Шатеев И.В. Разработка и тестирование интерфейса программного продукта.

Меркулов А.А.Разработка документации тестирование программного продукта.

ПРОБЛЕМЫ, ВОЗНИКШИЕ ПРИ

РАЗРАБОТКЕПроблемы:

1.Нехватка времени 2.Плохая разработка учебного плана кафедрой ПОАС, как следствие:

• Нехватка времени• Менеджер проекта отвечающий за его работоспособность,

не имеет реальной власти в мерах взыскания (не как менеджер в группе разработки)

Возможные решения:

1.Увеличить время на разработку ПО2.Увеличить количество разработчиков

ПЕРСПЕКТИВЫ РАСШИРЕНИЯ

ПРОГРАММНОГО ПРОДУКТА

На следующий релиз планируется расширить функционал программы:

1.Масштабирование рабочей области2.Операция "копирование«3.Операция "вставить«4.Динамическое изменение размеров элементов диаграммы

Также планируется повысить информативность интерфейса, улучшить дизайн.

По мере возможности также могут быть реализованы следующие дополнения:•Отмена и повтор действия

Общий план работ Основные решения при разработке

Общий план работ Основные решения при разработке

Общий план работ Основные решения при разработке