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

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

• Дымовое тестирование (Smoke Testing)
• Регрессионное тестирование (Regression Testing)
• Тестирование сборки (Build Verification Test)
• Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

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

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

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

В случае если " smoke test failed!!!", вы отправляете приложение на доработку.

Если же " smoke test passed!!!", то вы переходите к следующему виду тестирования - регрессионное тестирование (Regression testing) и санитарное тестирование (Sanity testing).

Открыв багтрекер, вы должны перепроверить дефекты, которые разработчики перевели в статус Fixed (Исправлено), Rejected, Can't Reproduce и т.д. Заметим, что статусы Rejected и Can't Reproduce для вас самые неприятные - это явное свидетельство того, что либо вы недостаточно хорошо локализовали дефект, не очень понятно описали шаги для воспроизведения, либо разработчик поленился воспроизвести ситуацию.

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

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

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

Надеюсь что вы запомнили, последовательность выполненных видов тестирования:

 

Процесс тестирования

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

Рис. 2.19. Спиральный (расширяющийся) характер процесса тес

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

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

1. Тестирование элементов. Цель — индивидуальная проверка каждого модуля. Используются способы тестирования «белого ящика».

2. Тестирование интеграции. Цель — тестирование сборки модулей в программную систему. В основном применяют способы тестирования «черного ящика».

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

4. Системное тестирование. Цель — проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализации всех системных функций.

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

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

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

Жизненный цикл дефекта

Жизненный цикл дефекта[править | править вики-текст]

Как правило, система отслеживания ошибок использует тот или иной вариант «жизненного цикла» ошибки, стадия которого определяется текущим состоянием, или статусом, в котором находится ошибка.

Типичный жизненный цикл дефекта:

1. новый — дефект зарегистрирован тестировщиком

2. назначен — назначен ответственный за исправление дефекта

3. разрешён — дефект переходит обратно в сферу ответственности тестировщика. Как правило, сопровождается резолюцией, например:

· исправлено (исправления включены в версию такую-то)

· дубль (повторяет дефект, уже находящийся в работе)

· не исправлено (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и т.п.)

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

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

5. открыт повторно — дефект вновь найден в другой версии.

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

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

Жизненный цикл дефектов

Итак, мы нашли баг. Может даже блокер. Что же с ним может случится, на всём его нелегком жизненном пути? (Названия этапов жизни дефектов могут быть разными в разных баг-трекинг системах, но суть их одна).

• Новый (New). Тестировщик нашел баг, дефект успешно занесен в «Bug-tracking» систему.

• Открыт (Opened). После того, как тестеровщик отправил ошибку, она либо автоматически, либо в ручную назначается на человека который должен её проанализировать (обычно Project Manager). В зависимости от решения менеджера проекта, баг может быть:

— Отложен (Deferred). Исправление этого бага не несет ценности на данном этапе разработки или по другим, отсрочивающим его исправление причинам.

— Отклонен (Rejected). По разным причинам дефект может и не считаться дефектом или считаться неактуальным дефектом, что вынуждает отклонить его.

— Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему, то статус такой ошибки меняется на «дубликат».

• Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика который должен исправить ошибку.

Когда наличие дефекта неопровержимо, его путь может привести к следующим статусам:

• Исправлен (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.

В зависимости от того, исправил ли разработчик дефект, дефект может быть:

— Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект, или все-таки разработчик безответственный. Если бага больше нет, он получает данный статус.

— Повторно открыт (Reopened). Если опасения тестировщика оправданы и баг в новом билде не исправлен – он все так же потребует исправления, поэтому заново открывается.

• Закрытый (Closed). В результате определенного количества циклов баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым.

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

 

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

Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование. Является частью общеинженерной дисциплины «инженерия требований» (англ. Requirements Engineering).

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

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

Анализ требований включает три типа деятельности:

· Сбор требований — общение с клиентами и пользователями, чтобы определить, каковы их требования; анализ предметной области.

· Анализ требований — определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; решение этих проблем; выявление взаимосвязи требований.

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

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

Фазы[править | править вики-текст]

Процесс анализа требований к информационной системе включает следующие фазы:^[1]

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

· Выявление требований

· Анализ требований

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

· Проверка требований

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

Выявление и анализ требований[править | править вики-текст]

Идентификация стейкхолдеров [править | править вики-текст]

Основная статья: Стейкхолдер

Стейкхолдер — физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC 15288:2008, ISO/IEC 29148:2011).

