commit - b052d833944336202a14ae618da971975410338c
commit + fd326bc534189060f6001c9d60c6a559ee22d716
blob - 4877e7925e1d965f0a387ff4ce2d161a5336f203
blob + 5d4191183baeadd6e9064b62d4bdd50cfb46f807
--- 10_software_quality.md
+++ 10_software_quality.md
“Назначением технических оценок является исследование программного продукта для
определения его пригодности для использования в надлежащих целях. Цель состоит
-в идентификации расхождений с утвержденными спецификациями и стандартами.” -
+в идентификации расхождений с утверждёнными спецификациями и стандартами.” -
IEEE 1028-97 “IEEE Standard for Software Reviews”.
Для обеспечения технических оценок необходимо распределение следующих ролей:
полномочиями (например, организацией-разработчиком того или иного стандарта,
соответствие которому оценивается независимым экспертом и чьи действия
подтверждены создателем стандарта). Назначение такого рода тестирования состоит
-в проверке продукта на соответствие определенному набору требований (например,
+в проверке продукта на соответствие определённому набору требований (например,
по информационной безопасности).
### Количественная оценка качества программного обеспечения (Software Quality Measurement)
blob - 6b9594b6daf791cb304862a36d2ccdc70171bf7a
blob + a15a319d076751d052bb1fed09b0e1f4218801a3
--- 1_software_requirements.md
+++ 1_software_requirements.md
Бизнес-правила могут быть не только использованы при определении требований к
разрабатываемому ПО, но и могут отдельно оформляться в дизайне ПО (класс или
-группа классов), отражаясь в конечном итоге в программном коде на определенном
+группа классов), отражаясь в конечном итоге в программном коде на определённом
языке программирования. Существуют специализированные инструментальные средства
и библиотеки, позволяющие разрабатывать и поддерживать приложения, интенсивно
использующие бизнес-правила.
так и с нефункциональными (в т.ч. с ограничениями проектирования или атрибутами
качества).
-Необходимо также отметить, что Features обладают определенным дуализмом в своей
+Необходимо также отметить, что Features обладают определённым дуализмом в своей
интерпретации, зависимым от контекста конкретного продукта – с одной стороны
это может быть «тот самый список характеристик, указанный на коробке продукта»
в случае создания «коробочного ПО», с другой стороны это может список
секунду”; в то же самое время, крайне важно понимать, что постановка вопроса
(то есть формулирование требования) в форме “система должна обеспечить рост
пропускной способности” без указания конкретных количественных характеристик
-является просто некорректно определенным требованием.
+является просто некорректно определённым требованием.
При этом, например, требование “система должна вести журнал подключений
пользователей” может и должно детализироваться с точки зрения описания
типичное требование с количественной оценкой, в котором определена верхняя
граница диапазона времени, за которое должен быть осуществлен поиск документов.
Несомненно, этот атрибут качества системы существует в контексте определенного
-функционального требования о возможности поиска документов по определенным
+функционального требования о возможности поиска документов по определённым
критериям. И этот контекст или связь должна быть определена либо явно, в рамках
иерархии требований, либо посредством трассировки, между требованиями разных
видов (функционального и атрибута качества). Примечательно, что Вигерс в своей
“Инициация и определение содержания” (Initiation and Scope Definition) области
знаний “Управление в программной инженерии” (Software Engineering Management).
Основная цель данной темы – обеспечение связи между процессами и деятельностью,
-определенными в 2.1 “модели процесса определения требований” и вопросами
+определёнными в 2.1 “модели процесса определения требований” и вопросами
использования проектных ресурсов – стоимостью, человеческими ресурсами,
инструментами и т.п.
Вопросы моделирования тесно связаны с применяемыми методами и подходами.
Однако, частные методы или нотации, как отмечается в SWEBOK, так или иначе
-следуют распространенным в индустрии практикам и тяготеют к тем формам, с
+следуют распространённым в индустрии практикам и тяготеют к тем формам, с
которыми связаны накопленный опыт и подтвержденные общепринятой практикой
знания. SWEBOK отмечает, что могут быть разработаны различные виды моделей,
включающие потоки работ и данных, модели состояний, трассировки событий,
В какой-то степени можно провести параллель между требованиями и записями
(строками) в реляционной базе данных, где каждая запись обладает набором
-атрибутов (столбцов). В определенном смысле, можно и необходимо говорить о том
+атрибутов (столбцов). В определённом смысле, можно и необходимо говорить о том
или ином уровне атомарности требований (что не исключает связей между
требованиями), представляемой такой метафорой.
blob - 106abb9f63ec35345bed7fdc99c8118bb5ab3441
blob + 9876fe53fac4eb5358d92c2df0c540587a32a3d4
--- 2_software_design.md
+++ 2_software_design.md
#### Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)
Этот подход подразумевает, что создаваемые программные компоненты обладают
-всеми необходимыми характеристиками, определенными абстракцией (моделью), но не
+всеми необходимыми характеристиками, определёнными абстракцией (моделью), но не
более того. То есть не включают функциональность, отсутствующую в модели.
Данный принцип особенно ярко выделен и явно представлен в виде рекомендуемых
признаки хорошего дизайна, специфичные для данной платформы и компонентной
модели, но абсолютно никак не связанные с какими-либо требованиями к
создаваемой на этой платформе программной системе. Если вернуться к измеряемым
-атрибутам качества, они описываются определенными метриками. Приведенный выше
+атрибутам качества, они описываются определёнными метриками. Приведенный выше
пример с количеством бизнес-методов на класс является метрикой, относящейся к
теме 4.3 “Измерения”. Эта же метрика позволяет оценить атрибуты качества
“модифицируемость” и “сложность” системы.
“слабоформализованные” или просто частные практические подходы или техники.
Методы здесь являются более общими понятиями, это - методологии,
сконцентрированные на процессе (в частности, проектирования) и предполагающие
-следование определенным правилам и соглашениям, в том числе – по используемым
+следование определённым правилам и соглашениям, в том числе – по используемым
выразительным средствам. Такие методы полезны как инструмент систематизации
(иногда, формализации) и передачи знаний в виде общего фреймворка (то есть
комплексного набора понятий, подходов, техник и инструментов) не только для
### Компонентное проектирование (Component-Based Design)
Программные компоненты являются независимыми единицами, которые обладают
-однозначно-определенными (well-defined) интерфейсами и зависимостями (связями)
+однозначно-определёнными (well-defined) интерфейсами и зависимостями (связями)
и могут собираться и развертываться независимо друг от друга. Данный подход
призван решить задачи использования, разработки и интеграции таких компонент с
целью повышения повторного использования активов (как архитектурных, так и в
blob - e923769328017e0519ee8cb88a27a26dbde9f27c
blob + bc07a3d953b0e68f0923624f54523d9b70aa5fcb
--- 3_software_construction.md
+++ 3_software_construction.md
Использование внутренних стандартов. Определенные стандарты, соглашения и
процедуры могут быть также созданы внутри организации или даже проектной
-команды. Эти стандарты поддерживают координацию между определенными видами
+команды. Эти стандарты поддерживают координацию между определёнными видами
деятельности, группами операций, минимизируют сложность (в том числе при
взаимодействии членов проектной группы и за ее пределами), могут быть связаны с
вопросами ожидания и обработки изменений, рисков и вопросами конструирования
сам код.
Последнее время, большое внимание многие профессиональные разработчики, то есть
-инженеры-конструкторы программного обеспечения, уделяют рефакторинг кода, как
+инженеры-конструкторы программного обеспечения, выделяют рефакторинг кода, как
методы его реструктурирования, призванные без изменения содержания (то есть
функциональности и функциональной целостности) обеспечить решение задач
минимизации сложности, готовности к изменениям (гибкости), прозрачности
*Лингвистические нотации* характеризуются, в частности, использованием строк
текста, содержащих специализированные “слова”, представляющие сложные
программные конструкции, и комбинируемые в шаблоны, напоминающие предложения,
-построенные в соответствии с определенным синтаксисом. В случае корректного
+построенные в соответствии с определённым синтаксисом. В случае корректного
использования таких нотаций, каждая получаемая строка обладает строгой
смысловой нагрузкой (семантикой), обеспечивающей интуитивное понимание того,
что будет происходить когда будет выполняться программное обеспечение,
blob - cfe3acabbc28bc1f2820504131014bff7b142939
blob + 4d10e0902e91ad00167f35909e7512d7837a4c3c
--- 4_software_testing.md
+++ 4_software_testing.md
Общий взгляд на тестирование программного обеспечения последние годы активно
эволюционировал, становясь все более конструктивным, прагматичным и
-приближенным к реалиям современных проектов разработки программных систем.
+приближённым к реалиям современных проектов разработки программных систем.
Тестирование более не рассматривается как деятельность, начинающаяся только
после завершения фазы конструирования. Сегодня тестирование рассматривается как
деятельность, которую необходимо проводить на протяжении всего процесса
### Цели тестирования (Objectivies of Testing)
-Тестирование проводится в соответствии с определенными целями (могут быть
+Тестирование проводится в соответствии с определёнными целями (могут быть
заданы явно или неявно) и различным уровнем точности. Определение цели точным
образом, выражаемым количественно, позволяет обеспечить контроль результатов
тестирования.
проходить стадии альфа (внутреннее пробное использование) и бета (пробное
использование с привлечением отобранных внешних пользователей) версий. Отчеты
об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в
-соответствии с определенными процедурами, включающими подтверждающие тесты
+соответствии с определёнными процедурами, включающими подтверждающие тесты
(любого уровня), проводимые специалистами группы разработки.
Данный вид тестирования не может быть заранее спланирован.
IEEE, ISO/IEC, ГОСТ Р 12207 не выделяет деятельность по тестированию в качестве
самостоятельного процесса, однако, рассматривает соответствующие принципы работ
по тестированию как неотъемлемую часть процессов жизненного цикла и
-сопровождения программных систем. В другом распространенном стандарте IEEE 1074
+сопровождения программных систем. В другом распространённом стандарте IEEE 1074
деятельность по тестированию также объединена с другими оценочными работами как
интегральная часть полного жизненного цикла.
- управление оборудованием и другими средствами, необходимыми для организации
тестирования
- планирование обработки нежелательных результатов (т.е. является управлением
-определенными видами рисков)
+определёнными видами рисков)
В случае одновременной поддержки и сопровождения нескольких версий программной
системы или нескольких систем, необходимо уделять особое внимание планированию
blob - 02a3e97adb5e3a31bf6e4bde9441b03079c8f3c8
blob + 84df82f3168f350be60fe148581deb24566b28ca
--- 5_software_maintenance.md
+++ 5_software_maintenance.md
разработку программных систем. Принятию тех или иных решений в процессе
сопровождения, помогает понимание того, что происходит с программной системой в
процессе ее эксплуатации. Существующее (особенно, корпоративное) программное
-обеспечение никогда не бывает полностью завершенным и продолжает
+обеспечение никогда не бывает полностью завершённым и продолжает
эволюционировать в течение всего срока эксплуатации. В процессе
эволюционирования, программная система становится все более сложной до тех пор,
пока не предпринимаются специальные усилия (в том числе, в рамках специального
Организационные цели описывают как продемонстрировать возврат инвестиций от
деятельности по сопровождению программного обеспечения. Обычно, разработка
-ведется на проектной основе, с определенными временными и бюджетными
+ведется на проектной основе, с определёнными временными и бюджетными
ограничениями. Главный акцент, при этом, делается на выпуске системы,
отвечающей потребностям пользователей, в заданные сроки и в рамках бюджета. В
отличие от этого, сопровождение системы преследует цели максимального продления
организации, отвечающие за сопровождение, в случае использования элементов
процессов разработки в своей деятельности, адаптировали эти процессы <целиком>
в соответствии со своими потребностями. В то же время, деятельность по
-сопровождению обладает и определенными уникальными чертами, что приводит к
+сопровождению обладает и определёнными уникальными чертами, что приводит к
необходимости использования специализированных процессов.
#### Уникальные работы (Unique activities)
проблемах (modification requests, problem reports). Должны быть контролируемы и
сам программный продукт, и любые изменения (не только в коде, но документации,
спецификациях и т.п., то есть любых активах продукта и проекта, прим. автора).
-Такой контроль устанавливается реализацией и строгим следованием утвержденным
+Такой контроль устанавливается реализацией и строгим следованием утверждённым
процессам конфигурационного управления (software configuration management,
SCM). Область знаний “Конфигурационное управление” подробно описывает и
обсуждает процессы, в соответствии с которыми, размещаются, оцениваются и
* для обеих тем – 4.2 и 4.3 возможно применение слова реконструкция, в
зависимости от контекста, означающее как полную перестройку или воссоздание
-чего-либо, идентичного по определенным характеристикам оригинальному образцу,
+чего-либо, идентичного по определённым характеристикам оригинальному образцу,
так и восстановление какой-либо сущности по сохранившимся и/или доступным
внешним признакам, где восстановление может подразумевать опять-таки создание
нового образца или представления об оригинальной сущности.
blob - f78dc25f689f5b1b60e6d3a65fcf0ce4149c4680
blob + e413dc9977e42b570425cc8811cd5c2bbb508dad
--- 6_software_configuration_management.md
+++ 6_software_configuration_management.md
продукте. Конфигурация также может восприниматься как сочетание конкретных
версий аппаратных, программно-аппаратных или программных элементов,
объединенных вместе, в соответствии с заданными процедурами сборки и отвечающих
-определенному назначению. Конфигурационное управление (CM - Configuration
+определённому назначению. Конфигурационное управление (CM - Configuration
Management), в свою очередь, дисциплина идентификации конфигурации системы в
определенные (заданные) моменты времени, с целью систематического контроля
изменений конфигурации, а также поддержки и сопровождения целостной и
В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207, конфигурационное
управление в области программного обеспечения (“6.2 Управление конфигурацией”
по ГОСТ) – Software Configuration Management (SCM[^12]) – один из
-вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающих
+вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающий
проектный менеджмент, деятельность по разработке и сопровождению, обеспечению
качества, а также, заказчиков и пользователей конечного продукта.
и инструменты, привлекаемые для выполнения соответствующих работ и задач SCM.
Планирование касается вопросов определения расписания, устанавливая
последовательность задач конфигурационного управления и идентифицируя их связь
-с расписанием проекта и его вехами, определенными на стадии планирования
+с расписанием проекта и его вехами, определёнными на стадии планирования
проекта. Также должны быть специфицированы требования по обучению персонала,
необходимые для реализации планов.
инструменты предоставляют высокий уровень настраиваемости для обеспечения
гибкой адаптации процессов. Другие инструменты являются менее гибкими, диктуя
те или иные процессы и их характеристики. Требования контроля (надзора), с
-одной стороны, и уровень гибкости и адпатируемости, с другой, являются
+одной стороны, и уровень гибкости и адаптируемости, с другой, являются
определяющими критериями выбора того или иного инструмента.
#### Метрики и процесс количественной оценки в SCM (SCM measures and measurement)
#### Базовая линия, срез (Baseline)
Базовая линия или <фиксированный> срез (baseline) программного обеспечения
-–набор элементов программной конфигурации, формально определенный и
+– набор элементов программной конфигурации, формально определенный и
зафиксированный по времени в процессе жизненного цикла программного
обеспечения. Этот термин также иногда используется для указания конкретной
версии элемента конфигурации, если это согласовано заранее. В определенных
случаях, базовая линия может изменяться только через формальную процедуру
-контроля изменений. Фиксированный срез в сочетании со всеми утвержденными
+контроля изменений. Фиксированный срез в сочетании со всеми утверждёнными
изменениями в отношении его представляет собой текущую утвержденную
конфигурацию.
находятся в ведении организационной структуры, отвечающей за разработку
программного обеспечения, но могут также разделяться и с другими
организационными структурами (например, отвечающей за конфигурационное
-управление или тестирование). Базовая линия продукта соответствует завершенному
+управление или тестирование). Базовая линия продукта соответствует завершённому
программному продукту, готовому для проведения работ по интеграции в рамках
целевой системы (system integration). Базовые линии, используемые для данного
проекта, вместе с ассоциированным уровнем полномочий, необходимым для
рассматриваться инструментарий, используемый в работах по выпуску программного
обеспечения и передаче его в эксплуатацию (например, инсталляции). На практике
могут использоваться различные типы библиотек, каждая из которых соответствует
-определенному уровню зрелости элементов программного обеспечения. Например,
+определённому уровню зрелости элементов программного обеспечения. Например,
“рабочая библиотека” (working library) может поддерживать работы по
кодированию, “библиотека поддержки проекта” (project support library) может
поддерживать тестирование, “мастер-библиотека” (master library) может
оценки программных продуктов и процессов на <формальное> соответствие
(conformance) применимым в данном случае инструкциям, стандартам, руководящим
документам, планам и процедурам (см. IEEE 1028-97 “Standard for Software
-Reviews”). Аудиты проводятся в <строгом> соответствии с четко определенными
+Reviews”). Аудиты проводятся в <строгом> соответствии с четко определёнными
процессами, содержащими и определяющими различные роли аудиторов и из
обязанности. Каждый аудит должен быть, в свою очередь, четко спланирован и
может требовать привлечения многих специалистов для выполнения различных задач
характеристикам. Неформальный аудит такого типа может быть связан с ключевыми
точками жизненного цикла (вехами проекта, в терминах управления проектами -
milestones). Существует два достаточно распространенных типа формального
-аудита (требуемого определенными категориями контрактов, например, на создание
+аудита (требуемого определёнными категориями контрактов, например, на создание
критически-важного программного обеспечения): функциональный аудит конфигураций
(Functional Configuration Audit, FCA) и физический аудит конфигураций (Physical
Configuration Audit, PCA). Успешное (в терминах соответствия результатов
blob - 265b3cbf3b7f5e91d0bb6f6eb87f1f75aaa43b00
blob + e5704171c8f61e7581909d8e38c122e4d0f6ec84
--- 7_software_engineering_management.md
+++ 7_software_engineering_management.md
детально, если изменение требования(ий) решено реализовать (в силу, например,
контрактных обязательств со стороны исполнителя) и необходимо определить, как
именно такое изменение повлияет на существующую систему и какие работы
-необходимо выполнить, чтобы удовлетворить обновленному(ым) требованиям. SWEBOK
+необходимо выполнить, чтобы удовлетворить обновлённому(ым) требованию(ям). SWEBOK
отмечает, что управление изменениями полезно и при оценке результатов проекта
(программного продукта, программной системы), так как содержание и требования
формируют основу оценки успешности проекта. (см. также секцию “Контроль
После того, как принято и утверждено решение о закрытии проекта (также говорят
о “подтверждении закрытия/завершения проекта”) создается архив материалов в
-соответствии с утвержденными заинтересованными лицами методами,
+соответствии с утверждёнными заинтересованными лицами методами,
местоположением, формой и заданной длительностью хранения. База данных
измерений <в организации> обновляется в соответствии с полученными финальными
данными проекта и проводится пост-проектный анализ этих данных. Анализ по
результаты анализа представляются в форме соответствующих графиков, численных
характеристик или других индикаторов, интерпретируемых и передаваемых, в конце
концов, заинтересованным лицам. Результаты и сделанные на их основе заключения
-должны быть оценены (reviewed) в соответствии с процессом, определенным в
+должны быть оценены (reviewed) в соответствии с процессом, определённым в
организации (который может быть формальным или неформальным). Лица,
предоставляющие данные и проводящие измерения, должны участвовать в процессе
обзора и оценки (review) данных для обеспечения соответствия их содержательной
blob - b8cfbe31d1930eafecf227beb29441f5ce69a647
blob + 8ae2d4a355059841a8b4d0c0abc7033e3ea6d145
--- 8_software_engineering_process.md
+++ 8_software_engineering_process.md
Во всех случаях оценка может проводиться по качественным и/или количественным
показателям.
-На сегодняшний день наиболее проработанными и распространенными стандартами
+На сегодняшний день наиболее проработанными и распространёнными стандартами
оценки и совершенствования процесса программной инженерии являются CMMI (де
факто стандарт) и SCAMPI (разработанная в SEI CMU стандартная методика оценки
совершенствования процессов – Standard CMMI Appraisal Method for Process
Software), а потом и CMMI, разрабатывались с учетом потребностей крупных
государственных структур США (в первую очередь, министерства обороны) и их
подрядчиков, модель Bootstrap изначально была ориентирована на малые и средние
-коммерческие компании, с определенным акцентом на индивидуальные практики.
+коммерческие компании, с определённым акцентом на индивидуальные практики.
Также и в системной инженерии существуют модели зрелости, применимые в
отношении программного обеспечения, когда программы являются частью системы.
его поведения и результатов, прим. автора). Этот тип исследований может
использоваться для анализа поведения процесса, выяснения потенциальных
возможностей усовершенствования процесса, предсказания результатов процесса
-(для того случая, если существующий процесс изменяется определенным образом) и
+(для того случая, если существующий процесс изменяется определённым образом) и
контроля выполнения процесса. В качестве первичных данных для симуляции
процесса, обычно, используются данные текущего (существующего) процесса.
- Обзор (оценка) определения процесса (Process Definition Review)
blob - 94bee7c4314e825ef2f5b6a54fecadebd921a83e
blob + 721310bd30d4909e5fb51c6d4aa561a90290eb19
--- 9_software_engineering_tools_and_methods.md
+++ 9_software_engineering_tools_and_methods.md
- Инструменты управления проектами.
- Инструменты конфигурационного управления, поддерживающие работу с актуальными
версиями всего комплекса артефактов проекта и, что не менее важно, позволяющие
-задать поведенческие характеристики (в упрощенном понимании - workflow) и
+задать поведенческие характеристики (в упрощённом понимании - workflow) и
атрибуты этих артефактов в форме элементов конфигураций.
- Ролевые платформы разработки программного обеспечения, охватывающие все
стадии жизненного цикла и, на сегодняшний день, являющиеся развитием
blob - 8a242ba641445ee376386dbc8833dfa36f163b59
blob + 55e2a537d348d29f796ecf68a1f36d458c2094d6
--- software_lifecycle_models.md
+++ software_lifecycle_models.md
* работы
* задачи
-В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле:
+В общем случае, разбиение процесса базируется на широко распространённом PDCA-цикле:
- “P” – Plan – Планирование
- “D” – Do – Выполнение
операционных условиях с анализом откликов пользователей для определения
содержания и планирования следующей итерации. “Чистая” инкрементальная модель
не предполагает развертывания промежуточных сборок (релизов) системы и все
-итерации проводятся по заранее определенному плану наращивания
+итерации проводятся по заранее определённому плану наращивания
функциональности, а пользователи (заказчик) получает только результат финальной
итерации как полную версию системы. С другой стороны, Скотт Амблер [Ambler,
2004], например, определяет эволюционную модель как сочетание итеративного и
-Наиболее известным и распространенным вариантом эволюционной модели является
+Наиболее известным и распространённым вариантом эволюционной модели является
спиральная модель, ставшая уже по сути самостоятельной моделью, имеющей
различные сценарии развития и детализации.
> Модель предполагает возможность эволюции жизненного цикла, развитие и
изменение программного продукта. Главные источники изменений заключены в целях,
для достижения которых создается продукт. Подход, предусматривающий скрытие
-информации о деталях на определенном уровне дизайна, позволяет рассматривать
+информации о деталях на определённом уровне дизайна, позволяет рассматривать
различные архитектурные альтернативы так, как если бы мы говорили о
единственном проектном решении, что уменьшает риск невозможности согласования
функционала продукта и изменяющихся целей (требований).
> Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию
ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах
-проекта. Это достигается явно определенными работами по анализу рисков,
+проекта. Это достигается явно определёнными работами по анализу рисков,
проверке различных характеристик создаваемого продукта (включая архитектуру,
соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше
на каждом “цикле” процесса разработки.
