Все новости от 1 марта 2002 г.

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

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

Для предприятий государственного аппарата очень важно управление требованиями к используемому ПО, поскольку режим работы госучреждений сильно зависит от законодательной нормативной базы, подверженной частым изменениям. Здесь необходимы специальные инструменты (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, и не имеет универсальных решений.