Гибкая методология разработки
Балтийский Государственный Технический Университет ВОЕНМЕХ им. Д. Ф. Устинова
Кафедра И9 "Систем управления и компьютерных технологий"
РЕФЕРАТ
Тема: Процесс разработки ПО. Методологии.
Выполнил студент гр. И 952:
Шестакова А. В.
Проверил:
Васюков В. М.
Г. Санкт-Петербург
Г.
Содержание
1. Введение ----------------------------------------------------------------------------------3
2. Гибкая методология разработки -----------------------------------------------------4
3. Cleanroom Software Engineering ------------------------------------------------------7
4. Rational Unified Process -----------------------------------------------------------------9
5. OpenUP -----------------------------------------------------------------------------------11
6. RAD ---------------------------------------------------------------------------------------13
7. Microsoft Solutions Framework -------------------------------------------------------16
8. Dynamic Systems Development Method --------------------------------------------20
9. Разработка через тестирование -----------------------------------------------------23
10. Заключение ----------------------------------------------------------------------------25
11. Список использованных источников ---------------------------------------------26
Введение
Процесс разработки программного обеспечения (англ. software development process, software process) — структура, согласно которой построена разработка программного обеспечения[1].
Существует несколько различных методологий разработки программного обеспечения:
Гибкая методология разработки
Cleanroom Software Engineering
OpenUP
RAD
Rational Unified Process
Microsoft Solutions Framework
Dynamic Systems Development Method
Разработка через тестирование
Они основаны на разных принципах и концепциях, поэтому стоит поговорить о каждой из них в отдельности, что и будет сделано в следующих параграфах.
Гибкая методология разработки
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся небольших рабочих групп, состоящих из специалистов различного профиля[2].
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование,программирование, тестирование и документирование. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе. Как минимум, она включает и «заказчиков» . Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных.
В феврале 2001 в штате Юта США был выпущен «Манифест гибкой методологии разработки программного обеспечения». Данный манифест был одобрен и подписан представителями методологий: экстремального программирования, Crystal Clear, DSDM, Feature driven development, Scrum,Adaptive software development, Pragmatic Programming. Гибкая методология разработки использовалась многими компаниями и до принятия манифеста, однако вхождение Agile-разработки в массы произошло именно после этого события .
Agile Manifesto содержит 4 основные идеи и 12 принципов. Примечательно, что он не содержит практических советов.
Основные идеи:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.
Основополагающие принципы Agile-манифеста:
- наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения
- изменение требований приветствуется, даже на поздних стадиях разработки; Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества
- работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев
- на протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе
- над проектом должны работать мотивированные профессионалы; чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им
- непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды
- работающий продукт — основной показатель прогресса
- инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно; Agile помогает наладить такой устойчивый процесс разработки
- постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта
- простота — искусство минимизации лишней работы — крайне необходима
- самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд
- команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.[3]