Деятельность по анализу и разработке требований. Тема 2

1.

Тема 2. Деятельность по анализу и
разработке требований
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
1

2.

Tabelul prezintă defectele
introduse în diferite etape ale
ciclului de viață al dezvoltării
software-ului.
Случайная цитата
Чтобы правильно задать
вопрос, нужно знать
большую часть ответа.
(Шекли)
7/25/2022
Software Development
Phases
Percent of Defects
Introduced
Requirements
20 Perecent
Design
25 Percent
Coding
35 Percent
User Manuals
12 Percent
Bad Fixes
8 Percent
ASCA
ASCS dr. ing. conf. Pavel Chirev
2

3.

• Действия при анализе и разработке требований
Из того, что мы узнали из предыдущей теме, можно отметить:
• Что важно иметь надлежащий процесс анализа требований,
чтобы гарантировать, что потребности клиентов
правильно переведены в требуемые спецификации желаемой
информационной системы.
• Возможно, две или три итерации интерактивных сессий с
клиентом могут быть очень полезными для проверки
понимания разработчиком реальных требований
бенефициара к желаемой информационной системы.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
3

4.

• Анализ требований осуществляется посредством 4
действий:
1. Самопроверка — одно из самых эффективных действий по
обнаружению дефектов, которые могут быть обнаружены позже
группой тестирования или непосредственно заказчиком.
• Большинство организаций-разработчиков программного
обеспечения делают это частью своих «передовых практик
кодирования» и действительно повышают качество своих
продуктов.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
4

5.

• 2. Коллективная Экспертная оценка путем создания дерева
дефектов
• Использование анализа дерева отказов (FTA) — хороший
способ повысить эффективность тестирования программного
обеспечения (fault tree analysis, FTA).
• Это может помочь определить потенциальные причины
проблемы,
• предложить соответствующие корректирующие действия и
предоставить информацию о подготовке сценариев тестового
примера.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
5

6.

• Тестирование программного продукта для устранения скрытых
дефектов - неотъемлемaя часть жизненного цикла разработки
программного обеспечения (SDLC).
• Необходимо отметить, Тестировать программный продукт во
всех возможных сценариях для проверки на наличие дефектов не
только сложно, но и обычно невозможно.
• Требуемые огромные затраты и огромные усилия просто слишком
велики.
• Таким образом, более ограниченное тестирование остается
основной частью усилий по разработке программного
обеспечения, как и проблемы, стоящие перед тестированием
программного обеспечения.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
6

7.

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

8.

Условная схема построения дерева отказов

9.

Пример дерева отказов (FTA)
«Дерево отказов» для случая первичных отказов
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
9

10.

дерево отказов (FTA)
информационной системы
https://online.visual-paradigm.com/drive/#diagramlist:proj=0&documents
Использование анализа дерева
отказов (FTA) — хороший
способ повысить
эффективность тестирования
программного обеспечения.
Это может помочь определить
потенциальные причины
проблемы, предложить
соответствующие
корректирующие действия и
предоставить информацию о
подготовке сценариев
тестового примера.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
10

11.

Распределение по фазам усилий, затрачиваемых на разработку
программного продукта в течение жизненного цикла (SDLC)
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
11

12.

3. Регистрация дефектов и их документирование
• Эффективное отслеживание дефектов начинается с
систематического процесса.
• Процесс структурированного отслеживания начинается с
первоначальной регистрации дефектов, их исследования
и предоставления структуры для их устранения.
• Анализ дефектов и отчетность предоставляют мощные
средства управления дефектами и тенденциями их
исчерпания, а, следовательно, и затратами.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
12

13.

• При Регистрации дефектов необходимо документировать
определенную жизненно важную информацию о дефекте,
такую ​как:
- точное и полное описание дефекта , чтобы все в команде
разработчиков понимали, что это такое и как его воспроизвести.
- Этап, на котором обнаружен дефект, чтобы можно было
принять превентивные меры и избежать распространения
дефекта на следующий этап (создание программного
обеспечения).
- Дополнительное описание дефекта через скриншоты.
- Имена первооткрывателей дефектов - чтобы все знали, к кому
обратиться для лучшего понимания дефекта.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
13

14.

