Классификация требований. Тема 6

1.

Тема 6.
Классификация требований
2/2/2023
ASCS, dr. ing. Pavel Chirev
1

2.

• Требование — это отдельная документально подтвержденная
физическая или функциональная потребность, которую должен
удовлетворить конкретный проект, продукт или процесс.
• Требования показывают, какие элементы и функции
необходимы для конкретного проекта.
• Требования разрабатываются до проектирования и внедрения
информационной системы.
• Набор требований используется в качестве исходных данных на
этапах проектирования и разработки информационного
продукта.
2/2/2023
ASCS, dr. ing. Pavel Chirev
2

3.

Категории требований к
информационным системам
2/2/2023
ASCS, dr. ing. Pavel Chirev
3

4.

• Категории требований к информационным системам
• Определение:
• При разработке информационных систем требование определяет
желаемое, которое оно должно выполнять в ответ на потребности
своих пользователей.
• требование представляет собой часть цели, для которой
разрабатывается ИТ-проект.
• Требования также определяют, как система должна реагировать на
взаимодействие с пользователем.
2/2/2023
ASCS, dr. ing. Pavel Chirev
4

5.

• Аспекты связанные с разработкой требований к
информационной системны:
Использование языка, характерного для домена
пользователя:
- требования всегда должны быть указаны на языке пользователя,
возможно, включая словарь анализируемой области;
Связь между требованиями и бизнес-целями:
- каждое требование должно быть четко увязано с целями деловых
людей.
2/2/2023
ASCS, dr. ing. Pavel Chirev
5

6.

Известные требования
Неизвестные требования
- предписывающие требования
- Описательные требования
Неописанные и/или неустановленные
требования
2/2/2023
ASCS, dr. ing. Pavel Chirev
6

7.

Categorii de cerințe
Cerințe cunoscute
Cerințe
necunoscute
Cerințe
prescriptive
2/2/2023
cerințe nedescrise
și/sau nedeclarate
Cerințe
descriptive
ASCS, dr. ing. Pavel Chirev
7

8.

• Известные требования
Cerințe cunoscute
• Они проявляется в том, что для эффективного
использования любой программы, написанной для ЭВМ,
нуждается в определенных:
- Требования к оборудованию и
- Требования к компонентам программных ресурсов,
которые должны присутствовать на компьютере.
Эти предварительные условия известны как системные
требования.
Большинство программ определяет два набора системных
требований: минимальные и рекомендуемые.
2/2/2023
ASCS, dr. ing. Pavel Chirev
8

9.

• С увеличением потребности в большей мощности и
вычислительных ресурсах в новых версиях программного
обеспечения требования к системе имеют тенденцию к
увеличению.
• Аналитики ИТ-индустрии предполагают, что эта тенденция играет
важную роль, особенно для улучшения существующих ИТ-систем.
• Второе значение термина «Системные требования» является
обобщением требования, которые должны быть выполнены
при проектировании системы или подсистемы.
2/2/2023
ASCS, dr. ing. Pavel Chirev
9

10.

• Аппаратные (hardware) требования
• Наиболее распространенным набором требований,
определяемых любой операционной системой или программным
приложением, являются физические ресурсы компьютера,
также известные как аппаратное обеспечение.
• Список требований к оборудованию часто сопровождается
списком совместимости оборудования, особенно с
операционными системами.
2/2/2023
ASCS, dr. ing. Pavel Chirev
10

11.

• Архитектура
• Вычислительная мощность
• Оперативная память (ОЗУ)
• Устройство хранения данных
• Адаптер дисплея
• Периферийное оборудование
2/2/2023
ASCS, dr. ing. Pavel Chirev
11

12.

• Требования к программному обеспечению
• Требования к программному обеспечению относятся к
определению требований к программным ресурсам и
предварительным требованиям, которые должны быть
установлены на компьютере для обеспечения
оптимальной работы приложения.
• Эти требования или предпосылки обычно не
включаются в пакет установки программного
обеспечения и должны быть установлены отдельно
перед установкой приложения.
2/2/2023
ASCS, dr. ing. Pavel Chirev
12

13.

Требования к программному обеспечению
могут включать:
• Операционная платформа
• API и драйверы
• веб-браузер
• Интернет-соединение (тип и скорость)
2/2/2023
ASCS, dr. ing. Pavel Chirev
13

14.

Cerințe
necunoscute
• Неизвестные требования
К этой категории требований можно отнести
требования, которые разрабатываются совместно с
заинтересованными сторонами.
• Они определяются:
требования домена,
бизнес-требования,
Требования заинтересованных сторон
Требования пользователя
2/2/2023
ASCS, dr. ing. Pavel Chirev
14

15.

cerințe nedescrise
și/sau nedeclarate
Неописанные и/или неустановленные требования
• Фунециональности системы, которые не описанные в
документации:
I. Неописанные требования
- это требования, которые не были озвучены пользователем или
бенефициаром при выявлений требований - упущенные
требования - предпологая, что они понятны, поэтому они не были
задокументированы
Эти упущенные требования могут повлиять на качество ИТпродукта.
2/2/2023
ASCS, dr. ing. Pavel Chirev
15

16.

• II. Недекларированные требования
• Эти Недекларированные требования могут вызвать проблемы
при эксплуатации системы
• Среди них могут быть требования:
- удаленно управлять системой,
- удаленно получать тестовые данные и устанавливать патчи которые позволяют разработчикам экономить время, силы и
деньги на стадии экспериментальной реализации системы.
Эти функции могут повлиять на безопасность информации и
информационной системы.
2/2/2023
ASCS, dr. ing. Pavel Chirev
16

17.

• Большинство клиентов знают об этой
«опасной» части процесса.
• Другое дело, если после завершения опытной
эксплуатации и ввода изделия в промышленную
эксплуатацию все эти функциональные
возможности закрыты.
• Почему не всегда так всегда происходит ?вопрос довольно риторический.
2/2/2023
ASCS, dr. ing. Pavel Chirev
17

18.

Cerinţe necunoscute ale sistemelor informatice
Cerințe
necunoscute
Cerințe
descriptive
2/2/2023
Cerințe
prescriptive
ASCS, dr. ing. Pavel Chirev
18

19.

• Процесс разработки требований направлен на
сбор, разработку, исправление и адаптацию
большого объема спецификаций, которые
различаются по назначению и выражению.
• Такая дифференциация может быть проведена
между требованиями:
Cerințe
necunoscute
a) предписывающие.
b) описательные;
Cerințe
descriptive
2/2/2023
ASCS, dr. ing. Pavel Chirev
Cerințe
prescriptive
19

20.

• предписывающие требования,
• которые обеспечивают проектные или
эксплуатационные решения, используются в случае,
если другие требования не могут быть определены с
достаточной ясностью для реализации в качестве
обязательной функциональности в информационных
системах.
• Проверка реализации, - будь то тестирование,
демонстрация, проверка или анализ.
2/2/2023
ASCS, dr. ing. Pavel Chirev
20

