1.1. Понятие жизненного цикла программы

В наше время любое предприятие (не зависимо от рода деятельности) обрабатывает и перемещает большое количество той или иной информации.

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

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

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

a.    время, которое затрачивается на оформление документации, уменьшается, вследствие чего сокращается цикл основного производства;

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

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

Обычно информационная система разрабатывается для какого – либо конкретного предприятия.

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

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

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

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

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

До создания и ввода в эксплуатацию ИС руководство предприятия должно ответить на ряд вопросов, например:

a.    Какие именно задачи должна выполнять ИС?

b.    Кто будет являться конечными пользователями (например, администрация, отдел кадров, менеджеры верхнего и среднего звена, бухгалтеры)?

c.    В какие сроки должна быть выполнена работа по проектированию и внедрению ИС на предприятии?

d.    Каковы будут материальные затраты?

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

После того, как на все вопросы получены аргументированные ответы стоит приступать к формированию и внедрению информационной системы на

Система – совокупность объектов, компонентов, элементов произвольной природы, образующих некоторую целостность.

Добавляя к определению система слово информационная становится видно цель ее создания и функционирования.

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

Жизненный цикл программного обеспечения (ЖЦ ПО, ИС) — это совокупность взаимосвязанных процессов от момента появления идеи создания программного обеспечения до окончания его эксплуатации.

1.1.1  стандарт ISO/IEC 12207: 1995 (Процессы ЖЦ)

Описание структуры ЖЦ ПО и состав его процессов регламентируется международным стандартом ISO/IEC 12207: 1995 «Information Technology — Software Life Cycle Processes» («Информационные технологии — Процессы жизненного цикла программного обеспечения»). Отечественный вариант стандарта называется ГОСТ Р ИСО/МЭК 12207—2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

- Международная организация по стандартизации (International Standards Organization, ISO) - основная м/н организация, которая занимается стандартизацией.

- Международная электротехническая комиссия МЭК (International Electrotechnical Commission, IEC) - область электротехники, электроники, радиосвязи и приборостроения

Организации ISO и IEC объединили свою деятельность в сфере стандартизации информационных технологий, создав в 1987 году Объединенный технический комитет (JTC1).

Стандарты, которые разрабатываются JTC1 получают аббревиатуру ISO/IEC (ИСО/МЭК).

Международный стандарт ISO/IEC 12207: 1995-08-01. – Базовый стандарт, который определяет процессы ЖЦ ПО, действия и задачи, которые необходимо выполнить во время разработки ПО.

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

Стандарт равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь);

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

В стандарте  не предусмотрены этапы (фазы, стадим) ЖЦ ИС.

Общая структура стандарта - набор процессов ЖЦ.

Каждый процесс разделен на набор действий, каждое действие - на набор задач.

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

Согласно этому стандарту, архитектура ЖЦ ПО состоит из трех компонентов:

— 5 основных процессов: Приобретение, Поставка, Разработка, Эксплуатация, Сопровождение;

В стандарте описаны 5 основных, крупных обобщенных процессов ЖЦ ПО:

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

В соответствии со стандартом, процесс приобретения содержит следующие основные действия:

1. Инициирование (Initiation): Описание потребности в приобретении или разработке продукта, определение системных требований и концепции проекта.
2. Подготовка запроса предложения (Request for Proposal Preparation): Документирование требований к приобретению (включая технические ограничения), определение необходимых процессов ЖЦ и контрольных точек.
3. Подготовка и корректировка договора (Contract Preparation & Update): Разработка процедуры выбора поставщика, включение адаптированных требований стандарта в договор и проведение переговоров.
4. Мониторинг поставщика (Supplier Monitoring): Контроль деятельности поставщика в соответствии с согласованным планом и условиями контракта.
5. Приемка и завершение (Acceptance and Completion): Разработка критериев и процедур приемки, проведение приемочных испытаний, управление конфигурацией поставленного продукта и его передача заказчику.

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

Ключевые действия процесса поставки включают:

1. Инициирование поставки: Анализ запросов предложений и требований, подготовка и подача технико-коммерческого предложения.
2. Подготовка ответа на запрос: Оценка осуществимости проекта, определение рисков, подготовка проектной документации и предложений по адаптации процессов.
3. Заключение договора: Согласование и подписание контракта, в котором зафиксированы обязательства сторон.
4. Планирование выполнения: Разработка плана управления проектом, который будет служить основой для управления процессами разработки, функционирования или сопровождения.
5. Выполнение и контроль: Реализация плана, управление субподрядчиками, верификация и валидация результатов.
6. Поставка и завершение: Передача готового продукта или услуги заказчику, оказание содействия при приемке.

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

Процесс Разработка программного обеспечения (раздел 5.3) содержит 13 подразделов:

— подготовка процесса — выбор модели жизненного цикла, стандартов, составление плана работ;

— анализ требований к системе — определение функциональных, эксплуатационных, пользовательских требований;

— проектирование архитектуры системы — определение состава оборудования, ПО и операций, выполняемых персоналом;

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

— проектирование архитектуры программного обеспечения — определение структуры программного обеспечения, документирование интерфейсов его компонентов;

— детальное проектирование программного обеспечения — описание компонентов ПО и интерфейсов между ними, разработка требований к тестам;

— кодирование и тестирование компонентов программного обеспечения — разработка и тестирование компонентов;

— интеграция компонентов программного обеспечения — сборка программных компонентов в соответствии с планом интеграции, тестирование ПО на соответствие требованиям, соответствующим своим спецификациям;

— квалификационное тестирование программного обеспечения — тестирование в присутствии заказчика, проверка документации;

— интеграция системы — сборка всех компонентов системы, ПО и оборудования;

— квалификационное (аттестационное) тестирование системы — тестирование системы на соответствие требованиям, проверка оформления и полноты документации;

— инсталляция программного обеспечения — установка программного обеспечения на оборудовании заказчика и проверка его работоспособности;

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

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

Процесс функционирования включает в себя следующие действия:

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

5) процесс сопровождения - определяет действия персонала (службы сопровождения), обеспечивающего поддержку программного продукта после его передачи заказчику ( управление модификацией программного продукта, поддержку текущего состояния и функциональной пригодности, установку и удаление)

 Цель — управление модификациями, поддержание текущего состояния и функциональной пригодности продукта.

Данный процесс включает в себя следующие действия:

1. Подготовка процесса: Разработка плана и стратегии сопровождения, определение интерфейса с процессом разработки и поставки.
2. Анализ проблем и запросов: Прием и регистрация сообщений о проблемах и запросах на модификацию (доработку). Анализ их влияния на систему.
3. Выполнение модификаций: Реализация изменений в продукте. Важно отметить, что стандарт предписывает выполнять этот этап, используя все активности процесса разработки (анализ требований, проектирование, кодирование, тестирование и т.д.), но примененные к модификации.
4. Верификация и приемка модификаций: Проверка внесенных изменений и их аттестация совместно с заказчиком (оператором) перед передачей в эксплуатацию.
5. Миграция и вывод из эксплуатации: Планирование и выполнение переноса данных и функций на новую платформу или вывод устаревшей версии продукта из обращения (с уведомлением пользователей и архивацией данных).

—    8 вспомогательных процессов -  обеспечивающие выполнение основных процессов:

1) процесс решения проблем;

Данный процесс определяет действия по анализу и устранению проблем (несоответствий, сбоев, запросов на изменение), обнаруженных в ходе разработки, эксплуатации или сопровождения, независимо от их происхождения.

1. Подготовка процесса: Создание системы регистрации и классификации проблем.
2. Регистрация проблемы: Прием и формальная запись сообщения о проблеме или запросе на изменение.
3. Анализ и классификация: Оценка воздействия проблемы, определение ее приоритета и срочности.
4. Инициирование решения: Передача проблемы в соответствующий процесс (например, разработки или сопровождения) для выработки решения.
5. Отслеживание и закрытие: Контроль прохождения проблемы, верификация исправления, уведомление инициатора и закрытие запроса.

2) процесс документирования;

Этот процесс определяет действия по формальному описанию информации, создаваемой в ходе ЖЦ ПО. Его цель — создание и поддержание в актуальном состоянии документированной информации о продукте и процессах -1 -3.

1. Подготовка процесса: Планирование стратегии документирования, определение стандартов и требований к документации (пользовательской, технической, управленческой).
2. Проектирование и разработка: Определение содержания, формата и структуры документов, разработка проектов документации.
3. Выпуск (производство) документации: Подготовка, рецензирование, утверждение и тиражирование документов.
4. Сопровождение документации: Внесение изменений в документацию при модификации продукта или процессов, обеспечение синхронизации документа и продукта.

3) процесс управления конфигурацией;

Процесс определяет действия по административной и технической поддержке проекта. Цель — идентифицировать состояние компонентов ПО, управлять их версиями и изменениями, обеспечивая целостность и отслеживаемость.

1. Подготовка процесса: Разработка плана управления конфигурацией.
2. Идентификация конфигурации: Определение объектов конфигурации (документы, код, данные), присвоение им уникальных идентификаторов.
3. Контроль версий и изменений: Управление доступом к объектам, регистрация и обработка запросов на изменение, отслеживание версий.
4. Учет состояния конфигурации: Ведение отчетности о статусе объектов и внесенных изменениях.
5. Оценка конфигурации: Проверка полноты и целостности продуктов в базе линии.
6. Управление поставками и выпусками: Формирование релизов и передача их заказчику.

4) процесс обеспечения качества;

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

1. Подготовка процесса: Разработка плана обеспечения качества, выбор стандартов, методологий и метрик.
2. Оценка процесса и продукта: Систематическая проверка соответствия выполняемых работ утвержденным планам и стандартам.
3. Обеспечение соответствия: Проведение аудитов и проверок для подтверждения, что продукт соответствует требованиям.
4. Регистрация и анализ несоответствий: Фиксация отклонений, подготовка отчетов о качестве и инициирование корректирующих действий.

