commit - 22dec2c442c05d4671e44214b79f232fc36ced95
commit + e3b3be103c332a9662c829b24c37c06c2ab1b7a2
blob - 757866a0d9625898069024162f53b3bb9fe9f44a
blob + f10301070ffba8a7ca8a4b66ab9d91d9e42763d6
--- 0_introduction.markdown
+++ 0_introduction.markdown
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* – Учебный План для Преподавания Программной
Инженерии в ВУЗах<sup>1</sup> (данное название на русском языке представлено в
blob - aa8e08506576f3edcc2e70022a2d2bb94d5f0a37
blob + 15c1f9c1d19c918d215c4643be6a6336d58dc506
--- 10_software_quality.markdown
+++ 10_software_quality.markdown
Все эти процессы поддерживают стремление к достижению качества и, кроме того,
помогают в поиске возможных ошибок. Однако, они отличаются в том, на чем
-концентрируют внимание.
+концентрируют внимание.
Процессы SQM помогают в обеспечении лучшего качества программного обеспечения в
данном проекте. Они предоставляют менеджерам основную информацию по каждому
blob - 4d08f584da1e5897efb5d69eedeca31a6b6cf1fd
blob + 49f2268b51feb173bf128407fb0d4fb5b7c5d9c6
--- 1_software_requirements.markdown
+++ 1_software_requirements.markdown
системные, программные, функциональные, нефункциональные (в частности, атрибуты
качества) и т.п. классический пример (см. рисунок 1) высокоуровневого
структурирования групп требований как требований к продукту описан в работах
-одного из классиков дисциплины управления требованиями – карла вигерса.
+одного из классиков дисциплины управления требованиями – карла вигерса.
![рисунок 1. уровни требований по вигерсу [вигерс, 2003, с.8, рис. 1-1]](images/requirements_wiegers.jpg)
функциональность (поведение) программной системы, которая должна быть создана
разработчиками для предоставления возможности выполнения пользователями своих
обязанностей в рамках бизнес-требований и в контексте пользовательских
-требований.
+требований.
- группа нефункциональных требований (non-functional requirements)
- бизнес-правила (business rules) – включают или связаны с корпоративными
контролируют или влияют на поведение бизнеса”. бизнес-правила часто определяют
распределение ответственности в системе, отвечая на вопрос “кто будет
осуществлять конкретный вариант, сценарий использования” или диктуют появление
-некоторых функциональных требований.
+некоторых функциональных требований.
в контексте дисциплины управления проектами (уже вне проекта разработки
программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов)
группа классов), отражаясь в конечном итоге в программном коде на определенном
языке программирования. существуют специализированные инструментальные средства
и библиотеки, позволяющие разрабатывать и поддерживать приложения, интенсивно
-использующие бизнес-правила.
+использующие бизнес-правила.
Рассматривая бизнес-правила, как артефакты относящиеся к области программных
требований можно отметить, вернее дать одно из пояснений, почему бп относят к
непосредственно использовать программное обеспечение; пользователи могут
описать задачи, которые они решают (планируют решать) с использованием
программной системы, а также ожидания по отношению к атрибутам качества,
-отображаемые в пользовательских требованиях.
+отображаемые в пользовательских требованиях.
- Заказчики (Customers): те, кто отвечают за заказ программного обеспечения
или, в общем случае, являются целевой аудиторией на рынке программного
-обеспечения (образуют целевой рынок ПО);
+обеспечения (образуют целевой рынок ПО);
Стандарт 12207 (его обзор будет приведен в другой главе) определяет более
суженное понятие “заказчика” (обратите внимание – acquirer, а не customer, хотя
обладают “заказчиками” в понимании персонификации тех, кто “заказывает
разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в
идентификации потребностей и обращению к тем, кто может играть роль
-<квалифицированных> “представителей” потребителей;
+<квалифицированных> “представителей” потребителей;
- Регуляторы (Regulators): многие области применения (“домены”) являются
регулируемыми, например, телекоммуникации или банковский сектор. Программное
обеспечение для ряда целевых рынков (в первую очередь, корпоративного сектора)
требует соответствия руководящим документам и прохождения процедур,
-определяемых уполномоченными органами.
+определяемых уполномоченными органами.
- Инженеры по программному обеспечению, иженеры-программисты (Software
Enginner): лица, обладающие обоснованным интересом к разработке программного
пилотных подсистем, реализуемых как самостоятельные (в терминах управления
ресурсами) проекты или бета-версии продуктов; часто прототипы постепенно
трансформируются в результаты проекта и используются для проверки и утверждения
-требований;
+требований;
- “Разъясняющие встречи” - в оригинале звучит как “facilitated meetings”;
достаточно емкий по смыслу термин, пришедший из общей практики менеджмента и
базирующийся на идеях сотрудничества заинтересованных лиц для совместного
Существуют и другие, достаточно эффективные практики, описание которых можно
найти в литературе и которые вы, наверняка, сами используете в своей работе
(например, Requirements Workshop, Role Playing, Storyboarding и т.п.).
-Некоторые из них будут также упоминаться в контексте конкретных методологий.
+Некоторые из них будут также упоминаться в контексте конкретных методологий.
## Анализ требований (Requirements Analysis)
применяемым как для моделирования бизнес-процессов, так и структур данных, в
частности – реляционных баз данных.
- ???
-
+
Так или иначе, вне зависимости от выразительных средств, которые являются лишь
инструментом анализа и фиксирования результатов, результатом анализа требований
должны быть однозначно интерпретируемые требований, реализация которых
описывающих требования – например использование глаголов (will, shall, should,
may, can – перечислены в порядке “убывания директивности”). Действительно,
“программный модуль X отсылает уведомление на e-mail адрес пользователя...”
-несет, мягко говоря, иную смысловую нагрузку, чем “отсылается сообщение”.
+несет, мягко говоря, иную смысловую нагрузку, чем “отсылается сообщение”.
- Отсутствие представления о классификации требований. Подмена одних категорий
требований – другими и смешение требований (например, такое часто случается с
функциональными требованиями, бизнес-требованиями и бизнес-правилами). Как
blob - 6759b3cebb770a276afb1c5fcd74eedccf834d55
blob + b5f793a1ff077877de8d15fe8e2edb699ebea296
--- 2_software_design.markdown
+++ 2_software_design.markdown
Обычно под абстракций, как результатом процесса абстракции, понимают модель,
упрощающую поставленную проблему до рамок, значимых для заданного контекста.
-#### Связанность и соединение (Coupling and Cohesion)
+#### Связанность и соединение (Coupling and Cohesion)
*Связанность (Coupling)* – определяет силу связи (часто, взаимного влияния)
между модулями. Соединение (Cohesion) – определяет как тот или иной элемент
-обеспечивает связь внутри модуля, внутреннюю связь.
+обеспечивает связь внутри модуля, внутреннюю связь.
Значение оригинальных терминов очень близко и, в зависимости от контекста,
“связанность” и “соединение” могут рассматриваться как степень
связанные группы функциональности).
#### Инкапсуляция/сокрытие информации (Encapsulation/information hiding)
-
+
Данная концепция предполагает группировку и упаковку (с точки зрения подготовки
к развертыванию и эксплуатации) элементов и внутренних деталей абстракции (то
есть модели) в отношении реализации с тем, чтобы эти детали (как малозначимые
blob - 22534459b8e7342dd0206cb9287930bac1ec6c57
blob + 7ac63738e12fc6764a8214db1b68f431a19b7fa7
--- 3_software_construction.markdown
+++ 3_software_construction.markdown
Содержит перевод описания области знаний SWEBOK “Software Construction”, с
замечаниями и комментариями.
-Конструирование программного обеспечения (Software Construction)
+Конструирование программного обеспечения (Software Construction)
Термин конструирование программного обеспечения (software construction)
описывает детальное создание рабочей программной системы посредством комбинации
blob - 8000214af2c5f9f75d67efd714cd1043b2355570
blob + 829d7ca79b25dc2e6bfb1a4d3fc78c96eec6cd53
--- 4_software_testing.markdown
+++ 4_software_testing.markdown
что “тестирование программы может использоваться для демонстрации наличия
дефектов, но никогда не покажет их отсутствие”. Основная причина этого в том,
что полное (всеобъемлющее) тестирование недостижимо для реального программного
-обеспечения.
+обеспечения.
#### Проблема неосуществимых путей (The problem of infeasible paths)
blob - 257e0b0c5b14098694b407f962f5ccf88d2bfa71
blob + 6bed2f44578167adfacd234d884ae08b32594e55
--- 5_software_maintenance.markdown
+++ 5_software_maintenance.markdown
Содержит перевод описания области знаний SWEBOK “Software Maintenance”, с
замечаниями и комментариями.
-Сопровождение программного обеспечения (Software Maintenance)
+Сопровождение программного обеспечения (Software Maintenance)
Результат усилий по разработке программного обеспечения состоит в передачи в
эксплуатацию программного продукта, удовлетворяющего требованиям пользователей.
* Как мы видим из описания данных работ в SWEBOK, речь идет не только о
компонентах системы, но и о ее окружении, включая другие системы,
-функционирующие в том же операционном/системном окружении.
+функционирующие в том же операционном/системном окружении.
Запросы на изменения<sup>2</sup> (change requests - CR), иногда упоминаемые как
запросы на модификацию (modification request - MR), часто также называемые
приоритетности и стоимости модификаций, связанных с поступившим запросом или
сообщенной проблемой.
- Анализ влияния (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
процессов и процедур конфигурационного управления. Для этого может быть
необходимо введение соответствующих полномочий и назначение обязанностей по
контролю выполнения задач SCM. Аналогичные полномочия и обязанности по надзору
-над SCM-процессом могут существовать в контексте SQA-деятельности.
+над SCM-процессом могут существовать в контексте SQA-деятельности.
Использование интегрированных SCM-инструментов с возможностью контроля процесса
может сделать процедуру надзора более легкой и прозрачной. Некоторые
blob - 39aa5fa430e002c25035ee3fbab3a4bdd1770bad
blob + e7a7acfc91f4d6992dd346054b453b9324f59599
--- 7_software_engineering_management.markdown
+++ 7_software_engineering_management.markdown
Содержит перевод описания области знаний SWEBOK “Software Engineering
Management”, с замечаниями и комментариями.
-Управление программной инженерией (Software Engineering Management)
+Управление программной инженерией (Software Engineering Management)
Управление программной инженерией может быть определено как приложение вопросов
управления (management activities) – планирования, координации, количественной
* В данном контексте, SWEBOK видимо подразумевает, что полученные модели
используются для идентификации и анализа рисков, планирования и
совершенствования процессов программной инженерии (процессов жизненного цикла,
-включая процессы сопровождения), а также процесса управления.
+включая процессы сопровождения), а также процесса управления.
Секции (подобласти) данной области знаний, связанные с управлением программной
инженерией, тесно связаны с секций измерений (количественной оценки).
относящийся к общей дисциплине управления проектами, применимый и для проектов
программных систем). Если возможно, критические аспекты должны быть разрешены,
а для задач определены ожидаемые сроки выполнения (расписание), включающие
-начало, длительность и окончание (например, в форме PERT-диаграмм*).
+начало, длительность и окончание (например, в форме PERT-диаграмм*).
* PERT анализ (Program, Evaluation, and Review Technique) – техника оценки
ожиданий в отношении длительности (duration) задач проекта, проводимая на
выступать “выпуск на рынок новых продуктов первыми”. Это, в свою очередь, может
порождать требование того, что факторы, способствующие достижению цели также
должны быть оценены количественно, с тем, чтобы проект могу быть управляем в
-процессе достижения заданного результата. Для этого необходимо:
+процессе достижения заданного результата. Для этого необходимо:
- Определить содержание измерений. Необходимость принять, в каких масштабах –
на уровне какой организационной единицы* будут проводиться измерения – только в
стоимость сбора данных, возможность срыва процессных работ при сборе данных
(например, в силу недостатка ресурсов), легкость анализа, легкость получения
точных и целостных данных и т.п. (см. стандарт ISO 15939-02, раздел 5.2.3 и
-приложение C).
+приложение C).
- Определение наборов <собираемых> данных, а также процедур анализа и ведения
отчетности. Это включает в себя коллекцию процедур и расписаний, хранение,
проверку, анализ, отчетность и конфигурационное управление собираемыми данными.
предоставляющие данные и проводящие измерения, должны участвовать в процессе
обзора и оценки (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
Содержит перевод описания области знаний SWEBOK “Software Engineering Process”,
с замечаниями и комментариями.
-Процесс программной инженерии (Software Engineering Process)
+Процесс программной инженерии (Software Engineering Process)
Область знаний “Процесс программной инженерии” (Software Engineering Process)
может быть рассмотрена на двух уровнях. Первый уровень содержит техническую и
обеспечить согласие и поддержку заинтересованных лиц (в первую очередь,
менеджмента) в работах по реализации и изменении процесса; получить возможность
развернуть соответствующую инфраструктуру процесса, выделив необходимые ресурсы
-и обеспечив распределение обязанностей (ответственности).
+и обеспечив распределение обязанностей (ответственности).
- Planning – планирование. Задача (цель) – понять (сформулировать) текущие
бизнес-цели и потребности в процессе, необходимые отдельным специалистам,
проекту и/или организации, в целом; идентифицировать сильные и слабые стороны
Для надлежащего проведения оценки соответствующие методы <оценки> позволяют
получить количественные параметры, характеризующие возможности оцениваемого
-процесса (или зрелости организации, в целом).
+процесса (или зрелости организации, в целом).
Например, метод CBA-IPI (CMM-Based Appraisals for Internal Process Improvement)
фокусируется на совершенствовании процесса внутри организации, а метод SCE
отношении “выходов” процесса (получаемого программного продукта или его
отдельных элементов). Наблюдения (observations) за выполнением процесса также
могут дать дополнительные данные, позволяющие идентифицировать возможные пути
-совершенствования процесса.
+совершенствования процесса.
- Ортогональная классификация дефектов (Orthogonal Defect Classification) –
техника, которая может быть использована для связывания (отображения) сбоев с
их потенциальными причинами. В данном контексте может быть полезен для
Описанная выше ортогональная классификация дефектов может использоваться для
определения категорий различных сбоев и, соответственно, путей обнаружения их
причин. Такая классификация добавляет количественные показатели к технике
-анализа причин.
+анализа причин.
- Статистический контроль процесса (Statistical Process Control, SPC) –
эффективный путь для определения стабильности (или отсутствия стабильности)
процесса.
blob - f8ead1a9357c973d15e8e9286c1b7ba48fe33906
blob + 3adfd562f16c24ef4d854d346f5049f91c5c330b
--- 9_software_engineering_tools_and_methods.markdown
+++ 9_software_engineering_tools_and_methods.markdown
линковщики/загрузчики, а также генераторы кода (за исключением, может быть,
объектно-ориентированных средств проектирования, поддерживающих связь с
исходным кодом и имеющих тенденцию быть тесно интегрированными с новым
-поколением IDE).
+поколением IDE).
- Интерпретаторы (interpreters). Эти инструменты обеспечивают исполнение
программ посредством эмуляции. Они могут поддерживать действия по
конструированию программного обеспечения, предоставляя для исполнения программ
окружение, более контролируемое и поддающееся наблюдению, чем это обычно
-способна сделать та или иная операционная система.
+способна сделать та или иная операционная система.
- Хочется отметить определенное “слияние”, если так можно выразиться, между
компиляторами и интерпретаторами. Ярким тому свидетельством является
использование так называемой just-in-time компиляции – компиляции “на лету”,
blob - 02535e892ae668e8a5753186bf55013658ce15d2
blob + f16192805ec0688ff10c795456af6b2e5439df87
--- software_lifecycle_models.markdown
+++ software_lifecycle_models.markdown
Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков
(используется с разрешения автора):
-1. Дефицит специалистов.
+1. Дефицит специалистов.
1. Нереалистичные сроки и бюджет.
1. Реализация несоответствующей функциональности.
1. Разработка неправильного пользовательского интерфейса.
- альтернативам организации процесса и технологических решений, закладываемых в продукт
- идентификации и разрешению рисков
- оценки со стороны заинтересованных лиц (в первую очередь заказчика)
- - достижению согласия в том, что можно и необходимо двигаться дальше
+ - достижению согласия в том, что можно и необходимо двигаться дальше
1. Использование соображений, связанных с рисками, для определения уровня
-усилий, необходимого для каждой работы на всех циклах спирали.
+усилий, необходимого для каждой работы на всех циклах спирали.
1. Использование соображений, связанных с рисками, для определения уровня
-детализации каждого артефакта, создаваемого на всех циклах спирали.
+детализации каждого артефакта, создаваемого на всех циклах спирали.
1. Управление жизненным циклом в контексте обязательств всех заинтересованных
лиц на основе трех контрольных точек:
- Life Cycle Objectives (LCO)
- Life Cycle Architecture (LCA)
- - Initial Operational Capability (IOC)
+ - Initial Operational Capability (IOC)
1. Уделение специального внимания проектным работам и артефактам создаваемой
системы (включая непосредственно разрабатываемое программное обеспечение, ее
окружение, а также эксплуатационные характеристики) и жизненного цикла