21.

• Предписывающие требования — представляют
собой свойства, которыми должна обладать
система независимо от того, как она будет
работать.
• Такие свойства обычно генерируются
(регулируются) законами или физическими
ограничениями (контекстом работы системы).
2/2/2023
ASCS, dr. ing. Pavel Chirev
21

22.

• Примеры предписывающих спецификаций:
- Одно и то же транспортное средство не может управляться
двумя водителями одновременно. - правила дорожного
движения
- Гостиничный номер, который находится на реконструкции, не
может быть занят. - физическое принуждение
- Разрешение на огнестрельное оружие может быть выдано, если
заявитель соответствует требованиям:
- Ему больше 18 лет,
- у него есть справка нарколога,
- у него есть справка от психолога,
- у него есть условия для хранения оружия....
2/2/2023
ASCS, dr. ing. Pavel Chirev
22

23.

• Описательные требования
-описывают свойства, которыми должна
обладать компьютерная система,
• и от того, соответствует ли она требованиям или
нет, зависит, как будет работать система.
2/2/2023
ASCS, dr. ing. Pavel Chirev
23

24.

• Примеры описательных спецификаций:
- Скорость передвижения сборочного конвеера
Tesla Motors не может превышать одного
метра в секунду.
- Купленный товар должен быть доставлен в
соответствии с графиком, указанным
покупателем.
- Деталь для сборки компьютера должна иметь
параметры, установленные...
2/2/2023
ASCS, dr. ing. Pavel Chirev
24

25.

• Различие между описательными и
предписывающими требованиями очень важно в
контексте разработки требований в том смысле,
что:
- Если для описательных требований, мы можем
вести переговоры, изменять или находить
альтернативы,
-то - для предписывающих требовани это
невозможно.
2/2/2023
ASCS, dr. ing. Pavel Chirev
25

26.

• В целом
• Требования к информационной системе описывают:
Что
но не
Как
будут выполняться Некоторые функции и процессы для
достижения бизнес-целей
Для этого:
• Создается комплексный документ, написанный на естественном
языке, который содержит описание того, что будет делать
система, но не описывает, как она это сделает.
2/2/2023
ASCS, dr. ing. Pavel Chirev
26

27.

Документирование требованиям к ИТ-продуктам
2/2/2023
ASCS, dr. ing. Pavel Chirev
27

28.

• Одной из проблем ИТ-индустрии является отсутствие
общепринятых определений терминов, которыми мы описываем
свою работу.
• Разные специалисты, говоря об одном и том же документе,
называют его по разному: и
- требования пользователяи
- требования к программному обеспечениюи
- функциональные требованияи
- системные требованияи
- технологические требованияи
- требования бизнеса и
- требования к продукту.
2/2/2023
ASCS, dr. ing. Pavel Chirev
28

29.

• Характеристики (некоторые особенности) интерпретации требований
• Стандарт глоссарий терминологии системной и программной
инженерии IEEE ISO/IEC/IEEE 24765-2017, Системная и программная
инженерия. Словарь
определяет требования как:
1. Условия или характеристики, необходимые для решения проблем
или достижения целей;
2. Условия или возможности, которыми должна обладать система
или компоненты системы для выполнения контракта или
соответствия стандартам, спецификациям или другим
формальным документам;
3. Документированное представление условий или возможностей
для пунктов (1) и (2).
Это определение охватывает требования обеих сторон:
- как для пользователей (внешнее поведение системы),а
- также для разработчиков (некоторые скрытые параметры).
2/2/2023
ASCS, dr. ing. Pavel Chirev
29

30.

• Мы будем рассматривать Требования как свойства, которыми
должен обладать продукт, чтобы представлять определенную
ценность для пользователей.
Приведенное ниже определение подтверждает различия между
типами требований (Sommerville and Sawyer, 1997):
• Требования...
• Это спецификация того, что должно быть достигнуто.
• Они описывают: поведение системы, свойства системы или ее
атрибуты. Они могут быть ограничены в процессе разработки
системы.
• Следует отметить, что универсального определения понятия
«требования» не существует.
2/2/2023
ASCS, dr. ing. Pavel Chirev
30

31.

• Уровни требований
Требования к программным продуктам состоят из двух блоков
Функциональные требования и
• Нефункциональные требования
На трех уровнях:
• бизнес-требования,
• требования пользователя и
• системные требования (функциональные и нефункциональные
требования).
• Ниже показана модель представления для этих типов требований.
Следует отметить, что, как и все модели, она не является полной, но
схематично показывает организацию требований.
- Овалы обозначают типы информации для требований и прямоугольники - способ хранения информации (документы, схемы,
базы данных).
2/2/2023
ASCS, dr. ing. Pavel Chirev
31

32.

2/2/2023
ASCS, dr. ing. Pavel Chirev
32

33.

• Cerințele de afacere (cerințele business)
Domeniul de interes
Cerințele domeniului
Afaceri
Cerințele de afafere
P1
Clienți (participanți)
P2
Cerințe clienti
P3
Cerițe față
de sistem
Determinarea extinderii sistemului și a cerințelor conform ISO/IEC 29148:2011
(Systems and software engineering — Life cycle processes — Requirements engineering)
2/2/2023
ASCS, dr. ing. Pavel Chirev
33

34.

• Требования пользователя (user requirements)
• Они описывают цели и задачи, которые система будет решать для
пользователей.
• Отличные способы подачи таких требований включают
варианты использования, сценарии и таблицы последствий
событий.
• В этом документе указано, что пользователи смогут
делать с помощью системы.
• Примеры использования
-"Оформление заказа" для бронирования билетов на самолет,
аренды автомобиля,
бронирования отеля....через интернет.
2/2/2023
ASCS, dr. ing. Pavel Chirev
34

35.

• Функциональные требования (functional requirements)
• Определеяют функциональные возможности
информационной системы, которые разработчики должны
создать, чтобы пользователи могли выполнять свои задачи в
рамках бизнес-требований.
• Иногда называемые поведенческими требованиями, они
содержат пункты с традиционными «должен» или «следует»:
• Пример - «Система должна отправить подтверждение заказа
пользователю по электронной почте».
Функциональные требования описывают то, что
разработчик должен реализовать.
2/2/2023
ASCS, dr. ing. Pavel Chirev
35

36.

• Термин системные требования (system requirements)
относится к высокоуровневым требованиям к продукту,
который содержит множество подсистем.
Говоря о системе, мы имеем в виду:
- программное обеспечение и подсистемы, программное и
аппаратное обеспечение, сотрудники (персонал) являются
частью системы, поэтому некоторые функции системы могут
распространяться на персонал.
2/2/2023
ASCS, dr. ing. Pavel Chirev
36

