Жизненный цикл программного обеспечения

Материал из ПИЭ.Wiki

Перейти к: навигация, поиск

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

Содержание

Стандарты жизненного цикла ПО

  • ГОСТ 34.601-90
  • ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207-99)

Методологии разработки ПО

  • Rational Unified Process (RUP).
  • Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
  • Экстремальное программирование (Extreme Programming, XP). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.

Стандарт ГОСТ 34.601-90

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

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

Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

Стандарт ISO/IEC 12207/ и его применение

Стандарт ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» является основным нормативным документом, регламентирующим состав процессов жизненного цикла ПО. Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

Процессы жизненного цикла ПО

  • Основные:
    • Приобретение (действия и задачи заказчика, приобретающего ПО)
    • Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
    • Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
    • Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)
    • Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение — внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
  • Вспомогательные
    • Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
    • Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
    • Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)
    • Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
    • Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
    • Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
    • Аудит (определение соответствия требованиям, планам и условиям договора)
    • Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
  • Организационные
    • Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
    • Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
    • Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
    • Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

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

  1. Инициирование приобретения
  2. Подготовка заявочных предложений
  3. Подготовка и корректировка договора
  4. Надзор за деятельностью поставщика
  5. Приемка и завершение работ

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

  1. Формирование требований к системе
  2. Формирование списка программных продуктов
  3. Установление условий и соглашений
  4. Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

  1. Стадии;
  2. Результаты выполнения работ на каждой стадии;
  3. Ключевые события — точки завершения работ и принятия решений.

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

Модели жизненного цикла ПО

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

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

  • Задачная модель;
  • каскадная модель (или системная) (70-85 г.г.);
  • спиральная модель (настоящее время).

Задачная модель

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

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

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

Каскадная модель

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

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

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

Этапы проекта в соответствии с каскадной моделью:

  1. Формирование требований;
  2. Проектирование;
  3. Реализация;
  4. Тестирование;
  5. Внедрение;
  6. Эксплуатация и сопровождение.


Файл:Рис1.gif

Рис. 1. Каскадная схема разработки

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


Файл:Рис2.gif

Рис. 2. Реальный процесс разработки ПО по каскадной схеме

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

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

Для преодоления перечисленных проблем была предложена спиральная модель жизненного цикла (рис. 3), которая была разработана в середине 1980-х годов Барри Боэмом. Она основывается на начальных этапах жизненного цикла: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов.

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

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

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

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

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


Файл:Рис3.gif

Рис 3. Спиральная модель ЖЦ ИС

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

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

Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:

  • фаза определения требований и анализа;
  • фаза проектирования;
  • фаза реализации;
  • фаза внедрения.

На каждой итерации оцениваются:

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


Преимущества итерационного подхода:

  • Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.
  • При использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40 % всех затрат в конце проекта).
  • Итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие.
  • Итерационный подход упрощает повторное использование компонентов (реализует компонентный подход к программированию). Это обусловлено тем, что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итераций позволяет выявить общие многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться.
  • Спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы.
  • Итерационный подход дает возможность совершенствовать процесс разработки — анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.


--Гвоздев Сергей 23:46, 30 мая 2010 (UTC)

Просмотры
Инструменты

Besucherzahler russian mail order brides
счетчик посещений
Rambler's Top100
Лингафонные кабинеты  Интерактивные доски  Интерактивная приставка Mimio Teach