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*. Это, в большой степени,
 связано с попыткой ответить на вопрос “где мы?”. Вопрос, особенно актуальный