4. Анализ первопричины и определение профилактических
мер
• После того, как дефекты зарегистрированы и
задокументированы, следующим шагом является их
анализ.
• Как правило, назначенный координатор по
предотвращению дефектов или руководитель проекта
по разработке организует встречу для изучения
первопричин.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
14

15.

• Анализ первопричин дефекта основывается на трех ключевых
принципах:
- Сокращение дефектов для повышения качества: анализ должен
привести к внедрению изменений в процесс, которые помогают
предотвратить дефекты и обеспечить их раннее обнаружение.
- Применение местного опыта: специалисты, которые действительно
понимают, что пошло не так, - это люди, присутствующие при
обнаружении дефектов, - члены группы разработчиков программного
обеспечения. Они могут дать лучшие предложения, чтобы избежать
таких дефектов в будущем.
- Устранение систематических ошибок: может быть много ошибок или
дефектов, которые необходимо устранить на таком аналитическом
форуме; однако некоторые ошибки имеют тенденцию повторяться. Эти
систематические ошибки составляют большую часть дефектов,
обнаруживаемых в типичном программном проекте. Выявление и
предотвращение систематических ошибок может оказать большое
влияние на качество при относительно небольших инвестициях.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
15

16.

Каждая категория дефектов и причины, вызывающие эти
дефекты, могут быть представлены с помощью причинноследственной диаграммы, как показано на рисунке ниже.
Диаграмма причин и следствий, также известная как
диаграмма «рыбья кость» (Ișicava), представляет собой
простой графический метод для сортировки и
сопоставления факторов, влияющих на данную
ситуацию.Команда обычно разрабатывает диаграмму
причинно-следственных связей в ходе мозгового
штурма.Как только основные причины
задокументированы, поиск способов их устранения
требует еще одного раунда мозгового штурма.Цель
состоит в том, чтобы определить, какие изменения
следует внести в процессы, чтобы свести к минимуму
повторение дефектов.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
16

17.

7/25/2022
ASCS dr. ing. conf. Pavel Chirev
17

18.

• Вывод:
• «Человеку свойственно ошибаться»
Человек ошибается, но методы предотвращения дефектов
повышают способность разработчиков программного
обеспечения учиться на этих ошибках и, что более важно, учиться
на ошибках других.
Преимущества внедрения методологии предотвращения
дефектов: - Улучшен контрольный список качества продукции
- Трудоемкость обработки снижена
- Значительное снижение количества дефектов и их серьезности
- Улучшение взаимодействия между проектной командой и высшим
руководством.
- Оптимизация планирования ресурсов
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
18

19.

2. Требования с точки зрения заказчика
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
19

20.

• Диалог между:
• Главный менеджер ÎM FarmacoPrim SA и специалист отдела
развития информационных систем.
Флореа Андрей, главный менеджер ÎM FarmacoPrim SA,
встретился с
Августиной (выпускницей UTM), недавно принятая на работу в
отделе разработки информационных систем.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
20

21.

• Главный менеджер, - говорит,
- Мы должны создать новую "Систему химического контроля".
– Эта новая система должна обеспечивать контроль всех
химических контейнеров на складе и в лабораториях.
Может , благодаря этой новой «Системе химического контроля»
химики смогут контролировать наличие химикатов и
оптимизировать порядок заказа новых контейнеров
Система сэкономит компании много денег.
Кроме того, отдел надзора за охраной труда должен отчитываться
перед органами государственного контроля. "
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
21

22.

• Августина,
- "Я понимаю важность этого проекта, господин директор,
- «Но прежде чем мы наметим функционалы проекта, нам нужно
собрать некоторые системные требования».
- Главный менеджер (удивленно): «Как?
- Я только что перечислил требования для вас».
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
22

23.

• Августина, объясняет
• «На самом деле вы описали концепцию и некоторые бизнес-цели
проекта».
«Бизнес-требования такого высокого уровня не предоставляют
достаточно информации, чтобы точно определить, какую систему
построить и сколько времени это может занять.
Аналитику необходимо работать напрямую с пользователями и
понимать, чего они ждут от системы.
После обсуждения - мы определим - функциональные возможности,
которые обеспечивают выполнение как ваших бизнес-целей, так и
потребностей пользователей.
Вам может не понадобиться новая система, чтобы сэкономить
деньги, просто внесите некоторые изменения в вашу текущую
систему. "
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
23

