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

Размещено на http://www.allbest.ru/

2

Дипломная работа

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

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• ГЛАВА 1. Анализ существующих процессов создания автоматизированных систем
• 1.1 Понятие разработки программного обеспечения
• 1.2 Модели жизненного цикла разработки ПО
• 1.3 Уровень формализма
• 1.4 Методологии разработки ПО
• ГЛАВА 2. Выбор процесса разработки и адаптация его под проект создания системы «Планирования деятельности»
• 2.1 Текущее состояние в области программного обеспечения в корпорации
• 2.2 Анализ требований к процессу разработки ПО
• 2.3 Краткое описание Rational Unified Process (RUP)
• 2.4 Адаптация процесса разработки под проект создания системы «Планирования деятельности»
• ГЛАВА 3. Анализ и выбор инструментов моделирования предметной области и системы
• 3.1 Понятие моделирования
• 3.2 Используемые модели системы
• 3.3 Унифицированный язык моделирования (UML)
• ГЛАВА 4. Разработка системы «Планирование деятельности», этапы разработки
• 4.1 Разработка моделей предметной области
• 4.2 Разработка моделей требований
• 4.3 Реализация программного кода
• 4.4 Тестирование
• 4.5 Внедрение
• ЗАКЛЮЧЕНИЕ
• Список использованных источников

ВВЕДЕНИЕ

«Уральская машиностроительная корпорация «Пумори-СИЗ» - это объединение 14 компаний, осуществляющих деятельность по нескольким направлениям. Общее, связующее этих компаний - это работа в области производства и продажи различного металлорежущего и вспомогательного инструмента, оборудования, станков и оснастки. Также компании оказывают услуги по инжинирингу (подготовка производства, разработка техпроцессов), пуску, наладки и сервисного обслуживания станков, обучение персонала работе со станками. Для финансирования крупных поставок привлекается собственная лизинговая компания.

История компании начинается в 1997 году. Основной для создания корпорации явился «Свердловский инструментальный завод», основанный в 1941 году.

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

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

За прошедшее десятилетия произошли существенные изменения по многим направлениям, связанным с информационными технологиями.

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

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

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

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

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

Все эти изменения, не прошли мимо нашей корпорации.

Сегодня информационная система корпорации - это:

- ИТ-инфраструктура

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

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

Программная инфраструктура - совокупность программного обеспечения используемого пользователями на ПК (операционная система, офисное ПО, бизнес-приложения, графические пакеты, программное обеспечение для работы с банками и налоговыми органами и др.)

- Функциональные бизнес-приложения

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

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

Предпосылки к разработке требуемого приложения

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

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

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

- Взаимодействие по решению оперативных задач, связанных с повседневной деятельностью (например, передача заказа в производство, согласование комплексных поставок)

- Взаимодействие по вопросам обмена информацией с корпоративным центром (например, финансовая отчетность)

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

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

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

Однако решение корпоративных задач имело определенные проблемы.

- Разногласия в целях между компаниями

- Игнорирование выполнения части задач

- Срыв сроков выполнения задач

- Большие временные затраты на встречи и разговоры

- Конфликтные ситуации между участниками в ходе решения задач

Одной из причин этих проблем является - информационный обмен между участниками в ходе решения таких задач. Важно, что решение корпоративных задач чаще всего носит проектных характер работы. Т.е. решается четко поставленная задача в определённые сроки. Участники, привлекаемые для решения этой задачи, могут, фактически находится в разных компаниях, занимать различные должности. Но для решения этой задачи, они объединяются в различных ролях под управлением ответственного за эту задачу. Получается определённая матрица распределения сотрудников и задач (рисунок 1).



Рисунок 1. Матрица распределения сотрудников и задач

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

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

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

- Покупка готовых решений и их адаптация под требования

- Разработка нового приложения удовлетворяющего требованиям.

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

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

- Высокие риски по не возможности сопровождения готового решения (интеграция с существующими системами, изменения в соответствии с будущими требованиями)

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

- Большой опыт в разработке приложений

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

Таким образом, было принято решение, о разработке нового модуля в существующем корпоративном решении.

В рамках аттестационной работе представлены основные этапы разработки и полученные результаты.

Методологии разработки программного обеспечения

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

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

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

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

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

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

ГЛАВА 1. Анализ существующих процессов создания автоматизированных систем

1.1 Понятие разработки программного обеспечения

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

Процесс разработки это совокупность работ и задач, выполняемых разработчиком, таких как анализ требований, проектирование, программирование, сборка, тестирование, вводу в действие и приемка программных продуктов [1].

Разработка программного обеспечения - это процесс создания системы на основании требований, новых или изменённых [2].

