commit 690824cc05e5bb1b3a40131947061a4793f56a90 from: Mike Voznesensky via: Sergey Bronnikov date: Sat Jan 20 11:36:22 2024 UTC Fixed typos commit - 98f9c0b64bcb6bbe09bcb8892863f45b8c85c4d0 commit + 690824cc05e5bb1b3a40131947061a4793f56a90 blob - f10301070ffba8a7ca8a4b66ab9d91d9e42763d6 blob + 5a25b665604c9f0a0d614581ac840e95ade82fdb --- 0_introduction.markdown +++ 0_introduction.markdown @@ -85,7 +85,7 @@ SWEBOK включал “лишь” 10 *област соответствующей области знаний, если это не приведет к серьезному усложнению SWEBOK. (Концепция “общепринятости” - generally accepted – определена в IEEE Std 1490-1998, Adoption of PMI Standard — A Guide to the Project Management -Body of Knowledge) +Body of Knowledge Важно понимать, что программная инженерия является развивающейся дисциплиной. Более того, данная дисциплина не касается вопросов конкретизации применения тех blob - 15c1f9c1d19c918d215c4643be6a6336d58dc506 blob + cc106997149473f5500c6bb6d959855f6f4040fa --- 10_software_quality.markdown +++ 10_software_quality.markdown @@ -58,7 +58,7 @@ quality” – “стоимость качества программного обеспечения является постоянным объектом заботы программной инженерии и обсуждается во многих областях знаний (что вполне обосновано, если учесть поистине катастрофический уровень проваленных проектов и -неудовлетворенность пользователей программных продуктов, ставшая притчей во +неудовлетворённость пользователей программных продуктов, ставшая притчей во языцех для программной индустрии). В общем случае, SWEBOK описывает ряд путей достижения качества программного обеспечения. В частности, эта область знаний касается статических техник, не требующих выполнения оцениваемых программных @@ -118,7 +118,7 @@ failure cost). Движущей силой программных проектов является желание создать программное обеспечение, обладающее определенной ценностью (значимое для решения -определенных задач или достижения целей). Ценность программного обеспечения в +определенных задач или достижения целей). Ценность программного обеспечения может выражаться в форме стоимости, а может и нет. Заказчик, обычно, имеет свое представление о максимальных стоимостных вложениях, возврат которых ожидается в случае достижения основных целей создания программного обеспечения. Заказчик @@ -574,7 +574,7 @@ IEEE 1028-97 “IEEE Standard for Software Reviews”. бизнес-правил, функциональных требований или атрибутов качества). Каждый член команды должен исследовать программный продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические -техники (описанные ниже в подтеме 3.3.3) в небольшим фрагментам продукта или к +техники (описанные ниже в подтеме 3.3.3) к небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит @@ -991,7 +991,7 @@ Adoption of International Standard IDO/IEC12119:1994(E <достигаемого> качества. С увеличением внутренней сложности, изощренности программного обеспечения, -вопросы качества выходят далеко за рамки констатации факта – работает или на +вопросы качества выходят далеко за рамки констатации факта – работает или не работает программное обеспечение. Вопрос ставится – насколько хорошо достигаются количественно оцениваемые цели качества. blob - a37cbedd34e49a068c802d43b7d4683aa9d59d49 blob + 6b9594b6daf791cb304862a36d2ccdc70171bf7a --- 1_software_requirements.markdown +++ 1_software_requirements.markdown @@ -849,7 +849,7 @@ INCOSE – www.incose.org ), в свою очеред описания программных требований – “Recommended Practice for Software Requirements Specifications”. -Необходим отметить, что в документацию на требования не следует вносить +Необходимо отметить, что в документацию на требования не следует вносить элементы дизайна системы (скажем, логическую модель базы данных). А вот сценарии использования Use Case часто включают в спецификацию требований наравне с трассировкой (traces) к соответствующим моделям в форме диаграмм, @@ -1060,7 +1060,7 @@ Testing) в описании 2.2.4 “Тесты со индустрии однозначно это показывает. Поэтому отношение к управлению требованиями как к постоянно действующему бизнес-процессу – абсолютно обоснованный подход, требующий применения определенных практик. В противном -случае, мы практически гарантировано столкнемся с темни негативными +случае, мы практически гарантировано столкнемся с теми негативными последствиями, которые не раз описывались и упоминались выше. ### Итеративная природа процесса работы с требованиями (Iterative Nature of the Requirements Process) blob - 7ac63738e12fc6764a8214db1b68f431a19b7fa7 blob + 7c532dfa5f824d2230361ac291df806d89ab13ad --- 3_software_construction.markdown +++ 3_software_construction.markdown @@ -416,7 +416,7 @@ www.omg.org/mda)/UML (Unified Modeling Language www.om предполагают однозначную интерпретацию визуального представления в виде текста и наоборот. Кроме того, исторически эти нотации определялись изначально как нотации визуального представления функциональности и уже в дальнейшем эти -визуальные представления были отражены на цровне соответствующих мета-моделей +визуальные представления были отражены на уровне соответствующих мета-моделей (хотя это в большей степени верно для UML, чем DSL, но DSL можно рассматривать и как аналог UML, предполагающий бОльшую свободу применений и интегрированность с конкретной платформой - Microsoft). Другая область стандартов, направленных blob - 829d7ca79b25dc2e6bfb1a4d3fc78c96eec6cd53 blob + cfe3acabbc28bc1f2820504131014bff7b142939 --- 4_software_testing.markdown +++ 4_software_testing.markdown @@ -746,12 +746,12 @@ IEEE, ISO/IEC, ГОСТ Р 12207 не выделяет тестирование достаточно и когда необходимо завершить процесс тестирования. Тщательные измерения, такие как достигнутое покрытие кода тестами или охват функциональности, безусловно, очень полезны. Однако, сами по себе они не могут -определить критериев достаточности тестирования. Приятие решения об окончании +определить критериев достаточности тестирования. Принятие решения об окончании тестирования также включает рассмотрение стоимости и рисков, связанных с потенциальными сбоями и нарушениями надёжности функционирования тестируемой программной системы. В то же время, стоимость самого тестирования также является одним из ограничений, на основе которых принимается решение о -продолжении тех или иных связанных с проектом работ (с частности, тестирования) +продолжении тех или иных связанных с проектом работ (в частности, тестирования) или об их прекращении. Cм. также 1.2.1 “Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования”. blob - 6bed2f44578167adfacd234d884ae08b32594e55 blob + 46d99b8d437cd2ab8eae584f4af8dfe5107d49f8 --- 5_software_maintenance.markdown +++ 5_software_maintenance.markdown @@ -50,7 +50,7 @@ Source во всем мире и связанная с многих организаций на первый план. Ситуация во многих ИТ-подразделениях показывает, что такие надежды оправдались только частично. Использование продуктов Open Source не стало дешевой альтернативой и, в ряде случаев, привело -даже к бОльшим проектным затратам именно в силу недостаточно проработанной +даже к бо́льшим проектным затратам именно в силу недостаточно проработанной политики эксплуатации и сопровождения построенных на их основе прикладных решений. Это ни в коем случае не значит, что волна Open Source “захлебнулась”. Это означает только, что игнорирование оценки стоимости сопровождения привело к @@ -58,7 +58,7 @@ Source во всем мире и связанная с инициатив по использованию таких продуктов в корпоративной среде. Неготовность рассматривать жизненный цикл во времени как продолжающийся и после передачи системы в эксплуатацию, непроработанность соответствующих процедур -корректировки продукта после его выпуска – основная беда и в бизнесе-среде, для +корректировки продукта после его выпуска – основная беда и в бизнес-среде, для которой программное обеспечение лишь инструмент, и в компаниях-интеграторах, “забывающих” о необходимости развития успеха после внедрения системы у заказчика, и у независимых поставщиков программных продуктов, которые, выпуская @@ -402,7 +402,7 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof представления о системе, иногда – даже не в разы, а на порядок (конечно, при достаточном уровне знания используемых технологий со стороны инженера по сопровождению). Если к этому добавить документированность (и доступность -соответствующих активов –спецификаций, моделей) архитектуры и ключевых +соответствующих активов – спецификаций, моделей) архитектуры и ключевых технологических решений со стороны разработчиков системы – обсуждаемый вопрос, конечно, не становится тривиальным, однако, превращается во вполне решаемую задачу. Вообще говоря, использование соответствующих средств автоматизации @@ -427,7 +427,7 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof быть существенным как по времени, так и по стоимости. Для сопровождения системы особо значимым является выборочное регрессионное тестирование (см. область знаний Software Testing, тему 2.2.6 Регрессионное тестирование) системы или его -компонент для проверки того, что внесенные изменения для привели к +компонент для проверки того, что внесенные изменения привели к непреднамеренному изменению поведения программного обеспечения. Вопрос состоит в том, что часто сложно найти время для необходимого тестирования. Не меньшей проблемой является и координации в проведении тестов различными членами группы @@ -503,7 +503,7 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof технологическое решение. Иногда это может быть временное решение, может быть даже нарушающее архитектурные шаблоны системы, однако, обоснованное с точки зрения сроков и стоимости его реализации. В то же самое время, результаты -анализа направляются разработчикам системы, обычно работающим над следующей +анализа направляются разработчикам системы, обычно работающими над следующей версией, для включения соответствующего изменения уже в рамках принятого стиля кодирования, соглашений, архитектурных шаблонов и т.п. Безусловно, такой путь многим может показаться просто неэтичным, с точки зрения “настоящего” blob - 443322fd5fc0affa79206dbd51a35aeda89e876c blob + c851acf998140424efaf3422eddf3c38b762ddab --- 7_software_engineering_management.markdown +++ 7_software_engineering_management.markdown @@ -63,7 +63,7 @@ Glossary for Software Engineering Terminology). деятельности внутренние организационные стандарты, обеспечивающие эффективное управление программной инженерией. Эти политики являются основой для решения долгосрочных задач улучшения процессов и повышения производительности труда -специалистов, вовлеченных с работы по созданию сопровождению программного +специалистов, вовлеченных в работы по созданию и сопровождению программного обеспечения. Другим важным аспектом управления является управление персоналом через политики @@ -269,7 +269,7 @@ project enactment”, ее название и пер – выбор и применение методов определения (извлечения), анализа (например, моделирования сценариев use case), специфицирования и проверки (например, -прототипирования) требований, принимая в внимание позицию различных +прототипирования) требований, принимая во внимание позицию различных заинтересованных лиц. Это является первичными работами, необходимыми для определения содержания, целей и ограничений проекта. Данные работы важны всегда, так как позволяют определить четкие границы задач, необходимых для @@ -641,7 +641,7 @@ analysis) <плана с реальным выполн ## Закрытие (Closure) Проект закрывается/завершается (не путайте с прекращением проекта), когда все -планы и процессы выполнены и завершены. На этой стадии в результатам проекта +планы и процессы выполнены и завершены. На этой стадии по результатам проекта применяются критерии оценки его успешности. Когда принимается решение о закрытии проекта, выполняются действия по архивированию проектных данных, анализу результатов, полученных в процессе работы над проектом (post mortem blob - 62ebc739583f4da9849badb17d3280307c791289 blob + 433d38e060d9606b132462f4f7abd0e2d6ed6d44 --- 8_software_engineering_process.markdown +++ 8_software_engineering_process.markdown @@ -114,7 +114,7 @@ Process”). #### Software Engineering Process Group (SEPG) SEPG создается как центральный орган, принимающий на себя работу по -processimprovement - совершенствованию процесса(-ов). SEPG берет на себя +process improvement - совершенствованию процесса(-ов). SEPG берет на себя ответственность по множеству вопросов, связанных с этой задачей в терминах инициирования <улучшений> и поддержки <существующего процесса и его постоянного совершенствования>. @@ -716,7 +716,7 @@ metrology). Качество результатов измерений, в терминах точности, повторяемости и воспроизводимости, связано с инструментальной составляющей и используемой концепцией оценки и точкой зрения в отношении измерений (например, когда -оценивающее лицо – ассессор - выставляет оценки по конкретным процессам). +оценивающее лицо – асессор - выставляет оценки по конкретным процессам). Техники измерения процесса классифицируются по двум типам: аналитическая и эталонная (benchmarking). Эти два типа используются вместе, так как blob - d2468dd5f9bfe919fa70417436df54e190caf21d blob + 94bee7c4314e825ef2f5b6a54fecadebd921a83e --- 9_software_engineering_tools_and_methods.markdown +++ 9_software_engineering_tools_and_methods.markdown @@ -217,7 +217,7 @@ Amazon и др.), которые включают на отличие от тестирования <корректности> функционального поведения. Последний класс инструментов тестирования, в какой-то степени, показывает -недостаточностьпредложенной классификации, упуская, например, инструменты +недостаточность предложенной классификации, упуская, например, инструменты функционального тестирования, средства тестирования безопасности, инструменты тестирования пользовательского интерфейса, инструменты нагрузочного тестирования и др., соответствующие, различным целям тестирования, @@ -417,11 +417,11 @@ methods). Такие специализированн уровне внутренней реализации конкретных инструментов программной инженерии, например, в средствах моделирования и проектирования. Иан Соммервилл дает такую характеристику формальным методам [Соммервилл, 2002, стр. 188]: “Традиционные -технические дисциплины … обычно легко адаптируют математические методы. Однако +технические дисциплины обычно легко адаптируют математические методы. Однако инженерия программного обеспечения не идет таким путем. Хотя прошло более 25 лет исследований по использованию математических методов в процессе создания ПО, воздействие этих методов все же ограничено. Так называемые формальные методы -… широко не используются. Многие компании, разрабатывающие ПО, не считают +широко не используются. Многие компании, разрабатывающие ПО, не считают экономически выгодным применение этих методов в процессе разработки.” ### Методы прототипирования (Prototyping Methods) blob - 87d1379117fbdfad9a19b25e834ccabcd6c13f49 blob + 8a242ba641445ee376386dbc8833dfa36f163b59 --- software_lifecycle_models.markdown +++ software_lifecycle_models.markdown @@ -163,7 +163,7 @@ Processes” – “Процессы жизненно ### Основные процессы жизненного цикла - Primary Processes -5.1 Заказ - Acqusition +5.1 Заказ - Acquisition 5.2 Поставка - Supply 5.3 Разработка - Development 5.4 Эксплуатация - Operation @@ -588,7 +588,7 @@ ISO/IEC 15288 (выпущен в 2002 году), фо сопровождению, так и критичным вопросам, связанным с расширением функциональности продукта, всегда ассоциированным с повышенными рисками. -> Модель позволяет решать интегрированный задачи системной разработки, +> Модель позволяет решать интегрированные задачи системной разработки, охватывающей и программную и аппаратную составляющие создаваемого продукта. Подход, основанный на управлении рисками и возможности своевременного отбрасывания непривлекательных альтернатив (на ранних стадиях проекта) @@ -609,7 +609,7 @@ all software development participants are operating in *методологии разработки*. Действительно, детализация процессов, ролей и активов – вопрос методологии. -Однако, рассматривая (спиральная) модель разработки, являясь концептуальным +Однако, рассматривая (спиральную) модель разработки, являясь концептуальным взглядом на создание продукта, требует, как и в любом проекте, *определения ключевых контрольных точек проекта - milestones*. Это, в большой степени, связано с попыткой ответить на вопрос “где мы?”. Вопрос, особенно актуальный