Решения Rational Software
Борис Позин, Михаил Кумсков 
Управление требованиями в проекте
Управление заданиями и задачами
Из отчетов Standish Group1 известна нерадостная статистика — лишь 26% проектов создания программного обеспечения информационных систем завершаются успешно, то есть в срок и в рамках выделенного бюджета. Так, в 1996 году этот показатель составил 16%. При этом около трети проектов остаются незавершенными.
Возникающие проблемы зависят от типов подразделений в организации. Существуют заказывающие службы, например бухгалтерия, финансовые управления, отделы кадров. Им нужна автоматизация работ на базе информационных систем (ИС). Эти службы формируют заявки на создание/обновление ИС для разрабатывающих подразделений (IT-отделов) или заказывают покупку ИС у внешних фирм. Кроме того, обязательно существуют службы сопровождения ИС. У каждой службы свои задачи и свои проблемы, связанные с ИС.
Так, заказывающие подразделения хотят, чтобы ИС надежно и прозрачно поддерживала их работы, чтобы вновь созданные приложения не нарушали работу уже задействованных программ, чтобы их заказы на развитие ИС выполнялись в срок и чтобы новые модули ИС делали именно то, что нужно. Если в организации нет общих правил по формированию заявок на автоматизацию заказывающих подразделений, то IT-отделу будет трудно понять, что именно требуется подразделению-заказчику и как оперативно выполнить новый заказ, когда не завершена работа над предыдущими. Другими словами, необходимы стандарты предприятия, упорядочивающие работы по развитию и сопровождению корпоративной ИС.
Если организация решила разместить крупный заказ ИС у внешней фирмы, необходимы принципы оценки возможности фирмы-подрядчика справиться с данной работой. Существует, например, СММ-модель оценки (см. врезку), однако она нуждается в адаптации к российским условиям, ее следует оформить как методику отбора подрядчиков в тендере. Как правило, такие методики используются редко.
Перейдем теперь к разрабатывающим подразделениям (службам АСУ и фирмам, создающим прикладные программы). Перед ними стоят другие задачи. Например, как организовать работы над новым проектом, когда в работе находятся два или три крупных заказа, в которых заняты все программисты? Как сократить объемы переделок кода программ, вызванных изменяющимися и уточняющимися в ходе проекта требованиями? Как в подобных условиях планировать работы и оценивать текущий статус работ?
Разрабатывающие подразделения нуждаются в соответствующих методиках и регламентах управления проектами как на уровне плана, так и при формировании и изменении требований (технических заданий), отслеживания изменений в требованиях. При расширении IT-отдела, по мере роста объемов работ по многим проектам, становится жизненно необходимой упорядоченность взаимодействий и взаимосвязанных задач всех сотрудников. IT-службы понимают, что следует «лучше» организовать работы, но не знают, как это сделать и с чего начать.
У сопровождающих подразделений свои задачи. Требуется собирать замечания пользователей, фиксировать обнаруженные ошибки, принимать предложения по модификации программ — и все это отрабатывать в условиях, когда зачастую наряду с программами собственной (внутрифирменной) разработки эксплуатируются продукты третьих фирм. Известные проблемы обусловлены тем, что процесс сопровождения и развития ИС не регламентирован, отсутствуют организационно-распорядительные документы, описывающие процессы сбора и фиксации замечаний по работе ИС и предложений по совершенствованию программного обеспечения (ПО).
Даже при построении информационных систем средней сложности возникают трудности взаимодействия разработчиков и заказчика. Как правило, разработчики и заказчики ИС разговаривают на разных языках, что не позволяет однозначно перевести содержательные требования к ПО в формальную спецификацию системы. В результате в коды программ и структуру данных постоянно вносятся изменения. Статистика показывает, что 40-50% работ по проекту связано с переделками уже выполненной работы.
Еще в 60-х годах Фредерик Брукс2, принимавший участие в разработке знаменитой OS/360, отмечал, что самое главное в системе — это ее концептуальная целостность. Если сразу не определена единая концепция системы и, как результат, не создаются ее проектные спецификации («чертежи»), то развитие и сопровождение такой ИС не только становится делом трудоемким, но и ведет к дальнейшему росту «хаотичности» ее структуры. В этом случае «проектные ошибки» обнаруживаются только на этапах интеграции и внедрения, стоимость их исправления очень высока, а у разработчиков уже не остается для этого ни времени, ни средств.
Кто же виноват? На первый взгляд все — и заказчики, и разработчики — заинтересованы в том, чтобы проект был успешным. Рассмотрим причины трудностей, с которыми сталкиваются коллективы разработчиков.
По существу, есть только две подобные причины: сложность создаваемой ИС и неадекватная организация взаимодействия в проекте. Сложность создаваемых ИС вызвана объективными причинами, поскольку современные корпоративные ИС являются неотъемлемой составной частью бизнеса, сложного и быстроменяющегося. Другими словами, поскольку корпоративная ИС — это стратегический ресурс успешной работы предприятия, то требования к функциям ИС неизменно диктуются потребностями бизнеса. Такими требованиями являются необходимость оперативного доступа к актуальной информации для быстрого принятия точных решений. Корпоративная ИС должна эффективно и прозрачно поддерживать выполнение бизнес-процессов организации, легко адаптироваться к изменению условий работы компании.
В связи с этим происходит индустриализация информационных технологий и всей индустрии IT-отрасли. Вводятся стандарты, распределяются обязанности и ответственность, проводится формализация процессов и операций при создании сложного ПО.
Проблемы, связанные со сложностью ИС, накапливаются незаметно. Их возникновение похоже на болезнь роста, с которой сталкиваются все быстро расширяющиеся организации. Для того чтобы решать эти и подобные им проблемы, были предложены инженерные методы создания ИС-методологии. В их основе лежит «пошаговый подход» к разработке ИС. Этот подход требует определения этапов жизненного цикла, контрольных точек (milestones), правил работ для каждого этапа, что упорядочивает проектирование и разработку ИС.
Для каждого этапа жизненного цикла методология определяет:
- последовательность работ и выполняемых действий;
- правила их выполнения;
- состав и структуру получаемых промежуточных и итоговых документов;
- порядок их контроля и проверки качества;
- инструментальные средства поддержки работ.
Что можно посоветовать руководителям IT-подразделений? Осуществление средних и крупных проектов разработки ИС в приемлемые сроки с высоким качеством невозможно без применения современных методов программной инженерии, или методологий.
Методология поддерживает различные роли в проекте (рис. 1) и определяет жизненный цикл разработки ПО. Известны методологии различных фирм: PJM (Oracle), MSF (Microsoft), RUP (Rational Software). Принципы построения регламентов, содержащихся в методологиях, определены в стандарте ГОСТ Р ИСО/МЭК 12207, который введен в действие в России с 1 июля 2000 года3. Зрелость разрабатывающих подразделений и организаций можно оценить с помощью СММ-модели. Принципиальным фактором успеха при внедрении и использовании методологии является инструментальная поддержка ее процессов.
Ведущей методологией, в которой инструментально поддерживаются все этапы жизненного цикла разработки ПО, является методология фирмы Rational Software — Rational Unified Process (RUP). Она опирается на проверенные на практике методы анализа, проектирования и разработки ИС, методы управления проектами. RUP обеспечивает прозрачность и управляемость процесса и позволяет создавать ИС в соответствии с теми требованиями, которые были нужны заказчику на момент сдачи ИС, а также с возможностями, предоставляемыми инструментальными средствами поддержки разработки (рис. 2).
Что дает разработчикам инструментальная поддержка? Когда речь заходит о средствах фирмы Rational Software, как правило, имеется в виду CASE4-инструмент визуального моделирования и проектирования Rational Rose, хорошо известный российским разработчикам. В настоящее время этот продукт входит в состав инструментального пакета Rational Suite, в котором объединены усилия аналитиков, разработчиков и тестировщиков, позволившие преодолеть существующие между ними коммуникационные барьеры, оптимизировано выполнение специфических задач каждого члена команды, упрощена установка, поддержка и использование всех продуктов, входящих в Rational Suite (см. врезку).
Существуют специализированные варианты этого пакета, ориентированные на различные роли в проекте (рис. 3): AnalystStudio — законченное решение для аналитиков, DevelopmentStudio — для проектировщиков и разработчиков ИС, TestStudio — для тестировщиков приложений, Enterprise — поддерживает работы всего жизненного цикла разработки информационной системы.
Рассмотрим, как инструментально поддерживаются такие ключевые процессы жизненного цикла, как:
- Управление требованиями (Rational RequisitePro/RequisiteWeb);
- Визуальное моделирование (Rational Rose);
- Управление конфигурациями (Rational ClearCase);
- Управление задачами и изменениями (Rational ClearQuest/ClearQuestWeb);
- Тестирование (Rational TeamTest, Rational Performance Studio).
Управление требованиями в проекте
Требования к программному обеспечению фиксируются в техническом задании, но, как правило, изменяются и дополняются на протяжении жизненного цикла проекта. Rational RequisitePro позволяет создавать и управлять требованиями, которые записываются в БД на основе документов Microsoft Word и становятся доступны всем исполнителям команды разработчиков. Вся команда проекта находится в курсе принятых решений в течение всего процесса разработки.
RequisitePro — это простой инструмент для регистрации, классификации и управления требованиями. Возможность отслеживания зависимостей требований друг от друга позволяет визуально определять схожие требования в рамках проекта. Связи между требованиями дают возможность определить те требования, которые следует дополнительно «посмотреть» при появлении изменений в требованиях. Тем самым упорядочивается процесс внесения и обработки изменений.
RequisitePro интегрирован с Microsoft Word, атрибуты требований помогают устанавливать приоритеты, сортировать и выбирать требования, то есть вся информация о требованиях консолидирована воедино и сразу видно, кто, как и почему изменил требование.
 |
