Файл: Особенности современных методологий и технологий разработки программного средства.docx

Автономная некоммерческая образовательная организация высшего образования

«Сибирский институт бизнеса и информационных технологий»

Зачетная работа

№7 семестра

ПИСЬМЕННАЯ РАБОТА №1

Дисциплина: Технология и методы программирования, часть 1

Тема: Особенности современных методологий и технологий разработки программного средства.

Выполнил(а): Бобровский Дорин Игоревич

Группа ИН-418(2), 09.03.03 «Прикладная информатика»

Проверил(а): _____________________________

Омск 2023 г.

Оглавление

Введение

Методологии представляют собой ядро теории управления
разработкой ПО. К существующей классификации в зависимости от
используемой в ней модели жизненного цикла (каскадные и
эволюционные) добавилась более общая классификация на
прогнозируемые и адаптивные методологии.
Прогнозируемые (предикативные) методологии фокусируются на
детальном планировании будущего. Известны запланированные задачи и
ресурсы на весь срок проекта. Команда с трудом реагирует на возможные
изменения. План оптимизирован исходя из состава работ и
существующих требований. Изменение требований может привести к
существенному изменению плана, а также дизайна проекта.
Адаптивные (гибкие) методологии нацелены на преодоление
ожидаемой неполноты требований и их постоянного изменения. Когда
меняются требования, команда разработчиков тоже меняется. Команда,
участвующая в адаптивной разработке, с трудом может предсказать
будущее проекта. Существует точный план лишь на ближайшее время.
Более удаленные во времени планы существуют лишь как декларации о
целях проекта, ожидаемых затратах и результатах. Среди адаптивных
методологий: (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. Scrum

Scrum предоставляет эмпирический подход к разработке ПО. Этот
процесс быстр, адаптивен, умеет подстраиваться и отличен от каскадной
модели. Scrum основан на повторяющихся циклах, это делает его более
гибким и предсказуемым.

Роли, которые участвуют в процессе: Scrum
мастер (Scrum Master), Владелец продукта (Product Owner), Команда
(Team).

Scrum Мастер - самая важная роль в методологии. Scrum Мастер
отвечает за успех Scrum в проекте. Как правило, эту роль в проекте играет
менеджер проекта или лидер команды (Team Leader). Важно
подчеркнуть, что Scrum Мастер не раздает задачи членам команды. В
Scrum команда является самоорганизующейся и самоуправляемой.

Product Owner - это человек, отвечающий за разработку продукта.
Как правило представитель заказчика для заказной разработки. Владелец
продукта - это единая точка принятия окончательных решений для
команды в проекте, именно поэтому это всегда один человек, а не группа
или комитет.

Команда (Team) - в методологии Scrum команда является
самоорганизующейся и самоуправляемой. Команда берет на себя

---

обязательства по выполнению объема работ на спринт перед Владельцем
продукта. Работа команды оценивается как работа единой группы. В
Scrum вклад отдельных членов проектной команды не оценивается, так
как это разваливает самоорганизацию команды

1.4. Экстремальное программирование (eXtreme
Programming)

Методология XP, разработанная Кентом Беком (Kent Beck), Уордом
Каннингемом (Ward Cunningham) и Роном Джеффрисом (Ron Jeffries),
является сегодня одной из самых популярных гибких методологий. Она
описывается как набор практик: игра в планирование, короткие релизы,
метафоры, простой дизайн, переработки кода (refactoring), разработка
«тестами вперед», парное программирование, коллективное владение
кодом, 40-часовая рабочая неделя, постоянное присутствие заказчика и
стандарты кода.

Интерес к XP рос снизу вверх – от разработчиков и тестировщиков,
замученных тягостным процессом, документацией, метриками и прочим
формализмом. Они не отрицали дисциплину, но не желали бессмысленно
соблюдать формальные требования и искали новые быстрые и гибкие
подходы к разработке высококачественных программ.

При использовании XP тщательное предварительное
проектирование ПО заменяется, с одной стороны, постоянным
присутствием в команде заказчика, готового ответить на любой вопрос и
оценить любой прототип, а с другой – регулярными переработками кода
(так называемый рефакторинг). Основой проектной документации
считается тщательно прокомментированный код. Очень большое
внимание в методологии уделяется тестированию. Как правило, для
каждого нового метода сначала пишется тест, а потом уже
разрабатывается собственно код метода до тех пор, пока тест не начнет
выполняться успешно. Эти тесты сохраняются в наборах, которые
автоматически выполняются после любого изменения кода.

Хотя парное программирование и 40-часовая рабочая неделя и
являются, возможно, наиболее известными чертами XP, но все же носят
вспомогательный характер и способствуют высокой производительности
разработчиков и сокращению количества ошибок при разработке.

---