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

 

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

 

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

  • Дублирование сущностей. В системе все чаще появляются однородные сущности в разных модулях (обычно, созданных разными разработчиками команды), которые необходимо синхронизировать как по данным, так и по структуре.
  • Дублирование работ. Разные разработчики команды создают модули(подзадачи), с практически, идентичными функциональными возможностями и, описывающими одну и туже предметную область.
  • Отсутствие механизмов отчуждения знаний. При разработке новых модулей, каждый из разработчиков использует только свой опыт, который чаще всего плохо документирован и через некоторое время утрачивается или теряет актуальность, в связи с невозможностью вывести его на новый качественный уровень. Уход из коллектива разработчика приводит к потере управления развитием его программных продуктов и усложнения дальнейшего сопровождения.
  • Отсутствие анализа деятельности коллектива. Затруднено определение эффективности работы каждого члена коллектива. Невозможно проследить количественные и качественные показатели, производимых работ. Как следствие из этого, невозможно предотвратить повторение ошибок.
  • Отсутствие планирования работ. Постоянно повышается процент разработанных, но не внедренных модулей(подмодулей), нарушаются графики работ, нет возможности гибко и быстро менять приоритеты выполнения работ.
  • Отсутствие поддержки версионности. Возникают проблемы с отслеживанием истории изменения функциональности и правил обработки данных.
  • Отсутствие документирования разработок. При разработке программных продуктов не ведется документация по производимым работам и описанию получаемого продукта, в связи с тем, что эти данные очень часто меняются и дополняются, а когда продукт готов к сдаче в эксплуатацию, охватить весь объем работ чрезвычайно тяжело. Этот список можно продолжать. Обобщая вышесказанное, можно сказать, что самая большая проблема это проблема побороть сложность. Появление большого количества статей, описывающих теорию СУП, заставляют разработчиков делать попытки ознакомиться с существующими методиками. Но без отрыва от текущих работ и серьезного подхода, эти попытки заканчиваются потерей времени. В большей степени, это обусловлено масштабностью пропагандируемых методик, большая часть из которых, рассчитана на применение в больших коллективах и только в полном объеме.

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


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

 

 

Рис.1. Пример сложной иерархической структуры проектирования

 

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

 

Взгляд на модель СУП для небольших коллективов


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


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

  1. Система Автоматизированного Проектирования Программных продуктов.
  2. Система календарного планирования и контроля выполнения работ.
  3. Среда разработки.
  4. Среда поддержки пользователей.

В данной статье рассмотрим подробнее первый пункт:


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


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


При формировании Матриц следует учитывать следующие ключевые моменты:

  1. Матрицы, должны быть определены в такой последовательности, чтобы каждые последующие использовали или уточняли предыдущие, это позволит сгладить переходы между стадиями проектирования.
  2. Окончание заполнения каждой матрицы, означает окончание этапа работ и, следовательно, должно инициировать формирование итогового документа по нему.
  3. Каждая матрица должна содержать информацию о версии производимых работ.
  4. Конечным итогом работы Системы Автоматизированного Проектирования должны стать данные, являющиеся входными для Среды разработки.

Потоки работ по Автоматизации Проектирования. С чего начать


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


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

  1. Анализ
  2. Формализация
  3. Проектирование
  4. Построение
  5. Внедрение

В первой фазе, для начала, можно использовать 4-ре Матрицы:

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

Во второй фазе, для начала, можно использовать 6-ть составных Матриц:

  • Сущности, используемые в проекте

Матрицу можно создать на основе матрицы «основные сценарии работ», путем выделения из текстов - существительных, характеризующих предметную область проекта. Желательно использовать две матрицы «Сущности типовые» и «Сущности по проекту». Под типовым, подразумевается глобальное определение сущности, а под проектными - видение этой сущности в контексте проекта, с возможностью наследования свойств. Такой подход позволит использовать единое хранилище сущностей (родителей) для сущностей (потомков) из разных проектов, а следовательно упростить работу по обслуживанию и синхронизации проектов в рамках единой системы. В тоже время появляется возможность иметь единое описание сущности для разных хранилищ и соответственно организовывать обмен и взаимодействие между ними.


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


При построении полнофункциональной системы следует обратить внимание на создание механизмов поддержки связей между сущностями. Для этого можно в матрицу «свойства сущностей» ввести атрибут «Ссылка» указывающее на сущность (связь многие к одному).

  • Сценарий работ в терминах сущностей и процессов

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

  • Процессы, необходимые для выполнения Сценария.

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

  • Информационные потоки

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

  • Риски

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


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

 

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

 

В фазе проектирования, для начала, можно использовать 3-и составных Матрицы:

  • Таблицы Базы Данных

Матрица описывает таблицы, как элементы Хранилища данных. Должна быть связана с матрицей «сущности по проекту».

  • Функции, процедуры, триггера и т.д.

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

  • Интерфейс пользователя

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

 


 Рис.2. Схематичный пример построения системы.


Продолжение см. в сл. номере.

2004.06.29
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".