Системная архитектура вместо требований

1,316 views

Published on

Req labs 2011

Системная архитектура вместо требований

  1. 1. Системная архитектуравместо требованийДокладчик:Михаил ЗаборовReqLabs 2011 Киев
  2. 2. Занимаетсязаказной разработкой 2 / 79
  3. 3. Важная особенность заказной разработки Есть заказчик - человек или группа людей, с которыми можно и нужно договариваться, что именно нужно сделать 3 / 79
  4. 4. Проблематика 4 / 79
  5. 5. Программный продукт — сложный объект 5 / 79
  6. 6. Программный продукт — виртуальный объект 6 / 79
  7. 7. Программный продукт• Сложно увидеть (обозреть)• Невозможно пощупать• Нет четких границ• У всех разное понимание и видение 7 / 79
  8. 8. Артефакты,через которые можно увидетьпрограммное обеспечение 8 / 79
  9. 9. Программный код 9 / 79
  10. 10. Пользовательский интерфейс 10 / 79
  11. 11. Документация 11 / 79
  12. 12. Чаще всего она далека от идеала 12 / 79
  13. 13. Эти артефакты сами по себесложные объекты 13 / 79
  14. 14. 14 / 79
  15. 15. • Что именно делает система?• Насколько она большая/маленькая (как следствие адекватно дорогая/дешевая)?• Насколько она решает нужные проблемы?• Насколько она гибкая, и на какие изменения рассчитана?• Как ее встраивать в существующий ИТ-ландшафт?• Какой объем функционала еще не реализован?• Каково внутреннее устройство системы?• и т. д. 15 / 79
  16. 16. Вопросы разработчика 16 / 79
  17. 17. • Как выяснить у заказчика — «чего же он хочет от системы»?• Как зафиксировать функционал, который нужно в конце концов «поставить»?• Как защититься от постоянного раздувания scope-a?• Как объяснить заказчику, на какие изменения рассчитана система?• Как объяснить заказчику, в каком состоянии разработка?• Как объяснить разработчикам — что хочет заказчик?• Как объяснить заказчику, что то, что реализовали — это именно то, что он просил?• и т.д. 17 / 79
  18. 18. Нужен инструмент, который позволитдоговариваться Заказчику и Разработчику 18 / 79
  19. 19. Классическое лечение 19 / 79
  20. 20. 20 / 79
  21. 21. Business ITАртефакты в общем поле смысла ИТ и Бизнеса: 21 / 79требования, список задач + экранные формы
  22. 22. В современном подходетребования считаются экстремальноважным артефактом 22 / 79
  23. 23. Мой доклад Где встречаетсяслово требование 23 / 79
  24. 24. Я начал слушатьпро это на 24 / 79
  25. 25. 25 / 79
  26. 26. Андрей Терехов,СпбГУ, Ланит -Терком Если вы утратили требования на систему, то вам придется сделать их Reverse Engineering 26 / 79
  27. 27. С тех пор мало что поменялось 27 / 79
  28. 28. 2009ноябрь Лозунги: • Поддерживайте требования актуальными • Следите за качеством требований • Тестируйте требования до начала В этом нет ничего плохого реализации • Трассируйте требования до кода 28 / 79
  29. 29. У меня идея исключительной важности требованийвсегда вызывала отторжение Я делаю не так и все вокруг делают не так. Но все про это говорят. 29 / 79
  30. 30. Требования формулируютсяв определенном контексте 30 / 79
  31. 31. Контекст постоянно меняется• Состояние бизнеса• Состояние системы• Знания людей• Планы развития 31 / 79
  32. 32. Требования на разных этапах жизни системы Сделайте мне новый Сделайте мне документ, Добавьте в учет похожий на акт расчет обязательств отгрузки коэффициент усушки Хочу систему Добавьте учета всего мне «Зеленую кнопку» В начале очень общие В конце более конкретные В терминах бизнеса В терминах системы 32 / 79
  33. 33. Невозможно поместить контекст в требования Иначе требования сами по себе превращаются в экстремально сложный объект 33 / 79
  34. 34. Требованиязависят от предыдущих требованийЭто журнал изменений, а не текущее состояние 34 / 79
  35. 35. Чтобы понять новое требование, нужно вобщем случае прочитать все предыдущие Что было сделано Почему оно так сделано 35 / 79
  36. 36. Итеративный подход А теперь еще один Добавьте во «Специальная все документы накладная» новый режим А теперь Сделайте мне тоже самое, документ но для «накладная» Гонконга 36 / 79
  37. 37. Зачастую старые требованияне имеют смысла в новых условиях 37 / 79
  38. 38. Новые требования отменяют старые Сделайте мне расчет суммы документа по курсу валюты на дату перехода прав собственности С 01.01.2011 Все контракты рублевые 38 / 79
  39. 39. Приемы борьбы:Декомпозиция (Иерархия) и Кластеризация (Рубрикация/ Классификация / Разделение) по Бизнес-функциям / Онтологическимплоскостям / Частям системы. Тем самым локализуя сложность.Стандарты написания требований(SysML / AP233 / ISO 10303-233 / RIF / ReqIF / IntRIF / ISO 29148 / ITU Z.151 / ISO15926 / GORE) http://ailev.livejournal.com/900086.html — тут есть обзор Анатолий Левенчук 39 / 79
  40. 40. У разработчиков есть инструментборьбы — архитектура 40 / 79
  41. 41. Терминологические различия Под архитектурой ПО часто понимают техническое устройство системы. Слабо связанное с бизнесом. 41 / 79
  42. 42. Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований.Архитектура ПО, которую также можно представить себе в виде разработкистратегии — это деятельность, связанная с определением глобальныхограничений, накладываемых на проектирование системы. http://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения 42 / 79
  43. 43. Архитектура – модель предметнойобласти системы 43 / 79
  44. 44. Модель – упрощенное приближениереальности Максимально простое, при условии достаточной близости к действительности 44 / 79
  45. 45. Архитектура фиксирует то, что: • важно (существенно) • медленно меняется • дает представление о текущем состоянии системы • определяет будущие ключевые решения 45 / 79
  46. 46. Архитектура программногообеспечения — это структурапрограммы или вычислительнойсистемы, которая включаетпрограммные компоненты, видимыеснаружи свойства этихкомпонентов, а также отношениямежду ними.Там же:http://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения 46 / 79
  47. 47. ITBusiness Обычно место архитектуры тут 47 / 79
  48. 48. А как же Заказчик? Остается с костылями требованиями 48 / 79
  49. 49. • Нет целостной картины в голове• Плохо понимает, что для него делают• Подозревает, что его обманывают, но доказать он этого не может• По журналу требований почти всегда можно ему объяснить, что он сам во всем виноват 49 / 79
  50. 50. Как работаем мы 50 / 79
  51. 51. ITBusiness Существенная часть архитектуры у нас здесь 51 / 79
  52. 52. DDD во многом про это Эрик Эванс 52 / 79
  53. 53. Картина мираменяется 53 / 79
  54. 54. ТерминологияBusiness IT Системная архитектураБизнес Техническаяархитектура архитектура 54 / 79
  55. 55. Системная архитектура – модельсистемы в терминах бизнеса Сформулирована на общем языке Понимается и бизнесом, и ИТ 55 / 79
  56. 56. Контракт между бизнесом и ИТ • ИТ гарантирует, что это реализуемо • Бизнес гарантирует, что это то, что ему нужно • Изменения в архитектуре неизбежно влекут существенные изменения в ПО 56 / 79
  57. 57. Фиксирует существенные аспектыИгнорирует технические (и не только) детали Бизнес доверяет, что детали будут сделаны правильно Детали могут плыть очень сильно (тут помогает Agile) 57 / 79
  58. 58. Фиксирует вещи, которые редко меняются• Что бы ни произошло, назначение системы и базовые принципы ее устройства сохраняются• Фиксируем суть системы• Модель лаконичная и обозримая 58 / 79
  59. 59. Технически реализуема Формализована Должна состоять из небольшого количества базовых элементов и простых правил их использования Позволяет проводить "what if" анализ Позволяет понять, на какие изменения рассчитана система 59 / 79
  60. 60. Системная архитектура – ядро техническойархитектуры • Техническая архитектура Техническая детализирует (реализует) архитектура системную • Изменения в системной архитектуре неизбежно ведут к изменению технической Системная Архитектура • Системная архитектура адекватно отображает актуальное внутреннее устройство системы 60 / 79
  61. 61. Требования – короткоживущий артефакт • Скорее элемент управления потоком задач, чем проектирования • Остаются в архиве для разбора полетов и ретроспективы 61 / 79
  62. 62. 62 / 79
  63. 63. PROFIT!!! 63 / 79
  64. 64. Системная архитектура Придает жесткость системе (уменьшает аморфность) Позволяет существенно Уменьшает облегчить ответы сложность на перечисленные в начале вопросы 64 / 79
  65. 65. Почему это работает • Правильные люди • Наработанные методологии и практики • Критерии качественной архитектуры 65 / 79
  66. 66. Как бы посмотреть напримеры системнойархитектуры 66 / 79
  67. 67. Без контекста задачи и предметной области не имеет смыслаАрхитектура = модель ≠ диаграммаПроще всего с ней работать через графические итекстовые проекцииАрхитектура субъективна (Во многом она находится в головах техлюдей, которые ее проектировали)Устроена, как «матрешка» (Есть артефакты разного уровня)Проектирование системной архитектуры искусство, ане наука. 100 % рецептов не бывает 67 / 79
  68. 68. Примеры артефактов системной архитектуры из нашей жизниВ основном для учетных задач, от крупных к мелким:• Диаграмма взаимодействия крупных модулей – схемы• Диаграмма плана счетов – своя нотация• Диаграмма схемы сущностей – UML• Понятийное описание алгоритма – Текст + схемы• Схема переходов документа – Граф• Сценарий использования интерфейсов – Текст + схемы 68 / 79
  69. 69. Слайды 69-78 и со схемами. Удалены, т.к.содержат информацию заказчиков 69 / 79
  70. 70. Спасибо за внимание, а сейчас обед(перерыв) дискуссия! Михаил Заборов ReqLabs Киев, 2011 70 / 79

×