Понятие жизненного цикла ИС (ЖЦ ИС). Спиральная модель ЖЦ ИС.

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

Группы процессов

· Основные (приобретение, поставка, разработка, эксплуатация, сопровождение)

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

· организационные — определяют действия и задачи, выполняемые заказчиком и разработчиком для

 управления своими процессами (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение)

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

.итерационная (спиральная) с середины 80-х гг. XX в.

+упрощается внесение изменений

+постепенная интеграция отдельных элементов ИС

+уменьшение уровня рисков

+большая гибкость в управлении проектом

+упрощает повторное использование компонентов

+ИС более надежна и устойчива

+возможность совершенствования процесса разработки

-Сложность определения момента перехода к следующей итерации

-Планирование работ на основеa накопленного опыта

Анализ требований. Функциональные и нефункциональные требования.

Требования (requirements):

· подробное описание того, что должно быть реализовано

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

функциональные — какое поведение должна предлагать система

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

Производительность:

Время отклика (Response Time)

Быстрота реагирования (Responsiveness)

Время задержки (Latency)

Пропускная способность (Throughput) количество транзакций в секунду

 (Transactions per second, TPS)

Загрузка (Load)

Чувствительность к загрузке (Load Sensitivity)

     A: отклик — 0,5 с для 10-20 пользов.

     B: отклик — 0,2 с для 10 пользов., 2 с для 20 пользов.

Эффективность (Efficiency)

Мощность (Capacity)

Масштабируемость (Scalability)

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

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

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

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