commit - 0f568d073ef5dd305ae624595c9691a0ada6fabd
commit + ac26fd08856eb09fe1babd88852586d46886c009
blob - d064c732c739615c9a4d403d24a6d010c3c8956c
blob + b21b56a9c8eefffa0a0c13212009f3af5bd76303
--- 10_software_quality.md
+++ 10_software_quality.md
и т.п.). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем
обслуживания в рамках заданного SLA – Service Level Agreement, давно уже
принятого на вооружение в телекоммуникационной индустрии. Таким образом,
-приемлемое качество может рассматриваться как <количественно выраженный>
+приемлемое качество может рассматриваться как количественно выраженный
компромисс между заказчиком и исполнителем в отношении характеристик продукта,
-создаваемого исполнителем в интересах <решения задач> заказчика с учетом других
+создаваемого исполнителем в интересах решения задач заказчика с учетом других
ограничений проекта (в частности, стоимостью, что часто именуется как “cost of
quality” – “стоимость качества”). Можно сказать, что такой взгляд может в
какой-то степени рассматриваться как расширение определения ISO 9001 с учетом
отношении характеристик качества.
Данная глава (область знаний) рассматривает вопросы качества программного
-обеспечения, выходя за рамки <отдельных> процессов жизненного цикла. Качество
+обеспечения, выходя за рамки отдельных процессов жизненного цикла. Качество
программного обеспечения является постоянным объектом заботы программной
инженерии и обсуждается во многих областях знаний (что вполне обосновано, если
учесть поистине катастрофический уровень проваленных проектов и
Согласие, достигнутое по требованиям к качеству (в оригинале - quality
requirements), наравне с четким доведением до инженеров того, что составляет
-качество <получаемого продукта>, требуют обсуждения и формального определения
+качество получаемого продукта, требуют обсуждения и формального определения
многих аспектов качества.
Инженеры должны понимать смысл, вкладываемый в концепцию качества,
Важной идеей является то, что программные требования определяют требуемые
характеристики качества программного обеспечения, а также влияют на методы
количественной оценки и сформулированные для оценки этих характеристик
-<соответствующие> критерии приемки.
+соответствующие критерии приемки.
### Культура и этика программной инженерии (Software Engineering Culture and Ethics)
Ожидается, что инженеры по программному обеспечению воспринимают вопросы
-качества программного обеспечения как часть своей <профессиональной> культуры.
+качества программного обеспечения как часть своей профессиональной культуры.
SWEBOK дает ссылки на источники, описывающие здоровую культуру программной
инженерии.
Этические аспекты могут играть значительную роль в обеспечении качества
-программного обеспечения, культуре и отношении инженеров <к своей работе>. IEEE
+программного обеспечения, культуре и отношении инженеров к своей работе. IEEE
Computer Society и ACM разработали кодекс этики (“моральный кодекс” – code of
ethics) и профессиональной практики, основанный на восьми принципах, помогающих
-инженерам укрепить их отношение к качеству и независимость <в решении вопросов
-обеспечения достойного качества создаваемых программных продуктов> в их
+инженерам укрепить их отношение к качеству и независимость в решении вопросов
+обеспечения достойного качества создаваемых программных продуктов в их
повседневной работе.
### Значение и стоимость качества (Value and Costs of Quality)
Понятие “качество”, на самом деле, не столь очевидно и просто, как это может
показаться на первый взгляд. Для любого инженерного продукта существует
-множество <интерпретаций> качества, в зависимости от конкретной “системы
+множество интерпретаций качества, в зависимости от конкретной “системы
координат” (в оригинале – “перспективы”). Множество этих точек зрения
необходимо обсудить и определить на этапе выработки требований к программному
продукту. Характеристики качества могут требоваться в той или иной степени,
обеспечение качества, как достижение совершенства).
Стоимость качества (cost of quality) может быть дифференцирована на стоимость
-предупреждения <дефектов> (prevention cost), стоимость оценки (appraisal cost),
+предупреждения дефектов (prevention cost), стоимость оценки (appraisal cost),
стоимость внутренних (internal failure cost), а также внешних сбоев (external
failure cost).
такого рода решений должно приниматься процессе работы с требованиями (см.
область знаний SWEBOK “Программные требования”), однако эти вопросы могут (и
должны) подниматься на протяжении всего жизненного цикла программного
-обеспечения. Не существует каких-то <“стандартных”> правил того, как именно
+обеспечения. Не существует каких-то “стандартных” правил того, как именно
необходимо принимать такие решения. Однако, инженеры должны быть способны
представить различные альтернативы (в достижении различного уровня качества) и
их стоимость. Здесь SWEBOK приводит некоторые источники, в которых более
В различных источниках (таксономиях и моделях) терминология характеристик
качества программного обеспечения отличается. Каждая модель включает различное
-число уровней иерархии и общее число <”распознанных”> характеристик качества.
+число уровней иерархии и общее число ”распознанных” характеристик качества.
Различные авторы создали разные модели качества со своим набором характеристик
и атрибутов (в частности, Барри Боэм, автор спиральной модели жизненного цикла
разработки программного обеспечения, которая рассматривается в отдельной
продуктов и получению всех необходимых данных. Кроме этого, разрабатываемая
программа совершенствования (improvement program, обычно является целевой и
охватывает работу подразделения или организации, в целом) детально
-идентифицирует все действия и проекты по улучшению <отдельных аспектов
-деятельности> в рамках определенного периода времени, за который такие проекты
+идентифицирует все действия и проекты по улучшению отдельных аспектов
+деятельности в рамках определенного периода времени, за который такие проекты
можно осуществить с успешным решением соответствующих задач. При этом,
поддержка менеджмента означает, что все проекты по улучшению обладают
достаточными ресурсами для достижением поставленных целей. Поддержка
полученной практики и уже произведенные продукты. Однако, они играют главную
роль на стадии планирования, являясь проактивными как процессы и процедуры,
необходимые для достижения характеристик и уровня качества, востребованных
-заинтересованными лицами <проекта> программного обеспечения.
+заинтересованными лицами проекта программного обеспечения.
Управление рисками также может играть значительную роль для выпуска
качественного программного обеспечения. Включение “регулярного” (как постоянно
действующего, а не периодического; в оригинале – disciplined) анализа рисков и
-<соответствующих> техник управления <рисками> в процессы жизненного цикла
+соответствующих техник управления рисками в процессы жизненного цикла
программного обеспечения может увеличить потенциал для производства
качественного продукта. Более подробную информацию по управлению рисками можно
найти в области знаний “Управление программной инженерией”.
Процессы SQA обеспечивают подтверждение того, что программные продукты и
процессы жизненного цикла проекта соответствуют заданным требованиям. Такое
-подтверждение проводится на основе планирования (planning), постановки <работ>
+подтверждение проводится на основе планирования (planning), постановки работ
(enacting) и исполнения (performing) набора действий, направленных на то, чтобы
качество стало неотъемлемой частью программного обеспечения (см. выше
определения качества). Такой взгляд подразумевает ясное и точное формулирование
проблемы, а также то, что определены и четко выражены (полны и однозначно
-интерпретируемы) требования к соответствующему <программному> решению. SQA
+интерпретируемы) требования к соответствующему программному решению. SQA
добивается обеспечения качества в процессе разработки и сопровождения за счет
-выполнения различных действий на всех этапах <жизненного цикла>, что позволяет
+выполнения различных действий на всех этапах жизненного цикла, что позволяет
идентифицировать проблемы еще на ранних стадиях, которые практически неизбежны
в любой сложной деятельности.
цели качества были четко определены и понимаемы (а также, однозначно
интерпретируемы, что является обязательным условием любых целей и
соответствующих требований). Это, в обязательном порядке, должно быть отражено
-в соответствующих планах управления <проектом>, разработки и сопровождения.
+в соответствующих планах управления проектом, разработки и сопровождения.
Подробности можно найти в стандарте IEEE 730-02 “IEEE Standard for Software
Quality Assurance Plans”.
проектов, а не SQA-плана), тренинги, а также формирование отчетности и
документации, относящиеся к вопросам SQA. Кроме того, SQA-план касается и
вопросов работ по обеспечению качества, относящихся к другим типам
-деятельности, описанным в <различных> планах по созданию программного
+деятельности, описанным в различных планах по созданию программного
обеспечения, к которым также относятся поставка, установка, обслуживание
(поддержка и сопровождение) заказных и/или тиражируемых/готовых программных
решений (commercial off-the-shelf, COTS), необходимых для данного проекта
программного обеспечения. Наконец, SQA-план может содержать необходимые для
обеспечения качества критерии приемки программного обеспечения и действия по
-формированию отчетности и управлению <и контролю над> работами.
+формированию отчетности и управлению и контролю над работами.
### Проверка (верификация) и аттестация (Verification and Validation, V&V)
-С целью краткости <изложения> (что, не мешало их детализировать достаточным
+С целью краткости изложения (что, не мешало их детализировать достаточным
образом, в виде соответствующих "подтем" в рамках формата SWEBOK, так как,
будучи тесно связанными и взаимодополняющими, проверка и аттестация все же
обладают и самостоятельным содержанием), проверка (верификация) и аттестация –
V&V напрямую адресуется вопросам качества программного обеспечения и использует
соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V
может применяться для промежуточных продуктов, однако, в том объеме, который
-соответствует промежуточным “шагам” <соответствующих> процессов жизненного
+соответствует промежуточным “шагам” соответствующих процессов жизненного
цикла.
Процесс V&V определяет в какой степени продукт (результат) тех или иных работ
Целью планирования V&V является обеспечение процессов верификации и аттестации
необходимыми ресурсами, четкое назначение ролей и обязанностей. Получаемый план
-V&V документирует и <детально> описывает различные ресурсы, роли и действия, а
+V&V документирует и детально описывает различные ресурсы, роли и действия, а
также используемые техники и инструменты. Понимание различных целей каждого
действия в рамках V&V может помочь в точном планировании техник и ресурсов
(включая, финансовые), необходимых для достижения заданных целей. Стандарты
#### Управленческие оценки (Management Reviews)
“Назначение управленческих оценок состоит в отслеживании развития
-<проекта/продукта>, определения статуса планов и расписаний, утверждения
+проекта/продукта, определения статуса планов и расписаний, утверждения
требования и распределения ресурсов, или оценки эффективности управленческих
подходов, используемых для достижения поставленных целей.” - IEEE 1028-97 “IEEE
Standard for Software Reviews”. Управленческие оценки поддерживают принятие
будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии),
V&V-отчетов, а также различных типов планов – управления рисками,
проекта/проектного управления, конфигурационного управления, безопасности
-<использования> программного обеспечения (safety), оценки рисков и т.п.
+использования программного обеспечения (safety), оценки рисков и т.п.
Информация, связанная с данными вопросами, также представлена в областях знаний
“Управление программной инженерией” и “Конфигурационное управление”.
- Списка проблем (вопросов), ассоциированных с продуктом
- Процедуры технической оценки
-Команда <технической оценки> следует заданной процедуре оценки.
+Команда технической оценки следует заданной процедуре оценки.
Квалифицированные (с технической точки зрения) лица представляют обзор продукта
-(представляя команду разработки). Исследование <продукта> проводится в течение
+(представляя команду разработки). Исследование продукта проводится в течение
одной и более встреч (между теми, кто представляет продукт и теми, кто провoдит
оценку). Техническая оценка завершается после того, как выполнены все
предписанные действия по исследованию продукта.
продукту, в целом, рассматривая в последнем случае только один его аспект,
например, интерфейсы. Любая найденная аномалия должна документироваться, а
информация передаваться лидеру инспекции. В процессе инспекции лидер руководит
-сессией <инспекции> и проверяет, что все <члены команды> подготовились к
+сессией инспекции и проверяет, что все члены команды подготовились к
инспектированию. Общим инструментом, используемым при инспектировании, является
проверочный лист (checklist), содержащий аномалии и вопросы, связанные с
-аспектами <программного продукта>, вызывающими интерес. Результирующий лист
+аспектами программного продукта, вызывающими интерес. Результирующий лист
часто классифицирует аномалии (см. стандарт IEEE 1044-93 “IEEE Standard for the
Classification of Software Anomalies”) и оценивается командой с точки зрения
его завершенности и точности. Решение о завершении инспекции принимается в
соответствии с одним (любым) из трех критериев:
-- Принятие <продукта> с отсутствием либо малой необходимостью переработки
-- Принятие <продукта> с проверкой переработанных фрагментов
+- Принятие продукта с отсутствием либо малой необходимостью переработки
+- Принятие продукта с проверкой переработанных фрагментов
- Необходимость повторной инспекции
- Инспекционные встречи занимают, обычно, несколько часов, в отличие от
технической оценки и аудита, предполагающих, в большинстве случаев, больший
(another auditor), регистратор (recorder) и инициатор (initiator). В аудите
принимает участие представитель оцениваемой организации/организационной
единицы. В результате аудита идентифицируются случаи несоответствия и
-формируется отчет, необходимый команде <разработки> для принятия корректирующих
+формируется отчет, необходимый команде разработки для принятия корректирующих
действий.
При том, что существуют различные формальные названия (и классификации) оценок
различные факторы, среди которых:
- Область применения системы, в которой будет работать программное обеспечение
-(критичное для безопасности <людей>), критичное для бизнеса и т.п.)
+(критичное для безопасности людей), критичное для бизнеса и т.п.)
- Системные и программные требования
- Какие компоненты используются в системе – коммерческие (внешние) или
стандартные (внутренние)
#### Гарантоспособность (Dependability)
-(Гарантоспособость – гарантия <высокой> надежности, защищенности от сбоев)
+(Гарантоспособость – гарантия высокой надежности, защищенности от сбоев)
В случаях, когда сбой системы может привести к крайне тяжелым последствиям
(такие системы иногда называют в англоязычных источниках “high confidence” или
“системы повышенной надежности”, “высокой доступности” и т.п.), общая
(совокупная) гарантоспособность системы (как сочетания аппаратной части,
программного обеспечения и человека) является главным и приоритетным
-требованием качества, по отношению к основной функциональности <системы>.
+требованием качества, по отношению к основной функциональности системы.
Гарантоспособность (dependability) программного обеспечения включает такие
характеристики, как защищенность от сбоев (fault-tolerance), безопасность
использования (safety – безопасность в контексте приемлемого риска для здоровья
опасностей (в контексте безопасности использования, safety) и анализа угроз (в
информационной безопасности, security). История сбоев аналогичных систем может
также помочь в идентификации наиболее полезных техник, направленных на
-обнаружение сбоев и <всесторонней> оценки качества программного обеспечения.
+обнаружение сбоев и всесторонней оценки качества программного обеспечения.
Уровни целостности (например, градации целостности) предлагаются, в частности,
стандартом IEEE 1012-98 “IEEE Standard for Software Reviews”.
выглядят следующим образом:
- Ошибка (error): “Отличие … между корректным результатом и вычисленным
-результатом < полученным с использованием программного обеспечения>”
+результатом полученным с использованием программного обеспечения”
- Недостаток (fault): “Некорректный шаг, процесс или определение данных в
компьютерной программе”
-- Сбой (failure): “<Некорректный> результат, полученный в результате
+- Сбой (failure): “Некорректный результат, полученный в результате
недостатка”
- Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее
к некорректному результату”
действия по удалению дефектов из исследуемого продукта. Однако, этим дело не
ограничивается. Есть и другие возможные действия, позволяющие получить полную
отдачу от результатов выполнения соответствующих SQM-работ. Среди них – анализ
-и подведение итогов (резюмирование) <по обнаруженным несоответствиям/дефектам>,
+и подведение итогов (резюмирование) по обнаруженным несоответствиям/дефектам,
использование техник количественной оценки (получение метрик) для улучшения
продукта и процесса, отслеживание дефектов и удаления их из системы (с
управленческим и техническим контролем проведения необходимых корректирующих
#### Статические техники (Static techniques)
-Статические техники предполагают <детальное> исследование (examination)
+Статические техники предполагают детальное исследование (examination)
проектной документации, программного обеспечения и другой информации о
программном продукте без его исполнения. Эти техники могут включать другие,
рассматриваемые ниже, действия по “коллективной” оценке (см. 3.3.2) или
относится различного рода листы проверки (checklists) и результаты
аналитических техник (рассматриваются ниже) и работ по тестированию. Данные
техники рассматриваются, например, в стандарте 12207 при обсуждении оценки
-(<joint> review) и аудита (audit). SWEBOK приводит и другие полезные источники,
+(review) и аудита (audit). SWEBOK приводит и другие полезные источники,
в которых можно найти дополнительную информацию по обсуждаемому вопросу.
#### Аналитические техники (Analytical techniques)
рода суждение является крайне консервативным и ограниченным. Особенно это
заметно в контексте широкого (и достаточно успешного) применения Agile-методик
и подходов, в которых individuals and interactions (см.первое положение The
-Agile Manifesto) предполагает <непосредственное> общение и постоянное
+Agile Manifesto) предполагает непосредственное общение и постоянное
взаимодействие членов команды (включая представителей заказчика – см. третье
положение Agile Manifesto - customer collaboration). В частности, Agile-взгляд
на SQM, вероятно, требует расширения вариантов форм оценки дополнительными
говоря, мало связано с формальными методами – это естественный путь достижения
приемлемого качества при минимизации затрат). Чаще всего они используются для
верификации особо важных частей критически-важных систем, например, конкретных
-требований <информационной> безопасности и надежности.
+требований информационной безопасности и надежности.
#### Динамические техники (Dynamic techniques)
роли человека в организации, он может принимать и применять одни и те же
техники по-разному.
-В зависимости от организации <ведения> проекта, определенные работы по
+В зависимости от организации ведения проекта, определенные работы по
тестированию могут выполняться при разработке программных систем в SQA и V&V
процессах. В силу того, что план SQM адресуется вопросам тестирования, данная
тема включает некоторые комментарии по тестированию. В свою очередь, область
#### Тестирование (Testing)
-Процессы подтверждения <качества>, описанные в SQA и V&V <планах>, исследуют и
+Процессы подтверждения качества, описанные в SQA и V&V планах, исследуют и
оценивают любой выходной продукт (включая промежуточный и конечный), связанный
со спецификацией требований к программному обеспечению, на предмет
трассируемости (traceability), согласованности (consistency),
полноты/завершенности (completeness), корректности (correctness) и
-непосредственно выполнения <требований> (performance). Такое подтверждение
+непосредственно выполнения требований (performance). Такое подтверждение
также охватывает любые выходные артефакты процессов разработки и сопровождения,
сбора, анализа и количественной оценки результатов. SQA-деятельность
обеспечивает гарантию того, что соответствующие (необходимые в заданном
контексте проекта) типы тестов спланированы, разработаны и реализованы, а V&V –
-разработку планов тестов, стратегий, сценариев и процедур <тестирования>.
+разработку планов тестов, стратегий, сценариев и процедур тестирования.
Вопросы тестирования детально обсуждаются в области знаний “Тестирование”. Два
типа тестирования следуют задачам, задаваемым SQA и V&V, потому как на них
Иногда, независимые V&V-организации могут требовать возможности мониторинга
процесса тестирования и, в определенных случаях, заверять (или, чаще,
-документировать/фиксировать) реальное выполнение <тестов> на предмет их
+документировать/фиксировать) реальное выполнение тестов на предмет их
проведения в соответствии с заданными процедурами. С другой стороны, может быть
сделано обращение к V&V может быть направлено на оценку и самого тестирования:
достаточности планов и процедур, соответствия и точности результатов.
проблемных аспектов и узких мест в процессах. Метрики являются инструментом
оценки качества своей работы самими инженерами – как в целях, определенных SQA,
так и с точки зрения более долгосрочного процесса совершенствования
-<достигаемого> качества.
+достигаемого качества.
С увеличением внутренней сложности, изощренности программного обеспечения,
вопросы качества выходят далеко за рамки констатации факта – работает или не
модели надежности и сравнение с образцами (эталонами, принятыми в качестве
примеров определенного уровня качества – benchmarks).
-Стоимость процесса SQM является одним из <проблемных> вопросов, который всегда
+Стоимость процесса SQM является одним из проблемных вопросов, который всегда
всплывает в процессе принятия решения о том, как будет организован проект
(проектные работы). Часто, используются общие (generic) модели стоимости,
основанные на определении того, когда именно дефект обнаружен и как много
Хотя, как количественные оценки (в данном случае речь идет о результатах
оценок, а не о процессе измерений) характеристик качества могут полезны сами по
себе (например, число неудовлетворенных требований и пропорция таких
-требований), могут <эффективно> применяться математические и графические
+требований), могут эффективно применяться математические и графические
техники, облегчающие интерпретацию значений метрик. Такие техники вполне
естественно классифицируются, например, следующим образом:
предоставляют “снимок” наиболее проблемных областей исследуемого программного
продукта (и, кстати, то же часто верно и в отношении процессов). Результирующие
графики и диаграммы визуально помогают лицам, принимающим решения, в
-определении аспектов, на которых необходимо сфокусировать ресурсы <проекта>.
+определении аспектов, на которых необходимо сфокусировать ресурсы проекта.
Результаты анализа тенденций могут демонстрировать, что нарушается расписание,
например, при тестировании; или что сбои определенных классов становятся все
более частыми до тех пор, пока не предпринимаются корректирующие действия в
рассматриваются аспекты анализа дефектов (defect analysis), количественной
оценки возникновения дефектов и последующего применения статистических методов
для формирования понимания наиболее часто встречающихся типов дефектов и
-отвечая на вопрос соответствующей оценки плотности дефектов <различных типов>.
+отвечая на вопрос соответствующей оценки плотности дефектов различных типов.
Они могут, также, помочь в понимании тенденций и оценке того, насколько хорошо
работают техники обнаружения дефектов и насколько успешно развиваются (как в
плане выполнения, так и в контексте совершенствования) процессы разработки и
сопровождения. Оценка покрытия тестами (test coverage) облегчает формирование
ожиданий в отношении оставшегося объема тестирования и предсказании возможного
-количества дефектов, которые будут еще обнаружены <до окончания процесса
-тестирования>. На основе этих методов количественной оценки могут быть
+количества дефектов, которые будут еще обнаружены до окончания процесса
+тестирования. На основе этих методов количественной оценки могут быть
сформированы, так называемые профили дефектов (defect profiles) для конкретных
прикладных областей (application domains). В дальнейшем, для будущих
программных систем в данной организации, такие профили могут направлять
blob - 50f296d2f36e35e97071af397c4ad79672eae31a
blob + b59eabc79ca26ddb193b1fe6ebdf1e99242f895b
--- 1_software_requirements.md
+++ 1_software_requirements.md
Вигерс, описывает feature как “множество логически связанных функциональных
требований, которые предоставляют определенные возможности для пользователя и
-удовлетворяют бизнес-целям <организации>”. С точки зрения маркетинга
-программного обеспечения, как отмечает Вигерс, feature это «группа требований,
+удовлетворяют бизнес-целям организации”. С точки зрения маркетинга
+программного обеспечения, как отмечает Вигерс, feature это «группа требований,
узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия
-решения по приобретению ПО – это список <отличительных особенностей или
-возможностей, характеристик>, присутствующий в описании продукта». В то же
+решения по приобретению ПО – это список отличительных особенностей или
+возможностей, характеристик, присутствующий в описании продукта». В то же
время, Леффингвелл и Видриг (D.Leffingwell, D. Widrig, Managing Software
Requirements: A Use Case Approach, Second Edition, 2003) определяют feature как
“сервисы, которые оказывает система для удовлетворения одной или более
В качестве примера можно привести реальное требование, присутствующее в
реальном проекте по электронному документообороту: “Система должна производить
-поиск документов <определенного вида> за время, не превышающее 5 секунд”. Это
+поиск документов определенного вида за время, не превышающее 5 секунд”. Это
типичное требование с количественной оценкой, в котором определена верхняя
граница диапазона времени, за которое должен быть осуществлен поиск документов.
Несомненно, этот атрибут качества системы существует в контексте определенного
Данное разделение базируется на определении “системы”,
данном INCOSE (International Council on Systems Engineering) “комбинация
-взаимодействующих элементов <созданная> для достижения определенных целей;
+взаимодействующих элементов созданная для достижения определенных целей;
может включать аппаратные средства, программное обеспечение, встроенное ПО,
другие средства, людей, информацию, техники (подходы), службы и другие
поддерживающие элементы”; таким образом, подразумевается, что система является
обладают “заказчиками” в понимании персонификации тех, кто “заказывает
разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в
идентификации потребностей и обращению к тем, кто может играть роль
-<квалифицированных> “представителей” потребителей;
+квалифицированных “представителей” потребителей;
- Регуляторы (Regulators): многие области применения (“домены”) являются
регулируемыми, например, телекоммуникации или банковский сектор. Программное
### Определение системы (System Definition Document)
Данный документ, часто называемый как “спецификация пользовательских
-требований” (user requirements specification) или “концепция” (concept <of
-operations>), описывает системные требования. Содержание документа определяет
+требований” (user requirements specification) или “концепция” (concept of
+operations), описывает системные требования. Содержание документа определяет
высокоуровневые требования, часто – стратегические цели, для достижения которых
создается программная система. Принципиальным моментом является то, что такой
документ описывает требования к системе с точки зрения области применения -
Engineering Process).
В дополнение к практическим соображениям, представленным в SWEBOK, на фоне
-общей тенденции разработки моделей <оценки> зрелости, стоит отметить, что
+общей тенденции разработки моделей оценки зрелости, стоит отметить, что
существуют определенные работы и по созданию различных моделей зрелости
требований. Например, наиболее популярная модель зрелости в индустрии
программного обеспечения – CMMI включает разный объем и содержание работ по
blob - bdc5ac227824cb28fb126dd188f87fc415273ec7
blob + ddc53a82070c25d983e0b8c26308aabea83517fb
--- 2_software_design.md
+++ 2_software_design.md
используемые представления и решения.
Например, архитектурный фреймворк – TOGAF [TOGAF, 2003], разработанный и
развиваемый консорциумом The Open Group (www.opengroup.org), предлагает
-следующие <возможные> цели (goals):
+следующие возможные цели (goals):
- Улучшение и повышение продуктивности бизнес-процессов
- Уменьшение затрат
- Повышение эффективности ИТ-организации
- Повышение продуктивности работы пользователей
- Повышение интероперабельности (возможности и прозрачности взаимодействия)
-- Уменьшение стоимости <поддержки> жизненного цикла
+- Уменьшение стоимости поддержки жизненного цикла
- Улучшение характеристик безопасности
- Повышение управляемости
Также известные как метрики. Могут быть использованы для количественной оценки
ожиданий в отношении различных аспектов конкретного дизайна, например, размера
-<проекта>, структуры (ее сложности) или качества (например, в контексте
+проекта, структуры (ее сложности) или качества (например, в контексте
требований, предъявляемых к производительности). Чаще всего, все метрики
разделяют по двум категориям:
компонентов, реализующих не функциональность, но обеспечивающих взаимосвязь
функциональных компонентов между собой и с “внешним миром”);
- *Диаграммы классов и объектов (Class and object diagrams)*: используются для
-представления набора классов и <статических> связей между ними (например,
+представления набора классов и статических связей между ними (например,
наследования);
- *Диаграммы компонентов или компонентные диаграммы (Component diagrams)*: в
определенной степени аналогичны диаграммам классов, однако, в силу специфики
концепции или понятия компонента[^2_2], обычно, представляются в другой
визуальной форме;
-- *Карточки <функциональной> ответственности и связей класса (Class
+- *Карточки функциональной ответственности и связей класса (Class
responsibility collaborator card, CRC)*: используются для обозначения имени
класса, его ответственности (то есть, что он должен делать) и других сущностей
(классов, компонентов, актёров/ролей и т.п.), с которыми он связан; часто их
[^2_2]: Здесь необходимо отметить различие в понятиях класса (или объекта) и
компонента: компонент рассматривается как физически реализуемый элемент
-программного обеспечения, несущий <в определенной степени> самодостаточную
+программного обеспечения, несущий в определенной степени самодостаточную
логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде
комплекса классов);
- *Диаграммы потоков данных (Data flow diagrams, DFD)*: описывают потоки данных
внутри набора процессов (не в терминах процессов операционной среды, но в
понимании обмена информацией в бизнес-контексте);
-- *Таблицы и диаграммы <принятия> решений (Decision tables and diagrams)*:
+- *Таблицы и диаграммы принятия решений (Decision tables and diagrams)*:
используются для представления сложных комбинаций условий и действий
(операций);
- *Блок-схемы и структурированные блок-схемы (Flowcharts and structured
мета-информации, например, с применением технологии отражения (reflection).
Хотя корни объектно-ориентированного проектирования лежат в абстракции данных
(к которым добавлены поведенческие характеристики), так называемый
-responsibility-driven design или проектирование на основе <функциональной>
+responsibility-driven design или проектирование на основе функциональной
ответственности по SWEBOK[^2_3] может рассматриваться как альтернатива
объектно-ориентированному проектированию.
blob - b4d02ad105bdcc99724e4fd1f7be67f28f2897dd
blob + 89a70dfc34a7e3b94a9527aa15b39278e4aa1364
--- 3_software_construction.md
+++ 3_software_construction.md
Стандарты, которые напрямую применяются при конструировании, включают:
- коммуникационные методы (например, стандарты форматов документов и
-<оформления> содержания)
+оформления содержания)
- языки программирования и соответствующие стили кодирования (например, Java
Language Specification, являющийся частью стандартной документации JDK – Java
Development Kit и Java Style Guide, предлагающий общий стиль кодирования для
Задачи, связанные с повторным использованием в процессе конструирования и
тестирования, включают:
-- выбор единиц (units), баз данных тестовых процедур, данных <полученных в
-результате> тестов и самих тестов, подлежащих повторному использованию
+- выбор единиц (units), баз данных тестовых процедур, данных полученных в
+результате тестов и самих тестов, подлежащих повторному использованию
- оценку потенциала повторного использования кода и тестов
- отслеживание информации и создание отчетности по повторному использованию в
новом коде, тестовых процедурах и данных, полученных в результате тестов.
blob - 56b654df2bded15cdd92b073a88083a3b6953188
blob + d2b3ccfd4e17c4819634f9275809f437eb2e49de
--- 4_software_testing.md
+++ 4_software_testing.md
### Техники, базирующиеся на спецификации (Specification-based techniques)
-#### Эквивалентное разделение <приложения> (Equivalence partitioning)
+#### Эквивалентное разделение приложения (Equivalence partitioning)
Рассматриваемая область приложения разделяется на коллекцию наборов или
эквивалентных классов, которые считаются эквивалентными с точки зрения
-рассматриваемых связей и характеристик <спецификации>. Репрезентативный набор
+рассматриваемых связей и характеристик спецификации. Репрезентативный набор
тестов (иногда – только один тест) формируется из тестов эквивалентных классов
(или наборов классов).
blob - 1b4ef61388db73757127a0b968341e287504c2e3
blob + d19ed2b21f88f0afb25ddba94886c69f2756dd26
--- 5_software_maintenance.md
+++ 5_software_maintenance.md
В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК)
позиционирует сопровождение как один из главных процессов жизненного цикла.
Этот стандарт описывает сопровождение как процесс модификации программного
-продукта в части его кода и документации для решения возникающих проблем <при
-эксплуатации> или реализации потребностей в улучшениях <тех или иных
-характеристик продукта>. Задача состоит в модификации продукта при условии
+продукта в части его кода и документации для решения возникающих проблем при
+эксплуатации или реализации потребностей в улучшениях тех или иных
+характеристик продукта. Задача состоит в модификации продукта при условии
сохранения его целостности. Международный стандарт ISO/IEC 14764 (Standard for
Software Engineering - Software Maintenance) определяет сопровождение
программного обеспечения в тех же терминах, что и стандарт 12207, придавая
коде.
Стандарт жизненного цикла 12207 также идентифицирует основные работы по
-сопровождению: реализация процесса <сопровождения>, анализ проблем и
+сопровождению: реализация процесса сопровождения, анализ проблем и
модификаций (изменений), реализаций модификаций, обзор (оценка)/принятие
-<решений> по сопровождению, миграция (с одной версии программного продукта на
+решений по сопровождению, миграция (с одной версии программного продукта на
другую, с одного продукта на другой) и вывод системы из эксплуатации. Эти
работы описываются далее в теме 3.2 “Работы по сопровождению” (Maintenance
Activities).
- устранение сбоев
- улучшение дизайна
-- реализация расширений <функциональных возможностей>
+- реализация расширений функциональных возможностей
- создание интерфейсов взаимодействия с другими (внешними) системами
- адаптация (например, портирование) для возможности работы на другой
аппаратной платформе (или обновленной платформе), применения новых системных
ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance)
классифицирует адаптивное и совершенствующее сопровождение как работы по
-расширению <функциональности> продукта. Этот стандарт также объединяет
+расширению функциональности продукта. Этот стандарт также объединяет
корректирующую и профилактическую деятельность в общую категорию работ по
корректировке системы. Профилактическое сопровождение (новейшая категория работ
по сопровождению) наиболее часто проводится для программных систем, связанных с
-вопросами безопасности <людей>.
+вопросами безопасности людей.
в том, что часто сложно найти время для необходимого тестирования. Не меньшей
проблемой является и координации в проведении тестов различными членами группы
сопровождения, занимающимеся решением различных задач. Если же система
-выполняет критичные <для бизнеса> функции, временный вывод системы из
+выполняет критичные для бизнеса функции, временный вывод системы из
эксплуатации (как говорят, перевод системы в offline) для выполнения тестов
часто оказывается просто невозможен.
необходимое расширение интеграционных возможностей), затрагиваемых модулях,
персоналом сопровождения будут проводиться стандартные процедуры. К таким
процедурам, наравне с журналированием запросов и проводимых работ, могут и,
-скорее, должны относиться: анализ влияния <изменений> (impact analysis – см.
+скорее, должны относиться: анализ влияния изменений (impact analysis – см.
ниже), оценка рисков, тестирование (различными методами, в различном объеме),
выпуск предварительных версий патчей/обновлений в ограниченное использование
(если это позволяет спецификация системы), использование “клона” системы
Работы по сопровождению в стандарте 14764 разбиты на задачи:
- Process Implementation – реализация процесса
-- Problem and Modification Analysis – анализ проблем и <необходимых>
+- Problem and Modification Analysis – анализ проблем и необходимых
модификаций
- Modification Implementation –проведение модификаций (реализация изменений)
-- Maintenance Review/Acceptance – оценка и принятие <проведенных работ> при
+- Maintenance Review/Acceptance – оценка и принятие проведенных работ при
сопровождении
- Migration – миграция (на модифицированную или новую версию программного
обеспечения)
и обновлять документацию по мере разработки и/или выпуска обновленных или новых
релизов продукта. Стандарт ISO/IEC 14764 рекомендует, чтобы персонал или
организации, отвечающие за сопровождение, в случае использования элементов
-процессов разработки в своей деятельности, адаптировали эти процессы <целиком>
+процессов разработки в своей деятельности, адаптировали эти процессы целиком
в соответствии со своими потребностями. В то же время, деятельность по
сопровождению обладает и определёнными уникальными чертами, что приводит к
необходимости использования специализированных процессов.
отчетов
- Достижения соглашения с пользователями о содержании (функциональности,
поведении и т.п.) последующих релизов/версий программного обеспечения
-- Идентификации потенциальных конфликтов и возможных альтернатив <реализации
-необходимых запросов>
-- Оценки рисков для <функционирования> текущего релиза и разработки плана
+- Идентификации потенциальных конфликтов и возможных альтернатив реализации
+необходимых запросов
+- Оценки рисков для функционирования текущего релиза и разработки плана
“отката” на немодифицированный (текущий, до внесения изменений, касающихся
рассматриваемого запроса) вариант системы, в случае возникновения проблем,
связанных с модификацией
Реинжиниринг определяется как детальная оценка (examination) и перестройка
программного обеспечения для формирования понимания, воссоздания (на уровне
-модели и, в ряде случаев, требований) и дальнейшей реализации его <функций> в
+модели и, в ряде случаев, требований) и дальнейшей реализации его функций в
новой форме (например, с использованием новых технологий и платформ, при
сохранении существующей и расширением и облегчением возможностей добавлений
новой функциональности). Отмечается, что в индустрии существуют различные
blob - 01eba18a1ccbc968cb8b2d354ce23219424b4946
blob + 3d700d32475a8c2fec2c54a984a91faaa60e4a82
--- 6_software_configuration_management.md
+++ 6_software_configuration_management.md
требованиями SQA (например, в IEEE 730-02 “Standard for Software Quality
Assurance Plans”).
-Работы по конфигурационному управлению <программного обеспечения> включают:
+Работы по конфигурационному управлению программного обеспечения включают:
управление и планирование SCM-процессов, идентификацию программных
конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также
управление выпуском (release management) и поставкой (delivery).
контекстом, в рамках которого проводится такая деятельность.
SCM может играть роль интерфейса к работам, направленным на обеспечение
-качества (quality assurance), вытекающим, например, из отслеживания записей <по
-изменениям> и несогласующихся элементов (например, выявленным в процессе сборки
-очередной версии системы, прим. автора). С точки зрения составителей <данной
-области знаний SWEBOK>, некоторые элементы, находящиеся под управлением SCM
-<процесса>, могут также служить объектами рассмотрения в рамках организационных
+качества (quality assurance), вытекающим, например, из отслеживания записей по
+изменениям и несогласующихся элементов (например, выявленным в процессе сборки
+очередной версии системы, прим. автора). С точки зрения составителей данной
+области знаний SWEBOK, некоторые элементы, находящиеся под управлением SCM
+процесса, могут также служить объектами рассмотрения в рамках организационных
программ по обеспечению качества. Управление несогласующемися элементами обычно
относится к работам по управлению качеством. Однако, SCM может обеспечить
существенную помощь в отслеживании (трассировке) и создании отчетности по
-элементам программных конфигураций, попадающих в такую <проблемную> категорию.
+элементам программных конфигураций, попадающих в такую проблемную категорию.
SWEBOK отмечает, что возможно тесное взаимодействие между организационными
структурами, отвечающими за разработку и сопровождение (и SCM играет роль
между заказчиком и поставщиком может содержать положения, затрагивающие процесс
конфигурационного управления. Например, может требоваться проведение
определенных процедур проверки (аудита) или специфицирован набор элементов
-(активов, артефактов), передаваемых под управление <процедур и системы>
+(активов, артефактов), передаваемых под управление процедур и системы
конфигурационного управления (или в части формализации обработки и контроля
реализации запросов на изменения, поступающих от заинтересованных лиц). Когда
разрабатываемый программный продукт потенциально затрагивает аспекты публичной
Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного
управления, как организационные вопросы, обязанности, ресурсы и расписание,
выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а
-также, контроль интерфейсов <взаимодействия программных модулей>. Результаты
+также, контроль интерфейсов взаимодействия программных модулей. Результаты
планирования сводятся в план конфигурационного управления (SCM Plan - SCMP),
обычно, являющийся объектом оценки и аудита в рамках деятельности по
обеспечению качества (SQA – Software Quality Assurance).
- Отчетности по статусу конфигураций и сбору соответствующих метрических
показателей
- Аудиту конфигураций
-- Управлению и отслеживанию <состояния и полноты> программной документации
+- Управлению и отслеживанию состояния и полноты программной документации
- Выполнению задач по сборке программных продуктов и их модулей
- Управлению, контролю и поставке выпусков (релизов) программных продуктов
Инструменты, используемые для обеспечения конфигурационного управления, могут
также предоставлять метрики, необходимые для совершенствования процессов.
SWEBOK обращает внимание (рекомендуя соответствующий первоисточник) на
-следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and
+следующие ключевые индикаторы: работы и прогресс по их выполнению (Work and
Progress) и индикаторы качества – поток изменений (Change Traffic),
-стабильность <конфигураций> (Stability), раздробленность (Breakage),
+стабильность конфигураций (Stability), раздробленность (Breakage),
модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility),
среднее время между сбоями (MTBF – Mean Time Between Failures),
-зрелость/полнота <информации> (Maturity). Отчетность по этим индикаторам может
+зрелость/полнота информации (Maturity). Отчетность по этим индикаторам может
быть организована различным образом, например, по элементам конфигураций или по
типу запросов на изменения.
поддерживают процесс сборки и выпуска программного обеспечения и документации
на основе программных элементов, содержащихся в библиотеках. Инструменты для
управления запросами на изменения программного обеспечения используются для
-контролируемых <системой конфигурационного управления> программных элементов.
+контролируемых системой конфигурационного управления программных элементов.
Другие инструменты могут обеспечивать управление базой данных и необходимыми
менеджменту отчетными средствами, а также деятельностью по разработке и
обеспечению качества. Как уже упоминалось выше, в рамках SCM-системы может быть
#### Базовая линия, срез (Baseline)
-Базовая линия или <фиксированный> срез (baseline) программного обеспечения
+Базовая линия или фиксированный срез (baseline) программного обеспечения
– набор элементов программной конфигурации, формально определенный и
зафиксированный по времени в процессе жизненного цикла программного
обеспечения. Этот термин также иногда используется для указания конкретной
После включения элемента в конфигурацию в качестве SCI, изменения элементов
должны утверждаться формально, как связанные с соответствующими элементами
(SCI) и базовыми линиями, следуя плану конфигурационного управления (SCMP).
-После утверждения <запроса на изменение и проведения работ по изменению>,
-<измененный> элемент включается в конфигурацию, в соответствии с заданной
+После утверждения запроса на изменение и проведения работ по изменению,
+измененный элемент включается в конфигурацию, в соответствии с заданной
процедурой утверждения.
### Программная библиотека (Software Library)
Программная библиотека – контролируемая коллекция программных приложений и
связанной с ними документации, предназначенная для использования в процессе
разработки, эксплуатации и сопровождения программного обеспечения (см. IEEE
-610.12-90). В качестве <элемента> программной библиотеки, также, может
+610.12-90). В качестве элемента программной библиотеки, также, может
рассматриваться инструментарий, используемый в работах по выпуску программного
обеспечения и передаче его в эксплуатацию (например, инсталляции). На практике
могут использоваться различные типы библиотек, каждая из которых соответствует
запросы на изменения, включая сообщения об обнаруженных дефектах, и т.п.) в
многопользовательской среде. На более высоком уровне контроля, доступ ограничен
сильнее и SCM (процесс и/или система) является основным пользователем
-<библиотеки> (например, для осуществления автоматической сборки продукта по
+библиотеки (например, для осуществления автоматической сборки продукта по
расписанию).
Все эти библиотеки также являются важным источником информации для
-количественной оценки работ, их результата и прогресса <в развитии программных
-элементов>.
+количественной оценки работ, их результата и прогресса в развитии программных
+элементов.
## Контроль программных конфигураций (Software Configuration Control)
Контроль программных конфигураций касается вопросов управления изменениями в
течение жизненного цикла программного обеспечения. Он включает процесс
определения того, какие именно изменения должны быть сделаны, какие полномочия
-необходимы для утверждения определенных <типов> изменений, в чем состоит
+необходимы для утверждения определенных типов изменений, в чем состоит
поддержка реализации этих изменений, а также концепцию формального утверждения
отклонений от проектных требований, также как и отказа от внесения изменений.
Получаемая в результате этого информация полезна для количественной оценки
-потока изменений, нарушения целостности <системы> и аспектов “переработки” в
+потока изменений, нарушения целостности системы и аспектов “переработки” в
проекте (в большинстве случаев, по времени, стоимости и усилиям -
трудозатратам).
#### Совет по конфигурационному контролю (Software Configuration Control Board)
Полномочия по принятию или отклонению предлагаемых изменений обычно возлагаются
-на <организационную> сущность, называемую совет по конфигурационному контролю -
+на организационную сущность, называемую совет по конфигурационному контролю -
Configuration Control Board (чаще звучит как совет по координации изменений -
Change Control Board, CCB). В небольших проектах такие полномочия могут, в
действительности, принадлежать лидеру или одному назначенному лицу из числа
#### Процесс обработки запросов на изменения (Software change request process)
-Эффективный процесс <обработки> запросов на изменения (SCR process) требует
-использования соответствующих средств поддержки и процедур <для данного вида
-деятельности>, от “бумажных” форм и документированных процедур (как
+Эффективный процесс обработки запросов на изменения (SCR process) требует
+использования соответствующих средств поддержки и процедур для данного вида
+деятельности, от “бумажных” форм и документированных процедур (как
последовательности действий или сценариев) до программных инструментов,
позволяющих отсылать запросы на изменения, выполнять процесс обработки таких
запросов (изменять их статус, комментировать, детализировать и т.п.),
расписания. Если набор утвержденных запросов на изменения может выполняться
одновременно, необходимо обеспечить отслеживание того, какие именно SCR
реализованы в конкретной версии программного продукта и базовой линии
-<конфигурации>. Составной частью процесса “закрытия” изменения (по аналогии с
+конфигурации. Составной частью процесса “закрытия” изменения (по аналогии с
closure - “закрытием”, то есть завершением проекта), является аудит(ы)
конфигурации(й) и верификация качества программного обеспечения. Это
обеспечивает гарантию того, что были внесены только утвержденные изменения.
Фактическая реализация изменений поддерживается инструментальными средствами
соответствующей программной библиотеки (см. выше 2.2 “Программная библиотека”),
-обеспечивающими управление версиями и поддержку <единого> репозитория кода. Как
+обеспечивающими управление версиями и поддержку единого репозитория кода. Как
минимум, эти инструменты должны поддерживать операции chek-in/check-out
(помещение в репозиторий/ получение из репозитория) и ассоциированные
возможности по контролю версий (например, отметка версии – labeling, сравнение
### Отклонения и отказ от изменений (Deviations and Waivers)
Ограничения, накладываемые на усилия, прилагаемые к выполнению определенных
-работ <программной инженерии>, как и спецификации, созданные в процессе
+работ программной инженерии, как и спецификации, созданные в процессе
разработки, могут содержать условия, которые не могут быть удовлетворены в
заданной точке жизненного цикла. Отклонение (deviation) - утверждение
изменений, внесенных относительно предварительно сформулированных условий к
для получения (и генерации отчетов) информации, необходимой для осуществления
процессов жизненного цикла системы. Как и в любой информационной системе,
информация о статусе конфигураций должна идентифицироваться, собираться и
-поддерживаться <в актуальном состоянии> по мере эволюции этих конфигураций.
+поддерживаться в актуальном состоянии по мере эволюции этих конфигураций.
Различная информация и количественные показатели необходимы для поддержки
процесса конфигурационного управления, а также для генерации отчетности (о
статусе конфигураций), необходимой для управления, выполнения процессов
проведения различных количественных оценок в интересах менеджмента, разработки
или конфигурационного управления. Например, к такого рода данным относятся:
количество запросов на изменения на один конфигурационный элемент; среднее
-время, необходимое для реализации запрошенных изменений <заданного типа>.
+время, необходимое для реализации запрошенных изменений заданного типа.
## Аудит конфигураций (Software Configuration Auditing)
Аудит программного обеспечения – деятельность, выполняемая для независимой
-оценки программных продуктов и процессов на <формальное> соответствие
+оценки программных продуктов и процессов на формальное соответствие
(conformance) применимым в данном случае инструкциям, стандартам, руководящим
документам, планам и процедурам (см. IEEE 1028-97 “Standard for Software
-Reviews”). Аудиты проводятся в <строгом> соответствии с четко определёнными
+Reviews”). Аудиты проводятся в строгом соответствии с четко определёнными
процессами, содержащими и определяющими различные роли аудиторов и из
обязанности. Каждый аудит должен быть, в свою очередь, четко спланирован и
может требовать привлечения многих специалистов для выполнения различных задач
числе, включая стандарт IEEE 1028-97 “Standard for Software Reviews”.
Деятельность по аудиту программных конфигураций определяет степень, в которой
-элемент <конфигурации> (SCI) удовлетворяет заданным (например, на уровне
+элемент конфигурации (SCI) удовлетворяет заданным (например, на уровне
требований и/или запросов на изменения) функциональным и физическим
характеристикам. Неформальный аудит такого типа может быть связан с ключевыми
точками жизненного цикла (вехами проекта, в терминах управления проектами -
## Управление выпуском и поставкой (Software Release Management and Delivery)
Термин “релиз” (release, выпуск) используется в данном контексте, подразумевая
-распространение <и использование> элементов конфигураций за рамками работ по
+распространение и использование элементов конфигураций за рамками работ по
разработке программного обеспечения. Это может включать как внутренние релизы,
так и выпуск и передачу программного обеспечения заказчикам. В ситуациях, когда
доступны для поставки различные версии программных элементов (в частности,
различные версии для разных платформ или редакции с различным набором
функциональных возможностей), часто бывает необходимо создавать
специализированные версии и пакеты (сборки) соответствующих материалов
-(элементов, активов) для выпуска в качестве <самостоятельной> версии.
+(элементов, активов) для выпуска в качестве самостоятельной версии.
Программная библиотека (предоставляющая соответствующий инструментарий для
такой сборки) играет ключевую роль в выполнении таких работ.
программного обеспечения.
Процесс и результаты сборки могут быть необходимы для последующего
-использования <в других процессах, работах и проектах> и часто являются
+использования в других процессах, работах и проектах и часто являются
объектом верификации (проверки) в рамках деятельности по обеспечению качества
(SQA).
известных проблемах, а также требованиях к платформе(ам), которые необходимо
соблюдать для предусмотренного режима эксплуатации продукта. Подготовленный к
выпуску пакет (package) также включает инструкции по установке и обновлению
-<предыдущей версии>. Создание такой инструкции может быть осложнено тем, что
+предыдущей версии. Создание такой инструкции может быть осложнено тем, что
некоторые текущие пользователи могут иметь устаревшие версии, более ранние, чем
предыдущий выпущенный релиз. Наконец, в ряде случаев, деятельность по
управлению выпуском может требовать отслеживание распространения (поставки)
изменения для отображения содержимого релиза на полученные запросы на изменения
(SCR - software change request, включая сообщения об обнаруженных ранее и
исправленных в данном релизе ошибках, прим. автора). Эти инструментальные
-средства <поддержки управления выпуском продуктов> также могут поддерживать
-информацию о различных целевых платформах и <операционном> окружении,
+средства поддержки управления выпуском продуктов также могут поддерживать
+информацию о различных целевых платформах и операционном окружении,
используемом у заказчиков.
blob - 000adcbe06357fbc4c9a75e144a68501989a038f
blob + 5ad010cbb66b703c77dfc2a9c068d1c4ee908077
--- 7_software_engineering_management.md
+++ 7_software_engineering_management.md
- Обзор и оценка (Review and evaluation) – относится к работам по проверке
того, что получаемый программный продукт отвечает заданным целям, требованиям,
ограничениям и т.п.
-- Закрытие <проекта> (Closure) – относится к фиксированию результатов
+- Закрытие проекта (Closure) – относится к фиксированию результатов
программного проекта после передачи полученного программного продукта в
эксплуатацию.
- Измерения в программной инженерии (Software engineering measurement) –
ассоциированными входами, выходами и условиями завершения (completion),
например, в форме структуры декомпозиции работ – WBS (work breakdown
structure). Это влияет на высокоуровневое (первичное) определение проектного
-расписания и организационной структуры <проектной команды>.
+расписания и организационной структуры проектной команды.
### Определение результатов (Determine Deliverables)
В совокупности, вся эта деятельность является итеративной и должна обсуждаться
и проводиться до тех пор, пока не будет достигнут консенсус между
соответствующими заинтересованными лицами – в первую очередь, менеджментом
-<проекта> и инженерами <входящими в команду проекта>.
+проекта и инженерами входящими в команду проекта.
### Распределение ресурсов (Resource Allocation)
План проекта реализуется за счет выполнения процессов, представленных в плане.
Следование плану на протяжении выполнения проекта связано с ожиданиями, что
-соблюдение <корректно составленного> плана приводит к успешному удовлетворению
+соблюдение корректно составленного плана приводит к успешному удовлетворению
требований заинтересованных лиц и достижению целей проекта. Основой для
успешного выполнения проекта является управленческая деятельность по ведению
оценки и измерений, мониторинга, контроля и отчетности.
### Процесс мониторинга (Monitor Process)
Соблюдение плана проверяется постоянно и через предопределенные интервалы
-времени. Анализируются выходы (outputs) и условия завершения <задач>.
-Получаемые <в процессе измерений> результаты оцениваются в терминах требуемых
+времени. Анализируются выходы (outputs) и условия завершения задач.
+Получаемые в процессе измерений результаты оцениваются в терминах требуемых
характеристик (например, через процедуры обзора/оценки и аудита – review,
audit). Затраты усилий (efforts), соблюдения расписания, стоимость к данному
моменту, используемые ресурсы – все это исследуется к каждой дате оценки. При
проверка удовлетворения требований качества.
Моделируются и анализируются данные измерений. Анализ расхождений (variance
-analysis) <плана с реальным выполнением проекта> базируется на оценке
+analysis) плана с реальным выполнением проекта базируется на оценке
отклонений реальных данных от планируемых и ожидаемых. Такой анализ может
проводиться в отношении оценки перерасхода средств (cost overrun), нарушения
расписания и других важных характеристик – ограничений проекта Часто
В критических точках проекта оценивается общий (по всему проекту) прогресс в
достижении установленных целей и удовлетворении требований заинтересованных
лиц. Аналогично, проводится оценка (assessment) эффективности процессов,
-<работы> персонала, а также инструментов и методов, использованных в работах,
+работы персонала, а также инструментов и методов, использованных в работах,
проведенных за заданный промежуток времени.
### Определение удовлетворения требованиям (Determining Satisfaction of Requirements)
анализу результатов, полученных в процессе работы над проектом (post mortem
analysis), и улучшению процессов (process improvement).
-### Определение <критериев> закрытия проекта (Determining Closure)
+### Определение критериев закрытия проекта (Determining Closure)
Проект закрывается, когда завершены специфицированные в плане проекта задачи и
-подтверждено <удовлетворительное> достижение критериев завершения (completion
+подтверждено удовлетворительное достижение критериев завершения (completion
criteria) проекта. При этом, все запланированные результаты (продукт, его
модули и т.п.) должны быть переданы заказчику и/или в эксплуатацию с
приемлемыми (с точки зрения требований) и принятыми (со стороны заказчика)
о “подтверждении закрытия/завершения проекта”) создается архив материалов в
соответствии с утверждёнными заинтересованными лицами методами,
местоположением, формой и заданной длительностью хранения. База данных
-измерений <в организации> обновляется в соответствии с полученными финальными
+измерений в организации обновляется в соответствии с полученными финальными
данными проекта и проводится пост-проектный анализ этих данных. Анализ по
завершении проекта помогает в оптимизации процессов, практик и организационной
структуры (см. область знаний Software Engineering Process).
характеристик организационной единицы в уже упомянутом стандарте ISO 15939-02
(ISO/IEC 15939:2002 Software Engineering - Software Measurement Process, раздел
5.2.1).
-- Идентификация информационных потребностей <в отношении результатов
-измерений>. Такие потребности, обычно, базируются на целях, ограничениях,
+- Идентификация информационных потребностей в отношении результатов
+измерений. Такие потребности, обычно, базируются на целях, ограничениях,
рисках и проблемах на уровне заданной организационной единицы. В основе
указанных аспектов лежат различные цели – организационные, проектные и т.п. Все
эти аспекты (как и порождающие их цели) должны быть четко идентифицированы и
(например, в силу недостатка ресурсов), легкость анализа, легкость получения
точных и целостных данных и т.п. (см. стандарт ISO 15939-02, раздел 5.2.3 и
приложение C).
-- Определение наборов <собираемых> данных, а также процедур анализа и ведения
+- Определение наборов собираемых данных, а также процедур анализа и ведения
отчетности. Это включает в себя коллекцию процедур и расписаний, хранение,
проверку, анализ, отчетность и конфигурационное управление собираемыми данными.
(см. стандарт ISO 15939-02, раздел 5.2.4).
- Определение критериев оценки информационных продуктов (т.е. результатов
измерений). На критерии оценки влияют технические и бизнес цели,
сформулированные прежде для соответствующей организационной единицы. Результаты
-измерений* ассоциированы с создаваемым продуктом <являющемся целью проекта>, а
+измерений* ассоциированы с создаваемым продуктом являющемся целью проекта, а
также с процессами, обеспечивающими управление и измерения в проекте. (см.
стандарт ISO 15939-02, раздел 5.2.5 и приложения D, E).
* в данной теме в отношении результатов измерений часто используется термин
установлены на уровне организационной единицы или выше. Такие критерии должны
принимать во внимание существующий опыт, доступность ресурсов и потенциальный
срыв проекта когда предлагается изменение существующих практик. Утверждение
-(approval) <выделения ресурсов> демонстрирует поддержку и принятие обязательств
+(approval) выделения ресурсов демонстрирует поддержку и принятие обязательств
по проведению измерений. (см. стандарт ISO 15939-02, раздел 5.2.6.1 и
приложение F).
- Ресурсы должны быть доступны для реализации запланированных и утвержденных
подразделения или организации). Также, необходимо уделять внимание ресурсам,
необходимым для успешного внедрения новых процедур и измерений (метрик). (см.
стандарт ISO 15939-02, раздел 5.2.6.2).
-- Овладевание и внедрение технологий поддержки <измерений>. Это включает оценку
+- Овладевание и внедрение технологий поддержки измерений. Это включает оценку
доступных технологий, выбор наиболее соответствующих (заданному контексту и
ограничениям) технологий, их приобретение и овладевание ими и, наконец,
внедрение в повседневную практику. (см. стандарт ISO 15939-02, раздел 5.2.7).
Анализ данных и процедуры отчетности должны быть интегрированы в
организационные и/или проектные процессы. (см. стандарт ISO 15939-02, раздел
5.3.1).
-- Сбор данных. Данные должны собираться, верифицироваться и сохраняться <для
-дальнейшего использования>. (см. стандарт ISO 15939-02, раздел 5.3.2).
+- Сбор данных. Данные должны собираться, верифицироваться и сохраняться для
+дальнейшего использования. (см. стандарт ISO 15939-02, раздел 5.3.2).
- Анализ данных и создание информационного продукта (как результата измерений,
позволяющего принимать на его основе те или иные решения). Данные могут
агрегироваться, трансформироваться или записываться как часть процесса анализа
полученные результаты. Сделанные выводы должны быть записаны в соответствующую
базу данных. (см. стандарт ISO 15939-02, раздел 5.4.1 и приложение D).
- Определение потенциальных возможностей улучшения/усовершенствований
-(improvements) <процесса проведения измерений>. Такие рекомендации по улучшению
+(improvements) процесса проведения измерений. Такие рекомендации по улучшению
могут заключаться в изменении формата используемых количественных индикаторов,
единиц измерения или изменений в их классификации (категориях метрик).
Необходимо определять стоимости и отдачу (benefits) от предлагаемых улучшений и
blob - 2220ace2390d547db17e338f5299c1d99254e626
blob + 0848601fd72adb8b854f7a2ea3d6baf8fbed8109
--- 8_software_engineering_process.md
+++ 8_software_engineering_process.md
Для внедрения процессов жизненного цикла необходимо обладать соответствующей
инфраструктурой, подразумевая, что ресурсы (компетентный персонал, инструменты,
-финансирование) – доступны, а ответственность – распределена <по членам
+финансирование) – доступны, а ответственность – распределена по членам
проектной команды и/или организационной единицы, в терминах структуры компании
-или организации, например, отдела или группы>. Выполнение этих задач является
-хорошим индикатором того, что менеджмент <управленческий персонал
-проекта/организации> реально прилагает усилия по поддержке процесса программной
+или организации, например, отдела или группы. Выполнение этих задач является
+хорошим индикатором того, что менеджмент управленческий персонал
+проекта/организации реально прилагает усилия по поддержке процесса программной
инженерии. Как следствие таких усилий могут создаваться различные комитеты и
другие специализированные организационные структуры и органы, в общем случае
называемые steering committee – “управляющий комитет”, обладающий
SEPG создается как центральный орган, принимающий на себя работу по
process improvement - совершенствованию процесса(-ов). SEPG берет на себя
ответственность по множеству вопросов, связанных с этой задачей в терминах
-инициирования <улучшений> и поддержки <существующего процесса и его постоянного
-совершенствования>.
+инициирования улучшений и поддержки существующего процесса и его постоянного
+совершенствования.
Часто SEPG формируется из нескольких ведущих членов проектной команды (если,
SEPG создается в рамках проекта) или на уровне подразделения или всей
Основной задачей EF является институализация (внедрение в повседневную
практику) коллективного опыта и полученных уроков в масштабах организации на
основе разработки, обновления и внедрения в проектную организацию “пакетов
-опыта” – experience packages (например, руководств, моделей, курсов обучения и
-т.п.), <типовых> “активов процесса” – process assets. Проектная организация
+опыта” – experience packages (например, руководств, моделей, курсов обучения и
+т.п.), типовых “активов процесса” – process assets. Проектная организация
предлагает на рассмотрение EF свои продукты, планы, использовавшиеся при
разработке, а также данные, собранные в процессе разработки и эксплуатации.
### Цикл управления программным процессом (Software Process Management Cycle)
Управление процессами в области программного обеспечения состоит из четырех
-действий, представленных в рамках итеративного цикла. Это позволяет получать и
-анализировать отклики на постоянной основе и, <более оперативно>
+действий, представленных в рамках итеративного цикла. Это позволяет получать и
+анализировать отклики на постоянной основе и, более оперативно
совершенствовать процесс. Вот эти четыре действия, предлагаемые SWEBOK:
- Establish Process Infrastructure – создание инфраструктуры процесса. Задачи –
- Planning – планирование. Задача (цель) – понять (сформулировать) текущие
бизнес-цели и потребности в процессе, необходимые отдельным специалистам,
проекту и/или организации, в целом; идентифицировать сильные и слабые стороны
-(см. концепцию SWOT-анализа в различных источниках) <существующего процесса и
-планируемых на данной итерации нововведений и/или изменений> и разработать план
+(см. концепцию SWOT-анализа в различных источниках) существующего процесса и
+планируемых на данной итерации нововведений и/или изменений и разработать план
реализации и изменения процесса.
- Process Implementation and Change – реализация и изменение процесса. Задача
(цель) – выполнение разработанного плана по внедрению нового и/или
Некоторые процессы жизненного цикла придают особое значение быстрому вводу в
эксплуатацию (rapid delivery) программных систем и глубокой вовлеченности
-пользователей <в процесс разработки>. Такие процессы называют agile-методами –
+пользователей в процесс разработки. Такие процессы называют agile-методами –
быстрыми, живыми, подвижными. К ним относится, например, экстремальное
программирование – eXtreme Programming (XP, см. работы Кента Бека – Kent Beck).
Отличительной особенностью этих методов является гибкость в вопросах
### Методы оценки процесса (Process Assessment Methods)
-Для надлежащего проведения оценки соответствующие методы <оценки> позволяют
+Для надлежащего проведения оценки соответствующие методы оценки позволяют
получить количественные параметры, характеризующие возможности оцениваемого
процесса (или зрелости организации, в целом).
инженерии, лежащих в основе многих более детальных измерений и процессов
анализа. Более того, результаты усилий по совершенствованию процессов и
продуктов, могут быть оценены только в том случае, если установлены
-количественные характеристики заданных параметров <процессов и продуктов> для
+количественные характеристики заданных параметров процессов и продуктов для
заданных вех или, более точно (так как измерения, все же, выходят за рамки вех
конкретных проектов, если, конечно, сама SPI-деятельность не позиционировать
как проект, что, конечно, возможно), так называемых “базовых линий”
Далеко не каждый процесс обладает положительным влиянием на получаемые
-результаты. Например, внедрение инспекции <получаемого> программного
+результаты. Например, внедрение инспекции получаемого программного
обеспечения может сократить усилия и стоимость по тестированию, но может и
увеличить время, если каждая инспекция приводит к нарушению расписания просто в
силу продолжительности соответствующих инспекционных действий. Поэтому,
сопровождаемости, большей удовлетворенности пользователей) мы должны внедрить
соответствующие процессы.
-Конечно, не только процессы непосредственно влияют на результат <проекта>.
+Конечно, не только процессы непосредственно влияют на результат проекта.
Существуют и другие факторы, играющие не менее важную роль, например,
возможности инструментов и потенциал, знания и опыт специалистов. Когда
оценивается влияние изменения процессов, такие факторы должны учитываться
Существует широкий спектр метрик, которые можно использовать для оценки
структуры программного обеспечения – в отношении высокоуровневого и
низкоуровневого дизайна, а также артефактов кода для анализа потоков работ,
-потоков данных, вложенности <вызовов>, структур контроля, модульности,
+потоков данных, вложенности вызовов, структур контроля, модульности,
взаимодействия и т.п.
#### Оценка качества (Quality measurement)
возможно построить соответствующие информационные модели на основе собранных
данных и имеющихся знаний.
-Эти модели применяются для анализа, классификации и предсказания <характеристик
-и поведения измеряемых объектов>. Оценка моделей необходима для обеспечения
+Эти модели применяются для анализа, классификации и предсказания характеристик
+и поведения измеряемых объектов. Оценка моделей необходима для обеспечения
достаточной степени точности и понимания их ограничений. Также необходимо
отметить важность работ, направленных на уточнение моделей как в процессе
ведения проекта, так и после его завершения.
например, подходом QIP (Quality Improvement Paradigm) состоит из цикла
“понимание-проверка-приложение”. Техники, представленные ниже, приведены в
качестве других примеров аналитического подхода к измерениям и отражают
-достаточно типичную практику реализации такого <аналитического> взгляда на
+достаточно типичную практику реализации такого аналитического взгляда на
проведение количественной оценки. Будут или нет использоваться эти техники в
практике конкретной организации зависит, как минимум, от зрелости ее
организационной культуры и используемых процессов.
- Экспериментальные исследования (Experimental Studies). Проводятся в
-специально подготовленном “окружении” для оценки <нового или измененного>
+специально подготовленном “окружении” для оценки нового или измененного
процесса. Обычно новый (или измененный) процесс сравнивается с существующим для
определения того, в какой степени “старый” процесс дает лучшие результаты, по
сравнению с новым процессом.
blob - 91b075ee2ec43b279e84820ece36d7cc249e2efb
blob + 8cd06eb3708beed03d1812e2fbd82b9779669929
--- 9_software_engineering_tools_and_methods.md
+++ 9_software_engineering_tools_and_methods.md
деятельности в соответствие с заданным систематическим подходом и более
вероятным и скорым, с точки зрения соответствующего метода, достижением успеха.
Методы обычно предоставляют соответствующие соглашения (нотацию), словарь
-<терминов и понятий> и процедуры выполнения идентифицированных (и охватываемых
-методом) задач, а также рекомендации по оценке и проверке <выполняемого>
-процесса и <получаемого в его результате> продукта. Методы, как и инструменты,
+терминов и понятий и процедуры выполнения идентифицированных (и охватываемых
+методом) задач, а также рекомендации по оценке и проверке выполняемого
+процесса и получаемого в его результате продукта. Методы, как и инструменты,
варьируются по содержанию (охватываемой области применения) от отдельной фазы
жизненного цикла (или даже процесса) до всего жизненного цикла. Данная область
знаний касается только методов, охватывающих множество фаз (этапов) жизненного
случаев (что подтверждается конкретными программными средствами, доступными на
рынке программного обеспечения), в качестве инструмента работы с требованиями
может выступать и система конфигурационного управления, если, конечно, она
-изначально не ограничена базовой функциональностью контроля версий <файлов>. С
+изначально не ограничена базовой функциональностью контроля версий файлов. С
другой стороны, сегодняшние средства моделирования на основе UML и BPMN могут
также рассматриваться как элементы инструментального обеспечения работы с
требованиями, что часто отражается в их функциональности, включающей тесную
Эта тема охватывает инструменты для создания и проверки программного дизайна.
Существует большое разнообразие таких инструментов, использующих различные
нотации (соглашения, в том числе визуальные) и методы. Несмотря на такое
-разнообразие, <авторами SWEBOK> не было найдено <адекватной> классификации этих
+разнообразие, авторами SWEBOK не было найдено адекватной классификации этих
инструментов.
Однако, в данном случае, все же возможно разделение инструментов по нескольким
машинного выполнения.
- Редакторы (program editors). Эти инструменты используются для создания и
-модификации <исходного кода> программ и, возможно, ассоциированной с ними
+модификации исходного кода программ и, возможно, ассоциированной с ними
документации. Это могут быть как редакторы “общего назначения” (что на
протяжении многих лет наблюдается в UNIX и unix-подобных средах) или
специализированные редакторы с поддержкой специфики целевого языка
(трансляции) исходного кода к исполнению.
- Отладчики (debuggers). Эти инструменты было принято выделить в
самостоятельную категорию, так как они поддерживают процесс конструирования
-программного обеспечения, но, в то же время, <функционально> отличаются от
+программного обеспечения, но, в то же время, функционально отличаются от
редакторов и компиляторов.
С точки зрения классификации инструментов необходимо выделить явно и давно
позволяющем отслеживать поведение объекта, подвергаемого тестированию.
- Инструменты оценки тестов (test evaluation tools). Эти инструменты
поддерживают оценку результатов выполнения тестов, помогая определить в какой
-степени и где именно обнаруженное поведение <тестируемого объекта>
+степени и где именно обнаруженное поведение тестируемого объекта
соответствует ожидаемому поведению.
- Средства управления тестами (test management tools). Эти средства
обеспечивают поддержку всех аспектов процесса тестирования программного
инструменты используются для количественной оценки и анализа производительности
программного обеспечения, являющегося специализированным видом тестирования,
цель которого – в оценки поведения программ в части производительности, в
-отличие от тестирования <корректности> функционального поведения.
+отличие от тестирования корректности функционального поведения.
Последний класс инструментов тестирования, в какой-то степени, показывает
недостаточность предложенной классификации, упуская, например, инструменты
- Инструменты (статического) анализа. Эти средства используются для анализа
программных артефактов, данных, потоков работ и зависимостей. Такие инструменты
предназначены для проверки определенных свойств или артефактов, в целом, на
-соответствие <заданным характеристикам>.
+соответствие заданным характеристикам.
### Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues)
(heuristic methods), касающиеся неформализованных подходов; формальные методы
(formal methods), обоснованные математически; методы прототипирования
(prototyping methods), базирующиеся на различных формах прототипирования. Эти
-три темы не являются изолированными <друг от друга>, скорее они выделены исходя
+три темы не являются изолированными друг от друга, скорее они выделены исходя
из их значимости и на основе определенных достаточно явных индивидуальных
особенностей. Например, объектно-ориентированный подход может включать
формальные техники и использовать прототипирование для проверки и аттестации.
- Методы, ориентированные на конкретную область применения (domain-specific
methods). Такие специализированные методы разрабатываются с учетом специфики
решаемых задач, например, систем реального времени, безопасности
-<жизнедеятельности> (safety) и защищенности <от несанкционированного доступа>
+жизнедеятельности (safety) и защищенности от несанкционированного доступа
(security).
### Формальные методы (Formal Methods)
качестве результата применения таких методов рассматривается конечный -
исполнимый программный продукт.
- Подтверждение/доказательство (verification/proving properties). Этот подход
-основывается на строгом доказательстве точности <любых> характеристик <исходных
-предпосылок и получаемого продукта> с использованием теорем и проверки точности
+основывается на строгом доказательстве точности любых характеристик исходных
+предпосылок и получаемого продукта с использованием теорем и проверки точности
моделей.
История программной инженерии показала, что в области разработки прикладных
(часто основывается как на формальных методах).
- Цели прототипирования. Примерами таких целей служат требования, архитектурный
дизайн или пользовательский интерфейс.
-- Техники оценки/исследования (evaluation) <результатов> прототипирования. Эти
+- Техники оценки/исследования (evaluation) результатов прототипирования. Эти
аспекты касаются того, как именно будут использованы результаты создания
прототипа (например, будет ли он трансформирован в продукт, создается он для
оценки нагрузочных способностей и других аспектов масштабируемости и т.п.).
blob - 5dbe36c867b957748fef5d4d9e60e8a6ec720c6f
blob + 8fa41573f0d66e07e2301ddadc09746a2199364c
--- software_lifecycle_models.md
+++ software_lifecycle_models.md
обеспечения возможности управления) более четкое разграничение фаз проекта (что
не подразумевает их линейного и последовательного выполнения).
-Ниже приведены определения <модели> жизненного цикла программной системы,
+Ниже приведены определения модели жизненного цикла программной системы,
даваемые, например, в различных вариантах стандартов ГОСТ:
- Модель жизненного цикла - структура, состоящая из процессов, работ и задач,
включающих в себя разработку, эксплуатацию и сопровождение программного
методологией. В частности, выбор и применение метрик оценки качества
программной системы и процессов находятся за рамками стандарта 12207, а
концепция совершенствования процессов рассматривается в стандарте ISO/IEC 15504
-“Information Technology - Software Process Assessment” (“Оценка процессов <в
-области> программного обеспечения”).
+“Information Technology - Software Process Assessment” (“Оценка процессов в
+области программного обеспечения”).
Необходимо отметить заложенные в стандарте ключевые концепции рассмотрения
жизненного цикла программных систем.
В результате, можно определить общий набор контрольных точек в сегодняшней
спиральной модели:
-- *Concept of Operations (COO)* – концепция <использования> системы;
+- *Concept of Operations (COO)* – концепция использования системы;
- *Life Cycle Objectives (LCO)* – цели и содержание жизненного цикла;
- *Life Cycle Architecture (LCA)* – архитектура жизненного цикла; здесь же
возможно говорить о готовности концептуальной архитектуры целевой программной