37.

• Бизнес-правила (business rules)
• включают корпоративные политики, правительственные
документы, отраслевые стандарты и алгоритмы процессов.
• Следует также отметить, что бизнес-правила не являются
требованиями к информационной системы, поскольку они выходят за
рамки любой программной системы.
• Однако они накладывают ограничения на то, кто может составлять
спецификации или диктовать, какие функции должна иметь система,
обеспечивать соблюдение соответствующих правил.
• Иногда бизнес-правила становятся источником атрибутов качества,
которые реализуются в функциональности.
• Таким образом, мы можем проследить происхождение конкретных
функциональных требований на соответствие им бизнес-правил.
2/2/2023
ASCS, dr. ing. Pavel Chirev
37

38.

• Функциональные требования
• Задокументированы в спецификации требований к
информационной системы (SRS), которая описывает,
насколько полно требуется ожидаемое поведение
системы.
• Спецификация требований к к информационной системы
используется при разработке, тестировании, обеспечении
качества продукта, управлении проектами и функциях,
связанных с проектом.
2/2/2023
ASCS, dr. ing. Pavel Chirev
38

39.

• Функциональные требования определяют функции ИТсистемы
или их компонентов через наборы входов, поведения и
выходов.
• В эту категорию мы можем поместить расчеты,
технические детали, информацию об обработке и
манипулировании данными, а также другие функции,
которые показывают, например, как должен быть
реализован вариант использования.
2/2/2023
ASCS, dr. ing. Pavel Chirev
39

40.

• Нефункциональные требованиякоторые описывают цели и
атрибуты качества.
Атрибуты качества (quality attributes) — это дополнительные
описания характеристик продукта, выраженные описанием его
характеристик, важных для пользователей или разработчиков.
Нефункциональные требования охватывают критерии, которые
можно использовать для анализа аспектов, связанных с
функциональностью системы, а не с ее поведением.
Они накладывают ограничения на функциональные требования
на уровне проектирования или реализации (например,
требования, связанные с производительностью, безопасностью
или надежностью системы).
2/2/2023
ASCS, dr. ing. Pavel Chirev
40

41.

Tipuri de cerinţe non-funcţionale
2/2/2023
ASCS, dr. ing. Pavel Chirev
41

42.

• Нефункциональные требования часто обозначаются термином
«качества системы».
• но их также можно назвать атрибутами качества, целями
качества, характеристиками качества или ограничениями.
• Эти характеристики включают простоту использования, простоту
перемещения, целостность, эффективность и отказоустойчивость.
• Другие нефункциональные требования описывают внешние
взаимодействия между системой и внешним миром, а также
ограничения проектирования и реализации.
2/2/2023
ASCS, dr. ing. Pavel Chirev
42

43.

• Типы нефункциональных требований
А. Требования к качеству- определить аспекты, связанные с тем,
«насколько хорошо» должна работать система.
К ним относятся спецификации, касающиеся:
- требований устойчивости, которые представляют собой
требования к качеству, предотвращающие возникновение аварий
или ухудшение состояния окружающей среды.
- Требования безопасности описывают меры защиты системы от
нежелательного поведения.
- Требования конфиденциальности гласят, что определенная
информация не может быть раскрыта неуполномоченным лицам.
- Требования целостности гласят, что определенная информация
может быть изменена, если это было сделано правильным и
санкционированным образом.
2/2/2023
ASCS, dr. ing. Pavel Chirev
43

44.

-Требования доступности относятся к тому факту, что определенные
требования или ресурсы могут быть использованы уполномоченными
лицами, когда это необходимо.
- Требования надежности ограничивают функционирование ИТсистемы ожидаемым и желаемым образом в течение длительных
периодов времени. За исключением исключительных обстоятельств,
система должна предоставлять услуги честным и надежным образом.
- Требования к производительности накладывают условия на то, как
работает система, например, максимальное время, необходимое для
выполнения операции.
- Требования к интерфейсу показывают, как система взаимодействует
с окружающей средой, пользователями, а также с другими системами.
2/2/2023
ASCS, dr. ing. Pavel Chirev
44

45.

• Нефункциональные требования
- B. Требования соответствия устанавливают необходимые условия
функционирования в соответствии с национальными законами,
международными правилами, социальными нормами, политическими
и культурными ограничениями, стандартами и т. д.
- C. Архитектурные требования налагают структурные ограничения
на ИТ-систему, чтобы она могла правильно функционировать в
среде, в которой она будет реализована. Предоставляет
разработчикам рекомендации о том, какой тип архитектуры подходит для
системы.
- D. Требования к разработке — это нефункциональные требования,
которые определяют способ разработки системы, а не то, как она
должна удовлетворять функциональным требованиям. Сюда
включены требования, касающиеся затрат на разработку, плана доставки
и установки, сведений об обслуживании, переносимости и т. д.
2/2/2023
ASCS, dr. ing. Pavel Chirev
45

46.

Требования Пользователей.
Как мы их выявляем?
2/2/2023
ASCS, dr. ing. Pavel Chirev
46

47.

Soluție de Sistem
Informațional
Determinare
restricții
client
2/2/2023
Analist
ASCS, dr. ing. Pavel Chirev
47

48.

• Как мы Аналиттики поступаем при выявлений
требований пользователей?
2/2/2023
ASCS, dr. ing. Pavel Chirev
48

49.

Во-первых, нам необходим план действий по выявлению
требований к проекту?
Следует отметить, что даже самый простой план
увеличивает шансы на успех в формализации требований и
позволяет услышать ожидания всех заинтересованных
сторон.
Четкое формулирование требований и планирование сроков
поставки програмного продукта может избавить нас от
необходимости повторно привлекать пользователя для
исправления ошибок или другой работы.
2/2/2023
ASCS, dr. ing. Pavel Chirev
49

50.

• Что необходимо отразить в этот план?
2/2/2023
ASCS, dr. ing. Pavel Chirev
50

51.

I. Цель идентификации требований, например:
- проверка требований рынка,
- исследование вариантов использования или
- разработка подробного списка функциональных
требований к системе;
2/2/2023
ASCS, dr. ing. Pavel Chirev
51

52.

II. Стратегии и методы определения требований,
например:
опросы, семинары, встречи с клиентами, интервью и
другие методики,
возможно использование разных подходов для
разных групп заинтересованных сторон;
2/2/2023
ASCS, dr. ing. Pavel Chirev
52

53.

• III. Результаты идентификации требований,
например:
- список вариантов использования программного
обеспечения,
- подробная спецификация требований к
программному обеспечению,
- анализ результатов опроса или спецификация
атрибутов качества и производительности;
2/2/2023
ASCS, dr. ing. Pavel Chirev
53

54.

