Требования к программному обеспечению слишком часто автоматически отождествляется с требованиями пользователей, такими как функции, связанные со способами эксплуатации, или уровни производительности. Однако существуют другие требования, которые часто становятся источниками серьезных проблем в производственных системах, такие как количество подключений к базе данных, выделение памяти или сосуществования с другими системами, даже не связанными с данной системой. В этой статье из двух частей мы покажем, как IBM Rational Requirements Composer обеспечивает сотрудничество между группами разработки и эксплуатации в целях моделирования и отслеживания требований, относящихся к исполнению приложения, и как после этого применять IBM Rational Quality Manager для подготовки и протоколирования испытаний.

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

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

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

В этой статье из двух частей мы покажем, как подразделения разработки и эксплуатации могут совместно использовать IBM Rational Requirements Composer для решения следующих двух задач.

1. Для моделирования и отслеживания требований, связанных с производственным использованием приложения.
2. Для подготовки и протоколирования испытаний с помощью IBM Rational Quality Manager.

Почему нефункциональные, эксплуатационные требования могут вызывать проблемы

Как уже говорилось в предыдущих статьях (см. Loasacco and Castiglioni в разделе Ресурсы), нефункциональные требования (NFR) ― это потребности различных сторон, заинтересованных в разрабатываемой ИТ-системе (см. Rozanski and Woods в разделе Ресурсы).

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

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

Однако вторым важным источником эксплуатационных требований является группа управления IT-услугами (или эксплуатации), в которую входят:

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

Кроме того, могут быть и другие заинтересованные стороны:

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

Таким образом, эксплуатационные требования, как правило, берутся из следующих источников:

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

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

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

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

• Отсутствие полноты взаимодействия. информация часто бывает только текстовой, основанной на формах и синтетических контрольных списках, которые могут лишь частично соответствовать новой системе и требовать интерпретации.
• Отсутствие обмена информацией. Сведения поступают только в одном направлении в виде официальных документов (как правило, от группы разработки в группу эксплуатации), тогда как для хорошего понимания и уточнения содержания требуется расширенное обсуждение с разных точек зрения.
• Упущение важной информации. Человек, который получает информацию, не понимает актуальности требования и не способен ее донести. Это часто означает, что требование не будет включено в план разработки и в план эксплуатационных испытаний.

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

1. Этап 1 заключается в выявлении контекстно-зависимых NFR, то есть тех нефункциональных требований, которые оказывают непосредственное влияние на разработчиков новой системы и другие, уже существующие системы, с которыми должно поддерживаться взаимодействие. В основе этого шага лежит схема контекста системы (или, точнее, схема контекста эксплуатации) и документы, которые описывают внутренние и внешние стандарты.
2. На втором этапе, требований NFR к логическому внедрению, регистрируются главным образом NFR, исходящие из технологии и архитектуры, в том числе конструктивных решений, принятых в ходе разработки приложения. Этот этап строится вокруг логической модели внедрения нового приложения.
3. Третий этап, NFR к физическому внедрению, определяет эксплуатационные требования, связанные с физической моделью производственной среды и физическими ограничениями, которые происходят из объектов инфраструктуры и промежуточного ПО, поддерживающих новую систему.
4. На четвертом этапе составление списка нефункциональных требований завершается соответствующим обсуждением со сбором отзывов и утверждающих подписей всех заинтересованных сторон.

Особенности процесса с использованием Rational Requirements Composer

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

Средства, направленные на поддержку деятельности по сбору и определению требований , появились гораздо позднее.

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

В этом случае решения, отвечающие конкретным потребностям отдельных субъектов, выглядят недостаточными: целевой аудиторией должна быть более широкая группа. Гораздо более предпочтительным является подход, основанный на хранилище данных, с мощными средствами обмена информацией и интеграции с другими инструментами управления жизненным циклом приложений (Application Lifecycle Management - ALM) и моделирования.

Rational Requirements Composer представляет собой решение на базе сервера, которое помогает группам людей сотрудничать в области определения, уточнения и пересмотра требований; оно опирается на платформу Jazz и обеспечивает богатую среду сотрудничества, дополненную интеллектуальными редакторами и другими визуальными и текстовыми средствами.

Подход коллективной работы

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

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

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

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

Артефакты и моделирование

Rational Requirements Composer содержит несколько редакторов и инструментов для подготовки требований и поддержки артефактов.

В процессе определения требований все еще широко используются текстовые документы. В Rational Requirements Composer легко создать новые или загрузить существующие документы (например, документы Microsoft Word). Функция Smart Text позволяет выделить и пометить как требование любой фрагмент текста, такой как предложение или даже отдельное слово, и может использоваться для создания новой записи в глоссарий. Точно так же фрагмент текста можно связать с комментариями или тегами, а также с другими артефактами и элементами.

