Процесс работы с требованиями. Модель процесса определения требований. Участники процессов. Управление и поддержка процессов. Качество и улучшение процессов.



Программная Инженерия.

1.  Основы программных требований. Определение требований. Требования к продукту и процессу. Функциональные и нефункциональные требования Независимые свойства. Требования с количественной оценкой.. Системные требования и программные требования. 4

2. Процесс работы с требованиями. Модель процесса определения требований. Участники процессов. Управление и поддержка процессов. Качество и улучшение процессов. 8

3. Извлечение требований. Источники требований. Техники извлечения требований. 10

4. Анализ требований. Классификация требований. Концептуальное моделирование. Архитектурное проектирование и распределение требований. 12

5. Спецификация требований. Определение системы. Спецификация системных требований. Спецификация программных требований. 15

6. Проверка требований. Обзор требований. Прототипирование. Утверждение модели. Приемочные тесты. 17

7. Практические соображения. Итеративная природа процесса работы с требованиями. Управление изменениями. Атрибуты требований. Трассировка требований. Измерение требований. 19

8. Основы проектирования. Общие концепции проектирования. Контекст проектирования. Процесс проектирования. Техники применения. 21

9. Ключевые вопросы проектирования. Параллелизм. Контроль и обработка событий. Распределение компонентов. Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости. Взаимодействие и представление. Сохраняемость данных. 23

10. Структура и архитектура программного обеспечения. Архитектурные структуры и точки зрения. Архитектурные стили. Шаблоны проектирования. Семейства программ и фреймворков. 24

11. Анализ качества и оценка программного дизайна. Атрибуты качества. Анализ качества и техники оценки. Измерения. 26

12. Нотации проектирования. Структурные описания, статический взгляд. Поведенческие описания, динамический взгляд. 27

13. Стратегии и методы проектирования программного обеспечения. Общие стратегии. Функционально-ориентированное или структурное проектирование. Объектно-ориентированное проектирование. Проектирование на основе структур данных. Компонентное проектирование. Другие методы. 29

14. Основы конструирования. Минимизация сложности. Ожидание изменений. Конструирование с возможностью проверки. Стандарты в конструировании. 31

15. Управление конструированием. Модели конструирования. Планирование конструирования. Измерения в конструировании. 33

16. Практические соображения. Проектирование в конструировании. Языки конструирования. Кодирование. Тестирование в конструировании. Повторное использование. Качество конструирования. Интеграция. 35

17. Основы тестирования. Терминология тестирования. Ключевые вопросы. Связь тестирования с другой деятельностью. 38

18. Уровни тестирования. Над чем производятся тесты. Цели тестирования. 39

19. Техники тестирования. Техники, базирующиеся на интуиции и опыте инженера. Техники, базирующиеся на спецификации. Техники, ориентированные на код. Тестирование, ориентированное на дефекты. Техники, базирующиеся на условиях использования. Техники, базирующиеся на природе приложения. Выбор и комбинация различных техник. 41

20. Измерение результатов тестирования. Оценка программ в процессе тестирования. Оценка выполненных тестов. 43

21. Процесс тестирования. Практические соображения. Тестовые работы. 45

22. Основы сопровождения программного обеспечения. Определения и терминология. Природа сопровождения. Потребность в сопровождении. Приоритет стоимости сопровождения. Эволюция программного обеспечения. Категории сопровождения. 48

23. Ключевые вопросы сопровождения программного обеспечения. Технические вопросы. Управленческие вопросы. Оценка стоимости сопровождения. Измерения в сопровождении программного обеспечения. 52

24. Процесс сопровождения. Процессы сопровождения. Работы по сопровождению. 57

25. Техники сопровождения. Понимание программных систем. Реинжиниринг. Обратный инжиниринг. 61

26. Управление SCM-процессом. Организационный контекст SCM. Ограничения и правила SCM. Планирование в SCM. План конфигурационного управления. Контроль выполнения SCM-процесса. 62

27. Идентификация программных конфигураций. Идентификация элементов, требующих контроля. Программная библиотека. 67

