УчМетПособие_ПрактРаб_ИМС21. Учебнометодическое пособие для студентов бакалавриата рту мирэа по образовательной программе Разработка программных продуктов и проектирование информационных систем

• Название: Учебнометодическое пособие для студентов бакалавриата рту мирэа по образовательной программе Разработка программных продуктов и проектирование информационных систем
• Дата: 12.10.2022
• Размер: 235.77 Kb.
• Имя файла: УчМетПособие_ПрактРаб_ИМС21.docx
• Тип: Учебно-методическое пособие; #729894
• страница: 3 из 10

Раздел 01. Теоретический базис и справочные материалы к практическим занятиям по дисциплине «Информационный менеджмент…»

01.01. Методология, модели разработки. Перечни и понятия. Управленческое соглашение проекта

Методология разработки программного обеспечения — это прежде всего организация труда, включающая идеологические принципы, план, контроль над процессами, подход к сотрудникам.

Здесь представлены 12 современных моделей разработки:

Waterfall — модель быстрой разработки.

RUP (Rational Unified Process) — «рациональная модель».

Agile — общая методология гибкой разработки.

Crystal Clear — подход с уравниванием разработчиков в коллективе.

Spiral — спиральный метод (в современных редакциях, начиная с 2017 г.).

RAD (Rapid Application Development) — модель быстрой разработки.

DSDM (Dynamic Systems Development Model) — динамическая модель.

FDD (Feature Driven Development) — методология, рассматривающая будущие изменения.

JAD (Joint Application Development) — ориентированный на пользователя подход.

Scrum — концепция работы в условиях сорванных сроков и идеологического кризиса.

XP (Extreme Programming) — экстремальная разработка в динамической среде.

LD (Lean Development) — метод, предполагающий бережное отношение ко всем участникам процесса.

Раскроем приведённый выше перечень на реферативном уровне описания его составляющих.
Waterfall

Модель Waterfall относится к классическому пониманию разработки программного обеспечения (ПО). Весь процесс является жестким и линейным, имеет четкие цели для каждого этапа. Новая фаза начинается по завершению предыдущей; нет возврата назад. Преимущества водопадной методологии — децентрализация и строгий контроль над сроками и качеством исполнения.

На практике Waterfall часто не оправдывает ожиданий, поскольку игнорирует динамические изменения. Так, после тестирования очень сложно откатить процесс и заложить функции, не учтенные на стадии разработки. Waterfall не всегда эффективен ещё и потому, что предполагает временные простои сотрудников в рамках одного проекта. Тестирование проводится только в конце разработки, хотя проблемы, найденные на завершающем этапе — это дорогостоящие и времяёмкие исправления и корректировки.
RUP

RUP — итеративный подход, который успешно решает проблемы, которые есть у Waterfall.

Чем замечателен RUP:

• 
  Учитывает изменяющиеся требования. Как бы ни был хорош руководитель проекта, учесть всё в начале невозможно.
  
• 
  Интеграция функций происходит постепенно, то есть каждая «деталь» проходит цикл разработки, проверки и внедрения в проект. Как следствие, снижаются риски и стоимость производства.
  
• 
  Ранний выпуск продукта. ПО выходит с уменьшенной функциональностью, чтобы занять нишу на рынке и противостоять конкурентам, после чего обрастает добавлениями.
  
• 
  Повторное использование. При наращивании функциональности проще выделить типовые решения, которые сократят разработку.
  
• 
  Постоянное обучение. Из-за частых итераций разработчики не имеют больших пауз между доработкой кода, поэтому профессиональный рост происходит плавно и безболезненно.
  
• 
  Постоянное улучшение продукта. Итерации позволяют оценить проект не только с точки зрения соответствия плану и ТЗ, но и найти пути увеличения эффективности и качества продукта.
  

Agile

Agile — метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идеи и 12 принципов гибкого подхода. Кратко его можно описать всего двумя пунктами:

• 
  Неформальные отношения важнее задокументированных. То есть устные договоренности между сотрудниками, между заказчиком и исполнителем важнее всего, что отражено в планах, договорах и техническом задании. Иначе говоря, клиент всегда прав.
  
• 
  Работающий продукт — главная оценка прогресса. Важны не инструменты, решения, производительность и изящество, а тот факт, что все запланированные возможности реализованы.
  

Несмотря на недостатки, Agile стала фундаментальной концепцией для разработки ПО и нашла отражение в других методологиях, речь о которых пойдет далее. К тому же Agile постоянно развивается и совершенствуется. Например, в последнее время освоена и широко применяется улучшенная версия v.04.
Crystal Clear

Методология, созданная для небольших коллективов из 6−10 сотрудников. Также поддерживает принципы гибкой разработки, но имеет чуть больше конкретики. Основная идея, которая и заключена в названии — каждая команда является набором людей с разным уровнем знаний, разными умениями и опытом.

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

Модель спирального жизненного цикла — это сложная организация жизненного цикла ПО, которая фокусируется на раннем выявлении и уменьшении проектных рисков. Разработка начинается в небольшом масштабе, решаются локальные задачи, оцениваются риски и пути их уменьшения. Следующий шаг охватывает более комплексные задачи — следующий виток спирали.

Преимущество подхода не в увеличении скорости разработки, а в снижении уровня возникновения рисков. Успешность спирального метода зависит от добросовестного, внимательного и компетентного управления, а размер проекта не имеет принципиального значения.
RAD

RAD — методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий — использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, и т.д.). Вот ещё несколько пунктов концепции:

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

DSDM

Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс — исследовательская работа.

В DSDM тоже присутствует деление на команды, в каждой из которых есть уполномоченный для принятия стратегических решений. В процессе могут участвовать все заинтересованные стороны: пользователи, разработчики, заказчики, руководители. Тестирование проводится на протяжении всего жизненного цикла.
FDD

FDD — процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Основные принципы FDD:

• 
  Разработка каждого крупного проекта должна иметь системность.
  
• 
  Процессы должны быть простыми и проработанными.
  
• 
  Ценность и логичность процесса должна быть ясна каждому члену команды.
  
• 
  Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.
  
• 
  FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.
  

JAD

JAD — это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.

В отличие от подхода Waterfall, JAD приводит к сокращению времени разработки, большей удовлетворенности клиентов и экономии средств на изучении рынка. С другой стороны, это требует большой клиентской выборки и необходимости разработчиков работать не со строгими требованиями ТЗ, а с постоянно меняющимся мнением.
Scrum

Scrum — гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт — короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).

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

Экстремальное программирование — возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:

Игра в планирование. В начале проекта есть только приблизительный план, после каждой итерации его чёткость возрастает.

Высокая частота релизов. Новая версия продукта имеет незначительные изменения по сравнению с предыдущей, но время на выпуск при этом минимально.

Контакт с клиентом. Для удовлетворения требований конечной аудитории необходимо оперативное реагирование на замечания и пожелания.

Рефакторинг. Улучшение качества кода без уменьшения функциональности.

Стандарт выполнения кода. Или применяются общие правила, или разногласия в оформлении не подлежат обсуждению и критике.

Коллективная ответственность. Несмотря на то, что каждый член команды выполняет свой участок работ, за код в целом отвечает весь коллектив.
LD

Бережливая разработка ПО — ещё одно ответвление гибкой методологии, предполагающее сохранение высокого морально-функционального состояния разработчиков. Это выражается в:

Поощрении сотрудников за успешную работу.

Изменении текущих задач только по мере необходимости или по запросу заказчика.

Строгое выполнение плана: всё, что сверх — считается потерями времени и ресурсов.

Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».