Таким образом, под процессом разработки программного обеспечения понимается создание и ввод в эксплуатацию программного средства удовлетворяющего предъявленным требованиям.

Процесс разработки может быть различен у разных групп разработчиков. Но в этом разнообразии можно найти общее черты. Все процессы разработки можно классифицировать по таким признакам как:

- модель жизненного цикла разработки (устанавливает взаимосвязь между задачами и работами в процессе разработки)

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

- уровень формализма (определяет структуру и содержание обязательной документации порождаемой в процессе разработки)

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

1.2 Модели жизненного цикла разработки ПО

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

Существуют несколько моделей жизненного цикла разработки программного обеспечения, но три из них -- фундаментальные [3]:

- каскадная

- инкрементная

- эволюционная (итерационная)

Каскадная модель

Каскадная модель разработки по существу реализует принцип однократного выполнения определённых работ в их естественных границах. Например, это могут быть такие работы как:

- установление потребностей пользователя

- определение требований

- проектирование системы

- изготовление системы

- испытание

- корректировка

- поставка или использование

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

Часто каскадную модель называют моделью «Водопада» (рисунок 2).

Рисунок 2. Каскадная модель

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

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

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

- возможны изменения требований к системе в процессе разработки

- ограниченность ресурсов, например средств или персонала

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

Преимущества использования данной модели:

- однократное представление всех возможностей (характеристик) системы

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

Инкрементная модель

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

Рисунок 3. Инкрементная модель

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

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

- предусмотрены сразу все возможности системы

- возможны изменения требований к системе в процессе разработки

- привлечение ресурсов (средств или персонала) на длительный период ограничено

Преимущества использования данной модели:

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

- естественное разделение системы на наращиваемые компоненты (инкременты)

- возможности наращивания привлекаемого персонала и средств

Эволюционная модель

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

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

Рисунок 4. Эволюционная модель

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

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

Преимущества использования данной модели:

- изначальное определение возможностей системы

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

- естественное разделение системы на наращиваемые компоненты (инкременты)

- привлечение персонала и средств по мере необходимости

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

1.3 Уровень формализма

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

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

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

1.4 Методологии разработки ПО

«Как получится»

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

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

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

«Структурный подход»

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. На основе SADT разработана, в частности, известная методология IDEF0. (рисунок 5)

Рисунок 5. Диаграммы SADT (IDEF 0)

DFD (Data Flow Diagrams) диаграммы потоков данных. Описание асинхронного процесса преобразования информации от ее ввода в систему до выдачи пользователю, через различные преобразования. (рисунок 6)

Рисунок 6. Пример диаграммы DFD

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь". С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (рисунок 7)

Рисунок 7. Пример диаграммы ER

«Гибкие методы»

Гибкие методологии базируются на десяти принципах, некоторые из которых ниже перечислены:

- Главное -- удовлетворить заказчика и предоставить ему продукт как можно скорее.

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

- Наиболее эффективный способ передачи знаний участникам разработки и между ними - личное общение.

- Работающая программа -- лучший показатель прогресса разработки

Список гибких методологий на сегодня достаточно широк (экстремальное программирование XP, Crystal Clear, FDD).

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

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

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

«ГОСТы»

В настоящее время в России действуют старые ГОСТы 19-ой и 34-ой серий и более новый ГОСТ Р ИСО МЭК 122207. ГОСТы 19-ой и 34-ой описывают совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям [4]. Согласно требований ГОСТа, допускается исключать некоторые стадии и отдельные этапы, выполнять отдельные этапы работ параллельно, добавлять новые этапы исходя из специфики проекта.

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

ГОСТ 12207, описывает разработку ПО как набор основных и вспомогательных процессов, которые могут действовать с начала до завершения проекта. ГОСТ 12207 мягче в части требований к формальности процесса разработки. В нем содержатся только указания на необходимость документирования основных результатов всех процессов, но нет перечней необходимых документов и указаний относительно их содержания.

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

«Rational Unified Process (RUP)»

Rational Unified Process (RUP) представляет собой методологию, упорядочивающую процесс разработки программного обеспечения с распределением ответственности между исполнителями. В конечном итоге такая методология позволяет наладить производство высококачественного, отвечающего требованиям пользователя программного обеспечения [6].

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

Что касается формальности методологии, то здесь RUP представляет пользователю весьма широкий диапазон возможностей. Если выполнять все работы и задачи, создавать все артефакты и достаточно формально (то есть с официальным назначением рецензента, с предоставлением рецензентом достаточно полной рецензии в виде электронного или бумажного документа и т.д.) проводить все рецензирования, RUP представляет собой крайне формальную, тяжеловесную методологию. С другой стороны, RUP позволяет разрабатывать только те артефакты и выполнять только те работы и задачи, которые необходимы в конкретном проекте. А выбранные артефакты могут выполняться и рецензироваться с произвольной степенью формальности.

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

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

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

