Средства производства программистов

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

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

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

И при этом некоторые отрасли отечественной промышленности и бизнеса (такие, как военная индустрия, банковское дело, топливно-энергетический комплекс и т. д.) всегда будут нуждаться в развитых технологиях производства ПО, сделанных в России.

Миф об универсальных готовых технологиях

На рынке средств автоматизации производства ПО наблюдается тенденция к интеграции компаний. Так, Logic Works (автор лучшего CASE-пакета для моделирования баз данных) была куплена фирмой PLATINUM (старейший производитель CASE-пакетов, имеющий один из лучших продуктов на рынке - Paradigm Plus). Последнюю, в свою очередь, приобрела Computer Associates.

Фирма Telelogic AB, автор лучшего SDL-продукта, купила WebLogic (создателя одного из лучших Requirenment Managеment Tools - DOORS) и еще ряд компаний и продуктов. SDL - один из стандартов европейского комитета ITU, развивается с 1976 г. и широко используется для спецификации телекоммуникационных систем.

Корпорация Rational Software, наиболее активно работающая на российском рынке средств автоматизации ПО, также скупала некоторые компании и продукты.

Таким образом, мы видим, что компании стремятся собрать у себя как можно больше средств поддержания жизненного цикла разработки ПО, не вступая разве что в конкуренцию с производителями сред разработки (компиляторов, СУБД и т. д.). Их конечная цель - представить в качестве объекта продажи единую интегрированную среду. Например, на российском рынке хорошо известна среда Rational Onified Process (RUP) фирмы Rational Software.

Однако такие среды имеют ряд существенных недостатков:

их дороговизну отмечают даже западные компании-клиенты;

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

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

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

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

Собственная технология

Отсюда следует вывод: никто не освобождает компанию от необходимости построения собственной технологии разработки ПО. При ее построении следует:

понять собственные проблемы, а не надеяться на то, что передовая технология, будучи внедренной, решит все (в том числе и не осознаваемые явно) проблемы;

быть готовым к глубокой доработке покупного ПО;

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

детально разрабатывать собственные правила использования средств автоматизации (как должностные инструкции, так и общие бизнес-процессы);

правильно выбирать приоритеты и руководствоваться в этом заповедью CMM - прежде чем внедрять передовые методы разработки (Software Engineering Methods), необходимо наладить первичный менеджмент (конфигурационное управление, управление качеством, требованиями и планами и т. д.).

Российские производители

Хотелось бы призвать российские компании к тому, чтобы они более внимательно пригляделись к отечественным средствам разработки прикладного ПО. Как правило, наши продукты уступают западным пакетам в "коробочности".

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

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

На российском рынке существуют интересные разработки (имеется в виду именно специальное ПО) в области автоматизации технологии создания ПО. Назовем некоторые из них.

Cреда "Шторм" компании ИВС (Пермь), состоящая из набора готовых решений реализации информационных систем в трехзвенной архитектуре (распределенная база данных, использование транзакционных мониторов и т. д.).

CASE-пакет REAL, разработанный в ЗАО "Ланит-Терком" на базе Санкт-Петербургского государственного университета. Пакет поддерживает два технологических решения - для событийно-ориентированных систем реального времени (спецификация архитектуры приложения и его событийно-ориентированной бизнес-логики с помощью визуальных моделей, кодогенерация, поддержка циклической дисциплины разработки) и для информационных систем (автоматическая генерация пользовательского интерфейса по схеме базы данных с поддержкой циклической дисциплины разработки).

Набор средств для тестирования систем реального времени, разработанный Институтом системного программирования РАН (Москва). Средства предназначены для работы на Java, Cи и т. д. Многие такие решения основываются на стандартном ПО (например, технология "Шторм" - на CASE-пакете Telelogic Tau UML Suite компании Telelogic AB). Однако оказывается, что распространение этих систем на российском рынке затруднительно ввиду сильной дороговизны составных частей, являющихся стандартным ПО для западных компаний.

Заметим, что приведенный список не претендует на полноту.

Примеры нестандартных проблем при разработке ПО

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

Для предприятий государственного аппарата очень важно управление требованиями к используемому ПО, поскольку режим работы госучреждений сильно зависит от законодательной нормативной базы, подверженной частым изменениям. Здесь необходимы специальные инструменты (Requirement Management Tools - RMT). Что касается проблемы связи требований с кодом, то здесь стандартных решений быть не может.

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

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

Значит, необходимы специальные средства тестирования и верификации ПО на инструментальной платформе. К сожалению, западные продукты, которые могут оказать существенную помощь в тестировании таких систем, очень дороги (например, протокольный анализатор для ATM-устройств фирмы Radcom в "голом виде" стоит 25-30 тыс. долл. плюс по 7 тыс. долл. за каждый дополнительный модуль; в итоге хороший анализатор с полной функциональностью может обойтись примерно в 150 тыс. долл.). Поэтому российские компании-разработчики обычно создают средства тестирования для себя сами и лишь в редких случаях покупают стандартные.

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

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

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

К сожалению, стандартных средств версионного контроля явно не хватает, поскольку недорогие средства (типа Microsoft Visual SourceSafe + SourceOffSite) не обладают надежными и многофункциональными возможностями сетевой работы, а более серьезные средства слишком дороги (например, Clear Case компании Rational Software Corp стоит $4000 за одно клиентское место, а такое средство должно быть у каждого участника проекта).

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

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

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

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

При тиражировании ПО для разных клиентов возникает проблема сопровождения множества версий, которая является одновременно и технической, и организационной, и проблемой внешнего менеджмента. Она связана с кругом вопросов, коротко характеризуемых термином Product Line, и не имеет универсальных решений.

Как создавать и развивать технологию

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

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

В области средств поддержания жизненного цикла разработки ПО существуют отдельные "острова", поддающиеся формализации, а потому удачно реализуемые в рамках стандартного ПО. И здесь нужно, как и в случае средств разработки (компиляторов, СУБД и т. д.), пользоваться "коробочным" ПО. Не претендуя на полноту, отметим такие направления:

планирование;

управление требованиями;

версионный контроль;

средства управления информацией об ошибках;

средства тестирования.

Здесь имеется большой выбор программных продуктов, поставляемых Microsoft, Rational Software, IBM и т. д.

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

Затем оценивается объем организационных преобразований на предприятии. Эта проблема является стандартной при автоматизации любого бизнес-процесса, в том числе разработки ПО. Такие преобразования могут включать в себя создание новых групп и отделов в организации - например, отдела качества (с функцией тестирования ПО, документирования и т. д.), технологической группы и др. Должны измениться и алгоритмы работы разработчиков и менеджеров.

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

Разработка технологии сопровождается немедленным внедрением.

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

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

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

Заключение

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

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