Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Введение в программную инженерию. Учебное пособие-1
.pdf
Д.В. Кознов
Введение в программную инженерию
21
чтобы убелить начальство и заказчика в оплате таких процессов,
требуются аргументы — хорошие модели процессов как раз могут быть
такими аргументами.
Отметим, что идея модели процесса является одной из самых ранних в
программной инженерии: тогда, в 60-х – 80-х года XX века считалось,
что удачная модель — это самое главное, что способствует успеху
разработки. В этом видится научный подход к сложности и стремление
выразить, охватить, описать сложное изящным и компактным законом,
уравнением. Однако позднее пришло осознание, что существует
множество аспектов разработки ПО (например, принципы управления,
структура команды, архитектура систем, наконец, национальные и
культурные особенности), которые также должны быть также учтены,
определены и согласованы. В итоге, вместо моделей процесса стали
создаваться интегральные методологии разработки. Тем не менее,
модели процессов используются в обиходе программных разработок до
сих пор и необходимо знать самые известные из них.
Тем не менее существует несколько классических моделей процесса,
которые полезны на практике и которые будут рассмотрены ниже.
Говоря о моделях процессов, необходимо различать фазы и виды
деятельности.
Определение. Фаза (phase) — это определенный этап процесса
разработки, имеющий начало, конец и конечный результат. В качестве
примера можно привести фазу проверки осуществимости проекта,
сдачи проекта. Фазы следуют друг за другом в линейном порядке,
характеризуются предоставлением отчетности заказчику и, часто,
выплатой денег за выполненную часть работы.
Отметим две конкурирующие крайности в программных проектах.
• Заказчик хочет постоянно получать результаты по ходу проекта, а
деньги заплатить как можно позже (в идеале — после завершения
всех работ).
• Подрядчик хочет, чтобы ему не мешали работать (т.е. он хотел бы
предоставить результаты в самом конце), но деньги за проект
получить как можно раньше (в идеале — до начала всех работ).
Д.В. Кознов
Введение в программную инженерию
22
Таким образом, фазы проекта являются разумным компромиссом,
позволяя планировать и предоставлять заказчику результаты по ходу
проекта, а подрядчику после каждого такого результата получать
оплату за выполненную работу.
Фазы полезны также безотносительно взаимодействия подрядчика с
заказчиком — с их помощью в проекте можно синхронизировать
деятельность разных рабочих групп, а также отслеживать продвижение
разработке.
Примерами фаз может служить согласование с заказчиком
технического задания, реализация определенной функциональности
ПО, этап разработки, оканчивающийся сдачей системы на
тестирование или выпуском альфа-версии.
Определение. Вид деятельности (activity) — это определенный тип
работы, выполняемый при разработке ПО, например,
программирование, тестирование, DevOps.
Разные виды деятельности часто требуют разные профессиональные
навыки и выполняются разными специалистами. Например, управление
проектом выполняется менеджером проекта, кодирование —
программистом, тестирование — тестеровщиком. Есть виды
деятельности, которые могут выполняться одними и теми же
специалистами — например, кодирование и проектирование (особенно
в небольшом проекте) часто выполняют одни и те же люди.
В рамках одной фазы может выполняться много различных видов
деятельности. Кроме того, один вид деятельности может выполняться
на разных фазах. В качестве примера рассмотрим тестирование: на
фазе разработки требований нужно анализировать последние на
предмет возможности тестирования, на фазе анализа и проектирования
можно создавать тесты и налаживать тестовое окружение, при
разработке и перед сдачей проекта производить, собственно, само
тестирование. На настоящий момент для сложного программного
обеспечения используются многомерные модели процесса, в которых
отделение фаз от видов деятельности существенно облегчает
управление разработкой ПО.
Виды деятельности, фактически, присутствуют, под разными
Д.В. Кознов
Введение в программную инженерию
23
названиями, в каждом методе разработки ПО. В RUP они называются
рабочими процессами (work flow), в CMM — ключевыми областями
процесса (key process area). Мы будем сохранять традиционные
названия, принятые в том или ином методе, чтобы не создавать
путаницы.
В рамках этого курса мы рассмотрим следующие известные модели
процесса:
• водопадная модель,
• спиральная модель,
• итеративно-инкрементальная модель.
Водопадная модель
Эта модель была предложена в 1970 году Винстоном Ройсом.
Фактически, впервые в процессе разработки ПО были выделены
различные фазы (шаги) разработки и поколеблены примитивные
представления о процессе в виде анализа системы, т.е. создания
математических алгоритмов, и их последующего кодирования. Ройс
работал в области создания аэрокосмических систем, процесс обычно
выглядел как разработка математических алгоритмов, описывающих
движение летательных аппаратов, и последующее их кодирование.
Однако такой процесс оставлял за скобками множество задач,
связанных со сбором требований, проектированием, тестированием и
т.д. Фактически, Ройс написал свою знаменитую статью про
водопадную модель именно для того, чтобы объяснить различным
сторонам, вовлеченным в разработку аэрокосмических систем, что
процесс разработки должен быть организован существенно сложнее,
чем это обстояло на тот момент.
Определение. Водопадная модель является линейной моделью
разработки ПО, в рамках которой проект проходит фиксированные
фазы строго по порядку и только один раз.
В рамках водопадной модели были определены следующие фазы:
разработка системных требований, разработка требований к ПО,
анализ, проектирование, кодирование, тестирование, использование
системы — см. рис. 2.1.
Д.В. Кознов
Введение в программную инженерию
24
Еще одним достоинством этой модели явилось ограничение
возможности возвратов на произвольный шаг назад, например, от
тестирования — к анализу, от разработки — работе над требованиями и
т.д. Отмечалось, что такие возвраты могут катастрофически увеличить
стоимость проекта и сроки его выполнения. Например, если при
тестировании обнаруживаются ошибки проектирования или анализа, то
их исправление часто приводит к полной переделке системы. Этой
моделью допускались возвраты только на предыдущий шаг, например,
от тестирования к кодированию, от кодирования к проектированию и
т.д.
Разработка
системных
требований
Разработка
требований к
ПО
Анализ
Проекти-
рование
Кодирование
Тестирование
Использование
Рис. 2.1. Водопадная модель
Наконец, в рамках этой модели было введено прототипирование, то
есть предлагалось разрабатывать систему дважды, чтобы уменьшить
риски разработки. Первая версия — прототип — позволяет увидеть
основные риски и обосновано принять главные архитектурные
решения. На создание прототипа отводилось до одной трети времени
всей разработки.
Д.В. Кознов
Введение в программную инженерию
25
В 70-80 годах прошлого века эта модель прочно укоренилась в
разработке ПО в силу своей простоты и сходности с моделями
разработки иных, не программных систем. Причём, прототипирование
и ряд других практик, введенных Ройсом для смягчения рисков
водопадной модели, остался в стороне. В дальнейшем, в связи с
развитием программной инженерии и осознанием итеративного
характера процесса разработки ПО эта модель активно критиковалась,
практически, каждым автором соответствующих статей и учебников.
Стало общепринятым мнение, что она не отражает особенностей
разработки ПО. Недостатками водопадной модели являются:
• отождествление фаз и видов деятельности, что влечет потерю
гибкости разработки, в частности, трудности поддержки
итеративного процесса разработки;
• требование полного окончания фазы-деятельности, закрепление
результатов в виде подробного исходного документа
(технического задания, проектной спецификации); однако опыт
разработки ПО показывает, что невозможно полностью завершить
разработку требований, дизайн системы и т.д. — все это
подвержено изменениям; и причины тут не только в том, что
подвижно окружение проекта, но и в том, что заранее не удается
точно определить и сформулировать многие решения, они
проясняются и уточняются лишь впоследствии;
• интеграция всех результатов разработки происходит в конце,
вследствие чего интеграционные проблемы дают о себе знать
слишком поздно;
• пользователи и заказчик не могут ознакомиться с вариантами
системой во время разработки, и видят результат только в самом
конце; тем самым, они не могут повлиять на процесс создания
системы, и поэтому увеличиваются риски непонимания между
разработчиками и пользователями/заказчиком;
• модель неустойчива к сбоям в финансировании проекта или
перераспределению денежных средств, начатая разработка,
фактически, не имеет альтернатив “по ходу дела”.
Однако данная модель продолжает использоваться на практике — для
небольших проектов или при разработке типовых систем, где
итеративность не так востребована. С ее помощью удобно отслеживать
разработку и осуществлять поэтапный контроль за проектом. Эта
Д.В. Кознов
Введение в программную инженерию
26
модель также часто используется в оффшорных проектах с почасовой
оплатой труда1. Водопадная модель вошла в качестве составной части в
другим модели и методологии, например, в MSF.
Спиральная модель
Эта модель была предложена Б. Боемом в 1988 году для преодоления
недостатков водопадной модели, прежде всего, для лучшего управления
рисками. Согласно этой модели, разработка продукта осуществляется по
спирали, каждый виток которой является определенной фазой
разработки. В отличие от водопадной модели в спиральной нет
предопределенного и обязательного набора витков, каждый виток может
стать последним при разработке системы, при его завершении
составляются планы следующего витка. Наконец, виток является именно
фазой, а не видом деятельности, как в водопадной модели, в его рамках
может осуществляться много различных видов деятельности, то есть
модель является двумерной.
Определение. Спиральная модель разработки программного
обеспечения основывается на многократных циклах (витках спирали), на
каждом из которых проводится анализ рисков, прототипирование,
уточнение требований и разработка всё более зрелых версий системы.
Последовательность витков может быть такой: на первом витке
принимается решение о целесообразности создания ПО, на следующем
определяются системные требования, потом осуществляется
проектирование системы и т.д. Витки модели могут иметь и иные
значения.
Каждый виток имеет следующую структуру (сектора) — см. рис. 2.2:
• определение целей, ограничений и альтернатив проекта;
• оценка альтернатив, оценка и разрешение рисков; возможно
использование прототипирования (в том числе создание серии
прототипов), симуляция системы, визуальное моделирование и
анализ спецификаций; фокусировка на самых рисковых частях
проекта;
• разработка и тестирование — здесь возможна водопадная модель
или использование иных моделей и методов разработки ПО;
Д.В. Кознов
Введение в программную инженерию
27
• планирование следующих итераций — анализируются
результаты, планы и ресурсы на последующую разработку,
принимается (или не принимается) решение о новом витке;
анализируется, имеет ли смысл продолжать разрабатывать
систему или нет; разработку можно и приостановить, например,
из-за сбоев в финансировании; спиральная модель позволяет
сделать это корректно.
Отдельная спираль может соответствовать разработке некоторой
программной компоненты или внесению очередных изменений в
продукт. Таким образом, у модели может появиться третье измерение.
Спиральную модель нецелесообразно применять в проектах с
небольшой степенью риска, с ограниченным бюджетом, для небольших
проектов. Кроме того, отсутствие хороших средств прототипирования
может также сделать неудобным использование спиральной модели.
Рис. 2.2. Спиральная модель
Спиральная модель не нашла широкого применения в индустрии и
важна, скорее в историко-методологическом плане: она является
первой итеративной моделью, имеет красивую метафору — спираль
(см. рис 2.3) — и, подобно водопадной модели, использовалась в
дальнейшем при создании других моделей процесса и методологий
разработки ПО.
Следует также отметить, что сегодня мало кто помнит исходную
спиральную модель Б. Боема: как правило, под спиральной моделью
Д.В. Кознов
Введение в программную инженерию
28
сейчас понимают постоянное уточнение требований, постепенное
наращивание функционала и т.д. (см. рис. 2.3).
Рис. 2.3. Современное общепринятое
понимание спиральной модели
Итеративно-инкрементальная модель
В 90-е годы мощные и дорогие суперкомпьютеры, так называемые
Mainframes, уступали место персональным компьютерам (лидерами
здесь оказались компании Apple и IBM). В итоге компьютеры стали
доступны не только крупному бизнесу, госучреждениям и военным
организациям, как это было до этого, но среднему и малому бизнесу, а
также отдельным людям. Соответственно, программное обеспечение
бурно устремилось в новые области, программистов стало существенно
больше, и остро встали вопросы комплексных методологий, которые
позволили бы максимально эффективно создавать системы,
удовлетворяющие нуждам многочисленных новых пользователей.
Развивающиеся с конца 60-х годов средства проектирования
искусственных систем и структурный анализ программного
превратились в объектно-ориентированный анализ и проектирование
ПО ввиду дополнительного обстоятельства — появления объектноориентированных языков программирования, таких как С++, Java и др.
В итоге наметилось движение от единой модели процесса к
комплексной и универсальной методологии разработки.
Ответом на это стала методология RUP (Rational Unified Process),
которая начала развиваться с середины 90-х годов под
предводительством Ф. Крютхена, Г. Буча, А. Якобсона и Д. Рэмбо.
Последние трое были авторами самых известных объектно-
ориентированных методологий и создателями универсального языка
моделирования UML. Однако именно RUP стала полноценной
методологией разработки, существенно опиравшейся на UML,
оставаясь до середины 2000-х, пожалуй, самой известной и
Д.В. Кознов
Введение в программную инженерию
29
востребованной методологией корпоративной создания ПО.
Деятельность по созданию RUP осуществлялась компанией Rational
Software Corp, которая в 2003 году была куплена компанией IBM.
Кроме прочего эта методология была поддержана линейкой средств
разработки ПО, выступая серьёзным маркетинговым средством.
Впоследствии, из-за роста популярности Agile-подхода
использовавшего многое из RUP (итеративность, зачатки DevOpsпрактик и пр.), а таже падения популярности UML, методология RUP
превратилась в методологический фундамент многих универсальных
процессов в рамках отдельных компаний, а также в источник
отдельных архитектурных практик.
Мы выделим из RUP именно модель процесса, оставив в стороне
прочие аспекты этой методологии. Эта модель является первой
итеративно-инкрементальной, соединяя поступательный характер
водопадной модели и циклы спиральной модели, т.е., фактически,
имеет два измерения — виды деятельности и вехи (см. рис. 2.4).
Определение. Итеративно-инкрементальная модель разработки ПО
позволяет создавать программный продукт посредством коротких
циклов (итераций), каждый из которых добавляет функционал системы,
обеспечивая постепенность разработки, раннее тестирование и
валидацию системы, а также адаптацию требований.
Рис. 2.4 Двумерная модель процесса
Определение. Вид деятельности — это определенный вид
профессиональной активности в программном проекте: разработка
(кодирование), тестирование, управление проектом и т.д.
Важно точно определить, какие виды деятельности будут в проекте, и
Д.В. Кознов
Введение в программную инженерию
30
обеспечить их соответствующими работниками. Как мы увидим ниже,
выделяется значительное число разных видов деятельности, и не все
они могут быть востребованы для конкретного проекта. Также
возможно совмещение разных видов деятельности в рамках одним
членом команды — например, управление проектом и тестирование,
управление проектом и проектирование, проектирование и разработка.
Планирование объёма того или иного вида деятельности в проекте
является важной задачей, и это влияет на бюджет проекта, а также на
его успешность. Например, недостаток или отсутствие проектирования
могут оказаться фатальными для сложного проекта, отсутствие
тестирования (что по факту означает, что оно выполняется лишь
разработчиками) может создать много проблем при сдаче и
эксплуатации системы.
Определение. Фаза (этап) — это некоторый объём деятельности в
проекте, который должен быть завершен к определённому сроку,
предъявлен и принят заказчиком.
Фазы удобны при взаимодействии с заказчиком, в частности, для
поэтапой выплаты деньг за проект. Общеизвестно, что существуют две
крайности:
• разработчикам удобно получить все деньги за создаваемую
систему сразу, а потом спокойно её спокойно разрабатывать;
• заказчику комфортно заплатить в самом конце, когда он увидит,
что получилось, примет систему.
Очевидно, что в рамках этих крайностях то, что удобно одной стороне,
крайне неудобно для другой — платить целиком за несделанную
работу для заказчика рискованно и дискомфортно, а работать без денег
для разработчиков тяжело и ненадёжно. Соответственно, оплата по
фазам (этапам) а также некоторый аванс — это является приемлемым
компромиссом. При этом по окончанию этапа заказчик должен увидеть
некоторый промежуточный результат и согласиться с ним. Это снимает
риски того, что если он видит систему в первый раз лишь по
завершению её разработки, то не может внести коррективы. Кроме
того, в этом случае может оказаться, что у разработчиков и заказчика
сложилось разное представление о том, какой должна быть система, и
окончание проекта является очень неподходящим временем для
выявление этого факта: что-либо сделать конструктивное в этом случае
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]