С.Трофимов
Разработкаи внедрение сложных программных комплексов для предприятий хранения ипереработки зерна требует привлечения значительных ресурсов как разработчикатак и самого предприятия, поэтому стоимость таких решений для промышленногопредприятия среднего размера начинается от нескольких десятков тысяч долларов внижнем ценовом диапазоне и практически не имеет верхней ценовой границы.Возникает вопрос есть ли пути ее уменьшения со стороны разработчиков системы.
Стоимостьсовокупного владения программной системой складывается из стоимости создания,стоимости внедрения и стоимости сопровождения. Причем достаточнораспространенной ошибкой при выборе ПО является учет стоимости только самойсистемы. Тогда как затраты на внедрение и сопровождение автоматизированнойсистемы управления предприятием (АСУП), которая должна работать десятилетиями,значительно перекрывают стоимость самого ПО.
Внастоящее время методы и средства уменьшения трудоемкости разработки исопровождения ПО (а значит и его стоимости) разработаны достаточно глубоко. Этотакие методы программной инженерии, направленные на создание сложных систем,как разработка открытых систем [1], разработка принципов оптимального разбиениясистем на модули [2], методы объектно-ориентированного анализа и проектированиясистем [3]. Сейчас для разработки ПО различного назначения широко применяетсяповторное использование программных объектов и программных компонентов [4],предлагаемых производителями средств ускоренной разработки приложений (rapidapplication development RAD). Использование CASE-средств [5] также позволяетзначительно сократить трудоемкость проектирования и сопровождения систем.
Казалосьбы, к вышесказанному уже нечего добавить, и при использовании перечисленныхметодов и средств стоимость создания и сопровождения ПО будет минимальной.Однако это не так. Резервы кроются в определенной структуре ПО системы, припомощи которой осуществляется снижение стоимости внедрения и сопровождения ПОАСУП. Сразу хочу заметить, что “серебряной пули” по выражению Ф. Брукса [6],позволяющей разрабатывать легко сопровождаемые, дешевые программные системы,еще не создано, и предлагаемый подход требует дальнейших исследований, однако,он уже применялся в той или иной степени при разработке Автоматизированнойинформационной системы для комбинатов хлебопродуктов (АИС КХП) которая успешноработает в режиме промышленной эксплуатации на нескольких десятках предприятийотрасли.
Особохочу отметить, что речь идет именно о структуре программного обеспечения, а несобственно информационной системы. Не для кого не секрет, что даже жесткозаданную функциональность можно реализовать различными методами, причем невсегда рассчитанными на дальнейшее сопровождение. Здесь можно отметитьособенности реализации при помощи различных языков программирования и личныепредпочтения того или иного программиста. Последнее часто доминирует при слабомконтроле или отсутствием такового со стороны руководителя проекта. Многиерешения в этом случае отдаются на откуп программисту, который часто не имеетдолжной квалификации для создания действительно легко сопровождаемой и дешевойпрограммной системы.
Этопри том, что структуру программного продукта трудно определить по внешнемувиду. Система отвечает заявленной функциональности и неизвестно, используетсяли в создаваемой системе та или иная конструкция языка, создается ли система наоснове взаимодействующих объектов или написана при помощи условных ибезусловных переходов.
Трудно,да часто и невозможно контролировать весь программный код системы. И уже черезкакое-то время работы выяснятся, что для того чтобы внести изменения в код,написанный программистом-контрактником, заинтересованным в быстром созданиинеобходимой функциональности, необходимо частично или полностью переписатьнедокументированный, неструктурированный, написанный без учета дальнейшегосопровождения код.
Мнеможно возразить, что для этого и существуют CASE-средства, однако, это толькосредства, а структура ПО создается все-таки программистом, в лучшем случае подруководством проектировщика.
Идаже в этом случае процесс разработки осуществляется без использования некихобщих законов, как, например, законов физики в строительстве, и полностьюосновывается на методах проб и ошибок [7]. Таких законов для разработки ПОпросто не существует, потому что научные основы для создания ПО толькоразрабатываются.
Такимобразом, предоставление программисту готовой структуры ПО, построенной наоснове объективных исследований конкретной предметной области, и методическихрекомендаций по созданию ПО на основе такой структуры может значительноуменьшить трудоемкость создания и, что немаловажно, сопровождения системы иуберечь от дорогостоящих логических ошибок при создании программных модулей.
Термин“типовой программный компонент” определяется как набор программных объектов,учитывающих особенности предметной области, неотделимых друг от друга в рамкахвыполнения определенного класса задач, имеющих унифицированный интерфейс,позволяющий ТПК взаимодействовать между собой без дополнительногокоординирующего кода и имеющих возможность изменения своих свойств без внесенияизменений в программный код.
ОсновойТПК при таком подходе является динамически создаваемое представление данных,использующее для этого хранимую в профиле пользователя информацию. Этимета-данные представляют собой описатели обрабатываемых полей таблиц, шаблоновввода-вывода и ссылок на другие таблицы. При этом все алгоритмы вывода напечать, поиска, группировки, добавления, удаления записей реализованынезависимо от обрабатываемой информации. Для заполнения ссылочной части таблицпредусмотрен интерфейс для взаимодействия с тем же модулем, но настроенным дляработы с другими данными, т.е. предусматривается рекурсивный вызов.
Длясоздания ПО на основе ТПК предлагаются следующие шаги:
1.СозданиеТПК — наиболее трудоемкий и дорогостоящий этап, который должен быть выполненквалифицированным программистом. Он включает в себя следующие пункты:
выборсредства создания (RAD,CASE);
определениенеобходимого набора функций;
определениенеобходимого объема адаптации;
созданиеиерархии классов;
созданиеисполняемого кода ТПК.
2.Анализпредметной области для дальнейшего создания модулей системы на основе ТПК. Этотэтап выполняется аналитиком системы и не включает в себя непосредственногопрограммирования. Его можно разбить на следующие пункты:
определениенабора информационных журналов для работы ТПК;
определениеструктуры информационных журналов, форматов полей данных и связей;
определениефункций и квалификации пользователей.
3.Модулейсистемы на основе ТПК и профилей пользователей. Этот этап выполняетсяпрограммистами средней квалификации и включает основной объем работ по созданиюсистемы. Этот этап разбивается на следующие пункты:
созданиеструктуры для динамического формирования представлений данных и принеобходимости программных модулей для их обработки на основе шаблонов ТПК;
заполнениеструктуры для динамического формирования представлений данных согласноструктурам информационных журналов, форматам полей и связей;
предварительноезаполнение профилей пользователей согласно функциям и квалификациипользователей.
4.НастройкаПО осуществляется отделом внедрения и, в дальнейшем, отделом сопровождениянепосредственно на предприятии и включает в себя следующие пункты:
определениеконфигурации дисковых устройств для конкретных рабочих станций;
заполнениеэталонов адресов хранения файлов;
окончательнаянастройка профилей пользователей согласно функциям и квалификации конкретныхпользователей с настройкой форм ввода-вывода.
Предложеннаяметодика позволяет сократить расходы на создание и сопровождение ПО АСУП путемсокращения размеров программного кода требующего дальнейшего сопровождения,повышения его гибкости, что позволяет осуществлять основную адаптацию кизменяющимся условиям эксплуатации силами самого предприятия без привлечения разработчика.Снижаются требования к квалификации программистов, повышается надежностьсистемы за счет использования многократно протестированных компонентов.
Список литературы
[1]Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационныхсистемах. –М.: Научная книга, 1997. – 368 с.
[2]Мамиконов А.Г. Методы разработки автоматизированных систем управления. –М.:Энергия, 1973. – 336 с.
[3]Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложенийна С++: Пер. с англ. –М.: –СПб.: Издательство Бином, Невский диалект, 1999.–560 с.: ил.
[4]Zubeck J. Повторное использование объектов в системах укоренной разработкиприложений // COMPUTERWEEKLY. – 1998. – №7.– C.24-28
[5]Трофимов С.А. CASE-технологии: практическая работа в Rational Rose. –M: ЗАОИздательство БИНОМ, 2001 г. -272 с.: ил.
[6]Брукс Ф. Мифический человеко-месяц или как создаются программные системы.- Пер.с англ. – СПб.: Символ-Плюс, 1999. – 304 с.: ил.
[7]Бюрер К. От ремесла к науке: поиск основных принципов разработки ПО.(http://interface.ru/rational/science.htm)