Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы разработки информационных систем. Учебное пособие.pdf
2. МЕТОДОЛОГИИ РАЗРАБОТКИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
2.1. РАЗВИТИЕ ТЕХНОЛОГИЙ РАЗРАБОТКИ
В развитии технологий разработки программного обеспечения можно
выделить три этапа.
I этап (конец 60-х – 70-е гг. XX в.). Осмысление опыта разработки
больших систем, включающее понимание важности того, как ведётся разработка ПО, а не только на каком языке программирования это делается. Этот
этап также характеризуется проведением первых международных и национальных конференций.
II этап (начал
нологических подходов.
III этап (середина 80-х гг. XX в. – настоящее время). Принятие стандартов на состав процессов жизненного цикла ПО и многочисленные попытки
решить проблему качества программных средств. Достижение высокого качества программных средств существенно зависит от качества технологии и
инструментальных средств, испо
сопровождении ПО.
В конце 60-х гг. прошлого века в США было отмечено явление под названием software crisis (кризис программного обеспечения). Быстрое развитие
компьютерных технологий привело к росту областей их применения, увеличению функций, а, следовательно, сложности и масштабу разрабатываемого ПО. Оказалось, что неформальный подход, применявшийся ранее к раз
ботке программных средств, недостаточен для разработки крупномасштабных программных средств. Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого ПО
не устраивало потребителей. Сто
снижалась, тогда как стоимость ПО стремительно возрастала.
Основными причинами кризиса, по мнению разработчиков ПО, стало:
• нечёткая и неполная формулировка требований к ПО;
• недостаточное вовлечение пользователей в работу над проектом;
• отсутствие необходимых ресурсов;
• неудовлетворительное планирование и отсутствие грамотного управ-
ления проектом;
• частое изменение треб
• новизна и несовершенство используемых технологий;
• недостаточная поддержка со стороны высшего руководства;
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
о 70-х гг. XX в. – настоящее время). Разработка новых тех-
льзуемых разработчиками при создании и
ра-
имость аппаратных средств постепенно
ований и спецификаций;
21
• недостаточно высокая квалификация разработчиков, отсутствие не-
обходимого опыта.
Кризис выявил необходимость в принципиальном изменении методов
в сфере разработки программных средств и к переходу от технологии индивидуального программирования отдельных небольших программ к коллективному созданию крупномасштабного ПО инженерными методами проектирования и разработки. Накопление в мире знаний, опыта разработки и
именения огромного количества различных сложных компьютерных про-
пр
грамм способствовало систематизации и обобщению методов и технологий
их разработки, сокращению дефектов и неопределённостей в характеристиках и качестве поставляемых и применяемых программных продуктов, объединённых общим названием software engineering.
Программная инженерия – это область компьютерной науки и технологии, которая занимается построением программных систем, настолько больших и сложных, чт
о для этого требуется участие слаженных команд разработчиков различных специальностей и квалификаций. Обычно такие системы
существуют и применяются долгие годы, развиваясь от версии к версии, претерпевая на своём жизненном пути множество изменений, улучшение существующих функций, добавление новых или удаление устаревших возможностей, адаптацию для раб
оты в новой среде, устранение дефектов и ошибок.
Суть методологии программной инженерии состоит в применении систематизированного, научного и предсказуемого процесса проектирования, разработки и сопровождения программных средств.
В основе программной инженерии лежит одна фундаментальная идея:
проектирование программных средств является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное пр
именение методов и средств создания ПО позволяет повысить его качество, обеспечить управляемость процесса проектирования ПО и увеличить срок его
жизни.
Невозможно достичь удовлетворительных результатов от применения
даже самых совершенных технологий и инструментальных средств, если они
применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам п
роект выполняется и управляется хаоти-
чески.
В начале 1990-х гг. в индустрии информационных технологий стал распространяться новый термин «быстрая разработка приложений» (Rapid
Application Development, RAD).
RAD – концепция создания средств разработки программных продуктов,
уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально
быстро создавать компьютерные программы. Концепцию RAD также часто
связыва
ют с концепцией визуального программирования.
22
2.2. ОСНОВНЫЕ ПРИНЦИПЫ ГИБКИХ МЕТОДОЛОГИЙ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Методология – это система принципов, а также совокупность идей, по-
нятий, методов, способов и средств, определяющих стиль разработки ПО.
Методологии представляют собой ядро теории управления разработкой ПО. В зависимости от используемой в методологии модели жизненного
цикла выделяют каскадную и итеративную разработку.
Каскадная разработка – модель процесса разработки ПО, в которой процесс раз
работки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и
поддержки.
На сегодняшний день чисто каскадная разработка ПО не применяется
из-за малой гибкости модели, однако она может использоваться в сочетании
с более современными методологиями, образуя гибридные модели разработки ПО.
Итеративная разработка предполагает выполнение работ параллельно с
ерывным анализом полученных результатов и корректировкой преды-
непр
дущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл Планирование–Реализация–Проверка–Оценка.
Также существует классификация, согласно которой методологии делят
на прогнозируемые и адаптивные.
Прогнозируемые методологии фокусируются на детальном планировании будущего. Известны запланированные задачи и ресурсы на весь срок
роекта. Команда с трудом реагирует на возможные изменения. План опти-
п
мизирован исходя из состава работ и существующих требований. Изменение
требований может привести к существенному изменению плана, а также дизайна проекта. Часто создаётся специальный комитет по «управлению изменениями», чтобы в проекте учитывались только самые важные треб
ования.
Адаптивные методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения. Когда меняются требования,
команда разработчиков тоже меняется. Команда, участвующая в адаптивной
разработке, с трудом может предсказать будущее проекта. Существует точный план лишь на ближайшее время. Более удалённые во времени планы существуют лишь как декларации о целях про
екта, ожидаемых затратах и ре-
зультатах.
В настоящее время в индустрии информационных технологий широкое
распространение получили так называемые «гибкие» или, как ещё их называют, «быстрые» методики разработки (agile development processes). Основные идеи, которые заложены в методологию гибкой разработки, были сформулированы ведущими программистами (Алистер Коберн, Мартин Фаулер,
Джим Хайс-мит, Кент Бек и др.). В 2001
году сформированная ими группа
под названием Agile Alliance, основываясь на своём богатом опыте участия
в разнообразных проектах в течение многих лет, разработала подход к разра-
23
ботке программных средств под названием «Гибкая (быстрая) разработка ПО»
(Agile software development). Этот подход базируется на четырёх идеях,
сформулированных ими в документе «Манифест гибкой разработки ПО»
(Agile Alliance's Manifesto) и заключающихся в следующем:
• люди и их взаимодействие важнее процессов и инструментов;
• работающее ПО важнее документации по нему;
• сотрудничество с заказчиками важнее жёстких контрактных ог
рани-
чений;
• реакция на изменения важнее следования плану.
Гибкая разработка базируется на следующих принципах:
• Наивысшим приоритетом является удовлетворение потребностей за-
казчика, благодаря регулярной и ранней поставке программного обеспечения.
• Изменение требований приветствуется, даже на поздних стадиях раз-
работки. Быстрота изменений позволяет обеспечить проект конкурентным
преимуществом.
• Работающий продукт следует выпускать как можн
о чаще, с перио-
дичностью от пары недель до пары месяцев.
• На протяжении всего проекта разработчики и представители заказ-
чика должны ежедневно работать вместе.
• Над проектом должны работать мотивированные профессионалы.
• Непосредственное общение является наиболее практичным и эффек-
тивным способом обмена информацией как в самой команде разра
ботчиков,
так и между пользователями и разработчиками.
• Работающий продукт – основной показатель прогресса.
• Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
• Простота – искусство минимизации лишней работы – крайне необ-
ходима.
Самые лучшие требования, архитектурные и технические решения рож-
даются у самоорганизующихся команд.
Команда должна систематически анализировать возможные с
пособы улуч-
шения эффективности и соответственно корректировать стиль своей работы.
Быстрота предполагает манёвренность, которая в настоящее время становится более важной, чем когда-либо. Распространение ПО в Internet ещё
больше усилило конкуренцию между программными продуктами. Нужно не
только выпускать ПО на рынок и сокращать число дефектов в них, но и по-
о следить за изменяющимися требованиями пользователей и рынка.
стоянн
В настоящее время существует множество различных методологий разработки программного обеспечения, но все они не являются универсальными. Выбор конкретной методологии зависит от размера команды, специфики
и сложности проекта, стабильности и зрелости процессов в компании, личных качеств сотрудников и других факторов. По оц
енке Алистера Коберна,
гибкая разработка ПО применима только в проектах малого и среднего масштаба с низкой критичностью (C или D).
24
2.3. КРАТКИЙ ОБЗОР ОСНОВНЫХ ГИБКИХ МЕТОДОЛОГИЙ
В области разработки ИС нашли широкое применение такие гибкие ме-
тодологии, как XP, Scrum, Kanban и др.
Экстремальное программирование. Одной из гибких методологий
разработки ПО является «экстремальное программирование» (Extreme
Programming – XP), авторами которой являются Кент Бек, Уорд Каннингем и др.
Название методологии исходит из идеи применить полезные традици-
онные методы и практики разработки ПО, подняв их на но
вый «экстремаль-
ный» уровень.
Основными принципами XP являются:
• итеративность;
• простота решений;
• интенсивная разработка малыми группами;
• обратная связь с заказчиком, представитель которого фактически во-
влечён в процесс разработки.
XP предназначено для небольших команд (не больше 10 человек), наце-
ленных на получение как можно более высокого качества и продуктивности,
и достигает эт
ого посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению и навыкам, дисциплине и пониманию, сводя к минимуму все промежуточные рабочие продукты.
При данной методологии разработка ведётся короткими итерациями при
наличии активной взаимосвязи с заказчиком.
В XP признаётся важность принятия проектных решений, но категори-
чески отрицается жёсткое заблагов
ременное планирование с полной детализацией проекта. Вместо этого прилагаются большие усилия для обеспечения
коммуникации и способности быстро менять направленность проекта. Имея
такую способность, разработчики могут на любом этапе проекта выбирать
простейшее из работоспособных решений, а затем постоянно вносить много
мелких проектных улучшений, постепенно приводя архитектуру ИС до максимального удовлетворения пот
ребностей пользователей.
Методология Scrum. Одной из самых популярных гибких методологий
разработки ПО на сегодня является Scrum.
Scrum (от англ. толкучка) – это методология управления проектом по соз-
данию различных продуктов, активно применяющаяся при разработке ПО.
Обычно, при создании ПО, Scrum дополняют инженерными практиками из
других гибких методологий (например, из экстремального программирования).
В Scrum выделяют три элемента:
роли:
1)
• владелец продукта;
• команда;
• скрам-мастер;
2) артефакты:
• беклог продукта;
25
• беклог спринта;
• инкремент продукта;
3) процессы:
• скрам-митинг;
• планирование спринта;
• спринт;
• обзор спринта;
• ретроспектива.
В Scrum принято выделять три основные роли:
• владелец продукта (менеджер продукта) – это человек, ответствен-
ный за приоритезацию требований и часто за их создание;
• команда – как правило, состоит из небольшого числа людей (7
±
2 че-
ловек), один из членов команды становится скрам-мастером. Владелец продукта не является членом команды в прямом смысле этого слова;
• скрам-мастер – член команды, который дополнительно отвечает за
процессы и координацию работы команды. Он должен ежедневно следить за
тем, чтобы скрам-митинг начинался и заканчивался вовремя, помогает команде п
роводить планирование спринта и запуск спринта, в конце спринта
организует демонстрацию результатов.
К артефактам относится:
• беклог продукта – приоритезированный список требований с оцен-
кой трудозатрат. Обычно он состоит из бизнес-требований, которые приносят
конкретную бизнес-ценность;
• беклог спринта – часть беклога продукта, с самой высокой важно-
стью и суммарной оценкой, не пр
евышающей скорость команды, отобранная
для спринта;
• инкремент продукта – новая функциональность продукта, созданная
во время спринта.
Список задач беклог спринта представляет в виде карточек на стене (так
называемой Scrum-доске или доске задач).
Большинство процессов Scrum носят характер встреч, так как данная
методология основана на качественных коммуникациях. Выделяют следующие процессы:
• скрам-митинг (ск
рам, планёрка) – собрание членов команды (с возможностью приглашения владельца продукта) для синхронизации деятельности команды и обозначения проблем;
• планирование спринта – формирование беклог спринта (список за-
дач, которые команда планирует реализовать в рамках спринта);
• спринт – итерация в Scrum, имеющая жёстко фиксированное время
(1 – 4 недель), в ходе которой создаётся зако
нченный функционал;
• обзор спринта (демонстрация) – показ владельцу продукта и заинте-
ресованным лицам работающего функционала продукта;
• ретроспектива – получение отзывов о функционале продукта.
26
Scrum-команда проводит короткие встречи (не более 15 минут) каждый
день, в одно и то же время, в одном и том же месте. При скрам-митинге решаются три вопроса:
1. Что было сделано с предыдущего скрам-митинга?
2. Какие есть проблемы?
3. Что будет сделано к следующему скрам-митингу?
Если первый и третий пункт служат для синх
ронизации деятельности
команд, то второй пункт очень важен для выработки решений проблем: если
проблема действительно небольшая, её можно решить или выработать решение прямо на скрам-митинге, если серьёзная и требует обсуждения, то она
решается после скрам-митинга.
Поскольку длина спринта в Scrum жёстко фиксирована, то команда оп-
ределяет кол
ичество элементов беклога (объём работ), которые она может
реализовать. В беклоге необходимо, чтобы:
• все элементы имели уникальную числовую важность;
• самые важные элементы были уточнены и понятны всей команде и
владельцу продукта;
• владелец продукта чётко представлял, что будет реализовано в рам-
ках каждого элемента беклога.
Основная задача проведен
ия обзора спринта заключается в получении
обратной связи.
Демонстрация результатов работы не только мотивирует команду, но и
подталкивает реализовывать задачи полностью.
Основной мерой прогресса является функционал продукта, поэтому показывать на демонстрации надо именно программу. Если заказчик находится
не в одном помещении с разработчиками, используются специальные средства демонстрации.
оре спринта обязательно должна принимать участие вся команда,
В обз
при этом возможны разные стратегии показа:
• демонстрация функционала осуществляется одним человеком (на-
пример, скрам-мастером);
• привлечение аналитиков, тестировщиков, верстальщиков и т.д. для
демонстрации «чужих» реализованных элементов беклога. Такой подход позволяет выработать командную ответственность за результат.
Ретроспектива является важной практикой Scrum
: ведь именно они позволяют адаптировать Scrum, делая из него по-настоящему гибкую структуру
для управления проектом. Её традиционно проводят после обзора спринта
спустя небольшое количество времени, чтобы оперативно получить информацию от потребителя. Скрам-мастер собирает всю команду для обсуждения
результатов спринта. Рекомендуется на ретроспективу приглашать владельца
продукта для получения допо
лнительной обратной связи.
Обычно ретроспектива занимает от 30 минут до 4 часов и её продолжи-
тельность зависит от следующих факторов:
27
• длина спринта: чем длиннее спринт, тем больше команда успевает
сделать и тем больше материала для обсуждения;
• размер команды: чем команда больше, тем больше надо времени,
чтобы у каждого её члена была возможность высказаться и тем больше
функционала команда успевает сделать;
• наличие проблем: со временем команда решает проблемы и ретр
о-
спективы сокращаются по времени.
Также традиционным является формат по сбору данных, который за-
ключается в ответах каждого участника на три вопроса:
1. Что было сделано хорошо?
2. Что можно улучшить?
3. Какие улучшения будем делать?
Количество улучшений, которые команда берёт в реализацию, не должно
превышать 2–3, чтобы не снизить скорость реализации бизнес-ф
ункционала.
Команда должна обязательно в том или ином виде составить план улучшений
для контроля их исполнения.
Методология Kanban. Kanban – это гибкая методология разработки
программного обеспечения, ориентированная на задачи.
Термин «канбан» пришёл из Японии благодаря системе организации
производства и снабжения, разработанной и реализованной на фирме Toyota.
Слово «камбан» по-японски означает «рекламный щит, вывеска», ус
тоялся вариант с ошибочной транскрипцией латинской записи японского слова
(kanban). Появление термина «канбан» связано с перечислением стандартных
операций: мастера участков перечисляли выполняемые работы на бумаге и
вывешивали их на видном месте рядом с такими же списками мастеров других участков.
Kanban характеризуется тремя принципами:
1) визуализация процесса работы – вся рабо
та разбивается на задачи,
которые выписываются на карточки и крепятся на стену, подписав столбцы,
чтобы видеть этапы работы;
2) ограничение количества незавершённой работы (НЗР) – определяется
максимальное количество работы на каждом этапе;
3) измерение времени выполнения задачи.
Преимущества Kanban:
• уменьшение числа параллельно выполняемых задач значительно
уменьшает время выполнения каждой отдельной задачи;
• быстрое выявление п
роблемных задач;
• вычисление времени на выполнение усреднённой задачи.
Рассмотрим основные отличия Kanban от Scrum:
Роли. Scrum предписывает наличие трёх ролей (владелец, команда, мастер). Kanban не предписывает никаких ролей, однако это не означает, что их
нельзя использовать. Применяя как Scrum, так и Kanban, можно добавлять
дополнительные роли.
28
Ограничение итераций. Scrum основан на ограниченных по времени
итерациях. Длину итерации можно выбрать любую, однако главная идея состоит в том, чтобы сохранить эту длину неизменной на протяжении определённого периода времени. Итерации в Scrum объединяют три различных вида
деятельности: планирование, улучшение процесса и релиз.
В Kanban ограниченные по времени итерации необязательны. Можно
самостоятельно выби
рать время, когда заниматься планированием, улучшать
процесс и делать релиз. Можно выполнять эти действия не систематически
или по требованию.
Ограничение незавершённых задач. В Scrum и Kanban отслеживается
прогресс в ходе работы, используя список задач, которые представляются
набором карточек на стене.
Обе методологии ограничивают незавершённую работу, но по-разному.
Scrum-команды обычно измеряют производительность – скольк
о задач выполняется за одну итерацию. После того как команда узнает свою производительность, это значение считается границей незавершённой работы.
В Kanban незавершённая работа ограничена по каждому из статусов.
Когда в одной из колонок достигнуто Kanban-ограничение, и части ко-
манды нечего делать, то они ищут «узкое место» дальше по потоку (т.е. зада-
торые скопились с правой стороны доски) и помогают их устранить.
чи, ко
Если же «узких мест» нет, то это может указывать на то, что Kanban ограничение слишком мало, так как ограничения служат для минимизации риска
возникновения «узких мест» дальше по потоку.
А если много элементов находится на доске и не обрабаты
вается, то
возможно Kanban-ограничение слишком велико.
Слишком низкое Kanban-ограничение приводит к тому, что люди простаивают и, следовательно, плохая производительность, а слишком высокое
ограничение приводит к тому, что задачи простаивают, т.е. плохое время выполнения.
Управление доской. Scrum-доска используется только одной командой.
Все участники Scrum-команды обладают всеми навыками, необхо
димыми
для успешного выполнения всех задач итерации. Scrum-доска, как правило,
доступна для просмотра всем желающим, но только Scrum-команда, владеющая этой доской, может вносить изменения – это инструмент для управления
их обязательствами на эту итерацию.
В Kanban доска отображает рабочий процесс и не обязательно должна
принадлежать одной команде.
Разбиение работы. И Scrum, и Kanban базируются на инкр
ементальной
разработке, т.е. работа разбивается на меньшие части.
Scrum-команда возьмётся только за те задачи, которые возможно закончить за одну итерацию. Если задача слишком велика, команда и владелец
продукта будут пытаться разбить её на более мелкие подзадачи, которые
впишутся в спринт.
29
Kanban-команды пытаются минимизировать время выполнения и обеспечить равномерную загрузку, что неявно стимулирует разбивать задачи на
относительно небольшие части. Но при этом не существует никакого явного
правила, что элементы должны быть такого размера, чтобы вписаться в определённый временной интервал. На одной и той же доске могут быть один
элемент, на выпо
лнение которого уйдёт один месяц, и другой, на который
уйдёт один день.
Измерение производительности. В Scrum команда должна оценивать
относительные размеры для каждого элемента, который они обязуются выполнить. Суммируя размеры каждого элемента, завершённого в конце каждого спринта, получается производительность. Зная среднюю производительность, можно составить прогноз о том, какие элемен
ты можно завершить в
предстоящих спринтах и, следовательно, сделать реалистичный план работ.
В Kanban оценки не предусмотрены.
Работа над несколькими продуктами. В Scrum используется понятие
«беклог продукта», который неявно подразумевает, что все его элементы
должны относиться к одному-единственному продукту.
В Kanban можно отображать на одной доске ход работ сразу над несколькими пр
одуктами. Чтобы различать их, можно использовать, например,
карточки разных цветов или разные «дорожки» на доске.
2.4. ИНЖЕНЕРНЫЕ ПРАКТИКИ
Инженерные практики представляют собой проверенные временем решения, связанные непосредственно с реализацией требований заказчика.
Большинство практик, рассматриваемые ниже, взяты из XP.
Непрерывная интеграция. Практика непрерывной интеграции заключается в использовании специального ПО (например, Bamboo, Hudson, Jenkins,
CruiseControl, TeamCity, BuildBot, Travis CI), которое получает свежую версию исходного кода проекта и производит сборку. В сборку проекта входит
запуск автоматических тестов. В случае наличия п
роблем выводится и рас-
сылается соответствующее сообщение.
Когда над разными частями ПО разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить
трудоёмкость интеграции и сделать её более предсказуемой за счёт наиболее
раннего обнаружения и устранения ошибок и п
ротиворечий.
Разработка через тестирование (англ. test-driven development, TDD) –
техника разработки ПО, которая основывается на повторении очень коротких
циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам.
Разработка через тестирование требует от разработчика создания автоматизированных модульных тест
ов, определяющих требования к коду непо-
средственно перед написанием самого кода. Тест содержит проверки усло-
30