Управление проектами разработки
1. Методология разработки сложных программных систем
При создании сложного программного обеспечения (ПО) для корпоративных информационных систем (ИС) требуется четко и грамотно организовать весь процесс разработки/заказа ПО – от написания технического задания до внедрения на предприятии и дальнейшего развития этого ПО. Среди основных проблем, возникающих при разработке ПО без использования специальных технологий, можно выделить следующие:
- Разночтения в требованиях. Разработчики и пользователи разговаривают на "разных языках", что не позволяет точно перевести разрозненные неформальные требования в целостную формальную спецификацию системы. В результате трудно создать систему, отвечающую требованиям пользователей. Необходимы постоянные доработки и изменения.
- Отсутствие “чертежей”. Отсутствие проектных спецификаций ("чертежей") на систему приводит к отсутствию структуры и единой концепции системы. Развитие такой системы трудоемко и ведет к дальнейшему росту "хаотичности".
- Документирование постфактум. Трудоемкость документирования в ходе разработки выливается либо в неприемлемые сроки создания точной проектной документации в соответствии с требованиями стандартов, либо в неприемлемое качество документации, что влечет за собой проблематичность последующей модификации ПО ИС.
- Ошибки проектирования. Ошибки, возникающие на этапах анализа и проектирования, часто не удается обнаружить до самого начала внедрения, когда уже стоимость их исправления становится на порядок выше.
- Отсутствие общего контекста проекта. Подсистемы, создаваемые разными группами разработчиков, трудно интегрировать из-за отсутствия или недостаточной проработки общего контекста проекта.
- Обособленность проекта. Информационные системы не переносятся с одной платформы на другую, имеют сложное взаимодействие с внешними системами и являются тяжелыми для последующего развития. В результате разработка нового и изменение существующего программного обеспечения отнимают слишком много времени и средств.
Мировой опыт показывает, что для успешного создания подобного ПО необходимы апробированные современные методологии, опирающиеся на мощные и удобные инструментальные средства. Осуществление таких проектов в заданные сроки с высоким качеством невозможно без применения инженерных методов автоматизации программного производства, т.е. без современных CASE-технологий.
Ведущей методологией, в которой инструментально поддерживаются все этапы жизненного цикла разработки ПО, является методология Rational Unified Process (RUP). Она опирается на проверенные практикой методы анализа, проектирования и разработки ПО, методы управления проектами. RUP обеспечивает прозрачность и управляемость процесса и позволяет создавать ПО в соответствии с требованиями заказчика на момент сдачи ПО, а также в соответствии с возможностями инструментальных средств поддержки разработки.
2. Основные принципы организации работы над проектом
Ведущие идеологи инструментальной инфраструктуры IBM Rational (Г. Буч, Дж. Рамбо, А. Джекобсон), проанализировав опыт различных проектов в области разработки ИС, выделяют следующие обязательные факторы для успешного ведения любого проекта:
- постоянное взаимодействие с потенциальными пользователями с целью выяснения реальных требований к системе;
- тщательно проработанная архитектура системы, открытая для возможных усовершенствований;
- наличие высококвалифицированных специалистов;
- грамотно подобранный инструментарий;
- определение верного направления работ;
- продуманный процесс разработки, обеспечивающий адаптацию к изменяющимся потребностям бизнеса и требованиям новых технологий;
- высокая степень управляемости проектом и получение достоверной информации по его состоянию в любой момент времени.
При наблюдаемом в настоящее время взрывном росте количества приложений, как для исполнителя, так и для заказчика, необходимо выполнение высококачественных программных проектов быстрее, чем когда бы то ни было.
Программные проекты должны завершаться в ограниченные сроки и при этом оставаться в рабочем состоянии с гарантией качества. Возникает ключевая проблема – необходимо достичь баланса между качеством исполнения и скоростью разработки. Решения IBM Rational помогут Вам преодолеть эту проблему, объединяя лучший опыт и методологии разработки, соответствующие требованиям качества SEI CMM/CMMI, с унифицированными инструментами и сервисом, ускоряющими промышленную разработку ПО.
Итеративная разработка
Классический подход, широко применявшийся в прошлом и до сих пор часто встречающийся в настоящее время, – разработка программного обеспечения по методу "водопада".
При этом подходе разработка ПО движется линейно через стадии анализа требований, дизайна (проектирования), кодирования и тестирования отдельных модулей (компонентов), тестирование сборок и интегрированное тестирование всего конечного продукта. Основная проблема здесь заключается в том, что происходит нарастание риска преждевременного крушения проекта из-за накапливания различных ошибок, допущенных на ранних стадиях проекта. Если только к концу проекта, становится очевидно, что такие ошибки были допущены, то любой возврат к предыдущим стадиям с целью исправления ошибок становится крайне дорогостоящим.
Метод "водопада" не позволяет эффективно выявлять и нивелировать последствия подобных рисков. "Если вы сами активно не атакуете риски, то потом они будут активно атаковать вас” (Том Глиб, IBM Rational).
Эффективной альтернативой методу "водопада" служит итеративный подход.
Основой итеративного подхода является непрерывный анализ выполненных работ, последующее проектирование и физическое воплощение результатов проектирования. Итеративный подход акцентирует работу команды в более предсказуемом и повторяемом направлении.
Основные преимущества итеративного подхода:
- нивелирование воздействия серьезных рисков на ранних стадиях проекта, пока это еще можно сделать с минимальными затратами;
- возможность организовать плодотворную обратную связь с будущими конечными пользователями с целью создания системы, реально отвечающей их потребностям;
- акцент усилий на наиболее важные и критичные направления проекта;
- непрерывное итеративное тестирование конечного продукта, позволяющее оценить успешность всего проекта в целом;
- раннее обнаружение несоответствий между требованиями, моделями и программным кодом;
- более равномерная загрузка участников проекта;
- эффективное использование накопленного опыта;
- реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.
Эффективное управление требованиями
Неизбежной реальностью проектов создания современных ИС, является то, что список требований к системе динамически изменяется в ходе всего жизненного цикла. В любой момент следует ожидать пересмотра и корректировки требований. Более того, непрерывное выявление и уточнение реальных требований к системе – один из путей успешного ведения проекта. На старте проекта практически невозможно наиболее точным образом и в полном объеме определить необходимые требования, за исключением наиболее простых систем.
Реализация каждого отдельного требования представляет собой добавление в систему некоторой способности, которой та должна соответствовать.
Процесс управления требованиями охватывает несколько видов деятельности:
- выявление;
- организацию;
- документирование.
Существуют проверенные решения, которые позволяют гарантировать более эффективное ведение проекта, основанное на грамотном управлении требованиями. Они опираются на следующие аспекты:
- организованный подход к управлению требованиями;
- взаимодействие участников проекта на базе выявленных и утвержденных требований;
- ранжирование требований по приоритету, фильтрация их по необходимым параметрам и выявление зависимости между ними для контроля изменений;
- объективная оценка реализованного функционала и полученной производительности;
- раннее предсказание различных несоответствий и расхождений;
- использование инструментальных средств для организации более эффективного процесса управления требованиями.
Компонентный подход
Компонентный подход при создании ПО крайне важен, т.к. он обеспечивает повторное использование уже существующих компонентов и позволяет эффективно распределить работу между участниками проекта.
Применение компонентного подхода дает возможность повысить эффективность процесса разработки следующим образом:
- использование компонентов повышает гибкость архитектуры создаваемой системы;
- модульность компонентов позволяет четко определить границы тех изменений, которые требуется внести в систему при ее доработке;
- наличие множества коммерческих компонентов, которые разработаны и протестированы третьими фирмами, а также построены на основе промышленных спецификаций COM+, CORBA, Enterprise Java Beans (EJB) и др., облегчает реализацию и позволяет экономить проектные ресурсы;
- программные компоненты задают естественную основу для конфигурируемости продукта;
- средства визуального моделирования обеспечивают автоматизацию процесса разработки, опирающегося на компонентный подход.
Визуальное проектирование системы
Модель – это абстрагирование, упрощение реальности, позволяющее описать систему в предопределенном разрезе. Модели формируются для выявления того, какая система в конечном итоге должна быть построена.
Используя универсальный язык моделирования UML (Unified Modeling Language), участники проекта могут эффективно взаимодействовать друг с другом. Продуманное моделирование в различных его проявлениях предоставляет следующие возможности:
- однозначное описание функционального поведения системы с помощью прецедентов и сценариев;
- спецификация и анализ технических особенностей системы с помощью моделей;
- ранний акцент на построение гибкой и надежной архитектуры;
- сокрытие излишней детализации;
- выявление и исключение на ранних стадиях проекта ошибок проектирования.
Гарантия качества продуктов
Чем раньше участники проекта начинают заботиться о качестве разрабатываемой системы, тем дешевле им это обходится. Непрерывный контроль качества реализуется с помощью тестирования. Данный процесс предполагает создание тестов для каждого ключевого сценария, реализуемого в системе. Качество системы проявляется, прежде всего, в количестве успешных и неуспешных сценариев, что как раз и выявляется в процессе тестирования. Тестирование и разработка новых тестовых сценариев проводятся на каждой итерации проекта. Наборы сценариев и программных скриптов дорабатываются итеративно вместе с создаваемым продуктом.
Непрерывный контроль качества приводит к следующим позитивным моментам:
- оценка состояния проекта приобретает большую объективность, т. к. оценивается реальное функционирование системы, а не качество проектной документации;
- оценка проекта позволяет раскрыть несоответствия в требованиях, моделях и реализации;
- тестирование акцентирует внимание на тех сторонах работы системы, которые имеют наибольшую важность и повышенный риск;
- дефекты выявляются на ранних стадиях, что снижает затраты на их устранение;
- автоматизированное тестирование обеспечивает высокий уровень функциональности системы, надежности и производительности.
Контроль изменений
Для любого проекта характерна задача по организации работы между различными людьми и их группами. Отсутствие продуманного управления процессом разработки неизбежно приводит к возникновению хаотичности проекта и снижению его эффективности. Основой для объективного мониторинга проекта служит налаженный контроль изменений, который позволяет своевременно реагировать на возникающие проблемы. Контроль изменений приводит к следующему:
- деятельность по изменению требований становится предсказуемой и повторяемой;
- запросы на изменения формируют основу четкого и налаженного взаимодействия между участниками проекта;
- статистика по запросам на изменения создает отличную базу для оценки состояния проекта в любой момент времени;
- все изменения проекта находятся под контролем;
- с помощью контролируемых изменений строится система, адекватно отвечающая потребностям заказчиков.
3. Методология Rational Unified Process (RUP)
Ведущей методологией, в которой инструментально поддерживаются все этапы жизненного цикла разработки ПО, является методология Rational Unified Process (RUP). Она опирается на проверенные практикой методы анализа, проектирования и разработки ПО, методы управления проектами. RUP обеспечивает прозрачность и управляемость процесса и позволяет создавать ПО в соответствии с требованиями заказчика на момент сдачи ПО, а также в соответствии с возможностями инструментальных средств поддержки разработки.
В основе методологии RUP, как и многих других программных методологий, объединяющих инженерные методы создания ПО, лежит "пошаговый подход". Он определяет этапы жизненного цикла, контрольные точки, правила работ для каждого этапа и, тем самым, упорядочивает проектирование и разработку ПО. Для каждого этапа жизненного цикла методология задает:
- состав и последовательность работ, а также правила их выполнения;
- распределение полномочий среди участников проекта (роли);
- состав и шаблоны формируемых промежуточных и итоговых документов;
- порядок контроля и проверки качества.
RUP как методология
Методология RUP позволяет объединить проектную команду, предоставляя в ее распоряжение проверенные мировой практикой лучшие подходы к разработке ИС. К ним относятся такие процессы жизненного цикла создания ПО, как управление проектами, бизнес-моделирование, управление требованиями, анализ и проектирование, тестирование и контроль изменений. Внедрение RUP в организации способствует выработке качественных внутрикорпоративных стандартов и повышению общей культуры разработки.
Основа RUP – итеративный процесс разработки. В условиях активно развивающегося мирового бизнеса практически невозможно создавать современные сложные программные системы последовательно, т. е. сначала выявлять все проблемы, затем принимать проектные решения, потом формировать программное обеспечение и, наконец, проверять полученное изделие. Итеративный подход позволяет улучшать понимание проблем на основе последовательных усовершенствований и конкретизировать их в эффективных решениях. Этот подход обеспечивает большую гибкость при изменяющихся требованиях и тактических коррективах в бизнес-целях, что позволяет более эффективно и заблаговременно идентифицировать и снижать проектные риски.
Rational Unified Process – управляемый процесс. Итеративный подход предполагает управление требованиями и изменениями, чтобы между всеми участниками проекта обеспечивать единое понимание ожидаемых функциональных возможностей, требуемый уровень качества, наилучшее управление затратами и графиками выполнения работ.
Rational Unified Process – процесс создания и физического воплощения визуальных моделей. RUP фокусирует внимание не на создании большого количества бумажных документов, а на развитии и применении визуальных моделей – семантически богатых представлений разрабатываемой ИС. RUP сосредотачивает внимание на разработке и дальнейшем развитии надежной и гибкой архитектуры, которая облегчает параллельную разработку, минимизирует необходимость изменений, увеличивает возможность многократного использования и надежность эксплуатации системы. Подобная архитектура применяется для планирования использования программных компонентов и управления их развитием.
Rational Unified Process – процесс управления действиями с помощью прецедентов, определяющих функционал системы. Понятия прецедентов и сценариев работы способствуют эффективному управлению технологическим маршрутом от бизнес-моделирования и требований вплоть до испытаний. Они обеспечивают связанные и доступные для анализа направления разработки и развертывания системы.
Rational Unified Process поддерживает объектно-ориентированную технологию. Моделирование по методологии RUP является объектно-ориентированным и базируется на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), в качестве единого стандарта для организации взаимодействия участников проекта используют Unified Modelling Language™ (UML) – универсальный язык моделирования.
Rational Unified Process поддерживает компонентно-ориентированный подход. Компоненты – это нетривиальные модули или подсистемы, которые выполняют конкретную функцию и могут быть использованы многократно. Как правило, компоненты соответствуют одной из промышленных спецификаций, таких как CORBA, COM/DCOM, ActiveX, Enterprise Java Beans и др.
Rational Unified Process – адаптируемый и конфигурируемый процесс. Опыт единичного проекта, даже успешно завершенного, вряд ли подойдет для создания ПО во всех случаях и условиях. Но способность RUP к адаптации подойдет как маленьким группам разработчиков, так и большим организациям. RUP содержит рекомендации по конфигурированию процесса для удовлетворения потребностей практически любых компаний и их подразделений.
Rational Unified Process поддерживает объективно осуществляемое управление качеством. Оценка качества всех работ, выполняемых любыми участниками проекта, использует объективные метрики и критерии. Методология RUP создавалась с прицелом на поддержку управления качеством в рамках требований SEI CMM/CMMI.
Структура жизненного цикла проекта
Структуру жизненного цикла проекта, выполняемого по технологии RUP удобно рассматривать на координатной плоскости. При этом по горизонтальной оси отложено время, а по вертикальной – основные деятельности, которые обычно выполняются в ходе любого проекта, претендующего на статус успешного.
Время отражает динамический аспект жизненного цикла проекта, выраженный в терминах циклов, фаз, итераций и контрольных точек, которые разделяют две отдельные фазы. Вертикальная ось отражает статический аспект проекта. Он описывается в терминах процессов, артефактов (единица информации, создаваемая или модифицируемая в ходе любого процесса) и ролей (ответственность за адекватное выполнение той или иной деятельности в процессе). RUP организует выполнение проекта по фазам, каждая из которых состоит из одной или нескольких итераций. При итеративном подходе объем работ по каждому процессу варьируется в течение всего жизненного цикла. Контрольные точки в конце фаз позволяют оценить, насколько успешной была предыдущая фаза и насколько успешен весь проект в целом. RUP определяет следующие основные процессы:
- моделирование бизнес-процессов;
- управление требованиями;
- анализ и проектирование;
- реализация;
- тестирование;
- развертывание;
- конфигурационное управление и управление изменениями;
- управление проектом;
- управление средой.
Моделирование бизнес-процессов применяется с тем, чтобы разобраться в структуре исследуемой предметной области, обеспечить единство понимания основных автоматизируемых процессов среди всех участников проекта и определить высокоуровневые требования, которые должны быть реализованы в ходе проекта.
Управление требованиями позволяет прийти к соглашению с заказчиками и конечными пользователями, определить, что должна уметь делать создаваемая система, предоставить более четкие инструкции участникам проекта о возможностях системы, создать базу для успешного планирования работ в проекте и оценки его статуса в любой момент жизненного цикла.
Анализ и проектирование служат для последовательного преобразования выявленных требований к системе в спецификации особого вида, которые описывают, как следует конкретно реализовать конечный продукт. Следует при этом делать различия между анализом и проектированием. Основное из них состоит в том, что спецификации анализа не зависят от конкретной платформы и технологии, для которой осуществляется создание ИС. А спецификации проектирования являются точным представлением проектируемой системы, часто позволяя автоматизировать процесс генерации на их основе программного кода.
Реализация необходима для выявления порядка организации программного кода в терминах отдельных подсистем, преобразования исходного кода в выполняемые компоненты, тестирования созданных компонентов и интеграции отдельных компонентов в подсистемы и системы.
Тестирование позволяет определять и контролировать качество создаваемых продуктов, следить за тем, насколько качественно осуществлена интеграция компонентов и подсистем, все ли требования к системе реализованы и все ли выявленные ошибки устранены до того, как система будет развернута на оборудовании конечного пользователя.
Развертывание является процессом, в ходе которого осуществляется доставка разрабатываемого продукта к конечному пользователю. В ходе данного процесса производится новый выпуск системы, распространение ПО, его установка на стороне конечного пользователя, обучение последнего навыкам эффективной работы с поставленным ПО, предоставление услуг по технической поддержке, бета-тестирование и т. п.
Конфигурационное управление и управление изменениями позволяет организовать эффективную работу с артефактами проекта, контролировать и управлять доступом к ним, вести историю изменений, обеспечить эффективное взаимодействие участников проекта, как в простых командах, так и в распределенных, находящихся на большом удалении друг от друга.
Управление проектом включает в себя непосредственное формирование условий для эффективного хода всего проекта, определение руководств и руководящих принципов для планирования, формирования команды и мониторинга проекта, выявление и управление рисками, организацию работы участников проекта, формирование бюджета, планирование фаз и итераций.
Управление средой позволяет осуществить поддержку всех участников проекта. В эту поддержку входят выбор инструментария и его приобретение, настройка и установка, конфигурирование процесса, доработка и адаптация методологии, используемой для ведения проекта, обучение.
Важнейшие акценты RUP
Главная цель любой организации, занимающейся созданием информационных систем – работать эффективнее, а значит, быстрее создавать более качественные продукты и получать бизнес-преимущества от успешного ведения проектов. Внедрение передовой методологии, подобной RUP, позволяет гарантировать выработку и дальнейшее развитие в организации необходимых для этого навыков.
Однако внедрение методологии – не столь уж простой процесс, как это может показаться на первый взгляд. Очень важно, стремясь к более эффективному ведению проектов, не разрушить то, что уже достигнуто. Особенность методологии RUP в том, что она может быть настроена и адаптирована в соответствии с особенностями и требованиями организации-разработчика, при этом варианты внедрения RUP могут варьироваться в зависимости от конкретных условий.
Для упрощения перехода к методологии RUP допускается постепенное его внедрение. Но при этом RUP акцентирует внимание на нескольких важнейших элементах, без которых сложно гарантировать успех в проекте.
- Общее видение проекта. Сюда относятся первоначальный анализ будущего проекта, организация единого словаря для общения и ведение спецификации требований. Это важно потому, что участники проекта должны четко понимать цели проекта.
- Бизнес-перспективы проекта. Важны потому, что в основном проект выполняется для реализации каких-либо бизнес-целей. И если такие цели существуют, то имеет смысл начинать процесс разработки. Это не относится напрямую к научным и исследовательским проектам, т. к. их финансирование имеет иные корни.
- План работ. Позволяет определить ресурсы проекта, привязать их к задачам и рассчитать бюджет проекта. Таким образом, имеется возможность заранее спрогнозировать, насколько выгодно вести конкретный проект и какие могут быть при этом затраты.
- Анализ рисков. Важен потому, что обычно намного легче и дешевле выявить и устранить возможные проблемы заранее, чем делать это уже на поздних стадиях проекта.
- Гибкая и надежная архитектура системы. Гарантирует, что проект не потерпит крушение задолго до его завершения, что разработчики смогут развивать данную систему при изменении условий и правил ведения бизнеса на стороне заказчика.
- Управление запросами на изменения. Позволяет организовать эффективную работу и взаимодействие участников проекта. Возрастает контроль за качеством выполнения задания любого уровня, отслеживанием устранения ошибок и обработки предложений по дальнейшему развитию ИС.
- Тестирование. Дает возможность гарантировать высокое качество продукта, а, следовательно, не даст заказчику повод усомниться в возможностях организации-разработчика.
- Акцент на самом продукте. Крайне важен, потому что продукт – конечная цель любого проекта. Надо помнить в любой момент, что важны не модели или многочисленные документы проекта сами по себе, а именно конечный продукт. Все остальное создается только с тем, чтобы как можно скорее создать качественный продукт.
- Документы для поддержки пользователя. Необходимы, т. к. без них многие сильные стороны созданного продукта могут остаться неизвестными и недоступными.
- Измерение проекта. В любой момент времени необходимо, чтобы вовремя реагировать на возможные отклонения проекта от бюджета и на перерасход ресурсов.
4. Моделирование и проектирование
Моделирование представляет собой один из ключевых процессов создания программного обеспечения, направленный на решение следующих задач:
- снижение сложности понимания предметной области;
- понимание структуры и динамики предметной области, в которой должна быть развернута система (целевой организации);
- понимание текущих проблем целевой организации и определение потенциальных возможностей усовершенствования;
- обеспечение общего понимания целевой предметной области заказчиками, конечными пользователями и разработчиками;
- выявление системных требований, необходимых для автоматизации предметной области.
Область моделирования охватывает следующие дисциплины:
- бизнес-моделирование предметной области, которая рассматривается как потенциальная для внедрения процессов автоматизации;
- функциональное моделирование системы, которая позволяет автоматизировать некоторую часть исследуемой предметной области;
- анализ и проектирование системы, которые позволяют сформировать детальное представление системы на уровне конкретных средств реализации.
Многие компании добились большей эффективности в процессе создания сложных программных систем благодаря средствам моделирования начального уровня, которые на протяжении ряда лет предлагались в составе продуктов IBM Rational и хорошо знакомы сообществу разработчиков. Имея невысокую стоимость в расчете на одного пользователя, они позволили бизнес-аналитикам эффективно описывать процессы и данные. Однако, по мере изменения и усложнения бизнес-требований, появилась потребность в использовании более развитых и совершенных средств моделирования и проектирования, которые отражали бы бизнес-ориентированный подход к процессу создания программных систем.
Для выполнения этих требований, IBM существенно расширило возможности традиционных средств моделирования, таких как IBM Rational Rose и IBM Rational XDE Modeler, новыми инструментами в составе пакета IBM Rational Software Architect (RSA). Одним из преимуществ новых средств моделирования является возможность автоматизированного преобразования моделей, позволяющая быстро переходить от высокоуровнего моделирования к разработке и тестированию приложений. Это позволяет более эффективно использовать шаблоны проектирования (patterns), стандарты и лучшие проектные решения для создания высококачественного кода и повышения общей эффективности проектов разработки программных систем. Базовые возможности новой линейки средств графического моделирования, дизайна и проектирования реализованы в продукте IBM Rational Software Modeler. IBM Rational Software Architect включает всю функциональность IBM Rational Software Modeler, дополняя ее возможностями автоматизированного преобразования моделей и поддержкой C++ в дополнение к Java.
Кроме того, новые средства моделирования в линейке IBM исключают риски использования нестандартной технологии моделирования, жестко привязанной к технологии конкретного поставщика. Решения IBM Rational Software Architect построены на базе Eclipse – платформы с открытым исходным кодом, написанной на Java, что дает возможность быстро наращивать объем функциональных возможностей предлагаемых решений в соответствии с конкретными требованиями проекта. Eclipse поддерживает использование модулей расширения независимых разработчиков (plug-in), что также способствует созданию оптимальной среды моделирования приложений как в среде Windows, так и в среде Linux.
Специализированные средства моделирования позволяют автоматизировать повторяющиеся действия, тем самым повышая не только продуктивность, но и зрелость процесса разработки программного обеспечения в целом. Во многом этому способствует использование стандартизованного языка моделирования Unified Modeling Language (UML). Однако, как показывает опыт, текущей версии UML были присущи определенные ограничения, в частности, в сфере моделирования структуры и поведения сложных систем. Новые средства моделирования IBM поддерживают UML версии 2 (UML 2), в которой предлагаются структурированные классы, усовершенствованные блок-схемы, диаграммы действий и диаграммы конечных автоматов, что позволяет гораздо более точно отображать архитектуру будущих программных систем.
Кроме того, средства моделирования в составе IBM Rational Software Architect поддерживают Model Driven Architecture (MDA) – новую инициативу Object Management Group (OMG) в области описания управления процессами, благодаря которой становится возможным определять несколько уровней моделей, связанных с заданными пользователем преобразованиями между моделями, для более четкого разделения аспектов жизненного цикла. Новые средства проектирования IBM поддерживают как последнюю версию этого языка – UML 2.0, так и более ранние реализации.
Для поддержки инструментальных средств и платформ, не вошедших в пакет IBM Rational Software Architect, используются средства моделирования из пакета IBM Rational Suite. При совместном использовании пакетов IBM Rational Professional Bundle и IBM Rational Suite возможен импорт моделей из IBM Rational Rose в RSA для реализации моделей на платформе J2EE.
Возможности инструментального средства IBM Rational XDE Modeler включены в инструментальные средства нового пакета RSA. Однако, если в организации уже наработано большое количество скриптов для IBM Rational XDE Modeler, то, из-за возможной трудоемкости переноса имеющихся скриптов на новые инструментальные средства, может оказаться целесообразным продолжение использования IBM Rational XDE Modeler наряду с новой линейкой инструментальных средств RSA.
Кроме того, линейка средств моделирования IBM включает также IBM WebSphere® Business Integration Modeler (WBI Modeler) – средство моделирования бизнес-процессов, которое входит в пакет для бизнес-интеграции IBM WebSphere. WBI Modeler наряду с новыми средствами IBM Rational является частью интегрированной платформы разработки на основе Eclipse. По этой причине мы посчитали целесообразным также включить его описание в данный раздел.
5. Средства разработки ПО
Основные цели разработки ПО:
- определение структуры кода на основе реализуемых подсистем, организованных по уровням;
- реализация классов и объектов в виде модулей (исходных, двоичных, исполняемых файлов и др.);
- тестирование разработанных модулей;
- интеграция результатов работы отдельных программистов (или групп) в рабочую систему.
Для ведения непосредственной разработки IBM Rational предлагает целый набор специализированных инструментальных средств:
- IBM Rational Application Developer
- IBM Rational Web Developer
- IBM Rational XDE Developer
6. Тестирование
Тестирование программного обеспечения занимает от 30 до 50 процентов от всей стоимости разработки. Однако многие полагают, что приложение не может быть хорошо протестировано до момента внедрения. Это заблуждение основано на двух фактах. Во-первых, тестирование ПО является чрезвычайно сложным процессом. Выполнение любой программы может иметь неисчислимое количество различных путей. Во-вторых, тестирование часто проводится без четкой методологии и без требуемой автоматизации с помощью соответствующих инструментальных средств. Сложность создаваемого ПО делает невозможным проведение 100%-го тестирования, но хорошо продуманная методология и использование современных инструментальных средств, могут значительно улучшить производительность и эффективность тестирования ПО.
Основные цели тестирования:
- проверить взаимодействие между объектами;
- проверить корректную интеграцию всех модулей системы;
- проверить, что все требования были корректно реализованы;
- идентифицировать дефекты и убедиться, что они максимально выявлены еще до развертывания системы.
Хорошо выполненные тесты, запуск которых осуществляется еще на ранней стадии жизненного цикла, могут значительно снизить стоимость завершения проекта и поддержки ПО. Это может также значительно снизить риски или штрафы, связанные с поставкой ПО плохого качества, исключить низкую производительность работы приложений конечных пользователей, неудобство ввода данных, наличие вычислительных ошибок и ошибочное функциональное поведение системы. Для систем "с особыми требованиями к безопасности", когда отказ в работе может причинить вред людям или принести значительные убытки компании – таких, как системы управления воздушными полетами, управления ракетами или медицинскими поставками, финансовые приложения – высокие требования к качеству ПО являются необходимыми для успеха разрабатываемой системы. Для обычной информационной административной системы такие требования не являются настолько критичными, но эффект от всего лишь одного дефекта может быть, тем не менее, достаточно дорогостоящим.
В соответствии с RUP принята следующая базовая классификация видов тестирования:
1. Функциональное тестирование
- непосредственно функциональное тестирование (Function testing);
- тестирование целостности данных (Data integrity testing);
- тестирование на разных платформах (Configuration testing);
- тестирование отказоустойчивости (Failover & recovery testing);
- тестирование доступа (Security testing);
- инсталляционное тестирование (Installation testing);
- тестирование пользовательского интерфейса (User interface testing).
2. Нагрузочное тестирование
- непосредственно нагрузочное тестирование (Load testing);
- профилирование производительности (Performance profiling);
- тестирование цикла работы (Business cycle testing);
- тестирование при большой пользовательской нагрузке (Stress testing);
- тестирование на больших объемах данных (Volume testing).
Для автоматизации процессов тестирования IBM Rational предлагает следующие инструментальные средства.
Средства тестирования в линейке продуктов Atlantic, входящие в пакет IBM Rational Professional Bundle:
- IBM Rational Performance Tester – средство нагрузочного тестирования.
- IBM Rational Functional Tester – средство функционального тестирования, включает также IBM Rational Manual Tester – средство для организации и проведения ручного тестирования.
Эти средства предназначены для функционального и нагрузочного тестирования программного обеспечения, создаваемого на платформе J2EE. Они интегрированы с инструментом IBM Rational TestManager, входящего в пакет IBM Rational Team Unifying Platform и служащего средством планирования и мониторинга процесса тестирования как для инструментов тестирования новой линейки продуктов Atlantic, так и многоплатформенных средств тестирования линейки продуктов IBM Rational Suite.
Средства тестирования, в составе IBM Rational Suite:
- IBM Rational Robot – cредство разработки, записи и выполнения скриптов автоматизированного функционального и регрессионного тестирования приложений, предоставляющее полную поддержку тестирования всех средств управления Visual Studio.NET.
- IBM Rational XDE Tester – расширенные средства автоматизированного функционального и регрессионного тестирования Java- и Web-приложений из сред разработки Eclipse IDE, IBM WSAD и Rational XDE.
- IBM Rational Purify – средство выявления ошибок, связанных с обращением к динамической памяти (версии для Windows и UNIX)
- IBM Rational Quantify – средство выявления узких мест в коде, оказывающих влияние на производительность разрабатываемой информационной системы.
- IBM Rational PureCoverage – средство определения полноты тестирования кода.
- IBM Rational TestFactory – средство для полуавтоматического формирования набора тестовых скриптов, предназначенных для проведения функционального тестирования и обеспечивающих его полноту для конкретной информационной системы; способен выполнить анализ графического интерфейса разрабатываемой ИС и сгенерировать для нее комплексный набор тестов, позволяющий провести максимально полное функциональное тестирование.
Средства управления тестированием в составе Team Unifying Platform:
- IBM Rational TestManager – средство планирования и мониторинга процесса тестирования, входит в объединяющую платформу Team Unifying Platform, а также в пакет IBM Rational Suite.
Основным инструментом для планирования процесса тестирования, описания его сценариев и управления всем ходом данного процесса является IBM Test Manager, который входит в состав пакета Team Unifying Platform и подробно описан в соответствующем разделе. На основе требований на тестирование, которые аккумулируются с помощью IBM Rational RequisitePro, специальный механизм интеграции RequisitePro и TestManager позволяет сформировать план тестирования. Элементами плана служат сценарии, каждый из которых позволяет протестировать какой-либо аспект работы создаваемой ИС. Сформированный план тестирования дополняется тестовыми скриптами, которые формируются с помощью IBM Rational Robot и позволяют автоматизировать процесс тестирования.
При проведении распределенного тестирования, в частности, когда требуется одновременно проверить систему на разных программно-аппаратных платформах, используются специальные агенты (Test Agents). Таким образом, можно одновременно протестировать систему в операционных системах Windows, Linux, HP-UX, Solaris и AIX.
Для проведения расширенного функционального и регрессионного тестирования Java- и Web-приложений рекомендуется использовать новый продукт – IBM Rational XDE Tester. Для автоматизации процесса создания необходимых отчетов – плана тестирования, отчетов по результатам тестирования и т. п. – могут быть использованы Seagate Crystal Report и IBM Rational SoDA.
Для анализа работы систем, построенных с помощью языков C/C++, Microsoft Visual Basic, Java, C# .NET, VB. NET и Java .NET, можно использовать средства IBM Rational Purify, Quantify и PureCoverage. Основное назначение Purify при тестировании native-приложений (приложения, работа которых не управляется с помощью дополнительного окружения, например, так называемых сборщиков мусора) – выявить всевозможные утечки памяти и любые иные ошибки работы с ней. Для приложений класса managed applications (такие, как Java- и .NET-приложения) Purify позволяет провести эффективное профилирование памяти с целью оптимизации ее использования. С помощью Quantify становится проще определить узкие места производительности системы и провести ее настройку вплоть до отдельных строк программного кода. PureCoverage окажется незаменимым, если требуется оценить полноту тестирования системы.
IBM Rational TestFactory – еще одно специализированное средство автоматизированного тестирования, предназначенное для анализа графического интерфейса пользователя (GUI) разрабатываемой информационной системы и генерации полного набора тестов, позволяющего провести максимально полное функциональное тестирование.
7. Управление проектами и портфелями
Управление проектом по разработке программного обеспечения – это своего рода искусство балансирования между конкурирующими целями, рисками, различными ограничениями и обстоятельствами. Основной задачей данного процесса является обеспечение успешной поставки продукта, удовлетворяющего потребностям заказчиков – основных плательщиков по счетам, и потребителей – конечных пользователей.
Основные цели управления проектами:
- организация процесса управления проектом, планирование проекта на протяжении всего жизненного цикла и отдельной итерации;
- соблюдение основных принципов планирования, управления персоналом, выполнения работ и мониторинга проекта с помощью соответствующих метрик;
- эффективное управление рисками.
Компании и организации обычно ведут много проектов, которыми необходимо управлять – как традиционных IT-проектов, например, по разработке ПО или внедрению автоматизированной системы, так и проектов в других областях. Управление портфелем проектов – это подход, который позволяет держать под контролем широкий диапазон проектов и ресурсов, обеспечивая необходимый уровень их управляемости. Помимо управления единым финансовым портфелем, управление проектами включает множество различных процессов – управление ресурсами, затратами, рисками, качеством, а также другие связанные с этим процессы, и все они должны выполняться совместно.
В составе новой линейки средств IBM Rational предлагается надежный инструмент для управления проектами и портфелями, который играет ключевую роль в обеспечении процесса разработки программного обеспечения, управляемого бизнес целями компании – IBM Rational Portfolio Manager. Этот инструмент предоставляет командам разработчиков возможности по управлению проектами, значительно превышающие возможности программы MS Project, в то же время позволяя интегрироваться с ней.
8. Управление требованиями
Успешный опыт разработки показывает, что эффективное управление требованиями является ключевым фактором всего процесса разработки ПО. Требования определяют то, что должна делать система. Поэтому в течение всего жизненного цикла проекта нужно организовать эффективную работу с ними. Первым шагом в этом направлении служит организация хранения всех выявленных требований.
Основные цели процесса управления требованиями:
- понять структуру и динамику предметной области, в которой должна быть развернута создаваемая информационная система;
- понять текущие проблемы предметной области и определить потенциальные возможности ее усовершенствования;
- обеспечить общее понимание предметной области заказчиками, конечными пользователями и разработчиками;
- выявить системные требования, необходимые для поддержки автоматизации предметной области;
- установить и поддержать соглашение с клиентами и другими заинтересованными лицами на том, что система должна делать;
- обеспечить разработчиков системы лучшим пониманием требований к ее созданию;
- определить функциональные границы создаваемой информационной системы;
- обеспечить базис для планирования технического содержания фаз разработки;
- обеспечить базис для оценки стоимости и времени на разработку информационной системы;
- определить графические интерфейсы пользователей с учетом их потребностей и целей.
Основным инструментом для организации работы с требованиями в проекте является IBM Rational RequisitePro. Он позволяет команде работать с требованиями, отслеживать возможные изменения в них и организовывать обсуждения.
9. Управление конфигурациями и изменениями
Перефразируя модель зрелости процессов Института программной инженерии (SEI CMM), можно сказать, что конфигурационное управление и управление изменениями обеспечивает контроль за изменениями и обеспечивает взаимосвязь артефактов проекта. Методы, процессы и инструментальные средства, используемые для обеспечения конфигурационного управления и управления изменениями в организации, могут рассматриваться как единая система конфигурационного управления.
Конфигурационное управление и управление изменениями включают:
- идентификацию объектов конфигурационного управления;
- ограничение возможности изменения этих объектов;
- аудит изменений, произведенных с объектами конфигурационного управления;
- определение конфигураций объектов конфигурационного управления и управление этими конфигурациями.
Система конфигурационного управления является необходимой и неотъемлемой частью всего процесса разработки и содержит ключевую информацию о процессах разработки продуктов, их развитии, развертывании и внедрении. Она сохраняет для повторного использования артефакты, получаемые в ходе выполнения проекта.
Инструментом, позволяющим организовать эффективное управление версиями и конфигурациями является IBM Rational ClearCase, а управления изменениями – IBM Rational ClearQuest.