28. Контроль программных конфигураций. Предложение, оценка и утверждение изменений. Реализация изменений. Отклонения и отказ от изменений. 70

29. Учет статусов конфигураций. Информация о статусе конфигураций. Отчетность по статусу конфигураций. 73

30. Аудит конфигураций. Функциональный аудит программных конфигураций. Физический аудит программных конфигураций. Внутренние аудиты базовых линий. 74

31. Управление выпуском и поставкой. Сборка программного обеспечения. Управление выпуском программного обеспечения. 75

32. Инициирование и определение содержания. Определение и обсуждение требований. Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. Процесс оценки и пересмотра требований. 77

33. Планирование программного проекта. Планирование процесса. Определение результатов. Оценка усилий, расписания и стоимостных ожиданий. Распределение ресурсов. Управление рисками. Управление качеством. Управление планом проекта. 78

34. Выполнение программного проекта. Реализация планов. Управление контрактами с поставщиками. Реализация процесса по ведению измерений. Процесс мониторинга. Процесс контроля. Ведение отчетности. 81

35. Обзор и оценка. Определение удовлетворения требованиям. Оценка продуктивности и результативности. 83

36. Закрытие. Определение критериев закрытия проекта. Работы по закрытию проекта. 84

37. Измерения в программной инженерии. Установление и поддержка процесса ведения измерений. Планирование процесса измерений. Выполнение процесса измерений. Оценка измерений. 85

38. Реализация и изменение процесса. Инфраструктура процесса. Цикл управления программным процессом. Модели реализации и изменения процесса. Практические соображения. 88

39. Определение процесса. Модели жизненного цикла программного обеспечения. Процессы жизненного цикла программного обеспечения. Нотации определения процесса. Адаптация процесса. Автоматизация. 91

40. Оценка процесса. Модели оценки процесса. Методы оценки процесса. 93

41. Измерения в отношении процессов и продуктов. Измерения в отношении процессов. Измерения в отношении программных продуктов. Качество результатов измерений. Информационные модели. Техники количественной оценки процессов. 95

42. Инструменты программной инженерии. Инструменты работы с требованиями. Инструменты проектирования. Инструменты конструирования. Инструменты тестирования. Инструменты сопровождения. Инструменты конфигурационного управления. Инструменты управления инженерной деятельностью. Инструменты поддержки процессов. Инструменты обеспечения качества. Дополнительные аспекты инструментального обеспечения. 99

43. Методы программной инженерии. Эвристические методы. Формальные методы. Методы прототипирования. 103

44. Основы качества программного обеспечения. Культура и этика программной инженерии. Значение и стоимость качества. Модели и характеристики качества. Повышение качества. 105

45. Процессы управления качеством программного обеспечения. Подтверждение качества программного обеспечения. Проверка (верификация) и аттестация. Оценка (обзор) и аудит. 108

46. Практические соображения. Требования к качеству программного обеспечения. Характеристика дефектов. Техники управления качеством программного обеспечения. Количественная оценка качества программного обеспечения. 112

47. Процессы жизненного цикла программного обеспечения. Организация стандарта и архитектура жизненного цикла. Основные процессы жизненного цикла. Приобретение. Поставка. Разработка. Эксплуатация. Сопровождение. Адаптация стандарта. 117

48. Модели жизненного цикла. Каскадная (водопадная) модель. Итеративная и инкрементальная модель - эволюционный подход. Спиральная модель. 120

49.  Привести пример реализации ответа на каждый вопрос из перечня вопросов к экзамену по дисциплине “Программная инженерия” на конкретном программном продукте экономической направленности. 126

 


 

Основы программных требований. Определение требований. Требования к продукту и процессу. Функциональные и нефункциональные требования Независимые свойства. Требования с количественной оценкой.. Системные требования и программные требования.

Эта секция включает определение программных требований как таковых и описывает основные типы требований и их отличия: к продукту и процессу, функциональные и нефункциональные требования и т.п.