Рисунок 8. Распределение методологий

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

ГЛАВА 2. Выбор процесса разработки и адаптация его под проект создания системы «Планирования деятельности»

2.1 Текущее состояние в области программного обеспечения в корпорации

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

- Управление финансами (бухгалтерский и управленческий учет, бюджетирование)

- Управление торговлей (оптовая и розничная торговля)

- Управление логистикой (складское хозяйство)

- Управление персоналом (персонифицированный учет)

Все функциональные бизнес-приложения нашей компании реализованы с использованием платформы «1С Предприятие».

Учет кадров и расчет заработной платы реализован при помощи готового решения от компании 1С - «1С 7.7: Зарплата и Кадры».

Бухгалтерский учет реализован при помощи адаптированного решения от компании 1С - «1С 7.7: Бухгалтерский учет»

Использование именно этих решений обусловлено несколькими причинами:

- Дешевизна решений (стоимость лицензий, стоимость специалистов сопровождающих это ПО)

- Наличие поддержки решений со стороны компании «1С» (обновление, линии консультации)

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

- Возможность самостоятельного сопровождения (изменения) программ под специфические требования компаний

Управленческие системы, такие как «Бюджетирование и консолидированная отчетность», «Управление торговлей», «Логистика» реализованы при помощи индивидуального программного обеспечения на базе платформы «1С Предприятие 8»

Предпосылками использование решений на 1С является:

- Низкая стоимость лицензий (3000р / 1 рабочее место)

- Невысокая стоимость специалиста по сопровождению, и большое количество этих специалистов на рынке

- Достаточная производительность и функциональность платформы, соответствующая требованиям бизнеса

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

- Текущая возможность реализации всех требований бизнеса, используя платформу

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

2.2 Анализ требований к процессу разработки ПО

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

- Общий рост бизнеса

- Организационные изменения в компании

- Изменения в бизнес-процессах

- «Принятие» информационных технологий сотрудниками в повседневной деятельности

- Рост компьютерной грамотности пользователей

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

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

- Адаптация типовых решений проходила не системно, что не позволяет обновлять эти типовые решения стандартными методами

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

- О том, как работает программа, знает только программист её разрабатывавший

Не остается сомнений, что в ближайшее время рост требований бизнеса сохранится (рисунок 9) и это может вызвать просто «информационный ступор» в компании. Не допустить этого - важная задача всего ИТ-подразделения.

Рисунок 9. Прогноз роста требований

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

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

- Обеспечивать понятный процесс взаимодействия между «заказчиком» и «разработчиком»

- Обеспечивать эффективное взаимодействие внутри группы разработки

- Поддерживать работу в случаях неопределённости требований или их изменений

- Обеспечивать достаточно быстро и эффективное написание качественного кода программ

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

Исходя их требований, потенциальная методология должны поддерживать инкрементную и итеративную модели разработки с невысоким уровнем формализма. Из описанных выше методологий наиболее удовлетворяет этим требованиям «Rational Unified Process (RUP)».

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

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

Аналогичное понятие существует в других методологиях, например в ГОСТах - это процесс адаптации. Процесс адаптации является процессом применения положений настоящего стандарта к условиям реализации конкретного программного проекта ([1], Приложение А)

2.3. Краткое описание Rational Unified Process (RUP)

Рисунок 10. Архитектура RUP

На рисунке 10 представлена общая архитектура RUP.

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

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

Во втором измерении процесс представлен в статическом виде и описывается в терминах: компоненты процесса, задачи, последовательности работ, артефакты, и роли Т.к. оригинальная методология RUP написана на английском языке, то есть различные варианты перевода терминов на русский. [7].

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

Жизненный цикл проекта.

RUP обеспечивает структурированный подход к итеративной разработке, разделяя проект на четыре фазы: Начало (Inception), Проектирование (Elaboration), Построение (Construction) и Внедрение (Transition). Переход от одной фазы к другой осуществляется при достижении целей очередной фазы, достижение которых проверяется в контрольных точках или вехах.

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

Фаза «Начало».

- Понять границы проекта

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

Фаза «Проектирование».

- Свести к минимуму главные технические риски

- Создать базовую архитектуру

- Получить достоверную оценку сроков и необходимых ресурсов для построения системы

Фаза «Построение».

- Построить первую работающую версию продукта

Фаза «Внедрение».

- Создать окончательную версию продукта и отправить её заказчику

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

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

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

