exam05 3
Реферат к лекции 5 Управление требованиями, изменениями, инцидентами
ИДБ-19-**
Выполнила: Воробьева Ирина ИДБ-19-06
Проверила: Сарыбаева Анна ИДБ-19-06
Обратимся к "ГОСТ Р ИСО 9000-2015. Национальный стандарт Российской Федерации. Системы менеджмента качества. Основные положения и словарь" для получения разъяснения термина управление изменениями.
Управление изменениями (change control) - Действия по управлению выходом (3.7.5) после официального одобрения информации о конфигурации продукции (3.6.8).
3.7.5. Выход (output): Результат процесса.
Примечание - Является ли выход организации продукцией или услугой , зависит от преобладающих характеристик. Например, покупка музыкального инструмента является продукцией, в то время как поставка музыкального оборудования по заказу является услугой.
3.6.8. Информация о конфигурации продукции (product configuration Information): Требование или другая информация по проектированию, производству, верификации, функционированию и обслуживанию продукции.
Далее обратимся к "ГОСТ Р ИСО 10007-2019 Менеджмент качества. Руководящие указания по менеджменту конфигурации."
Базовая конфигурация состоит из одобренных данных о конфигурации, которые представляют собой определение продукции или услуги. Управление изменениями. После первоначального установления данных о конфигурации следует управлять всеми изменениями. Потенциальное воздействие изменений, требований потребителя и базовой конфигурации влияют на степень управления, необходимую для введения предложенного изменения или применения разрешения на отклонение. Необходимо, чтобы процесс управления изменением был документально оформлен и включал в себя:
- описание обоснования и документированную информацию об изменении
- классификацию изменения с точки зрения его сложности, необходимых ресурсов и планирования
- оценку последствий изменения
Scrum — методология гибкой разработки ПО. Методология делает акцент на качественном контроле процесса разработки
Журнал пожеланий проекта — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса. Project backlog ведется SCRUM Product Owner.
Журнал пожеланий спринта — содержит функциональность, выбранную владельцем продукта из журнала пожеланий проекта Все функции разбиты по задачам, каждая из которых оценивается скрамкомандой. На Sprint Planning Meeting команда оценивает объем работы, который нужно проделать для завершения спринта методом Planning Poker.
Спринт — итерация в скраме, в ходе которой создается инкремент бизнеспродукта. Жестко фиксирован по времени. Длительность одного спринта от 1 до 4 недель.
Взаимодействие команды Scrum-команда — это несколько человек, которые работают на один результат и как единое целое. Каждый стремится к общей цели. Scrum всегда ориентируется на клиента, который должен получить желаемый продукт вовремя и с минимальными затратами. Этого можно достичь при соблюдении нескольких обязательных принципов.
Работа короткими циклами (спринтами) Планируйте один спринт, а не весь проект сразу. Каждый спринт — период, в который команда работает над полностью законченной частью продукта. Гибкость процесса и тестирование продукта после каждого спринта. Если что-то идёт не так, команда всегда готова сменить стратегию разработки или пересмотреть бэклог продукта.
Участие заказчика и пользователей в создании продукта Заказчик не стоит в стороне, а полностью задействован в работе. Для этого существует роль владельца продукта, которую выполняет сам заказчик или его представитель. Именно через него команда взаимодействует с пользователями. Так как разработка ведётся короткими этапами, пользователи подключаются к тестированию почти сразу. После первичного тестирования им открывают доступ к продукту, а владелец продукта собирает обратную связь. Так команда может совершенствовать результат.
DevOps – это методология, которая позволяет автоматизировать и интегрировать процессы между разработчиками программного обеспечения и ИТ-командами. Благодаря этому они создают, тестируют и выпускают качественные продукты в короткие сроки.
Главная задача методологии DevOps – вовремя предоставить необходимую технологию бизнес-подразделениям и наладить ее бесперебойную работу.
Схема работы DevOps
Сокращение DevOps расшифровывается, как development и operations. «Dev» используется как сокращение, обозначающее работу программистов и всех, кто задействован в разработке продукта. Например, менеджеров, тестировщиков и других специалистов. «Ops» – это общий термин, который характеризует работу системных администраторов, операционного персонала, администраторов баз данных, сетевых инженеров, специалистов по безопасности и других.
DevOps – это командные усилия сотрудников, занимающихся разработкой, операциями и тестированием. Как правило, инструменты DevOps вписываются в одну или несколько из этих категорий, что отражает ключевые аспекты разработки и доставки программного обеспечения: *Code — разработка и анализ кода, инструменты контроля версий, слияние кода *Build — инструменты непрерывной интеграции, статус сборки *Test — инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам *Package — репозиторий артефактов, предварительная установка приложения *Release — управление изменениями, официальное утверждение выпуска, автоматизация выпуска *Configure — Конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода *Monitor — мониторинг производительности приложений, опыт работы с конечным пользователем
Непрерывная интеграция практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счёт наиболее раннего обнаружения и устранения ошибок и противоречий, но основным преимуществом является сокращение стоимости исправления дефекта, за счёт раннего его выявления.
Преимущества непрерывной интеграции
Вложения в непрерывную интеграцию возвращаются в виде быстрой обратной связи по изменениям в коде. Быстрой — значит появляющейся за считаные минуты. Команда, которая полагается прежде всего на ручное тестирование, может получить обратную связь через пару часов, но на деле исчерпывающая обратная связь по тестированию приходит через день (или несколько дней) после изменения кода. К этому времени изменений в код вносится еще больше, что превращает устранение багов в сложную задачу, когда в поисках первопричин проблемы разработчикам приходится разбираться в нескольких уровнях кода. Это происходит совсем не быстро.
CI обеспечивает актуальность основной ветви. Разработчики могут использовать современные системы управления версиями, такие как Git, для изоляции их работы в коротких ветвях функций. После завершения функции разработчик отправляет из ветви компонента в главную ветвь. При утверждении запроса на вытягивание изменения объединяются в главную ветвь и ветвь компонента можно удалить.
Команды разработчиков повторяют этот процесс для каждого рабочего элемента. Teams может установить политики филиалов, чтобы убедиться, что основная ветвь поддерживает требуемые критерии качества. Определения сборки указывают, что каждая фиксация в главной ветви активирует процесс автоматической сборки и тестирования. Автоматические тесты проверяют, что каждая сборка поддерживает согласованное качество. CI перехватывает ошибки ранее в цикле разработки, что делает их менее дорогостоящими для исправления.
CI — это стандартная функция на современных платформах DevOps. Пользователи GitHub могут реализовать CI с помощью GitHub Actions. Пользователи Azure DevOps могут использовать Azure Pipelines.
Репозиторий, хранилище место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети. Репозитории используются в системах управления версиями, в них хранятся все документы вместе с историей их изменения и другой служебной информацией.
Пример: Использование репозитория позволяет программистам придать процессу коллективной работы организованный характер. С помощью репозитория ведется учет того, кем и когда внесены изменения в хранящиеся файлы, репозиторий позволяет определить, в чем именно заключались эти изменения, а в случае необходимости — возвратить файлы в исходное состояние. Известные средства организации репозиториев этого рода (также называемые «средства контроля версий») — CVS, Subversion, Git и др
Система управления версиями — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое
Примеры:
SCCS (Source Code Control System): первое поколение
SCCS считается одной из первых успешных систем управления версиями. Она была разработана в 1972 году Марком Рочкиндом из Bell Labs. Система написана на C и создана для отслеживания версий исходного файла. Кроме того, она значительно облегчила поиск источников ошибок в программе. Базовая архитектура и синтаксис SCCS позволяют понять корни современных инструментов VCS.
(Concurrent Versions System): второе поколение
CVS создана Диком Груном в 1986 году с целью добавить в систему управления версиями поддержку сети. Она также написана на C и знаменует собой рождение второго поколения инструментов VCS, благодаря которым географически рассредоточенные команды разработчиков получили возможность работать над проектами вместе.
Git: третье поколение
Систему Git разработал в 2005 году Линус Торвальдс (создатель Linux). Она написана в основном на C в сочетании с некоторыми сценариями командной строки. Отличается от VCS по функциям, гибкости и скорости. Торвальдс изначально написал систему для кодовой базы Linux, но со временем её сфера использования расширилась, и сегодня это самая популярная в мире система управлениями версиями.
ИДБ-18-**
Реферат к лекции 5 Управление требованиями, изменениями, инцидентами
Выполнил: Салип Даниил, ИДБ-18-08
Проверил: Хушнуд Мавлоназаров, ИДБ-18-08
В терминах ГОСТ Р ИСО 9000-2015 управление изменениями рассматривается как набор действий по управлению выходом совокупности взаимосвязанных и (или) взаимодействующих видов деятельности, использующих входы для получения намеченного результата после официального одобрения информации о конфигурации продукции.
Согласно ГОСТ Р ИСО 10007-2019 в процесс менеджмента конфигурации - деятельности, направленной на применение технического и административного управления процессом жизненного цикла продукции и услуги, входит управление изменениями. После первоначального установления данных о конфигурации следует управлять всеми изменениями. Потенциальное воздействие изменений, требований потребителя и базовой конфигурации влияют на степень управления, необходимую для введения предложенного изменения или применения разрешения на отклонение.
Управление изменениями, как правило, состоит из возникновения и регистрации изменений, оценки воздействия, затрат, выгоды и риска от предлагаемых изменений, разработки бизнес-обоснования и получения одобрения, управления и координации реализации изменений, мониторинга и докладов о реализации, пересмотра и закрытия требований на изменения. Контроль изменений, происходящих в проектах развертывания или разработки контролируется процессом управления изменениям, установленным методологией управления проектами, принятой для данного проекта.
SCRUM - методология гибкой разработки ПО, которая делает акцент на качественном контроле процесса разработки.
Участниками проекта по SCRUM являются Product Owner (владелец продукта), SCRUM-мастер и сама команда разработчиков.
Основой данной методологии является Спринт, в течении которого выполняется работа над продуктом. Спринт ограничен по времени и имеет фиксированную продолжительность. По окончанию Спринта должен быть получен инкремент продукта - готовую к использованию часть продукта.
Перед каждым Спринтом производится планирование Спринта, на котором производится оценка содержимого журнал пожеланий проекта (Project backlog), который содержит перечень требований к функциональности, упорядоченный по степени важности, и, соответственно, порядку реализации и формирование журнала пожеланий спринта (Sprint backlog), который содержит функциональность, выбранную владельцем продукта из Project backlog.
Каждый день производится ежедневное SCRUM-совещание. Его Задача — определение статуса и прогресса работы над Спринтом, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Спринта.
По окончанию Спринта также проводятся Sprint Review и Sprint Retrospective, задача которых получение обратной связи от заказчика, чтобы понять, на чём нужно делать акцент в дальнейшем, и какой должен быть следующий инкремент бизнес-продукта, а также оценивание эффективности работы команды в пройденном Спринте, выявление проблем и внесение изменений в необходимые процессы.
Основная ответственность за управление изменениями в данной методологии возлагается на владельца продукта, который определяет для команды наиболее приоритетные задачи для текущего проекта и решает стоит ли выпускать инкремент. В некоторых случаях, если цель спринта потеряла актуальность Product Owner может вообще полностью отменить текущий Спринт.
Главным инструментом для внесения изменений для владельца продукта является Project backlog, а также проводимый в конце Спринта Sprint review.
DevOps, как и другие Agile-практики, ориентирован на командную работу, где рассматриваются все аспекты жизненного цикла ПО, от программного кода до эксплуатации продукта конечным пользователем. DevOps позиционируется как Agile-подход для устранения организационных и временных барьеров между командами разработчиков и других участников жизненного цикла ПО (тестировщиками, администраторами, техподдержкой), чтобы они могли быстрее и надежнее собирать, тестировать и выпускать релизы программных продуктов.
Как правило, инструменты DevOps вписываются в одну или несколько из этих категорий, что отражает ключевые аспекты разработки и доставки программного обеспечения:
- Code — Разработка и анализ кода, инструменты контроля версий, слияние кода
- Build — Инструменты непрерывной интеграции, статус сборки
- Test — Инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам
- Package — Репозиторий артефактов, предварительная установка приложения
- Release — Управление изменениями, официальное утверждение выпуска, автоматизация выпуска
- Configure — Конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода
- Monitor — мониторинг производительности приложений, опыт работы с конечным пользователем
В DevOps процессы управления изменениями часто включают утверждение внешними рецензентами или советами по утверждению изменений (CAB) для продвижения изменений через описанную выше систему. Исследование DevOps Research and Assessment (DORA), представленное в отчете о состоянии DevOps за 2019 год (PDF), показывает, что одобрение изменений лучше всего осуществляется посредством экспертной оценки в процессе разработки, дополненной автоматизацией для раннего обнаружения, предотвращения и исправления плохих изменений в жизненном цикле поставки программного обеспечения.
Такие методы, как непрерывное тестирование, непрерывная интеграция (continuous integration) и комплексный мониторинг и наблюдаемость обеспечивают раннее и автоматическое обнаружение дефектов, прозрачность и быструю обратную связь.
Одним из инструментов непрерывной интеграции, позволяющим осуществлять управление изменениями является создание сборок по расписанию. Это даёт возможность повторно выпускать даже очень старые версии программы с небольшими исправлениями.
Также в качестве инструментов, позволяющих осуществлять управление изменениями DevOps предполагает использование систем управления версиями, которые позволяют хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое. Данный инструмент позволяет осуществлять управление изменениями уже на самых ранних этапах процесса создания продукта.