Разработка и внедрение автоматизированной системы "Планирование деятельности"

Модель: «Роли и автоматизируемые виды деятельности»

Модель отображает роли и их автоматизируемые виды деятельности. Модель используется при определении функций системы

Модель: «Структура предприятия»

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

Модель: «Бизнес правила»

Модель отображает ограничения, накладываемые на бизнес процессы. Модель используется для определения правил системы

Модель: «Требования к системе»

Модель отображает выявленные функциональные и нефункциональные требования к системе. На основании которых проектируются необходимые функции и характеристики системы.

Модель: «Функции системы»

Модель отображает функции системы

Модель: «Экранные формы»

Модель отображает экранные формы системы

Модель: «Сценарии работы пользователя с системой»

Модель отображает сценарии работы пользователя с системой

Модель: «Модель размещения»

Модель отображает технические средства и, размещенные на них, программные средства системы и прочие программные средства

Модель: «Модель данных»

Модель отображает логическую и физическую структуру данных.

Модель: «Модель реализации»

Модель отображает подсистемы и компоненты, из которых они состоят

Модель: «Модель тестирования»

Модель отображает контрольные примеры, тесты, последовательность выполнения тестов, ожидаемые и полученные результаты тестов

В качестве основного подхода к формированию моделей было выбрано моделирования с использованием языка моделирования UML.

3.3 Унифицированный язык моделирования (UML)

Унифицированный язык моделирования (Unified Modeling Language - UML) является языком визуального моделирования, прежде всего предназначенным для разработки программных систем. Однако сфера применения этого языка гораздо шире. Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и других систем различной природы.

UML не является языком программирования. Программный код можно получить на основе созданной модели, разработанной с использованием UML, и применением инструментальных средств, его поддерживающих и содержащих генераторы кода. С другой стороны, на основе исходного кода можно восстановит UML модели уже существующих систем.

UML имеет следующие достоинства:

- обеспечивает формализацию и стандартизацию процесса моделирования

- представляет проектировщикам систем удобные средства визуального моделирования и документирования

- поддерживает высокоуровневое проектирование с использованием различных структур, шаблонов, компонент

- обеспечивает поддержку множества языков программирования

- прост в освоении

Последняя версия UML 2.0 включает набор диаграмм, используемых для разработки различных моделей программных и бизнес систем.

Для построения диаграмм применяется определенная семантика которая содержит определенную нотацию. Нотация представляет собой совокупность графических элементов, которые используются в моделях. Она является синтаксисом данного языка моделирования [10].

В качестве инструмента для построения диаграмм используется программный продукт Enterprise Architect (EA) полностью поддерживающий UML 2.0. Преимуществами этого инструмента является его простота использования, и удобное и наглядное компоновка, как моделей, так и элементов модели.

В таблице 2 представлены основные элементы нотации UML, и их представление в программе Enterprise Architect.

Таблица 2. Элементы нотации UML

Изображение элемента	Назначение
	связь «ассоциация». Используется для отображения связей между элементами
	связь «наследование». Используется для отображения наследования функций
	связь «включает». Специализированная связь, используется для отображения включения функциональности одной функции в другую.
	связь «расширяет». Специализированная связь, используется для расширения функциональности одного функции функциональностью другой функции при наступлении определенных условий
	связь «реализация» Используется для отображения связи между типовым требованием и сценарием его реализующим.
	связь «зависимость». Используется для отображения связей между элементами. Связь проводится от зависимого элемента к независимому элементу
	Связь «трассировка». Используется для отображения связи между элементами
	Класс. Используется для отображения различных объектов и их структуры (атрибутов и операторов)
	Класс со стереотипом <<target>>. Используется для отображения целей системы.
	пользователь системы. Под пользователем системы может подразумевается другая система, устройство, взаимодействующие с создаваемой системой. Используется для отображения смежных систем или устройств.
	Пакет используется для группировки элементов в соответствие с различными критериями.
	Граница. Используется для группировки элементов в разбивке по подсистемам
	Функция. Используется для отображения функций, реализующих требование.
	Функциональное требование. Используется для отображения требований к системе
	Начало. Используется для отображения начала сценария
	Конец. Используется для отображения окончания сценария
	Деятельность. Используется для отображения деятельности выполняемой объектами или субъектами системы
	«макро» деятельность. Используется для отображения обобщенной деятельности, которая декомпозируется
	объект системы или предметной области. Используется для отображения ролевой ответственности при выполнении какой-либо деятельности
	Поток управления. Используется для отображений связей между деятельностями
	Поток объектов. Используется для отображения связей между деятельностью и объектом
	Решение. Используется для ветвления, слияния, разветвления потока работ в сценарии
	Отправка. Используется для отображения действия, связанного с отправкой сигнала
	Прием. Используется для отображения действия, связанного с приемом запроса
	горизонтальная вилка. Используется для слияния и расщепления параллельных потоков
	вертикальная вилка. Используется для слияния и расщепления параллельных потоков
	БД. Используется в сценариях, связанных с БД.
	узел. Используется для отображения технических средств, например, процессоров
	компонент системы. Используется для отображения компонент системы, размещенных на технических средствах

