commit 48c63dee92b321ed49c64cb7a2b481a47e98d6af from: Mike Voznesensky via: Sergey Bronnikov date: Tue Jun 04 08:33:40 2024 UTC Updated footnotes * Removed end-to-end numbering. Now numbering refer to file where: first number - number document from name second number - ordinal number footnote * Added two new footes - 10_1 and 2_3 commit - 824fc889d10debe960fe260f36df3ae8f5ad5ead commit + 48c63dee92b321ed49c64cb7a2b481a47e98d6af blob - 859bf36717c3e9ed6fd1d9d32684ae4937a25599 blob + c3f385153806b2b312ff8d616ab8ba9089e5de3f --- 0_introduction.md +++ 0_introduction.md @@ -15,7 +15,7 @@ ## Программная инженерия как дисциплина В 1958 всемирно известный статистик Джон Тьюкей (John Tukey) впервые ввел -термин *software* – программное обеспечение. В 1972 году IEEE[^1] выпустил первый +термин *software* – программное обеспечение. В 1972 году IEEE[^0_1] выпустил первый номер *Transactions on Software Engineering* – Труды по Программной Инженерии. Первый целостный взгляд на эту область профессиональной деятельности появился 1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730 @@ -24,7 +24,7 @@ Наконец, в 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”. Этот стандарт стал первым опытом создания единого общего @@ -32,7 +32,7 @@ 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 году сформулировали два ключевых описания того, что сегодня мы и называем основами программной инженерии – @@ -45,15 +45,15 @@ Programs in Software Engineering* – Учебный Инженерии в ВУЗах (данное название на русском языке представлено в вольном смысловом переводе) [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 Оба стандарта стали результатом консенсуса ведущих представителей индустрии и признанных авторитетов в области программной инженерии - по аналогии с тем, как @@ -101,11 +101,11 @@ Boeing, MITRE, Raytheon, SAP. В результате 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 @@ -416,11 +416,11 @@ Quality Assurance Plans”. образом, в виде соответствующих "подтем" в рамках формата 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: “Проверка и аттестация программного обеспечения – упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и @@ -429,7 +429,7 @@ V&V*: “Проверка и аттестация пр понимании управления требованиями, а потребности пользователей, ради удовлетворения которых создается программное обеспечение). -* здесь и далее в переводе намеренно используется обозначение V&V, как +[^10_1]: Здесь и далее в переводе намеренно используется обозначение V&V, как общепринятое в индустрии программного обеспечения V&V напрямую адресуется вопросам качества программного обеспечения и использует blob - 4ce897dac446894dc2a9d79b05162e7fe4c78181 blob + 8527710f27d1b1221de2ea82d2256986da76e76b --- 2_software_design.md +++ 2_software_design.md @@ -219,9 +219,9 @@ Aren’ t Going to Need It”, то есть “не Распределение (и выполнение) по различным узлам обработки в терминах аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших вопросов данной темы – использование связующего программного обеспечения -(middleware[^5]) +(middleware[^2_1]) -[^5]: Часто middleware переводят как “промежуточное программное обеспечение”. Такой +[^2_1]: Часто middleware переводят как “промежуточное программное обеспечение”. Такой вариант перевода, к сожалению, рассматривает связующее ПО во второстепенной – “промежуточной” роли. Читатель, безусловно, может не согласиться с такой трактовкой, однако, многолетняя практика автора в обсуждении архитектурных @@ -476,7 +476,7 @@ Collaborator или CRC Card (CRC по свое при наследования); - *Диаграммы компонентов или компонентные диаграммы (Component diagrams)*: в определенной степени аналогичны диаграммам классов, однако, в силу специфики -концепции или понятия компонента[^6], обычно, представляются в другой +концепции или понятия компонента[^2_2], обычно, представляются в другой визуальной форме; - *Карточки <функциональной> ответственности и связей класса (Class responsibility collaborator card, CRC)*: используются для обозначения имени @@ -499,7 +499,7 @@ IDL)*: языки, подобные языкам пр - *Структурные схемы (Structure charts)*: описываю структуру вызовов в программах (какой модуль вызывает, кем и как вызываем). -[^6]: Здесь необходимо отметить различие в понятиях класса (или объекта) и +[^2_2]: Здесь необходимо отметить различие в понятиях класса (или объекта) и компонента: компонент рассматривается как физически реализуемый элемент программного обеспечения, несущий <в определенной степени> самодостаточную логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде @@ -592,10 +592,10 @@ languages, PDL)*: языки, используемые Хотя корни объектно-ориентированного проектирования лежат в абстракции данных (к которым добавлены поведенческие характеристики), так называемый responsibility-driven design или проектирование на основе <функциональной> -ответственности по SWEBOK* может рассматриваться как альтернатива +ответственности по SWEBOK[^2_3] может рассматриваться как альтернатива объектно-ориентированному проектированию. -*Такое противопоставление – достаточно спорный вопрос, так как функциональная +[^2_3]: Такое противопоставление – достаточно спорный вопрос, так как функциональная ответственность столь же близка принципам современного объектно-ориентированного проектирования, сколь и абстракция данных. Это вопрос эволюционирования взглядов и степени их консерватизма. blob - 84df82f3168f350be60fe148581deb24566b28ca blob + bc967963990b2b8a36cbfc7b94d5140347d2cc30 --- 5_software_maintenance.md +++ 5_software_maintenance.md @@ -26,7 +26,7 @@ SWEBOK. большинстве организаций, разработка программных систем явно в фаворе, по сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний -ITIL[^7] – IT Infrastructure Library, уделяющей особое внимание +ITIL[^5_1] – IT Infrastructure Library, уделяющей особое внимание вопросам поддержки и сопровождения инфраструктуры информационных технологий). В большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций организаций непосредственно в разработку программных систем, с целью увеличения @@ -37,7 +37,7 @@ ITIL[^7] – IT Infrastructure Library, уделяющ программного обеспечения и естественной интеграции такой деятельности в бизнес-процессы подразделений информационных технологий. -[^7]: ITIL, в частности, определяет три аспекта управления жизненным циклом +[^5_1]: ITIL, в частности, определяет три аспекта управления жизненным циклом приложений – определение требований, проектирование и разработку, и, наконец, сопровождение. Все это, в контексте программного обеспечения, относится к деятельности по управлению приложениями – Application Management в ITIL ICT @@ -458,16 +458,16 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof необходимыми знаниями о специфике системы (в идеальном случае, иметь полное представление о системе на уровне ее разработчиков) – ее содержании и структуре. Инженеры используют эти знания для выполнения работ по анализу -влияния, идентифицируя все системы[^8] и программные продукты, на +влияния, идентифицируя все системы[^5_2] и программные продукты, на которые могут повлиять изменения, вносимые в обслуживаемую программную систему. При этом, должны быть определены риски, связанные с внесением обсуждаемых изменений. -[^8]: Как мы видим из описания данных работ в SWEBOK, речь идет не только о +[^5_2]: Как мы видим из описания данных работ в SWEBOK, речь идет не только о компонентах системы, но и о ее окружении, включая другие системы, функционирующие в том же операционном/системном окружении. -Запросы на изменения[^9] (change requests - CR), иногда упоминаемые как +Запросы на изменения[^5_3] (change requests - CR), иногда упоминаемые как запросы на модификацию (modification request - MR), часто также называемые отчетами о проблемах (problem report - PR), должны анализироваться и трансформироваться в термины программной системы. Эти шаги выполняются после @@ -476,7 +476,7 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof управления, и фиксируется в системе конфигурационного управления (см. область знаний Configuration Management). -[^9]: Обычно запросы на изменения разделяют на две категории – “пожелания” +[^5_3]: Обычно запросы на изменения разделяют на две категории – “пожелания” (suggestions), относящиеся к расширению системы, и “отчеты об ошибках” (defect или bug report), направляемые пользователями в службу сопровождения или инженерами по тестированию разработчикам. @@ -570,7 +570,7 @@ Quality – Part 1: Quality Model, 2001 г.) опре ресурсов без явно выраженной и количественно определяемой отдачи для организации. -#### Проблемы кадрового обеспечения[^10] (Staffing) +#### Проблемы кадрового обеспечения[^5_4] (Staffing) Данная тема касается вопросов привлечения и удержания квалифицированного персонала по сопровождению. Часто, работа по сопровождению не выглядит @@ -592,7 +592,7 @@ Quality – Part 1: Quality Model, 2001 г.) опре качества информационного обеспечения бизнеса, что сказывается, в подавляющем большинстве случаев, и на бизнесе, как таковом. -[^10]: Такой перевод, вместо просто “кадрового обеспечения”, в большей степени +[^5_4]: Такой перевод, вместо просто “кадрового обеспечения”, в большей степени соответствует принятому использованию термина staffing. Часто, staffing подразумевает и высокую текучесть кадров. @@ -926,7 +926,7 @@ Desk и Software Support – эти функции, о Несмотря на то, что разработка программных системы, обычно, занимает от несколько месяцев (что более типично) до нескольких лет, сопровождение (как деятельность по поддержке использования) и активная эксплуатация систем -занимает несколько лет, а то и более[^11] (5-10-...). Проведение оценки +занимает несколько лет, а то и более[^5_5] (5-10-...). Проведение оценки ресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должны быть оценены и заложены в бюджет еще при разработке системы. Планирование работ по сопровождению должно начинаться одновременно с @@ -934,7 +934,7 @@ Desk и Software Support – эти функции, о качества (отмечается в 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 @@ -32,12 +32,12 @@ Management), в свою очередь, дисцип В соответствии с ГОСТ Р ИСО/МЭК (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 @@ -155,9 +155,9 @@ SWEBOK “Связанные дисциплины” ( сбалансировано с другими аспектами программной инженерии, не превращая Software Engineering Management (SEM) в дорогостоящую, но бесполезную работу. Эффективный менеджмент требует комбинации соответствующих систематических и -упорядоченных подходов в управлении и соответствующего опыта[^13]. +упорядоченных подходов в управлении и соответствующего опыта[^7_1]. -[^13]: Например, на практике практически невозможно добиться статуса PMP – Project +[^7_1]: Например, на практике практически невозможно добиться статуса PMP – Project Management Professional по версии Project Management Institute (PMI), если претендент не обладает серьезным практическим опыт управления проектами и пытается сдать соответствующий экзамен только на основе штудирования PMBOK и @@ -172,10 +172,10 @@ activities), предпринимаемые для о принятыми в организации - Измерения (Measurement) связаны с определением величин и характеристикой различных аспектов программной инженерии (продуктов, процессов и т.п.), а также -разработкой на их основе моделей[^14] с использованием статистических +разработкой на их основе моделей[^7_2] с использованием статистических методов (и данных), экспертных знаний и других техник. -[^14]: В данном контексте, SWEBOK видимо подразумевает, что полученные модели +[^7_2]: В данном контексте, SWEBOK видимо подразумевает, что полученные модели используются для идентификации и анализа рисков, планирования и совершенствования процессов программной инженерии (процессов жизненного цикла, включая процессы сопровождения), а также процесса управления. @@ -315,7 +315,7 @@ project enactment”, ее название и пер ## Планирование программного проекта (Software Project Planning) -Процесс планирования является итеративным[^15] и базируется на +Процесс планирования является итеративным[^7_3] и базируется на содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить, что различные фазы проекта перекрываются (что, например, специально отмечает PMBOK) и вместе с определением содержания, детализацией требований и @@ -342,7 +342,7 @@ Software Quality). Безусловно, что дол обязанности в части управления планом проекта, его оценкой и порядка пересмотра различных аспектов проекта. -[^15]: Позднее, при обсуждении жизненного цикла и, в частности, спиральной модели +[^7_3]: Позднее, при обсуждении жизненного цикла и, в частности, спиральной модели разработки, мы будем рассматривать ключевые идеи итеративного подхода. ### Планирование процесса (Process Planning) @@ -510,14 +510,14 @@ quality assurance) на протяжении всех успешного выполнения проекта является управленческая деятельность по ведению оценки и измерений, мониторинга, контроля и отчетности. -### Реализация планов[^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 @@ -272,13 +272,13 @@ SWEBOK также отмечает роль “аге Модели жизненного цикла задают высокоуровневое определение фаз (стадий) разработки программного обеспечения. Их целью не является предоставление детального определения, но концентрируется на ключевых работах и их -взаимосвязях. Примерами таких моделей[^17] являются водопадная +взаимосвязях. Примерами таких моделей[^8_1] являются водопадная (каскадная - waterfall), модель прототипирования, эволюционной разработки, инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения и критерии выбора моделей, ссылки на некоторые из которых, в частности, даны в оригинальной версии SWEBOK. -[^17]: Базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе. +[^8_1]: Базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе. ### Процессы жизненного цикла программного обеспечения (Software Life Cycle Processes) @@ -414,14 +414,14 @@ methods). Во многих случаях вмест Стандарт 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) и многих @@ -454,7 +454,7 @@ SWEBOK отмечает, что ряд моделей Например, метод 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), @@ -466,7 +466,7 @@ CMMI Appraisal Method for Process Improvement). Дея направлена ли оценка на совершенствование процессов или проводится в контексте контракта/договора подряда. -[^19]: SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment +[^8_3]: SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment – внутренняя деятельность в организации, направленная на оценку и совершенствование собственного процесса в рамках всей организации. Evaluation подразумевает аудит и мониторинг процессов поставщика (подрядчика, исполнителя) @@ -498,9 +498,9 @@ CMMI Appraisal Method for Process Improvement). Дея заданных вех или, более точно (так как измерения, все же, выходят за рамки вех конкретных проектов, если, конечно, сама SPI-деятельность не позиционировать как проект, что, конечно, возможно), так называемых “базовых линий” -(baseline[^20]). +(baseline[^8_4]). -[^20]: Термин baseline обычно используется в контексте управления изменениями, +[^8_4]: Термин baseline обычно используется в контексте управления изменениями, требованиями и, часто, конфигурациями, в целом, для именования временных “срезов” всего комплекса соответствующих активов. @@ -516,9 +516,9 @@ Measurement Process” и международном Необходимо отметить, что в литературе встречаются некоторые терминологические отличия, например, термин “метрика” (metric) часто используется вместо термина -“измерение” (measure)[^21]. +“измерение” (measure)[^8_5]. -[^21]: В данном переводе эти термины используются взаимозаменяемым образом, за +[^8_5]: В данном переводе эти термины используются взаимозаменяемым образом, за исключением случаев, когда контекст обсуждения предполагает разделение процесса измерения – “измерения”, как такового, и критериев/параметров или результатов измерения – “метрик”. @@ -557,11 +557,11 @@ Measurement Process” и международном соответствующего инструментария, главный ресурс, который нуждается управлении – персонал. Как результат, наиболее важные метрики касаются оценки продуктивности команд и процессов (например, может использоваться оценка функциональных точек, -производимых на единицу трудозатрат[^22]. – “person-effort”), а также, +производимых на единицу трудозатрат[^8_6]. – “person-effort”), а также, ассоциированного с этим уровня опыта в программной инженерии, в целом, и в отдельных технологиях, в частности. -[^22]: Трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или +[^8_6]: Трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или “человеко-месяц”; здесь полезно обратиться к юбилейному второму изданию классического труда Фреда Брукса “Мифический человеко-месяц” [Брукс, 1995]. @@ -593,12 +593,12 @@ Lines Of Code или FP за человеко-меся приводят к желаемому результату, когда процессы полностью или частично остаются лишь на бумаге. -### Измерения в отношении программных продуктов[^23] (Software Product Measurement) +### Измерения в отношении программных продуктов[^8_7] (Software Product Measurement) Измерения в отношении программного продукта включают количественную оценку его размера, структуры и качества. -[^23]: Данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке +[^8_7]: Данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке оригинального варианта SWEBOK 2004, поэтому, далее, нумерация тем смещена. #### Оценка размера (Size measurement)