Жизненный цикл информационных систем менеджмента

Жизненный цикл информационных систем менеджмента thumbnail

Проектирование информационных систем

Лекции

2. ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1. Структура жизненного цикла информационной системы.

2.2. Основные процессы жизненного цикла.

2.3. Организационные процессы жизненного цикла.

2.4. Вспомогательные процессы жизненного цикла.

2.5. Распределение обязанностей между участниками проекта.

Вопросы для самопроверки.

2.1. Структура жизненного цикла информационной системы

Понятие жизненного цикла (ЖЦ) является одним из ключевых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы – это непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации [4].

Основным стандартом, определяющим структуру жизненного цикла, является ГОСТ Р ИСО/МЭК 12207-02 «Информационная технология. Процессы жизненного цикла программных средств» [5]. Согласно стандарту структура жизненного цикла основывается на трех группах процессов.

Жизненный цикл информационных систем менеджмента

Рис.2.1. Классификация процессов жизненного цикла

2.2. Основные процессы жизненного цикла

В следующей таблице предпринята попытка сопоставления стадий классического жизненного цикла (автор Уинстон Ройс, 1970 г.) [43], стандарта ИСО/МЭК 12207-02, ГОСТ 34.601-90 и СТО РЖД 04.001.0-2021.

Таблица 2.1. Стадии (основные процессы) жизненного цикла информационной системы

Классический

ЖЦ

ИСО / МЭК 12207ГОСТ 34.601-90 и СТО РЖД 04.001.0-2021
СтадияОсновные этапы (работы)
Формирование требованийЗаказФормирование требований к ИСТехнико-

экономическое обоснование1

(ТЭО)

1. Обследование объекта и обоснование необходимости создания ИС.

2. Формирование требований Заказчика к ИС.

3. Оформление договора между Разработчиком и Заказчиком.

Анализ требованийРазработкаРазработка концепции ИС

(для комплексных многоуровневых и интегрированных систем)

1. Поиск путей удовлетворения требований Заказчика на уровне концепции создаваемой системы (структура, функции, программно-техническая платформа, режимы).

2. Рассмотрение альтернативных вариантов концепции системы, их анализ и выбор лучшей концепции.

ПроектированиеТехническое задание (ТЗ)Разработка, согласование и утверждение ТЗ на создание ИС.
Эскизный проект

(для комплексных многоуровневых и интегрированных систем)

Разработка предварительных проектных решений2 по системе и ее частям.
Пилот-проект

(макетирование3, прототипирование)

(при необходимости)

1. Разработка частей проекта для испытаний в реальных, но ограниченных условиях функционирования с целью проверки предварительно принятых решений.

2. Проведение испытаний на головном объекте или стенде и анализ результатов испытаний.

Технический проект1. Разработка проектных решений по системе и ее частям.

2. Разработка документации на ИС и ее части.

3. Разработка документации на поставку изделий для комплектования ИС и/или технических заданий на их разработку.

4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации (строительство, монтаж, наладка и др.).

Кодирование

(реализация)

Рабочая документация1. Разработка рабочей документации на систему и ее части.

2. Разработка программных и технических средств и/или адаптация приобретаемых.

3. Тестирование средств.

ТестированиеИнтеграция и тестирование1. Загрузка БД типовыми исходными данными и тестами.

2. Интеграция программ и тестирование в имитированной среде.

3. Интеграция программных средств с аппаратными в реальной операционной и внешней среде.

4. Тестирование в реальной среде.

5. Разработка комплекта документации для пользователей.

ЭксплуатацияПоставка

и

эксплуатация

Ввод в действие на головном объекте

(ввод в эксплуатацию, внедрение)

1. Подготовка объекта автоматизации к вводу ИС в действие.

2. Подготовка персонала.

3. Комплектация ИС поставляемыми изделиями.

4. Проведение предварительных испытаний4 и передача ИС для опытной эксплуатации5.

5. Проведение опытной эксплуатации.

6. Проведение приемочных испытаний6 по сдаче ИС в постоянную эксплуатацию.

Тиражирование

(при внедрении на нескольких объектах)