5) процесс верификации;

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

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

6) процесс аттестации;

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

1. Подготовка процесса: Выбор методов и определение условий для аттестации (обычно в среде, максимально приближенной к реальной эксплуатации).
2. Проведение аттестации: Тестирование продукта (или его версии) на соответствие функциональным и пользовательским требованиям.
3. Анализ результатов: Оценка готовности продукта к эксплуатации, подтверждение его пригодности для решения задач пользователя.

7) процесс совместной оценки;

Этот процесс определяет действия по периодической оценке состояния и результатов работ совместно с участвующими сторонами (заказчиком, разработчиком, пользователями). Цель — обеспечить прозрачность, достичь взаимопонимания и своевременно выявить отклонения.

1. Подготовка процесса: Планирование графика совещаний, определение состава участников и повестки дня.
2. Оценка состояния проекта: Анализ хода выполнения работ, соблюдения сроков и бюджета.
3. Техническая оценка: Совместный анализ архитектурных решений, требований, результатов тестирования.
4. Документирование решений: Фиксация выявленных проблем, принятых решений и запланированных корректирующих действий.

8) процесс аудита.

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

1. Подготовка процесса: Определение целей, критериев и объема аудита, формирование аудиторской группы.
2. Проведение аудита: Сбор и анализ объективных свидетельств, интервьюирование персонала, проверка документации и продуктов.
3. Подготовка отчета: Документирование выводов, выявленных несоответствий и рекомендаций.
4. Завершение аудита: Представление результатов заинтересованным сторонам и контроль выполнения корректирующих действий.

— 4 организационных процесса:

 1) процесс управления;

Этот процесс определяет основные действия по управлению проектами и задачами в ходе ЖЦ ПО. Он применим к любому другому процессу (основному, вспомогательному), который требует управления. Его цель — организовать, контролировать и оценивать выполнение работ для достижения поставленных целей в рамках бюджета и сроков .

1. Инициирование и определение области управления: Постановка целей, определение задач и объема работ.
2. Планирование: Разработка планов (расписания, оценка ресурсов и стоимости, распределение обязанностей, определение рисков).
3. Исполнение и контроль: Реализация планов, мониторинг хода выполнения, анализ отклонений, управление рисками и проблемами.
4. Анализ и оценка: Оценка эффективности выполнения работ и достижения целей.
5. Завершение: Подведение итогов, анализ полученного опыта, архивирование результатов.

2) процесс создания инфраструктуры;

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

1. Определение требований к инфраструктуре: Анализ того, какие аппаратные и программные средства, методики, стандарты, помещения и коммуникации необходимы для выполнения проектов.
2. Создание (приобретение) инфраструктуры: Выбор, закупка, установка и настройка оборудования, ПО, инструментов и средств связи.
3. Обеспечение функционирования и сопровождение: Поддержание инфраструктуры в рабочем состоянии, обновление компонентов, администрирование.
4. Вывод из эксплуатации: Списание или замена устаревших элементов инфраструктуры.

3) процесс усовершенствования;

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

1. Сбор и анализ данных (мониторинг процессов): Постоянное или периодическое измерение характеристик выполняемых процессов (например, сроки, стоимость, количество дефектов).
2. Оценка зрелости процессов: Анализ собранных данных для выявления сильных и слабых сторон, узких мест и потенциальных областей для улучшения.
3. Внесение улучшений: Разработка и планирование изменений в процессах (например, внедрение новых методик, автоматизация, изменение регламентов).
4. Внедрение и оценка результатов: Реализация запланированных улучшений и последующая оценка их эффективности.

4) процесс обучения

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

1. Определение потребности в обучении: Анализ требуемых компетенций для выполнения проектных ролей и выявление разрыва между текущими знаниями сотрудников и необходимыми.
2. Планирование обучения: Разработка учебных планов и программ, определение формата обучения (курсы, тренинги, наставничество).
3. Разработка или приобретение учебных материалов: Создание собственных программ или привлечение внешних провайдеров.
4. Проведение обучения: Организация и проведение учебных мероприятий.
5. Оценка эффективности обучения: Проверка усвоения знаний и влияния обучения на качество выполнения рабочих задач, ведение записей об обучении.

.

Контрольные вопросы:

1. Как расшифровываются аббревиатуры ISO и IEC, и какой объединенный комитет они создали для стандартизации в области информационных технологий?
2. Каков основной фокус и назначение международного стандарта ISO/IEC 12207:1995?
3. Какие две основные стороны (роли) в процессе жизненного цикла ПО рассматривает стандарт, и как он регулирует их взаимодействие?
4. На какие три группы подразделяются все процессы жизненного цикла программного обеспечения согласно архитектуре стандарта ISO/IEC 12207?
5. Перечислите пять основных процессов жизненного цикла ПО, определенных в стандарте.
6. Перечислите 8 вспомогательных процессов  жизненного цикла ПО, определенных в стандарте.
7. Перечислите 4 организационных процесса жизненного цикла ПО, определенных в стандарте.
8. В чем заключается ключевое отличие в подходе стандарта ISO/IEC 12207 к последовательности выполнения процессов и задач по сравнению с жесткими пошаговыми моделями?
9. Назовите три первых подраздела (действия) в рамках процесса «Разработка программного обеспечения» согласно стандарту.
10. Какие два заключительных действия процесса разработки связаны с передачей готового продукта заказчику (пользователю)?

1.3.2  Этапы (стадии)  разработки ПО

Можно выделить следующие укрупненные этапы разработки ПО с учетом соответствующих стадий разработки по ГОСТ 19.102—77 «Стадии разработки»:

— постановка задачи (стадия «Техническое задание»);

— определение спецификаций (стадия «Эскизный проект»);

— проектирование (стадия «Технический проект»);

— реализация (стадия «Рабочий проект»).

— внедрение

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

Неверно предполагать, что жизненный цикл разработки ПО согласно ГОСТ 19.102- 77 есть последовательное выполнение стадий и этапов, определенных в таблице.

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

По стандарту возможно также наличие отдельного этапа сопровождения, заключающегося в сопровождении и модификации программного продукта.

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

1. На стадии Техническое задание выполняются следующие работы, входящие в состав соответствующих этапов.

1.1. Обоснование необходимости разработки программ:

- постановка задачи;

-- сбор исходных материалов;

- выбор и обоснование критериев эффективности и качества;

- обоснование необходимости проведения НИР.

1.2. Выполнение научно-исследовательских работ:

- определение структуры входных и выходных данных;

- предварительный выбор методов решения задач;

- обоснование целесообразности применения ранее разработанных программ;

- определение требований к техническим средствам;

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

1.3. Разработка и утверждение технического задания:

- определение требований к программе;

- разработка технико-экономического обоснования разработки программы;

 -определение стадий, этапов и сроков разработки программы и документации на нее;

- выбор языков программирования;

- определение необходимости проведения НИР на последующих стадиях;

 -согласование и утверждение ТЗ.

Постановка задачи — это процесс формулировки назначения программного обеспечения и основных требований к нему.

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

Этап постановки задачи заканчивается разработкой технического задания с принятием основных проектных решений.

Техническое задание в соответствии со стандартом ГОСТ 19.201—78 «Техническое задание. Требования к содержанию и оформлению» имеет следующие основные разделы:

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

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

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

Архитектурой программного обеспечения называют описание создаваемого программного обеспечения на уровне его компонентов и связей между ними.

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

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

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

Распространенными являются следующие архитектурные паттерны:

·            модель-представление-контроллер (Model-View-Controller, MVC) применяется в системах, ориентированных на обслуживание клиентов;

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

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

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

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

При процедурном программировании модель построения программы — иерархия множества подпрограмм, при объектно-ориентированном программировании — иерархия множества классов, совокупность обменивающихся сообщениями объектов классов.

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

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

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

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

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

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

• примитивные интерфейсы;
• интерфейсы-меню;
• интерфейсы со свободной навигацией;
• интерфейсы прямого манипулирования.

К технологическим требованиям к программному обеспечению относятся:

• выбор метода программирования: процедурный или объектно-ориентированный;
• выбор языка программирования: C++, Java, Python и др.;
• выбор среды программирования: Visual Studio фирмы Microsoft, Embarcadero RAD Studio (включающая Delphi и C++ Builder), Eclipse и др.

2. Эскизный проект

Основные этапы и содержание работ на стадии Эскизный проект приведены в таблице.

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

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

Спецификации содержат:

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

2.1. Графическое представление спецификаций

Модели программного обеспечения зависят от технологии программирования (процедурная или объектно-ориентированная).

При процедурном программировании используются следующие модели разрабатываемого программного обеспечения:

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

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

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

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

В настоящее время стандартным средством описания разрабатываемого программного обеспечения с использованием объектно-ориентированного подхода является фактически графический язык UML (Unified Modeling Language, универсальный язык моделирования), разработанный авторами Г. Буч, Д. Рамбо и И. Якобсоном в 1995 г.

Язык UML описывает модель сложной системы в виде специальных графических конструкций (диаграмм).

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

Все диаграммы используют единую графическую нотацию.

В диаграммах используется 3 типа графических элементов, имеющих различное назначение:

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

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

Нотация языка UML определяет использование следующих основных видов диаграмм:

• вариантов использования (прецедентов) — описывают основные функции системы;
• классов — описывают классы, их характеристики (поля и операции) и связи между ними;
• кооперации — показывают взаимодействие объектов в процессе реализации варианта использования;
• пакетов — показывают связи наборов классов, объединенных в пакеты;

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

Пример 1

Пример 2

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

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

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

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

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

Каждая модель конкретной программной системы может содержать все или только некоторые типы диаграмм.

3. Технический проект

Основные этапы и содержание работ на стадии Технический проект приведены в таблице.

