?

Log in

No account? Create an account

beskov


Программные продукты и проекты

Методы, Подходы, Новости, Объявления, Заметки


Previous Entry Share Next Entry
Уровни требований, источники, документы, ответственные
beskov
Странно, но до сих пор не находил ничего подобного, потому решил сделать сам, почитав перевод SWEBOK Сергея Орлика в части УТ, который в комментариях опирался на Вигерса, Лефингвелла и Коберна.


Уровень

Название вида требований

Источники

Название документа

Порядок количества
требований

Вид теста

Ответственный за создание / контроль реализации

Подход к разработке с акцентом на этом уровне

Чёрный ящик

Предприятие / Рынок

Бизнес-потребности

Business Needs

Менеджмент компании,
Рынок

Обоснование потребности
(Business Case,
Stakeholder Requests)

5

Опытно-промышленная эксплуатация,
Выход на рынок

Менеджер проекта

 

Заказчик

Бизнес-требования, Свойства продукта
(Business Requirements,
Features)

Заказчик,
Эксперт предметной области,
Маркетолог

Концепция
(Vision)

25

Пакет приёмочных тестов,
«Показ»

Бизнес-аналитик, Менеджер продукта

Risk-Driven Approach

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

Требования пользователя

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

Требования к ПО
(Software Requirements Specification):
прецеденты, неф.требования

100

Приёмочный тест (Acceptance Test)

Системный аналитик

Structured System Analysis,
Use-Case Driven Development, Object-Oriented Analysis,
User-Centered Design,
Task-Centered Design

Белый ящик

Система

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

Стандарты, Архитектурные шаблоны

Документ архитектуры
(Software Architecture Document):
уровни, пакеты, внешние интерфейсы

150

Системный тест
(System Test)

Архитектор

Model-Driven Architecture,
Service-Based Development,
Component Based Development,
Event-Driven Architecture,
Service Oriented Architecture

Подсистема (компонент)

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

Шаблоны проектирования

Модель проектирования
(Design Model):
компоненты, классы, интерфейсы

1000

Интеграционный тест (Integration Test)

Проектировщик

Model-Driven Development, Object-Oriented Design, Refactoring

Модуль

Требования к модулю

Соглашения о кодировании, Алгоритмы вычислений

Спецификация модуля (?): методы, сигнатуры

2000

Модульный тест
(Unit Test)

Программист

Test-Driven Development,
Object-Oriented Programming


  • 1
В анналы однозначно!

(Deleted comment)
С указанием источника - конечно.

(Deleted comment)
Я ещё добавил столбец подходов к разработке, интересно, насколько удачно.

А как тебе сама книга Орлика? Нашел что-нибудь полезное для себя?

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

у меня есть пара вопросов

1. На этапе создания документа Vision, что Вы имеете в виду под термином «Показ» (и "Пакет приёмочных тестов", на мой взгляд, еще формировать рановато: Вы пока еще не определились со всеми факторами, влияющими на системные ограничения)?
Если "Показ" - это черновая версия прототипа системы, то я на 100% согласна с уместностью его составления и наличия на данном этапе.
2. Табличка очень хорошая, прекрасная табличка, но взаимосвязи между документами всё-таки прослеживаются не совсем четко. Если, например, у меня в группе есть новичок, ему не совсем будет ясно, какие документы он должен брать за основу при разработке, скажем, системной спецификации.
3. Табличная структура мне немного мешает, очевидно. Но правильно ли я понимаю, что то, что указывается в одной строке таблицы, читается "слева направо" и документы, указанные слева в этой таблице, являются основой для документов, указанных справа? Или здесь еще есть связи "сверху вниз" и "слева направо"?
Я вот к чему. Приемочные тесты (Acceptance Tests) основываются только на пользовательских требованиях к ПО? Мне кажется, на данном этапе мы можем быть более или менее уверены в том, что получаем корректные функциональные тесты, а о приёмочных говорить пока ещё рановато. Пример: разрабатываемая аналитическая система реплицирует данные из внешних систем. На этапе проработки пользовательских требований мы договариваемся о функциональности, определяем нефункциональные требования и существующие ограничения; реализация на данном этапе еще не продумана. Физической модели БД еще нет. Как я пишу приёмочные тесты для модуля, реплицирующего данные из внешних систем, если пока ещё схема репликации у меня не готова (в отсутствии готовой физической модели БД)?

Re: у меня есть пара вопросов

1. В таблице нет чёткой опоры на этапы и процесс, это просто иерархия требований по уровням от бизнеса к технологиям. Связку Документ-вид теста скорее стоит читать как V&V. Показ в данном случае может означать и показ прототипа, и показ полной системы для любого типа процесса. "Показ", демонстрация - это способ доказательства Заказчику того, что система соответствует его требованиями, обладает необходимыми высокоуровневыми свойствами.

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

3. Основные связи - сверху-вниз по столбцам Уровень-Документ, снизу-вверх по столбцу "тип теста". Слева направо читается в том смысле, что требования из соотв. столбца аккамулируются в документы их другого столбца.

Приемочные тесты (Acceptance Tests) основываются только на пользовательских требованиях к ПО?
У меня очень мало опыта в тестировании. Коллега - руководитель службы тестиирования сказал, что в целом верно ).

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

виды тестов

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

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

проектировщик подсистемы - например, базы данных

  • 1