1. Передача эталона загрузочных модулей ПО и эксплуатационной документации в группу сопровождения или ОФАП7 ОАО «РЖД».

2. Тиражирование документации.

3. Обучение и консультации пользователей.

4. Поставка ПО и документации на объекты внедрения.

Сопровождение

и

эксплуатация

Сопровождение

(включая авторскую или техническую поддержку)

и

эксплуатация

1. Выполнение работ в соответствии с гарантийными обязательствами8.

2. Оказание научно-технических услуг в послегарантийный период9.

3. Разработка методики оформления отчетов об ошибках и предложениях на изменение версий.

4. Учет состояния конфигураций ИС.

Примечания:

1. Не по ГОСТ и СТО РЖД.

2. Основные проектные решения на создание ИС включают в себя определение:

– функциональной и организационной структур системы;

– состава и структуры комплекса технических и программных средств;

– применяемых инструментальных средств;

– технологии обработки информации;

– состава, структуры и технологии ведения информационной базы;

– входных и выходных форм;

– алгоритмов обработки данных.

3. Цель макетирования (прототипирования) – снять неопределенность в требованиях Заказчика.

4. Предварительные испытания информационной системы проводят для определения ее работоспособности и решения вопроса о возможности приемки ее в опытную эксплуатацию.

5. Опытную эксплуатацию проводят с целью определения фактических значений количественных и качественных характеристик информационной системы; готовности персонала к работе с ней; фактической эффективности ее работы; корректировки (при необходимости) документации.

6. Приемочные испытания проводят для определения соответствия информационной системы ТЗ, оценки качества опытной эксплуатации и решения вопроса о возможности приемки ИС в постоянную (промышленную) эксплуатацию.

7. ОФАП – отраслевой фонд алгоритмов и программ.

8. Гарантийные обязательства (выполняются бесплатно согласно договору):

– устранение выявленных недостатков и ошибок;

– внесение необходимых изменений в программы и документацию;

– внесение изменений в технологический процесс;

– консультации пользователей.

9. Послегарантийные обязательства (выполняются за отдельную плату):

– анализ функционирования системы;

– выявление отклонений фактических эксплуатационных характеристик ИС от проектных значений и установление причин этих отклонений;

– устранение выявленных недостатков и обеспечение стабильности эксплуатационных характеристик ИС;

– внесение необходимых изменений в документацию на ИС;

– передача очередных версий.

В табл. 2.1 отсутствует процесс поставки из стандарта ИСО/МЭК 12207-02, так как он определяет работы, выполняемые на всем протяжении жизненного цикла. Эти работы связаны с управлением и обеспечением проекта, начиная с момента подготовки договора и заканчивая сопровождением.

Согласно ГОСТ 34.601-90 и СТО РЖД 04.001.0-2021 допускается:

– исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях;

– объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект»;

– выполнять отдельные этапы работ до завершения предшествующих стадий;

– параллельное во времени выполнение этапов работ;

– включение дополнительных этапов работ.

2.3. Организационные процессы жизненного цикла

В следующей таблице приведена краткая характеристика организационных процессов.

Таблица 2.2. Организационные процессы жизненного цикла

Организационный процессРаботы
Управление проектамиПланирование и управление процессами, включая контроль, проверку и оценку выполненных работ с формированием отчетности.
Создание инфраструктуры проектаУстановление и обеспечение инфраструктуры, необходимой для любого другого процесса.

Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения системы.

ОбучениеПланирование и проведение обучения персонала, включая разработку учебных материалов.

При этом под персоналом понимаются не только конечные пользователи, которые будут эксплуатировать систему, но и разработчики системы. Например, разработчики должны быть обучены технологиям и средствам программирования, принятым в организации, и даже обучены правильно внедрять и обучать конечных пользователей работе с системой. Как бы это ни парадоксально звучало, но обучать правильной методике и приемам обучения тоже необходимо.

УсовершенствованиеОценка, контроль и улучшение процессов жизненного цикла.

2.4. Вспомогательные процессы жизненного цикла

В следующей таблице приведена краткая характеристика вспомогательных процессов.

Таблица 2.3. Вспомогательные процессы жизненного цикла