24.

• - такой реакции специалиста по информационным системам он
еще не встречал.!!!
• Главный менеджер –
- "Химики люди занятые",
- «Они не будут иметь свободного времени для объяснения всех
деталей до того, как вы начнете писать программу.
- Может ваши аналисты – смогут определить сами
эти требования?"
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
24

25.

• Августина попыталась объяснить, зачем аналитику
необходимо разговаривать с пользователями будущей
системы.
«Если мы сами будем догадываться об ожиданиях
пользователей, ничего хорошего из этого не выйдет.
Мы разработчики ИТ-продуктов, а не химики.
Мы не можем точно знать, чего хотят специалисты по
химическому контролю от системы
Я знаю по опыту аналитиков требовании к
информционным системам, что если вы не дадите время на
изучение проблемы до того, как мы начнем проектировать,
результаты будут неудовлетворительными. "
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
25

26.

• Клиенты, которые заказывают новую
информационную систему, часто не понимают,
насколько важно проводить интервью с
будущими пользователями вживую.
• Одна из проблем при определение требований
заключается в том, что люди путают разные
уровни требований:
Требования домена
бизнес-требования,
требования пользователя и
функциональные требования.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
26

27.

• Кто является клиентом?
• В широком смысле «клиент — это лицо или
организация, которые прямо или косвенно
извлекают выгоду из данного продукта».
• Потребителями ИТ-продуктов можно считать
участников проекта, которые запрашивают,
оплачивают, выбирают, определяют, используют и
получают ИТ-продукт.
• Другие заинтересованные стороны — аналитики требований,
разработчики, инженеры-программисты, тестировщики,
менеджеры проектов, а также сотрудники юридической и
маркетинговой поддержки.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
27

28.

• Без надлежащего участия заказчика в
определении требований , неизбежным
результатом в конце проекта является
отклонения от ожидаемых требований от
информационной системы,
• Отклонения между тем, что действительно
нужно клиентам, и тем, что предлагают
разработчики, исходят из того, что они не
услышали в начале проекта.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
28

29.

Степень участия бенефициара и ИТ-специалиста на этапах
реализации системы на разных этапах проектирования
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
29

30.

Зависимость отклонения требовний от частоты
общения с клиентом (пользователем...)
разрыв ожиданий с
привлечением клиентов
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
30

31.

• Лучший способ свести к минимуму отклонения— организовать
частые контакты с соответствующими представителями
клиентов.
• Эти точки соприкосновения могут принимать форму интервью,
бесед, обзоров требований, дорожных карт дизайна
пользовательского интерфейса, оценок прототипов.
• и - при гибкой разработке - обратная связь с пользователями в
процессе постепенного роста готового программного
обеспечения.
• Каждая точка взаимодействия дает возможность уменьшить
разрыв в ожиданиях: того, что разрабатывает разработчик, все
лучше и лучше соответствует потребностям клиента.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
31

32.

• Конечно, разрыв сразу же начнет снова расти, так как развитие
продолжается после каждого контакта.
• Чем чаще точки соприкосновения, тем легче оставаться на
правильном пути. Как показывают сужающиеся серые треугольники
на предыдущем рисунке, ряд таких точек взаимодействия приведет
к уменьшению разрыва в ожиданиях в конце проекта и к решению,
намного более близкому к реальным потребностям клиентов.
• Вот почему одним из руководящих принципов Agile-разработки
является постоянное общение между разработчиками и
клиентами.
• Это отличный принцип при повышении качества любого
проекта.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
32

33.

• Качество любого проекта основано на выявлении требований
заказчика
• Для управления качеством проекта крайне важно понимать, что
такое качество и как оно связано с проектом.
• Качество это - совокупность свойств, признаков продукции,
товаров, услуг, работ, труда, обусловливающих их способность
удовлетворять потребности и запросы людей,
соответствовать своему назначению и предъявляемым
требованиям.
• Качество определяется мерой соответствия товаров, работ,
услуг условиям и требованиям стандартов, договоров, контрактов,
запросов потребителей.(экономический словарь)
(https://dic.academic.ru/dic.nsf/econ_dict/7330
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
33

34.

• Джозеф М. Джуран, широко известный как отец качества,
определил качество как: «Пригодность к использованию»,
которая позже была изменена на «соответствие
назначению».
• В контексте качества проекта важно удовлетворить
потребности клиента,
• Джозеф Мозес Джуран (Joseph Moses Juran) – американский
специалист в области качества, академик Международной
академии качества (МАК). Один из главных архитекторов
всемирной революции в области управления ради достижения
качества.
• «Самое главное, чтобы высшее руководство было
ориентировано на качество. В отсутствие искреннего
проявления интереса наверху мало что произойдет внизу»
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
34

35.

• Joseph Moses Juran (December 24, 1904 – February 28,
2008) was a Romanian-born American engineer and
management consultant
• Juran's quality management approach is based on three key
principles. ...
• These three elements are:
- quality planning (the design stage),
- quality control (ongoing inspections to ensure that processes
are in control) and
- quality improvement (including proactive refinement of
processes to improve processes).
7/25/2022
ASCA
ASCS dr. ing. conf. Pavel Chirev
35

36.

• Что для вас означает слово «качество»?
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
36

37.

• Институт управления проектами определяет качество как:
«Степень, в которой набор неотъемлемых характеристик
соответствует требованиям».
Важно просто выполнить требования, указанные в контракте по
проекту. «Почему, что и как», описывает простой набор
утверждений, связанных со спецификациями проекта:
- Если вы не выполняете требованя спецификаций, вы
нарушаете условия контракта.
- Если вы хотите завершить текущий контракт, пожалуйста,
соблюдайте условия контракта.
- Если вы хотите выиграть следующий контракт, оправдайте или
превзойдите ожидания клиента.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
37

38.

• THE QUALITY PLANNING SOLUTION
Quality planning provides the process, methods, tools, and techniques
for closing each of these component gaps and thereby ensuring that the
final quality gap is at a minimum.
• Quality planning steps
1)
2)
3)
4)
5)
6)
Establish the project
Identify the customers
Discover the customer needs
Develop the product
Develop the process
Develop the controls and,
transfer to operations
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
38

39.

Спираль качества Джурана
1. Исследование рынка;
2. Разработка проектного задания;
3. Проектно-конструкторские работы;
4. Составление технических условий;
5. Разработка технологии и подготовка производства;
6. Материально-техническое обеспечение;
7. Изготовление инструмента приспособлений и контрольноизмерительных средств;
8. Производство;
9. Контроль процесса производства;
10. Контроль готовой продукции;
11. Испытания рабочих характеристик продукции;
12. Сбыт;
13. Техническое обслуживание;
14. Исследования рынка.
Таким образом, по мнению Джозефа Джурана, указанные
процессы обеспечивают непрерывное формирование и
улучшение качества продукции.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
39

40.

• Менеджер клиентской компании — это клиент,
который оплачивает или спонсирует проект по
разработке программного обеспечения.
• Клиенты на управленческом уровне компании
определяют бизнес-требования к системе.
• Они формулируют концепцию продукта для
высокого уровня и бизнес-кейс для реализации
этого проекта.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
40

41.

• Бизнес-требования описывают бизнес-цели,
которых хочет достичь клиент или компания.
• Бизнес-требования составляют основу всего
проекта.
• Любые другие функции и требования к продукту
информатизации должны удовлетворять Бизнестребования.
• Необходимо отметить, что бизнес-требования не
предоставляют разработчикам достаточно информации
для создания продукта информатизации.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
41

42.

• На ранних стадиях проекта требования могут быть
расплывчатыми и неизмеримыми.
• По мере продвижения проекта требования должны
быть уточнены до измеримых спецификаций.
• Определение качества с точки зрения проекта
должно быть определено с самого начала и четко
определено с участием клиента, чтобы в конце
проекта результаты воспринимались клиентами как
высококачественные.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
42

43.

• Пользовательские требования: определяются
теми, кто прямо или косвенно взаимодействует с
продуктом, т. е. конечными пользователями.
А также
• Они способны описывать требуемые
функциональности, и ожидаемые качественные
характеристики продукта.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
43

44.

