СТАТЬИ АРБИР
 

  2018

  Октябрь   
  Пн Вт Ср Чт Пт Сб Вс
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 1 2 3 4
   

  
Логин:
Пароль:
Забыли свой пароль?


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


ОБЗОР МЕТОДОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Аннотация

В статье рассматриваются различные подходы (методологии) к разработки программного обеспечения. Затрагиваются такие темы, как: размер команды и уровень разработчиков; условия работы; подходы к проектированию.

Ключевые слова

Методологии разработки, XP, FDD, Scrum.

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

FDD

В методологии функционально-ориентированной разработки (FDD, Feature Driven Development) ключевую роль играет понятие функции или свойства системы. Функция должна реализовываться не более чем за две недели. Если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько, относительно независимых, функций.

Основные процессы функционально-ориентированной разработки:

Разработка общей модели - набросок возможностей и взаимодействий системы.

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

Планирование работы над каждой функцией.

Проектирование функции.

Конструирование функции.

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

Методология функционально-ориентированной разработки имеет важное достоинство: всегда имеется рабочая версия проекта, а функционал добавляется постепенно. При увеличении количества разработчиков проекта общая модель и подробный список всех функций позволит быстро влиться в работу, а тщательное проектирование функции в отдельности позволит минимизировать количество ошибок в конечной программе.[1]

Scrum

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

В процессе разработки участвуют:

Владелец продукта (Product Owner), отвечающий за представление интересов заказчика и конечных пользователей на проекте.

Член команды (Scrum Master), следящий за соблюдением принципов Scrum и проводящий ежедневные планерки.

Команда разработчиков (Scrum Team), берет на себя обязательства по выполнению объема работ на спринт перед владельцем продукта. Команда отвечает за оценку элементов баклога, принимает решение по дизайну и программной реализации, разрабатывает программное обеспечение и предоставляет его заказчику, отслеживает собственный прогресс и отвечает за результат перед владельцем продукта.

Достоинства такой методологии в ее гибкости и адаптивности. Методология отлично подойдет для крупных проектов, требующих быстрого старта с минимальным функционалом. Так же к плюсам Scrum можно отнести самостоятельность и самоорганизованность каждого участника проекта. Недостатком данной методологии является неопределенность. Количество спринтов неограниченно, поэтому сложно поставить конечную дату в проекте.[2]

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

Экстремальное программирование (XP) является ответом сообщества программистов на наступление формальных подходов к созданию программных продуктов.

В основе экстремального программирования лежит 12 принципов:

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

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

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

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

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

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

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

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

Заказчик всегда рядом. Основной проблемой разработки программного обеспечения является недостаточная компетентность разработчиков в предметной области. Самым простым способом преодолеть такое неудобство является привлечение заказчика к процессу разработки.

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

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

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

Вывод

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

Список литературы:

Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice Hall

Хенрик Книберг. Scrum и XP: заметки с передовой. — C4Media, 2007.

Бек К. Экстремальное программирование - СПб.: Питер, 2002 - 212 с.


Аникеев Д.А., Пешкова К.Е., Гарченко Е.В. - магистранты Научный руководитель - Сарапулова Т.В., ст. преподаватель Кузбасский государственный технический университет имени Т.Ф. Горбачева, Россия, г. Кемерово





МОЙ АРБИТР. ПОДАЧА ДОКУМЕНТОВ В АРБИТРАЖНЫЕ СУДЫ
КАРТОТЕКА АРБИТРАЖНЫХ ДЕЛ
БАНК РЕШЕНИЙ АРБИТРАЖНЫХ СУДОВ
КАЛЕНДАРЬ СУДЕБНЫХ ЗАСЕДАНИЙ

ПОИСК ПО САЙТУ