Модели жизненного цикла программной системы.

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

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

I Классический последовательный тип ЖЦ, каскадная (водопадная) модель.

Старейшим типом ЖЦ является классический жизненный цикл (автор Уинстон Ройс, 1970).

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

Основные этапы данного типа ЖЦ:

- планирование;

- формирование требований или системный анализ;

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

- конструирование (кодирование);

- интеграция и тестирование;

- поддержка и эксплуатация (сопровождение).

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

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

Анализ требований относится к программному элементу – программному обеспечению (ПО). Уточняются и детализируются его функции, характеристики и интерфейс. На этом этапе проектировщик должен ответить на вопрос: “Что система должна делать? ”.

Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Проектирование состоит в создании представлений:

- архитектуры ПО;

- модульной структуры ПО;

- алгоритмической структуры ПО;

- структуры данных;

- входного и выходного интерфейса (входных и выходных форм данных).

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

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

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

Поддержка и эксплуатация (сопровождение) – это внесение изменений в эксплуатируемое ПО.

Цели изменений:

- исправление ошибок;

- адаптация к изменениям внешней для ПО среды;

- усовершенствование ПО по требованиям заказчика.

Данный тип ЖЦ применим, когда:

– требования к системе четко определены и не меняются со временем;

– имеется достаточно большой опыт реализации подобного рода систем;

– время реализации проекта составляет от нескольких месяцев до года.

Реализация проекта по данному типу ЖЦ легко планируется и контролируется. Однако для этого необходимо заранее иметь все требования к продукту, реально в начале проекта требования заказчика определены лишь частично. Данный тип ЖЦ не приспособлен к изменениям требований к системе. Результаты проекта доступны заказчику только в конце работы. В силу приведенных выше недостатков, на данный момент классический последовательный типЖЦ не применяется.

II Эволюционный тип ЖЦ

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

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

– сложность в управлении и контроле выполнения проекта;

– сложность оценки затрат на разработку;

– риск бесконечного улучшения системы.

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

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

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

Модель определяет четыре действия:

- Планирование – определение целей, вариантов и ограничений.

- Анализ риска – анализ вариантов и распознавания/выбор риска.

- Конструирование – разработка продукта следующего уровня.

- Оценивание – оценка заказчиком текущих результатов конструирования.

Достоинства спиральной модели:

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

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

3) включает шаг системного подхода в итерационную структуру разработки;

4) использует моделирование для уменьшения риска и совершенствования программного изделия.

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

1) новизна (отсутствует достаточная статистика эффективности модели);

2) повышенные требования к заказчику;

3) трудности контроля и управления временем разработки.

Требования к системе. Модель FURPS+

Требования (requirements) – это возможности или условия, которым должна соответствовать система или проект. Основная задача этапа определения требований – найти, обсудить и зафиксировать, что действительно требуется от системы в форме, понятной и заказчикам ПО и членам команды разработчиков.

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

– функциональные требования (Functionality) – свойства, возможности, безопасность;

– требования к удобству использования (Usability) – человеческий фактор, справочная система, документация;

– требование к надежности (Reliability) – частота сбоев, возможность восстановления и предсказуемость поведения;

– требования к производительности (Performance) – время отклика, точность, доступность использования ресурсов;

– требования возможности сопровождения (Supportability) – адаптивность, возможность поддержки, соответствие международным стандартам, возможность конфигурирования, возможность расширения.

При этом символом “+” обозначены дополнительные условия, к которым относятся:

– проектные ограничения;

– требования управления системой;

– требования к графическому интерфейсу пользователя;

– физические требования;

– юридические требования – авторское право и т. п.

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

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

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

Помимо требований, классифицированных по модели FURPS+, полезно рассмотреть следующие вопросы:

– cовместимости (система должна быть совместима с существующими и проектируемыми информационными системами для данного объекта);

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

– адаптируемости, гибкости и возможности настройки под конкретные нужды пользователей;

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

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

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

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

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