1.1 Определение требований (Definition of a Software Requirement) – в данном случае подразумевается не процесс определения (извлечения, сбора, формирования, формулирования) требований, а дается само понятие “требования”, как такового, и отмечаются его основные характеристики, например, верифицируемость (проверяемость) требования.

По мнению авторов, необходимо обратить внимание на следующие определения понятия “требование” (на основе работ Вигерса и стандарта IEEE Standard Glossary of Software Engineering Terminology, 1990):

  • Условие или возможность, требуемая пользователем для решения задач или достижения целей.
  • Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами.
  • Документальная репрезентация (зафиксированное представление, определение, описание) условий или возможностей, перечисленных в предыдущих пунктах.

1.2 Требования к продукту и процессу (Product and Process Requirements) – проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться; отмечается, что ряд требований может быть заложен неявно и программные требования могут порождать требования к процессу, например: работа в режиме 24x7 (как бизнес-требование) наверняка приведет к ограничению выбора тех или иных программных средств, платформ развертывания и архитектурных решений; в свою очередь, выбор платформы J2EE (Java 2 Enterprise Edition) и ее реализации в виде конкретного сервера приложений практически наверняка потребует применения модульного тестирования (Unit testing) как практики процесса разработки и JUnit, как инструмента реализации этой практики.

1.3 Функциональные и нефункциональные требования (Functional and Non-functional Requirements) – функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

Систематизируя работы Вигерса, Лефингвелла и Видрига, Коберна, а также других экспертов, Возможно и необходимо привести классификацию различных категорий (видов) требований и связанных с ними понятий, важнейших с точки зрения их понимания и дальнейшего практического применения:

  • Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы.
  • Группа функциональных требований
    • Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.
    • Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).
    • Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.
  • Группа нефункциональных требований (Non-Functional Requirements)
    • Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.
    • Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно сфункциональностью системы, направленной на решение бизнес-потребностей.
    • Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
    • Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
  • Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

Необходимо сделать несколько важных замечаний по бизнес-правилам. Бизнес правила, как таковые, являются предметом пристального изучения различных специалистов в области как бизнес-моделирования, так и программной инженерии в целом. Практика разработки программных требований включает идентификацию и описание бизнес-правил как самостоятельных артефактов. Например, методология RUP выделяет отдельный артефакт Business Rule в рамках дисциплины Business Modeling. Все бизнес-правила, в рамках данной дисциплины, идентифицируются и описываются в документе Business Rules Document. При разработке требований, в сценариях Use Cases обычно включается ссылка на уже описанное бизнес-правило. Скотт Амблер (см. www.agilemodeling.com/artifacts/) так же выделяет бизнес-правило как один из артефактов, который используют в семействе Agile методологий.

В настоящее время разработаны методы и подходы формального представления бизнес-правил, вплоть до формальных языков описания (использование OCL – Object Constraint Language, BRML – Business Rules Markup Language).

Бизнес-правила могут быть не только использованы при определении требований к разрабатываемому ПО, но и могут отдельно оформляться в дизайне ПО (класс или группа классов), отражаясь в конечном итоге в программном коде на определенном языке программирования. Существуют специализированные инструментальные средства и библиотеки, позволяющие разрабатывать и поддерживать приложения, интенсивно использующие бизнес-правила.

Рассматривая бизнес-правила, как артефакты относящиеся к области программных требований можно отметить, вернее дать одно из пояснений, почему БП относят к нефункциональным требованиям: Например, при написании определенного шага в сценарии use case, используется ссылка на бизнес правило: «… система производит расчет стоимости в соответствии с бизнес-правилом BP41 …». В свою очередь данное бизнес-правило может определять алгоритм расчета стоимости. Т.е. налицо «с соблюдением каких условий система делает расчет».

Одним из наиболее известных специалистов по BR является Рональд Росс, автор книги «Principles of the Business Rule Approach» (Ronald G. Ross. «Principles of the Business Rule Approach», 2003).

Наравне с представленной классификацией требований, могут использоваться и другие подходы.

