Вспомогательные и организационные процессы жизненного цикла программного средства. Процессы жизненного цикла программного обеспечения Основные процессы жизненного цикла программного средства

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

Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения ( ПО ) первоначально, в 70-е годы прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации – серии ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно.

Процессы создания автоматизированных систем ( АС ), в состав которых входит и ПО , регламентированы стандартами ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания", ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы" и ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем". Однако многие положения этих стандартов устарели, а другие отражены недостаточно, чтобы их можно было применять для серьезных проектов создания ПС. Поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

В соответствии со стандартом ISO / IEC 12207 все процессы ЖЦ ПО разделены на три группы (рис.5.1).

Рис. 5.1.

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

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

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

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

Инициирование приобретения включает следующие задачи:

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

Заявочные предложения должны содержать:

1. требования, предъявляемые к системе;
2. перечень программных продуктов;
3. условия приобретения и соглашения;
4. технические ограничения (например, по среде функционирования системы).

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

Подготовка и корректировка договора включает следующие задачи:

1. определение заказчиком процедуры выбора поставщика, включающей критерии оценки предложений возможных поставщиков;
2. выбор конкретного поставщика на основе анализа предложений;
3. подготовку и заключение договора с поставщиком ;
4. внесение изменений (при необходимости) в договор в процессе его выполнения.

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

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

1. инициирование поставки;
2. подготовку ответа на заявочные предложения;
3. подготовку договора;
4. планирование работ по договору;
5. выполнение и контроль договорных работ и их оценку;
6. поставку и завершение работ.

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

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

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

Процесс разработки включает следующие действия:

1. подготовительную работу;
2. анализ требований, предъявляемых к системе;
3. проектирование архитектуры системы;
4. анализ требований, предъявляемых к программному обеспечению;
5. проектирование архитектуры программного обеспечения;
6. детальное проектирование программного обеспечения;
7. кодирование и тестирование программного обеспечения;
8. интеграцию программного обеспечения;
9. квалификационное тестирование программного обеспечения;
10. интеграцию системы;
11. квалификационное тестирование системы;
12. установку программного обеспечения;
13. приемку программного обеспечения.

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

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

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

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

1. функциональных возможностей, включая характеристики производительности и среды функционирования компонента;
2. внешних интерфейсов;
3. спецификаций надежности и безопасности;
4. эргономических требований;
5. требований к используемым данным;
6. требований к установке и приемке;
7. требований к пользовательской документации;
8. требований к эксплуатации и сопровождению.

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

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

1. трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;
2. разработку и документирование программных интерфейсов ПО и баз данных (БД);
3. разработку предварительной версии пользовательской документации;
4. разработку и документирование предварительных требований к тестам и плана интеграции ПО.

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

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

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

