commit - dcaa803f0887dee08029ae7d380158de4dfc3960
commit + 98f9c0b64bcb6bbe09bcb8892863f45b8c85c4d0
blob - 933593d398673bf66ec035c76972b90db02dbe94
blob + a37cbedd34e49a068c802d43b7d4683aa9d59d49
--- 1_software_requirements.markdown
+++ 1_software_requirements.markdown
представлена в виде ключевых тем (см. рисунок 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)
### Определение требований (Definition of a Software Requirement)
-– в данном случае подразумевается не процесс определения (извлечения, сбора, формирования,
+В данном случае подразумевается не процесс определения (извлечения, сбора, формирования,
формулирования) требований, а дается само понятие “требования”, как такового, и
отмечаются его основные характеристики, например, верифицируемость
(проверяемость) требования.
понятия “требование” (на основе работ Вигерса и стандарта IEEE Standard
Glossary Of Software Engineering Terminology, 1990):
-условие или возможность, требуемая пользователем для решения задач или
+- Условие или возможность, требуемая пользователем для решения задач или
достижения целей.
-условие или возможность, которые должны удовлетворяться системой/компонентом
+- Условие или возможность, которые должны удовлетворяться системой/компонентом
системы или которыми система/компонент системы должна обладать для обеспечения
условий контракта, стандартов, спецификаций или др. регулирующими документами.
-документальная репрезентация (зафиксированное представление, определение,
+- Документальная репрезентация (зафиксированное представление, определение,
описание) условий или возможностей, перечисленных в предыдущих пунктах.
### Требования к продукту и процессу (Product and Process Requirements)
-– проводится разграничение соответствующих требований как свойств продукта,
+Проводится разграничение соответствующих требований как свойств продукта,
который необходимо получить, и процесса, с помощью которого продукт будет
создаваться; отмечается, что ряд требований может быть заложен неявно и
программные требования могут порождать требования к процессу, например: работа
### Функциональные и нефункциональные требования (Functional and Non-Functional Requirements)
-– функциональные требования задают “что” система должна делать;
+Функциональные требования задают “что” система должна делать;
нефункциональные – с соблюдением “каких условий” (например, скорость отклика
при выполнении заданной операции); часто функциональные требования представляют
в виде сценариев (вариантов использования) use сase.
(видов) требований и связанных с ними понятий, важнейших с точки зрения их
понимания и дальнейшего практического применения:
-- потребности (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-го уровня), учетными практиками, алгоритмами вычислений и
ограничения бизнес-проектов, для автоматизации которых создается
соответствующее программное обеспечение.
- - внешние интерфейсы (external interfaces) – часто подменяются
+ - Внешние интерфейсы (external interfaces) – часто подменяются
“пользовательским интерфейсом”. На самом деле вопросы организации
пользовательского интерфейса безусловно важны в данной категории требований,
однако, конкретизация аспектов взаимодействия с другими системами, операционной
интерфейсов, так как функциональные требования связаны непосредственно с
функциональностью системы, направленной на решение бизнес-потребностей.
- - атрибуты качества (quality attributes) – описывают дополнительные
+ - Атрибуты качества (quality attributes) – описывают дополнительные
характеристики продукта в различных “измерениях”, важных для пользователей
и/или разработчиков. Атрибуты касаются вопросов портируемости,
интероперабельности (прозрачности взаимодействия с другими системами),
целостности, устойчивости и т.п.
- - ограничения (constraints) – формулировки условий, модифицирующих требования
+ - Ограничения (constraints) – формулировки условий, модифицирующих требования
или наборы требований, сужая выбор возможных решений по их реализации. В
частности, к ним могут относиться параметры производительности, влияющие на
выбор платформы реализации и/или развертывания (протоколы, серверы приложений,
баз данных, ...), которые, в свою очередь, могут относиться, например, к
внешним интерфейсам.
-- системные требования (system requirements) – иногда классифицируются как
+- Системные требования (system requirements) – иногда классифицируются как
составная часть группы функциональных требований (не путайте с как таковыми
“функциональными требованиями”). Описывают высокоуровневые требования к
программному обеспечению, содержащему несколько или много взаимосвязанных
### Независимые или общие свойства (Emergent Properties)
-– эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть
+Эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть
соотнесены с отдельнымы ее элементами. Т.е. данные требования относятся к тому
синергетическому эффекту, которым может обладать такая система («целое больше,
чем сумма его частей»). Примером может служить требования к «пропускной
### Требования с количественной оценкой (Quantifiable Requirements)
-– требования, поддающиеся количественному определению/измерению, например,
+Требования, поддающиеся количественному определению/измерению, например,
система должна обеспечить пропускную способность “столько-то запросов в
секунду”; в то же самое время, крайне важно понимать, что постановка вопроса
(то есть формулирование требования) в форме “система должна обеспечить рост
### Системные требования и программные требования (System Requirements and Software Requirements)
-– данное разделение базируется на определении “системы”,
+Данное разделение базируется на определении “системы”,
данном INCOSE (International Council on Systems Engineering) “комбинация
взаимодействующих элементов <созданная> для достижения определенных целей;
может включать аппаратные средства, программное обеспечение, встроенное ПО,
моделирование – стандарт IEEE 1320.2, известный также как IDEFObject), часто
применяемым как для моделирования бизнес-процессов, так и структур данных, в
частности – реляционных баз данных.
-- ???
Так или иначе, вне зависимости от выразительных средств, которые являются лишь
инструментом анализа и фиксирования результатов, результатом анализа требований
blob - e7a7acfc91f4d6992dd346054b453b9324f59599
blob + 443322fd5fc0affa79206dbd51a35aeda89e876c
--- 7_software_engineering_management.markdown
+++ 7_software_engineering_management.markdown
Что касается программной инженерии, управленческая деятельность в этой области
происходит на трех уровнях:
+
- Организационное управление и управление инфраструктурой
- Управление проектами
- Планирование и контроль программ количественной оценки
blob - 3adfd562f16c24ef4d854d346f5049f91c5c330b
blob + d2468dd5f9bfe919fa70417436df54e190caf21d
--- 9_software_engineering_tools_and_methods.markdown
+++ 9_software_engineering_tools_and_methods.markdown
программное обеспечение. Функции в этом случае являются вторичными.
- Объектно-ориентированные методы (object-oriented methods). Система при таком
подходе рассматривается как коллекция объектов, а не функций.
-
-Методы, ориентированные на конкретную область применения (domain-specific
+- Методы, ориентированные на конкретную область применения (domain-specific
methods). Такие специализированные методы разрабатываются с учетом специфики
решаемых задач, например, систем реального времени, безопасности
<жизнедеятельности> (safety) и защищенности <от несанкционированного доступа>
превращения спецификаций в конечный результат, максимально близкий желаемому. В
качестве результата применения таких методов рассматривается конечный -
исполнимый программный продукт.
-
-Подтверждение/доказательство (verification/proving properties). Этот подход
+- Подтверждение/доказательство (verification/proving properties). Этот подход
основывается на строгом доказательстве точности <любых> характеристик <исходных
предпосылок и получаемого продукта> с использованием теорем и проверки точности
моделей.
blob - f16192805ec0688ff10c795456af6b2e5439df87
blob + 87d1379117fbdfad9a19b25e834ccabcd6c13f49
--- software_lifecycle_models.markdown
+++ software_lifecycle_models.markdown
следующим образом:
* группа процессов
-** процессы
-*** работы
-**** задачи
+ * процессы
+ * работы
+ * задачи
В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле:
1. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
1. Недостаточная производительность получаемой системы.
1. “Разрыв” в квалификации специалистов разных областей знаний.
-1. Большая часть этих рисков связана с организационными и процессными аспектами
+
+Большая часть этих рисков связана с организационными и процессными аспектами
взаимодействия специалистов в проектной команде.
![Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму (используется с разрешения автора) [Boehm, 1988]](images/lifecycle_spiral-boehm.jpg)
