commit 824fc889d10debe960fe260f36df3ae8f5ad5ead from: Mike Voznesensky via: Sergey Bronnikov date: Tue Jun 04 08:33:40 2024 UTC Broke to lines paragraphs commit - 18db97879f7512c0b94e487e8067f7f5aec4bd64 commit + 824fc889d10debe960fe260f36df3ae8f5ad5ead blob - 07378492c1e705ec5ea1213666e81a910b7dd1b7 blob + 859bf36717c3e9ed6fd1d9d32684ae4937a25599 --- 0_introduction.md +++ 0_introduction.md @@ -62,7 +62,27 @@ Engineering как дисциплины. ## 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 году @@ -178,7 +198,16 @@ SWEBOK – “секций” и дает декомп представления по-русски, которые кажутся представляются наиболее адекватными в соответствующем контексте. -К моменту начала работы над представленным переводом 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 @@ -38,9 +38,14 @@ top-level design) – описание высокоу известных специалистов в программной инженерии, предложил терминологическое разделение различных видов дизайна: -- *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 @@ -215,11 +215,23 @@ Identification) - Аудит конфигураций (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) @@ -683,7 +695,10 @@ Change Control Board, CCB). В небольших пр Software Configuration (Change) Control Board – SCCB. Деятельность CCB обычно является объектом аудита качества или оценки. -Учитывая роль управления изменениями в конфигурационном управлении и реальные задачи CCB, более обоснованным выглядит использование именно названия Change Coordination & Control Board – в общем случае звучащий как совет по координации и контролю изменений. +Учитывая роль управления изменениями в конфигурационном управлении и реальные +задачи CCB, более обоснованным выглядит использование именно названия Change +Coordination & Control Board – в общем случае звучащий как совет по координации +и контролю изменений. #### Процесс обработки запросов на изменения (Software change request process) @@ -777,7 +792,10 @@ environment). Эти инструменты могут ## Учет статусов конфигураций (Software Configuration Status Accounting) -Учет статусов программных конфигураций (Software Configuration Status Accounting, SCSA) подразумевает сохранение (recording) и генерацию отчетности (reporting) для всей информации, необходимой для эффективного управления конфигурациями программного обеспечения. +Учет статусов программных конфигураций (Software Configuration Status +Accounting, SCSA) подразумевает сохранение (recording) и генерацию отчетности +(reporting) для всей информации, необходимой для эффективного управления +конфигурациями программного обеспечения. ### Информация о статусе конфигураций (Software Configuration Status Information)