Д. А. Градусов а. В. Шутов теоретические вопросы разработки программного обеспечения учебное пособие

40 
Эксплуатация и поддержка 
После того, как продукт был протестирован и развернут на 
сервере заказчика, начинается следующая фаза жизненного цикла 
разработки 
программного 
обеспечения, 
которая 
называется 
сопровождением или технической поддержкой ПО. В целом, 
сопровождение подразумевает под собой исправление мелких багов, 
которые обнаруживаются на этом этапе. Тем не менее, вполне 
возможно, что вам придется вносить некоторые изменения в 
созданное программное обеспечение, несмотря на все усилия, 
приложенные вами на предыдущих этапах. Заказчик может решить 
внести изменения в функциональность разработанного продукта. 
Следовательно, вам придется собирать, описывать и обсуждать новые 
требования с заказчиком, чтобы внести в продукт необходимые 
изменения. В данном случае, вам предстоит работа с новым 
каскадным проектом, и все вышеописанные шаги придется повторять 
с начала. 
Преимущества модели 
1.
Предельная 
детализация 
каждого 
этапа 
работы, 
сопровождающаяся документированием. 
2.
Требования максимально внятно и четко изложены, не могут 
меняться в процессе работы. 
3.
Возможность заранее знать сколько денежных и временных 
ресурсов будет затрачено на проект. 
4.
Легкость понимания методологии. 
5.
Простота контроля выполнения задачи. 
6.
При необходимости легко передать проект другой команде. 
Недостатки модели 
1.
Главный недостаток каскадной модели заключается в том, что 
ошибки и недоработки на любом из этапов проявляются, как правило, 
на последующих этапах работ, что приводит к необходимости 
возврата назад. 

41 
2.
Дополнительные 
временные 
затраты 
на 
ведение 
документации. 
3.
Необходимость дополнительных квалифицированных кадров 
для создания технического задания. 
4.
Высокие временные и денежные затраты. 
5.
Позднее тестирование. 
6.
Сложность распараллеливания работ. 
7.
Сложность управления проектом. 
8.
Высокий уровень риска и ненадежность инвестиций (возврат 
на предыдущие стадии может быть связан не только с ошибками, но и 
с изменениями, произошедшими в предметной области или в 
требованиях заказчика во время разработки. Причем возврат проекта 
на доработку вследствие этих причин не гарантирует, что предметная 
область снова не изменится к тому моменту, когда будет готова 
следующая версия проекта. Фактически это означает, что существует 
вероятность того, что процесс разработки «зациклится» и система 
никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут 
постоянно расти, а сроки сдачи готового продукта постоянно 
откладываться). 
Каскадная модель демонстрирует классический подход к 
разработке различных систем в различных прикладных областях. Для 
разработки информационных систем данная модель широко 
использовалась в 70-х и первой половине 80-х годов. Каскадная 
модель предусматривает последовательную организацию процессов. 
Причем переход к следующему процессу происходит только после 
того, как полностью завершены все работы на предыдущем. Каждый 
процесс завершается выпуском полного комплекта документации, 
достаточной для того, чтобы работа могла быть продолжена другой 
командой разработчиков. 
На практике водопадная модель часто не оправдывает 
ожиданий, поскольку игнорирует динамические изменения. Так, 

42 
после тестирования очень сложно откатить процесс и заложить 
функции, не учтенные на стадии разработки. Каскадная модель 
неэффективна ещё и потому, что предполагает временные простои 
сотрудников в рамках одного проекта. Тестирование проводится 
только в конце разработки, хотя проблемы, найденные на этом этапе 
— это дорогостоящие исправления. 
3.3 Итерационная модель 
Рис. 3.2 - Итерационная модель 
Не все модели жизненного цикла последовательны. Существуют 
также итеративные (или инкрементальные) модели, в которых 
используется другой подход. Вместо одной продолжительной 
последовательности действий здесь весь жизненный цикл продукта 
разбит на ряд отдельных мини-циклов (рис. 3.2). Причем каждый из 
них состоит из все тех же базовых стадий модели жизненного цикла. 
Эти мини-циклы называются итерациями. В каждой из итераций 
происходит разработка отдельного компонента системы, после чего 
этот компонент добавляется к уже ранее разработанному 
функционалу. 

