Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Трудности при разработкесложных распределѐнныхсистем на Java.Способы решения проблем.
Вводная часть  Цель выступления    1. Нет цели научить и рассказать как делать проекты.    2. Нет цели научить разрабатыва...
Часть 1. Проработкаархитектуры. Обеспечениедальнейшего развития.
Часть 1. Проработка архитектуры (1)Архитектура приложения определяет:   1. Функции, которые будет выполнять приложение в ц...
Часть 1. Проработка архитектуры (2)Основные составляющие архитектуры:   1. Authentication/Authorization (User, Password, R...
Часть 1. Проработка архитектуры (3)Разделение общего целого на блоки.                   First application   Second applica...
Часть 1. Проработка архитектуры (4)Влияние факторов на процесс разработки.Одно принятое решение = один фактор влиянияTechn...
Часть 1. Проработка архитектуры (5)Предвидение будущего. Масштабирование нагрузки.Первый этап оптимизацияОсновные шаги опт...
Часть 1. Проработка архитектуры (6)                                      9
Часть 2. Декомпозиция наотдельные независимыеподсистемы.
Часть 2. Декомпозиция (1)Декомпозиция1. Как часть аналитического метода2. Как часть работ по планированию3. Разделениеодно...
Часть 2. Декомпозиция (2)Разработка в два основных этапа:1. Разработка базовой функциональности2. Разработка отдельных под...
Часть 3. Процесс разработкираспределѐнной системы.
Часть 3. Процесс разработки (1).Разработка проекта несколькими независимыми группами разработчиков                        ...
Часть 3. Процесс разработки (2).Процесс отчѐтностиПоследствия неверно составленного отчѐта1. Трата времени на выяснение де...
Часть 4. Поддержка процессаразработки с помощьюAccuRev.
Часть 4. Процесс разработки. AccuRev (1)Дано:1.   Команда разработчиков, тестировщиков, аналитиков, архитекторов…. Более 1...
Часть 4. Процесс разработки. AccuRev (2)Терминология:        Stream                                           18
Часть 4. Процесс разработки. AccuRev (3)Picture source: http://www.accurev.com/scm-features.html                          ...
Часть 4. Процесс разработки. AccuRev (4)Терминология:        Snapshot                                           20
Часть 4. Процесс разработки. AccuRev (5)Терминология:        Promote                                           21
Часть 4. Процесс разработки. AccuRev (6)Picture source: http://www.accurev.com/scm-features.html                          ...
Часть 4. Процесс разработки. AccuRev (7)Picture source: http://www.accurev.com/scm-features.html                          ...
Часть 4. Процесс разработки. AccuRev (8)Picture source: http://www.accurev.com/scm-features.html                          ...
Часть 4. Процесс разработки. AccuRev (9)                                           25
Часть 5. Как работать сбольшим объѐмом требований.Contour.Управление требованиями в проекте спомощью Contour
Часть 5. Требования. Contour (1)Что такое изменение требований?- CR (Change Request)- New FeatureЦели- Добавить новый функ...
Часть 5. Требования. Contour (2)Инициаторы изменений  Представители заказчика разного уровня– аналитики, участники различн...
Часть 5. Требования. Contour (3)Формулировка требования с точки зрения архитектора системы.1. Все операции изменения реест...
Часть 5. Требования. Contour (4)               STOPЗаказчик снова меняет требования после начала работ.1. Производить запи...
Часть 5. Требования. Contour (5)Единый репозиторий требований Countour.1. Взаимные связи.2. Поддержка хранения версий доку...
Часть 5. Требования. Contour (6)Picture source: http://www.jamasoftware.com/contour/screenshots.php                       ...
Часть 5. Требования. Contour (7)Picture source: http://www.jamasoftware.com/contour/screenshots.php                       ...
Часть 5. Требования. Contour (8)Пример.FEATURE_000123 123 – номер featureFR-123-000001 – Функциональное требование        ...
Часть 5. Требования. Contour (9)Picture source: http://www.jamasoftware.com/contour/screenshots.php                       ...
Часть 6. Тестированиефинального продукта в облаке.
Часть 6. Тестирование. Облако (1)Часто встречающаяся проблемаБольшая система требует много аппаратных ресурсов для промежу...
Часть 6. Тестирование. Облако (2)Пример решение проблемы     QA инженеры                             Серверы      Группы р...
Часть 7. Поддержка идальнейшая модернизацияпроекта. Bug fixing and newfeatures.
Часть 7. Bug fixing and new features (1)Непрерывный bug fixingРабота двух команд из разных часовых поясов                 ...
Useful Links.           http://www.accurev.com           http://www.jamasoftware.com/contour           http://home.wlu.edu...
Questions Time.                  42
Contacts                              Thank You and                    We Look Forward to Working with YouAuriga, USA     ...
Upcoming SlideShare
Loading in …5
×

«трудности при разработке сложных распределённых систем на Java. способы решения проблем» (константин миронов, auriga)

1,269 views

Published on

  • Be the first to comment

  • Be the first to like this

«трудности при разработке сложных распределённых систем на Java. способы решения проблем» (константин миронов, auriga)

  1. 1. Трудности при разработкесложных распределѐнныхсистем на Java.Способы решения проблем.
  2. 2. Вводная часть Цель выступления 1. Нет цели научить и рассказать как делать проекты. 2. Нет цели научить разрабатывать проект «from scratch».Основная цель выступления - Познакомить аудиторию с реальным опытом разработки большого JAVA приложения.1. Познакомить с применяемыми принципами анализа требований2. Рассказать подходе к управлению требованиями3. Использование системы хранения версий.Познакомить с реальной жизнью в проектах. Рассказать о своѐм опыте. Термины. Определения 1. «Большая система». 2. Подсистема. 2
  3. 3. Часть 1. Проработкаархитектуры. Обеспечениедальнейшего развития.
  4. 4. Часть 1. Проработка архитектуры (1)Архитектура приложения определяет: 1. Функции, которые будет выполнять приложение в целом 2. Компоненты из которых будет состоять приложение 3. Функции которые будут выполнять компоненты 4. Как компоненты будут взаимодействовать между собойПравильный анализ – залог будущего вашего проекта 4
  5. 5. Часть 1. Проработка архитектуры (2)Основные составляющие архитектуры: 1. Authentication/Authorization (User, Password, Roles) 2. Управление конфигурацией приложения – глобальные и локальные переменные, настройки 3. Deployment strategy (including tools) 4. Функции которые будут выполнять компоненты 5. Как компоненты будут взаимодействовать между собой 6. Доступ к данным – DataBase, в файлах, внешние системы 7. Схема работы с исключительными ситуациями. 8. Принципы логирования 9. Взаимодействие с пользователем, определение общего подхода 10. Data validation 5
  6. 6. Часть 1. Проработка архитектуры (3)Разделение общего целого на блоки. First application Second applicationНе скатываться к - «Целое состоит из частей»1. Общий код переносится из однойчасти системы в другую2. Группировка сущностей в пакет3. Выделение общего функционала в отдельные пакетыПакет как отдельная подсистема-проект. 6
  7. 7. Часть 1. Проработка архитектуры (4)Влияние факторов на процесс разработки.Одно принятое решение = один фактор влиянияTechnical debt1. Business pressure2. Lack of process or understanding3. Lack of building loosely components4. Lack of design/project documentation5. Feature parallel development6. Delayed refactoring.7. Laziness of project staff. 7
  8. 8. Часть 1. Проработка архитектуры (5)Предвидение будущего. Масштабирование нагрузки.Первый этап оптимизацияОсновные шаги оптимизации1. Запросы к DB. Скорость получения результата.2. Необходимость изменения структуры DB3. Анализ алгоритмов обработки данных4. Оптимизация –, есть ли необходимость оптимизировать структуру DB, алгоритмы обработки данных (оптимальная работа алгоритмов)Масштабирование1. Вертикальное – увеличение ресурсов в рамках одного узла.2. Горизонтальное – добавление новых узлов.Закон АмдалаВ случае, когда задача разделяется на несколько частей,суммарное время еѐ выполнения на параллельной системе неможет быть меньше времени выполнения самого длинного фрагмента 8
  9. 9. Часть 1. Проработка архитектуры (6) 9
  10. 10. Часть 2. Декомпозиция наотдельные независимыеподсистемы.
  11. 11. Часть 2. Декомпозиция (1)Декомпозиция1. Как часть аналитического метода2. Как часть работ по планированию3. Разделениеодной большой задачина группу мелких задач 11
  12. 12. Часть 2. Декомпозиция (2)Разработка в два основных этапа:1. Разработка базовой функциональности2. Разработка отдельных подсистем, как самостоятельных проектов. 12
  13. 13. Часть 3. Процесс разработкираспределѐнной системы.
  14. 14. Часть 3. Процесс разработки (1).Разработка проекта несколькими независимыми группами разработчиков 14
  15. 15. Часть 3. Процесс разработки (2).Процесс отчѐтностиПоследствия неверно составленного отчѐта1. Трата времени на выяснение действительного статуса работ.2. Несвоевременное принятие решений по проекту. Потеря времени может оказать негативное влияние на проект в целом.Способы решения1. Формулировка в отчѐте по задаче должна отвечать на вопрос - Что сделал? Какой результат?2. Детальное описание результата.3. Единое время посылки отчѐтов для всех инженеров. 15
  16. 16. Часть 4. Поддержка процессаразработки с помощьюAccuRev.
  17. 17. Часть 4. Процесс разработки. AccuRev (1)Дано:1. Команда разработчиков, тестировщиков, аналитиков, архитекторов…. Более 100 человек.2. Исходный код, который содержит несколько миллионов строк.Почему AccuRev1. Необходимость обеспечить сложную разветвлѐнную структуру версий разрабатываемого продукта2. Регламентированные роли доступа – инженеры различных категорий, лидеры групп, QA инженеры, релиз инженеры.3. Обеспечение различных уровней доступа к коду для разных категорий специалистов.Особенности работы1. Нет привычных терминов tag, branch, trunk.2. Оригинальная терминология. Каждый новый сотрудник должен пройти небольшой вводный курс. 17
  18. 18. Часть 4. Процесс разработки. AccuRev (2)Терминология: Stream 18
  19. 19. Часть 4. Процесс разработки. AccuRev (3)Picture source: http://www.accurev.com/scm-features.html 19
  20. 20. Часть 4. Процесс разработки. AccuRev (4)Терминология: Snapshot 20
  21. 21. Часть 4. Процесс разработки. AccuRev (5)Терминология: Promote 21
  22. 22. Часть 4. Процесс разработки. AccuRev (6)Picture source: http://www.accurev.com/scm-features.html 22
  23. 23. Часть 4. Процесс разработки. AccuRev (7)Picture source: http://www.accurev.com/scm-features.html 23
  24. 24. Часть 4. Процесс разработки. AccuRev (8)Picture source: http://www.accurev.com/scm-features.html 24
  25. 25. Часть 4. Процесс разработки. AccuRev (9) 25
  26. 26. Часть 5. Как работать сбольшим объѐмом требований.Contour.Управление требованиями в проекте спомощью Contour
  27. 27. Часть 5. Требования. Contour (1)Что такое изменение требований?- CR (Change Request)- New FeatureЦели- Добавить новый функционал- Добавить новую возможность- Изменить существующий бизнес процесс.- Внести изменения в 27
  28. 28. Часть 5. Требования. Contour (2)Инициаторы изменений Представители заказчика разного уровня– аналитики, участники различных бизнес процессов. Бизнес аналитик со стороны исполнителя проекта Архитекторы Представители отдела R&D (Research and Development)Формулировка требования с точки зрения аналитика.Пример:Система должна логировать действия пользователя при изменениях в реестре товаров. 28
  29. 29. Часть 5. Требования. Contour (3)Формулировка требования с точки зрения архитектора системы.1. Все операции изменения реестра должны содержать атрибут «Исполнитель»2. Добавить журнал изменений. Просмотр журнала изменений.Формулировка задачи для разработчиков1. Задача 123 – разработать Журнал изменений2. Добавить атрибуты ID пользователя (Long userId;) и текст изменения (String changeMessage;)3. При внесении изменения в реестр создавать запись в журнале изменений.Формулировка задачи для тестировщиков. Тестовый сценарий.1. Войти в систему под тестовым пользователем, который имеет право на изменение в реестре товаров.2. Произвести изменение в реестре.3. Убедиться, что изменение отражено в журнале изменений.Работа началась…….. 29
  30. 30. Часть 5. Требования. Contour (4) STOPЗаказчик снова меняет требования после начала работ.1. Производить запись в журнал изменения, которые касаются только добавления новых позиций в реестр.Сложности и возможные ошибки:1. Внести изменения во все связанные документы. Высока вероятность того, что необходимые изменения будут внесены не во все связанные документы.2. Проинформировать всех заинтересованных лиц. Высока вероятность того, что не все будут проинформированы о произошедших изменениях.Как следствие – потеря времени на установление истины. 30
  31. 31. Часть 5. Требования. Contour (5)Единый репозиторий требований Countour.1. Взаимные связи.2. Поддержка хранения версий документов.3. Синхронизация.Преимущества использование Contour1. Все требования и изменения к ним публикуются в Contour.2. Уникальные идентификаторы для каждого документа. Поддержка связей между документами.3. Всем участникам проекта доступна одинаковые версии документов. Описание требований, тест планы.4. Просмотр истории изменений.5. Уведомление. Каждый разработчик и тестировщик, которые работают над разработкой конкретной feature получает уведомление о внесѐнных изменениях. 31
  32. 32. Часть 5. Требования. Contour (6)Picture source: http://www.jamasoftware.com/contour/screenshots.php 32
  33. 33. Часть 5. Требования. Contour (7)Picture source: http://www.jamasoftware.com/contour/screenshots.php 33
  34. 34. Часть 5. Требования. Contour (8)Пример.FEATURE_000123 123 – номер featureFR-123-000001 – Функциональное требование 34
  35. 35. Часть 5. Требования. Contour (9)Picture source: http://www.jamasoftware.com/contour/screenshots.php 35
  36. 36. Часть 6. Тестированиефинального продукта в облаке.
  37. 37. Часть 6. Тестирование. Облако (1)Часто встречающаяся проблемаБольшая система требует много аппаратных ресурсов для промежуточного и финального тестирования.Обеспечение каждого сотрудника проектанеобходимыми аппаратными средствамиможет привести к значительномуперерасходу бюджета проекта. 37
  38. 38. Часть 6. Тестирование. Облако (2)Пример решение проблемы QA инженеры Серверы Группы разработчиков 38
  39. 39. Часть 7. Поддержка идальнейшая модернизацияпроекта. Bug fixing and newfeatures.
  40. 40. Часть 7. Bug fixing and new features (1)Непрерывный bug fixingРабота двух команд из разных часовых поясов Нижний США Новгород Transfer meeting Email transfer 40
  41. 41. Useful Links. http://www.accurev.com http://www.jamasoftware.com/contour http://home.wlu.edu/~whaleyt/classes/parallel/topics/amdahl.html http://en.wikipedia.org/wiki/Amdahls_law http://cc2e.com/ 41
  42. 42. Questions Time. 42
  43. 43. Contacts Thank You and We Look Forward to Working with YouAuriga, USA Auriga, Russia92 Potter Rd, Ste 1 125 Varshavskoe Shosse, Unit 16AWilton, NH 03086, USA Moscow, 117587Phone: +1 (866) 645-1119 Tel:+7 (495) 713-9900Fax: +1 (603) 386-6097 Fax:+7 (495) 939-0300info@auriga.com info@auriga.comwww.auriga.com www.auriga.com 43

×