Жизненный цикл программного продукта лекции
Аннотация: Понятие жизненного цикла программных систем (ЖЦ ПС) является одним из базовых в программной инженерии.
5.1. Понятие жизненного цикла программных систем
ЖЦ ПС определяется как период времени, который начинается с момента принятия решения о необходимости создания ПС и закачивается в момент ее полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим состав процессов ЖЦ ПС, является международный стандарт ISO/IEC 12207: 1995 “rmation 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]:
- функциональных возможностей, включая характеристики производительности и среды функционирования компонента;
- внешних интерфейсов;
- спецификаций надежности и безопасности;
- эргономических требований;
- требований к используемым данным;
- требований к установке и приемке;
- требований к пользовательской документации;
- требований к эксплуатации и сопровождению.
Требования к программному обеспечению оцениваются, исходя из критериев соответствия требованиям, предъявляемым к системе в целом, реализуемости и возможности проверки при тестировании.
Проектирование архитектуры ПО включает следующие задачи для каждого компонента ПО:
- трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;
- разработку и документирование программных интерфейсов ПО и баз данных (БД);
- разработку предварительной версии пользовательской документации;
- разработку и документирование предварительных требований к тестам и плана интеграции ПО.
Детальное проектирование ПО включает следующие задачи:
- описание компонентов ПО и интерфейсов между ними на более низком уровне, достаточном для последующего кодирования и тестирования;
- разработку и документирование детального проекта базы данных;
- обновление (при необходимости) пользовательской документации;
- разработку и документирование требований к тестам и плана тестирования компонентов ПО;
- обновление плана интеграции ПО.
Кодирование и тестирование ПО включает следующие задачи:
- кодирование и документирование каждого компонента ПО и базы данных, а также подготовку совокупности тестовых процедур и данных для их тестирования;
- тестирование каждого компонента ПО и БД на соответствие предъявляемым к ним требованиям с последующим документированием результатов тестирования;
- обновление документации (при необходимости);
- обновление плана интеграции ПО.
Интеграция ПО предусматривает сборку разработанных компонентов ПО в соответствии с планом интеграции и тестирования агрегированных компонентов. Для каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые процедуры, предназначенные для проверки каждого из квалификационных требований при последующем квалификационном тестировании. Квалификационное требование – это набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт как соответствующий своим спецификациям и готовый к использованию в условиях эксплуатации.
Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (по возможности) для демонстрации того, что ПО удовлетворяет своим спецификациям и готово к использованию в заданных условиях эксплуатации. Такое тестирование выполняется для каждого компонента программного продукта по всем разделам требований при широком варьировании тестов. При этом также проверяется полнота технической и пользовательской документации и ее адекватность самим компонентам ПО.
Интеграция системы заключается в сборке всех ее компонентов, включая ПО и оборудование. После интеграции система, в свою очередь, подвергается квалификационному тестированию на соответствие предъявляемым к ней требованиям. При этом также производится оформление и проверка полного комплекта документации на систему.
Установка ПО осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПО и БД. Если устанавливаемое ПО заменяет существующую систему, разработчик должен обеспечить их параллельное функционирование в соответствии с договором.
Приемка ПО предусматривает оценку результатов квалификационного тестирования ПО и системы и документирование результатов оценки, которые производятся заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПО заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку.
Процесс эксплуатации охватывает действия и задачи организации оператора, эксплуатирующего систему. Процесс эксплуатации включает следующие действия.
Подготовительная работа, которая включает проведение оператором следующих задач:
- планирование действий и работ, выполняемых в процессе эксплуатации, и установка эксплуатационных стандартов;
- определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.
- Эксплуатационное тестирование, осуществляемое для каждой очередной редакции программного продукта, после чего эта редакция передается в эксплуатацию.
- Собственно эксплуатация системы, которая выполняется в предназначенной для этого среде в соответствии с пользовательской документацией.
- Поддержка пользователей – оказание помощи и консультаций при обнаружении ошибок в процессе эксплуатации ПО.
Процесс сопровождения представляет собой действия и задачи, которые выполняются сопровождающей организацией, при изменениях (модификациях) программного продукта и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации или адаптации ПО.
Изменения, вносимые в соответствующее ПО, не должны нарушать его целостность. Процесс сопровождения включает его перенос в другую среду (миграцию) и заканчивается снятием ПО с эксплуатации.
Процесс сопровождения охватывает следующие действия:
- подготовительную работу (планирование действий и работ, определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения);
- анализ проблем и запросов на модификацию ПО (анализ сообщений о возникшей проблеме или запроса на модификацию, оценка масштаба, стоимости модификации, получаемого эффекта, оценка целесообразности модификации);
- модификацию ПО (внесение изменений в компоненты программного продукта и документацию в соответствии с правилами процесса разработки);
- проверку и приемку (в части целостности модифицируемой системы);
- перенос ПО в другую среду (конвертирование программ и данных, параллельная эксплуатация ПО в старой и новой среде в течение некоторого периода времени);
- снятие ПО с эксплуатации по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей. При этом программные продукты и документации подлежат архивированию в соответствии с договором.
Источник
Жизненный цикл программ Программный продукт (ПП) представляет собой набор компьютерных программ, процедур и связанной с ними документации и данных. Жизненный цикл программного продукта – это период времени, начинающийся с момента принятия решения о необходимости создания ПП и заканчивающийся в момент его полного изъятия из эксплуатации. Структуру жизненного цикла ПП, состав процессов, действия и задачи, которые должны быть выполнены во время создания ПП, определяет и регламентирует международный стандарт ISO/IEC 12207:1995 «rmation Technology – Software Life Cycle Processes» (ISO – International Organization for Standardization – Международная организация по стандартизации; IEC – International Electrotechnical Commission – Международная комиссия по электротехнике; название стандарта «Информационные технологии – Процессы жизненного цикла программ»). Под процессом понимают совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, а также исходными данными, полученными от других процессов, и результатами. Каждый процесс разделен на набор действий, каждое действие – на набор задач. Запуск и выполнение процесса, действия или задачи осуществляются другими процессами. В соответствии со стандартом ISO/IEC 12207 все процессы жизненного цикла ПП разделены на три базовые группы: · основные процессы; · вспомогательные (поддерживающие) процессы; · организационные процессы. 1.2. Основные процессы жизненного цикла программного продукта Основные процессы включают в себя набор определенных действий и связанных с ними задач, которые должны быть выполнены в течение жизненного цикла ПП. К основным относятся процессы приобретения, поставки, разработки, эксплуатации и сопровождения. Процесс приобретения (acquisition process) охватывает действия заказчика по приобретению ПП. Процесс поставки (supply process) охватывает действия и задачи поставщика при снабжении заказчика ПП или услугой. Процесс разработки (development process) охватывает действия и задачи. Процесс эксплуатации (operation process) охватывает действия и задачи оператора – организации, занимающейся эксплуатацией разработанного ПП или системы. Процесс сопровождения (maintenance process) охватывает действия и задачи сопровождающей организации (службы сопровождения). 1.3. Вспомогательные (поддерживающие) процессы жизненного цикла программного продукта Основной целью вспомогательных (поддерживающих) процессов является создание надежного, полностью удовлетворяющего требованиям заказчика ПП в установленные договором сроки. К вспомогательным относятся процессы документирования, управления конфигурацией, обеспечения качества, верификации, аттестации, совместной оценки, аудита, разрешения проблем. Процесс документирования (documentation process) предусматривает формализованное описание информации, созданной в течение жизненного цикла ПП. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких как руководство, технические специалисты и пользователи системы. Процесс управления конфигурацией (configuration management process) предполагает применение административных и технических процедур на всем протяжении жизненного цикла ПП. Процесс обеспечения качества (quality assurance process) обеспечивает соответствующие гарантии того, что ПП и процессы его жизненного цикла соответствуют заданным требованиям и утвержденным планам. Под качеством ПП понимается совокупность свойств, которые характеризуют способность ПП удовлетворять заданным требованиям. Для получения достоверных оценок создаваемого ПП процесс обеспечения его качества должен происходить независимо от субъектов, непосредственно связанных с разработкой ПП. При этом могут использоваться результаты других вспомогательных процессов, таких как верификация, аттестация, совместная оценка, аудит и разрешение проблем. Процесс верификации (verification process) состоит в доказательстве того, что ПП, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, зависящим от предшествующих действий. Верификация в узком смысле означает формальное доказательство правильности ПП. Процесс аттестации (validation process) предусматривает определение полноты соответствия заданных требований к создаваемой системе или ПП функциональному назначению последних. Под аттестацией обычно понимают подтверждение и оценку достоверности проведенного тестирования ПП. Процесс совместной оценки (joint review process) предназначен для оценки состояния работ по проекту и ПП, создаваемому при выполнении данных работ. Он заключается в основном в контроле за планированием и управлением ресурсами, персоналом, аппаратурой и инструментальными средствами проекта. Процесс аудита (audit process) представляет собой определение соответствия требованиям, планам и условиям договора как хода выполнения работ по созданию ПП, так и самого ПП. Аудит может выполняться двумя любыми сторонами, участвующими в договоре, когда одна сторона проверяет другую. Аудит – это ревизия (проверка), проводимая компетентным органом (лицом) в.целях обеспечения независимой оценки степени соответствия ПП или проводимых работ установленным требованиям, планам, условиям договора и контракта. 1.4. Организационные процессы жизненного цикла программного продукта Основной целью организационных процессов является организация процесса разработки надежного, полностью удовлетворяющего требованиям заказчика ПП в установленные договором сроки и управление этим процессом. К организационным относятся процессы управления, создания инфраструктуры, усовершенствования, обучения. Процесс управления (management process) состоит из действий и задач, которые могут выполняться любой стороной, управляющей своими процессами. Данная сторона (менеджер) отвечает за управление выпуском продукта, проектом и задачами соответствующих процессов, таких как Приобретение, поставка, разработка, эксплуатация, сопровождение и др. Процесс создания инфраструктуры (infrastructure process) охватывает выбор и поддержку (сопровождение) технологии, стандартов и инструментальных средств, выбор и установку аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПП. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к соответствующим процессам. Инфраструктура, в свою очередь, является одним из объектов управления конфигурацией. Процесс усовершенствования (improvement process) предусматривает оценку, измерение, контроль и усовершенствование процессов жизненного цикла ПП Создание процесса усовершенствования процессов жизненного цикла ПП позволяет на основе контроля за ходом выполнения процессов жизненного цикла, измерения характеристик и оценки полученных результатов существенно улучшить качество разрабатываемого ПП и сократить сроки его создания. Процесс обучения (training process) охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала. Приобретение, поставка, разработка, эксплуатация и сопровождение программного продукта в значительной степени зависят от уровня знаний и квалификации персонала. Например, разработчики ПП должны пройти необходимое обучение методам и средствам программной инженерии. Содержание процесса обучения определяется требованиями к проекту. Для этого процесса должны быть запланированы необходимые ресурсы и технические средства обучения. Кроме того, должны быть разработаны и представлены методические материалы, необходимые для обучения пользователей в соответствии с учебным планом. 1.5. Взаимосвязь между процессами жизненного цикла программного продукта Процессы жизненного цикла ПП, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения, или в различных аспектах (договорном, управления, эксплуатации, инженерном, поддержки), который показан на рис. 1.1. Штриховые стрелки показывают связь действующих лиц процессов (заказчик, поставщик и т.д.) с конкретными процессами, а сплошные стрелки – связь процессов или групп процессов между собой. В договорном аспекте заказчик и поставщик вступают в договорные отношения и реализуют соответственно процессы приобретения и поставки. В аспекте управления заказчик, поставщик, разработчик, оператор, служба сопровождения и другие стороны, участвующие в жизненном цикле ПП, управляют выполнением своих процессов. Менеджер является связующим звеном между организационными и основными процессами. В аспекте эксплуатации оператор, эксплуатирующий систему, предоставляет необходимые услуги пользователям. В инженерном аспекте разработчик или служба сопровождения решают соответствующие технические задачи, разрабатывая или модифицируя ПП. В аспекте поддержки службы, реализующие вспомогательные процессы, предоставляют необходимые услуги всем остальным участникам работ. В рамках аспекта поддержки можно выделить аспект управления качеством ПП. Рис. 1.1. Связь между процессами жизненного цикла программного продукта Организационные процессы выполняются на корпоративном уровне, т.е. на уровне всей организации в целом, создавая баЗу для реализации и постоянного совершенствования остальных процессов жизненного цикла ПП. Процессы и реализующие их организации (или стороны) связаны между собой чисто функционально. При этом внутренняя структура и статус организаций никак не регламентируются. Одна и та же организация может выполнять различные роли (поставщика, разработчика и др.), и, наоборот, одна и та же роль может выполняться несколькими организациями. Взаимосвязи между процессами, описанные в стандарте, носят статический характер. Более важные динамические связи между процессами и реализующими их сторонами устанавливаются в реальных проектах. |
Источник