commit e0436dbcd5fbc42ecec0b95d82d35ad456e3f223 from: Mike Voznesensky via: Sergey Bronnikov date: Sat Jan 20 11:36:22 2024 UTC Changed all footnote on markdown style commit - 376dbe710b5872a29809aed59fd6dcb080c9f337 commit + e0436dbcd5fbc42ecec0b95d82d35ad456e3f223 blob - 5a25b665604c9f0a0d614581ac840e95ade82fdb blob + 7e81b2e7754c5fd69292b725ead4c5a7b3cd1e85 --- 0_introduction.markdown +++ 0_introduction.markdown @@ -15,7 +15,7 @@ ## Программная инженерия как дисциплина В 1958 всемирно известный статистик Джон Тьюкей (John Tukey) впервые ввел -термин *software* – программное обеспечение. В 1972 году IEEE* выпустил первый +термин *software* – программное обеспечение. В 1972 году IEEE[^1] выпустил первый номер *Transactions on Software Engineering* – Труды по Программной Инженерии. Первый целостный взгляд на эту область профессиональной деятельности появился 1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730 @@ -24,15 +24,15 @@ Наконец, в 1990 году началось планирование всеобъемлющих *международных* стандартов, в основу которых легли концепции и взгляды стандарта IEEE Std 1074 -и результатов работы образованной в 1987 году совместной комиссии ISO/IEC JTC -12. В 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 и ACM3, начав совместные работы еще в 1993 году +В свою очередь, IEEE и ACM[^3], начав совместные работы еще в 1993 году с кодекса этики и профессиональной практики в данной области (ACM/IEEE-CS Code of Ethics and Professional Practice), к 2004 году сформулировали два ключевых описания того, что сегодня мы и называем основами программной инженерии – @@ -42,19 +42,19 @@ Version* - Руководство к Своду Зна просто “SWEBOK” [SWEBOK, 2004]; - *Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering* – Учебный План для Преподавания Программной -Инженерии в ВУЗах1 (данное название на русском языке представлено в +Инженерии в ВУЗах (данное название на русском языке представлено в вольном смысловом переводе) [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 @@ -81,9 +81,11 @@ C 1993 года IEEE и ACM координируют 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 @@ -214,9 +214,9 @@ Aren’ t Going to Need It”, то есть “не Распределение (и выполнение) по различным узлам обработки в терминах аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших вопросов данной темы – использование связующего программного обеспечения -(middleware1) +(middleware[^5]) -1 часто middleware переводят как “промежуточное программное обеспечение”. Такой +[^5]: Часто middleware переводят как “промежуточное программное обеспечение”. Такой вариант перевода, к сожалению, рассматривает связующее ПО во второстепенной – “промежуточной” роли. Читатель, безусловно, может не согласиться с такой трактовкой, однако, многолетняя практика автора в обсуждении архитектурных @@ -471,13 +471,8 @@ Collaborator или CRC Card (CRC по свое при наследования); - *Диаграммы компонентов или компонентные диаграммы (Component diagrams)*: в определенной степени аналогичны диаграммам классов, однако, в силу специфики -концепции или понятия компонента2, обычно, представляются в другой +концепции или понятия компонента[^6], обычно, представляются в другой визуальной форме; -2 здесь необходимо отметить различие в понятиях класса (или объекта) и -компонента: компонент рассматривается как физически реализуемый элемент -программного обеспечения, несущий <в определенной степени> самодостаточную -логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде -комплекса классов); - *Карточки <функциональной> ответственности и связей класса (Class responsibility collaborator card, CRC)*: используются для обозначения имени класса, его ответственности (то есть, что он должен делать) и других сущностей @@ -499,6 +494,12 @@ IDL)*: языки, подобные языкам пр - *Структурные схемы (Structure charts)*: описываю структуру вызовов в программах (какой модуль вызывает, кем и как вызываем). +[^6]: Здесь необходимо отметить различие в понятиях класса (или объекта) и +компонента: компонент рассматривается как физически реализуемый элемент +программного обеспечения, несущий <в определенной степени> самодостаточную +логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде +комплекса классов); + ### Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view) Следующие нотации и языки (часть из которых – графические, часть - текстовые) blob - 46d99b8d437cd2ab8eae584f4af8dfe5107d49f8 blob + 02a3e97adb5e3a31bf6e4bde9441b03079c8f3c8 --- 5_software_maintenance.markdown +++ 5_software_maintenance.markdown @@ -26,7 +26,7 @@ SWEBOK. большинстве организаций, разработка программных систем явно в фаворе, по сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний -ITIL1 – IT Infrastructure Library, уделяющей особое внимание +ITIL[^7] – IT Infrastructure Library, уделяющей особое внимание вопросам поддержки и сопровождения инфраструктуры информационных технологий). В большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций организаций непосредственно в разработку программных систем, с целью увеличения @@ -37,7 +37,7 @@ ITIL1 – IT Infrastructure Library, уде программного обеспечения и естественной интеграции такой деятельности в бизнес-процессы подразделений информационных технологий. -* ITIL, в частности, определяет три аспекта управления жизненным циклом +[^7]: ITIL, в частности, определяет три аспекта управления жизненным циклом приложений – определение требований, проектирование и разработку, и, наконец, сопровождение. Все это, в контексте программного обеспечения, относится к деятельности по управлению приложениями – Application Management в ITIL ICT @@ -458,16 +458,16 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof необходимыми знаниями о специфике системы (в идеальном случае, иметь полное представление о системе на уровне ее разработчиков) – ее содержании и структуре. Инженеры используют эти знания для выполнения работ по анализу -влияния, идентифицируя все системы1 и программные продукты, на +влияния, идентифицируя все системы[^8] и программные продукты, на которые могут повлиять изменения, вносимые в обслуживаемую программную систему. При этом, должны быть определены риски, связанные с внесением обсуждаемых изменений. -* Как мы видим из описания данных работ в SWEBOK, речь идет не только о +[^8]: Как мы видим из описания данных работ в SWEBOK, речь идет не только о компонентах системы, но и о ее окружении, включая другие системы, функционирующие в том же операционном/системном окружении. -Запросы на изменения2 (change requests - CR), иногда упоминаемые как +Запросы на изменения[^9] (change requests - CR), иногда упоминаемые как запросы на модификацию (modification request - MR), часто также называемые отчетами о проблемах (problem report - PR), должны анализироваться и трансформироваться в термины программной системы. Эти шаги выполняются после @@ -476,7 +476,7 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof управления, и фиксируется в системе конфигурационного управления (см. область знаний Configuration Management). -** Обычно запросы на изменения разделяют на две категории – “пожелания” +[^9]: Обычно запросы на изменения разделяют на две категории – “пожелания” (suggestions), относящиеся к расширению системы, и “отчеты об ошибках” (defect или bug report), направляемые пользователями в службу сопровождения или инженерами по тестированию разработчикам. @@ -570,7 +570,7 @@ Quality – Part 1: Quality Model, 2001 г.) опре ресурсов без явно выраженной и количественно определяемой отдачи для организации. -#### Проблемы кадрового обеспечения3 (Staffing) +#### Проблемы кадрового обеспечения[^10] (Staffing) Данная тема касается вопросов привлечения и удержания квалифицированного персонала по сопровождению. Часто, работа по сопровождению не выглядит @@ -592,7 +592,7 @@ Quality – Part 1: Quality Model, 2001 г.) опре качества информационного обеспечения бизнеса, что сказывается, в подавляющем большинстве случаев, и на бизнесе, как таковом. -*** такой перевод, вместо просто “кадрового обеспечения”, в большей степени +[^10]: Такой перевод, вместо просто “кадрового обеспечения”, в большей степени соответствует принятому использованию термина staffing. Часто, staffing подразумевает и высокую текучесть кадров. @@ -926,7 +926,7 @@ Desk и Software Support – эти функции, о Несмотря на то, что разработка программных системы, обычно, занимает от несколько месяцев (что более типично) до нескольких лет, сопровождение (как деятельность по поддержке использования) и активная эксплуатация систем -занимает несколько лет, а то и более 4 (5-10-...). Проведение оценки +занимает несколько лет, а то и более[^11] (5-10-...). Проведение оценки ресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должны быть оценены и заложены в бюджет еще при разработке системы. Планирование работ по сопровождению должно начинаться одновременно с @@ -934,7 +934,7 @@ Desk и Software Support – эти функции, о качества (отмечается в 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 @@ -32,12 +32,12 @@ Management), в свою очередь, дисцип В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207, конфигурационное управление в области программного обеспечения (“6.2 Управление конфигурацией” -по ГОСТ) – Software Configuration Management (SCM1) – один из +по ГОСТ) – 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 @@ -155,9 +155,9 @@ SWEBOK “Связанные дисциплины” ( сбалансировано с другими аспектами программной инженерии, не превращая Software Engineering Management (SEM) в дорогостоящую, но бесполезную работу. Эффективный менеджмент требует комбинации соответствующих систематических и -упорядоченных подходов в управлении и соответствующего опыта1. +упорядоченных подходов в управлении и соответствующего опыта[^13]. -* например, на практике практически невозможно добиться статуса PMP – Project +[^13]: Например, на практике практически невозможно добиться статуса PMP – Project Management Professional по версии Project Management Institute (PMI), если претендент не обладает серьезным практическим опыт управления проектами и пытается сдать соответствующий экзамен только на основе штудирования PMBOK и @@ -172,10 +172,10 @@ activities), предпринимаемые для о принятыми в организации - Измерения (Measurement) связаны с определением величин и характеристикой различных аспектов программной инженерии (продуктов, процессов и т.п.), а также -разработкой на их основе моделей2 с использованием статистических +разработкой на их основе моделей[^14] с использованием статистических методов (и данных), экспертных знаний и других техник. -* В данном контексте, SWEBOK видимо подразумевает, что полученные модели +[^14]: В данном контексте, SWEBOK видимо подразумевает, что полученные модели используются для идентификации и анализа рисков, планирования и совершенствования процессов программной инженерии (процессов жизненного цикла, включая процессы сопровождения), а также процесса управления. @@ -315,7 +315,7 @@ project enactment”, ее название и пер ## Планирование программного проекта (Software Project Planning) -Процесс планирования является итеративным2 и базируется на +Процесс планирования является итеративным[^15] и базируется на содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить, что различные фазы проекта перекрываются (что, например, специально отмечает PMBOK) и вместе с определением содержания, детализацией требований и @@ -342,7 +342,7 @@ Software Quality). Безусловно, что дол обязанности в части управления планом проекта, его оценкой и порядка пересмотра различных аспектов проекта. -* позднее, при обсуждении жизненного цикла и, в частности, спиральной модели +[^15]: Позднее, при обсуждении жизненного цикла и, в частности, спиральной модели разработки, мы будем рассматривать ключевые идеи итеративного подхода. ### Планирование процесса (Process Planning) @@ -510,14 +510,14 @@ quality assurance) на протяжении всех успешного выполнения проекта является управленческая деятельность по ведению оценки и измерений, мониторинга, контроля и отчетности. -### Реализация планов4 (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 @@ -272,12 +272,13 @@ SWEBOK также отмечает роль “аге Модели жизненного цикла задают высокоуровневое определение фаз (стадий) разработки программного обеспечения. Их целью не является предоставление детального определения, но концентрируется на ключевых работах и их -взаимосвязях. Примерами таких моделей1 являются водопадная +взаимосвязях. Примерами таких моделей[^17] являются водопадная (каскадная - waterfall), модель прототипирования, эволюционной разработки, инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения и критерии выбора моделей, ссылки на некоторые из которых, в частности, даны в оригинальной версии SWEBOK. -* базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе. + +[^17]: Базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе. ### Процессы жизненного цикла программного обеспечения (Software Life Cycle Processes) @@ -413,13 +414,14 @@ methods). Во многих случаях вмест Стандарт ISO/IEC 15504 (SPICE) определяет типовую (exemplar) модель оценки и требования соответствия к другим моделям. В каждом конкретном случае используется та или иная существующая модель – CMM-SW, CMMI, -Bootstrap2. Также имеются и другие модели, например, 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) и многих @@ -452,7 +454,7 @@ SWEBOK отмечает, что ряд моделей Например, метод CBA-IPI (CMM-Based Appraisals for Internal Process Improvement) фокусируется на совершенствовании процесса внутри организации, а метод SCE -(Software Capability Evaluation) касается процессов у подрядчиков3. +(Software Capability Evaluation) касается процессов у подрядчиков[^19]. Требования в обоих типах методов отражают те лучшие практики оценки, которые описаны в стандарте ISO 15504. Эти методы были разработаны для модели CMM-SW. С выходом CMMI (интегрированной модели, объединяющей различные модели CMM), @@ -464,7 +466,7 @@ CMMI Appraisal Method for Process Improvement). Дея направлена ли оценка на совершенствование процессов или проводится в контексте контракта/договора подряда. -* SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment +[^19]: SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment – внутренняя деятельность в организации, направленная на оценку и совершенствование собственного процесса в рамках всей организации. Evaluation подразумевает аудит и мониторинг процессов поставщика (подрядчика, исполнителя) @@ -496,9 +498,9 @@ CMMI Appraisal Method for Process Improvement). Дея заданных вех или, более точно (так как измерения, все же, выходят за рамки вех конкретных проектов, если, конечно, сама SPI-деятельность не позиционировать как проект, что, конечно, возможно), так называемых “базовых линий” -(baseline4). +(baseline[^20]). -* термин baseline обычно используется в контексте управления изменениями, +[^20]: Термин baseline обычно используется в контексте управления изменениями, требованиями и, часто, конфигурациями, в целом, для именования временных “срезов” всего комплекса соответствующих активов. @@ -514,9 +516,9 @@ Measurement Process” и международном Необходимо отметить, что в литературе встречаются некоторые терминологические отличия, например, термин “метрика” (metric) часто используется вместо термина -“измерение” (measure)5. +“измерение” (measure)[^21]. -** В данном переводе эти термины используются взаимозаменяемым образом, за +[^21]: В данном переводе эти термины используются взаимозаменяемым образом, за исключением случаев, когда контекст обсуждения предполагает разделение процесса измерения – “измерения”, как такового, и критериев/параметров или результатов измерения – “метрик”. @@ -555,11 +557,11 @@ Measurement Process” и международном соответствующего инструментария, главный ресурс, который нуждается управлении – персонал. Как результат, наиболее важные метрики касаются оценки продуктивности команд и процессов (например, может использоваться оценка функциональных точек, -производимых на единицу трудозатрат56 Измерения в отношении программных продуктов (Software Product Measurement) +### Измерения в отношении программных продуктов[^23] (Software Product Measurement) Измерения в отношении программного продукта включают количественную оценку его размера, структуры и качества. -* данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке +[^23]: Данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке оригинального варианта SWEBOK 2004, поэтому, далее, нумерация тем смещена. #### Оценка размера (Size measurement)