Опрос стейкхолдеров [править | править вики-текст]

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

Сеансы совместного развития требований (СРТ) [править | править вики-текст]

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

Спецификация требований[править | править вики-текст]

Списки требований [править | править вики-текст]

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

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

Преимущества [править | править вики-текст]

· Обеспечивает контрольный список требований.

· Обеспечивает договор между заказчиками и разработчиками.

· Для большой системы может обеспечить описание высокого уровня.

Недостатки [править | править вики-текст]

· Такие списки могут занимать сотни страниц. Фактически невозможно прочитать такие документы в целом и получить чёткое понимание системы.

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

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

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

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

· Эта абстракция означает, что чрезвычайно трудно убедиться, что у вас есть все необходимые требования.

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

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

Альтернативы спискам требования [править | править вики-текст]

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

Измеримые цели [править | править вики-текст]

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

Прототипы (опытные образцы) [править | править вики-текст]

В середине 1980-х прототипирование (англ. prototyping) рассматривалось как решение проблемы анализа требований. Прототипы — макеты системы. Макеты дают возможность пользователям представить систему, которая ещё не построена. Опытные образцы помогают пользователям представить, на что будет похожа система, и облегчают пользователям принятие проектных решений, не дожидаясь окончания постройки системы. Наибольшие улучшения во взаимопонимании между пользователями и разработчиками часто замечались с введением опытных образцов. Ранние обзоры системы приводят к меньшему количеству изменений на поздних стадиях разработки и следовательно значительно уменьшают затраты.

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

· Менеджерам, как только они видят опытный образец, сложно понять, что окончательный проект не будет разработан ещё некоторое время.

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

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

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

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

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

Сценарии использования [править | править вики-текст]

Вариант использования (англ. Use Case) — техника для документации потенциальных требований для создания новой системы или изменения существующей. Каждый вариант описывает один или несколько способов взаимодействия системы с конечным пользователем или другой системой, для достижения определённой цели. Варианты использования обычно избегают технического жаргона, предпочитая вместо этого язык конечного пользователя или эксперта в данной области. Они часто создаются совместно специалистами по сбору требований и заинтересованными лицами.

Варианты использования — наиболее важный инструмент для моделирования требований с целью спецификации функциональных возможностей разрабатываемого программного обеспечения или системы в целом. Они могут содержать дополнительное текстовое описание всех способов, которыми пользователи могут работать с программным обеспечением или системой. Такое текстовое описание называется сценарием. Как правило, варианты использования отвечают на вопрос «Что должна выполнить система для конкретного актёра (англ. Actor)?», не отвечая на вопрос «Каким образом система должна это реализовать?» Текст сценария в этом случае дополняет графическое представление вариантов использования в форме описания последовательности шагов или действий, следуя которым пользователь может достичь желаемой цели при взаимодействии с системой. Полнота функциональных требований к разрабатываемой системе достигается спецификацией всех вариантов использования с соответствующими сценариями, отражающими все пожелания и потребности пользователей к разрабатываемой системе.

Спецификация требований программного обеспечения [править | править вики-текст]

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) является полным описанием поведения системы, которая будет создана. Она включает ряд сценариев использования, которые описывают все виды взаимодействия пользователей с программным обеспечением. Сценарии использования также известны как функциональные требования. В дополнении к сценариям использования, спецификация программного обеспечения также содержит нефункциональные (или дополнительные) требования. Нефункциональные требования — требования, которые налагают дополнительные ограничения на систему (такие как требования эффективности работы, стандарты качества, или проектные ограничения).

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

Типы требований[править | править вики-текст]

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

Требования клиентов [править | править вики-текст]

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

· Требования эксплуатации или развёртывания: Где система будет использоваться?

· Профиль миссии или сценарий: Как система достигнет целей миссии?

· Требования производительности: Какие параметры системы являются критическими для достижения миссии?

· Сценарии использования: Как различные компоненты системы должны использоваться?

· Требования эффективности: Насколько эффективной должна быть система для выполнения миссии?

· Эксплуатационный жизненный цикл: Как долго система будет использоваться?

· Окружающая среда: Каким окружением система должна будет эффективно управлять?

Функциональные требования [править | править вики-текст]

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

Нефункциональные требования [править | править вики-текст]

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

Производные требования [править | править вики-текст]

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

Известные модели классификации требований включают FURPS и FURPS+, разработанные в Hewlett-Packard.

