Req labs 2011

1. Системная архитектура
вместо требований
Докладчик:
Михаил Заборов
ReqLabs 2011 Киев

2. Занимается
заказной разработкой
2 / 79

3. Важная особенность заказной разработки
Есть заказчик -
человек
или группа людей, с которыми
можно и нужно
договариваться,
что именно нужно
сделать
3 / 79

4. Проблематика
4 / 79

5. Программный продукт — сложный объект
5 / 79

6. Программный продукт — виртуальный объект
6 / 79

7. Программный продукт
• Сложно увидеть (обозреть)
• Невозможно пощупать
• Нет четких границ
• У всех разное понимание и видение
7 / 79

8. Артефакты,
через которые можно увидеть
программное обеспечение
8 / 79

9. Программный код
9 / 79

10. Пользовательский интерфейс
10 / 79

11. Документация
11 / 79

12. Чаще всего она далека от идеала
12 / 79

13. Эти артефакты сами по себе
сложные объекты
13 / 79

14. 14 / 79

15. • Что именно делает система?
• Насколько она большая/маленькая (как следствие
адекватно дорогая/дешевая)?
• Насколько она решает нужные проблемы?
• Насколько она гибкая, и на какие изменения
рассчитана?
• Как ее встраивать в существующий ИТ-ландшафт?
• Какой объем функционала еще не реализован?
• Каково внутреннее устройство системы?
• и т. д. 15 / 79

16. Вопросы разработчика
16 / 79

17. • Как выяснить у заказчика — «чего же он хочет от системы»?
• Как зафиксировать функционал, который нужно в конце концов
«поставить»?
• Как защититься от постоянного раздувания scope-a?
• Как объяснить заказчику, на какие изменения рассчитана
система?
• Как объяснить заказчику, в каком состоянии разработка?
• Как объяснить разработчикам — что хочет заказчик?
• Как объяснить заказчику, что то, что реализовали
— это именно то, что он просил?
• и т.д.
17 / 79

18. Нужен инструмент, который позволит
договариваться Заказчику и Разработчику
18 / 79

19. Классическое лечение
19 / 79

20. 20 / 79

21. Business IT
Артефакты в общем поле смысла ИТ и Бизнеса:
21 / 79
требования, список задач + экранные формы

22. В современном подходе
требования считаются экстремально
важным артефактом
22 / 79

23. Мой доклад

Где встречается
слово требование
23 / 79

24. Я начал слушать
про это на
24 / 79

25. 25 / 79

26. Андрей Терехов,
СпбГУ, Ланит -Терком
Если вы утратили
требования на систему, то
вам придется сделать их
Reverse Engineering
26 / 79

27. С тех пор мало что поменялось
27 / 79

28. 2009
ноябрь
Лозунги:
• Поддерживайте требования
актуальными
• Следите за качеством требований
• Тестируйте требования до начала В этом нет
ничего плохого
реализации
• Трассируйте требования до кода
28 / 79

29. У меня идея исключительной важности требований
всегда вызывала отторжение
Я делаю не так и все вокруг
делают не так.
Но все про это говорят.
29 / 79

30. Требования формулируются
в определенном контексте
30 / 79

31. Контекст постоянно меняется
• Состояние бизнеса
• Состояние системы
• Знания людей
• Планы развития
31 / 79

32. Требования на разных этапах жизни системы
Сделайте мне
новый
Сделайте мне документ, Добавьте в
учет похожий на акт расчет
обязательств отгрузки коэффициент
усушки
Хочу систему Добавьте
учета всего мне
«Зеленую
кнопку»
В начале очень общие В конце более конкретные
В терминах бизнеса В терминах системы
32 / 79

33. Невозможно поместить контекст в требования
Иначе требования сами по
себе превращаются в
экстремально сложный
объект
33 / 79

34. Требования
зависят от предыдущих требований
Это журнал изменений, а не текущее состояние
34 / 79

35. Чтобы понять новое требование, нужно в
общем случае прочитать все предыдущие
Что было сделано Почему оно так сделано
35 / 79

36. Итеративный подход
А теперь еще
один
Добавьте во
«Специальная
все документы
накладная»
новый режим
А теперь
Сделайте мне тоже самое,
документ но для
«накладная» Гонконга
36 / 79

37. Зачастую старые требования
не имеют смысла в новых условиях
37 / 79

38. Новые требования отменяют старые
Сделайте мне расчет
суммы документа по
курсу валюты на дату
перехода прав
собственности
С 01.01.2011
Все контракты
рублевые
38 / 79

39. Приемы борьбы:
Декомпозиция (Иерархия) и Кластеризация (Рубрикация
/ Классификация / Разделение) по Бизнес-функциям / Онтологическим
плоскостям / Частям системы. Тем самым локализуя сложность.
Стандарты написания требований
(SysML / AP233 / ISO 10303-233 / RIF / ReqIF / IntRIF / ISO 29148 / ITU Z.151 / ISO
15926 / GORE)
http://ailev.livejournal.com/900086.html — тут есть обзор
Анатолий Левенчук 39 / 79