IV. Планирование и оценка ресурсов
• определите какие разработчики и заказчики
будут задействованы в различных операциях
по выявлению требований;
приблизительно оценить усилия и время,
необходимые для выявления требований;
2/2/2023
ASCS, dr. ing. Pavel Chirev
54

55.

V. Возможные Риски при идентификации
требований :
- определите факторы, которые могут
помешать графику идентификации
требований,
- оцените опасность каждого фактора и
решите, как ее смягчить или контролировать
2/2/2023
ASCS, dr. ing. Pavel Chirev
55

56.

• Выявление требований – это:
- самый сложный процесс,
- Самое важное действие,
- Это то место, где совершаются ошибки и
- Требует интенсивного общения Аналитика с
Пользователем
Как вы уже знаете из Темы 2, это действие может быть
успешной только при тесном сотрудничестве разработчиков
и заказчиков.
Аналитик должен создать атмосферу,
способствующую изучению требуемого продукта.
2/2/2023
ASCS, dr. ing. Pavel Chirev
56

57.

Зависимость разрыва требований от частоты общения с
клиентом (пользователем...)
2/2/2023
ASCS, dr. ing. Pavel Chirev
57

58.

Предложенноя
Информационная
система
Клиент
2/2/2023
Аналитик
ASCS, dr. ing. Pavel Chirev
58

59.

• Бизнес-требования.
• Вся информация, описывающая:
- финансовые отношения,
- Рыночные отношения или
- Отношения между деловыми партнерами
- другие коммерческие отношения
которые заказчики или разработчики намереваются
достичь с помощью продукта, относятся к бизнес-
требованиям.
2/2/2023
ASCS, dr. ing. Pavel Chirev
59

60.

• Заявления пользователей об их целях или бизнес-целях
называются вариантами использования;
- Документированный вариант использования называется
сценарием.
- При определении бизнес-требований — применяйте варианты
использования или сценарии.
• Работайте с пользователями, чтобы сократить сценарии до
более общих вариантов использования.
- Сценарии использования можно определить путем
описания и моделирования функциональнлов и рабочих
процессов.
2/2/2023
ASCS, dr. ing. Pavel Chirev
60

61.

• Еще один способ выявления бизнес-требований —
спросить клиента, каковы его цели, когда он садится
перед терминалом.
• Сотрудник, который говорит: «Мне нужно сделать
то-то и то-то», скорее всего он, опишет конкретный
вариант использования, например:
I. «Мне нужно распечатать почтовую этикетку для
посылки»;
II. «Я должен управлять «очередью» проб, взятых на
анализ»;
III. «Мне нужно откалибровать контроллер давления».
2/2/2023
ASCS, dr. ing. Pavel Chirev
61

62.

• Бизнес правила.
Если клиент заявляет, что только определенные классы пользователей
могут выполнять определенные действия при определенных условиях,
то он, скорее всего, описывает бизнес-правила.
Пример:
-«Химик может заказать вещество из Перечня опасных химических веществ
1-го уровня только в том случае, если:
а) он допущен (имеет удостоверение) к работе с опасными
соединениями и
б) если он включен в список работников, выполняющих операции с
опасными химическими соединениями».
Проверка этих ограничений осуществляется путем моделирования
процесса отпуска химикатов.
2/2/2023
ASCS, dr. ing. Pavel Chirev
62

63.

• Необходимо отметить, что бизнес-правила и бизнестребования — это не одно и то же.
Вот несколько фраз, по которым можно сделать вывод, что
пользователь точно описывает правила торговли:
1 «Должно соответствовать «Регламенту…» или
«Корпоративной политике»;
2. «Должно соответствовать стандарту ISO......»;
3. «Если это условие выполняется, то происходит
процес....»;
4. «обработка данных ведется по алгоритму .....».
2/2/2023
ASCS, dr. ing. Pavel Chirev
63

64.

• Функциональные требования.
Функциональные требования описывают ожидаемое
поведение системы при определенных условиях и
действия, которые система позволит пользователям
выполнять.
• Функциональные требования вытекают:
из системных требований,
из требований пользователя,
из бизнес-правил и другие источники,
лежащие в основе спецификации требований к продукту ИТ
2/2/2023
ASCS, dr. ing. Pavel Chirev
64

65.

• Примеры функциональных требований:
1. «Если давление в линии превышает 20,0
атмосфер, должна бы загореться контрольная
лампочка»;
2. "Пользователь должен иметь возможность
сортировать список проектов в прямом и
обратном алфавитном порядке";
3. «Когда кто-то предлагает новую идею,
системагенерирует и отправляет электронное
письмо координатору идей».
2/2/2023
ASCS, dr. ing. Pavel Chirev
65

66.

• Эти утверждения демонстрируют, как пользователи обычно
представляют функциональные требования,
• но эти утверждения не могут быть записаны непосредственно в
спецификации требований к программному обеспечению.
• В первом случае замените «должен загореться» на «загорится»,
чтобы указать, что активация сигнальной лампы чрезвычайно
важна.
• Во втором примере показаны требования пользователя, а не
функциональные требования. Функциональное требование здесь предоставляет пользователю функцию сортировки.
2/2/2023
ASCS, dr. ing. Pavel Chirev
66

67.

• Показатели качества.
Утверждения о том, насколько хорошо система подходит для
определенного режима работы или позволяет пользователям
выполнять определенные действия, называются триггерами
качества.
Обратите особое внимание на слова, которые пользователи
используют для их описания!
Желаемые характеристики системы:
быстрая, легкая, интуитивно, понятная, простая в
использовании, отказоустойчивая, надежная и
эффективная. - Это расплывчатые термины
Вам нужно будет работать с пользователями, чтобы точно понять,
что означают эти расплывчатые и субъективные термины, и
получить четкие и поддающиеся проверке атрибуты качества.
2/2/2023
ASCS, dr. ing. Pavel Chirev
67

68.

• Варианты использования или сценарии.
• Основные заявления пользователей об их целях или
бизнес-задачах называются вариантами
использования;
Документированный вариант называется
сценарием.
• Работайте с пользователями, чтобы сократить
сценарии до более общих вариантов использования.
• Чтобы определить варианты использования,
попросите клиентов описать свой рабочий процесс.
2/2/2023
ASCS, dr. ing. Pavel Chirev
68

69.

• Требования к внешнему интерфейсу.
• Требования этого класса описывают, как
информационная система взаимодействует с
остальным миром.
• Спецификации требований к программному
обеспечению должны включать разделы,
посвященные взаимодействию с пользователями,
оборудованием и другими программными
системами.
2/2/2023
ASCS, dr. ing. Pavel Chirev
69

70.

Pauză

71.

Этап Анализа Требований
2/2/2023
ASCS, dr. ing. Pavel Chirev
71

72.

1.Введение
2.Методы анализа
3.Типы спецификаций
4.Документ спецификации
5.Валидация требований
6.Выводы
Постановка
задачи
Сбор
требований
Анализ
требований
2/2/2023
ASCS, dr. ing. Pavel Chirev
72

