Состав и структура по

ПО: специальное и общее.

Специальное ПО- функциональные программы, реализующие конкретные алгоритмы.

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

Общее:

-ПО вычислительного процесса, включающие ОС и систему функционального контроля

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

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

Раздел 1.Жизненный цикл программного обеспечения (жцпу). Понятия и основные этапы жцпо

ЖЦПО включает в себя все этапы развития программного комплекса от момента возникновения потребности в программах определённого назначения до полного прекращения их эксплуатации.

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

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

-эксплуатация- непосредственное использование ПО

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

В каждой предстоящей модернизации анализируется и оценивается по критериям:

-на сколько улучшаются эксплуатационные характеристики ПО

-каковы затраты на модернизацию

-какое влияние может оказать данная корректировка на функционирование других компонентов ПО

-какова срочность оповещения пользователя о появлении новой версии

-для какого числа пользователей полезна данная модернизация

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

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

Классификация ПО по длительности ЖЦ

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

Модели ЖЦПО

В настоящее время получили распространение три модели ЖЦПО:

-каскадная- разработана в 60-70 годах Боулином

-спиральная- разработана Рейлином 80-90 года

-инкрементная- 90е годы

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

Каскадная модель- при работе с классической каскадной моделью ЖЦ разбивается на этапы причём переход к следующему этапу осуществляется только после полного завершения всех работ по текущему этапу. Этап завершается выпуском конструкторской документации.

Достоинства:

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

Недостатки:

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

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

Недостатки:

-запаздывания результатов

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

Для решения этих проблем была разработана спиральная модель ЖЦПО.

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

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

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

ЖЦПО в соответствии со стандартом ISO/IEC-12207:1995

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

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

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

-организационные- управление, усовершенствование, обучение, создание инфраструктуры.

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

Управления требованиями к разработке программных систем

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

Требования- условия или характеристика, которым должна удовлетворять система.

Все требования разбиваются на три уровня:

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

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

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

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

Функциональные требования

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