commit - 376dbe710b5872a29809aed59fd6dcb080c9f337
commit + e0436dbcd5fbc42ecec0b95d82d35ad456e3f223
blob - 5a25b665604c9f0a0d614581ac840e95ade82fdb
blob + 7e81b2e7754c5fd69292b725ead4c5a7b3cd1e85
--- 0_introduction.markdown
+++ 0_introduction.markdown
## Программная инженерия как дисциплина
В 1958 всемирно известный статистик Джон Тьюкей (John Tukey) впервые ввел
-термин *software* – программное обеспечение. В 1972 году IEEE* выпустил первый
+термин *software* – программное обеспечение. В 1972 году IEEE[^1] выпустил первый
номер *Transactions on Software Engineering* – Труды по Программной Инженерии.
Первый целостный взгляд на эту область профессиональной деятельности появился
1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730
Наконец, в 1990 году началось планирование всеобъемлющих *международных*
стандартов, в основу которых легли концепции и взгляды стандарта IEEE Std 1074
-и результатов работы образованной в 1987 году совместной комиссии ISO/IEC JTC
-1<sup>2</sup>. В 1995 году группа этой комиссии SC7 “Software Engineering”
+и результатов работы образованной в 1987 году совместной комиссии ISO/IEC JTC 1[^2].
+В 1995 году группа этой комиссии SC7 “Software Engineering”
выпустила первую версию международного стандарта ISO/IEC 12207 “Software
Lifecycle Processes”. Этот стандарт стал первым опытом создания единого общего
взгляда на программную инженерию. Соответствующий национальный стандарт России
– ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207, 1999] содержит полный аутентичный
перевод текста международного стандарта ISO/IEC 12207-95 (1995 года).
-В свою очередь, IEEE и ACM<sup>3</sup>, начав совместные работы еще в 1993 году
+В свою очередь, IEEE и ACM[^3], начав совместные работы еще в 1993 году
с кодекса этики и профессиональной практики в данной области (ACM/IEEE-CS Code
of Ethics and Professional Practice), к 2004 году сформулировали два ключевых
описания того, что сегодня мы и называем основами программной инженерии –
просто “SWEBOK” [SWEBOK, 2004];
- *Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree
Programs in Software Engineering* – Учебный План для Преподавания Программной
-Инженерии в ВУЗах<sup>1</sup> (данное название на русском языке представлено в
+Инженерии в ВУЗах (данное название на русском языке представлено в
вольном смысловом переводе) [SE, 2004].
--------------
-
-- 1 IEEE - Computer Society of the Institute for Electrical and Electronic
+[^1]: IEEE - Computer Society of the Institute for Electrical and Electronic
Engineers, IEEE Computer Society – IEEE-CS (Компьютерное Общество) или просто
-IEEE. https://www.ieee.org
-- 2 ISO – International Organization for Standardization. https://www.iso.ch ;
+IEEE. https://www.ieee.org
+
+[^2]: ISO – International Organization for Standardization. https://www.iso.ch ;
IEC – International Electrotechnical Commission; JTC 1 – Joint Technical
Committee 1, Information technology
-- 3 ACM – Association of Computer Machinery
+[^3]: ACM – Association of Computer Machinery
+
Оба стандарта стали результатом консенсуса ведущих представителей индустрии и
признанных авторитетов в области программной инженерии - по аналогии с тем, как
был создан PMI PMBOK. Так мы пришли к сегодняшнему состоянию Software
SWEBOK включал “лишь” 10 *областей знаний* (*knowledge areas*, KA). При этом,
что справедливо и для PMBOK, добавление новых областей знаний в SWEBOK
достаточно прозрачно. Все, что для этого необходимо, зрелость (или, по крайней
-мере, явный и быстрый процесс достижения зрелости) и общепринятость
+мере, явный и быстрый процесс достижения зрелости) и общепринятость[^4]
соответствующей области знаний, если это не приведет к серьезному усложнению
-SWEBOK. (Концепция “общепринятости” - generally accepted – определена в IEEE
+SWEBOK.
+
+[^4]: Концепция “общепринятости” - generally accepted – определена в IEEE
Std 1490-1998, Adoption of PMI Standard — A Guide to the Project Management
Body of Knowledge
blob - b5f793a1ff077877de8d15fe8e2edb699ebea296
blob + 106abb9f63ec35345bed7fdc99c8118bb5ab3441
--- 2_software_design.markdown
+++ 2_software_design.markdown
Распределение (и выполнение) по различным узлам обработки в терминах
аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших
вопросов данной темы – использование связующего программного обеспечения
-(middleware<sup>1</sup>)
+(middleware[^5])
-1 часто middleware переводят как “промежуточное программное обеспечение”. Такой
+[^5]: Часто middleware переводят как “промежуточное программное обеспечение”. Такой
вариант перевода, к сожалению, рассматривает связующее ПО во второстепенной –
“промежуточной” роли. Читатель, безусловно, может не согласиться с такой
трактовкой, однако, многолетняя практика автора в обсуждении архитектурных
наследования);
- *Диаграммы компонентов или компонентные диаграммы (Component diagrams)*: в
определенной степени аналогичны диаграммам классов, однако, в силу специфики
-концепции или понятия компонента<sup>2</sup>, обычно, представляются в другой
+концепции или понятия компонента[^6], обычно, представляются в другой
визуальной форме;
-2 здесь необходимо отметить различие в понятиях класса (или объекта) и
-компонента: компонент рассматривается как физически реализуемый элемент
-программного обеспечения, несущий <в определенной степени> самодостаточную
-логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде
-комплекса классов);
- *Карточки <функциональной> ответственности и связей класса (Class
responsibility collaborator card, CRC)*: используются для обозначения имени
класса, его ответственности (то есть, что он должен делать) и других сущностей
- *Структурные схемы (Structure charts)*: описываю структуру вызовов в
программах (какой модуль вызывает, кем и как вызываем).
+[^6]: Здесь необходимо отметить различие в понятиях класса (или объекта) и
+компонента: компонент рассматривается как физически реализуемый элемент
+программного обеспечения, несущий <в определенной степени> самодостаточную
+логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде
+комплекса классов);
+
### Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view)
Следующие нотации и языки (часть из которых – графические, часть - текстовые)
blob - 46d99b8d437cd2ab8eae584f4af8dfe5107d49f8
blob + 02a3e97adb5e3a31bf6e4bde9441b03079c8f3c8
--- 5_software_maintenance.markdown
+++ 5_software_maintenance.markdown
большинстве организаций, разработка программных систем явно в фаворе, по
сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно
начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний
-ITIL<sup>1</sup> – IT Infrastructure Library, уделяющей особое внимание
+ITIL[^7] – IT Infrastructure Library, уделяющей особое внимание
вопросам поддержки и сопровождения инфраструктуры информационных технологий). В
большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций
организаций непосредственно в разработку программных систем, с целью увеличения
программного обеспечения и естественной интеграции такой деятельности в
бизнес-процессы подразделений информационных технологий.
-* ITIL, в частности, определяет три аспекта управления жизненным циклом
+[^7]: ITIL, в частности, определяет три аспекта управления жизненным циклом
приложений – определение требований, проектирование и разработку, и, наконец,
сопровождение. Все это, в контексте программного обеспечения, относится к
деятельности по управлению приложениями – Application Management в ITIL ICT
необходимыми знаниями о специфике системы (в идеальном случае, иметь полное
представление о системе на уровне ее разработчиков) – ее содержании и
структуре. Инженеры используют эти знания для выполнения работ по анализу
-влияния, идентифицируя все системы<sup>1</sup> и программные продукты, на
+влияния, идентифицируя все системы[^8] и программные продукты, на
которые могут повлиять изменения, вносимые в обслуживаемую программную систему.
При этом, должны быть определены риски, связанные с внесением обсуждаемых
изменений.
-* Как мы видим из описания данных работ в SWEBOK, речь идет не только о
+[^8]: Как мы видим из описания данных работ в SWEBOK, речь идет не только о
компонентах системы, но и о ее окружении, включая другие системы,
функционирующие в том же операционном/системном окружении.
-Запросы на изменения<sup>2</sup> (change requests - CR), иногда упоминаемые как
+Запросы на изменения[^9] (change requests - CR), иногда упоминаемые как
запросы на модификацию (modification request - MR), часто также называемые
отчетами о проблемах (problem report - PR), должны анализироваться и
трансформироваться в термины программной системы. Эти шаги выполняются после
управления, и фиксируется в системе конфигурационного управления (см. область
знаний Configuration Management).
-** Обычно запросы на изменения разделяют на две категории – “пожелания”
+[^9]: Обычно запросы на изменения разделяют на две категории – “пожелания”
(suggestions), относящиеся к расширению системы, и “отчеты об ошибках” (defect
или bug report), направляемые пользователями в службу сопровождения или
инженерами по тестированию разработчикам.
ресурсов без явно выраженной и количественно определяемой отдачи для
организации.
-#### Проблемы кадрового обеспечения<sup>3</sup> (Staffing)
+#### Проблемы кадрового обеспечения[^10] (Staffing)
Данная тема касается вопросов привлечения и удержания квалифицированного
персонала по сопровождению. Часто, работа по сопровождению не выглядит
качества информационного обеспечения бизнеса, что сказывается, в подавляющем
большинстве случаев, и на бизнесе, как таковом.
-*** такой перевод, вместо просто “кадрового обеспечения”, в большей степени
+[^10]: Такой перевод, вместо просто “кадрового обеспечения”, в большей степени
соответствует принятому использованию термина staffing. Часто, staffing
подразумевает и высокую текучесть кадров.
Несмотря на то, что разработка программных системы, обычно, занимает от
несколько месяцев (что более типично) до нескольких лет, сопровождение (как
деятельность по поддержке использования) и активная эксплуатация систем
-занимает несколько лет, а то и более <sup>4</sup> (5-10-...). Проведение оценки
+занимает несколько лет, а то и более[^11] (5-10-...). Проведение оценки
ресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для
сопровождения должны быть оценены и заложены в бюджет еще при разработке
системы. Планирование работ по сопровождению должно начинаться одновременно с
качества (отмечается в IEEE 1061-98 Standard for a Software Quality Metrics
Methodology).
-*** эта оценка согласуется и с опытом Сергея Орлика, когда в начале 90-х он
+[^11]: Эта оценка согласуется и с опытом Сергея Орлика, когда в начале 90-х он
принимал непосредственное участие в проектировании и разработке системы
автоматизации добровольного медицинского страхования (в одной из крупнейших
российских страховых компаний), выведенной, в дальнейшем, из эксплуатации на
blob - 18c5450074f46e95c5349cc76d7e076b4c68822e
blob + f78dc25f689f5b1b60e6d3a65fcf0ce4149c4680
--- 6_software_configuration_management.markdown
+++ 6_software_configuration_management.markdown
В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207, конфигурационное
управление в области программного обеспечения (“6.2 Управление конфигурацией”
-по ГОСТ) – Software Configuration Management (SCM<sup>1</sup>) – один из
+по ГОСТ) – Software Configuration Management (SCM[^12]) – один из
вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающих
проектный менеджмент, деятельность по разработке и сопровождению, обеспечению
качества, а также, заказчиков и пользователей конечного продукта.
-* в ряде источников можно увидеть аббревиатуру SCCM – Software Configuration
+[^12]: В ряде источников можно увидеть аббревиатуру SCCM – Software Configuration
and Change Management. При том, что в понимании SWEBOK и соответствующих
стандартов, содержание SCM и SCCM тождественно, термин SCCM иногда используется
для того, чтобы подчеркнуть принципиальную значимость управления изменениями
blob - c851acf998140424efaf3422eddf3c38b762ddab
blob + 265b3cbf3b7f5e91d0bb6f6eb87f1f75aaa43b00
--- 7_software_engineering_management.markdown
+++ 7_software_engineering_management.markdown
сбалансировано с другими аспектами программной инженерии, не превращая Software
Engineering Management (SEM) в дорогостоящую, но бесполезную работу.
Эффективный менеджмент требует комбинации соответствующих систематических и
-упорядоченных подходов в управлении и соответствующего опыта<sup>1</sup>.
+упорядоченных подходов в управлении и соответствующего опыта[^13].
-* например, на практике практически невозможно добиться статуса PMP – Project
+[^13]: Например, на практике практически невозможно добиться статуса PMP – Project
Management Professional по версии Project Management Institute (PMI), если
претендент не обладает серьезным практическим опыт управления проектами и
пытается сдать соответствующий экзамен только на основе штудирования PMBOK и
принятыми в организации
- Измерения (Measurement) связаны с определением величин и характеристикой
различных аспектов программной инженерии (продуктов, процессов и т.п.), а также
-разработкой на их основе моделей<sup>2</sup> с использованием статистических
+разработкой на их основе моделей[^14] с использованием статистических
методов (и данных), экспертных знаний и других техник.
-* В данном контексте, SWEBOK видимо подразумевает, что полученные модели
+[^14]: В данном контексте, SWEBOK видимо подразумевает, что полученные модели
используются для идентификации и анализа рисков, планирования и
совершенствования процессов программной инженерии (процессов жизненного цикла,
включая процессы сопровождения), а также процесса управления.
## Планирование программного проекта (Software Project Planning)
-Процесс планирования является итеративным<sup>2</sup> и базируется на
+Процесс планирования является итеративным[^15] и базируется на
содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить,
что различные фазы проекта перекрываются (что, например, специально отмечает
PMBOK) и вместе с определением содержания, детализацией требований и
обязанности в части управления планом проекта, его оценкой и порядка пересмотра
различных аспектов проекта.
-* позднее, при обсуждении жизненного цикла и, в частности, спиральной модели
+[^15]: Позднее, при обсуждении жизненного цикла и, в частности, спиральной модели
разработки, мы будем рассматривать ключевые идеи итеративного подхода.
### Планирование процесса (Process Planning)
успешного выполнения проекта является управленческая деятельность по ведению
оценки и измерений, мониторинга, контроля и отчетности.
-### Реализация планов<sup>4</sup> (Implementation of Plans)
+### Реализация планов[^16] (Implementation of Plans)
Проект инициируется и проектные работы выполняются в соответствии с планом. В
процессе выполнения используются соответствующие ресурсы (например, усилия
персонала, бюджет) и производятся необходимые результаты (deliverables; активы,
артефакты проекта – например, архитектурные документы, тестовые сценарии).
-* в SWEBOK используется как “план проекта” в единственном числе, так и “планы”
+[^16]: В SWEBOK используется как “план проекта” в единственном числе, так и “планы”
– во множественном числе, подразумевающие, судя по контексту, отдельные задачи
проекта.
blob - 433d38e060d9606b132462f4f7abd0e2d6ed6d44
blob + b8cfbe31d1930eafecf227beb29441f5ce69a647
--- 8_software_engineering_process.markdown
+++ 8_software_engineering_process.markdown
Модели жизненного цикла задают высокоуровневое определение фаз (стадий)
разработки программного обеспечения. Их целью не является предоставление
детального определения, но концентрируется на ключевых работах и их
-взаимосвязях. Примерами таких моделей<sup>1</sup> являются водопадная
+взаимосвязях. Примерами таких моделей[^17] являются водопадная
(каскадная - waterfall), модель прототипирования, эволюционной разработки,
инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения
и критерии выбора моделей, ссылки на некоторые из которых, в частности, даны в
оригинальной версии SWEBOK.
-* базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе.
+
+[^17]: Базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе.
### Процессы жизненного цикла программного обеспечения (Software Life Cycle Processes)
Стандарт ISO/IEC 15504 (SPICE) определяет типовую (exemplar) модель оценки и
требования соответствия к другим моделям. В каждом конкретном случае
используется та или иная существующая модель – CMM-SW, CMMI,
-Bootstrap<sup>2</sup>. Также имеются и другие модели, например, ISO 9000-3
+Bootstrap[^18]. Также имеются и другие модели, например, ISO 9000-3
(теперь именуемый как ISO 90003) “Software and Systems Engineering - Guidelines
for the Application of ISO9001:2000 to Computer Software”, являющаяся
приложением общей модели качества ISO 9001 “Quality Management Systems -
Requirements” к программной инженерии. Кроме того, существуют частные модели,
охватывающие, например, только вопросы документирования, проектирования и т.п.
-* В 1990 году стартовала европейская инициатива European Strategic Program for
+
+[^18]: В 1990 году стартовала европейская инициатива European Strategic Program for
Information Technology (ESPRIT), целью которой было внедрение современных
программных технологий в Европе. В основу инициативы легли работы Уотса Хампфри
(Watts S. Humphrey) – идеолога CMMI, PSP (People Software Process) и многих
Например, метод CBA-IPI (CMM-Based Appraisals for Internal Process Improvement)
фокусируется на совершенствовании процесса внутри организации, а метод SCE
-(Software Capability Evaluation) касается процессов у подрядчиков<sup>3</sup>.
+(Software Capability Evaluation) касается процессов у подрядчиков[^19].
Требования в обоих типах методов отражают те лучшие практики оценки, которые
описаны в стандарте ISO 15504. Эти методы были разработаны для модели CMM-SW. С
выходом CMMI (интегрированной модели, объединяющей различные модели CMM),
направлена ли оценка на совершенствование процессов или проводится в контексте
контракта/договора подряда.
-* SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment
+[^19]: SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment
– внутренняя деятельность в организации, направленная на оценку и
совершенствование собственного процесса в рамках всей организации. Evaluation
подразумевает аудит и мониторинг процессов поставщика (подрядчика, исполнителя)
заданных вех или, более точно (так как измерения, все же, выходят за рамки вех
конкретных проектов, если, конечно, сама SPI-деятельность не позиционировать
как проект, что, конечно, возможно), так называемых “базовых линий”
-(baseline<sup>4</sup>).
+(baseline[^20]).
-* термин baseline обычно используется в контексте управления изменениями,
+[^20]: Термин baseline обычно используется в контексте управления изменениями,
требованиями и, часто, конфигурациями, в целом, для именования временных
“срезов” всего комплекса соответствующих активов.
Необходимо отметить, что в литературе встречаются некоторые терминологические
отличия, например, термин “метрика” (metric) часто используется вместо термина
-“измерение” (measure)<sup>5</sup>.
+“измерение” (measure)[^21].
-** В данном переводе эти термины используются взаимозаменяемым образом, за
+[^21]: В данном переводе эти термины используются взаимозаменяемым образом, за
исключением случаев, когда контекст обсуждения предполагает разделение процесса
измерения – “измерения”, как такового, и критериев/параметров или результатов
измерения – “метрик”.
соответствующего инструментария, главный ресурс, который нуждается управлении –
персонал. Как результат, наиболее важные метрики касаются оценки продуктивности
команд и процессов (например, может использоваться оценка функциональных точек,
-производимых на единицу трудозатрат<sup>5</sup. – “person-effort”), а также,
+производимых на единицу трудозатрат[^22]. – “person-effort”), а также,
ассоциированного с этим уровня опыта в программной инженерии, в целом, и в
отдельных технологиях, в частности.
-* трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или
+[^22]: Трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или
“человеко-месяц”; здесь полезно обратиться к юбилейному второму изданию
классического труда Фреда Брукса “Мифический человеко-месяц” [Брукс, 1995].
приводят к желаемому результату, когда процессы полностью или частично остаются
лишь на бумаге.
-### <sup>6</sup> Измерения в отношении программных продуктов (Software Product Measurement)
+### Измерения в отношении программных продуктов[^23] (Software Product Measurement)
Измерения в отношении программного продукта включают количественную оценку его
размера, структуры и качества.
-* данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке
+[^23]: Данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке
оригинального варианта SWEBOK 2004, поэтому, далее, нумерация тем смещена.
#### Оценка размера (Size measurement)