73.

1.Введение
2.Методы анализа
3.Типы спецификаций
4.Документ спецификации
5.Валидация требований
6.Выводы
2/2/2023
ASCS, dr. ing. Pavel Chirev
73

74.

• Анализ требований – Цели
• Целью анализа требований является создание правильной, полной,
непротиворечивой и однозначной модели системы (eng. Analysis
model)
• Основное внимание уделяется структурированию и формализации
требований, собранных на этапе выявления
Формализация требований позволяет выявить:
- Неоднозначности требований,
- несоответствия требований и
- неполнота описании требований,
Которые позже уточняются путем обсуждения с
заказчиками/пользователями и модификации спецификации системы.
Сбор и Анализ требований являются параллельными действиями, они
выполняются итеративно-пошагово
2/2/2023
ASCS, dr. ing. Pavel Chirev
74

75.

Procesul de analiza – vedere generală
Cerințele
doneniului
Cerințe
generale
Cerințețe
de afacere
Punerea
problemei
UTILIZATORI
Interveviera
utilizatorilor
Construirea
modelului
Modelul
sistemului
Experiența
proprie
Experiența din
Lunea reală
8/1/2022
7/22/2022
9/1/2022
10/1/2022
11/1/2022
12/1/2022
1/1/2023
1/20/2023

76.

• Этап анализа
• Анализ является первым шагом методологии техники
моделирования и направлен на построение точной, краткой и
конкретной модели реального мира.
• На рисунке показан обзор процесса анализа. Аналитик, тот, кто
проводит анализ проблемы, начинает с определения проблемы,
как она формулируется потенциальными пользователями.
• Аналитик построит модель, которая может быть неполной, на
основе неполных требований. Поэтому последующая модель
будет уточняться.
• Первым шагом в определении проблемы является определение
требований.

77.

• Будет установлено что должно делать система, а не как,
а именно будет определено:
- цель проблемы;
- Потребности пользователей;
- контекст функционирования системы;
- различные предположения;
- Необходимая производительность;
• В части проектирования и реализации будет следовать
следующее:
- Алгоритмы реализации;
- структуры данных;
- Архитектура системы;
- Возможная оптимизация

78.

• На этом этапе определяются системные требования, но не
описываются, как они будут выполняться.
• Здесь определятся проблема, которую хочет решить клиент.
• Результатом этого этапа является документ, содержащий
спецификацию требований четко определяющий, что должно быть
построено.
• Документ пытается представить требования с точки зрения клиента,
определяя цели и взаимодействия на высоком описательном уровне,
независимо от деталей реализации, таких как, например,
формулировка проблемы, ожидания клиента или критерии, которым
должен соответствовать продукт.
• Граница между высокоуровневыми и низкоуровневыми описаниями
проведена не очень четко.
2/2/2023
ASCS, dr. ing. Pavel Chirev
78

79.

ASCS, dr. ing. Pavel Chirev

80.

• Стадию анализа можно рассматривать как уточнение
деталей.
• Различие между высокоуровневыми и низкоуровневыми
деталями лучше подчеркивается подходами «сверху вниз»
(который имеет тенденцию к деталям низкого уровня) и
«снизу вверх» (который имеет тенденцию к деталям
высокого уровня).
• Документ с требованиями, называемый спецификацией
требований, может быть составлен формально, на основе
математической логики, или может быть выражен на
естественном языке.
2/2/2023
ASCS, dr. ing. Pavel Chirev
80

81.

• Логически первый шаг в создании программного продукта
состоит в том, чтобы точно установить, чего пользователь
хочет от системы.
• Доминирующей частью на этом этапе является общение между
бенефициаром (называемым пользователем) и инженероманалитиком — инженером, который отвечает за
установление требований пользователя, что фактически
представляет собой анализ системы.
• Все начинается с представления пользователя о новой системе.
Он сотрудничает с аналитиком, чтобы определить требования и
технические характеристики системы.
• Пользователь может иметь очень смутное представление о том,
чего он хочет, или, наоборот, знать очень точно.
2/2/2023
ASCS, dr. ing. Pavel Chirev
81

82.

• Теорема для разработки программного обеспечения
• В предыдущих параграфах мы говорили об ошибках,
возникающих в программных комплексах, особенно когда они
имеют большую сложность.
• Более того, их размер напрямую влияет на стоимость разработки
программного обеспечения.
• Предположим, у нас есть
- мера размера проблемы P, обозначенная M(P), и
- стоимость написания программы для проблемы P равна C(P).
2/2/2023
ASCS, dr. ing. Pavel Chirev
82

83.

• Если P и Q — две задачи, для которых M(P) > M(Q), то между
затратами существует связь C(P) > C(Q).
• Другими словами, стоимость разработки программ в первом
приближении является монотонно возрастающей функцией размера
программ.
• имея две отдельные и разные задачи, обозначенные P и Q, и мы
хотим создать объединенную программу.
Объединив две задачи, мы получим новую задачу P+Q,
размер которого M(P+Q) > M(P) + M(Q).
Между затратами будет соотношение: C(P+Q) > C(P) + C(Q)
Отсюда следует, что легче создать две маленькие программы,
чем одну большую, объединяющую функции обеих программ
2/2/2023
ASCS, dr. ing. Pavel Chirev
83

84.

• Это объясняется учетом сложности программ.
• По мере увеличения сложности, безусловно, будет появляться
больше ошибок, также порожденных взаимодействием между
программами.
• Указанное явление характерно для всех областей, в которых
решаются задачи.
• Во всех случаях небольшое увеличение сложности задачи
(начиная с простой задачи) показывает небольшое увеличение
количества ошибок.
• Однако рано или поздно количество ошибок начинает очень
быстро увеличиваться.

85.

• Именно эта связь между элементами задачи и возникновением
ошибок оправдывает неравенство C(P + Q) > C(P) + C(Q).
• Это означает, что в случае больших задач для преодоления
сложности с меньшими затратами приходится прибегать к
декомпозиции задачи на более мелкие и квазинезависимые
модули.
• Выполнение замены в приведенном выше соотношении дает:
C(P) > C(P') + C(P''), называемая фундаментальной теоремой
инженерного программирования,где P' и P'' — две независимые
подзадачи, решение которых решает проблему P с меньшими
затратами.
Если две проблемы на самом деле не независимы, то
интерференция между ними также должна быть решена.

86.

Relaţiile cost-dimensiune modul şi cost-număr module

87.

• Процесс анализа выполняется для:
- Определеня новых функций: не существуют установленных методов,
требования должны быть визуализированы, требует творчества
- Чтобы уточнить некоторые невысказанные требования:
- Информация существует в сознании людей
- Они не организованы
- Неформализованные, неорганизованные, неполные, противоречивые
спецификации
• Цель этапа
- Разработка формализованных, полных, последовательных спецификаций
- Разработка набора рекомендаций
- Следует отметить, что - Анализ не может быть автоматизирован

88.

• Значимость (Важность) спецификаций
-Спецификации – это формальные документы, которые
показывают, что заказчик хочет/получит
- Качество спецификаций жизненно важно для успеха
проекта
- Спецификации являются формой коммуникации
- Спецификации должены иметь достаточный объем
- Значимость спецификаций увеличивается с размером
проекта
- Предотвращает забывание информации

89.

• Спецификации делают информацию:
Более безопасный
— Когда опытные программисты уходят из проекта
— Предотвращаются различные предположения
Доступной
— Когда новые программисты входят в проект
Более точный
— Облегчает идентификацию проблемы

90.

• Изменение требований
Паралич Анализа
- Попытка определить все требования слишком рано
Срок жизни требований ограничен
- Меняется бизнес-среда
- Знания устаревают
- Психологические ограничения команды на количество
требований, которые могут быть рассмотрены в данный момент
времени
- Выполнение требований с первой итерации влияет на
детализацию требований в следующей итерации

91.

• Abstracția cerințelor
Требования должны быть поняты одинаково всеми участниками
ASCS, dr. ing. Pavel Chirev

92.

• Детализация требований:
Определяется аудиторией
Общий уровень
Для коммуникации, оценки стоимости, расстановки приоритетов
Подробный уровень
Для проектирования и реализации
Детализация для одной итерации
Формализм
Неформальная спецификация (экстремальное программирование)
Формальная спецификация (регламентированные согласования,
аудит, тендеры)

93.

1.Введение
2.Методы анализа
3.Типы спецификаций
4.Документ спецификации
5.Валидация требований
6.Выводы
2/2/2023
ASCS, dr. ing. Pavel Chirev
93

94.

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

95.

• Применение методологии SMART к определению требований
• Специфическими: требования должны быть связаны только с
проблемами, которые решает проект.
• ИзМеримы: Количественные требования предпочтительнее,
поскольку они более точны, могут быть агрегированы, их легче
проверить, а затем они позволяют провести статистический
анализ результатов.
• Акцесибельны: требования должны быть реализуемы по
разумной цене и соответствующими методами,
• Релевантны: требования должны быть полезными для команды
разработчиков. Детализация затрудняет понимание реальных
потребностей клиента
• Термины выполнения: требования должны иметь крайние сроки.

96.

Прототипирование
Одноразовый прототип (engl. “throw-away”)
Система частично созданна для лучшего понимания — от него
отказываются после понимания требований и создается новая
система, возможно, на другом языке
Эволюционный прототип (engl. “evolutionary”)
—Система будет дополнена другими функциями, чтобы стать
окончательной

97.

• Прототип
Обычно фокусируется на:
- Пользовательский интерфейс
- Новые функции
- Функции, которые могут быть нефезабельны
- Функции, о которых клиенты часто меняют свое мнение
Содержит только функции, ценные для клиента
Не фокусируется на качестве (исключения, восстановление данных и стандарты)
Прототипирование может быть:
- горизонтальное (например, пользовательский интерфейс) или
- вертикальное (часть системы полностью построена)
Стоимость заброшенного прототипа не может превышать более 10%
от общей стоимости проекта

98.

• Преимущества прототипирования
- Прототипирование - уменьшают общую стоимость
- Позволяет разработчикам устранить нечеткость
требований
- Дает клиентам возможность изменить требования
таким образом, что это не сильно повлияет на время
разработки.
- Облегчает обучение конечных пользователей до того,
как продукт будет готов.

99.

1.Введение
2.Методы анализа
3.Типы спецификаций
4.Документ спецификации
5.Валидация требований
6.Выводы
2/2/2023
ASCS, dr. ing. Pavel Chirev
99

100.

Типы спецификаций
ASCS, dr. ing. Pavel Chirev

101.

Типы спецификаций
Specificații pentru
subsisteme
Arhitecturi de
proectare
subsisteme
Specificatii
de proectare
SubSuis 1
Specificatii
de testsre
Specificatiile
arhitecturale
Specificatii
funcționale
Specificatii
de proectare
SubSuis 2
Specificatiile
necesare
Specificatiile
funcționale
Specificatiile
de proectare
UI
specificații
Specificatii
de testsre
Specificatii
funcționale
Specificatii
funcționale
Specificatii
de testare
Specificatii
de proectare
SubSuis 3
Specificatii
de testsre
Plan de testare
componente și
produs final
Plan de
testare

102.

Типы спецификаций
Arhitecturi de
proectare
subsisteme
Specificatii de
performanță
Specificații pentru
subsisteme
Specificatii
de proectare
SubSuis 1
Specificatii
de testsre
Specificatii
arhitecturale
Specificatii
funcționale
Specificatii
de proectare
SubSuis 2
Specificatiile
necesare
Specificatii
funcționale
Specificatii
de proectare
UI
specificații
Specificatii
de testsre
Specificatii
funcționale
Specificatii
funcționale
Specificatii
de testare
Specificatii
de proectare
SubSuis 3
Specificatii
de testsre
Plan de testare
componente și
produs final
Plan de
testare

103.

• Функциональные спецификации
Specificatiile
funcționale
Описывают наблюдаемое поведение:
-Для всего продукта
-Для каждой подсистемы и/или компонента (индивидуальные
спецификации)
Функциональные спецификации содержат:
- Внешние интерфейсы
- Структуры данных и внешние форматы
- Зависимости между компонентами
(Некоторые критические требования могут быть избыточно
дублированы параллельно, избыточно, с теми же
интерфейсами (например, НАСА)).

104.

• Un vehicul de explorare a planetei Venus a fost pierdut
• Deoarece programul primit de pe Pământ pentru rectificarea orbitei
conţinea instrucţiunea 'DO 3 I = 1.3’;
• instrucţiunea corectă în limbajul FORTRAN ar fi trebuit să
conţină virgulă în loc de punct;

105.

• Спецификации архитектуры
Физическая модель
Specificatiile
arhitecturale
— Распределенный клиент-сервер, настольное приложение
Компонентизация программного обеспечения
— «разработка vs. покупка»: какие компоненты будут разработаны,
какие можно купить
Параллелизм (конкурентность)
— потоки выполнения (декомпозиция системы и параллельное
выполнение разными командами)
Хранение данных
- СУБД и Структура базы данных

106.

• Спецификации пользовательского интерфейса
Как система представляется пользователю, как она выглядит и как
реагирует
Представление пользователю, может отличаться от реализации
- Распределенная система с унифицированным интерфейсом
- Ограниченный функционал для более дешевой версии
Содержат:
- Текстовые описания, изображения, диаграммы
- Скриншоты (если есть прототип)
UI
- Состояния, переходы
specificații
- Все экраны (окна)
- Время отклика
- Случаи ошибок

107.

• Пример спецификации пользовательского интерфейса:
- При запуске системы охранной сигнализации и срабатывании
датчика
- пользователь сможет ввести числовой код доступа для снятия
системы с охраны.

108.

109.

• Спецификации дизайна (проектирования)
Specificatiile
de proectare
• Внутренний дизайн – как будут реализованы функциональные
спецификации
- Внутренний API (интерфейс прикладной программы)
- Алгоритмы, взаимодействие потоков выполнения
- Языки программирования, инструменты разработки
- Отметим:
- Трудности Постоянной синхронизации с написанной программой
- Рекомендуется автоматическая генерация документации

110.

• Анализ vs Дизайн - от абстракции к деталям
почему был запущен проект (бизнес-цели)
Что сможет пользователь делать с этим продуктом
(функции, процессы, потоки)
Что будет проектироватьть разработчик
(функциональные требования, особенности продукта)
Компоненты системы и их взаимосвязь
(архитектура продукта, архитектура U.I)
индивидуальное поведение компонентов
(подробный дизайн модулей и/или подсистем, дизайн базы данных,
дизайн пользовательского интерфейса)
Реализация каждого компонента
(алгоритмы, пользовательский интерфейс)
ASCS, dr. ing. Pavel Chirev

111.

• Спецификации тестирования
Specificatii
de testare
- Содержит список: всех тестов, предпринятые шаги, ожидаемых
результатов
- Для высокоуровневых тестов используются скрипты
- Для тестов на уровне кода не рекомендуется использовать
модульное тестирование
- Сам тестовый код является документацией стратегии теста

112.

• Спецификации производительности
Specificatii de
performanță
• Они показывают, «насколько хороша» система в
объективных и измеримых терминах.
• Атрибуты производительности:
- Эти Спецификации предлагаются заинтересованными сторонами
- Могут быть указаны количественно (время, давление, скорость...)
- Могут быть Переменны.
- Могут быть сложными, состоять из нескольких элементарных атрибутов
- Могут быть расставлены по приоритетам: компромиссы (например,
время выполнения или объем памяти)
Типы атрибутов:
- Качество (то есть частота ошибок)
- Экономия ресурсов (сколько сохраняется по сравнению с предыдущими
версиями или другими системами)
- Емкость (сколько система может сделать: обработка, хранение)

113.

• Написание спецификаций:
предпологает
• Выбор формата документа («шаблон»)
• Фактическое написание спецификаций (самая
сложная часть)
• Рецензия документа
• Выпуск Версии и ввод в эксплуатации
• Регистр Запросв на изменение

114.

• Рекомендации по управлению спецификациями
Один автор у документа
- Сложный документ может разбиваться на несколько частей
Автор должен быть компетентным специалистом
- Знать проблему и уметь писать
У каждого документа должно быть ответственное
лицо
- ответственное лицо с определенного места времени
может быть другим от начального автора

115.

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

116.

• Рекомендации лингвистики
• Документы пишутся в настоящем времени, от третьего
лица.
• Применейте Соглашения о терминологии ((согласно RFC 2119
(OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features,))
Должно (must): абсолютное требование
Нельзя (must not): абсолютные запреты
Следует (should): необязательное требование
Не следует (should not): рекомендовано избегать
Возможно (may): совершенно необязательно
«Может» (can) : не рекомендуется

117.

• The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL,
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC 2119.
• 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
• 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
• 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a particular
item, but the full implications must be understood and carefully weighed
before choosing a different course.
• 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the particular
behavior is acceptable or even useful, but the full implications should be
understood and the case carefully weighed before implementing any
behavior described with this label.

118.

5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One
vendor may choose to include the item because a particular marketplace requires it or
because the vendor feels that it enhances the product while another vendor may omit the
same item. An implementation which does not include a particular option MUST be prepared
to interoperate with another implementation which does include the option, though perhaps
with reduced functionality. In the same vein an implementation which does include a
particular option MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the option provides.)
6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo
must be used with care and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has potential for causing
harm (e.g., limiting retransmisssions). For example, they must not be used to try to impose a
particular method on implementors where the method is not required for interoperability.
7. Security Considerations These terms are frequently used to specify behavior with
security implications. The effects on security of not implementing a MUST or SHOULD, or
doing something the specification says MUST NOT or SHOULD NOT be done may be very
subtle. Document authors should take the time to elaborate the security implications of not
following recommendations or requirements as most implementors will not have had the
benefit of the experience and discussion that produced the specification.

119.

• Процесс написания спецификаций
Написание спецификаций требует времени и
усилий
- Это инвестиция
Аналитический талант не означает и талант
написания
- Требуется писать только необходимые документы
- У кого нет терпения писать спецификации, у
того нет терпения и писать качественный
код!!!

120.

1.Введение
2.Методы анализа
3.Типы спецификаций
4.Документ спецификации
5.Валидация требований
6.Выводы
2/2/2023
ASCS, dr. ing. Pavel Chirev
120

121.

• Важность Документа спецификаций требований
(SRS)
• Документ спецификаций требований к программному обеспечению или
«Software Requirements Specification (SRS) | Software Engineering»
- Спецификации пытаются преодолеть коммуникационный барьер между
заказчиками, пользователями и разработчиками.
- Спецификации являются частью договора, в противном случае заказчик
может необоснованно отказаться от продукта
• SRS является эталоном для проверки конечного продукта, он помогает
клиентам проверить соответствие требованиям.
• Качественная SRS необходима для качественного программного продукта
(снижает стоимость разработки).
• Вероятность обнаружения ошибки анализа: 40 % при проектировании, 10 %
при реализации, 40 % при приеме, 10 % при эксплуатации
• Спецификации должны быть полными
• Моделирование должно быть достаточным,

122.

1.Введение
2.Методы анализа
3.Типы спецификаций
4.Документ спецификации
5.Валидация требований
6.Выводы
2/2/2023
ASCS, dr. ing. Pavel Chirev
122

123.

• Этапы процесса валидации
• Как правило, процесс валидации любого ИТпродукта выполняется на каждом этапе цикла
разработки продукта, от разработки
требований до использования и обслуживания.
• Таким образом, процесс проверки ИТ-продукта
соответствует 5 этапам цикла разработки.

124.

Разработка
и анализ SRS
Тестирование и
приемка
системы
Валидация функциональностей
моделирование
системы
Архитектурный
дизайн
Тестирование
системы
sistem
Валидация системы
Валидация архитектуры
T&V
модулей
Дизайн
модулей
Написание
кода
Интеграция и
тестирование
Валидация кода
Т&V-кодa
Цикл разработки информационной системы

125.

• Верификация и валидация
• Давайте четко найдем разницу между действиями
«Верификация» и «Валидация».• "Верификация" - это процесс оценки системы и программного
обеспечения в соответствии с заданным набором требований и
спецификаций, который осуществляется внутри разрабатываемой
системы разработчиками и тестировщиками.
• А «Валидация» — это процессы проверки обеспечения качества
— процессы, выполняемые внешними заказчиками,
владельцами, поставщиками в отношении доставленного им
продукта для проверки пригодности перед приемкой или
покупкой данного продукта.
• Действия по валидации в основном выполняются на
площадке заказчика.

126.

Процесс валилации
Процесс верификации
Prin urmare, la dezvoltatra
produselor IT, echipa Ops este
cea care desfășoară activitățile
de validare pentru Sistem și
software elaborat.
Смотри:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/

127.

• Верификация только тогда, когда вы еще не
потребляли продукт, но проверяете несколько
параметров, изучая продукт.
• Валидация — это когда фактически потребляете
продукт, чтобы увидеть, соответствуют ли
характеристики, полученные при проверке, тем, что вы
ожидаете.
• Верификация отвечает на вопрос «Правильно ли
мы строим систему?»
• Валидации отвечают на вопрос: «Правильно ли мы
построили систему?»

128.

Правильно ли я
создаю продукт?
Создаю ли я
правильный
продукт?

129.

• V&V на различных этапах жизненного цикла
разработки ИТ-продукта
• Верификация и валидация выполняются на каждом из этапов
жизненного цикла разработки ИТ-продукта.
• Давайте взглянем.

130.

#1) V & V tasks – Planning
Verification of contract.
Evaluation of Concept document.
Performing risk analysis.
#2) V & V tasks – Requirement phase
Evaluation of software requirements.
Evaluation/analysis of the interfaces.
Generation of the systems test plan.
Generation of Acceptance test plan.
#3) V&V tasks – Design Phase
Evaluation of software design.
Evaluation / Analysis of the Interfaces (UI).
Generation of Integration test plan.
Generation of the Component test plan.
Generation of test design.

131.

#4) V&V Tasks – Implementation Phase
Evaluation of source code.
Evaluation of documents.
Generation of test cases.
Generation of the test procedure.
Execution of Components test cases.
#5) V&V Tasks – Test Phase
Execution of systems test case.
Execution of the acceptance test case.
Updating traceability metrics.
Risk analysis
#6) V&V Tasks – Installation and checkout phase
Audit of installation and configuration.
The final test of the installation candidate build.
Generation of the final test report.

132.

#7) V&V Tasks – Operation Phase
Evaluation of new constraint.
Assessment of the change proposed.
#8) V&V Tasks – Maintenance Phase
Evaluation of the anomalies.
Assessment of migration.
Assessment of the retrial features.
Assessment of the proposed change.
Validating the production issues.

133.

• Действия по проверке информационной системы должны
демонстрировать, что «система готова к использованию
пользователями», и в основном проверять: успешность
установки системы, а затем функциональности и
работоспособность.
5. CQ Cod
Qualification
4. MQ Module
Oualification
3. AQ Architecture
Qualification
2. SQ
Sistem
Qualification
1. RQ Reqirimemt
Qualification
• 5 требований к качеству, провереаемые в процессе валидации продукта

134.

• Подход — 5Q, RQ-SQ-AQ-MQ-CQ отслеживается как часть
проверки и будет выполняться группой эксплуатации, которая в
конечном итоге отвечает за внедрение системы в производство.
Lansare
Qalificare
text

135.

• Шаблон, план и любые другие документы, представленные
для реализации проверки 5Q, будут представлены командой
разработчиков системы и будут включать подробный
подход, задачи/действия/тесты, которые будут
выполняться вместе с тестом как часть валидации
полученных результатов.
• Сводные отчеты будут доставлены группе эксплуатации во
время передачи системы вместе с исходным кодом и другими
результатами.
• В общем, целью выполнения проверки 5Q состоит в том,
чтобы гарантировать, что система может быть успешно
внедрена и что все функции могут использоваться без сбоев.

136.

• Обзор требований- Самая распространенная форма
валидации
Должны участвовать клиенты и пользователи, а также другие
спецы из команды или организации
Контрольный список вопросов:
- Включены ли все аппаратные ресурсы?
- Определено ли время отклика функций?
- Все ли внешние интерфейсы и интерфейсы данных определены?
- Все ли функции, желаемые заказчиком, указаны?
- Можно ли протестировать каждое требование?
- Определено ли начальное состояние системы?
- Определены ли реакции на исключительные условия?
- Указаны ли возможные последующие изменения?

137.

• Юзабилити-тестирование
- Пользователь думает вслух, а наблюдатель
слышит внутренний монолог
- Наблюдатель не мешает пользователю
исследовать и открывать функциональные
возможности ПО
- - Должна создаваться атмосфера для
тестирования ПО, а не пользователя

138.

• Показатели качества
Количество обнаруженных ошибок
- Можем статистически оценить распределение дефектов
- Слишком мало ошибок: очень хорошая SRS или рецензия
низкого качества
- Слишком много неясностей в SRS: требуется продолжение
анализ или создание прототипа
Частота запросов на изменение
- Мера стабильности последующих фаз
- Частота запросов должна уменьшаться со временем. Если
нет, то анализ был сделан неправильно.

139.

• Выводы
• На этапе анализа указывается, ЧТО мы хотим построить.
• Этап анализа Относится к предметной области.
• На этом этапе выполняются три основных действия:
- Анализ требований.
- Спецификация требований.
- Валидация требований
Документ «Спецификация требований к
программному обеспечению» (SRS) представляет
собой набор требований, согласованных между
заказчиком и командой разработчиков.

140.

Literatură:
• - CORNELIA NOVAC UDUDEC. INGINERIA SISTEMELOR DE PROGRAME. EDITURA ALMA MATER BACĂU, 2011
• Exact Difference Between Verification and Validation with Examples
https://www.softwaretestinghelp.com/what-is-verification-and-validation/
• Формализация требований на практике. В. В. Кулямин, Н. В. Пакулин, О. Л.
Петренко, А. А. Сортов, А. В. Хорошилов
{kuliamin,npak,olga,sortov,khoroshilov}@ispras.ru
• Элизабет Халл, Кен Джексон, Джереми Дик, Разработка и управление
требованиями. Практическое руководство пользователя
• METHOD FOR THE IDENTIFICATION OF REQUIREMENTS FOR
DESIGNING REFERENCE PROCESSES
M. Wilmsen 1, , K. Gericke 2, M. Jäckle 1 and A. Albers 1. DESIGN METHODS
1175 INTERNATIONAL DESIGN CONFERENCE – DESIGN 2020
https://doi.org/10.1017/dsd.2020.301
• An Effective Requirement Engineering Process Model for Software Development and
Requirements Management. Dhirendra Pandey . U. Suman, A. K. Ramani