Содержанием работ на этой стадии является проектирование структуры ПО.

Проектирование — это процесс разработки структурной схемы программного обеспечения с проектированием компонентов и их взаимосвязей.

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

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

При этом исследование объектов нацелено:

• на раскрытие целостности объекта и обеспечивающих его механизмов;
• выявление многообразных типов связей сложного объекта;
• сведение этих связей в единую теоретическую картину.

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

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

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

Методы структурного анализа основываются на соблюдении следующих правил:

·       разбиение системы на уровни абстракции с ограничением числа элементов на уровне;

·       включение на каждом уровне только существенных для этого уровня деталей;

·       использование строгих формальных правил записи и условных обозначений — нотаций;

·       последовательное приближение к конечному результату.

Основными средствами структурного анализа являются:

·       DFD (Data Flow Diagrams) — диаграммы потоков данных в нотациях Гейна — Сарсона, Йордона — Де Марко и других, обеспечивающие требования анализа и функционального проектирования информационных систем;

·       STD (State Transition Diagrams) — диаграммы перехода состояний, основанные на расширениях Хартли и Уорда — Меллора для проектирования систем реального времени;

·       ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» в нотациях Чена и Баркера; структурные карты Джексона и (или) Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;

·       FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции;

·       SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования;

·       семейство IDEF (Integration Definition for Function Modeling).

Тип модели программного обеспечения определяется выбранной технологией — методом программирования (процедурный, объектно-ориентированный, компонентный).

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

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

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

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

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

4. Рабочий проект

Основные этапы и содержание работ на стадии Рабочий проект приведены в таблице.

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

Реализация — это процесс создания кода компонентов программного обеспечения на выбранном языке программирования, его тестирования и отладки.

При процедурном подходе реализация заключается в программировании функций и файлов (модулей) с использованием методов структурного программирования функций и программирования «сверху-вниз» (top-down).

Этап программирования задачи выполняется в следующей последовательности:

• программирование функций верхнего уровня схемы;
• программирование функций нижнего уровня схемы и т. д.

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

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

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

Тестирование и отладка являются завершающими этапами процесса реализации программного обеспечения.

Тестирование позволяет обнаружить ошибки, а отладка — их исправить.

В соответствии с этапами обработки программы (компиляция, компоновка, выполнение) различают следующие группы ошибок:

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

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

Согласно рекомендациям Microsoft, различают следующие стадии тестирования:

·  модульное тестирование, проверяющее небольшие отдельные части программы (циклы, блоки, подпрограммы);

·  компоновочное тестирование, проверяющее следующий уровень — программные файлы (модули), объединение, взаимодействие отдельных частей программы;

·  системное тестирование, проверяющее полную версию программы, взаимодействие с операционной системой;

·  стресс-тестирование, изучающее работу программы при ограниченных системных ресурсах;

·  бета-тестирование, позволяющее узнать мнение специалистов-пользователей;

·  приемно-сдачное тестирование — приемка пользователями в реальных условиях.

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

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

6. Отладка — это процесс поиска и исправления ошибок, обнаруженных при тестировании программы. Имеются методы отладки программного обеспечения, основанные на анализе текста программы и результатов тестирования без дополнительной информации. Например, метод индукции включает следующие процессы отладки: выявление симптомов ошибки, изучение фрагмента программы, выдвижение гипотезы об ошибке, проверка гипотезы и, при необходимости, выдвижение новой гипотезы, нахождение ошибки.

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

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

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

• установка различных точек прерывания, связанных с кодом, с данными, с сообщением, условных точек прерывания;
• выполнение программы до точки прерывания;
• просмотр в шести окнах отладчика информации о текущем состоянии программы при остановке программы в точке прерывания и при пошаговом выполнении;
• пошаговое выполнение программы с заходом в функции и без захода;
• выполнение программы до строки с курсором.

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

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

8. Внедрение

На стадии Внедрения осуществляется подготовка и передача ПО и программной

документации для сопровождения и/или изготовления, оформление и утверждение акта о передаче ПО на сопровождение или изготовление, передача ПО в фонд алгоритмов и программ.

?? Задача 1. по разделу «Стандарт ISO/IEC 12207:1995» ??

Контекст для всех заданий:
Вы — руководитель проектов в IT-компании "DevStandard", которая решила привести свои процессы в соответствие с международным стандартом ISO/IEC 12207. Ваша задача — анализировать различные ситуации и применять положения стандарта для решения проблем или построения процессов.

Кейс 1: Выбор модели ЖЦ для нового проекта

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

Задание: Опираясь на стандарт (раздел 5.3, первый подраздел), определите:

1.      Какой процесс стандарта отвечает за выбор модели жизненного цикла?

2.      Какую модель ЖЦ (каскадную, итерационную, спиральную) вы порекомендуете и почему?

3.      Какие еще решения должны быть приняты на этапе «подготовка процесса разработки» согласно стандарту?

Кейс 2: Конфликт при приемке ПО

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

Задание:

1.      К каким процессам стандарта относятся действия по приемке и разрешению споров? (Укажите основные и вспомогательные).

2.      Как должен быть организован процесс приемки согласно разделу 5.3 (последний подраздел), чтобы избежать таких ситуаций?

3.      Какой вспомогательный процесс мог бы зафиксировать устные требования?

Кейс 3: Проблемы с сопровождением устаревшей системы

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

Задание:

1.      К какому из 5 основных процессов относится данная деятельность?

2.      Какие действия из этого процесса должны быть выполнены перед началом модификации?

3.      Какой вспомогательный процесс «управление конфигурацией» мог бы помочь в этой ситуации?

Кейс 4: Организация распределенной разработки

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

Задание:

1.      Какие организационные процессы из стандарта необходимо активизировать?

2.      Какие вспомогательные процессы критически важны для распределенной работы?

3.      Предложите конкретные меры в рамках выбранных процессов.

Кейс 5: Инцидент при эксплуатации банковской системы

Ситуация: В процессе эксплуатации банковской системы произошел сбой, приведший к временной недоступности онлайн-банкинга. Расследование показало, что ошибка была внесена при последнем обновлении.

Задание:

1.      К каким процессам (основным и вспомогательным) относится расследование инцидента?

2.      Как процессы «эксплуатация» и «сопровождение» должны взаимодействовать в этой ситуации?

3.      Какой вспомогательный процесс мог бы предотвратить попадание ошибки в продуктивную среду?

Кейс 6: Разработка ПО для медицинского оборудования

Ситуация: Компания разрабатывает программное обеспечение для аппарата ИВЛ. Требуется доказать соответствие строгим стандартам безопасности и надежности.

Задание:

1.      Какие вспомогательные процессы из стандарта становятся критически важными?

2.      Как процесс «верификация» должен быть интегрирован в жизненный цикл?

3.      Чем отличается «аттестация» от «верификации» в контексте этого проекта?

Кейс 7: Китайская стена между заказчиком и разработчиком

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

Задание:

1.      Какие основные процессы задействованы со стороны заказчика и со стороны разработчика?

2.      Как стандарт описывает взаимодействие между процессами «приобретение» и «поставка»?

3.      Какие риски возникают при таком разделении и как их минимизировать?

Кейс 8: Создание инфраструктуры для стартапа

Ситуация: IT-стартап из 5 человек начинает первый коммерческий проект. У них нет регламентов, системы контроля версий, трекера задач, тестовых сред.

Задание:

1.      Какой организационный процесс стандарта описывает создание инфраструктуры?

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

3.      Как процесс «обучение» должен быть реализован в таком стартапе?

Кейс 9: Масштабирование процессов при росте компании

Ситуация: Компания выросла с 10 до 100 сотрудников. Хаотичные процессы, которые работали в маленькой команде, теперь приводят к хаосу. Руководство решило внедрить ISO/IEC 12207.

Задание:

1.      С каких процессов следует начать внедрение стандарта? Обоснуйте последовательность.

2.      Как процесс «усовершенствование» должен работать в компании?

3.      Какие процессы могут оставаться гибкими, а какие необходимо формализовать в первую очередь?

Кейс 10: Аудит открытого исходного кода

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

Задание:

1.      К каким процессам (основным, вспомогательным, организационным) относится аудит сторонних компонентов?

2.      Как процесс «совместная оценка» может быть применен к open-source компонентам?

3.      Разработайте чек-лист аудита библиотек, основываясь на структуре процессов стандарта.

Контрольные вопросы:

1.3.3 Этапы (Стадии) ЖЦ ПО

Полный жизненный цикл информационной системы состоит из следующих основных этапов:

1.        анализ и формирование требований к будущей системе (Предпроектное обследование);

2.        проектирование;

3.        реализация проекта создания ИС;

4.        тестирование ИС;

5.        ввод ИС в эксплуатацию;

6.        эксплуатация и сопровождение ИС;

7.        вывод ИС из эксплуатации.

1. Стадия анализа и формирования требований является одной из важнейших, так как определяет успех всего проекта.

Это исследовательская и аналитическая фаза, целью которой является всестороннее изучение предметной области, выявление проблем и потребностей заказчика, а также формализация и документирование того, ЧТО должна делать будущая система, без описания КАК она это будет делать.

Ключевые цели:

·       Установить общее видение и границы проекта.

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

·       Сформулировать непротиворечивый, полный, проверяемый набор требований.

·       Оценить техническую и экономическую осуществимость проекта.

·       Создать основу для планирования и проектирования.

Основные активности:

·       Интервью, анкетирование, наблюдение за работой пользователей.

·       Анализ документов и существующих процессов («как есть»).

·       Моделирование бизнес-процессов (BPMN, диаграммы потоков данных).

·       Выявление и классификация требований: функциональные, нефункциональные (атрибуты качества), бизнес-требования, ограничения.

·       Разработка прототипов интерфейсов для уточнения потребностей.

·       Оценка рисков и составление предварительного плана проекта.

Выходные артефакты (результаты):

·       Устав проекта (Project Charter).

·       Отчет об обследовании.

·       Модели «As-Is» и «To-Be».

·       Спецификация требований к программному обеспечению (SRS) или бэклог продукта (в Agile).

·       Бизнес-кейс с предварительной оценкой затрат и выгод.

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

На этой стадии определяется область применения информационной системы, и формируются граничные условия.

Данная стадия включает в себя этапы:

a.    Планирование работ предшествует работам над проектом. На этом этапе производится предварительная экономическая оценка проекта (Расчет ROI (Return on Investment), TCO (Total Cost of Ownership), анализ рисков и альтернатив (build vs. buy)), определяются цели разработки, строится план выполнения работ, создается и обучается рабочая группа.

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

c.    Моделирование. Построение двух моделей деятельности организации на основании результатов обследования:

·       Модель «Как есть» — отражает существующее на момент обследования положение дел в организации. Позволяет выявить «узкие» места в функционировании и сформулировать предложение по улучшению ситуации.

·       Модель «Как должно быть» — представляет наиболее оптимальную работу предприятия. Проектируется целевое состояние процессов. На этом этапе уже закладываются контуры будущей системы:

- Выделение ключевых сущностей и их атрибутов (предметная область → будущие классы/модули).

- Определение точек автоматизации → будущие функциональные модули.

- Анализ информационных потоков → будущие интерфейсы (API) между модулями.

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

Переход может осуществляться двумя путями:

a.    совершенствование существующих жизненных процессов;

b.    радикальное перепроектирование бизнес – процессов и внедрение новых технологий обработки.

Для сбора информации используются следующие способы:

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

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

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

Логическим завершением каждой из этой процедур является пересмотр существующих планов.

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

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

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

• Совместимость требований. Функции разрабатываемого программного обеспечения могут оказаться несовместимыми по логическим (противоречивость функций) или психологическим (концептуальные различия) компонентам.

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

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

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

2. Проектирование ИС осуществляется на основе моделей «Как должно быть».

Это творческо-техническая фаза, на которой требования трансформируются в детальные планы и спецификации, описывающие КАК система будет удовлетворять этим требованиям. Фокус смещается с «что» на «как».

Ключевые цели:

·       Разработать архитектурное решение, удовлетворяющее функциональным и нефункциональным требованиям.

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

·       Создать техническую документацию, достаточную для начала разработки.

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

Основные активности:

·       Архитектурное проектирование: Выбор стиля (микросервисы, монолит), определение ключевых подсистем и технологического стека.

·       Проектирование данных: Создание логической и физической модели базы данных.

·       Проектирование компонентов: Детальная спецификация программных модулей, их интерфейсов (API), алгоритмов и структур данных.

·       Проектирование пользовательского интерфейса (UI/UX): Создание макетов, сценариев взаимодействия, дизайн-системы.

·       Проектирование интеграций: Описание протоколов взаимодействия с внешними системами.

Выходные артефакты:

·       Архитектурная схема (диаграмма компонентов, развертывания).

·       Техническое задание (ТЗ) или детальные спецификации.

·       Диаграммы UML (Sequence, Class, State).

·       Прототипы/макеты интерфейсов.

·       Спецификация API (например, в OpenAPI).

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

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

-  Концептуальное проектирование (Архитектура высокого уровня):

• Выбор технологического стека (языки, фреймворки, СУБД).
• Определение архитектурного стиля (монолит, микросервисы, сервис-ориентированная архитектура). Это ключевое решение, определяющее границы и принципы взаимодействия модулей.
• Проектирование компонентной архитектуры: Выделение основных подсистем и модулей, определение их ответственности.
• Проектирование данных: Концептуальная и логическая модель данных (ER-диаграммы).

-  Детальное проектирование (Низкоуровневое):

• Спецификация модулей: Детальное описание интерфейсов (вход/выход), алгоритмов, структур данных для каждого программного модуля.
• Проектирование базы данных: Физическая модель данных, индексы, процедуры.
• Проектирование пользовательского интерфейса (UI/UX): Макеты, сценарии взаимодействия, прототипы.
• Спецификация интеграций: API-контракты (например, с использованием OpenAPI/Swagger), форматы обмена сообщениями.
• Выходные артефакты: Техническое задание (ТЗ), спецификации, диаграммы UML (Sequence, Class, Component), прототипы.

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

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

Ключевые цели:

·       Создать качественный, соответствующий проекту и стандартам код.

·       Обеспечить модульность, тестируемость и сопровождаемость кода.

·       Организовать эффективную совместную работу команды разработчиков.

·       Интегрировать отдельные компоненты в единую систему.

Основные активности:

·       Написание исходного кода в соответствии с техническим заданием и стандартами кодирования.

·       Модульное (юнит) тестирование (часто по методологии TDD).

·       Обзоры кода (Code Review) для обеспечения качества и передачи знаний.

·       Статический анализ кода.

·       Сборка (Build) компонентов и системы в целом.

·       Непрерывная интеграция (CI) — частое слияние кода в общий репозиторий с автоматической сборкой и тестированием.

·       Версионный контроль кода (Git).

Выходные артефакты:

·       Исходный код системы в репозитории.

·       Исполняемые файлы / артефакты сборки.

·       Наборы модульных тестов.

·       Техническая документация к коду (комментарии, README).

Риски при некорректном выполнении: Низкое качество кода, несоблюдение архитектуры, рост «технического долга», что делает систему нестабильной и крайне дорогой в изменении.

Стадия включает фазы:

-  Подготовительная фаза:

·  Настройка среды разработки (IDE, инструменты сборки).

·  Создание репозитория кода (Git) и стратегии ветвления (Gitflow, Trunk-based).

·  Настройка CI/CD-конвейера для автоматической сборки и базового тестирования.

-   Непосредственная разработка модулей:

·  Кодирование в соответствии со спецификациями и стандартами кодирования (code style, naming conventions).

·  Применение принципов «чистого кода» (Clean Code) и паттернов проектирования (SOLID, GRASP) на уровне модулей.

·  Параллельная разработка модульных (юнит) тестов (TDD — Test-Driven Development — как возможный подход).

·  Проведение регулярного обзора кода (Code Review) для обеспечения качества и обмена знаниями в команде.

·  Непрерывная интеграция (Continuous Integration): Частая сборка и слияние кода с главной веткой, автоматический прогон тестов.

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

Ключевые цели:

·       Обнаружить и зафиксировать как можно больше дефектов до передачи системы пользователям.

·       Оценить соответствие системы функциональным и нефункциональным требованиям.

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

·       Минимизировать риски сбоев при эксплуатации.

Основные активности:

• Планирование тестирования, разработка тестовых сценариев и чек-листов.
• Модульное, интеграционное, системное и приемочное тестирование.
• Нефункциональное тестирование: нагрузочное, стрессовое, тестирование безопасности и удобства использования.
• Регрессионное тестирование — проверка, что новые изменения не сломали существующий функционал.
• Автоматизация тестирования (где это целесообразно).
• Анализ и классификация обнаруженных дефектов, их передача на исправление.

Выходные артефакты:

• План тестирования.
• Тестовые сценарии и данные.
• Отчеты о дефектах (баг-репорты).
• Итоговый отчет о тестировании с рекомендацией о готовности к выпуску.

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

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

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

Ключевые цели:

·       Обеспечить плавный, контролируемый и безопасный переход пользователей от старых процессов/систем к новой ИС.

·       Минимизировать простои и негативное влияние на бизнес-процессы.

·       Добиться того, чтобы пользователи могли эффективно работать с новой системой.

Основные активности:

·       Подготовка производственной среды: установка и настройка серверов, СУБД, сетевого оборудования.

·       Развертывание (деплой) установочных пакетов системы и перенос данных.

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

·       Осуществление стратегии перехода: прямой замены, параллельного запуска, пилотного внедрения или поэтапного ввода.

·       Формальная приемка-передача системы заказчику (подписание акта).

Выходные артефакты:

·       Развернутая и работающая система в продуктивной среде.

·       Акт о вводе в эксплуатацию.

·       Пользовательская и административная документация.

·       Обученные пользователи и команда поддержки.

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

Стадия включает этапы:

- Пилотное внедрение (Pilot Launch): Запуск системы для ограниченной группы пользователей или в одном подразделении.

- Фазированный ввод (Phased Rollout): Поэтапный запуск функциональности.

- Полномасштабный запуск (Big Bang): Полный переход на новую систему в назначенную дату.

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

6. Эксплуатация и сопровождение ИС

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

Ключевые цели:

·       Обеспечить стабильную, надежную и безопасную работу системы.

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

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

Основные активности:

·       Техническая поддержка и устранение инцидентов.

·       Мониторинг производительности, доступности и безопасности системы.

·       Внесение изменений:

- Корректирующие — исправление ошибок.

- Адаптивные — приспособление к новой среде (ОС, законы).

- Совершенствующие — добавление новой функциональности или улучшение существующей.

·       Резервное копирование и восстановление.

·       Оптимизация производительности.

Выходные артефакты:

·       Стабильно работающая, актуальная система.

·       Журналы инцидентов и изменений.

·       Обновленные версии документации и кода.

·       Отчеты о работе системы.

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

Наиболее длительная и ресурсоемкая фаза, которая включает:

- Техническая поддержка: Устранение инцидентов и ошибок (корректирующее сопровождение).

- Адаптивное сопровождение: Дообучение пользователей, настройка под изменяющиеся условия работы, адаптация к новым версиям ОС или платформ.

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

- Управление инцидентами и проблемами (ITSM/ITIL).

 - Мониторинг и аналитика: Отслеживание доступности, производительности, анализ логов для предупреждения проблем.

7. Вывод из эксплуатации

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

Ключевые цели:

• Организовать упорядоченное и безопасное прекращение использования системы.
• Сохранить исторические данные в соответствии с законодательными и бизнес-требованиями.
• Освободить и переназначить ресурсы (аппаратные, программные, человеческие).

Основные активности:

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

Выходные артефакты:

• Акт о выводе системы из эксплуатации.
• Архивные копии данных и кода.
• Отчет о завершении проекта/жизненного цикла.

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

Стадия включает этапы:

- Анализ и планирование: Определение даты вывода, оценка рисков.

- Миграция данных: Перенос исторических данных в новую систему или в архивный формат.

- Отключение сервисов: Поэтапное прекращение работы компонентов системы.

- Архивация: Сохранение кода, документации и данных для юридических и исторических целей.

 - Вывод оборудования из эксплуатации или его перепрофилирование.

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

?? Задача 2.  «Проект внедрения складской системы для сети розничных магазинов» ??

Общая ситуация:
Компания «FreshMarket» (сеть из 20 продовольственных магазинов) решает автоматизировать управление запасами на центральном складе. Была выбрана и закуплена готовая ERP-система «StockMaster». Проект длится уже 8 месяцев, но столкнулся с критическими проблемами, и генеральный директор требует от вас, как приглашенного консультанта, провести аудит проекта.

Вам предоставили информацию о ходе работ:

1. Этап анализа и формирования требований (Месяцы 1-2):

·         Факт: Техническое задание (ТЗ) составлял отдел логистики без привлечения будущих пользователей системы — кладовщиков и бухгалтерии. ТЗ содержало общие пожелания («увеличить оборачиваемость товара»), но не детализированные процессы. Команда тестирования не привлекалась к анализу требований.

·         Вопрос: Какие три ключевые ошибки были допущены на этом этапе, исходя из его целей и активностей? К каким рискам (из описанных в теории) это уже привело или может привести?

2. Этап проектирования (Месяцы 3-4):

·         Факт: Внешний подрядчик, отвечающий за настройку системы, спроектировал архитектуру на основе устаревшей монолитной СУБД, аргументируя это опытом своей команды. Интерфейсы для интеграции с существующей бухгалтерской программой «1С» были описаны поверхностно.

·         Вопрос: Какие артефакты этапа проектирования, вероятно, были недостаточно проработаны? Какова главная опасность выбора архитектуры, исходя лишь из удобства подрядчика?

3. Этап реализации/разработки (Месяцы 4-6):

·         Факт: Команда настройщиков работала без единого репозитория кода (использовали общую сетевую папку), стандарты кодирования не соблюдались. Обзоры кода (Code Review) не проводились. Из-за срочности некоторые модули были сделаны без модульных тестов.

·         Вопрос: Какие три принципа из фазы реализации были нарушены? Что такое «технический долг» и как описанные действия к нему приводят?

4. Этап тестирования (Месяц 7):

·         Факт: Тестирование проводилось только силами подрядчика. Было проверено, что кнопки нажимаются, но не проводилось нагрузочное тестирование на объеме данных, сопоставимом с реальной работой склада. Сценарии тестирования не включали проверку целостности данных при откате операций.

·         Вопрос: Какие виды тестирования были проигнорированы и почему это критично для складской системы? Какова роль независимой (от разработчиков) группы тестирования?

5. Этап ввода в эксплуатацию (Текущий момент, месяц 8):

·         Факт: При попытке запуска система «упала» при одновременной работе 10 пользователей. Данные о товарах из старой Excel-таблицы были загружены с ошибками формата. Кладовщики не прошли полноценного обучения и отказываются работать с системой, называя интерфейс неудобным.

·         Вопрос: Какая стратегия перехода (ввода в эксплуатацию) должна была быть выбрана для минимизации рисков? Какие три подготовительные активности были явно пропущены перед запуском?

6. Этап эксплуатации и сопровождения (Проблемы, с которыми столкнулись):

·         Факт: В первую неделю после «запуска» выяснилось, что в системе нет отчета, который еженедельно требует руководство. Заявка на его создание оценена подрядчиком в 3 недели. Также обнаружена ошибка, приводящая к потере данных о партиях товара при определенных условиях.

·         Вопрос: К каким типам работ по сопровождению (корректирующие, адаптивные, совершенствующие) относятся описанные проблемы? Как должна быть организована служба поддержки?

7. Гипотетическая ситуация на этапе вывода из эксплуатации:

·         Факт: Через 2 года компания планирует переход на новую, более мощную систему. Руководство хочет просто выключить старую «StockMaster» и удалить её базу данных.

·         Вопрос: Какие риски несет такой подход? Какие активности из этапа вывода из эксплуатации необходимо запланировать?

8. Сквозной вопрос по управлению проектом:

·         Факт: На всех этапах отсутствовал полноценный руководитель проекта со стороны «FreshMarket». Контроль осуществлялся по принципу «раз в месяц – устный отчет».

·         Вопрос: Какой ключевой артефакт начала проекта (из этапа анализа) либо не был создан, либо был создан формально? Как это повлияло на весь жизненный цикл?

9. Практическое задание на исправление ошибок:

·         Задание: Вам поручено «спасти» проект. Составьте план из 5 первоочередных действий, распределив их по соответствующим этапам ЖЦ. Например: «1. Вернуться к этапу анализа: провести интервью с кладовщиками...».

10. Ситуация для обсуждения и выбора:

·         Факт: После вашего аудита стало ясно, что систему нужно существенно дорабатывать. Подрядчик настаивает на продолжении работ по старому контракту.

 Заказчик рассматривает два варианта:

1) Расторгнуть договор и начать проект с нуля с другой командой.

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

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

Контрольные вопросы:

1. Перечислите все семь основных этапов полного жизненного цикла информационной системы.
2. Какой главный вопрос (Что? или Как?) решается на стадии анализа и формирования требований? Почему эта стадия считается критически важной?
3. Почему начальные фазы проекта (анализ, проектирование) оказывают наибольшее влияние на итоговое качество и успех системы?

1.3.4 Модели ЖЦ ПО

В основе любого жизненного цикла лежат модели и методологии разработанные на их основе.

Модель ЖЦ ПО - представляет собой определенную структуру, которая отражает последовательность выполнения и взаимосвязи задач, процессов, действий на протяжении всего жизненного цикла ИС.

Модель ЖЦ зависит от характерных особенностей информационной системы и условий, в которых она создается.

Модель жизненного цикла информационной системы может включать:

1.    Стадии.

2.    Основные результаты выполнения работ на каждой стадии.

3.    Ключевые события (точки завершения работ и принятия решений)

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

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

Можно выделить  модели жизненного цикла программного обеспечения:

•      Каскадная (Waterfall)

•      Итерационная с промежуточным контролем

•      Спиральная (Spiral Model)

•      Итерационная

•      Инкрементальная

•      RAD (Rapid Application Development)

•       v-образная V-Model

•      Rational Unified Process (RUP)

•      Microsoft Solutions Framework (MSF)

•      Гибкие методологии Agile:

o      scrum,

o      Kanban

o       extreme Programming (XP)

?? Задача 3.  Используя информацию из опорного конспекта и пользуясь дополнительными источниками опишите: ??

- Схема (Рисунок)

- Описание модели

- Описание каждого этапа (стадии), что на нем происходит

- Результаты каждой стадии

- На каком этапе начинается тестирование

- Размер команды разработчиков

- Особенности

- Для каких по масштабу и направленности проектов разработки подходит

- Преимущества

- Недостатки

Моделей разработки ПО много, но, в общем случае, классическими можно считать каскадную, v-образную, итерационную, инкрементальную, спиральную и гибкую.

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

Достоинства модели заключаются в следующем:

·                     получение после этапа законченного набора проектной документации без возврата на предыдущие этапы;

·                     простота планирования процесса разработки программного обеспечения.

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

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

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

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

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

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

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

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

Необходимость возвратов на предыдущие этапы бывает обусловлена следующими причинами:

·                     неточные спецификации, уточнение которых требует пересмотра предыдущих решений;

·                     изменения требований заказчика;

·                     моральное устаревание технических и программных средств.

К достоинствам модели относятся:

•   устойчивость к изменению кадрового состава;

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

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

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

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

Недостатки модели:

•   неадаптивная структура ПО; на первых этапах модель водопада может быть гибкой, но если на фазе тестирования выявляются проблемы в общей структуре — это влечет за собой плачевные последствия в виде сорванных сроков и даже отказов заказчика;

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

•   позднее тестирование; именно на этапе тестирования чаще всего выявляются ошибки, допущенные на каждом из этапов. Более гибкие методологии используют тестирование в качестве фундаментальной операции, происходящей непрерывно. «Водопад» же допускает низкую квалификацию сотрудников на каждом этапе и плохое качество исполнения, ведь при запоздалом тестировании проблемы невозможно решить фундаментально, только при помощи «заплаток».

Таким образом, каскадная методология — хорошее решение, с точки зрения сроков и отчетности, но очень слабое в плане качества, поэтому сегодня ее рекомендуется использовать только в трех случаях:

·           при ориентации ИС на заказчика, требующего прозрачность работ и исполнение в назначенные сроки;

·           при наличии в штате руководителей соответствующей квалификации;

·           при исполнении проекта, не имеющего конкуренции на рынке.

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

Действительно если тесты обнаружили несоответствие реализации требованиям, то причина может крыться:

 (а) в неправильном тесте,

(б) в ошибке кодирования (реализации),

(в) в неверной архитектуре системы,

(г) некорректности требований к программному обеспечению и т.д.

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

2. Итерационная (поэтапная) модель с промежуточным контролем - поддерживает итерационный характер процесса разработки, т. е. возврат на предыдущие этапы (цикл обратной связи между этапами). Опасность использования модели состоит в том, что разработка программного обеспечения может затянуться.

Разработка ИС ведется итерациями

Каждый этап имеет с циклы обратной связи между итерациями

Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах

Время жизни каждого из этапов растягивается на весь период разработки

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

Некоторые свойства модели:

• Модель состоит из последовательно расположенных этапов. Следующий этап не начинается, пока не завершится предыдущий.  
• Каждый этап имеет обратную связь с предыдущими этапами. Исправление ошибок происходит на каждом из этапов, сразу при выявлении проблемы — это промежуточный контроль.  
• Этапы перекрываются во времени. При первом проходе по модели вниз, как только обнаружена ошибка, осуществляется возврат снизу вверх к предыдущим этапам, которые повлекли ошибку.  
• Результат появляется только в конце разработки. Критерием появления результата является приемлемое качество продукта, то есть такое состояние продукта, когда наиболее критические для клиента ошибки устранены, а с наличием непринципиальных для жизнедеятельности системы ошибок клиент согласился. 

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

3. Спиральная модель

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

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

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

При этом обосновывается и проверяется возможность реализации спроектированных технических решений.

В спиральной модели разработка системы происходит повторяющимися этапами – витками спирали. Каждый виток спирали – один каскадный или V-образный жизненный цикл.

На каждом витке создается прототип проектируемой информационной системы  (законченная версия системы, реализующая некоторый набор функций), который на следующих витках спирали ЖЦ ИС совершенствуется, дополняется и доводится до полного внедрения.

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

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

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

Новый виток спирали соответствует поэтапной модели создания фрагмента информационной системы.

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

При использовании спиральной модели ЖЦ:

-       происходит ориентация на модернизацию информационной системы;

- осуществляется аккумулирование всех решений в процессе проектирования и создания моделей и прототипов информационной системы;

-       проводится анализ издержек и всех рисков в процессе проектирования ИС.

Этот многократный цикл, завершающийся созданием новой версии информационной системы.

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

•  проработка целей, альтернатив и ограничений;

•  анализ рисков и прототипирование;

•  разработка (промежуточной версии) продукта;

•  планирование следующего цикла.

Для применения спиральной модели ЖЦ ИС может быть несколько причин, это необходимость минимизации рисков и возможность представления заказчику прототип или эскизную версию проекта для конкретизации пожеланий и учета их в следующих циклах.

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

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

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

Достоинства модели:

•     позволяет быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований;

•     допускает изменение требований при разработке системы;

•     обеспечивает большую гибкость в управлении проектом;

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

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

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

Недостатки модели:

•     увеличивается неопределенность в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;

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

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

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

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

Как следует из названия модели, ей свойственна определённая двойственность (а ISTQB-глоссарий даже не приводит единого определения, разбивая его на отдельные части):

•  с точки зрения жизненного цикла модель является итерационной, т.к. подразумевает многократное повторение одних и тех же стадий;

•  с точки зрения развития продукта (приращения его полезных функций) модель является инкрементальной.

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

Для каждого инкремента выполняется:

·          Анализ, на котором мы собираем требования и анализируем, и планируем сам инкремент;

·          Проектирование, на котором происходит проектирование архитектуры, допроектирование тех вещей, которые не были сделаны на предыдущем инкременте;

·          Разработка;

·          Тестирование.

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

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

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

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

Применение данной модели ЖЦ характерно для разработки сложных и комплексных систем, выполняемых большими командами на протяжении длительных сроков. Для команды имеется четкое видение того, что собой должен представлять конечный результат — информационную систему.

 Разработка версиями ведется в силу разного рода причин:

•    отсутствия у заказчика возможности сразу профинансировать весь проект;

•    отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;

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

Преимущества инкрементной модели:

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

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

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

·          ускоряется начальный график поставки (что позволяет соответствовать возросшим требованиям рынка);

·          риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки);

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

Недостатки инкрементной модели:

·          в модели не предусмотрены итерации в рамках каждого инкремента;

·          определение полной функциональности системы должно осуществляться в начале жизненного цикла, чтобы обеспечить определение инкрементов;

·          формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом;

·          поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах;

·          для модели необходимо хорошее планирование и проектирование;

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

5. RAD (Rapid Application Development)

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

RAD-модель включает в себя следующие этапы:

Сбор требований: На этом этапе осуществляется сбор и анализ требований, чтобы определить, что должно быть разработано.

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

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

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

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

Релиз и сопровождение: После успешного прохождения тестирования приложение готово для выпуска. В данном этапе также осуществляется техническая поддержка приложения и устранение возникающих ошибок.

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

Преимущества:

Модель RAD (Rapid Application Development) – это методология разработки программного обеспечения, основанная на быстром создании прототипов и итеративном подходе. Её главными преимуществами являются:

Быстрота разработки: RAD-модель позволяет быстро создавать рабочие прототипы, которые можно демонстрировать клиентам и пользователям. Это ускоряет процесс разработки и позволяет быстрее получать обратную связь на ранних стадиях проекта.

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

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

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

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

Улучшенная коммуникация: RAD-модель способствует улучшению коммуникации между командами разработчиков, тестировщиков, менеджеров и клиентов. Более частые встречи и общение улучшают понимание требований и уменьшают риск непонимания.

Недостатки:

Несмотря на ряд преимуществ, у модели RAD есть и недостатки, включая:

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

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

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

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

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

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

Модель RAD (Rapid Application Development) подходит для проектов, где сроки и время разработки критичны, а клиенты и пользователи требуют быстрой реакции на изменения и быстрое внедрение новых функциональных возможностей. Она также хорошо подходит для проектов, где требуется демонстрация прототипов клиентам и пользователям на ранних стадиях разработки, чтобы получать обратную связь и улучшать продукт.

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

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

6. «V-Model»

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

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

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

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

В V-модели каждому этапу проектирования и разработки системы соответствует отдельный уровень тестирования. Здесь процесс разработки представлен нисходящей последовательностью в левой части условной буквы V, а стадии тестирования — на ее правом ребре (рис. 4). Соответствие этапов разработки и тестирования показано горизонтальными линиями.

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

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

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

·                Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.

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

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

Достоинства V-модели:

• строгая последовательность этапов;

• планирование тестирования и верификация системы произво- дятся на ранних этапах;

• улучшенный, по сравнению с каскадной моделью, тайм- менеджмент;

• промежуточное тестирование. Недостатки V-модели:

• недостаточная гибкость модели;

• создание программы происходит на этапе написания кода, т. е. уже в середине процесса разработки;

•       недостаточный анализ рисков;

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

Когда рекомендуется использовать V-модель:

1)            в проектах, в которых существуют временные и финансовые ограничения;

2)            для задач, которые предполагают более широкое, по сравнению с каскадной моделью, тестовое покрытие.

7. Rational Unified Process (RUP)

Rational Unified Process – это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Продукт Rational Unified Process (RUP) разработаниподдерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.

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

RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. Обеспечивая каждому члену группы доступ к той же самой базе знаний, вне зависимости от того, разрабатывает ли он требования, проектирует, выполняет тестирование или управляет проектом - RUP гарантирует, что все члены группы используют общий язык моделирования, процесс, имеют согласованное видение того, как создавать ПО. В качестве языка моделирования в общей базе знаний используется Unified Modeling Language (UML), являющийся международным стандартом.

Особенностью RUP является то, что в результате работы над проектом создаются и совершенствуются модели. Вместо создания громадного количества бумажных документов, RUP опирается на разработку и развитие семантически обогащенных моделей, всесторонне представляющих разрабатываемую систему. RUP – это руководство по тому, как эффективно использовать UML. Стандартный язык моделирования, используемый всеми членами группы, делает понятными для всех описания требований, проектирование и архитектуру системы.

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

RUP – это конфигурируемый процесс, поскольку, вполне понятно, что невозможно создать единого руководства на все случаи разработки ПО. RUP пригоден как для маленьких групп разработчиков, так и для больших организаций, занимающихся созданием ПО. В основе RUP лежит простая и понятная архитектура процесса, которая обеспечивает общность для целого семейства процессов. Более того, RUP может конфигурироваться для учета различных ситуаций. В его состав входит Development Kit, который обеспечивает поддержку процесса конфигурирования под нужды конкретных организаций.

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

использования передового опыта в:

  итерационной разработке ПО,

  управлении требованиями,

  использовании компонентной архитектуры,

  визуальном моделировании,

  тестировании качества ПО,

  контроле за изменениями в ПО.

RUP организует работу над проектом в терминах последовательности действий (workflows), продуктов деятельности, исполнителей и других статических аспектов процесса с одной стороны, и в терминах циклов, фаз, итераций и временных отметок завершения определенных этапов в создании ПО (milestones), т.е. в терминах динамических аспектов процесса, с другой.

8. Microsoft Solutions Framework (MSF)

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

Microsoft Solutions Framework является схемой для принятия решений по планированию и реализации новых технологий в организациях. MSF включает обучение, информацию, рекомендации и инструменты для идентификации и структуризации информационных потоков бизнес-процессов и всей информационной инфраструктуры новых технологий.

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

В момент подготовки данного учебного курса последней версией MSF была 3.1, при этом существовали документы, относящиеся к версии 4.0 beta.

MSF состоит из двух моделей:

  модель проектной группы;

  модель процессов;

и трех дисциплин:

  управление проектами;

  управление рисками;

  управление подготовкой.

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

  Управление программой

  Разработка

  Тестирование

  Управление выпуском

  Удовлетворение потребителя

  Управление продуктом

Жизненный цикл процессов в MSF сочетает водопадную и спиральную модели разработки: проект реализуется поэтапно, с наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться по спирали

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

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

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

9. Гибкие методологии Agile:

Гибкая модель(agile model) представляет собой совокупность различных подходов к разработке ПО и базируется на т. н. «agile-манифесте»:

•  Люди и взаимодействие важнее процессов и инструментов.

•  Работающий продукт важнее исчерпывающей документации.

