Заметки консультанта

Шамрай Александр Владимирович

Archive for Июль 2010

Руководство по управлению требованиями VS TFS 2010

Posted by Шамрай Александр на Июль 27, 2010

Перевел очередное руководство проекта Visual Studio ALM Rangers «Visual Studio 2010 Team Foundation Server Requirements Management Guidance«, которое рассказывает о возможностях TFS 2010 для организации эффективного процесса управления требованиями. Изначально это руководство готовилось для реализации процесса на TFS 2010 Beta1, поэтому есть один момент, который будет отличаться для релизной версии TFS 2010. Этот момент заключается в использовании рабочего элемента Возможность (Feature): в TFS 2010 Beta1 это был отдельный рабочий элемент, а уже в окончательной редакции он является просто отдельным типом Возможность рабочего элемента Требование. Поэтому при реализации у себя в организации изложенных в этом руководстве практик, учтите этот момент.

Содержание руководства:

  1. Введение в Управление требованиями с использованием Team Foundation Server. Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине Инженерия требований вашего жизненного цикла разработки ПО. Ввиду изменчивости и вопреки методик, используемых в индустрии, в этом руководстве эти задачи приведены тремя способами.
    • Общие Руководство по Разработке
    • Традиционная разработка
    • Гибкая разработка
  2. Планирование управления требованиями. План управления требованиями должен быть разработан для определения и механизмов контроля информации, которая будет собираться и использоваться для сбора метрик, отчетности и контроля изменений требований к продукту.
  3. Трассировка Требований. Трассировка, вероятно, наиболее важный аспект в инженерии требований, который обеспечивает подотчетность команды разработки. Кроме этого, она помогает:
    • Идентифицировать источник и важность требований
    • Управлять масштабом проекта
    • Управлять изменениями требований
    • Оценить воздействие на проект изменения требований или других элементов проекта
    • Оценить влияние провала тестирования требований (например, не пройденный тест может означать, что требование не выполнено)
    • Убедиться, что все требования к системе будут выполнены при реализации
    • Убедиться, что приложение делает то, для чего оно предназначено
    • Дать разработчику контекст требований для задачи
  4. Анализ и Декомпозиция. Анализ и Валидация выполняются для:
    • Установки рабочей концепции и сценариев (требования продукта – например, пользовательские цели и контекстные диаграммы; требования компонента продукта – например, технические ограничения и рабочая концепция)
    • Установки и поддержки определения необходимых функциональных возможностей (функциональная архитектура, диаграммы деятельности и сценарий использования, объектно-ориентированный анализ с идентифицированными сервисами)
    • Анализа требований (дефекность/изменчивость требований, изменения требований, технические критерии качества выполнения, оценка рисков)
    • Валидации требований со всесторонними методами (Отчет о методах анализа и результатах)
  5. Выявление требований. Этот документ описывает выявление требований на каждом из своих эволюционных уровней в рамках параметров двух различных методологий: традиционной разработки приложений и гибкой методологии. Visual Studio и Team Foundation Server обеспечивают общую технологию для двух типов методологий и служат для планирования, хранения, отслеживания и отчетности в хранилище для всех стадий выявления.
  6. Спецификация требований. Независимо от уровня иерархии при выявлении требований (бизнес, системные или реализация), существуют некоторые основные свойства Team Foundation Server 2010, которые необходимо понимать для определения требований и их проверки. Этот раздел рассказывает о документировании различных элементов требований в виде рабочих элементов и использовании других методов.
  7. Валидация требований. Валидация представляет собой процесс оценки, будет ли конечный продукт удовлетворять требованиям заказчика, и помогает удостовериться, что требования были правильно поняты. Такой подход к поставке в последнее время называют «Test-First Development» или «Requirements-Based Testing».
  8. Управление изменениями и утверждение требований. Управление изменениями требований и утверждение описывает, как участник процесса формально получает утверждение для новых требований или изменений/расширений существующих требований. Фокус в этом разделе будет сделан на описании действий процесса изменения требований, управления базовыми линиями требований и разрешения на продолжение работ по реализации требования. Также будет уделяться большое внимание к соблюдению промышленных стандартов таких, как CMMI и ITIL, соответствие отраслевым нормам такие, как FDA CFR-21, Часть 11 и закону Сарбейнса-Оксли.
  9. Анализ влияния. Анализ влияния выполняется для:
    • Оценки в рамках задач, которые обеспечивают соответствие изменений всем техническим и проектным требованиям
    • Оценки влияния изменений за пределами непосредственного проекта или контракта требований (изменения в элементах, использующихся в нескольких продуктах, может решить текущую проблему, но вызывать проблему в других приложениях)
    • Определение влияния, которое изменения будут иметь для рабочих продуктов, связанных рабочих продуктов, рабочих графиков и стоимости проекта
  10. Дополнительные интеграции. Различные производители программного обеспечения и партнеры Microsoft разработали интеграции с Visual Studio, которые предоставляют возможности не очень хорошо реализованные в Visual Studio Team Suite. В частности, они имеют встроенные возможности в следующих областях: выявление, спецификации, валидации и управления изменениями. Тут список некоторых из наиболее тесно интегрированных решений.
  11. Контрольные списки для разработки требований. Контрольные списки, которые помогают улучшить качество разрабатываемых требований.

Дополнительная информация:

  • Visual Studio TFS Branching Guide 2010 – руководство по ветвлению для Team Foundation Server 2010 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.
  • TFS 2008 Branching Guide 2.0 – руководство по ветвлению для Team Foundation Server 2008 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.
Реклама

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | 2 комментария »

Тестирование памяти с помощью Windows Memory Diagnostic

Posted by Шамрай Александр на Июль 19, 2010

Если компьютер начинает себя вести неестественно (подвисать, притормаживать, выдавать синий экран), то конечно стоит задуматься, правильно ли функционирует железо. Утилита Windows Memory Diagnostic позволяет определить неисправность или исключить из списка подозреваемых оперативную память ПК. Скачать утилиту можно по этому адресу: http://oca.microsoft.com/en/windiag.asp. Процесс установки простой:

  1. Качаем и запускаем файл mtinst.exe
  2. После запуска появиться окно лицензионного соглашения, в котором нужно нажать Accept|
  3. Далее появится окно предлагающее выбрать метод установки утилиты

    • Первый пункт Create Sturtup Disk должен создать установочную дискету (лет 10 не использовал предлагаемое)
    • Второй пункт Save CD Image to Disk сохраняет образ CD по выбранному в дальнейшем пути. Сохраненный образ можно записать на CD или DVD, который нужно в дальнейшем использовать как загрузочный.

Далее необходимо перезагрузить ПК и вставить созданный на предыдущем шаге floppy, CD или DVD (предварительно выставив загрузку с этих устройств). После загрузки появится следующий экран, в котором сразу начнется процесс тестирования памяти:

По умолчанию запускается стандартный процесс тестирования, который включает в себя 6 тестов и проходит довольно быстро (около 20-ти минут). Кроме этого доступен расширенный тест, который включает в себя 11 тестов и длится уже намного дольше (до 2-х часов). Переключиться на простой или расширенный режим можно с помощью клавиши T. Запущенные тесты будут длиться (повторяться) до тех пор, пока не будет перезагружен компьютер или не будет выполнен выход с помощью клавиши E. Правда у утилиты есть ограничение (на момент публикации заметки) по объему оперативной памяти в размере 4 GB. Все, что выше этого объема, просто не тестируется.
Более подробно, включая полную инструкцию по использованию, можно посмотреть здесь: http://oca.microsoft.com/en/windiag.asp.

Posted in Полезное, Разное, Техника | Отмечено: | 2 комментария »

Руководство по управлению требованиями VS TFS 2010 – Введение в Управление требованиями с использованием Team Foundation Server

Posted by Шамрай Александр на Июль 13, 2010

<<Содержание

Добро пожаловать в Руководство по управлению требованиями Team Foundation Server! На TechReady7 (внутренние технические встречи Microsoft) в июле 2008 года, практики проголосовали за проекты Visual Studio ALM Rangers, в которых, по их мнению, они больше всего нуждаются. Разработка требований была признана одним из двух самых важных. В этом документе будут рассмотрены люди, процессы и руководство по технологиям для Разработки требований с использованием Team Foundation Server.

Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине Инженерия требований вашего жизненного цикла разработки ПО. Ввиду изменчивости и вопреки методик, используемых в индустрии, в этом руководстве эти задачи приведены тремя способами.

  • Общие Руководство по Разработке Требований – есть практики инженерии требований, которые реализуются, независимо от используемой методологии. Например, общее развитие представления бизнес уровня к функциональным возможностям, качеству обслуживания определено в любом случае, выполняет разработку организация по традиционному водопаду в соответствии со стандартами института инженеров по электротехнике и радиоэлектронике (IEEE) или выполняется экстремальное программирование с гибкими методами. Руководство приведено на концептуальном уровне, по возможности с использованием конкретных примеров на Visual Studio/Team Foundation Server.
  • Традиционная разработка – руководство будет приведено в основном в соответствии со стандартами IEEE по инженерии требований. В руководстве будут описаны конкретные указания по выявлению бизнес требований, спецификации, а также валидации спецификаций функциональных и технических требований.
  • Гибкая разработка – даже в рамках гибких методов есть несколько методологий, которые подчеркивают или выделяют различные практики в рамках этой темы. Руководство сосредоточено в основном на Scrum в качестве выбранной методологии и ссылается при необходимости на другие методологии.

Сценарий Разработки Требований

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

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

Это руководство описывает этот список более подробно в разделах по планированию управления требованиями и трассировки. Сейчас мы используем этот список как основу для описания сценария инженерии требований. Этот сценарий начинается с выявления требований уровня бизнеса вплоть до выполнения тестов по сборкам. Далее будут показаны цели каждого этапа этого процесса и как Team Foundation Server может быть использован для этих шагов.

Этот сценарий будет служить основой для описания на протяжении всего этого руководства, и мы будем на него ссылаться при описании альтернатив на основе Общей, Традиционной и Agile практик, используемых в Microsoft и в индустрии в целом. В каждом шаге сценариев, описанных ниже, указано в какой части руководство можно найти более детальную информацию о его поддержке в Visual Studio Team System и Team Foundation Server.

  1. Анализ Проблемы и Целей и определение Видения – бизнес-руководители спонсируют проект для решения некоторых бизнес-проблем и достижения бизнес-цели. Бизнес-аналитик будет выявлять их в качестве требований к продукту в виде набора возможностей или бизнес-требований. Мы можем хранить их в Team Foundation Server в виде рабочего элемента «Возможность».
    1. Первоначально выявление будет направлено на бизнес-руководителей. После того, как возможности продукта будут выявлены, специалисты по бизнес-областям будут дополнять этот набор функций. (Разделы Планирование управления требованиями и Выявление)
    2. Валидация на этом уровне будет проверять не только точность описанных функции, но и определять их влияние на решение проблем бизнеса и достижения бизнес-целей. (Раздел Валидация требований)
    3. Проблемы и цели, как правило, хранятся в виде документа бизнес-сценарий, где, в нормальной ИТ организации спонсируемой CIO, менеджер проекта собирает предварительную смету расходов на решение этой проблемы в проекте разработки и выполняет анализ экономических выгод. Этот вид деятельности находится вне области инженерии требований этого руководства. Анализа экономического обоснования и дальнейшего выявление спонсоров и экспертов в этой области приводит к бизнес-требованиям или возможностям продукта, которые будут определены в документах по проекту; обычно в документе Спецификация бизнес требований. (Разделы Планирование управления требованиями и Спецификация требований)
  2. Переход к функциям – выполняя анализ возможностей, аналитик получает функциональную контекстную модель или диаграмму вариантов использования для всех функциональных сценариев, реализующих функции. Мы можем хранить их в качестве рабочего элемента «Пользовательское описание функциональности» (MSF для Agile) или «Требование» с типом «Функциональное» (MSF для CMMI) и связать их с каждой возможностью, которую они реализуют.
    1. Планирование требований – описано в разделе Планирование управления требованиями
    2. Аналитик анализирует возможности и готовится к выявлению функциональных требований пользователей заинтересованных сторон и бизнес экспертов по конкретным областям. Их анализ поможет им выявить правильные функциональные требования, задокументировать и выполнить их валидацию на точность. (Разделы Выявление, Анализ и Валидация требований)
    3. Полученные функциональные требования и возможности связываются – описано в разделе Трассировка требований
  3. Переход к качеству обслуживания и нефункциональным требованиям – проводится дальнейший анализ возможностей и функциональных требований. Аналитик, работая с другими составляющими продукта (инфраструктура, операции, архитектура и администраторы баз данных, удобство использования, эксперты по безопасности, управление и обеспечение соблюдения требований и т.д.), определяет нефункциональные требования и качества обслуживания. Опять же, мы можем хранить их в качестве рабочих элементов в Team Foundation Server и привязать их к каждой возможности или функции, из которых они получены.
    1. Анализ функциональных требований для получения качества обслуживания и нефункциональные требований – разделы Выявление, Анализ и Спецификация требований
    2. Валидация свойств и нефункциональных требований на точность (Раздел Валидация требований)
    3. Полученные требования и функциональные требования связываются – описано в разделе Трассировка требований
  4. Планирование работ – менеджер проекта определяет с командой разработчиков задачи разработки (будь то гибкий проект или водопад или что-нибудь между ними, задачи определяются и по-прежнему с оценкой трудозатрат определенным образом) на функциональные и нефункциональные требования. Их можно хранить как рабочие элементы «Задача» и связывать с функциональными или нефункциональным требованиям, для которых они были запланированы.
    1. Планирование разработки и тестирования – описано в разделе Анализ
  5. Разработка Приложения и Тестов — команда разработчиков может разрабатывать код проекта приложения и модульные тесты (и тесты производительности) и связать их с исходным кодом. Во время регистрации (check-in) изменений, они связывают их с задачей, и мы можем даже заставить их это делать.
    1. Наборы изменений (Change Sets) связываются с задачами и требованиями – описано в разделе Трассировка требований
  6. Проверка качества приложения — Мы выполняем модульные тесты, и мы с помощью отчета, который связан со сборкой, можем продемонстрировать, какие наборы изменений вошли в эту сборку и какие рабочие элементы были связаны с этими зарегистрированными наборами изменений. И мы можем это сделать с помощью Team Foundation Server. Мы выполняем Ручные или Web функциональные тесты, а также можно использовать общие тесты, которые доступны из внешних систем функционального тестирования (например, Quick Test Professional) и опубликовать результаты. Отчеты будут демонстрировать, что рабочие элементы покрыты всеми видами тестов, с использованием Team Foundation Server Data warehouse.
    1. Выполнить тесты, публиковать результаты, сгенерировать отчеты покрытия – описано в разделе Трассировка требований
  7. Планирование тестирования – почему планирование тестирования включено в темы инжиниринга требования? Что ж, планирование тестирования гарантирует, что валидация имеет место. Влидация предусматривает проверку, которая позволяет убедиться, что команда проекта понимает цели требований и может достичь согласования с источником требования (бизнес-спонсором или заинтересованным лицом). Проверка предусматривает тесты, которые команда предоставила и согласовала для поставки. Планирование тестирования обеспечивает хранилище и трассируемость всех работ, связанных с управлением тестирования. Таким образом, после шага (1), но до шага (2), мы теперь имеем надежный механизм для планирования приемо-сдаточных тестов для функциональных требований. На самом деле, планирование тестирования на каждом уровне может быть выполнено с помощью Visual Studio 2010 Test and Lab Manager edition. Таким образом, мы можем создать несколько тестовых планов и тестовых наборов в Test and Lab Manager, которые обеспечивают разработку устойчивого отчета плана тестирования, который показывает, какие тесты не были запланированы, какие были запланированы, но не реализованы, какие были реализованы, но не выполняются, какие были выполнены, но провалены и какие были выполнены и прошли. Все эти данные есть, а у нас теперь есть возможность получить такой отчет и сортировать результаты по рабочим элементам, к которым они принадлежат.
    1. Планирование тестирования для системных требований — описано в разделах Трассировка требований, Валидация требований и Спецификация требований