|
Визуальное моделирование
Инструмент визуального проектирования — Rational Rose. Для создания моделей используется принятая в 1997 году стандартная нотация — унифицированный язык моделирования (UML). Работа в Rose основана на использовании репозитария и построении диаграмм — диаграмм классов, диаграмм сценариев использования, диаграмм взаимодействий, компонентных диаграмм, диаграмм состояний, диаграмм развертывания.
Rational Rose включает в себя средства автоматической генерации исходных кодов программ. Одним из достоинств Rational Rose является наличие эффективных средств обратного проектирования, позволяющих автоматически строить модели по исходным текстам программ. Реинжиниринг позволяет выполнять перепроектирование унаследованных систем, включать в модели библиотечные классы и компоненты, использовать в проекте ранее созданные модули-компоненты.
|
|
Управление конфигурациями
Поскольку разработка ИС происходит при изменяющихся требованиях, в процессе внесения изменений необходимы учет множества факторов, оповещение о сделанных изменениях, одновременная разработка новой версии и исправление ошибок в старой, учет версий ИС, установленных у разных заказчиков и т.п. Здесь на помощь приходит Rational ClearCase — средство конфигурационного управления при создании крупных ИС масштаба предприятия. Более 100 тысяч пользователей во всем мире используют семейство продуктов Rational ClearCase для поддержки групповой и параллельной разработки крупных информационных систем. Rational ClearCase является лидером по числу продаж среди систем конфигурационного управления проектами.
Rational ClearCase — это инструментальное средство управления конфигурацией программного продукта с поддержкой как Windows-, так и Unix-платформ. Работает с наиболее популярными сегодня средами программных разработок, включая Visual Basic, Visual C++, Visual Java++, PowerBuilder и Oracle Developer/2000.
|
|
Управление заданиями и задачами
Инструмент типа «клиент-сервер» для управления запросами на изменения (Change request) с возможностью использования Windows и Web-интерфейса — Rational ClearQuest. Дает возможность отслеживать и управлять всей деятельностью, связанной с изменениями, происходящими в течение всего жизненного цикла ИС, включая процесс исправления ошибок, обнаруженных тестировщиками. ClearQuest позволяет настраивать процессы внесения изменений в ИС в соответствии с потребностями конкретной организации.
|
|
Автоматизация тестирования ИС
Средство автоматизированного тестирования приложений архитектуры «клиент–сервер» — Rational TeamTest. Его использование позволяет охватить все стадии тестирования, включая планирование тестирования, проектирование тестов, проведение системного тестирования, в том числе функционального и регрессионного тестирования.
Использование TeamTest позволяет существенно повысить производительность тестировщиков. TeamTest берет на себя рутинную работу по созданию и выполнению тестовых скриптов.
Средство нагрузочного тестирования приложений архитектуры «клиент—сервер» и Web-приложений — PerformanceStudio — позволяет оценить, как будет работать система в реальных условиях при различных конфигурациях аппаратно-программной платформы, измерить время реакции системы на запросы конечного пользователя, зафиксировать «узкие места» в системе.
Методология и инструментальные средства фирмы Rational Software широко используются ведущими компаниями мира, такими как «Боинг», «Эрикссон», «Форд», «Оракл», «Сименс», «Моторола», и многими другими. Имеется и отечественный опыт работы с указанной методологией в компаниях «АйТи», «Протек-Флагшип», «Аргуссофт» и др.
КомпьютерПресс 4'2001
