Министерство образования и науки Украины Государственное высшее учебное заведение
advertisement
Министерство образования и науки Украины Государственное высшее учебное заведение «Приазовский государственный технический университет» Е. Е. Пятикоп Технология создания программных продуктов Учебное пособие Рекомендовано Ученым советом ГВУЗ «ПГТУ» в качестве учебного пособия для студентов высших учебных учреждений Мариуполь 2016 УДК 004.413(075.8) ББК 32.973.2 П 994 Рекомендовано Ученым советом ГВУЗ «Приазовский государственный технический университет» в качестве учебного пособия для студентов высших учебных заведений (протокол № 11 от 25.02.015 г.). Рецензенты: Каргин А. А. – зав. кафедрой компьютерных технологий Донецкого национального университета, д. т. н, профессор (г. Винница); Назаренко Н. В. – доцент кафедры математических методов и системного анализа Мариупольского государственного университета, к.т.н. доцент; Симкин А. И. – зав. кафедрой автоматизации и компьютерных технологий ГВУЗ «Приазовский государственный технический университет», к.т.н., доцент. П 994 Пятикоп Е. Е. Технология создания программных продуктов : учебное пособие / Е. Е. Пятикоп. – Мариуполь : ПГТУ, 2016. – 232 с. Рассмотрены жизненный цикл создания программных продуктов, стратегии разработки и реализующие их модели жизненного цикла, международные и национальные стандарты, методологии разработки программ. Приведены основные понятия и классификации паттернов проектирования, архитектурных стилей, средств автоматизации разработки программ. Учебное пособие предназначено для студентов направления подготовки 6.050101 «Компьютерные науки». УДК004.413(075.8) ББК 32.973.2 © Е. Е. Пятикоп, 2016 © ГВУЗ «ПГТУ», 2016 2 Содержание Введение .................................................................................. 7 Часть 1. Жизненный цикл и стандарты программного обеспечения ............................................................................. 8 Раздел 1. Понятие программного обеспечения и проблемы разработки сложного программного обеспечения ......................................................................... 8 1.1 Понятие программного обеспечения ...................... 8 1.2 Классы программного обеспечения ........................ 9 1.3 Проблемы разработки сложного программного обеспечения ................................................................... 14 Контрольные вопросы .................................................. 17 Раздел 2. Жизненный цикл и процессы разработки программного обеспечения .............................................. 18 2.1 Понятие жизненного цикла .................................... 18 2.2 Модели каскадной стратегии ЖЦ ......................... 21 2.2.1 Классическая каскадная модель ..................... 21 2.2.2 Каскадная модель с обратными связями ....... 25 2.2.3 V-образная модель ........................................... 26 2.3 Модели инкрементной стратегии ЖЦ .................. 28 2.3.1 Классическая инкрементная модель .............. 30 2.3.2 Модель быстрой разработки приложений ..... 32 2.4 Модели эволюционной стратегии ЖЦ .................. 35 2.4.1 Спиральная модель .......................................... 38 2.4.2 Компонентно-ориентированная модель ........ 41 2.5 Модель прототипирования..................................... 42 2.6 Сравнение стратегий............................................... 45 2.7 Выбор модели жизненного цикла ......................... 47 Резюме ............................................................................ 52 Контрольные вопросы .................................................. 53 Раздел 3. Международные и национальные стандарты разработки сложных программных продуктов .............. 54 3.1 Понятие, виды и классификация стандартов ....... 54 3 3.2 Международные организации по стандартизации ИТ ................................................................................... 55 3.3 Стандарты в области ПО ........................................ 59 3.4 Комплекс стандартов ГОСТ 34.............................. 62 3.4.1 Стандарт ГОСТ 34.201-89 ............................... 62 3.4.2 Стандарт ГОСТ 34.601-90 ............................... 63 3.4.3 Стандарт ГОСТ 34.602-89 ............................... 66 3.4.4 Стандарт ГОСТ 34.603-92 ............................... 69 3.5 Семейство стандартов ISO/IEC 12207 .................. 69 3.5.1 Структура жизненного цикла ......................... 70 3.5.2 Основные процессы ......................................... 73 3.5.3. Вспомогательные процессы ........................... 74 3.5.4 Организационные процессы ........................... 79 3.5.5 Взаимосвязь между процессами жизненного цикла программного продукта................................. 81 3.6 ISO/IEC 15288:2002................................................. 83 3.6.1 Группы процессов в стандарте ....................... 85 3.6.2 Структура жизненного цикла ......................... 87 3.6.3 Сравнение с ISO/IEC 12207............................. 88 3.7 SWEBOK .................................................................. 90 Контрольные вопросы .................................................. 91 Часть 2. Методы и средства разработки программных средств .................................................................................... 93 Раздел 4. Методологии разработки программных средств ................................................................................ 93 4.1 Группы методологий .............................................. 93 4.2 Методология Rational Unified Process ................... 95 4.2.1 Принципы RUP................................................. 95 4.2.2 Этапы RUP ........................................................ 96 4.3 Методология Microsoft Solutions Framework...... 100 4.3.1 Принципы MSF .............................................. 100 4.3.2 Модель проектной группы MSF ................... 102 4.3.3 Модель процессов MSF ................................. 110 4.4 Методология Extreme Programming .................... 111 4 4.5 Методология Scrum .............................................. 115 4.5.1 Принципы Scrum ............................................ 116 4.5.2 Scrum- процессы............................................. 117 4.5.3 Команда Scrum ............................................... 120 4.6 Методология OpenUP ........................................... 123 4.7 Методология Feature Driven Development .......... 124 4.8 Методология Dynamic Systems Development Method .......................................................................... 127 4.8.1 Принципы DSDM ........................................... 127 4.8.2 Стадии DSDM................................................. 129 4.8.3 Участники DSDM........................................... 129 4.9 Сравнение методологий ....................................... 132 Контрольные вопросы ................................................ 141 Раздел 5. Паттерны проектирования программных средств .............................................................................. 143 5.1 Понятие паттерна, классификация ...................... 143 5.2 Паттерны проектирования ................................... 149 5.3 Паттерны проектирования классов/объектов ..... 151 Контрольные вопросы ................................................ 158 Раздел 6. Архитектура программных средств, стандарты описания архитектуры программных средств ............. 159 6.1 Место архитектурного проектирования в процессе разработки ПО ............................................................. 159 6.1 Архитектурное проектирование .......................... 163 6.2 Понятие архитектуры ПО .................................... 165 6.3 Классификация архитектурных стилей .............. 167 6.4 Структурные паттерны ......................................... 173 6.4.1 Паттерн (модель) репозитория ..................... 173 6.4.2 Паттерн (модель) клиент/сервер ................... 175 6.4.3 Паттерн (модель) многоуровневой системы или абстрактной машины ....................................... 177 6.4.4 Паттерн (модель) объектов ........................... 179 6.4.5 Паттерн (модель) потоков данных (конвейер или фильтр) .............................................................. 180 5 6.5 Паттерны управления ........................................... 182 6.5.1 Паттерны централизованного управления .. 182 6.5.2 Паттерны управления, основанные на событиях .................................................................. 186 6.5.3 Паттерны взаимодействия с базой данных.. 190 6.5.4 Паттерны для представления данных в Веб 193 6.6 Архитектурные концепции и методики Microsoft ....................................................................................... 201 Контрольные вопросы ................................................ 209 Раздел 7. Средства автоматизации разработки программных продуктов ................................................ 210 7.1 Понятие CASE-средства ....................................... 210 7.2 История развития CASE-средств ......................... 211 7.3 Базовые принципы построения CASE-средств .. 213 7.4 Классификация CASE-средств ............................ 215 7.4.1 Классификация по типам .............................. 217 7.4.2 Классификация по категориям ..................... 218 7.4.3 Классификация по методологии проектирования ....................................................... 221 Контрольные вопросы ................................................ 223 Библиографический список ............................................... 224 6 ВВЕДЕНИЕ Данное учебное пособие посвящено изучению различных технологий создания программного обеспечения на разных этапах жизненного цикла. Учебное пособие составлено на основе отраслевого стандарта высшего образования Украины «Образовательно-квалификационная характеристика бакалавра направления подготовки 6.050101 «Компьютерные науки» и в соответствии с рекомендуемыми модулями содержит две части: жизненный цикл и стандарты программного обеспечения; методы и средства разработки программных средств. Первая часть раскрывает вопросы, связанные с понятиями программного обеспечения, жизненного цикла, стратегиями и моделями разработки программного обеспечения. Приводится сравнение стратеги и параметры выбора моделей. Рассмотрены понятие, виды, классификация стандартов в сфере программного обеспечения, характеристики международных и национальных стандартов касательно жизненного цикла разработки программ. Вторая часть включает в себя рассмотрение методологий разработки программных средств (RUP, MSF, XP, Scrum, OpenUp, FDD, DSD), паттернов проектирования и средств автоматизации разработки программ. Данная часть охватывает вопросы архитектурного проектирования, архитектуры программного обеспечения, классификацию и описание архитектурных паттернов и стилей. Приведена общая систематизация CASE–средств. 7 ЧАСТЬ 1. ЖИЗНЕННЫЙ ЦИКЛ И СТАНДАРТЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РАЗДЕЛ 1. ПОНЯТИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ПРОБЛЕМЫ РАЗРАБОТКИ СЛОЖНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 1.1 Понятие программного обеспечения Под программным обеспечением (ПО) понимается совокупность программ, выполняемых вычислительной системой [1, 2, 3]. К программному обеспечению относится также вся область деятельности по проектированию и разработке ПО: технология проектирования программ; методы тестирования программ; методы доказательства правильности программ; анализ качества работы программ; документирование программ; разработка и использование программных средств, облегчающих процесс проектирования программного обеспечения, и многое другое. Программное обеспечение – неотъемлемая часть компьютерной системы. Оно является логическим продолжением технических средств. Сфера применения конкретного компьютера определяется созданным для него программным обеспечением. Сам по себе компьютер не обладает знаниями ни в одной области применения. Все эти знания сосредоточены в выполняемых на компьютерах программах. Программное обеспечение современных 8 компьютеров включает миллионы программ – от игровых до научных. 1.2 Классы программного обеспечения Существует два основных типа программного обеспечения [4]: системное (общее); прикладное (специальное). Каждый тип программного обеспечения выполняет различные функции. Системное программное обеспечение – это набор программ, которые управляют компонентами компьютера, такими как процессор, коммуникационные и периферийные устройства. Программистов, которые создают системное программное обеспечение, называют системными программистами. К прикладному программному обеспечению относятся программы, написанные для пользователей или самими пользователями, для задания компьютеру конкретной работы. Программы обработки заказов или создания списков рассылки – примеры прикладного программного обеспечения. Программистов, которые пишут прикладное программное обеспечение, называют прикладными программистами. Оба типа программного обеспечения взаимосвязаны и могут быть представлены в виде диаграммы, изображенной на рисунке 1.1. Как видно, каждая область тесно взаимодействует с другой. Системное программное обеспечение обеспечивает и контролирует доступ к аппаратному обеспечению компьютера. Прикладное программное обеспечение взаимодействует с аппаратными компонентами через системное. Конечные пользователи в основном работают с прикладным программным 9 обеспечением. Чтобы обеспечить аппаратную совместимость, каждый тип программного обеспечения разрабатывается для конкретной аппаратной платформы. Рисунок 1.1 – Структура и назначение программного обеспечения Системное ПО, в состав которого входят операционная система, трансляторы языков и обслуживающие программы, управляет доступом к аппаратному обеспечению. Прикладное ПО, такое как языки программирования и различные пользовательские приложения, работает с аппаратным обеспечением через слой системного ПО. Пользователи, в свою очередь, взаимодействуют с прикладным программным обеспечением. Программные системы можно классифицировать по различным признакам. Рассмотрим классификацию, в 10 которой основополагающим признаком является сфера (область) использования программных продуктов: аппаратная часть автономных компьютеров и сетей ЭВМ; функциональные задачи различных предметных областей; технология разработки программ. Для поддержки информационной технологии в этих областях выделяют соответственно три класса программных продуктов, представленных на рис.1.2: системное программное обеспечение; прикладное программное обеспечение; инструментальное программное обеспечение. Системное программное обеспечение (System Software) – совокупность программ и программных комплексов, предназначенная для обеспечения работы компьютера и сетей. Системное программное обеспечение выполняет следующие задачи: создание операционной среды функционирования других программ; обеспечение надежной и эффективной работы самого компьютера и вычислительной сети; проведение диагностики, локализации сбоев, ошибок и отказов и профилактики аппаратуры компьютера и вычислительных сетей; выполнение вспомогательных технологических процессов (копирование, архивирование, восстановление файлов программ и баз данных и т.д.). Данный класс программных продуктов тесно связан с типом компьютера и является его неотъемлемой частью, ориентирован на квалифицированных пользователей – профессионалов в компьютерной области: системного программиста, администратора сети, прикладного программиста, оператора. . 11 Рисунок 1.2 – Классы программных продуктов 12 Однако знание базовой технологии работы с этим классом программных продуктов требуется и конечным пользователям персонального компьютера, которые самостоятельно не только работают со своими программами, но и выполняют обслуживание компьютера, программ и данных. Программные продукты данного класса носят общий характер применения, независимо от специфики предметной области. К ним предъявляются высокие требования по надежности и технологичности работы, удобству и эффективности использования. Прикладное программное обеспечение представляет собой комплекс взаимосвязанных программ, предназначенный для решения задач определенного класса конкретной предметной области. Пакеты прикладных программ (ППП) общего назначения служат программным инструментарием решения функциональных задач и являются самым многочисленным классом программных продуктов. В данный класс входят программные продукты, выполняющие обработку информации различных предметных областей. Установка пакетов прикладных программ на компьютер выполняется системными администраторами, системными программистами, а также (в некоторых случаях) квалифицированными пользователями. Непосредственную эксплуатацию программных продуктов осуществляют, как правило, конечные пользователи – потребители информации, во многих случаях деятельность которых весьма далека от компьютерной области. Данный класс программных продуктов может быть весьма специфичным для отдельных предметных областей. Инструментарий технологии программирования представляет собой совокупность программ и программных комплексов, обеспечивающих технологию 13 разработки, отладки и внедрения создаваемых программных продуктов [3]. Инструментарий технологии программирования включает специализированные программные продукты, которые являются инструментальными средствами разработчика. Программные продукты данного класса поддерживают все технологические этапы процесса проектирования, программирования (кодирования), отладки и тестирования создаваемых программ. Пользователями технологии программирования являются системные и прикладные программисты. 1.3 Проблемы разработки сложного программного обеспечения Главная причина – логическая сложность решаемых задач. Дополнительные факторы, увеличивающие сложность разработки программных систем: сложность формального определения требований к программным системам. Обусловливается двумя факторами. Во-первых, при определении требований необходимо учесть большое количество различных факторов. Во-вторых, разработчики программных систем не являются специалистами в автоматизируемых предметных областях, а специалисты в предметной области, как правило, не могут сформулировать проблему в нужном ракурсе. коллективная разработка. Из-за больших объемов проектов разработка программного обеспечения ведется коллективом специалистов. Работая в коллективе, отдельные специалисты должны взаимодействовать друг с другом, обеспечивая целостность проекта, что при отсутствии удовлетворительных средств описания поведения сложных систем достаточно сложно. Причем, 14 чем больше коллектив разработчиков, тем сложнее организовать процесс работы; необходимость увеличения степени повторяемости кодов. Для увеличения производительности труда компании стремятся к созданию библиотек компонентов, которые можно было бы использовать в дальнейших разработках. Поэтому приходится делать компоненты универсальными, что увеличивает сложность разработки. С другой [5] стороны основные проблемы разработки сложных программных систем связаны с нахождением разумного компромисса между затратами на разработку и качеством ее результата. В затраты входят все виды используемых ресурсов, из которых наиболее важны затрачиваемое время, бюджет проекта и используемый персонал. Удовлетворение пользователей от работы с программой (а, следовательно, доходы от ее продаж и предоставления дополнительных услуг) и удовлетворение разработчиков от ее создания определяются качеством программы, которое включает в себя такие аспекты, как набор предоставляемых возможностей, надежность, удобство использования, гибкость, удобство внесения изменений и исправления ошибок. Более подробно понятие качественного программного обеспечения будет обсуждаться в одной из следующих тем. Возможны различные подходы к решению проблем разработки, связанных с обеими составляющими дилеммы «ресурсы – качество» при создании сложных программ. Для изложения этих подходов вводится система понятий, относящихся к программным системам и процессам их создания и позволяющих эффективно разрабатывать такие системы, оценивать и планировать их свойства. В их число входят такие понятия, как жизненный цикл ПО, качество 15 ПО, процесс разработки ПО, требования к ПО, архитектура ПО, образцы проектирования и пр. На основании опыта конструирования больших систем разработаны так называемые технологические процессы, содержащие достаточно детальные описания разных аспектов их создания и эксплуатации. Эти описания дают ответы на вопросы о том, как должна вестись разработка, какие лица должны в ней участвовать и на каких этапах, какие виды деятельности и в какой последовательности должны выполняться, какие документы являются их входными данными и какие документы, модели, другие части программной системы должны быть подготовлены в результате каждой отдельной работы. Элементы таких методик будут упоминаться на всем протяжении пособия. Так как программное обеспечение чаще разрабатывается не для собственного использования, а для других пользователей, т.е. для продажи на внутреннем и внешнем рынках, то оно является продуктом. В это случае ПО как продукция производственно-технического назначения должно отвечать ряду требований: должно создаваться в соответствии с государственными отраслевыми стандартами (ГОСТами); должно иметь установленную цену, согласованную с ведущими организациями – разработчиками программных средств; при реализации ПО должны быть особо оговорены вопросы совершенствования (модернизации) ПО организациями-поставщиками. тщательное документирование ПО обеспечивает возможность их применения пользователями различной квалификации. Состав и количество документации, сопровождающей ПО, определяются в соответствии с ГОСТами на ПО. 16 Поэтому важно также рассмотреть отраслевые стандарты, содержащие описание выработанных на основе большого количества реальных проектов подходов к построению сложных программных систем. Контрольные вопросы 1. Дайте определение термину программное обеспечение 2. На какие виды делится программное обеспечение? 3. Перечислите основные компоненты системного программного обеспечения и укажите их назначение. 4. Определите основные функции системного обеспечения. 5. Каковы функции прикладного программного обеспечения? 6. Как классифицируется прикладное программное обеспечение? 7. Укажите назначение и функции основных групп прикладного ПО. 8. К кикой группе относится служебное программное обеспечение? 9. Что включает в себя инструментальное программное обеспечение? 10. Привести примеры прикладного программного обеспечения. 11. Какие сложности могут возникать при разработке сложного программного обеспечения? 17 РАЗДЕЛ 2. ЖИЗНЕННЫЙ ЦИКЛ И ПРОЦЕССЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 2.1 Понятие жизненного цикла Жизненный цикл можно представить как ряд событий, происходящих с системой в процессе ее создания и использования. Жизненный цикл ПО – совокупность процессов, протекающих от момента принятия решения о создании ПО до его полного вывода из эксплуатации. Существуют 3 стратегии разработки ПО [1, 6]: водопадная (каскадная) стратегия (однократный проход) (waterfall strategy) линейная последовательность этапов конструирования; инкрементная стратегия (incremental strategy). В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система; эволюционная стратегия (evolutionary strategy). Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий. Характеристики стратегий конструирования ПО приведены в таблице 2.1. 18 Жизненный цикл Процесс Фаза План Действие Разработка проекта Спецификация Разработка Тестирование модуля Код Планы тестирования, результаты тестирования Показатель LOC Рисунок 2.1 Обобщенная схема процесса. 19 Эксплуатация Тестирование системы Планы тестирования, результаты тестирования Таблица 2.1 Характеристики стратегий разработки ПО В начале Множество Распространение Стратегия процесса циклов промежуточного разработки определены все разработки ПО требования Каскадная Да Нет Нет Инкрементная Да Да Может быть Эволюционная Нет Да Да Стратегию отражает модель жизненного цикла. Модель жизненного цикла (Software Life Cycle Model, SLCM) отражает различные состояния системы, начиная с момента возникновения необходимости данного ПО и заканчивая моментом его полного выхода из употребления. Модель жизненного цикла структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. Наибольшее распространение получили следующие модели жизненного цикла разработки ПП: каскадная модель, или «водопад» (Waterfall model); V-образная модель (V-shaped model); модель прототипирования (Рrоtоtуре mоdеl); модель быстрой разработки приложений, или RAD-модель (RAD – Rapid Application Dеvеlорmеnt model); инкрементная модель (Incremental model); спиральная модель (Spiral model) [7]. 20 2.2 Модели каскадной стратегии ЖЦ Каскадная (классическая) стратегия является старейшей парадигмой процесса разработки ПО, ее описал Уинстон В. Ройс (Winston W. Royce) в 1970 году. Каскадная стратегия представляет собой однократный проход этапов разработки. Данная стратегия основана на полном определении всех требований к разрабатываемому программному средству или системе в начале процесса разработки. Каждый этап разработки начинается после завершения предыдущего этапа. Возврат к уже выполненным этапам не предусматривается. Промежуточные продукты разработки в качестве версии программного средства (системы) не распространяются [7, 8]. 2.2.1 Классическая каскадная модель Модель данной стратегии подразумевает линейную последовательность прохождения стадий создания ПО (рис.2.2). Другими словами, переход с одной стадии на следующую происходит только после того, как будет полностью завершена работа на текущей. Рисунок 2.2 – Каскадная стратегия 21 Ройс разделил процесс на основные этапы (перечень этапов варьируется в изложении различных авторов). В соответствии с работой [6] содержание основных этапов подразумевает, что разработка начинается на системном уровне и проходит через анализ, проектирование, кодирование, тестирование и сопровождение. При этом моделируются действия стандартного инженерного цикла. Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ. Анализ требований относится к программному элементу – программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс. Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта. Проектирование состоит в создании представлений: архитектуры ПО; модульной структуры ПО; алгоритмической структуры ПО; структуры данных; входного и выходного интерфейса (входных и выходных форм данных). 22 Исходные данные для проектирования содержатся в спецификации анализа, то есть в ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений. При решении задач проектирования основное внимание уделяется качеству будущего программного продукта. Кодирование состоит в переводе результатов проектирования в текст на языке программирования. Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта. Сопровождение — это внесение изменений в эксплуатируемое ПО. Цели изменений: исправление ошибок; адаптация к изменениям внешней для ПО среды; усовершенствование ПО по требованиям заказчика. Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе но не в разработке новой программы. Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки . Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования. Недостатки классического жизненного цикла: реальные проекты часто требуют отклонения от стандартной последовательности шагов; цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично); результаты проекта доступны заказчику только в конце работы. 23 В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что необходимо возвращаться к более ранней фазе проекта. Это порождает необходимость реализовать все уже пройденные этапы заново, что приводит к росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально был спроектирован. Кроме того, эта модель не способна гарантировать необходимую скорость отклика и внесение соответствующих изменений в ответ на меняющиеся потребности пользователей, для которых программная система является одним из инструментов исполнения бизнес-функций. Области применения каскадной стратегии определяются ее достоинствами и ограничены ее недостатками. Использование данной стратегии наиболее эффективно в следующих случаях [9]: 1) при разработке проектов с четкими, неизменяемыми в течение ЖЦ требованиями и понятной реализацией; 2) при разработке проектов невысокой сложности, например: создание программного средства или системы такого же типа, как уже разрабатывались разработчиками; создание новой версии уже существующего программного средства или системы; перенос уже существующего продукта на новую платформу. 24 2.2.2 Каскадная модель с обратными связями Реализовать классическую каскадную модель ЖЦ в чистом виде затруднительно ввиду сложности разработки ПС без возвратов к предыдущим шагам и изменения их результатов для устранения возникающих проблем. поэтому В этой связи разработаны варианты каскадной модели между ее отдельными шагами, пример показан на рисунке 2.3. Показанную схему называют моделью «водоворота», она является более реальной и близкой к практике программирования. В отличие от классической, данная модель допускает параллельное выполнение отдельных работ (их перекрытие), а также возвраты назад, в том числе и на несколько фаз, в случае обнаружения ошибок. Рисунок 2.3 – Каскадная модель с обратными связями (модель «водоворота») 25 Каскадная модель с обратными связями обеспечивает большую надежность по сравнению с каскадной моделью, хотя увеличивается весь период разработки. 2.2.3 V-образная модель Другим вариантом модификации классической каскадной модели является V-образная модель, пример которой показан на рисунке 2.4. Основное назначение Vобразной модели – обеспечение планирования тестирования (испытаний) системы и программного средства на ранних стадиях проекта [8, 10]. Особенностью V-образной модели является то, что в ней выделены связи между шагами, предшествующими программированию, и соответствующими видами тестирования и испытаний. Данная модель направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты. Связи между деятельностью по разработке планов испытаний и тестирования и деятельностью по подтверждению результатов соответствующих этапов на рис. 2.4 обозначены пунктирными линиями. Таким образом, в данной модели есть место проверкам и аттестации. Поскольку V-образная модель поддерживает каскадную стратегию разработки ПС и систем, то она обладает всеми достоинствами данной стратегии. Кроме того, при подходящем использовании V-образная модель обладает следующими дополнительными достоинствами: 26 1) планирование тестирования и испытаний на ранних стадиях разработки системы и программного средства; 2) упрощение аттестации и верификации промежуточных результатов разработки; 3) упрощение управления и контроля хода процесса разработки. Рисунок 2.4 – V-образная модель При использовании V-образной модели для несоответствующего ей проекта выявляются следующие ее недостатки: 1) поздние сроки тестирования требований в жизненном цикле, что оказывает существенное влияние на 27 график выполнения проекта при необходимости изменения требований; 2) отсутствие, как и в остальных каскадных моделях, действий, направленных на анализ рисков. 2.3 Модели инкрементной стратегии ЖЦ Инкрементная стратегия (англ. increment – увеличение, приращение) подразумевает разработку информационной системы с линейной последовательностью стадий, но в несколько инкрементов (версий), т. е. с запланированным улучшением продукта. Инкрементная стратегия представляет собой многократный проход этапов разработки с запланированным улучшением результата [8, 11]. Данная стратегия основана на полном определении всех требований к разрабатываемому программному средству (системе) в начале процесса разработки. Однако полный набор требований реализуется постепенно в соответствии с планом в последовательных циклах разработки. Результат каждого цикла называется инкрементом. Первый инкремент реализует базовые функции программного средства. В последующих инкрементах функции программного средства постепенно расширяются, пока не будет реализован весь набор требований. Различия между инкрементами соседних циклов в ходе разработки постепенно уменьшаются. Результат каждого цикла разработки может распространяться в качестве очередной поставляемой версии программного средства или системы. Особенностью инкрементной стратегии является большое количество циклов разработки при 28 незначительной продолжительности цикла и небольших различиях между инкрементами соседних циклов. Инкрементная стратегия обычно основана на объединении элементов каскадной модели и прототипирования. Основными достоинствами инкрементной стратегии, проявляемыми при разработке соответствующего ей проекта, являются [8, 12]: 1) возможность получения функционального продукта после реализации каждого инкремента; 2) короткая продолжительность создания инкремента; это приводит к сокращению сроков начальной поставки, позволяет снизить затраты на первоначальную и последующие поставки программного продукта; 3) предотвращение реализации громоздких спецификаций требований; стабильность требований во время создания определенного инкремента; возможность учета изменившихся требований; 4) снижение рисков по сравнению с каскадной стратегией; 5) включение в процесс пользователей, что позволяет оценить функциональные возможности продукта на более ранних этапах разработки и в конечном итоге приводит к повышению качества программного продукта, снижению затрат и времени на его разработку. К основным недостаткам инкрементной стратегии, проявляющимся в результате ее несоответствующего применения, следует отнести: 1) необходимость полного функционального определения системы или программного средства в начале ЖЦ для обеспечения планирования инкрементов и управления проектом; 29 2) возможность текущего изменения требований к системе или программному средству, которые уже реализованы в предыдущих инкрементах; 3) сложность планирования и распределения работ; 4) проявление человеческого фактора, связанного с тенденцией к оттягиванию решения трудных проблем на поздние инкременты, что может нарушить график работ или снизить качество программного продукта. Области применения инкрементной стратегии определяются ее достоинствами и ограничены ее недостатками. Использование данной стратегии наиболее эффективно в следующих случаях [9]: 1) при разработке проектов, в которых большинство требований можно сформулировать заранее, но часть из них могут быть уточнены через определенный период времени; 2) при разработке сложных проектов с заранее сформулированными требованиями; для них разработка системы или программного средства за один цикл связана с большими трудностями; 3) при необходимости быстро поставить на рынок продукт, имеющий базовые функциональные свойства; 4) при разработке проектов с низкой или средней степенью рисков; 5) при выполнении проекта с применением новых технологий. 2.3.1 Классическая инкрементная модель Инкрементная модель является классическим примером инкрементной стратегии конструирования. Существуют различные варианты реализации инкрементных моделей. В классических вариантах модель основана на использовании полного заранее 30 сформированного набора требований, реализуемых последовательно в виде небольших инкрементов, образуя версии (рисунок 2.5). При этом каждая версия является законченным и работоспособным продуктом. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система. Рисунок 2.5– Инкрементная модель Существуют варианты модели, начинающиеся с формулирования общих требований. Требования постепенно уточняются в процессе разработки прототипов. Данные варианты инкрементных моделей похожи на эволюционные модели. Однако от последних они отличаются существенно большим количеством инкрементов при гораздо меньших различиях между соседними инкрементами [8, 13]. К таким вариантам моделей относится, например, модель ЖЦ, реализующая современную реализацию инкрементной стратегии – экстремальное программирование (см. раздел 4). При использовании инкрементной модели различия между последовательными прототипами постепенно уменьшаются. В каждой последующей версии системы или программного средства добавляются к предыдущей версии определенные программные компоненты, реализующие 31 соответствующие функциональные возможности до тех пор, пока не будут реализованы все требования к системе (программному средству). При этом каждая версия системы ли программного средства может сдаваться в эксплуатацию. Достоинства и недостатки этой модели такие же, как и у каскадной. Но в отличие от нее заказчик может раньше увидеть результаты. Уже по результатам разработки и внедрения первой версии он может незначительно изменить требования к разработке, отказаться от нее или предложить разработку более совершенного продукта с заключением нового договора. 2.3.2 Модель быстрой разработки приложений Модель быстрой разработки приложений (Rapid Application Development) — второй пример применения инкрементной стратегии конструирования ПО [1, 6] появилась в 80-е гг. XX в. в связи с бурным развитием мощных технологий и инструментальных средств разработки программных продуктов. Данная модель, исходя из особенностей ее реализации и целей ее использования, может поддерживать как инкрементную, так и эволюционную стратегию разработки [8]. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). Для этого процесса характерны небольшие группы разработчиков (3-7 чел.), выполняющие работы по проектированию отдельных подсистем ПО. Для RAD-подхода выделяет следующие этапы [6]: бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация 32 руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее? моделирование данных. Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами; моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных; генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RADпроцесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации; тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы). Общая модель быстрой разработки приложений приведена на рисунке 2.6. Особенность модели является участие конечного пользователя в формировании требований и апробации их на работающих прототипах совместно с разработчиками. 33 2-я группа Бизнесмоделирование 1-я группа Бизнесмоделирование Моделирование данных Моделирование обработки Генерация приложения Моделирование данных Тестирование и объединение Моделирование обработки Генерация приложения 60 – 90 дней Тестирование и объединение Рисунок 2.6 – Модель быстрой разработки приложений На рисунке 2.7.указаны этапы процесса разработки и штриховой линией отображено участие заказчиков на каждом из них. Рисунок 2.7 – Модель быстрой разработки приложений Модель обладает следующими достоинствами: использование современных инструментальных средств позволяет сократить время цикла разработки; 34 привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым ПП; повторно используются компоненты уже существующих программ. RAD-модель обеспечивает экстремально короткий цикл разработки. Применение RAD имеет и свои недостатки, и ограничения: для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп); RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной. RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии). Рассмотренную RAD-модель можно применять при разработке ПП, которые хорошо поддаются моделированию, когда требования к ПП хорошо известны, а заказчик может принять непосредственное участие в процессе разработки. 2.4 Модели эволюционной стратегии ЖЦ Эволюционная стратегия представляет собой многократный проход этапов разработки. Данная стратегия основана на частичном определении требований к разрабатываемому программному средству или системе в начале процесса разработки. Требования постепенно уточняются в последовательных циклах разработки. Результат каждого цикла разработки обычно представляет 35 собой очередную поставляемую версию программного средства или системы [8]. В общем случае для эволюционной стратегии характерно существенно меньшее количество циклов разработки при большей продолжительности цикла по сравнению с инкрементной стратегией. При этом результат каждого цикла разработки (очередная версия программного средства или системы) гораздо сильнее отличается от результата предыдущего цикла. Как и при инкрементной стратегии, при реализации эволюционной стратегии зачастую используется прототипирование. Основными достоинствами эволюционной стратегии, проявляемыми при разработке соответствующего ей проекта, являются: 1) возможность уточнения и внесения новых требований в процессе разработки; 2) пригодность промежуточного продукта для использования; 3) возможность управления рисками; 4) обеспечение широкого участия пользователя в проекте, начиная с ранних этапов, что минимизирует возможность разногласий между заказчиками и разработчиками и обеспечивает создание продукта высокого качества; 5) реализация преимуществ каскадной и инкрементной стратегий. К недостаткам эволюционной стратегии, проявляемым при ее несоответствующем выборе, следует отнести: 1) неизвестность точного количества необходимых итераций и сложность определения критериев для продолжения процесса разработки на следующей 36 итерации; это может вызвать задержку реализации конечной версии системы или программного средства; 2) сложность планирования и управления проектом; 3) необходимость активного участия пользователей в проекте, что реально не всегда осуществимо; 4) необходимость в мощных инструментальных средствах и методах прототипирования; 5) возможность отодвигания решения трудных проблем на последующие циклы, что может привести к несоответствию полученных продуктов требованиям заказчиков. Очевидно, что ряд недостатков эволюционной стратегии характерны и для инкрементной стратегии. Области применения эволюционной стратегии определяются ее достоинствами и ограничены ее недостатками. Использование данной стратегии наиболее эффективно в следующих случаях [9]: 1) при разработке проектов, для которых требования слишком сложны, неизвестны заранее, непостоянны или требуют уточнения; 2) при разработке сложных проектов, в том числе: больших долгосрочных проектов; проектов по созданию новых, не имеющих аналогов ПС или систем; проектов со средней и высокой степенью рисков; проектов, для которых нужна проверка концепции, демонстрация технической осуществимости или промежуточных продуктов; 3) при разработке проектов, использующих новые технологии. 37 2.4.1 Спиральная модель Спиральная модель — классический пример применения эволюционной стратегии конструирования ПО. Базовой в семействе спиральных моделей является классическая модель Боэма, разработанная в 1988 г. [9]. На рисунке 2.8 изображен вариант классической спиральной модели Боэма, которая поделена на четыре квадранта. В каждый квадрант модели входят основные и вспомогательные действия по разработке продукта или системы. В квадранте I – анализ целей, альтернативных вариантов и ограничений – определяются рабочие характеристики, выполняемые функции, стабильность (возможность внесения изменений), аппаратно/программный интерфейс продукта разработки данной фазы или цикла. Формулируются требования к данному продукту. Определяются альтернативные способы реализации системы или программного продукта (разработка, повторное использование компонент, покупка, договор подряда и т.п.). Определяются ограничения, налагаемые на применение альтернативных вариантов (затраты, график выполнения, интерфейс, ограничения среды и др.). Определяются риски, связанные с недостатком опыта в данной предметной области, применением новых технологий, жесткими графиками, недостаточно хорошо организованными процессами. В квадранте II – оценка альтернативных вариантов, идентификация и разрешение рисков – выполняется оценка альтернативных вариантов, рассмотренных в предыдущем квадранте; оценка возможных вариантов сокращения или устранения рисков. Выполняется прототипирование как основа для работ следующего квадранта. 38 Рисунок 2.8 – Модель быстрой разработки приложений 39 В квадрант III – разработка продукта текущего уровня – включаются действия по непосредственной разработке системы или программного продукта: разработка требований, проектирование системы и ее программных компонентов, квалификационные испытания продукта или системы и т.п. В квадранте IV – планирование следующей фазы – выполняются действия, связанные с решением о переходе на цикл следующей фазы разработки или выполнении еще одного цикла текущей фазы разработки, в частности, оценка заказчиком (пользователем) результатов текущего цикла, уточнение требований, разработка или коррекция планов проекта и следующего цикла, управление конфигурацией. Работа над проектом в соответствии со спиральной моделью начинается с определения заказчиком потребности в разработке системы или программного продукта (этап 1 квадранта I в центре спирали, см. рис. 2.8). В начале работы над проектом у заказчика и разработчика нет четкого видения итогового продукта (требования не могут быть четко определены) или стопроцентной уверенности в успешной реализации проекта. В связи с этим принимается решение разработки системы по частям с возможностью изменения требований или отказа от ее дальнейшего развития. Достоинства спиральной модели [1, 6]: 1) наиболее реально отображает разработку программного обеспечения; 2) позволяет явно учитывать риск на каждом витке эволюции разработки; 3) включает шаг системного подхода в итерационную структуру разработки; 4) использует моделирование для уменьшения риска и совершенствования программного изделия. 40 Недостатки спиральной модели: 1) новизна (отсутствует достаточная статистика эффективности модели); 2) повышенные требования к заказчику; 3) трудности контроля и управления временем разработки. 2.4.2 Компонентно-ориентированная модель Компонентно-ориентированная модель является развитием спиральной модели и тоже основывается на эволюционной стратегии конструирования. В этой модели конкретизируется содержание квадранта конструирования – оно отражает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов (рис. 2.9). Программные компоненты, созданные в реализованных программных проектах, хранятся в библиотеке. В новом программном проекте, исходя из требований заказчика, выявляются кандидаты в компоненты. Далее проверяется наличие этих кандидатов в библиотеке. Если они найдены, то компоненты извлекаются из библиотеки и используются повторно. В противном случае создаются новые компоненты, они применяются в проекте и включаются в библиотеку [1, 6]. Достоинства компонентно-ориентированной модели: 1) уменьшает на 30% время разработки программного продукта; 2) уменьшает стоимость программной разработки до 70%; 3) увеличивает в полтора раза производительность разработки. 41 Рисунок 2.9 – Модель быстрой разработки приложений 2.5 Модель прототипирования Прототип - это первоначальная версия системы, которая используются для апробирования возможностей дизайна и демонстрирования идей. Прототипы можно использовать на различных фазах разработки. Например, на этапе анализа требований при их нахождении и проверке; на этапе дизайна при исследовании выбора возможностей и планировании пользовательского интерфейса. 42 Как показано на рис. 2.10, прототипирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик. Рисунок 2.10 – Модель прототипирования Этапы прототипирования являются следующими: накопление требований - это делают на более общем уровне и там же фиксируют то, что в дальнейшем необходимо начать обязательно уточнять. интенсивное планирование - сосредоточение внимания на видимой части в результате чего и создается прототип. Клиент имеет возможность оценить прототип и на этой основе уточнить свои желания. итерация улучшения прототипа до тех пор, пока это не удовлетворит пользователя. В то же время разработчик получает новые идеи исходя из пожеланий клиента. 43 При разработке прототипа важно, чтобы он мог бы быть быстро создан, используя вспомогательные инструменты. Прототип не должен содержать в себе всей функциональности. В прототипе не должно быть контроля ошибок, и прототип направлен на функциональные требования. Прототипирование можно делать на различной основе – например: быстрое прототипирование; эволюционное прототипирование; инкрементное прототипирование. Преимущества прототипов: лучшее удобство при использовании системы, более точная совместимость с реальными потребностями пользователей; более высокое качество и более лучшее удобство сопровождения и меньше трудностей при разработке. Модель прототипирования обладает целым рядом преимуществ [7]: – взаимодействие заказчика с разрабатываемой системой начинается на раннем этапе; – благодаря реакции заказчика на прототип сводится к минимуму число неточностей в требованиях; – снижается вероятность возникновения путаницы, искажения информации или недоразумений при определении требований к ПП, что приводит к созданию более качественного ПП; – в процессе разработки всегда можно учесть новые, даже неожиданные требования заказчика; – прототип представляет собой формальную спецификацию, воплощенную в ПП; – прототип позволяет очень гибко выполнять проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла разработки; 44 – заказчик всегда видит прогресс в процессе разработки ПП; – возможность возникновения противоречий между разработчиками и заказчиками сведена к минимуму; – уменьшается число доработок, что снижает стоимость разработки: – возникающие проблемы решаются на ранних стадиях, что резко сокращает расходы на их устранение; – заказчики принимают участие в процессе разработки на протяжении всего жизненного цикла. Недостатки модели прототипирования: решение сложных задач может отодвигаться на будущее, заказчик может предпочесть получить прототип, а не законченную полную версию ПП, прототипирование может неоправданно затянуться, перед началом работы неизвестно, сколько итераций придется выполнить. Модель прототипирования рекомендуется применять в следующих случаях: требования к ПП заранее неизвестны; требования не постоянны или неудачно сформулированы; требования необходимо уточнить; нужна проверка концепции; существует потребность в пользовательском интерфейсе; выполняется новая, не имеющая аналогов разработка; разработчики не уверены в том, какое решение следует выбрать. 2.6 Сравнение стратегий Каждая из моделей имеет свои достоинства и недостатки, а также сферы применения в зависимости от специфики разрабатываемой системы, возможностей заказчика и разработчика и т. п. В таблице 2.2 приводится сравнительная характеристика рассмотренных выше моделей, которая должна помочь в выборе стратегии для конкретного проекта. 45 Таблица 2.2 Характеристики стратегий разработки ПО Модель (стратегия) Характеристика проекта Новизна разработки и обеспеченность ресурсами Масштаб проекта Сроки выполнения проекта Заключение отдельных договоров на отдельные версии Определение основных требований в начале проекта Изменение требований по мере развития проекта Разработка итерациями Распространение промежуточного ПО Каскадная Инкрементная Спиральная Типовой. Хорошо проработаны технология и методы решения задачи Нетиповой Ресурсов Ресурсов (новаторский). заказчика и заказчика или Нетрадиционн разработчика разработчика не ый для хватает для хватает для разработчика реализации реализации проекта в проекта в сжатые сжатые сроки сроки Малые и Средние и Любые средние крупные проекты проекты проекты До нескольких лет. Разработка До года одной версии может занимать срок от нескольких недель до года Заключается один договор. На отдельную версию или Версия и есть несколько последовательных итоговый версий обычно заключается результат отдельный договор проекта Да Да Нет Нет Незначительное Да Нет Да Да Нет Может быть Да 46 2.7 Выбор модели жизненного цикла Не существует единственной и наилучшей модели разработки системы. Решение, какую модель выбрать, необходимо вынести исходя из конкретного программного проекта: результата, навыков и знаний команды, временных графиков, выяснения и стабильности потребностей клиентов. Выбор приемлемой модели жизненного цикла разработки ПО для проекта может осуществляться на основе анализа следующих отличительных категорий проекта [8]: – команда разработчиков; – требования; – коллектив пользователей; – тип проекта и риски. Команда разработчиков. По возможности, в состав команды разработчиков лучше всего отобрать персонал еще до того, как будет выбрана модель жизненного цикла. Характеристики такой команды (таблица 2.3) играют важную роль в процессе выбора, поскольку она несет ответственность за удачное выполнение цикла и может оказать помощь в процессе выбора. Требования. Категория требований (таблица 2.4) состоит из вопросов относительно требований, которые предъявляет пользователь к проекту. В терминологии их иногда называют свойствами системы, которая будет поддерживаться данным проектом. 47 Являются ли проблемы предметной области проекта новыми для большинства разработчиков? Является ли технология предметной области проекта новой для большинства разработчиков? Являются ли инструменты, используемые проектом, новыми для большинства разработчиков? Изменяются ли роли участников проекта во время жизненного цикла? Могут ли разработчики проекта пройти обучение? Является ли структура более значимой для разработчиков, чем гибкость? Будет ли менеджер проекта строго отслеживать прогресс команды? Важна ли легкость распределение ресурсов? Приемлет ли команда равноправные обзоры и инспекции, менеджмент/обзоры заказчика, а также стадии? Нет Нет Да Да Инкрементная Быстрой разработки Спиральная Прототипирование V-образная Команда разработчиков проекта Каскадная Таблица 2.3 Выбор модели жизненного цикла на основе характеристик участников команды разработчиков Нет Нет Да Да Нет Да Нет Да Да Да Нет Да Нет Нет Нет Нет Да Да Нет Да Нет Да Нет Нет Да Да Да Нет Нет Нет Да Да Да Нет Да Да Да Нет Нет Да Да Да Да 48 Да Да Нет Да Да Нет Да Являются ли требования легко определимыми и/или хорошо известными? Могут ли требования заранее определяться в цикле? Часто ли будут изменяться требования в цикле? Нужно ли демонстрировать требования с целью определения? Требуются ли для демонстрации возможностей проверка концепции? Будут ли требования отражать сложность системы? Обладает ли требование функциональными свойствами на раннем этапе? Инкрементная Быстрой разработки Спиральная Прототипирование V-образная Требования Каскадная Таблица 2.4 Выбор модели жизненного цикла на основе характеристик требований Да Да Нет Нет Да Нет Да Да Нет Нет Да Да Нет Нет Да Да Нет Нет Нет Нет Да Да Да Нет Нет Нет Да Да Да Нет Нет Нет Да Да Нет Да Нет Нет Да Да Да Да Коллектив пользователей. На начальных фазах проекта можно получить четкое представление о коллективе пользователей (табл. 2.5) и его будущей взаимосвязи с командой разработчиков на протяжении всего проекта. Такое представление поможет вам при выборе подходящей модели, поскольку некоторые модели требуют усиленного участия пользователей в процессе разработки и изучения проекта. 49 Будет ли присутствие пользователей ограничено в жизненном цикле? Будут ли пользователи знакомы с определением системы? Буду ли пользователи ознакомлены с проблемами предметной области? Будут ли пользователи вовлечены во все фазы жизненного цикла? Будет ли заказчик отслеживать ход выполнения проекта? Да Да Нет Да Инкрементная Быстрой разработки Спиральная Прототипирование V-образная Коллектив пользователей Каскадная Таблица 2.5 Выбор модели жизненного цикла на основе характеристик коллектива пользователей Нет Да Нет Нет Да Да Нет Да Нет Нет Да Нет Да Да Нет Нет Да Нет Да Нет Нет Нет Да Да Нет Нет Тип проекта и риски. И, наконец, уточним, что собой представляют тип проекта и риски (таблица 2.6), которые были рассмотрены как элементы, определение которых осуществляется на фазе планирования. В некоторых моделях предусмотрен менеджмент рисков высокой степени, в то время как в других он не предусмотрен вообще. Выбор модели, которая делает возможным менеджмент рисков, не означает, что вам не нужно составлять план действий, направленный на минимизацию выявленных рисков. Такая модель просто обеспечивает схему, в рамках которой можно обсудить и выполнить данный план действий. 50 Будет ли проект идентифицировать новое направление продукта для организации? Будет ли проект иметь тип системной интеграции? Будет ли проект являться расширением существующей системы? Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла? Ожидается ли длительная эксплуатация продукта в организации? Должна ли быть высокая степень надежности? Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения? Является ли график ограниченным? Являются ли "прозрачными" интерфейсные модули? Доступны ли повторное используемые компоненты? Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)? Инкрементная Быстрой разработки Спиральная Прототипирование V-образная Команда разработчиков проекта Каскадная Таблица 2.6 Выбор модели жизненного цикла на основе характеристик типа проектов и рисков Нет Нет Да Да Нет Да Нет Да Да Да Да Да Нет Да Нет Нет Да Да Да Да Да Нет Да Да Нет Да Нет Да Нет Да Нет Да Нет Нет Да Да Нет Нет Да Да Нет Да Нет Нет Да Да Да Да Да ^J Нет Нет Нет Да Нет Нет Да Да Да Нет Нет Да Да Нет Нет 51 Нет Резюме Таблица 2.7 Модели жизненного цикла разработки программного продукта Название 1 Каскадная модель V-образная модель Модель прототипирования Модель быстрой разработки приложений Инкрементная модель Спиральная модель Характеристики 2 Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль за ходом работы. Разрабатываемое программное обеспечение не доступно для изменений Простая в использовании. Особое значение придается тестированию и сравнению результатов фаз тестирования и проектирования Создается «быстрая» частичная реализация системы до составления окончательных требований. Обеспечивается обратная связь между пользователями и разработчиками в процессе выполнения проекта. Используемые требования не полные Проектные группы небольшие (3–7 человек) и составлены из высококвалифицированных специалистов. Уменьшенное время цикла разработки (до 3 мес.) и улучшенная производительность. Повторное использованис кода и автоматизация процесса разработки Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе разработки. Невозможен переход от текущей реализации к новой версии в течение построения текущей частичной реализации Охватывает каскадную модель. Разбивает фазы на меньшие части. Позволяет гибко выполнять проектирование. Анализирует риски и управляет ими. Пользователи знакомятся с ПП на более раннем этапе благодаря прототипам. 52 Контрольные вопросы 1. Какие этапы каскадного жизненного цикла вы знаете? 2. Охарактеризуйте содержание этапов классического каскадного жизненного цикла. 3. Объясните достоинства и недостатки классического каскадного жизненного цикла. 4. Чем отличается классический каскадный жизненный цикл от модели «водоворота»? 5. Чем отличаются друг от друга стратегии конструирования ПО? 6. Укажите сходства и различия каскадной и инкрементной стратегий. 7. Какие существуют модели инкрементной стратегии? 8. Объясните достоинства и недостатки классической инкрементной модели. 9. Чем отличается модель быстрой разработки приложений от инкрементной модели? 10. Объясните достоинства и недостатки модели быстрой разработки приложений. 11. Укажите сходства и различия спиральной и каскадной моделей жизненного цикла. 12. В чем состоит главная особенность спиральной модели? 13. Чем отличается компонентно-ориентированная модель от спиральной модели жизненного цикла? 14. Перечислите достоинства и недостатки компонентно-ориентированной модели. 15. Что представляет собой прототип программного продукта? 16. Какие факторы влияют на выбор модели жизненного цикла? 53 РАЗДЕЛ 3. МЕЖДУНАРОДНЫЕ И НАЦИОНАЛЬНЫЕ СТАНДАРТЫ РАЗРАБОТКИ СЛОЖНЫХ ПРОГРАММНЫХ ПРОДУКТОВ 3.1 Понятие, виды и классификация стандартов Международная организация по стандартизации (ИСО) приняла следующее определение: Стандарт документ, составленный в сотрудничестве и с согласия или общего одобрения всех заинтересованных в этом сторон, основанный на использовании обобщенных результатов науки, техники и практического опыта, направленный на достижение оптимальной пользы для общества и утвержденный органом, занимающимся стандартизацией. В Украине принята формулировка термина «стандарт», отражающая специфику стандартизации в нашей стране [14]: Cтандарт - нормативный документ, основанный на консенсусе, принятый признанным органом, который устанавливает для общего и многократного использования правила, инструкции или характеристики относительно деятельности или ее результатов, и направлен на достижение оптимальной степени упорядоченности в определенной сфере. В соответствии с законом об стандартизации от 05.06.2014 № 1315-VII [14] различают следующие виды стандартов: международный стандарт – стандарт, принятый международной организацией по стандартизации и доступный широкому кругу пользователей; межгосударственный стандарт – региональный стандарт, предусмотренный Соглашением о проведении 54 согласованной политики в области стандартизации, метрологии и сертификации от 13 марта 1992 и принят Межгосударственным советом по стандартизации, метрологии и сертификации; региональный стандарт – стандарт, принятый региональной организацией по стандартизации и доступный широкому кругу пользователей. европейский стандарт – региональный стандарт, принятый европейской организацией стандартизации; национальный стандарт – стандарт, принятый национальным органом стандартизации и доступный широкому кругу пользователей; По объектам стандартизации стандарты делят на три группы: стандарты на свойства, методы и средства. Категории нормативных документов в зависимости от объекта стандартизации и сферы деятельности распределяются так [15]: государственные стандарты Украины (Державні стандарти України – ДСТУ); отраслевые стандарты Украины (Галузеві стандарти України – ГСТУ); стандарты научно-технических обществ Украины (Стандарти науково-технічних та інженерних товариств України – СТТУ); технические условия (ТУ); стандарты предприятий (СТП). 3.2 Международные организации по стандартизации ИТ Основными организациями, занятыми вопросами стандартизации в сфере разработки ПО являются: ISO (International Organization for Standardization) – Международная организация по стандартизации; 55 IEC (МЭК) (International Electrotechnical Commission) – Международная электротехническая комиссия; JTC1 (Joint Technical Committee 1) – Объединенный технический комитет 1; ITU (МСЭ) (International Telecommunication Union) – Международный союз электросвязи; IEEE (Institute of Electrical and Electronics Engineers) – Институт инженеров по электротехнике и электронике; SEI (Software Engineering Institute) Институт программной инженерии. Международная организация по стандартизации (ИСО) создана в 1946г. двадцатью пятью национальными организациями по стандартизации. Сфера деятельности ИСО1) касается стандартизации во всех областях, а также связана с проблемами сертификации. Основной задачей ИСО является содействие развитию стандартизации и смежных видов деятельности в мире с целью обеспечения международного обмена товарами и услугами, а также развития сотрудничества в интеллектуальной, научно–технической и экономической областях. В последнее десятилетие ИСО уделяет много внимания стандартизации систем обеспечения качества, учитывая ожидания всех заинтересованных сторон – производителей продукции (услуг), потребителей, правительственных кругов, научно-технических и общественных организаций. 1) При создании организации и выборе ее названия учитывалась необходимость того, чтобы аббревиатура наименования звучала одинаково на всех языках. Для этого было решено использовать греческое слово «isos» – равный. Поэтому на всех языках мира Международная организация по стандартизации имеет краткое название ISO (ИСО). 56 На сегодняшний день в состав ИСО входят около 120 стран своими нaциoнальными организациями по стандартизации. Всего в составе ИСО более 80 комитетовчленов. Довольно широки деловые контакты ИСО: с ней поддерживают связь около 500 международных организаций, в том числе все cпeциализиpoвaнныe агентства ООН, работающие в смежных направлениях. Крупнейший партнер ИСО – Международная электротехническая комиссия (МЭК). Вопросы информационной технологии, микропроцессорной техники и т.п. входят в область совместных разработок ИСО/МЭК. В целом эти две организации охватывают международной стандартизацией все области техники. Кроме того, они стабильно взаимодействуют в области информационных технологий и телекоммуникации. Международные стандарты ИСО не имеют статуса обязательных для всех стран–участниц. Любая страна мира вправе применять или не применять их. Решение вопроса о применении международного стандарта ИСО связано в основном со степенью участия страны в международном разделении труда и состоянием ее внешней торговли. ИСО поддерживает постоянные рабочие отношения с региональными организациями по стандартизации. Практически члены таких организаций одновременно являются членами ИСО. Поэтому при разработке региональных стандартов за основу принимается стандарт ИСО нередко еще на стадии проекта. Наиболее тесное сотрудничество поддерживается между ИСО и Европейским комитетом по стандартизации СЕН (Comité Européen de Normalisation, CEN) — международная некоммерческая организация, основной целью которой является содействие развитию торговли товарами и 57 услугами путём разработки европейских стандартов (евронорм, EN) [16]. Объединенный технический комитет JTC1 был создан в 1987 г. путем объединения деятельности в области стандартизации ИТ двух организаций: ИСО и МЭК. JTC1 формирует всеобъемлющую систему базовых стандартов в области ИТ и их расширений для конкретных сфер деятельности. JTC1 имеет 17 подкомиссий, чья работа покрывает все: от техники программного обеспечения до языков программирования, компьютерной графики и обработки изображения, соединения оборудования, методов защиты и т. д. Работа над стандартами ИТ в JTC1 тематически распределена по подкомитетам (Subcommittees – SC). Ниже перечислены основные подкомитеты и группы JTC1, связанные с разработкой стандартов ИТ, относящихся к окружению открытых систем (Open Systems Environment – OSE): C2 – Символьные наборы и кодирование информации; SC6 – Телекоммуникация и информационный обмен между системами; SC7 – Разработка программного обеспечения и системная документация; SC18 – Текстовые и офисные системы; SC21 – Открытая распределенная обработка (Open Distributed Processing – ODP), управление данными (Data Management – DM) и взаимосвязь открытых систем (OSI); SC22 – Языки программирования, их окружение и интерфейсы системного программного обеспечения; SC24 – Компьютерная графика; SC27 – Общие методы безопасности для ИТ– приложений; 58 SGFS – Cпeциальная группа по фyнкциoнальным стaндapтaм. Институт инженеров по электротехнике и электронике — международная некоммерческая ассоциация специалистов в области техники, мировой лидер в области разработки стандартов по радиоэлектронике, электротехнике и аппаратному обеспечению вычислительных систем и сетей, появилась в 1963 году, в результате слияния Института радиотехников, и Американского института инженеров-электриков. Главная цель IEEE — информационная и материальная поддержка специалистов для организации и развития научной деятельности в электротехнике, электронике, компьютерной технике и информатике, приложение их результатов для пользы общества, а также профессиональный рост членов IEEE. IEEE, объединяя более 400 000 индивидуальных членов из 170 стран (в том числе более 100 000 студентов), издаёт третью часть мировой технической литературы, касающейся применения радиоэлектроники, компьютеров, систем управления, электротехники, в том числе (январь 2011 года) 122 реферируемых научных журнала и 36 отраслевых журналов для специалистов, проводит в год более 300 крупных конференций. Ассоциация принимала участие в разработке около 900 действующих стандартов [17]. 3.3 Стандарты в области ПО Стандарты в области программного обеспечения дают возможность разработчикам программного обеспечения использовать данные и программы других разработчиков, осуществлять экспорт/импорт данных. Стандарты занимают все более значительное место в направлении развития индустрии информационных 59 технологий. Более 250 подкомитетов в официальных организациях по стандартизации работают над стандартами в области информационных технологий. Более 1000 стандартов или уже приняты этими организациями, или находятся в процессе разработки. Процесс стандартизации информационных технологий далеко не закончен, так как область информационных технологий постоянно динамично развивается. [7]. Необходимость стандартизации разработки программного обеспечения наиболее удачно описана во введении в стандарт ISO/IEC 12207: «Программное обеспечение является неотъемлемой частью информационных технологий и традиционных систем, таких, как транспортные, военные, медицинские и финансовые. Имеется множество разнообразных стандартов. Это разнообразие создает трудности при проектировании и управлении программным обеспечением, особенно при объединении программных продуктов и сервисных программ. Стратегия разработки программного обеспечения требует перехода от этого множества к общему порядку, который позволит специалистам, практикующимся в программном обеспечении, «говорить на одном языке» при разработке и управлении программным обеспечением. Международный стандарт обеспечивает такой общий порядок» [18]. Порядок в многообразии стандартов, действующих в сфере ИТ, и классификация их представлены на рисунке 3.1. Рассмотрим разновидности нормативных документов, которые рекомендуются руководством 2-й Международной организации по стандартизации и Международной электротехнической комиссии (ИСО/МЭК), а также принятые в государственной системе стандартизации. 60 Стандарты на организацию жизненного цикла Стандарты обеспечения качества Стандарты надежности Стандарты документирования Стандарты тестирования Стандарты разработки ПО Стандарты интерфейса Стандарты обмена данными Другие стандарты Стандарты программирования Рисунок 3.1 - Стандарты, действующие в сфере ИТ Чтобы проиллюстрировать, какой путь проделали стандарты в ИТ за последние годы, и показать, чем современные процессно-ориентированные стандарты принципиально отличаются от традиционных, рассмотрим стандарты в хронологическом порядке. 61 3.4 Комплекс стандартов ГОСТ 34 ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Комплекс рассчитан на взаимодействие заказчика и разработчика, в основном уделяет внимание содержанию проектных документов. Данный стандарт до сих пор олицетворяет для многих управленцев и ИТ-специалистов понятие ИТ-стандарта вообще, включает совокупность взаимосвязанных стандартов, имеют номер, начинающийся на 34: ГОСТ 34.201-89. «Виды, комплектность и обозначение документов при создании автоматизированных систем» [19]; ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» [20]; ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»; ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [21]. 3.4.1 Стандарт ГОСТ 34.201-89 Серьезно устаревший, но отчасти пригодный для использования стандарт, устанавливает соответствие документов стадиям создания АС1, описанным в ГОСТ 34.601 [21]. По составу документов и стадиям проекта можно проследить происхождение стандарта из практики строительства. Такие документы, упомянутые в стандарте, как «Техническое задание», «Эскизный проект», «Технический проект», «Инструкция» (пользователя), «Программа и методика испытаний» прочно вошли в практику создания систем. С другой стороны, «Ведомость машинных носителей информации», «Каталог базы 62 данных» или «Ведомость держателей подлинников» вряд ли сейчас имеют смысл. Стандарт включает также элементы практики делопроизводства в виде правил кодирования документов. Данный стандарт может быть использован в тех организациях, где проектная деятельность регулируется аналогичными проектноориентированными стандартами, а состав проектных документов близок к тому, что предлагает ГОСТ 34.201-89 [22]. 3.4.2 Стандарт ГОСТ 34.601-90 Один из наиболее применяемых до сих пор стандартов [21], определяющий стадии и этапы создания автоматизированной системы. Таблица 3.1 является центральной в стандарте. Практически все перечисленные стадии и этапы до сих пор встречаются в практике создания информационных систем предприятий и организаций. Стандарт демонстрирует точное соответствие своим целям. Во-первых, он не требует знаний в области ИТ и, следовательно, понятен обычным управленцам. Вовторых, он компактен и прост по структуре, что позволяет человеку, не знакомому с ним, быстро войти в курс дела. В-третьих, он самодостаточен - практически никаких ссылок на смежные документы в нем нет. И наконец, он практичен - сразу понятно, как его применять и как контролировать его применение [22]. Помимо таблицы ГОСТ 34.601-90 содержит справочное Приложение 1 с поэтапной расшифровкой работ, включая указание на документы, возникающие в результате этих работ, а также Приложение 2 – «Перечень организаций, участвующих в работах по созданию АС». Это подсказывает способ адаптации стандарта к 63 конкретным условиям: достаточно переработать Приложения, и получится вполне разумный корпоративный стандарт на создание ИС. Таблица 3.1 – Стадии и этапы создания автоматизированной системы по ГОСТ 34.601-90 Стадии Этапы 1. Формирование 1.1. Обследование объекта и требований к АС обоснование необходимости создания АС 1.2. Формирование требований пользователя к АС 1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания) 2. Разработка 2.1. Изучение объекта концепции АС 2.2. Проведение необходимых научноисследовательских работ 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя 2.4. Оформление отчета о выполненной работе 3. Техническое 3.1 Разработка и утверждение задание технического задания на создание АС 4. Эскизный 4.1. Разработка предварительных проект проектных решений по системе и ее частям 4.2. Разработка документации на АС и ее части 5. Технический 5.1. Разработка проектных решений по проект системе и ее частям 5.2. Разработка документации на АС и ее части 64 Продолжение таблицы 3.1 – Стадии и этапы создания автоматизированной системы по ГОСТ 34.601-90 Стадии Этапы 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации 6. Рабочая 6.1. Разработка рабочей документации документация на систему и ее части 6.2. Разработка или адаптация программ 7. Ввод в 7.1. Подготовка объекта автоматизации действие к вводу АС в действие 7.2. Подготовка персонала 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями) 7.4. Строительно-монтажные работы 7.5. Пусконаладочные работы 7.6. Проведение предварительных испытаний 7.7. Проведение опытной эксплуатации 7.8. Проведение приемочных испытаний 8. Сопровождение 8.1. Выполнение работ в соответствии с АС гарантийными обязательствами 8.2. Послегарантийное обслуживание 65 3.4.3 Стандарт ГОСТ 34.602-89 Требование «подготовить Техническое задание в соответствии с ГОСТ 34.602-89», знакомо, наверное, каждому, кто хоть однажды участвовал в заказной разработке ИС или ее приемке, да и вообще всем, кто так или иначе связан с информационными системами. Некоторые разработчики до сих пор считают хорошим тоном помнить наизусть состав Технического задания (ТЗ) в соответствии с ГОСТ 34.602-89 [20]: 1. Общие сведения. 2. Назначение и цели создания (развития) системы. 3. Характеристика объектов автоматизации. 4. Требования к системе. 5. Состав и содержание работ по созданию системы. 6. Порядок контроля и приемки системы. 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. 8. Требования к документированию. 9. Источники разработки. Весь стандарт представляет собой расшифровку перечисленных девяти пунктов. Размер его - всего 11 страниц, но объем сообщаемой полезной информации на удивление велик. Если выбросить явные архаизмы, вроде существовавших когда-то фондов алгоритмов и программ, окажется, что практически все, о чем идет речь, полностью применимо до сих пор. Вот пример одного из разделов. «2.6.2. В подразделе «Требования к функциям (задачам)», выполняемым системой, приводят: 1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих 66 взаимодействие частей системы), подлежащих автоматизации; 2) при создании системы в две или более очереди перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях; 3) временной регламент реализации каждой функции, задачи (или комплекса задач); 4) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов; 5) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности». Приведенный отрывок демонстрирует иерархичность стандарта: система состоит из подсистем, комплексов задач, отдельных задач, функций. Чем точнее и подробнее сформулированы требования, тем более предсказуемым будет результат. Специально формулируются требования к функциям взаимодействия подсистем (сейчас мы бы сказали "к методам интеграции"), функции привязываются к плану-графику реализации системы (который тем самым также становится иерархическим). Специально упомянуты требования к качеству. Представленный отрывок показывает, что разработка Технического задания в соответствии с ГОСТ 34.602-89 - непростая и очень трудоемкая работа, накладывающая серьезные обязательства не только на разработчика, но и на заказчика системы. Потенциал стандарта чрезвычайно велик, и неудивительно, что популярность его остается неизменно высокой на протяжении стольких лет. 67 С течением времени стали видны и оборотные стороны стандарта: стандарт ориентирован на полностью заказную разработку системы "с нуля" и не рассчитан на внедрение готового решения с помощью типовой методологии или на комбинацию заказных разработок и внедрений; стандарт предлагает одну-единственную модель жизненного цикла системы, называемую каскадной, когда все работы по созданию системы линейно упорядочены и этот порядок заранее определен; стандарт имеет слишком формальный характер. На практике это приводит к появлению Технических заданий, по форме удовлетворяющих требованиям ГОСТ 34.602-89, но по сути малосодержательных. Стоит подчеркнуть, что, как и ГОСТ 34.601-90, ГОСТ 34.602-89 не требует специальной подготовки в области информационных технологий, поэтому контролировать соответствие ему Технического задания может обычный управленец, в задачу которого входит, например, взаимодействие с субподрядчиками. Это упрощает внедрение и практическое применение стандарта. Другое интересное явление, которое продемонстрировала практика, состоит в том, что, как оказалось, далеко не каждый ИТ-специалист способен разработать Техническое задание, удовлетворяющее требованиям стандарта. Фактически появление ГОСТ 34.602-89 стимулировало возникновение новых специалистов - бизнес-аналитиков и консультантов в сфере информационных технологий, основной работой которых стали разработка и согласование Технических заданий с заказчиками автоматизированных систем [22]. 68 3.4.4 Стандарт ГОСТ 34.603-92 Компактный и прозрачный стандарт, устанавливающий последовательность испытаний готовой информационной системы, цели и результаты испытаний. Широко применяется на практике, обладая теми же достоинствами, что и ГОСТ 34.601-90, - лаконичностью, доступностью для неспециалиста в ИТ, самодостаточностью. Понятия и термины стандарта стали общепринятыми в российском ИТ-сообществе. 3.5 Семейство стандартов ISO/IEC 12207 Среди процессных стандартов в области ИТ есть несколько основополагающих разработок ISO [23-24], сыгравших важнейшую роль в становлении процессного подхода к управлению ИТ. Появившиеся в конце 1990-х начале 2000-х годов, эти стандарты демонстрируют совершенно иной подход к управлению ИТ и качественно иной теоретический уровень, чем ГОСТ 34. Это проявляется в первую очередь в ориентированности на процессы, современном взгляде на управление качеством, проектном подходе к деятельности по созданию информационных систем. Первая группа стандартов ISO объединена в семейство стандартов 12207. В состав семейства входят: ISO/IEC 12207:1995 «Information technology– Software life cycle processes» с дополнениями и изменениями ISO/IEC 12207:1995/AMD 1:2002 и ISO/IEC 12207:2002/AMD 2:2004 (принят в новой редакции в 2008 году); ISO/IEC 12207:2008 «Systems and software engineering–Software life cycle processes»; 69 ISO/IEC TR 15271:1998 Information technology – Guide for ISO/IEC 12207 (Software Life Cycle Processes); ISO/IEC TR 16326:1999 Software engineering – Guide for the application of ISO/IEC 12207 to project management. В основе практически всех современных промышленных технологий создания программных средств лежит международный стандарт ISO/IEC 12207 «Системная и программная инженерия. Процессы жизненного цикла программных средств». Далее будут рассмотрены украинские аналоги стандартов ISO. Они представляют собой аутентичные официальные переводы стандартов ISO на украинский язык. В области управления ИТ это прежде всего «ДСТУ 3918-99 (ISO/IEC 12207:1995) Інформаційні технології. Процеси життєвого циклу програмного забезпечення» [25] – один из самых известных и распространенных процессноориентированных стандартов в области управления ИТ. Ссылки на него [18] встречаются практически во всех работах и методиках, относящихся к процессам управления ИТ. 3.5.1 Структура жизненного цикла Область применения стандарта, как следует из названия, относительно узка: процессы, выполняющиеся в ходе жизненного цикла программной системы. Эти процессы представлены во взаимосвязи с другими процессами организации. Модель жизненного цикла стандарт определяет как «структуру, состоящую из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающую жизнь системы от установления требований к ней до прекращения ее использования». 70 Методологическая основа – разбиение процессов на группы, которых в стандарте вводится три. Рисунок 3.2 показывает структуру процессов организации. Рисунок 3.2 – Структура процессов жизненного цикла программных систем по ISO/IEC 12207:1995 Рассмотрим кратко основные характеристики процессов ЖЦ ПС. 1. Основные – это процессы, непосредственно относящиеся к жизненному циклу информационной системы. Можно считать, что это производственные процессы организации. 71 2. Вспомогательные – это процессы, предназначенные для поддержки основных процессов. Сами по себе эти процессы организации не нужны - только в связи с основными процессами, которые они обслуживают. Несколько процессов из этой группы связано с управлением качеством. 3. Организационные – это общекорпоративные процессы, такие как «Обучение» или «Управление». Эти процессы существуют в организации независимо от того, как организовано производство и как устроены вспомогательные процессы. Основные процессы ЖЦ реализуются ответственным субъектом, вовлеченным в ЖЦ ПС. Ответственным субъектом является одно из юридических лиц (или подразделений, или должностных физических лиц), которое реализует соответствующий процесс. Ответственными субъектами могут быть заказчик, поставщик, разработчик, эксплуатационный оператор и сопровождающий персонал. Перечислим основные процессы ЖЦ ПС и дадим их краткие определения. Процесс заказа – это работы заказчика (субъекта, приобретающего систему, ПС или получающего программную услугу). Процесс поставки – это работы поставщика (субъекта, поставляющего систему, ПС или программную услугу заказчику). Процесс разработки – это работы разработчика (субъекта, проектирующего и разрабатывающего ПС). Процесс эксплуатации – это работы эксплуатационного персонала (субъекта, обеспечивающего эксплуатационное обслуживание вычислительной системы в заданных условиях в интересах пользователей). Процесс сопровождения – это работы персонала сопровождения (субъекта, предоставляющего услуги по 72 сопровождению ПС, обеспечивающие контролируемое изменение программного продукта в целях сохранения его исходного состояния и функциональных возможностей). Данный процесс охватывает перенос ПС в другую среду и снятие его с эксплуатации. 3.5.2 Основные процессы Основные процессы включают в себя набор определенных действий и связанных с ними задач, которые должны быть выполнены в течение жизненного цикла ПП. К ним относятся процессы приобретения, поставки, разработки, эксплуатации и сопровождения. Процесс приобретения (acquisition process) охватывает действия заказчика по приобретению ПП. К этим действиям относятся: – инициирование приобретения; – подготовка заявочных предложений; – подготовка и корректировка договора; – надзор за деятельностью поставщика; – приемка и завершение работ. Процесс поставки (supply process) охватывает действия и задачи поставщика при снабжении заказчика ПП или услугой. К этим действиям относятся: – инициирование поставки; – подготовка ответа на заявочные предложения; – подготовка договора; – планирование; – выполнение и контроль; – проверка и оценка; – поставка и завершение работ [18, 25, 26]. Процесс разработки (developmeпt process) охватывает действия и задачи разработчика и предусматривает следующие основные направления работ: 73 – создание ПП и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации; – подготовку материалов, необходимых для проверки работоспособности и качества ПП; – подготовку материалов, необходимых для организации обучения персонала и т.д. Процесс эксплуатации (operation process) охватывает действия и задачи оператора – организации, занимающейся эксплуатацией разработанных ПП или системы. К этим действиям относятся: – подготовительная работа; – эксплуатационное тестирование; – эксплуатация системы; – поддержка пользователей [18, 25, 26]. Процесс сопровождения (raintenance process) охватывает действия и задачи сопровождающей организации (службы сопровождения). Данный процесс активизируется при изменениях (модификациях) ПП и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации либо адаптации ПП. В соответствии со стандартом IEEE-90 (IЕЕЕ – Institute of Electrical and Electronics Engineers – Институт инженеров по электротехнике и электронике) под сопровождением понимается внесение изменений в ПП в целях исправления ошибок, повышения производительности либо адаптации к изменившимся условиям работы или требованиям [18, 25, 26]. 3.5.3. Вспомогательные процессы Основной целью вспомогательных (поддерживающих) процессов является создание надежного, полностью удовлетворяющего требованиям 74 заказчика ПП в установленные договором сроки. К вспомогательным относятся процессы документирования, управления конфигурацией, обеспечения качества, верификации, аттестации, совместной оценки, аудита, разрешения проблем. Процесс документирования (documentaton process) предусматривает формализованное описание информации, созданной в течение жизненного цикла ПП. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких как руководство, технические специалисты и пользователи системы. Процесс документирования включает в себя подготовительную работу, проектирование и разработку документации, выпуск документации, сопровождение [18, 25, 26]. Процесс управления конфигурацией (configuration management process) предполагает применение административных и технических процедур на всем протяжении жизненного цикла ПП. Согласно стандарту IEEE-90 под конфигурацией программного продукта понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПП. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПП на всех стадиях жизненного цикла. Общие принципы и рекомендации по управлению конфигурацией ПП отражены в стандарте ISO/IEC CD 12207-2: 1995 «Information Technology – Software Life Cycle Processes. Раrt 2. Configuration Management for Software» – 75 Информационные технологии – Процессы жизненного цикла программ. Часть 2. Управление конфигурацией программ». Процесс управления конфигурацией включает в себя подготовительную работу, идентификацию конфигурации, контроль конфигурации, учет состояния конфигурации, оценку конфигурации; управление выпуском и поставку [18, 25, 26]. Процесс обеспечения качества (quality assurance process) обеспечивает соответствующие гарантии того, что ПП и процессы его жизненного цикла соответствуют заданным требованиям и утвержденным планам. Под качеством ПП понимается совокупность свойств, которые характеризуют способность ПП удовлетворять заданным требованиям. Для получения достоверных оценок создаваемого ПП процесс обеспечения его качества должен происходить независимо от субъектов, непосредственно связанных с разработкой ПП. При этом могут использоваться результаты других вспомогательных процессов, таких как верификация, аттестация, совместная оценка, аудит и разрешение проблем. Процесс обеспечения качества включает в себя подготовительную работу; обеспечение качества продукта; обеспечение качества процесса; обеспечение прочих показателей качества системы [18, 25, 26]. Обеспечение прочих показателей качества системы осуществляется в соответствии с условиями договора и стандартом качества 180-9001. Процесс верификации (verification process) состоит в доказательстве того, что ПП, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, зависящим от предшествующих действий. 76 Верификация может проводиться самим исполнителем или другим специалистом данной организации, а также специалистом сторонней организации. Тут возможны различные вариации, в соответствии с которыми можно говорить о различной степени независимости верификации. Если процесс верификации осуществляется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой верификации. Процесс верификации включает в себя подготовительную работу и собственно верификацию. Верификация в узком смысле означает формальное доказательство правильности ПП. Данный процесс может включать в себя анализ, оценку и тестирование. В процессе верификации проверяются непротиворечивость требований к системе и степень учета потребностей пользователей; возможности поставщика выполнить заданные требования; соответствие выбранных процессов жизненного цикла ПП условиям договора; адекватность стандартов, процедур и среды разработки процессам жизненного цикла ПП; соответствие проектных спецификаций ПП заданным требованиям; корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т. д.; соответствие кода проектным спецификациям и требованиям; тестируемость и корректность кода, его соответствие принятым стандартам кодирования; корректность интеграции компонентов ПП в систему; адекватность, полнота и непротиворечивость документации. Процесс аттестации (validation process) предусматривает определение полноты соответствия заданных требований к создаваемой системе или ПП 77 функциональному назначению последних. Под аттестацией обычно понимают подтверждение и оценку достоверности проведенного тестирования ПП. Аттестация должна гарантировать полное соответствие ПП спецификациям, требованиям и документации, а также возможность его безопасного и надежного применения пользователем. Аттестацию рекомендуется выполнять путем тестирования во всех возможных ситуациях и использовать при этом независимых специалистов. Аттестация так же, как и верификация, может осуществляться с различными степенями независимости. Процесс аттестации включает в себя подготовительную работу и собственно аттестацию. Аттестация позволяет определить полноту соответствия разработанных требований к создаваемому ПП или системе функциональному назначению последних. Процесс совместной оценки (joint review process) предназначен для оценки состояния работ по проекту и ПП, создаваемому при выполнении данных работ. Он заключается в основном в контроле за планированием и управлением ресурсами, персоналом, аппаратурой и инструментальными средствами проекта. Оценка выполняется как на уровне управления проектом, так и на уровне его технической реализации и проводится в течение всего срока действия договора. Данный процесс может выполняться двумя любыми сторонами, участвующими в договоре, при этом одна сторона проверяет другую. Процесс совместной оценки включает в себя подготовительную работу; оценку управления проектом; техническую оценку. Процесс аудита (audit process) представляет собой определение соответствия требованиям, планам и условиям договора как хода выполнения работ по 78 созданию ПП, так и самого ПП. Аудит может выполняться двумя любыми сторонами, участвующими в договоре, когда одна сторона проверяет другую. Аудит служит для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Аудиторы (ревизоры) не должны иметь прямой зависимости от разработчиков ПП. Они оценивают состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность проводимого тестирования. Процесс аудита включает в себя подготовительную работу и собственно аудит [18, 25, 26]. Процесс разрешения проблем (problem resolution process) предусматривает анализ и решение проблем (включая выявленные несоответствия), обнаруженных в ходе разработки, эксплуатации, сопровождения и других процессов, независимо от их происхождения или источника. Каждая обнаруженная проблема должна быть идентифицирована, описана, проанализирована и разрешена. Процесс разрешения проблем включает в себя подготовительную работу и собственно разрешение проблем. 3.5.4 Организационные процессы Основной целью организационных процессов является организация процесса разработки надежного, полностью удовлетворяющего требованиям заказчика ПП, к установленным договором относятся процессы управления, создания инфраструктуры, усовершенствования, обучения [18, 25, 26]. Процесс управления (management process) состоит из действий и задач, которые могут выполняться любой 79 стороной, управляющей своими процессами. Данная сторона (менеджер) отвечает за управление выпуском продукта, проектом и задачами соответствующих процессов, таких как приобретение, поставка, разработка, эксплуатация, сопровождение и др. Процесс управления включает в себя инициирование и определение области управления; планирование; управление работами по созданию ПП и контроль за их выполнением; проверку и оценку; завершение работ. Процесс создания инфраструктуры (infrastructure process) охватывает выбор и поддержку (сопровождение) технологии, стандартов и инструментальных средств, выбор и установку аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПП. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к соответствующим процессам. Она является одним из объектов управления конфигурацией. Процесс усовершенствования (improvement process) предусматривает оценку, измерение, контроль и усовершенствование процессов жизненного цикла ПП. Данный процесс включает в себя создание процесса; оценку процесса; усовершенствование процессов жизненного цикла ПП. Процесс обучения (training process) охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала. Приобретение, поставка, разработка, эксплуатация и сопровождение программного продукта в значительной степени зависят от уровня знаний и квалификации персонала. Например, разработчики ПП должны пройти необходимое обучение методам и средствам программной инженерии. Содержание процесса обучения определяется 80 требованиями к проекту. Для этого процесса должны быть запланированы необходимые ресурсы и технические средства обучения, кроме того должны быть разработаны и представлены методические материалы, необходимые для обучения пользователей в соответствии с учебным планом. 3.5.5 Взаимосвязь между процессами жизненного цикла программного продукта Процессы жизненного цикла ПП, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами в различных аспектах (договорном, управления, эксплуатации, инженерном, поддержки), которые показаны на рисунке 3.3. Рисунок 3.3 – Связь между процессами жизненного цикла программного продукта 81 Штриховые стрелки показывают связь действующих лиц процессов (заказчик, поставщик и т.д.) с конкретными процессами, а сплошные стрелки – связь процессов или групп процессов между собой. В договорном аспекте заказчик и поставщик вступают в договорные отношения и реализуют соответственно процессы приобретения и поставки. В аспекте управления заказчик, поставщик, разработчик, оператор, служба сопровождения и другие стороны, участвующие в жизненном цикле ПП, управляют выполнением своих процессов. Менеджер является связующим звеном между организационными и основными процессами. В аспекте эксплуатации оператор, эксплуатирующий систему, предоставляет необходимые услуги пользователям. В инженерном аспекте разработчик или служба сопровождения решают соответствующие технические задачи, разрабатывая или модифицируя ПП [18, 25, 26]. В аспекте поддержки службы, реализующие вспомогательные процессы, предоставляют необходимые услуги всем остальным участникам работ. В рамках аспекта поддержки можно выделить аспект управления качеством ПП. Организационные процессы выполняются на корпоративном уровне, т. е. на уровне всей организации в целом, создавая базу для реализации и постоянного совершенствования остальных процессов жизненного цикла ПП. Процессы и реализующие их организации (или стороны) связаны между собой чисто функционально. При этом внутренняя структура и статус организаций никак не регламентируются. Одна и та же организация может выполнять различные роли (поставщика, разработчика и 82 др.) и наоборот – одна и та же роль может выполняться несколькими организациями. Взаимосвязи между процессами, описанные в стандарте, носят статический характер. 3.6 ISO/IEC 15288:2002 Стандарт ISO/IEC 15288:2002 «Системная инженерия. Процессы жизненного цикла систем» является практически первым международным стандартом, в котором всесторонне с точки зрения организации процессов жизненного цикла (ЖЦ) рассматриваются методологические принципы проектирования систем. Стандарт разработан 7-ым подкомитетом «Системная и программная инженерия» объединенного технического комитета по информационным технологиям (JTC1) ИСО/МЭК [27]. Документ создан на основе опыта проектирования сложных систем, сложившегося в оборонно-промышленных комплексах и крупных коммерческих корпорациях ведущих промышленных держав и в 2003-2004 гг. введен в действие в США, Австралии, Великобритании, Канаде, Швеции и ряде других стран. Идентичный национальный стандарт принят в 2005 [28]. Стандарт задает единую структуру для установления и развития связей и кооперации между сторонами, создающими и использующими современные системы и управляющими ими в целях совместной согласованной работы. Документ обеспечивает основы для моделирования и реализации общих процессов, составляющих ЖЦ систем, предоставляя возможность для их оценки и совершенствования, и, охватывая все концепции и идеи, имеющие отношение к этим системам, начиная от замысла и вплоть до момента снятия с 83 эксплуатации. Процессы ЖЦ, задаваемые стандартом, могут использоваться однократно, многократно или рекурсивно, как по отношению к системе в целом, так и к любым ее элементам, применяться для систем единичного и массового производства, а также адаптируемых к требованиям заказчика [29]. Стандарт может практически использоваться одним или несколькими из следующих способов: организацией – для формирования среды необходимых процессов и оценки соответствия между заявленной и утвержденной моделью ЖЦ и ее конкретной реализацией; проектировщиками – для помощи в выборе, систематизации и использовании элементов среды, пригодной для производства продукции и предоставления услуг, и оценки проекта на соответствие заявленной и сформированной среде; заказчиком и поставщиком – для разработки соглашений, касающихся процессов и деятельности, которые отбираются, согласовываются и выполняются в контексте данного стандарта. В стандарте, по существу, сформирован новый взгляд на системы и их проектирование, который отличается тем, что: понятие системы обобщено практически на любой объект, созданный человеком, при этом системы рассматриваются как результат воплощения человеческого замысла, связанного с необходимостью получения продукции и/или услуг, причем, люди одновременно или попеременно, могут выступать как в качестве пользователя, так и в качестве элемента системы; для противодействия растущей сложности систем предлагается использовать единый комплексный подход к 84 их созданию и формированию процессов ЖЦ любого масштаба, сложности и уровня; область действий и процессов, относящихся к ЖЦ систем, существенно расширена, в нее включены как бизнес-процессы, так технические процессы, рассматриваемые в неразрывной связи друг с другом; состав и вид конкретных, используемых в проектах моделей ЖЦ, способы ведения проектной документации, состав работ, содержание и наличие специальных процессов приспособления стандартов к особенностям конкретных систем оставлены на усмотрение предприятия; система рассматривается как объект, который может меняться в ходе реализации процессов ЖЦ [29]. 3.6.1 Группы процессов в стандарте Стандартом устанавливается (рис. 3.4) четыре группы процессов ЖЦ систем, а именно: процессы соглашения, процессы предприятия, процессы проекта, технические процессы. К процессам соглашения относятся процесс приобретения, используемый организациями для приобретения продукции или получения услуг, и процесс поставки, используемый для поставок продукции или оказания услуг. Процессы предприятия включают процесс управления средой предприятия, процесс управления инвестициями, процесс управления процессами жизненного цикла системы, процесс управления ресурсами, процесс управления качеством. 85 К процессам проекта относятся процесс планирования проекта, процесс оценки проекта, процесс контроля проекта, процесс принятия решений, процесс управления рисками, процесс управления конфигурацией, процесс управления информацией [22, 27, 28]. Рисунок 3.4 – Процессы жизненного цикла систем по ISO/IEC 15288:2002 86 И, наконец, технические процессы включают процесс определения требований правообладателей, процесс анализа требований, процесс проектирования архитектуры, процесс реализации элементов системы, процесс комплексирования, процесс верификации, процесс передачи, процесс валидации, процесс функционирования, процесс технического обслуживания, процесс изъятия и списания. Стандарт предназначен для организаций, приобретающих, разрабатывающих или внедряющих системы. Созданные системы могут использоваться для внутренних целей или поставляться заказчикам. В качестве заказчиков и поставщиков могут выступать и подразделения самой организации [22, 27, 28, 29]. 3.6.2 Структура жизненного цикла Предлагаются следующие стадии жизненного цикла систем: стадия замысла; стадия разработки; стадия производства; стадия применения; стадия поддержки применения; стадия прекращения применения и списания. В отношении каждого из процессов в документе рассматриваются цели, результаты реализации и виды деятельности, обеспечивающие достижение указанных результатов. Всего в стандарте специфицировано 25 процессов, 123 результата реализации и 208 видов деятельности. Стадии «образуют структуру работ для детализированного моделирования жизненных циклов системы». Это означает, что стадии являются теми 87 кирпичиками, из которых в ходе процесса адаптации строится жизненный цикл конкретной системы. Стадии могут перекрываться или повторяться; каждая стадия содержит процессы, отобранные и настроенные (также во время адаптации) так, чтобы реализовать цели этой стадии. Для каждой стадии определяются цель и результаты. 3.6.3 Сравнение с ISO/IEC 12207 Принцип разделения процессов на группы абсолютной иной, нежели в ISO/IEC 12207. На первый план выдвигаются бизнес-цели, на достижение которых работают процессы. Иерархия ответственностей, предлагаемая стандартом, конечно, не единственно возможная, но сама идея привязки процессов к ответственностям представляется очень плодотворной. Это помогает привязать процессы к структуре организации, определить в ней владельцев процессов. Таким образом, становится более структурированной задача внедрения стандарта, возникают связи между бизнес-целями организации и результатами деятельности владельцев процессов. По сравнению с ранее рассмотренными стандартами, ISO/IEC 15288:2002 открывает ряд новых возможностей. Прежде всего, он позволяет связать задачу анализа процессов с бизнесом организации, переводя ее из разряда технических или технологических в разряд бизнес-задач. Например, посредством процессов соглашения и управления инвестициями реализуется связь процессов жизненного цикла с задачами управления корпоративными финансами, финансового планирования и бюджетирования, процесс управления ресурсами взаимодействует с управлением персоналом и т. д. Роль стандарта, с этой точки зрения, прежде всего в том, что он 88 определяет место процессов управления жизненным циклом систем среди остальных процессов организации [22]. При разработке международного стандарта ISO/IEC 15288 использовались стандарты управления качеством серии ISO 9000 [30-31], стандарты группы ISO/IEC 15504 (SPICE), относящиеся к оценке зрелости процессов проектирования, а также стандарт на процессы ЖЦ программных средств ISO/IEC 12207. Важно отметить, что все упомянутые стандарты нацелены на решение вопроса о том, ЧТО нужно делать в процессе создания и эксплуатации систем, оставляя открытым вопрос о том, КАК это нужно делать. С целью перехода от общего описания процессов ЖЦ к более детальному – следует использовать стандарт ISO/IEC 15288 совместно с другими стандартами, содержащими более подробное описание отдельных процессов и работ, относящихся к ЖЦ систем, а также использовать подходящие руководства по применению. Среди этих документов следует упомянуть ISO/IEC TR 19760 – руководство по применению стандарта ISO/IEC 15288, ГОСТ ISO/IEC 15271-2002 – руководство по применению стандарта ГОСТ ISO/IEC 12207-2002, ISO/IEC 15939 – на процессы определения характеристик программных продуктов, ISO/IEC 15940 – на сервисы среды, относящиеся к программной инженерии, ISO/IEC TR 15846 – на управление конфигурацией, ISO/IEC 18019 – на процессы документирования, ГОСТ ISO/IEC 147642002 – на сопровождение программного обеспечения, стандарты в области информационных технологий серии ГОСТ 34, а также стандарт IEEE 1220 и стандарт электронного промышленного альянса США EIA 632 на процессы проектирования систем. 89 3.7 SWEBOK Наиболее полным на сегодняшний день методическим руководством по программной инженерии следует признать появившийся в 2004 г. документ SWEBOK, полное английское название которого - Guide to the Software Engineering Body of Knowledge (SWEBOK), что можно перевести как "Руководство к методическому справочнику по программной инженерии" (IEEE Computer Society, 2004) [32-33]. Книга представляет собой систематизированное и структурированное изложение основных понятий, связанных с разработкой ПО, объединяющее определения, концепции, методы из множества источников, среди которых стандарты занимают одно из центральных мест. Сам по себе SWEBOK не является ни стандартом, ни методикой, ни моделью. Это просто развернутый справочник, который состоит из десяти разделов, соответствующих десяти основным видам деятельности при разработке ПО. В каждом из разделов даются ссылки на стандарты, полностью или частично описывающие соответствующие процессы. Одно из приложений к руководству (Приложение С) целиком посвящено стандартам. Содержание Приложения С – таблица, показывающая степень покрытия стандартами (их приведено свыше пятидесяти) десяти разделов SWEBOK. Руководство дает достаточно полное представление о том, какое место занимают процессные модели в программной инженерии и как они развиваются. Очевидный вывод, который следует из анализа SWEBOK, состоит в том, что модели процессов, представленные разными стандартами, хотя и являются отчасти взаимодополняющими, не складываются в единую 90 непротиворечивую модель. Как следствие, выбор подходящей процессной модели для внедрения на практике оказывается неизбежно субъективным, и для обоснования его приходится привлекать дополнительные соображения [22, 34]. SWEBOK может служить хорошей отправной точкой для углубленного анализа ситуации и принятия решения о выборе процессной модели. Руководство доступно для просмотра на http://www.computer.org/portal/web/swebok. Контрольные вопросы 1. Что такое стандарт? 2. На какие категории распределяются нормативные документы в зависимости от объекта стандартизации и сферы деятельности? 3. Перечислить основные международные организации по стандартизации. 4. На какие группы делятся стандарты в сфере информационных технологий? 5. Что такое ГОСТ 34? Какие стандарты входят в ГОСТ 34? 6. Какую деятельность регламентирует ГОСТ 34? 7. В чем основные достоинства ГОСТ 34? 8. Каковы недостатки ГОСТ 34? 9. Для чего имеет смысл применять ГОСТ 34 сейчас? 10. Какова область применения стандарта ISO/IEC 12207? 11. Чем отличается стандарт ISO/IEC 12207 от ГОСТ 34 (одно предложение)? 12. Какова структура ISO/IEC 12207? 13. Какие конкретные критерии и методы оценки поставщика в процессе заказа предлагает ISO/IEC 12207? 91 14. В чем разница между процессами аттестации, верификации, аудита и обеспечения качества? 15. Что такое адаптация в терминологии ISO/IEC 12207? 16. Какова структура процессов жизненного цикла ISO/IEC 12207? 17. Какие вспомогательные процессы описывает ISO/IEC 12207? 18. В чем состоит назначение стандарта ISO/IEC 15288? 19. Какова структура стандарта, чем она принципиально отличается от структуры ISO/IEC 12207? 20. Какие группы процессов входят в ISO/IEC 15288? 21. Каково назначение процесса управления процессами жизненного цикла? Что послужило прообразом этого процесса в ISO/IEC 12207? 22. Какие стадии жизненного цикла определяет ISO/IEC 15288? 23. Что представляет собой SWEBOK? 24. Какова цель создания SWEBOK? 92 ЧАСТЬ 2. МЕТОДЫ И СРЕДСТВА РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ РАЗДЕЛ 4. МЕТОДОЛОГИИ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ 4.1 Группы методологий Процесс разработки программного обеспечения (англ. software development process, software process) — структура, согласно которой построена разработка программного обеспечения (ПО). Существуют различные методологии (RUP, MSF, XP, Scrum, FDD, OpenUP и другие) такого процесса, каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса [6, 11, 13, 26, 34-39]. На сегодняшний день существуют различные подходы к группировке методологий. В учебнике [6] предложена классификация методологий на два семейства процессов разработки: семейство прогнозирующих (тяжеловесных) процессов; семейство адаптивных (подвижных, облегченных) процессов. У каждого семейства есть свои достоинства, недостатки и область применения: адаптивный процесс используют при частых изменениях требований, малочисленной группе высококвалифицированных разработчиков и грамотном заказчике, который согласен участвовать в разработке; 93 прогнозирующий процесс применяют при фиксированных требованиях и многочисленной группе разработчиков разной квалификации. С другой стороны возможно разбиение методологий на следующие основные виды разработки ПО: каскадная разработка или реализация модели водопада (англ. waterfall model) – модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. итеративная разработка (англ. iteration – повторение) – выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование – Реализация – Проверка – Оценка (англ. plan-do-check-act cycle).В ходе разработки всегда выявляются дополнительные требования или изменяются выявленные ранее. Также появляются новые ограничения, связанные с принятыми техническими решениями. В наиболее полной мере их удается учесть именно в итерационной разработке, поскольку именно при таком подходе руководство проекта в полной мере готово к изменениям. В рамках последней отдельно выделяют гибкую методологию разработки (Agile software development, agile-методы), которая сформировалась в 2001 году на основе «Манифест гибкой методологии разработки программного обеспечения», представляет собой серию подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного 94 взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля [17]. К гибким методологиям относятся: Extreme programming, Scrum, DSDM, Adaptive Software Development, Crystal Clear, Feature-Driven Development, Pragmatic Programming [36- 39]. 4.2 Методология Rational Unified Process Рациональный унифицированный процесс Rational Unified Process (RUP) – методология разработки программного обеспечения, созданная компанией Rational Software. 4.2.1 Принципы RUP В основе RUP лежат следующие принципы [13, 17, 40- 43]: ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков; концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)); ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки; компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта; постоянное обеспечение качества на всех этапах разработки проекта (продукта); работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам. 95 4.2.2 Этапы RUP Модель жизненного цикла RUP является детально проработанной итеративно-инкрементной моделью с элементами каскадной модели. Полный жизненный цикл разработки продукта состоит из 4 основных фаз, каждая из которых включает в себя одну или несколько итераций, также выделяют 9 видов деятельности (процессов). [5]. Основными фазами RUP являются: Фаза начала проекта (Inception). Определяются основные цели проекта, бюджет проекта, основные средства его выполнения – технологии, инструменты, ключевой персонал, составляются предварительные планы проекта. Цель: достичь компромисса между всеми заинтересованными лицами относительно задач проекта. Фаза проработки (Elaboration). Цель: на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы. Фаза построения (Construction). Цель: детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры. Фаза передачи (Transition). Цель: сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей. В рамках каждой фазы возможно проведение нескольких итераций, количество которых определяется сложностью выполняемого проекта. Графическое представление процесса разработки по RUP представлено на рисунке 4.1. 96 Рисунок 4.1 – Графическое представление процесса разработки по RUP 97 Деятельности (основные процессы) RUP делятся на пять рабочих и четыре поддерживающие. К рабочим деятельностям относятся [5, 38]: Моделирование предметной области (бизнесмоделирование, Business Modeling). Цели этой деятельности – понять бизнес-контекст, в котором должна будет работать система (и убедиться, что все заинтересованные лица понимают его одинаково), понять возможные проблемы, оценить возможные их решения и их последствия для бизнеса организации, в которой будет работать система. Определение требований (Requirements). Цели – понять, что должна делать система, определить границы системы и основу для планирования проекта и оценок ресурсозатрат в нем. Анализ и проектирование (Analysis and Design). Выработка архитектуры системы на основе ключевых требований, создание проектной модели, представленной в виде диаграмм UML, описывающих продукт с различных точек зрения. Реализация (Implementation). Разработка исходного кода, компонент системы, тестирование и интегрирование компонент. Тестирование (Test). Общая оценка дефектов продукта, его качество в целом; оценка степени соответствия исходным требованиям. Поддерживающими деятельностями являются: Развертывание (Deployment). Цели – развернуть систему в ее рабочем окружении и оценить ее работоспособность. Управление конфигурациями и изменениями (Configuration and Change Management). Определение элементов, подлежащих хранению и правил построения из них согласованных конфигураций, поддержание 98 целостности текущего состояния системы, проверка согласованности вносимых изменений. Управление проектом (Project Management). Включает планирование, управление персоналом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта. Управление средой проекта (Environment). Настройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте. Методология RUP ориентирована на поэтапное моделирование создаваемого продукта с помощью языка UML. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. RUP должен позволять устанавливать степень формализации и итеративности процесса разработки в зависимости от особенностей реализуемого проекта. Данная методология позиционируется как универсальная, подходящая для большинства типов проектов – как каскадных, так и гибких. Но, как и все универсальное, RUP не обеспечивает высокой производительности и удобства внедрения. В то же время RUP учитывает опыт большого числа разработчиков и содержит наиболее полный набор концепций, которые так или иначе присутствуют в других методиках [44]. 99 4.3 Методология Microsoft Solutions Framework Microsoft Solutions Framework (MSF) – методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения [13, 17, 44-48]. 4.3.1 Принципы MSF Основными являются следующие принципы MSF. Распределение ответственности и полномочий членов команды. Все члены команды отвечают за успех проекта. В рамках проектной группы каждый ролевой кластер отчитывается перед всей командой о достижении своей цели. Единое видение проекта, которое предполагает понимание всеми заинтересованными лицами целей и задач создания ПО. Гибкость – готовность к переменам, что обеспечивает возможность уточнения и изменения требований в процессе разработки ПО, оперативного и быстрого реагирования на текущие изменения условий проекта при неизменной эффективности управленческой деятельности. Концентрация на бизнес-приоритетах, что предполагает создание продукта с высоким потребительским качеством и формирование определенной выгоды или отдачи. Для организаций, как правило, это получение прибыли. Поощрение свободного общения, что предполагает открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. 100 Универсальность модели MSF определяется тем, что благодаря своей гибкости и отсутствию жестко установленных связей и процедур она может быть применена при разработке различных программных приложений, которые могут использоваться в бизнесе и повседневной жизни. MSF состоит из двух моделей и трех дисциплин. модели: проектной группы MSF. Одной из основ MSF является постулат о шести качественных целях, достижение которых определяет успешность проекта. Исходя из этих целей построена модель проектной группы. Она включает в себя шесть ролевых кластеров, каждый из которых имеет свою область компетенции, а также связанные с нею цели и задачи. процессов MSF. Представляет собой общую методологию разработки и внедрения IT-решения, охватывающую весь жизненный цикл создания решения. Эта модель сочетает в себе особенности двух классических моделей процессов: спиральной и каскадной. дисциплины: управления проектами. Данная дисциплина описывает основные принципы, концепции и характеристики управления проектом в рамках MSF. Она отвечает вопрос: Что такое управление проектом? управления рисками. MSF рассматривает изменения и связанные с ними затруднения как неотъемлемую часть жизненного цикла информационных технологий. MSF отстаивает превентивный подход к работе с рисками. Должна осуществляться непрерывная оценка рисков на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. 101 Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. управления подготовкой. Данная дисциплина посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина управления подготовкой MSF описывает фундаментальные принципы MSF и дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Эта дисциплина также рассматривает планирование процесса управления подготовкой. Будучи подкрепленной испытанными практическими методиками, дисциплина управления подготовкой предоставляет проектным группам и отдельным специалистам базу для осуществления этого процесса [46]. 4.3.2 Модель проектной группы MSF Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь [17]. Главная особенность модели команды в MSF является то, что она не имеет официального лидера. Все отвечают за проект в равной степени, уровень 102 заинтересованности каждого в результате очень высок, а коммуникации внутри группы четкие, ясные, дружественные и ответственные [45]. Состав команды определяется теми целями, которые необходимо достичь для успеха проекта: за достижение конкретной цели отвечает соответствующий ролевой кластер, а за успешность проекта в целом несет ответственность вся команда. Ролевые кластеры показаны на рисунке 4.2. В соответствии с целями проекта MSF выделяет семь ролевых кластеров, каждый из которых должен обладать специфическими компетенциями для исполнения собственных функций (см. таблицу 4.1) [46]. Масштабирование команды MSF. В зависимости от размера и сложности проекта модель команд MSF допускает масштабирование. Для небольших и несложных проектов один сотрудник может объединять несколько ролей. При этом некоторые роли нельзя объединять. В таблице 4.2 представлены рекомендации MSF относительно совмещения ролей в рамках одним членом команды. "+" означает, что совмещение возможно, "+-" что совмещение возможно, но нежелательно, "-" означает, что совмещение не рекомендуется. В частности, нельзя совмещать разработку и тестирование, поскольку необходимо, чтобы у тестировщиков был сформирован свой, независимый взгляд на систему, базирующийся на изучении требований. Для больших команд (более 10 человек) модель проектной группы MSF предлагает разбиение на малые многопрофильные группы направлений. Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия, каждая из которых устроена на основе модели кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к 103 ней вопросы, начиная от проектирования и составления календарного графика. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются так называемые функциональные группы, которые затем объединяются в ролевые кластеры. Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции. Часто функциональные группы имеют внутреннюю иерархическую структуру. Например, менеджеры программы могут быть подотчетны ведущим менеджерам программы, которые в свою очередь отчитываются перед главным менеджером программы. Подобные структуры могут также появляться внутри областей компетенций. Управление компромиссами. Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (функциональность). Эти три переменные образуют треугольник. После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне [45]. 104 управление проектом контроль произв. процесса административные службы бизнес-приоритеты маркетинг представление заказчика планирование продукта концепция, проектирование, выработка архитектурных решений обучение, эргономика, графический дизайн, интернационализация, обеспечение техподдержки, общедоступность реализация приложений разработка инфраструктуры инфраструктура, сопровождение, бизнес-процессы, управление выпуском готового продукта планирование тестов, разработка тестов, отчетность Рисунок 4.2 – Модель проектной группы 105 Таблица 4.1 – Функции и области компетенции ролевых кластеров Ролевой кластер Цель 1. Управление продуктом Цель: удовлетворенные заказчики Область компетенции маркетинг; бизнесприоритеты; представление интересов заказчика; планирование продукта; 2. Управление программой Цель: достижение результата в рамках проектных ограничений управление проектом; контроль производственного процесса; административные службы; Функции выступает в роли представителя заказчика; формирует общее видение/рамки проекта; организует работу с требованиями заказчика; развивает сферы применения в бизнесе; формирует ожидания заказчика; определяет компромиссы между параметрами «возможности продукта / время / ресурсы»; организует маркетинг, PR; разрабатывает, поддерживает и исполняет план коммуникаций; управляет процессом разработки с целью получения готового продукта в отведенные сроки; регулирует взаимоотношения и коммуникацию внутри проектной группы; следит за временным графиком проекта и готовит отчетность о его состоянии; проводит в жизнь важные компромиссные решения, организует управление рисками; разрабатывает, поддерживает и исполняет сводный план и календарный график проекта; 106 Продолжение таблицы 4.1 – Функции и области компетенции ролевых кластеров Ролевой кластер Цель 3. Разработка Цель: создание продукта в соответствии со спецификацией Область компетенции технологическое консультирование; проектирование и осуществление реализации; разработка приложений; разработка инфраструктуры; 4. Тестирование планирование Цель: одобрение выпуска тестов; продукта только лишь разработка тестов; после того, как все отчетность по дефекты выявлены и тестам; улажены 5. Удовлетворение обеспечение потребителя технической Цель: повышение поддержки; эффективности обучение; пользователя, увеличение эргономика; Функции определяет детали физического дизайна; оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна; разрабатывает или контролирует разработку элементов; подготавливает продукт к внедрению; консультирует команду по технологическим вопросам; обеспечивает обнаружение всех дефектов разрабатывает стратегию и планы тестирования осуществляет тестирование представляет интересы потребителя в команде; организует работу с требованиями пользователя; проектирует и разрабатывает системы 107 Продолжение таблицы 4.1 – Функции и области компетенции ролевых кластеров Ролевой кластер Цель потребительской ценности продукта Область компетенции Функции графический дизайн; интернационализация; общедоступность; поддержки производительности; определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта; определяет требования к системе помощи и её содержание; разрабатывает учебные материалы и осуществляет обучение пользователей; представляет интересы отделов поставки и обслуживания продукта; организует снабжение проектной группы; организует внедрение продукта; вырабатывает компромиссы в управляемости и удобстве сопровождения продукта; организует сопровождение и инфраструктуру поставки; организует логистическое обеспечение; формулирует спецификацию продукта и разрабатывает его архитектуру; 6. Управление выпуском Цель: беспроблемное внедрение и сопровождение продукта инфраструктура; сопровождение; бизнес- процессы; управление выпуском готового продукта; 7. Архитектура выработка архитектуры решения; 108 Управление продуктом Управление программой Разработка Тестирование Удовлетворение потребителя Управление выпуском Архитектура – – Архитектура Управление выпуском Удовлетворение потребителя Тестирование Разработка Управление программой Управление продуктом Таблица 4.2 – Рекомендации MSF относительно совмещения ролей в команде проекта – + + +– – – +– +– + + – – + – + +– + +– +– – + + – +– +– – – + +– + – + +– – + + +– +– 109 + + 4.3.3 Модель процессов MSF Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Модель процессов MSF базируется на сочетании двух моделей жизненного цикла программных систем: каскадной и спиральной, как показано на рисунке 4.3 [45]. Рисунок 4.3 – Модель жизненного цикла решения MSF В рамках MSF программный код, документация, дизайн, планы и другие рабочие материалы создаются, как правило, итеративными методами. MSF рекомендует начинать разработку решения с построения, тестирования 110 и внедрения его базовой функциональности. Затем к решению добавляются все новые и новые возможности. Такая стратегия именуется стратегией версионирования. Несмотря на то, что для малых проектов может быть достаточным выпуск одной версии, рекомендуется не упускать возможности создания для одного решения ряда версий. С созданием новых версий эволюционирует функциональность решения. Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. «Живые» документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки. Решение не представляет бизнес-ценности, пока оно не внедрено. Именно по этой причине модель процессов MSF содержит весь жизненный цикл создания решения, включая его внедрение – вплоть до момента, когда решение начинает давать отдачу. 4.4 Методология Extreme Programming Экстремальное программирование (eXtreme Programming, XP) – одна из гибких методологий разработки программного обеспечения, главный автор которого – Кент Бек (1999) [6, 13, 17, 39, 44, 49]. Методология ХР ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР-группу образуют до 10 сотрудников, которые размещаются в одном помещении. 111 Основная идея ХР – устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов и реляционных баз данных. ХР-группа имеет дело с изменениями требований на всем протяжении итерационного цикла разработки, причем цикл состоит из очень коротких итераций. Четырьмя базовыми действиями в ХР-цикле являются [6]: 1) планирование, 2) проектирование, 3) кодирование, 4) тестирование, Динамизм обеспечивается с помощью пяти характеристик: непрерывная связь с заказчиком; простота (всегда выбирается минимальное решение); быстрая обратная связь (с помощью модульного и функционального тестирования); смелости в проведении профилактики возможных проблем; уважение членов команды к друг другу и своей работе. Большинство принципов, поддерживаемых в ХР (минимальность, простота, эволюционный цикл разработки, малая длительность итерации, участие пользователя, оптимальные стандарты кодирования и т. д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе. Просто в ХР эти принципы достигают «экстремальных значений». Базис первой версии ХР (1999 г.) формировали двенадцать методик, во второй версии (2004 г.) их количество возросло до двадцати четных. Наиболее 112 характерные их ХР-методик, которые могут быть объединены в четыре группы [6, 17, 44, 49]: Короткий цикл обратной связи (Fine scale feedback): разработка через тестирование (Test driven development) – сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. игра в планирование (Planning game) – быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс) заказчик всегда рядом (Whole team, Onsite customer) – в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков. парное программирование (Pair programming) – техника программирования, при которой исходный код создаётся парами людей, программирующих одну задачу, сидя за одним рабочим местом. Непрерывный, а не пакетный процесс: непрерывная интеграция (Continuous Integration) – система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности. рефакторинг (Design Improvement, Refactor) – это методика улучшения кода без изменения его 113 функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. частая смена версий (Small Releases) – быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле. Понимание, разделяемое всеми: простота (Simple design) – проектирование выполняется настолько просто, насколько это возможно в данный момент. метафора системы (System metaphor) – это аналог того, что в большинстве методик называется архитектурой. Метафора системы даёт команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять. коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership) –возможность любому разработчику улучшать любой код системы в любое время. стандарт кодирования (Coding standard or Coding conventions) – должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы. Социальная защищенность программиста (Programmer welfare): 40-часовая рабочая неделя (Sustainable pace, Forty hour week) Методология XP, несомненно, очень популярно и позволяет разрабатывать проекты достаточно успешно, но только в идеальном варианте. В реальности все гораздо сложнее: заказчик, как правило, бывает доступен весьма ограниченное время, и он не может посвящать работе в 114 проекте столько же времени, сколько программист или менеджер. Это значит, что получение отклика и уточнение требований будут проходить со значительной задержкой. Рефакторинг – это не панацея. Изменение существующего кода может потребовать значительно больше времени, чем разработка нового. Программист может тратить много времени на улучшение того, что уже есть, а не на создание нового функционала. Совместное владение кодом – еще один спорный момент. За каждый класс должен отвечать только один разработчик: при совместном владении возможны неожиданные правки, и класс станет работать не так, как было запланировано создателем класса. Совместное владение кодом, и парное программирование подразумевают затраты на изучение кода другого разработчика, но о них обычно нигде не упоминается: считается, что для этого достаточно всем программистам находиться в одной комнате и время от времени обмениваться репликами. Эта позиция не имеет какихлибо строгих обоснований, и совершенно нет уверенности, что такого обмена информацией будет достаточно. Даже если в организации приняты стандарты кодирования и они строго выполняются, изучение чужого кода может занимать большое количество времени [44]. 4.5 Методология Scrum Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки 115 программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums [17]. 4.5.1 Принципы Scrum Скрам (Scrum) – это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость [17, 50-52]. Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения. Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки программного продукта [44]. Основа Scrum – итеративная разработка. Scrum определяет: правила, по которым должен планироваться и управляться список требований к продукту для достижения максимальной прибыльности от реализованной функциональности; правила планирования итераций для максимальной заинтересованности команды в результате; 116 основные правила взаимодействия участников команды для максимально быстрой реакции на существующую ситуацию; правила анализа и корректировки процесса разработки для совершенствования взаимодействия внутри команды. 4.5.2 Scrum- процессы Общая схема Scrum показана на рисунке 4.4 [52]. На схеме приведены основные понятия: Product Backlog – это список имеющихся на данный момент бизнес-требований и технических требований к системе с указанием приоритетов. Product Backlog включает в себя задачи, ошибки, технологии, проблемы, запросы и т.д. Sprint Backlog содержит функциональность, выбранную из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Sprint (Спринт) – итерация в Scrum, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель [17]. Результатом Sprint является готовый продукт (build), который можно передавать заказчику. Каждую итерацию (Sprint) можно описать так: планируем – фиксируем – реализуем – анализируем, т. е каждый спринт представляет собой маленький "водопад", в течение которого делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. За счет фиксирования требований на время одной итерации и изменения длины итерации можно управлять балансом между гибкостью и планируемостью разработки. 117 Рисунок 4.4 - Общая схема Scrum 118 Жизненный цикл Sprint (итерации) включает следующие процессы (этапы в данной методологи названы митингами) [17, 44, 50-52]. Ежедневный митинг (Daily Scrum Meeting). Этот митинг проходит каждое утро в начале дня, предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте, длительность не должна превышать 15 минут. Цель митинга - поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга. Планирование спринта. Планирование спринта состоит из двух последовательных митингов. Планирование спринта, митинг первый. Цель: определить цель спринта (Sprint Goal) и Sprint Backlog –функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта. Планирование спринта, митинг второй. Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность. Остановка спринта (Sprint Abnormal Termination). Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла. После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. 119 После этого начинается новый спринт: производится его планирование и стартуются работы. Демо и ревью спринта. Рекомендованная длительность: 4 часа. Команда демонстрирует инкремент продукта, созданный за последний спринт. Product Owner, менеджмент, заказчики, пользователи, в свою очередь, его оценивают. Команда рассказывает о поставленных задачах, о том как они были решены, какие препятствия были у них на пути, какие были приняты решения, какие проблемы остались нерешенными. На основании ревью принимающая сторона может сделать выводы о том, как должна дальше развиваться система. Участники миитинга делают выводы о том, как шел процесс в команде и предлагает решения по его улучшению. Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и распланировать кто и в какой последовательности что представляет. Подготовка к митингу не должна занимать у команды много времени (правило - не более двух часов). В частности, именно поэтому запрещается использовать презентации в Power Point. 4.5.3 Команда Scrum В методологии Scrum всего три роли [17, 44, 50-52]: Scrum Master, Product Owner, Team. Скрам Мастер (Scrum Master) – самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или TeamLider (тимлид). 120 Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой. Основные обязанности Скрам Мастера таковы: создает атмосферу доверия, участвует в митингах в качестве фасилитатора1 устраняет препятствия, делает проблемы и открытые вопросы видимыми, отвечает за соблюдение практик и процесса в команде. Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. ScrumMaster может также помогать Product Owner создавать Backlog для команды Product Owner – это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner - это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет. Обязанности Product Owner таковы: отвечает за формирование product vision, управляет ROI, управляет ожиданиями заказчиков и всех заинтересованных лиц. координирует и приоритизирует Product backlog, Фасилитатор (англ. facilitator, от лат. facilis — «лёгкий, удобный») – это человек, обеспечивающий успешную групповую коммуникацию [17]. 1 121 предоставляет понятные и тестируемые требования команде, взаимодействует с командой и заказчиком, отвечает за приемку кода в конце каждой итерации. Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта. В методологии Scrum команда Team является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. Обязанности команды таковы: отвечает за оценку элементов баклога принимает решение по дизайну и имплементации разрабатывает софт и предоставляет его заказчику отслеживает собственный прогресс (вместе со Скрам Мастером). отвечает за результат перед Product Owner Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды - 7 плюс минус 2. Команда в Scrum кроссфункциональна. В нее входят люди с различными навыками - разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью. 122 Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи. Для облегчения коммуникаций команда должна находиться в одном месте (colocated). Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы уменьшить препятствия для свободного общения. 4.6 Методология OpenUP OpenUP – это итеративно-инкрементальный метод разработки ПО. Позиционируется как легкий и гибкий вариант RUP [44, 53-54]. OpenUP – это открытый процесс разработки программного обеспечения, который разработан для небольших команд, находящихся в одном месте, которые хотят воспользоваться гибким подходом к разработке. Версия OpenUp 1.0 была опубликована в 2007 году. Метод развивается в рамках проекта Eclipse Process Framework Project [54]. Принципы методологии. В основу OpenUP положены следующие основные принципы: совместная работа с целью согласования интересов и достижения общего понимания; развитие с целью непрерывного обеспечения обратной связи и совершенствования проекта; концентрация на архитектурных вопросах на ранних стадиях для минимизации рисков и организации разработки; выравнивание конкурентных преимуществ для максимизации потребительской ценности для заинтересованных лиц. 123 Этапы методологии. OpenUP делит жизненный цикл проекта на четыре фазы: 1) начальная фаза, 2) фазы уточнения, 3) фаза конструирования 4) фаза передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение. OpenUP делит проект на итерации: планируемые, ограниченные во времени интервалы, длительность которых обычно измеряется неделями. План итерации определяет, что именно должно быть сдано по окончании итерации, а результатом является работоспособная версия. Коллективы разработчиков OpenUP строятся по принципу самоорганизации, решая вопросы выполнения задач итераций и передачи результатов. Для этого они сначала определяют, а затем решают хорошо детализированные задачи из списка элементов работ. Базовый процесс OpenUP является независимым от инструментов, малорегламентированным процессом, который может быть расширен для удовлетворения потребностей широкого диапазона типов проектов [44, 53]. 4.7 Методология Feature Driven Development Feature driven development (FDD, разработка, управляемая функциональностью) — итеративная методология разработки программного обеспечения, одна 124 из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки [17, 44, 55-57]. Данная методология – это функциональноориентированная разработка. Используемое в FDD понятие функции или свойства (feature) системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций. Методология FDD была изначально предложена Джеффом Де Люкой для проекта (рассчитанного на 15 месяцев и 50 человек) по разработке программного обеспечения для одного крупного Сингапурского банка в 1997 году. Процессы методологии. Де Люка выделил набор из пяти процессов последние два из которых повторяются для каждой функции: разработка общей модели, составление списка функций системы, планирование работы над каждой функцией, проектирование функции, реализацию функции (элементов функциональности (англ. feature)). 125 Разработчики в FDD делятся на «хозяев классов» и «главных программистов». Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Работа над проектом предполагает частые сборки и делится на итерации, каждая из которых предполагает реализацию определенного набора функций [55-57]. Этапы методологии. Так как функции малы, то их разработка – относительно легкая задача. Для мониторинга проекта по разработке ПО и предоставления точных данных о развитии проекта необходимо протоколировать разработку каждого свойства (функции). В методологии FDD выделяют шесть последовательных этапов для каждой функции (свойства): 1) анализ области; 2) дизайн; 3) проверка дизайна; 4) код; 5) проверка код; 6) включение в сборку. Первые три полностью завершаются в процессе проектирования, последние три – в процессе реализации. Для удобства контроля за выполнением работ на каждом этапе показывается процент его готовности (выполнения). К сожалению, такие области, как обеспечение качества, оценка рисков данная модель обходит стороной. FDD подходит для небольших проектов, срок реализации которых составляет несколько месяцев. Для долгосрочных проектов, со сроком производства год или более, предпочтительно выбрать другую, более формализованную модель [44]. 126 4.8 Методология Dynamic Systems Development Method Методология разработки динамических систем (Dynamic Systems Development Method, DSDM) – итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя. Цель метода: сдать готовый проект вовремя и уложиться в бюджет, но в то же время регулируя изменения требований к проекту во время его разработки. DSDM входит в семейство гибкой методологии разработки программного обеспечения, а также разработок не входящих в сферу информационных технологий [17, 57]. 4.8.1 Принципы DSDM Существует 9 принципов, состоящих из 4 основных и 5 начальных точек: вовлечение пользователя: разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными; команда должна быть уполномочена принимать важные для проекта решения без согласования с начальством; частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше – это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей; главный критерий – как можно более быстрая поставка программного обеспечения, которое удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет 127 потребностям рынка, менее важна, чем решение критических проблем в функционале продукта; разработка – итеративная и инкрементная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения; любые изменения во время разработки – обратимы; требования устанавливаются на высоком уровне прежде, чем начнётся проект; тестирование интегрировано в жизненный цикл разработки; взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности [17]. Предпосылки для использования DSDM. Чтобы успешно использовать DSDM, необходимо чтобы был выполнен ряд предпосылок: необходимо организовать взаимодействие между проектной командой, будущими пользователями и высшим руководством. должна присутствовать возможность разбиения проекта на меньшие части, что позволит использовать итеративный подход. В рамках DSDM существуют следующие факторы, которые влияют на успех проекта. принятие методики DSDM руководством и всеми работниками. Это обеспечивает мотивацию всех участников с момента запуска проекта и их последующую вовлечённость. готовность руководства обеспечить вовлечённость конечных пользователей в работу над проектом. Процесс прототипирования требует большой вовлечённости пользователей в тестирование и оценивание функциональных прототипов. 128 проектная команда. Она должна состоять из опытных членов и в итоге стать постоянным объединением. Это означает, что команда обладает правом и возможностью принимать важные решения о проекте без формального согласования с руководством, что могло бы отнять много времени. благосклонные отношения между разработчиком и покупателем. Это касается проектов, которые разрабатываются внутри самих компаний, а также с использованием сторонних подрядчиков. 4.8.2 Стадии DSDM Методология DSDM основана на подходе RAD и включает в себя три стадии: 1) предпроектная стадия, на которой авторизуется реализация проекта, определяются финансовые параметры и команда. 2) жизненный цикл проекта представляет собой реализации проекта и включает в себя пять этапов: определение реализуемости; экономическое обоснование; создание функциональной модели; проектирование и разработка; реализация; 3) постпроектная стадия обеспечивает качественную эксплуатацию системы. 4.8.3 Участники DSDM Методология DSDM определяет набор стандартных ролей. Каждая роль имеет свою собственную зону ответственности. Каждому члену команды сопоставляется 129 одна из ролей. Ниже перечислены основные роли, определяемые методологией DSDM [17, 57]. Менеджер проекта (Project Manager) – обеспечивает общее руководство проектом. Провидец (Visionary) – следит за соответствием проекта коммерческим целям и задачам. Провидцем часто является топ-менеджер, который инициировал проект. Чемпион проекта (Project Champion или Executive Sponsor) – обладает возможностями и обязанностями по распоряжению ресурсами и фондами, которые необходимы данному проекту. Чемпион проекта несет ответственность за принятие любых решений, связанных с проектом. Лидер команды (Team Leader) – руководит командой разработчиков и обеспечивает эффективность ее работы. Технический координатор (Technical Co-ordinator) – отвечает за разработку архитектуры продукта. Технический координатор также отвечает общее техническое состояние проекта. Разработчик (Developer) – участвует в анализе требований, моделировании и проектировании. Очевидно, что основной обязанностью разработчика является программирование. Тестировщик (Tester) – отвечает техническое тестирование продукта. Представительный пользователь (Ambassador User) – отвечает за то, чтобы разработчики вовремя получали обратную связь со стороны пользователей. Пользователь-консультант (Advisor User) – привносит в проект знание по некоторому аспекту использования разрабатываемого продукта. Секретарь (Scribe) – отвечает за протоколирование всех соглашений и решений, принятых во время семинаров. 130 Посредник (Facilitator) – отвечает за проведение семинаров. Посредник также отвечает за эффективность коммуникации между всеми членами команды. Методология DSDM рекомендует создавать команды небольшого размера, до шести человек (без учета руководящих персон вроде провидца и чемпиона проекта). При этом над одним проектом может работать несколько команд. Команды могут отвечать как за реализацию некоторого набора функциональности (например, отдельная команда может отвечать за реализацию системы базы данных), так и за некоторые виды деятельности (например, в проекте могут быть две команды, отвечающие за разработку, и одна команда, отвечающая за тестирование). На рисунке 4.5 приведена типичная структура команды разработчиков (участники проекта, имеющие полную занятость, изображены в закрашенных прямоугольниках) [57]. Рисунок 4.5 – Типичная структура команды в DSDM 131 4.9 Сравнение методологий Разнообразие методологий разработки программного обеспечения ставит большой вопрос при выборе оптимального подхода. Поэтому многие авторы проводят анализ и сравнение методологий по различным параметрам [44, 51, 56-59]. Прежде чем выбирать из конкретных методологий определяют общий подход, т.е. выбирают например, между тяжеловесными (каскадная стратегия) или легковесными (гибкие методологии) процессами. В таблицах 4.3-4.5 приведены результаты сравнения этих групп [58]. Таблица 4.3 – Сильные стороны групп методологий Тяжеловесные процессы (каскадная (Waterfall) стратегия) Легковесные процессы (гибкие (Agile) методологии) – легок для понимания и использования; – детально структурирован, что облегчает его применение к малоопытным командам; – задает стабильные требования к проекту /продукту с самого старта; – проекты легко контролируются, отслеживаются ресурсы, риски, время; – первоочередной приоритет качества перед стоимостью и временем. – итеративная разработка; – временные рамки (time boxes); – конечный пользователь вовлечен в процесс с самого начала; – быстрое получение первой/пробной версии продукта для тестирования; – легко воспринимаются корректировки и изменения в процессе разработки. 132 Таблица 4.4 – Слабые стороны групп методологий Тяжеловесные процессы (каскадная (Waterfall) стратегия) Легковесные процессы (гибкие (Agile) методологии) – все требования должны быть определены и детально описаны до начала разработки; – дорого и медленно; – чувствительны к изменениям; – мало возможностей для конечного пользователя повлиять на цели проекта и требования к продукту; – зачастую проблемы выявляются на этапе тестирования; – много технической документации, которая не понятна конечному пользователю или заказчику. – может привести к низкому качеству продукта; – риск никогда не достигнуть закрытия/завершения проекта; – могут возникнуть проблемы с расширяемостью продукта. Два подхода со своими плюсами и минусами, каждый из которых прекрасно подходит для применения в проектах с совершенно разными входными данными и требованиями. Не исключена ситуация, когда обоими методами можно реализовать поставку одного и того же продукта, но на старте каждого из проектов входные данные по таким ключевым параметрам, как стоимость, время, квалификация команды, требования к качеству, конечный пользователь и т. д., существенно влияют на выбор методологии. 133 Таблица 4.5 – Применение методологий Тяжеловесные процессы (каскадная (Waterfall) стратегия) Легковесные процессы (гибкие (Agile) методологии) – требования к продукту предельно ясны и стабильны; – известны используемые технологии и инструменты; – проект большой, дорогой и сложный; – примеры: – внедрение новой версии известного продукта; – внедрение ERP систем. – конечный пользователь вовлечен в проект со старта; – четко определены бизнес-цели проекта/продукта; – небольшой или средний проект, относительно короткий по времени; – состав команды стабильный; – команда с высоким уровнем профессионализма; – технические требования приемлемые, коррелируются с технологиями, которые собираются быть использованными для разработки; – система может быть модульной. Задача руководителя проекта – выбрать наиболее подходящий способ для достижения целей проекта. Waterfall, RUP, Scrum, RAD, XP, FDD, TDD и другие методологии помогут этого добиться, если вы понимаете разницу между ними, их принципы, слабые и сильные стороны. В некоторых случаях, это не выбор между методологиями, а правильная комбинация подходов для каждого из этапов проекта. И, как утверждает автор 134 анализа, Waterfall и Agile могут быть оптимально применены в рамках одного проекта [58]. Эти подходы также можно сравнить на другому набору критериев, приведенном в таблице 4.6 [59]. Таблица 4.6 – Сравнение групп методологий Критерии Традиционная Гибкая выбора Критичность Очень высокая, Низкая, новый mission-critical, бизнес продукт или решение платформа Требования В целом объем Есть только понятен, детали надо направление, идея уточнить Срочность Средняя-низкая, важнее Крайне высокая объем и качество Заказчик Ограниченно доступен, Постоянно длительные или доступен, быстрые сложные схемы решения принятия решений Команда Низкая квалификация Команда, у всех возможна, большая высокая команда, квалификация, все распределенная мотивированы, до 10 чел., в одном помещении Инструменты Желательны Обязательны инструменты и технологии быстрого прототипирования Культура Порядок, традиция Креатив, хаос 135 После определения общего подхода можно конкретизировать методологию. На основании исследований [60] составлена таблица 4.7. Касательно универсальности анализируют методологию Rational Unified Process (RUP) [61]. Рисунок 4.5 – Сравнение универсальности Методология RUP, в отличие от большинства других методологий, позволяет в широком диапазоне выбирать степень формализации и итеративности процесса разработки в зависимости от особенностей проектов и разрабатывающей организации. 136 Таблица 4.7 – Сравнение методологий Название Достоинства Рациональный – очень широкий диапазон решений в унифицированный части формализации процесса процесс Rational разработки; Unified Process – можно использовать как основу для (RUP) водопадного стиля разработки, так и в качестве гибкого процесса; – снижение основных рисков заказчика и разработчика; – экономия ресурсов за счет автоматизации регрессионного тестирования; – улучшение качества ПО за счет многократных проверок изменений; – улучшение качества тестирования за счет использования современных технологий. Microsoft Solutions – систематизация и структуризация Framework (MSF) информации в форме базы знаний; – нестандартные подходы к организационной структуре, 137 Недостатки недостаточный уровень формализма, который может приводить: – к несогласованности решений, принимаемых участниками проекта, – к непродуктивным затратам ресурсов на переработку кода и на повторное решение типовых проблем. не описывает детально важнейшие роли заказчика и пользователя; не рассматриваются Продолжение таблицы 4.7 – Сравнение методологий Название Достоинства распределению ответственности и принципам взаимодействия внутри команды; – MSF легко масштабируется – минимальный размер проектной группы в MSF-проекте – 3 человека, – но применять данную методологию можно для коллективов и в десятки, сотни, тысячи человек; MSF не навязывает использование каких-либо конкретных инструментов и программных средств. Разработка, – делает процесс легче; управляемая – дает возможность планирования и функциональность предварительного проектирования, ю Feature Driven создания детального дизайна, Development(FDD). – есть управление приоритетами и возможна трассировка требований; – рассчитан на работу в больших командах. 138 Недостатки методы управления группой проектов. – недостаток документации может значительно увеличивать стоимость последующего сопровождения продукта, т.к внесение каких-либо изменений потребует очень больших усилий. Продолжение таблицы 4.7 – Сравнение методологий Название Достоинства Экстремальное если его удается применить, то: программирование – большая гибкость; (eXtreme – возможность быстро и аккуратно Programming, XP вносить изменения в ПО в ответ на изменения требований и отдельные пожелания заказчиков; – высокое качество получающегося в результате кода; – отсутствие необходимости убеждать заказчиков в том, что результат соответствует их ожиданиям. 139 Недостатки – использование только в команде опытных разработчиков; – команду нельзя разбивать на несколько частей, возможный размер команды ограничен числом в 10–15 человек, т. к. большую роль играет прямое общение; – не всегда можно обеспечить постоянное присутствие представителя заказчика в проектной команде; – – нежелательно использовать в проекте с фиксированной ценой. Продолжение таблицы 4.7 – Сравнение методологий Название Достоинства Scrum – ориентирована на клиента, адаптивена; – дает клиенту возможность делать изменения в требованиях в любой момент времени (но не гарантирует того, что эти изменения будут выполнены); – возможность изменения требований привлекательна для многих заказчиков ПО; – достаточно прост в изучении, позволяет экономить время; – позволяет получить потенциально рабочий продукт в конце каждой итерации; – делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. 140 Недостатки – ввиду простоты и минималистичности, задает небольшое количество довольно жестких правил; – не принято, к примеру, создание плана коммуникаций и реагирования на риски. На основе приведенных данных имеем следующие выводы: 1. Каждая из рассмотренных моделей предназначена для разработки определенного класса ПО с разными требованиями к командам разработчиков. Модели ориентированы на соответствующее ПО, однако эффективны и при использовании в качестве независимых методологий. 2. Для выбора модели итеративного процесса разработки ПО одним из наиболее эффективных является показатель «вес модели», который учитывает масштаб, новизну и критичность проекта, распределение участников и требования заказчика [60]. Контрольные вопросы 1. На какие две группы делятся методологии разработки программного обеспечения? 2. Когда применяют прогнозирующий процесс разработки? 3. Поясните понятие «гибкая методология разработки программного обеспечения». 4. Какие компетенции необходимы для команды разработчиков, использующих гибкие методологии. 5. Как управляют рисками в гибких методологиях разработки ПО? 6. Какие задачи выполняются на итерациях в методологии гибкой разработки? 7. Назовите ключевые ценности методологий гибкой разработки ПО. 8. Назовите основные принципы гибкой разработки ПО. 9. Какие существуют методологии, которые соответствуют принципам гибкой разработки ПО? 141 10. Поясните, как относятся к изменениям в гибком подходе к разработке ПО. 11. Каковы основные принципы RUP? 12. Какие этапы включает рациональный унифицированный процесс? 13. Как определяет понятие «ИТ-решение» компания Microsoft? 14. Назовите основные принципы MSF. 15. Чем определяется универсальность модели MSF? 16. Какая модель цикла программной системы используется в MSF? 17. В чем состоит итеративность методологии MSF? 18. Поясните назначение интеграции в методологии MSF? 19. В чем проявляется высокая культура дисциплины обязательств методологии MSF? 20. Назовите ролевые кластеры модели команд методологии MSF. 21. Как можно масштабировать команду, использующую методологию MSF? 22. Поясните назначение треугольника компромиссов. 23. В чем состоит основная идея ХР подхода? 24. Какие отличительные признаки экстремального программирования? 25. Что такое рефакторинг? 26. Какими принципами характерна методология Scrum? 27. Какие процессы включает в себя Scrum? 28. Каков состав участников в проекте Scrum? 29. Характерные особенности OpenUP? 30. Какие процессы и этапы включает DSDM? 142 РАЗДЕЛ 5. ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ 5.1 Понятие паттерна, классификация В качестве основы проектирования программных продуктов применяются «типовые решения» или «шаблоны проектирования» (Patterns). Паттерн (англ. Pattern – образец, шаблон; форма, модель; схема, диаграмма) – схема-образ, действующая как посредствующее представление, или чувственное понятие, благодаря которому в режиме одновременности восприятия и мышления выявляются закономерности как они существуют в природе и обществе. Паттерн понимается как повторяющийся шаблон, или образец. Элементы паттерна предсказуемо повторяются. Так, из графических паттернов складываются красивые узоры [17]. В сфере создания программного обеспечения паттерны появились в середине 90-х как составная часть объектно-ориентированного подхода и рассматривались как набор объектов, организованных определенным образом для решения конкретного класса задач. Значимость паттернов состоит в том, что их использование позволяет выделить часто встречающиеся проблемы, дать им имена, предложить типовые решения, которые можно внедрять в создаваемые программные продукты [62-63]. Паттерны не являются готовыми компонентами, это только заготовка, для которой необходимо создавать функциональность, т.е. писать код. Известны различные подходы к классификации паттернов. Так, паттерны с точки зрения абстракции предлагается классифицировать на: 143 – концептуальные, – проектирования, – программные. Концептуальные паттерны – паттерны, функционирование которых описывается в терминах предметной области. Относятся к приложению в целом, крупным подсистемам ИС. Паттерны проектирования – паттерны, для описания которых используются термины, относящиеся к разработке программных систем, такие как объект, класс, модуль. Паттерны проектирования описывают решение общих проблем в конкретном контексте. Программные паттерны – паттерны, для описания которых используются такие низкоуровневые понятия как списки, деревья. Используется также следующая классификация паттернов [62]: – архитектурные (architectural); – системные (system); – структурные (structural); – поведенческие (behavioral); – производящие (creational); – параллельного программирования (concurrency). Архитектурный паттерн описывает структуру программной системы и определяет состав подсистемы, их основные функции и допустимые способы компоновки подсистемы. Архитектурные паттерны называют также архитектурными стилями, которые подробно будут рассмотрены в разделе 6. Архитектурные паттерны являются описанием, которое не зависит от платформы, ни от языка программирования. Архитектурные паттерны можно рассматривать как паттерны высокого уровня. Системные паттерны представляют собой приложение на верхнем (системном) уровне. Системные 144 паттерны могут применяться в приложении для реализации типовых процессов и для поддержки взаимодействия разных приложений. Структурные паттерны с одинаковой эффективностью применяются как для разделения, так и для объединения элементов приложения. Поведенческие паттерны применяются для передачи управления в системе. Существуют методы организации управления, применение которых позволяет добиться значительного повышения как эффективности системы, так и удобства ее эксплуатации. Поведенческие шаблоны представляют собой набор проверенных на практике методов и обеспечивают понятные и простые в применении эвристические способы организации управления. Производящие паттерны предназначены для создания объектов в системе. Производящие паттерны облегчают процесс создания объектов, предоставляя разработчику возможности единого способа получения экземпляров объектов, простоту создания объектов, учет ограничений при создании объектов. Паттерны параллельного программирования ориентированы на облегчение корректного взаимодействия асинхронно протекающих процессов и ориентированы на решение двух основных задач: совместное использование ресурсов и управление доступом к ресурсам. Группы структурных, поведенческих и производящих паттернов соответствуют паттернам проектирования, указанным в первой классификации. Более подробно будут рассмотрены в разделе 5.3. Возможна также другая классификация, в основе которой лежит следующий принцип [64]. Эффективной процедурой является многоуровневое представление 145 структур. Переход с одного уровня представления на другой осуществляется путем выделения определенных подструктур, которые, в свою очередь рассматриваются в качестве «макроскопических» элементов, связанных между собой более простым и понятным образом. В свою очередь, элементы более низкого уровня могут быть названы «микроскопическими». При проектировании в области информационных технологий в качестве вышеописанной структуры выступает система. В рассматриваемом подходе к проектированию система конфигурируется с использованием паттернов. Низшим уровнем представления данной системы является описание ее в терминах классов (со своими атрибутами и операциями) и соответствующих им объектов, выступающих в качестве «микроскопических» элементов, и отношений между ними, играющих роль связей. Примером «макроскопического» элемента следующего уровня является системная архитектура, представляющая собой базовую подструктуру рассматриваемой системы. Самым высоким уровнем является интеграция отдельных систем, которые в данном случае рассматриваются в качестве макроскопических элементов. Следует подчеркнуть, что на этом уровне связи фактически становятся метасвязями и строятся на основе методик, отличных от тех, которые используются на двух предыдущих уровнях. Базовым примером подобной метасвязи может служить интегрирующая среда. Соответственно, предлагаемая классификация паттернов проектирования отражает три вышеописанные уровня представления [65-67], как показано на рисунке 5.1. 146 Рисунок 5.1 – Классификация паттернов проектирования 147 паттерны проектирования классов/объектов: o структурные паттерны проектирования классов/объектов; o паттерны проектирования поведения классов/объектов; o порождающие паттерны проектирования; архитектурные системные паттерны: o структурные паттерны; o паттерны управления: паттерны централизованного управления; паттерны управления, основанные на событиях; паттерны, обеспечивающие взаимодействие с базой данных; паттерны, предназначенные для представления данных в веб; паттерны интеграции корпоративных информационных систем: o структурные паттерны интеграции; o паттерны по методу интеграции; o паттерны интеграции по типу обмена данными; Также на сегодняшний день существует ряд других паттернов: – Carrier Rider Mapper, предоставление доступа к хранимой информации; – аналитические шаблоны, описывают основной подход для составления требований для программного обеспечения (requirement analysis) до начала самого процесса программной разработки; – коммуникационные шаблоны, описывают процесс общения между отдельными участниками/сотрудниками организации; – организационные шаблоны, описывают организационную иерархию предприятия/фирмы; 148 – Анти-паттерны (Anti-Design-Patterns) как не следует поступать при разработке показывая характерные ошибки в дизайне и в [64]. Рассмотрим подробнее группу проектирования. описывают программ, реализации паттернов 5.2 Паттерны проектирования Паттерн проектирования (шаблон, design pattern) – это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения [17, 65-71]. Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код, скорее это описание или образец для того, как решить задачу, таким образом, чтобы это можно было использовать в различных ситуациях. Историческая справка [17, 67-69]. В 1970-е годы архитектор Кристофер Александр составил набор шаблонов проектирования. В области архитектуры эта идея не получила такого развития, как позже в области программной разработки. Согласно определению Кристофера Александера: «Каждое типовое решение описывает некую повторяющуюся проблему и ключ к ее разгадке, причем таким образом, что вы можете пользоваться этим ключом многократно, ни разу не придя к одному и тому же результату». В 1987 году Кент Бэк и Вард Каннигем взяли идеи Александра и разработали шаблоны применительно к разработке программного обеспечения для разработки графических оболочек на языке Smalltalk. 149 В 1988 году Эрих Гамма начал писать докторскую диссертацию при Цюрихском университете об общей переносимости этой методики на разработку программ. В 1989 Джеймс Коплиен в целях обучения С++ внутри компании AT&T составил каталог идиом С++ (разновидность паттернов, специфичных для языка программирования В 1991 Джеймс Коплиен опубликовал книгу «Advanced C++ Programming Styles and Idioms». В этом же году Эрих Гамма заканчивает свою докторскую диссертацию и переезжает в США. В 1994 Эрих Гамма в сотрудничестве с Ричардом Хелмом, Ральфом Джонсоном и Джоном Влиссидсом публикует книгу «Design Patterns – Elements of Reusable Object-Oriented Software» [65]. В этой книге описаны 23 шаблона проектирования. Также команда авторов этой книги известна общественности под названием Банда четырех (Gang of Four, часто сокращается до GoF). Книга получила большое количество наград, переведена на 13 языков. Именно эта книга стала причиной роста популярности шаблонов проектирования. Другим видным деятелем в области проектирования программных систем, который поддержал использование паттернов, является Мартин Фаулер, написавший книгу «Архитектура корпоративных программных приложений» (Patterns of Enterprise Application Architecture [70]. Как отметил Мартин Фаулер в своей книге «собираясь воспользоваться типовыми решениями, не забывайте, что они только отправная точка, а не пункт назначения». В книге Крейга Лармана «Применение UML и шаблонов проектирования» описано 9 шаблонов GRASP (General Responsibility Assignment Software Patterns, общие образцы распределения обязанностей) – паттернов, используемых в объектно-ориентированном 150 проектировании для решения общих задач по назначению обязанностей классам и объектам. Каждый из них помогает решить некоторую проблему, возникающую при объектно-ориентированном анализе, и которая возникает практически в любом проекте по разработке программного обеспечения. Главная польза каждого отдельного шаблона состоит в том, что он описывает решение целого класса абстрактных проблем. Также тот факт, что каждый шаблон имеет свое имя, облегчает дискуссию об абстрактных структурах данных (ADT) между разработчиками, так как они могут ссылаться на известные шаблоны. Таким образом, за счет шаблонов производится унификация терминологии, названий модулей и элементов проекта. 5.3 Паттерны проектирования классов/объектов Не смотря на различие классификаций (см. 5.1), паттерны проектирования классов/объектов разделяют на: – структурные (structural) табл. 5.1; – порождающие, производящие (creational) табл. 5.2; – поведенческие (behavioral) табл. 5.3. Структурные паттерны рассматривают вопросы о компоновке системы на основе классов и объектов. При этом могут использоваться следующие механизмы: – наследование, когда базовый класс определяет интерфейс, а подклассы – реализацию. Структуры на основе наследования получаются статичными. – композиция, когда структуры строятся путем объединения объектов некоторых классов. Композиция позволяет получать структуры, которые можно изменять во время выполнения. К структурным паттернам относятся паттерны, показанные в таблице 5.1. 151 Таблица 5.1 – Структурные паттерны проектирования классов/объектов 1. Адаптер (Adapter); GoF 2. Декоратор (Decorator) или Оболочка GoF (Wrapper); 3. Заместитель (Proxy) или Суррогат (Surrogate); GoF 4. Информационный эксперт (Information GRASP Expert); 5. Компоновщик (Composite); GoF 6. Мост (Bridge), Handle (описатель) или Тело GoF (Body); 7. Низкая связанность (Low Coupling); GRASP 8. Приспособленец (Flyweight); GoF 9. Устойчивый к изменениям (Protected GRASP Variations); 10. Фасад (Facade); GoF Создание новых объектов является наиболее распространенной задачей, встающей перед разработчиками программных систем. Порождающие паттерны проектирования предназначены для создания объектов, позволяя системе оставаться независимой как от самого процесса порождения, так и от типов порождаемых объектов. К порождающим паттернам относятся паттерны, показанные в таблице 5.2. Таблица 5.2 – Порождающие паттерны проектирования 1. Абстрактная фабрика (Abstract Factory, GoF Factory, Kit); 2. Одиночка (Singleton); GoF 3. Прототип (Prototype); GoF 4. Создатель экземпляров класса (Creator); GoF 5. Строитель (Builder); GoF 6. Фабричный метод (Factory Method) GoF 152 Паттерны поведения рассматривают вопросы о связях между объектами и распределением обязанностей между ними. Для этого могут использоваться механизмы, основанные как на наследовании, так и на композиции. К порождающим паттернам относятся паттерны, показанные в таблице 5.3. Таблица 5.3 – Паттерны проектирования поведения классов/объектов 7. Интерпретатор (Interpreter ); GoF 8. Итератор (Iterator) или Курсор (Cursor); GoF 9. Команда (Command), Действие (Action); GoF 10. Наблюдатель (Observer, Publish – Subscribe); GoF 11. Не разговаривайте с неизвестными (Don't GRASP talk to strangers); 12. Посетитель (Visitor); GoF 13. Посредник (Mediator); 14. Состояние (State); GoF 15. Стратегия (Strategy); GoF 16. Хранитель (Memento); GoF 17. Цепочка обязанностей (Chain of GoF Responsibility); 18. Шаблонный метод (Template Method); GoF 19. Высокое зацепление (High Cohesion); GRASP 20. Контроллер (Controller); GRASP 21. Полиморфизм (Polymorphism); GRASP 22. Искусственный (Pure Fabrication); GRASP 23. Перенаправление (Indirection); GRASP Задача каждого паттерна – дать четкое описание проблемы и ее решения в соответствующей области. В общем случае описание паттерна всегда содержит следующие элементы: 153 – название паттерна. Представляет собой уникальное смысловое имя, однозначно определяющее данную задачу или проблему и ее решение. – решаемая задача. Здесь дается понимание того, почему решаемая проблема действительно является таковой, четко описывает ее границы. – решение. Здесь указывается, как именно данное решение связано с проблемой, приводится пути ее решения. – результаты использования паттерна. Обычно приводятся достоинства, недостатки и компромиссы. Результаты применения паттернов. Один из соавторов GoF, Джон Влиссидес [65] приводит следующие преимущества применения паттернов проектирования: – они (паттерны) позволяют суммировать опыт экспертов и сделать его доступным рядовым разработчикам; – имена паттернов образуют своего рода словарь, который позволяет разработчикам лучше понимать друг друга; – если в документации системы указано, какие паттерны в ней используются, это позволяет читателю быстрее понять систему; – паттерны упрощают реструктуризацию системы независимо от того, использовались ли паттерны при ее проектировании; Правильно выбранные паттерны проектирования позволяют сделать программную систему более гибкой, ее легче поддерживать и модифицировать, а код такой системы в большей степени соответствует концепции повторного использования. В таблице 5.4 приведены паттерны проектирования классов и объектов с кратким описанием. 154 Таблица 5.4 –Паттерны проектирования Оригинальное Русскоязычное Тип паттерна название название Abstarct Абстрактная Порождающий Factory фабрика Adapter Адаптер Структурный Bridge Мост Структурный Builder Строитель Порождающий Chain of Responsibility Command Цепочка обязанностей Команда Поведения Composite Компоновщик Структурный Decorator Декоратор Структурный Facade Фасад Структурный Поведения 155 Краткое описание Создает семейство взаимосвязанных объектов Преобразует интерфейс существующего класса к виду, подходящему для использования Делает абстракцию и реализацию независимыми друг от друга Поэтапное создание сложного объекта Предоставляет способ передачи запроса по цепочке получателей Инкапсулирует запрос в виде объекта Группирует схожие объекты в древовидные структуры Динамически добавляет объекту новую функциональность Предоставляет унифицированный интерфейс вместо набора интерфейсов некоторой системы Продолжение таблицы 5.4 – Паттерны проектирования Оригинальное Русскоязычное Тип паттерна Краткое описание название название Factory Method Фабричный Порождающий Определяет интерфейс для создания метод объекта, при этом его тип определяется подклассами Flyweight Приспособленец Структурный Использует разделение для поддержки множества мелких объектов Interpreter Интерпретатор Поведения Для языка определяет его грамматику и интерпретатор, использующий эту грамматику Iterator Итератор Поведения Предоставляет механизм обхода элементов коллекции Mediator Посредник Поведения Инкапсулирует взаимодействие между множеством объектов в объектпосредник Memento Хранитель Поведения Сохраняет и восстанавливает состояние объекта Object Pool Пул объектов Порождающий Создание "затратных" объектов за счет их многократного использования Observer Наблюдатель Поведения При изменении объекта извещает всех зависимые объекты для их обновления 156 Продолжение таблицы 5.4 – Паттерны проектирования Оригинальное Русскоязычное Тип паттерна Краткое описание название название Prototype Прототип Порождающий Создание объектов на основе прототипов Proxy Заместитель Структурный Подменяет другой объект для контроля доступа к нему Singleton Одиночка Порождающий Создает единственный экземпляр некоторого класса и предоставляет к нему доступ State Состояние Поведения Изменяет поведение объекта при изменении его состояния Strategy Стратегия Поведения Переносит алгоритмы в отдельную иерархию классов, делая их взаимозаменяемыми Template Шаблонный Поведения Определяет шаги алгоритма, позволяя Method метод подклассам изменить некоторые из них Visitor Посетитель Поведения Определяет новую операцию в классе без его изменения 157 Контрольные вопросы 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Что такое паттерн? Является ли паттерн готовым кодом? Можно ли считать паттерном какой-либо компонент? Что можно описать с помощью концептуальных паттернов? Какой вид паттерном можно отнести к нижнему уровню представления программы? На какие группы можно разбить архитектурные системные паттерны? Какие факторы повлияли на появление паттернов в проектировании и программировании? Какие авторы наиболее повлияли на развитие паттернов в сфере разработки программного обеспечения? Перечислить группы паттернов проектирования классов и объектов. Какие достоинства в применении паттернов проектирования? Что подразумевает GRASP? Какие паттерны относятся к порождающим? Привести пример структурного паттерна. 158 РАЗДЕЛ 6. АРХИТЕКТУРА ПРОГРАММНЫХ СРЕДСТВ, СТАНДАРТЫ ОПИСАНИЯ АРХИТЕКТУРЫ ПРОГРАММНЫХ СРЕДСТВ 6.1 Место архитектурного проектирования в процессе разработки ПО Разработка программного обеспечения неизбежно включает этап проектирования. Проектирование – итерационный процесс, при помощи которого требования к ПС транслируются в инженерные представления ПС. Вначале эти представления дают только концептуальную информацию (на высоком уровне абстракции), последующие уточнения приводят к формам, которые близки к текстам на языках программирования [6]. В работе [1] описано, что на этапе проектирования ПО определяется его структура, данные, которые являются частью системы, интерфейсы взаимодействия системных компонентов и иногда используемые алгоритмы. Проектировщики сразу никогда не получают законченный результат – процесс проектирования обычно проходит через разработку нескольких промежуточных версий ПО. Проектирование предполагает последовательную формализацию и детализацию создаваемого ПО с возможностью внесения изменений в решения, принятые на более ранних стадиях проектирования. Процесс проектирования может включать разработку нескольких моделей системы различных уровней обобщения. Поскольку проектирование – это процесс декомпозиции, такие модели помогают выявить ошибки, допущенные на ранних стадиях проектирования, а следовательно, позволяют внести изменения в ранее 159 созданные модели. На рис. 6.1 показана схема процесса проектирования ПО с указанием результата каждого этапа проектирования. Эта схема построена в предположении, что все этапы процесса проектирования выполняются последовательно. На практике эти этапы перекрываются вследствие неизбежных обратных связей от одного этапа к предыдущему и повторного выполнения некоторых проектных работ. Конечными результатами процесса проектирования являются точные спецификации на алгоритмы и структуры данных, которые будут реализованы на следующем этапе создания ПО. Ниже перечислены отдельные этапы процесса проектирования [1]. 1. Архитектурное проектирование. Определяются и документируются подсистемы и взаимосвязи между ними. 2. Обобщенная спецификация. Для каждой подсистемы разрабатывается обобщенная спецификация на ее сервисы и ограничения. 3. Проектирование интерфейсов. Для каждой подсистемы определяется и документируется ее интерфейс. Спецификации на эти интерфейсы должны быть точно выраженными и однозначными, чтобы использование подсистем не требовало знаний о том, как они реализуют свои функции. 4. Компонентное проектирование. Проводится распределение системных функций (сервисов) по различным компонентам и их интерфейсам. 5. Проектирование структур данных. Детально разрабатываются структуры данных, необходимые для реализации программной системы. 6. Проектирование алгоритмов. Детально разрабатываются алгоритмы, предназначенные для реализации системных сервисов. 160 Рисунок 6.1 – Обобщенная схема процесса проектирования [1] 161 Описанная схема процесса проектирования является достаточно общей и на практике может (и должна) адаптироваться применительно к разработке конкретного программного продукта. Если рассмотреть описанные выше этапы с другой точки зрения, то можно укрупнить процесс проектирования. Так в работе [6] в проектировании выделяют две ступени: архитектурное проектирование и детальное проектирование. Архитектурное проектирование формирует абстракции архитектурного уровня, детальное проектирование уточняет эти абстракции, добавляет подробности алгоритмического уровня. Кроме того, во многих случаях выделяют интерфейсное проектирование, цель которого – сформировать графический интерфейс пользователя (GUI). Схема информационных связей процесса проектирования приведена на рис. 6.2. Рисунок 6.2 – Информационные связи процесса проектирования [6] Таким образом, архитектурное проектирование является первым базовым этапом проектирования. 162 6.1 Архитектурное проектирование Архитектурным проектированием называют первый этап процесса проектирования, на котором определяются подсистемы, а также структура управления и взаимодействия подсистем. Целью архитектурного проектирования является описание архитектуры программного обеспечения [1]. Архитектурное проектирование обеспечивает понимание правильной организации системы и создает структуру под эту правильную организацию. оно напрямик связывает весь этап проектирования с детальными требованиями, поскольку архитектура выделяет основные структурные компоненты системы и формирует отношения между ними. Между созданием детальных требований и архитектурным проектированием имеется существенное перекрытие. На самом деле это справедливо только для малых систем. Архитектурное разделение системы на части просто необходимо для структуризации и организации спецификации требований. Поэтому перед созданием детальных требований формируется абстрактная архитектура системы, с подсистемами которой ассоциируются целые группы функций и характеристик [6]. Эта же архитектура используется для обсуждения требований и характеристик системы с заинтересованными лицами. Модель системной архитектуры часто является отправной точкой для создания спецификации различных частей системы. В процессе архитектурного проектирования разрабатывается базовая структура системы, т.е. определяются основные компоненты системы и взаимодействия между ними. 163 Результатом процесса архитектурного проектирования является документ, отображающий архитектуру системы. Он состоит из набора графических схем представлений моделей системы с соответствующим описанием. В описании должно быть указано, из каких подсистем состоит система и из каких модулей слагается каждая подсистема. Графические схемы моделей системы позволяют взглянуть на архитектуру с разных сторон. Как правило, разрабатывается четыре архитектурные модели. 1. Статическая структурная модель, в которой представлены подсистемы или компоненты, разрабатываемые в дальнейшем независимо. 2. Динамическая модель процессов, в которой представлена организация процессов во время работы системы. 3. Интерфейсная модель, которая определяет сервисы, предоставляемые каждой подсистемой через общий интерфейс. 4. Модели отношений, в которых показаны взаимоотношения между частями системы, например поток данных между подсистемами. Существуют различные подходы к процессу архитектурного проектирования, которые зависят от профессионального опыта, а также мастерства и интуиции разработчиков. И все же можно выделить несколько этапов, общих для всех процессов архитектурного проектирования [1]: – структурирование системы. Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами. Более подробно рассматривается в разделе 6.4. 164 – моделирование управления. Разрабатывается базовая модель управления взаимоотношениями между частями системы. Более подробно описано в разделе 6.5. – модульная декомпозиция. Каждая определенная на первом этапе подсистема разбивается на отдельные модули. Здесь определяются типы модулей и типы их взаимосвязей. Как правило, эти этапы перемежаются и накладываются друг на друга. Этапы повторяются для все более детальной проработки архитектуры до тех пор, пока архитектурный проект не будет удовлетворять системным требованиям. 6.2 Понятие архитектуры ПО Существует большое количество определений, характеризующих понятие архитектуры программного продукта или системы [1-5, 9-14, 67, 70-74]: – Архитектура – это организационная структура системы. – Архитектура информационной системы – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. – Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы. – Архитектура – это набор значимых решений по поводу организации системы программного обеспечения, набор структурных элементов и их интерфейсов, при помощи которых компонуется система, вместе с их поведением, определяемым во взаимодействии между этими элементами, компоновка элементов в постепенно 165 укрупняющиеся подсистемы, а также стиль архитектуры, который направляет эту организацию – элементы и их интерфейсы, взаимодействия и компоновку. – Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними. – Архитектура – это структура организации и связанное с ней поведение системы. Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы. – Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания. Хотя определения несколько отличаются, можно заметить немалую степень сходства. Например, большинство определений указывают на то, что архитектура связана со структурой и поведением, а также только со значимыми решениями, может соответствовать некоторому архитектурному стилю, на нее влияют заинтересованные в ней лица и ее окружение, она воплощает решения на основе логического обоснования. Под архитектурой программных систем будем понимать совокупность решений относительно [67]: – организации программной системы; 166 – выбора структурных элементов, составляющих систему и их интерфейсов; – поведения этих элементов во взаимодействии с другими элементами; – объединение этих элементов в подсистемы; – архитектурного стиля, определяющего логическую и физическую организацию системы: статические и динамические элементы, их интерфейсы и способы их объединения. Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и правила ее использования и интеграции с другими системами, функциональность, производительность, гибкость, надежность, возможность повторного применения, полноту, экономические и технологические ограничения, а также вопрос пользовательского интерфейса. По мере развития программных систем все большее значение приобретает их интеграция друг с другом с целью построения единого информационного пространства предприятия. Как можно видеть из вышеприведенных определений интеграция является важнейшим элементом архитектуры. Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем необходимо иметь представлении об разновидностях архитектурных моделей, архитектурных стилях (паттернов). 6.3 Классификация архитектурных стилей Архитектура может архитектурному стилю. соответствовать 167 некоторому Большинство архитектур построены на основе систем, использующих похожие решения. Сходство может быть определено как архитектурный стиль, который, в свою очередь, можно рассматривать как особый ВИД паттерна (шаблона). Архитектурный стиль представляет собой кодификацию опыта проектирования ИТ-систем. Примеры архитектурных стилей включают распределенный стиль, стиль «каналы и фильтры», стиль с централизованной обработкой данных, стиль, построенный на правилах, и т.д. Конкретная система может демонстрировать более одною архитектурного стиля. Архитектурный стиль можно определить как семейство систем в терминах шаблона организации структуры. Точнее, архитектурный стиль определяет номенклатуру компонентов и типов соединительных звеньев, а также набор условий, в соответствии с которыми они могут соединяться. Архитектурный стиль определяется набором типов компонентов, во время счета выполняющих некоторую функцию, топологической раскладкой компонентов с указанием их взаимосвязей во время выполнения, набором семантических ограничений, набором соединителей, служащих средой сообщения, координации и сотрудничества между компонентами [62]. При использовании вместо термина архитектурный стиль термин архитектурный паттерн (шаблон) следует подразумевать подход к проектированию. Существуют различные взгляды на классификацию архитектурных стилей. Мэри Шоу (Mary Shaw) и Дэвид Гарлан (David Garlan) в 1996 г. предложили классификацию архитектур ПО с точки зрения практики (рисунок 6.3): независимые компоненты: o параллельные взаимодействующие процессы; 168 клиент-серверные системы; системы с событиями: неявный вызов и явный вызов; поток данных: o пакетно-последовательный; o каналы и фильтры; централизованные данные: o базы данных (хранилище); o гипертекстовые системы; o доска объявлений; виртуальные машины: o интерпретаторы; o системы, основанные на правилах; уровневые архитектуры. o o Архитектуры ПО Рисунок 6.3 – Классификация архитектур ПО с точки зрения практики (М. Шоу и Д. Гарлан, 1996) 169 В работе [62] выделяют двенадцать базовых стилей, которые делятся на пять групп (рисунок 6.5). 1. Потоки данных (Data Flow System): – системы пакета-последовательной обработки (Batch Sequential Systems); – системы типа конвейеры и фильтры (Pipe and Filter Architecture). 2. Вызов с возвратом (Call- and-Return System): – программа-сопрограммы (Маіn Program and Subroutines), – объектно-ориентированные системы (ObjectOriented Systems), – клиент-серверные системы (Client-Server Systems), – иерархические многоуровневые системы (Hierarchically Layered Systems). 3. Независимые компоненты (Independent Component System): – системы двух стилей взаимодействующих процессов (Communicating Sequential Processes); – системы, управляемые событиями (Event-Based Systems). 4. Центральные данные (Data-Centric System): – системы, основанные на использовании централизованной базы данных (Database Systems); – системы, использующие принцип классной доски (Blackboard Systems). 5. Виртуальные машины (Virtual Machines): – интерпретаторы (Interpreters); – системы, основанные на правилах (Rule-Based Systems). В соответствии с классификацией паттернов проектирования выделяют следующие архитектурные системные паттерны [64, 67]: 170 Рисунок 6.4 – Классификация архитектурных стилей 171 Структурные паттерны: – репозиторий (хранилище данных); – клиент/сервер; – многоуровневая система (Layers) или абстрактная машина; – объектная модель, модель предметной области (Domain Model), модуль таблицы (Data Mapper); – потоки данных (конвейер или фильтр); 2. Паттерны управления: – Паттерны централизованного управления: вызов – возврат; диспетчер; – Паттерны управления, основанные на событиях передача сообщений управляемый прерываниями – Паттерны взаимодействие с базой данных: паттерны архитектуры источников данных; паттерны объектно-реляционной логики; паттерны объектно-реляционного структурирования; паттерны логики сущности; паттерны обработки объектно-реляционных метаданных; паттерны распределения данных; паттерны локальной конкуренции; – Паттерны для представления данных в Веб: модель-представление-контроллер (Model View Controller); контроллер страниц (Page Controller); контроллер запросов (Front Controller); представление по шаблону (Template View); представление с преобразованием (Transform View); двухэтапное представление (Two Step View); 1. 172 контроллер приложения (Application Controller); Если сопоставить последнюю классификацию этапам архитектурного проектирования, приведенным в п. 6.1, то первые три структурных паттерна соответствуют этапу структурирование системы, остальные два относятся к декомпозиции модулей, а паттерны управления – этапу моделирование управления. Поэтому рассмотрим далее архитектурные паттерны (стили) в соответствии с последней классификацией. 6.4 Структурные паттерны 6.4.1 Паттерн (модель) репозитория Модель системы, основанная на совместном использовании базы данных, называют моделью репозитория (хранилища данных). Описание. Все совместно используемые подсистемами данные хранятся в центральной базе данных, доступной всем подсистемам. Репозиторий является пассивным элементом, а управление им возложено на подсистемы. Пример архитектуры репозитория показан на рисунке 6.5. В основе архитектуры лежит репозиторий, который является хранилищем информации, необходимой для запуска заданий. В репозитории сохраняются задания, в него же поступаю журналы выполнения заданий агентами. Репозиторий также доступен бизнес пользователям. Рекомендации. Логично использовать, если система обрабатывает большие объёмы данных. Такая модель подойдет к приложениям, в которых данные создаются в одной подсистеме, а используются в другой. Удобно 173 использовать в системах, определяется данными. порядок работы которых Рисунок 6.5 – Паттерн (модель) хранилища данных Преимущества. Совместное использование больших объёмов данных эффективно, поскольку не требуется передавать данные из одной подсистемы в другие. Подсистема не должна знать, как используются данные в других подсистемах - уменьшается степень связывания. В системах с репозиторием резервное копирование, обеспечение безопасности, управление доступом и восстановление данных централизованы, поскольку входят в систему управления репозиторием. Недостатки. Все подсистемы должны быть согласованы со структурой репозитория (моделью данных). Модернизировать модель данных достаточно трудно [64]. К разными подсистемам предъявляются различные требования по безопасности, восстановлению и резервированию данных, а в паттерне Репозиторий ко всем подсистемам применяется одинаковая политика. 174 6.4.2 Паттерн (модель) клиент/сервер Модель архитектуры клиент/сервер – это модель распределенной системы, в которой показано распределение данных и процессов между несколькими процессорами. Модель включает три основных компонента: 1. Набор автономных серверов, предоставляющих сервисы другим подсистемам. Например, сервер печати, который предоставляет услуги печати, файловые серверы, предоставляющие сервисы управления файлами, и серверкомпилятор, который предлагает сервисы по компилированию исходных кодов программ. 2. Набор клиентов, которые вызывают сервисы, предоставляемые серверами. В контексте системы клиенты являются обычными подсистемами. Допускается параллельное выполнение нескольких экземпляров клиентской программы. 3. Сеть, посредством которой клиенты получают доступ к сервисам. В принципе нет никакого запрета на то, чтобы клиенты и серверы запускались на одной машине. На практике, однако, модель клиент/сервер в такой ситуации не используется [1]. Описание. Данные и процессы системы распределены между несколькими процессорами. Паттерн имеет три основных компонента: набор автономных серверов, (предоставляют сервисы другим подсистемам), набор подсистем - клиентов (которые вызывают сервисы, предоставляемые серверами) и сеть (служит для доступа клиентов к сервисам). Клиенты должны знать имена серверов и сервисов, в то время как серверам не надо знать имена клиентов и их количество. Клиенты получают доступ к сервисам, предоставляемым серверами посредством удаленного вызова процедур. 175 Клиенты должны знать имена доступных серверов и сервисов, которые они предоставляют. В то же время серверам не нужно знать ни имена клиентов, ни их количество. Клиенты получают доступ к сервисам, предоставляемым сервером, посредством удаленного вызова процедур. Пример системы, организованной по типу модели клиент/сервер, показан на рис. 6.6. Это многопользовательская гипертекстовая система, предназначенная для поддержки библиотек фильмов и фотографий. В ней содержится несколько серверов, которые размещают различные типы медиафайлов и управляют ими. Видеофайлы требуется передавать быстро и синхронно, но с относительно малым разрешением. Они могут храниться в сжатом состоянии. Фотографии должны передаваться с высоким разрешением. Каталоги должны обеспечивать работу с множеством запросов и поддерживать связи с использованием гипертекстовой системы. Здесь клиентская программа является просто интегрированным интерфейсом пользователя [1]. Рисунок 6.6 – Пример модели клиент/сервер 176 Рекомендации. Можно использовать когда услуги должны быть доступны из разных мест или когла требуется гибкий механизм перестройки системы по загружаемым начальным данным [6]. Преимущества. 1. Предоставление клиентам различных услуг через четь. 2. Устраняется необходимость тиражирования реализации услуг среди серверов. 3. Формирует распределенную архитектуру, ее эффективно использовать в сетевых системах с множеством распределенных процессоров. В систему легко добавить новый сервер и интегрировать его с остальной частью системы или же обновить сервисы, не воздействуя на другие части системы [6, 64]. Недостатки. Возможно понижение скорости доступа к данным из-за проблем в сети. Поломка сервера лишает клиента услуги. 6.4.3 Паттерн (модель) многоуровневой системы или абстрактной машины Паттерн (модель) многоуровневой архитектуры предлагает организовать функциональность в виде отдельных уровней, каждый из которых предоставляет свои сервисы. Каждый уровень определяет абстрактную машину, машинный язык которой (сервисы, предоставляемые уровнем) используется для реализации следующего уровня абстрактной машины [1]. Описание. Паттерном «Многоуровневая система» структурные элементы системы организуются в отдельные уровни со взаимосвязанными обязанностями таким образом, чтобы на нижнем уровне располагались низкоуровневые службы и службы общего назначения, а на более высоких – объекты уровня логики приложения. При этом взаимодействие и связывание уровней 177 происходит сверху вниз. Связывания объектов снизу вверх следует избегать [64]. Пример. На рис. 6.7 изображена подобная модель и показано, как с помощью модели абстрактной машины можно представить систему администрирования версий. Система администрирования версий основана на управлении версиями объектов и предоставляет средства для полного управления конфигурацией системы. Для поддержки средств управления конфигурацией используется система администрирования объектов, поддерживающая систему базы данных и сервисы управления объектами. В свою очередь, в системе баз данных поддерживаются различные сервисы, например управления транзакциями, отката назад, восстановления и управления доступом. Для управления базами данных используются средства основной операционной системы и ее файловая система [1]. Рисунок 6.7 – Модель абстрактной машины для системы администрирования версий Рекомендации. 1. Когда разработка обеспечивается чередой команд, причем каждая команда создавала функциональность одного уровня. 2. когда новые 178 возможности создаются на базе существующих систем. 3. Когда требуется многоуровневая защищенность. Преимущества. 1. Позволяет замещать целые уровни (при условии сохранения интерфейса). 2. Для повышения надежности в каждый уровень можно добавить дополнительные возможности. Недостатки. 1. Трудно обеспечить ясное разделение уровней. Текущий уровень может взаимодействовать не с соседним нижним, а с более низкими уровнями. 2. Возможно понижение производительности, поскольку запрос услуги может последовательно обрабатываться на каждом уровне. 3. Изменение исходного кода влечет за собой переделку всех элементов системы, поскольку все элементы системы тесно связаны друг с другом [6, 64]. Логика приложения тесно связана с интерфейсом пользователя - затруднительно менять интерфейс или принципы реализации логики. Из-за высокой связанности, работу по реализации системы сложно разделить между разработчиками и, кроме того, сложно модифицировать функции приложения или переходить на новые технологии [64]. 6.4.4 Паттерн (модель) объектов Объектно-ориентированная модель основана на объектах (слабо сцепленных сущностях, имеющих собственные наборы данных, состояния, наборы операций) и их описания – классы. Данная модель используется на этапе детального проектирования, для декомпозиции системы. Описание. Система представляется состоящей из совокупности связанных между собой объектов. Объекты представляют сервисы (методы) другим объектам и создаются во время исполнения программы на основе 179 определения классов объектов. Объекты скрывают информацию о представлении состояний и, следовательно, ограничивают к ним доступ. Преимущества. Упрощается процесс модификации системы: можно изменять реализацию того или иного объекта, не воздействуя на другие объекты. Объектноориентированная система проще в понимании и модернизации. Данная система удобна для групповой разработки: работу по реализации системы легко разделить между разработчиками. Потенциально все объекты являются повторно используемыми компонентами, так как они независимо инкапсулируют данные о состоянии и операции. Архитектуру системы можно разрабатывать на базе объектов (структур объектов) уже созданных в предыдущих проектах. Недостатки. При использовании сервисов объекты должны явно ссылаться на имена других объектов и знать их интерфейс (это необходимо учесть если при изменении системы требуется изменить интерфейс) [64]. 6.4.5 Паттерн (модель) потоков данных (конвейер или фильтр) Модель также используется на этапе детального проектирования с целью декомпозиции. В основе модели потока данных лежит разбиение по функциям. При выборе этой модели получаем набор функций и определение связей между ними. В управляемой потоками данных модели данные проходят через последовательность преобразований. Каждый шаг обработки данных реализован в виде преобразования. Данные, поступающие на вход системы, проходят через все преобразования и достигают выхода системы. Преобразования могут выполняться 180 последовательно или параллельно. Обработка данных может быть пакетной или поэлементной. Если преобразования представлены в виде отдельных процессов, такую модель иногда называют конвейером или моделью фильтров, следуя терминологии, принятой в системе Unix. Последняя поддерживает конвейеры, которые действуют как хранилища данных, и набор команд, представляющих функциональные преобразования. Здесь используется термин «фильтр», поскольку преобразование «фильтрует» данные во время обработки потока данных [1]. Описание. Система состоит из функциональных модулей, которые получают на входе данные и преобразуют их некоторым образом в выходные данные (конвейерный подход). Каждый шаг обработки данных реализован в виде преобразования. Преобразования могут выполняться последовательно или параллельно, обработка данных может быть пакетной (пакетный последовательный паттерн) или поэлементной. Пример. Пример такого типа системной архитектуры показан на рис. 6.8. Здесь организация выписывает счета заказчикам. Раз в неделю платежные квитанции согласуются со счетами. Для оплаченных счетов выдается квитанция. По счетам, не оплаченным в течение установленного срока, выдается соответствующее уведомление. Данная модель представляет только часть системы обработки счетов – при выписке счетов используются другие преобразования [1]. Преимущества. Возможность повторного использования преобразований, простота в понимании, возможность модификации системы посредством добавления новых преобразований. Данный паттерн прост в реализации как для последовательных, так и для параллельных систем. 181 Рисунок 6.8 – Модель потоков данных для системы обработки счетов Недостатки. Необходимость использования некоего общего формата данных, который должен распознаваться всеми преобразованиями. Каждое преобразование либо следует согласовывать со смежными преобразованиями относительно формата преобразовываемых данных, либо необходимо использовать стандартный формат для всех обрабатываемых данных. Взаимодействующие подсистемы со сложными форматами ввода - вывода и большим количеством разнообразных событий достаточно сложно проектировать с использованием данного паттерна, поскольку трудно прогнозировать поток обрабатываемых данных [64]. Рекомендации. Выбор между объектноориентированной архитектурной моделью или моделью потока данных зависит от большого количества факторов, в том числе и от сложности разрабатываемой подсистемы. 6.5 Паттерны управления 6.5.1 Паттерны централизованного управления В модели централизованного управления одна из систем назначается главной и управляет работой других 182 подсистем. Такие модели можно разбить на два класса, в зависимости от того, последовательно или параллельно реализовано выполнение управляемых подсистем: модель вызова-возврата; модель диспетчера (менеджера). 6.5.1.1 Модель вызова-возврата Описание. Вызов программных процедур осуществляется «сверху – вниз», то есть управление начинается на вершине иерархии процедур и через вызовы передается на нижние уровни иерархии. Пример. Модель вызова-возврата представлена на рис. 6.9. Из главной программы можно вызвать подпрограммы 1, 2 и 3, из подпрограммы 1 – подпрограммы 1.1 и 1.2, из подпрограммы 3 – подпрограммы 3.1 и 3.2 и т.д. Такая модель выполнения подпрограмм не является структурной – подпрограмма 1.1 не обязательно является частью подпрограммы 1. Рисунок 6.9 – Модель вызова-возврата Управление переходит от программы, расположенной на самом верхнем уровне иерархии, к 183 подпрограмме более нижнего уровня. Затем происходит возврат управления в точку вызова подпрограммы. За управление отвечает та подпрограмма, которая выполняется в текущий момент; она может либо вызывать другие подпрограммы, либо вернуть управление вызвавшей ее подпрограмме. Несовершенство данного стиля программирования при возврате к определенной точке в программе очевидно [1]. Рекомендации. Применима только в последовательных системах, то есть в таких системах, в которых процессы должны происходить последовательно. Преимущества. Простой анализ потоков управления. Последовательные системы легче проектировать и тестировать. Недостатки. Сложно обрабатывать исключительные ситуации [6]. 6.5.1.2 Модель диспетчера (менеджера) Описание. Один системный компонент назначается диспетчером и управляет запуском и завершением других процессов системы и координирует эти процессы. Процессы могут протекать параллельно. Пример. На рис. 6.10 представлена модель централизованного управления для параллельной системы. Подобная модель часто используется в «мягких» системах реального времени, в которых нет чересчур строгих временных ограничений. Центральный контроллер управляет выполнением множества процессов, связанных с датчиками и исполнительными механизмами. Контроллер системы, в зависимости от переменных состояния системы, определяет моменты запуска или завершения процессов. Он проверяет, генерируется ли в остальных процессах информация, для того чтобы затем 184 обработать ее или передать другим процессам на обработку. Обычно контроллер работает постоянно, проверяя датчики и другие процессы или отслеживая изменения состояния, поэтому данную модель иногда называют моделью с обратной связью [1]. Рисунок 6.10 – Модель централизованного управления для системы реального времени Рекомендации. Применяется в системах, в которых необходимо организовать параллельные процессы, но может использоваться также и для последовательных систем, в которы- управляющая программа вызывает отдельные подсистемы в зависимости от значений некоторых переменных состояния. Преимущества. Можно использовать в системах реального времени, где нет чересчур строгих временных ограничений (в так называемых «мягких» системах реального времени). Недостатки. Малая скорость реакции на внешние события [6]. 185 6.5.2 Паттерны управления, основанные на событиях В моделях централизованного управления, как правило, управление системой определяется значениями некоторых переменных ее состояния. В противоположность таким моделям существуют системы, управление которыми основано на внешних событиях. В данном контексте под событием подразумевается не только бинарный сигнал типа «да-нет». Здесь сигнал может принимать некоторый диапазон значений. Различие между событием и обычными входными данными заключается в том, что планирование события выходит за рамки управления процессом, обрабатывающим это событие. Для обработки события подсистеме необходим доступ к информации состояния, однако такая информация обычно не определяется потоком управления. Разработано множество различных типов событийноуправляемых систем. К ним относятся электронные таблицы, в которых изменение значения в какой-либо ячейке изменяет содержимое других ячеек, системы искусственного интеллекта, в которых при выполнении некоторого условия происходит инициирование действия либо используются активные объекты, тогда при изменении значения свойства объекта инициируется некоторое действие. В этом разделе описаны две модели систем, управляемых событиями [1]: модели передачи сообщений; модели, управляемые прерываниями. 6.5.2.1 Передача сообщений (широковещательное управление) Описание. В рамках данного паттерна событие представляет собой передачу сообщения всем подсистемам. Любая подсистема, которая обрабатывает данное событие, отвечает на него. 186 Пример. В модели передачи сообщений на рисунке 6. 11 подсистемы реагируют на определенные события. Если произошло некоторое событие, управление переходит к подсистеме, обрабатывающей данное событие. Между моделью передачи сообщений и моделью централизованного управления, показанной на рис.6.11, существует отличие: алгоритм управления не встроен в обработчик сообщений и событий. Подсистемы определяют, какие события им требуются, а обработчик сообщений и событий следит, чтобы данные события были отправлены именно им [1]. Рисунок 6.11 – Модель управления, основанная на передаче сообщений Все события могут генерировать сообщения всем подсистемам, но при этом значительно увеличивается нагрузка при обработке данных. Часто обработчик событий и сообщений управляет регистром подсистем и событиями, на которые они реагируют. Подсистемы генерируют события, в которых, возможно, есть данные для обработки. Обработчик регистрирует событие, принимая во внимание его регистр, и передает это событие в те подсистемы, которые на него реагируют. Обработчик события всегда поддерживает двухточечное взаимодействие. Поэтому подсистемы могут явно отправить сообщение другой подсистеме. 187 Рекомендации. Данный подход эффективен при сетевой интеграции подсистем, распределенных на разных компьютерах. Преимущества. Простота изменения системы, легкость ее размещения. Новую подсистему можно интегрировать в систему, регистрируя ее события в обработчике событий. Каждая подсистема может активизировать любую другую подсистему, не зная ее имени или размещения. Подсистемы также можно реализовать на разных машинах [1]. Недостатки. Неизвестность появления события: генерируя событие, подсистема не знает, какая именно система прореагирует на него. Вполне допустима ситуация, когда разные подсистемы реагируют на одинаковые события. Это может привести к конфликтам при получении доступа к результатам обработки события. [1]. 6.5.2.2 Управляемый прерываниями Описание. При использовании данного паттерна внешние прерывания регистрируются обработчиком прерываний, а обрабатываются другим системным компонентом. Пример. На рис. 6.12 показана модель управления, основанная на прерываниях. Для каждого типа прерываний существует свой обработчик. Каждый тип прерывания ассоциируется с ячейкой памяти, в которой хранится адрес обработчика прерывания. При получении определенного прерывания аппаратный переключатель немедленно передает управление обработчику прерывания. В ответ на событие, вызванное прерыванием, обработчик может запустить или завершить другие процессы [1]. 188 Рисунок 6.12 – Модель управления, основанная на прерываниях Данная модель используется только в жестких системах реального времени, где требуется немедленная реакция на определенные события. Можно скомбинировать эту модель с моделью централизованного управления. Центральный диспетчер обрабатывает нормальный ход выполнения системы, а в критических ситуациях используется управление, основанное на прерываниях. Рекомендации. Используются в системах реального времени со строгими временными требованиями. Данный паттерн может быть скомбинирован с паттерном Диспетчер: центральный диспетчер управляет нормальной работой системы, а в критических ситуациях используется управление, основанное на прерываниях. Преимущества. Достаточно быстрая реакция системы на происходящие события. 189 Недостатки. Система сложна в программировании и проверке. При тестировании системы затруднительно имитировать все прерывания. Число прерываний ограничено используемой аппаратурой (после достижения предела, связанного с аппаратными ограничениями, никакие другие прерывания не обрабатываются) [1-3]. 6.5.3 Паттерны взаимодействия с базой данных В своих работах Мартин Фаулер выделил паттерны проектирования источников данных [66, 70]. Все паттерны этой группы делятся на: – паттерны архитектуры источников данных: o row data gateway (шлюз к данным записи); o active record (активная запись); o table data gateway (шлюз к данным таблицы); o data mapper; – паттерны объектно-реляционной логики: o lazy load (ленивая загрузка); o identity map (карта присутствия / карта соответствия); o unit of work (единица работы); – паттерны объектно-реляционного структурирования: o identity field (поле первичного ключа); o foreign key mapping (разметка внешних ключей); o association table mapping (разметка таблиц связей); o dependent mapping (управление распределением подчинённых сущностей); o embedded value (объединённое свойство); o serialized lob (сериализованный lob); 190 single table inheritance (наследование с единой таблицей); o class table inheritance (наследование с таблицами классов); o concrete table inheritance (наследование с таблицами конечных классов); o inherritance mappers (наследуемые распределители); – паттерны логики сущности: o transaction script (сценнарий транзакции); o domain model (модель области определения); o table module (обработчик таблицы); o service layer (сервисный уровень); – паттерны обработки объектно-реляционных метаданных: o metadata mapping (распределение на основе метаданных); o query object (объект-запрос); o repository (репозиторий); – паттерны распределения данных: o remote facade (парадный вход); o data transfer object (объект передачи данных); – паттерны локальной конкуренции: o optimistic offline lock (оптимистичная блокировка); o pessimistic offline lock (пессимистичная блокировка); o coarse grained lock (грубая блокировка); o implicit lock (скрытая блокировка); o На рисунке 6.13 приведена наглядная схема этой классификации. 191 Рисунок 6.13 –Класисфикация паттернов проектирования источников данных 192 6.5.4 Паттерны для представления данных в Веб Одно из изменений, происшедших с корпоративными приложениями за последние несколько лет, связано с появлением пользовательских интерфейсовв стиле Webобозревателей. Они принесли с собой ряд преимуществ: исключили потребность в применении специального клиентского программного слоя, обобщили и унифицировали процедуры доступа и упростили проблему конструирования Web-приложений. Проектирование таких систем также может быть основано на паттернах. К паттернам, предназначенным для представления данных в Веб, относятся [66, 67, 70]: – модель-представление-контроллер (Model View Controller (MVC)); – контроллер страниц (Page Controller); – контроллер запросов (Front Controller); – представление по шаблону (Template View); – представление с преобразованием (Transform View); – двухэтапное представление (Two Step View); – контроллер приложения (Application Controller). Рассмотрим некоторые из них. 6.5.4.1 Паттерн модель-представление-контроллер Типовое решение модель-представление-контроллер подразумевает выделение трех отдельных ролей, показанных на рисунке 6.14. Модель – это объект, предоставляющий некоторую информацию о домене. У модели нет визуального интерфейса, она содержит в себе все данные и поведение, не связанные с пользовательским интерфейсом. В объектно-ориентированном контексте наиболее «чистой» формой модели является объект модели 193 предметной области. В качестве модели можно рассматривать и сценарий транзакции, если он не содержит в себе никакой логики, связанной с пользовательским интерфейсом. Подобное определение не очень расширяет понятие модели, однако полностью соответствует распределению ролей в рассматриваемом типовом решении. Рисунок 6.14 – Паттерн модель-представление-контроллер (MVC) Представление отображает содержимое модели средствами графического интерфейса. Таким образом, если модель – это объект покупателя, соответствующее представление может быть фреймом с кучей элементов управления или HTML-страницей, заполненной информацией о покупателе. Функции представления заключаются только в отображении информации на экране. Все изменения информации обрабатываются третьим «участником» системы – контроллером. 194 Контроллер получает входные данные от пользователя, выполняет операции над моделью и указывает представлению на необходимость соответствующего обновления. В этом плане графический интерфейс можно рассматривать как совокупность представления и контроллера. Говоря о типовом решении модель-представлениеконтроллер, нельзя не подчеркнуть два принципиальных типа разделения: отделение представления от модели и отделение контроллера от представления. Отделение представления от модели – это один из фундаментальных принципов проектирования программного обеспечения. Наличие подобного разделения весьма важно по ряду причин: – представление и модель относятся к совершенно разным сферам программирования. – пользователи хотят, чтобы, в зависимости от ситуации, одна и та же информация могла быть отображена разными способами. – объекты, не имеющие визуального интерфейса, гораздо легче тестировать, чем объекты с интерфейсом. Ключевым моментом в отделении представления от модели является направление зависимостей: представление зависит от модели, но модель не зависит от представления. Это означает, что изменение представления не требует изменения модели. Отделение контроллера от представления. Классическим примером необходимости подобного разделения является поддержка редактируемого и нередактируемого поведения. Этого можно достичь при наличии одного представления и двух контроллеров (для двух вариантов использования), где контроллеры являются стратегиями, используемыми представлением. Между тем на практике в большинстве систем каждому 195 представлению соответствует только один контроллер, поэтому разделение между ними не проводится. О данном решении вспомнили только при появлении Webинтерфейсов, где отделение контроллера от представления оказалось чрезвычайно полезным. 6.5.4.2 Паттерн контроллер страниц В основе контроллера страниц лежит идея создания компонентов, которые будут выполнять роль контроллеров для каждой страницы Веб-сайта, рисунок 6.15. Рисунок 6.15 – Паттерн контроллер страниц (Page Controller) На практике количество контроллеров не всегда в точности соответствует количеству страниц, поскольку иногда при щелчке на ссылке открываются страницы с разным динамическим содержимым. Если говорить более точно, контроллер необходим для каждого действия, под которым подразумевается щелчок на кнопке или гиперссылке. 196 Контроллер страниц может быть реализован в виде сценария (сценария CGI, сервлета и т.п.) или страницы сервера (ASP, PHP, JSP и т.п.). Использование страницы сервера обычно предполагает сочетание в одном файле контроллера страниц и представления по шаблону. Это хорошо для представления по шаблону, но не очень подходит для контроллера страниц, поскольку значительно затрудняет правильное структурирование этого компонента. Данная проблема не столь важна, если страница применяется только для простого отображения информации. Тем не менее, если использование страницы предполагает наличие логики, связанной с извлечением пользовательских данных или выбором представления для отображения результатов, страница сервера может заполниться кодом «скриптлета», т.е. внедренного сценария. Чтобы избежать подобных проблем, можно воспользоваться вспомогательным объектом (helper object). При получении запроса страница сервера вызывает вспомогательный объект для обработки всей имеющейся логики. В зависимости от ситуации, вспомогательный объект может вернуть управление первоначальной странице сервера или же обратиться к другой странице сервера, чтобы она выступила в качестве представления. В этом случае обработчиком запросов является страница сервера, однако большая часть логики контроллера заключена во вспомогательном объекте. Возможной альтернативой описанному подходу является реализация обработчика и контроллера в виде сценария. В этом случае при поступлении запроса Вебсервер передает управление сценарию; сценарий выполняет все действия, возложенные на контроллер, после чего отображает полученные результаты с помощью нужного представления. 197 Ниже перечислены основные обязанности контроллера страниц: – проанализировать адрес URL и извлечь данные, введенные пользователем в соответствующие формы, чтобы собрать все сведения, необходимые для выполнения действия. – создать объекты модели и вызвать их методы, необходимые для обработки данных. – определить представление, которое должно быть использовано для отображения результатов, и передать ему необходимую информацию, полученную от модели. Контроллер страниц не обязательно должен представлять собой единственный класс, зато все классы контроллеров могут использовать одни и те же вспомогательные объекты. Это особенно удобно, если на Веб-сервере должно быть несколько обработчиков, выполняющих аналогичные задания. В этом случае использование вспомогательного объекта позволяет избежать дублирования кода. При необходимости одни адреса URL можно обрабатывать с помощью страниц сервера, а другие – с помощью сценариев. Те адреса URL, у которых нет или почти нет логики контроллера, хорошо обрабатывать с помощью страниц сервера, потому что последние представляют собой простой механизм, удобный для понимания и внесения изменений. Все остальные адреса, для обработки которых необходима более сложная логика, требуют применения сценариев. 6.5.4.1 Паттерн контроллер запросов Контроллер запросов обрабатывает все запросы, поступающие к Веб-сайту, и обычно состоит из двух частей: Веб-обработчика и иерархии команд, как показано 198 на рисунке 6.16. Веб-обработчик – это объект, который выполняет фактическое получение POST- или GETзапросов, поступивших на Веб-сервер. Он извлекает необходимую информацию из адреса URL и входных данных запроса, после чего решает, какое действие необходимо инициировать, и делегирует его выполнение соответствующей команде. Рисунок 6.16 – Паттерн контроллер запросов (Front Controller) Веб-обработчик обычно реализуется в виде класса, а не страницы сервера, поскольку он не генерирует никаких откликов. Команды также являются классами, а не страницами сервера; более того, им не нужно знать о наличии Веб-окружения, несмотря на то, что им часто передается информация из HTTP-запросов. В большинстве случаев Веб-обработчик – это довольно простая программа, функции которой заключаются в выборе нужной команды. Выбор команды может происходить статически или динамически. Статический выбор команды подразумевает проведение синтаксического анализа адреса URL и 199 применение условной логики, а динамический – извлечение некоторого стандартного фрагмента адреса URL и динамическое создание экземпляра класса команды. Преимущества статического выбора команды состоят в использовании явного кода, наличии проверки времени компиляции и высокой гибкости возможных вариантов написания адресов URL. В свою очередь, использование динамического подходапозволяет добавлять новые команды, не требуя изменения Вебобработчика. При динамическом выборе команд имя класса команды можно поместить непосредственно в адрес URL либо воспользоваться файлом свойств, который будет привязывать адреса URL к именам классов команд. Разумеется, это потребует создания дополнительного файла свойств, однако позволит легко и непринужденно изменять имена классов, не просматривая все имеющиеся на сервере Веб-страницы. 6.5.4.1 Паттерн представления по шаблону Основная идея, лежащая в основе типового решения представление по шаблону, – вставка маркеров в текст готовой статической HTML-страницы. При вызове страницы для обслуживания запроса эти маркеры будут заменены результатами некоторых вычислений (например, результатами выполнения запросов к базе данных). Подобная схема позволяет создавать статическую часть страницы с помощью обычных средств, например текстовых редакторов, работающих по принципу WYSIWYG, и не требует знания языков программирования. Для получения динамической информации маркеры обращаются к отдельным программам. Пример паттерна показан на рисунке 6.17. 200 Рисунок 6.17 – Паттерн представления по шаблону (Template View) Представление по шаблону используется целым рядом программных средств. Таким образом, задача состоит не столько в том, чтобы разработать данное решение самому, сколько в том, чтобы научиться его эффективно использовать и познакомиться с возможными альтернативами. 6.6 Архитектурные Microsoft концепции и методики Крупные компании-поставщики инфраструктурных информационных технологий, такие как Microsoft, IBM, SAP и другие могут позволить себе создания собственных методик разработки архитектуры информационных систем предприятия – конечно, с учетом своей области специализации. Взгляды компании Microsoft на архитектуру информационных систем достаточно подробно изложены в [75]. Эти подходы в большей степени сфокусированы на процессах разработки конкретных программных прикладных систем и создании технологической инфраструктуры, включая центры обработки данных различного масштаба и уровня надежности. Как 201 практически и во всех других методиках, здесь выделяются четыре представления (домена) в архитектуре: – бизнес-архитектура, – архитектура информации, – прикладные системы, – технологическая архитектура. Эти представления рассматриваются на различных уровнях абстракции: концептуальном, логическом и физическом. Помимо этого, явно выделяются процессы разработки прикладных систем, организация процессов эксплуатации технологической инфраструктуры и создание соответствующих шаблонов, которые могут использоваться как при разработке архитектуры систем, так и при ее создании [74-75]. При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы разработки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как: – Microsoft Solutions Framework (MSF), – Microsoft Operations Framework (MOF), – Microsoft Systems Architecture (MSA) – MicrosoftSolutions for Management (MSM) Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов: MSF – "Как правильно создавать ИТ-системы?" MSA – "Как правильно создавать технологическую инфраструктуру?" MOF – "Как правильно эксплуатировать технологическую инфраструктуру?" MSM – "Как правильно строить процессы управления технологической инфраструктурой?" 202 Методики MSF и MSA в большей степени относятся к процессу разработки архитектуры прикладных систем и инфраструктуры соответственно, а методики MOF и MSM – к архитектуре системного управления, т.е. вопросам управления и эксплуатации. При этом MOF и MSF нацелены на различные, но связанные между собой фазы жизненного цикла ИТрешений так, как показано на рис. 6.18. Рисунок 6.18 – Взаимодействие MSF и MOF для удовлетворения запросов бизнеса Заметим, что методики Microsoft сосредоточены, в основном, на системном уровне – уровне архитектуры прикладных систем и обеспечивающей инфраструктуры. 203 Поэтому в этой более "узкой" области полезными являются приведенные соотношения между различными перспективами описания системы и моделями, используемыми для описания на соответствующем уровне абстракции так, как показано на рисунке 6.19 [74-75]. Рисунок 6.19 – Различные перспективы архитектуры системы и используемые модели То есть в идеале для каждой перспективы используется какой-то один тип моделей так, как это показано на рисунке 6.18. Но в реальности могут использоваться и несколько различных моделей для 204 описания каждой из перспектив, т.е. концептуальной, логической и физической архитектур системы. Рисунок 6.20 показывает взаимосвязи между различными перспективами в описании архитектуры, используемыми шаблонами проектирования, а также примерно отображает соответствие между методиками Microsoft и соответствующими элементами архитектуры. Microsoft выделяет два типа руководств и обеспечивающих методик, которые могут помочь системным архитекторам ускорить процессы разработки моделей при минимизации рисков. Первый тип руководств – это архитектурные концепции, такие, например, как сервис-ориентированные подходы к проектированию архитектуры. Эти концепции обеспечивают следующее: общее понимание и язык описания архитектуры; общие руководства, рекомендации по использованию специфических концепций; указания на то, как эти концепции могут быть реализованы на практике в форме конкретных технологий и стандартов. Второй набор руководств, которыми могут пользоваться системные архитекторы – это архитектурные шаблоны, о которых уже шла речь в лекциях 5-7 и которые основаны на практическом опыте большого количества успешно реализованных проектов создания распределенных прикладных систем; они явились следствием использования описанных выше архитектурных концепций. Эти шаблоны содержат в себе лучшие практики проектирования распределенных приложений и средства по минимизации рисков неудач проектов, поскольку рекомендуют хорошо апробированные модели (см. рис. 6.21). 205 Рисунок 6.20 – Архитектурные перспективы, шаблоны и методики Microsoft 206 Эти два типа руководств – архитектурные концепции и шаблоны – могут присутствовать и использоваться на различных уровнях проектирования архитектуры прикладной системы (рисунок 6.20): на уровне концептуальной архитектуры в форме концепций построения бизнес-моделей и соответствующих шаблонов; на уровне логической архитектуры в форме концепций построения моделей приложений и соответствующих шаблонов; на уровне физической архитектуры в форме концепций построения технологических моделей и соответствующих шаблонов. Знание и использование этих концепций и шаблонов является важным условием успешного, быстрого и эффективного с точки зрения затрат создания систем и использования информационных технологий организациями. Поэтому помимо методик MSF, MOF, MSA и MSM компанией опубликованы в открытом доступе подробные руководства по разработке архитектуры систем [73-76]. Корпорация Microsoft при построении любых информационных систем (не только с использованием архитектур, платформ и продуктов Microsoft) рекомендует применять методику разработки приложений, получившую название Microsoft Solutions Framework (MSF), описанную в разделе 4.3. Одно из важных достоинств методологии MSF, которая во многом опирается на представления о современной программной архитектуре, состоит в том, что в результате следования дисциплине, принципам и методам, заложенным в ее основу, решения получаются комплексными, интеграционными, работоспособными, с ясно определенными приоритетами. 207 Рисунок 6.21 – Концепции и шаблоны по построению архитектуры приложений 208 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Контрольные вопросы Какие особенности имеет этап проектирования? Решение каких задач обеспечивает архитектурное проектирование? Какова связь архитектурного и детального проектирования? Что является результатом архитектурного проектирования? Что такое архитектура программного обеспечения? Какова классификация архитектурных стилей с точки зрения М Шоу и Д Гарлана? Перечислить типы моделей управления? Какие существуют разновидности моделей централизованного управления? Поясните разновидности моделей событийного управления. Объясните, почему архитектуру системы необходимо разработать до окончания создания спецификации. Предложите подходящую структурную модель для системы видеоконференций, управляемой компьютером, с возможностью одновременного просмотра компьютерных, аудио- и видеоданных несколькими участниками. Обоснуйте свой выбор. Объясните, почему модель управления вызовавозврата обычно не подходит для систем реального времени, управляющих определенным процессом. Предложите подходящую модель управления для набора инструментальных программных средств от разных производителей, которые должны работать совместно. Обоснуйте свой выбор. Какие паттерны используются для представления данных в Веб? 209 РАЗДЕЛ 7. СРЕДСТВА АВТОМАТИЗАЦИИ РАЗРАБОТКИ ПРОГРАММНЫХ ПРОДУКТОВ 7.1 Понятие CASE-средства Большие размеры и высокая сложность разрабатываемых ПС при ограничениях на бюджетные и временные затраты проекта могут привести к низкому качеству конечных программных продуктов и системы в целом. В этой связи в последнее время все большее внимание уделяется современным технологиям и инструментальным средствам, обеспечивающим автоматизацию процессов ЖЦ ПС (CASE-средствам). Средства автоматизации разработки программ – инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки программного обеспечения. CASE (англ. Computer-Aided Software Engineering) – набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASEинструментов [17]. Международный стандарт ISO/IEC 14102:1995 (ДСТУ 3919-99 Інформаційні технології. Основні напрямки оцінювання та відбору CASE-інструментів) [77] определяет CASE-средства – как программное средство, поддерживающее процессы жизненного цикла программного обеспечения, включая анализ требований к системе, проектирование прикладного ПО и баз данных, 210 генерацию кода, тестирование, документирование, обеспечение качества, управление конфигурацией ПО и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют среду разработки ПО. CASE-средства характеризуются наличием мощных средств визуального моделирования. Современный рынок программных средств насчитывает около 300 различных CASE-средств. Особенности средств автоматизации разработки программ: поддерживают единственную методологию; ориентируются на определенную технологию; предназначаются для команд, работающих над единственным проектом; используются для разработки информационных систем; разрабатываются одной компанией. Возможность интеграции инструментов других компаний отсутствует. 7.2 История развития CASE-средств В истории развития CASE-средств обычно выделяется шесть периодов. Данные периоды различаются применяемой техникой и методами разработки ПС. Эти периоды используют в качестве инструментальных средств следующие средства [8, 78]. Период 1. Ассемблеры, анализаторы. Период 2. Компиляторы, интерпретаторы, трассировщики. Период 3. Символические отладчики, пакеты программ. Период 4. Системы анализа и управления исходными текстами. 211 Период 5. Первое поколение CASE (CASE-I). Это CASE-средства, позволяющие выполнять поддержку начальных работ процесса разработки ПС и систем (анализ требований к системе, проектирование архитектуры системы, анализ требований к программным средствам, проектирование программной архитектуры, логическое проектирование баз данных). Адресованы непосредственно системным аналитикам, проектировщикам, специалистам в предметной области. Поддерживают графические модели, экранные редакторы, словари данных. Не предназначены для поддержки полного ЖЦ ПС. Период 6. Второе поколение CASE (CASE-II). Представляют собой, как правило, набор (линейку) инструментальных средств, каждое их которых предназначено для поддержки отдельных этапов процесса разработки или других процессов ЖЦ ПС. В совокупности обычно поддерживают практически полный ЖЦ ПС. Используют средства моделирования предметной области, графического представления требований, поддержки автоматической кодогенерации ПС. Содержат средства контроля и управления разработкой, интеграции системной информации, оценки качества результатов разработки. Поддерживают моделирование и прототипирование системы, тестирование, верификацию, анализ сгенерированных программ, генерацию документации по проекту. Первоначально термин CASE трактовался как Computer Aided Software Engineering (компьютерная поддержка проектирования ПО). В настоящее время данному термину придается более широкий смысл, и он расшифровывается как Computer Aided System Engineering (компьютерная поддержка проектирования систем). С учетом выше изложенного введено понятие CASEтехнологии. 212 CASE-технология – это совокупность методологий разработки и сопровождения сложных систем (в том числе ПС), поддерживаемая комплексом взаимосвязанных средств автоматизации. Основные цели использования CASE-технологий при разработке ПС – отделить анализ и проектирование от программирования и последующих работ процесса разработки, предоставив разработчику соответствующие методологии визуального анализа и проектирования [8, 78]. 7.3 Базовые принципы построения CASE-средств Большинство CASE-средств основано на парадигме метод – нотация – средство [8, 78]. Парадигма – это система изменяющихся форм некоторого понятия. В данном случае метод реализуется с помощью нотаций. Метод и нотации поддерживаются инструментальными средствами. Метод – это систематическая процедура или техника генерации описаний компонент ПС. Нотация – это система обозначений, предназначенная для описания структуры системы, элементов данных, этапов обработки; может включать графы, диаграммы, таблицы, схемы алгоритмов, формальные и естественные языки. Средства – это инструментарий для поддержки методов, помогающий пользователям при создании и редактировании графического проекта в интерактивном режиме, способствующий организации проекта в виде иерархии уровней абстракции, выполняющий проверки соответствия компонентов. Фактически CASE-средство – это совокупность графически ориентированных инструментальных средств, 213 поддерживающих процессы или отдельные этапы процессов ЖЦ ПС и систем. К CASE-средствам может быть отнесено любое программное средство, обеспечивающее автоматическую помощь при разработке ПС, их сопровождении или управлении проектом, базирующееся на следующих основополагающих принципах: 1. Графическая ориентация. В CASE-средствах используется мощная графика для описания и документирования систем или ПС и для улучшения интерфейса с пользователем. 2. Интеграция. CASE-средство обеспечивает легкость передачи данных между своими компонентами и другими средствами, входящими в состав линейки CASEсредств. Это позволяет поддерживать совокупность процессов ЖЦ ПС. 3. Локализация всей проектной информации в репозитории (компьютерном хранилище данных). Исполнителям проекта доступны соответствующие разделы репозитория в соответствии с их уровнем доступа. Это обеспечивает поддержку принципа коллективной работы. Информация из репозитория может использоваться для работ над текущим проектом, в том числе для автоматической кодогенерации ПС или систем, разработки следующих проектов, сбора статистики по выполненным ранее проектам организации. Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты [79]: репозиторий, являющийся основой CASEсредства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при 214 групповой разработке, контроль метаданных на полноту и непротиворечивость; графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС; средства разработки приложений, включая языки 4GL и генераторы кодов; средства конфигурационного управления; средства документирования; средства тестирования; средства управления проектом; средства реинжиниринга. 7.4 Классификация CASE-средств На сегодняшний день возможны варианты классификаций CASE-средств по различным признакам: 1. По типам (по функциональному назначению): анализ и проектирование; проектирование баз данных и файлов; программирование и тестирование; сопровождение и реинженерия; окружение; управление проектом. 2. По степени интегрированности: tools (отдельные локальные средства); toolkits (набор интегрированных средств, охватывающих большинство этапов разработки ЭИС); workbench (полностью интегрированные средства, связанные общей базой проектных данных – репозиторием). 215 3. По поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные; объектно-ориентированные; комплексно-ориентированные. 4. По области действия: верхние (Upper) CASE (средствами компьютерного планирования); средние (Middle) CASE считаются средствами поддержки этапов анализа требований и проектирования спецификаций и структуры ПО; нижние (Lower) CASE являются средствами разработки ПО. 5. По поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией; с отдельными нотациями; с наиболее распространёнными нотациями. 6. По типу и архитектуре вычислительной техники: ориентированные на отдельные компьютеры; ориентированные на локальную вычислительную сеть; ориентированные на глобальную вычислительную сеть; смешанного типа. 7. По режиму коллективной разработки проекта: не поддерживающие коллективную разработку; ориентированные на режим реального времени разработки проекта; ориентированные на режим объединения подпроектов; 8. По типу операционной системы. Рассмотрим наиболее известные. 216 7.4.1 Классификация по типам Данная классификация отражает функциональное назначение CASE-средства в ЖЦ ПС и систем. 1. Анализ и проектирование Средства этого типа используются для поддержки начальных этапов процесса разработки: анализа предметной области, разработки требований к системе, проектирования системной архитектуры, разработки требований к программным средствам, проектирования программной архитектуры, технического проектирования программных средств. На выходе генерируются спецификации системы, ее компонентов и интерфейсов, связывающих эти компоненты, архитектура системы, архитектура программного средства, технический проект программного средства, включая алгоритмы и определения структур данных. 2. Проектирование баз данных и файлов Средства этого типа обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в третью нормальную форму, автоматическую генерацию схем баз данных и описаний форматов файлов на уровне программного кода. 3. Программирование и тестирование Средства этого типа поддерживают программирование и тестирование. Данные средства выполняют автоматическую кодогенерацию ПС на основе спецификаций или моделей. Содержат графические редакторы, средства поддержки работы с репозиторием, генераторы и анализаторы кодов, генераторы тестов, анализаторы покрытия тестами, отладчики. 4. Сопровождение и реинженерия Общей целью средств этого типа является поддержка корректировки, изменения, преобразования, реинженерия 217 существующей системы, поддержка документации по проекту. К данным средствам относятся средства документирования, анализаторы программ, средства управления изменениями и конфигурацией ПС и систем, средства реструктурирования и реинженерии. Реинженеринг (reverse engineering) – обратное проектирование. 5. Окружение К средствам данного типа относятся средства поддержки интеграции CASE-средств и данных. 6. Управление проектом К средствам данного типа относятся средства поддержки процесса управления ЖЦ ПС и систем. Их функциями являются планирование, контроль, руководство, организация взаимодействия и т.п. 7.4.2 Классификация по категориям Классификация по категориям определяет уровень интегрированности по выполняемым функциям и включает: 1. Вспомогательные программы (tools). Категория tools обозначает вспомогательный пакет, решающий небольшую автономную задачу, принадлежащую проблеме более широкого масштаба. 2. Пакеты разработчика (toolkit). Категория toolkit представляет совокупность интегрированных программных средств, обеспечивающих помощь для одного из классов программных задач; использует репозитарий для всей технической и управляющей информации о проекте, концентрируясь при этом на поддержке, как правило, одной фазы или одного этапа разработки ПО. 218 3. Инструментальные средства (workbench). Категория workbench представляет собой интеграцию программных средств, которые поддерживают системный анализ, проектирование и разработку ПО; используют репозитарий, содержащий всю техническую и управляющую информацию о проекте; обеспечивают автоматическую передачу системной информации между разработчиками и этапами разработки; организуют поддержку практически полного ЖЦ (от анализа требований и проектирования ПО до получения документированной выполняемой программы). Workbench, по сравнению с toolkit, обладает более высокой степенью интеграции выполняемых функций, большей самостоятельностью и автономностью использования, а также наличием тесной связи с системными и техническими средствами аппаратновычислительной среды, на которой workbench функционирует. Адаптированная под современное состояние выше описанная классификация CASE-систем содержит 3 класса [80]: 1. «Tools» – инструменты, поддерживающие только определенные задачи в про- цессах ЖЦ ПО и ОЭС; 2. «Workbenches» – рабочие приложения, поддерживающие только определенный вид деятельности. Они могут включать в себя системы класса «Tools» или иметь самостоя- тельную сложную модульную структуру; 3. «Environments» – программные среды, поддерживающие все (или большую часть) процессов ЖЦ ПО и организационно-управляющих систем. Могут включать в себя системы классов «Tools», «Workbenches». Общая схема показана на рисунке 7.1. 219 Рисунок 7.1 –Классификация CASE-систем 220 7.4.3 Классификация по методологии проектирования Выбор CASE-средства во многом зависит от конкретного подхода к проектированию ИС. Важнейшими из подходов являются: структурный (функциональный), объектно-ориентированный, комплексно-ориентированный (методология ARIS). Сущность структурного подхода к разработке ИС заключается в ее декомпозиции на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. В рамках этого подхода используются методологии: функционального моделирования IDEF0; структурного анализа потоков данных DFD; информационного моделирования IDEF1X; ориентированные на данные (Метод JSD Джексона, Диаграммы Варнье–Орра). Для их реализации на сегодняшний момент широкое распространение получили: CA ERwin Process Modeler (ранее: BPwin), CA ERwin Data Modeler (ранее: ERwin), Vantage Team Builder, Oracle Designer. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщений между объектами. Для описания данного подхода широко используется унифицированный язык моделирования UML – Unified Modeling Language. 221 Язык UML – это унифицированный язык визуального моделирования, позволяющий разрабатывать концептуальные, логические и физические модели сложных систем. Он предназначен для визуализации, анализа, спецификации, проектирования и документирования предметных областей, сложных систем вообще и ПС в частности. Язык UML основан на принципах абстрагирования, инкапсуляции, модульности, иерархии, многомодельности. Основными понятиями языка UML являются понятия объекта, связи, агрегации, класса. Между классами существует четыре основных вида отношений: ассоциация, зависимость, обобщение, агрегация (целое-часть). Для моделирования различных аспектов предметной области или проектируемой системы в языке UML предусмотрены следующие виды диаграмм: диаграммы вариантов использования, классов, состояний, деятельности, последовательности, кооперации, компонентов, развертывания. Все модели языка UML подразделяются на два вида: структурные модели и модели поведения. Модели языка UML подразделяются на три уровня: концептуальные модели, логические модели, физические модели. Средства, отвечающие объектно-ориентированному подходу: IBM Rational Rose Enterprise, Sybase PowerDesigner, Rational Rose; Borland Together; Microsoft Visio; Sparx Systems Enterprise Architect; Gentleware Poseidon; SmartDraw; Dia; Telelogic TAU G2; StarUML и др. Методология ARIS определяет принципы моделирования различных аспектов деятельности организаций, основывается на концепции интеграции, предлагающей целостный взгляд на бизнес-процессы, и представляет собой множество различных методологий, интегрированных в рамках единого системного подхода. 222 Контрольные вопросы 1. Перечислите периоды развития CASE-средств. 2. Дайте сравнительную оценку трудозатрат по этапам разработки при различных подходах к процессу разработки ПС. 3. Какое программное средство называется CASEсредством? 4. Перечислите основополагающие принципы, на которых базируются CASE-средства. 5. Какие положения лежат в основе концептуального построения CASE-средств? 6. Перечислите и охарактеризуйте основные компоненты CASE-средств. 7. Какие типы контроля реализуются обычно в CASE-средствах? 8. Перечислите свойства современных CASEсредств, обеспечивающие поддержку процесса разработки программных продуктов. 9. По каким критериям подразделяются средства кодогенерации? 10. Что отражает классификация CASE-средств по типам? 11. Перечислите и охарактеризуйте типы CASEсредств. 12. Что отражает классификация CASE-средств по категориям? 13. Перечислите и охарактеризуйте категории CASE-средств. 14. Что отражает классификация CASE-средств по уровням? 15. Перечислите и охарактеризуйте уровни CASEсредств. 223 БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1. Соммервилл И. Инженерия программного обеспечения, 6-е издание.: Пер. с англ. – М.: Издательский дом «Вильямс», 2002. – 624 с. 2. Гордеев А. В. Операционные системы: учебник для вузов / А. В. Гордеев. - 2-е изд. - СПб. : Питер, 2006. – 416 с. 3. Крылов Е.В. Техника разработки программ / Е.В.Крылов, В.А. Острейковский, Н.Г. Типикин. –М.: Высшая шк., 2008. – 469 с. 4. Васильев Ю. Введение в программные системы и их разработку. НОУ «ИНТУИТ» Режим доступа http://www.intuit.ru/studies/courses/3632/874/lecture/1429 7 5. Кулямин В. Компонентный подход в программировании НОУ «ИНТУИТ» Режим доступа http://www.intuit.ru/studies/courses/64/64/info 6. Орлов С. А. Технологии разработки программного обеспечения: Учебник для вузов. 4-е изд. Стандарт третьего поколения. / С. А. Орлов, Б. Я. Цилькер. – СПб.: Питер, 2012. – 608 с. 7. Минитаева А. М. Разработка и стандартизация программных средств и информационных технологий: учеб. пособие / А. М. Минитаева. – Омск: Изд-во ОмГТУ, 2011. – 92 с. 8. Бахтизин, В. В. Технология разработки программного обеспечения: учеб. пособие / В. В. Бахтизин, Л. А. Глухова. – Минск : БГУИР, 2010. – 267 с. 9. Фатрелл, Р. Управление программными проектами: достижение оптимального качества при минимуме затрат / Р. Фатрелл, Д. Шафер, Л. Шафер. М. : Вильямс, 2003. – 1136 с. 224 10. Брауде Э. Технология разработки программного обеспечения. – Спб.: Питер, 2004. – 655 с. 11. Гагарина Л. Г. Технология разработки программного обеспечения : учебное пособие / Л. Г. Гагарина, Е. В. Кокорева, Б. Д. Виснадул. - М. : ИД «ФОРУМ»: ИНФРА. - М., 2008. – 400 с. 12. Технология разработки программных продуктов. Практикум: учеб. пособие для студ. учреждений сред. проф. образования / А. В.Рудаков, Г. Н. Федорова. – 4-е изд., стер. - М. : Издательский центр «Академия»; 2014. – 192 с. 13. Технології програмування та створення програмних продуктів: конспект лекцій /укладач О.В.Алексенко. – Суми : Сумський державний університет, 2013. – 133 с. Режим доступу: http://essuir.sumdu.edu.ua/bitstream/123456789/30254/1/A lekseenko_Programuvannja.pdf 14. Про стандартизацію: Верховна Рада України; Закон від 05.06.2014 № 1315-VII 15. Метрологія, стандартизація та управління якістю/ Л.П. Клименко, Л.В. Пізінцалі, Н.І. Александровська, В.Д. Євдокимов – Миколаїв : Вид-во ЧДУ ім. Петра Могили, 2011 Электронный ресурс: http://buklib.net/books/35966/ 16. Осипенко Н. Б. Основы стандартизации и сертификации программного обеспечения: общие положения о стандартах и жизненный цикл программного обеспечения: / Н. Б. Осипенко, М–во образ. РБ, Гомельский гос. ун-т им. Ф. Скорины. – Гомель: ГГУ им. Ф. Скорины, 2014. – 45 с. 17. Вікіпедія Режим доступа: uk.wikipedia.org 18. Systems and software engineering – Software Life Cycle Processes. ISO 12207:2008. – [Чинний від 2008-02-01] – II, 122 c.– (Міжнародний стандарт). 225 19. Виды, комплектность и обозначение документов при создании автоматизированных систем. ГОСТ 34.201-89. – [Чинний від 1990-01-01] – 8 c.– (Міждержавний стандарт). 20. Техническое задание на создание автоматизированной системы. ГОСТ 34.602-89 – [Чинний від 1990-01-01] – 12 c.– (Міждержавний стандарт). 21. Автоматизированные системы. Стадии создания. ГОСТ 34.601-90. – [Чинний від 1991-01-01] – 10 c.– (Міждержавний стандарт). 22. Бирюков А.Н. Процессы управления информационными технологиями НОУ «ИНТУИТ» Режим доступа: http://www.intuit.ru/studies/courses/2298/598/info 23. ДСТУ ISO/IEC TR 15271:2010 Інформаційні технології Настанови щодо застосування ISO/IEC 12207 (Процеси життєвого циклу програмного забезпечення) (ISO/IEC TR 15271:1998,IDT). 24. ДСТУ 3918-99 (ISO/IEC 12207:1995) Інформаційні технології. Процеси життєвого циклу програмного забезпечення .–К .: Держстандарт України, 2002. – 49 с. 25. Благодатских В.А. Стандартизация разработки программных средств: учеб. пособие / В.А. Благодатских, В.А. Волнин, К.Ф. Поскакалов. – М.: Финансы и статистика, 2003. – 288 с. 26. Ушакова І.О. Основи системного аналізу об’єктів і процесів комп’ютеризації: навчальний посібник для студентів напряму «Комп’ютерні науки» / І. О. Ушакова. – Харків: Вид. ХНЕУ, 2008. – 308 с. 27. ISO/IEC 15288 Systems and software engineering - System life cycle processes. – [Чинний від 2008-03-18] – 70 c.– (Міжнародний стандарт). 28. ДСТУ ISO/IEC 15288:2005 Інженерія систем. Процеси життєвого циклу систем. (ISO/IEC 15288:2002, IDT). 226 29. Батоврин В.К. ГОСТ ИСО/МЭК 15288-2005 «Системная инженерия. Процессы жизненного цикла систем» – базовый стандарт в области проектирования систем Режим доступа: www.pqmonline.com/assets/files/lib/.../gost_r_iso_iec_152882005.pdf 30. ДСТУ ISO 9000:2007. Системи управління якістю. Основні положення та словник термінів. – К.: Держспоживстандарт, 2008. – [Чинний від 2008-01-01] – 35 c.– (Державний стандарт). 31. ДСТУ ISO 9001:2009. Системи управління якістю. Вимоги. – К.: Держспоживстандарт, 2009. – [Чинний від 2009-06-22] – 80 c.– (Державний стандарт). 32. IEEE Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004. – (Галузевий стандарт). [Електронний ресурс]. – Режим доступу: http://www.computer.org/portal/web/swebok/htmlformat. 33. Электронный учебник «Программная Инженерия», Лаврищева Е. М. Режим доступу: http://www.programsfactory.univ.kiev.ua/ru/content/books/ 2 34. Ехлаков Ю.П. Введение в програмную инженерию: учебное пособие / Ю.П. Ехлаков. – Томск: Эль Континент, 2011. – 148 с. 35. Крупский А.Ю. Разработка и стандартизация программных средств: Учебное пособие / А.Ю. Крупский, Л.А. Феоктистова. – М.: Издателльское-тогрговаякорпорация «Дашков и К», 2009. – 100 с. 36. Карпов Д.В. Гибкая методология разработки программного обеспечения/ Вестник Нижегородского университета им. Н.И. Лобачевского, 2011, № 3 (2), С. 227–230. 227 37. Независимое некоммерческое сообщество, объединяющее ИТ-профессионалов, занимающихся или интересующихся гибкими методологиями разработки ПО Режим доступа: http://agilerussia.ru/ 38. Кулямин В.В Технологии программирования. Компонентный подход. / В.В Кулямин. – М.: ИнтернетУниверситет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. – 463 с. 39. М. Фаулер, Новые методологии программирования, Режим доступа: http://www.maxkir.com/sd/newmethRUS.html 40. Якобсон А. Унифицированный процесс разработки программного обеспечения./ А.Якобсон А., Г. Буч, Дж Рамбо. – СПб.: Изд-во «Питер», 2002. – 492 с. 41. Полис Г. Разработка программных проектов на основе Rational Unified Process.: Пер. с англ./ Г. Полис, Л. Огастин, К. Лоу, Д. Мадхар; ООО «Бином-Пресс», М., 2005. – 256с. 42. Кролл П. Rational Unified Process – это легко. Руководство по RUP для практиков / П. Кролл, Ф. Крачтен; КУДИЦ-ОБРАЗ, М., 2004. – 432с. 43. Арлоу Дж. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование./ Дж.Арлоу, А. Нейштадт – СПб.: Символ-Плюс, 2007 44. Технологии производства ПО. Режим доступа: http://freiman.info/texnologii-proizvodstvaprogrammnogo-obespecheniya 45. Долженко А. Академия Microsoft: Технологии командной разработки программного обеспечения информационных систем Режим доступа: http://www.intuit.ru/studies/courses/4806/1054/info 228 46. Грекул В. Управление внедрением информационных систем. Режим доступа: http://www.intuit.ru/studies/courses/2196/267/info 47. Якимчук С. MSF – философия создания IT-решений или голые амбиции лидера. Режим доступа: http://citforum.ru/SE/project/msf/ 48. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD /Пер. с англ. – 2-е изд., испр. – М: Издатель-ско-торговый дом «Русская Редакция», 2002. –736 с. 49. Экстремальное программирование Режим доступа: http://www.extremeprogramming.org/ 50. Вольфсон Б. Гибкие методологии разработки Режим доступа: http://adm-lib.ru/books/10/Gibkiemetodologii.pdf 51. Книберг Х., Скарин М. Scrum и Kanban: выжимаем максимум Режим доступа: http://www.infoq.com/resource/news/2010/01/kanbanscrum-minibook/en/resources/KanbanAndScrumRussian.pdf 52. Узарбаев А. Обзор методологии SCRUM Режим доступа: http://citforum.ck.ua/SE/project/scrum/ 53. Кролл П. OpenUP - это просто. Режим доступа: http://www.ibm.com/developerworks/ru/library/kroll/index. html?S_TACT=105AGX99&S_CMP=GR01 54. Введение в OpenUP Режим доступа: http://epf.eclipse.org/wikis/openupru/index.htm 55. Методология Feature Driven Development Режим доступа: http://featuredrivendevelopment.com/ 56. Бибичев А. Обзор Feature-Driven Development и Domain-Driven Design Режим доступа: http://2009.agiledays.ru/reports/themes/view/4/ 57. Шопырин Д. Г. Управление проектами разработки ПО. Дисциплина «Гибкие технологии разработки 229 программного обеспечения» Режим доступа: http://books.ifmo.ru/file/pdf/422.pdf 58. Довгополый М. Сравнение Waterfall и Agile. Плюсы и минусы Режим доступа: http://agile.kh.ua/2013/11/13/sravnenie-waterfall-i-agileplyusy-i-minusy/ 59. Ларионов Ю. Методологии разработки и жизненный цикл ПО Режим доступа: http://www.reksoft.com/pdf/lectures/Larionov-YulianLecture.pdf 60. Брагина Т. И. Сравнительный анализ итеративных моделей разработки программного обеспечения // Т.И. Брагина, Г.В. Табунщик Радіоелектроніка, інформатика, управління. 2010. №2 (23). URL: http://cyberleninka.ru/article/n/sravnitelnyy-analiziterativnyh-modeley-razrabotki-programmnogoobespecheniya 61. Закис А. RUP и другие методологии разработки ПО Режим доступа: http://compress.ru/article.aspx?id=16880 62. Советов Б.Я. Архитектура информационных систем / Б.Я. Советов, А.И. Водяхо, В.А. Дубенецкий, В.В.Цехановский. – М. : Издательский центр «Академия», 2012. – 288 с. 63. Гудов А.М., Завозкин С.Ю., Трофимов С.Н. Технология разработки программного обеспечения Режим доступа: http://unesco.kemsu.ru/study_work/method/po/UMK/Posob ie/index.html 64. Дубина О. Обзор паттернов проектирования Режим доступа: http://citforum.ck.ua/SE/project/pattern/index.shtml#toc 65. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования /Э. Гамма, Р. Хелм, Р. Джонсон, Влисидес Дж. – СПб: Питер, 2010. – 368 с. 230 66. Справочник паттернов проектирования Режим доступа: http://design-pattern.ru/ 67. Несвижский А. Академия Microsoft: Современные вебтехнологии, А. Несвижский, В. Рябов Режим доступа: http://www.intuit.ru/studies/courses/611/467/info 68. Паттерны проектирования Режим доступа: http://cppreference.ru/patterns/ 69. Шаллоуей А. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию А. Шаллоуей, Д. Р. Тротт / М.: Издательский дом «Вильямс», 2002. – 288 с. 70. Фаулер М. Архитектура корпоративных программных приложений.: Пер. с англ. – М.: Издательский дом «Вильямс», 2006. – 544 с. 71. Фримен Э. Паттерны проектирования / Э. Фримен, К. Сьерра, Б. Бейс. – СПб.: Питер, 2011. – 656 с. 72. Илес П. Что такое архитектура программного обеспечения? Режим доступа: https://www.ibm.com/developerworks/ru/library/eeles/ 73. Данилин А. Архитектура предприятия Режим доступа: http://www.intuit.ru/studies/courses/995/152/info 74. Руководство Microsoft по проектированию архитектуры приложений Режим доступа: www.goodreads.com/book/show/10134291-microsoft http://download.microsoft.com/documents/rus/ msdn/ры_приложений_полная_книга.pdf 75. Руководства по разработке архитектуры систем. Режим доступа: http://msdn.microsoft.com/architecture; http://msdn.microsoft.com/practices; http://www.microsoft.com/resources/practices. 76. Электронный журнал Microsoft Architecture Journal Режим доступа: http://msdn.microsoft.com/architecture/journ/. 231 77. ДСТУ 3919-99 (ISO/IEC 14102:1995) Інформаційні технології. Основні напрямки оцінювання та відбору CASE-інструментів – К.: Держспоживстандарт, 2000. – [чинний: від 2000-07-01] – 45 c.– (Державний стандарт). 78. Калянов Г. Н. CASE-технологии. Консалтинг при автоматизации бизнес-процессов / Г. Н. Калянов. – М. : Горячая линия-Телеком, 2000. – 320 с. 79. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем Режим доступа: http://www.vernikov.ru/material90.htm 80. Редколис Е. В. О классификации систем автоматизированного проектирования и создания программ (CASE)/ Е. В. Редколис, В. Д. Бердоносов Режим доступа: http://www.metodolog.ru/node/1598 232