На рисунке 14 представлена среда программы Enterprise Architect.



Рисунок 14. Окно программы Enterprise Architect

ГЛАВА 4. Разработка системы «Планирование деятельности», этапы разработки

4.1 Разработка моделей предметной области

Первый этап в процессе разработки программного модуля является моделирование предметной области.

Основанием для разработки моделей предметной области являлась нормативная документация созданная департаментом развития (основным заказчиком системы).

В процессе моделирования предметной области решалось несколько задач:

- описать структуру и процессы организации, в которой должна быть развернута система

- понять текущие проблемы организации и определить потенциальные возможности усовершенствования

- обеспечить общее понимание организации заказчиками, конечными пользователями и разработчиками

В ходе решения этих задач были разработаны следующие модели:

- «Организационная структура корпорации»

Отображение участвующих в процессе участников и взаимосвязь подчиненности между ними.

- «Бизнес цели»

Отображение требуемых показателей бизнес-процессов, которые должны быть достигнуты в результате их выполнения. К таким целям отнесено:

- Формирование механизма согласования деятельности предприятий корпорации

- Создание механизма контроля и управления деятельностью на всех уровнях: корпорации, предприятия, подразделения, отдельного сотрудника

- Информирование Совета Директоров и персонала предприятий о деятельности, целях и планах предприятия

Рисунок 15. Диаграмм бизнес процессов

- Формирование предпосылок, способствующих достижению стратегических целей

- Повышение качества формируемых бюджетов предприятий

- Формирование условий для создания системы мотивации, ориентированной на результаты деятельности

- Повышения уровня «принятия» ИТ в бизнес-деятельности у директоров и сотрудников компаний

- «Бизнес процессы»

Отображение состава бизнес-процессов, их взаимосвязи и целей, которые они поддерживают. Для качественного анализа требований были выявлены и описаны следующие бизнес-процессы (рисунок 15):

- «Цикл управления». Процесс с высокой степенью агрегации работ.

- «Согласовании целей предприятия с общекорпоративными целями»

- «Создание планов деятельности»

- «Согласование и утверждение планов деятельности»

- «Описание бизнес-процессов»

Отображение последовательности выполнения работ, связанных с бизнес-процессом. Сформированы модели всех вышеописанных бизнес-процессов. Н рисунке 16 представлен пример описания одного из бизнес процессов - «Цикл управления»



Рисунок 16. Диаграмм «Цикл управления»

- «Объекты бизнес-процессов»

описание материальных и информационных объектов реального мира, связанных с бизнес-процессом. На рисунке 17 представлена модель объектов бизнес процессов, реализованная в Enterprise Architect.



Рисунок 17. Диаграмма объектов бизнес процессов

Данная работа была важной отправной точкой для формирования требований к разрабатываемой системе.

4.2 Разработка моделей требований

На основании имеющихся моделей предметной области, были выявлены те процессы, для которых возможна автоматизация, и эта автоматизация оправданна и влечет повышения эффективности процесса.

Основные задачи, которые ставились на этапе разработки моделей требований это:

- установить и поддержать соглашение с заинтересованными лицами на том, что система должна делать

- обеспечить разработчиков системы лучшим пониманием требований к системе

- определить функциональные границы системы

- обеспечить базис для оценки времени при разработки системы

- определить интерфейсы пользователей системы, с учетом их потребностей и целей

В ходе решения этих задач были разработаны следующие модели:

- «Цели системы»

Отображение требуемых показателей объекта автоматизации, которые должны быть достигнуты в результате создания системы На рисунке 18 представлена диаграмма целей системы.

Рисунок 18. Цели системы

- «Смежные системы»

Т.к. разрабатываемый модель интегрирован в общую корпоративную систему, то необходимо указать другие модули, или сервисы которые используются. В результате анализа и проектирования были выявлено эффективное использование таких модулей корпоративной системы как:

- Модуль «Персонал». В данном модуле имеется актуальная информация о сотрудниках, и их контактные данные.

- Модуль «Хранилище файлов». При работе пользователя с разрабатываемым модулем, возникает потребность прикреплять различные файлы. Все файлы помещаются в хранилище, что позволяет использовать такие функции как сохранение версий файлов, поиск файлов по ключевым полям, разграничение доступа к файлам и ряд других функций.