- Интеграция перестает быть авралом в конце проекта. Опыт разработки систем показывает, что откладывание интеграции до конца проекта почти всегда приводит к дополнительным затратам времени на переделку, иногда до 30-40% от всего времени проекта. Чтобы избежать этого, каждая итерация обязательно должна заканчивается интеграцией компоновочных блоков, что минимизирует в будущем затраты на переделку.

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

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

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

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

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

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

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

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

Для управления итерациями, и определения необходимых работ на каждой итерации, RUP предлагает определённую классификацию таких работ. Все работы образуют процессы, которые в терминологии RUP называются дисциплины.

Дисциплины RUP.

Методология RUP содержит в себе девять дисциплин (процессов).

Процесс описывает, кто что делает, как и когда.

Основными процессами в разработке программных продуктов являются (рисунок 11):

Рисунок 11. Дисциплины RUP

- Бизнес-моделирование (моделирование предметной области)

С точки зрения RUP целями бизнес моделирования являются:

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

- Определение проблем автоматизируемой организации и способов их решения.

- Определение требований к автоматизированной системе организации со стороны заинтересованных лиц.

- Понимание процесса размещения программного обеспечения в организации.

Для достижения этих целей в RUP описаны виды деятельности проектной команды при проведении бизнес моделирования, главными из которых являются разработка моделей бизнес процессов (Business Use-Case Model) и моделей анализа бизнеса (Business Analysis Model), описывающих реализации бизнес процессов.

Результаты работы, полученные после проведения бизнес моделирование, являются основой для проведения работ по определению требований и разработки архитектуры автоматизированной системы.[9].

- Управление требованиями

Цель дисциплины «Управление требованиями»:

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

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

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

- обеспечить базис для планирования технического содержания стадий,

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

- Анализ и проектирование

Целями анализа и проектирования являются:

- трансформирование управления требованиями в проектирование системы

- формирование архитектуры системы

- адаптация проектирования к соответствующей реализации поддержки среды разработки, проектирование для исполнения

- Реализация

Цели реализации:

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

- реализация классов и объектов в виде компонентов (исходных, двоичных, исполняемых файлов и др.)

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

- интеграция результатов работы отдельных программистов (или групп) в рабочую систему

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

Цели тестирования:

- проверить взаимодействие между объектами

- проверить корректную интеграцию всех компонент системы

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

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

- Развертывание (Ввод в дейвие)

Процесс "Ввод в действие" состоит из задач, выполнение которых обеспечивает функционирование программного продукта у конечных пользователей.

- Управление проектом

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

- Управление конфигурациями и изменениями

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

- Поддержка среды

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

2.4 Адаптация процесса разработки под проект создания системы «Планирования деятельности»

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

Таким образом, процесс адаптации RUP к проекту - это выбор необходимых элементов RUP.

Для проекта разработки системы «Планирование деятельности» использованы практически все дисциплины. Часть дисциплин в большем объеме часть в меньшем. Это было сделано специально с целью более качественного знакомства с методологией и выявления действительно необходимых элементов RUP.

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

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

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

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

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

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

ГЛАВА 3. Анализ и выбор инструментов моделирования предметной области и системы

3.1 Понятие моделирования

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

Моделирование - методология выполнения работ путем исследования свойств различных объектов на моделях. Информатика. Энциклопедический систематизированный словарь-справочник

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

Моделирование позволяет решить несколько различных задач:

- визуализировать систему в ее текущем или желательном для нас состоянии;

- определить структуру или поведение системы;

- получить шаблон, позволяющий затем сконструировать систему;

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

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

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

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

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

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

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

Таблица 1. Схема Захмана

	Данные «Что?»	Функции «Как?»	Сеть «Где?»	Люди «Кто?»	Время «Когда?»	Цель «Зачем?»
Заказчик (бизнес)
Модель предприятия
Логическая модель системы
Технологическая модель системы
Детальное представление системы

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

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

3.2 Используемые модели системы

Основу любой дисциплины RUP составляют рекомендации по разработке различных моделей [9].

Для проекта разработки системы «Планирование деятельности» были выбраны следующие модели:

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

Модель отображает процессы, подлежащие автоматизации, связи между процессами, цели, которые они поддерживают, субъектов и объектов, взаимодействующих с бизнес процессами и являющихся внешними по отношению к ним. Модель используется для определения целей системы и разбиения системы на подсистемы. Каждому бизнес процессу ставится в соответствие подсистема. Пример модели приведен на рисунке 12.

Рисунок 12. Пример модели «Бизнес Процессы»

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

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



Рисунок 13

Модель: «Описание бизнес сущностей»

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

Модель: «Описание состояний бизнес сущностей»

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