ОПИ-2. Министерство науки и образования рф

• Название: Министерство науки и образования рф
• Дата: 12.02.2022
• Размер: 1.52 Mb.
• Имя файла: ОПИ-2.pdf
• Тип: Курс лекций; #359541
• страница: 1 из 12

МИНИСТЕРСТВО НАУКИ И ОБРАЗОВАНИЯ РФ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
УРАЛЬСКИЙ ГОСУДАРСТВЕННЫЙ ЛЕСОТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ
Кафедра информационных технологий и моделирования
О.А. Карасева
Программная инженерия
Курс лекций
направления 230700.62- Прикладная информатика
ЕКАТЕРИНБУРГ
2012

Введение
ПРОГРАММНАЯ ИНЖЕНЕРИЯ КАК СОВОКУПНОСТЬ ИНЖЕНЕРНЫХ
МЕТОДОВ И СРЕДСТВ СОЗДАНИЯ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Программная инженерия. Понятие модели архитектуры ПО.
Особенности современных крупных проектов ЭИС.
Проектирование экономических информационных систем – логически сложная, трудоемкая и длительная работа, требующая высокой квалификации участвующих в ней специалистов. Однако до настоящего времени проектирование
ИЭС нередко выполняется на интуитивном уровне неформализованными методами, включающими в себя элементы искусства, практический опыт, экспертные оценки и дорогостоящие экспериментальные проверки качества функционирования ИЭС. Кроме того, в процессе создания и функционирования
ИЭС информационные потребности пользователей постоянно изменяются и уточняются, что еще более усложняет разработку и сопровождение таких систем.
Основная доля трудозатрат при создании ИЭС приходится на прикладное программирование и базы данных. Производство ПО – это крупнейшая отрасль мировой экономики, в которой занято около трех млн. специалистов.
Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце
70-х годов к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания
ПО, объединенных общим названием «программная инженерия». Впервые этот термин был использован как тема конференции, проводившейся под эгидой НАТО в 1968 г. Спустя 7 лет, в 1975г. в Вашингтоне была проведена первая международная конференция, посвященная программной инженерии.
В процессе становления и развития программной инженерии можно выделить два этапа: 70-е и 80-е годы - систематизация и стандартизация процессов создания
ПО (на основе структурного подхода) и 90-е годы - начало перехода к сборочному, индустриальному способу создания ПО (на основе объектно-ориентированного подхода).
В основе программной инженерии лежит одна фундаментальная идея:
проектирование ПО является формальным процессом, который можно
изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПО позволяет повысить качество ЭИС, обеспечить управляемость процесса проектирования ЭИС и увеличить срок ее жизни.
Тенденции развития современных информационных технологий определяют постоянное возрастание сложности ПО ЭИС. Современные крупные проекты ЭИС характеризуют, как правило, следующие особенности:
Сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного

моделирования и анализа данных и процессов.
Наличие совокупности тесно связанных подсистем, имеющих локальные задачи и цели функционирования.
Отсутствие полных аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем.
Необходимость интеграции существующих и вновь разрабатываемых приложений.
Функционирование в неоднородной среде на нескольких аппаратных платформах.
Разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств.
Значительная временная протяженность проекта, обусловленная с одной стороны, ограниченными возможностями коллектива разработчиков и различной степенью готовности отдельных ее подразделений к внедрению ЭИС.
Для успешной реализации проекта объект проектирования (ПО ЭИС) должен быть прежде всего адекватно описан, т.е. должны быть построены полные и непротиворечивые модели архитектуры ПО, включающие совокупность структурных элементов системы и связей между ними, поведение элементов системы в процессе их взаимодействия, а также иерархию подсистем, объединяющих структурные элементы.
Под моделью понимается полное описание системы ПО с определенной точки зрения. Модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы.
Моделирование является центральным звеном всей деятельности по созданию качественного ПО. Модели строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения.
Разработка модели архитектуры системы ПО промышленного характера на стадии, предшествующей ее реализации или обновлению, также необходима, как и наличие проекта для строительства большого здания.
Тема 1.
Программное обеспечение
Структура программного обеспечения ПК
Совокупность программ, предназначенная для решения задач на ПК, называется программным обеспечением. Состав программного обеспечения
ПК называют программной конфигурацией.

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