1. кодирование и документирование каждого компонента ПО и базы данных, а также подготовку совокупности тестовых процедур и данных для их тестирования;
2. тестирование каждого компонента ПО и БД на соответствие предъявляемым к ним требованиям с последующим документированием результатов тестирования;
3. обновление документации (при необходимости);
4. обновление плана интеграции ПО.

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

Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (

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

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

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

Вспомогательныепроцессы жизненного цикла программного средства. Процесс документирования (documentation process) предусматривает формализованное описание информации, созданной в течение ЖЦ ПС. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких, как руководители, технические специалисты и пользователи системы

Процесс управления конфигурацией (configuration management process) предполагает применение административных и технических процедур на всем протяжении ЖЦ ПС для определения состояния компонентов ПС в системе, управления модификациями ПС, описания и подготовки отчетов о состоянии компонентов ПС и запросов на модификацию, обеспечения полноты, совместимости и корректности компонентов ПС, управления хранением и поставкой ПС. Согласно стандарту IEEE–90 под конфигурацией ПС понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПС.

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

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

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

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

Обеспечение качества процесса предполагает гарантирование соответствия процессов ЖЦ ПС, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам.

Обеспечение прочих показателей качества системы осуществляется в соответствии с условиями договора и стандартом качества ISO 9001.

Процесс верификации (verification process) состоит в определении того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями (верификация в «узком» смысле означает формальное доказательство правильности ПС). Для повышения эффективности верификация должна как можно раньше интегрироваться с использующими ее процессами (такими, как поставка, разработка, эксплуатация или сопровождение). Данный процесс может включать анализ, оценку и тестирование.

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

В процессе верификации проверяются следующие условия:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс усовершенствования (improvement process) предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПС. Усовершенствование процессов ЖЦ ПС направлено на повышение производительности труда всех участвующих в них специалистов за счет совершенствования используемой технологии, методов управления, выбора инструментальных средств и обучения персонала. Усовершенствование основано на анализе достоинств и недостатков каждого процесса. Такому анализу в большой степени способствует накопление в организации исторической, технической, экономической и иной информации по реaлизoвaнным проектам.

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

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

1. процесс документирования;
2. процесс управления конфигурацией;
3. процесс обеспечения качества;
4. процесс верификации;
5. процесс аттестации;
6. процесс совместного анализа;
7. процесс аудита;
8. процесс решения проблем.

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

Данная организация организует и выполняет управление вспомогательным процессом на проектном уровне в соответствии с процессом управления (подраздел 7.1); определяет инфраструк­туру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);

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

6.1 Процесс документирования

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

1. подготовка процесса;
2. проектирование и разработка;
3. выпуск;
4. сопровождение.

6.1.1 Подготовка процесса

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

a) заголовок или наименование;

b) назначение;

c) пользователи документа;

d) процедуры и обязанности по подготовке исходных материалов, разработке, проверке, изменению, утверждению, выпуску, хранению, распространению, сопровождению и управлению конфигурацией;

e) сроки выпуска промежуточных и окончательных редакций.

6.1.2 Проектирование и разработка

Данная работа состоит из следующих задач:

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

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

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

6.1.З Выпуск

Данная работа состоит из следующих задач:

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

6.1.3.2 Средства управления документированием должны быть определены в соответствии с процессом управления конфигурацией (подраздел 6.2).

6.1.4 Сопровождение

6.1.4.1 Должны быть решены задачи, связанные с внесением изменений в документацию (подраздел 5.5). Изменения в документы, находящиеся под управлением конфигурацией, вносят в соответствии с процессом управления конфигурацией (подраздел 6.2).

6.2 Процесс управления конфигурацией

Процесс управления конфигурацией является процессом применения административных и технических процедур на всем протяжении жизненного цикла программных средств для: обозначе­ния, определения и установления состояния (базовой линии) программных объектов в системе;

управления изменениями и выпуском объектов; описания и сообщения о состояниях объектов и заявок на внесение изменений в них; обеспечения полноты, совместимости и правильности объектов; управления хранением, обращением и поставкой объектов.

Примечание- Когда данный процесс применяется к другим программным продуктам или объектам, термин «программный объект» интерпретируется ниже соответствующим образом.

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;
2. определение конфигурации;
3. контроль конфигурации;
4. учет состояний конфигурации;
5. оценка конфигурации;
6. управление выпуском и поставка.

6.2.1 Подготовка процесса

Данная работа состоит из следующей задачи:

6.2.1.1 Должен быть разработан план управления конфигурацией. План должен определять:

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

Примечание- Данный план может быть частью плана управления конфигурацией системы.

6.2.2 Определение конфигурации.

Данная работа состоит из следующей задачи:

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

6.2.3 Контроль конфигурации

Данная работа состоит из следующей задачи:

6.2.3.1 Должны быть выполнены: обозначение и регистрация заявок на внесение изменений;

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

6.2.4 Учет состояний конфигурации

Данная работа состоит из следующей задачи:

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

6.2.5 Оценка конфигурации

Данная работа состоит из следующей задачи:

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

