Создание Программ как инженерная дисциплина

Предметом беседы редактора журнала «Открытые системы» Леонида Черняка с ведущими сотрудниками компании «АйТи», докторами наук — директором департамента консалтинга Борисом Позиным и аналитиком-консультантом Михаилом Кумсковым стали злободневные проблемы разработки прикладного ПО информационных систем

Борис Позин и Михаил Кумсков: «Мы проводим консалтинг и обучение, адаптацию методологии к нуждам заказывающего предприятия, поставку и техническую поддержку инструментальных средств, а также выполняем пилотные проекты совместно с заказчиком»

Борис Позин (БП): Признавая справедливость сказанного, хочу все же подчеркнуть — определенно, для упадочных настроений оснований нет, хотя дела по части внедрения ИТ воистину обстоят не слишком благополучно. По данным, публикуемым Standish Group, подавляющее большинство проектов действительно не завершается в намеченный срок, но, заметим, процент «незавершенки» сократился с 84% в 1996 году до 74% в 1998-м.

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

Заказчики заинтересованы в наличии строго детерминированного регламента на весь процесс выполнения заказа. Для этого как минимум необходимы: критерии оценки трудоемкости и длительности проектов, методики для оценки предложений участников тендера, а также «прозрачность», то есть возможность тотального контроля по ходу выполнения проекта на полноту и качество. Справедливость этого отрицать невозможно. Но нельзя не признать, что и сам заказчик является источником проблем; одна из них — «коммуникационная». Он не всегда может точно сформулировать свои требования, ему понятнее потребительская стоимость проекта и отдельные критерии оценки результата, чем конкретные требования к будущей системе, необходимые поставщику.

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

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

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

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

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

Михаил Кумсков (МК): Добавлю, что даже при построении информационных систем средней сложности возникают трудности во взаимодействии разработчиков и заказчика. Они, как правило, разговаривают на разных языках. Без специальных средств, без совершенствования интерфейса, о котором шла речь, не удается перевести содержательные требования в формальную спецификацию системы. Ее отсутствие существенно усложняет непрерывный процесс модификации кодов программ и структур. Статистика показывает, что 40-50% работ по проекту связано с переделками.

Еще в 60-х годах Фредерик Брукс, принимавший участие в разработке эпохальной OS/360, отмечал, что самое главное в системе — концептуальная целостность. Если сразу не определена единая концепция системы, не созданы проектные спецификации («чертежи») системы, то дальнейшее развитие и сопровождение такой ИС не только становятся трудоемким делом, но и ведут к росту хаотичности структуры системы в последующем. Если дело обстоит так, то «проектные ошибки» обнаруживаются только на этапах системной интеграции и внедрения, когда стоимость их исправления очень высока, а у разработчиков уже не остается для этого ни времени, ни средств.

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

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

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

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

БП: Прежде всего, введем для технологической оснастки термин «методология». Это своего рода неологизм, он не имеет ничего общего с традиционным науковедческим или философским представлением о методологии. Определим его следующим образом: «Методология — это регламентированный технологический процесс создания программного обеспечения».

Наличие методологии является обязательным условием для осуществления средних и крупных проектов разработки ИС в заданные сроки и с высоким качеством. На практике методология представляет собой совокупность взаимоувязанных стадий, этапов и операций, образующих технологический процесс разработки программного обеспечения. Обычно методология определяет распределение ролей в проекте и жизненный цикл разработки ПО. Известно несколько методологий: PJM (Oracle), MSF (Microsoft), RUP (Rational Software).

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

Важно подчеркнуть, что все известные методологии строятся на основании международного стандарта «Процессы жизненного цикла ПО» ИСО/МЭК 12207, который признан в качестве Государственного стандарта ГОСТ Р ИСО/МЭК 12207 и введен в действие в России с 1 июля 2000 года.

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

RequisitePro — инструмент для регистрации, классификации и управления требованиями. Возможность отслеживания зависимостей требований друг от друга позволяет визуально определять схожие требования в рамках проекта. Связи между требованиями позволяют определить те требования, которые следует дополнительно «посмотреть» при появлении изменений. Тем самым упорядочивается процесс внесения и обработки изменений. Атрибуты требований помогают устанавливать приоритеты, сортировать и выбирать требования, то есть вся информация о требованиях консолидирована воедино и сразу видно, кто, как и почему изменил требование.

Rational Rose — инструмент визуального проектирования. Для создания моделей используется стандартная нотация — унифицированный язык моделирования UML. Работа в Rose основана на использовании репозитария и построении диаграмм — диаграмм классов, диаграмм сценариев использования, диаграмм взаимодействий, компонентных диаграмм, диаграмм состояний, диаграмм развертывания. Rational Rose включает в себя средства автоматической генерации исходных кодов программ. Одним из его достоинств является наличие эффективных средств обратного проектирования, позволяющих автоматически строить модели по исходным текстам программ. Реинжиниринг позволяет выполнять перепроектирование унаследованных систем, включать в модели библиотечные классы и компоненты, использовать в проекте ранее созданные модули.

Rational ClearCase — средство конфигурационного управления при создании крупных ИС масштаба предприятия. Более 100 тыс. пользователей во всем мире используют Rational ClearCase для поддержки групповой и параллельной разработки крупных информационных систем. ClearCase отслеживает изменения вплоть до каждого файла и каталога, управляя полными историями аннотированных версий исходных и двоичных кодов, создания документации, библиотек и объектов, проведения тестирования и других параметров ИС. Разработчики могут быстро идентифицировать версию программного продукта, перестроить ее или вернуться назад к любой предыдущей версии.

Rational ClearQuest — инструмент для управления запросами на изменения. Дает возможность отслеживать и управлять всей деятельностью, связанной с изменениями, происходящими в течение всего жизненного цикла ИС, включая процесс исправления ошибок, обнаруженных тестировщиками. ClearQuest позволяет настраивать процессы внесения изменений в ИС в соответствии с потребностями конкретной организации.

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

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

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

Решения Rational Software широко используются ведущими компаниями мира. Мы уверены, что предлагаем заказчику то, что ему нужно.

Основные и поддерживающие процессы методологии Rational Unified Process