Жизненный цикл это непрерывный процесс
Жизненный цикл – это модель создания и использования программной системы. Он отражает различные состояния программной системы, начиная с момента возникновения необходимости в этой программной системе и принятия решения о ее создании и заканчивая полным изъятием программной системы из эксплуатации.
Международный стандарт ISOIES 12207 регламентирует структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания программного обеспечения. По этому стандарту жизненный цикл программного обеспечения базируется на трех группах процессов:
основные процессы жизненного цикла, то есть приобретение, поставка, разработка, эксплуатация и сопровождение;
вспомогательные процессы, обеспечивающие выполнение основных процессов, то есть документирование, верификация, аттестация, оценка качества и другие;
организационные процессы, то есть управление проектами, создание инфраструктуры проекта и обучение.
Разработка включает в себя все работы по созданию программного обеспечения в соответствии с заданными требованиями. Сюда включаются оформление проектной и эксплуатационной документации, подготовка материалов, необходимых для проверки работоспособности и качества программных продуктов.
Основные этапы процесса разработки:
анализ требований заказчика;
проектирование;
реализация (программирование).
Процесс эксплуатации включает в себя работы по внедрению программного обеспечения в эксплуатацию, в том числе конфигурирование рабочих мест, обучение персонала, локализация проблем эксплуатации и устранение причин их возникновения, модификация программного обеспечения в рамках установленного регламента и подготовка предложений по модернизации системы.
Каждый процесс характеризуется определенными задачами и методами их решения, а также исходными данными и результатами.
Жизненный цикл программного обеспечения носит, как правило, итерационный характер, то есть реализуются этапы, начиная с самых ранних, которые циклически повторяются в соответствии с изменением требований внешних условий и введением ограничений.
Модели жизненного цикла программного обеспечения
Существует несколько моделей жизненного цикла, которые определяют порядок исполнения этапов разработки и критерии перехода от этапа к этапу. К настоящему времени наибольшее распространение получили две модели жизненного цикла: каскадная и спиральная.
В существующих ранее однородных информационных системах каждое приложение представляло собой единое целое. Для разработки таких приложений применялась каскадная модель жизненного цикла, которую также называют классической или водопадной.
При использовании каскадной модели разработка рассматривалась как последовательность этапов, причем переход на следующий более низкий этап происходит только после того, как полностью завершены все работы на текущем этапе. Подразумевается, что в каскадной модели разработка начинается на системном уровне и происходит через анализ, проектирование, кодирование, тестирование и сопровождение.
Рисунок 1– Основные этапы разработки каскадной модели
1. Системный анализ задает роль каждого элемента в компьютерной системе и взаимодействие элементов друг с другом. Поскольку программное обеспечение рассматривается как часть большой системы, то анализ начинается с определения требований по всем системным элементам. Необходимость системного анализа явно проявляется, когда формируется интерфейс программного обеспечения с другими элементами, т.е. с аппаратурой или базами данных. На этом же этапе начинается решение задач планирования проекта. В ходе планирования проекта определяется объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.
Анализ требований относится к отдельному программному элементу. На этом этапе уточняются и детализируются функции каждого элемента, его характеристики и интерфейс. На этом же этапе завершается решение задачи планирования проекта.
2. Проектирование состоит в создании:
архитектуры программного обеспечения;
модульной структуры программного обеспечения;
алгоритмической структуры программного обеспечения;
структуры данных;
входного/выходного интерфейса (входных/выходных форм данных).
При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.
3. Кодирование или разработка состоит в переводе результатов проектирования в код программы.
4. Тестирование – это выполнение программы на выявление дефектов в функциях, логике и форме реализации программного продукта.
5. Сопровождение – это внесение изменений в эксплуатируемое программное обеспечение с целью:
исправления ошибок;
адаптации к изменениям внешней для программного обеспечения среды;
усовершенствование программного обеспечения в соответствии с требованиями заказчика.
Достоинства применения каскадной модели:
дает план и временной график по всем этапам проекта, упорядочивая, таким образом, ход разработки;
на каждом этапе формируется законченный набор проектной документации, проверенный на полноту и согласованность;
выполняемые в логической последовательности этапы работы позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадная модель хорошо себя зарекомендовала при построении информационных систем, для которых в самом начале разработки можно достаточно точно сформулировать все требования в системе, например, сложные расчетные системы, различные системы реального времени и т.д.
Недостатки каскадной модели:
реальные проекты часто требуют отклонений от стандартной последовательности шагов;
каскадная модель основана на точной формулировке исходных требований к программному обеспечению, однако реально в ряде случаев в начале проекта требования заказчика определены только частично;
результаты реализации проекта доступны заказчику только после завершения всех работ.
Из-за необходимости в процессе создания программного обеспечения постоянного возврата к предыдущим этапам и уточнения или пересмотра ранее принятых решений реальный процесс разработки программного обеспечения на основе каскадной модели может быть представлен следующей схемой (рис.2).
Рисунок 2 – Процесс разработки программного обеспечения на основе каскадной модели
Спиральная модель жизненного цикла
Спиральная модель является классическим примером эволюционной стратегии конструирования программного обеспечения.
Спиральная модель базируется на лучших свойствах каскадной модели жизненного цикла и макетирования, к которым добавляется анализ риска.
Спиральная модель включает четыре основных этапа, которые периодически повторяются:
планирование – это определение целей, вариантов и ограничений;
анализ риска – это анализ вариантов и распознавание риска;
конструирование – это разработка программного продукта следующего уровня;
оценивание – это оценка заказчика текущих результатов конструирования.
При движении по спирали строятся все более полные версии программного обеспечения при продвижении от центра к периферии. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, то на помощь заказчику и разработчику приходит макетирование. Заказчик оценивает инженерную или конструкторскую работу и вносит предложения по модификации.
Следующая фаза планирования и анализа риска базируется на предложении заказчика. Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. Количество действий по разработке возрастает по мере продвижения от центра спирали.
Рисунок 4 – Этапы спиральной модели
Достоинства спиральной модели:
наиболее реально отображает процесс разработки программного обеспечения;
позволяет явно учитывать риск на каждом витке эволюции разработки;
использует моделирование для уменьшения риска и совершенствования программного продукта.
Недостатки спиральной модели:
повышенное требование к заказчику;
трудности контроля и управления временем разработки.
ВЗАИМОСВЯЗИ МЕЖДУ ПРОЦЕССАМИ ЖЦ ПО
Процессы ЖЦ ПО, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (или в различных аспектах), который показан на рис. 1.2. Такими аспектами являются:
1) договорной аспект;
2) аспект управления;
3) аспект эксплуатации;
4) инженерный аспект;
5) аспект поддержки.
В договорном аспекте заказчик и поставщик вступают в договорные отношения и реализуют соответственно процессы приобретения и поставки.
Рис. 1.2. Связи между процессами жизненного цикла ПО
В аспекте управления заказчик, поставщик, разработчик, оператор, служба сопровождения и другие участвующие в ЖЦ ПО стороны управляют выполнением своих процессов. В аспекте эксплуатации оператор, эксплуатирующий систему, предоставляет необходимые услуги пользователям. В инженерном аспекте разработчик или служба сопровождения решают соответствующие технические задачи, разрабатывая или модифицируя программные продукты. В аспекте поддержки службы, реализующие вспомогательные процессы, предоставляют необходимые услуги всем остальным участникам работ. В рамках аспекта поддержки можно выделить аспект управления качеством ПО, включающий пять процессов: обеспечение качества, верификация, аттестация, совместная оценка и аудит. Организационные процессы, показанные в нижней части рис. 1.2, выполняются на корпоративном уровне или на уровне всей организации в целом, создавая базу для реализации и постоянного совершенствования остальных процессов ЖЦ ПО.
Процессы и реализующие их организации (или стороны) связаны между собой чисто функционально, при этом внутренняя структура и статус организаций никак не регламентируются. Одна и та же организация может выполнять различные роли: поставщика, разработчика и другие, и наоборот, одна и та же роль может выполняться несколькими организациями.
Взаимосвязи между процессами, описанные в стандарте, носят статический характер. Более важные динамические связи между процессами и реализующими их сторонами устанавливаются в реальных проектах. Соотношение процессов ЖЦ ПО и стадий ЖЦ, характеризующих временной аспект ЖЦ системы, рассматривается в рамках модели ЖЦ ПО.
Значение данного стандарта трудно переоценить, поскольку он формирует подход к выбору и оценке всех современных технологий и процессов создания и сопровождения ПО. Безусловно, на выбор конкретной технологии в проекте влияет целый ряд факторов, но принципы реализации и состав процессов ЖЦ ПО остаются стабильными. Большинство технологий, поставляемых ведущими производителями (IBM, Oracle, Microsoft и др.), соответствуют требованиям этого стандарта. Анализ различных технологий показывает, что общие принципы описания процессов ЖЦ ПО в стандарте ISO 12207 прошли практическую апробацию и стали общепризнанными.
Таблица 1. Содержание основных процессов ЖЦ ПО АИС (ISO/IEC 12207):
Процесс (испол- нитель) | Действия | Вход | Результат |
Приобретение (действия и задачи заказчика, приобретающего ИС) | Инициирование. Подготовка заявочных предложений. Подготовка договора. Контроль деятельности поставщика. Приемка ИС. | Решение о начале работ. Результаты обследования. Результаты анализа рынка ИС/ тендера. План поставки/ разработки. Комплексный тест. | Технико-экономическое обоснование внедрения. Техническое задание. Договор на поставку/ разработку. Акты приемки этапов работы. Акт приемно-сдаточных испытаний. |
Поставка (поставщик снабжает заказчика прогр. продуктом или услугой) | Инициирование. Ответ на заявочные предложения. Подготовка договора. Планирование исполнения. Поставка. | Техническое задание. Решение руководства об участии в разработке. План управления проектом. Разработанная ИС и документация. | Решение об участии в разработке. Коммерческие предложения/ конкурсная заявка. Договор на поставку/ разработку. План управления проектом. Реализация/ корректировка. Акт приемо-сдаточных испытаний. |
Разра-ботка (разработчик создает ПО, оформляет проектную и эксплуатационную документацию, подготавливает тестовые и учебные материалы и др.) | Подготовка. Анализ требований ТЗ. Проектирование архитектуры. Разработка требований к ПО. Проектирование архитектуры ПО. Детальное проектирование ПО. Кодирование и тестирование ПО. Интеграция ПО и квалификационное тестирование ПО. Интеграция ИС и квалификационное тестирование ИС. | Техническое задание на ИС. Модель ЖЦ. Подсистемы ИС. Спецификации требования к компонентам ПО. Архитектура ПО. Материалы детального проектирования ПО. План интеграции ПО, тесты. Архитектура ИС, ПО, документация на ИС, тесты. | Используемая модель ЖЦ, стандарты разработки. План работ. Состав подсистем, компоненты оборудования. Спецификации требования к компонентам ПО. Состав компонентов ПО, интерфейсы с БД, план интеграции ПО. Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам. Тексты модулей ПО, акты автономного тестирования. Оценка соответствия комплекса ПО требованиям ТЗ. Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ. |
В соответствии с ИСО 12207 основные процессы так же:
Эксплуатация (действия и задачи организации, эксплуатирующей систему).
Сопровождение (действия и задачи, выполняемые сопровождающей организацией или службой сопровождения). Сопровождение – внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
Вспомогательные процессы жизненного цикла ИС:
Документирование (формализованное описание информации, созданной в течение ЖЦ ИС)
Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ИС для определения состояния компонентов ИС, управления ее модификациями).
Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)
Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
Аудит (определение соответствия требованиям, планам и условиям договора)
Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
Организационные процессы жизненного цикла ИС:
Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:
1. Инициирование приобретения.
2. Подготовка заявочных предложений.
3. Подготовка и корректировка договора.
4. Надзор за деятельностью поставщика.
5. Приемка и завершение работ.
Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:
1. Формирование требований к системе.
2. Формирование списка программных продуктов.
3. Установление условий и соглашений.
4. Описание технических ограничений (среда функционирования системы и т. д.).
Источник
Понятие информационной системы
Под информационной системой обычно понимается прикладная программная подсистема, ориентированная на сбор, хранение, поиск и обработку текстовой и/или фактографической информации.
Подавляющее большинство информационных систем работает в режиме диалога с пользователем.
Свойства информационных систем:
• любая ИС может быть подвергнута анализу, построена и управляема на основе общих принципов построения сложных систем;
• при построении ИС необходимо использовать системный подход;
• ИС является динамичной и развивающейся системой;
• ИС следует воспринимать как систему обработки информации, состоящую из компьютерных и телекоммуникационных устройств, реализованную на базе современных технологий;
• выходной продукцией ИС является информация, на основе которой принимаются решения или производится автоматическое выполнение рутинных операций;
• участие человека зависит от сложности системы, типов и наборов данных, степени формализации решаемых задач.
Процессы в информационной системе:
- ввод информации из внешних и внутренних источников;
- обработка входящей информации;
- хранение информации для последующего ее использования; вывод информации в удобном для пользователя виде;
- обратная связь, т.е. представление информации, переработанной в данной организации, для корректировки входящей информации.
С учетом сферы применения выделяют:
- технические ИС,
- экономические ИС,
- ИС в гуманитарных областях и т.д.
Классификация ИС
1. По областям применения.
Информационных системы в экономике (АСЭ – автоматизированные системы в экономике). В образовании (АСО). В научных исследованиях (АСНИ) и т.д.
2. По характеру информации, которой оперирует ИС. Фактографические или документальные
3. По роли, которую ИС играют в профессиональной деятельности.
• Системы управления. АСУ (автоматизированная система управления), САУ(система автоматического управления – без участия человека).
• Вычислительные информационные системы.
• Поисково-справочные информационные системы.
• Системы принятия решения.
• Информационные обучающие системы.
4. По техническим средствам:
Один компьютер / Локальная сеть / Глобальная сеть
Соотношение между ИС и ИТ
Информационная технология – процесс различных операций и действий над данными.
Все процессы преобразования информации в информационной системе осуществляются с помощью информационных технологий.
Информационная система – среда, составляющими элементами которой являются компьютеры, компьютерные сети, программные продукты, базы данных, люди, различного рода технологические и программные средства и т.д.
Таким образом, информационная технология является более емким понятием, чем информационная система.
Реализация функций информационной системы невозможна без знаний ориентированной на нее информационной технологии. Информационная технология может существовать и вне сферы информационной системы.
Понятие жизненного цикла (ЖЦ) ИС
ЖЦИС– это период создания и использования ИС, начиная с момента возникновения потребности в ИС и заканчивая моментом полного её выхода из эксплуатации.
Традиционные основные этапы ЖЦ ПО:
•анализ требований;
•проектирование;
•кодирование (программирование);
•тестирование и отладка;
•эксплуатация и сопровождение.
ЖЦ является моделью создания и использования ПО, отражающей его различные состояния, начиная с момента возникновения необходимости в данном программном изделии и заканчивая моментом его полного выхода из употребления у всех пользователей.
Стадии жизненного цикла информационной системы
1. Предпроектное обследование
1.1. Сбор материалов для проектирования; формулирование требований, изучение объекта автоматизации, даются предварительные выводы предпроектного варианта ИС.
1.2. Анализ материалов и разработка документации; разрабатывается технико- экономическое обоснование с техническим заданием на стадии проектирования ИС.
2. Проектирование
2.1. Предварительное проектирование:
- выбор проектных решений по аспектам разработки ИС; описание реальных компонент ИС;
- оформление и утверждение технического проекта (ТП).
2.2. Детальное проектирование:
- выбор или разработка математических методов или алгоритмов программ;
- корректировка структур БД;
- создание документации на доставку и установку программных продуктов;
- выбор комплекса технических средств с документацией на её установку.
2.3. Разработка техно-рабочего проекта ИС (ТРП).
2.4. Разработка методологии реализации функций управления с помощью ИС и описанием регламента действий аппарата управления.
3. Разработка ИС
• получение и установка технических и программных средств;
• тестирование и доводка
программного комплекса;
• разработка инструкций по эксплуатации программно- технических средств.
4. Ввод ИС в эксплуатацию
• ввод технических средств;
• ввод программных средств;
• обучение и сертификация персонала;
• опытная эксплуатация;
• сдача и подписание актов приёмки-сдачи работ.
5. Эксплуатация ИС
• повседневная эксплуатация;
• общее сопровождение всего проекта
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трёх группах процессов:
•основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
•вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
•организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями.
• оформление проектной и эксплуатационной документации,
• подготовка материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т.д.
• анализ, проектирование и реализацию (программирование).
Эксплуатация включает в себя работы по внедрению компонентов ПО в эксплуатацию.
• конфигурирование базы данных и рабочих мест пользователей,
• обеспечение эксплуатационной документацией,
проведение обучения персонала и т.д.,
• эксплуатация, в том числе локализация проблем и устранение причин их возникновения,
• модификацию ПО в рамках установленного регламента,
• подготовку предложений по совершенствованию, развитию и модернизации системы.
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ.
Техническое и организационное обеспечение проекта включает:
• выбор методов и инструментальных средств для
реализации проекта,
• определение методов описания промежуточных состояний разработки,
• разработку методов и средств испытаний ПО, обучение
персонала и т.п.
Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО.
Верификация – это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа.
Проверка позволяет оценить соответствие параметров разработки с исходными требованиями.
Проверка частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям.
В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.
Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего, процессы разработки и сопровождения ПО.
При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учёта их связей и функций, создания унифицированной структуры и обеспечения развития всей системы.
Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
Общие принципы и рекомендации конфигурационного учёта, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.
Каждый процесс характеризуется определёнными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами.
Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы.
ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.
Модели ЖЦ ИС
Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу.
В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ:
«Waterfall Model» (каскадная модель или «водопад») (70-80г.г.) — предполагает переход на следующий этап после полного окончания работ по предыдущему этапу
В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены.
Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации.
Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена.
Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий.
Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
Когда использовать каскадную методологию?
• Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
• Нет проблем с доступностью программистов нужной квалификации.
• В относительно небольших проектах.
V-Model унаследовала структуру «шаг за шагом» от каскадной модели
V- образная модель применима к системам, которым особенно важно бесперебойное функционирование.
Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее.
Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования.
Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий.
Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
• Когда требуется тщательное тестирование
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
«Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки.
Терминология часто используется для описания поэтапной сборки ПО.
Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад».
Цикл разделен на более мелкие легко создаваемые модули.
Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования.
Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов».
Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы.
Пример проектов: читалка DefView, сеть электронных библиотек Vivaldi.
Пример одного инкремента.
Сеть электронных библиотек Vivaldi пришла на смену DefView.
DefView подключалась к одному серверу документов, а теперь может подключаться ко многим.
На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат.
Появился корневой элемент архитектуры — центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.
Когда использовать инкрементную модель?
• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.
«RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель — разновидность инкрементной модели.
В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов.
Временные рамки одного цикла жестко ограничены.
Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
• Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
• Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
• Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
• Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
• Тестирование: тестируются новые компоненты и интерфейсы.
Когда используется RAD-модель?
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов.
Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки.
RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
«Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет.
Это одно из преимуществ гибкой модели.
К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку.
Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
• отчёт о проделанной работе с момента последнего Scrum’a;
• список задач, которые сотрудник должен выполнить до следующего собрания;
• затруднения, возникшие в ходе работы.
Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка.
Соответственно, в процессе реализации требования изменяются.
Гибкая разработка лучше всего подходит для психотипа руководителей – творческие люди, которым свойственно генерировать, выдавать и опробовать новые идеи еженедельно или даже ежедневно.
Внутренние стартапы компании разрабатываются по Agile.
Примером клиентских проектов является Электронная Система Медицинских Осмотров, созданная для проведения массовых медосмотров в считанные минуты.
Когда использовать Agile?
• Когда потребности пользователей постоянно меняются в динамическом бизнесе.
• Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
• В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
«Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований.
Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований.
Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, идет стремление к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
Примером итерационной разработки может служить распознавание голоса.
Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге.
С каждой новой итерацией качество распозн?