commit e3b3be103c332a9662c829b24c37c06c2ab1b7a2 from: Mike Voznesensky via: Sergey Bronnikov date: Sat Jan 20 11:36:22 2024 UTC Removed trailing spaces commit - 22dec2c442c05d4671e44214b79f232fc36ced95 commit + e3b3be103c332a9662c829b24c37c06c2ab1b7a2 blob - 757866a0d9625898069024162f53b3bb9fe9f44a blob + f10301070ffba8a7ca8a4b66ab9d91d9e42763d6 --- 0_introduction.markdown +++ 0_introduction.markdown @@ -39,7 +39,7 @@ of Ethics and Professional Practice), к 2004 году Software Engineering: - *Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 Version* - Руководство к Своду Знаний по Программной Инженерии, в дальнейшем -просто “SWEBOK” [SWEBOK, 2004]; +просто “SWEBOK” [SWEBOK, 2004]; - *Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering* – Учебный План для Преподавания Программной Инженерии в ВУЗах1 (данное название на русском языке представлено в blob - aa8e08506576f3edcc2e70022a2d2bb94d5f0a37 blob + 15c1f9c1d19c918d215c4643be6a6336d58dc506 --- 10_software_quality.markdown +++ 10_software_quality.markdown @@ -306,7 +306,7 @@ SQM может использоваться для о Все эти процессы поддерживают стремление к достижению качества и, кроме того, помогают в поиске возможных ошибок. Однако, они отличаются в том, на чем -концентрируют внимание. +концентрируют внимание. Процессы SQM помогают в обеспечении лучшего качества программного обеспечения в данном проекте. Они предоставляют менеджерам основную информацию по каждому blob - 4d08f584da1e5897efb5d69eedeca31a6b6cf1fd blob + 49f2268b51feb173bf128407fb0d4fb5b7c5d9c6 --- 1_software_requirements.markdown +++ 1_software_requirements.markdown @@ -26,7 +26,7 @@ SWEBOK. системные, программные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п. классический пример (см. рисунок 1) высокоуровневого структурирования групп требований как требований к продукту описан в работах -одного из классиков дисциплины управления требованиями – карла вигерса. +одного из классиков дисциплины управления требованиями – карла вигерса. ![рисунок 1. уровни требований по вигерсу [вигерс, 2003, с.8, рис. 1-1]](images/requirements_wiegers.jpg) @@ -118,7 +118,7 @@ Glossary Of Software Engineering Terminology, 1990): функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских -требований. +требований. - группа нефункциональных требований (non-functional requirements) - бизнес-правила (business rules) – включают или связаны с корпоративными @@ -133,7 +133,7 @@ Glossary Of Software Engineering Terminology, 1990): контролируют или влияют на поведение бизнеса”. бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление -некоторых функциональных требований. +некоторых функциональных требований. в контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) @@ -196,7 +196,7 @@ constraint language, brml – business rules markup l группа классов), отражаясь в конечном итоге в программном коде на определенном языке программирования. существуют специализированные инструментальные средства и библиотеки, позволяющие разрабатывать и поддерживать приложения, интенсивно -использующие бизнес-правила. +использующие бизнес-правила. Рассматривая бизнес-правила, как артефакты относящиеся к области программных требований можно отметить, вернее дать одно из пояснений, почему бп относят к @@ -397,10 +397,10 @@ kshell (популярной командной обо непосредственно использовать программное обеспечение; пользователи могут описать задачи, которые они решают (планируют решать) с использованием программной системы, а также ожидания по отношению к атрибутам качества, -отображаемые в пользовательских требованиях. +отображаемые в пользовательских требованиях. - Заказчики (Customers): те, кто отвечают за заказ программного обеспечения или, в общем случае, являются целевой аудиторией на рынке программного -обеспечения (образуют целевой рынок ПО); +обеспечения (образуют целевой рынок ПО); Стандарт 12207 (его обзор будет приведен в другой главе) определяет более суженное понятие “заказчика” (обратите внимание – acquirer, а не customer, хотя @@ -418,13 +418,13 @@ kshell (популярной командной обо обладают “заказчиками” в понимании персонификации тех, кто “заказывает разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в идентификации потребностей и обращению к тем, кто может играть роль -<квалифицированных> “представителей” потребителей; +<квалифицированных> “представителей” потребителей; - Регуляторы (Regulators): многие области применения (“домены”) являются регулируемыми, например, телекоммуникации или банковский сектор. Программное обеспечение для ряда целевых рынков (в первую очередь, корпоративного сектора) требует соответствия руководящим документам и прохождения процедур, -определяемых уполномоченными органами. +определяемых уполномоченными органами. - Инженеры по программному обеспечению, иженеры-программисты (Software Enginner): лица, обладающие обоснованным интересом к разработке программного @@ -566,7 +566,7 @@ Engineering Process). В этом контексте, пилотных подсистем, реализуемых как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов; часто прототипы постепенно трансформируются в результаты проекта и используются для проверки и утверждения -требований; +требований; - “Разъясняющие встречи” - в оригинале звучит как “facilitated meetings”; достаточно емкий по смыслу термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного @@ -598,7 +598,7 @@ Engineering Process). В этом контексте, Существуют и другие, достаточно эффективные практики, описание которых можно найти в литературе и которые вы, наверняка, сами используете в своей работе (например, Requirements Workshop, Role Playing, Storyboarding и т.п.). -Некоторые из них будут также упоминаться в контексте конкретных методологий. +Некоторые из них будут также упоминаться в контексте конкретных методологий. ## Анализ требований (Requirements Analysis) @@ -632,7 +632,7 @@ SADT – Structured Analysis and Design Technique (м применяемым как для моделирования бизнес-процессов, так и структур данных, в частности – реляционных баз данных. - ??? - + Так или иначе, вне зависимости от выразительных средств, которые являются лишь инструментом анализа и фиксирования результатов, результатом анализа требований должны быть однозначно интерпретируемые требований, реализация которых @@ -878,7 +878,7 @@ Requirements Specifications”. описывающих требования – например использование глаголов (will, shall, should, may, can – перечислены в порядке “убывания директивности”). Действительно, “программный модуль X отсылает уведомление на e-mail адрес пользователя...” -несет, мягко говоря, иную смысловую нагрузку, чем “отсылается сообщение”. +несет, мягко говоря, иную смысловую нагрузку, чем “отсылается сообщение”. - Отсутствие представления о классификации требований. Подмена одних категорий требований – другими и смешение требований (например, такое часто случается с функциональными требованиями, бизнес-требованиями и бизнес-правилами). Как blob - 6759b3cebb770a276afb1c5fcd74eedccf834d55 blob + b5f793a1ff077877de8d15fe8e2edb699ebea296 --- 2_software_design.markdown +++ 2_software_design.markdown @@ -130,11 +130,11 @@ FP-дизайн. I-дизайн в большей ст Обычно под абстракций, как результатом процесса абстракции, понимают модель, упрощающую поставленную проблему до рамок, значимых для заданного контекста. -#### Связанность и соединение (Coupling and Cohesion) +#### Связанность и соединение (Coupling and Cohesion) *Связанность (Coupling)* – определяет силу связи (часто, взаимного влияния) между модулями. Соединение (Cohesion) – определяет как тот или иной элемент -обеспечивает связь внутри модуля, внутреннюю связь. +обеспечивает связь внутри модуля, внутреннюю связь. Значение оригинальных терминов очень близко и, в зависимости от контекста, “связанность” и “соединение” могут рассматриваться как степень @@ -157,7 +157,7 @@ Request Broker Architecture), все чаще прих связанные группы функциональности). #### Инкапсуляция/сокрытие информации (Encapsulation/information hiding) - + Данная концепция предполагает группировку и упаковку (с точки зрения подготовки к развертыванию и эксплуатации) элементов и внутренних деталей абстракции (то есть модели) в отношении реализации с тем, чтобы эти детали (как малозначимые blob - 22534459b8e7342dd0206cb9287930bac1ec6c57 blob + 7ac63738e12fc6764a8214db1b68f431a19b7fa7 --- 3_software_construction.markdown +++ 3_software_construction.markdown @@ -6,7 +6,7 @@ SWEBOK. Содержит перевод описания области знаний SWEBOK “Software Construction”, с замечаниями и комментариями. -Конструирование программного обеспечения (Software Construction) +Конструирование программного обеспечения (Software Construction) Термин конструирование программного обеспечения (software construction) описывает детальное создание рабочей программной системы посредством комбинации blob - 8000214af2c5f9f75d67efd714cd1043b2355570 blob + 829d7ca79b25dc2e6bfb1a4d3fc78c96eec6cd53 --- 4_software_testing.markdown +++ 4_software_testing.markdown @@ -160,7 +160,7 @@ Std. 610-90 также обсуждается в об что “тестирование программы может использоваться для демонстрации наличия дефектов, но никогда не покажет их отсутствие”. Основная причина этого в том, что полное (всеобъемлющее) тестирование недостижимо для реального программного -обеспечения. +обеспечения. #### Проблема неосуществимых путей (The problem of infeasible paths) blob - 257e0b0c5b14098694b407f962f5ccf88d2bfa71 blob + 6bed2f44578167adfacd234d884ae08b32594e55 --- 5_software_maintenance.markdown +++ 5_software_maintenance.markdown @@ -6,7 +6,7 @@ SWEBOK. Содержит перевод описания области знаний SWEBOK “Software Maintenance”, с замечаниями и комментариями. -Сопровождение программного обеспечения (Software Maintenance) +Сопровождение программного обеспечения (Software Maintenance) Результат усилий по разработке программного обеспечения состоит в передачи в эксплуатацию программного продукта, удовлетворяющего требованиям пользователей. @@ -465,7 +465,7 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof * Как мы видим из описания данных работ в SWEBOK, речь идет не только о компонентах системы, но и о ее окружении, включая другие системы, -функционирующие в том же операционном/системном окружении. +функционирующие в том же операционном/системном окружении. Запросы на изменения2 (change requests - CR), иногда упоминаемые как запросы на модификацию (modification request - MR), часто также называемые @@ -859,14 +859,14 @@ Desk): функция поддержки конечн приоритетности и стоимости модификаций, связанных с поступившим запросом или сообщенной проблемой. - Анализ влияния (Impact Analysis): анализ возможных последствий изменений, -вносимых в существующую систему - рассматривался выше в теме 2.1.3. +вносимых в существующую систему - рассматривался выше в теме 2.1.3. - Поддержка программного обеспечения (Software Support): работы по консультированию пользователей, проводимые в ответ на их информационные запросы (request for information), например, касающиеся соответствующих бизнес-правил (см. область знаний “Требования к программному обеспечению”), проверки, содержания данных и специфических (ad hoc) вопросов пользователей и их сообщений о проблемах (ошибках, сбоях, непредусмотренному поведению, -непониманию аспектов работы с системой и т.п.). +непониманию аспектов работы с системой и т.п.). - Контракты и обязательства: к ним относятся классическое соглашение об уровне предоставляемого сервиса - Service Level Agreement (SLA), а также другие договорные аспекты, на основании которых, группа/служба/организация по blob - 70593bc8a49526da268c49f6e202d45ad8d2ccc5 blob + 18c5450074f46e95c5349cc76d7e076b4c68822e --- 6_software_configuration_management.markdown +++ 6_software_configuration_management.markdown @@ -390,7 +390,7 @@ SCM-процесс. процессов и процедур конфигурационного управления. Для этого может быть необходимо введение соответствующих полномочий и назначение обязанностей по контролю выполнения задач SCM. Аналогичные полномочия и обязанности по надзору -над SCM-процессом могут существовать в контексте SQA-деятельности. +над SCM-процессом могут существовать в контексте SQA-деятельности. Использование интегрированных SCM-инструментов с возможностью контроля процесса может сделать процедуру надзора более легкой и прозрачной. Некоторые blob - 39aa5fa430e002c25035ee3fbab3a4bdd1770bad blob + e7a7acfc91f4d6992dd346054b453b9324f59599 --- 7_software_engineering_management.markdown +++ 7_software_engineering_management.markdown @@ -6,7 +6,7 @@ SWEBOK. Содержит перевод описания области знаний SWEBOK “Software Engineering Management”, с замечаниями и комментариями. -Управление программной инженерией (Software Engineering Management) +Управление программной инженерией (Software Engineering Management) Управление программной инженерией может быть определено как приложение вопросов управления (management activities) – планирования, координации, количественной @@ -177,7 +177,7 @@ activities), предпринимаемые для о * В данном контексте, SWEBOK видимо подразумевает, что полученные модели используются для идентификации и анализа рисков, планирования и совершенствования процессов программной инженерии (процессов жизненного цикла, -включая процессы сопровождения), а также процесса управления. +включая процессы сопровождения), а также процесса управления. Секции (подобласти) данной области знаний, связанные с управлением программной инженерией, тесно связаны с секций измерений (количественной оценки). @@ -399,7 +399,7 @@ structure). Это влияет на высокоур относящийся к общей дисциплине управления проектами, применимый и для проектов программных систем). Если возможно, критические аспекты должны быть разрешены, а для задач определены ожидаемые сроки выполнения (расписание), включающие -начало, длительность и окончание (например, в форме PERT-диаграмм*). +начало, длительность и окончание (например, в форме PERT-диаграмм*). * PERT анализ (Program, Evaluation, and Review Technique) – техника оценки ожиданий в отношении длительности (duration) задач проекта, проводимая на @@ -709,7 +709,7 @@ Process (2002 г.), основывающемся на выступать “выпуск на рынок новых продуктов первыми”. Это, в свою очередь, может порождать требование того, что факторы, способствующие достижению цели также должны быть оценены количественно, с тем, чтобы проект могу быть управляем в -процессе достижения заданного результата. Для этого необходимо: +процессе достижения заданного результата. Для этого необходимо: - Определить содержание измерений. Необходимость принять, в каких масштабах – на уровне какой организационной единицы* будут проводиться измерения – только в @@ -764,7 +764,7 @@ Process (2002 г.), основывающемся на стоимость сбора данных, возможность срыва процессных работ при сборе данных (например, в силу недостатка ресурсов), легкость анализа, легкость получения точных и целостных данных и т.п. (см. стандарт ISO 15939-02, раздел 5.2.3 и -приложение C). +приложение C). - Определение наборов <собираемых> данных, а также процедур анализа и ведения отчетности. Это включает в себя коллекцию процедур и расписаний, хранение, проверку, анализ, отчетность и конфигурационное управление собираемыми данными. @@ -833,7 +833,7 @@ Process (2002 г.), основывающемся на предоставляющие данные и проводящие измерения, должны участвовать в процессе обзора и оценки (review) данных для обеспечения соответствия их содержательной стороны и точности, а также выполнения действий, обоснованных результатами -последующего анализа. (см. стандарт ISO 15939-02, раздел 5.3.3 и приложение G). +последующего анализа. (см. стандарт ISO 15939-02, раздел 5.3.3 и приложение G). - Обсуждение результатов. Полученный “информационный продукт” должен быть документирован и передан пользователям и заинтересованным лицам. (см. стандарт ISO 15939-02, раздел 5.3.4). blob - b0d40d1ff14d72f97fe5eb0efaab24458ffa26af blob + 62ebc739583f4da9849badb17d3280307c791289 --- 8_software_engineering_process.markdown +++ 8_software_engineering_process.markdown @@ -5,7 +5,7 @@ Содержит перевод описания области знаний SWEBOK “Software Engineering Process”, с замечаниями и комментариями. -Процесс программной инженерии (Software Engineering Process) +Процесс программной инженерии (Software Engineering Process) Область знаний “Процесс программной инженерии” (Software Engineering Process) может быть рассмотрена на двух уровнях. Первый уровень содержит техническую и @@ -173,7 +173,7 @@ SEPG проводит пилотное внедрен обеспечить согласие и поддержку заинтересованных лиц (в первую очередь, менеджмента) в работах по реализации и изменении процесса; получить возможность развернуть соответствующую инфраструктуру процесса, выделив необходимые ресурсы -и обеспечив распределение обязанностей (ответственности). +и обеспечив распределение обязанностей (ответственности). - Planning – планирование. Задача (цель) – понять (сформулировать) текущие бизнес-цели и потребности в процессе, необходимые отдельным специалистам, проекту и/или организации, в целом; идентифицировать сильные и слабые стороны @@ -448,7 +448,7 @@ SWEBOK отмечает, что ряд моделей Для надлежащего проведения оценки соответствующие методы <оценки> позволяют получить количественные параметры, характеризующие возможности оцениваемого -процесса (или зрелости организации, в целом). +процесса (или зрелости организации, в целом). Например, метод CBA-IPI (CMM-Based Appraisals for Internal Process Improvement) фокусируется на совершенствовании процесса внутри организации, а метод SCE @@ -760,7 +760,7 @@ metrology). отношении “выходов” процесса (получаемого программного продукта или его отдельных элементов). Наблюдения (observations) за выполнением процесса также могут дать дополнительные данные, позволяющие идентифицировать возможные пути -совершенствования процесса. +совершенствования процесса. - Ортогональная классификация дефектов (Orthogonal Defect Classification) – техника, которая может быть использована для связывания (отображения) сбоев с их потенциальными причинами. В данном контексте может быть полезен для @@ -776,7 +776,7 @@ Software Anomalies”, классифицирующи Описанная выше ортогональная классификация дефектов может использоваться для определения категорий различных сбоев и, соответственно, путей обнаружения их причин. Такая классификация добавляет количественные показатели к технике -анализа причин. +анализа причин. - Статистический контроль процесса (Statistical Process Control, SPC) – эффективный путь для определения стабильности (или отсутствия стабильности) процесса. blob - f8ead1a9357c973d15e8e9286c1b7ba48fe33906 blob + 3adfd562f16c24ef4d854d346f5049f91c5c330b --- 9_software_engineering_tools_and_methods.markdown +++ 9_software_engineering_tools_and_methods.markdown @@ -157,12 +157,12 @@ Development, обладающая более ёмки линковщики/загрузчики, а также генераторы кода (за исключением, может быть, объектно-ориентированных средств проектирования, поддерживающих связь с исходным кодом и имеющих тенденцию быть тесно интегрированными с новым -поколением IDE). +поколением IDE). - Интерпретаторы (interpreters). Эти инструменты обеспечивают исполнение программ посредством эмуляции. Они могут поддерживать действия по конструированию программного обеспечения, предоставляя для исполнения программ окружение, более контролируемое и поддающееся наблюдению, чем это обычно -способна сделать та или иная операционная система. +способна сделать та или иная операционная система. - Хочется отметить определенное “слияние”, если так можно выразиться, между компиляторами и интерпретаторами. Ярким тому свидетельством является использование так называемой just-in-time компиляции – компиляции “на лету”, blob - 02535e892ae668e8a5753186bf55013658ce15d2 blob + f16192805ec0688ff10c795456af6b2e5439df87 --- software_lifecycle_models.markdown +++ software_lifecycle_models.markdown @@ -516,7 +516,7 @@ ISO/IEC 15288 (выпущен в 2002 году), фо Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков (используется с разрешения автора): -1. Дефицит специалистов. +1. Дефицит специалистов. 1. Нереалистичные сроки и бюджет. 1. Реализация несоответствующей функциональности. 1. Разработка неправильного пользовательского интерфейса. @@ -627,16 +627,16 @@ Architecting and Software Engineering (MBASE), Боэ - альтернативам организации процесса и технологических решений, закладываемых в продукт - идентификации и разрешению рисков - оценки со стороны заинтересованных лиц (в первую очередь заказчика) - - достижению согласия в том, что можно и необходимо двигаться дальше + - достижению согласия в том, что можно и необходимо двигаться дальше 1. Использование соображений, связанных с рисками, для определения уровня -усилий, необходимого для каждой работы на всех циклах спирали. +усилий, необходимого для каждой работы на всех циклах спирали. 1. Использование соображений, связанных с рисками, для определения уровня -детализации каждого артефакта, создаваемого на всех циклах спирали. +детализации каждого артефакта, создаваемого на всех циклах спирали. 1. Управление жизненным циклом в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек: - Life Cycle Objectives (LCO) - Life Cycle Architecture (LCA) - - Initial Operational Capability (IOC) + - Initial Operational Capability (IOC) 1. Уделение специального внимания проектным работам и артефактам создаваемой системы (включая непосредственно разрабатываемое программное обеспечение, ее окружение, а также эксплуатационные характеристики) и жизненного цикла