6.2.6 Управление выпуском и поставка

Данная работа состоит из следующей задачи:

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

6.3 Процесс обеспечения качества

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

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;
2. обеспечение продукта;
3. обеспечение процесса;
4. обеспечение систем качества.

6.3.1 Подготовка процесса

Данная работа состоит из следующих задач:

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

6.3.1.2 Процесс обеспечения качества должен быть скоординирован с соответствующими процессами верификации (подраздел 6.4), аттестации (подраздел 6.5), совместного анализа (подраз­дел 6.6) и аудита (подраздел 6.7).

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

a) стандарты качества, методологии, процедуры и средства для выполнения работ по обеспе­чению качества (или содержать ссылки на соответствующую официальную документацию);

b) процедуры проведения анализов качества при выполнении договора и координации этих работ;

c) процедуры для обозначения, сбора, регистрации, сопровождения и распространения ин­формации о качестве;

d) ресурсы, графики и обязанности при проведении работ по обеспечению качества;

e) выбранные работы и задачи из вспомогательных процессов, таких как верификация (подраздел 6.4), аттестация (подраздел 6.5), совместный анализ (подраздел 6.6), аудит (подраздел 6.7) и решение проблем (подраздел 6.8).

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

6.3.1.5 Отчеты о работах и задачах по обеспечению качества должны быть доступны заказчику в соответствии с условиями договора.

6.3.1.6 Должно быть обеспечено, чтобы лица, отвечающие за соблюдение соответствия усло­виям договора, были организационно независимы, имели ресурсы и полномочия для выполнения объективных оценок и постановки, реализации и проверки решения возникших проблем.

6.3.2 Обеспечение продукта

Данная работа состоит из следующих задач:

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

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

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

6.3.3 Обеспечение процесса

Данная работа состоит из следующих задач:

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

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

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

6.3.3.4 Должно быть обеспечено, чтобы заказчик и другие участники договора обеспечивали взаимную поддержку и кооперацию в соответствии с условиями договора, достигнутыми соглаше­ниями и утвержденными планами.

6.3.3.5 Должно быть обеспечено, чтобы характеристики программного продукта и процессов соответствовали установленным стандартам и процедурам.

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

6.3.4 Обеспечение систем качества

Данная работа состоит из следующей задачи:

6.3.4.1 Должно быть обеспечено проведение дополнительных работ по управлению качеством в соответствии с разделами ГОСТ Р ИСО 9001, указанными в договоре.

6.4 Процесс верификации

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

Данный процесс может выполняться с различными степенями независимости исполнителей. Степень независимости исполнителей может распределяться как между различными субъектами в самой организации, так и субъектами в другой организации, с различными степенями распределения обязанностей. Данный процесс называется процессом независимой верификации, если организа­ция-исполнитель не зависит от поставщика, разработчика, оператора или персонала сопровожде­ния.

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;
2. верификация.

6.4.1 Подготовка процесса

Данная работа состоит из следующих задач:

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

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

b) совершенства используемой технологии программирования и рисков, связанных с ее применением;

c) доступности фондов и ресурсов.

6.4.1.2 Если проект предусматривает работы по верификации, должен быть установлен про­цесс верификации для проверки программного продукта.

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

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

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

6.4.1.6 Должен быть реализован план проведения верификации. Проблемы и несоответствия, обнаруженные при проведении верификации, должны быть введены в процесс решения проблем (подраздел 6.8). Все возникшие проблемы должны быть решены, а обнаруженные несоответствия устранены. Результаты работ по верификации должны быть доступны заказчику и другим органи­зациям, участвующим в договоре.

6.4.2 Верификация

Данная работа состоит из следующих задач:

6.4.2.1 Верификация договора

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

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

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

c) наличия соответствующих процедур для внесения изменений в установленные требования и решения проблем;

d) наличия процедур и правил их применения по взаимодействию и кооперации между участниками договора, включая права собственности, гарантии, авторские права и конфиденциаль­ность;