• Необхрдимо отметить, что клиенты выдвигающие бизнестребования иногда пытаются говорить от имени пользователей,
но обычно они слишком далеки от их реальной деятельности,
чтобы точно описать их требования.
• В случае разработки ИТ-систем или нестандартных приложений
бизнес-требования должны определяться платящим лицом, а
пользовательские требования должны определяться теми,
кто будет нажимать на клавиатуру и работать
непосредственно с продуктом.
• Рекомендация всем участникам проекта!
• Проверьте соответствие бизнес-требований требованиям
пользователей.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
44

45.

• К сожалению,
часто заказчики не хотят тратить время на работу с
аналитиком требований, который собирает, анализирует и
документирует требования.
Иногда клиенты думают! Аналитик либо разработчики сами
определят, что именно нужно пользователям и не хотят
вступать в долгие дискуссии. (как в примере фармацевтической
компании)
Следует отметить, что коммерческие и пользовательские
требования иногда противоречат друг другу. посколько
Бизнес-требования отражают организационную стратегию или
бюджетные ограничения, которые скрыты от пользователей.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
45

46.

• Пользователи,
разочарованные тем, что руководство насильно внедряет новую
информационную систему, не всегда хотят общаться с
разработчиками программного обеспечения, считая последних
пониманием неблагоприятного будущего.
Избежать этого помогает четкое и полное обсуждение целей и
ограничений проекта.
Реальность может никого не удовлетворять, но у людей будет
возможность понять ее и приспособиться к ней.
Для смягчения всех конфликтов аналитик должен взаимодействовать
с уполномоченными представителями пользователей и менеджеров.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
46

47.

• Сотрудничество между заказчиками и разработчиками
• Отличные программные продукты являются результатом хорошо
продуманной архитектуры, основанной на требованиях, которая
является результатом эффективного взаимодействия, то есть
тесного взаимодействия между разработчиками и заказчиками.
• Иногда сотрудничество между разработчиками и
заказчиками переходит во вражду.
• Напряжение также создается менеджерами, которые меняют
пользовательские требования по своему усмотрению.
• В этом случае никто не выигрывает.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
47

48.

• Сотрудничество возможно только тогда,
когда все участники процесса разработки знают, что им нужно для
достижения успеха, и когда они понимают и уважают стремление
своих коллег к успеху.
Когда во время работы над проектом нарастает напряжение,
очень возможно упустить из виду общую цель участников —
создать успешный программный продукт, ценный для бизнеса
и выполняющий стремления всех участников проекта.
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
48

49.

• Литература:
,
JURAN’S QUALITY HANDBOOK, Fifth Edition Joseph M. Juran Co-Editor-in-Chief
A. Blanton Godfrey Co-Editor-in-Chief
Анализ дерева отказов в среде программирования R. Александр В. Антонов, АО РАСУ, Москва, Россия. Евгений Ю. Галивец, АО РАСУ, Москва,
Россия. Валерий А. Чепурко, АО РАСУ, Москва, Россия. Алексей Н. Черняев, АО РАСУ, Москва, Россия Оригинальная статья. Надежность, том 18,
№1, 2018
.
Характеристики качества программного обеспечения и методы их
оценки. Лозинин А.И., Шубинский И.Б.
ВЗГЛЯДЫ ДЖ. ДЖУРАНА И А.ФЕЙГЕНБАУМА НА СОЗДАНИЕ СИСТЕМЫ МЕНЕДЖМЕНТА КАЧЕСТВА: ПРАКТИКА ПРИМЕНЕНИЯ. СИДОРЕНКО АЛЕКСЕЙ
НИКОЛАЕВИЧ, НИКОНОВА ЯНА ИГОРЕВНА
ФГБОУ ВО «Сибирский государственный университет путей сообщения». издания: 2017
• Спецификация требований к программному обеспечению (SRS): советы и шаблон
• Анализ дерева отказов (Fault tree analysis (FTA)). http://statistica.ru/knowledge-clusters/technicalsciences/analiz-dereva-otkazov/#%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F
7/25/2022
ASCS dr. ing. conf. Pavel Chirev
49

50.

Pauză
7/25/2022
ASCA
ASCS dr. ing. conf. Pavel Chirev
50