Жизненный цикл программных систем
В общем случае программная система помимо собственно программ содержит еще и аппаратное обеспечение, а также обычно рассматривается в окружении других программно-аппаратных систем.
Под жизненным циклом программной системы обычно понимают весь период времени существования программной системы, начинающийся с момента выработки первоначальной концепции системы и кончающийся тогда, когда система морально устаревает. Понятие ``жизненного цикла'' используется, когда предполагается, что программная система будет иметь достаточно большой срок действия, в отличие от экспериментального программирования, при котором программы прогоняются несколько раз и больше не используются.
Жизненный цикл традиционно моделируется в виде некоторого числа последовательных этапов (или стадий, фаз). В настоящее время не выработано общепринятого разбиения жизненного цикла программной системы на этапы. Иногда этап выделяется как отдельный пункт, иногда - входит в качестве составной части в более крупный этап. Могут варьироваться действия, производимые на том или ином этапе. Нет единообразия и в названиях этих этапов. Поэтому попытаемся вначале описать некоторый обобщенный жизненный цикл программной системы, а затем продемонстрируем несколько примеров различных жизненных циклов с указанием аналогий из этого обобщенного цикла.
Этапы жизненного цикла ПО Жизненный цикл программного обеспечения - период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы:
-1- возникновение и исследование идеи;
-2- анализ требований и проектирование;
-3- программирование;
-4- тестирование и отладка;
-5- ввод программы в действие;
-6- эксплуатация и сопровождение;
-7- завершение эксплуатации.
Следует обратить внимание, что разбиение жизненного цикла на этапы иногда способствует затушевыванию некоторых важных аспектов создания программного обеспечения; особенно это проявляется по отношению к такому необходимому процессу, как итерационная реализация различных этапов жизненного цикла с целью исправления ошибок, изменения решений, которые оказались неправильными, или учета изменений в общих требованиях, предъявляемых к системе.
Примеры описания жизненного цикла
Рассмотрим несколько описаний жизненного цикла программного обеспечения, которые послужат своеобразным комментарием этапам обобщенного жизненного цикла.
В отечественных нормативных документах (например, ГОСТ ЕСПД) принято следующее разграничение на этапы, которое приводится с указанием аналогий из списка, данного в начале раздела:
разработка технического задания (этапы 1 и 2);
технический проект (третий этап до 3.2.1 включительно);
рабочий проект (3.2.2, 4.2.1 и, частично, 4.2, 4.3);
экспериментальное внедрение (4.2 и 4.3);
сдача в промышленную эксплуатацию (этап 5);
промышленная эксплуатация (этап 6).
Подобное описание имеет своим прообразом технологию разработки аппаратных средств и поэтому не вполне учитывает все отличительные особенности проектирования программ. Более подходящим выглядит описание жизненного цикла программного обеспечения, состоящее из 12 этапов, которые очень близки этапам обобщенного жизненного цикла (см. рис. 1.1). В скобках после имени фазы указывается аналог из обобщенного цикла. Практически все этапы заканчиваются проверкой результатов, полученных на соответствующем этапе.
Рис. 1.1 Пример жизненного цикла программных систем
Начало проекта и планирование (этап 1). Определяются необходимые действия, планы и организация управления проектом. Определяются меры по обеспечению непрерывного выполнения фаз жизненного цикла.
Анализ целевых требований (2.1). Определяются, без учета средств реализации, общие характеристики системы, которым она должна удовлетворять. Устанавливается, что и как должна делать система.
Анализ системных требований (2.2). Описывается, как должны удовлетворятся запросы пользователя, в терминах конкретных функциональных понятий описываются действия предполагаемой системы, хранимые данные, используемый интерфейс - все это без учета физической реализации. Проверяется пригодность этих конкретных понятий.
Проектирование системы (3.1). Устанавливается структура системы или, иначе говоря, ее архитектура в терминах основных компонентов этой системы и их предполагаемой реализации (аппаратной, программной, с помощью окружения и т.д.). Устанавливаются требования для каждого компонента, а также стратегию тестирования и интеграции.
Предварительное проектирование программного обеспечения (3.2.1). Определение конкретных программных компонент, которые будут разрабатываться и внедряться в конечную систему. Проверка этого множества компонент на непротиворечивость общим требованиям к программному обеспечению. Определение функциональных, эксплуатационных и тестовых требований к каждому конкретному компоненту.
Детальное проектирование программного обеспечения (3.2.2). В терминах используемых программных конструкций производится описание того, как каждый конкретный компонент будет разрабатываться. Описываются режимы использования каждого компонента в системе.
Кодирование и тестирование программного обеспечения (4.1.1 и 4.1.2). Создание, тестирование отдельных модулей, документирование и приемка программных компонентов, которые составляют программную систему.
Интеграция программного обеспечения (частично 4.2). Тестирование работоспособности и функциональной законченности программных частей системы в предсказуемом окружении (аппаратуре и окружающей среде).
Интеграция системы (4.3). Тестирование работоспособности и функциональной законченности частей общей системы в целом.
Приемка и поставка системы (5). Производится приемка системы заказчиком, и поставка ему системы.
Эксплуатация и сопровождение системы (6). Выпуск последующих вариантов или версий системы, необходимость в которых возникает из-за устранений дефектов, отработки измененных требований и т.д.
Завершение проекта (7). Формирование посториорной модели проектных действий с анализом достоинств, недостатков и т.д., и использование их в качестве основания для улучшения процесса разработки.
В качестве следующего примера рассмотрим неполный жизненный цикл программного обеспечения, без этапов эксплуатации и сопровождения (см. рис. 1.2). В этом варианте не фиксируется последовательность фаз или этапов, а предлагается перечень действий, которые должны быть выполнены на протяжении жизненного цикла программного обеспечения. Эти действия могут быть разбиты или, наоборот, сгруппированы в различные этапы, в зависимости от конкретных условий. Можно выделить следующие этапы жизненного цикла программных систем (в скобках, как и ранее, - аналоги из модели обобщенного цикла):
этап планирования, который определяет и координирует действия по разработке программной системы (этап 1);
этап разработки, на котором создается программная система:
постановку задачи (этап 2),
проектирование (3),
кодирование (4.1.1),
получение исполняемого кода (4.1.1, 4.3);
интегрированный этап, обеспечивающий коррекцию, проверку, и определение полноты программной системы, а также ее выпуск. Этот этап включает в себя верификацию, контроль за конфигурацией системы, оценку качества и проверку взаимодействия между этапами. Из названия этого этапа видно, что он выполняется совместно с другими этапами на протяжении жизненного цикла системы.
Рис. 1.2 Вариант упрощенного жизненного цикла программной системы.
Отсутствие интегрированного этапа в обобщенном жизненном цикле не означает, что проверка производится только там, где это явно указано в названии этапа (например 4.2.1 и 4.2). Каждый этап может считаться завершенным только тогда, когда результаты, полученные на данном этапе, были признаны удовлетворительными, а для этого необходимо производить проверку результатов на каждом этапе. В обобщенном жизненном цикле некоторые проверки были вынесены отдельными пунктами для демонстрации повышенных объемов, сложности и важности этих проверок.
Последовательность этапов жизненного цикла для разных программных систем определяется такими характеристиками как функциональные возможности, сложность, размер, устойчивость, использование ранее полученных результатов, разрабатываемая стратегия и аппаратное обеспечение.
На рис. 1.3. показана последовательность этапов разработки программного обеспечения для отдельных компонентов единой программной системы с различными жизненными циклами.
Рис. 1.3 Последовательность этапов разработки компонент программного обеспечения
Для компонента W из множества системных требований к единому продукту формируется подмножество требований, относящихся к данному компоненту, используются эти требования при формировании проекта программного компонента, реализовывают этот проект в исходном коде и тогда интегрирует компонент с аппаратурой. Компонент X показывает использование ранее разработанного программного обеспечения. Компонент Y показывает использование простой отдельной функции, которая может быть закодирована прямо на основе требований к программному обеспечению. Компонент Z показывает использование прототипной стратегии. Обычно, целями прототипирования является лучшее понимание требований к программному обеспечению и уменьшение технических рисков и рисков разработки при создании конечного продукта. Исходные требования используются как базис для получения прототипа. Этот прототип преобразуется в окружение, типичное для конкретного использования системы при разработке. Результатом преобразований является уточненные данные, которые используются для создания конечного программного продукта.
Практически все этапы жизненного цикла объединяются с верификацией.
Этап планирования
Целями этапа планирования является определение средств для создания программного продукта, которые будут удовлетворять требованиям, предъявляемым к системе, и обеспечивать достаточный уровень надежности. На этом этапе производится:
определение действий на этапах разработки и интегрированном этапе, которые будут посвящены стратегическому планированию и проектированию программной системы. Эффективность определения этих действий - определяющий фактор создания программной системы;
определение жизненного цикла программной системы, включая взаимодействие между этапами, механизм взаимного влияния этапов, критерии оценки системы при переходе от одного этапа к другому;
определение окружения жизненного цикла, имея в виду методы и инструментарий, используемые на каждом этапе. Здесь определяются процедуры, языки программирования, аппаратура, методы и инструменты, которые будут использоваться для разработки, верификации, контроля и выпуска программной системы. Окружение жизненного цикла - важный фактор создания высококачественного программного продукта. Оно может влиять на создание системы как положительно, так и отрицательно;
рассмотрение вопросов стандартов разработки системы. Эти стандарты определяют правила и нормы разработки программной системы. Стандарты используются системами верификации, как основа для сравнения реальных результатов разработки с требуемыми;
формирование дополнительных замечаний к системе;
составление плана создания программной системы;
проработка и проверка плана.
Этап разработки программной системы
Этап разработки программной системы состоит из следующих стадий:
постановка задачи при котором определяются высокоуровневые параметры: функциональные и эксплуатационные требования, интерфейс, требования к надежности и безопасности;
проектирование программной системы, заключающееся в разработке архитектуры продукта и требований к ней;
кодирование, при котором на основе архитектуры и требований к ней получается исходный код системы;
получение исполняемого кода путем компиляции и загрузки исходного кода.
Этап верификации
Верификация программных продуктов представляет собой комбинацию обзора, анализа, разработки тестов и процедур, и выполнение этих процедур. Обзор и анализ обеспечивают оценку точности, полноты и тестопригодности стратегического планирования, архитектуры и исходного кода. Разработка тестов может обеспечить дополнительную оценку внутренней согласованности и полноты постановки задачи. Выполнение тестовых процедур обеспечивает демонстрацию того, что система удовлетворяет требованиям.
Цель верификации программных систем - это определение и выдача отчетов об ошибках, которые могут быть допущены на этапах жизненного цикла. Основные задачи верификации:
определение соответствия высокоуровневых требований требованиям к системе;
учет высокоуровневых требований в архитектуре системы;
соблюдение архитектуры и требований к ней в исходном коде;
определение соответствия исполняемого кода требованиям к системе;
определение средств, используемых для решения вышеперечисленных задач, которые технически корректны и достаточно полны.
Структура программных продуктов
В большей степени программные продукты не являются монолитом и имеют конструкцию (архитектуру) построения - состав и взаимосвязь программных модулей.
Модуль - это самостоятельная часть программы, имеющая определенное назначение и обеспечивающая заданные функции обработки автономно от других программных модулей.
Таким образом, программный продукт обладает внутренней организацией, или же внутренней структурой, образованной взаимосвязанными программными модулями. Это справедливо для сложных и многофункциональных программных продуктов, которые часто называются программными системами.
Структуризация программ выполняется в первую очередь для удобства разработки, программирования, отладки и внесения изменений в программный продукт. Как правило, программные комплексы большой алгоритмической сложности разрабатываются коллективом разработчиков (2 - 15 и более человек). Управлять разработкой программ в условиях применения промышленных технологий изготовления программ можно лишь на научной основе.
Таким образом, структуризация программных продуктов преследует основные цели:
распределить работы по исполнителям, обеспечив приемлемую их загрузку и требуемые сроки разработки программных продуктов;
построить календарные графики проектных работ и осуществлять их координацию в процессе создания программных изделий;
контролировать трудозатраты и стоимость проектных работ и др.
Структурное ``разбиение'' программ на отдельные составляющие служит основой и для выбора инструментальных средств их создания, хотя имеет место и обратное влияние - выбор инструментальных средств разработчика программного обеспечения определяет типы программных модулей. При создании программных продуктов выделяются многократно используемые модули, проводится их типизация и унификация, за счет чего сокращаются сроки и трудозатраты на разработку программного продукта в целом.
Некоторые программные продукты используют модули из готовых библиотек стандартных подпрограмм, процедур, функций, объектов, методов обработки данных.
На рис. 1.4 приведена типовая структура программного продукта, состоящего из отдельных программных модулей и библиотек процедур, встроенных функций, объектов и т.п.
Рис 1.4. Структура программного продукта
Среди множества модулей различают:
головной модуль - управляет запуском программного продукта (существует в единственном числе);
управляющий модуль - обеспечивает вызов других модулей на обработку;
рабочие модули - выполняют функции обработки;
сервисные модули и библиотеки, утилиты - осуществляют обслуживающие функции.
В работе программного продукта активизируются необходимые программные модули. Управляющие модули задают последовательность вызова на выполнение очередною модуля. Информационная связь модулей обеспечивается за счет использования общей базы данных либо межмодульной передачи данных через переменные обмена.
Каждый модуль может оформляться как самостоятельно хранимый файл; для функционирования программного продукта необходимо наличие программных модулей в полном составе.
Структурно-сложные программные продукты разрабатываются как пакеты программ, и чаще всего они имеют прикладной характер - пакеты прикладных программ, или ППП.
ППП (application program package) - это система программ, предназначенных для решения задач определенного класса.
Компоненты ППП объединены общими данными (базой данных), информационно и функционально связаны между собой и обладают свойством системности, т.е. объединению программ присуще новое качество, которое отсутствует для отдельного компонента ППП. Структура ППП, как правило, многомодульная.
http://skif.bas-net.by/bsuir/base/node1.html |
Скачать 164.5 Kb.