Вспомогательный процессРаботы
ДокументированиеРазработка, выпуск, редактирование, распространение и сопровождение документов, в которых нуждаются все заинтересованные лица.
Управление конфигурацией

(конфигурационное управление)

Определение и установление состояния программных объектов в системе.

Управление изменениями и выпуском объектов.

Обеспечение полноты, совместимости и правильности объектов.

Управление хранением, обращением и поставкой объектов.

Обеспечение качестваОбеспечение соответствия создаваемой системы и реализуемых процессов жизненного цикла установленным требованиям и утвержденным планам.
ВерификацияРаботы соответствующего субъекта (заказчика, поставщика или независимой стороны) по проверке соответствия создаваемых промежуточных результатов установленным требованиям по мере реализации проекта.

Различают верификацию договора, процесса, требований, проекта, системы, сборки системы и документации.

АттестацияРаботы соответствующего субъекта по проверке полного соответствия требований и конечного продукта функциональному назначению системы.
АудитРаботы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и условиям договора.
Совместный анализОценка состояния или результатов какой-либо работы (системы).
Разрешение проблемАнализ и устранение проблем, обнаруженных при реализации проекта.

2.5. Распределение обязанностей между участниками проекта

В процессе разработки и эксплуатации системы участвует определенный круг лиц (представители заказчика и разработчика), заинтересованных в успешной реализации проекта. В этом процессе между ними распределяются роли, за каждой из которых закрепляется определенный набор функций (обязанностей). При этом один и тот же человек может выступать в разных ролях (качествах). Так, например, один и тот же человек может быть проектировщиком и программистом, в то же время в проекте может принимать участие несколько экспертов, проектировщиков или программистов. В следующей таблице приведен типичный список ролей и их функций.

Таблица 2.4. Роли участников в проекте

РольФункции
Руководитель (менеджер) проектаИщет потенциальных заказчиков. Заключает договор на разработку системы. Отвечает за планирование сроков и ресурсов. Выполняет управление и контроль за ходом выполнения проекта. Отвечает за взаимодействие с заказчиком.
Эксперт-технологДелает постановку задачи. Определяет (совместно с системным аналитиком) основные функциональные и нефункциональные требования к системе. Определяет технологию использования разрабатываемой системы. Консультирует разработчиков в процессе создания системы. Участвует в процессе приемки системы в эксплуатацию.
Системный аналитик (архитектор, главный конструктор)Определяет функциональные и нефункциональные требования к системе, а также технологию ее использования. Выполняет анализ требований и ищет пути их реализации на уровне концепции системы. Задает архитектуру (скелет) системы и несет ответственность за соответствие моделей системы заданной архитектуре (отвечает за проектирование). Квалифицированный аналитик должен быть специалистом в области разработки программного обеспечения и должен быть (стать) специалистом в предметной области.
ПроектировщикРазрабатывает модели системы на основе архитектуры.
ПрограммистРеализует модели в виде программного обеспечения.
ТестировщикРазрабатывает тесты и тестирует модели системы и разработанное программное обеспечение.
Технический редактор (писатель)Готовит документацию для пользователей на разработанную систему. В комплект документации могут входить технологические инструкции, руководства пользователя, администратора системы, БД и т.д.
Инженер по внедрениюВнедряет разработанную систему на объекте автоматизации. В его функции может входить как первоначальная установка и настройка системы, так и обучение пользователей.
ПользовательЭксплуатирует систему в штатном режиме. Кроме этого, желательно, чтобы пользователь (помимо эксперта-технолога) был вовлечен в процесс формирования требований к системе.

У проекта должен быть один руководитель и, как правило, один системный аналитик. За остальные роли в крупных проектах отвечает обычно по несколько человек. В табл. 2.4 роли эксперта-технолога и пользователя выполняют представители заказчика, остальные роли – представители разработчика. Эксперты-технологи могут быть приглашены из сторонней организации. По мере необходимости в проекте могут принимать участие координатор работ (ответственный) со стороны заказчика, аудиторы и т. д.

Вопросы для самопроверки

1. Дайте определение понятию «жизненный цикл информационной системы».

2. Назовите группы процессов жизненного цикла.