Каждый из приведенных шагов поддерживается «коробочной версией» Team Foundation Server. Некоторые, однако, еще не были покрыты возможностями Team Foundation Server. Для них руководство предлагает альтернативу или ручные методы, которые обеспечивают решение, с помощью которого наши пользователи могут достичь этих целей с Team Foundation Server в любом случае.

Примечание: руководство для анализа требований этого раздела предполагает, что требование на уровне бизнеса реализованы с использованием рабочего элемента «Возможность» в Team Foundation Server. Авторы не настаивают на использовании рабочего элемента «Возможность» для этой цели и признают, что это добавляет элемент формальности, который можно легко избежать для небольших и гибких команд.

Отступление

В 20-тилетней карьере лидера в области разработки, практик, внедрения передового опыта, обучения, коучинга по управлению жизненным циклом разработки для своих клиентов, мы установили, что Инженерия требования, как правило, наиболее сложная дисциплина в рамках программного обеспечения и сообществ разработки систем. Таким образом, это руководство было разработано с подходом, который напрашивается на критику и изменение. Команда из более 20 практиков из Microsoft Consulting Services, Product Management и программы MVP собрались вместе для обсуждения и определения предложения руководства, которое учитывает передовые практики индустрии и лучшие практики Microsoft в дисциплине разработки требований.

Visual Studio ALM Rangers

Эта руководство было разработано в проекте Visual Studio ALM Ranger. Visual Studio ALM Rangers особая группа в составе представителей Visual Studio Product group и Microsoft Services. Их миссия заключается в предоставлении решений для отсутствующих возможностей или руководств.

Целевая аудитория этого руководства это Microsoft пользователи Team Foundation Server «уровня 200-300». Целевая группа рассматривается как промежуточная к опытным пользователям Team Foundation Server, глубоко понимающим возможности продукта в реальном мире. Части этого руководства могут быть полезными для новичков и экспертов Team Foundation Server, но пользователи этих уровней не фокусируются во внимание этого руководства.

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

Мы надеемся, что данное руководство охватывает более 80% нужд сегмента инженерии требований. В дополнение к этому руководство вы найдете отдельные методологические сценарии, Q&A, учебные пособия и обновление трассировки и документацию по стратегии. Мы призываем участников нашего сообщества предоставлять идеи для новых сценариев, которые мы будем добавлять в пакеты. Эти новые пакеты будут доступны на CodePlex или MSDN и будут обновлены на основе отзывов пользователей.

Словарь

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

Термин Определение
Анализ требований

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

Активный дизайн (Participatory Design)

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

Аппаратное требование

Требование, которым должно соответствовать аппаратное обеспечение.

Артефакт (рабочий продукт)

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

Атрибуты

Качественные характеристики продукта (например, надежность, удобство использования и т.д.)

Базовая линия

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

Базовая линия требований

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

Бизнес-правила

Правила и ограничения, регулирующие отдельные бизнес-процессы и работы.

Валидация требований

Валидация фокусирует внимание на определении, работает ли продукт как ожидалось. Валидация требований предусматривает проверку связи между тестами (и результаты тестов) и тестируемой системой. Удовлетворяет ли построенная система требованиям?

Вариант использования

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

Взаимодействие

Атрибут: возможность взаимодействия одной программной системы с другой.

Гибкость

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

Группа контроля за изменениями

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

Группа пользователей

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

Двунаправленная трассировка

