Версия (release) Комплект рабочих продуктов, подлежащий оценке при достижении контрольной точки.
Внедрение, рабочий процесс (deployment workflow) Деятельность, связанная с передачей конечных продуктов пользователю.
Выполняемый код (executable code) Код на машинном языке, выполняемое ПО, а также сценарии сборки, сценарии инсталляции и данные, необходимые для использования продукта в конкретной среде выполнения.
Декомпозиция работ (work breakdown structure) Схема планирования; декомпозиция проекта на единицы работы, для которых могут быть определены или отслежены затраты, рабочие продукты и виды деятельности.
Демонстрация (demonstration) Набор программных компонентов, реализующий потоки событий в рамках демонстрируемых вариантов использования.
Дефекты (breakage) Усредненный показатель объема ПО, которое нуждается в доработке; в качестве единиц измерения используются строки исходного кода, функциональные точки, компоненты, подсистемы, файлы или другие единицы.
Динамика команды (team dynamics) Число уволенных и нанятых сотрудников в течение некоторого времени.
Доработка (rework) Средние затраты на внесение изменений, состоящие из трудозатрат на анализ, поиск решения и повторное тестирование всех изменений, вносимых в базовую версию ПО.
Жизненный цикл (lifecycle) Один полный проход по четырем стадиям (начальная стадия, уточнение, конструирование и ввод в действие); охватывает время от старта начальной стадии до завершения стадии ввода в действие.
Завершенность (maturity) Зависимость MTBF от времени.
Заинтересованная сторона (stakeholder) Полномочный представитель, ответственный за принятие решений в каждой организации, имеющей свою долю от прибыли проекта.
Запрос на внесение изменений в ПО (software change order) Элементарная единица работ по внесению изменений в ПО, которая позволяет создавать, модифицировать или исключать компоненты в рамках базовой конфигурации.
Изменяющиеся уровни детализации (evolving levels of detail) Эволюция рабочих продуктов проекта, соответствующая текущему уровню понимания требований и архитектуры.
Интенсивность внесения изменений (change traffic) Количество запросов на внесение изменений, открытых и закрытых на протяжении всего жизненного цикла.
Исходный код (source code) Запись на языке программирования, представляющая собой реализацию компонентов и их форм, интерфейсов и зависимостей.
Итерационный процесс жизненного цикла (iterative life-cyde process).
Процесс, последовательно уточняющий на протяжении нескольких итераций понимание проблемы, ее эффективное решение и план, гарантируя при этом баланс интересов всех заинтересованных сторон.
Итерация (iteration) Последовательность работ в рамках одной стадии, в результате выполнения которых создается версия; включает в себя подробный план и документированные результаты.
Кадровое обеспечение (staffing) Число работающих над проектом.
Компонент (component) Связный модуль ПО, который представлен в виде исходного кода или в выполняемом формате и для которого определены интерфейс и поведение.
Компонентно-ориентированная разработка (component-based development) Парадигма управления и разработки, отдающая предпочтение использованию существующих компонентов, а не разработке компонентов на заказ.
Комплект внедрения (deployment set) Рабочие продукты, представленные в виде кода на машинном языке и связанных с ним файлов.
Комплект проектирования (design set) Рабочие продукты, представленные в виде моделей области решений.
Комплект реализации (implementation set) Рабочие продукты, представленные в виде программ на языке программирования высокого уровня и соответствующих исходных файлов.
Комплект требований (requirements set) Рабочие продукты, представленные в виде организованного текста и модели проблемной области.
Комплект управления (management set) Рабочие продукты, содержащие планы проекта, описание промежуточных состояний и выполненной ранее работы.
Контрольная точка архитектуры жизненного цикла (life-cycle architecture milestone) Анализ, проводимый в конце стадии уточнения с целью демонстрации выполняемой архитектуры всем заинтересованным сторонам и достижения согласия по детальному плану стадии конструирования.
Контрольная точка версии продукта (product releas^ milestone) Анализ, проводимый в конце стадии ввода в действие с целью оценки законченности ПО и, при необходимости, его передачи организации, осуществляющей сопровождение.
Контрольная точка начальной готовности к эксплуатации (initial operational capability milestone) Анализ, проводимый в конце стадии конструирования с целью оценки готовности ПО к вводу в действие у заказчика или пользователя и утверждения решения о начале квалификационного тестирования системы.
Контрольная точка целей жизненного цикла (life-cycle objectives milestone) Анализ, проводимый в конце начальной стадии с целью представления всем заинтересованным сторонам рекомендаций относительно проведения разработки. Включает в себя план, оценку стоимости и сроков, а также ожидаемую прибыль и экономию средств.
Конфигурация, базовая (configuration baseline) Поименованная совокупность программных компонентов и сопроводительной документации, которая является объектом управления изменениями и обновляется, сопровождается, тестируется, оценивается и устаревает как единое целое.
Конфигурируемый процесс (configurable process) Схема жизненного цикла, применимая для широкого спектра приложений.
Коэффициент дефектности (modularity) Зависимость среднего количества дефектов от времени.
Кривая затрат (expenditure profile) Зависимость затрат от времени.
«Круговая» разработка (round-trip engineering) Поддержка среды, необходимая для автоматизации и синхронизации рабочей информации в различных форматах (например, спецификации требований, проектные модели, исходный код, выполняемый код, варианты тестирования).
Модель требований (requirements model) Нотации для описания требований (например, UML) на различных уровнях абстракции для представления объектов и компонентов проблемной области, их атрибутов, статических связей, динамических взаимодействий и т.п.
Нотация, основанная на моделях (model-based notation) Семантически насыщенные графические и текстовые проектные нотации (например, UML).
Объективный контроль качества (objective quality control) Оценка процесса и всех промежуточных продуктов на протяжении жизненного цикла с использованием результатов четко определенных измерений, которые получаются непосредственно из рабочих продуктов и распространяются по всем видам деятельности и проектным командам.
Общая концепция (vision statement) Общее представление разрабатываемого продукта в виде, понятном всем заинтересованным сторонам.
Описание архитектуры ПО (software architecture description) Представления проектной модели, которые содержат информацию о структуре и поведении системы, достаточную для определения количества и спецификации ее составных частей, трудозатрат и других прямых затрат.
Описание версии (release description) Рабочий продукт, содержащий описание основных результатов версии.
Организационная политика (organizational policy) Рабочий продукт, определяющий элементы жизненного цикла и процесса: основные контрольные точки, промежуточные рабочие продукты, репозитории разработки, метрики, а также роли и распределение обязанностей.
Основная контрольная точка (major milestone) Событие масштаба системы, наступающее в конце каждой из стадий разработки и позволяющее ясно осознать проблемы системы в целом, синхронизировать процессы управления и разработки, а также подтвердить, что цели, стоявшие перед данной стадией, достигнуты.
Ответственный за проверку проекта (Project Review Authority, PRA) Лицо, персонально ответственное за то, чтобы проект по созданию ПО подчинялся всем организационным и экономическим правилам, практике и стандартам, касающимся ПО.
Ответственный за процесс разработки ПО (Software Engineering Process Authority, SEPA) Отдельное лицо или группа лиц, ответственная за сопровождение процесса, используемого в данной организации, и за облегчение процесса обмена информацией и руководствами между участниками проекта.
Ответственный за среду разработки ПО (Software Engineering Environment Authority, SEEA) Отдельное лицо или группа лиц, ответственная за автоматизацию процесса, сопровождение стандартной среды, обучение пользованию средой и сопровождение в организации наработок, пригодных для повторного использования.
Оценка, рабочий процесс (assessmentworkflow) Вид деятельности, связанный с оценкой тенденций изменения качества процесса и продукта.
Оценка состояния (status assessment) Периодические мероприятия, обеспечивающие руководство частой и регулярной информацией относительно достигнутого прогресса.
План разработки ПО (software development plan) Вариант процесса, специфический для данного проекта.
Проверка (inspection) Анализ рабочих продуктов, выполняемый людьми.
Прогресс (progress) Объем работы, завершенной за некоторое время.
Продукт (product) Подмножество рабочих продуктов внедрения, передаваемое конечным пользователям.
Проектирование, рабочий процесс (design workflow) Деятельность, связанная с построением модели области решения, созданием архитектуры и рабочих продуктов проектирования.
Проектная модель (design model) Проектные нотации (например, UML) на различных уровнях абстракции для представления объектов и компонентов области решения, их атрибутов, статических связей, динамических взаимодействий и т.п.
Промежуточная контрольная точка (minor milestone) Событие уровня одной итерации, при котором выполняется подробный анализ содержания текущей итерации и утверждается решение о продолжении работ.
Прототип (prototype) Версия, которая необязательно является объектом управления изменениями и контроля конфигурации.
Работа (work) Усилия, которые необходимо приложить для выполнения определенного множества заданий.
Рабочий продукт (artifact) Дискретная связная совокупность информации, обычно разрабатываемая и рассматриваемая как единое целое.
Рабочий процесс (workflow) Поток тесно связанных и выполняемых последовательно видов деятельности.
Рабочие продукты внедрения (deployment artifacts) Проектные документы, необходимые для ввода программного продукта в эксплуатацию (например, руководство по эксплуатации компьютерной системы, руководство по установке ПО, планы и процедуры перехода в новую среду эксплуатации, инфраструктура вычислительной системы).
Реализация, рабочий процесс (implementation workflow) Деятельность, связанная с программированием компонентов и с развитием комплектов рабочих продуктов реализации и внедрения.
Риск (risk) Текущая или предварительно выявленная проблема, которая с высокой степенью вероятности может оказать неблагоприятное влияние на достижение основных контрольных точек.
Руководство пользователя (user manual) Справочная документация, необходимая для сопровождения поставляемого ПО.
Совет по контролю за конфигурацией (Configuration Control Board) Группа лиц, которая выступает в роли органа, принимающего решения по вопросам, касающимся содержимого базовой конфигурации.
Современный процесс (modern process) Процесс итерационной разработки ПО, в котором выполняется упреждающая разработка архитектуры, затем производится пошаговая реализация функциональных возможностей до получения окончательной версии продукта.
Спецификация версии (release specification) Рабочий продукт, содержащий область действия, план и цели версии.
Среда (environment) Автоматизация процесса, направленная на изготовление рабочих продуктов жизненного цикла. Должна включать в себя управление требованиями, визуальное моделирование, автоматизацию создания документации, средства программирования, автоматизированное регрессионное тестирование, а также управление изменениями и отслеживание дефектов.
Среда, рабочий процесс (environment workflow) Деятельность, связанная с автоматизацией производства рабочих продуктов жизненного цикла и с развитием среды сопровождения.
Среда для создания прототипов (prototyping environment) «Испытательный стенд» для создания прототипов архитектуры проекта с целью оценки соглашений, достигнутых на начальной стадии и стадии уточнения жизненного цикла.
Среда разработки (development environment) Полный набор инструментов разработки, необходимых для поддержки различных рабочих процессов и «круговой» разработки.
Среда сопровождения (maintenance environment) Развитая версия среды разработки.
Среднее время наработки на отказ (mean time between failures, MTBF).
Среднее время работы системы между двумя сбоями типа 0 (критическими).
Стабильность (stability) Отношение числа открытых запросов на внесение изменений к числу закрытых запросов.
Стадия (этап) (stage) Часть жизненного цикла ПО, обладающая относительно однородной экономической моделью.
Стадия (фаза) (phase) Промежуток времени между двумя основными контрольными точками процесса, 8 течение которого достигается четко сформулированный набор целей, завершается создание определенных рабочих продуктов и принимается решение относительно перехода к следующей стадии.
Стадия ввода в действие (transition phase) Четвертая стадия жизненного цикла, в которой основное внимание уделяется процессу передачи продукта пользователям.
Стадия, начальная (inception phase) Первая стадия жизненного цикла, в которой основное внимание уделяется начальной концепции продукта и соответствующему бизнес-плану.
Стадия конструирования (construction phase) Третья стадия жизненного цикла, в которой основное внимание уделяется созданию полезного продукта, достаточно завершенного для ввода в действие у пользователей.
Стадия производства (production stage) Деятельность, которая осуществляется на последних этапах жизненного цикла и направлена на создание пригодных к использованию версий ПО в контексте базовых планов, требований и архитектуры, созданных на стадии разработки; в современном процессе должна быть связана с понятием экономии при больших масштабах.
Стадия разработки (engineering stage) Деятельность, которая осуществляется на ранних этапах жизненного цикла и объединяет планы, требования и архитектуру, разрешая, таким образом, риски, присущие разработке; обычно связана с понятием платы за масштаб.
Стадия сопровождения (maintenance stage) Развитие программного продукта после завершения жизненного цикла первоначальной разработки.
Стадия уточнения (elaboration phase) Вторая стадия жизненного цикла, в которой основное внимание уделяется созданию базовой архитектуры, согласованной с планом выпуска продукта и с требованиями.
Тип 0 запроса на внесение изменений (type 0 software change order).
Критические сбои или фатальные проблемы ПО, непосредственно влияющие на возможность использования ПО по основному назначению.
Тип 1 запроса на внесение изменений (type 1 software change order).
Ошибка или дефект, который либо не оказывает влияния на возможность использования ПО, либо может быть исправлен.
Тип 2 запроса на внесение изменений (type 2 software change order).
Изменение, которое скорее может рассматриваться как улучшение, нежели попытка исправления дефекта.
Тип 3 запроса на внесение изменений (type 3 software change order).
Изменение, вызванное сменой требований.
Традиционный процесс (conventional process) «Водопадный» процесс создания ПО, при котором происходит последовательный переход от анализа требований к проектированию, кодированию, тестированию модулей, интеграционному тестированию и верификации системы.
Требования, рабочий процесс (requirements workflow) Деятельность, связанная с анализом проблемной области и с созданием рабочих продуктов требований.
Управление, рабочий процесс (management workflow) Деятельность, связанная с планированием и контролем процессов жизненного цикла, а также с созданием условий для достижения успеха всеми заинтересованными сторонами.
Управление изменениями (change management) Отслеживание изменений в технических рабочих продуктах с целью контроля и понимания реального технического прогресса и тенденций изменения качества в процессе формирования приемлемого конечного продукта или промежуточной версии.
Упреждающая разработка архитектуры (architecture first) Подход, требующий достижения баланса между ведущими требованиями, архитектурно значимыми проектными решениями и планированием жизненного цикла прежде, чем будут выделены ресурсы на полномасштабную разработку.