Жизненный цикл программной системы основные этапы

Аннотация: Понятие жизненного цикла программных систем (ЖЦ ПС) является одним из базовых в программной инженерии.
5.1. Понятие жизненного цикла программных систем
ЖЦ ПС определяется как период времени, который начинается с момента принятия решения о необходимости создания ПС и закачивается в момент ее полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим состав процессов ЖЦ ПС, является международный стандарт ISO/IEC 12207: 1995 “Information Technology – Software Life Cycle Process” (ISO – International Organization for Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике). Этот стандарт определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПС.
В данном стандарте ПС (или программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документацией и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные (Г. Майерс называет это трансляцией данных [11]). Каждый процесс характеризуется определенными задачами и методами их решения. В свою очередь, каждый процесс разделен на набор действий, а каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным).
Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения (ПО) первоначально, в 70-е годы прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации – серии ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно.
Процессы создания автоматизированных систем (АС), в состав которых входит и ПО, регламентированы стандартами ГОСТ 34.601-90 “Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания”, ГОСТ 34.602-89 “Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы” и ГОСТ 34.603-92 “Информационная технология. Виды испытаний автоматизированных систем”. Однако многие положения этих стандартов устарели, а другие отражены недостаточно, чтобы их можно было применять для серьезных проектов создания ПС. Поэтому в отечественных разработках целесообразно использовать современные международные стандарты.
В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ ПО разделены на три группы (рис.5.1).
Рис.
5.1.
Процессы жизненного цикла программного обеспечения
В группах определено пять основных процессов: приобретение, поставка, разработка, эксплуатация и сопровождение. Восемь вспомогательных процессов обеспечивают выполнение основных процессов, а именно документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем. Четыре организационных процесса обеспечивают управление, создание инфраструктуры, усовершенствование и обучение.
5.2. Основные процессы ЖЦ ПС
Процесс приобретения состоит из действий и задач заказчика, приобретающего ПС. Данный процесс охватывает следующие действия [2]:
- инициирование приобретения;
- подготовку заявочных предложений;
- подготовку и корректировку договора;
- надзор за деятельностью поставщика;
- приемку и завершение работ.
Инициирование приобретения включает следующие задачи:
- определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы, программных продуктов или услуг;
- анализ требований, предъявляемых к системе;
- принятие решения относительно приобретения, разработки или усовершенствования существующего ПО;
- проверку наличия необходимой документации, гарантий, сертификатов, лицензий и поддержки в случае приобретения программного продукта;
- подготовку и утверждение плана приобретения, включающего требования к системе, тип договора, ответственность сторон и т.д.
Заявочные предложения должны содержать:
- требования, предъявляемые к системе;
- перечень программных продуктов;
- условия приобретения и соглашения;
- технические ограничения (например, по среде функционирования системы).
Заявочные предложения направляются к выбранному поставщику или нескольким поставщикам в случае тендера. Поставщик – это организация, которая заключает договор с заказчиком на поставку системы, ПО или программной услуги на условиях, оговоренных в договоре.
Подготовка и корректировка договора включает следующие задачи:
- определение заказчиком процедуры выбора поставщика, включающей критерии оценки предложений возможных поставщиков;
- выбор конкретного поставщика на основе анализа предложений;
- подготовку и заключение договора с поставщиком;
- внесение изменений (при необходимости) в договор в процессе его выполнения.
Надзор за деятельностью поставщика осуществляется в соответствии с действиями, предусмотренными в процессах совместной оценки и аудита. В процессе приемки подготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки.
Процесс поставки охватывает действия и задачи, выполняемые поставщиком, который снабжает заказчика программным продуктом или услугой. Данный процесс включает следующие действия:
- инициирование поставки;
- подготовку ответа на заявочные предложения;
- подготовку договора;
- планирование работ по договору;
- выполнение и контроль договорных работ и их оценку;
- поставку и завершение работ.
Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятии решения, соглашаться ли с выставленными требованиями и условиями или предложить свои (согласовать).
Планирование включает следующие задачи:
- принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;
- разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственности, технические требования к среде разработки и ресурсам, управление субподрядчиками и др.
Процесс разработки предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПО и его компонентов в соответствии с заданными требованиями. Сюда включается оформление проектной и эксплуатационной документации, подготовка материалов, необходимых для проверки работоспособности, и качества программных продуктов, материалов, необходимых для организации обучения персонала и др.
Процесс разработки включает следующие действия:
- подготовительную работу;
- анализ требований, предъявляемых к системе;
- проектирование архитектуры системы;
- анализ требований, предъявляемых к программному обеспечению;
- проектирование архитектуры программного обеспечения;
- детальное проектирование программного обеспечения;
- кодирование и тестирование программного обеспечения;
- интеграцию программного обеспечения;
- квалификационное тестирование программного обеспечения;
- интеграцию системы;
- квалификационное тестирование системы;
- установку программного обеспечения;
- приемку программного обеспечения.
Подготовительная работа начинается с выбора модели ЖЦ ПО, соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбирать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ.
Анализ требований, предъявляемых к системе, подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности, безопасности, требований к внешним интерфейсам, производительности и т.д. Требования к системе оцениваются, исходя из критериев реализуемости и возможности проверки при тестировании.
Проектирование архитектуры системы заключается в определении компонентов ее оборудования (аппаратуры), программного обеспечения и операций, выполняемых эксплуатирующим систему персоналом. Архитектура системы должна соответствовать требованиям, предъявляемым к системе, а также принятым проектным стандартам и методам.
Анализ требований к программному обеспечению предполагает определение следующих характеристик для каждого компонента ПО [11]:
- функциональных возможностей, включая характеристики производительности и среды функционирования компонента;
- внешних интерфейсов;
- спецификаций надежности и безопасности;
- эргономических требований;
- требований к используемым данным;
- требований к установке и приемке;
- требований к пользовательской документации;
- требований к эксплуатации и сопровождению.
Требования к программному обеспечению оцениваются, исходя из критериев соответствия требованиям, предъявляемым к системе в целом, реализуемости и возможности проверки при тестировании.
Проектирование архитектуры ПО включает следующие задачи для каждого компонента ПО:
- трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;
- разработку и документирование программных интерфейсов ПО и баз данных (БД);
- разработку предварительной версии пользовательской документации;
- разработку и документирование предварительных требований к тестам и плана интеграции ПО.
Детальное проектирование ПО включает следующие задачи:
- описание компонентов ПО и интерфейсов между ними на более низком уровне, достаточном для последующего кодирования и тестирования;
- разработку и документирование детального проекта базы данных;
- обновление (при необходимости) пользовательской документации;
- разработку и документирование требований к тестам и плана тестирования компонентов ПО;
- обновление плана интеграции ПО.
Кодирование и тестирование ПО включает следующие задачи:
- кодирование и документирование каждого компонента ПО и базы данных, а также подготовку совокупности тестовых процедур и данных для их тестирования;
- тестирование каждого компонента ПО и БД на соответствие предъявляемым к ним требованиям с последующим документированием результатов тестирования;
- обновление документации (при необходимости);
- обновление плана интеграции ПО.
Интеграция ПО предусматривает сборку разработанных компонентов ПО в соответствии с планом интеграции и тестирования агрегированных компонентов. Для каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые процедуры, предназначенные для проверки каждого из квалификационных требований при последующем квалификационном тестировании. Квалификационное требование – это набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт как соответствующий своим спецификациям и готовый к использованию в условиях эксплуатации.
Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (по возможности) для демонстрации того, что ПО удовлетворяет своим спецификациям и готово к использованию в заданных условиях эксплуатации. Такое тестирование выполняется для каждого компонента программного продукта по всем разделам требований при широком варьировании тестов. При этом также проверяется полнота технической и пользовательской документации и ее адекватность самим компонентам ПО.
Интеграция системы заключается в сборке всех ее компонентов, включая ПО и оборудование. После интеграции система, в свою очередь, подвергается квалификационному тестированию на соответствие предъявляемым к ней требованиям. При этом также производится оформление и проверка полного комплекта документации на систему.
Установка ПО осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПО и БД. Если устанавливаемое ПО заменяет существующую систему, разработчик должен обеспечить их параллельное функционирование в соответствии с договором.
Приемка ПО предусматривает оценку результатов квалификационного тестирования ПО и системы и документирование результатов оценки, которые производятся заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПО заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку.
Процесс эксплуатации охватывает действия и задачи организации оператора, эксплуатирующего систему. Процесс эксплуатации включает следующие действия.
Подготовительная работа, которая включает проведение оператором следующих задач:
- планирование действий и работ, выполняемых в процессе эксплуатации, и установка эксплуатационных стандартов;
- определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.
- Эксплуатационное тестирование, осуществляемое для каждой очередной редакции программного продукта, после чего эта редакция передается в эксплуатацию.
- Собственно эксплуатация системы, которая выполняется в предназначенной для этого среде в соответствии с пользовательской документацией.
- Поддержка пользователей – оказание помощи и консультаций при обнаружении ошибок в процессе эксплуатации ПО.
Процесс сопровождения представляет собой действия и задачи, которые выполняются сопровождающей организацией, при изменениях (модификациях) программного продукта и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации или адаптации ПО.
Изменения, вносимые в соответствующее ПО, не должны нарушать его целостность. Процесс сопровождения включает его перенос в другую среду (миграцию) и заканчивается снятием ПО с эксплуатации.
Процесс сопровождения охватывает следующие действия:
- подготовительную работу (планирование действий и работ, определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения);
- анализ проблем и запросов на модификацию ПО (анализ сообщений о возникшей проблеме или запроса на модификацию, оценка масштаба, стоимости модификации, получаемого эффекта, оценка целесообразности модификации);
- модификацию ПО (внесение изменений в компоненты программного продукта и документацию в соответствии с правилами процесса разработки);
- проверку и приемку (в части целостности модифицируемой системы);
- перенос ПО в другую среду (конвертирование программ и данных, параллельная эксплуатация ПО в старой и новой среде в течение некоторого периода времени);
- снятие ПО с эксплуатации по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей. При этом программные продукты и документации подлежат архивированию в соответствии с договором.
Источник
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 12 ноября 2018; проверки требуют 6 правок.
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1].
Стандарты жизненного цикла ПО[править | править код]
- ГОСТ 34.601-90
- ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes» (российский аналог — ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств)
Стандарт ГОСТ 34.601-90[править | править код]
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС):
- Формирование требований к АС
- Обследование объекта и обоснование необходимости создания АС
- Формирование требований пользователя к АС
- Оформление отчета о выполнении работ и заявки на разработку АС
- Разработка концепции АС
- Изучение объекта
- Проведение необходимых научно-исследовательских работ
- Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
- Оформление отчета о проделанной работе
- Техническое задание
- Разработка и утверждение технического задания на создание АС
- Эскизный проект
- Разработка предварительных проектных решений по системе и её частям
- Разработка документации на АС и её части
- Технический проект
- Разработка проектных решений по системе и её частям
- Разработка документации на АС и её части
- Разработка и оформление документации на поставку комплектующих изделий
- Разработка заданий на проектирование в смежных частях проекта
- Рабочая документация
- Разработка рабочей документации на АС и её части
- Разработка и адаптация программ
- Ввод в действие
- Подготовка объекта автоматизации
- Подготовка персонала
- Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
- Строительно-монтажные работы
- Пусконаладочные работы
- Проведение предварительных испытаний
- Проведение опытной эксплуатации
- Проведение приёмочных испытаний
- Тестирование АС.
- Сопровождение АС.
- Выполнение работ в соответствии с гарантийными обязательствами
- Послегарантийное обслуживание
Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.
Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)[править | править код]
Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes».
Данный стандарт, используя устоявшуюся терминологию, устанавливает общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов.
Процессы жизненного цикла ПО[править | править код]
Стандарт группирует различные виды деятельности, которые могут выполняться в течение жизненного цикла программных систем, в семь групп процессов. Каждый из процессов жизненного цикла в пределах этих групп описывается в терминах цели и желаемых выходов, списков действий и задач, которые необходимо выполнять для достижения этих результатов.
- процессы соглашения — два процесса;
- процессы организационного обеспечения проекта — пять процессов;
- процессы проекта — семь процессов;
- технические процессы — одиннадцать процессов;
- процессы реализации программных средств — семь процессов;
- процессы поддержки программных средств — восемь процессов;
- процессы повторного применения программных средств — три процесса.
- Основные:
- Приобретение (действия и задачи заказчика, приобретающего ПО)
- Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
- Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
- Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)
- Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение — внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
- Вспомогательные
- Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
- Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
- Обеспечение качества (обеспечение гарантий того, что ИС и процессы её ЖЦ соответствуют заданным требованиям и утверждённым планам)
- Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
- Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
- Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
- Аудит (определение соответствия требованиям, планам и условиям договора)
- Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
- Организационные
- Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
- Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
- Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
- Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:
- Инициирование приобретения
- Подготовка заявочных предложений
- Подготовка и корректировка договора
- Надзор за деятельностью поставщика
- Приёмка и завершение работ
Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:
- Формирование требований к системе
- Формирование списка программных продуктов
- Установление условий и соглашений
- Описание технических ограничений (среда функционирования системы и т. д.)
Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями[править | править код]
Модель жизненного цикла ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Стандарт ГОСТ Р ИСО/МЭК 12207-2010 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ ПО включает в себя:
- Стадии;
- Результаты выполнения работ на каждой стадии;
- Ключевые события — точки завершения работ и принятия решений.
Стадия — часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-2010, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.
См. также[править | править код]
- Версия программного обеспечения
Примечания[править | править код]
- ↑ Стандарт IEEE Std 610.12, Глоссарий
Литература[править | править код]
- Братищенко В.В. Проектирование информационных систем. — Иркутск: Изд-во БГУЭП, 2004. — 84 с.
- Вендров А.М. Проектирование программного обеспечения экономических информационных систем. — М.: Финансы и статистика, 2000.
- Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. — М.: Интернет-университет информационных технологий – ИНТУИТ.ру, 2005.
- Мишенин А.И. Теория экономических информационных систем. — М.: Финансы и статистика, 2000. — 240 с.
Ссылки[править | править код]
- Зараменских Е.П. (2014) Управление жизненным циклом информационных систем. Новосибирск : СИБПРИНТ (недоступная ссылка)
- Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. (2005). Курс лекций “Проектирование ИС” М.: Интернет-университет информационных технологий
- Коровкина Н. Л., Куприянов Ю. В., Грекул В. И. (2010) Методические основы управления ИТ-проектами. М. : Национальный открытый университет «ИНТУИТ», 2010
- Wissenschaftliche Kommission Wirtschaftsinformatik im Verband der Hochschulleh- rer für Betriebswirtschaft, (2007) Rahmenempfehlung für die Universitätsausbildung in Wirt- schaftsinformatik. Wirtschaftsinformatik. 49 (2007) 4, S. 318–325.
Источник