Tbd что это в бизнесе
Trunk-Based Development: как мы внедряем разработку на основе главной ветки
В этой статье мы подробно расскажем о том, как мы трансформируем процесс разработки в наших командах.
Trunk Based Development на пальцах
Все релизы в обязательном порядке выходят в ветке Trunk или Master (по-русски – главной ветке). Разработка новых фич ведется в отдельных, коротко живущих ветках, так называемых фича-бранчах (Feature Branches). Разработчик делает ответвление, пишет код в течение одного-двух дней и возвращает ветку обратно в Master.
Принципиально важно всегда поддерживать работоспособность и стабильность Master-ветки. Здесь на помощь приходят Feature Toggles (FT) – специальные переключатели в коде, которые отображают/скрывают элементы решения или приложения. Они встраиваются в код во время разработки, а управление ими происходит через специальный портал. Так мы можем скрыть от пользователя нестабильные и незавершенные функции, пока идет доработка, и это не повлияет на работу приложения в целом.
Автоматическое тестирование и непрерывное Code Review – еще две обязательных компонента TBD. Если все изменения в фича-бранче закончены, их нужно оперативно слить в Master, поэтому проверка кода должна быть приоритетной задачей. Что касается автотестов, то строго говоря, они подходят не для всех задач, и покрывать ими 100% кода не нужно (мы подробно рассказывали об этом в статье про наш опыт внедрения практик SDET). Для каждой конкретной задачи сценарий тестирования прописывается на этапе планирования. Для задач, где автотесты актуальны, код сливается в Master только после их прохождения.
Декомпозиция задач и Short-lived ветки
Все ветки кода, кроме главной, должны иметь короткий срок жизни, максимум – несколько дней. Этого можно добиться за счет мелкой декомпозиции: ветка будет небольшой, если она решает небольшую задачу. Правильная постановка задач на этапе планирования играет очень важную роль, поэтому мы придерживаемся принципа декомпозиции задач INVEST и вводим иерархию задач.
Декомпозиция по INVEST определяет, каким должен быть пользовательский сценарий (user story):
Independent — независимый
Negotiable — написанный понятным языком
Valuable — несущий ценность
Estimable — поддающийся оценке
Small — компактный, не более 40 часов разработки
Testable — тестируемый в широком смысле
Каждую из планируемых задач нужно «прогнать» по всем этим пунктам. Если по результатам выпадает хотя бы один из них, задачу нужно декомпозировать заново.
Иерархия задач
При уменьшении отдельных задач их общее количество возрастает многократно. Правильно расставить приоритеты и не потеряться в этом потоке нам помогает иерархия задач.
Непрерывная поставка и TBD
Конечная цель всех наших внутренних изменений – ускорение и оптимизация стандартных этапов создания IT-решений.
Мы тщательно проанализировали наш процесс разработки и нашли несколько точек потери времени и качества – они могут возникать из-на недоработки на конкретном этапе или из-за проблем между разными этапами.
Недостаточная аналитика и декомпозиция;
Сборка релизов из множества задач;
Длительное ожидание Code Review;
Потери на слияние больших изменений;
Отсутствие обратной связи от потребителей.
Для того, чтобы оптимизировать этот процесс, мы переходим от ручной доставки программного обеспечения к практике так называемой “непрерывной поставки” (Continuous Delivery, CD). Это надежный, контролируемый и максимально автоматизированный процесс с понятными и четко измеряемыми рисками, который:
Учитывает потери на каждом этапе;
Учитывает потери на переходах между этапами;
Может быть собран автоматически на основе метрик трекера.
Как мы внедряем TBD в работу команд
Прежде всего, мы придерживаемся мнения, что внедрение методики TBD имеет смысл только в активно растущих продуктах. Если на данном этапе проекта мы выпускаем по одной правке в месяц и ведем поддержку, TBD не актуально.
В целом, мы не рассматриваем переход на TBD как отдельную задачу, мы стараемся действовать комплексно и включаем в наши проекты несколько платформенных практик сразу – это и переход на единый трекер Azure DevOps, и добавление функций SDET в командах, и внедрение TBD, в том числе.
Наши проекты сейчас находятся на разных стадиях перехода на TBD, от проекта к проекту текущий статус может отличаться достаточно сильно. Но, в любом случае, в каждом из них мы стараемся внедрить важные составляющие CD и TBD, например, правильную декомпозицию задач, написание автотестов и тестирование требований.
Словарь терминов (глоссарий) по разработке требований (Вигерс, 2013)
CRUD matrix — таблица, связывающая действия системы с элементами данных, чтобы показать, где каждый элемент создается (Created), читается (Read), обновляется (Updated) и удаляется (Deleted). Planguage — основанный на ключевых словах язык, предложенный Томом Гилбом (Tom Gilb) и позволяющий создать точную и количественно оцениваемую спецификацию требований.
Swimlane-диаграмма
diagram — модель анализа, показывающая последовательные шаги потока бизнес-процессов предлагаемой программной системы. Процесс разбивается на визуальные компоненты, называемые дорожками, которые показывают системы или действующие лица, выполняющие эти шаги.
TBD — сокращение от To Be Determined. Служит для отметки неясностей или пропусков, которые надо заполнить, в информации требований.
UML (Unified Modeling Language) — набор стандартной нотации для создания различных визуальных моделей систем, особенно в объектно-ориентированном программировании.
Альтернативное направление
alternative flow — направление, учитывающее вариант использования, которое ведет к успеху (достижение цели действующего объекта), но которое подразумевает отклонение от нормального направления в специфике задач или при взаимодействии объекта с системой.
Анализ первопричин
root cause analysis — действия, которые предпринимаются для поиска основных причин, вызывающих наблюдаемые проблемы.
Анализ расхождение
gap analysis — сравнение текущего состояния и альтернативного или возможного состояния системы, процесса или другого аспекта бизнес-ситуации для выявления значительных расхождений между ними.
Анализ требований
requirements analysis — процесс классификации информации, касающейся требований, по различным категориям, оценка требований для определения желаемого качества, представление требований в различных формах, выделение детальных требований из требований более высокого уровня, обсуждение приоритетов требований и т. д.
Архитектура
architecture — структура системы, включающая все ПО, оборудование и людей, из которых она состоит, интерфейсы и взаимосвязи между этими компонентами и поведение компонентов, видимое другим компонентам.
Атрибут качества
quality attribute — вид нефункционального требования, описывающего характеристику сервиса или производительности продукта. Примеры атрибутов качества: удобство и простота использования, легкость перемещения, легкость в эксплуатации, целостность, надежность, эффективность и устойчивость к сбоям. В требованиях описаны рамки атрибутов качества, до которых продукт демонстрирует желаемые характеристики.
Атрибут требования
requirement attribute — описательная информация о требованиях, которая дополняет описание желаемой функциональности продукта. К ней относятся источники данных, логические обоснования, приоритеты, ответственные лица, номера версий и выпусков.
Бизнес-аналитик
business analyst — роль члена команды по разработке требований, основная обязанность которой — работа с заинтересованными лицами над выявлением, анализом, определением, утверждением и управлением требованиями в проекте. Эта роль также может называться аналитик требований, системный аналитик, разработчик требований и просто аналитик.
Бизнес-правило
business rule — политика, предписание, стандарт, правило или вычислительная формула, определяющая или ограничивающая некоторые стороны бизнес-процессов.
Бизнес-требования
business requirement — объем информации, который в совокупности описывает потребность, которая инициирует один или больше проектов, призванных предоставить решение и получить требуемый конечный бизнес-результат. Бизнес-требования включают бизнес-возможности, бизнес-цели, метрики успеха, концепция и границы и ограничения.
Бизнес-цель
business objective — финансовая или нефинансовая выгода, которую организация ожидает получить в результате реализации проекта или другой инициативы.
Блок-схема
flowchart — модель, которая показывает этапы процесса и точки принятия решений в логике процесса или программы. Аналогична диаграмме взаимодействия.
Большие данные
big data — обычно описывают массив данных, отличительные особенности которых — большой объем (много данных), высокая скорость (данные быстро поступают в организацию) и/или высокая сложность (данные очень разнородны). Управление большими данными предусматривает обнаружение, сбор, хранение и обработку больших объемов данных быстро и эффективно.
Бумажный прототип
paper prototype — непрограммная модель пользовательского интерфейса ПО с недорогими, несложными в исполнении эскизами экрана.
Вариант использования
use case — описание набора логически связанных возможных взаимодействий действующего лица и системы, которые дают результат, ценный для действующего лица. Может включать много сценариев.
Взаимосвязь «расширить»
extend relationship — конструкция, в которой альтернативное направление ответвляется от нормального направления в отдельный «расширенный» вариант использования.
Владелец продукта
product owner — роль, обычно в команде проекта гибкой разработки, представляющая клиента и отвечающая за определение концепции продукта, предоставление границ и ограничений проекта, определение приоритетов запаса продукта и принятие решений по продукту.
Внешняя сущность
external entity — объект в контекстной диаграмме или диаграмма потока данных, представляющая класс пользователей, действующее лицо, программную или аппаратную систему и являющийся внешним к описываемой системе, но так или иначе взаимодействует с ней. Также называется оконечным устройством.
Водопадный жизненный цикл проекта
waterfall development life cycle — модель процесса разработки ПО, в которой различные действия с требованиями, дизайном, кодированием, тестированием и развертыванием выполняются последовательно, с небольшим наложением или итерациями.
Встроенная система
embedded system — система, содержащая аппаратные компоненты, управляемые ПО, работающем на выделенном компьютере, являющемся частью более крупного продукта.
Выходное условие
postcondition — условие, описывающее состояние системы после успешного завершения варианта использования.
Выявление требований
requirements elicitation — процесс определения требований из различных источников посредством интервью, семинаров, анализа задач, рабочих потоков и документов и других механизмов.
Гибкая разработка
agile development — методы разработки ПО, характеризующиеся постоянным взаимодействием между разработчиками и клиентами. К методам гибкой разработки относятся экстремальное программирование (Extreme Programming), Scrum, разработка, управляемая функциональностью (Feature Driven Development), бережливая разработка программного обеспечения (Lean Software Development) и Kanban.
Граница проекта
scope — часть концепции конечного продукта, реализуемой в ходе текущего проекта. Определяет границу между тем, что входит и что не входит в проект, в котором создается определенный выпуск или итерация.
Действующее лицо
actor — лицо, играющее конкретную роль, программная система или аппаратное устройство, которое взаимодействует с системой для достижения полезных целей. Также называется ролью пользователя.
Дерево решений
decision tree — модель анализа, которая графически показывает действия системы в ответ на все комбинации набора факторов, которые влияют на поведение части системы.
Дерево функций
feature tree — модель анализа, отображающая функции, запланированные для продукта, в виде иерархического дерева и отображающая до двух уровней подчиненных функций в каждой функции.
Дефект требования
requirement issue — проблема, открытый вопрос или решение относительно требования. Это могут быть элементы, помеченные как «TBD» (to be determined — необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п.
Диаграмма (или машина) состояний
state machine diagram — модель анализа, показывающая представления различных состояний, которые могут принимать объекты системы на протяжении своего жизненного цикла в ответ на то или иное событие или отображающая возможные состояния системы в целом. Похожа на диаграмму перехода состояний.
Диаграмма «сущность–связь»
entity-relationship diagram — модель анализа, которая показывает логические взаимосвязи между парами объектов. Используется для моделирования данных.
Диаграмма вариантов использования
use case diagram — модель анализа с указанием действующих лиц, которые могут взаимодействовать с системой для выполнения задач, и различные варианты использования, в которых может участвовать действующее лицо.
Диаграмма взаимодействия
activity diagram — аналитическая модель, которая позволяет динамически представить систему, посредством изображения потока процессов от одной функции к другой. Схожа с блок-схемой.
Диаграмма классов
class diagram — аналитическая модель, которая показывает набор классов системы или определенной предметной области, их интерфейсы и взаимосвязи.
Диаграмма перехода состояний
state-transition diagram — модель анализа, показывающая возможные состояния системы или объектов в ней, разрешенные переходы между ними и условия и/или события, инициирующие каждый переход. Аналогична диаграмме или машине состояний.
Диаграмма потока данных
data flow diagram — модель анализа, описывающая процесс, хранилища данных, внешние сущности и потоки, характеризующие поведение данных, проходящих через бизнес-процессы или программные системы.
Документ о концепции и границах
vision and scope document — документ, в котором определены бизнес-требования к новой системе, в том числе положения о концепции продукта и описания границы проекта.
Документы процесса
process assets — документы, такие как шаблоны, формы, списки, политики, процедуры, описание процессов и примеры рабочих продуктов, которые собраны для эффективного применения в организации с целью улучшить приемы разработки ПО.
Допущение
assumption — положение, которое считается верным в отсутствие доказательств или точных знаний.
Зависимость
dependency — зависимость проекта от внешних факторов, событий или групп, находящихся вне зоны контроля.
Заинтересованное лицо
stakeholder — это человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата или может влиять на процесс или результат.
Исключение
exception — условие, которое может помешать успешному завершению варианта использования. Если некоторые возвратные механизмы не работают, то выходные условия варианта использования не достигаются и желаемая цель не достигается.
Итерация
iteration — непрерывный период разработки, обычно от одного до четырех недель, во время которого команда разработки реализует определенный набор функциональности, выбранной из резерва продукта, или базовой версии требований к продукту.
Каркас
wireframe — разновидность одноразового прототипа, который используется для предварительного дизайна веб-страниц.
Карта диалоговых окон
dialog map — модель анализа, описывающая архитектуру пользовательского интерфейса, показывая видимые диалоговые элементы и навигацию между ними.
Карта экосистемы
ecosystem map — аналитическая модель, которая показывает набор классов системы или определенной предметной области, их интерфейсы и взаимосвязи. В отличие от контекстных диаграмм, карта экосистемы показывает системы, имеющие отношения друг с другом, даже если между ними нет интерфейса.
Класс пользователей
user class — группа пользователей системы, имеющих схожие требования к системе. Члены пользовательского класса функционируют как действующие лица при взаимодействии с системой.
Класс
class — описание набора объектов, имеющих общие свойства и поведение, которые стандартным образом соотносятся с элементами реального мира (людьми, местами или вещами) в бизнесе или определенной предметной области.
Клиент
customer — человек или организация, получающая от продукта прямую или косвенную выгоду. Клиенты это заинтересованные в проекте лица, запрашивающие, оплачивающие, выбирающие, определяющие, использующие и получающие результаты работы программного продукта.
Количество элементов
cardinality — количество элементов данных объектов или данных, которые связаны с элементами других объектов или данных. Например, «один к одному», «один ко многим» или «многие ко многим».
Контекстная диаграмма
context diagram — аналитическая модель, которая описывает абстрактную систему высокого уровня. Контекстная диаграмма определяет внешние для системы объекты, которые взаимодействуют с ней, но не отображает ничего из внутренней структуры или поведения системы.
Концепция
vision — утверждение, описывающее стратегический принцип конечной цели и формы новой системы.
Критерий приемлемости
acceptance criteria — условия, которым продукт должен удовлетворять, чтобы его приняли пользователи, клиенты или другие заинтересованные лица.
Матрица отслеживания связей требований
requirements traceability matrix — таблица, отображающая логические связи между функциональными требованиями и другими системными артефактами, в том числе функциональными требованиями, пользовательскими требованиями, бизнес-требованиями, элементами архитектуры и дизайна, модулями кода, тестами и бизнес-правилами.
Модель
mock-up — частичная или возможная реализация пользовательского интерфейса для систем ПО. Применяется для оценки легкости и простоты использования, а также завершенности и корректности требований. Может представлять собой программу или прототип на бумаге. Также называется горизонтальным прототипом.
Модель бизнес-целей
business objectives model — визуальное представление иерархии бизнес-задач и бизнес-целей.
Нефункциональное требование
nonfunctional requirement — описание присущих свойств или характеристик, которые система ПО должна демонстрировать, или ограничения, которые она должна соблюдать.
Нормальное направление
normal course — последовательность действий, заданная по умолчанию в варианте использования, которая ведет к удовлетворению выходных условий этого варианта использования или достижению целей пользователей. Другие названия: нормальное направления развития, базовый поток, нормальная последовательность, основной успешный сценарий и счастливый путь (happy path).
Ограничение
constraint — налагается на доступные разработчику возможности дизайна или конструирования продукта. Другие типы ограничений могут ограничить возможности, доступные для менеджеров проектов. Бизнес-правила часто накладывают ограничения на бизнес-операции, а значит, на программные системы.
Одноразовый прототип
throwaway prototype — прототип, который создается с расчетом, что после его использования для уточнения и утверждения требований и вариантов дизайна он будет выброшен.
Оперативный профиль
operational profile — комплект сценариев, который представляет ожидаемые случаи применения ПО.
Организатор мероприятия
facilitator — лицо, ответственное за планирование и работу группы, например работу семинара по выявлению требований.
Основная версия требований
requirements baseline — зафиксированный в определенный момент времени, согласованный, просмотренный и одобренный набор требований, обычно определяющих определенный выпуск продукта или итерацию разработки. Служит основой для дальнейшей разработки.
Отношение включения
include relationship — конструкция, в которой несколько шагов, повторяющихся во многих вариантах использования, выделяются в отдельный вложенный вариант использования, который вызывается по мере необходимости.
Отслеживание
tracing — процесс определения логических связей между одним элементом системы (вариантом использования, функциональными требованиями, бизнес-правилами, компонентами дизайна, фрагментами кода, тестами и т. д.) и другим.
Панель мониторинга
dashboard — изображение на экране или в печатном документе с множественными текстовыми и/или графическими представлениями данных, предоставляющее консолидированное многомерное представление происходящего в организации или процессе.
Пилотная версия
pilot — контролируемое выполнение нового решения (такого как процесс, инструмент, программная система или учебный курс) для оценки его работы в реальных условиях и готовности к развертыванию.
Повторное использование требований
requirements reuse — использование существующих требований во многих системах, отличающихся одинаковой функциональностью.
Пользователь
user — клиент, который взаимодействует с системой непосредственно или косвенно (например, пользуется результатами работы системы, хотя не генерирует эти результаты). Также называется конечным пользователем.
Пользовательская история
user story — способ выражения пользовательских требований в проектах гибкой разработки в форме одного или двух предложений, формулирующих потребность пользователя или описывающих единицу необходимой функциональности, а также говорящих о пользе, какую эта функциональность приносит пользователю.
Пользовательское требование
user requirement — цель и задача, которую пользователи должны иметь возможность выполнять с системой, или положения об ожиданиях пользователей о качестве системы. Пользовательские требования обычно представляются в виде вариантов использования, пользовательских историй и сценариев.
Поток процесса
process flow — последовательные шаги бизнес-процесса или операций предложенной программной системы. Обычно предоставляется с применением диаграммы взаимодействия, блок-схемы, swimlane-диаграммы или другой нотации моделирования.
Правило решения
decision rule — согласованный способ выработки единого решения в группе людей.
Предварительные условия
precondition — условия, которые должны быть удовлетворены, или состояние, в котором система должна пребывать, чтобы мог начаться вариант использования.
Приемочный тест
acceptance test — тест для проверки ожидаемых вариантов использования с целью определения приемлемости ПО. Используется в проектах гибкой разработки для представления подробностей пользовательских историй и определения правильности их реализации.
Приоритизация, определение приоритетов, расстановка приоритетов
prioritization — акт определения того, какие требования программного продукта наиболее важны для достижения бизнес-успеха и в каком порядке должны реализовываться требования.
Проверка
verification — процесс оценки рабочего продукта, позволяющий определить, удовлетворяет ли он спецификации, на основе которой создан. Обычно формулируется в виде вопроса: «Правильно ли мы создаем продукт?»
Продукт
product — конечный результат разработки, выполняемой в рамках проекта. В этой книге используются также термины-синонимы «приложение», «система» и «решение».
Проект с чистого листа
green-field project — проект, в котором разрабатывается новое ПО или новая система.
Прототип
prototype — частичная, предварительная или возможная реализация программы. Применяется для исследования и утверждения требований, а также для разработки приемов. Прототипы бывают эволюционные, одноразовые, бумажные, горизонтальные и вертикальные.
Процедура
procedure — пошаговое описание направления действия для выполнения и завершения конкретной работы.
Процесс
process — последовательность действий, выполняемых для достижения конкретной цели. Описание процесса представляет собой документированное определение этих действий.
Процесс создания требований, процесс построения требований
requirements engineering — область, которая охватывает все стороны жизненного цикла проекта, связанные с необходимыми возможностями и атрибутами продукта. Состоит из разработки требований и управления требованиями. Считается подобластью процессов построения системы и ПО.
Рабочий продукт
work product — любой промежуточный или окончательный результат, созданный в проекте разработки ПО.
Разработка требований
requirements development — процесс определения границ проекта, классов и представителей пользователей, выявления, анализа, спецификации и утверждения требований. Результатом этого процесса считается основная версия требований, в которой указано, что за продукт должен быть построен.
Расползание границ проекта
scope creep — условия, при которых границы проекта неконтролируемо расширяются на протяжении всего процесса.
Распределение требований, назначение требований
requirements allocation — процесс распределения системных требований по различным архитектурным и компонентным подсистемам.
Резерв продукта
product backlog — в проекте гибкой разработки, распределенные по приоритетам список еще не реализованных задач проекта. Резерв может содержать пользовательские истории, бизнес-процессы, запросы на изменение и разработку инфраструктуры. Рабочие элементы из резерва назначаются на будущие итерации на основе их приоритетов.
Ретроспектива
retrospective — рецензирование, в котором участники анализируют действия и результаты проекта с целью определения путей повышения успешности последующих проектов.
Рецензирование
peer review — действия, предпринимаемые одной или несколькими лицами (не авторами продукта), для исследования продукта с целью обнаружить возможные дефекты и улучшить возможности.
Решение
solution — все компоненты, которые должны быть созданы в процессе реализации проекта для достижения бизнес-целей, определенных организацией, в том числе ПО, оборудование, бизнес-процессы, руководство пользователя и обучение.
Риск
risk — условие, которое может привести к потере или иным образом поставить под угрозу успех проекта.
Серийные продукты, коммерческие готовые продукты
COTS (commercial offtheshelf) product — готовый пакет ПО, приобретаемый у поставщика. Применяется как готовое решение или интегрируется, настраивается и расширяется в соответствии с потребностями клиента для удовлетворения нужд последнего.
Система
system — продукт, содержащий много программных или аппаратных подсистем. В общеупотребимом смысле используется в этой книге в отношении приложения, продукта и решения для обозначения любого содержащего ПО результата, создаваемого командой.
Система бизнес-аналитики
business analytics system — программная система, служащая для преобразования больших и сложных наборов данных в осмысленную информацию, на основе которой можно принимать решения.
Система реального времени
real-time system — аппаратная или программная система, которая должна реагировать в четко определенное время на заданные события.
Системное требование
system requirement — требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования
Словарь данных
data dictionary — набор определений элементов данных, структуры и атрибутов, относящихся к определенной предметной области.
Событие
event — инициирующее или стимулирующее событие, которое происходит в системной среде, например поведение функции или изменение состояния.
Совет по управлению изменениями
change control board — группа сотрудников, отвечающая за решение о принятии или отклонении предлагаемых изменений в требованиях к ПО.
Спецификация требований к продукту
software requirements specification — набор функциональных и нефункциональных требований к продукту ПО.
Сторонник продукта
product champion — назначенный представитель отдельного класса пользователей, который предоставляет пользовательские требования представляемых им групп пользователей.
Сущность
entity — элемент области бизнеса, данные о котором собираются и сохраняются.
Схема требования
requirement pattern — систематический подход к определению определенного типа требований.
Сценарий
scenario — описание взаимодействия пользователя и системы с целью достижения некоторой цели. Пример работы с системой. Один из путей развития варианта использования.
Таблица «событие–реакция»
event-response table — перечень внешних или зависящих от времени событий, которые могут влиять на систему, и описание того, как система будет отвечать на каждое из них.
Таблица решения
decision table — модель анализа в виде матрицы, где показаны все комбинации значений для наборов факторов, которые влияют на поведение части системы, и определены ожидаемые действия системы в ответ на каждую комбинацию.
Таблица состояний
state table — модель анализа, показывающая в виде матрицы состояния, в которых может находиться система или ее объекты, а также какие возможны переходы между состояниями.
Требование
requirement — документ, где указаны потребности или цели пользователей либо условия и возможности, которыми должен обладать продукт, чтобы удовлетворить такие возможности или цели. Свойство, которым должен обладать продукт, чтобы представлять ценность для заинтересованного лица.
Требования для интерфейса внешнего устройства
external interface requirement — описание интерфейса между системой ПО и пользователем, другой системой ПО или оборудованием.
Требования-«бантики», украшательство
gold plating — не являющаяся необходимой или избыточно сложная функциональность, запланированная и разработанная для продукта, иногда без одобрения клиента.
Управление требованиями
requirements management — работа с определенным набором требований к продукту, начиная от процесса разработки продукта и заканчивая поддержкой действующего продукта. Управление подразумевает отслеживание состояния продукта, управление изменениями требований и версиями спецификаций требований, а также отслеживание требований до других требований и элементов системы.
Утверждение
validation — процесс оценки рабочего продукта, позволяющий определить, действительно ли он удовлетворяет потребности клиента. Обычно формулируется в виде вопроса: «Создаем ли мы правильный продукт?»
Функциональная точка
function point — мера размера ПО, основанная на числе и сложности внутренних логических файлов, файлов интерфейса внешнего устройства, вводимых извне данных, результатов и запросов.
Функциональное требование
functional requirement — описание поведения системы в определенных условиях.
Функция
feature — одна или несколько логически связанных возможностей системы, которые представляют ценность для пользователя и описаны рядом функциональных требований
Цикл разработки ПО
software development life cycle — последовательность действий, в которой ПО определяется, конструируется, строится и проверяется.
Шаблон
template — образец, который используется в качестве руководства при создании всеобъемлющей документации или других элементов.
Эволюционный прототип
evolutionary prototype — полностью функциональный прототип, построенный как скелет или некая стадия конечного продукта, которые постепенно будут «обрастать мясом» по мере прояснения требований.
Экспериментальный образец
proof of concept — прототип, реализующий часть содержащей программную часть системы и охватывающий много уровней архитектуры. Применяется для оценки технической осуществимости и производительности. То же самое, что вертикальный прототип.
Эксперт предметной области
subject matter expert — лицо, имеющее обширный опыт и знания в предметной области и считающееся полномочным источником информации о предметной области.
Экспертиза
inspection — тип рецензирования, когда члены специально созданной команды в определенном и строгом порядке исследуют рабочий продукт на предмет выявления дефектов.
Эпика
epic — пользовательская история в проекте гибкой разработки, которая слишком большая, чтобы ее можно было реализовать в одной итерации разработки. Эпика разбивается на более мелкие истории, каждая из которых может быть реализована в одной итерации.
Литература
Карл Вигерс и Джой Битти — Разработка требований к программному обеспечению. Издание третье, дополненное. 2013 год.