commit - 18db97879f7512c0b94e487e8067f7f5aec4bd64
commit + 824fc889d10debe960fe260f36df3ae8f5ad5ead
blob - 07378492c1e705ec5ea1213666e81a910b7dd1b7
blob + 859bf36717c3e9ed6fd1d9d32684ae4937a25599
--- 0_introduction.md
+++ 0_introduction.md
## SWEBOK: Руководство к своду знаний по программной инженерии
-C 1993 года IEEE и ACM координируют свои работы в рамках специального совместного комитета - Software Engineering Coordinating Committee (SWECC - http://www.computer.org/tab/swecc). Проект SWEBOK был инициирован этим комитетом в 1998 году. Оцененный предположительный объем содержания SWEBOK и другие факторы привели к тому, что было рекомендовано проводить работы по реализации проекта не только силами добровольцев из рядов экспертов индустрии и представителей крупнейших потребителей и производителей программного обеспечения, но и на основе принципа “полной занятости”. Базовый комплекс работ, в соответствии со специальным контрактом, был передан в Software Engineering Management Research Laboratory Университета Квебек в Монреале (Universite du Quebec a Montreal). Среди компаний, поддержавших этот уникальный проект были Boeing, MITRE, Raytheon, SAP. В результате проекта, оcуществленного при финансовой поддержке этих и других компаний и организаций, а также с учетом его значимости для индустрии, SWEBOK Advisory Committee (SWAC) принял решение сделать SWEBOK 2004 trial edition общедоступной. В перспективе, в зависимости от финансирования, SWAC считал необходимым законченную версию SWEBOK (изначально планировалось, что она будет готова в 2008 году) сделать также свободно доступной на Web-сайте проекта – http://www.swebok.org. Сегодняшняя “публичность” (общедоступность) результатов проекта стала возможна, в первую очередь, именно благодаря поддержке SWEBOK Industrial Advisory Board (IAB) – структуры, объединяющей представителей компаний, поддержавших проект.
+C 1993 года IEEE и ACM координируют свои работы в рамках специального
+совместного комитета - Software Engineering Coordinating Committee (SWECC -
+http://www.computer.org/tab/swecc). Проект SWEBOK был инициирован этим комитетом
+в 1998 году. Оцененный предположительный объем содержания SWEBOK и другие
+факторы привели к тому, что было рекомендовано проводить работы по реализации
+проекта не только силами добровольцев из рядов экспертов индустрии и
+представителей крупнейших потребителей и производителей программного
+обеспечения, но и на основе принципа “полной занятости”. Базовый комплекс работ,
+в соответствии со специальным контрактом, был передан в Software Engineering
+Management Research Laboratory Университета Квебек в Монреале (Universite du
+Quebec a Montreal). Среди компаний, поддержавших этот уникальный проект были
+Boeing, MITRE, Raytheon, SAP. В результате проекта, оcуществленного при
+финансовой поддержке этих и других компаний и организаций, а также с учетом его
+значимости для индустрии, SWEBOK Advisory Committee (SWAC) принял решение
+сделать SWEBOK 2004 trial edition общедоступной. В перспективе, в зависимости от
+финансирования, SWAC считал необходимым законченную версию SWEBOK (изначально
+планировалось, что она будет готова в 2008 году) сделать также свободно
+доступной на Web-сайте проекта – http://www.swebok.org. Сегодняшняя
+“публичность” (общедоступность) результатов проекта стала возможна, в первую
+очередь, именно благодаря поддержке SWEBOK Industrial Advisory Board (IAB) –
+структуры, объединяющей представителей компаний, поддержавших проект.
Проект SWEBOK планировался в виде трех фаз: *Strawman* (“соломенный человек”),
*Stoneman* (“каменный человек”) и *Ironman* (“железный человек”). К 2004 году
представления по-русски, которые кажутся представляются наиболее адекватными в
соответствующем контексте.
-К моменту начала работы над представленным переводом SWEBOK в 2004 году, каких-либо даже фрагментарных переводов SWEBOK на русский язык не существовало. В то же время, несмотря на спорность некоторых положений SWEBOK, значимость его для индустрии программного обеспечения как первой коллективной попытки систематизации накопленных знаний просто сложно переоценить. Представленный далее перевод SWEBOK - Руководство к своду знаний по программной инженерии необходимо рассматривать как авторский перевод с замечаниями и комментариями ключевых положений SWEBOK. Такой подход ни в коем случае не подменяет оригинального SWEBOK и является всего лишь авторским прочтением последнего.
+К моменту начала работы над представленным переводом SWEBOK в 2004 году,
+каких-либо даже фрагментарных переводов SWEBOK на русский язык не
+существовало. В то же время, несмотря на спорность некоторых положений SWEBOK,
+значимость его для индустрии программного обеспечения как первой коллективной
+попытки систематизации накопленных знаний просто сложно
+переоценить. Представленный далее перевод SWEBOK - Руководство к своду знаний по
+программной инженерии необходимо рассматривать как авторский перевод с
+замечаниями и комментариями ключевых положений SWEBOK. Такой подход ни в коем
+случае не подменяет оригинального SWEBOK и является всего лишь авторским
+прочтением последнего.
> Представленный перевод SWEBOK 2004 никак не заменяет первоисточника и создан
> [Сергеем Орликом](https://www.linkedin.com/in/sorlik) при участии [Юрия
blob - 9876fe53fac4eb5358d92c2df0c540587a32a3d4
blob + 4ce897dac446894dc2a9d79b05162e7fe4c78181
--- 2_software_design.md
+++ 2_software_design.md
известных специалистов в программной инженерии, предложил терминологическое
разделение различных видов дизайна:
-- *D-дизайн (D-design, decomposition design)* – декомпозиция структуры программного обеспечения в виде набора фрагментов или компонент;
-- *FP-дизайн (FP-design, family pattern design)* – семейство архитектурных представлений, базирующихся на шаблонах;
-- *I-дизайн (I-design, invention)* – создание высоко-уровневой концепции, видения того, что из себя будет представлять программная система; данный вид дизайна является результатом процесса анализа требований и их трансформации в подходы к реализации.
+- *D-дизайн (D-design, decomposition design)* – декомпозиция структуры
+ программного обеспечения в виде набора фрагментов или компонент;
+- *FP-дизайн (FP-design, family pattern design)* – семейство
+ архитектурных представлений, базирующихся на шаблонах;
+- *I-дизайн (I-design, invention)* – создание высоко-уровневой
+ концепции, видения того, что из себя будет представлять программная
+ система; данный вид дизайна является результатом процесса анализа
+ требований и их трансформации в подходы к реализации.
Если обсуждать данную область знаний в терминах ДеМарко, проектирование
программного обеспечения в понимании программной инженерии подразумевает D- и
blob - e413dc9977e42b570425cc8811cd5c2bbb508dad
blob + 1a0db5d6d3c3727bafde6e2e865fa9c40325ca4a
--- 6_software_configuration_management.md
+++ 6_software_configuration_management.md
- Аудит конфигураций (Software Configuration Auditing)
- Управление выпуском и поставкой (Software Release Management and Delivery)
-Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного управления, как организационные вопросы, обязанности, ресурсы и расписание, выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а также, контроль интерфейсов <взаимодействия программных модулей>. Результаты планирования сводятся в план конфигурационного управления (SCM Plan - SCMP), обычно, являющийся объектом оценки и аудита в рамках деятельности по обеспечению качества (SQA – Software Quality Assurance).
+Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного
+управления, как организационные вопросы, обязанности, ресурсы и расписание,
+выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а
+также, контроль интерфейсов <взаимодействия программных модулей>. Результаты
+планирования сводятся в план конфигурационного управления (SCM Plan - SCMP),
+обычно, являющийся объектом оценки и аудита в рамках деятельности по
+обеспечению качества (SQA – Software Quality Assurance).
#### Организация и обязанности (SCM organization and responsibilities)
-Для предотвращения путаницы в том, кто будет выполнять заданные работы и задачи конфигурационного управления, должны быть четко идентифицированы организации (организационные структуры), вовлеченные в SCM-процесс. Конкретные обязанности по выполнению заданных работ и задач SCM должны быть назначены соответствующим организационным сущностям. Также, должны быть идентифицированы общие полномочия и пути отчетности, даже если это выполняется в процессе планирования управления проектом или деятельности по обеспечению качества.
+Для предотвращения путаницы в том, кто будет выполнять заданные работы и задачи
+конфигурационного управления, должны быть четко идентифицированы организации
+(организационные структуры), вовлеченные в SCM-процесс. Конкретные обязанности
+по выполнению заданных работ и задач SCM должны быть назначены соответствующим
+организационным сущностям. Также, должны быть идентифицированы общие полномочия
+и пути отчетности, даже если это выполняется в процессе планирования управления
+проектом или деятельности по обеспечению качества.
#### Ресурсы и расписание (SCM resources and schedules)
Software Configuration (Change) Control Board – SCCB. Деятельность CCB обычно
является объектом аудита качества или оценки.
-Учитывая роль управления изменениями в конфигурационном управлении и реальные задачи CCB, более обоснованным выглядит использование именно названия Change Coordination & Control Board – в общем случае звучащий как совет по координации и контролю изменений.
+Учитывая роль управления изменениями в конфигурационном управлении и реальные
+задачи CCB, более обоснованным выглядит использование именно названия Change
+Coordination & Control Board – в общем случае звучащий как совет по координации
+и контролю изменений.
#### Процесс обработки запросов на изменения (Software change request process)
## Учет статусов конфигураций (Software Configuration Status Accounting)
-Учет статусов программных конфигураций (Software Configuration Status Accounting, SCSA) подразумевает сохранение (recording) и генерацию отчетности (reporting) для всей информации, необходимой для эффективного управления конфигурациями программного обеспечения.
+Учет статусов программных конфигураций (Software Configuration Status
+Accounting, SCSA) подразумевает сохранение (recording) и генерацию отчетности
+(reporting) для всей информации, необходимой для эффективного управления
+конфигурациями программного обеспечения.
### Информация о статусе конфигураций (Software Configuration Status Information)