вспомогательные функции, например, создание копий используемой информации, выдачу справочной информации о компьютере, проверку работоспособности устройств компьютера и т.п.
К системному ПО относятся: операционные системы (эта программа загружается в ОЗУ при включении компьютера) программы – оболочки (обеспечивают более удобный и наглядный способ общения с компьютером, чем с помощью командной строки DOS, например, Norton Commander) операционные оболочки – интерфейсные системы, которые используются для создания графических интерфейсов, мультипрограммирования и.т.
Драйверы (программы, предназначенные для управления портами периферийных устройств, обычно загружаются в оперативную память при запуске компьютера) утилиты (вспомогательные или служебные программы, которые представляют пользователю ряд дополнительных услуг)
К утилитам относятся: диспетчеры файлов или файловые менеджеры средства динамического сжатия данных (позволяют увеличить количество информации на диске за счет ее динамического сжатия) средства просмотра и воспроизведения средства диагностики; средства контроля позволяют проверить конфигурацию компьютера и проверить работоспособность устройств компьютера, прежде всего жестких дисков средства коммуникаций (коммуникационные программы) предназначены для организации обмена информацией между компьютерами средства обеспечения компьютерной безопасности (резервное копирование, антивирусное ПО).
Необходимо отметить, что часть утилит входит в состав операционной системы, а другая часть функционирует автономно. Большая часть общего
(системного) ПО входит в состав ОС. Часть общего ПО входит в состав самого компьютера (часть программ ОС и контролирующих тестов записана в ПЗУ или ППЗУ, установленных на системной плате). Часть общего ПО относится к автономными программам и поставляется отдельно.
Прикладное ПО
Прикладные программы могут использоваться автономно или в составе программных комплексов или пакетов. Прикладное ПО – программы, непосредственно обеспечивающие выполнение необходимых работ на ПК: редактирование текстовых документов, создание рисунков или

картинок, создание электронных таблиц и т.д.
Пакеты прикладных программ – это система программ, которые по сфере применения делятся на проблемно – ориентированные, пакеты общего назначения и интегрированные пакеты. Современные интегрированные пакеты содержат до пяти функциональных компонентов: тестовый и табличный процессор, СУБД, графический редактор, телекоммуникационные средства.
К прикладному ПО, например, относятся:
Комплект офисных приложений MS OFFICE
Бухгалтерские системы
Финансовые аналитические системы
Интегрированные пакеты делопроизводства
CAD – системы (системы автоматизированного проектирования)
Редакторы HTML или Web – редакторы
Браузеры – средства просмотра Web - страниц
Графические редакторы
Экспертные системы
И так далее.
Инструментальное ПО
Инструментальное ПО или системы программирования - это системы для автоматизации разработки новых программ на языке программирования.
В самом общем случае для создания программы на выбранном языке программирования (языке системного программирования) нужно иметь следующие компоненты:
1. Текстовый редактор для создания файла с исходным текстом программы.
2. Компилятор или интерпретатор. Исходный текст с помощью программы- компилятора переводится в промежуточный объектный код. Исходный текст большой программы состоит из нескольких модулей (файлов с исходными текстами). Каждый модуль компилируется в отдельный файл с объектным кодом, которые затем надо объединить в одно целое.
3. Редактор связей или сборщик, который выполняет связывание объектных модулей и формирует на выходе работоспособное приложение – исполнимый код.
Исполнимый код – это законченная программа, которую можно запустить на любом компьютере, где установлена операционная система, для которой эта программа создавалась. Как правило, итоговый файл имеет расширение .ЕХЕ или .СОМ.
4. В последнее время получили распространение визуальный методы программирования (с помощью языков описания сценариев),