•  Сотрудничество с заказчиком важнее согласования условий контракта.

•  Готовность к изменениям важнее следования первоначальному плану.

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

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

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

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

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

9.1 scrum

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

В конце каждого этапа (в терминологии Scrum — спринта) готовый продукт предоставляется заказчику. Полученный от заказчика отзыв позволяет выявить возможные проблемы или пересмотреть некоторые аспекты первоначального плана. Прежде чем приступить к описанию жизненного цикла Scrum-проекта, стоит рассказать об основных ролях, принятых в Scrum-методологии: Владелец продукта (Product owner) представляет интересы конечного пользователя. Скрам-мастер (Scrum master) следит за соблюдением принципов Scrum-разработки, координирует процесс, проводит ежедневные собрания (Scrum Meetings). Скрам-команда (Scrum team) участвует в разработке продукта. В скрам-команду входят программисты, тестировщики, аналитики и прочие специалисты. (5-9 чел.) Стейкхолдеры (бизнес-заказчик) и пользователи.

Шаг 1. Создание бэклога продукта Бэклог продукта (Product backlog) представляет собой упорядоченный по степени важности список требований, предъявляемых к разрабатываемому продукту. Элементы этого списка называются Пользовательскими историями (User story (описание функциональной возможности ПО простыми словами, составленное с точки зрения пользователя)). Каждой истории соответствует уникальный ID. Описание каждой истории должно включать в себя набор обязательных полей, необходимых для дальнейшей работы над проектом: Важность (Importance). Степень важности задачи, по мнению владельца продукта. Описывается произвольным числом. Предварительная оценка (Initial estimate). Предварительная оценка объема работ. Измеряется в story point’ах. Как продемонстрировать (How to demo). Описание способа демонстрации завершенной задачи. 9

Шаг 2. Планирование спринта и создание Бэклога спринта На этапе планирования определяется длительность спринта. Короткий спринт позволяет чаще выпускать работающие версии продукта, а, следовательно, чаще получать отзывы от клиента и вовремя выявлять возможные ошибки. С другой стороны, длинные спринты позволяют посвятить решению проблемы больше времени. Оптимальная длина спринта выбирается как нечто среднее между этими двумя решениями и составляет обычно около 2-ух недель. На этом этапе важно взаимодействие владельца продукта и скрамкоманды. Владелец продукта определяет приоритет той или иной задачи, а задача скрамкоманды состоит в определении необходимых трудозатрат. Во время планирования спринта команда выбирает самые приоритетные пользовательские истории из бэклога продукта и решает, каким образом будут решаться поставленные задачи. Истории, выбранные для реализации в течение данного спринта, составляют Бэклог спринта (Sprint backlog). Количество историй, попадающих в бэклог спринта зависит от их длительности в story point’ах, присвоенных каждой истории на этапе предварительной оценки. Это количество выбирается так, чтобы каждая история была успешно реализована к концу спринта.

Шаг 3. Работа над спринтом. Scrum meetings После того, как определены актуальные для данного спринта пользовательские истории, начинается процесс разработки. Для визуализации процесса разработки удобно использовать учетные карточки. Они могут иметь вид больших карточек с названием конкретной истории и маленьких стикеров, описывающих отдельные задачи, необходимые для реализации истории. После начала работы над определенной задачей, ее стикер перемещается из поля «Запланировано» в область «В работе». По завершении работы над задачей, стикер перемещается в поле «Тестирование» и затем, при успешном выполнении тестирования, в поле «Готово». Расположив истории согласно их важности, можно получить представление о текущем состоянии проекта: Также может быть использовано программное обеспечение, предназначенное для такого рода задач. Примером такого ПО может служить, например, Atlassian JIRA. Важной отличительной особенностью Scrum являются ежедневные совещания (Scrum meetings), целью которых является дать команде полную и достоверную информацию о том, на каком этапе находится процесс разработки. Во время совещания каждый участник скрам-команды сообщает о том, какая задача им выполнена, какая будет выполняться и какие у него возникли трудности во время работы.

 Шаг 4. Тестирование и демонстрация продукта Поскольку в идеале результатом каждого спринта является продукт, готовый к работе, важное место в Scrum занимает процесс тестирования. Существуют разные способы свести к минимуму затраты на данном этапе: от уменьшения количества историй в спринте и, как результат, снижения количества ошибок до включения тестировщиков в скрамкоманду.

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

Шаг 5. Ретроспектива. Планирование следующего спринта На основе отзыва о продукте, полученного после демонстрации, проводится ретроспектива. Ее основная цель — определить, как можно улучшить процесс разработки на следующем спринте, чтобы избежать возникших проблем и работать более эффективно. После того, как пути улучшения качества работы были определены, команда может приступать к планированию следующего спринта.

9.2 .Kanban

«KANBAN» стал символом визуализации рабочего процесса (карточки на стенде) и сейчас обозначает стратегию оптимизации потока поставки ценности посредством 10 процесса, использующую систему вытягивания и имеющую ограничение незавершённой работы. Этот метод, демонстрирующий, что происходит в процессе работы, увеличивает предсказуемость процедур, благодаря чему рабочий процесс становится прозрачным и равномерным. Kanban также можно использовать, чтобы достичь большей согласованности действий, а это означает более быстрое достижение стратегических целей

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

Некоторые особенности Kanban-модели жизненного цикла разработки ПО:

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

·  Ограничение одновременно выполняемых задач. Новая задача может ставиться только тогда, когда какая-то из существующих передаётся следующему элементу производственного цикла. 

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

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

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

9.3 extreme Programming (XP)

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

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

Основная проблема данного подхода – интерфейсы между модулями, реализующими эту функцию. Если во всех предыдущих типах жизненного цикла интерфейсы достаточно четко определяются в самом начале разработки, поскольку заранее известны все модули, то при экстремальном подходе интерфейсы проектируются «на лету», вместе с разрабатываемыми модулями.

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

XP ориентирована на:

  командную работу с тесными связями внутри команды и с заказчиком,

  разработку наиболее простых работающих решений,

  гибкое адаптивное планирование

  оперативную обратную связь (путем модульного и функционального тестирования).

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

Основными практиками XP являются

  Планирование процесса

  Частые релизы

  Метафора системы

  Простая архитектура

  Тестирование

  Рефакторинг

  Парное программирование

  Коллективное владение кодом

  Частая интеграция

  40-часовая рабочая неделя

  Стандарты кодирования

  Тесное взаимодействие с заказчиком

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

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

1. Основной процесс разработки

2. Процесс верификации

3. Процесс управления разработкой

4. Вспомогательные (поддерживающие) процессы

Выбор оптимальной модели и методологии ЖЦ

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

Начало выбора: Стартап или нет?
ИТ-стартапы характерны тем, что там все строится на энтузиазме. Далеко не всегда участники работают по 8 ч в день, и если им навязать какую-то методологию и поставить в определенные рамки, то либо весь энтузиазм угаснет, либо никто не будет соблюдать правила. Поэтому для стартапа на начальном этапе формальная методология не нужна. В дальнейшем, когда все стабилизируется, можно перейти к использованию подходящей методологии.

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

·         Если такие риски присутствуют: скорее всего, разработка начнется с прототипов, концептов, моделей и т. п., чтобы выяснить принципиальную возможность задуманного. В таком случае наиболее оптимальной моделью будет спиральная модель. Типичный пример применения этой модели — исследовательские проекты (но не только).

·         Если таких серьезных рисков нет: переходим к вопросу об изменении требований.

Шаг 2: Изменчивость требований

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

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

Шаг 3: Сложность требований
Следующий вопрос касается сложности требований.

·         Когда требования сложные: рекомендуется тщательно продумать все сценарии тестирования еще на этапе анализа и проектирования, разработать тест-планы и тест-кейсы. В таком случае приходит на помощь V-model жизненного цикла.

o    Важно: Применение V-model там, где требования простые, приведет к удорожанию системы и излишней бюрократии.

·         Если требования простые: переходим к вопросу о необходимости формализованного подхода.

Шаг 4: Формализованный подход
Формализованный подход подразумевает, что все процессы ЖЦ детально регламентированы. Это необходимо в сложных больших проектах (медицина, транспорт, энергетика), где системы разрабатываются по отраслевым стандартам и требуют лицензирования.

·         Если требуется формализованный подход: хорошим выбором станут такие фреймворки, как RUP (Rational Unified Process). RUP изначально создан для итеративной модели, но его можно адаптировать и для каскадной.

·         Если формализованный подход не нужен: оптимально использовать Agile-методологии (Скрам, Канбан, XP и др.), которые базируются на живом общении, а не на документации. Переходим к следующему вопросу.

Шаг 5: Скорость или качество (продуктивность или инженерия)
Здесь мы выбираем между быстрым добавлением функционала и высокой инженерной дисциплиной.

·         Высокое качество (инженерия): выбор в пользу Экстремального программирования (XP). XP обеспечивает высокое качество за счет жестких инженерных практик (TDD, непрерывная интеграция, парное программирование).

o    Важно: Для максимального эффекта XP требует использования всех 12 практик, а также опытной команды. Проект на XP может получиться дороже.

·         Максимальная продуктивность (скорость): выбор между методологиями, ориентированными на поток задач и постоянные улучшения. Переходим к следующему вопросу.

Шаг 6: Постоянные улучшения процесса

·         Если улучшения нужны (команда неслаженная, процесс не отлажен, либо это новый проект): хорошим выбором станет Скрам (Scrum). Он ориентирован на постоянное усовершенствование процесса через ретроспективы и итеративный подход.

·         Если улучшения не нужны, процесс отлажен, и нужно просто сконцентрироваться на выполнении задач: переходим к ограничениям по времени.

Шаг 7: Длительность и тип работ

·         Если проект ограничен по времени (желательно 60–90 дней): хорошо подойдет RAD (Rapid Application Development). RAD имеет много общего с Agile, но имеет жесткое ограничение по длительности.

