3. Важная особенность заказной разработки
Есть заказчик -
человек
или группа людей, с которыми
можно и нужно
договариваться,
что именно нужно
сделать
3 / 79
15. • Что именно делает система?
• Насколько она большая/маленькая (как следствие
адекватно дорогая/дешевая)?
• Насколько она решает нужные проблемы?
• Насколько она гибкая, и на какие изменения
рассчитана?
• Как ее встраивать в существующий ИТ-ландшафт?
• Какой объем функционала еще не реализован?
• Каково внутреннее устройство системы?
• и т. д. 15 / 79
17. • Как выяснить у заказчика — «чего же он хочет от системы»?
• Как зафиксировать функционал, который нужно в конце концов
«поставить»?
• Как защититься от постоянного раздувания scope-a?
• Как объяснить заказчику, на какие изменения рассчитана
система?
• Как объяснить заказчику, в каком состоянии разработка?
• Как объяснить разработчикам — что хочет заказчик?
• Как объяснить заказчику, что то, что реализовали
— это именно то, что он просил?
• и т.д.
17 / 79
28. 2009
ноябрь
Лозунги:
• Поддерживайте требования
актуальными
• Следите за качеством требований
• Тестируйте требования до начала В этом нет
ничего плохого
реализации
• Трассируйте требования до кода
28 / 79
29. У меня идея исключительной важности требований
всегда вызывала отторжение
Я делаю не так и все вокруг
делают не так.
Но все про это говорят.
29 / 79
32. Требования на разных этапах жизни системы
Сделайте мне
новый
Сделайте мне документ, Добавьте в
учет похожий на акт расчет
обязательств отгрузки коэффициент
усушки
Хочу систему Добавьте
учета всего мне
«Зеленую
кнопку»
В начале очень общие В конце более конкретные
В терминах бизнеса В терминах системы
32 / 79
33. Невозможно поместить контекст в требования
Иначе требования сами по
себе превращаются в
экстремально сложный
объект
33 / 79
35. Чтобы понять новое требование, нужно в
общем случае прочитать все предыдущие
Что было сделано Почему оно так сделано
35 / 79
36. Итеративный подход
А теперь еще
один
Добавьте во
«Специальная
все документы
накладная»
новый режим
А теперь
Сделайте мне тоже самое,
документ но для
«накладная» Гонконга
36 / 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
41. Терминологические различия
Под архитектурой ПО
часто понимают
техническое устройство
системы.
Слабо связанное с
бизнесом.
41 / 79
42. Архитектура ПО является
реализацией нефункциональных
требований к системе, в то время
как проектирование ПО является
реализацией функциональных
требований.
Архитектура ПО, которую также можно представить себе в виде разработки
стратегии — это деятельность, связанная с определением глобальных
ограничений, накладываемых на проектирование системы.
http://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения
42 / 79
44. Модель – упрощенное приближение
реальности
Максимально простое,
при условии достаточной
близости к действительности
44 / 79
45. Архитектура фиксирует то, что:
• важно (существенно)
• медленно меняется
• дает представление о
текущем состоянии
системы
• определяет будущие
ключевые решения
45 / 79
46. Архитектура программного
обеспечения — это структура
программы или вычислительной
системы, которая включает
программные компоненты, видимые
снаружи свойства этих
компонентов, а также отношения
между ними.
Там же:
http://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения
46 / 79
48. А как же Заказчик?
Остается
с
костылями требованиями
48 / 79
49. • Нет целостной картины в голове
• Плохо понимает, что для него
делают
• Подозревает, что его обманывают,
но доказать он этого не может
• По журналу требований почти
всегда можно ему объяснить, что
он сам во всем виноват
49 / 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
64. Системная архитектура
Придает
жесткость системе
(уменьшает аморфность) Позволяет
существенно
Уменьшает
облегчить ответы
сложность
на перечисленные в
начале вопросы
64 / 79
65. Почему это работает
• Правильные люди
• Наработанные методологии и
практики
• Критерии качественной
архитектуры
65 / 79
67. Без контекста задачи и предметной области не имеет смысла
Архитектура = модель ≠ диаграмма
Проще всего с ней работать через графические и
текстовые проекции
Архитектура субъективна (Во многом она находится в головах тех
людей, которые ее проектировали)
Устроена, как «матрешка» (Есть артефакты разного уровня)
Проектирование системной архитектуры искусство, а
не наука. 100 % рецептов не бывает
67 / 79
68. Примеры артефактов
системной архитектуры из нашей жизни
В основном для учетных задач, от крупных к мелким:
• Диаграмма взаимодействия крупных модулей – схемы
• Диаграмма плана счетов – своя нотация
• Диаграмма схемы сущностей – UML
• Понятийное описание алгоритма – Текст + схемы
• Схема переходов документа – Граф
• Сценарий использования интерфейсов – Текст + схемы
68 / 79
69. Слайды 69-78 и со схемами. Удалены, т.к.
содержат информацию заказчиков
69 / 79
70. Спасибо за внимание,
а сейчас обед
(перерыв) дискуссия!
Михаил Заборов
ReqLabs
Киев, 2011
70 / 79