Просмотр исходного текста страницы Словарь терминов. Карл Вигерс


'''CRUD-матрица ~ CRUD matrix''' — таблица, которая позволяет согласовать действия системы с элементами данных, чтобы показать, где каждый элемент создается (Created), читается (Read), обновляется
(Updated) и удаляется (Deleted).

'''IEEE (Institute of Electrical and Electronics Engineers)''' — организация, которая поддерживает набор стандартов для управления и выполнения проектов по конструированию ПО и систем.Planguage — основанный на ключевых словах язык, предложенный Tom Gilb, который позволяет создать точную и количественно оцениваемую спецификацию требований.

'''Альтернативное напрвление развития ~ alternative course''' — направление, учитывающее вариант использования, которое ведет к успеху (достижение цели действующего объекта), но которое подразумевает отклонение от нормального направления в специфике задач
или при взаимодействии объекта с системой.

'''Анализ основных причин''' - root cause analysis — действия, которые предпринимаются для поиска основных причин, вызывающих на блюдаемые проблемы.

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

'''Аналитик требований ~ requirements analyst''' — роль члена команды по разработке требований. Аналитик отвечает за работу с заинтересованными лицами — за извлечение, анализ, определение, утверждение требований и за их управление. Эта роль также может называться бизнес-аналитик, системный аналитик, разработчик требований и просто аналитик.

'''Аналитик - analyst''' — см. аналитик требований.
Архитектура ~ architecture — структура системы, включающая ПС и оборудование (они, собственно говоря, и составляют систему), взаи
мосвязи между этими компонентами и поведение компонентов, видимое другим компонентам.

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

'''Атрибуты требований ~ requirement attribute''' — описательная
информация о требованиях, которая обогащает положения о желаемой функциональности продукта. К ней относятся источники данных,
логические обоснования, приоритеты, ответственные лица, номера версий и выпусков.

'''Бизнес-аналитик ~ business analyst''' — см. аналитик требований.
Бизнес-правило- business rule — политика, руководящие принципы или положения, которые определяют или ограничивают некоторые аспекты бизнеса.

'''Бизнес-требования''' - business requirement — высокоуровневая бизнес-цель организации, которая строит продукт, или клиента, который приобретает продукт.

'''Блок-схема - flowchart''' — модель, которая показывает этапы процесса и точки принятия решений в логике процесса или программы. Аналогична диаграмме взаимодействия.

'''Бумажный прототип''' - paper prototype — неработающая модель пользовательского интерфейса ПО с недорогими, несложными в исполнении эскизами экрана.

'''Вариант использования ~ use case''' — описание набора логически связанных возможных взаимодействий действующего лица и систе-
мы, которые дают результат, ценный для действующего лица.
Вертикальный прототип - vertical prototype — частичная реализация системы, содержащей ПО, с учетом всех уровней архитектуры.
Используется для оценки технической осуществимости и выполнения. Также называется структурным прототипом или прототипом концепции.

'''Включенная взаимосвязь - includes relationship''' — конструкция, в которой несколько повторяющихся в разных вариантах использования стадий выделяются в отдельный подвариант использования. Когда необходимо, этот подвариант вызывается вариантом использования более высокого уровня {или «вызывающим»).

'''Выходные условия''' - postcondition — условия, которые описывают состояние системы после успешного завершения варианта использования.

'''Горизонтальный прототип ~ horizontal prototype''' — частичная или возможная реализация пользовательского интерфейса для сис-
тем ПО. Применяется для оценки легкости и простоты использования, а также завершенности и корректности требований. Также называется прототипом поведения или имитацией.

'''Граница проекта ~ scope''' — часть образа конечного продукта, создаваемого в ходе текущего проекта. Определяет границу между внутренней и внешней областью проекта.

'''Действующий объект - actor''' — лицо, играющее особую роль, система ПО или аппаратное устройство, которое взаимодействует с
системой для достижения полезных целей. Также называется ролью пользователя.