e) наличия соответствующих критериев и процедур, предусмотренных в соответствии с установленными требованиями.

Примечание- Данная работа может выполняться при оценке договора (см. 6.3.1.3.b)].

6.4.2.2 Верификация процесса

Процесс должен быть верифицирован по следующим критериям:

a) соответствие и своевременность установления проектных требований к планированию;

b) пригодность, реализуемость, выполнимость в соответствии с планом и условиями договора выбранных для проекта процессов;

c) применимость стандартов, процедур и условий к процессам проектирования;

d) укомплектованность и обученность персонала в соответствии с условиями договора.

6.4.2.3 Верификация требований

Требования должны быть верифицированы по следующим критериям:

a) непротиворечивость, выполнимость и тестируемость требований к системе;

b) распределение требований к системе между объектами технических и программных средств и ручных операций в соответствии с проектом;

c) непротиворечивость, выполнимость, тестируемость и точность отражения требований к системе в требованиях к программным средствам;

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

6.4.2.4 Верификация проекта

Проект должен быть верифицирован по следующим критериям:

a) правильность проекта, его соответствие установленным требованиям и учет этих требова­ний в проекте;

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

c) возможность выбора проекта, исходя из установленных требований;

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

6.4.2.5 Верификация программы

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

a) учет в программе условий проекта и установленных требований; ее тестируемость, правиль­ность и соответствие установленным требованиям и стандартам программирования;

b) реализуемость в программе: соответствующей последовательности событий, соответствую­щих интерфейсов, правильных данных и логики управления; распределения временных и матери­альных ресурсов; обнаружения, локализации и восстановления ошибок, а также ее завершенность:

c) возможность выбора программы, исходя из проекта или установленных требований;

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

6.4.2.6 Верификация сборки

Сборка должна быть верифицирована по следующим критериям:

a) полнота и правильность сборки программных компонентов и модулей каждого программ­ного объекта в соответствующий программный объект;

b) полнота и правильность сборки технических и программных объектов и ручных операций в систему;

c) выполнение задач сборки в соответствии с планом сборки.

6.4.2.7 Верификация документации

Документация должна быть верифицирована по следующим критериям:

a) соответствие, полнота и непротиворечивость документации;

b) своевременность подготовки документации;

c) соблюдение установленных процедур управления конфигурацией документов.

6.5 Процесс аттестации

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

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

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;
2. аттестация.

6.5.1 Подготовка процесса

Данная работа состоит из следующих задач:

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

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

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

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

a) объекты, подлежащие аттестации;

b) задачи, решаемые при аттестации;

c) ресурсы, обязанности и график при проведении аттестации;

d) процедуры передачи отчетов об аттестации заказчику и другим сторонам.

6.5.1.5 Должен быть реализован план проведения аттестации. Проблемы и несоответствия, обнаруженные при проведении аттестации, должны быть введены в процесс решения проблем (подраздел 6.8). Все возникшие проблемы должны быть решены, а обнаруженные несоответствия устранены. Результаты работ по аттестации должны быть доступны заказчику и другим организа­циям, участвующим в договоре.

6.5.2 Аттестация

Данная работа состоит из следующих задач:

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

6.5.2.2 Обеспечение того, чтобы требования к испытаниям (тестированию), контрольные примеры и технические условия испытаний отражали конкретные требования к конкретным объектам аттестации.

6.5.2.3 Проведение испытаний с учетом 6.5.2.1 и 6.5.2.2, включая:

a) испытания при критических, граничных и особых значениях исходных данных;

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

c) испытание при участии репрезентативно выбранных пользователей, могущих успешно решать свои задачи при использовании данного программного продукта.

6.5.2.4 Подтверждение того, что программный продукт удовлетворяет заявленным возможнос­тям.

6.5.2.5 Испытание программного продукта в выбранных областях среды эксплуатации.

6.6 Процесс совместного анализа

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

6.1 Список работ.

Данный процесс состоит из следующих работ:

1) подготовка процесса;

2) анализы управления проектом;

3) технические анализы.

6.6.1 Подготовка процесса

Данная работа состоит из следующих задач:

6.6.1.1 Должны проводиться периодические анализы хода работ в сроки, установленные проектным планом(ами). Должны проводиться целевые анализы в сроки, определяемые заинтере­сованной стороной.

6.6.1.2 Между сторонами, участвующими в проведении анализа, должны быть согласованы объем и состав ресурсов, необходимых для проведения анализа. Данные ресурсы включают персонал, место проведения, условия проведения, необходимые технические, программные и инструментальные средства.

6.6.1.3 Стороны должны согласовать следующие вопросы проведения каждого анализа: план проведения анализа; состав анализируемых программных продуктов (результатов работы) и про­блем; объем и процедуры проведения анализа; исходные и итоговые критерии при проведении анализа.

6.6.1.4 Проблемы, выявленные при проведении анализа, должны быть документально офор­млены и введены в процесс решения проблем (подраздел 6.8).

6.6.1.5 Результаты анализа должны быть документально оформлены и разосланы заинтересован­ным сторонам. Анализирующая сторона должна довести до сведения анализируемой стороны соответ­ствующие результаты анализа (например, согласовано, не согласовано или согласовано условно).

6.6.1.6 Стороны должны согласовать итоговый результат анализа, любые принимаемые обя­зательства и критерии завершения анализа.

6.6.2 Анализы управления проектом

Данная работа состоит из следующих задач:

6.6.2.1 Состояние проекта должно быть оценено на соответствие проектным планам, графи­кам, стандартам и руководствам. Итоговый результат анализа должен быть обсужден между двумя участвующими сторонами и должен включать:

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

b) предложения по проведению общего контроля проекта посредством соответствующего перераспределения ресурсов;

c) предложения по изменению хода проекта или определению потребности в перепланирова­нии проекта;

d) предложения по оценке и управлению критическими ситуациями, могущими угрожать успешному ходу проекта.

6.6.3 Технические анализы

Данная работа состоит из следующих задач:

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

a) они полностью реализованы на данный момент;

b) они соответствуют принятым стандартам и техническим требованиям;

c) изменения к ним выполнены должным образом и влияют только на те области, которые определены процессом управления конфигурацией (подраздел 6.2);

d) они полностью придерживаются установленных графиков работ;

e) они готовы к последующим работам;

f) их разработка, эксплуатация или сопровождение проводятся в соответствии с проектными планами, графиками, стандартами и руководствами.

6.7 Процесс аудита

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

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;
2. аудиторская проверка.

6.7.1 Подготовка процесса

Данная работа состоит из следующих задач:

6.7.1.1 Аудиторские проверки должны проводиться в сроки, установленные проектным планом(ами).

6.7.1.2 Аудиторский персонал не должен нести какой-либо прямой ответственности за прове­ряемые программные продукты и работы.

6.7.1.3 Между сторонами, участвующими в проведении аудита, должен быть согласован объем и состав ресурсов, необходимых для проведения аудиторской проверки. Данные ресурсы включают персонал, место проведения, условия проведения, необходимые технические, программные и инструментальные средства.

6.7.1.4 Стороны должны согласовать следующие вопросы проведения каждой аудиторской проверки: план проведения аудиторской проверки; состав проверяемых программных продуктов (и результатов работы); объем и процедуры проведения аудиторской проверки; исходные и итоговые критерии при проведении аудиторской проверки.

6.7.1.5 Проблемы, выявленные при проведении аудиторской проверки, должны быть доку­ментально оформлены и введены в процесс решения проблем (подраздел 6.8).

6.7.1.6 Результаты аудиторской проверки после ее завершения должны быть документально оформлены и представлены ревизуемой стороне. Ревизующая сторона должна довести до сведения ревизуемой стороны все проблемы, обнаруженные при проведении аудиторской проверки, и планируемые решения по соответствующим проблемам.

6.7.1.7 Стороны должны согласовать итоговый результат аудиторской проверки, любые при­нимаемые обязательства и критерии завершения аудиторской проверки. 6.7.2 Аудиторская проверка Данная работа состоит из следующей задачи:

6.7.2.1 Аудиторские проверки должны проводиться для обеспечения того, чтобы:

a) запрограммированные программные продукты (такие, как программный объект) отражали проектную документацию;

b) подготовка приемки и требования к тестированию, установленные в документации, были пригодны для приемки программных продуктов;

c) тестовые данные соответствовали установленным техническим требованиям;

d) программные продукты были успешно протестированы и соответствовали установленным к ним требованиям;

e) отчеты об испытаниях (тестировании) были правильны и расхождения между фактическими и ожидаемыми результатами были устранены;

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

g) работы были выполнены в соответствии с утвержденными требованиями, планами и договором;

h) стоимости и графики проведения работ соответствовали утвержденным планам.

6.8 Процесс решения проблем

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

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;
2. решение проблемы.

6.8.1 Подготовка процесса

Данная работа состоит из следующей задачи:

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

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

реализацию решения данных проблем и их внесение в соответствующие объекты; учет и докумен­тирование состояний проблем; сопровождение отчетов о проблемах;

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

c) в отчетах о проблемах должен быть приведен анализ причин их возникновения;

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

6.8.2 Решение проблемы

Данная работа состоит из следующей задачи:

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

Тема 3. Жизненный цикл ПО 28

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

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

пять основных процессов (приобретение, поставка, разработка, эксплуатация, сопровождение.

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

Четыре организационных процесса (управление, создание инф­раструктуры, усовершенствование, обучение).

ОСНОВНЫЕ ПРОЦЕССЫ ЖЦ ПО

Процесс приобретения.

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

инициирование приобретения;

подготовку заявочных предложений;

подготовку и корректировку договора;

надзор за деятельностью поставщика;

приемку и завершение работ.

Инициирование приобретения включает следующие задачи:

определение заказчиком своих потребностей в приобретении, раз­работке или усовершенствовании системы, программных продук­тов или услуг;

анализ требований к системе;

принятие решения относительно приобретения, разработки или усовершенствования существующего ПО;

проверку наличия необходимой документации, гарантий, серти­фикатов, лицензий и поддержки в случае приобретения про­граммного продукта;

подготовку и утверждение плана приобретения, включающего тре­бования к системе, тип договора, ответственность сторон и т. д. Заявочные предложения должны содержать:

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

перечень программных продуктов;

условия и соглашения;

технические ограничения (например, среда функционирования системы).

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

Подготовка и корректировка договора включают следующие задачи:

определение заказчиком процедуры выбора поставщика, вклю­чающей критерии оценки предложений возможных поставщи­ков;

выбор конкретного поставщика на основе анализа предложений;

подготовку и заключение договора с поставщиком;

внесение изменений (при необходимости) в договор в процессе его выполнения.

Надзор за деятельностью поставщика осуществляется в соответ­ствии с действиями, предусмотренными в процессах совместной оценки и аудита.

В процессе приемки подготавливаются и выполняются необходи­мые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки.

Процесс поставки.

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

инициирование поставки;

подготовку ответа на заявочные предложения;

подготовку договора;

планирование;

выполнение и контроль;

проверку и оценку;

поставку и завершение работ.

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

Планирование включает следующие задачи:

принятие решения поставщиком относительно выполнения ра­бот своими силами или с привлечением субподрядчика;

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

Процесс разработки.

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

Процесс разработки включает следующие действия:

подготовительную работу;

анализ требований к системе;

проектирование архитектуры системы;

анализ требований к ПО;

проектирование архитектуры ПО;

детальное проектирование ПО;

кодирование и тестирование ПО;

интеграцию ПО;

квалификационное тестирование ПО;

интеграцию системы;

квалификационное тестирование системы;

установку ПО;

приемку ПО.

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

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

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

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

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

внешних интерфейсов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

разработку и документирование детального проекта базы данных;

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

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

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

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

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

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

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

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

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

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

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

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

Процесс эксплуатации.

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

1) подготовительную работу;

2) эксплуатационное тестирование;

3) эксплуатацию системы;

4) поддержку пользователей.

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

планирование действий и работ, выполняемых в процессе эксп­луатации, и установку эксплуатационных стандартов;

определение процедур локализации и разрешения проблем, воз­никающих в процессе эксплуатации.

Эксплуатационное тестирование осуществляется для каждой оче­редной редакции программного продукта, после чего она передается в эксплуатацию.

Эксплуатация системы выполняется в предназначенной для это­го среде в соответствии с пользовательской документацией.

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

Процесс сопровождения.

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

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

Процесс сопровождения охватывает следующие действия:

подготовительную работу;

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

модификацию ПО;

проверку и приемку;

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

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

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

планирование действий и работ, выполняемых в процессе сопро­вождения;

определение процедур локализации и разрешения проблем, воз­никающих в процессе сопровождения.

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

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

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

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

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

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

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

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

ВСПОМОГАТЕЛЬНЫЕ ПРОЦЕССЫ ЖЦ ПО

Процесс документирования.

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

Процесс документирования включает следующие действия:

подготовительную работу;

проектирование и разработку;

выпуск документации;

сопровождение.

Процесс управления конфигурацией.

Он предполагает применение административных и техни­ческих процедур на всем протяжении ЖЦ ПО для определения со­стояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО

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

Процесс управления конфигурацией включает следующие дей­ствия:

подготовительную работу;

идентификацию конфигурации;

контроль конфигурации;

учет состояния конфигурации;

оценку конфигурации;

управление выпуском и поставку.

Подготовительная работа заключается в планировании управле­ния конфигурацией.

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

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

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

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

Управление выпуском и поставка охватывают изготовление эталон­ных копий программ и документации, их хранение и поставку пользо­вателям в соответствии с порядком, принятым в организации.

Процесс обеспечения качества.

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

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

Процесс обеспечения качества включает следующие действия:

подготовительную работу;

обеспечение качества продукта;

обеспечение качества процесса;

обеспечение прочих показателей качества системы.

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

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

Обеспечение качества процесса предполагает гарантирование со­ответствия процессов ЖЦ ПО, методов разработки, среды разработ­ки и квалификации персонала условиям договора, установленным стандартам и процедурам.

Обеспечение прочих показателей качества системы осуществляет­ся в соответствии с условиями договора.

Процесс верификации.

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

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

Процесс верификации включает следующие действия:

1) подготовительную работу;

2) верификацию.

В процессе верификации проверяются следующие условия:

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

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

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

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

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

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

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

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

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

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

Процесс аттестации.

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

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

Процесс аттестации включает следующие действия:

подготовительную работу;

аттестацию.

Процесс совместной оценки.

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

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

Процесс совместной оценки включает следующие действия:

подготовительную работу;

оценку управления проектом;

техническую оценку.

Процесс аудита.

Он представляет собой определе­ние соответствия требованиям, планам и условиям договора. Аудит может выполняться двумя любыми сторонами, участвующими в до­говоре, когда одна сторона проверяет другую.

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

Процесс аудита включает следующие действия:

подготовительную работу;

Процесс разрешения проблем.

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

Процесс разрешения проблем включает следующие действия:

1) подготовительную работу;

2) разрешение проблем.

ОРГАНИЗАЦИОННЫЕ ПРОЦЕССЫ ЖЦ ПО

Процесс управления.

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

Процесс управления включает следующие действия:

инициирование и определение области управления;

планирование;

выполнение и контроль;

проверку и оценку;

завершение.

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

Планирование подразумевает выполнение, как минимум, следую­щих задач:

составление графиков выполнения, работ;

оценку затрат;

выделение требуемых ресурсов;

распределение ответственности;

оценку рисков, связанных с конкретными задачами;

создание инфраструктуры управления.

Процесс создания инфраструктуры.

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

Процесс создания инфраструктуры включает следующие действия:

подготовительную работу;

создание инфраструктуры;

сопровождение инфраструктуры.

Процесс усовершенствования.

Он предусмат­ривает оценку, измерение, контроль и усовершенствование процес­сов ЖЦ ПО. Данный процесс включает следующие действия:

создание процесса;

оценку процесса;

усовершенствование процесса.

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

Процесс обучения.

Структура ЖЦ ПО в соответствии со стандартом ISO/IEC 12207 базируется на трех группах процессов (рис. 1):

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

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

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Рис. 1. Процессы жизненного цикла программного обеспечения.

Процесс приобретения (acquisition process). Он состоит из действий

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

1) инициирование приобретения;

2) подготовку заявочных предложений;

3) подготовку и корректировку договора;

4) надзор за деятельностью поставщика;

5) приемку и завершение работ.

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

1) инициирование поставки;

2) подготовку ответа на заявочные предложения;

3) подготовку договора;

4) планирование;

5) выполнение и контроль;

6) проверку и оценку;

7) поставку и завершение работ.

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

Процесс разработки включает следующие действия:

1) анализ требований к системе;

2) проектирование архитектуры системы;

3) анализ требований к ПО;

4) проектирование архитектуры ПО;

5) детальное проектирование ПО;

6) кодирование и тестирование ПО;

7) интеграцию ПО;

8) квалификационное тестирование ПО;

9) интеграцию системы;

10) квалификационное тестирование системы;

11) установку ПО;

12) приемку ПО.

Процесс эксплуатации (operation process). Он охватывает действия и задачи оператора - организации, эксплуатирующей систему. Данный процесс включает следующие действия:

1) эксплуатационное тестирование;

2) эксплуатацию системы;

3) поддержку пользователей.

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

требованиям. Изменения, вносимые в существующее ПО, не должны нарушать

его целостность. Процесс сопровождения включает перенос ПО в другую среду (миграцию) и заканчивается снятием ПО с эксплуатации.

Процесс сопровождения охватывает следующие действия:

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

2) модификацию ПО;

3) проверку и приемку;

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

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

В группу вспомогательных процессов включены:

Документирование;

Управление конфигурацией; обеспечение качества;

Верификация; аттестация;

Совместная оценка;

Разрешение проблем.

Процесс документирования (documentation process). Он предусматривает формализованное описание информации, созданной в течение ЖЦ ПО. Процесс документирования включает следующие действия:

1) проектирование и разработку;

2) выпуск документации;

3) сопровождение документации.

Процесс управления конфигурацией (configuration management process). Он предполагает применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности компонентов ПО, управления хранением и поставкой ПО. Согласно стандарту IEEE-90 под конфигурацией ПО понимается совокупность его функциональных и физических ха-

рактеристик, установленных в технической документации и реализованных в ПО.

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/I EC CD 12207-2: 1995 "Information Technology - Software Life Cycle Processes. Part 2.

Configuration Management for Software". Процесс управления конфигурацией включает следующие действия:

1) идентификацию конфигурации;

2) контроль конфигурации;

3) учет состояния конфигурации;

4) оценку конфигурации;

5) управление выпуском и поставку.

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

1) обеспечение качества продукта;

2) обеспечение качества процесса;

3) обеспечение прочих показателей качества системы.

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

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

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

Процесс аудита (audit process). Он представляет собой определение соответствия требованиям, планам и условиям договора.

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

В группу организационных процессов ЖЦ ПО входят:

Управление;

Создание инфраструктуры;

Усовершенствование;

Выпуск новых версий;

Обучение.

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

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

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

персонала.

Процесс обучения (training process). Он охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.