ориентированные на создание Windows-приложений. Этот процесс автоматизирован в средах быстрого проектирования. При этом используются готовые визуальные компоненты, которые настраиваются с помощью специальных редакторов.
Наиболее популярные редакторы (системы программирования программ с использованием визуальных средств) визуального проектирования:
Borland Delphi - предназначен для решения практически любых задачи прикладного программирования
Borland C++ Builder – это отличное средство для разработки DOS и
Windows приложений
Microsoft Visual Basic – это популярный инструмент для создания
Windows-программ
Microsoft Visual C++ - это средство позволяет разрабатывать любые приложения, выполняющиеся в среде ОС типа Microsoft Windows
Тема 2-3. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Понятие ЖЦ ПО. Международный стандарт ISO/IEC 12207: 1995. Основные и вспомогательные процессы ЖЦ ПО. Организация процессов ЖЦ. Связь между процессами.
ПОНЯТИЕ ЖЦ
Жизненный цикл (ЖЦ) программного обеспечения (ПО) определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим состав процессов
ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 “Information
Technology - Software Life Cycle Processes” (ISO - International Organization for
Standardization - Международная организация по стандартизации, IEC - International
Electrotechnical Commission - Международная комиссия по электротехнике. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
В данном стандарте ПО (или программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документации и данных.
Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.
Каждый процесс разделен на набор действий, каждое действие – на набор

задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным).
В России существуют стандарты:
ГОСТ 34601 - 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».
ГОСТ 34601 - 89. «Информационная технология. Комплекс стандартов на автоматизированные системы.
Техническое задание на создание автоматизированной системы».
ГОСТ 34601 - 92. «Информационная технология. Виды испытаний автоматизированных систем».
Однако процессы создания программного обеспечения для современных распределенных ЭИС, функционирующих в неоднородной среде, в этих стандартах отражены недостаточно, а отдельные их положения явно устарели. Поэтому в отечественных разработках целесообразно использовать современные международные стандарты.
В соответствии с ISO/IEC 12207: 1995 все процессы ЖЦ ПО разделены на три группы:
Основные процессы: приобретение; поставка; разработка; эксплуатация; сопровождение.
Вспомогательные процессы: документирование; управление конфигурацией; обеспечение качества; верификация; аттестация; совместная оценка; аудит; разрешение проблем.
Организационные процессы: управление; усовершенствование; создание инфраструктуры; обучение.
ОСНОВНЫЕ ПРОЦЕССЫ
Процесс приобретениясостоит из действий и задач заказчика:
Действие - инициирование приобретения - включает задачи:

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

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

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

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

и документации, подлежащих модификации, и внесение необходимых изменений в соответствии с правилами процесса разработки. Подготовленные изменения тестируются и проверяются по критериям, определенным в документации. При подтверждении корректности изменений в программах производится корректировка документации.
Проверка и приемка заключается в проверке целостности модифицированной системы и утверждении внесенных изменений.
При переносе ПО в другую среду используются имеющиеся или разрабатываются новые средства переноса, затем выполняется конвертирование программ и данных в новую среду. С целью облегчить переход предусматривается параллельная эксплуатация ПО в старой и новой среде в течение некоторого периода, когда проводится необходимое обучение пользователей в новой среде.
Снятие ПО с эксплуатации осуществляется по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей.
При этом программные продукты и соответствующая документация подлежат архивированию в соответствии с договором.
ВСПОМОГАТЕЛЬНЫЕ ПРОЦЕССЫ ЖЦ ПО
Процесс документирования предусматривает формализованное описание информации, созданной в течение ЖЦ ПО. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких, как руководство, технические специалисты и пользователи системы.
Процесс документирования включает действия: подготовительную работу; проектирование и разработку; выпуск документации; сопровождение.
Процесс
управления
конфигурацией
предполагает применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями
ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности ПО, управления хранением и поставкой ПО. Согласно стандарте IEEE - 90 под
конфигурацией ПО понимается совокупность ее функциональных и физических характеристик, установленных в технической документации и реализованных в ПО.
Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ ПО.
Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/IEC 12207-2: 1995 “Information Technology - Software Life
Cycle Processes. Part2. Configuration Management for Software”.
Процесс управления конфигурацией включает действия:

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

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

по приемке ПО.
Аттестация, так же как и верификация, может осуществляться с различными степенями независимости. Если процесс аттестации выполняется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой аттестации.
Процесс совместной оценки предназначен для оценки состояния работ по проекту и ПО. Он сосредоточен в основном на контроле планирования и управления ресурсами, персоналом, аппаратурой и инструментальными средствами проекта.
Оценка применяется как на уровне управления проектом, так и на уровне технической реализации проекта и проводится в течение всего срока договора.
Данный процесс может выполняться двумя любыми сторонами, участвующими в договоре, при этом одна сторона проверяет другую.
Процесс совместной оценки включает действия: подготовительную работу; оценку управления проектом; техническую оценку.
Процесс аудита представляет собой определение соответствия требованиям, планам и условиям договора. Аудит может выполняться двумя любыми сторонами, участвующими в договоре, когда одна сторона проверяет другую.
Аудит – это ревизия (проверка), проводимая компетентным органом (лицом) в целях обеспечения независимой оценки степени соответствия ПО или процессов установленным требованиям. Аудит служит для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Аудиторы не должны иметь прямой зависимости от разработчиков ПО. Они определяют состояние работ, использование ресурсов, соответствие документации требованиям и стандартам, корректность тестирования.
Процесс разрешения проблем предусматривает анализ и решение проблем
(включая обнаруженные несоответствия) независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов. Каждая обнаруженная проблема должна быть идентифицирована, описана, проанализирована и разрешена.
ОРГАНИЗАЦИОННЫЕ ПРОЦЕССЫ ЖЦ ПО
Процесс управления состоит из действий и задач, которые могут выполняться любой стороной, управляющей своими ресурсами. Данная сторона
(менеджер) отвечает за управление выпуском продукта, управление проектом и управление задачами соответствующих процессов, таких, как приобретение, поставка, разработка, эксплуатация, сопровождение и т.д.
Процесс управления включает следующие действия:
инициирование о определение области управления. Менеджер должен убедиться, что необходимые для управления ресурсы (персонал,

оборудование и технология) имеются в его распоряжении в достаточном количестве;
планирование подразумевает выполнение, как минимум, следующих задач: составление графиков выполнения работ; оценку затрат; выделение требуемых ресурсов; распределение ответственности; оценку рисков, связанных с конкретными задачами; создание инфраструктуры управления.
Процесс создания инфраструктуры охватывает выбор и поддержку
(сопровождение технологии), стандартов и инструментальных средств, выбор и установку аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к соответствующим процессам. Инфраструктура, в свою очередь, является одним из объектов управления конфигурацией.
Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.
Процесс обучения охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.
СВЯЗЬ МЕЖДУ ПРОЦЕССАМИ ЖЦ ПО
Процессы ЖЦ ПО, регламентированные стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (рис.1). Такими аспектами являются: договорный аспект; аспект управления; аспект эксплуатации; инженерный аспект; аспект поддержки.
В договорном аспекте заказчик и поставщик вступают в договорные отношения и реализуют соответственно процессы приобретения и поставки. В
аспекте управления заказчик, поставщик, разработчик, оператор, служба сопровождения и другие участвующие в ЖЦ ПО стороны управляют выполнением своих процессов. В аспекте эксплуатации оператор, эксплуатирующий систему, предоставляет необходимые услуги пользователям. В инженерном аспекте разработчик или служба сопровождения решают соответствующие технические задачи, разрабатывая или модифицируя программные продукты. В аспекте
поддержки службы, реализующие вспомогательные процессы, предоставляют необходимые услуги всем остальным участникам работ.

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