Сама эта сеть отношений представляет собой истинное богатство технических и деловых знаний.

В дополнение к обработке текста, Rational Requirements Composer предоставляет несколько редакторов для создания особых артефактов:

• редактор ситуаций для создания характеристики и схем различных ситуаций;
• редактор бизнес-процессов для изображения схем на основе системы обозначений BPMN, отражающих потоки действий и событий. это гибкий метод определения требований; схемы BPMN можно экспортировать в другие инструменты моделирования на базе Business Process Modeling Notation (BPMN) для дальнейших уточнений;
• редакторы эскизов для построения моделей пользовательского интерфейса. Они позволяют довольно легко составлять представления и последовательности представлений, которые показывают, как выглядит система для конечного пользователя;
• функция раскадровки для создания раскадровок, которые состоят из кадров на шкале времени, отражающих определенный сценарий, например, конкретные действия пользователя. Как правило, раскадровки применяются для имитации того, как конечные пользователи будут ориентироваться в графическом интерфейсе. Однако это гибкий механизм, который можно приспособить для самых разных целей. В нашем случае раскадровки используются для поддержки процесса коллективной работы по определению и уточнению сценариев технических операции и соответствующих требований.

Определение требований в Rational Requirements Composer

Для выражения требований в Rational Requirements Composer используется специальный тип артефактов. Для поддержки определения требований могут использоваться артефакты нескольких типов (ситуации, раскадровки и т.п.), но окончательное требование выражено в виде экземпляра типа требования.

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

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

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

Этап 1. Контекстно-зависимые NFR в новой раскадровке

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

Рисунок 1. Схема функционального контекста

Увеличенный вариант рисунка 1.

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

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

Для визуальной связи требований с элементами схемы мы используем текстовые ярлыки (выделены зеленым цветом на рисунке 2) и связи требований и замечаний с этими ярлыками.

К этим основным ИТ-требованиям сотрудники отдела эксплуатации могут добавлять свои собственные "контекстные" NFR:

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

В нашем примере архитектурными стандартами компании являются IBM® WebSphere® Application Server в качестве платформы приложений и IBM DB2 качестве сервера базы данных.

Рисунок 2. Требования из текстового документа

Увеличенный вариант рисунка 2.

Этап 2. Нефункциональные требования по логическому внедрению

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

На данном этапе, как правило, имеются несоответствия между требованиями:

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

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

Рисунок 3. Схема логической модели

Увеличенный вариант рисунка 3.

В нашем примере группа разработчиков (по-видимому) должным образом следует стандартам промежуточного ПО компании, так что новая система представляет собой вполне правильное приложение Java 2 Enterprise Edition (J2EE) с Web-компонентом, back-end-компонентом и компонентом формирования запросов к Web-сервисам. Тем не менее, они полагались на наличие определенной технологии: JAX-WS (Java API for XML Web Services). Если поддержка JAX-WS отсутствует, компонент Web-сервисов приложения придется полностью переписать. Так что если этот технологический уровень еще недоступен в производственной среде, следует запланировать модернизацию.

Другие функциональные ограничения могут быть согласованы в обратном порядке. Например, разработчики могут согласиться на использование базы данных IBM DB2 на операционной системе IBM Z/OS, а не на распределенной платформе DB2, если отдел эксплуатации предпочитает эту платформу для данного класса данных.

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

Этап 3. Нефункциональные требования по физическому внедрению

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

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

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

Рисунок 4. Общая физическая модель

Увеличенный вариант рисунка 4.

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

Рисунок 5. Подробная физическая модель

Увеличенный вариант рисунка 5.

Наконец, требования предусматривают, что новая система должна быть разработана на IBM® WebSphere® Application Server и DB2, которые являются стандартом промежуточного ПО компании.

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

Этап 4. Окончательное рассмотрение

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

Опять же Rational Requirements Composer демонстрирует свои возможности по поддержке такого процесса: до окончательного подписания могут быть определены несколько рецензентов (см. рисунок 6), а сам процесс рассмотрения может сопровождаться комментариями и цепочками обсуждений. Как правило, в качестве рецензентов выступают сотрудники отдела эксплуатации и разработчики, но могут быть привлечены и конечные пользователи или другие подразделения, такие как архитектурный отдел. Окончательное утверждение может производиться на уровне руководителя подразделения или ИТ-директора.

Рисунок 6. Процесс утверждения

Увеличенный вариант рисунка 6.

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

Заключение

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

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

Требования, определенные в этом процессе, станут основой для сценариев тестирования.