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

Тема 10. Классификация case-средств и моделей

1. Современная концепция разработки информационных систем

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

2. Модель "as is" (как есть) - позитивная модель

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

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

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

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

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

3.      модель документооборота. Обязательным условием при построении моде­лей является фиксация "стоимости" каждого описываемого процесса. Под "стоимостью" следует понимать не только и не столько ее денежное выра­жение, но и ее натуральные компоненты – затраты людских ресурсов, за­траты рабочего времени и т.д. Эти данные используются на следующем этапе, когда проводится предварительный анализ модели деятельности клиента, а также анализ предъявленных им требований.

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

3. Модель "to be"- нормативная модель

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

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