Даже в рамках этой классификации, существуют и различные взгляды на ее интерпретацию и детализацию. Например, как результат определения целевой аудитории и в рамках маркетинговой стратегии продвижения тиражируемого решения, возможно определять высокоуровневые возможности (ключевые характеристики, особенности) – “фичи” (features) разрабатываемого продукта. Иногда, такие возможности детализируются в смысле функциональных требований в некоторых agile-техниках, например, FDD – Feature-Driven Development (как вы видите вплоть до самого названия целого комплекса практик, метода разработки).

Вигерс, описывает feature как “множество логически связанных функциональных требований, которые предоставляют определенные возможности для пользователя и удовлетворяют бизнес-целям <организации>”. С точки зрения маркетинга программного обеспечения, как отмечает Вигерс, feature это «группа требований, узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия решения по приобретению ПО – это список <отличительных особенностей или возможностей, характеристик>, присутствующий в описании продукта». В то же время, Леффингвелл и Видриг (D.Leffingwell, D. Widrig, Managing Software Requirements: A Use Case Approach, Second Edition, 2003) определяют feature как “сервисы, которые оказывает система для удовлетворения одной или более потребностей заинтересованных лиц (stakeholders needs)”. Ими же отмечается, что в реальных проектах могут быть не определены stakeholders needs (а их часто выделяют, особенно если у проекта/продукта есть много заинтересованных лиц со своими потребностями, и эти потребности могут носить взаимоисключающий характер), но существовать features могут и самостоятельно (как и stakeholder needs), и конечно же возможно существование и stakeholder needs и features со взаимной трассировкой.

Развивая тему features -- Kurt Bittner & Ian Spence в своей книге “Use Case Modeling” (Kurt Bittner, Ian Spence. Use Case Modeling, 2002), дают схожее, хотя и более формальное определение features. Они отмечают, что features могут быть как относящимся к функциональным, так и к нефункциональным требованиям. И могут изменяться от версии к версии продукта.

Анализируя различные источники на предмет работы с features, следует отметить следующее:

С точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными (в т.ч. с ограничениями проектирования или атрибутами качества).

Необходимо также отметить, что Features обладают определенным дуализмом в своей интерпретации, зависимым от контекста конкретного продукта – с одной стороны это может быть «тот самый список характеристик, указанный на коробке продукта» в случае создания «коробочного ПО», с другой стороны это может список высокоуровневых возможностей системы, например при заказной разработке ПО автоматизации бизнес-процессов конкретной организации.

Features могут быть разного уровня детализации – от выражения высокоуровневых возможностей системы (например, «Расчет заработной платы …»), до достаточно конкретных требований (например, «Автоматическое уведомление Клиента по e-mail о резервировании товара на складе»)

1.4 Независимые или общие свойства (Emergent Properties) – эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть соотнесены с отдельнымы ее элементами. Т.е. данные требования относятся к тому синергетическому эффекту, которым может обладать такая система («целое больше, чем сумма его частей»). Примером может служить требования к «пропускной способности» коллцентра, которая будут зависеть от того, каким образом будут взаимодействовать коммуникационное оборудование, оператор и программное обеспечение в конкретных условиях.
1.5 Требования с количественной оценкой (Quantifiable Requirements) – требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост пропускной способности” без указания конкретных количественных характеристик является просто некорректно определенным требованием.

При этом, например, требование “система должна вести журнал подключений пользователей” может и должно детализироваться с точки зрения описания информации, которую необходимо сохранять в журнале, однако, такое требование уже не будет являться количественным требованием. А требование с формулировкой “система должна обладать интуитивно-понятным пользовательским интерфейсом” - непроверяем. В определенных случаях, по мнению автора книги, это может выглядеть просто издевкой, даже не являясь изначально таковой – все зависит от точки зрения: например, в устах “целевого” пользователя специализированного программного обеспечения – системного администратора, привыкшего работать в kshell (популярной командной оболочке Unix/Linux), объясняющего свои потребности аналитику, фиксирующему запросы пользователя и привыкшего оперировать Microsoft Office ;) Может ли такое требование быть переформулировано и/или детализировано для адекватности интерпретации? Да. Например, так – средний показатель ошибок оператора не должен превышать 2% от объема вводимой информации и 85% пользователей должны дать положительную оценку прототипу пользовательского интерфейса на этапе опытной эксплуатации.

Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с численными величинами – как часто? насколько быстро? в каком количестве? и т.п.

