Методологии разработки по
 Скачать 30.07 Kb.
|
|
Государственное автономное профессиональное образовательное учреждение Чувашской Республики «Чебоксарский профессиональный колледж им. Н.В. Никольского» Министерства образования и молодежной политики Чувашской Республики (ГАПОУ ЧР «ЧПК» Минобразования Чувашии) РЕФЕРАТ По дисциплине: «Технология разработки программного обеспечения» На тему: «Методологии разработки ПО»
Чебоксары 2021 ОглавлениеОглавление 2 Введение 3 1.1. RUP (Rational Unified Process) 4 1.1.2. Жизненный цикл проекта 5 1.2. Microsoft Solutions Framework (MSF) 8 1.3. Scrum 8 1.4. Экстремальное программирование (eXtreme Programming) 9 1.5. Crystal Clear 10 Заключение 11 Список использованной литературы 12 ВведениеМетодологии представляют собой ядро теории управления разработкой ПО. К существующей классификации в зависимости от используемой в ней модели жизненного цикла (каскадные и эволюционные) добавилась более общая классификация на прогнозируемые и адаптивные методологии. Прогнозируемые (предикативные) методологии фокусируются на детальном планировании будущего. Известны запланированные задачи и ресурсы на весь срок проекта. Команда с трудом реагирует на возможные изменения. План оптимизирован исходя из состава работ и существующих требований. Изменение требований может привести к существенному изменению плана, а также дизайна проекта. Адаптивные (гибкие) методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения. Когда меняются требования, команда разработчиков тоже меняется. Команда, участвующая в адаптивной разработке, с трудом может предсказать будущее проекта. Существует точный план лишь на ближайшее время. Более удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах. Среди адаптивных методологий: (Scrum, Crystal, Extreme Programming, Adaptive Software Development, DSDM, Feature Driven Development, Lean software development). Рассмотрим самые основные и популярные методологии. 1.1. RUP (Rational Unified Process)Один из самых известных процессов, использующих итеративную модель разработки – RUP. Он был создан во второй половине 1990-x годов в компании Rational Software. Термином RUP обозначает как методологию, так и продукт компании IBM (ранее Rational) для управления процессом разработки. Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности. Основные характеристики: разработка требований, для описания требований в RUP используются прецеденты использования (use cases). Полный набор прецедентов использования системы вместе с логическими отношениями между ними называется моделью прецедентов использования. Каждый прецедент использования – это описание сценариев взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу. Согласно RUP все функциональные требования должны быть представлены в виде прецедентов использования. итеративная разработка, проект RUP состоит из последовательности итераций с рекомендованной продолжительностью от 2 до 6 недель. Перед началом очередной итерации определяется набор прецедентов использования, которые будут реализованы к её завершению. 1.1.2. Жизненный цикл проектаЖизненный цикл проекта RUP состоит из четырех фаз. Последовательность этих фаз фиксирована, но число итераций, необходимых для завершения каждой фазы, определяется индивидуально для каждого конкретного проекта. Фазы RUP нельзя отождествлять с фазами водопадной модели – их назначение и содержание принципиально различны. Начало (Inception) Стадия «начало» обычно состоит из одной итерации. В ходе выполнения этой стадии необходимо: определить видение и границы проекта; создать экономическое обоснование; идентифицировать большую часть прецедентов использования и подробно описать несколько ключевых прецедентов; найти хотя бы одно возможное архитектурное решение; оценить бюджет, график и риски проекта. Если после завершения первой итерации заинтересованные лица приходят к выводу о целесообразности выполнения проекта, проект переходит в следующую стадию. В противном случае проект может быть отменен или проведена еще одна итерация стадия «начало». Проектирование (Elaboration) В результате выполнения этой стадии на основе требований и рисков проекта создается основа архитектуры системы. Проектирование может занимать до двух-трех итераций или быть полностью пропущенным (если в проекте используется архитектура существующей системы без изменений). Целями этой фазы являются: детальное описание большей части прецедентов использования; создание оттестированной (при помощи архитектурно значимых прецедентов использования) базовой архитектуры; снижение основных рисков и уточнение бюджета и графика проекта. В отличие от каскадной модели, основным результатом этой стадии является не множество документов со спецификациями, а действующая система с 20-30% реализованных прецедентов использования. Построение (Construction) В этой стадии (длящейся от двух до четырех итераций) происходит разработка окончательного продукта. Вовремя ее выполнения создается основная часть исходного кода системы и выпускаются промежуточные демонстрационные прототипы. Внедрение (Transition) Целями стадии «внедрения» являются проведение бета- тестирования и тренингов пользователей, исправление обнаруженных дефектов, развертывание системы на рабочей площадке, при необходимости – миграция данных. Кроме того, на этой стадии выполняются задачи, необходимые для проведения маркетинга и продаж. Стадия «внедрения» занимает от одной до трех итераций. После ее завершения проводится анализ результатов выполнения всего проекта: что можно изменить для улучшения эффективности в будущих проектах Рабочий процесс В терминах RUP участники проектной команды создают так называемые артефакты (work products), выполняя задачи (tasks) в рамках определенных ролей (roles). Артефактами являются спецификации, модели, исходный код и т.п. Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline). В RUP определены шесть инженерных и три вспомогательные дисциплины. В них входят: Бизнес-моделирование (Business Modeling) – исследование и описание существующих бизнес-процессов заказчика, а также поиск их возможных улучшений. Управление требованиями (Requirements Management) – определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком. Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта. Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы. Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований. Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей. Управление конфигурациями и изменениями (Configuration and Change Management) – управление версиями исходного кода и документации, процесс обработки запросов на изменение (Change requests). Управление проектом (Project Management) – создание проектной команды, планирование фаз и итераций, управление бюджетом и рисками. Среда (Environment) – создание инфраструктуры для выполнения проекта, включая организацию и настройку процесса разработки. 1.2. Microsoft Solutions Framework (MSF)Данная методология описывает подход и организацию работы при создании программных продуктов. Подробно про методологию MSF вы можете прочитать в переводе Microsoft Solutions Frameworks for Agile Software Development, которая входит в поставку Microsoft Team Foundation Server 1.3. ScrumScrum предоставляет эмпирический подход к разработке ПО. Этот процесс быстр, адаптивен, умеет подстраиваться и отличен от каскадной модели. Scrum основан на повторяющихся циклах, это делает его более гибким и предсказуемым. Роли, которые участвуют в процессе: Scrum мастер (Scrum Master), Владелец продукта (Product Owner), Команда (Team). Scrum Мастер - самая важная роль в методологии. Scrum Мастер отвечает за успех Scrum в проекте. Как правило, эту роль в проекте играет менеджер проекта или лидер команды (Team Leader). Важно подчеркнуть, что Scrum Мастер не раздает задачи членам команды. В Scrum команда является самоорганизующейся и самоуправляемой. Product Owner - это человек, отвечающий за разработку продукта. Как правило представитель заказчика для заказной разработки. Владелец продукта - это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет. Команда (Team) - в методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Владельцем продукта. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды 1.4. Экстремальное программирование (eXtreme |