ТРПО_теория / Lect_trpo / lavrishcheva_petrukhin

Область знаний «Процесс инженерии ПО (Software Engineering Process)» состоит из следующих разделов:

–концепции процесса инженерии ПО (Software Engineering Process Concepts),

–инфраструктура процесса (Process Infrastructure),

–определение процесса (Process Definition),

–оценка процесс (Process Assessments),

–количественный анализ процесса (Qualitative Process Analysis),

–выполнение и изменение процесса.(Process Implementation and Change).

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

Инфраструктура процесса базируется на основных положениях стандартов IEEE/IEC 12207 и 15504, а также на видах ресурсов (групп разработчиков, технических средств, программных продуктов и др.) и процессе инженерии ПО (групповом или по типу экспериментальной фабрики (Experience Factory– EF), базирующейся на моделях проекта и продукта, моделях качества и риска. Инфраструктура включает уровни управления, отношения в коллективе, инженерные методы организации и интеграции программного продукта. Основной задачей EF является совершенствование ПО после получения опыта и уроков его разработки.

Определение процесса основывается на: типах процессов и моделей (водопадная, спиральная, итерационная и др.); моделях ЖЦ процессов и средств, стандартах ЖЦ ПО

ISO/IEC 12207 и 15504, IEEE std 1074-91 и 1219-92; а также методах и нотациях задания процессов и автоматизированных средствах их поддержки. Основной целью процесса является повышение качества получаемого продукта, улучшение различных аспектов программной инженерии, автоматизация процессов и др.

К нотациям определения процессов диаграммы потоков данных, диаграммы переходов и состояний. Ряд нотаций используются в рамках RUP. Есть специальные нотации для графического представления бизнес-процессов (Business Process Management Notation). Автоматизация заключается в использовании тех или иных диаграмм и нотаций (RUP, MSF, IBM, Rational Rose и др.).

Оценка процесса проводится с использованием соответствующих моделей и методов оценки. Например, оценка потенциальной способности специалиста для выполнения соответствующей работы. SWEBOK обращает внимание на необходимость проведения оценки возможности организации проводить разработку ПС на основе модели оценки зрелости (СММ [22]) и процессов, согласно которым проводится разработка ПО.

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

Качественный анализ процесса состоит в идентификации и поиске слабых мест в процессе создания ПО до начала его функционирования. Рассматривается две техники анализа: обзор данных и сравнение данного процесса с основными положениями стандарта ISO/IEC–12207; сбор данных о качестве процессов; анализ главных причин отказов в функционировании ПО, откат назад от точки

31

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

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

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

Таким образом, рассмотрение моделей ЖЦ и их особенностей, анализа процесса

рассмотренными задачами данной области знаний SWEBOK.

1. 9. Методы и средства инженерии ПО (Software Engineering Tools and Methods)

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

Область знаний «Методы и средства инженерии ПО (Software Engineering Tools and Methods)» состоит из разделов:

–инструменты (Software Tools),

–методы (Software Methods).

Инструменты ПО подразделяются на инструменты:

–работы с требованиями,

–проектирования ПО (редакторы схем и диаграмм),

–конструирования ПО (редакторы текстов, компиляторы, отладчики),

–тестирования (генераторы тестов, среды исполнения тестов),

–автоматизации процесса инженерии ПО,

–контроля качества,

–управления конфигурацией ПО (управление версиями, учет дефектов и решения этих проблем),

–управления инженерией ПО (планирование проектов, управление рисками).

Методы инженерии ПО включают эвристические (неформальные) методы – структурные, объектно-ориентированные, ориентированные на данные и на прикладную область, а также формальные методы проектирования и прототипирования.

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

32

1. 10. Качество ПО (Software Quality)

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

Стандарт ISO 9126-01 рассматривает внешние и внутренние характеристики качества.

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

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

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

Область знаний «Качество ПО (Software Quality)» состоит из следующих разделов:

–концепция качества ПО (Software Quality Concepts),

–определение и планирование качества (Definition & Planning for Quality),

–деятельности и техники гарантии качества и V&V(Activities and Techniques for Software Quality

Assurance, Validation –V & Verification – V),

– измерения в анализе качества ПО (Measurement in Software Quality Analysis).

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

Концепция качества ПО включает внешние и внутренние характеристики качества, их метрики, а также модели качества, определенные на множестве внешних и внутренних характеристик, которые определены в стандартах качества [16] – это шесть характеристик и для каждого из них 4-5 атрибутов. К характеристикам качества относятся:

33

–функциональность,

–надежность,

–удобства использования,

–эффективность,

–сопровождаемость,

–переносимость.

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

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

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

–определение продукта в терминах заданных характеристик качества;

–планирование процессов для получения требуемого качества;

–выбор методов оценки планируемых характеристик качества и установления соответствия продукта сформулированным требованиям.

В стандарте 12207 определены специальные процессы: обеспечения качества, верификации, аттестации (валидации), совместного анализа, аудита. Области ядра знаний SWEBOK (пп.1.7 и 1.8) предлагают методы разработки программных продуктов в организациях, занимающихся ПО.

Деятельности и техники гарантии качества включают: инспекцию, верификацию и валидацию ПО.

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

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

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

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

34

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

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

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

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

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

Таким образом, данная область знаний SWEBOK представляет методологию проведения мероприятий по достижению высокого качества ПО. Рассматриваются характеристики и атрибуты качества, согласно стандарта ISO 9126-98, и приведены способы их достижения на процессах ЖЦ ПО. Определяются виды и техники анализа ПО, прогонки системы на тестах и методы оценки показателей качества.

2. Введение в жизненный цикл ПО стандарта ISO/IEC 12207 и связь его с ядром знаний программной инженерией SWEBOK

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

воплощения в готовую программу, эксплуатации и изъятия. Такая последовательность этапов называется жизненным циклом (ЖЦ) разработки ПС. На каждом этапе ЖЦ выполняется определенная совокупность процессов и/или подпроцессов, каждый из

35

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

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

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

Разновидности действий и задач, представленные в процессах ЖЦ ПС, отображены в международном стандарте ISO\IEC 12207 (таблица 1) и связаны содержательно с областями знаний SWEBOK.

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

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

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

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

–основные процессы;

–обеспечивающие (поддерживающие) процессы;

–организационные процессы.

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

36

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

2.2Управление конфигурацией

2.3Обеспечение гарантии качества

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

2.5Валидация

2.6Общий просмотр

2.7Аудит

2.8Решение проблем

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

2.10Оценивание продукта

37

К основным процессам относятся:

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

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

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

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

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

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

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

38

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

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

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

Между стандартом ISO\IEC 12207 и ядром знаний SWEBOK существует связь и взаимовлияние друг на друга, тем более в разработке обоих документов примерно в одно время принимали участие высококвалифицированные специалисты в области программирования и информатики.

Общие идеи и методы программирования, сложившиеся в 90-х годах прошлого столетия, проникли в оба направления и оказали влияние на их структуру и содержание. Программисты–профессионалы систематизировали накопившиеся знания

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

изадачи процессов ЖЦ, чтобы построить ПО.

Таким образом, программная инженерии сформировалась как инженерная дисциплина, которая базируются на теоретических и прикладных методах и средствах разработки ПО, которые будут излагаться в данном учебнике более подробно, и стандартах (ISO/IEC 12207, 15404, ISO 9126 и др.), содержащих рекомендации, правила и методики управления разработкой ПО. Эти два базиса объединяет инженерия оценивания результатов на процессах ЖЦ, управление качеством ПО, оценка затраченных ресурсов на его создание и учета стоимости деятельности участников разработки.

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

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

39

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

3. Обучение специальности – программная инженерия

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

2)деятельность по созданию машин для предоставления полезных услуг.

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

В отличие от другой науки, целью которой есть получение знаний, в инженерии знание является способом получения некоторой пользы. Ф.Брукс [7] считает, что «ученый строит, чтобы научиться, инженер учится, чтобы строить».

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

40