Современный бизнес ставит перед разработчиками жесткие требования по необходимости сокращения жизненного цикла разработки,c которыми не может справится ни Agile, ни классическая модель разработки. В докладе рассмотрен методический подход позволяющий решить данную проблему на основе принципа системной инженерии “Система-Систем”

1. Методы сокращения ЖЦ цикла разработки на основе принципа Системы –Систем
1

2. Безуглый Дмитрий
Около 20-лет опыта участия в проектах по созданию, развитию, внедрению и эксплуатации различных систем.
Max масштаб проекта 50 инженеров, около 30 чел-лет. Разработка ПО
Max бюджет проекта 2,5 млндолл. (ЦОД)
Max ROIпроекта 400% (инвестиционный проект)
Ведущий эксперт ООО «Системный Подход» с 2008 года
@cornerless 2

3. Партнеры
@cornerless 3

4. Жизненный цикл разработки
Время от появления идеи до предоставления реальной возможности использования (capability)
@cornerless 4

5. 09.09.2013 Курс: Введение в ИТ технологии
Бизнес …
5

6. 09.09.2013 Курс: Введение в ИТ технологии
… Ожидает, и …
6

7. 09.09.2013 Курс: Введение в ИТ технологии
…. Департамент ИТ
7

8. http://www.modern-avionics.ru/
@cornerless 8

9. Теория систем ―это лекарство, которое превратилось в болезнь.
Кен Уилбер
Бизнес и системны анализ и теория
систем

10. Самое противное
@cornerless 10

11. 09.09.2013 Курс: Введение в ИТ технологии 11

12. В чем ключевая причина провалов в ИТ ?
@cornerless 12

13. Сложность
24.10.2014 Разработка требований к ПО
НЕОПРЕДЕЛЕННОСТЬ
НЕСОГЛАСОВАННОСТЬ
COMPLEX
(КОМПЛЕКСНЫЙ)
COMPLICATED
(УСЛОЖНЕННЫЙ)
СHAOTIC
(ХАОТИЧНЫЙ)
SIMPLE
(ПРОСТОЙ)

14. Усложненный и комплексный Complicated vs. Complex
•Тысячи частей, сотни шагов на сборку
•Кропотливая,тонкая работа, которую сложно завершить
•Все должно работать в определенной последовательности
•Конечная сборка должна отражать исходный план.
•Отклонение от плана = дефект
•Сложно предсказать детали поведения / результаты
•Результаты зависят от многих переменных
•Эти переменныесложно /невозможно предсказать надежно
•Следует ожидать изменений и отклонений, затем учитывать это при планировании
Разработка требований к ПО

15. Гибкие методологии уменьшают сложность самой системы ?
@cornerless 15

16. Проблема №1 Внутренняя архитектура
@cornerless 16

17. Понятно что лучше чем так …
@cornerless 17

18. Но и не так …
@cornerless 18

19. Проблема №2 Внешняя архитектура Представим организацию победившего Agile
@cornerless 19

20. Рефакторингвсех не спасет …
@cornerless 20

21. Среднестатистическая организация насчитывает порядка 500-700 систем, и около 20-40 команд разработки
@cornerless 21

22. Гибкие методологии не исключают, работы с требованиями, создания Архитектуры и документации, однако они и не определяют сколько либо пригодного процесса и его места в метологии
@cornerless

23. Гибкость
Команды (Организационная)
Системы в разработке
Контекста системы
@cornerless 23

24. Цепь изменений, мы по прежнему не знаем к чему на самом деле могут привести изменения

25. Ключевые проблемы «Теория систем»
•Подход на основе системы-подсистем подразумевает выявление предназначения совокупности подсистем и полное раскрытие неопределенности на этапе работы с требованиями
•Однако:
–На этом этапе информации недостаточно, поэтому требуются сложные технологии, и тем не менее полностью предсказать будущее не получается
–Ошибки на этапе работы с требованиями запускают рекурсивные процессы стабилизации требующие значительного времени
@cornerless 25

26. Ключевые проблемы «Гибкая разработка»
•Решая проблему «отклика» команды разработки для заказчика и локальной стабильности
–Маскирует проблемы связанные со сложностью системы или ее окружения,
–Что неизбежно влечет за собой отложенные и неконтролируемые последствия для систем класса Complicatedили Complex.
@cornerless 26

27. Конечная структура разрабатываемой системы в точности отражает структуру команды которая ее создает
Эмпирическое правило архитектуры
Филипп Кратчен
@cornerless 27

28. Иии… Подъехал Иван Царевич к камнюНаправо пойдёшь?
Нет
ДаГолову сложишьКоня потеряешь

29. Система-систем
@cornerless 29

30. Что изменилось ?
1. Контракт с надсистемой есть сумма контрактов взаимодействия с другими системами
@cornerless 30
2. Каждая система является «живым» развивающимся организмом, что требует координации на этапах планирования , реализации и эксплуатации

31. Принцип №1 Планирование низкой связанности

32. Часть работ управление интеграцией на всех уровнях создания
@cornerless 32
Работа
Планирование
Развитие
Работа
Планирование
Развитие
Работа
Планирование
Развитие

33. @cornerless 33

34. Ключевой принцип решения проблемы наладить взаимодействие на всех этапах
Создать структуру взаимодействующих команд
@cornerless 35

35. Принцип №2Независимость слоев. Замок нельзя построить на зыбкой почте
@cornerless 36

36. Шаблон В каждый момент времени комплексный слой может быть только один
@cornerless 37
COMPLEX
(КОМПЛЕКСНЫЙ)
COMPLICATED
(УСЛОЖНЕННЫЙ)
СHAOTIC
(ХАОТИЧНЫЙ)
SIMPLE
(ПРОСТОЙ)

37. Итоги
Было
•Система (complicated) технический объект, который сдается в эксплуатацию
•Детальные требования как контракт на разработку
•Проектирование архитектуры системы- подсистем
Будет (уже есть)
•Система (complex)социо- техническая система, которая живет
•Требования как поддерживающий механизм координированного развития
•Координированная эволюция
@cornerless 38

38. Что еще ждет ?
@cornerless 39

39. Спасибо за внимание !
Дмитрий Безуглый
+7 915 09 09 700
https://www.facebook.com/ dmitry.bezuglyy
@cornerlessbdl@system-approach.ru
ООО «Системный Подход»
https://www.facebook.com/ SystemApproachwww.system-approach.ru
@cornerless 40

40. Прочее …
•Упомянутые презентации
–http://www.slideshare.net/Cless/laf2014
–http://www.slideshare.net/Cless/rapid-foresight-for- product-strategy
•Авторское право:
–http://ru.123rf.com/profile_alexmit
–http://ru.123rf.com/profile_somchaij
–http://ru.123rf.com/profile_lightwise
–http://ru.123rf.com/profile_everythingpossible
–http://ru.123rf.com/profile_coramax
@cornerless 41