Большинство требований с количественной оценкой относится к атрибутам качества.

В качестве примера можно привести реальное требование, присутствующее в реальном проекте по электронному документообороту: “Система должна производить поиск документов <определенного вида> за время, не превышающее 5 секунд”. Это типичное требование с количественной оценкой, в котором определена верхняя граница диапазона времени, за которое должен быть осуществлен поиск документов. Несомненно, этот атрибут качества системы существует в контексте определенного функционального требования о возможности поиска документов по определенным критериям. И этот контекст или связь должна быть определена либо явно, в рамках иерархии требований, либо посредством трассировки, между требованиями разных видов (функционального и атрибута качества). Примечательно, что Вигерс в своей книге выделяет требования по производительности системы в отдельный вид требований, тем не менее входящих в понятие нефункциональных требований или атрибутов качества.

1.6 Системные требования и программные требования (System Requirements and Software Requirements) – данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов <созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”; таким образом, подразумевается, что система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности. Часто в литературе по управлению требованиями встречается описание системных требований как “пользовательских требований” (user requirements), SWEBOK ограничивает применение понятия “пользовательское требование” требованиями к системе конечных пользователей/заказчиков. Системные требования по SWEBOK, в свою очередь, окружают пользовательские требования (или требования других заинтересованных лиц – stakeholders, например, регулирование полномочий) без указания идентифицируемого источника-человека.

Процесс работы с требованиями. Модель процесса определения требований. Участники процессов. Управление и поддержка процессов. Качество и улучшение процессов.

Данная секция вводит процессы, касающиеся вопросов работы с требованиями, и в определенной степени “сшивает” в единое целое оставшиеся пять секций области знаний, посвященной требованиям к программному обеспечению.

Цель данной темы, в соответствии с SWEBOK, дать понимание того, что такое процесс работы с требованиями, как таковой. В русском языке также устойчиво используется его название как “процесс определения требований”. мы его будем использовать взаимозаменяемым образом, подразумевая весь процесс работы с требованиями по SWEBOK.

Что ж, рассмотрим структуру декомпозиции тем процесса работы с требованиями:

2.1 Модель процесса определения требований:

  • Не является дискретным; это постоянно действующий процесс на всех этапах жизненного цикла программного обеспечения. Процесс работы с требованиями инициируется в начале проекта и продолжается на протяжении всего жизненного цикла, в плоть до завершения проекта. Например, функциональные тесты создаются в соответствии с функциональными требованиями к программной системе и обычно выполняются, в том числе, при проведении приемочных испытаний. Как вы уже заметили, в переводе использовалась все же “работа с требованиями” для акцентирования внимания на том факте, что требования не только “определяются” на начальных этапах работ, но и модифицируются и используются во всем жизненном цикле.
  • Идентифицирует программные требования как элементы конфигурации (в терминах конфигурационного обеспечения) и контролирует их с использованием тех же практик конфигурационного управления, что и для других активов программных проектов (например, файлов или запросов на изменения).
  • Требует адаптации к проектному и/или организационному контексту, в рамках которого ведется соответствующий программный проект.

В частности, тема процесса определения требований касается тех вопросов, которые охватываются в рамках сбора, анализа, специфицирования и утверждения требований ч точки зрения организации этих видов деятельности для различных типов проектов и значимости тех или иных ограничений по отношению к процессу. В большинстве случаев, процесс определения, работы с требованиями выделен в самостоятельный набор и описан как последовательность (сценарии) действий, связанных с ними ролей и непосредственных результатов (их часто называют “артефактами”, например, в RUP – Rational Unified Process), в рамках конкретных методологий разработки программного обеспечения, наиболее популярные из которых мы рассмотрим позднее.


Дата добавления: 2018-05-12; просмотров: 1350; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!