Ассоциации между двумя или более логических объектов, которая видна в любом направлении (т. е. в и от сущности). (См. также Трассировка требований).

Дефектное требование

Требование, которое является неправильным, неоднозначным, непроверяемым, нетрассируемым, неполным и/или противоречивым.

Диаграммы взаимодействия

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

Доступность

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

Жизненный цикл разработки программного обеспечения

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

Заинтересованное лицо

Лицо, которое будет затронуто продуктом и имеет прямое или косвенное влияние на требования к продукту.

Интервью

Сессия один на один с пользователем на его рабочем месте.

Контекстно-независимые вопросы

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

Коробочное решение

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

Корректность

Атрибут: соответствие стандартам и техническим условиям.

Круг пользователей

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

Мета-вопрос

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

Моделирование требований

Работы, направленные на превращение набора требований в графическое и/или текстовое представление модели системы, как она будет работать, если требования были выполнены.

Надежность

Атрибут: работа без сбоев в течение определенного периода времени.

Нетехнические ограничения

Требования, связанные с продуктом, поставкой и выпуском (например, стоимость и сроки).

Однозначное требование

Требование однозначно только тогда, когда может быть только одна интерпретация.

Повторное использование

Атрибут: возможность переработки для использования в другом приложении.

Покупатель

Тот, кто приобретает продукт для пользователей.

Пользователь

Тот, кто будет использовать продукт.

Пользовательские требования

Высокоуровневые системные требования пользователя. Пользовательские требования не должны определять реализацию.

Портативность

Атрибут: возможность перемещения для использования в другой среде.

Представитель пользователей

Один человек, который представляет пользователей для разработчиков продукта.

Приемочные тесты

Тесты, которые выполняет заказчик в процессе окончательной валидации, чтобы удостовериться, что «продукт работает так, как заказчик заказывал». Приемо-сдаточные испытания, как правило, основываются на определенных сценариях использования, которые выполняются в пользовательской среде.

Приоритетность требований

Метод ранжирования важности требований на более и менее важные.

Проверяемое требование

Это требование, которое может быть проверено с помощью анализа, демонстрации, инспекции или тестирования.

Прототип

Частичная реализация программной системы, построенная для того, чтобы помочь разработчикам, пользователям и клиентам лучше понять требования к системе.

Разработка программного продукта

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

Разработка требований

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

Раскадровка

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

Сбор требований

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

Сессия совместного дизайна приложения (Joint Application Design (JAD))

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

Сценарий

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

Системные требования

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

Спецификация требований

Документация, определяющая, как продукт будет построен, и описывающая ее внешнее поведение.

Спонсор

Лицо, которое выполняет финансирование этого проекта.

Тестируемость

Атрибут: возможность проверить (протестировать) указанную операцию и производительность.

Тестируемое требование

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

Техника Фокус-группы

Техникой сбора требований, которая следует сценарию, и организована из набора вопросов для интервью с группой людей. Группа состоит из 3 — 10 пользователей, экспертов или клиентов, нескольких разработчиков или маркетологов.

Технические ограничения

Характеристики среды продукта, которые влияют на выполнение и/или дизайн продукта.

Техническая рецензия

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

Техническое требование

Свойства продукта для условий, в которых разрабатывается продукт.

Трассировка требования

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

Трассируемое требование

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

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

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

Требование к системным интерфейсам

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

Удобство использования

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

Управление изменениями

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

Управление требованиями

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

Функциональное требование

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

Целостность

Атрибут: (использование) безотказная работа при несанкционированном доступе; (данные) сохранение содержания и порядка данных и артефактов.

Эффективность

Атрибутов: относительное использование ресурсов (памяти, времени, пропускной способности сети).

Эксплуатационная надежность

Атрибут: простота обнаружения и исправления неисправности в период времени (во время использования).

Unified Modeling Language (UML)

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

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

Проблема создания базы данных ClearQuest на сервере MS SQL

Posted by Шамрай Александр на Июль 6, 2010

<< Перейти в раздел «ClearQuest FAQ»

При создании мастер или пользовательской базы данных с использованием сервера MS SQL возможны следующие ошибки:

SQLExecDirect: RETCODE=-1, State=37000, Native Error=-3504
SQL statement=’select from master_global’
[Microsoft][ODBC Microsoft Access Driver]The SELECT statement includes a reserved word or an argument name that is misspelled or missing, or the punctuation is incorrect.

или