Проблемы анализа требований[править | править вики-текст]

Проблемы стейкхолдеров [править | править вики-текст]

Стив Макконнелл, в его книге «Быстрая разработка»^[2], подробно описывает как пользователи могут препятствовать сбору требований:

· пользователи не понимают то, что они хотят, или у пользователей нет ясного представления об их требованиях;

· пользователи не соглашаются с ранее записанными требованиями;

· пользователи настаивают на новых требованиях после того, как стоимость и график работ были установлены;

· коммуникация с пользователями является медленной;

· пользователи часто не участвуют в обзорах требований или неспособны в них участвовать;

· пользователи технически не подготовлены;

· пользователи не понимают процесса разработки ПО.

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

Проблемы инженеров / разработчиков [править | править вики-текст]

Возможные проблемы, вызванные инженерами и разработчиками во время анализа требований:

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

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

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

Решения проблем [править | править вики-текст]

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

Методики, введённые в 1990-х — прототипирование, унифицированный язык моделирования (UML), сценарии использования и гибкая методология разработки, — также предназначены для решения описанных выше проблем.

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

В этой главе я познакомлю вас с функциями аналитика требований, требованиями, которые предъявляются к его знаниям и опыту, а также расскажу, как воспитать аналитика в своей организации (Wiegers, 2000). Пример должностных обязанностей аналитика требований опубликован на: http://www.processimpact.com/goodies.shtml.

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

Аналитик требований — это основное лицо, отвечающее за сбор, анализ, документирование и проверку требование к проекту. Это основной коммуникативный канал между группой клиентов и командой разработчиков (рис. 4-1), хотя, конечно, не единственный: есть и другие, Аналитик отвечает за сбор и распространение информации о продукте, а менеджер проекта — за обмен информацией о проекте.

 

 

Рис. 4-1. Обязанности аналитика требований: наведение коммуникативных мостов между различными группами клиентов и разработчиков проекта

 

Аналитик требований — это одна из ролей участников проекта, а не обязательно название должности. На эту роль можно назначить одного или нескольких специалистов. Кроме того, функции аналитика могут выполнять другие члены команды параллельно со своими обязанностями, например менеджер проекта, менеджер по продукту, профильный специалист (subject matter expert), разработчик и даже пользователь. В любом случае аналитик должен обладать всеми навыками, знаниями и личными качествами, необходимыми для эффективной работы.

 

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

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

Задачи аналитика.

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

Определить бизнес-требования. Ваша работа в качестве аналитика начинается, когда вы помогаете спонсору, менеджеру продукта или менеджеру по маркетингу определить бизнес-требования к проекту. Возможно, первое, что следует спросить: «Зачем мы начинаем этот проект?» Бизнес-требования включают бизнес-цели организации и представление о внешнем виде и функциональности системы. Можно разработать шаблон документа об образе и границах (см. главу 5) и, расспросив людей, имеющих представление о внешнем виде системы, получить у них необходимую информацию.

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

Выявить требования. Требования к программному продукту не лежат на виду и не ждут, когда какой-нибудь аналитик придет и соберет их, Профессиональный аналитик помогает пользователям четко обрисовать функции системы, необходимые им для достижения бизнес-целей. (Подробнее об этом — в главах 7 и 3). Для этого у него в арсенале припасено множество способов сбора информации:

· интервью;

· семинары;

· анализ документов;

· опросы;

· посещение рабочих мест клиентов;

· анализ бизнес-процессов;

· анализ документооборота и задач;

· списки событий;

· анализ конкурирующих продуктов;

· исследование существующих систем;

· ретроспективы развития предыдущего проекта.

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

Анализировать требования. Ищите производные требования, логически проистекающие из запросов клиентов, а также невысказанные ожидания, которые, как считают клиенты, и так будут реализованы. Сразу же проясните неясные и неубедительные слова, порождающие двусмысленность (примеры см. в главе 10). Выявите конфликтующие требования и области, требующие подробной детализации. Определите функциональные требования с такой степенью подробности, которая необходима разработчикам. От проекта к проекту степень подробности различается. Для Web-узла, постепенно создаваемого небольшой и дружной командой, достаточно документации с ограниченным перечнем требований. Напротив, для разработки сложной встроенной системы, которую будет строить внешний поставщик, потребуется точная и подробная спецификация требований к ПО.

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

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

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

Обеспечить расстановку приоритетов требований. Аналитик обеспечивает общение и взаимодействие различных классов пользо