Системная архитектура вместо требований
Download as PPTX, PDF3 likes1,121 views
Доклад Михаила Заборова на тему системной архитектуры в заказной разработке подчеркивает необходимость четкого взаимодействия между заказчиками и разработчиками, акцентируя внимание на сложности и неопределенности требований программного продукта. Он обсуждает важность архитектуры как средства управления требованиями и обеспечением гибкости системы, предлагая методы борьбы с проблемами, возникающими в процессе разработки. В итоге, доклад подчеркивает, что системная архитектура является основой для эффективного создания программного обеспечения.
Системная архитектура вместо требований
- 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