www.cmcons.com. Практика и технология внедрения процесса конфигурационного управления и управления изменениями с применением IBM Rational ClearCase и ClearQuest
www.cmcons.com. Практика и технология внедрения процесса конфигурационного управления и управления изменениями с применением IBM Rational ClearCase и ClearQuest
Ромуальд Здебский, Обеспечение качества через интегрированное управление прое...SQADays_2009_Piter
Ромуальд Здебский, Microsoft, Санкт-Петербург, Россия
Обеспечение качества через интегрированное управление проектами разработки ПО - настоящее и будущее
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
Современные подходы в инжиниринге сложных технических систем
Конференция ЦСР «С-З» для ГК «Росатом»
Кузнецов Л.В., Советник генерального директора
Крыловский государственный научный центр
Доклад был представлен на стратегической сессии кластера радиационных технологий Санкт-Петербурга и Ленинградской области
работа содержит описание метода Agile Scrum в проектах внедрения корпоративных информационных систем на базе SAP. Рассматриваются вопросы применения Scrum в проектах развития, тиражирования и внедрения «с нуля» решений SAP, а также использования гибкой методологии Agile для разработки и кастомизации информационных систем. Сделан вывод о целесообразности применения метода Scrum в проектах развития SAP-систем путём доработки.
Ромуальд Здебский, Обеспечение качества через интегрированное управление прое...SQADays_2009_Piter
Ромуальд Здебский, Microsoft, Санкт-Петербург, Россия
Обеспечение качества через интегрированное управление проектами разработки ПО - настоящее и будущее
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
Современные подходы в инжиниринге сложных технических систем
Конференция ЦСР «С-З» для ГК «Росатом»
Кузнецов Л.В., Советник генерального директора
Крыловский государственный научный центр
Доклад был представлен на стратегической сессии кластера радиационных технологий Санкт-Петербурга и Ленинградской области
работа содержит описание метода Agile Scrum в проектах внедрения корпоративных информационных систем на базе SAP. Рассматриваются вопросы применения Scrum в проектах развития, тиражирования и внедрения «с нуля» решений SAP, а также использования гибкой методологии Agile для разработки и кастомизации информационных систем. Сделан вывод о целесообразности применения метода Scrum в проектах развития SAP-систем путём доработки.
Наталья Чуфырина, Mail.Ru Group, «Как создать команду по автоматизации тестир...Mail.ru Group
Существует мнение, что от разработчиков системы автоматизированных тестов требуется высокая квалификация в области разработки программного обеспечения и солидный багаж знаний. Обычно таких людей в команде тестирования не много. Но можно начать работы по качественной автоматизации тестирования, даже не имея такого опыта. В докладе речь пойдет о:
отборе рекрутов в программу обучения автоматизации тестирования;
первичном пороге для вхождения в рекруты;
составлении учебной программы;
промежуточном контроле и испытаниях;
начале работы над реальными проектами;
подводных камнях и ошибках, которые можно допустить.
Применение этих знаний на собственном опыте позволило компании получить высокое покрытие проекта тестами и достичь результатов, когда каждый из команды разрабатывает и поддерживает автотесты, а также самостоятельно автоматизирует новые проекты.
Статья «Формирование универсальных требований к пользовательским программам п...ph.d. Dmitry Stepanov
предлагается обобщенная структура описания программ. Используя предложенную структуру, формулируются универсальные требования, применимые к любым пользовательским разработкам и необходимые в процессе подготовки функционально-технической спецификации на разработку программы.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
2. Вводная часть
Цель выступления
1. Нет цели научить и рассказать как делать проекты.
2. Нет цели научить разрабатывать проект «from scratch».
Основная цель выступления - Познакомить аудиторию с реальным опытом разработки большого
JAVA приложения.
1. Познакомить с применяемыми принципами анализа требований
2. Рассказать подходе к управлению требованиями
3. Использование системы хранения версий.
Познакомить с реальной жизнью в проектах. Рассказать о своѐм опыте.
Термины. Определения
1. «Большая система».
2. Подсистема.
2
4. Часть 1. Проработка архитектуры (1)
Архитектура приложения определяет:
1. Функции, которые будет выполнять приложение в целом
2. Компоненты из которых будет состоять приложение
3. Функции которые будут выполнять компоненты
4. Как компоненты будут взаимодействовать между собой
Правильный анализ – залог будущего вашего проекта
4
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. Часть 1. Проработка архитектуры (3)
Разделение общего целого на блоки. First application Second application
Не скатываться к - «Целое состоит из частей»
1. Общий код переносится из одной
части системы в другую
2. Группировка сущностей в пакет
3. Выделение общего функционала в отдельные пакеты
Пакет как отдельная подсистема-проект.
6
7. Часть 1. Проработка архитектуры (4)
Влияние факторов на процесс разработки.
Одно принятое решение = один фактор влияния
Technical debt
1. Business pressure
2. Lack of process or understanding
3. Lack of building loosely components
4. Lack of design/project documentation
5. Feature parallel development
6. Delayed refactoring.
7. Laziness of project staff.
7
8. Часть 1. Проработка архитектуры (5)
Предвидение будущего. Масштабирование нагрузки.
Первый этап оптимизация
Основные шаги оптимизации
1. Запросы к DB. Скорость получения результата.
2. Необходимость изменения структуры DB
3. Анализ алгоритмов обработки данных
4. Оптимизация –, есть ли необходимость оптимизировать структуру DB, алгоритмы обработки данных
(оптимальная работа алгоритмов)
Масштабирование
1. Вертикальное – увеличение ресурсов в рамках одного узла.
2. Горизонтальное – добавление новых узлов.
Закон Амдала
В случае, когда задача разделяется на несколько частей,
суммарное время еѐ выполнения на параллельной системе не
может быть меньше времени выполнения самого длинного фрагмента
8
11. Часть 2. Декомпозиция (1)
Декомпозиция
1. Как часть аналитического метода
2. Как часть работ по планированию
3. Разделение
одной большой задачи
на группу мелких задач
11
12. Часть 2. Декомпозиция (2)
Разработка в два основных этапа:
1. Разработка базовой функциональности
2. Разработка отдельных подсистем, как самостоятельных проектов.
12
14. Часть 3. Процесс разработки (1).
Разработка проекта несколькими независимыми группами разработчиков
14
15. Часть 3. Процесс разработки (2).
Процесс отчѐтности
Последствия неверно составленного отчѐта
1. Трата времени на выяснение действительного статуса работ.
2. Несвоевременное принятие решений по проекту. Потеря времени может оказать негативное влияние на
проект в целом.
Способы решения
1. Формулировка в отчѐте по задаче должна отвечать на вопрос - Что сделал? Какой результат?
2. Детальное описание результата.
3. Единое время посылки отчѐтов для всех инженеров.
15
17. Часть 4. Процесс разработки. AccuRev (1)
Дано:
1. Команда разработчиков, тестировщиков, аналитиков, архитекторов…. Более 100 человек.
2. Исходный код, который содержит несколько миллионов строк.
Почему AccuRev
1. Необходимость обеспечить сложную разветвлѐнную структуру версий разрабатываемого продукта
2. Регламентированные роли доступа – инженеры различных категорий, лидеры групп, QA инженеры,
релиз инженеры.
3. Обеспечение различных уровней доступа к коду для разных категорий специалистов.
Особенности работы
1. Нет привычных терминов tag, branch, trunk.
2. Оригинальная терминология. Каждый новый сотрудник должен пройти небольшой вводный курс.
17
18. Часть 4. Процесс разработки. AccuRev (2)
Терминология:
Stream
18
19. Часть 4. Процесс разработки. AccuRev (3)
Picture source: http://www.accurev.com/scm-features.html
19
20. Часть 4. Процесс разработки. AccuRev (4)
Терминология:
Snapshot
20
21. Часть 4. Процесс разработки. AccuRev (5)
Терминология:
Promote
21
22. Часть 4. Процесс разработки. AccuRev (6)
Picture source: http://www.accurev.com/scm-features.html
22
23. Часть 4. Процесс разработки. AccuRev (7)
Picture source: http://www.accurev.com/scm-features.html
23
24. Часть 4. Процесс разработки. AccuRev (8)
Picture source: http://www.accurev.com/scm-features.html
24
26. Часть 5. Как работать с
большим объѐмом требований.
Contour.
Управление требованиями в проекте с
помощью Contour
27. Часть 5. Требования. Contour (1)
Что такое изменение требований?
- CR (Change Request)
- New Feature
Цели
- Добавить новый функционал
- Добавить новую возможность
- Изменить существующий бизнес процесс.
- Внести изменения в
27
28. Часть 5. Требования. Contour (2)
Инициаторы изменений
Представители заказчика разного уровня– аналитики, участники различных бизнес процессов.
Бизнес аналитик со стороны исполнителя проекта
Архитекторы
Представители отдела R&D (Research and Development)
Формулировка требования с точки зрения аналитика.
Пример:
Система должна логировать действия пользователя при изменениях в реестре товаров.
28
29. Часть 5. Требования. Contour (3)
Формулировка требования с точки зрения архитектора системы.
1. Все операции изменения реестра должны содержать атрибут «Исполнитель»
2. Добавить журнал изменений. Просмотр журнала изменений.
Формулировка задачи для разработчиков
1. Задача 123 – разработать Журнал изменений
2. Добавить атрибуты ID пользователя (Long userId;) и текст изменения (String changeMessage;)
3. При внесении изменения в реестр создавать запись в журнале изменений.
Формулировка задачи для тестировщиков. Тестовый сценарий.
1. Войти в систему под тестовым пользователем, который имеет право на изменение в реестре товаров.
2. Произвести изменение в реестре.
3. Убедиться, что изменение отражено в журнале изменений.
Работа началась……..
29
30. Часть 5. Требования. Contour (4)
STOP
Заказчик снова меняет требования после начала работ.
1. Производить запись в журнал изменения, которые касаются только добавления новых позиций в реестр.
Сложности и возможные ошибки:
1. Внести изменения во все связанные документы. Высока вероятность того, что необходимые изменения
будут внесены не во все связанные документы.
2. Проинформировать всех заинтересованных лиц. Высока вероятность того, что не все будут
проинформированы о произошедших изменениях.
Как следствие – потеря времени на установление истины.
30
31. Часть 5. Требования. Contour (5)
Единый репозиторий требований Countour.
1. Взаимные связи.
2. Поддержка хранения версий документов.
3. Синхронизация.
Преимущества использование Contour
1. Все требования и изменения к ним публикуются в Contour.
2. Уникальные идентификаторы для каждого документа. Поддержка связей между документами.
3. Всем участникам проекта доступна одинаковые версии документов. Описание требований, тест планы.
4. Просмотр истории изменений.
5. Уведомление. Каждый разработчик и тестировщик, которые работают над разработкой конкретной
feature получает уведомление о внесѐнных изменениях.
31
32. Часть 5. Требования. Contour (6)
Picture source: http://www.jamasoftware.com/contour/screenshots.php
32
33. Часть 5. Требования. Contour (7)
Picture source: http://www.jamasoftware.com/contour/screenshots.php
33
34. Часть 5. Требования. Contour (8)
Пример.
FEATURE_000123 123 – номер feature
FR-123-000001 – Функциональное требование
34
35. Часть 5. Требования. Contour (9)
Picture source: http://www.jamasoftware.com/contour/screenshots.php
35
37. Часть 6. Тестирование. Облако (1)
Часто встречающаяся проблема
Большая система требует много аппаратных ресурсов для промежуточного и финального тестирования.
Обеспечение каждого сотрудника проекта
необходимыми аппаратными средствами
может привести к значительному
перерасходу бюджета проекта.
37
38. Часть 6. Тестирование. Облако (2)
Пример решение проблемы
QA инженеры
Серверы
Группы разработчиков
38
39. Часть 7. Поддержка и
дальнейшая модернизация
проекта. Bug fixing and new
features.
40. Часть 7. Bug fixing and new features (1)
Непрерывный bug fixing
Работа двух команд из разных часовых поясов
Нижний США
Новгород
Transfer meeting
Email transfer
40
43. Contacts
Thank You and
We Look Forward to Working with You
Auriga, USA Auriga, Russia
92 Potter Rd, Ste 1 125 Varshavskoe Shosse, Unit 16A
Wilton, NH 03086, USA Moscow, 117587
Phone: +1 (866) 645-1119 Tel:+7 (495) 713-9900
Fax: +1 (603) 386-6097 Fax:+7 (495) 939-0300
info@auriga.com info@auriga.com
www.auriga.com www.auriga.com
43