- Модуль «Оповещения». Данный модуль, обеспечивает функцию оповещения пользователей о различных событиях происходящих в корпоративной системе. Например, рассылка объявлений, напоминание сотрудникам о тех или иных событиях. Оповещения осуществляется несколькими способами, в том числе по электронной почте и по SMS, что позволяет значительно повысить эффективность сообщений. Модуль имеет определённый входной интерфейс, что обеспечивает возможность его использования без изменений для различных других модулей, в частности для разрабатываемого. Реализовано оповещения сотрудников, о прострочках выполнения задач, появлении новых задач, изменения в существующих задачах и т.д.

- «Границы системы»

Указание правил взаимодействия разрабатываемого модуля и имеющихся смежных систем.

- «Пользователи системы»

Определение необходимых типов ролей в системе. На основании выявленных ролей, происходит проектировка доступа к функциям и реализация сценариев использования. На рисунке 19 представлена диаграмма пользователей системы



Рисунок 19. Пользователи системы

- «Требования к системе»

Определение требований к системе. Одна из ключевых моделей на этапе разработки. Т.к. изначально было решение об итерационной разработке, то требования выявлялись постоянно. На основании выявленных требований разрабатывались необходимые функции системы. Всего было выявлены и отражены в документации десятки требований. Также было много требований которые просто не нашли свое отражение в документации, в связи с их «простотой» по субъективному мнению аналитика. На рисунке 20 представлена диаграмма требований к системе.



Рисунок 20. Диаграмма функциональных требований к системе

- «Функции системы»

Модель функций системы является одной из основных для понимания того «что делает система». При моделировании функции происходит определение взаимосвязи Пользователь системы - функция системы и требование к системе - функция системы. На рисунках 21 и 22 представлены пример диаграмм Требований к системе и функции системы



Рисунок 21. Диаграмма функций системы

Рисунок 22. Диаграмма требований

- «Описание автоматизируемых функций»

Детальное отображение последовательности выполнения действий системы и пользователя. Разработка данных моделей является с одной стороны основой при взаимодействии с заказчиком (заказчик уже может представить как будет работать система), а с другой стороны эти модели являются необходимыми для качественного реализации программного кода программистами.

- «Альбом форм пользовательского интерфейса»

Является своего рода приложением при проектировании функций системы. Считаю, что наличие альбома форм очень важно для конечного пользователя. Иногда картинка может значительно упростить понимание требований и функции всех заинтересованных лиц.

На рисунке 23, представлена диаграмма декомпозиции одной из функции системы - «Работа с задачей»

Рисунок 23. Диаграммафункции: «Работа с задачей»

На рисунке 24 представлен пример диаграммы, описывающий одну из функций системы - «Настройка пользователем оповещений для выбранной рекомендации»

Рисунок 24. Диаграмма сценария использования «Настройка оповещений»

На рисунке 25 представлено диаграмма декомпозиции функции системы «Работа с файлами».



Рисунок 25. Диаграмма функции «Работа с файлами»

- Ряд других вспомогательных моделей показывающих специфичные области системы. Такие как модель размещения (рисунок 26), модели печатных бланков.

Рисунок 26. Диаграмма: Модель размещения

Сформированные модели - являются ключевым объектом в процессе разработки системы. Качество реализации программного кода напрямую зависит от качества построенных моделей. Большинство описанных моделей явно вошло в техническое задание, часть являлись вспомогательными, помогающими лучше понять программистам требования к системе.

4.3 Реализация программного кода

В качестве платформы разработки, является платформа «1С Предприятие 8». Накопленный опыт в программировании на 1С, является одним из преимуществ нашей команды разработчиков. Многие реализованные функции абсолютно не типичны для решений на платформе 1С. Однако профессионализм и знания программистов позволяет реализовывать такие функции, что расширяет использование 1С для решения большого спектра задач.

Для начала реализации на основании аналитических моделей была предложена модель данных - описание структуры базы данных, описание взаимодействий объектов на уровне системы.

Результатом это этапа является программный код, который полностью соответствует предъявляемым требованиям.

На рисунке 27 представлена реализованная в системе форма списка Задач и рекомендаций.



Рисунок 27. Окно формы списка задач в разработанной системе

На рисунке 28 представлена реализованная в системе форма задачи.

Рисунок 28. Окно задачи в разработанной системе

4.4 Тестирование

Для проведения тестирования системы, был выбран пусть продуктивного использования внутри ИТ-отдела. В разрабатываем системе, велась полноценная работа по постановке задач, отслеживание хода выполнения и полученных результатов. Т.к. итерационная разработка предполагает получение работоспособного кода на каждой итерации, то такое использование было возможно.

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

В итоге, в момент передачи в полноценную эксплуатацию, можно утверждать, что более чем на 95% система была корректна.

Конечно, тестирование других разработок таким методом вряд ли возможно, но конкретно для этого проекта, этот подход наиболее эффективен.

4.5 Внедрение