·         Если проект бессрочный (например, поддержка): оптимален Канбан. Он похож на непрерывный конвейер, хорошо работает на проектах поддержки, но плохо подходит для разработки сложной архитектуры с нуля.

Примечания по совместимости:

·         Практики экстремального программирования (например, парное программирование) можно использовать в других методологиях (например, в Скраме) для решения локальных задач, даже если полный переход на XP не планируется.

·         Когда процесс в проекте становится отлаженным, а архитектура стабилизируется, можно переходить от более «церемониальных» методологий (Скрам) к более потоковым (Канбан).

?? Задача 4. Выбор модели жизненного цикла разработки ПО ??

Цель задания:

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

Условия задачи

Вам предложено 8 проекта с разными характеристиками. Для каждого проекта:

1. Выберите наиболее подходящую модель ЖЦ из списка:
• Каскадная (Waterfall)
• Итерационная с промежуточным контролем
• Спиральная (Spiral Model)
• Инкрементальная
• RAD (Rapid Application Development)
• V-образная (V-Model)
• Гибкие методологии (Agile/Scrum/Kanban)
2. Обоснуйте выбор, указав:
• Почему эта модель лучше других подходит для проекта.
• Какие её особенности помогут решить поставленные задачи.
3. Опишите риски, которые могут возникнуть при использовании выбранной модели.

Проекты для анализа

Проект 1: Разработка банковской системы для обработки платежей

• Требования: Четкие, строго регламентированные (соответствие законодательству).
• Сроки: Жесткие, фиксированные.
• Бюджет: Ограниченный.
• Команда: 15 человек (аналитики, разработчики, тестировщики).
• Особенности: Высокие требования к безопасности и надежности.

Проект 2: Мобильное приложение для доставки еды

• Требования: Частично определены, возможны изменения по feedback пользователей.
• Сроки: Гибкие, важна быстрая поставка MVP.
• Бюджет: Средний.
• Команда: 6 человек (full-stack разработчики, дизайнер).
• Особенности: Необходимость частых обновлений и A/B-тестирования.

Проект 3: Система управления космическим спутником

• Требования: Сложные, высокорискованные, могут уточняться в процессе.
• Сроки: Длительные (3+ года).
• Бюджет: Крупный.
• Команда: 30+ человек (инженеры, программисты, физики).
• Особенности: Критичность к ошибкам, необходимость управления рисками.

Проект 4: Разработка государственной информационной системы учета налогов

• Требования: Четкие, строго регламентированные (налоговый кодекс, приказы Минфина).
• Сроки: Фиксированные (к началу налогового периода).
• Бюджет: Ограниченный (госзаказ).
• Команда: 20 человек (архитекторы, backend-разработчики, тестировщики, специалисты по безопасности).
• Особенности: Высокие требования к сохранности и конфиденциальности данных, строгое соответствие законодательству.

Проект 5: Разработка мобильной игры в жанре гипер-казуал

• Требования: Изначально определены только общая механика, сильно меняются на основе метрик удержания и монетизации.
• Сроки: Очень сжатые, ключевой показатель — скорость выхода на рынок для проверки гипотезы.
• Бюджет: Низкий.
• Команда: 5 человек (гейм-дизайнер, 2 программиста, художник).
• Особенности: Необходимость быстро выпускать множество прототипов, постоянно обновлять продукт на основе данных аналитики.

Проект 6: Создание системы управления умным домом для нового производителя бытовой техники

• Требования: Частично определены, будут уточняться после проведения маркетинговых исследований и тестовых продаж.
• Сроки: Средние (1.5 года), с возможностью сдвига для захвата доли рынка.
• Бюджет: Высокий.
• Команда: 25 человек (embedded-разработчики, IoT-инженеры, дизайнеры интерфейсов).
• Особенности: Необходимость тесной интеграции программного и аппаратного обеспечения, работа с прототипами "железа".

Проект 7: Разработка медицинского программного обеспечения для диагностики (анализ МРТ-снимков)

• Требования: Строгие, регламентированные (медицинские стандарты, необходимость сертификации), но алгоритмы могут дорабатываться по мере обучения нейросети.
• Сроки: Длительные (2+ года) из-за длительного цикла тестирования и сертификации.
• Бюджет: Крупный.
• Команда: 40+ человек (биоинформатики, data scientists, врачи-рентгенологи, разработчики, тестировщики).
• Особенности: Критическая важность безошибочной работы, необходимость соблюдения медицинских стандартов и этики.

Проект 8: Заказная платформа для проведения корпоративных онлайн-тренингов

• Требования: Определены на уровне концепции, детали прорабатываются совместно с заказчиком в процессе демонстрации прототипов.
• Сроки: Жесткие (к началу учебного года в компании-заказчике).
• Бюджет: Средний.
• Команда: 8 человек (full-stack разработчики, UX/UI дизайнер, менеджер проекта).
• Особенности: Необходимость быстрой разработки и активного вовлечения заказчика для уточнения требований.

?? Задача 5. «Создай свой ЖЦ!»

Формат: групповая работа (3–4 человека в группе).

Задание:
Каждая группа получает описание реального сценария разработки ПО:

Группа 1

Мобильное приложение для учёта личных расходов и бюджетирования

• Платформа: Android / iOS
• Функции: добавление трат, категории, графики, напоминания, синхронизация с облаком
• Особенности: работа с локальной БД, пользовательская аутентификация, простой UI

Группа 2

Веб-сервис для онлайн-обучения (мини-«Юрайт» или «Stepik»)

• Платформа: веб (браузер)
• Функции: каталог курсов, прохождение уроков, тесты, прогресс пользователя
• Особенности: роли (студент/преподаватель), загрузка материалов, система оценок

Группа 3

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

• Платформа: десктоп (Python + Tkinter / PyQt или веб через Flask + Canvas)
• Функции: выбор алгоритма, настройка параметров, экспорт изображений
• Особенности: связь с вашими проектами (Turtle, Matplotlib, PIL), образовательное назначение

Группа 4

Чат-бот для технической поддержки студентов университета

• Платформа: Telegram / веб-виджет
• Функции: ответы на частые вопросы, маршрутизация запросов, интеграция с FAQ
• Особенности: простая NLP-логика или правило-ориентированный подход, база знаний

Группа 5

Система управления задачами для учебной группы (аналог Trello или Todoist)

• Платформа: веб или кроссплатформенное PWA
• Функции: создание досок, карточек, сроков, совместная работа
• Особенности: совместное редактирование, уведомления, роль «куратора»

Группа 6

Интерактивный тренажёр по алгебре для школьников (7–9 классы)

• Платформа: веб или десктоп
• Функции: генерация задач, проверка решений, подсказки, статистика успехов
• Особенности: связь с уроками алгебры, визуализация (графики функций), адаптивная сложность

Задачи группы:

1. Выбрать модель ЖЦ (каскадная, спиральная и т.д.) и обосновать выбор.
2. Разбить проект на этапы (постановка задачи, проектирование и т.д.).
3. Указать, какие документы будут созданы на каждом этапе.

Назначить роли в команде (аналитик, разработчик, тестировщик

Контрольные вопросы:

1.      Дайте определение «модели жизненного цикла программного обеспечения» и назовите её основные структурные элементы.

2.      Каков главный принцип каскадной (водопадной) модели? Перечислите её основные фазы в правильной последовательности-2.

3.      Почему в каскадной модели этап тестирования считается критически важным и в то же время проблемным? На каком этапе он обычно проводится?-2

4.      В чем заключаются ключевые достоинства каскадной модели, делающие её применимой для определённых проектов?-4-9

5.      Какие проектные условия являются идеальными для выбора каскадной модели? Приведите пример такого проекта-2.

6.      Опишите основную идею спиральной модели жизненного цикла. Что происходит на каждом витке «спирали»?

7.      В чем заключается принципиальное различие между итерационной и инкрементальной моделью? Можно ли их использовать вместе?-3-10

8.      Какой подход к разработке — итерационный или инкрементальный — лучше подходит для проекта с постоянно меняющимися или плохо определёнными требованиями? Обоснуйте свой выбор-10.

9.      Спиральная модель часто считается комбинацией двух других подходов. Каких именно и за счёт чего это достигается?-4

10.  Назовите главный риск, связанный с использованием спиральной модели, и как его можно минимизировать?

11.  Что такое прототип в контексте моделей ЖЦ и какова его основная цель в таких моделях, как RAD или спиральная?-4

12.  Перечислите четыре ценности Манифеста гибкой (Agile) разработки. Как они влияют на процесс разработки ПО?

13.  В чем заключается ключевое отличие подхода Agile от каскадной модели с точки зрения структуры процесса и работы с требованиями?-1

14.  Опишите базовый рабочий цикл в Scrum. Что такое «спринт», и какие ключевые события в него входят?-1

15.  Каковы основные практики Экстремального программирования (XP), направленные на обеспечение высокого качества кода? Назовите не менее трёх-5-6.

16.  Какой принцип лежит в основе методологии Kanban и как он визуализируется в работе команды?

17.  Методология RUP также использует итерационный подход. Чем её фазы (Inception, Elaboration, Construction, Transition) отличаются от простых циклов разработки?-3

18.  V-образная модель делает особый акцент на тестировании. Как в ней организована связь между этапами разработки и этапами тестирования?

19.  Для каких типов проектов и условий наиболее подходит модель быстрой разработки приложений (RAD)?

20.  Microsoft Solutions Framework (MSF) объединяет идеи разных моделей. Какой известный инструмент управления используется в MSF для балансировки ключевых ограничений проекта (сроки, ресурсы, содержание)?

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

Если вам нужна помощь в составлении сравнительной таблицы по этим моделям или более глубокий разбор какой-либо конкретной методологии — напишите.

Скачано с www.znanio.ru