commit 98f9c0b64bcb6bbe09bcb8892863f45b8c85c4d0 from: Mike Voznesensky via: Sergey Bronnikov date: Sat Jan 20 11:36:22 2024 UTC Fixed enumeration commit - dcaa803f0887dee08029ae7d380158de4dfc3960 commit + 98f9c0b64bcb6bbe09bcb8892863f45b8c85c4d0 blob - 933593d398673bf66ec035c76972b90db02dbe94 blob + a37cbedd34e49a068c802d43b7d4683aa9d59d49 --- 1_software_requirements.markdown +++ 1_software_requirements.markdown @@ -44,13 +44,13 @@ SWEBOK охватывает не только вопр представлена в виде ключевых тем (см. рисунок 2). Кроме того, данная область знаний тесно связана со следующими областями: -- software design -- software testing -- software maintenance -- software configuration management -- software engineering management -- software engineering process -- software quality +- Software Design +- Software Testing +- Software Maintenance +- Software Configuration Management +- Software Engineering Management +- Software Engineering Process +- Software Quality ## Основы программных требований (Software Requirements Fundamentals) @@ -62,7 +62,7 @@ SWEBOK охватывает не только вопр ### Определение требований (Definition of a Software Requirement) -– в данном случае подразумевается не процесс определения (извлечения, сбора, формирования, +В данном случае подразумевается не процесс определения (извлечения, сбора, формирования, формулирования) требований, а дается само понятие “требования”, как такового, и отмечаются его основные характеристики, например, верифицируемость (проверяемость) требования. @@ -71,17 +71,17 @@ SWEBOK охватывает не только вопр понятия “требование” (на основе работ Вигерса и стандарта IEEE Standard Glossary Of Software Engineering Terminology, 1990): -условие или возможность, требуемая пользователем для решения задач или +- Условие или возможность, требуемая пользователем для решения задач или достижения целей. -условие или возможность, которые должны удовлетворяться системой/компонентом +- Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами. -документальная репрезентация (зафиксированное представление, определение, +- Документальная репрезентация (зафиксированное представление, определение, описание) условий или возможностей, перечисленных в предыдущих пунктах. ### Требования к продукту и процессу (Product and Process Requirements) -– проводится разграничение соответствующих требований как свойств продукта, +Проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться; отмечается, что ряд требований может быть заложен неявно и программные требования могут порождать требования к процессу, например: работа @@ -94,7 +94,7 @@ Glossary Of Software Engineering Terminology, 1990): ### Функциональные и нефункциональные требования (Functional and Non-Functional Requirements) -– функциональные требования задают “что” система должна делать; +Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) use сase. @@ -104,24 +104,24 @@ Glossary Of Software Engineering Terminology, 1990): (видов) требований и связанных с ними понятий, важнейших с точки зрения их понимания и дальнейшего практического применения: -- потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, +- Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы. -- группа функциональных требований - - бизнес-требования (business requirements) – определяют высокоуровневые цели +- Группа функциональных требований + - Бизнес-требования (business requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения. - - пользовательские требования (user requirements) – описывают цели/задачи + - Пользовательские требования (user requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (use cases). - - функциональные требования (functional requirements) – определяют + - Функциональные требования (functional requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. -- группа нефункциональных требований (non-functional requirements) - - бизнес-правила (business rules) – включают или связаны с корпоративными +- Группа нефункциоНальных Требований (non-functional requirements) + - Бизнес-правила (business rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и @@ -141,7 +141,7 @@ Glossary Of Software Engineering Terminology, 1990): ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение. - - внешние интерфейсы (external interfaces) – часто подменяются + - Внешние интерфейсы (external interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной @@ -151,20 +151,20 @@ Glossary Of Software Engineering Terminology, 1990): интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей. - - атрибуты качества (quality attributes) – описывают дополнительные + - Атрибуты качества (quality attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п. - - ограничения (constraints) – формулировки условий, модифицирующих требования + - Ограничения (constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам. -- системные требования (system requirements) – иногда классифицируются как +- Системные требования (system requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных @@ -266,7 +266,7 @@ Features могут быть разного уровн ### Независимые или общие свойства (Emergent Properties) -– эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть +Эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть соотнесены с отдельнымы ее элементами. Т.е. данные требования относятся к тому синергетическому эффекту, которым может обладать такая система («целое больше, чем сумма его частей»). Примером может служить требования к «пропускной @@ -276,7 +276,7 @@ Features могут быть разного уровн ### Требования с количественной оценкой (Quantifiable Requirements) -– требования, поддающиеся количественному определению/измерению, например, +Требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост @@ -321,7 +321,7 @@ kshell (популярной командной обо ### Системные требования и программные требования (System Requirements and Software Requirements) -– данное разделение базируется на определении “системы”, +Данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов <созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, @@ -631,7 +631,6 @@ SADT – Structured Analysis and Design Technique (м моделирование – стандарт IEEE 1320.2, известный также как IDEFObject), часто применяемым как для моделирования бизнес-процессов, так и структур данных, в частности – реляционных баз данных. -- ??? Так или иначе, вне зависимости от выразительных средств, которые являются лишь инструментом анализа и фиксирования результатов, результатом анализа требований blob - e7a7acfc91f4d6992dd346054b453b9324f59599 blob + 443322fd5fc0affa79206dbd51a35aeda89e876c --- 7_software_engineering_management.markdown +++ 7_software_engineering_management.markdown @@ -41,6 +41,7 @@ Glossary for Software Engineering Terminology). Что касается программной инженерии, управленческая деятельность в этой области происходит на трех уровнях: + - Организационное управление и управление инфраструктурой - Управление проектами - Планирование и контроль программ количественной оценки blob - 3adfd562f16c24ef4d854d346f5049f91c5c330b blob + d2468dd5f9bfe919fa70417436df54e190caf21d --- 9_software_engineering_tools_and_methods.markdown +++ 9_software_engineering_tools_and_methods.markdown @@ -369,8 +369,7 @@ SWEBOK идентифицированы три кат программное обеспечение. Функции в этом случае являются вторичными. - Объектно-ориентированные методы (object-oriented methods). Система при таком подходе рассматривается как коллекция объектов, а не функций. - -Методы, ориентированные на конкретную область применения (domain-specific +- Методы, ориентированные на конкретную область применения (domain-specific methods). Такие специализированные методы разрабатываются с учетом специфики решаемых задач, например, систем реального времени, безопасности <жизнедеятельности> (safety) и защищенности <от несанкционированного доступа> @@ -406,8 +405,7 @@ methods). Такие специализированн превращения спецификаций в конечный результат, максимально близкий желаемому. В качестве результата применения таких методов рассматривается конечный - исполнимый программный продукт. - -Подтверждение/доказательство (verification/proving properties). Этот подход +- Подтверждение/доказательство (verification/proving properties). Этот подход основывается на строгом доказательстве точности <любых> характеристик <исходных предпосылок и получаемого продукта> с использованием теорем и проверки точности моделей. blob - f16192805ec0688ff10c795456af6b2e5439df87 blob + 87d1379117fbdfad9a19b25e834ccabcd6c13f49 --- software_lifecycle_models.markdown +++ software_lifecycle_models.markdown @@ -223,9 +223,9 @@ Processes” – “Процессы жизненно следующим образом: * группа процессов -** процессы -*** работы -**** задачи + * процессы + * работы + * задачи В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле: @@ -528,7 +528,8 @@ ISO/IEC 15288 (выпущен в 2002 году), фо 1. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. 1. Недостаточная производительность получаемой системы. 1. “Разрыв” в квалификации специалистов разных областей знаний. -1. Большая часть этих рисков связана с организационными и процессными аспектами + +Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде. ![Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму (используется с разрешения автора) [Boehm, 1988]](images/lifecycle_spiral-boehm.jpg)