commit - 824fc889d10debe960fe260f36df3ae8f5ad5ead
commit + 48c63dee92b321ed49c64cb7a2b481a47e98d6af
blob - 859bf36717c3e9ed6fd1d9d32684ae4937a25599
blob + c3f385153806b2b312ff8d616ab8ba9089e5de3f
--- 0_introduction.md
+++ 0_introduction.md
## Программная инженерия как дисциплина
В 1958 всемирно известный статистик Джон Тьюкей (John Tukey) впервые ввел
-термин *software* – программное обеспечение. В 1972 году IEEE[^1] выпустил первый
+термин *software* – программное обеспечение. В 1972 году IEEE[^0_1] выпустил первый
номер *Transactions on Software Engineering* – Труды по Программной Инженерии.
Первый целостный взгляд на эту область профессиональной деятельности появился
1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730
Наконец, в 1990 году началось планирование всеобъемлющих *международных*
стандартов, в основу которых легли концепции и взгляды стандарта IEEE Std 1074
-и результатов работы образованной в 1987 году совместной комиссии ISO/IEC JTC 1[^2].
+и результатов работы образованной в 1987 году совместной комиссии ISO/IEC JTC 1[^0_2].
В 1995 году группа этой комиссии SC7 “Software Engineering”
выпустила первую версию международного стандарта ISO/IEC 12207 “Software
Lifecycle Processes”. Этот стандарт стал первым опытом создания единого общего
– ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207, 1999] содержит полный аутентичный
перевод текста международного стандарта ISO/IEC 12207-95 (1995 года).
-В свою очередь, IEEE и ACM[^3], начав совместные работы еще в 1993 году
+В свою очередь, IEEE и ACM[^0_3], начав совместные работы еще в 1993 году
с кодекса этики и профессиональной практики в данной области (ACM/IEEE-CS Code
of Ethics and Professional Practice), к 2004 году сформулировали два ключевых
описания того, что сегодня мы и называем основами программной инженерии –
Инженерии в ВУЗах (данное название на русском языке представлено в
вольном смысловом переводе) [SE, 2004].
-[^1]: IEEE - Computer Society of the Institute for Electrical and Electronic
+[^0_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 ;
+[^0_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
+[^0_3]: ACM – Association of Computer Machinery
Оба стандарта стали результатом консенсуса ведущих представителей индустрии и
признанных авторитетов в области программной инженерии - по аналогии с тем, как
SWEBOK включал “лишь” 10 *областей знаний* (*knowledge areas*, KA). При этом,
что справедливо и для PMBOK, добавление новых областей знаний в SWEBOK
достаточно прозрачно. Все, что для этого необходимо, зрелость (или, по крайней
-мере, явный и быстрый процесс достижения зрелости) и общепринятость[^4]
+мере, явный и быстрый процесс достижения зрелости) и общепринятость[^0_4]
соответствующей области знаний, если это не приведет к серьезному усложнению
SWEBOK.
-[^4]: Концепция “общепринятости” - generally accepted – определена в IEEE
+[^0_4]: Концепция “общепринятости” - generally accepted – определена в IEEE
Std 1490-1998, Adoption of PMI Standard — A Guide to the Project Management
Body of Knowledge
blob - 8adb7001783259c95ad25046adba34e3c17a978e
blob + d02266df811e2001676eccdd567227e02abcad4c
--- 10_software_quality.md
+++ 10_software_quality.md
образом, в виде соответствующих "подтем" в рамках формата SWEBOK, так как,
будучи тесно связанными и взаимодополняющими, проверка и аттестация все же
обладают и самостоятельным содержанием), проверка (верификация) и аттестация –
-Validation and Verification (V&V*) – рассмотрены в SWEBOK в рамках единой темы.
+Validation and Verification (V&V[^10_1]) – рассмотрены в SWEBOK в рамках единой темы.
В свою очередь, они являются самостоятельными темами, например, в стандарте
жизненного цикла программного обеспечения 12207. Стандарт IEEE 1059-93 “IEEE
Guide for Software Verification and Validation Plans” дает такое определение
-V&V*: “Проверка и аттестация программного обеспечения – упорядоченный подход в
+V&V: “Проверка и аттестация программного обеспечения – упорядоченный подход в
оценке программных продуктов, применяемый на протяжении всего жизненного цикла.
Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на
обеспечение качества как неотъемлемой характеристики программного обеспечения и
понимании управления требованиями, а потребности пользователей, ради
удовлетворения которых создается программное обеспечение).
-* здесь и далее в переводе намеренно используется обозначение V&V, как
+[^10_1]: Здесь и далее в переводе намеренно используется обозначение V&V, как
общепринятое в индустрии программного обеспечения
V&V напрямую адресуется вопросам качества программного обеспечения и использует
blob - 4ce897dac446894dc2a9d79b05162e7fe4c78181
blob + 8527710f27d1b1221de2ea82d2256986da76e76b
--- 2_software_design.md
+++ 2_software_design.md
Распределение (и выполнение) по различным узлам обработки в терминах
аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших
вопросов данной темы – использование связующего программного обеспечения
-(middleware[^5])
+(middleware[^2_1])
-[^5]: Часто middleware переводят как “промежуточное программное обеспечение”. Такой
+[^2_1]: Часто middleware переводят как “промежуточное программное обеспечение”. Такой
вариант перевода, к сожалению, рассматривает связующее ПО во второстепенной –
“промежуточной” роли. Читатель, безусловно, может не согласиться с такой
трактовкой, однако, многолетняя практика автора в обсуждении архитектурных
наследования);
- *Диаграммы компонентов или компонентные диаграммы (Component diagrams)*: в
определенной степени аналогичны диаграммам классов, однако, в силу специфики
-концепции или понятия компонента[^6], обычно, представляются в другой
+концепции или понятия компонента[^2_2], обычно, представляются в другой
визуальной форме;
- *Карточки <функциональной> ответственности и связей класса (Class
responsibility collaborator card, CRC)*: используются для обозначения имени
- *Структурные схемы (Structure charts)*: описываю структуру вызовов в
программах (какой модуль вызывает, кем и как вызываем).
-[^6]: Здесь необходимо отметить различие в понятиях класса (или объекта) и
+[^2_2]: Здесь необходимо отметить различие в понятиях класса (или объекта) и
компонента: компонент рассматривается как физически реализуемый элемент
программного обеспечения, несущий <в определенной степени> самодостаточную
логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде
Хотя корни объектно-ориентированного проектирования лежат в абстракции данных
(к которым добавлены поведенческие характеристики), так называемый
responsibility-driven design или проектирование на основе <функциональной>
-ответственности по SWEBOK* может рассматриваться как альтернатива
+ответственности по SWEBOK[^2_3] может рассматриваться как альтернатива
объектно-ориентированному проектированию.
-*Такое противопоставление – достаточно спорный вопрос, так как функциональная
+[^2_3]: Такое противопоставление – достаточно спорный вопрос, так как функциональная
ответственность столь же близка принципам современного
объектно-ориентированного проектирования, сколь и абстракция данных. Это вопрос
эволюционирования взглядов и степени их консерватизма.
blob - 84df82f3168f350be60fe148581deb24566b28ca
blob + bc967963990b2b8a36cbfc7b94d5140347d2cc30
--- 5_software_maintenance.md
+++ 5_software_maintenance.md
большинстве организаций, разработка программных систем явно в фаворе, по
сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно
начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний
-ITIL[^7] – IT Infrastructure Library, уделяющей особое внимание
+ITIL[^5_1] – IT Infrastructure Library, уделяющей особое внимание
вопросам поддержки и сопровождения инфраструктуры информационных технологий). В
большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций
организаций непосредственно в разработку программных систем, с целью увеличения
программного обеспечения и естественной интеграции такой деятельности в
бизнес-процессы подразделений информационных технологий.
-[^7]: ITIL, в частности, определяет три аспекта управления жизненным циклом
+[^5_1]: ITIL, в частности, определяет три аспекта управления жизненным циклом
приложений – определение требований, проектирование и разработку, и, наконец,
сопровождение. Все это, в контексте программного обеспечения, относится к
деятельности по управлению приложениями – Application Management в ITIL ICT
необходимыми знаниями о специфике системы (в идеальном случае, иметь полное
представление о системе на уровне ее разработчиков) – ее содержании и
структуре. Инженеры используют эти знания для выполнения работ по анализу
-влияния, идентифицируя все системы[^8] и программные продукты, на
+влияния, идентифицируя все системы[^5_2] и программные продукты, на
которые могут повлиять изменения, вносимые в обслуживаемую программную систему.
При этом, должны быть определены риски, связанные с внесением обсуждаемых
изменений.
-[^8]: Как мы видим из описания данных работ в SWEBOK, речь идет не только о
+[^5_2]: Как мы видим из описания данных работ в SWEBOK, речь идет не только о
компонентах системы, но и о ее окружении, включая другие системы,
функционирующие в том же операционном/системном окружении.
-Запросы на изменения[^9] (change requests - CR), иногда упоминаемые как
+Запросы на изменения[^5_3] (change requests - CR), иногда упоминаемые как
запросы на модификацию (modification request - MR), часто также называемые
отчетами о проблемах (problem report - PR), должны анализироваться и
трансформироваться в термины программной системы. Эти шаги выполняются после
управления, и фиксируется в системе конфигурационного управления (см. область
знаний Configuration Management).
-[^9]: Обычно запросы на изменения разделяют на две категории – “пожелания”
+[^5_3]: Обычно запросы на изменения разделяют на две категории – “пожелания”
(suggestions), относящиеся к расширению системы, и “отчеты об ошибках” (defect
или bug report), направляемые пользователями в службу сопровождения или
инженерами по тестированию разработчикам.
ресурсов без явно выраженной и количественно определяемой отдачи для
организации.
-#### Проблемы кадрового обеспечения[^10] (Staffing)
+#### Проблемы кадрового обеспечения[^5_4] (Staffing)
Данная тема касается вопросов привлечения и удержания квалифицированного
персонала по сопровождению. Часто, работа по сопровождению не выглядит
качества информационного обеспечения бизнеса, что сказывается, в подавляющем
большинстве случаев, и на бизнесе, как таковом.
-[^10]: Такой перевод, вместо просто “кадрового обеспечения”, в большей степени
+[^5_4]: Такой перевод, вместо просто “кадрового обеспечения”, в большей степени
соответствует принятому использованию термина staffing. Часто, staffing
подразумевает и высокую текучесть кадров.
Несмотря на то, что разработка программных системы, обычно, занимает от
несколько месяцев (что более типично) до нескольких лет, сопровождение (как
деятельность по поддержке использования) и активная эксплуатация систем
-занимает несколько лет, а то и более[^11] (5-10-...). Проведение оценки
+занимает несколько лет, а то и более[^5_5] (5-10-...). Проведение оценки
ресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для
сопровождения должны быть оценены и заложены в бюджет еще при разработке
системы. Планирование работ по сопровождению должно начинаться одновременно с
качества (отмечается в IEEE 1061-98 Standard for a Software Quality Metrics
Methodology).
-[^11]: Эта оценка согласуется и с опытом Сергея Орлика, когда в начале 90-х он
+[^5_5]: Эта оценка согласуется и с опытом Сергея Орлика, когда в начале 90-х он
принимал непосредственное участие в проектировании и разработке системы
автоматизации добровольного медицинского страхования (в одной из крупнейших
российских страховых компаний), выведенной, в дальнейшем, из эксплуатации на
blob - 1a0db5d6d3c3727bafde6e2e865fa9c40325ca4a
blob + 9e004e1f4f3c4dbe5f0fe79d6242fbbdc6633ed3
--- 6_software_configuration_management.md
+++ 6_software_configuration_management.md
В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207, конфигурационное
управление в области программного обеспечения (“6.2 Управление конфигурацией”
-по ГОСТ) – Software Configuration Management (SCM[^12]) – один из
+по ГОСТ) – Software Configuration Management (SCM[^6_1]) – один из
вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающий
проектный менеджмент, деятельность по разработке и сопровождению, обеспечению
качества, а также, заказчиков и пользователей конечного продукта.
-[^12]: В ряде источников можно увидеть аббревиатуру SCCM – Software Configuration
+[^6_1]: В ряде источников можно увидеть аббревиатуру SCCM – Software Configuration
and Change Management. При том, что в понимании SWEBOK и соответствующих
стандартов, содержание SCM и SCCM тождественно, термин SCCM иногда используется
для того, чтобы подчеркнуть принципиальную значимость управления изменениями
blob - e5704171c8f61e7581909d8e38c122e4d0f6ec84
blob + 3ee2cd12d511378445c09aaccc36d928f4ff3f1c
--- 7_software_engineering_management.md
+++ 7_software_engineering_management.md
сбалансировано с другими аспектами программной инженерии, не превращая Software
Engineering Management (SEM) в дорогостоящую, но бесполезную работу.
Эффективный менеджмент требует комбинации соответствующих систематических и
-упорядоченных подходов в управлении и соответствующего опыта[^13].
+упорядоченных подходов в управлении и соответствующего опыта[^7_1].
-[^13]: Например, на практике практически невозможно добиться статуса PMP – Project
+[^7_1]: Например, на практике практически невозможно добиться статуса PMP – Project
Management Professional по версии Project Management Institute (PMI), если
претендент не обладает серьезным практическим опыт управления проектами и
пытается сдать соответствующий экзамен только на основе штудирования PMBOK и
принятыми в организации
- Измерения (Measurement) связаны с определением величин и характеристикой
различных аспектов программной инженерии (продуктов, процессов и т.п.), а также
-разработкой на их основе моделей[^14] с использованием статистических
+разработкой на их основе моделей[^7_2] с использованием статистических
методов (и данных), экспертных знаний и других техник.
-[^14]: В данном контексте, SWEBOK видимо подразумевает, что полученные модели
+[^7_2]: В данном контексте, SWEBOK видимо подразумевает, что полученные модели
используются для идентификации и анализа рисков, планирования и
совершенствования процессов программной инженерии (процессов жизненного цикла,
включая процессы сопровождения), а также процесса управления.
## Планирование программного проекта (Software Project Planning)
-Процесс планирования является итеративным[^15] и базируется на
+Процесс планирования является итеративным[^7_3] и базируется на
содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить,
что различные фазы проекта перекрываются (что, например, специально отмечает
PMBOK) и вместе с определением содержания, детализацией требований и
обязанности в части управления планом проекта, его оценкой и порядка пересмотра
различных аспектов проекта.
-[^15]: Позднее, при обсуждении жизненного цикла и, в частности, спиральной модели
+[^7_3]: Позднее, при обсуждении жизненного цикла и, в частности, спиральной модели
разработки, мы будем рассматривать ключевые идеи итеративного подхода.
### Планирование процесса (Process Planning)
успешного выполнения проекта является управленческая деятельность по ведению
оценки и измерений, мониторинга, контроля и отчетности.
-### Реализация планов[^16] (Implementation of Plans)
+### Реализация планов[^7_4] (Implementation of Plans)
Проект инициируется и проектные работы выполняются в соответствии с планом. В
процессе выполнения используются соответствующие ресурсы (например, усилия
персонала, бюджет) и производятся необходимые результаты (deliverables; активы,
артефакты проекта – например, архитектурные документы, тестовые сценарии).
-[^16]: В SWEBOK используется как “план проекта” в единственном числе, так и “планы”
+[^7_4]: В SWEBOK используется как “план проекта” в единственном числе, так и “планы”
– во множественном числе, подразумевающие, судя по контексту, отдельные задачи
проекта.
blob - 8ae2d4a355059841a8b4d0c0abc7033e3ea6d145
blob + e263e64b60344ce254d11b107883c7cb2097a5cb
--- 8_software_engineering_process.md
+++ 8_software_engineering_process.md
Модели жизненного цикла задают высокоуровневое определение фаз (стадий)
разработки программного обеспечения. Их целью не является предоставление
детального определения, но концентрируется на ключевых работах и их
-взаимосвязях. Примерами таких моделей[^17] являются водопадная
+взаимосвязях. Примерами таких моделей[^8_1] являются водопадная
(каскадная - waterfall), модель прототипирования, эволюционной разработки,
инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения
и критерии выбора моделей, ссылки на некоторые из которых, в частности, даны в
оригинальной версии SWEBOK.
-[^17]: Базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе.
+[^8_1]: Базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе.
### Процессы жизненного цикла программного обеспечения (Software Life Cycle Processes)
Стандарт ISO/IEC 15504 (SPICE) определяет типовую (exemplar) модель оценки и
требования соответствия к другим моделям. В каждом конкретном случае
используется та или иная существующая модель – CMM-SW, CMMI,
-Bootstrap[^18]. Также имеются и другие модели, например, ISO 9000-3
+Bootstrap[^8_2]. Также имеются и другие модели, например, 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” к программной инженерии. Кроме того, существуют частные модели,
охватывающие, например, только вопросы документирования, проектирования и т.п.
-[^18]: В 1990 году стартовала европейская инициатива European Strategic Program for
+[^8_2]: В 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) касается процессов у подрядчиков[^19].
+(Software Capability Evaluation) касается процессов у подрядчиков[^8_3].
Требования в обоих типах методов отражают те лучшие практики оценки, которые
описаны в стандарте ISO 15504. Эти методы были разработаны для модели CMM-SW. С
выходом CMMI (интегрированной модели, объединяющей различные модели CMM),
направлена ли оценка на совершенствование процессов или проводится в контексте
контракта/договора подряда.
-[^19]: SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment
+[^8_3]: SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment
– внутренняя деятельность в организации, направленная на оценку и
совершенствование собственного процесса в рамках всей организации. Evaluation
подразумевает аудит и мониторинг процессов поставщика (подрядчика, исполнителя)
заданных вех или, более точно (так как измерения, все же, выходят за рамки вех
конкретных проектов, если, конечно, сама SPI-деятельность не позиционировать
как проект, что, конечно, возможно), так называемых “базовых линий”
-(baseline[^20]).
+(baseline[^8_4]).
-[^20]: Термин baseline обычно используется в контексте управления изменениями,
+[^8_4]: Термин baseline обычно используется в контексте управления изменениями,
требованиями и, часто, конфигурациями, в целом, для именования временных
“срезов” всего комплекса соответствующих активов.
Необходимо отметить, что в литературе встречаются некоторые терминологические
отличия, например, термин “метрика” (metric) часто используется вместо термина
-“измерение” (measure)[^21].
+“измерение” (measure)[^8_5].
-[^21]: В данном переводе эти термины используются взаимозаменяемым образом, за
+[^8_5]: В данном переводе эти термины используются взаимозаменяемым образом, за
исключением случаев, когда контекст обсуждения предполагает разделение процесса
измерения – “измерения”, как такового, и критериев/параметров или результатов
измерения – “метрик”.
соответствующего инструментария, главный ресурс, который нуждается управлении –
персонал. Как результат, наиболее важные метрики касаются оценки продуктивности
команд и процессов (например, может использоваться оценка функциональных точек,
-производимых на единицу трудозатрат[^22]. – “person-effort”), а также,
+производимых на единицу трудозатрат[^8_6]. – “person-effort”), а также,
ассоциированного с этим уровня опыта в программной инженерии, в целом, и в
отдельных технологиях, в частности.
-[^22]: Трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или
+[^8_6]: Трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или
“человеко-месяц”; здесь полезно обратиться к юбилейному второму изданию
классического труда Фреда Брукса “Мифический человеко-месяц” [Брукс, 1995].
приводят к желаемому результату, когда процессы полностью или частично остаются
лишь на бумаге.
-### Измерения в отношении программных продуктов[^23] (Software Product Measurement)
+### Измерения в отношении программных продуктов[^8_7] (Software Product Measurement)
Измерения в отношении программного продукта включают количественную оценку его
размера, структуры и качества.
-[^23]: Данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке
+[^8_7]: Данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке
оригинального варианта SWEBOK 2004, поэтому, далее, нумерация тем смещена.
#### Оценка размера (Size measurement)