3. Перечислите стадии жизненного цикла системы согласно ГОСТ 34.601-90 и дайте краткую характеристику каждой из них.

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 Model» (каскадная модель или «водопад») (70-80г.г.) – предполагает переход на следующий этап после полного окончания работ по предыдущему этапу

В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены.

Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации.

Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена.

Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий.

Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

Когда использовать каскадную методологию?

• Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.

• Нет проблем с доступностью программистов нужной квалификации.

• В относительно небольших проектах.

V-Model унаследовала структуру «шаг за шагом» от каскадной модели

V-Model унаследовала структуру «шаг за шагом» от каскадной модели

V- образная модель применима к системам, которым особенно важно бесперебойное функционирование.

Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее.

Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования.

Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.

Пример работы на основе V-методологии – мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий.

Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.

Когда использовать V-модель?

• Когда требуется тщательное тестирование

• Для малых и средних проектов, где требования четко определены и фиксированы.

• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

«Incremental Model» (инкрементная модель)

В инкрементной модели полные требования к системе делятся на различные сборки.

Терминология часто используется для описания поэтапной сборки ПО.

Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад».

Цикл разделен на более мелкие легко создаваемые модули.

Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования.

Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов».

Процесс продолжается до тех пор, пока не будет создана полная система.

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы.

Пример проектов: читалка DefView, сеть электронных библиотек Vivaldi.

Пример одного инкремента.

Сеть электронных библиотек Vivaldi пришла на смену DefView.

DefView подключалась к одному серверу документов, а теперь может подключаться ко многим.

На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат.

Появился корневой элемент архитектуры – центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.

Когда использовать инкрементную модель?

• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.

• Требуется ранний вывод продукта на рынок.

• Есть несколько рисковых фич или целей.

«RAD Model» (rapid application development model или быстрая разработка приложений)

Rмодель – разновидность инкрементной модели.

Rмодель – разновидность инкрементной модели.

В Rмодели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов.

Временные рамки одного цикла жестко ограничены.

Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.

Модель быстрой разработки приложений включает следующие фазы:

• Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.

• Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.

• Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.

• Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.

• Тестирование: тестируются новые компоненты и интерфейсы.

Когда используется Rмодель?

Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов.

Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки.

Rмодель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.

«Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет.

Это одно из преимуществ гибкой модели.

К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку.

Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

В основе такого типа – непродолжительные ежедневные встречи – «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

• отчёт о проделанной работе с момента последнего Scrum’a;

• список задач, которые сотрудник должен выполнить до следующего собрания;

• затруднения, возникшие в ходе работы.

Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка.

Соответственно, в процессе реализации требования изменяются.

Гибкая разработка лучше всего подходит для психотипа руководителей – творческие люди, которым свойственно генерировать, выдавать и опробовать новые идеи еженедельно или даже ежедневно.

Внутренние стартапы компании разрабатываются по Agile.

Примером клиентских проектов является Электронная Система Медицинских Осмотров, созданная для проведения массовых медосмотров в считанные минуты.

Когда использовать Agile?

• Когда потребности пользователей постоянно меняются в динамическом бизнесе.

• Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.

• В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.

«Iterative Model» (итеративная или итерационная модель)

Итерационная модель жизненного цикла не требует для начала полной спецификации требований.

Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований.

Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, идет стремление к ней так, чтобы каждый шаг был результативен, а каждая версия – работоспособна.

Примером итерационной разработки может служить распознавание голоса.

Первые исследования и подготовка научного аппарата начались давно, в начале – в мыслях, затем – на бумаге.

С каждой новой итерацией качество распознавания улучшалось.

Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.

Когда оптимально использовать итеративную модель?

• Требования к конечной системе заранее четко определены и понятны.

• Проект большой или очень большой.

• Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.

«Spiral Model» (спиральная модель)

«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков.

Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;

2. анализ рисков;

3. конструирование;

4. оценка результата и при удовлетворительном качестве переход к новому витку.

Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование.

В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты.

Даже столь любимая всеми Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования.

Методологии частично пересекаются в средствах и отчасти похожи друг на друга.

Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.

Понравилась статья? Ставь лайк

(。◕‿◕。) Подписывайся на канал!

Источник

Читайте также:  Товар с увлечением жизненным циклом