40. У разработчиков есть инструмент
борьбы — архитектура
40 / 79

41. Терминологические различия
Под архитектурой ПО
часто понимают
техническое устройство
системы.
Слабо связанное с
бизнесом.
41 / 79

42. Архитектура ПО является
реализацией нефункциональных
требований к системе, в то время
как проектирование ПО является
реализацией функциональных
требований.
Архитектура ПО, которую также можно представить себе в виде разработки
стратегии — это деятельность, связанная с определением глобальных
ограничений, накладываемых на проектирование системы.
http://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения
42 / 79

43. Архитектура – модель предметной
области системы
43 / 79

44. Модель – упрощенное приближение
реальности
Максимально простое,
при условии достаточной
близости к действительности
44 / 79

45. Архитектура фиксирует то, что:
• важно (существенно)
• медленно меняется
• дает представление о
текущем состоянии
системы
• определяет будущие
ключевые решения
45 / 79

46. Архитектура программного
обеспечения — это структура
программы или вычислительной
системы, которая включает
программные компоненты, видимые
снаружи свойства этих
компонентов, а также отношения
между ними.
Там же:
http://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения
46 / 79

47. IT
Business
Обычно место архитектуры тут 47 / 79

48. А как же Заказчик?
Остается
с
костылями требованиями
48 / 79

49. • Нет целостной картины в голове
• Плохо понимает, что для него
делают
• Подозревает, что его обманывают,
но доказать он этого не может
• По журналу требований почти
всегда можно ему объяснить, что
он сам во всем виноват
49 / 79

50. Как работаем мы
50 / 79

51. IT
Business
Существенная часть архитектуры у нас здесь 51 / 79

52. DDD во многом про это
Эрик Эванс
52 / 79

53. Картина мира
меняется
53 / 79

54. Терминология
Business
IT
Системная
архитектура
Бизнес Техническая
архитектура архитектура 54 / 79

55. Системная архитектура – модель
системы в терминах бизнеса
Сформулирована на
общем языке
Понимается и бизнесом, и ИТ
55 / 79

56. Контракт между бизнесом и ИТ
• ИТ гарантирует, что это реализуемо
• Бизнес гарантирует, что это то, что
ему нужно
• Изменения в архитектуре
неизбежно влекут существенные
изменения в ПО
56 / 79

57. Фиксирует существенные аспекты
Игнорирует технические (и не только) детали
Бизнес доверяет, что детали
будут сделаны правильно
Детали могут плыть
очень сильно
(тут помогает Agile)
57 / 79

58. Фиксирует вещи, которые редко меняются
• Что бы ни произошло, назначение
системы и базовые принципы ее
устройства сохраняются
• Фиксируем суть системы
• Модель лаконичная и
обозримая
58 / 79

59. Технически реализуема
Формализована
Должна состоять из
небольшого количества
базовых элементов и
простых правил их
использования
Позволяет проводить
"what if" анализ
Позволяет понять,
на какие изменения
рассчитана система 59 / 79

60. Системная архитектура – ядро технической
архитектуры
• Техническая архитектура
Техническая детализирует (реализует)
архитектура системную
• Изменения в системной
архитектуре неизбежно ведут
к изменению технической
Системная
Архитектура
• Системная архитектура
адекватно отображает
актуальное внутреннее
устройство системы
60 / 79

61. Требования – короткоживущий артефакт
• Скорее элемент управления
потоком задач, чем
проектирования
• Остаются в архиве для разбора
полетов и ретроспективы
61 / 79

62. 62 / 79

63. PROFIT!!!
63 / 79

64. Системная архитектура
Придает
жесткость системе
(уменьшает аморфность) Позволяет
существенно
Уменьшает
облегчить ответы
сложность
на перечисленные в
начале вопросы
64 / 79

65. Почему это работает
• Правильные люди
• Наработанные методологии и
практики
• Критерии качественной
архитектуры
65 / 79

66. Как бы посмотреть на
примеры системной
архитектуры
66 / 79

67. Без контекста задачи и предметной области не имеет смысла
Архитектура = модель ≠ диаграмма
Проще всего с ней работать через графические и
текстовые проекции
Архитектура субъективна (Во многом она находится в головах тех
людей, которые ее проектировали)
Устроена, как «матрешка» (Есть артефакты разного уровня)
Проектирование системной архитектуры искусство, а
не наука. 100 % рецептов не бывает
67 / 79

68. Примеры артефактов
системной архитектуры из нашей жизни
В основном для учетных задач, от крупных к мелким:
• Диаграмма взаимодействия крупных модулей – схемы
• Диаграмма плана счетов – своя нотация
• Диаграмма схемы сущностей – UML
• Понятийное описание алгоритма – Текст + схемы
• Схема переходов документа – Граф
• Сценарий использования интерфейсов – Текст + схемы
68 / 79

69. Слайды 69-78 и со схемами. Удалены, т.к.
содержат информацию заказчиков
69 / 79

70. Спасибо за внимание,
а сейчас обед
(перерыв) дискуссия!
Михаил Заборов
ReqLabs
Киев, 2011
70 / 79