Потенциальными пользователями разрабатываемой системы являются практически каждый сотрудник корпорации.

Для снижения сроков внедрения, снижения уровня сопротивления сотрудников было проведено ряд мероприятий:

- Разработаны наглядные руководства пользователя. Простые руководства, для начинающих пользователей, в которых указаны только базовые принципы работы необходимые для возможности использовать систему. И полные руководства, для опытных пользователей, в которых описаны все возможные режимы использования системы.

- В процессе внедрения были сформированы группы пользователей (5-7 человек со сходным уровнем компьютерной грамотности), с которыми проводилось обучение. Для руководителей подразделений, проводилось индивидуальное обучение.

- В ходе эксплуатации, на поступающие от пользователей вопросы, давались консультации. Ответы на часто задаваемые вопросы публиковались на корпоративном форуме. Корректировалось и дополнялось руководство пользователя.

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

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

На сегодняшний день в системе зарегистрировано более сотни пользователей, из которых более половины используют систему в своей деятельности и этот показатель постоянно растет.

ЗАКЛЮЧЕНИЕ

Результатом выполнения предложенной аттестационной работы, является разработанное программное обеспечение. Разработанное ПО, является интегрированным модулем в общекорпоративной информационной системе. Модуль находится в эксплуатации. На сегодняшний день функциями системы активно пользуют десятки пользователей.

Внедрение модуля «Планирование деятельности» в первую очередь позволило повысить качество информационного обмена между сотрудниками корпорации при решении различных задач.

Наглядное представление, визуализация имеющихся задач, с указанием необходимых параметров выполнения, предоставление необходимого доступа разным категориям сотрудников, а также дополнительные сервисы, такие как оповещения и напоминания о событиях, повысило общую исполнительскую дисциплину, и качество работы сотрудников.

Формирующая база данных о решаемых задачах, является одним из важных компонентов корпоративной базы знаний. Принятие сотрудниками средств автоматизации для организации работ при решении задач, является хорошим заделом, для дальнейшего развития процесса накопления и управления корпоративными знаниями, а также и развитие средств автоматизации этого процесса.

Вовлечение большого числа сотрудников, в круг пользователей системы, является важным фактором повышения лояльности и признания эффективности информационных технологий. Руководители подразделений, более активно начинают обсуждать возможность применения тех или иных информационных решений в своих областях деятельности.

Для разработки программного обеспечения, был произведен анализ, выбор и адаптация методики разработки программного обеспечения. В качестве основы была выбрана методика «Rational Unified Process».

Использование методики позволило повысить качество разработки программных продуктов. Определенный уровень формализма процесса разработки позволяет не затягивать срок разработки, обеспечивает необходимый объем документации. Разработанная документация значительно снижает риск невозможности дальнейшего сопровождения.

Разработаны базовые руководства по основным видам деятельности, таким как моделирование предметной области и управление требованиями. В дальнейшем при реализации других проектов, при появлении нового опыта, эти документы будут изменяться и дополняться. Наличие такой нормативной базы, является важным для формирования стабильного качества работы при разработке, внедрении и сопровождении программных продуктов.

Наличие в деятельности понятных правил работы, разделение по зонам ответственности участников процесса, является хорошим мотивационным фактором.

Таким образом, решение поставленных задач, является качественной основной, для дальнейшего совершенствования как общего процесса управления деятельностью в корпорации, так и повышение качества работы каждого сотрудника. Наличие профессиональной команды из аналитиков, проектировщиков, программистов, менеджеров проектов, позволят и в дальнейшем внедрять такие информационные решения, которые смогут повысить эффективность деятельности организации.

Список использованных источников

автоматизированная система моделирование планирование

1. ГОСТ Р ИСО/МЭК 12207-99 «Процессы жизненного цикла программных средств».

2. Филипп Крачтен - «Введение в RUP» Перевод с англ.Вильямс. Москва 2002г. - 204с.

3. ГОСТ Р ИСО/МЭК ТО 15271-2002 «Руководство по применению ГОСТ Р ИСО/МЭК 12207».

4. ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания».

5. ГОСТ 34.201 - 89 «Виды, комплектность и обозначение документов при создании автоматизированных систем».

6. The Rational Unified Process v. 2003.06.00.

7. Пер Кролл «Rational Unified Process - это легко». Перевод с англ. Кудиц-Образ. Москва 2004. - 432с.

8. Стефан Бергстрём «Rational Unified Process - путь к успеху». Перевод с англ. Кудиц-Образ. Москва 2004. - 256с.

9. Е.Б. Золотухина Методическая разработка «Основы бизнес моделирования». Москва 2005. - 89с.

10. Мартин Фаулер «UML основы». Перевод с англ. СПб: Символ-Плюс, 2002. - 188с.

Размещено на Allbest.ru