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

–менеджеры, которые планируют и управляют проектом, отслеживают сроки и затраты;

–инженеры службы хранения готовых компонентов;

–технологи, которые определяют инженерные методы и стандарты, регламентирующие и регулирующие процесс построения программных проектов;

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

Инструменты поддержки разработки ПО совершили гигантский скачок в своем развитии и теперь обычной практикой стало создание ПС с использованием современных визуальных и диаграммных средств UML.

Таким образом, возникновение программной инженерии определено следующими факторами:

–появление разнообразных сложных методов анализа и моделирования ПО;

–большое количество ошибок в ПО;

–необходимость в эффективной организации работы коллективов разработчиков ПО;

–повторное использование готовых программных компонентов и высокотехнологических средств разработки и управления ПО;

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

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

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

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

Тема 2. Модели жизненного цикла для разработки программных систем.

Описываются основные модели ЖЦ, которые используются в практике проектирования программных систем. Дана характеристика фундаментальных моделей ЖЦ (водопадной, спиральной, инкрементной, эволюционной) и стандартной модели.

Тема 3. Методы определения требований в программной инженерии. Приведены методы и инженерия требований к системе. Рассмотрен процесс сбора, накопления и спецификации требований. Дана классификация требований и характеристика функциональных и нефункциональных требований.

Тема 4. Методы анализа и построения моделей ПрО. Приведены методы анализа предметной области и построения моделей. Рассмотрены объектно–ориентированные и стандартизованные, традиционные методы проектирования архитектуры системы.

11

Тема 5. Методы проектирования программных систем. Представлено описание базовых основ методов систематического (структурного, компонентного, аспектно– ориентированного и др.) и теоретического (алгебраического, композиционного и алгеброалгоритмичекого) программирования для ознакомления студентов с теорией и практикой проектирования ПС.

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

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

Тема 8. Методы интеграции, преобразования и изменения компонентов и данных. Рассмотрены основы интеграции и преобразования программ и данных, а также методы изменения (реинженерия, реверсная инженерия и рефакторинга) компонентов и систем.

Тема 9. Модели качества и надежности в программной инженерии. Посвящена представлению моделей качества ПС, метрикам и методам достижения и измерения качества ПС. Рассмотрен основной показатель качества – надежность, дано описание математических моделей надежности и способов их применения на практике.

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

Тема 11. Средства и инструменты программной инженерии. Дан обзор современных средств программирования и характеристика широко используемых CASE-средств

(Project Management, Rational Rose, MSF, RUP, CORBA, DCOM и др.), при объектно– ориентированном проектировании ПС.

Приложение 1. Набор основных терминов, используемых в программной инженерии. Приложение 2. Характеристика стандартов разработки автоматизированных систем. Приложение 3. Жизненный цикл компонентной разработки ПС.

Приложение 4. Кодекс этики в программной инженерии. Приложение 5. Стандарты в программной инженерии.

12

Тема 1 ВВЕДЕНИЕ В ПРОГРАММНУЮ ИНЖЕНЕРИЮ И ЖИЗНЕННЫЙ ЦИКЛ

ПО

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

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

Примерно каждые 10 лет происходит смена языков программирования и операционных сред для описания и функционирования программ. Это предполагает изменение ранее изготовленных и функционирующих программ в новые языки и операционные среды. На это тратятся огромные людские и финансовые ресурсы. Так, при изменении формата даты (2000 год) в программах и микросхемах на десятках млн. компьютеров участвовало более 2 млн. программистов, а затраты составили сотни млн. долларов. Переделка (реинженерия) ранее созданных прикладных Фортран программ в новые языки (С, Java и др.) и условия функционирования требует больших капиталовложений и привлечения программистов из третьих стран и СНГ.

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

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

13

Проектирование и создание новых компьютерных систем, в том числе из готовых компонентов (Reusing) и систем, теоретически и практически осуществляется с учетом современных возможностей платформ и распределенных сред, в которых компоненты распределяются по разным узлам сети и взаимодействуют между собой через сетевые протоколы. Появились новые методы и подходы к разработке ПО: структурный, объектно-ориентированный, компонентный, аспектный, визуальный – UML, агентноориентированный, сервисный и др. [3-13].

Разработано огромное количество разнообразных инструментальных средств поддержки процесса проектирования ПО и методов оценки качества, производительности, стоимости и т.п. Процесс разработки ПО и методы оценки продукта, процессов ЖЦ стандартизованы (ISO/IEC 12207 [14], 15504 [15], ISO 9126[16-18] и др.). Все это способствует повышению уровня проектирования, тестирования, прогнозирования надежности и оценки качества ПО.

Вместе с тем, новый программный проект разрабатывается 1-2 года, а эволюционирует 6-7лет. На его сопровождение тратиться 61% затрат против 39% на его разработку. Эффективность разработчиков в зависимости от квалификации колеблется в отношении 20:200, отсюда требуется повышать уровень знаний разработчиков ПО. На сегодня ядро стабильных знаний по программной инженерии составляет 75% от тех знаний, что используются в практической программисткой деятельности.

