Файл: Особенности технологии разработки ПО.pdf

Недостатки:

1. Предполагается, что требования системы могут быть заморожены.
2. Очень сложно вернуться на какой-либо этап после его завершения.
3. Немного гибкости и настройки объема сложно и дорого.
4. Дорого и требует больше времени, помимо подробного плана.

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

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

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

1. Простой и удобный в использовании
2. Каждый этап имеет конкретные результаты.
3. Более высокие шансы на успех по модели водопада из-за разработки планов испытаний в начале жизненного цикла.
4. Хорошо работает там, где требования легко понять.
5. Проверка и валидация продукта на ранних этапах разработки продукта.

Недостатки:

1. Очень негибкий, как модель водопада.
2. Регулировка объема сложна и дорога. [8, 11]
3. Программное обеспечение разрабатывается на этапе реализации, поэтому ранние прототипы программного обеспечения не производятся.
4. Модель не дает четкого пути для проблем, обнаруженных на этапах тестирования.
5. Дорого и требует больше времени, в дополнение к детальному плану.

Модель прототипирования — это относится к деятельности по созданию прототипов программных приложений, например, неполных версий разрабатываемой программы. Это действие, которое может происходить при разработке программного обеспечения, и оно используется для визуализации некоторого компонента программного обеспечения, чтобы ограничить разрыв в неправильном понимании требований заказчика командой разработчиков. Это также уменьшит количество итераций, которые могут возникнуть в подходе с водопадом, и его трудно реализовать из-за негибкости подхода с водопадом. Таким образом, при разработке окончательного прототипа требование считается замороженным. [2]

Он имеет несколько типов, таких как:

1. Быстрое прототипирование: прототипы, которые в конечном итоге отбрасываются, а не становятся частью окончательно поставляемого программного обеспечения
2. Одноразовое прототипирование
3. Эволюционное прототипирование: прототипы, которые эволюционируют в конечную систему благодаря итеративному включению отзывов пользователей.
4. Эволюционное прототипирование
5. Инкрементальное прототипирование: конечный продукт создается как отдельные прототипы. В итоге отдельные прототипы объединяются в общий дизайн.

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

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

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

1. Сокращение времени и затрат, но это может быть недостатком, если разработчик теряет время на разработку прототипов.
2. Улучшено и увеличено участие пользователей.

Недостатки:

1. Недостаточный анализ. Путаница пользователя с прототипом и готовой системой.
2. Недопонимание разработчиком целей пользователя.
3. Избыточное время разработки прототипа.
4. Это дорого для реализации прототипов

Спиральная модель — он объединяет элементы как проектирования, так и поэтапного создания прототипа, стремясь объединить преимущества концепций сверху вниз и снизу-вверх. Эта модель развития сочетает в себе особенности модели прототипа и модели водопада. Спиральная модель предпочтительна для больших, дорогих и сложных проектов. Эта модель использует многие из тех же этапов, что и модель водопада, в основном в том же порядке, разделенных планированием, оценкой риска и созданием прототипов и симуляций. [5]

Он используется в больших приложениях и системах, которые встроены в небольшие фазы или сегменты.

3.3 Использование гибких методологий при разработке ПО

История Agile начинается с публикации в 2001 году «Манифеста гибкой разработки ПО», состоящего из 12 принципов. Конечно, отдельные положения Agile-подхода появились появлялись и до этого, но только этот документ систематизировал и изложил их в достаточной для использования мере. Каждый год под манифестом подписываются новые компании, IT-специалисты и проектные менеджеры. Появляются новые методы и модификации гибкой системы разработки. [3, 9, 15]

Agile — итеративная модель разработки, в которой программное обеспечение создают инкрементально с самого начала проекта, в отличии от каскадных моделей, где код доставляется в конце рабочего цикла.

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

12 принципов, которые составляют Agile Methodology, можно поделить на 4 главные идеи:

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

Своему термину «Scrum» обязан регби, в котором это слово означает метод командной игры в виде построения трех линий каждым из соперников и попытке захватить мяч. Для успешного перехвата нужна не только хорошая физическая подготовка, но и слаженность каждого участника схватки и четкое понимание цели.

Метод успешно применяют такие компании как Microsoft, Yahoo, Siemens Healthcare, а проектный менеджер в Amazon даже описал кейс внедрения Scrum на основе полученного опыта.

Так как скрам — каркас разработки, в каждом последующем примере он может значительно отличаться от предыдущего. [3]

Джефф Сазерленд, автор книги «Scrum. Революционный метод управления проектами» выделил 8 шагов по использованию методики:

1. Выберите владельца продукта — он знает о цели проекта и ожидаемом результате.
2. Соберите команду — до 10 человек с необходимыми для создания работоспособного продукта навыками.
3. Найдите скрам-мастера — он следит за ходом проекта, помогает проектной команде бороться с трудностями.
4. Составьте бэклог продукта — на Agile-доске расставьте приоритеты по каждому требованию к продукту. В этом большую роль играет владелец продукта, который собирает пожелания к продукту для оценки командой бэклога.
5. Запланируйте спринты (итерации) — отрезки времени на выполнение определенного ряда задач.
6. Организовывайте ежедневные пятнадцатиминутные «мит-апы» — задавайте по 3 вопроса каждому из команды: что делал вчера, что будет сегодня, что мешает выполнить задачу.
7. Делайте обзоры рабочих частей продукта — с вовлечением в просмотр и обсуждение стейкхолдеров.
8. Проводите ретроспективу — обсуждение проблемы и поиск решения после каждого спринта. Полученный план изменения внедряете на следующем спринте.

В скрам есть 4 ключевых элемента:

1. Product Backlog — список требований по проекту
2. Sprint Backlog — список требований, которые нужно выполнить в ближайший спринт
3. Sprint Goal — цель спринта
4. Sprint Burndown Chart — диаграмма, которая обновляется по мере завершения задач. По ней легко понять динамику и уровень продвижения команды в проекте. [5]

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

Он применим исключительно в сфере разработки ПО, и строится вокруг 4 процессов:

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

Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet. [15]

Crystal-проекты должны соответствовать 3 основным показателям:

• быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.
• совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.
• «осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.

Над разработкой DSDM трудился не один человек и даже не команда, а консорциум из 17 английских компаний. DSDM, как и экстремальное программирование, используется преимущественно для создания программного обеспечения.

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

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

DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.

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

• цикл функциональной модели — создание аналитической документации и прототипов. [15]
• цикл проектирования и конструирования — приведение системы в рабочее состояние.
• цикл реализации — развертывание системы.

FDD тоже применяется итерационная модель разработки, от Agile она отличается в следующем:

• больше внимания предварительному моделированию
• повышенная (по сравнению с Agile) важность построения отчётности и графиков
• нацелено на корпоративную разработку.

Feature Driven Development состоит из таких цикличных этапов:

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

Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат. [15]

В набор входят следующие 7 принципов:

1. избавление от потерь — всё, что не прибавляет ценности продукту для конечного потребителя.
2. постоянное обучение — непрерывное развитие команды увеличивает возможности эффективного выполнения задач.
3. принятие решения так поздно, как только можно — приоритет не спонтанным решениям, а продуманным, разработанным на основе полученных знаний.
4. быстрая доставка — по сути основа итеративной модели.
5. усиление команды — один из принципов «Манифеста...» гласит, что люди и взаимодействие важнее процессов и инструментов. Проектная команда — основа успешного завершения задач.
6. целостность и качество — нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от багов.
7. видение цельной картины — разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и стратегии разрабатываемого ПО.

Agile Modeling — набор ценностей, принципов и практик для моделирования программного обеспечения.

AM используют как составляющую полноценной методики разработки ПО — например, экстремального программирования или Rapid Application Development.

Принципы Agile Modeling таковы:

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

AUP — упрощённая версия другой методологии разработки ПО — Rational Unified Process (RUP). С 2012 года её заменили на Disciplined Agile Delivery (DAD), но кое-где AUP еще встречается.