43 
Итеративная модель не предполагает полного объема 
требований для начала работ над продуктом. Разработка программы 
может начинаться с требований к части функционала, которые могут 
впоследствии дополняться и изменяться. Процесс повторяется, 
обеспечивая создание новой версии продукта для каждого цикла. 
В несколько упрощенном виде, итеративная модель состоит из 
четырех основных стадий, которые повторяются в каждой из 
итераций (plan-do-check-act): 
– определение и анализ требований; 
– дизайн и проектирование – согласно требованиями. Причем 
дизайн может как разрабатываться отдельно для данной 
функциональности, так и дополнять уже существующий; 
– разработка и тестирование – кодирование, интеграция и 
тестирование нового компонента; 
– фаза ревью – оценка, пересмотр текущих требований и 
предложения дополнений к ним. 
По результатам каждой итерации принимается решение – будут 
ли использованы ее результаты для дополнения существующей 
функциональности в качестве входной точки для начала следующей 
итерации (т.н. инкрементальное прототипирование). В конечном 
итоге, достигается точка, в которой все требования были воплощены 
в продукте – происходит релиз. 
В математических терминах, итеративная модель представляет 
реализацию
 
методики последовательной аппроксимации – то есть, 
постепенное приближение к образу готового продукта. 
Ключ к успешному использованию этой модели – строгая 
валидация требований и тщательная верификация разрабатываемой 
функциональности в каждой из итераций. 
Основные стадии процесса разработки в итеративной модели 
фактически повторяют модель водопада. В каждой итерации 

44 
создается программное обеспечение, требующее тестирования на всех 
уровнях. 
Плюсы и минусы итеративной модели: 
+ раннее создание работающего ПО; 
+ гибкость – готовность к изменению требований на любом 
этапе разработки; 
+ каждая итерация – маленький этап, для которого тестирование 
и анализ рисков обеспечить проще, чем для всего жизненного цикла 
продукта. 
— каждая фаза – самостоятельна, отдельные итерации не 
накладываются; 
— могут возникнуть проблемы с реализацией общей 
архитектуры системы, поскольку не все требования известны к 
началу проектирования. 
Когда использовать итеративную модель: 
— для крупных проектов; 
— когда известны, по крайней мере, ключевые требования; 
— когда требования к проекту могут меняться в процессе 
разработки. 
3.4 Спиральная модель 
Спиральная модель (рис. 3.3), которая была предложена Барри 
Боэмом в 1986 году, стала прорывом в разработке ПО, так как в ней 
сочетаются итеративность и этапность. 

45 
Рис. 3.3 – Схема работы спиральной модели 
Модель спирального жизненного цикла — это сложная 
организация жизненного цикла ПО, которая фокусируется на раннем 
выявлении и уменьшении проектных рисков.
Боэм сформулирован десять наиболее распространенных 
рисков: 
1.
Дефицит специалистов. 
2.
Нереалистичные сроки и бюджет. 
3.
Реализация не соответствует функциональности. 
4.
Разработка неправильного пользовательского интерфейса. 
5.
Ненужная оптимизация. 
6.
Непрекращающийся поток изменений. 
7.
Нехватка 
информации 
о 
внешних 
компонентах, 
определяющих окружение системы или вовлечённых в интеграцию. 
8.
Недостатки в работах, выполняемых внешними (по 
отношению к проекту) ресурсами. 
9.
Недостаточная производительность получаемой системы. 
10.
Разрыв между квалификацией специалистов и требованиями 
проекта. 
Разработка начинается в небольшом масштабе, решаются 
локальные задачи, оцениваются риски и пути их уменьшения. 

46 
Следующий шаг охватывает более комплексные задачи — 
следующий виток спирали. 
Каждый виток разбит на 4 сектора: 
1.
Определение целей. 
2.
Оценка и разрешение рисков. 
3.
Разработка и тестирование. 
4.
Планирование следующей итерации. 
На каждом витке спирали могут применяться разные модели 
процесса разработки ПО. В конечном итоге на выходе получается 
готовый продукт. 
Главной задачей данной методологии является как можно 
быстрее показать пользователям системы работоспособный продукт, 
тем самым активизируя процесс уточнения и дополнения требований.
Основной проблема спирального цикла является определение 
момента перехода на следующий этап. Для её решения необходимо 
ввести временные ограничения на каждый из этапов жизненного 
цикла.
Положительные стороны спиральной модели: 
1.
Улучшенный анализ рисков; 
2.
хорошая документация процесса разработки; 
3.
гибкость – возможность внесения изменений и добавления 
новой функциональности даже на относительно поздних этапах; 
4.
раннее создание рабочих прототипов. 
Отрицательные стороны: 
1.
достаточно высокая цена использования; 
2.
привлечение высококлассных специалистов; 
3.
успех процесса в основном зависит от стадии анализа рисков. 
Спиральную модель нужно использовать, когда важен анализ 
рисков и затрат; есть крупные долгосрочные проекты без четких 
требований и при разработке новой линейки продуктов. 

