Несколько изменив методологию, можно решить ряд стандартных проблем, возникающих при создании проектов
Владимир Смирнов, Игорь Рябенький
В жизненном цикле современных информационных систем (ИС) можно выделить два этапа: этап создания и этап эксплуатации. На первом из них осуществляется постановка задачи, проектирование системы и ее реализация. Иначе говоря, происходит декомпозиция задачи, т. е. переход от ее постановки к реализации отдельных функций, а затем объединение отдельных функций в приложения для конечных пользователей.
Рис. 1. Стандартная схема создания информационных систем
На этапе эксплуатации ИС появляется потребность в развитии ее функциональных возможностей (функционала). Само существование системы показывает, что знания о предметной области систематизированы. На основе этих знаний возникают новые, приводящие к выявлению новых прикладных задач и, как следствие, к формулированию новых требований к системе. Эти требования зарождаются на рабочих местах в процессе использования системы. Их накопление обычно ведет к созданию ее следующей версии.
Таким образом, этап эксплуатации системы подразумевает ее поддержание (администрирование) и накопление требований для следующей версии.
Не будем углубляться в процесс поддержания готовой системы, а сосредоточимся на вопросе накопления требований. Они могут касаться как изменения имеющегося, так и появления нового функционала.
Для реализации прикладной задачи в процессе эксплуатации системы используется заранее заложенная в нее композиция отдельных функций. В настоящее время проблема большинства проектов состоит в том, что способ композиции (объединения) этих функций определяется на этапе построения системы, поскольку, согласно существующим методологиям создания ИС, функционал выделяется в привязке к пользователю.
Рис. 2. Предлагаемая схема создания информационных систем
Проблемы, которые порождает существующий подход, очевидны:
- невозможно быстро изменять функционал приложения при изменении требований к прикладной задаче;
- с появлением новых типов пользователей нельзя создать приложение, использующее имеющиеся функции системы (не возвращаясь на этап создания);
- накопленный функционал остается в лучшем случае только на бумаге, отлаженный код не переходит из одной версии системы в другую.
Решение проблем
Мы предлагаем несколько изменить сами этапы жизненного цикла информационных систем, не отрицая при этом существующих методологий. В частности, ограничить этап создания ИС стадией разработки бизнес-функций и перенести процесс композиции отдельных функций на этап эксплуатации.
При этом становятся возможными следующие вещи:
- Сборка приложения для конкретного пользователя с произвольной функциональностью. Следуя предложенной методике, можно собрать приложение, использующее уже реализованный функционал.
- Вовлечение старых работников самих предприятий в создание и изменение функциональности новых приложений. Эти люди лучше других знают, что нужно их бизнесу.
- Накопление библиотеки готового функционала (элементов бизнеса) и порождение из него произвольного набора бизнес-функций (сервисов).
Идея подобной разработки информационных систем далеко не нова, но конкретная реализация всегда упиралась в неразрешимые проблемы. Для рассмотрения деталей необходимо определиться со словарем терминов, употребляемых в данной предметной области. Авторами предлагается следующая терминология:
- бизнес - совокупность сервисов, описываемых информационной системой предприятия;
- сервис - набор бизнес-функций, направленных на решение определенной проблемы предприятия;
- бизнес-функция - составная часть сервиса, отвечает за решение определенной задачи. Законченное действие пользователя;
- логическая функция - составная часть бизнес-функции;
- компонент - механизм реализации логических функций. Один компонент может участвовать в реализации нескольких логических функций.
Рис. 3. Список бизнес-функций
Опираясь на этот словарь терминов, можно перейти к более подробному рассмотрению встречающихся проблем.
- Отсутствие универсального механизма для связывания набора полученных компонентов. Механизм, объединяющий компоненты, должен быть достаточно гибким, позволяющим взаимодействовать распределенным компонентам. Кроме того, необходимо, чтобы он был открытым для сторонних разработчиков, использовал промышленные стандарты, принятые в отрасли, и мог работать в гетерогенных средах.
- Реализация крупных систем подразумевает применение нескольких серверов, на которых устанавливаются элементы системы. И здесь остро встает вопрос создания единой службы имен. Система должна предоставлять пользователю возможность прозрачной навигации внутри самой себя.
- Стандартизация уровней построения системы, т. е. разграничение ответственности между проектировщиками, программистами и теми, кто эксплуатирует систему. Системы, использующие исходный код для построения нового функционала, стоят дорого. Мы предлагаем более дешевое решение - сборку приложений из готовых компонентов.
- Отсутствие простых механизмов, позволяющих работникам предприятий формировать новые сервисы. Для решения этой проблемы необходимо создать систему хранения информации обо всех бизнес-процессах, протекающих на предприятии, с одновременной связкой их с выделенными сервисами и реализацией.
Предлагаемая нами технология создания информационных систем частично обходит эти проблемы, а частично дает инструмент для их решения. Она базируется на использовании собственного программного обеспечения, классических методологий и CASE-средств фирмы Rational. Основная идея технологии - дать возможность формировать сервисы на этапе эксплуатации (т. е. исключить из этапа создания системы объединение бизнес-функций в сервисы).
Предлагаемая технология обладает множеством достоинств. Ниже перечислены некоторые из них.
1. Для обеспечения связи между компонентами разработанное ПО поддерживает промышленные стандарты отрасли - технологии CORBA, JMS, Oracle AQ.
2. Единая служба имен и справочник сервисов реализованы с использованием LDAP и JNDI. Это позволяет решить все вопросы с аутентификацией пользователя на различных серверах и платформах.
3. Проектировщики и разработчики системы разрабатывают бизнес-функции, а эксплуатационники объединяют их в сервисы и выдают конечным пользователям. Стоимость внедрения и эксплуатации подобной системы значительно снижается за счет того, что каждый член команды работает в привычной ему среде.
4. Использование CASE-средств для ведения проектов позволяет хранить всю информацию в одном месте на этапах создания, проектирования и эксплуатации, при этом исключаются дублирование и разночтения между различными аспектами системы. Одновременно это позволяет бизнес-менеджерам и специалистам в конкретных предметных областях создавать необходимые сервисы методом “перетащи и оставь”.
5. Применение CASE-средств подразумевает разработку информационной системы в несколько этапов и позволяет использовать бизнес-менеджеров не только для корректировки направления развития системы, но и для ее эксплуатации. Менеджеры могут определять функциональность сервисов на этапе эксплуатации.
6. Использование классических методологий разработки софтверных проектов и, как следствие, документированность и прогнозируемость развития проекта. Получение документированного проекта позволяет компании-клиенту пользоваться услугами нескольких фирм-разработчиков.
7. Удешевление внедрения за счет разделения ответственности между проектировщиками и разработчиками, с одной стороны, и бизнес-пользователями - с другой.
Дополнительным достоинством данного подхода является его применимость при создании сложных, многоаспектных систем. На сегодняшний день не существует рекомендаций или методик для работы с подобными системами. И все бремя ответственности ложится на плечи проектировщиков и аналитиков. Рассмотрение функционала предприятия без привязки к пользователю позволяет реализовать набор бизнес-функций, из которых на этапе эксплуатации возможно построение произвольного набора сервисов в рамках данного бизнеса.
Примеры применения
Проектировщик, проводя декомпозицию предметной области, связанной с управлением электронным контентом, выделяет существующие бизнес-функции. Описание выполняется совместно со специалистом в предметной области и оформляется в виде текста, содержащего название бизнес-функции, описание последовательности действий пользователя для ее реализации и список нефункциональных требований (качество, надежность, масштабируемость и т. д.)
Рис. 4. Описание механизма вызова компонентов
Проектируя механизм реализации бизнес-функций, проектировщик выполняет декомпозицию до уровня компонентов. Вся последовательность шагов документируется в Rational Rose, что позволяет бизнес-менеджерам других отделов контролировать процесс разработки и, если нужно, влиять на него.
Проектировщик выделяет из бизнес-функции логические функции, проектирует компоненты, т. е. определяет наборы логических функций и спецификации реализующих их компонентов. Для каждой логической функции прописывается сценарий ее выполнения, включая описание передаваемых данных, последовательности действий и список используемых компонентов.
Далее для каждого спроектированного компонента необходимо получить задание для программиста. С использованием CASE-средств это можно сделать автоматически, так как информация была заложена проектировщиком и доступна в проекте. Задание для программиста содержит набор диаграмм, показывающих последовательность использования компонентов для реализации бизнес-функций, а также спецификацию интерфейса по каждому компоненту. Отдельно прилагается документ, содержащий набор нефункциональных требований.
Рис. 5. Описание интерфейса компонентов
В процессе работы над системой список готовых компонентов растет, и для реализации новых логических функций уже не надо формировать задание для программиста. Новые бизнес-функции реализуются готовыми компонентами. Использование же готовых компонентов не представляет сложности, так как все они содержатся в проекте и к тому же документированы.
После завершения проектирования и реализации набора компонентов менеджер отдела маркетинга определяет группы пользователей, для которых будет доступна реализованная бизнес-функция.
Вся работа выполняется бизнес-менеджером методом “перетащи и оставь” в Rational Rose.
Рис. 6. Определение прав пользователей
Следующими шагами построения информационной системы (или Web-ресурса) является размещение информации о пользователях и сервисах в LDAP-сервере и настройка системы взаимодействия компонентов. Эти операции также производятся автоматически с использованием информации из проекта, созданного в CASE-средстве.
Таким образом, процесс создания бизнес-функционала тесно интегрируется с современными CASE-средствами фирмы Rational, а также использует передовые методологии объектно-ориентированного анализа и проектирования (RUP).
Рис. 7. Структура LDAP-хранилища
В заключение можно сказать, что предлагаемая методика применялась фирмой UnitSpace при создании нескольких проектов на американском и российском рынках электронного бизнеса. Более конкретно это можно рассмотреть на примере проектов “Восторг” и E-content Exchange.
Проект “Восторг” (www.vostorg.ru) - это портал, предоставляющий своим пользователям весь спектр решений в области электронной коммерции - от создания простейших витрин магазинов до крупных супермаркетов, которые обеспечивают работу со многими поставщиками, а также отдельных магазинов и групп магазинов, предоставляющих покупателю общую корзину. Обслуживающему персоналу каждого магазина предлагается мощный back-office.
Рис. 8. Примеры реализации моделей проектов
Проект E-content Exchange (www.unitspace.net) - это портал компании UnitSpace. Он содержит богатую библиотеку э-контента (фотографии товаров, текстовые описания, презентации и пр.) и сервисы, предназначенные для создания виртуальных промостраниц, промосайтов и каталогов товаров и интеграции их на страницы сайта или электронного магазина, что поможет повысить эффективность представления продукции в Интернете.
Опыт применения технологии
Испытание описанной технологии в компании UnitSpace подтверждает ее эффективность.
Во-первых, разработка проектов стала более структурированной, модель проекта в CASE-средстве содержит описание предметной области, наработанного функционала, а также сервисов, предлагаемых каждой информационной системой. Это позволяет в любой момент автоматически получить необходимую документацию по любому этапу проекта.
Во-вторых, специалистам UnitSpace удалось сократить время разработки за счет использования готовых компонентов. Информация о готовых компонентах из модели проекта существенно сокращает стоимость этапа проектирования.
Далее, менеджеры отдела маркетинга получили возможность создавать сервисы, предоставляемые системой, используя наработанный функционал бизнес-функций. Это сократило время, необходимое для разработки новых сервисов, и снизило стоимость их создания, что в свою очередь придало системе динамичность и повысило ее привлекательность для пользователя.
Использование собственных разработок и обобщенной спецификации для написания компонентов, объединенной с адаптацией объектно-ориентированной методологии под собственные технологии, а также творческий подход к применению CASE-средств позволили фирме UnitSpace разработать законченную методику создания информационных систем произвольной сложности на промышленной основе.
