Внедрение структурного подхода и выбор CASE-средств

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

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

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

1. Поддержка методологий структурного (а не объектно-ориентированного) анализа и проектирования на начальных этапах проекта. Если Вы при общении с руководством или экспертом предметной области (например, с бухгалтером) будете употреблять слова “наследование”, ”инкапсуляция”, ”полиморфизм” и т.п., то в лучшем случае столкнетесь с непониманием.
2. Поддержка классических методов структурного анализа и проектирования. Это позволит Вам в случае неудовлетворенности пакетом относительно легко подобрать новый, не переделывая, а лишь перерисовывая (в худшем случае) наработанные модели.
3. Выбор в качестве первого опыта недорогих продуктов с учетом информации о реальных проектах, выполненных с их использованием. Например, известен ряд фирм и банков, использующих на начальных этапах проектирования автоматизированных банковских систем пакеты CASE.Аналитик для построения функциональной, а ERwin для построения информационной моделей.
4. Наличие средств экспорта/импорта фрагментов проекта, что при коллективной работе поможет избежать множества проблем, связанных с мультипользовательским доступом.
5. Обязательная поддержка автоматической верификации на полноту и состоятельность проекта и генерации отчетов по верификации.
6. Автоматическая генерация проектной документации в соответствии с общепринятыми стандартами (отечественных заказчиков вполне удовлетворяют ГОСТы, зарубежных - DOD STD-2167A).
7. Для функционального моделирования - наличие миниспецификаций процессов нижнего уровня (задаваемых общепринятыми методами), а не возможности задавать аналогичную информацию в качестве комментария при определении процессов. Это позволит полностью охватить технологии, применяемые заказчиком, и расширит возможности созданного проекта (например, его можно будет использовать для автоматизированного и быстрого обучения новых работников конкретному направлению деятельности).
8. Для информационного моделирования - наличие средств генерации схем БД для широкого спектра СУБД, а также поддержки обратного проектирования (reverse engineering), т.е. создания информационных моделей из существующих БД.

ПРИЛОЖЕНИЕ 2

Системы класса MRP

В конце 60-х годов Американским обществом управления производством и запасами (APICS), были сформулированы принципы управления предприятием, которые легли в основу концепции MRP (Material Requirement Planning), в настоящее время ставшей стандартом де-факто:

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

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

• планирование потребностей в материалах на основе данных о составе изделий и складских запасов (MRP);
• формирование производственной программы в масштабах всего предприятия и контроль ее выполнения на уровне подразделений (Closed Loop MRP);
• прогнозирование, планирование и контроль производства по всему циклу, начиная от закупки сырья и заканчивая отгрузкой товара потребителю (MRP II - Manufacturing Resource Planning);
• планирование потребностей в распределении и ресурсах при наличии у предприятия территориально-распределенной структуры и получение окончательного итога процесса моделирования сбытового и производственного планов в денежном выражении (MRP III - Money Resource Planning / ERP - Enterprise Resource Planning).

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

1. Планирование, включающее прогнозирование, производственное и объемно-календарное планирование, планирование потребностей в материалах и производственных мощностях.
2. Производство, включая ведение основных производственных данных по маршрутизации и составу изделия, оперативное управление производством, учет рабочего времени, расчет и контроль себестоимости продукции.
3. Управление запасами, и том числе управление данными по запасам, статистическое управление запасами, управление размещением запасов и планирование их распределения, управление партиями.
4. Управление сбытом, включая предложения и контракты на продажу, управление заказами на продажу, статистику по реализации, маркетинговую информацию.
5. Управление снабжением, включающее ведение предложений и контрактов, управление заказами и статистику.
6. Управление финансами, в том числе расчеты с заказчиками и поставщиками, главная книга, управление затратными центрами, субучет, финансовая отчетность и сводный баланс, учет основных средств.
7. Техническое обслуживание, включающее организацию техобслуживания и ремонта, обработку заявок, управление возвращенной продукцией.
8. Управление проектами, в том числе финансовая подготовка проекта (сметы), планирование проекта, конфигурация нестандартных изделий.
9. Проектно-конструкторские работы, включая управление чертежами, классификацию продукции, конструкторские спецификации и связь с САПР.

Примерами западных систем рассматриваемого класса являются R3 (продукт германской фирмы SAP AG), CA-MK/X (пакет американской фирмы Computer Associates), BAAN IV (продукт голландской фирмы Baan Int), IFS (пакет шведской фирмы IFS AB). Отечественные разработки значительно уступают перечисленным продуктам прежде всего по функциональности и степени интеграции модулей в единое информационное пространство. Кроме того, в отечественных продуктах отсутствуют встроенные средства наглядного описания бизнес-процессов (фактически, функционального и информационного моделирования).

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

ПРИЛОЖЕНИЕ 3