СДЕЛАЙТЕ СВОИ УРОКИ ЕЩЁ ЭФФЕКТИВНЕЕ, А ЖИЗНЬ СВОБОДНЕЕ

Благодаря готовым учебным материалам для работы в классе и дистанционно

Скидки до 50 % на комплекты
только до

Готовые ключевые этапы урока всегда будут у вас под рукой

Организационный момент

Проверка знаний

Объяснение материала

Закрепление изученного

Итоги урока

Технологии командной разработки программного обеспечения

Нажмите, чтобы узнать подробности

В данной разработке рассматриваются технологии командной разработки программного обеспечения. Данный материал полезен для подготовки и проведения занятий по дисциплине МДК.04.01 " Моделирование и анализ программного обеспечения" 

Просмотр содержимого документа
«Технологии командной разработки программного обеспечения»

Технологии командной разработки программного обеспечения

Технологии командной разработки программного обеспечения

 Гибкие методы разработки  Гибкие методы разработки ПО появились в 90-е годы 20-го века в качестве альтернативы формальным методологиям, перегруженных значительным объёмом документирования и проверок, которые зачастую, особенно небольших коммерческих проектах, неэффективны. Основными положениями гибких методов являются следующее: индивидуальные методы и взаимодействие вместо процессов и программных средств; работающее ПО вместо сложной документации; взаимодействие с заказчиком вместо жестких контрактов; реакция на изменения вместо следования плану.  Гибкие методологии предполагают создание небольших, самоорганизующихся команд, состоящих из высококвалифицированных и энергичных людей, ориентированных на бизнес.

Гибкие методы разработки

Гибкие методы разработки ПО появились в 90-е годы 20-го века в качестве альтернативы формальным методологиям, перегруженных значительным объёмом документирования и проверок, которые зачастую, особенно небольших коммерческих проектах, неэффективны. Основными положениями гибких методов являются следующее:

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

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

Экстремальное программирование  Самым известным гибким методом является экстремальное программирование (Extreme Programming или сокращенное название – XP ), созданный специалистом в области программной инженерии Кентом Беком в результате его работы в 1996-1999 годах над системой контроля платежей компании

Экстремальное программирование

Самым известным гибким методом является экстремальное программирование (Extreme Programming или сокращенное название – XP ), созданный специалистом в области программной инженерии Кентом Беком в результате его работы в 1996-1999 годах над системой контроля платежей компании "Крайслер".

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

Основные принципы организации процесса по XP:

  • планирование, основанное на принципе, что разработка ПО является диалогом между возможностями и желаниями, при этом изменятся и то и другое;
  • простой дизайн – против избыточного проектирования;
  • метафора – суть проекта должна умещаться в 1-2 емких фразах или в некотором образе;
рефакторинг – процесс постоянного улучшения (упрощения) структуры ПО, необходимый в связи с добавлением новой функциональности; парное программирование – один программирует, другой думает над подходом в целом, о новых тестах, об упрощении структуры программы и т.д.; коллективное владение кодом – все участники проекта должны уметь писать код; участие заказчика в разработке – представитель заказчика входит в команду разработчика; создание и использование стандартов кодирования в проекте – при написании кода используются стандарты на имена идентификаторов, составление комментариев и т.д.;
  • рефакторинг – процесс постоянного улучшения (упрощения) структуры ПО, необходимый в связи с добавлением новой функциональности;
  • парное программирование – один программирует, другой думает над подходом в целом, о новых тестах, об упрощении структуры программы и т.д.;
  • коллективное владение кодом – все участники проекта должны уметь писать код;
  • участие заказчика в разработке – представитель заказчика входит в команду разработчика;
  • создание и использование стандартов кодирования в проекте – при написании кода используются стандарты на имена идентификаторов, составление комментариев и т.д.;
тестирование – разработчики сами тестируют свое ПО, перемежая этот процесс с разработкой (при этом рекомендуется создавать тесты до того, как будет реализована соответствующая функциональность с привлечением заказчика); непрерывная интеграция – разработка представляется как последовательность выпусков; 40-часовая рабочая неделя.
  • тестирование – разработчики сами тестируют свое ПО, перемежая этот процесс с разработкой (при этом рекомендуется создавать тесты до того, как будет реализована соответствующая функциональность с привлечением заказчика);
  • непрерывная интеграция – разработка представляется как последовательность выпусков;
  • 40-часовая рабочая неделя.
 Однако в полном объеме XP не была использована даже ее авторами.  Кроме того, известны и внедряются отдельные практики XP, как, например, парное программирование, коллективное владение кодом, рефакторинг кода. Однако идея простого, неизбыточного дизайна проекта также оказала значительное влияние на мир разработчиков ПО.  Более практичным гибким методом разработки является Scrum.

Однако в полном объеме XP не была использована даже ее авторами.

Кроме того, известны и внедряются отдельные практики XP, как, например, парное программирование, коллективное владение кодом, рефакторинг кода. Однако идея простого, неизбыточного дизайна проекта также оказала значительное влияние на мир разработчиков ПО.

Более практичным гибким методом разработки является Scrum.

Метод Scrum   В 1986 году японские специалисты опубликовали сообщение о новом подходе к разработке новых сервисов и продуктов (не обязательно программных). Основу подхода составляла сплоченная работа небольшой универсальной команды, которая разрабатывает проект на всех фазах.  В начале 90-х годов данный подход стал применяться в программной индустрии и обрел название Scrum (термин из регби, означающий – схватка ).  Метод Scrum позволяет гибко разрабатывать проекты небольшими командами (7 человек плюс/минус 2) в ситуации изменяющихся требований. При этом процесс разработки итеративен и предоставляет большую свободу команде. Кроме того, метод очень прост – легко изучается и применяется на практике.

Метод Scrum

В 1986 году японские специалисты опубликовали сообщение о новом подходе к разработке новых сервисов и продуктов (не обязательно программных). Основу подхода составляла сплоченная работа небольшой универсальной команды, которая разрабатывает проект на всех фазах.

В начале 90-х годов данный подход стал применяться в программной индустрии и обрел название Scrum (термин из регби, означающий – схватка ).

Метод Scrum позволяет гибко разрабатывать проекты небольшими командами (7 человек плюс/минус 2) в ситуации изменяющихся требований. При этом процесс разработки итеративен и предоставляет большую свободу команде. Кроме того, метод очень прост – легко изучается и применяется на практике.

Его схема изображена на рисунке.

Его схема изображена на рисунке.

 Вначале создаются требования ко всему продукту. Потом из них выбираются самые актуальные и создается план на следующую итерацию.  В течение итерации планы не меняются (этим достигается относительная стабильность разработки), а сама итерация длится 2-4 недели. Она заканчивается созданием работоспособной версии продукта (рабочий продукт), которую можно предъявить заказчику, запустить и продемонстрировать с минимальными функциональными возможностями.  После этого результаты обсуждаются и требования к продукту корректируются. Это удобно делать, имея после каждой итерации продукт, который уже можно как-то использовать, показывать и обсуждать.  Далее происходит планирование новой итерации и все повторяется.

Вначале создаются требования ко всему продукту. Потом из них выбираются самые актуальные и создается план на следующую итерацию.

В течение итерации планы не меняются (этим достигается относительная стабильность разработки), а сама итерация длится 2-4 недели. Она заканчивается созданием работоспособной версии продукта (рабочий продукт), которую можно предъявить заказчику, запустить и продемонстрировать с минимальными функциональными возможностями.

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

Далее происходит планирование новой итерации и все повторяется.

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

KANBAN

KANBAN  – гибкая методология разработки программного обеспечения, ориентированная на задачи. 

Основные правила:

  • визуализация разработки:
  • разделение работы на задачи; использование отметок о положение задачи в разработке;
  • разделение работы на задачи;
  • использование отметок о положение задачи в разработке;
  • ограничение работ, выполняющихся одновременно, на каждом этапе разработки;
  • измерение времени цикла (среднее время на выполнение одной задачи) и оптимизация процесса.

Преимущества KANBAN:

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

Agile

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

Agile описывает  стиль моделирования , который позволит повысить качество и сократить сроки. Он сосредоточен на эффективном  моделировании и документировании . Он не охватывает программирование и тестирование, хотя в нем и говорится о проверке модели кодом и рассматривается тестируемость моделей и не включаются вопросы управления проектом, развертывания и сопровождения системы.

  Этот метод должен использоваться для повышения эффективности труда разработчиков, использующих процессы eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), или RUP.  Цели Agile  Показать, как применять на практике набор понятий, принципов и приемов, позволяющих легко и просто выполнять моделирование. Эта технология сосредоточена не на технике построения конкретных диаграмм, а на том, как их использовать. Показать, как использовать известные методики моделирования (XP, DSDM, RUP и др.) в гибком подходе к разработке проектов. Повысить эффективность моделирования в проектах на разных стадиях (бизнес-анализ, формирование требований, анализ и дизайн).

  Этот метод должен использоваться для повышения эффективности труда разработчиков, использующих процессы eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), или RUP.

Цели Agile

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

Основные принципы Agile Modeling

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