Society. В комитет вошли специалисты мирового уровня в области информатики и разработки ПО, которые внесли свой опыт и знания, а также систематизировали накопленные разнородные знания и определили (1999г., 2001г., 2004г.) ядро профессиональных знаний SWEBOK (Software Engineering Body Knowledge)

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

Программная инженерия (Software Engineering) является отраслью Computer science,

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

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

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

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

14

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

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

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

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

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

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

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

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

–отдельные готовые решения классифицированы и каталогизированы, а в программной инженерии каждая новая разработка - это новая проблема, в которой довольно тяжело рассмотреть аналогию с ранее разработанными системами.

Указанные отличия требуют проведения организационных и технических работ для превращения ее в специальность. В настоящее время мировая компьютерная общественность объединились в профессиональные комитеты и проводят такие работы: разработка ядра знаний SWEBOK, этического кодекса программиста [13], учебных курсов подготовки соответствующих специалистов, обучение специальности, сертификация специалистов в области программной инженерии и др.

15

Следующим шагом деятельности этих организаций и комитетов является создание общей компьютерной программы обучения – Curricula 2001 [8]. В ней содержатся рекомендации по структуре и преподаванию 15 учебных курсов по информатике (дискретные системы, программирование, теория сложности, ОС и др.) в том числе и по программной инженерии, как дисциплины, изучающей теорию, знания и практику эффективного построения ПО на всех этапах ЖЦ, которым соответствуют области знаний в SWEBOK.

В разработке больших программных проектов, кроме программистов, принимают участие:

–менеджеры, которые планируют и руководят проектом, отслеживают сроки и затраты;

–инженеры службы хранения готовых компонентов в библиотеках и репозитариях;

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

–использованием готовых программных компонентов, высоко технологических средств и инструментов разработки ПО;

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

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

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

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

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

16

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

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

1. Анализ и характеристика областей знаний SWEBOK

Ядра знаний SWEBOK [20] является основополагающим документом, отображает мнение многих зарубежных и отечественных специалистов в области программной инженерии [3-13] и согласуется с современными регламентированными процессами ЖЦ ПО стандарта ISO/IEC 12207. В этом ядре знаний содержится описание 10 областей, каждая из которых представлена согласно принятой всеми участниками создания этого ядра общей схемы описания, включающей определение понятийного аппарата, методов и средств, а также инструментов поддержки инженерной деятельности. Описание каждой области вносит определенный запас знаний, который должен практически использоваться на соответствующих процессах ЖЦ с учетом приведенного стандарта.

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

SWEBOK, их назначение и роль при проектировании и реализации программных продуктов.

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

1.1. Основы программных требований (Software Requirements)

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

Требования отражают потребности людей (заказчиков, пользователей, разработчиков),

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

17

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

Область знаний «Требования к ПО (Software Requirements)» состоит из следующих разделов:

–инженерия требований (Requirement Engineering),

–выявление требований (Requirement Elicitation),

–анализ требований (Requirement Analysis),

–спецификация требований (Requirement Specification).

–проверка требований (Requirement validation),

–управление требованиями (Requirement Menegement).

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

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

Управление требованиями к ПО заключается в планировании и контроле выполнения требований и проектных ресурсов в процессе разработки компонентов на этапах ЖЦ.

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

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

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

определяют условия и среду выполнения функций (например, защита и доступ к БД,

18

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

Спецификация требований к ПО – процесс формализованного описания функциональных и нефункциональных требований, требований к характеристикам качества в соответствии со стандартом качества ISO/IEC 9126-94, которые будут отрабатываться на этапах ЖЦ ПО. В спецификации требований отражается структура ПО, требования к функциям, качеству и документации, а также задается в общих чертах архитектура системы и ПО, алгоритмы, логика управления и структура данных. Специфицируются также системные требования, нефункциональные требования и требования к взаимодействию с другими компонентами и платформами (БД, СУБД, маршаллинг данных, сеть и др.).

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

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

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

1. 2. Проектирование ПО (Software design)

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

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

–базовые концепции проектирования ПО (Software Design Basic Concepts),

–ключевые вопросы проектирования ПО (Key Issue in Software Design),

–структура и архитектура ПО (Software Structure and Architecture),

19

–анализ и оценка качества проектирования ПО (Software Design Quality Analysis and Evaluation),

–нотации проектирования ПО (Software Design Notations),

–стратегия и методы проектирования ПО (Software Design Strategies and Methods).

К базовым концепциям проектирования ПО относятся процессы ЖЦ (стандарт

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

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

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

Паттерн – это конструктивный элемент ПО, который задает взаимодействие объектов (компонентов) проектируемой системы, определение ролей и ответственности исполнителей. Основным языком задания этого элемента является UML.

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

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

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

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

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

20