Словарь терминов. Карл Вигерс — различия между версиями

Текущая версия на 15:07, 18 апреля 2012

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 - «быстрый» метод разработки ПО, который характеризуется тесным взаимодействием разработчиков с находящимися тут же представителями клиентов, ограничением документации требований «историями пользователей», а также быстрым и частым выпуском небольших фрагментов функциональности пользователей.