Словарь терминов

Словарь терминов

С-требования (C-requirements) — требования, зафиксированные в форме, наиболее удобной с точки зрения заказчика приложения, участвующие также в формировании требований для разработчиков.
D-требования (D-requirements) — требования разработчика. Требования, изложенные в той форме, которая наиболее удобна для того, чтобы разработчики могли от них отталкиваться. Также используются при формировании требований заказчика.
Автоматизированная разработка программ (Computer-aided software engineering, CASE) — процесс разработки программного обеспечения с применением согласованного набора средств разработки. Эти средства строго соответствуют различным фазам процесса разработки.
Автоматизированное проектирование / автоматизированное производство, САПР / АСУ ТП (Computer aided design / Computer aided manufacturing, CAD/ CAM) — графические приложения, применяемые в проектировании и производстве электроники, строительных конструкций, машин и механизмов.
Альфа-версия (alpha release) — предварительная версия приложения, передаваемая особо доверенным представителям заказчика и (или) внутренним пользователям с целью обеспечения обратной связи.
Анализ требований (requirements analysis) — процесс получения законченного письменного утверждения, которое определяет, какими должны быть функциональность, внешний вид, производительность и поведение приложения.
Артефакт (artifact) — данные, исходный код или информация любого типа, которые сотрудник получает или использует в процессе разработки. В частности, используются в описании USDP.
Архитектура программного обеспечения (software architecture) — всеобъемлющий проект приложения, включающий в том числе и его структурную декомпозицию.
Ассоциация вычислительной техники (Association for Computing Machinery, ACM) — профессональная ассоциация предприятий, ведущих деятельность в сфере компьютерных технологий, в частности занимающихся программным обеспечением.
Атрибут (attribute) — переменная класса в целом (в отличие от переменной внутри метода).
Аудит физической конфигурации (physical configuration audit, РСА) — систематическая проверка имеющихся в распоряжении физических артефактов проекта, таких как документация, исходный код, файлы, магнитные ленты и диски.
Бета-версия (beta release) — предварительная версия приложения, передаваемая избранным представителям заказчика с целью выявления дефектов и обеспечения обратной связи.
Быстрая разработка приложения (Rapid application development, RAD) — процесс ускоренной разработки приложения или его части. Ради сокращения времени разработки, как правило, жертвуют документацией, проектированием и расширяемостью приложения.
Валидация (validation) — процесс, заключающийся в проверке того, что приложение выполняет свои функции именно так, как было задумано.
Вариант использования (use case) — последовательность действий, выполняемых как приложением, так и пользователем, типичная для данного приложения. При этом пользователю назначается некоторая роль, и применительно к этому варианту использования его называют действующим лицом (актером).
Верификация (verification) — процесс проверки того, что приложение строится в строгом соответствии с тем, как это запланировано.
Водопадный тип процесса разработки (waterfall) — процесс разработки программного обеспечения, состоящий из следующих фаз: сбор требований, проектирование, реализация в коде и тестирование. Все фазы выполняются последовательно, возможно лишь небольшое наложение соседних фаз.
Встреча (Encounter) — учебный пример видеоигры, изучаемый в этой книге.
Графический интерфейс пользователя (graphical user interface, GUI) — графический экран (часто интерактивный), посредством которого пользователь взаимодействует с приложением.
Действующее лицо (actor) — индивидуальная роль, присваиваемая пользователю приложения применительно к варианту использования.
Диаграмма последовательности (sequence diagram) — диаграмма, на которой изображены объекты приложения, отображающая последовательность обращений к функциям объектов. Обычно с помощью диаграмм последовательности уточняют варианты использования.
Диаграмма потоков данных (Data flow diagram, DFD) — диаграмма, отражающая потоки данных в направлении к приложению, внутри приложения и за его пределами. Данные перемещаются между пользователями приложения, хранилищами данных и элементами внутренней обработки в приложении.
Доказуемо корректная программа (provably correct program) — программа, написанная таким образом, что мы можем привлечь математический или логический аппарат для доказательства того, что она удовлетворяет предъявленным требованиям.
Документация по тестированию программного обеспечения (Software test documentation, STD) — документ, регламентирующий тестирование приложения во всех его аспектах.
Единица функционального размера (function point, FP) — мера сложности приложения.
Заинтересованные лица (stakeholders) — все те, кто так или иначе заинтересован в реализации проекта: заказчики и пользователи (которые сами могут и не являться заказчиками), а также инвесторы, пользовательские группы и сами разработчики.
Запрос на сопровождение (maintenance request, MR) — запрос на модификацию или расширение возможностей существующего приложения.
Инкрементальный тип процесса разработки (incremental) — процесс разработки программного обеспечения, в котором число итераций так велико, что каждая следующая итерация предоставляет слишком мало новых возможностей по сравнению с предыдущей.
Инспектирование (inspection) — проверка частей проекта, таких как требования, результаты проектирования, программный код, на наличие дефектов. Обычно инспектирование проводит группа коллег автора работы.
Инвариант (invariant) — утверждение, устанавливающее связь между переменными в определенном контексте, которое сохраняется неизменным, хотя значения этих переменных могут меняться.
Индивидуальная программная документация (Personal software documentation, PSD) — документация, поддерживаемая каждым разработчиком индивидуально, в которой отражается текущее состояние его части кода.
Индивидуальный процесс разработки программного обеспечения (Personal Software Process, PSP) — процесс, разработанный Хэмфри (Институт разработки программного обеспечения) с целью оценки и улучшения производительности отдельно взятого разработчика программного обеспечения.
Институт инженеров по электротехнике и радиоэлектронике (Institute of Electrical, and Electronics Engineers, IEEE) — профессиональная организация, в центре внимания которой лежат разработки в области электроники, электротехники и программного обеспечения.
Институт технологий разработки программного обеспечения (Software Engineering Institute, SEI) — институт, созданный с целью обеспечить качество программного обеспечения, разрабатываемого для вооруженных сил США. Его достижения нашли применение в многочисленных организациях, не имеющих отношения к оборонной промышленности.
Интегральное тестирование (integration testing) — процесс тестирования, в ходе которого проверяется, насколько успешно объединены модули.
Интеграция (integration) — слияние отдельных модулей в одном приложении.
Интерактивная среда разработки (interactive development environment, IDE) — программное приложение, облегчающее разработчику создание, редактирование, компиляцию и исполнение кода.
Интерфейс (interface) — под интерфейсом системы понимается спецификация набора ее функций. Эта спецификация содержит имена функций, а также типы параметров, возвращаемых значений и исключений.
Интерфейс прикладного программирования (Application Programming Interface, API) — набор классов и прототипов член-функций, полезных для программистов. Содержит такие данные о функции, как ее имя, типы параметров, типы возвращаемых значений и генерируемые исключения.
Исполнимые строки исходного кода (non-comment lines of source code, NCSLOC) — число строк программного кода без учета комментариев.
Итерация (iteration) — повторяющийся процесс добавления требований, проектирования, разработки и тестирования с целью получения очередной сборки приложения.
Каркас (framework) — набор обобщенных классов, формирующий базис для нескольких приложений. Классы каждого из этих приложений получены из классов каркаса путем агрегации или наследования.
Командный процесс разработки программного обеспечения (Team Software Process, TSP) — процесс, разработанный Хэмфри (Институт разработки программного обеспечения) с целью оценки и улучшения производительности команд разработчиков.
Консорциум по технологии манипулирования объектами (Object Management Group, OMG) — некоммерческая ассоциация компаний, выпускающая стандарты в области распределенных вычислений.
Конструктивная модель стоимости (Constructive Cost Model, СОСОМО) — формулы Боэма, позволяющие на основе оценки количества строк кода рассчитать предположительный объем трудозатрат (в человеко-часах), необходимый для построения приложения, и длительность проекта.
Контроль качества (quality assurance, QA) — процесс, с помощью которого можно обеспечить достижение заявленного уровня качества во время проектирования. Чаще используется для обозначения организации, выполняющей эту функцию.
Критический обзор проектных решений (critical design review, CDR) — процесс, в ходе которого принимается окончательное решение о том, приступать ли к предлагаемому проектированию.
Метод «белого ящика» (white box process) — метод (обычно метод тестирования), применяемый к реализации, который учитывает способ обработки данных, используемый в исследуемом коде.
Метод «черного ящика» (black box method) — метод (обычно метод тестирования), применяемый к реализации, который базируется только на входных и выходных данных (то есть не принимает в расчет способ обработки данных, используемый в исследуемом коде).
Метрика (metric) — количественная мера артефакта программного обеспечения. Например, число строк кода — это метрика исходного кода.
Модель (model) — модель приложения — это представление его проекта в определенном аспекте, таком как, например, множество его классов или поведение, управляемое событиями.
Модель зрелости возможностей (Capability Maturity Model, СММ) — системный метод, позволяющий оценить потенциал организации в целом относительно разработки программного обеспечения. Создан в Институте разработки программного обеспечения (Питтсбург).
Модульное (или компонентное) тестирование (unit testing) — тестирование части приложения в изоляции от остальных его частей.
Независимая экспертиза (independent verification and validation, IV&V) — процесс верификации и валидации, осуществляемый третьими лицами (то есть не организацией-разработчиком).
Нефункциональное требование (non-functional requirement) — требование, которое предъявляется к приложению, но никак не влияет на его функциональность. Примером может служить ограничение на объем памяти.
Образец проектирования (design pattern) — образец часто используемых классов, отношений между ними и сопутствующих им алгоритмов.
Обратное проектирование (reverse engineering) — построение содержимого фазы процесса разработки из артефактов последующей фазы, например получение модели из кода программы.
Общая архитектура посредника запросов к объектам (Common object request broker architecture, CORBA) — стандарт, в рамках которого приложения имеют возможность вызывать функции, размещенные на удаленных платформах, независимо от языка их реализации.
Объектно-ориентированный подход (object-oriented, 00) — организация проекта и кода по классам и экземплярам (объектам). Каждый объект класса обеспечен набором функций, определенных для этого класса, и каждый объект имеет копию определенного для этого класса набора переменных.
Обратное требование (inverse requirement) — спецификация требований, которые определяют, чего приложение не будет делать.
Оценка возможностей (capability assessment) — процесс, при помощи которого получают объективную количественную оценку возможностей организации, группы или отдельного разработчика.
Переход (в диаграмме переходов состояний) (transition) — процесс, в ходе которого объект меняет состояние с одного на другое.
План тестирования программного обеспечения (Software test plan, STP) — в этом документе указывается, какие части приложения должны быть протестированы, и приводится график тестирования.
План управления конфигурациями программного обеспечения (Software configuration management plan, SCMP) — документ, в котором устанавливается порядок управления кодом и документацией проекта, а также всех его версий.
План управления программным проектом (Software project management plan, SPMP) — план, определяющий, кто и в каком порядке какие части проекта будет разрабатывать.
Предварительный обзор проектных решений (preliminary design review, PDR) — совещание с участием разработчиков и менеджеров, на котором выносится на обсуждение эскизный проект (в целом или его часть).
Пригодный к прослеживанию (traceable) — требование является прослеживаемым, если фрагменты проекта и программного кода, в которых оно реализуется, могут быть легко индентифицированы. Требование не является прослеживаемым, если не ясно, какие элементы проекта выражают его и в какой части кода оно реализовано.
Пригодный к тестированию (testable) — артефакт, например требование, для которого имеется возможность написать детальный тест, проверяющий соответствие между продуктом и артефактом.
Прототип (prototype) — приложение, на котором можно проиллюстрировать или продемонстрировать некоторые аспекты разрабатываемого приложения.
Процесс (process) — программный процесс — это последовательность действий, из которых складывается разработка.
Псевдокод (pseudocode) — язык, подобный языку человеческого общения, и вместе с тем достаточно формальный для того, чтобы на нем было можно описывать алгоритмы.
Рабочая папка проекта (Software development folder, SDF) — документ, фиксирующий текущее состояние кода, над которым работает отдельный разработчик. В нем содержатся подробные результаты модульного тестирования, выполненного этим разработчиком на данный момент.
Регрессионное тестирование (regression testing) — процесс проверки того факта, что добавление кода в приложение, находящееся в разработке, не ухудшит тех возможностей, которыми оно на данный момент обладает.
Реинжиниринг бизнес-процесса (business process reengineering, BPR) — системный проект бизнес-процесса, например процесса управления закупками, от начальной стадии до завершения, включающий человеческие и другие аспекты. Обычно выполняется «с нуля».
Ролевая игра (role-playing game, RPG) — игра, в которой взаимодействие игроков осуществляется на основе распределенных между ними ролей.
Сборка (build) — частичная реализация приложения.
Система управления базами данных, СУБД (data base management system,.
DBMS) — система, управляющая организацией данных и доступом к ним.
Системная разработка (system engineering) — процесс анализа и разработки системы в целом, включая как аппаратное, так и программное обеспечение.
Системное тестирование (system testing) — тестирование приложения в целом.
Служба помощи (Help desk) — средство обеспечения помощи пользователям приложения.
Событие (event) — внешнее по отношению к объекту явление, оказывающее на него влияние.
Совет по контролю изменений (Change control board, ССВ) — группа, принимающая решения о целесообразности реализации тех или иных расширений или изменений в приложении.
Сопровождение (maintenance) — процесс изменения приложения после поставки с целью исправления ошибок, повышения производительности или для адаптации к изменившимся условиям.
Состояние (state) — статус объекта. Формально определяется через набор значений переменных объекта. Например, можно сказать, что объект Автомобиль находится в состоянии Раритетный, если год его выпуска не больше 1955 и переменная, отвечающая за его внешний вид, имеет значение не хуже, чем удовлетворительный.
Спецификация требований к программному обеспечению (Software requirements specification, SRS) — в этом документе определяется, что должно делать приложение.
Спиральный тип процесса разработки (spiral) — процесс разработки программного обеспечения, суть которого заключается в том, что на каждой итерации строится очередная версия приложения на основе ее предыдущей версии.
Среднее время наработки на отказ (mean time between failures, MTBF) —.
вычисляется как отношение срока эксплуатации приложения к числу уникальных отказов, обнаруженных за это время. Для этого необходимо сформулировать понятие «отказ».
Средний период ошибки (mean-time-to-failure, MTTF) — измеряется путем запоминания промежутков времени между всеми парами замеченных последовательных ошибок и их усреднения.
Схема (roadmap) — список действий, приводящий к достижению поставленной цели.
Унаследованное приложение (legacy application) — приложение, которое уже поставляется заказчику и находится в эксплуатации.
Унифицированный процесс разработки программного обеспечения (Unified Software Development Process, USDP) — процесс разработки, созданный Якобсоном, Бучем и Рамбо, в котором основное внимание уделяется вариантам использования.
Унифицированный язык моделирования (Unified modeling language, UML) —.
графическая нотация, используемая для описания объектно-ориентированного проектирования.
Управление конфигурациями (configuration management, CM) — процесс, регламентирующий управление версиями различных артефактов программного проекта, а также их сопровождение.
Управление проектом (project management) — процесс исполнения обязанностей с целью успешного завершения проекта.
Устранение риска (risk retirement) — процесс ликвидации факторов, угрожающих успешному исполнению проекта. Можно или найти способ избежать риска, или принять меры по снижению его влияния на проект.
Формальные методы (formal methods) — строгие методы спецификации требований, проекта или реализации, базирующиеся на законах математики или логики.
Функциональное требование (functional requirement) — требование, выражающее одну из функций, которые должно выполнять приложение.
Элемент конфигурации (configuration item, CI) — артефакт, версии которого тщательно отслеживаются от начальной стадии проекта до его завершения.