Размещено на http://www.allbest.ru/

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

Жизненный цикл ПО - это период времени, который начинается с момента принятия решения о необходимости создания программного обеспечения и заканчивается в момент его полного изъятия из эксплуатации (IEEE Std. 610.12-19990 Standard Glossary of Software Engineering Terminology).

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

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

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

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

Таким образом, первоначальное отношение к понятию жизненного цикла как к циклу разработки постепенно трансформировалось и стало рассматриваться как проекция пользовательского понятия «время жизни ПО» на понятие разработчика «технологический цикл (или цикл разработки)».

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

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

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 «International Technology - Software Life Cycle Processes» (ГОСТ ИСО МЭК 12207-99 Информационные технологии. Жизненный цикл программного обеспечения). В данном стандарте программный продукт определяется как набор компьютерных программ, процедур и, возможно связанных с ними документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные.

Стандарт ISO/IEC 12207 определяет общую структуру жизненного цикла ПО в виде 3 ступенчатой модели, состоящей из процессов, видов деятельности и задач. Каждый процесс разделен на набор действий, каждое действие - на набор задач, каждая задача характеризуется определенным методом решения, исходными данными, в том числе, полученными от других процессов, и результатами. Любой процесс увязан с определенными артефактами и ролями заинтересованных лиц. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения.

Всего в стандарте ISO/IEC 12207 определено 18 процессов, 74 вида деятельности и 224 различные задачи.

В соответствии со стандартом все процессы жизненного цикла ПО разделены на группы:

Жизненный цикл ПО

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

Основные процессы ЖЦ ПО

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

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

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

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

Первой фазой разработки ПО является анализ требований к системе. Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?». Для ответа на этот вопрос, во-первых, необходимо понять, какие именно потребности пользователей призвана обеспечить будущая система, а во-вторых, задокументировать это понимание, т. к. если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должен быть достаточно прост и понятен заказчику.

Список требований к разрабатываемой системе должен включать:

· совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отношение);

· описание выполняемых системой функций;

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

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

Требования к системе оцениваются исходя из критериев реализуемости и возможности проверки при тестировании.

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

· функциональные возможности, включая характеристики производительности и среды функционирования компонента;

· внешние интерфейсы;

· спецификации надежности и безопасности;

· эргономические требования;

· требования к используемым данным;

· требования к установке и приемке;

· требования к пользовательской документации;

· требования к эксплуатации и сопровождению.

Требования к ПО оцениваются исходя из критериев соответствия требованиям к системе, реализуемости и возможности проверки при тестировании.

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

· Архитектурный или высокоуровневый дизайн (software architectural design, top-level design) - описание высокоуровневой структуры и организации компонентов системы;

· Детализированная архитектура (software detailed design) - описывающая каждый компонент в том объеме, который необходим для конструирования.

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

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

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

· трансформацию требований к ПО в архитектуру, определяющую на высоком уровне абстракции структуру программного обеспечения и состав его компонентов;

· разработку и документирование программных интерфейсов ПО;

· разработку предварительной версии пользовательской документации;

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

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

Детальное проектирование ПО (рабочий план разработки ПО) включает следующие задачи:

· описание компонентов ПО и интерфейсов между ними на более низком уровне, достаточном для их последующего самостоятельного кодирования и тестирования;

· разработку и документирование детального проекта ПС;

· обновление (при необходимости) пользовательской документации;

· разработку и документирование требований к тестам и плана тестирования компонентов ПО;

· обновление плана интеграции ПО.

Кодирование и тестирование ПО подразумевает решение следующих задач:

· разработку (кодирование) и документирование каждого компонента ПО, а также создание совокупности тестовых процедур и данных для тестирования;

· тестирование каждого компонента ПО на соответствие предъявляемым требованиям. При этом результаты тестирования компонентов должны быть задокументированы;

· обновление (при необходимости) пользовательской документации;

· обновление плана интеграции ПО.

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

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

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

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

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

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

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

· анализ проблем и запросов на модификацию ПО;

· модификация программного продукта;

· его проверка и приемка;

· перенос ПО в другую среду;

· снятие ПО с эксплуатации.

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

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

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

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

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

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

Вспомогательные процессы жизненного цикла ПО

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

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

Общие принципы и рекомендации по управлению конфигурацией отражены в стандарте ISO/IEC CD 12207 - 2:1995 «Information Technology - Software Life Cycle Processes. Part 2. Configuration Management for Software». Этот стандарт предлагает установить правила, с помощью которых можно однозначно идентифицировать и различать компоненты ПО и их версии. При этом каждому компоненту и его версиям должен соответствовать однозначно обозначаемый комплект документации. При проведении модификаций ПО должен осуществляться контроль конфигурации, в процессе которого отслеживаются затраты на модификацию, оценивается ее эффективность, а также соответствие измененных компонентов их документации. Кроме того, согласно стандарту должны подготавливаться отчеты обо всех реализованных и отвергнутых модификациях компонентов ПО. Совокупность этих отчетов обеспечивает однозначное отражение текущего состояния системы и ее компонентов, а также ведение истории модификаций. Стандарт также рекомендует проводить оценку конфигурации, в процессе которой оценивается функциональная полнота компонентов ПО, а также соответствие их физического состояния текущему техническому описанию. Итоговое действие по управление конфигурацией - это управление выпуском и поставка, в процессе которых изготавливаются эталонные копии программ и документации для хранения и поставки пользователям в соответствии с порядком, принятом в организации.

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

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

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

Верификация в узком смысле означает формальное доказательство правильности ПО. В процессе верификации проверяются следующие условия:

· непротиворечивость требований к системе и степень учета потребностей пользователя;

· возможности поставщика выполнить заданные требования;

· соответствие выбранных процессов ЖЦ ПО условиям договора;

· адекватность стандартов, процедур и среды разработки процессам ЖЦ ПО;

· соответствие проектных спецификаций заданным требованиям;

· корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, логики и т.д.

· соответствие кода проектным спецификациям и требованиям;

· тестируемость и корректность кода, его соответствие принятым стандартам кодирования;

· корректность интеграции компонентов ПО в систему;

· адекватность, полнота и непротиворечивость документации.

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

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

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

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

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

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

стандарт жизненный цикл программный

Размещено на Allbest.ru