'''Дерево решений - decision tree''' — аналитическая модель, которая графически показывает действия системы в ответ на все комбинации набора факторов, которые влияют на поведение части системы.

'''Диаграмма «сущность — связь» ~ entity-relationship diagram''' — аналитическая модель, которая показывает логические взаимосвязи между парами объектов.

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

'''Диаграмма взаимодействия - activity diagram''' — аналитическая модель, которая позволяет динамически представить систему, по
средством изображения потока от одной функции к другой. СХОЖЕ!, с блок-схемой.

'''Диаграмма классов ~ class diagram''' — аналитическая модель, которая показывает набор классов системы или определенной предмет
ной области и их взаимосвязи.

'''Диаграмма перехода состояний - state-transition diagram''' - аналитическая модель, показывающая возможные состояния, или статусы, системы и разрешенные переходы между ними. Аналогична диаграмме состояний.

'''Диаграмма последовательностей ~ sequence diagram''' — аналитическая модель, которая показывает порядок прохождения сообш,е-
ний между объектами или компонентами в системе для выполнения работы.

'''Диаграмма потока данных - data flow diagram''' — аналитическая модель, которая описывает процесс, набор данных, оконечные уст-
ройства и потоки, характеризующие поведение бизнес-процессов или систем ПО.

'''Диаграмма состояний ~ statechart diagram''' — аналитическая мо-
дель, показывающая последовательность состояний объекта на про-
тяжении времени его жизни в ответ на происходящие события или воз-
можные состояния системы в целом. Аналогична диаграмме перехода
состояний.

'''Документ об образе и границах''' - vision and scope document -
документ, в котором определены бизнс-требования к новой система, в
том числе положения об образе продукта и описания границы проекта.

'''Допущение - assumption''' — положение, которое считается вер-
ным в отсутствие доказательств или точных знаний.
Зависимость - dependency — зависимость проекта от внешних
факторов, событий или групп, находящихся вне зоны контроля.
Заинтресованные лица - stakeholder — активно участвующие в
проекте лица, группы или организации, которых затрагивает получен-
ный результат и которые сами могут влиять на этот результат.
«Золочение», украшательство - gold plating — на являющаяся
необходимой или избыточно сложная функциональность, разработан-
ная для продукта.

'''Извлечение требований''' - elicitation, requirements — процесс
определения требований к ПО или системе от различных источников
посредством интервью, семинаров, анализа задач, рабочих потоков и
документов и других механизмов.

'''Карта диалогов - dialog map''' — аналитическая модель, которая
описывает архитектуру пользовательского интерфейса, показывая ви-
димые элементы и навигацию между ними.

'''Класс пользователей''' - user class — группа пользователей систе-
мы, имеющих схожие требования к системе. Члены пользовательского
класса функционируют как действующие лица при взаимодействии с
системой.

'''Класс ~ class''' — описание набора объектов, имеющих общие свой-
ства и поведение, которые стандартным образом соотносятся с эле-
ментами реального мира (людьми, местами или вещами) в бизнесе
или определенной предметной области.
Клиент - customer — лицо, заинтересованное в проекте, которое
запрашивает, оплачивает, выбирает, определяет, использует или полу-
чает продукт.

'''Количество элементов - cardinality''' — количество элементов дан-
ных объектов или данных, которые связаны с элементами других объ-
ектов или данных. Например, «один к одному», «один ко многим» или
«многие ко многим».

'''Коммерческие готовые продукты''' - COTS (commercial off-theshelf)
product — готовый набор ПО, приобретаемый у поставщика.
Применяется как готовое решение или интегрируется, настраивается
и расширяется в соответствии с потребностями клиента для удовле-
творения нужд последнего.

'''Контекстная диаграмма''' - context diagram — аналитическая мо-
дель, которая описывает абстрактную систему высокого уровня. Кон-
текстная диаграмма определяет внешние для системы объекты, кото-
рые взаимодействуют с ней, но ничего не отображает внутренней
структуры или поведения системы.