SQLExecDirect: RETCODE=-1, State=37000, Native Error=156
SQL statement=»select from master_global»
[Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword ‘from’.

Причины этой проблемы могут следующие:

  1. Схема по умолчанию для сопоставляемой базы данных не совпадет с именем пользователя, от которого выполняется работа с базами данных ClearQuest на сервере MS SQL.
  2. Пользователь sa используется для подключения к базе данных.

Решение:

  1. Для проблемы 1: Из MS SQL Management Studio перейти к свойствам пользователя используемого для подключения к базам данных MS SQL. В свойствах пользователя перейти к пункту Сопоставление пользователей и ввести в значение схемы по умолчанию наименование пользователя, под которым будет выполняться подключение.
  2. Для проблемы 2: Использовать для подключения к базам данных MS SQL отдельного пользователя (не sa). Разрешения, необходимые для этого пользователя смотрите в инструкции по установке.

Источник: ERROR: ‘Incorrect syntax’ or ‘The SELECT statement includes a reserved word or an argument name’, when administering databases hosted on SQL Server 2005

Posted in ClearQuest FAQ, IBM Rational | Отмечено: , , , , , , | Leave a Comment »

Руководство по управлению требованиями VS TFS 2010 – Выявление требований

Posted by Шамрай Александр на Июль 2, 2010

<<Содержание

В 1992 году было опубликовано следующее высказывание, на 17 лет раньше, чем Visual Studio ALM Ranger начали разрабатывать руководство по инжинирингу требований:

1«Многие из проблем в создании и поддержке системы можно связать с проблемами выявления. Тем не менее, большая часть исследований, проводимых по инженерии требований, игнорируют выявление, руководитель Лейте (автор) заявил, ссылаясь на обследование анализа требований в 1987, что состояние дел в области анализа требований не сильно отличается от того, что было в конце 1970-х. Он утверждает, что исследования в этой области сконцентрированы на точность, представление, методы моделирования, верификации и утверждения, а не на улучшение выявления потребностей. Он приходит к выводу, что ‘усилия исследований должны быть направлены на методы и инструменты, необходимые для улучшения процесса анализа требований, и, в частности, на те, которые оказывают большую поддержку выявлению требований'».

Тем не менее, и в 2009-ом году практики по-прежнему пренебрегают выявлением требований. В этом разделе описываются планирование, методы выявления, а также поддержка для хранения результатов, обеспечивающиеся в Visual Studio и Team Foundation Server для выявления требований по проектам разработки приложений.

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

Этот документ описывает выявление требований на каждом из своих эволюционных уровней в рамках параметров двух различных методологий: традиционной разработки приложений и гибкой методологии. Visual Studio и Team Foundation Server обеспечивают общую технологию для двух типов методологий и служат для планирования, хранения, отслеживания и отчетности в хранилище для всех стадий выявления.

Примечание: руководство по выявлению требований этого раздела предполагает, что требование на уровне бизнеса реализовывается с использованием рабочего элемента «Возможность» (Feature) в Team Foundation Server. Авторы не настаивают на использовании рабочего элемента Возможность в этих целях и признают, что это добавляет элемент формальности, который можно легко избежать для небольших и более гибких команд.

Общие темы выявления

Планирование выявления

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

Планирование выявления обеспечивается 3-мя основными уровнями: ранний сбор информации, представление требований и анализ, валидация.

Сбор информации включает в себя определение всех соответствующих сторон и сбора инициирующих требований («списков пожеланий») от них. Через приоритеты, основанные на политических, экономических, окружающей среды и т.д. факторах, эти требования передаются на следующую итерацию выявления требований.

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

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

Планирование выявления включает в себя последовательные мероприятия в начале проекта, а затем, через уточнение, будет включать мероприятия для дальнейшего анализа и проверки:

  • Выявление всех соответствующих сторон, которые являются источниками требований.
    Эта и следующая работа направлены на определение «Персонажей» приложения. Один из ключевых элементов Microsoft Solution Framework (MSF). Участник может быть конечным пользователем, интерфейсом системы или фактором среды. Несмотря на то, какие роли определены в любой нетипичной организации, ниже приведен типовой список возможных ролей:
    • Бизнес – человек или люди, обеспечивающие финансирование проекта
    • Пользователь – человек или люди, которые в конечном итоге будут использовать систему
    • Администратор – тоже, что и  пользователь, но особенность в том, что он обеспечивает безопасность, потоки данных, а также новых пользователей, продукты, цены и другую информацию в приложениях.
    • Инфраструктура – IT организация, которая обеспечивает оборудование и информационную поддержку на площадке, где приложение будет установлено. С точки зрения независимых поставщиков или сайта хостинговой компании, например SalesForce.Com, это люди, которые должны определить производительность оборудования и требования к пропускной способности для поддержки конечных пользователей, которые будут использовать приложения, размещенные на сайтах SalesForce.Com.
    • Операционная поддержка — люди или группа, которые будут оказывать операционную поддержку конечных пользователей. Они поддерживают аппаратное и программное обеспечение в рабочем состоянии в течение всего периода использования. Они также представляют службу поддержки пользователей, которые периодически сталкиваются с дефектами или отключениями.
  • Определение профиля соответствующих сторон, для которых требования будут собираться.
    Это включает в себя определение трудозатрат, необходимых для работы с ними, чтобы получить требования и риски для этих требований точно и однозначно. Например, типичный конечный пользователь в страховой организации будет описывать свои потребности в рамках непосредственно своего рабочего места. Снимки экрана для них предоставляются на бумаге и, когда они готовы (в редких случаях пользователь беспокоится, как это происходит), только тогда они могут подтвердить, что это было сделано правильно. Если сравнить с Директором информационной службы, который дает бюджет для проекта разработки приложения, предназначенного для повышения эффективности процессов страховых выплат, то их потребности описываются низкой стоимостью реализации, повышения производительности труда в денежном выражении и экономии времени, а также в утверждениях, которые приводят к увеличению прибыли.
  • Определение методов выявления (следующий раздел).
    Соответствующая техника выявления для каждого профиля будет зависеть от рабочего графика, ограничения времени, ограничения глубины знаний, возможной точности и других факторов. Использование этих факторов позволит выделить задачи с оценкой трудозатрат по выявлению требований для каждого источника.

Чтобы планировать эти три этапа, можно использовать электронную таблицу или план работ MS Project и синхронизировать с рабочим элементом TFS Задача. Следующие шаги демонстрируют, как сделать это с помощью MS Project:

  • Откройте MS Project и установите правильные атрибуты соответствия, выбрав TFS Team Project из пункта меню «Team»:

  • Далее выберите сервер TFS и коллекцию проектов по умолчанию, для которых будут планироваться задачи по выявлению:

  • Далее введите задачи выявления с оценками, основанными на анализе каждого человека, который представляет собой персонаж для вашего приложения:

  • Чтобы опубликовать, обязательно нужно включить и указать в колонке выбора Тип рабочего элемента. После завершения опубликуйте задачи в TFS. Убедитесь, что атрибуты отображаются также, как на снимке экрана ниже:

  • Вот как это выглядит в TFS после публикации:

Методы выявления

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

Семинары по выявлению

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

Семинары по требованиям не нуждаются в поддержке Visual Studio/TFS, но их результаты могут покрываться этой технологией.

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

Другие примеры внешних источников для требований:

  • Постановка работы
  • Запрос на предложение
  • Миссия
  • Постановка задачи
  • Бизнес-правила
  • Законы и нормативные акты
  • Юридические системы
  • Бизнес-модели

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

Семинар по требованиям является одним из наиболее эффективных экономически и по времени средств в смысле получения обратной связи. Такая же концепция применяется в сессиях JAD (Joint Application Development) или RAD (Rapid Application Development) . Вот некоторые из преимуществ семинара:

  • Ускорение процесса выявления
  • Сбор всех заинтересованных сторон на интенсивную, сосредоточенную встречу
  • Содействие обеспечению направленности и прогресса
  • Все мнения будут выслушаны
  • Результаты доступны немедленно
  • Обеспечение основы для применения других методов выявления
Механизм семинара

Как правило, для крупных проектов семинар может длиться от 3-х до 5-ти рабочих дней. Ниже показан высокий уровень выполнения семинара по требованиям.

  • Предварительное планирование семинара – перед семинаром бизнес-аналитик должен будет подготовить все материалы, выявить все заинтересованные стороны, послать приглашение участникам, подготовить темы для повестки дня,  правила и направление действий для семинара. Вот перечень мероприятий, которые должны быть выполнены:
    • Предложение семинара – некоторые заинтересованные стороны не хотят идти на семинар по различным причинам. Нужно подготовить пункты с выгодами для каждой из заинтересованных сторон, которые учитывают их потребности.
    • Создание команды – выявление всех заинтересованных сторон и посредников. Подготовка окон в их расписании для семинара.
    • Определение логистики – зарезервировать конференц-залы и комнаты для перерывов. Планирование заказов блюд, напитков и легких закусок. Убедитесь, что доступны Интернет, проекторы, доски, стикеры, маркеры и т.д.
    • Отправка материалов предварительного чтения и предпосылочных материалов – заинтересованные стороны должны иметь всю имеющуюся информацию, а также время для её рассмотрения. Отправьте их с четкой инструкцией о том, как подготовиться к семинару.
    • Подготовка повестки дня – используйте расписание (обычно с шагом в полдня, разделенным на 2-а перерыва по 15 минут в течение каждой сессии), сформируйте повестку дня для каждого из семинаров. Например, в результате оценки ALM, мы создали семинар, состоящий из:
      • Введение -> Понедельник: 8:00-12:00 – Введение для всех заинтересованных сторон, их ролей, а также открытое обсуждение желаемых целей семинара.
      • Сессия 1 – Дисциплина инженерии требований -> Понедельник: 1:00-5:00 – 30 минут введение в проблемы инженерии требований, выявленных в ходе оценки, 1 час дискуссии с использованием причинно-следственных диаграмм, 15-30 минут присвоение приоритетов проблемам, 1 час мозговой штурм по решению, 15-30 минут выставление приоритетов и сведение результатов.
      • Сессия 2 – Дисциплина управления изменениями и конфигурациями -> Вторник: 8:00-12:00 – тот же формат, что и для сессии 1
      • Сессия 3 – Управление и мониторинг Agile-проекта и Дисциплина контроля -> Вторник: 1:00-5:00 – Формат скорее как обсуждение «Моделирование вариантов использования». Описать все сценарии команды Agile, определить роли, определить действия, определить рабочие продукты; больше описание процесса, которому будут следовать, и мозговой штурм на проблемных областях
      • Сессия 4 – Дисциплина повторного использования Программного обеспечения / Архитектура -> Среда: 8:00-12:00, так же как сессия 1
      • Закрытие -> Среда: 1:00-3:00 – Подведение итогов каждой сессии, определение предстоящей работы и описание последующих действий.
  • Сессии семинаров – выполнение семинара, согласно некоторым из основ:
    • Содействие – вы или кто-то вами определенный поддерживает темп сессий. Этот человек не будет вводить свое мнение, но будет привносить предложения, если сессия становится нудной, чтобы вернуть ее в нужное русло.
    • Поддержание темпа – также, как предыдущий пункт.
    • Запись выводов – организатору может быть сложно документировать результаты каждой сессии. Рассмотрите вопрос о найме специального человека (писателя) для этой цели. Очень важно, чтоб все понимали, что информация должна быть учтена и документирована. Это не простая задача.
    • Краткие выводы – в конце каждой сессии, работа с заинтересованными сторонами с целью обобщения каких-либо выводов или решений, которые были сделаны. Убедитесь, что все участники сессии поняли все варианты, которые были представлены, и все необходимые действия были предприняты в отношении результатов.
  • Выпуск результатов – найдите время для подведения итогов, их анализа и организации.
    • Обобщить выводы – организуйте результаты в формате, который можно проанализировать.
    • Объединить информацию – после проведения анализа, консолидируйте информацию таким образом, чтоб она могла быть представлена заинтересованным сторонам для последующих действий.
  • Передача
    • Представить результаты для заказчика
    • Определить следующие шаги и действия для реализации окончательного набора требований.

Мозговой штурм

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

«Мозговой штурм означает проведение с группой короткого промежутка времени, скажем, 15 минут, когда всем в комнате разрешено говорить все, что они считают важным для проекта. После этого организатор переключает группу на организацию и выставление приоритетов для результатов» 3.

Техника мозгового штурма

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

Для генерации идей есть несколько полезных для использования методов:

  • Стикеры и маркеры — каждый участник получает маркер и комплект стикеров. Они могут свободно записать такое количество идей, насколько это возможно для них, и прикрепить их к стенке. Роль организатора состоит в том, чтобы прочитать каждую заметку и объединить их как можно лучше по тематическим областям. После истечения срока, скажем, 15 минут, остановите сбор идей и затем попросите остальных участников помочь в распределении стикеров на стене. Это самый быстрый способ получить собранную и организованную информацию.
  • Белая доска или мольберт — либо каждый участник поднимает руку, и организатор записывает их идеи на мольберт или доску, либо каждый участник получает маркер, и они  по очереди пишут на доске до окончания срока. Этим методом сложно организовать информацию после выполнения сбора.

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

Другие методы уменьшения количества найденных идей:

  • Дайте каждому возможность проголосовать.
  • Пусть каждый определит приоритеты каждой идеи по категориям (например, критическая, важно и неплохо, если будет), которые имеют свой вес (например, 3, 2, 1). Суммы из приоритетов для каждой идеи скажут вам её важность по отношению к другим.
  • Дайте каждому участнику 100$ для голосования (нереальных денег), и пусть они покупают свои идеи за необходимую, по их мнению, стоимость. Это позволит не только выявить наиболее популярные идеи, но и определит приоритеты для всех идеи, которые были сгенерированы.

Документация по результатам

Независимо от метода, используемого для генерации идей, его результаты должны быть документально зафиксированы и сохранены. TFS можно использовать в качестве предварительного хранилища для этих идей в рабочих элементах типов «Возможность», «Пользовательское описание функциональности» или «Требование», в зависимости от используемых шаблонов процесса; MSF для Agile или MSF для CMMI.

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

Интервью

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

Во-первых, вы должны подготовить список «контекстно-свободных» вопросов, которые помогут вам вникнуть в область с интервьюируемым. Контекстно-свободные вопросы это вопросы, которые являются подходящими для любой области и, когда проводятся в открытом формате общения, собеседник может рассказывать на эту тему долго, объективно описывая их проблемы и возможные решения.

Контекстно-свободные вопросы:

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

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

Общий процесс для проведения интервью:

  1. Предварительное обследование среды заинтересованных сторон или пользователей и компании.
  2. Рассмотрение вопросов до интервью и подготовка ожидаемых ответов на некоторые вопросы для того, чтобы вникнуть в проблему за проблемой.
  3. Следите за форматом во время интервью для того, чтобы задавались правильные вопросы.
  4. Подведите итоги по двум или трем проблемам в конце интервью.
  5. Повторите, что вы узнали, чтобы подтвердить ваше понимание.

Во время интервью используйте «активное слушание». Практика активного слушания – когда один «Пытается понять, а не быть понятым». Для этого случая некоторые рекомендации:

  1. Задайте вопрос
  2. Прослушайте ответ
  3. Повторите ответ, чтобы удостовериться, что вы услышали правильно
  4. Повторите ответ своими словами, чтобы показать, что вы поняли, что вы слышали.

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

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

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

Примеры контекстно-свободных вопросов используемых для поиска пользователей и интерфейсов системы:

  • Кто является заказчиком?
  • Кто является пользователем?
  • Они имеют различные потребности?
  • Каковы их особенности, возможности, условия работы?

Примеры контекстно-свободные вопросы, которые помогут вам понять бизнес-процессы:

  • В чем заключается проблема?
  • Что является основанием для желающих решения этой проблемы?
  • Существуют ли другие причины для стремления решить эту проблему?
  • Какая польза успешного решения?
  • Как можно решить проблему?
  • Какой компромисс между временем и пользой?
  • Как еще можно обеспечить решение этой проблемы?

Примеры контекстно-свободных вопросов, которые помогут вам понять требования к системе или разрабатываемому продукту:

  • Какую проблему решает этот продукт?
  • Какие бизнес-задачи может создать этот продукт?
  • Какие опасности могут существовать для пользователей?
  • В какой среде продукт будет работать?
  • Каковы ваши ожидания по удобству использования?
  • Каковы ваши ожидания по надежности?
  • Какая производительность/точность требуется?

Примеры контекстно-свободных мета-вопросов:

  • Я задаю слишком много вопросов?
  • Мои вопросы представляются актуальными?
  • Вы тот человек, который может ответить на эти вопросы?
  • Ваши ответы требования?
  • Могу ли я задать дополнительные вопросы позже?
  • Вы бы хотели принять участие в обзоре требования?
  • Есть ли что-нибудь еще, о чем я должен спросить вас?

Пример не контекстно-свободных вопросов, которых следует избегать:

  • Наводящие вопросы: «Вы хотите большой экран, не так ли?»
  • Вопросы с ответом: «Если будет 50 пунктов, так будет нормально?
  • Контрольные высказывания: «Можем ли мы вернуться к моим вопросам?»
  • Слишком длинные и слишком сложные: «Этот вопрос из трех частей …»

При разработке комплекса вопросов вам также необходимо учитывать следующее:

  • Не просить людей описать вещи, которые они обычно не описывают.
  • Не задавайте вопросы предполагающие, что пользователи могут описать различные комплексные задачи. Пример: методы завязывания ваших шнурков.
  • В целом, люди могут делать многие вещи, которые они не могут описать.
  • Эмпирические данные – плохое соотношение.
  • Спрашивайте открытые вопросы.
  • Избегайте вопросов, которые начинаются с «почему?», поскольку такие вопросы могут вызвать оборонительную реакцию.

При проведении сессии интервью помните:

  • Не ждите простых ответов.
  • Не торопите собеседника.
  • Слушайте, слушайте, слушайте!

Документация по результатам собеседования

Общий Шаблон Интервью, показанный в конце этого документа в приложении, является хорошей начальной точкой для подготовки интервью. Полученные результаты могут быть описаны в шаблоне и храниться в документе Резюме Интервью на папке Требования TFS Team Project:

Диаграммы причинно-следственных связей (Fishbone Diagrams)

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

Схема диаграммы причинно-следственных связей может быть описана так же, как кости рыб, после того, как мясо было съедено. «Голова» и «позвоночник» рыбы представляют собой описание исходной задачи. Каждая «кость» от основы является причиной или главной причиной этой проблемы. Первоначальный набор «хребта» затем анализируется на важность и актуальность этой проблемы. Главные 20% из причин потом анализируются по своим собственным диаграммам «рыбным скелетам» пока проблемы не будет достаточно проанализированы.

Это хорошая техника, потому что она вовлекает заинтересованных сторон в определение их собственных причин их проблем.

Разработка раскадровки, каркасов и прототипов

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

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

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

Как документировать раскадровку

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

Вот несколько примеров:

  • Бумага эскизы или рисунки
  • Растровые инструменты рисования
  • Индекс карты
  • PowerPoint слайды
  • Скриншоты (если пользовательский интерфейс или прототип пользовательского интерфейса существует)

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

Несколько слов о каркасах и прототипах

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

Примеры возможных форматов:

  • Проект Expression Blend SketchFlow
  • Горизонтальные прототипы, написанные с использованием решений Web,WPF и Windows Forms
  • PowerPoint слайды с дополнительной анимацией или логикой навигации

Независимо от формата важно, чтобы раскадровки нашли свой путь в центральный репозиторий.

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

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

Переход от раскадровки к рабочим элементам

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

Рисунок 1. Соответствие частей раскадровки рабочим элементам

Более комплексный способ объединения прототипов и рабочих элементов является документирование сценариев использования в Visual Studio Architect Edition и создание прототипов с использованием Expression Blend SketchFlow. Диаграммы вариантов использования содержат визуальное описание того, как пользователи взаимодействуют с программным обеспечением, а также могут включать ссылки на другие артефакты внутри вашего решения Visual Studio. Эти так называемые элементы Артефакты могут использоваться для подключения информации к диаграмме, например, для справки. Это то, где SketchFlow начинает действовать.

SketchFlow, который входит в состав Expression Blend 3, представляет собой инструмент для создания экранных прототипов для приложений WPF и Silverlight. Решения, созданные с SketchFlow, могут быть открыты и отредактированы в Visual Studio и наоборот. На рисунке 2 показано решение Visual Studio, которое содержит проект модели с диаграммой варианта использования и проект SketchFlow под названием «UsecasesTestScreens». Последний был создан раньше в Expression Blend SketchFlow.

Рисунок 2. Проекты SketchFlow могут быть импортированы в Visual Studio

После открытия проекта SketchFlow в Visual Studio и создания диаграмм вариантов использования в решении, можно просто перетащить экраны, выполненные в SketchFlow, в диаграммы вариантов использования. Файлы, перемещенные в диаграмму, будут автоматически преобразованы в элемент артефакт и использоваться, как и любой другой элемент внутри диаграммы варианта использования (см. Рисунок 3).

Рисунок 3. Перемещение экрана пользовательского интерфейса на диаграмме варианта использования преобразует ее в артефакт

При двойном нажатии на артефакт-снимок откроется связанный Xaml-файл с выбранным вами средством просмотра XML, например, Internet Explorer. Таким образом, можно непосредственно связать диаграммы варианта использования с UI, предоставляя разработчикам возможность лучше понять проект и одновременного включения идей дизайнеров пользовательского интерфейса.

Наблюдение

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

Результатом наблюдения может быть диаграмма бизнес-активностей или последовательность шагов, представляющих рабочие процедуры (сценарии использования). Эта документация должна храниться в библиотеке требований документации TFS для использования в ходе анализа для выявления наиболее значимых функциональных требований. Смотрите раздел «Анализ и Декомпозиция» для более конкретных рекомендаций.

Рецензирование существующих требований

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

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

Механизмы формального рецензирования требований:

  1. Распространение документации, которая должна быть рассмотрена, каждому из заинтересованных лиц для проверки.
  2. Попросите каждого участника рассмотреть документ с их точки зрения и документировать или выделить любые вопросы, дополнительные или упущенные требования или ограничения относительно возможности осуществления этого требования. Их точка зрения определяется той ролью, которую они выполняют, то есть инженер испытаний должен иметь возможность определить тесты для требований в документации. Архитектор инфраструктуры должен сопоставить новые функциональные возможности своей производительности для гарантированной поддержки больших приложений на оборудование предприятия или DBA необходимо определить, есть ли какая-либо информация, которая приведет к требованиям увеличения хранилищ для корпоративных баз данных.
  3. Используйте контрольные списки для проверки каждого документа на покрытие каждой точки зрения. Смотрите раздел руководства «Валидация требований«.
  4. После предоставления заинтересованным сторонам времени для самостоятельного рецензирования, соберите их вместе для обсуждения своих выводов. Это даст им возможность проверить свои выводы со всеми участниками, а также возможность выявить недостающие требования.
  5. Результаты анализа должны быть отмечены в качестве рабочих элементов либо требования, либо запроса на изменение или задачи для дальнейшего анализа или утверждения.

Тема выявления в Agile

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

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

  1. Создание журнала продукта – для гибких команд (Scrum), журнал продукта представляет собой все требования, которые должны быть разработаны командой разработчиков. Владелец продукта несет ответственность за создание этого списка. Он может использовать многие из описанных выше методов для руководства в формировании списка. Однако основное различие заключается в том, что он обычно не обеспечивает формальности для этого. Планирование рассчитывается на очень короткий период времени, и вся группа заинтересованных лиц рассматривается в качестве однородной группы источников для различных требований, которые поставляются в журнал продукта. Качество журнала не столь высокое, как в традиционных проектах. Это не является ни риском, ни недостатком, потому что гибкая команда вновь будет пересматривать его с владельцем продукта и другими заинтересованными сторонами, чтобы углубиться в детали, когда придет время.
    Журнал продукта должен храниться в TFS как рабочие элементы «Требование», «Сценарий» или «Качество обслуживания».
  2. Анализ Журнала итераций – как только «кусок» журнала продукта утвержден в качестве цели для итерации, члены команды разработчиков будут использовать в основном техники интервью и неофициальных раскадровок для конкретизации деталей пользовательского описания функциональности, опираясь на владельца продукта или его делегата для предоставления детализации. Документация используется по минимуму. Этого достаточно, чтобы позволить членам команды разработать и сопоставить поведение требований к архитектуре предприятия/приложения, написать свои тесты и код и выполнить приемо-сдаточные испытания для них.
    Для хранения элемент журнала, как правило, представляется в виде рабочего элемента «Требование» в шаблоне процесса MSF для CMMI , или «Сценарий» шаблона процесса MSF для Agile.

Руководство по выявлению для традиционной разработки

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

В TFS, шаблон процесса MSF для CMMI обеспечивает поддержку для управления требованиями и разработку требований, которые компания может использовать для организации их в соответствии модели качества CMMI уровня 3. В рамках этого руководства шаблона процесса Microsoft определил «персонажи», которые могут быть использованы для определения пользователей, которые помогут выявить функциональные требования.

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

Дополнительные комментарии по традиционному выявлению

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

Для того чтобы обеспечить такую поддержку, используются следующие правила:

  1. Если вы собираетесь получить требования от заинтересованных сторон:
    1. Планируйте работы и используйте рабочие элементы «Задача» для оценки и отслеживания работ выявления.
    2. Разработайте и применяйте контрольные списки к конкретным областям и работам по выявлению, которые должны быть выполнены. Храните шаблон контрольного списка в TFS в шаблонах требований библиотеки документации.
    3. Измените название шаблона, заполните его, добавьте свою контактную информацию и дату, когда он использовался, а затем сохраните результат в библиотеке документации артефактов Требований в TFS.
    4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.
  2. Если вы выявляете требования из ранее сформированной документации:
    1. Планируйте работы и используйте рабочие элементы «Задача» для оценки и отслеживания работ выявления.
    2. Разработайте и применяйте контрольные списки к конкретным областям и работам по выявлению, которые должны быть выполнены. Храните шаблон контрольного списка в TFS в шаблонах требований библиотеки документации.
    3. Измените название шаблона, заполните его, добавьте свою контактную информацию и дату, когда он использовался, а затем сохраните результат в библиотеке документации артефактов Требований в TFS.
    4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.
  3. Если по итогам интервью, «мозгового штурма» или другой сессии в рамках семинара по требованиям:
    1. Планируйте работы и используйте рабочие элементы «Задача» для оценки и отслеживания работ выявления.
    2. Разработайте и применяйте контрольные списки и шаблоны для документирования результатов работы. Храните их в шаблонах документации библиотеки TFS Team Project.
    3. Заполните шаблон, измените его название, добавьте имена и роли всех участников, а также добавьте даты события в документ перед его сохранением в библиотеке документации артефактов требований в TFS Team Project.
    4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.
  4. Если вы создаете больше, чем просто рабочий элемент для представления набора требований:
    1. Разработайте и используйте шаблон, который доступен для всей организации (хранится в шаблонах библиотеки документации TFS Team Project)
    2. Храните итоговые документы, таблицы, графики и т.д. в библиотеке документации требований TFS Team Project
    3. Связывайте результирующий файл с соответствующими рабочими элементами через URL ссылки в TFS.

1 — ChrKang92, p. 4 — Christel, M. G., & Kang, K. C. (1992). Issues in Requirements Elicitation. Pittsburgh, PA: Software Engineering Institute.
2 — SEI 91, p.26 — Software Engineering Institute. (1991). Requirements Engineering and Analysis Workshop Proceedings, Technical Report. Software Engineering Institute Requirements Engineering Project. Pittsburgh, PA: Software Engineering Institute.
3 — Rat99 — Rational Software Corporation. (1999). Guideline: Brainstorming and Idea Reduction. The Rational Unified Process . Rational Software Corporation.

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | 2 комментария »

 
%d такие блоггеры, как: