Дипломная работа - Тырин А.А. (АП-91). Назначение и область применения

• Название: Назначение и область применения
• Дата: 18.02.2022
• Размер: 0.55 Mb.
• Имя файла: Дипломная работа - Тырин А.А. (АП-91).docx
• Тип: Техническое задание; #366386
• страница: 9 из 15

5. Конструкторско-технологическая часть

5.1 Технология программирования

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

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

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

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

Основные идеи гибких методик разработки:

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

Гибкая методология разработки придерживается следующих принципов:

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

Рассмотрим несколько методов более конкретно.

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

Экстремальное программирование (англ. Extreme Programming, XP) – это упрощенная методология организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований. Авторами методологии являются Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Цели экстремального программирования.

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

Принципы экстремального программирования.

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

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

Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков). Парное программирование направлено на решение задачи стабилизации проекта. При применении экстремального программирования высок риск потери кода по причине ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода. Немаловажно и то, как именно распределены группы в рабочем пространстве – в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем.

Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.

Достаточная степень смелости и желание идти на риск.

Основные приемы экстремального программирования.

Двенадцать основных приёмов экстремального программирования [2] могут быть объединены в четыре группы:

• 
  Короткий цикл обратной связи (Fine scale feedback)
  
  • 
    Разработка через тестирование (Test driven development)
    
  • 
    Игра в планирование (Planning game)
    
  • 
    Заказчик всегда рядом (Whole team, Onsite customer)
    
  • 
    Парное программирование (Pair programming)
    
• 
  Непрерывный, а не пакетный процесс
  
  • 
    Непрерывная интеграция (Continuous Integration)
    
  • 
    Рефакторинг (Design Improvement, Refactor)
    
  • 
    Частые небольшие релизы (Small Releases)
    
• 
  Понимание, разделяемое всеми
  
  • 
    Простота (Simple design)
    
  • 
    Метафора системы (System metaphor)
    
  • 
    Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
    
  • 
    Стандарт кодирования (Coding standard or Coding conventions)
    
• 
  Социальная защищенность программиста (Programmer welfare):
  
  • 
    40-часовая рабочая неделя (Sustainable pace, Forty hour week)
    

5.1.2 Методология SCRUM

Scrum – одна из самых популярных методологий гибкой разработки. Главным преимуществом этой методологии является её простота [18].

В Scrum существуют всего три роли:

• 
  Scrum Master
  
• 
  Product Owner
  
• 
  Team
  

Скрам Мастер (Scrum Master)

Скрам Мастер (Scrum Master) – самая важная роль в методологии. Эта роль отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В гибких методах разработки команда является самоорганизующейся и самоуправляемой.

Основные обязанности Скрам Мастера таковы:

• 
  Создает атмосферу доверия,
  
• 
  Участвует в митингах в качестве человека, обеспечивающего легкую коммуникабельность между участниками митинга
  
• 
  Устраняет препятствия
  
• 
  Делает проблемы и открытые вопросы видимыми
  
• 
  Отвечает за соблюдение практик и процесса в команде
  

Ведущий проекта (Product Owner)

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

Обязанности ведущего проекта таковы:

• 
  Отвечает за формирование концепции продукта
  
• 
  Управляет ожиданиями заказчиков и всех заинтересованных лиц
  
• 
  Координирует и приоритизирует бэклог продукта
  
• 
  Предоставляет понятные и тестируемые требования команде
  
• 
  Взаимодействует с командой и заказчиком
  
• 
  Отвечает за приемку кода в конце каждой итерации
  

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

Команда (Team)

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

Обязанности команды таковы:

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

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

Спринт (Sprint)

В Scrum итерация называется спринт (sprint). Ее длительность обычно составляет 1 месяц (30 дней). Результатом спринта является готовый продукт, который можно передавать заказчику (по крайней мере, система должна быть готова к показу заказчику). Короткие спринты обеспечивают быстрый отзыв проектной команде от заказчика. Заказчик получает возможность гибко управлять возможностями системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в бэклог продукта, получают приоритет наравне с прочими требованиями и могут быть запланированы на один из следующих спринтов. В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Требования к спринту должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что бэклок спринта никем не может быть изменен, кроме команды.

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

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

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

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

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

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

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

5.1.3 Методология Kanban

Методология Канбан (Kanban) является самой гибкой из методологий, представленных на обзор в данной дипломной работе. Основным принципом Канбана является минимизация количества выполняемой в данный момент времени работы. Достигается эта цель с помощью визуализации задач проекта посредством карточек, каждая из которых интерпретирует ту или иную задачу. Такие карточки располагаются на Канбан-доске, которая наглядно демонстрирует количество задач в проекте и их текущее состояние.

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

Для разработки конкретного программного обеспечения канбан-доска может иметь уникальный набор столбцов. Приведём один из вариантов структуры такой доски со значением каждого отдельного столбца.

Цели проекта:

В этом столбце содержатся карточки с целями проекта. Этот столбец является статичным, то есть карточки из него не перемещаются в процессе работы над проектом. Назначение этого столбца несёт мотивационный характер.

Очередь задач:

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

Проработка дизайна:

В этом состоянии производится разработка дизайна интерфейса или архитектура программного кода.

Разработка:

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

Тестирование:

В этом состоянии производится тестирование разработки. В случае если при тестировании были обнаружены ошибки, задача перемещается обратно в состояние «разработка».

Развертывание:

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

Закончено:

Сюда задача попадает, как только завершены все предыдущие работы по этой задаче.

Неотложно:

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

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

Всю методологию Канбан можно описать всего тремя основными правилами:

1. 
   Визуализировать производство
   
2. 
   Ограничивать количество работы, выполняемой одновременно на каждом этапе производства.
   
3. 
   Измерять время цикла (среднее время на выполнение одной задачи) и оптимизировать процесс, чтобы уменьшить это время.
   

Главными отличиями Канбан от Скрам являются:

• 
  Отсутствие лимитов времени ни на задачи, ни на спринты
  
• 
  Задачи больше и их меньше
  
• 
  Оценки сроков на задачу опциональные или вообще их нет
  
• 
  «Скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи
  

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

Выбор методологии разработки программного обеспечения:

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

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

Методология Скрам является самым сбалансированным вариантом из предложенных на обзор. Итеративность метода поможет разработчику сконцентрироваться на конкретной части программы, а не на всей системе в целом. Митинги помогут осознать задачи текущего этапа и выбрать средства разработки. Ежедневные собрания помогут скрам мастеру заблаговременно узнать о возникших трудностях у разработчика и помочь быстро их устранить. Это очень важно, когда речь идёт о недостатке опыта разработки программного обеспечения у программиста.