Жизненный цикл программного обеспечения: понятие, стандарты, процессы. Жизненный цикл программы
Рассмотрим жизненный цикл программного обеспечения (ПО), т.е. процесс его создания и применения от начала до конца. Жизненный цикл начинается с момента осознания появления данного ПО и заканчивается моментом его полного выхода из употребления. Этот процесс состоит из нескольких стадий: определения требований и спецификаций, проектирования, программирования и сопровождения.
Первая стадия - определение требований и спецификаций, может быть названа стадией системного анализа. На ней устанавливаются общие требования ПО: по надежности, технологичности, правильности, универсальности, эффективности, информационной согласованности и т.п.
Они дополняются требованиями заказчика, включающими пространственно-временными ограничениями, необходимые функции и возможности, режимы функционирования, требования точности и надежности и т.д., то есть вырабатывается описание системы с точки зрения пользователя.
При определении спецификаций (набора требований и параметров, которыми должно удовлетворять ПО) производится точное описание функций ПО, разрабатываются и утверждаются входные и промежуточные языки, форма выходной информации для каждой из подсистем, описывается возможное взаимодействие с другими программными комплексами, специфицируются средства расширения и модификации ПО, разрабатываются интерфейсы обслуживающих и основных подсистем, решаются вопросы базы данных, утверждаются основные алгоритмы.
Итогом выполнения этого этапа являются эксплуатационные и функциональные спецификации, содержащие конкретное описание ПО. Разработка спецификаций требует тщательной работы системных аналитиков, постоянно контактирующих с заказчиками, которые в большинстве случаев не способны сформулировать четкие и реальные требования.
Эксплуатационные спецификации содержат сведения о быстродействии ПО, затратах памяти, требуемых технических средствах, надежности и т.д.
Функциональные спецификации определяют функции, которые должно выполнять ПО, т.е. в них определяется, что надо делать системе, а не то, как это делать.
Спецификации должны быть полными, точными и ясными. Полнота исключает необходимость получения разработчиками ПО в процессе их работы от заказчиков иных сведений, кроме содержащихся в спецификациях. Точность не позволяет различных толкований. Ясность подразумевает легкость понимания как заказчиком, так и разработчиком при однозначном толковании.
Значение спецификаций:
1. Спецификации являются заданием на разработку ПО и их выполнение - закон для разработчика.
2. Спецификации используются для проверки готовности ПО.
3. Спецификации являются неотъемлемой частью программной документации, облегчают сопровождение и модификацию ПО,
Второй стадией является проектирование ПО. На этом этапе:
1. Формируется структура ПО и разрабатываются алгоритмы, задаваемые спецификациями.
2. Устанавливается состав модулей с разделением их на иерархические уровни на основе изучения схем алгоритмов.
3. Выбирается структура информационных массивов.
4. Фиксируются межмодульные интерфейсы.
Цель этапа - иерархическое разбиение сложных задач создания ПО на подзадачи меньшей сложности. Результатом работы на этом этапе являются спецификации на отдельные модули, дальнейшая декомпозиция которых нецелесообразна.
Третья стадия - программирование . На данном этапе произвоится программирование модулей. проектные решение, полученные на предыдущей стадии, реализуются в виде программ. Разрабатываются отдельные блоки и подключаются к создаваемой системе. Одна из задач - обоснованный выбор языков программирования. На этой же стадии решаются все вопросы, связанные с особенностями типа ЭВМ.
Четвертая стадия - отладка ПО заключается в проверке всех требований, всех структурных элементов системы на таком количестве всевозможных комбинаций данных, какое только позволяют здравый смысл и бюджет. Этап предполагает выявление в программах ошибок, проверку работоспособности ПО, а также соответствие спецификациям.
Пятая стадия - сопровождение, т.е. процесс исправления ошибок, координация всех элементов системы в соответствии с требованиями пользователя, внесения всех необходимых ему исправлений и изменений.
Перед началом разработки ПО следует провести маркетинг.
Маркетинг предназначен для изучения требований к создаваемому программному продукту (технических, программных, пользовательских). Изучаются также существующие аналоги и продукты-конкуренты. Оцениваются необходимые для разработки материальные, трудовые и финансовые ресурсы, а также устанавливаются примерные сроки разработки. Стадии разработки ПО описаны ГОСТ 19.102-77. В соответствии с ним приведем названия и краткое описание каждого этапа (см. табл. 1). Настоящий стандарт устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Таблица 1
Стадии разработки, этапы и содержание работ по созданию ПО
Жизненный цикл программного обеспечения
Одним из базовых понятий методологии проектирования ПО является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ним документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:
· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
· вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Модели жизненного цикла ПО
Модель жизненного цикла - структура, определяющая последовательность выполнения и взаимосвязи стадий и этапов, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ПО и специфики условий, в которых последняя создается и функционирует. Основные модели ЖЦ следующие.
1. Каскадная модель (до 70-х годов XX в) определяет последовательный переход на следующий этап после завершения предыдущего.
Для этой модели характерна автоматизация отдельных несвязанных задач, не требующая информационной интеграции и совместимости, программного, технического и организационного сопряжения.
Достоинство : хорошие показатели по срокам разработки и надежности при решении отдельных задач.
Недостаток : неприменимость к большим и сложным проектам из-за изменчивости требований к системе в течение длительного проектирования.
2. Итерационная модель (70-80-е годы XX в.) соответствует технологии проектирования «снизу - вверх». Допускает итерационные возвраты на предыдущие этапы после выполнения очередного этапа;
Модель предусматривает обобщение полученных проектных решений отдельных задач в общесистемные решения. При этом возникает потребность в пересмотре ранее сформулированных требований.
Достоинство: возможность оперативно вносить коррективы в проект.
Недостаток: при большом числе итераций растет время проектирования, возникают расхождения в проектных решениях и документации, запутывается функциональная и системная архитектура созданной ПО. Необходимость в перепроектировании старой или создании новой системы может возникнуть сразу после этапа внедрения или эксплуатации.
3. Спиральная модель (80-90-е годы XX в.) соответствует технологии проектирования «сверху - вниз». Предполагает использование программного прототипа, допускающего программное расширение. Проект системы циклически повторяет путь от детализации требований к детализации программного кода.
При проектировании архитектуры системы сначала определяется состав функциональных подсистем и решаются общесистемные вопросы (организация интегрированной базы данных, технология сбора, передачи и накопления информации). Затем формулируются отдельные задачи и разрабатывается технология их решения.
При программировании сначала разрабатываются головные программные модули, а затем - модули, исполняющие отдельные функции. Сначала обеспечивается взаимодействие модулей между собой и с базой данных, а затем - реализация алгоритмов.
Достоинства:
1. сокращение число итераций и, следовательно, число ошибок и несоответствий, которые необходимо исправлять;
2. сокращение сроков проектирования;
3. упрощение создания проектной документации.
Недостаток: высокие требования к качеству общесистемного репозитория (общей базы проектных данных).
Спиральная модель лежит в основе технологии быстрой разработки приложений или RAD-технологии (rapid application development), которая предполагает активное участие конечных пользователей будущей системы в процессе ее создания. Основные стадии информационного инжиниринга следующие:
· Анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области.
· Проектирование. Пользователи под руководством разработчиков принимают участие в техническом проектировании.
· Конструирование. Разработчики проектируют рабочую версию ПО с использованием языков 4-го поколения;
· Внедрение. Разработчики обучают пользователей работе в среде новой ПО.
Стандарты жизненного цикла ПО
- ГОСТ 34.601-90
- ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)
Стандарт ГОСТ 34 .601-90
Итерационная модель
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID ), получившей также от Т. Гилба в 70-е гг. название эволюционной модели . Также эту модель называют итеративной моделью и инкрементальной моделью .
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации - получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение - инкремент - к его возможностям, которые, следовательно, развиваются эволюционно . Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения .
По выражению Т. Гилба, «эволюция - прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте» .
Подход IID имеет и свои отрицательные стороны, которые, по сути, - обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже» .
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP , MSF , ).
Спиральная модель
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
- риск превышения сроков и стоимости проекта;
- необходимость выполнения ещё одной итерации;
- степень полноты и точности понимания требований к системе;
- целесообразность прекращения проекта.
Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID .
Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
- Дефицит специалистов.
- Нереалистичные сроки и бюджет.
- Реализация несоответствующей функциональности.
- Разработка неправильного пользовательского интерфейса.
- Перфекционизм, ненужная оптимизация и оттачивание деталей.
- Непрекращающийся поток изменений.
- Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
- Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
- Недостаточная производительность получаемой системы.
- Разрыв в квалификации специалистов разных областей.
В сегодняшней спиральной модели определён следующий общий набор контрольных точек :
- Concept of Operations (COO) - концепция (использования) системы;
- Life Cycle Objectives (LCO) - цели и содержание жизненного цикла;
- Life Cycle Architecture (LCA) - архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
- Initial Operational Capability (IOC) - первая версия создаваемого продукта, пригодная для опытной эксплуатации;
- Final Operational Capability (FOC) –- готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.
Методологии разработки ПО
- Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
- Экстремальное программирование (англ. Extreme Programming, XP ). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.
- ЕСПД - комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.
Литература
- Братищенко В.В. Проектирование информационных систем. - Иркутск: Изд-во БГУЭП, 2004. - 84 с.
- Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М .: Финансы и статистика, 2000.
- Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. - М .: Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
- Мишенин А.И. Теория экономических информационных систем. - М .: Финансы и статистика, 2000. - 240 с.
Примечания
Wikimedia Foundation . 2010 .
Смотреть что такое "Жизненный цикл программного обеспечения" в других словарях:
Период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы: 1 возникновение и исследование идеи; 2 анализ требований и проектирование; 3 программирование; 4 тестирование и отладка; 5 ввод программы в действие; 6… … Финансовый словарь
жизненный цикл программного обеспечения - … Справочник технического переводчика
жизненный цикл программного обеспечения - 3.7 жизненный цикл программного обеспечения; жизненный цикл ПО (software lifecycle): Последовательность следующих друг за другом процессов создания и использования программного обеспечения программируемой связанной с безопасностью здания или… …
жизненный цикл программного обеспечения - Последовательность следующих друг за другом процессов создания и использования программного обеспечения, происходящих в течение интервала времени, который начинается с разработки общей концепции программного обеспечения и заканчивается когда… … Комплексное обеспечение безопасности и антитеррористической защищенности зданий и сооружений
Цикл программного обеспечения жизненный - Жизненный цикл программного обеспечения (software lifecycle): период времени, включающий в себя стадии: разработки требований к программному обеспечению, разработки программного обеспечения, кодирования, тестирования, интеграции, установки, а… … Официальная терминология
жизненный цикл - 4.16 жизненный цикл (life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения. Источник … Словарь-справочник терминов нормативно-технической документации
Это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из… … Википедия
Жизненный цикл информационной системы это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в… … Википедия, О. В. Казарин. В книге рассмотрены теоретические и прикладные аспекты проблемы зашиты программного обеспечения от различного рода злоумышленных действий. Особое внимание уделено моделям и методам создания…
Жизненный цикл программы.
Жизненный цикл программного обеспечения (ПО) - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл - процесс построения и развития ПО.
Этапы жизненного цикла :
2. Проектирование
3. Реализация
4. Сборка, тестирование, испытание
5. Внедрение (выпуск)
6. Сопровождение
Различают 2 случая производства ПО: 1) ПО делается для конкретного заказчика. В этом случае нужно прикладную задачу преврашать в программистскую. Нужно понять как функционирует та среда, которую нужно автоматизировать (анализ бизнес-процессов). В результате появляется документация-спецификация требования, где указаны какие именно задачи д.б. решены и при каких условиях. Эту работу выполняет системный аналитик (аналитик бизнес-процессов).
2) ПО разрабатывается для рынка. Нужно проводить маркетинговые исследования и найти какого продукта на рынке нет. Это связано с большим риском. Цель – разработка спецификации требований.
Проектирование
Цель – определение общей структуры (архитектуры) ПО. Результат – спецификация ПО. Эту работу выполняет системный программист.
Реализация
Написание программного кода. Реализация включает и разработку, и тестирование, и документацию.
Сборка, тестирование, испытние
Сборка всего, что сделано разными программистами. Тестирование всего программного комплекса. Отладка – поиск и устранение причин ошибок. Испытание – уточнение технических характеристик. В результате – гарантия работоспособносит программы.
Внедрение (выпуск)
Внедрение – когда работают на одного заказчика. Включает постановку программы у заказчика, обучение заказчика, консультации, устранение ошибок и явных недостатков. Должно произойти отчуждение ПО – пользователь может работать с ПО без участия автора.
Выпуск – когда ПО разрабатывается на рынок. Начинается с этапа бета-тестирования. Соотв. версия – бета-версияю. Альфа-тестирование – тестирование людьми из той же организации, не участвовавших в разработке программ. Бета-тестирование – изготовление нескольких экземпляров ПО и отправка потенциальным заказчикам. Цель – еще раз проверить разработку ПО.
Если на рынок выпускается принципиально новый ПО, то возможно несколько бета-тестирований. После бета-тестирование – выпуск коммерческой версии.
Сопровождение
Устранение замеченных в ходе эксплуатации ошибок. Внесение непринципиальных усовершенствований. Накопление предложений для разработки следующей версии.
Модели жизненного цикла
1. Waterfall («водопад», каскадная модель)
2. Прототипирование
Сначала разрабатывается не сам программный продукт, а его прототип, содержащий решение главных проблем, стоящих перед разработчиками. После успешного завершения разработки прототипа по тем же принципам разрабатывается и настоящий программный продукт. Прототип позволяет лучше понимать требования к разрабатываемой программе. Используя прототип заказчик также может точнее сформулировать свои требования. Разработчик имеет возможность с помощью прототипа предъявить заказчику предварительные результаты своей работы.
3. Итерационная модель
Задача разделяется на подзадачи и определяется очередность их реализации т.о., чтобы каждая следующая подзадачи расширяла возможности ПО. Успех существенно зависит от того сколь удачно разделены задачи на подзадачи и как выбрана очередность. Преимущества: 1) возможность активного участия заказчика в разработке, он имеет возможность уточнить свои требования в ходе разработки; 2) возможность тестирования вновь разрабатываемых частей совместно с ранее разработанными, это уменьшит затраты на комплексную отладку; 3) во время разработки можно начинать внедрение по частям.
Следует начать с определения, Жизненный цикл программного обеспечения (Software Life Cycle Model) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.
Модели Жизненного цикла программного обеспечения
Жизненный цикл можно представить в виде моделей. В настоящее время наиболее распространенными являются: каскадная , инкрементная (поэтапная модель с промежуточным контролем ) и спиральная модели жизненного цикла.
Каскадная модель
Каскадная модель (англ . waterfall model ) — модель процесса разработки программного обеспечения, жизненный цикл которой выглядит как поток, последовательно проходящий фазы анализа требований, проектирования. реализации, тестирования, интеграции и поддержки.
Процесс разработки реализуется с помощью упорядоченной последовательности независимых шагов. Модель предусматривает, что каждый последующий шаг начинается после полного завершения выполнения предыдущего шага. На всех шагах модели выполняются вспомогательные и организационные процессы и работы, включающие управление проектом, оценку и управление качеством, верификацию и аттестацию, менеджмент конфигурации, разработку документации. В результате завершения шагов формируются промежуточные продукты, которые не могут изменяться на последующих шагах.
Жизненный цикл традиционно разделяют на следующие основные этапы :
- Анализ требований,
- Проектирование,
- Кодирование (программирование),
- Тестирование и отладка,
- Эксплуатация и сопровождение.
Достоинства модели:
- стабильность требований в течение всего жизненного цикла разработки;
- на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
- определенность и понятность шагов модели и простота её применения;
- выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие ресурсы (денежные. материальные и людские).
Недостатки модели:
- сложность чёткого формулирования требований и невозможность их динамического изменения на протяжении пока идет полный жизненный цикл;
- низкая гибкость в управлении проектом;
- последовательность линейной структуры процесса разработки, в результате возврат к предыдущим шагам для решения возникающих проблем приводит к увеличению затрат и нарушению графика работ;
- непригодность промежуточного продукта для использования;
- невозможность гибкого моделирования уникальных систем;
- позднее обнаружение проблем, связанных со сборкой, в связи с одновременной интеграцией всех результатов в конце разработки;
- недостаточное участие пользователя в создании системы — в самом начале (при разработке требований) и в конце (во время приёмочных испытаний);
- пользователи не могут убедиться в качестве разрабатываемого продукта до окончания всего процесса разработки. Они не имеют возможности оценить качество, т.к.нельзя увидеть готовый продукт разработки;
- у пользователя нет возможности постепенно привыкнуть к системе. Процесс обучения происходит в конце жизненного цикла, когда ПО уже запущено в эксплуатацию;
- каждая фаза является предпосылкой для выполнения последующих действий, что превращает такой метод в рискованный выбор для систем, не имеющих аналогов, т.к. он не поддается гибкому моделированию.
Реализовать Каскадную модель жизненного цикла затруднительно ввиду сложности разработки ПС без возвратов к предыдущим шагам и изменения их результатов для устранения возникающих проблем.
Область применения Каскадной модели
Ограничение области применения каскадной модели определяется её недостатками. Её использование наиболее эффективно в следующих случаях:
- при разработке проектов с четкими, неизменяемыми в течение жизненного цикла требованиями, понятными реализацией и техническими методиками;
- при разработке проекта, ориентированного на построение системы или продукта такого же типа, как уже разрабатывались разработчиками ранее;
- при разработке проекта, связанного с созданием и выпуском новой версии уже существующего продукта или системы;
- при разработке проекта, связанного с переносом уже существующего продукта или системы на новую платформу;
- при выполнении больших проектов, в которых задействовано несколько больших команд разработчиков.
Инкрементная модель
(поэтапная модель с промежуточным контролем)
Инкрементная модель (англ . increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.
Разработка программного обеспечения ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах, время жизни каждого из этапов растягивается на весь период разработки.
В начале работы над проектом определяются все основные требования к системе, подразделяются на более и менее важные. После чего выполняется разработка системы по принципу приращений, так, чтобы разработчик мог использовать данные, полученные в ходе разработки ПО. Каждый инкремент должен добавлять системе определенную функциональность. При этом выпуск начинают с компонентов с наивысшим приоритетом. Когда части системы определены, берут первую часть и начинают её детализировать, используя для этого наиболее подходящий процесс. В то же время можно уточнять требования и для других частей, которые в текущей совокупности требований данной работы были заморожены. Если есть необходимость, можно вернуться позже к этой части. Если часть готова, она поставляется клиенту, который может использовать её в работе. Это позволит клиенту уточнить требования для следующих компонентов. Затем занимаются разработкой следующей части системы. Ключевые этапы этого процесса — простая реализация подмножества требований к программе и совершенствование модели в серии последовательных релизов до тех пор, пока не будет реализовано ПО во всей полноте.
Жизненный цикл данной модели характерен при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат. Разработка версиями ведется в силу разного рода причин:
- отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;
- отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;
- требований поэтапного внедрения и освоения продукта конечными пользователями. Внедрение всей системы сразу может вызвать у её пользователей неприятие и только “затормозить” процесс перехода на новые технологии. Образно говоря, они могут просто “не переварить большой кусок, поэтому его надо измельчить и давать по частям”.
Достоинства и недостатки этой модели (стратегии) такие же, как и у каскадной (классической модели жизненного цикла). Но в отличие от классической стратегии заказчик может раньше увидеть результаты. Уже по результатам разработки и внедрения первой версии он может незначительно изменить требования к разработке, отказаться от нее или предложить разработку более совершенного продукта с заключением нового договора.
Достоинства:
- затраты, которые получаются в связи с изменением требований пользователей, уменьшаются, повторный анализ и совокупность документации значительно сокращаются по сравнению с каскадной моделью;
- легче получить отзывы от клиента о проделанной работе — клиенты могут озвучить свои комментарии в отношении готовых частей и могут видеть, что уже сделано. Т.к. первые части системы являются прототипом системы в целом.
- у клиента есть возможность быстро получить и освоить программное обеспечение — клиенты могут получить реальные преимущества от системы раньше, чем это было бы возможно с каскадной моделью.
Недостатки модели:
- менеджеры должны постоянно измерять прогресс процесса. в случае быстрой разработки не стоит создавать документы для каждого минимального изменения версии;
- структура системы имеет тенденцию к ухудшению при добавлении новых компонентов — постоянные изменения нарушают структуру системы. Чтобы избежать этого требуется дополнительное время и деньги на рефакторинг. Плохая структура делает программное обеспечение сложным и дорогостоящим для последующих изменений. А прерванный Жизненный цикл ПО приводит еще к большим потерям.
Схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к ПО. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ПО зафиксированы в виде технического задания на всё время её создания. Таким образом, пользователи зачастую получаю ПП, не удовлетворяющий их реальным потребностям.
Спиральная модель
Спиральная модель: Жизненный цикл — на каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки — анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов.
Данная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипировнаие с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.
На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации.
Жизненный цикл на каждом витке спирали — могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели . Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Достоинства модели:
- позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;
- допускает изменение требований при разработке программного обеспечения, что характерно для большинства разработок, в том числе и типовых;
- в модели предусмотрена возможность гибкого проектирования, поскольку в ней воплощены преимущества каскадной модели, и в то же время разрешены итерации по всем фазам этой же модели;
- позволяет получить более надежную и устойчивую систему. По мере развития программного обеспечения ошибки и слабые места обнаруживаются и исправляются на каждой итерации;
- эта модель разрешает пользователям активно принимать участие при планировании, анализе рисков, разработке, а также при выполнении оценочных действий;
- уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта;
- обратная связь по направлению от пользователей к разработчикам выполняется с высокой частотой и на ранних этапах модели, что обеспечивает создание нужного продукта высокого качества.
Недостатки модели:
- если проект имеет низкую степень риска или небольшие размеры, модель может оказаться дорогостоящей. Оценка рисков после прохождения каждой спирали связана с большими затратами;
- Жизненный цикл модели имеет усложненную структуру, поэтому может быть затруднено её применение разработчиками, менеджерами и заказчиками;
- спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл, что отдаляет окончание работы над проектом;
- большое количество промежуточных циклов может привести к необходимости в обработке дополнительной документации;
- использование модели может оказаться дорогостоящим и даже недопустимым по средствам, т.к. время. затраченное на планирование, повторное определение целей, выполнение анализа рисков и прототипирование, может быть чрезмерным;
- могут возникнуть затруднения при определении целей и стадий, указывающих на готовность продолжать процесс разработки на следующей и
Основная проблема спирального цикла — определение момента перехода на следующий этап. Для её решения вводятся временные ограничения на каждый из этапов жизненного цикла и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков.
Область применения спиральной модели
Применение спиральной модели целесообразно в следующих случаях:
- при разработке проектов, использующих новые технологии;
- при разработке новой серии продуктов или систем;
- при разработке проектов с ожидаемыми существенными изменениями или дополнениями требований;
- для выполнения долгосрочных проектов;
- при разработке проектов, требующих демонстрации качества и версий системы или продукта через короткий период времени;
- при разработке проектов. для которых необходим подсчет затрат, связанных с оценкой и разрешением рисков.
Популярное
- Определение численности работающих на предприятии
- Должностная инструкция инспектора отдела кадров, должностные обязанности инспектора отдела кадров, образец должностной инструкции инспектора отдела кадров Какую работу выполняет отдел кадров
- Увольнение при ликвидации предприятия
- Как можно восстановиться на работе после увольнения по собственному желанию
- «Повелитель морей» (Sovereign of the Seas) по прозвищу «Золотая смерть» Сколько будет выпусков повелитель морей
- Стало известно, какие данные и как будут хранить операторы по "закону яровой" Закон о хранении сотовыми операторами
- Образная пластика в парах
- Перевозки опасных грузов морем — основные правила, требования к упаковке и документации
- Фундаментальные исследования Отсюда можно найти выражения составляющих вектора
- Научно-исследовательский институт приборостроения имени В