'''Критерий приемлемости ~ acceptance criteria''' — условия, кот-
рым продукт должен удовлетворять, чтобы его приняли пользователи,
клиенты или другие заинтересованные лица.

'''Нефункциональные требования - nonfunctional requirement''' -
описание присущих свойств или характеристик, которые система ПО
должна демонстрировать, или ограничения, которые она должна со-
блюдать, в отличие от наблюдаемого поведения системы.
Нормальное напрвление развития ~ normal course — последо-
вательность действий, заданная по умолчанию в варианте использова-
ния, которая ведет к удовлетворению выходных условий этого вариан-
та использования или достижению целей пользователей.
Образ ~ vision — длительная стратегическая концепция конечной
цели и формы новой системы.

'''Образцы документов - process assets''' — документы — шаблон >t,
формы, списки, политики, процедуры, описание процессов и примеры
рабочих продуктов, которые собраны для эффективного применения в
организации с целью улучшить приемы разработки ПО.
Объект - entity — элемент области бизнеса, данные о котором бу-
дут собираться и сохраняться.

'''Объект - object''' — отдельный вариант класса, для которого собран
набор атрибутов данных и список возможных операций. Например,
«Мэри Джонс» — отдельный вариант класса «Клиент».
Ограничение - constraint — налагается на доступные разработчи-
ку возможности дизайна или конструирования продукта.
Одноразовый прототип ~ throws way prototype — прототип, кото-
рый создается для уточнения и утверждения требований и вариантов
дизайна. Такие прототипы не используются после того, как цель дос-
тигнута.


'''Ожидание-exception''' — условия, которые могут помешать успеш-
ному завершению варианта использования. Если некоторые возврат-
ные механизмы не работают, то выходные условия варианта использо-
вания не достигаются и желаемая цель не достигается.

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

'''Оперативный профиль ~ operational profile''' — комплект сценари-
ев, который представляет ожидаемые случаи применения ПО.
Организатор мероприятия ~ facilitator — лицо, ответственное за
планирование и работу группы, например работу семинара по извле-
чению требований.

'''Основная версия требований - baseline, requirements''' — зафик-
сированный в определенный момент времени, согласованный, про-
смотренный и одобренный набор требований для указанной версии
продукта.

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

'''Пользователь - user''' — клиент, который взаимодействует с систе-
мой непосредственно или косвенно (например, пользуется результа-
тами работы системы, хотя не генерирует эти результаты). Также на-
зывается конечным пользователем.

'''Пользовательский сценарий ~ usage scenario''' — см. сценарий.
Правило решения - decision rule — согласованный способ выра-
ботки единого решения.

'''Предварительные условия - precondition''' — условия, которые
должны быть удовлетворены, или состояние, в котором система долж-
на пребывать, чтобы мог начаться вариант использования.

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

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

'''Процедура - procedure''' — пошаговое описание направления дей-
ствий для выполнения и завершения конкретной работы.

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

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

'''Разработка требований ~ requirements development''' — процесс
определения объема проекта, классов и представителей пользовате-
лей, извлечения, анализа, спецификации и утверждения требований.
Результатом этого процесса считается основная версия требований, в
которой указано, что за продукт должен быть построен.

'''Расползание границ проекта''' - scope creep — условия, при кото-
рых границы проекта увеличиваются, как правило, неконтролируемс,
на протяжении всего процесса.

'''Распределение allocation''' — см. распределение требований.

'''Распределение требований ~ requirements allocation''' — про-
цесс распределения системных требований по различным архитектур-
ным и компонентным подсистемам.

'''Расширенная взаимосвязь - extends relationship''' — конструк
ция, где альтернативное направление варианта использования от-
ветвляется от нормальной последовательности действий. Последова
тельность действий альтернативного направления можно определить
как расширенный вариант использования, который выполняется для
достижения альтернативного результата. Процесс продолжается, ко-
гда альтернативное направление вновь присоединяется к основному
для завершения.

'''Ретроспектива - retrospective''' — см. спецификация требований к
продукту и спецификация требований.

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

'''Словарь данных - data dictionary''' — набор определений элемен-
тов данных, структуры и атрибутов, которые важны для данной пред-
метной области.

'''Событие - event''' — инициирующее или стимулирующее событие,
которое происходит в системной среде, например поведение функции
или изменение состояния.

'''Совет по управлению изменениями - change control board''' -
группа людей, отвечающая за решение принять или отклонить предла-
гаемое изменение в требованиях к ПО.

'''Спецификация требований ~ specification, requirements''' — про-
цесс документирования системы в структурированном, доступном
всем и управляемом формате. Также называется и результат этого
процесса. См. также спецификация требований к продукту.

'''Спецификация требований к продукту - software requirements specification''' — набор функциональных и нефункциональных требо-
ваний к продукту ПО.

'''Сторонник продукта - product champion''' — назначенный представитель отдельного класса пользователей, который поддерживав!
требования представляемых им групп пользователей.

'''Сценарий - scenario''' — описание взаимодействия пользователя и
системы с целью достижения некоторой цели. Пример работы с систе-
мой. Один из путей развития варианта использования. Часто представлен в виде истории.

'''Таблица «событие — реакция» - event-response table''' — перечень внешних или зависящих от времени событий, которые могут
влиять на систему, и описание того, как система будет отвечать на каждое из них.

'''Таблица решения - decision table''' — таблица, где показаны все
комбинации значений для наборов факторов, которые влияют на поведение части системы, и определены ожидаемые действия системы в
ответ на каждую комбинацию.

'''Трассирование - tracing (also traceability)''' — процесс определе-
ния логических связей между одним элементом системы (вариантом
использования, функциональными требованиями, бизнес-правилами,
компонентами дизайна, фрагментами кода, вариантами тестирования
и т.д.} и другим.

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

'''Требования для интерфейса внешнего устройства ~ external interface requirement''' — описание интерфейса между системой ПО и
пользователем, другой системой ПО или оборудованием.

'''Требования к системе ~ system requirement''' — высокоуровневые
требования к продукте, который состоит из множества подсистем, в
том числе только ПО или ПО и оборудования.

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

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

'''Утверждение - validation''' — процесс оценки рабочего продукта, по-
зволяющий определить, действительно ли он отвечает требованиям.

'''Функциональная точка - function point''' — измерение размера ПО,
основанное на числе и сложности внутренних логических файлов, фай-
лов интерфейса внешнего устройства, вводимых извне данных, ре-
зультатов и запросов.

'''Функциональные требования - functional requirement''' — поло-
жение о фрагменте требуемой функциональности или поведения, ко-
торые система проявляет при определенных условиях.

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

'''Цикл водопадной модели проекта - waterfall development lifecycle''' — модель процесса разработки ПО, в которой различные дейст
вия с требованиями, дизайном, кодированием, тестированием и развертыванием выполняются последовательно, с небольшим наложени-
ем или итерациями.

'''Цикл разработки ПО - software development life cycle''' — последовательность действий, в которой ПО определяется, конструируется,строится и проверяется.

'''Шаблон - template''' — образец, который используется в качестве
руководства при создании всеобъемлющей документации или других
элементов.

'''Эволюционный прототип - evolutionary prototype''' — полностью
функциональный прототип, построенный как «скелет» или некая ста-
дия конечного продукта, которые постепенно будут «обрастать мясом»
по мере прояснения требований.

'''Эксперт предметной области ~ subject matter expert''' — лицо,
имеющее обширный опыт и знания в предметной области и считающееся авторитетным источником информации о предметной области.

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

'''Экспертная оценка ~ peer review''' — действия, предпринимаемые одной или несколькими лицами (не авторами продукта), для исследования продукта с целью обнаружить возможные дефекты и улучшить возможности.

'''Экстремальное программирование - Extreme Programming''' - «быстрый» метод разработки ПО, который характеризуется тесным
взаимодействием разработчиков с находящимися тут же представителями клиентов, ограничением документации требований «историями
пользователей», а также быстрым и частым выпуском небольших фрагментов функциональности пользователей.