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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• · Архитектурный или высокоуровневый дизайн (software architectural design, top-level design) — описание высокоуровневой структуры и организации компонентов системы;
• · Детализированная архитектура (software detailed design) — описывающая каждый компонент в том объеме, который необходим для конструирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• · анализ проблем и запросов на модификацию ПО;
• · модификация программного продукта;
• · его проверка и приемка;
• · перенос ПО в другую среду;
• · снятие ПО с эксплуатации.

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

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

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

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

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

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