Р ЕДАКТОР UML ACTION ДИАГРАММ Исполнители: Гусев А.П. [Главный программист] Шатеев И.В. [Архитектор] Меркулов А.А. [Прожект-менеджер] (ИВТ-461) ВОЛГОГРАДСКИЙ. - презентация

1 Р ЕДАКТОР UML ACTION ДИАГРАММ Исполнители: Гусев А.П. [Главный программист] Шатеев И.В. [Архитектор] Меркулов А.А. [Прожект-менеджер] (ИВТ-461) ВОЛГОГРАДСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ КУРСОВОЙ ПРОЕКТ

2 Ц ЕЛИ И ЗАДАЧИ Цель - сократить время создания диаграмм классов за счет удобного интерфейса и соответствующего набора инструментов. Для достижения поставленной цели были поставлены следующие задачи: - анализ предметной области - выбор методов - кодирование и тестирование - внедрение

3 Р АСПРЕДЕЛЕНИЕ РОЛЕЙ РольОсновная задача Исполните ль План работ Главный программист Определяет реализацию программного продукта Гусев А.П.План работ Гусев А.П. АрхитекторРазрабатывает архитектуру системы…, проводит тестирование. Шатеев И.В.План работ Шатеев И.В. Прожект- менеджер Контролирует разработку продукта, проводит тестирование. Меркулов А.А. План работ Меркулов А.А.

4 Ф УНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ Главная функция Создание UML action диаграммы Основные функции Сохранение action диаграммы в файл Загрузка action диаграммы из файла Редактирование диаграммы: добавление, удаление, перемещение элементов диаграммы Редактирование свойств компонентов Экспорт диаграммы в картинку (формата jpg)

5 Н ЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ 1. Собственный формат файла для хранения сцены диаграммы 2. Установщик, позволяющий запуск программы на «чистой» ОС 3. Редактор должен работать под управлением ОС Windows XP и выше 4. Сроки: I-й релиз , II-й релиз ; 5. Адекватный интерфейс 6. Технология разработки – объектно-ориентированная 7. Безотказность системы при неадекватных действиях адекватного пользователя

6 В ЫБОР ТЕХНОЛОГИИ Разработка ведется на языке высокого уровня С++ в среде Visual Studio Используется платформа.NET. Выбор языка и платформы обусловлен: Легкостью разработки, Малой требовательностью, Отказоустойчивостью, Нехваткой времени для проведения углубленного анализа. Средства командной разработки: Mercurial Для согласованности работы используется репозиторий (code.google.com). Тестирование проводятся вручную по заданиям на тестирование. Средства коммуникации: Skype, Qip.

7 О СНОВНЫЕ РЕШЕНИЯ ПРИ РАЗРАБОТКЕ Составление плана работ. В организационной части важным пунктом было составление плана работ. Он оформлялся в виде таблицы с задачами, сроками и исполнителями выполнения. Разработка структуры программы. Для разработки была спроектирована структура программного продукта в виде UML диаграмм.

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

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

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

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

12 В НЕДРЕНИЕ Установка Редактор был установлен на несколько машин, в том числе и с чистой ОС Windows. Проверка Была произведена проверка на: Надежность Проводились тесты на полный цикл программы и на отдельные функции. Дефекты не обнаружены. Функциональность Функционал программы соответствует заявленному в документации (для I-го релиза). Удобство Есть недостатки из-за некоторых ограничений (описанных в документации) Эффективность В редакторе можно быстро создать диаграмму классов, но с некоторыми ограничениями (обусловленными заданием и рамками ограничений проекта)

13 В КЛАД В КОМАНДНУЮ РАЗРАБОТКУ Гусев А.П. Разработка программного продукта, основного функционала. Шатеев И.В. Разработка и тестирование интерфейса программного продукта. Меркулов А.А. Разработка документации тестирование программного продукта.

14 П РОБЛЕМЫ, ВОЗНИКШИЕ ПРИ РАЗРАБОТКЕ Проблемы: 1.Нехватка времени 2.Плохая разработка учебного плана кафедрой ПОАС, как следствие: Нехватка времени Менеджер проекта отвечающий за его работоспособность, не имеет реальной власти в мерах взыскания (не как менеджер в группе разработки) Возможные решения: 1.Увеличить время на разработку ПО 2.Увеличить количество разработчиков

15 П ЕРСПЕКТИВЫ РАСШИРЕНИЯ ПРОГРАММНОГО ПРОДУКТА На следующий релиз планируется расширить функционал программы: 1.Масштабирование рабочей области 2.Операция "копирование« 3.Операция "вставить« 4.Динамическое изменение размеров элементов диаграммы Также планируется повысить информативность интерфейса, улучшить дизайн. По мере возможности также могут быть реализованы следующие дополнения: Отмена и повтор действия

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

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

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