47 
3.5 Agile 
Agile — метод гибкой разработки программного обеспечения, 
предполагающий 
большое 
количество 
итераций. 
Основным 
документом данной методологии является «Манифест о гибкой 
разработке программного обеспечения Agile».
Манифест Agile включает в себя 4 базовых идеи и 12 принципов 
эффективного управления проектами. 
Идеи Agile: 
1.
Люди и их взаимодействие важнее, чем процессы и 
инструменты.
2.
Рабочее ПО важнее, чем документация. 
3.
Клиенты и сотрудничество с ними важнее, чем контракт и 
обсуждение условий. 
4.
Готовность 
к 
внесению 
изменений 
важнее, 
чем 
первоначальный план. 
Принципы Agile: 
1.
Удовлетворять клиентов, заблаговременно и постоянно 
поставляя ПО. 
2.
Изменять требования к конечному продукту в течение всего 
цикла его разработки. 
3.
Поставлять рабочее ПО как можно чаще. 
4.
Поддерживать сотрудничество между разработчиками и 
заказчиком в течение всего цикла разработки. 
5.
Поддерживать и мотивировать всех, кто вовлечен в проект 
(если команда мотивирована, то она лучше справляется со своими 
задачами). 
6.
Обеспечивать непосредственное взаимодействие между 
разработчиками. 
7.
Измерять прогресс только посредством рабочего ПО (клиенты 
должны получать только функциональное и рабочее ПО). 

48 
8.
Поддерживать непрерывный темп работы. 
9.
Уделять внимание дизайну и техническим деталям. 
10.
Стараться сделать рабочий процесс максимально простым, а 
ПО – простым и понятным. 
11.
Позволять членам команды самостоятельно принимать 
решения (если разработчики могут сами принимать решения, 
самоорганизовываться и общаться с другими членами коллектива, 
обмениваясь с ними идеями, вероятность создания качественного 
продукта существенно возрастает). 
12.
Постоянно адаптироваться к меняющейся среде (благодаря 
этому конечный продукт будет более конкурентоспособен). 
Как и у любой другой методологии, у Agile есть свои 
положительные и негативные стороны (рис. 3.4). Начнем с 
положительных: 
1.
При использовании методологии Agile происходит гибкое 
управление проектом, благодаря этому учитывается больше 
требований заказчика и потребителей. 
2.
Минимизация дефектов конечного продукта, так как 
происходит тщательная проверка качества после каждого спринта.
3.
Agile быстро запускается и легко реагирует на изменения. 
4.
Возможность 
команде 
разработчиков 
и 
клиентов 
поддерживать постоянную связь в реальном времени.
Рис. 3.4 – Разработка по методологии Agile 

49 
Также не стоит забывать и о недостатках: 
1.
Постоянная обратная связь может приводить к тому, что все 
время будет переноситься. 
2.
Адаптация под изменяющиеся условия проекта проектную 
документацию, так как при ненадлежащем информировании команды 
документы с функциональными требованиями или архитектурой 
могут оказаться неактуальными на текущий момент времени. 
3.
Необходимость в частых встречах, так как происходит 
постоянное отвлечение членов команды от решаемых задач. 
4.
Необходимость в постоянном присутствии клиента. 
5.
Невозможность выстраивать долгосрочные планы. 
6.
Потребность в мотивированных и высококвалифицированных 
специалистах. 
3.6 Методология Scrum 
Главное отличие Scrum от других методов системы Agile - 
основной упор делается на качественный контроль рабочего 
процесса. Scrum заключается в том, что разработка проекта 

жүктеу/скачать 2,75 Mb.

Достарыңызбен бөлісу: