├── .gitignore ├── 01_introduction.md ├── 02_software_requirements.md ├── 03_software_design.md ├── 04_software_construction.md ├── 05_software_testing.md ├── 06_software_maintenance.md ├── 07_software_configuration_management.md ├── 08_software_engineering_management.md ├── 09_software_engineering_process.md ├── 10_software_engineering_tools_and_methods.md ├── 11_software_quality.md ├── Makefile ├── README.md ├── bibliography.md ├── images ├── SWEBOK_logo_v2.jpg ├── Terrace.jpg ├── configuration_management_1-activities.jpg ├── configuration_management_3-tools_and_processes.jpg ├── configuration_management_4-elements.jpg ├── configuration_management_5-changes.jpg ├── configuration_management_area_small.jpg ├── construction_area.jpg ├── design_area_small.jpg ├── lifecycle_categories-ambler.jpg ├── lifecycle_evolution.jpg ├── lifecycle_spiral-boehm.jpg ├── lifecycle_spiral-orlik.jpg ├── lifecycle_waterfall.jpg ├── maintenance_2-activities.jpg ├── maintenance_3-process.jpg ├── maintenance_area_small.jpg ├── maintenance_categories.jpg ├── management_small.jpg ├── process_area_small.jpg ├── process_in-out.jpg ├── quality_area_small.jpg ├── requirements_area_small.jpg ├── requirements_wiegers.jpg ├── swe_1-5_en.jpg ├── swe_1-5_ru.jpg ├── swe_6-10_en.jpg ├── swe_6-10_ru.jpg ├── swe_other-ka_en.jpg ├── swe_other-ka_ru.jpg ├── testing_area_small.jpg └── tools_area_small.jpg ├── software_lifecycle_models.md └── title.txt /.gitignore: -------------------------------------------------------------------------------- 1 | swebok_2004_ru.epub 2 | swebok_2004_ru.fb2 3 | swebok_2004_ru.html 4 | swebok_2004_ru.zip 5 | -------------------------------------------------------------------------------- /01_introduction.md: -------------------------------------------------------------------------------- 1 | # Введение 2 | 3 | В конце 90-х годов прошлого века знания и опыт, которые были накоплены в 4 | индустрии программного обеспечения за предшествующие 30-35 лет, а также более 5 | чем 15-летних попыток применения различных моделей разработки, все это, 6 | наконец, оформилось в то, что принято называть дисциплиной программной 7 | инженерии – Software Engineering. В какой-то мере, такое формирование 8 | дисциплины на основе широко распространенного практического опыта напоминает те 9 | процессы, которые происходили в управлении проектами. Возникали и развивались 10 | профессиональные ассоциации, специализированные институты, комитеты по 11 | стандартизации и другие образования, которые, в конце концов, пришли к общему 12 | мнению о необходимости сведения профессиональных знаний по соответствующим 13 | областям и стандартизации соответствующих программ обучения. 14 | 15 | ## Программная инженерия как дисциплина 16 | 17 | В 1958 всемирно известный статистик Джон Тьюкей (John Tukey) впервые ввел 18 | термин *software* – программное обеспечение. В 1972 году IEEE[^0_1] выпустил первый 19 | номер *Transactions on Software Engineering* – Труды по Программной Инженерии. 20 | Первый целостный взгляд на эту область профессиональной деятельности появился 21 | 1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730 22 | по качеству программного обеспечения. После 7 лет напряженной работы, в 1986 23 | году IEEE выпустило IEEE Std 1002 “Taxonomy of Software Engineering Standards”. 24 | 25 | Наконец, в 1990 году началось планирование всеобъемлющих *международных* 26 | стандартов, в основу которых легли концепции и взгляды стандарта IEEE Std 1074 27 | и результатов работы образованной в 1987 году совместной комиссии ISO/IEC JTC 1[^0_2]. 28 | В 1995 году группа этой комиссии SC7 “Software Engineering” 29 | выпустила первую версию международного стандарта ISO/IEC 12207 “Software 30 | Lifecycle Processes”. Этот стандарт стал первым опытом создания единого общего 31 | взгляда на программную инженерию. Соответствующий национальный стандарт России 32 | – ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207, 1999] содержит полный аутентичный 33 | перевод текста международного стандарта ISO/IEC 12207-95 (1995 года). 34 | 35 | В свою очередь, IEEE и ACM[^0_3], начав совместные работы еще в 1993 году 36 | с кодекса этики и профессиональной практики в данной области (ACM/IEEE-CS Code 37 | of Ethics and Professional Practice), к 2004 году сформулировали два ключевых 38 | описания того, что сегодня мы и называем основами программной инженерии – 39 | Software Engineering: 40 | - *Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 41 | Version* - Руководство к Своду Знаний по Программной Инженерии, в дальнейшем 42 | просто “SWEBOK” [SWEBOK, 2004]; 43 | - *Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree 44 | Programs in Software Engineering* – Учебный План для Преподавания Программной 45 | Инженерии в ВУЗах (данное название на русском языке представлено в 46 | вольном смысловом переводе) [SE, 2004]. 47 | 48 | [^0_1]: IEEE - Computer Society of the Institute for Electrical and Electronic 49 | Engineers, IEEE Computer Society – IEEE-CS (Компьютерное Общество) или просто 50 | IEEE. https://www.ieee.org 51 | 52 | [^0_2]: ISO – International Organization for Standardization. https://www.iso.ch ; 53 | IEC – International Electrotechnical Commission; JTC 1 – Joint Technical 54 | Committee 1, Information technology 55 | 56 | [^0_3]: ACM – Association of Computer Machinery 57 | 58 | Оба стандарта стали результатом консенсуса ведущих представителей индустрии и 59 | признанных авторитетов в области программной инженерии - по аналогии с тем, как 60 | был создан PMI PMBOK. Так мы пришли к сегодняшнему состоянию Software 61 | Engineering как дисциплины. 62 | 63 | ## SWEBOK: Руководство к своду знаний по программной инженерии 64 | 65 | C 1993 года IEEE и ACM координируют свои работы в рамках специального 66 | совместного комитета - Software Engineering Coordinating Committee (SWECC - 67 | http://www.computer.org/tab/swecc). Проект SWEBOK был инициирован этим комитетом 68 | в 1998 году. Оцененный предположительный объем содержания SWEBOK и другие 69 | факторы привели к тому, что было рекомендовано проводить работы по реализации 70 | проекта не только силами добровольцев из рядов экспертов индустрии и 71 | представителей крупнейших потребителей и производителей программного 72 | обеспечения, но и на основе принципа “полной занятости”. Базовый комплекс работ, 73 | в соответствии со специальным контрактом, был передан в Software Engineering 74 | Management Research Laboratory Университета Квебек в Монреале (Universite du 75 | Quebec a Montreal). Среди компаний, поддержавших этот уникальный проект были 76 | Boeing, MITRE, Raytheon, SAP. В результате проекта, оcуществленного при 77 | финансовой поддержке этих и других компаний и организаций, а также с учетом его 78 | значимости для индустрии, SWEBOK Advisory Committee (SWAC) принял решение 79 | сделать SWEBOK 2004 trial edition общедоступной. В перспективе, в зависимости от 80 | финансирования, SWAC считал необходимым законченную версию SWEBOK (изначально 81 | планировалось, что она будет готова в 2008 году) сделать также свободно 82 | доступной на Web-сайте проекта – http://www.swebok.org. Сегодняшняя 83 | “публичность” (общедоступность) результатов проекта стала возможна, в первую 84 | очередь, именно благодаря поддержке SWEBOK Industrial Advisory Board (IAB) – 85 | структуры, объединяющей представителей компаний, поддержавших проект. 86 | 87 | Проект SWEBOK планировался в виде трех фаз: *Strawman* (“соломенный человек”), 88 | *Stoneman* (“каменный человек”) и *Ironman* (“железный человек”). К 2004 году 89 | была выпущена версия Руководства по Своду Знаний 3-ей фазы - Ironman, то есть 90 | максимально приближенная к окончательному варианту и одобренная IEEE в феврале 91 | 2005 года к публикации в качестве Trial-версии. Основная цель текущей “пробной” 92 | версии SWEBOK – улучшить представление, целостность и полезность материала 93 | руководства на основе сбора и анализа откликов на данную версию с тем, чтобы 94 | выпустить финальную редакцию документа в 2008 году. Однако версии 2008 не 95 | появилось, хотя ряд дополнений на начало 2010 года и находится уже в виде 96 | драфтов, что не исключает расширения SWEBOK в ближайшей перспективе и, в то же 97 | время, не принижает значимости уже выпущенной версии 2004. 98 | 99 | По ряду обоснованных причин, “SWEBOK является достаточно консервативным” 100 | [SWEBOK, 2004, с.B-2]. После 6 лет непосредственных работ над документом, 101 | SWEBOK включал “лишь” 10 *областей знаний* (*knowledge areas*, KA). При этом, 102 | что справедливо и для PMBOK, добавление новых областей знаний в SWEBOK 103 | достаточно прозрачно. Все, что для этого необходимо, зрелость (или, по крайней 104 | мере, явный и быстрый процесс достижения зрелости) и общепринятость[^0_4] 105 | соответствующей области знаний, если это не приведет к серьезному усложнению 106 | SWEBOK. 107 | 108 | [^0_4]: Концепция “общепринятости” - generally accepted – определена в IEEE 109 | Std 1490-1998, Adoption of PMI Standard — A Guide to the Project Management 110 | Body of Knowledge 111 | 112 | Важно понимать, что программная инженерия является развивающейся дисциплиной. 113 | Более того, данная дисциплина не касается вопросов конкретизации применения тех 114 | или иных языков программирования, архитектурных решений или, тем более, 115 | рекомендаций, касающихся более или менее распространенных или развивающихся с 116 | той или иной степенью активности/заметности технологий (например, web-служб). 117 | Руководство к своду знаний, каковым является SWEBOK, включает базовое 118 | определение и описание областей знаний (например, конфигурационное управление – 119 | configuration management) и, безусловно, является *недостаточным* для охвата 120 | всех вопросов, относящихся к вопросам создания программного обеспечения, но, в 121 | то же время *необходимым* для их понимания. 122 | 123 | Необходимо отметить, что одной из важнейших целей SWEBOK является именно 124 | определение и систематизация тех аспектов деятельности, которые составляют суть 125 | профессии инженера-программиста. 126 | 127 | ## Структура и содержание SWEBOK 128 | 129 | Описание областей знаний в SWEBOK построено по иерархическому принципу, как 130 | результат структурной декомпозиции. Такое иерархическое построение обычно 131 | насчитывает два-три уровня детализации, принятых для идентификации тех или иных 132 | общепризнанных аспектов программной инженерии. При этом, структура декомпозиции 133 | областей знаний детализирована только до того уровня, который необходим для 134 | понимания природы соответствующих тем и возможности нахождения источников 135 | компетенции и других справочных данных и материалов. В принципе, считается, что 136 | как таковой “свод знаний” по программной инженерии представлен не в обсуждаемом 137 | руководстве (SWEBOK), а в первоисточниках (как указанных в нем, так и 138 | представленных за его рамками) [SWEBOK, 2004, с.1-2]. 139 | 140 | SWEBOK описывает 10 областей знаний: 141 | 142 | - Software requirements – программные требования 143 | - Software design – дизайн (архитектура) 144 | - Software construction – конструирование программного обеспечения 145 | - Software testing - тестирование 146 | - Software maintenance – эксплуатация (поддержка) программного обеспечения 147 | - Software configuration management – конфигурационное управление 148 | - Software engineering management – управление в программной инженерии 149 | - Software engineering process – процессы программной инженерии 150 | - Software engineering tools and methods – инструменты и методы 151 | - Software quality – качество программного обеспечения 152 | 153 | В дополнение к ним, SWEBOK также включает обзор смежных дисциплин, связь с 154 | которыми представлена как фундаментальная, важная и обоснованная для 155 | программной инженерии: 156 | 157 | - Computer engineering 158 | - Computer science 159 | - Management 160 | - Mathematics 161 | - Project management 162 | - Quality management 163 | - Systems engineering 164 | 165 | Стоит отметить, что принятые разграничения между областями знаний, их 166 | компонентами (subareas) и другими элементами достаточно произвольны. При этом, 167 | в отличие от PMBOK, области знаний SWEBOK не включают “входы” и “выходы”. В 168 | определенной степени такая декомпозиция связаны с тем, что SWEBOK не 169 | ассоциирован с той или иной моделью (например, жизненного цикла) или методом. 170 | Хотя на первый взгляд первые пять областей знаний в SWEBOK представлены в 171 | традиционной последовательной (каскадной - waterfall) модели, это не более чем 172 | следование принятой последовательности освещения соответствующих тем. Остальные 173 | области и структура декомпозиции областей представлены в алфавитном порядке. 174 | 175 | Для каждой области знаний SWEBOK описывает ключевые акронимы, представляет 176 | область в виде “подобластей” (subareas) или как их часто называют в самом 177 | SWEBOK – “секций” и дает декомпозицию каждой секции в форме списка тем (topics) 178 | с их описанием. 179 | 180 | ![Рисунок 1-а. Первые пять областей знаний SWEBOK на английском языке](images/swe_1-5_en.jpg) 181 | 182 | ![Рисунок 1-б. Первые пять областей знаний SWEBOK на русском языке](images/swe_1-5_ru.jpg) 183 | 184 | ![Рисунок 2-а. Вторые пять областей знаний SWEBOK на английском языке](images/swe_6-10_en.jpg) 185 | 186 | ![Рисунок 2-б. Вторые пять областей знаний SWEBOK на русском языке](images/swe_6-10_ru.jpg) 187 | 188 | ![Рисунок 3-а. Области знаний связанных дисциплин на английском языке](images/swe_other-ka_en.jpg) 189 | 190 | ![Рисунок 3-б. Области знаний связанных дисциплин на русском языке](images/swe_other-ka_ru.jpg) 191 | 192 | 193 | ## Перевод SWEBOK на русский язык 194 | 195 | Учитывая, что существует ряд неоднозначностей и фактически отсутствует 196 | консенсус по соответствующей терминологии на русском языке, далее в книге будут 197 | использоваться как оригинальные термины на английском языке, так и те их 198 | представления по-русски, которые кажутся представляются наиболее адекватными в 199 | соответствующем контексте. 200 | 201 | К моменту начала работы над представленным переводом SWEBOK в 2004 году, 202 | каких-либо даже фрагментарных переводов SWEBOK на русский язык не 203 | существовало. В то же время, несмотря на спорность некоторых положений SWEBOK, 204 | значимость его для индустрии программного обеспечения как первой коллективной 205 | попытки систематизации накопленных знаний просто сложно 206 | переоценить. Представленный далее перевод SWEBOK - Руководство к своду знаний по 207 | программной инженерии необходимо рассматривать как авторский перевод с 208 | замечаниями и комментариями ключевых положений SWEBOK. Такой подход ни в коем 209 | случае не подменяет оригинального SWEBOK и является всего лишь авторским 210 | прочтением последнего. 211 | 212 | > Представленный перевод SWEBOK 2004 никак не заменяет первоисточника и создан 213 | > [Сергеем Орликом](https://www.linkedin.com/in/sorlik) при участии [Юрия 214 | > Булуя](http://www.linkedin.com/in/yurybuluy) без какой-либо поддержки IEEE или 215 | > других структур по собственной инициативе в полном соответствии со SWEBOK 216 | > Copyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc. 217 | > All rights reserved. Copyright and Reprint Permissions: This document may be 218 | > copied, in whole or in part, in any form or by any means, as is, or with 219 | > alterations, provided that (1) alterations are clearly marked as alterations 220 | > and (2) this copyright notice is included unmodified in any copy. Далее перевод 221 | > соответствующих глав SWEBOK включает расширения (замечания и комментарии), 222 | > помеченные цветом, отличным от цвета перевода оригинального содержания 223 | > SWEBOK. 224 | -------------------------------------------------------------------------------- /03_software_design.md: -------------------------------------------------------------------------------- 1 | # Проектирование программного обеспечения 2 | 3 | Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK. 4 | 5 | Содержит перевод описания области знаний SWEBOK “Software Design”, с замечаниями и комментариями. 6 | 7 | Процесс определения архитектуры, компонентов, интерфейсов и других 8 | характеристик системы или ее компонентов называется *проектированием*. 9 | Результат процесса проектирования – *дизайн*. Рассматриваемое как процесс, 10 | проектирование есть инженерная деятельность в рамках жизненного цикла (в данном 11 | контексте – программного обеспечения), в которой надлежащим образом 12 | анализируются требования для создания описания внутренней структуры ПО, 13 | являющейся основой для конструирования программного обеспечения как такового. 14 | Программный дизайн (как результат деятельности по проектированию) должен 15 | описывать архитектуру программного обеспечения, то есть представлять 16 | декомпозицию программной системы в виде организованной структуры компонент и 17 | интерфейсов между компонентами. Важнейшей характеристикой готовности дизайна 18 | является тот уровень детализации компонентов, который позволяет заняться их 19 | конструированием. Термины дизайн и архитектура могут использоваться 20 | взаимозаменяемым образом, но чаще говорят о дизайне как о целостном взгляде на 21 | архитектуру системы. 22 | 23 | Проектирование играет важную роль в процессах жизненного цикла создания 24 | программного обеспечения (Software Development Life Cycle), например, IEEE и 25 | ISO/IEC (ГОСТ Р ИСО.МЭК) 12207. Проектирование программных систем можно 26 | рассматривать как деятельность, результат которой состоит из двух составных 27 | частей: 28 | 29 | - Архитектурный или высокоуровневый дизайн (software architectural design, 30 | top-level design) – описание высокоуровневой структуры и организации 31 | компонентов системы; 32 | - Детализированная архитектура (software detailed design) – описывающая каждый 33 | компонент в том объеме, который необходим для конструирования. 34 | 35 | В результате консенсуса, принятого создателями SWEBOK, данная область знаний не 36 | описывает все сущности или понятия, имеющие в своем названии слово “дизайн” или 37 | “архитектура”. В 1999 году Том ДеМарко (Tom DeMarco) [DeMarco, 1999], один из 38 | известных специалистов в программной инженерии, предложил терминологическое 39 | разделение различных видов дизайна: 40 | 41 | - *D-дизайн (D-design, decomposition design)* – декомпозиция структуры 42 | программного обеспечения в виде набора фрагментов или компонент; 43 | - *FP-дизайн (FP-design, family pattern design)* – семейство 44 | архитектурных представлений, базирующихся на шаблонах; 45 | - *I-дизайн (I-design, invention)* – создание высоко-уровневой 46 | концепции, видения того, что из себя будет представлять программная 47 | система; данный вид дизайна является результатом процесса анализа 48 | требований и их трансформации в подходы к реализации. 49 | 50 | Если обсуждать данную область знаний в терминах ДеМарко, проектирование 51 | программного обеспечения в понимании программной инженерии подразумевает D- и 52 | FP-дизайн. I-дизайн в большей степени относится к работе с программными 53 | требованиями. 54 | 55 | Соответственно, данная область знаний тесно связана со следующими областями 56 | программной инженерии: 57 | 58 | - Software Requirements 59 | - Software Construction 60 | - Software Maintenance 61 | - Software Engineering Management 62 | - Software Quality 63 | 64 | Сама же область знаний по проектированию программного обеспечения представлена 65 | в виде 6 секций, структурированных по темам. 66 | 67 | ![Рисунок 3. Область знаний “Проектирование программного обеспечения” [SWEBOK, 2004, с.3-2, рис. 1]](images/design_area_small.jpg) 68 | 69 | ## Основы проектирования (Software Design Fundamentals) 70 | 71 | Эта секция вводит концепции, понятия и терминологию в качестве основы для 72 | понимания роли и содержания проектирования (как деятельности) и дизайна 73 | (архитектуры, как результата) программного обеспечения. 74 | 75 | Темы данной секции: 76 | 77 | ### Общие концепции проектирования (General Design Concepts) 78 | 79 | К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, 80 | используемые представления и решения. 81 | Например, архитектурный фреймворк – TOGAF [TOGAF, 2003], разработанный и 82 | развиваемый консорциумом The Open Group (www.opengroup.org), предлагает 83 | следующие возможные цели (goals): 84 | 85 | - Улучшение и повышение продуктивности бизнес-процессов 86 | - Уменьшение затрат 87 | - Улучшение операционной бизнес-деятельности 88 | - Повышение эффективности управления 89 | - Уменьшение рисков 90 | - Повышение эффективности ИТ-организации 91 | - Повышение продуктивности работы пользователей 92 | - Повышение интероперабельности (возможности и прозрачности взаимодействия) 93 | - Уменьшение стоимости поддержки жизненного цикла 94 | - Улучшение характеристик безопасности 95 | - Повышение управляемости 96 | 97 | ### Контекст проектирования (Context of Software Design) 98 | 99 | Для понимания роли проектирования программного обеспечения важно понимать 100 | контекст, в котором осуществляется проектирование и используются его 101 | результаты. В качестве такого контекста выступает жизненный цикл программной 102 | инженерии, а проектирование напрямую связано с результатами анализа требований, 103 | конструированием программных систем и их тестированием. Стандарты жизненного 104 | цикла, например, IEEE и ISO/IEC (ГОСТ Р) 12207 уделяют специальное внимание 105 | вопросам проектирования и детализируют их, описывая контекст проектирования – 106 | от требований до тестов. 107 | 108 | ### Процесс проектирования (Software Design Process) 109 | 110 | Проектирование в основном рассматривается как двух-шаговый процесс: 111 | 112 | #### Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент; 113 | 114 | #### Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент. 115 | 116 | Выходом этого процесса является набор моделей и артефактов, содержащих 117 | результаты решений, принятых по способам реализации требований в программном 118 | коде. 119 | 120 | ### Техники применения (Enabling Techniques) 121 | 122 | Принципы проектирования, также называемые техниками применения, являются 123 | ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в 124 | различных методах и подходах к проектированию программного обеспечения. 125 | 126 | ##### Абстракция (Abstraction) 127 | 128 | В контексте проектирования программных систем существует два механизма 129 | абстракции – параметризация и специфицирование (может интерпретироваться как 130 | детализация). При этом, абстракция через специфицирование бывает трех видов: 131 | процедурная абстракция (динамическая, то есть в отношении поведения), 132 | абстракция данных (статическая, то есть в отношении информации) и абстракция 133 | контроля (то есть управления системой и обрабатываемой ею информацией). 134 | 135 | Обычно под абстракций, как результатом процесса абстракции, понимают модель, 136 | упрощающую поставленную проблему до рамок, значимых для заданного контекста. 137 | 138 | #### Связанность и соединение (Coupling and Cohesion) 139 | 140 | *Связанность (Coupling)* – определяет силу связи (часто, взаимного влияния) 141 | между модулями. Соединение (Cohesion) – определяет как тот или иной элемент 142 | обеспечивает связь внутри модуля, внутреннюю связь. 143 | 144 | Значение оригинальных терминов очень близко и, в зависимости от контекста, 145 | “связанность” и “соединение” могут рассматриваться как степень 146 | самодостаточности или ее отсутствия (coupling) и функциональная зависимость 147 | (cohesion), соответственно. 148 | 149 | Хочется особенно подчеркнуть значимость этих понятий, так как с развитием 150 | сервисно-ориентированной архитектуры (Service-Oriented Architecture, SOA), 151 | слабосвязанной по своей природе (то есть со слабым “сопряжением”, слабой “силой 152 | связи” между модулями), по сравнению, например, с OMG CORBA (Common Object 153 | Request Broker Architecture), все чаще приходится сравнивать различные подходы 154 | и решения, определяемые способом и степенью связанности различных модулей, 155 | компонент и самих программных систем. 156 | 157 | #### Декомпозиция и разбиение на модули (Decomposition and Modularization) 158 | 159 | Декомпозиция и разбиение на модули сложных программных систем производится с 160 | целью получения более мелких и относительно независимых программных 161 | компонентов, каждый из которых несет различную функциональность (логически 162 | связанные группы функциональности). 163 | 164 | #### Инкапсуляция/сокрытие информации (Encapsulation/information hiding) 165 | 166 | Данная концепция предполагает группировку и упаковку (с точки зрения подготовки 167 | к развертыванию и эксплуатации) элементов и внутренних деталей абстракции (то 168 | есть модели) в отношении реализации с тем, чтобы эти детали (как малозначимые 169 | для использования компонента или по другим причинам) были недоступны 170 | пользователям элементов (компонент). При этом, в качестве “пользователя” одного 171 | компонента может выступать другой компонент. Более того, при использовании 172 | объектно-ориентированного подхода, наследники компонентов могут не иметь 173 | доступа ко внутренним деталям реализации компонента, который является их 174 | предком (зависит от объектно-ориентированной модели конкретного языка 175 | программирования или платформы). 176 | 177 | #### Разделение интерфейса и реализации (Separation of interface and implementation) 178 | 179 | Данная техника предполагает определение компонента через специфицирование 180 | интерфейса, известного (описанного) и доступного клиентам (или другим 181 | компонентам), от непосредственных деталей реализации. 182 | 183 | #### Достаточность, полнота и простота (Sufficiency, completeness and primitiviness) 184 | 185 | Этот подход подразумевает, что создаваемые программные компоненты обладают 186 | всеми необходимыми характеристиками, определёнными абстракцией (моделью), но не 187 | более того. То есть не включают функциональность, отсутствующую в модели. 188 | 189 | Данный принцип особенно ярко выделен и явно представлен в виде рекомендуемых 190 | практик (best practices) методологий гибкого моделирования и экстремального 191 | программирования, где “все, что надо, но ни граммом больше” лежит в основе 192 | самой концепции “прагматичного” подхода (и на стадии моделирования, и в 193 | отношении реализации в коде). В оригинале этот принцип звучит как YAGNI – “You 194 | Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”. 195 | 196 | ## Ключевые вопросы проектирования (Key Issues in Software Design) 197 | 198 | В какой-то мере, данную секцию стоило перевести как ключевые проблемы. Как 199 | проводить декомпозицию? Как организовать и объединить компоненты в единую 200 | систему? Как обеспечить необходимую производительность? Наконец, как обеспечить 201 | приемлемое качество системы? Все это – фундаментальные вопросы и проблемы 202 | проектирования, вне зависимости от используемых при проектировании подходов. 203 | 204 | ### Параллелизм (Concurrency) 205 | 206 | Эта тема охватывает вопросы, подходы и методы организации процессов, задач и 207 | потоков для обеспечения эффективности, атомарности, синхронизации и 208 | распределения (по времени) обработки информации. 209 | 210 | ### Контроль и обработка событий (Control and Handling of Events) 211 | 212 | В самом названии данной темы заложен комплекс обсуждаемых вопросов. В 213 | частности, данная тема касается и неявных методов обработки событий, часто 214 | реализуемых в виде функции обратного вызова (call-back), как одной из 215 | фундаментальных концепций обработки событий. 216 | 217 | ### Распределение компонентов (Distribution of Components) 218 | 219 | Распределение (и выполнение) по различным узлам обработки в терминах 220 | аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших 221 | вопросов данной темы – использование связующего программного обеспечения 222 | (middleware[^2_1]) 223 | 224 | [^2_1]: Часто middleware переводят как “промежуточное программное обеспечение”. Такой 225 | вариант перевода, к сожалению, рассматривает связующее ПО во второстепенной – 226 | “промежуточной” роли. Читатель, безусловно, может не согласиться с такой 227 | трактовкой, однако, многолетняя практика автора в обсуждении архитектурных 228 | вопросов с различными специалистами демонстрирует именно такой взгляд 229 | пользователей, не знакомых или не имеющих успешного опыта разработки и 230 | эксплуатации распределённых систем. 231 | 232 | ### Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости (Errors and Exception Handling and Fault Tolerance) 233 | 234 | Вопрос темы, как ни странно, формулируется достаточно просто – как 235 | предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее 236 | функционирование системы. 237 | 238 | ### Взаимодействие и представление (Interaction and Presentation) 239 | 240 | Тема касается вопросов представления информации пользователям и взаимодействия 241 | пользователей с системой, с точки зрения реакции системы на действия 242 | пользователей. Речь в этой теме идет о реакции системы в ответ на действия 243 | пользователей и организации ее отклика с точки зрения внутренней организации 244 | взаимодействия, например, в рамках популярной концепции Model-View-Controller. 245 | 246 | Ни в коем случае не надо путать данную тему с вопросами организации 247 | пользовательского интерфейса, являющимеся частью “Эргономики программного 248 | обеспечения” – Software Ergonomics (см. “Связанные дисциплины”). 249 | 250 | ### Сохраняемость данных (Data Persistence) 251 | 252 | Именно сохраняемость, а не сохранность, так как тема касается не доступа к 253 | базам данных, как такового, а также не гарантий сохранности информации. Суть 254 | вопроса – как должны обрабатываться “долгоживущие” данные. 255 | 256 | ## Структура и архитектура программного обеспечения (Software Structure and Architecture) 257 | 258 | В строгом значении архитектура программного обеспечения (software architecture) 259 | – описание подсистем и компонент программной системы, а также связей между 260 | ними. Архитектура пытается определить внутреннюю структуру получаемой системы, 261 | задавая способ, которым система организована или конструируется. 262 | 263 | В середине 90-х, на волне распространения клиент-серверного подхода и начала 264 | его трансформации в “многозвенный клиент-сервер”, призванный обеспечить 265 | централизованное развертывание и управление общей (для клиентских приложений) 266 | бизнес-логикой, вопросы организации архитектуры программного обеспечения стали 267 | складываться в самостоятельную и достаточно обширную дисциплину. В результате, 268 | сформировалась точка зрения на архитектуру не только в приложении к конкретной 269 | программной системе, но и развился взгляд на архитектуру, как на приложение 270 | общих (generic) принципов организации программных компонент. В итоге, уже на 271 | сегодняшний день, на фоне такого развития понимания архитектуры, накоплен целый 272 | комплекс подходов и созданы (и продолжают создаваться и развиваться !) 273 | различные архитектурные “фреймворки”, то есть систематизированные комплексы 274 | методов, практик и инструментов, призванные в той или иной степени 275 | формализовать имеющийся в индустрии опыт (как положительный – например, design 276 | patterns, так и отрицательный – например, anti-patterns). 277 | Примеры такой систематизации в форме фреймворков: 278 | 279 | - TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент 280 | первичного написания данной главы доступен в версии 8.1, впервые опубликованной 281 | в декабре 2003 года; в 2009 году вышла версия TOGAF 9) 282 | - Модель Захмана – Zachman Framework [Zachman] 283 | - Руководство по архитектуре электронного правительства E-Gov Enterprise 284 | Architecture Guidance [E-Gov, 2002] 285 | 286 | ### Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints) 287 | 288 | Любая система может рассматриваться с разных точек зрения – например, 289 | поведенческой (динамической), структурной (статической), логической 290 | (удовлетворение функциональным требованиям), физической (распределенность), 291 | реализации (как детали архитектуры представляются в коде) и т.п. В результате, 292 | мы получаем различные архитектурные представления (view). Архитектурное 293 | представление может быть определено, как частные аспекты программной 294 | архитектуры, рассматривающие специфические свойства программной системы. В свою 295 | очередь, дизайн системы – комплекс архитектурных представлений, достаточный для 296 | реализации системы и удовлетворения требований, предъявляемых к системе. 297 | 298 | SWEBOK не дает явного определения, что такое “архитектурная структура”. В то же 299 | время это понятие достаточно важно. Я хотел бы предложить его толкование как 300 | применение архитектурной точки зрения и представления к конкретной системе и 301 | описания тех деталей, которые необходимы для реализации системы, но отсутствуют 302 | (в силу достаточно общего взгляда) в используемом представлении. Таким образом, 303 | представление (view), концентрируясь на заданном подмножестве свойств является 304 | составной частью и/или результатом точки зрения, а архитектурная структура – 305 | дальнейшей детализацией в отношении проектируемой системы. 306 | 307 | Модель Захмана [Zachman] является великолепным и, кстати, классическим 308 | источником комплекса архитектурных точек зрения и представлений, построенных в 309 | системе координат “вопрос-уровень детализации”. Каждое архитектурное 310 | представление является результатом ответа на вопрос (Как? Что? Где? и т.п.) в 311 | контексте необходимого уровня абстракции (содержание, то есть концепция: 312 | бизнес-модель, то есть функциональность и т.д.). Например, физическая модель 313 | данных (Physical Data Model) является ответом на вопрос “что?” в контексте 314 | технологической модели, а логическая модель данных, отвечая на тот же вопрос, 315 | находится на один уровень абстракции выше – в контексте системной или 316 | логической модели. 317 | 318 | ### Архитектурные стили (Architectural Styles) 319 | 320 | В рассматриваемой редакции SWEBOK допущено несоответствие между структурой 321 | декомпозиции данной области знаний и описанием охватываемых ею тем. Если 322 | архитектурные стили присутствуют в декомпозиции, в самом описании области 323 | знаний темы 3.1 и 3.2 смешаны (по форматированию и структуре) в рамках темы 324 | “3.1”, (о чем сообщено ассоциированному редактору данной части SWEBOK). 325 | 326 | Архитектурный стиль, по своей сути, мета-модель или шаблон проектирования 327 | макро-архитектуры - на уровне модулей, "крупноблочного" взгляда. Например, 328 | архитектура распределенной сервисно-ориентированной системы может строится в 329 | стиле обмена сообщениями через соответствующие очереди сообщений, может 330 | проектироваться на основе идеи взаимодействия между компонентами и приложениями 331 | через общую объектную шину, а может использовать концепцию брокера как единого 332 | узла пересылки запросов. В то же время, на более концептуальном уровне, мы 333 | можем говорить о выборе клиент-серверного стиля или распределенного стиля 334 | архитектуры системы. Таким образом, архитектурный стиль – набор ограничений, 335 | определяющих семейство архитектур, которые удовлетворяют этим ограничениям. 336 | 337 | ### Шаблоны проектирования (Design Patterns) 338 | 339 | Наиболее краткая формулировка того, что такое шаблон проектирования, может 340 | звучать так – “общее решение общей проблемы в заданном контексте”. Что это 341 | значит в реальной жизни? Если мы хотим организовать системы таким образом, 342 | чтобы существовал один и только один экземпляр заданного ее компонента в 343 | процессе работы с данной системой – мы можем использовать шаблон проектирования 344 | “Singleton”, описывающий такое общее поведение. 345 | 346 | В то время, как архитектурный стиль определяет макро-архитектуру системы, 347 | шаблоны проектирования задают микро-архитектуру, то есть определяют частные 348 | аспекты деталей архитектуры. 349 | 350 | Чаще всего говорят о следующих группах шаблонов проектирования: 351 | 352 | - Шаблоны создания (Creational patterns) - builder, factory, prototype, 353 | singleton 354 | - Структурные шаблоны (Structural patterns) - adapter, bridge, composite, 355 | decorator, facade, flyweight, proxy 356 | - Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator, 357 | mediator, memento, observer, state, strategy, template, visitor 358 | 359 | В SWEBOK данная тема, в силу упомянутого выше несоответствия между структурной 360 | декомпозицией и описанием области знаний “проектирование”, имеет номер 3.2 361 | (следующая тема, в свою очередь, представлена в SWEBOK как 3.3). 362 | 363 | ### Семейства программ и фреймворков (Families of Programs and Frameworks) 364 | 365 | Один из возможных подходов к повторному использованию архитектурных решений и 366 | компонент заключается в формировании линий продуктов (product lines) на основе 367 | общего дизайна. В объектно-ориентированном программировании аналогичную 368 | смысловую нагрузку несут “фреймворки”, обеспечивающие решение одних и тех же 369 | задач – например, внутренней организации компонентов пользовательского 370 | интерфейса или общей логики работы распределенных систем. 371 | 372 | ## Анализ качества и оценка программного дизайна (Software Design Quality Analysis and Evaluation) 373 | 374 | ### Атрибуты качества (Quality Attributes) 375 | 376 | Существует целый спектр различных атрибутов, помогающих оценить и добиться 377 | качественного дизайна. Эти атрибуты могут описывать многие характеристики 378 | системы и элементов дизайна как такового – “тестируемость”, “переносимость”, 379 | “модифицируемость”, “производительность”, “безопасность” и т.п. 380 | 381 | Важно понимать, что обсуждаемые атрибуты касаются только дизайна (как 382 | результата), но не проектирования (как процесса). В принципе, все эти атрибуты 383 | можно разбить на несколько групп: 384 | 385 | - применимые к run-time, то есть ко времени выполнения системы; например, 386 | среднее время отклика системы позволяющий оценить качество дизайна с точки 387 | зрения производительности; 388 | - ориентированные на design-time, то есть позволяющие оценивать качество 389 | получаемого дизайна еще на этапе проектирования или, в общем случае, вплоть до 390 | тестирования, включительно; например, средняя нагруженность классов 391 | бизнес-методами (предположим бизнес-методов в каждом классе в среднем 30 – 392 | интересно, насколько легко можно поддерживать, модифицировать и развивать 393 | систему с такой внутренней структурой....); 394 | - атрибуты качества архитектурного дизайна как такового, например, 395 | концептуальная целостность дизайна, непротиворечивость, полнота, завершенность; 396 | например, любой определенный бизнес-метод является вызываемым, то есть создан 397 | не просто потому что может понадобиться в будущем, а определен в соответствии с 398 | требованиями или необходим для реализации дизайна в выбранном архитектурном 399 | стиле. 400 | 401 | Необходимо понимать, что существуют атрибуты, которые сложно измерить. 402 | Например, портируемость или безопасность. Не стоит путать атрибуты качества 403 | дизайна с атрибутами качества, фигурируемыми в ряду требований, предъявляемых к 404 | системе. Часть из них может отображаться друг на друга и нести эквивалентную 405 | смысловую нагрузку, некоторые могут быть связаны, большая часть атрибутов 406 | является специфичной именно для дизайна и не связана с требованиями. Например, 407 | если мы используем платформу J2EE (Java 2 Enterprise Edition) и ориентируемся 408 | на использование компонентой модели EJB (Enterprise JavaBeans), существуют 409 | признаки хорошего дизайна, специфичные для данной платформы и компонентной 410 | модели, но абсолютно никак не связанные с какими-либо требованиями к 411 | создаваемой на этой платформе программной системе. Если вернуться к измеряемым 412 | атрибутам качества, они описываются определёнными метриками. Приведенный выше 413 | пример с количеством бизнес-методов на класс является метрикой, относящейся к 414 | теме 4.3 “Измерения”. Эта же метрика позволяет оценить атрибуты качества 415 | “модифицируемость” и “сложность” системы. 416 | 417 | ### Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques) 418 | 419 | В индустрии распространены многие инструменты, техники и практики, помогающие 420 | добиться качественного дизайна: 421 | 422 | - обзор дизайна (software design review); например, неформальный обзор 423 | архитектуры членами проектной команды; 424 | - статический анализ (static analysis); например, трассировка с требованиями; 425 | - симуляция и прототипирование (simulation and prototyping) – динамические 426 | техники проверки дизайна в целом или отдельных его атрибутов качества; 427 | например, для оценки производительности используемых архитектурных решений при 428 | симуляции нагрузки, близкой к прогнозируемым пиковым; 429 | 430 | ### Измерения (Measures) 431 | 432 | Также известные как метрики. Могут быть использованы для количественной оценки 433 | ожиданий в отношении различных аспектов конкретного дизайна, например, размера 434 | проекта, структуры (ее сложности) или качества (например, в контексте 435 | требований, предъявляемых к производительности). Чаще всего, все метрики 436 | разделяют по двум категориям: 437 | 438 | - функционально-ориентированные 439 | - объектно-ориентированные 440 | 441 | ## Нотации проектирования (Software Design Notations) 442 | 443 | Нотация есть соглашение о представлении. Часто под нотацией подразумевают 444 | визуальное (графическое) представление. Нотация может задаваться: 445 | 446 | - стандартом; например, OMG UML – Unified Modeling Language, развиваемый 447 | консорциумом OMG (Object Management Group, http://www.omg.org); 448 | - общепринятой практикой; например, в eXtreme Programming часто используются 449 | карточки функциональной ответственности и связей класса - Class Responsibility 450 | Collaborator или CRC Card (CRC по свое природе является текстовой, то есть 451 | невизуальной нотацией); 452 | - внутренним методом проектной команды (“будем рисовать и обозначать так...”). 453 | 454 | Определенные нотации используются на стадии концептуального проектирования, ряд 455 | нотаций ориентирован на создание детального дизайна, многие могут 456 | использоваться на обеих стадиях. Кроме того, нотации чаще всего используют в 457 | контексте (выбор нотации может быть обусловлен таким контекстом) применяемой 458 | методологии или подхода (см. 6 “Software Design Strategies and Methods” данной 459 | области знаний). Ниже мы будем рассматривать нотации, исходя из описания 460 | структурного (статического) или поведенческого (динамического) представления. 461 | 462 | ### Структурные описания, статический взгляд (Structural Descriptions, static view) 463 | 464 | Следующие нотации, в основном (но, не всегда), являются графическими, описывая 465 | и представляя структурные аспекты программного дизайна. Чаще всего они касаются 466 | основных компонент и связей между ними (статических связей, например, таких как 467 | отношения “один-ко-многим”). 468 | 469 | - *Языки описания архитектуры (Architecture description language, ADL)*: 470 | текстовые языки, часто – формальные, используемые для описания программной 471 | архитектуры в терминах компонентов и коннекторов (специализированных 472 | компонентов, реализующих не функциональность, но обеспечивающих взаимосвязь 473 | функциональных компонентов между собой и с “внешним миром”); 474 | - *Диаграммы классов и объектов (Class and object diagrams)*: используются для 475 | представления набора классов и статических связей между ними (например, 476 | наследования); 477 | - *Диаграммы компонентов или компонентные диаграммы (Component diagrams)*: в 478 | определенной степени аналогичны диаграммам классов, однако, в силу специфики 479 | концепции или понятия компонента[^2_2], обычно, представляются в другой 480 | визуальной форме; 481 | - *Карточки функциональной ответственности и связей класса (Class 482 | responsibility collaborator card, CRC)*: используются для обозначения имени 483 | класса, его ответственности (то есть, что он должен делать) и других сущностей 484 | (классов, компонентов, актёров/ролей и т.п.), с которыми он связан; часто их 485 | называют карточками “класс-обязанность-кооперация”; 486 | - *Диаграммы развёртывания (Deployment diagrams)*: используется для 487 | представления (физических) узлов, связей между ними и моделирования других 488 | физических аспектов системы; 489 | - *Диаграммы сущность-связь (Entity-relationship diagram, ERD или ER)*: 490 | используется для представления концептуальной модели данных, сохраняемых в 491 | процессе работы информационной системы; 492 | - *Языки описания/определения интерфейса (Interface Description Languages, 493 | IDL)*: языки, подобные языкам программирования, не включающие возможностей 494 | описания логики системы и предназначенные для определения интерфейсов 495 | программных компонентов (имён и типов экспортируемых или публикуемых операций); 496 | - *Структурные диаграммы Джексона (Jackson structure diagrams)*: используются 497 | для описания структур данных в терминах последовательности, выбора и итераций 498 | (повторений); 499 | - *Структурные схемы (Structure charts)*: описываю структуру вызовов в 500 | программах (какой модуль вызывает, кем и как вызываем). 501 | 502 | [^2_2]: Здесь необходимо отметить различие в понятиях класса (или объекта) и 503 | компонента: компонент рассматривается как физически реализуемый элемент 504 | программного обеспечения, несущий в определенной степени самодостаточную 505 | логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде 506 | комплекса классов); 507 | 508 | ### Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view) 509 | 510 | Следующие нотации и языки (часть из которых – графические, часть - текстовые) 511 | используются для описания динамического поведения программных систем и их 512 | компонентов. Многие из этих нотаций успешно используются для проектирования 513 | деталей дизайна, но не только для этого. 514 | 515 | - *Диаграммы деятельности или операций (Activity diagrams)*: используются для 516 | описания потоков работ и управления; 517 | - *Диаграммы сотрудничества (Collaboration diagrams)*: показывают динамическое 518 | взаимодействие, происходящее в группе объектов и уделяют особое внимание 519 | объектам, связям между ними и сообщениям, которыми обмениваются объекты 520 | посредством этих связей; 521 | - *Диаграммы потоков данных (Data flow diagrams, DFD)*: описывают потоки данных 522 | внутри набора процессов (не в терминах процессов операционной среды, но в 523 | понимании обмена информацией в бизнес-контексте); 524 | - *Таблицы и диаграммы принятия решений (Decision tables and diagrams)*: 525 | используются для представления сложных комбинаций условий и действий 526 | (операций); 527 | - *Блок-схемы и структурированные блок-схемы (Flowcharts and structured 528 | flowcharts)*: применяются для представления потоков управления (контроля) и 529 | связанных операций; 530 | - *Диаграммы последовательности (Sequence diagrams)*: используются для показа 531 | взаимодействий внутри группы объектов с акцентом на временной 532 | последовательности сообщений/вызовов; 533 | - *Диаграммы перехода и карты состояний(State transition and statechart 534 | diagrams)*: применяются для описания потоков управления переходами между 535 | состояниями; 536 | - *Формальные языки спецификации (Formal specification languages)*: текстовые 537 | языки, использующие основные понятия из математики (например, множества) для 538 | строгого и абстрактного определения интерфейсов и поведения программных 539 | компонентов, часто в терминах пред- и пост-условий; 540 | - *Псевдокод и программные языки проектирования (Pseudocode and program design 541 | languages, PDL)*: языки, используемые для описания поведения процедур и 542 | методов, в основном на стадии детального проектирования; подобны структурным 543 | языкам программирования. 544 | 545 | ## Стратегии и методы проектирования программного обеспечения (Software Design Strategies and Methods) 546 | 547 | Существуют различные общие стратегии, помогающие в проведении работ по 548 | проектированию. В отличие от общих стратегий, методы проектирования более 549 | специфичны и, в основном, предлагают и предоставляют нотации (или наборы 550 | нотаций) для использования совместно с этими методами, а также процессы, 551 | которым необходимо следовать в рамках используемого метода. 552 | 553 | Таким образом, методы в данном контексте это не просто некие 554 | “слабоформализованные” или просто частные практические подходы или техники. 555 | Методы здесь являются более общими понятиями, это - методологии, 556 | сконцентрированные на процессе (в частности, проектирования) и предполагающие 557 | следование определённым правилам и соглашениям, в том числе – по используемым 558 | выразительным средствам. Такие методы полезны как инструмент систематизации 559 | (иногда, формализации) и передачи знаний в виде общего фреймворка (то есть 560 | комплексного набора понятий, подходов, техник и инструментов) не только для 561 | отдельных специалистов, но для команд и проектных групп программных проектов. 562 | 563 | ### Общие стратегии (General Strategies) 564 | 565 | Это обычно часто упоминаемые и общепринятые стратегии: 566 | 567 | - “разделяй-и-властвуй” и пошаговое уточнение 568 | - проектирование “сверху-вниз” и “снизу-вверх” 569 | - абстракция данных и сокрытие информации 570 | - итеративный и инкрементальный подход 571 | - и другие... 572 | 573 | ### Функционально-ориентированное или структурное проектирование (Function-Oriented – Structured Design) 574 | 575 | Это один из классических методов проектирования, в котором декомпозиция 576 | сфокусирована на идентификации основных программных функций и, затем, детальной 577 | разработке и уточнении этих функций “сверху-вниз”. Структурное проектирование, 578 | обычно, используется после проведения структурного анализа с применением 579 | диаграмм потоков данных и связанным описанием процессов. Исследователи 580 | предлагают различные стратегии и метафоры или подходы для трансформации DFD в 581 | программную архитектуру, представляемую в форме структурных схем. Например, 582 | сравнивая управление и поведение с получаемым эффектом. 583 | 584 | ### Объектно-ориентированное проектирование (Object-Oriented Design) 585 | 586 | Представляет собой множество методов проектирования, базирующихся на концепции 587 | объектов. Данная область активно эволюционирует с середины 80-х годов, 588 | основываясь на понятиях объекта (сущности), метода (действия) и атрибута 589 | (характеристики). Здесь главную роль играют полиморфизм и инкапсуляция, в то 590 | время, как в компонентно-ориентированном подходе большее значение придается 591 | мета-информации, например, с применением технологии отражения (reflection). 592 | Хотя корни объектно-ориентированного проектирования лежат в абстракции данных 593 | (к которым добавлены поведенческие характеристики), так называемый 594 | responsibility-driven design или проектирование на основе функциональной 595 | ответственности по SWEBOK[^2_3] может рассматриваться как альтернатива 596 | объектно-ориентированному проектированию. 597 | 598 | [^2_3]: Такое противопоставление – достаточно спорный вопрос, так как функциональная 599 | ответственность столь же близка принципам современного 600 | объектно-ориентированного проектирования, сколь и абстракция данных. Это вопрос 601 | эволюционирования взглядов и степени их консерватизма. 602 | 603 | ### Проектирование на основе структур данных (Data-Structure-Centered Design) 604 | 605 | В данном подходе фокус сконцентрирован в большей степени на структурах данных, 606 | которыми управляет система, чем на функциях системы. Инженеры по программному 607 | обеспечению часто вначале описывают структуры данных входов (inputs) и выходов 608 | (outputs), а, затем, разрабатывают структуру управления этими данными (или, 609 | например, их трансформации). 610 | 611 | ### Компонентное проектирование (Component-Based Design) 612 | 613 | Программные компоненты являются независимыми единицами, которые обладают 614 | однозначно-определёнными (well-defined) интерфейсами и зависимостями (связями) 615 | и могут собираться и развертываться независимо друг от друга. Данный подход 616 | призван решить задачи использования, разработки и интеграции таких компонент с 617 | целью повышения повторного использования активов (как архитектурных, так и в 618 | форме кода). 619 | 620 | Компонентно-ориентированное проектирование является одной из наиболее динамично 621 | развивающихся концепций проектирования и может рассматриваться как предвестник 622 | и основа сервисно-ориентированного подхода (Service-Oriented Architecture, SOA) 623 | в проектировании, не рассматриваемого, к сожалению, в SWEBOK, но все более 624 | активно использующегося в индустрии и смещающего акценты с аспектов организации 625 | связи интерфейс-реализация к обмену информацией на уровне интерфейс-интерфейс 626 | (то есть – межкомпонентному взаимодействию). По мнению автора книги, уже 627 | наступил тот момент, когда необходимо вводить отдельную тему, посвященную 628 | сервисно-ориентированному подходу в проектировании и сервисно-ориентированным 629 | архитектурам, как моделям. В частности, нотация UML 2.0 уже позволяет решать 630 | ряд вопросов, связанных с визуальным представлением соответствующих 631 | архитектурных решений, где сервисы (службы) могут рассматриваться как 632 | публикуемая функциональность одиночных компонентов и групп компонентов, 633 | объединенных в более “крупные” блоки, обеспечивающие предоставление 634 | соответствующей сервисной функциональности. 635 | 636 | ### Другие методы (Other Methods) 637 | 638 | Другие интересные, но менее распространенные подходы, в основном, представляют 639 | собой формальные и точные (строгие) методы, а также, методы трансформации. 640 | -------------------------------------------------------------------------------- /04_software_construction.md: -------------------------------------------------------------------------------- 1 | # Конструирование программного обеспечения 2 | 3 | Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - 4 | SWEBOK. 5 | 6 | Содержит перевод описания области знаний SWEBOK “Software Construction”, с 7 | замечаниями и комментариями. 8 | 9 | Конструирование программного обеспечения (Software Construction) 10 | 11 | Термин конструирование программного обеспечения (software construction) 12 | описывает детальное создание рабочей программной системы посредством комбинации 13 | кодирования, верификации (проверки), модульного тестирования (unit testing), 14 | интеграционного тестирования и отладки. 15 | 16 | Данная область знаний связана с другими областями. Наиболее сильная связь 17 | существует с проектированием (Software Design) и тестированием (Software 18 | Testing). Причиной этого является то, что сам по себе процесс конструирования 19 | программного обеспечения затрагивает важные аспекты деятельности по 20 | проектированию и тестированию. Кроме того, конструирование отталкивается от 21 | результатов проектирования, а тестирование (в любой своей форме) предполагает 22 | работу с результатами конструирования. Достаточно сложно определить границы 23 | между проектированием, конструированием и тестированием, так как все они 24 | связаны в единый комплекс процессов жизненного цикла и, в зависимости от 25 | выбранной модели жизненного цикла и применяемых методов (методологии), такое 26 | разделение может выглядеть по разному. 27 | 28 | Хотя ряд операций по проектированию детального дизайна может происходить до 29 | стадии конструирования, большой объем такого рода проектных работ происходит 30 | параллельно с конструированием или как его часть. Это есть суть связи с 31 | областью знаний “Проектирование программного обеспечения”. 32 | 33 | В свою очередь, на протяжении всей деятельности по конструированию, инженеры 34 | используют модульное и интеграционное тестирование. Таким образом связана 35 | данная область знаний с “Тестированием программного обеспечения”. 36 | 37 | В процессе конструирования обычно создается большая часть активов программного 38 | проекта - конфигурационных элементов (configuration items). Поэтому в реальных 39 | проектах просто невозможно рассматривать деятельность по конструированию в 40 | отрыве от области знаний “Конфигурационного управления” (Software Configuration 41 | Management). 42 | 43 | Так как конструирование невозможно без использования соответствующего 44 | инструментария и, вероятно, данная деятельность является наиболее 45 | инструментально-насыщенной, важную роль в конструировании играет область знаний 46 | “Инструменты и методы программной инженерии” (Software Engineering Tools and 47 | Methods). 48 | 49 | Безусловно, вопросы обеспечения качества значимы для всех областей знаний и 50 | этапов жизненного цикла. В то же время, код является основным результирующим 51 | элементом программного проекта. Таким образом, явно напрашивается и 52 | присутствует связь обсуждаемых вопросов с областью знаний “Качество 53 | программного обеспечения” (Software Quality). 54 | 55 | Из связанных дисциплин программной инженерии (Related Disciplines of Software 56 | Engineering) наиболее тесная и естественная связь данной области знаний 57 | существует с компьютерными науками (computer science). Именно в них, обычно, 58 | рассматриваются вопросы построения и использования алгоритмов и практик 59 | кодирования. Наконец, конструирование касается и управления проектами (project 60 | management), причем, в той степени, насколько деятельность по управлению 61 | конструированием важна для достижения результатов конструирования. 62 | 63 | ![Рисунок 4. Область знаний “Конструирование программного обеспечения” [SWEBOK, 2004, с.4-2, рис. 1]](images/construction_area.jpg) 64 | 65 | ## Основы конструирования (Software Construction Fundamentals) 66 | 67 | Фундаментальные основы конструирования программного обеспечения включают: 68 | 69 | - Минимизация сложности 70 | - Ожидание изменений 71 | - Конструирование с возможностью проверки 72 | - Стандарты в конструировании 73 | 74 | Первые три концепции применяются не только к конструированию, но и 75 | проектированию, и лежат в основе современных методологий управления жизненным 76 | циклом программных систем. 77 | 78 | ### Минимизация сложности (Minimizing Complexity) 79 | 80 | Основной причиной того, почему люди используют компьютеры в бизнес-целях, 81 | являются ограниченные возможности людей в обработке и хранении сложных структур 82 | и больших объемов информации, в частности, на протяжении длительного периода 83 | времени. Это соображение является одной из основных движущих сил в 84 | конструировании программного обеспечения: минимизация сложности. Потребность в 85 | уменьшении сложности влияет на все аспекты конструирования и особенно критична 86 | для процессов верификации (проверки) и тестирования результатов 87 | конструирования, т.е. самих программных систем. 88 | 89 | Уменьшение сложности в конструировании программного обеспечения достигается при 90 | уделении особого внимания созданию простого и легко читаемого кода, пусть и в 91 | ущерб стремлению сделать его идеальным (например, с точки зрения гибкости или 92 | следования тем или иным представлениям о красоте, утончённости кода, ловкости 93 | тех или иных приемов, позволяющих его сократить в ущерб размерам и т.п.). Это 94 | не значит, что должно ущемляться применение тех или иных развитых языковых 95 | возможностей используемых средств программирования. Это подразумевает “лишь” 96 | придание большей значимости читаемости кода, простоте тестирования, приемлемому 97 | уровню производительности и удовлетворению заданных критериев, вместо 98 | постоянного совершенствования кода, не оглядываясь на сроки, функциональность и 99 | другие характеристики и ограничения проекта. 100 | 101 | Минимизация сложности достигается, в частности, следованием стандартам 102 | (обсуждаются в теме 1.4 “Стандарты в конструировании”), использованием ряда 103 | специфических техник (освещаются в 3.3 “Кодирование”) и поддержкой практик, 104 | направленных на обеспечение качества в конструировании (3.5 “Качество 105 | конструирования”). 106 | 107 | ### Ожидание изменений (Anticipating Changes) 108 | 109 | Большинство программных систем изменяются с течением времени. Причин этому – 110 | множество. Ожидание изменений является одной из движущих сил конструирования 111 | программного обеспечения. Программное обеспечение не является изолированным от 112 | внешнего окружения (как системного, так и с точки зрения области деятельности, 113 | для автоматизации задач и проблем которого оно применяется). Более того, 114 | программные системы являются частью изменяющейся среды и должны меняться вместе 115 | с ней, а, иногда, и быть источником изменений самой среды. 116 | 117 | Ожидание изменений поддерживается рядом техник, представленных в теме 3.3 118 | “Кодирование”. 119 | 120 | ### Конструирование с возможностью проверки (Constructing for Verification) 121 | 122 | “Конструирование для проверки” (а именно такой смысл заложен в оригинальное 123 | название данной темы) предполагает, что построение программных систем должно 124 | вестись таким образом, чтобы сама программная система помогала вести поиск 125 | причин сбоев, будучи прозрачной для применения различных методов проверки (и, 126 | кстати, внесения необходимых изменений), как на стадии независимого 127 | тестирования (например, инженерами-тестировщиками), так и в процессе 128 | операционной деятельности - эксплуатации, когда особенно важна возможность 129 | быстрого обнаружения и исправления возникающих ошибок. 130 | 131 | Среди техник, направленных на достижение такого результата конструирования: 132 | 133 | - обзор, оценка кода (code review) 134 | - модульное тестирование (unit-testing) 135 | - структурирование кода для автоматизированных средств тестирования (automated testing) 136 | - ограниченное применение сложных или тяжелых для понимания языковых структур 137 | 138 | ### Стандарты в конструировании (Standards in Constructing) 139 | 140 | Стандарты, которые напрямую применяются при конструировании, включают: 141 | 142 | - коммуникационные методы (например, стандарты форматов документов и 143 | оформления содержания) 144 | - языки программирования и соответствующие стили кодирования (например, Java 145 | Language Specification, являющийся частью стандартной документации JDK – Java 146 | Development Kit и Java Style Guide, предлагающий общий стиль кодирования для 147 | языка программирования Java) 148 | - платформы (например, стандарты программных интерфейсов для вызовов функций 149 | операционной среды, такие как прикладные программные интерфейсы платформы 150 | Windows - Win32 API, Application Programming Interface или .NET Framework SDK, 151 | Software Development Kit) 152 | - инструменты (не в терминах сред разработки, но возможных средств 153 | конструирования – например, UML как один из стандартов для определения нотаций 154 | для диаграмм, представляющих структура кода и его элементов или некоторых 155 | аспектов поведения кода) 156 | 157 | Использование внешних стандартов. Конструирование зависит от внешних 158 | стандартов, связанных с языками программирования, используемым инструментальным 159 | обеспечением, техническими интерфейсами и взаимным влиянием Конструирования 160 | программного обеспечения и других областей знаний программной инженерии (в том 161 | числе, связанных дисциплин, например, управления проектами). Стандарты 162 | создаются разными источниками, например, консорциумом OMG – Object Management 163 | Group (в частности. Стандарты CORBA, UML, MDA, …), международными организациями 164 | по стандартизации такими, как ISO/IEC, IEEE, TMF, …, производителями платформ, 165 | операционных сред и т.д. (например, Microsoft, Sun Microsystems, CISCO, NOKIA, 166 | …), производителями инструментов, систем управления базами данных ит.п. 167 | (Borland, IBM, Microsoft, Sun, Oracle, ...). Понимание этого факта позволяет 168 | определить достаточный и полный набор стандартов, применяемых в проектной 169 | команде или организации в целом. 170 | 171 | Использование внутренних стандартов. Определенные стандарты, соглашения и 172 | процедуры могут быть также созданы внутри организации или даже проектной 173 | команды. Эти стандарты поддерживают координацию между определёнными видами 174 | деятельности, группами операций, минимизируют сложность (в том числе при 175 | взаимодействии членов проектной группы и за ее пределами), могут быть связаны с 176 | вопросами ожидания и обработки изменений, рисков и вопросами конструирования 177 | для проверки и дальнейшего тестирования. В сочетании со внешними стандартами, 178 | внутренние стандарты призваны определить общие правила игры для всех членов 179 | проектной команды, договорившись о терминах, процедурах и других значимых 180 | соглашениях, вне зависимости от степени формализации процессов конструирования, 181 | в частности, и процессов жизненного цикла, в общем случае. 182 | 183 | ## Управление конструированием (Managing Construction) 184 | 185 | ### Модели конструирования (Construction Models) 186 | 187 | Модели конструирования определяют комплекс операций, включающих 188 | последовательность, результаты (например, исходный код и соответствующие 189 | unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. В 190 | большинстве случаев, модели конструирования определяются используемым 191 | стандартом жизненного цикла, применяемыми методологиями и практиками. Некоторые 192 | стандарты жизненного цикла, по своей природе, являются ориентированными на 193 | конструирование – например, экстремальное программирование (XP- eXtreme 194 | Programming). Некоторые рассматривают конструирование в неразрывной связи с 195 | проектированием (в части моделирования), например, RUP (Rational Unified 196 | Process). 197 | 198 | Создано множество моделей разработки программного обеспечения. Ряд из них в 199 | большей степени сфокусирован на конструировании программного обеспечения, как 200 | таковом. 201 | 202 | Некоторые модели являются более линейными с точки зрения конструирования ПО. К 203 | ним относятся, например, водопадная (waterfall) и поэтапная (staged-delivery) 204 | модели жизненного цикла (моделям жизненного цикла посвящена специальная глава, 205 | написанная Сергеем Орликом и доступная как часть представленных здесь "Основ 206 | программной инженерии"). Эти модели рассматривают конструирование как 207 | деятельность, которая начинает проводиться только после завершения определенных 208 | обязательных к выполнению (prerequisite) работ, включающих детальное 209 | определение требований, подробный дизайн и детальное планирование. Более 210 | линейные подходы стараются подчеркнуть действия, предваряющие конструирование 211 | (т.е. требования и дизайн) и создать более четкое разделение между такими 212 | различными типами деятельности. В таких моделях основным содержанием 213 | конструирования может быть кодирование. 214 | 215 | Другие модели более итеративны, к ним относятся – эволюционное 216 | прототипирование, экстремальное программирование и Scrum. Эти подходы сходятся 217 | к рассмотрению конструирования как деятельности, которая ведется одновременно 218 | с другими видами работ по созданию программного обеспечения и пересекаясь с 219 | ними (видимо, здесь имеется в виду взаимозависимость и влияние друг на друга), 220 | включая определение требований, проектирование и планирование. Эти подходы 221 | смешивают проектирование, кодирование и тестирование, часто рассматривая их 222 | комбинацию как конструирование. 223 | 224 | Соответственно, что именно подразумевается под “конструированием” зависит в 225 | определенной степени от используемой модели жизненного цикла. 226 | 227 | ### Планирование конструирования (Construction Planning) 228 | 229 | Выбор метода (методологии) конструирования является ключевым аспектом для 230 | планирования конструкторской деятельности. Такой выбор значим для всей 231 | конструкторской деятельности, а также необходимых условий её осуществления, 232 | определяя порядок соответствующих операций и уровень выполнения заданных 233 | условий перед тем как начнется конструирование или составляющие его действия. 234 | Например, модульное тестирование в ряде методов является частью работ, после 235 | написания соответствующего функционального кода, в то время, как ряд гибких 236 | (agile) практик, например, XP (кстати, первыми начавшие использовать такие 237 | методы верификации кода), требуют написания Unit-тестов до того, как пишется 238 | соответствующий код, требующий тестирования. 239 | 240 | Используемый подход к конструированию влияет на возможность уменьшения (в 241 | идеале - минимизации) сложности, готовности к изменениям и конструировании с 242 | возможностью проверки. 243 | 244 | Планирование конструкторской деятельности определяет порядок, в котором 245 | создаются компоненты и другие активы данной области знаний (фазы деятельности), 246 | проводятся работы по обеспечению качества получаемого программного обеспечения, 247 | распределяются* задачи и соответствующие ресурсы, в том числе, определяются 248 | назначения/отображения работ конкретным инженерам-программистам, членам 249 | проектной группы. Все это, конечно, происходит, следуя правилам, определяемым 250 | используемым методом (методологией, практиками и т.п.). 251 | 252 | *Заметьте – не распределяют, а распределяются, подразумевая процесс, приводящий 253 | к обеспечению явной связи между задачей и ресурсами. В нечетко 254 | регламентированных (это ни в коем случае не ругательство, это определение – 255 | ведь существует же понятие нечёткая логика, неструктурированные базы данных, 256 | например, в отношении нереляционных систем и т.п.) и неформальных методах, 257 | таких, как XP, члены проектной группы сами принимают на себя ответственность по 258 | решению определенных задач, а “владение” кодом является совместным на основе 259 | сотрудничества, как одного из ключевых принципов работы проектной команды. 260 | 261 | ### Измерения в конструировании (Construction Measurement) 262 | 263 | Большая часть результатов, да и самой деятельности по конструированию 264 | программного обеспечения, может быть измерена, в том числе - количественно. Это 265 | и исходный разработанный код, и модифицированный объем кода, и степень 266 | повторного использования, и многие другие характеристики. Эти измерения, или 267 | как их еще принято называть – результаты аудита кода и метрики кода, несут 268 | большую пользу как для оценки рисков и качества (приводящих к соответствующим 269 | операциям по снижению рисков и повышению качества), а также, для управления 270 | конструированием и программными проектами, в целом. О каком планировании может 271 | идти речь, если мы не способны предсказать (например, на основе оценки 272 | результатов предыдущих проектов) ни длительность работ, ни стоимость отдельных 273 | задач, ни вероятность возникновения дефектов против заданных параметров 274 | приемлемого качества? 275 | 276 | Код является одним из наиболее четко детерминированных активов проекта 277 | (постепенно такими становятся и модели, строящиеся на основе структур 278 | метаданных, и тесно связанные с кодом - например, UML). Код является и самим 279 | носителям требуемой функциональности. Соответственно, применение измерений в 280 | отношении кода становится тем инструментом, который влияет и на управление и на 281 | сам код. 282 | 283 | Последнее время, большое внимание многие профессиональные разработчики, то есть 284 | инженеры-конструкторы программного обеспечения, выделяют рефакторинг кода, как 285 | методы его реструктурирования, призванные без изменения содержания (то есть 286 | функциональности и функциональной целостности) обеспечить решение задач 287 | минимизации сложности, готовности к изменениям (гибкости), прозрачности 288 | документирования и многих других актуальных аспектов конструирования. Но, к 289 | сожалению, многие забывают о необходимости мотивированности изменений, даже на 290 | уровне рефакторинга. Применение измерений, в частности, метрик, позволяет 291 | определить необходимость внесения таких изменений, проведения рефакторинга. И 292 | не потому что “так, наверное, будет всё же лучше, красивше...”, а потому, что в 293 | иерархии наследования из 10 поколений классов – 9 являются абстрактными (“из 294 | любви к искусству”), а на 10-м (в силу превышений сроков проекта, после того, 295 | как долго и “в кайф” создавали архитектурно-красивый код) “повешено” 20 (!) 296 | бизнес-методов. Вот это – действительно обоснованная причина для рефакторинга, 297 | который, даже с применением самых совершенных инструментальных средств, вместе 298 | с обдумыванием необходимости рефакторинга, а потом, иногда, и борьбой с его 299 | последствиями из-за несогласованности членов команды (а это уже жизнь, даже в 300 | самом идеальном коллективе, где люди понимают друг друга с полуслова) часто 301 | является просто тратой времени. Если применяется рефакторинг, но не применяются 302 | метрики – в подавляющем большинстве случаев, это отрицательно влияет на проект. 303 | И таких примеров работ, требующих применения измерений, но, к несчастью, 304 | игнорирующих их, можно приводить достаточно долго. Вы, наверняка, сами можете 305 | рассказать на эту тему много примеров из жизни. 306 | 307 | Почему “авторизованный перевод” этой темы SWEBOK оказался столь эмоционален? 308 | Практика автора показывает, что в погоне за “красотой”, разработчики слишком 309 | часто забывают о цели их работы и воспринимают деятельность по управлению 310 | проектами (не буду спорить, иногда лишь формальную, для “прикрытия” всего, что 311 | только можно …) со стороны менеджеров и, тем более, любой аудит – как 312 | однозначную помеху “полёту мысли”. Зря. Если все именно так обстоит в вашем 313 | случае – проект, с большой вероятностью, а иногда и просто, “если не случится 314 | чудо”, можно считать пусть и не провальным (“фуух... не закрыли....”), то, 315 | наверняка, выйдущим за рамки тех или иных ограничений, будь то сроки, деньги, 316 | качество или, наконец, время, которое разработчик мог провести с семьей. И не 317 | сидеть ночью, дописывая функциональность или отлавливая очередную ошибку за 318 | несколько дней до передачи проекта в эксплуатацию. Все эти вопросы преследуют 319 | одну единственную цель – предсказуемость работ и результата. И измерения – 320 | важный инструмент достижения этой цели. 321 | 322 | Область знаний “Software Engineering Process” уделяет специальное внимание 323 | вопросам измерений при создании программного обеспечения. 324 | 325 | ## Практические соображения (Practical Considerations) 326 | 327 | Конструирование – деятельность, в рамках которой программное обеспечение 328 | приводится к соглашению с произвольными (иногда - хаотическими) ограничениями 329 | реального мира, которые требуют от программного обеспечения точного следования 330 | им. Приближаясь к ограничениям реального мира, конструирование (в большей 331 | степени, чем любая другая область знаний) ведется на основе практических 332 | соображений и техник. 333 | 334 | ### Проектирование в конструировании (Construction Design) 335 | 336 | Некоторые проекты предполагают больший объем работ по проектированию именно на 337 | стадии конструирования; другие проекты явно выделяют проектную деятельность в 338 | форме фазы дизайна. Вне зависимости от четкости выделения деятельности по 339 | проектированию, как таковой, практически всегда на стадии конструирования 340 | приходится заниматься и вопросами детального дизайна системы. Такие проектные 341 | работы имеют стремление к следованию устойчивым ограничениям, навязываемым 342 | конкретными проблемами, решение которых должно быть обеспечено использованием 343 | конструируемой программной системы. 344 | 345 | Детали деятельности по проектированию на стадии конструирования в основном те 346 | же самые, что и описанные в области знаний “Проектирование программного 347 | обеспечения” (Software Design). Отличие заключается в большем внимании деталям. 348 | 349 | ### Языки конструирования (Construction Languages) 350 | 351 | Языки конструирования включают все формы коммуникаций, с помощью которых 352 | человек может задать решение проблемы, выполняемое на компьютере. 353 | 354 | Простейший тип языков конструирования – *конфигурационный язык (configuration 355 | language)*, позволяющий задавать параметры выполнения программной системы. 356 | 357 | *Инструментальный язык (toolkit language)* – язык конструирования из 358 | повторно-используемых элементов; обычно строится как сценарный язык (script), 359 | выполняемый в соответствующей среде. 360 | 361 | *Язык программирования (programming language)* – наиболее гибкий тип языков 362 | конструирования. Содержит минимальный объем информации о конкретных областях 363 | приложения и процессе разработки, требуя больше всего (по сравнению с другими 364 | типами языков конструирования) усилий на изучение и наработку опыта для 365 | эффективного применения при решении конкретных задач. 366 | 367 | Существует три основных вида нотаций используемых при определении языков 368 | программирования: 369 | 370 | - лингвистическая 371 | - формальная 372 | - визуальная 373 | 374 | *Лингвистические нотации* характеризуются, в частности, использованием строк 375 | текста, содержащих специализированные “слова”, представляющие сложные 376 | программные конструкции, и комбинируемые в шаблоны, напоминающие предложения, 377 | построенные в соответствии с определённым синтаксисом. В случае корректного 378 | использования таких нотаций, каждая получаемая строка обладает строгой 379 | смысловой нагрузкой (семантикой), обеспечивающей интуитивное понимание того, 380 | что будет происходить когда будет выполняться программное обеспечение, 381 | построенное с использованием такого языка конструирования. 382 | 383 | Формальные нотации являются менее интуитивными, чем лингвистические, и часто 384 | базируются на точных формальных (математических) определениях. Формальные 385 | нотации конструкций и формальные методы являются ядром практически всех форм 386 | системного программирования, точнее – поведения систем во времени. Такие 387 | нотации обеспечивают наибольшую готовность получаемого кода к тестированию, что 388 | намного важнее, чем просто возможность отображения на обычный человеческий 389 | язык. Формальные конструкции также используют точный метод определения 390 | комбинаций применяемых символов, что позволяет избежать неоднозначностей, 391 | присущих конструкциям естественных языков. 392 | 393 | *Визуальные нотации* наименее связаны с текстово-ориентированными подходами, 394 | предполагая непосредственную интерпретацию визуальных конструкций в процессе 395 | исполнения описываемой логики. При этом логика в визуальных нотациях задается 396 | расположением соответствующих визуальных сущностей, ответственных за те или 397 | иные операции и структуры данных. 398 | 399 | Использование визуальных конструкций ограничено сложностью визуального 400 | представления сложных выражений и утверждений только за счет перемещения 401 | визуальных сущностей на диаграмме (визуальном представлении). Однако, 402 | визуальная нотация может играть роль достаточно мощного инструмента, когда 403 | применяется в тех задачах программирования, где необходимо построение 404 | пользовательского интерфейса. 405 | 406 | Сегодняшние работы (и их состояние) в области архитектур и приложений, 407 | управляемых моделями, в первую очередь - OMG MDA (Model-Driven Architecture 408 | www.omg.org/mda)/UML (Unified Modeling Language www.omg.org/uml), Microsoft DSL 409 | (Domain-Specific Language), направлены на то, чтобы использовать ту или иную 410 | визуальную нотацию, базирующуюся на мета-моделях, в качестве инструмента, 411 | применяемого и для определения функциональной логики системы. Можно ли в чистом 412 | виде считать эти нотации именно визуальными - вопрос спорный. Но в терминах, 413 | предлагаемых SWEBOK, они относятся именно к визуальным нотациям, так как 414 | предполагают однозначную интерпретацию визуального представления в виде текста 415 | и наоборот. Кроме того, исторически эти нотации определялись изначально как 416 | нотации визуального представления функциональности и уже в дальнейшем эти 417 | визуальные представления были отражены на уровне соответствующих мета-моделей 418 | (хотя это в большей степени верно для UML, чем DSL, но DSL можно рассматривать 419 | и как аналог UML, предполагающий бо́льшую свободу применений и интегрированность 420 | с конкретной платформой - Microsoft). Другая область стандартов, направленных 421 | на применение визуальных нотаций для описания функциональности – Business 422 | Process Management Notation (BPMN - www.omg.org/bpmn) и связанный с ней язык 423 | Business Process Execution Language, построенный на базе XML. Таким образом, 424 | область обоснованного применения визуальных нотаций для конструирования 425 | программных систем качественно расшириться и, не исключено, мы станем 426 | свидетелями де-факто формирования новой категории нотаций, соглашений и 427 | смешанных типов языковых средств, предназначенных для конструирования 428 | программного обеспечения как естественного продолжения проектирования. 429 | 430 | ### Кодирование (Coding) 431 | 432 | Практика конструирования программного обеспечения показывает активное 433 | применение следующих соображений и техник: 434 | 435 | - техники создания легко понимаемого исходного кода на основе использования 436 | соглашений об именовании, форматирования и структурирования кода; 437 | - использование классов, перечисляемых типов, переменных, именованных констант 438 | и других выразительных сущностей; 439 | - организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и 440 | другие структуры) 441 | - использование структур управления; 442 | - обработка ошибочных условий и исключительных ситуаций; 443 | - предотвращение возможных брешей в безопасности (например, переполнение буфера 444 | или выход за пределы индекса в массиве) 445 | - использование ресурсов на основе применения механизмов исключения (из 446 | рассмотрения) и порядка доступа к параллельно используемым ресурсам (например, 447 | на основе блокировки данных, использования потоков и их синхронизации и т.п.) 448 | - документирование кода 449 | - тонкая “настройка” кода 450 | - рефакторинг (не упоминается SWEBOK) 451 | 452 | ### Тестирование в конструировании (Construction Testing) 453 | 454 | При конструировании используются две формы тестирования, проводимого 455 | инженерами, непосредственно создающими исходный код: 456 | 457 | - модульное тестирование (unit testing) 458 | - интеграционное тестирование (integration testing) 459 | 460 | Главная цель тестирования в конструировании уменьшить временной разрыв между 461 | моментом проявления ошибок, имеющихся в коде, и моментом их обнаружения. Во 462 | многих случаях, тестирование в конструировании производится после того, как код 463 | написан. В ряде случаев, тесты (что отмечалось ранее, на примере XP) пишутся до 464 | того, как создается код. 465 | 466 | Тестировании в конструировании обычно включает подмножество видов тестирования, 467 | описанных в области знаний “Тестирование программного обеспечения” (Software 468 | Testing). Например, тестирование в конструировании обычно не включает 469 | системного тестирования, нагрузочного тестирования, usability-тестирования 470 | (оценки прозрачности использования) и других видов тестовой деятельности. 471 | 472 | IEEE опубликовал два стандарта, посвященных данной теме: 473 | 474 | - IEEE Std 829-1998: “IEEE Standard for Software Test Documentation” 475 | - IEEE Std 1008-1987: “IEEE Standard for Software Unit Testing” 476 | 477 | Напрямую с данной темой связаны под-темы SWEBOK 2.1.1 “Unit Testing” и 2.1.2 478 | “Integration Testing”. 479 | 480 | ### Повторное использование (Reuse) 481 | 482 | Во введении в стандарт IEEE Std. 1517-99 “IEEE Standard for Information 483 | Technology – Software Lifecycle Process – Reuse Processes” даётся следующее 484 | понимание повторному использованию в программном обеспечении: “Реализация 485 | повторного использования программного обеспечения подразумевает и влечёт за 486 | собой нечто большее, чем просто создание и использование библиотек активов. Оно 487 | требует формализации практики повторного использования на основе интеграции 488 | процессов и деятельности по повторному использованию в сам жизненный цикл 489 | программного обеспечения.” В то же время, повторное использование достаточно 490 | важно и непосредственно при конструировании программных систем, что 491 | подчеркивается включением этой темы в обсуждаемую область знаний 492 | конструирования ПО. 493 | 494 | Задачи, связанные с повторным использованием в процессе конструирования и 495 | тестирования, включают: 496 | 497 | - выбор единиц (units), баз данных тестовых процедур, данных полученных в 498 | результате тестов и самих тестов, подлежащих повторному использованию 499 | - оценку потенциала повторного использования кода и тестов 500 | - отслеживание информации и создание отчетности по повторному использованию в 501 | новом коде, тестовых процедурах и данных, полученных в результате тестов. 502 | 503 | ### Качество конструирования (Construction Quality) 504 | 505 | Существует ряд техник, предназначенных для обеспечения качества кода, 506 | выполняемых по мере его конструирования. Основные техники обеспечения качества, 507 | используемые в процессе конструирования, включают: 508 | 509 | - модульное (unit) и интеграционное (integration) тестирование 510 | - разработка с первичностью тестов (test-first development - тесты пишутся до 511 | конструирования кода) 512 | - пошаговое кодирование (деятельность по конструированию кода разбивается на 513 | мелкие шаги, только после тестирования результатов которых производится переход 514 | к следующему шагу кодирования; известен также как итеративное кодирование с 515 | тестированием) 516 | - использование процедур утверждений (assertion) 517 | - отладка (в привычном понимании - debugging) 518 | - технические обзоры и оценки (review) 519 | - статический анализ 520 | 521 | Выбор и использование конкретных техник часто диктуется стандартами 522 | (внутренними и внешними), используемыми проектной командой, а также зависят от 523 | опыта и подготовленности специалистов, занимающихся конструированием кода. 524 | 525 | Деятельность по обеспечению качества в конструировании отличается от других 526 | операций по обеспечению качества. Основное отличие заключается в фокусе на 527 | программном (исходном) коде и других артефактах (активах), тесно связанных с 528 | кодом, в частности, детальных моделях. 529 | 530 | ### Интеграция (Integration) 531 | 532 | Одна из ключевых деятельностей, осуществляемых в процессе конструирования, - 533 | интеграция отдельно сконструированных операций (процедур), классов, компонентов 534 | и подсистем (модулей). В дополнение к этому, некоторые программные системы 535 | нуждаются в специальной интеграции с другим программным и аппаратным 536 | обеспечением. 537 | 538 | Кроме упомянутых аспектов интеграции, к обсуждаемым интеграционным вопросам 539 | конструирования относятся: 540 | 541 | - планирование последовательности, в которой интегрируются компоненты; 542 | - обеспечение поддержки создания промежуточных версий программного обеспечения; 543 | - задание “глубины” тестирования (в частности, на основе критериев 544 | “приемлемого” качества) и других работ по обеспечению качества интегрируемых в 545 | дальнейшем компонент; 546 | - наконец, определение этапных точек проекта, когда будут тестироваться 547 | промежуточные версии конструируемой программной системы. 548 | -------------------------------------------------------------------------------- /05_software_testing.md: -------------------------------------------------------------------------------- 1 | # Тестирование программного обеспечения 2 | 3 | Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - 4 | SWEBOK. 5 | 6 | Содержит перевод описания области знаний SWEBOK “Software Testing”, с 7 | замечаниями и комментариями. 8 | 9 | Тестирование (software testing) – деятельность, выполняемая для оценки и 10 | улучшения качества программного обеспечения. Эта деятельность, в общем случае, 11 | базируется на обнаружении дефектов и проблем в программных системах. 12 | 13 | Тестирование программных систем состоит из динамической верификации поведения 14 | программ на конечном (ограниченном) наборе тестов (set of test cases), 15 | выбранных соответствующим образом из обычно выполняемых действий прикладной 16 | области и обеспечивающих проверку соответствия ожидаемому поведению системы. 17 | 18 | В данном определении тестирования выделены слова, определяющие основные 19 | вопросы, которым адресуется данная область знаний: 20 | 21 | - Динамичность (dynamic): этот термин подразумевает тестирование всегда 22 | предполагает выполнение тестируемой программы с заданными входными данными. При 23 | этом, величины, задаваемые на вход тестируемому программному обеспечению, не 24 | всегда достаточны для определения теста. Сложность и недетерминированность 25 | систем приводит к тому, что система может по разному реагировать на одни и те 26 | же входные параметры, в зависимости от состояния системы. В данной области 27 | знаний термин “вход” (input) будет использоваться в рамках соглашения о том, 28 | что вход может также специфицировать состояние системы, в тех случаях, когда 29 | это необходимо. Кроме динамических техник проверки качества, то есть 30 | тестирования, существуют также и статические техники, рассматриваемые в области 31 | знаний “Software Quality”. 32 | - Конечность (ограниченность, finite): даже для простых программ теоретически 33 | возможно столь большое количество тестовых сценариев, что исчерпывающее 34 | тестирование может занять многие месяцы и даже годы. Именно поэтому, с 35 | практической точки зрения, всестороннее тестирование считается бесконечным. 36 | Тестирование всегда предполагает компромисс между ограниченными ресурсами и 37 | заданными сроками, с одной стороны, и практически неограниченными требованиями 38 | по тестированию, с другой. То есть мы снова говорим об определении 39 | характеристик “приемлемого” качества, на основе которых планируем необходимы 40 | объем тестирования. 41 | - Выбор (selection): многие предлагаемые техники тестирования отличаются друг 42 | от друга в том, как выбираются сценарии тестирования. Инженеры по программному 43 | обеспечению должны обладать представлением о том, что различные критерии выбора 44 | тестов могут давать разные результаты, с точки зрения эффективности 45 | тестирования. Определение подходящего набора тестов для заданных условий 46 | является очень сложной проблемой. Обычно, для выбора соответствующих тестов 47 | совместно применяют техники анализа рисков, анализ требований и соответствующую 48 | экспертизу в области тестирования и заданной прикладной области. 49 | - Ожидаемое поведение (expected behaviour): Хотя это не всегда легко, все же 50 | необходимо решить, какое наблюдаемое поведение программы будет приемлемо, а 51 | какое – нет. В противном случае, усилия по тестированию – бесполезны. 52 | Наблюдаемое поведение может рассматриваться в контексте пользовательских 53 | ожиданий (подразумевая “тестирования для проверки” - testing for validation), 54 | спецификации (“тестирование для аттестации” - testing for verification) или, 55 | наконец, в контексте предсказанного поведения на основе неявных требований или 56 | обоснованных ожиданий. См. тему SWEBOK 6.4 “Приемочные тесты” области знаний 57 | “Software Requirements”. 58 | 59 | Общий взгляд на тестирование программного обеспечения последние годы активно 60 | эволюционировал, становясь все более конструктивным, прагматичным и 61 | приближённым к реалиям современных проектов разработки программных систем. 62 | Тестирование более не рассматривается как деятельность, начинающаяся только 63 | после завершения фазы конструирования. Сегодня тестирование рассматривается как 64 | деятельность, которую необходимо проводить на протяжении всего процесса 65 | разработки и сопровождения и является важной частью конструирования программных 66 | продуктов. Действительно, планирование тестирования должно начинаться на ранних 67 | стадиях работы с требованиями, необходимо систематически и постоянно развивать 68 | и уточнять планы тестов и соответствующие процедуры тестирования. Даже сами по 69 | себе сценарии тестирования оказываются очень полезными для тех, кто занимается 70 | проектированием, позволяя выделять те аспекты требований, которые могут 71 | неоднозначно интерпретироваться или даже быть противоречивыми. 72 | 73 | Не секрет, что легче предотвратить проблему, чем бороться с ее последствиями. 74 | Тестирование, наравне с управлением рисками, является тем инструментом, который 75 | позволяет действовать именно в таком ключе. Причем действовать достаточно 76 | эффективно. С другой стороны, необходимо осознавать, что даже если приемочные 77 | тесты показали положительные результаты, это совсем не означает, что полученный 78 | продукт не содержит ошибок. Этим вопросам, в частности, адресована область 79 | знаний “Сопровождение программного обеспечения” (Software Maintenance). Однако, 80 | адекватное внимание вопросам тестирования качественно снижает риск 81 | возникновения ошибок на этапе эксплуатации, обеспечивая более высокую 82 | удовлетворенность пользователей, что и является, по существу, целью любого 83 | проекта. 84 | 85 | В области знаний “Качество программного обеспечения” (Software Quality) техники 86 | управления качеством четко разделены на статические (без выполнения кода) и 87 | динамические (с выполнением кода). Обе эти категории важны. Данная область 88 | знаний - “Тестирование” – касается динамических техник. 89 | 90 | Как уже отмечалось ранее, тестирование тесно связано с областью знаний 91 | “Конструирование” (Software Construction). Более того, модульное (unit-) и 92 | интеграционное тестирование все чаще рассматривают как неотъемлемый элемент 93 | деятельности по конструированию. 94 | 95 | ![Рисунок 5. Область знаний “Тестирование программного обеспечения” [SWEBOK, 2004, с.5-2, рис. 1]](images/testing_area_small.jpg) 96 | 97 | ## Основы тестирования (Software Testing Fundamentals) 98 | 99 | Охватывает основные понятия в области тестирования, базовые термины, ключевые 100 | проблемы и их связь другими областями деятельности и знаний. 101 | 102 | ### Терминология тестирования (Testing-Related Terminology) 103 | 104 | Определение тестирования и связанной терминологии достаточно полно даётся 105 | в “Глоссарии терминов по программной инженерии” – IEEE Standard 610-90 106 | (Standard Glossary of Software Engineering Terminology). 107 | 108 | #### Недостатки и сбои (Faults vs. Failures) 109 | 110 | В литературе, посвященной программной инженерии, встречается множество 111 | терминов, описывающих нарушение функционирования программных систем – 112 | недостатки (faults), дефекты (defects), сбои (failures), ошибки (errors) и др. 113 | Соответствующая терминология, как было указано выше в 1.1.1, описана в IEEE 114 | Std. 610-90 также обсуждается в области знаний SWEBOK “Качество программного 115 | обеспечения” (Software Quality). Важно чётко разделять причину нарушения работы 116 | прикладных систем, обычно описываемую терминами недостаток или дефект, и 117 | наблюдаемый нежелательный эффект, вызываемый этими причинами – сбой. Термин 118 | ошибка, в зависимости от контекста, может описывать и как причину сбоя, и сам 119 | сбой. Тестирование позволяет обнаружить дефекты, приводящие к сбоям. 120 | 121 | Необходимо понимать, что причина сбоя не всегда может быть однозначно 122 | определена. Не существует теоретических критериев, позволяющих гарантированно 123 | определить какой именно дефект приводит к наблюдаемому сбою. 124 | 125 | ### Ключевые вопросы (Key Issues) 126 | 127 | #### Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования (Test selection criteria/test adequacy criteria, or stopping rules) 128 | 129 | Критерии отбора тестов могут использоваться как для создания набора тестов, так 130 | и для проверки, насколько выбранные тесты адекватны решаемым задачам 131 | (тестирования). При этом, обсуждаемые критерии помогают определить, когда можно 132 | или необходимо прекратить тестирование. 133 | 134 | #### Эффективность тестирования/Цели тестирования (Test effectiveness/Objectives for testing) 135 | 136 | Тестирование – это наблюдение за выполнением программы, запущенной в целях 137 | тестирования с заданными параметрами, по заданному сценарию или с другими 138 | заданными начальными условиями или целями тестирования. Эффективность теста 139 | может быть определена только в контексте заданных условий. 140 | 141 | #### Тестирование для идентификации дефектов (Testing for defect identification) 142 | 143 | Данный случай тестирования подразумевает успешность процедуры тестирования, 144 | если дефект найден. Это отличается от подхода в тестировании, когда тесты 145 | запускаются для демонстрации того, что программное обеспечение удовлетворяет 146 | предъявляемым требованиями и, соответственно, тест считается успешным, если не 147 | найдено дефектов. 148 | 149 | #### Проблема оракула (The oracle problem) 150 | 151 | “Оракул”, в данном контексте, любой агент (человек или программа), оценивающий 152 | поведение программы, формулируя вердикт - тест пройден (“pass”) или нет 153 | (“fail”). 154 | 155 | #### Теоретические и практические ограничения тестирования (Theoretical and practical limitation of testing) 156 | 157 | Теория тестирования выступает против необоснованного уровня доверия к серии 158 | успешно пройденных тестов. К сожалению, большинство установленных результатов 159 | теории тестирования – негативны, означая, по словам Дейкстры (Dijkstra), то, 160 | что “тестирование программы может использоваться для демонстрации наличия 161 | дефектов, но никогда не покажет их отсутствие”. Основная причина этого в том, 162 | что полное (всеобъемлющее) тестирование недостижимо для реального программного 163 | обеспечения. 164 | 165 | #### Проблема неосуществимых путей (The problem of infeasible paths) 166 | 167 | Эта сложнейшая проблема автоматизированного тестирования связана с тем, что 168 | путь, по которому выполняются потоки работ тестируемой программной системы, не 169 | могут быть заданы входными параметрами. 170 | 171 | #### Тестируемость (Testability) 172 | 173 | Это понятие может подразумевать две различных идеи. Первая описывает степень 174 | легкости описания критериев покрытия тестами для заданной программной системы. 175 | Вторая определяет возможность вероятность, возможность статистического 176 | измерения того, что при тестировании проявится сбой программной системы. Обе 177 | интерпретации этого понятия одинаково важны для тестирования. 178 | 179 | ### Связь тестирования с другой деятельностью (Relationships of testing with other activities) 180 | 181 | Тестирование программного обеспечения отличается от статических техник 182 | управления качеством, проверки корректности, отладки и программирования, но 183 | связано со всеми этими работами. Полезно рассматривать тестирование с точки 184 | зрения аналитиков и специалистов по сертификации качества. 185 | 186 | ## Уровни тестирования (Test Levels) 187 | 188 | ### Над чем производятся тесты (The target of the test) 189 | 190 | Тестирование обычно производится на протяжении всей разработки и сопровождения 191 | на разных уровнях. Уровень тестирования определяет “над чем” производятся 192 | тесты: над отдельным модулем, группой модулей или системой, в целом. При этом 193 | ни один из уровней тестирования не может считаться приоритетным. Важны все 194 | уровни тестирования, вне зависимости от используемых моделей и методологий. 195 | 196 | #### Модульное тестирование (Unit testing) 197 | 198 | Этот уровень тестирования позволяет проверить функционирование отдельно взятого 199 | элемента системы. Что считать элементом – модулем системы определяется 200 | контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 201 | “Standard for Software Unit Testing”, задающем интегрированную концепцию 202 | систематического и документированного подхода к модульному тестированию. 203 | 204 | #### Интеграционное тестирование (Integration testing) 205 | 206 | Данный уровень тестирования является процессом проверки взаимодействия между 207 | программными компонентами/модулями. 208 | 209 | Классические стратегии интеграционного тестирования – “сверху-вниз” и 210 | “снизу-вверх” – используются для традиционных, иерархически структурированных 211 | систем и их сложно применять, например, к тестированию слабосвязанных систем, 212 | построенных в сервисно-ориентированных архитектурах (SOA). 213 | 214 | Современные стратегии в большей степени зависят от архитектуры тестируемой 215 | системы и строятся на основе идентификации функциональных “потоков” (например, 216 | потоков операций и данных). 217 | 218 | Интеграционное тестирование – постоянно проводимая деятельность, предполагающая 219 | работу на достаточно высоком уровне абстракции. Наиболее успешная практика 220 | интеграционного тестирования базируется на инкрементальном подходе, позволяющем 221 | избежать проблем проведения разовых тестов, связанных с тестированием 222 | результатов очередного длительного этапа работ, когда количество выявленных 223 | дефектов приводит к серьезной переработке кода (традиционно, негативный опыт 224 | выпуска и тестирования только крупных релизов называют “big bang”). 225 | 226 | #### Системное тестирование (System testing) 227 | 228 | Системное тестирование охватывает целиком всю систему. Большинство 229 | функциональных сбоев должно быть идентифицировано еще на уровне модульных и 230 | интеграционных тестов. В свою очередь, системное тестирование, обычно 231 | фокусируется на нефункциональных требованиях – безопасности, 232 | производительности, точности, надежности т.п. 233 | 234 | На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному 235 | обеспечению, операционной среде и т.д. 236 | 237 | ### Цели тестирования (Objectivies of Testing) 238 | 239 | Тестирование проводится в соответствии с определёнными целями (могут быть 240 | заданы явно или неявно) и различным уровнем точности. Определение цели точным 241 | образом, выражаемым количественно, позволяет обеспечить контроль результатов 242 | тестирования. 243 | 244 | Тестовые сценарии могут разрабатываться как для проверки функциональных 245 | требований (известны как функциональные тесты), так и для оценки 246 | нефункциональных требований. При этом, существуют такие тесты, когда 247 | количественные параметры и результаты тестов могут лишь опосредованно говорить 248 | об удовлетворении целям тестирования (например, “usability” – легкость, 249 | простота использования, в большинстве случаев, не может быть явно описана 250 | количественными характеристиками). 251 | 252 | Можно выделить следующие, наиболее распространенные и обоснованные цели (а, 253 | соответственно, виды) тестирования: 254 | 255 | #### Приёмочное тестирование (Acceptance/qualification testing) 256 | 257 | Проверяет поведение системы на предмет удовлетворения требований заказчика. Это 258 | возможно в том случае, если заказчик берет на себя ответственность, связанную с 259 | проведением таких работ, как сторона “принимающая” программную систему, или 260 | специфицированы типовые задачи, успешная проверка (тестирование) которых 261 | позволяет говорить об удовлетворении требований заказчика. 262 | 263 | Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них. 264 | 265 | #### Установочное тестирование (Installation testing) 266 | 267 | Из названия следует, что данные тесты проводятся с целью проверки процедуры 268 | инсталляции системы в целевом окружении. 269 | 270 | #### Альфа- и бета-тестирование (Alpha and beta testing) 271 | 272 | Перед тем, как выпускается программное обеспечение, как минимум, оно должно 273 | проходить стадии альфа (внутреннее пробное использование) и бета (пробное 274 | использование с привлечением отобранных внешних пользователей) версий. Отчеты 275 | об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в 276 | соответствии с определёнными процедурами, включающими подтверждающие тесты 277 | (любого уровня), проводимые специалистами группы разработки. 278 | 279 | Данный вид тестирования не может быть заранее спланирован. 280 | 281 | #### Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing) 282 | 283 | Эти тесты могут называться по разному, однако, их суть проста – проверка 284 | соответствия системы, предъявляемым к ней требованиям, описанным на уровне 285 | спецификации поведенческих характеристик. 286 | 287 | #### Достижение и оценка надежности (Reliability achievement and evaluation) 288 | 289 | Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение 290 | надежности программных систем. Случайно генерируемые сценарии тестирования 291 | могут применяться для статистической оценки надежности. Обе цели – повышение и 292 | оценка надежности – могут достигаться при использовании моделей повышения 293 | надежности. Эти вопросы затрагиваются и в тематическом фрагменте 4.1.4 “Life 294 | test, reliability evaluation”. 295 | 296 | #### Регрессионное тестирование (Regression testing) 297 | 298 | Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of 299 | Software Engineering Terminology”) гласит: “повторное выборочное тестирование 300 | системы или компонент для проверки сделанных модификаций не должно приводить к 301 | непредусмотренным эффектам”. На практике это означает, что если система успешно 302 | проходила тесты до внесения модификаций, она должна их проходит и после 303 | внесения таковых. Основная проблема регрессионного тестирования заключается в 304 | поиске компромисса между имеющимися ресурсами и необходимостью проведения таких 305 | тестов по мере внесения каждого изменения. В определенной степени, задача 306 | состоит в том, чтобы определить критерии “масштабов” изменений, с достижением 307 | которых необходимо проводить регрессионные тесты. 308 | 309 | #### Тестирование производительности (Performance testing) 310 | 311 | Специализированные тесты проверки удовлетворения специфических требований, 312 | предъявляемых к параметрам производительности. Существует особый подвид таких 313 | тестов, когда делается попытка достижения количественных пределов, 314 | обусловленных характеристиками самой системы и ее операционного окружения. 315 | 316 | #### Нагрузочное тестирование (Stress testing) 317 | 318 | Необходимо понимать отличия между рассмотренным выше тестированием 319 | производительности с целью достижения ее реальных (достижимых) возможностей 320 | производительности и выполнением программной системы c повышением нагрузки, 321 | вплоть до достижения запланированных характеристик и далее, с отслеживанием 322 | поведения на всем протяжении повышения загрузки системы. 323 | 324 | #### Сравнительное тестирование (Back-to-back testing) 325 | 326 | Единичный набор тестов, позволяющих сравнить две версии системы. 327 | 328 | #### Восстановительные тесты (Recovery testing) 329 | 330 | Цель – проверка возможностей рестарта системы в случае непредусмотренной 331 | катастрофы (disaster), влияющей на функционирование операционной среды, в 332 | которой выполняется система. 333 | 334 | #### Конфигурационное тестирование (Configuration testing) 335 | 336 | В случаях, если программное обеспечение создается для использования различными 337 | пользователями (в терминах “ролей”), данный вид тестирования направлен на 338 | проверку поведения и работоспособности системы в различных конфигурациях. 339 | 340 | #### Тестирование удобства и простоты использования (Usability testing) 341 | 342 | Цель – проверить, насколько легко конечный пользователь системы может ее 343 | освоить, включая не только функциональную составляющую – саму систему, но и ее 344 | документацию; насколько эффективно пользователь может выполнять задачи, 345 | автоматизация которых осуществляется с использованием данной системы; наконец, 346 | насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от 347 | ошибок пользователя. 348 | 349 | #### Разработка, управляемая тестированием (Test-driven development) 350 | 351 | По-сути, это не столько техника тестирования, сколько стиль организации 352 | процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью 353 | требований (и соответствующих спецификаций) вместо того, чтобы рассматриваться 354 | независимой деятельностью по проверке удовлетворения требований программной 355 | системой. 356 | 357 | Иногда говорят о таком стиле разработки как о самостоятельной методологии – 358 | TDD. Насколько это верно, зависит от того, что именно понимать под методологией 359 | разработки. Скорее, с точки зрения автора, это техника, практика или стиль 360 | организации работы, чем самостоятельная методология. 361 | 362 | В меньшей степени это относится к FDD – Feature-Driven Development (разработка 363 | на основе функциональных возможностей). TDD может естественно рассматриваться 364 | как составная часть XP или, как минимум Agile-методов. В свою очередь, FDD 365 | может рассматриваться как один из методов гибкой разработки. 366 | 367 | В чем отличие столь близких, на первый взгляд, подходов (и, кстати, 368 | соответствующих аббревиатур)? Причина – проста. Тесты – инструмент достижения 369 | характеристик системы, удовлетворяющей заданным требованиям, то есть 370 | потребностям пользователей, а “возможности” (features) – практически сами (чаще 371 | – функциональные) требования, воплощенные (в идеальном случае) в код. 372 | 373 | ## Техники тестирования (Test Techniques) 374 | 375 | ### Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuition and experience) 376 | 377 | #### Специализированное тестирование (Ad hoc testing) 378 | 379 | Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, 380 | интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся 381 | ранее аналогий. Данный вид тестирования может быть полезен для идентификации 382 | тех тестов, которые не охватываются рассматривавшимеся выше более 383 | формализованными техниками. 384 | 385 | #### Исследовательское тестирование (Exploratory testing) 386 | 387 | Такое тестирование определяется как одновременное обучение, проектирование 388 | теста и его исполнение. Данный вид тестирования заранее не определяется в плане 389 | тестирования и такие тесты создаются, выполняются и модифицируются динамически, 390 | по мере необходимости. Эффективность исследовательских тестов напрямую зависит 391 | от знаний инженера, формируемых на основе поведения тестируемого продукта в 392 | процессе проведения тестирования, степени знакомства с приложением, платформой, 393 | типами возможных сбоев и дефектов, рисками, ассоциированными с конкретным 394 | продуктом и т.п. 395 | 396 | ### Техники, базирующиеся на спецификации (Specification-based techniques) 397 | 398 | #### Эквивалентное разделение приложения (Equivalence partitioning) 399 | 400 | Рассматриваемая область приложения разделяется на коллекцию наборов или 401 | эквивалентных классов, которые считаются эквивалентными с точки зрения 402 | рассматриваемых связей и характеристик спецификации. Репрезентативный набор 403 | тестов (иногда – только один тест) формируется из тестов эквивалентных классов 404 | (или наборов классов). 405 | 406 | #### Анализ граничных значений (Boundary-value analysis) 407 | 408 | Тесты строятся с ориентацией на использование тех величин, которые определяют 409 | предельные характеристики тестируемой системы. Расширением этой техники 410 | являются тесты оценки живучести (robustness testing) системы, проводимые с 411 | величинами, выходящими за рамки специфицированных пределов значений. 412 | 413 | #### Таблицы принятия решений (Decision table) 414 | 415 | Такие таблицы представляют логические связи между условиями (могут 416 | рассматриваться в качестве “входов”) и действиями (могут рассматриваться как 417 | “выходы”). Набор тестов строится последовательным рассмотрением всех возможных 418 | кросс-связей в такой таблице. 419 | 420 | #### Тесты на основе конечного автомата (Finite-state machine-based) 421 | 422 | Строятся как комбинация тестов для всех состояний и переходов между 423 | состояниями, представленных в соответствующей модели (переходов и состояний 424 | приложения). 425 | 426 | #### Тестирование на основе формальной спецификации (Testing from formal specification) 427 | 428 | Для спецификации, определенных с использованием формального языка, возможно 429 | автоматически создавать и тесты для функциональных требований. В ряде случаев 430 | могут строится на основе модели, являющейся частью спецификации, не 431 | использующей формального языка описания. 432 | 433 | #### Случайное тестирование (Random testing) 434 | 435 | В отличие от статистического тестирования (будет рассматриваться в 3.5.1 436 | “Operational profile”), сами тесты генерируются случайным образом по списку 437 | заданного набора специфицированных характеристик. 438 | 439 | ### Техники, ориентированные на код (Code-based techniques) 440 | 441 | #### Тесты, базирующиеся на блок-схеме (Control-flow-based criteria) 442 | 443 | Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В 444 | какой-то степени напоминает тесты на основе конечного автомата. Отличие – в 445 | источнике набора тестов. Максимальная отдача от тестов на основе блок-схемы 446 | получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии 447 | потоков работ (поведения) тестируемой системы. Адекватность таких тестов 448 | оценивается как процент покрытия всех возможных путей блок-схемы. 449 | 450 | #### Тесты на основе потоков данных (Data-flow-based criteria) 451 | 452 | В данных тестах отслеживается полный жизненный цикл величин (переменных) – с 453 | момента рождения (определения), на всем протяжении использования, вплоть до 454 | уничтожения (неопределенности). В реальной практике используются нестрогое 455 | тестирование такого вида, ориентированное, например, только на проверку задания 456 | начальных значений всех переменных или всех вхождений переменных в код, с точки 457 | зрения их использования. 458 | 459 | #### Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph) 460 | 461 | Является не столько техникой тестирования, сколько контролем структуры 462 | программы, представленной в виде дерева вызовов (например, sequence-диаграммы, 463 | определенной в нотации UML и построенной на основе анализа кода). 464 | 465 | ### Тестирование, ориентированное на дефекты (Fault-based techniques) 466 | 467 | Как это ни странно звучит на уровне названия таких техник тестирования, они, 468 | действительно, ориентированы на ошибки. Точнее – на специфические категории 469 | ошибок. 470 | 471 | #### Предположение ошибок (Error guessing) 472 | 473 | Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, 474 | в результате анализа рисков. 475 | 476 | #### Тестирование мутаций (Mutation testing) 477 | 478 | Мутация – небольшое изменение тестируемой программы, произошедшее за счет 479 | частных синтаксических изменений кода (в частности, рефакторинга). 480 | Соответствующие тесты запускаются для оригинального и всех “мутировавших” 481 | вариантов тестируемой программы. 482 | 483 | SWEBOK фокусируется на возможности, с помощью тестов, определять отличия между 484 | мутантами и исходным вариантом кода. Если такое отличие установлено, мутанта 485 | “убивают”, а тест считается успешным. Обычно, данный подход фокусируется на 486 | синтаксических ошибках, на практике отслеживаемых современными средами 487 | разработки и, конечно, компиляторами. 488 | 489 | ### Техники, базирующиеся на условиях использования (Usage-based techniques) 490 | 491 | #### Операционный профиль (Operational profile) 492 | 493 | Базируется на условиях использования системы. 494 | 495 | Тестирование для оценки надёжности системы должно проводиться в таком тестовом 496 | окружении, которое максимально приближено к реальным условиям работы системы. 497 | Результаты таких тестов позволяют оценить поведение системы в реальных 498 | условиях. Входные параметры тестов задаются на основе вероятностного 499 | распределения соответствующих параметров или их наборов при эксплуатации 500 | (входные данные могут прогнозироваться исходя из частоты возможных сценариев 501 | работы пользователей). 502 | 503 | #### Тестирование, базирующееся на надежности инженерного процесса (Software Reliability Engineered Testing) 504 | 505 | Базируется на условиях разработки системы. 506 | 507 | Соответствующие тесты (обозначаемые также аббревиатурой SRET от Software 508 | Reliability Engineered Testing) проектируются в контексте используемого 509 | процесса разработки и методик тестирования. 510 | 511 | ### Техники, базирующиеся на природе приложения (Techniques based on the nature of the application) 512 | 513 | Описанные выше техники могут применяться к любым типам программных систем. В то 514 | же время, в зависимости от технологической или архитектурной природы 515 | приложений, могут также применять специфические техники, важные именно для 516 | заданного типа приложения. Среди таких техник: 517 | 518 | - Объектно-ориентированное тестирование 519 | - Компонентно-ориентированное тестирование 520 | - Web-ориентированное тестирование 521 | - Тестирование на соответствие протоколам 522 | - Тестирование систем реального времени 523 | 524 | ### Выбор и комбинация различных техник (Selecting and combining techniques) 525 | 526 | #### Функциональное и структурное (Functional and structural) 527 | 528 | Техники тестирования, строящиеся на основе спецификаций или кода часто называют 529 | функциональными или структурными, соответственно. Оба подхода не должны 530 | противопоставляться, но дополнять друг друга. 531 | 532 | #### Определенное или случайное (Deterministic vs. random) 533 | 534 | Обычно тесты можно распределить по данным группам на основе используемой 535 | политики выбора или определения входных параметров тестов. 536 | 537 | ## Измерение результатов тестирования (Test-related measures) 538 | 539 | Часто техники тестирования путают с целями тестирования. Степень покрытия 540 | тестами - не то же самое, что высокое качество тестируемой системы. Однако, эти 541 | вопросы связаны. Чем выше степень покрытия, чем больше вероятность обнаружения 542 | скрытых дефектов. Когда мы говорим о результатах тестирования, мы должны 543 | подходить к их оценке, как оценке самой тестируемой системы. Именно 544 | количественные оценки результатов тестирования (но не самих тестов, например, 545 | покрытия ими возможных сценариев работы системы) освещаются ниже. В свою 546 | очередь, метрики самих тестов или процесса тестирования, как такового – 547 | вопросы, рассматриваемые в областях знаний “Процессы программной инженерии” 548 | (Software Engineering Process) и “Управление инженерной деятельностью” 549 | (Software Engineering Management). 550 | 551 | Измерения являются инструментом анализа качества. Измерение результатов 552 | тестирования касается оценки качества получаемого продукта – программной 553 | системы. История измерений демонстрирует прогресс достижения приемлемого 554 | качества. Такая история является инструментом менеджмента качества. 555 | 556 | ### Оценка программ в процессе тестирования (Evaluation of the program under test, IEEE 982.1-98) 557 | 558 | #### Измерения программ как часть планирования и разработки тестов (Program measurements to aid in planning and design testing) 559 | 560 | Данные измерения могут базироваться на размере программ (например, в терминах 561 | количества строк кода или функциональных точек) или их структуре (например, с 562 | точки зрения оценки ее сложности в тех или иных архитектурных терминах). 563 | Структурные измерения могут также включать частоту обращений одних модулей 564 | программы к другим. 565 | 566 | #### Типы дефектов, их классификация и статистика возникновения (Fault types, classification and statistics) 567 | 568 | В литературе по тестированию встречается большое количество различных 569 | классификаций дефектов. Эффективность тестирования может быть достигнута в том 570 | случае, если мы понимаем какие типы дефектов могут быть найдены в процессе 571 | тестирования программной системы и как изменяется их частота во времени 572 | (подразумевая историческую перспективу развития системы, а не её сбоев в 573 | процессе работы). Эта информация позволяет прогнозировать качество системы и 574 | помогает совершенствовать процесс разработки, в целом. 575 | 576 | Стандарт IEEE 1044-93 классифицирует возможные программные “аномалии”. 577 | 578 | #### Плотность дефектов (Fault density) 579 | 580 | Тестируемая программа может оцениваться на основе подсчета и классификации 581 | найденных дефектов. Для каждого класса дефектов можно определить отношение 582 | между количеством соответствующих дефектов и размером программы (в терминах 583 | выбранных метрик оценки размера). 584 | 585 | #### Жизненный цикл тестов, оценка надежности (Life test, reliability evaluation) 586 | 587 | Статистические ожидания в отношении надежности программной системы (см. выше 588 | 2.2.5 “Достижение и оценка надежности”) могут использоваться для принятия 589 | решения о продолжении или прекращении (окончании) тестирования, исходя из 590 | заданных параметров приемлемого качества (например, плотности дефектов 591 | заданного класса). 592 | 593 | #### Модели роста надежности (Reliability growth models) 594 | 595 | Данные модели обеспечивают возможности прогнозирования надежности системы, 596 | базируясь на обнаруженных сбоях (см. выше 2.2.5). Модели такого рода 597 | разбиваются на две группы – по количеству сбоев (failure-count) и времени между 598 | сбоями (time-between-failure). 599 | 600 | ### Оценка выполненных тестов (Evaluation of the tests performed) 601 | 602 | #### Метрики покрытия/глубины тестирования (Coverage/thoroughness measures) 603 | 604 | Критерии “адекватности” тестирования, в ряде случаев, требуют систематического 605 | выполнения тестов для определенных набора элементов программы, задаваемых ее 606 | архитектурой или спецификацией. Соответствующие метрики позволяют оценить 607 | степень охвата характеристик системы (например, процент различных тестируемых 608 | параметров производительности) и глубину их детализации (например, случайное 609 | тестирование параметров производительности или с учетом граничных значений и 610 | т.п.). Такие метрики помогают прогнозировать вероятностное достижение заданных 611 | параметров качества системы. 612 | 613 | #### Введение искусственных дефектов (Fault seeding) 614 | 615 | “Своими руками?! Никогда! ...” – такова, обычно, первая реакция на идею 616 | искусственного внесения дефектов, например, в программный код. На практике, 617 | этот подход помогает классифицировать возможные ошибки и следующие за ними 618 | сбои, применяя в дальнейшем полученные результаты для моделирования (пусть, 619 | часто, и интуитивного) возможных причин реальных сбоев, обнаруженных в процессе 620 | тестирования. 621 | 622 | Безусловно, данная техника должна использоваться с максимальной осторожностью 623 | опытными специалистами, хорошо представляющими общую архитектуру тестируемой 624 | программной системы и разбирающимеся во её внутренних связях. 625 | 626 | #### Оценка мутаций (Mutation score) 627 | 628 | Получаемое в процессе тестирования мутаций (см. выше 3.4.2) отношение “убитых” 629 | к общему числу сгенерированных мутантов помогает измерить эффективность 630 | выполняемых тестов. В силу специфики такой техники тестирования, количественные 631 | оценки мутаций имеют практическое значение только для определенных типов 632 | систем. 633 | 634 | #### Сравнение и относительная эффективность различных техник тестирования (Comparison and relative effectiveness of different techniques) 635 | 636 | Различные исследования в области тестирования связаны с попытками сравнения (с 637 | точки зрения достигаемого качества продукта) разных подходов к тестированию. 638 | Когда мы говорим об “эффективности” тестирования надо чётко договориться, что 639 | именно мы подразумеваем под эффективностью, желательно, в количественном 640 | выражении. Возможные варианты интерпретации этого понятия – число тестов 641 | (данной техники), необходимых для обнаружения первого дефекта; отношение 642 | количества всех обнаруженных дефектов к дефектам, найденным с применением 643 | заданного подхода и т.п. Только обладая такого рода данными можно говорить о 644 | корректности сравнения и оценки эффективности. 645 | 646 | ## Процесс тестирования (Test Process) 647 | 648 | Концепции, стратегии, техники и измерения тестирования должны быть объединены в 649 | единый процесс тестирования как деятельности по обеспечению качества. Процесс 650 | тестирования поддерживает работы по тестированию и определяет “правила игры” 651 | для членов команды тестирования – от планирования тестов до оценки их 652 | результатов. Хотя, в большинстве современных методов разработки, в частности, 653 | гибких (agile) подходов, тестирование выходит на передний план и является одной 654 | из базовых практик, многостороннее тестирование и, тем более, прогнозирование 655 | на основе полученных результатов, часто подменяется отдельными работами в этой 656 | области, не позволяющими добиться необходимых параметров качества (что, кстати, 657 | ясно показывают уже упоминавшиеся результаты исследований Standish Group 658 | [Chaos, 2004]). Только в том случае, если тестирование рассматривать как один 659 | из важных процессов всей деятельности по созданию и поддержке программного 660 | обеспечения, можно добиться оценки стоимости соответствующих работ и, в конце 661 | концов, соблюсти те ограничения, которые определены для проекта. 662 | 663 | ### Практические соображения (Practical considerations) 664 | 665 | #### Программирование без персоналий (Attitudes/Egoless programming) 666 | 667 | Очень важным компонентом успешного тестирования является совместное стремление 668 | участников проекта обеспечить необходимое качество продукта. Менеджеры играют 669 | ключевую роль в организации этой деятельности и на стадии разработки и в 670 | процессе сопровождения программных систем. 671 | 672 | #### Руководства по тестированию (Test guides) 673 | 674 | Работы по тестированию могут руководствоваться различными соображениями и 675 | критериями – от управления рисками до специфицированных сценариев работы 676 | программных систем. В любом случае, желательно, исходя из ресурсов, 677 | количественных оценок и других характеристик, обеспечить использование 678 | различных техник тестирования для многосторонней оценки и улучшения качества 679 | получаемого продукта. 680 | 681 | #### Управление процессом тестирования (Test process management) 682 | 683 | Работы по тестированию, ведущиеся на разных уровнях (см. выше 2. “Уровни 684 | тестирования”), должны быть организованы в единый (однозначно интерпретируемый) 685 | процесс, на основе учета 4 элементов и связанных с ними факторов: людей (в том 686 | числе, в контексте организационной структуры и культуры), инструментов, 687 | регламентов и количественных оценок (измерений). Стандарт жизненного цикла 688 | IEEE, ISO/IEC, ГОСТ Р 12207 не выделяет деятельность по тестированию в качестве 689 | самостоятельного процесса, однако, рассматривает соответствующие принципы работ 690 | по тестированию как неотъемлемую часть процессов жизненного цикла и 691 | сопровождения программных систем. В другом распространённом стандарте IEEE 1074 692 | деятельность по тестированию также объединена с другими оценочными работами как 693 | интегральная часть полного жизненного цикла. 694 | 695 | #### Документирование тестов и рабочего продукта (Test documentation and work products) 696 | 697 | Документация – составная часть формализации процесса тестирования. Существует 698 | стандарт IEEE 829-98 “Standard for Software Test Documentation”, 699 | предоставляющий прекрасное описание тестовых документов, их связей между собой 700 | и с процессом тестирования. Среди таких документов могут быть: 701 | 702 | - План тестирования 703 | - Спецификация процедуры тестирования 704 | - Спецификация тестов 705 | - Лог тестов 706 | - и др. 707 | 708 | Документирование тестов, в случае его формального ведения, должно быть 709 | актуальным. В противном случае, как и любые другие документы, документация по 710 | тестированию ляжет “мертвым грузом”. В то же время, деятельность по 711 | тестированию, в случае отсутствия соответствующих регламентов и результатов (в 712 | том числе, исторических, для разных проектов), сложно поддается оценке для 713 | прогнозирования и, тем более, улучшению - в общем контексте улучшения 714 | процессов. Если компания-разработчик не ведет соответствующей документации по 715 | тестированию, говорить о сертификации или оценке по тем или иным моделям или 716 | стандартам (CMMI, ISO, SixSigma и т.п.) – просто не представляется возможным. А 717 | это уже вопрос доверия заказчиков, не имевших опыта работы с конкретной 718 | компанией-разработчиком. 719 | 720 | #### Внутренние и независимые команды тестирования (Internal vs. independent test team) 721 | 722 | Формализация процесса тестирования может включать и организационную 723 | формализацию команд(ы) тестирования. В нее могу входить как члены проектной 724 | команды, в частности, разрабатывающие код, так и внешние лица и группы. В 725 | идеале – желательно иметь как внутреннюю команду тестирования, так и внешнюю 726 | группу тестирования (обеспечения качества). Соответствующие организационные 727 | решения принимаются на основе стоимостных характеристик проекта, доступных 728 | ресурсов, анализа стоимости тестирования, как такового, организационной 729 | культуры и т.п. 730 | 731 | #### Оценка стоимости и усилий, а также другие измерения процесса (Cost/effort estimation and other process measures) 732 | 733 | Ряд метрик, связанных с оценкой ресурсов, необходимых для тестирования, как и 734 | оценка эффективности тестирования на разных этапах и уровнях, основывается на 735 | точке зрения и практиках менеджмента проекта (подразделения, компании...) и 736 | используется для оценки и улучшения (оптимизации) процесса тестирования. Разные 737 | техники, концепции и модели тестирования требуют разных затрат – по времени и 738 | необходимым ресурсам. Результат – стоимость тестирования, как затратная 739 | составляющая проекта. Понимание соответствия между стоимостью/усилиями, 740 | необходимыми для той или иной формы тестирования является обязательной частью 741 | современного управления проектами разработки программного обеспечения. 742 | 743 | #### Окончание тестирования (Termination) 744 | 745 | Очень важным аспектом тестирования является решение о том, в каком объеме 746 | тестирование достаточно и когда необходимо завершить процесс тестирования. 747 | Тщательные измерения, такие как достигнутое покрытие кода тестами или охват 748 | функциональности, безусловно, очень полезны. Однако, сами по себе они не могут 749 | определить критериев достаточности тестирования. Принятие решения об окончании 750 | тестирования также включает рассмотрение стоимости и рисков, связанных с 751 | потенциальными сбоями и нарушениями надёжности функционирования тестируемой 752 | программной системы. В то же время, стоимость самого тестирования также 753 | является одним из ограничений, на основе которых принимается решение о 754 | продолжении тех или иных связанных с проектом работ (в частности, тестирования) 755 | или об их прекращении. Cм. также 1.2.1 “Критерии отбора тестов/критерии 756 | адекватности тестов, правила прекращения тестирования”. 757 | 758 | #### Повторное использование и шаблоны тестов (Test reuse and test patterns) 759 | 760 | Доведение тестов до конца и обеспечение сопровождения программной системы 761 | необходимо каждый фрагмент системы тестировать систематическим образом, 762 | повторно используя наработанные тесты. Общий репозиторий тестовых активов 763 | должен находиться под контролем системы конфигурационного управления, с тем, 764 | чтобы любые изменения в требованиях или дизайне могли быть отражены в 765 | используемых наборах тестов, в том числе, с точки зрения их расширения новыми 766 | тестами, если этого требуют соответствующие изменения. 767 | 768 | Шаблоны тестов конструируются на основе тестовых решений, наработанных для 769 | проверки определенных ситуаций или типовых фрагментов программных систем. Такие 770 | шаблоны должны быть документированы с учетом повторного использования, включая 771 | прозрачные возможности их адаптации под специфику программных решений, к 772 | которым такие шаблоны применяются. 773 | 774 | ### Тестовые работы (Test Activities) 775 | 776 | Данная тема дает краткий обзор работ по тестированию. При этом подразумевается, 777 | что успешное управление тестовыми работами сильно зависит от процессов 778 | конфигурационного управления (Software Configuration Management), 779 | рассматриваемых позднее как самостоятельная область знаний. 780 | 781 | #### Планирование (Planning) 782 | 783 | Также как и другие аспекты управления проектами, работы по тестированию должно 784 | планироваться заранее. Как минимум, на уровне организации соответствующего 785 | процесса. Ключевые аспекты планирования тестовой деятельности включают: 786 | 787 | - координацию персонала 788 | - управление оборудованием и другими средствами, необходимыми для организации 789 | тестирования 790 | - планирование обработки нежелательных результатов (т.е. является управлением 791 | определёнными видами рисков) 792 | 793 | В случае одновременной поддержки и сопровождения нескольких версий программной 794 | системы или нескольких систем, необходимо уделять особое внимание планированию 795 | времени, усилий и ресурсов, связанных с проведением работ по тестированию. 796 | Данная позиция перекликается с вопросами управления портфелями проектов с точки 797 | зрения общего управления проектами. 798 | 799 | #### Генерация сценариев тестирования (Test-case generation) 800 | 801 | Создание тестовых сценариев основывается на уровне и конкретных техниках 802 | тестирования. Тесты должны находиться под управлением системы конфигурационного 803 | управления и описывать ожидаемые результаты тестирования. 804 | 805 | #### Разработка тестового окружения (Test environment development) 806 | 807 | Используемое для тестирования окружение должно быть совместимо с инструментами 808 | программной инженерии (будут рассматриваться позднее как тема самостоятельной 809 | области знаний). Это окружение должно обеспечивать разработку и контроль 810 | тестовых сценариев, ведение журнала тестирования, и возможности восстановления 811 | ожидаемых и отслеживаемых результатов тестирования, самих сценариев, а также 812 | других активов тестирования. 813 | 814 | #### Выполнение тестов (Execution) 815 | 816 | Выполнение тестов должно содержать основные принципы ведения научного эксперимента: 817 | 818 | - должны фиксироваться все работы и результаты процесса тестирования 819 | - форма журналирования таких работ и их результатов должна быть такой, чтобы 820 | соответствующее содержание было понятно, однозначно интрепретируемой и 821 | повторяемо другими лицами (не теми, кто первоначально проводил тестирование) 822 | - тестирование должно проводиться в соответствии с заданными и 823 | документированными процедурами 824 | - тестирование должно производиться над однозначно идентифицируемой версией и 825 | конфигурацией программной системы 826 | 827 | Ряд вопросов выполнения тестов и других работ по тестированию освещен в 828 | стандарте IEEE 1008-87. 829 | 830 | #### Анализ результатов тестирования (Test results evaluation) 831 | 832 | Для определения успешности тестов их результаты должны оцениваться, 833 | анализироваться. В большинстве случаев, “успешность” тестирования 834 | подразумевает, что тестируемое программное обеспечение функционирует так, как 835 | ожидалось и в процессе работы не приводит к непредусмотренным последствиям. Не 836 | все такие последствия обязательно являются сбоями, они могут восприниматься как 837 | “помехи”. Однако, любое непредусмотренное поведение может стать источником 838 | сбоев при изменении конфигурации или условий функционирования системы, поэтому 839 | требуют внимания, как минимум, с точки зрения идентификации причин таких помех. 840 | Перед устранением обнаруженного сбоя, необходимо определить и зафиксировать те 841 | усилия, которые необходимы для анализа проблемы, отладки и устранения. Это 842 | позволит в дальнейшем обеспечить большую глубину измерений, а, соответственно, 843 | в перспективе, иметь возможность улучшения самого процесса тестирования. В тех 844 | случаях, когда результаты тестирования особенно важны, например, в силу 845 | критичности обнаруженного сбоя, может быть сформирована специальная группа 846 | анализа (review board). 847 | 848 | #### Отчёты о проблемах/журнал тестирования (Problem reporting/Test log) 849 | 850 | Во многих случаях, в процессе тестовой деятельности ведётся журнал 851 | тестирования, фиксирующий информацию о соответствующих работах: когда 852 | проводится тест, какой тест, кем проводится, для какой конфигурации программной 853 | системы (в терминах параметров и в терминах идентифицируемой версии контекста 854 | конфигурационного управления) и т.п. Неожиданные или некорректные результаты 855 | тестов могут записываться в специальной подсистеме ведения отчетности по сбоям 856 | (problem-reporting system, обеспечивая формирование базы данных, используемой 857 | для отладки, устранения проблем и дальнейшего тестирования. Кроме того, 858 | аномалии (помехи), которые нельзя идентифицировать как сбои, также могут 859 | фиксироваться в журнале и/или системе ведения отчетности по сбоям. В любом 860 | случае, документирование таких аномалий снижает риски процесса тестирования и 861 | помогает решать вопросы повышения надежности самой тестируемой системы. Отчёты 862 | по тестам могут являться входом для процесса управления изменениями и генерации 863 | запросов на изменения (change request) в рамках процессов конфигурационного 864 | управления (см. далее соответствующую область знаний “Software Configuration 865 | Management”). 866 | 867 | #### Отслеживание дефектов (Defect tracking) 868 | 869 | Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и 870 | ошибками, присутствующими в тестируемой программной системе (также они могут 871 | быть следствием поведения операционного и/или тестового окружения). Такие 872 | дефекты могут (и, чаще всего, должны) анализироваться для определения момента и 873 | места первого появления данного дефекта в системе, какие типы ошибок стали 874 | причиной этих дефектов (например, плохо сформулированные требования, 875 | некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены 876 | впервые. Вся эта информация используется для определения того, как может быть 877 | улучшен сам процесс тестирования и насколько критична необходимость таких 878 | улучшений. 879 | -------------------------------------------------------------------------------- /10_software_engineering_tools_and_methods.md: -------------------------------------------------------------------------------- 1 | # Инструменты и методы программной инженерии 2 | 3 | Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - 4 | SWEBOK. 5 | 6 | Содержит перевод описания области знаний SWEBOK “Software Engineering Tools and 7 | Methods”, с замечаниями и комментариями. 8 | 9 | Инструменты и методы программной инженерии (Software Engineering Tools and 10 | Methods) 11 | 12 | Программные инструменты предназначены для обеспечения поддержки процессов 13 | жизненного цикла программного обеспечения. Инструменты позволяют 14 | автоматизировать определенные повторяющиеся действия, уменьшая загрузку 15 | инженеров рутинными операциями и помогая им сконцентрироваться на творческих, 16 | нестандартных аспектах реализации выполняемых процессов. Инструменты часто 17 | проектируются с целью поддержки конкретных (частных) методов программной 18 | инженерии, сокращая административную нагрузку, ассоциированную с “ручным” 19 | применением соответствующих методов. Так же, как и методы программной 20 | инженерии, инструменты призваны сделать программную инженерию более 21 | систематической деятельностью и по своему содержанию (предлагаемой 22 | функциональности) могут варьироваться от поддержки отдельных индивидуальных 23 | задач вплоть до охвата всего жизненного цикла (в этом случае часто говорят об 24 | инструментальной платформе или просто платформе разработки). 25 | 26 | Методы программной инженерии накладывают определенные структурные ограничения 27 | на деятельность в рамках программной инженерии с целью приведения этой 28 | деятельности в соответствие с заданным систематическим подходом и более 29 | вероятным и скорым, с точки зрения соответствующего метода, достижением успеха. 30 | Методы обычно предоставляют соответствующие соглашения (нотацию), словарь 31 | терминов и понятий и процедуры выполнения идентифицированных (и охватываемых 32 | методом) задач, а также рекомендации по оценке и проверке выполняемого 33 | процесса и получаемого в его результате продукта. Методы, как и инструменты, 34 | варьируются по содержанию (охватываемой области применения) от отдельной фазы 35 | жизненного цикла (или даже процесса) до всего жизненного цикла. Данная область 36 | знаний касается только методов, охватывающих множество фаз (этапов) жизненного 37 | цикла. Те методы, применение которых фокусируется на отдельных фазах жизненного 38 | цикла или частных процессах, описаны в соответствующих областях знаний. 39 | 40 | Существует множество детальных описаний и руководств по конкретным 41 | инструментам, и исследований, посвященных анализу (и категоризации, в первую 42 | очередь, со стороны аналитиков) уже применяемых и новых инструментальных 43 | средств (и вероятным направлениям их развития). В таком контексте, общее 44 | техническое описание инструментов программной инженерии, действительно, может 45 | отпугнуть. (В то же время, с точки зрения автора, при всей неоднозначности 46 | любой категоризации инструментов, может быть сформирован общий взгляд на их 47 | целевую функциональность, пусть в чем то и спорный, что, отразится в 48 | определенных случаях ниже в соответствующих авторских комментариях). Одна из 49 | основных сложностей такого описания, в общем случае, заключается в высокой 50 | изменчивости и быстром эволюционировании программных инструментов. Конкретные 51 | аспекты функциональности инструментов достаточно быстро изменяются, что 52 | усложняет приведение конкретных актуальных примеров. 53 | 54 | Данная область знаний охватывает все процессы жизненного цикла и, 55 | соответственно, связана со всеми другими областями знаний SWEBOK. 56 | 57 | ![Рисунок 1. Область знаний “Инструменты и методы программной инженерии” [SWEBOK, 2004, с.10-1, рис. 1]](images/tools_area_small.jpg) 58 | 59 | ## Инструменты программной инженерии (Software Engineering Tools) 60 | 61 | Первые пять тем данной секции соответствуют первым пяти областям знаний SWEBOK 62 | - требования, проектирование, конструирование, тестирование и сопровождение. 63 | Следующие четыре темы касаются оставшихся четырех областей знаний – 64 | конфигурационного управления, управления программной инженерией, процессов и 65 | качества, соответственно. Также в данной секции представлена еще одна тема – 66 | “Дополнительные аспекты инструментального обеспечения” (в оригинале SWEBOK она 67 | называется “Miscellaneous”), посвященная таким вопросам как, например, 68 | интеграция инструментов, которые потенциально касаются всех классов 69 | инструментов. 70 | 71 | ### Инструменты работы с требованиями (Software Requirements Tools) 72 | 73 | SWEBOK говорит о том, что инструменты, применяемые для работы с требованиями 74 | могут быть классифицированы в две категории: средства моделирования (modeling) 75 | и средства трассировки (traceability). Однако, на практике, моделирование 76 | требований, все же, является частью управления требований, как, кстати, и 77 | трассировка. В принципе, инструменты трассировки могут быть рассмотрены как 78 | самостоятельная категория, в силу своей значимости при проведении анализа 79 | требований, в первую очередь, анализа влияний требований и изменений (т.н. 80 | “impact analysis”). Но моделирование требований лишь часть управления 81 | требованиями. Поэтому, в приведенной ниже классификации предлагаемая 82 | модификация оригинального SWEBOK состоит в том, что вместо “инструментов 83 | моделирования требований” используется термин “инструменты управления 84 | требованиями”, при сохранении оригинального содержания данной темы SWEBOK. 85 | Соответственно, 86 | 87 | - Инструменты управления требованиями (моделирования требований – Requirements 88 | modeling tools). Эти инструменты используются для извлечения (eliciting), 89 | анализа, специфицирования и проверки программных требований. 90 | - Инструменты трассировки требований (Requirement traceability tools). Эти 91 | инструменты становятся все более важными по мере повышения сложности 92 | программного обеспечения. В силе того, что они также относятся и к другим 93 | процессам жизненного цикла, здесь они представлены в качестве самостоятельной 94 | категории средств работы с требованиями. 95 | 96 | Необходимо заметить, что трассировка является неотъемлемой частью полноценной 97 | работы с требованиями, что приводит к естественному объединению предлагаемых 98 | SWEBOK категорий инструментов в единый класс “инструментов управления 99 | требованиями”, функциональное содержание которых может варьироваться, например, 100 | в зависимости от сложности проектов и уровня зрелости процессов. Если мы 101 | обратимся, например, к модели CMMI Staged, мы увидим, что на 2-м уровне 102 | зрелости речь идет об “управлении требованиями” – Requirement Management, а на 103 | 3-м уровне зрелости обсуждается “разработка требований” – Requirement 104 | Development, обладающая более ёмким содержанием. В то же самое время, с 105 | технократической точки зрения, требования могут восприниматься и как элементы 106 | конфигураций, наравне с запросами на изменения и другими активами проекта (см. 107 | область знаний SWEBOK “Конфигурационное управление”). Таким образом, в ряде 108 | случаев (что подтверждается конкретными программными средствами, доступными на 109 | рынке программного обеспечения), в качестве инструмента работы с требованиями 110 | может выступать и система конфигурационного управления, если, конечно, она 111 | изначально не ограничена базовой функциональностью контроля версий файлов. С 112 | другой стороны, сегодняшние средства моделирования на основе UML и BPMN могут 113 | также рассматриваться как элементы инструментального обеспечения работы с 114 | требованиями, что часто отражается в их функциональности, включающей тесную 115 | интеграцию с “классическими” средствами управления требованиями, а сама 116 | интеграция воплощена не только в визуальном представлении работы с 117 | репозиториями требований, но и в автоматизации трассировки между моделями 118 | (и/или их элементами) и требованиями, соответственно. 119 | 120 | ### Инструменты проектирования (Software Design Tools) 121 | 122 | Эта тема охватывает инструменты для создания и проверки программного дизайна. 123 | Существует большое разнообразие таких инструментов, использующих различные 124 | нотации (соглашения, в том числе визуальные) и методы. Несмотря на такое 125 | разнообразие, авторами SWEBOK не было найдено адекватной классификации этих 126 | инструментов. 127 | 128 | Однако, в данном случае, все же возможно разделение инструментов по нескольким 129 | критериям, например, применяемым базовым нотациям моделирования и 130 | проектирования (SADT/IDEF, UML, BPMN/BPEL, Microsoft DSL и т.п.) или целевым 131 | задачам (бизнес-моделирование, проектирование БД, объектно-ориентированное 132 | проектирование, интеграционное/SOA-проектирование и т.п.). 133 | 134 | ### Инструменты конструирования (Software Construction Tools) 135 | 136 | Данная тема касается инструментальных средств конструирования программного 137 | обеспечения, в соответствии с пониманием “конструирования”, заданным 138 | соответствующей областью знаний SWEBOK, рассматривавшейся ранее. Эти 139 | инструменты используются для производства и трансляции программного 140 | представления (например, исходного кода), достаточно детального и явного для 141 | машинного выполнения. 142 | 143 | - Редакторы (program editors). Эти инструменты используются для создания и 144 | модификации исходного кода программ и, возможно, ассоциированной с ними 145 | документации. Это могут быть как редакторы “общего назначения” (что на 146 | протяжении многих лет наблюдается в UNIX и unix-подобных средах) или 147 | специализированные редакторы с поддержкой специфики целевого языка 148 | программирования (что является, в большинстве случаев, прерогативой 149 | интегрированных сред разработки – IDE). В то же время, документирование все же 150 | является не только и не столько частью редактора, сколько самостоятельной 151 | функциональностью, пусть часто и тесно интегрированной с редактором. 152 | - Компиляторы и генераторы кода (compilers and code generators). Традиционно, 153 | компиляторы являлись неинтерактивными (командными) трансляторами исходного 154 | кода. Однако, существует тенденция (с точки зрения автора, более чем явная, что 155 | отмечено ниже) интеграции компиляторов и редакторов в интегрированные среды 156 | программирования. К этому классу также относятся препроцессоры, 157 | линковщики/загрузчики, а также генераторы кода (за исключением, может быть, 158 | объектно-ориентированных средств проектирования, поддерживающих связь с 159 | исходным кодом и имеющих тенденцию быть тесно интегрированными с новым 160 | поколением IDE). 161 | - Интерпретаторы (interpreters). Эти инструменты обеспечивают исполнение 162 | программ посредством эмуляции. Они могут поддерживать действия по 163 | конструированию программного обеспечения, предоставляя для исполнения программ 164 | окружение, более контролируемое и поддающееся наблюдению, чем это обычно 165 | способна сделать та или иная операционная система. 166 | - Хочется отметить определенное “слияние”, если так можно выразиться, между 167 | компиляторами и интерпретаторами. Ярким тому свидетельством является 168 | использование так называемой just-in-time компиляции – компиляции “на лету”, 169 | когда промежуточный программный код, по мере исполнения или с опережением 170 | (например, в процессе запуска/загрузки программы) преобразуется в набор 171 | инструкций, исполняемых непосредственно средствами операционной системы, но под 172 | контролем среды исполнения, в первую очередь, с точки зрения безопасности. 173 | Такого рода подход стал родоначальником ряда современных программных платформ, 174 | например, Java и .NET. На этом фоне, возможно было бы объединить интерпретаторы 175 | с компиляторами и генераторами кода, как средства непосредственной подготовки 176 | (трансляции) исходного кода к исполнению. 177 | - Отладчики (debuggers). Эти инструменты было принято выделить в 178 | самостоятельную категорию, так как они поддерживают процесс конструирования 179 | программного обеспечения, но, в то же время, функционально отличаются от 180 | редакторов и компиляторов. 181 | 182 | С точки зрения классификации инструментов необходимо выделить явно и давно 183 | присутствующие на рынке: “интегрированные средства разработки” (IDE - 184 | integrated developers environment), а также программные библиотеки/библиотеки 185 | компонент (frameworks, libraries, components), без которых просто невозможно 186 | представить сегодняшний процесс разработки, да и рынок программных средств, в 187 | целом. Кроме того, в данной теме можно говорить и о таких функционально ёмких 188 | “супер”-категориях, как “программная платформа” (например, Java, J2EE и 189 | Microsoft .NET) и “платформа облачных вычислений” (например, Microsoft Azure, 190 | Amazon и др.), которые включают наравне с инструментами, как таковыми, и 191 | определенные модели конструирования, преобразования и выполнения кода. При 192 | таком подходе, вероятно, обоснованным было бы введение класса “элементарных” 193 | или “базовых инструментов конструирования”, к которому можно было бы отнести 194 | редакторы, компиляторы, интерпретаторы, отладчики, средства документирования и 195 | библиотеки, а также класса “комплексных средств конструирования” – 196 | интегрированных сред и различных платформ, что, безусловно, не претендует на 197 | истину в последней инстанции и является одной из возможных точек зрения. 198 | 199 | ### Инструменты тестирования (Software Testing Tools) 200 | 201 | - Генераторы тестов (test generators). Эти инструменты помогают в разработке 202 | сценариев тестирования. 203 | - Средства выполнения тестов (test execution frameworks). Эти средства 204 | обеспечивают среду исполнения тестовых сценариев в контролируемом окружении, 205 | позволяющем отслеживать поведение объекта, подвергаемого тестированию. 206 | - Инструменты оценки тестов (test evaluation tools). Эти инструменты 207 | поддерживают оценку результатов выполнения тестов, помогая определить в какой 208 | степени и где именно обнаруженное поведение тестируемого объекта 209 | соответствует ожидаемому поведению. 210 | - Средства управления тестами (test management tools). Эти средства 211 | обеспечивают поддержку всех аспектов процесса тестирования программного 212 | обеспечения. 213 | - Инструменты анализа производительности (performance analysis tools). Эти 214 | инструменты используются для количественной оценки и анализа производительности 215 | программного обеспечения, являющегося специализированным видом тестирования, 216 | цель которого – в оценки поведения программ в части производительности, в 217 | отличие от тестирования корректности функционального поведения. 218 | 219 | Последний класс инструментов тестирования, в какой-то степени, показывает 220 | недостаточность предложенной классификации, упуская, например, инструменты 221 | функционального тестирования, средства тестирования безопасности, инструменты 222 | тестирования пользовательского интерфейса, инструменты нагрузочного 223 | тестирования и др., соответствующие, различным целям тестирования, 224 | представленным в секции 2.2 области знаний SWEBOK “Тестирование”, и естественно 225 | задающим “подвиды” возможного класса “специализированных или целевых 226 | инструментов тестирования”, к которым, в частности, относится тестирование 227 | производительности. 228 | 229 | ### Инструменты сопровождения (Software Maintenance Tools) 230 | 231 | Эта тема охватывает инструменты, особенно важные для обеспечения сопровождения 232 | существующего программного обеспечения, подверженного модификациям. SWEBOK 233 | идентифицирует две категории таких инструментов: 234 | 235 | - Инструменты облегчения понимания (comprehension tools). Эти инструменты 236 | помогают человеку в понимании программ. Примерами могут служить различные 237 | средства визуализации. 238 | - Инструменты реинжиниринга (reengineering tools). Эти инструменты поддерживают 239 | деятельность по реинжинирингу, описанную в области знаний SWEBOK “Software 240 | Maintenance”. 241 | 242 | Средства “обратного” инжиниринга (reverse engineering) помогают в процессе 243 | восстановления для существующего программного обеспечения таких артефактов, как 244 | спецификация и описание дизайна (архитектуры), которые, в дальнейшем, могут 245 | быть трансформированы для генерации нового продукта на основе функциональности 246 | существующего. 247 | 248 | Последнее замечание, в сочетании с типичной функциональностью современных 249 | средств проектирования, поддерживающих анализ исходного кода (в случае 250 | объектно-ориентированных систем) и его визуализацию (в том числе, 251 | поведенческую, например, в виде диаграмм UML Sequence), позволяет объединить 252 | упомянутые категории инструментов в единый класс “инструментов реинжиниринга”. 253 | В то же время, деятельность по сопровождению и поддержке, в частности, 254 | касающаяся сбоев и исправления обнаруженных ошибок в программном обеспечении, 255 | требует, в определенной степени, отнесения к этой теме и средств 256 | конфигурационного управления, рассматриваемых ниже (например, в части обработки 257 | запросов на изменения). 258 | 259 | ### Инструменты конфигурационного управления (Software Configuration Management Tools) 260 | 261 | Инструменты конфигурационного управления делятся на три категории: 262 | - Инструменты отслеживания (tracking) дефектов, расширений и проблем. 263 | - Инструменты управления версиями. 264 | - Инструменты сборки и выпуска. Эти инструменты предназначены для управления 265 | задачами сборки и выпуска продуктов, а также включают средства инсталляции. 266 | 267 | Дополнительная информация по данной теме представлена в области знаний SWEBOK 268 | “Конфигурационное управление”. 269 | 270 | ### Инструменты управления инженерной деятельностью (Software Engineering Management Tools) 271 | 272 | Средства управления деятельностью по программной инженерии делятся на три 273 | категории: 274 | 275 | - Инструменты планирования и отслеживания проектов. Эти средства используются 276 | календарного планирования работ, количественной оценки усилий и стоимостных 277 | ожиданий, связанных с проектами. 278 | - Инструменты управления рисками. Эти средства используются для идентификации, 279 | оценки ожиданий и мониторинга рисков. 280 | - Инструменты количественной оценки. Эти инструменты ведения измерений помогают 281 | в выполнении работ, связанных с программой количественной оценки, проводимой в 282 | отношении проектов программного обеспечения. 283 | 284 | Функциональные аспекты управления инженерной деятельностью достаточно детально 285 | представлены в области знаний SWEBOK “Управление программной инженерией” 286 | (Software Engineering Management). 287 | 288 | ### Инструменты поддержки процессов (Software Engineering Process Tools) 289 | 290 | В описании этой темы в текущей версии SWEBOK наблюдается противоречие между 291 | кратким делением на категории инструментов и их более детальным определением. 292 | Скорее всего, такая несогласованность связана, в первую очередь, с отсутствием 293 | достигнутого консенсуса в этой области. Базируясь на обеих классификациях, 294 | упомянутых в SWEBOK, хотелось бы отметить несколько типов инструментов из 295 | “смежных” областей, имеющих особое значение в поддержке процессов программной 296 | инженерии: 297 | 298 | - Инструменты моделирования, позволяющие, в частности, описать и модель процессов, как таковую. 299 | - Инструменты управления проектами. 300 | - Инструменты конфигурационного управления, поддерживающие работу с актуальными 301 | версиями всего комплекса артефактов проекта и, что не менее важно, позволяющие 302 | задать поведенческие характеристики (в упрощённом понимании - workflow) и 303 | атрибуты этих артефактов в форме элементов конфигураций. 304 | - Ролевые платформы разработки программного обеспечения, охватывающие все 305 | стадии жизненного цикла и, на сегодняшний день, являющиеся развитием 306 | интегрированных средств разработки и CASE-инструментов в направлении поддержки 307 | “смежной” функциональности – управления требованиями, работ по 308 | конфигурационному управлению с поддержкой управления изменениями, тестирования 309 | и оценки качества. 310 | 311 | Первые три вида инструментов в такой классификации позволяют описать 312 | применяемые процессы программной инженерии. Четвертый класс – 313 | “супер-интегрированные среды разработки”, называемые сегодня ролевыми 314 | платформами разработки, обеспечивают поддержку заданных процессов, описанных, 315 | например, в виде соответствующих правил на уровне глубоко интегрированных в 316 | такие среды инструментов конфигурационного управления. 317 | 318 | ### Инструменты обеспечения качества (Software Quality Tools) 319 | 320 | Средства обеспечения качества делятся на две категории: 321 | 322 | - Инструменты инспектирования. Эти средства используются для поддержки обзора 323 | (review) и аудита. 324 | - Инструменты (статического) анализа. Эти средства используются для анализа 325 | программных артефактов, данных, потоков работ и зависимостей. Такие инструменты 326 | предназначены для проверки определенных свойств или артефактов, в целом, на 327 | соответствие заданным характеристикам. 328 | 329 | ### Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues) 330 | 331 | Эта тема охватывает вопросы, касающиеся всех классов инструментов. Создателями 332 | SWEBOK идентифицированы три категории таких аспектов: 333 | 334 | - Техники интеграции инструментов. Эти техники важны для естественного 335 | использования сочетания различных инструментов. Типичные виды интеграции 336 | инструментов включают платформы, представление, процессы, данные и управление. 337 | - Мета-инструменты. Такие средства генерируют другие инструменты. Например, 338 | классическим примером мета-инструмента является компилятор компиляторов. 339 | 340 | Оценка инструментов. Данная тема представляется достаточно важной в силу 341 | постоянной эволюции инструментов программной инженерии. 342 | 343 | ## Методы программной инженерии (Software Engineering Methods) 344 | 345 | Данная секция (подобласть) разделена на три темы: эвристические методы 346 | (heuristic methods), касающиеся неформализованных подходов; формальные методы 347 | (formal methods), обоснованные математически; методы прототипирования 348 | (prototyping methods), базирующиеся на различных формах прототипирования. Эти 349 | три темы не являются изолированными друг от друга, скорее они выделены исходя 350 | из их значимости и на основе определенных достаточно явных индивидуальных 351 | особенностей. Например, объектно-ориентированный подход может включать 352 | формальные техники и использовать прототипирование для проверки и аттестации. 353 | Так же как и инструменты, методы программной инженерии постоянно 354 | эволюционируют. Именно поэтому, в описании данной области знаний авторы SWEBOK 355 | постарались избежать, насколько это возможно, упоминания любых конкретных 356 | методологий. 357 | 358 | ### Эвристические методы (Heuristic Methods) 359 | 360 | Эта тема содержит четыре категории методов: структурные, ориентированные на 361 | данные, объектно-ориентированные и ориентированные на область применения. 362 | 363 | - Структурные методы (structured methods). При таком подходе системы строится с 364 | функциональной точки зрения, начиная с высокоуровневого понимания поведения 365 | системы с постепенным уточнением низко-уровневых деталей. (такой подход, 366 | иногда, также называют “проектированием сверху-вниз”) 367 | - Методы, ориентированные на данные (data-oriented methods). Отправной точкой 368 | такого подхода являются структуры данных, которыми манипулирует создаваемое 369 | программное обеспечение. Функции в этом случае являются вторичными. 370 | - Объектно-ориентированные методы (object-oriented methods). Система при таком 371 | подходе рассматривается как коллекция объектов, а не функций. 372 | - Методы, ориентированные на конкретную область применения (domain-specific 373 | methods). Такие специализированные методы разрабатываются с учетом специфики 374 | решаемых задач, например, систем реального времени, безопасности 375 | жизнедеятельности (safety) и защищенности от несанкционированного доступа 376 | (security). 377 | 378 | ### Формальные методы (Formal Methods) 379 | 380 | Эта тема касается математических (строгих) методов программной инженерии. 381 | 382 | К сожалению, SWEBOK не дает здесь какого-либо определения формальных методов, 383 | поэтому, хотелось бы привести в данном контексте характеристику, данную им 384 | одним из классиков программной инженерии – Ианом Соммервиллем [Соммервилл, 385 | 2002, стр. 188]: “Термин формальные методы подразумевает ряд операций, в состав 386 | которых входит создание формальной спецификации системы, анализ и 387 | доказательство спецификаций, реализация системы на основе преобразования 388 | формальной спецификации в программы и верификация программ. Все эти действия 389 | зависят от формальной спецификации программного обеспечения. Формальная 390 | спецификация – это системная спецификация, записанная на языке, словарь, 391 | синтаксис и семантика которого определены формально. Необходимость формального 392 | определения языка предполагает, что этот язык основывается на математических 393 | концепциях. Здесь используется область математики, которая называется 394 | дискретной математикой и основывается на алгебре, теории множеств и алгебре 395 | логики.” 396 | 397 | Эти методы можно классифицировать в виде следующих категорий: 398 | 399 | - Языки и нотации специфицирования (specification languages and notations). 400 | Языки спецификаций могут быть ориентированы на модель, свойства и поведение. По 401 | мнению автора, ярким примером такого рода методов являются формальные методы 402 | описания требований, интерес к которым периодически возникает на протяжении 403 | всей истории программной инженерии. 404 | - Уточнение (refinement). Данные подходы связаны с уточнением (трансформацией) 405 | превращения спецификаций в конечный результат, максимально близкий желаемому. В 406 | качестве результата применения таких методов рассматривается конечный - 407 | исполнимый программный продукт. 408 | - Подтверждение/доказательство (verification/proving properties). Этот подход 409 | основывается на строгом доказательстве точности любых характеристик исходных 410 | предпосылок и получаемого продукта с использованием теорем и проверки точности 411 | моделей. 412 | 413 | История программной инженерии показала, что в области разработки прикладных 414 | систем, обоснованность (в частности, в силу трудоемкости) применения формальных 415 | методов не подтверждается на практике, за исключением случаев “скрытого” 416 | (неявного для разработчиков) применения определенных формальных методов на 417 | уровне внутренней реализации конкретных инструментов программной инженерии, 418 | например, в средствах моделирования и проектирования. Иан Соммервилл дает такую 419 | характеристику формальным методам [Соммервилл, 2002, стр. 188]: “Традиционные 420 | технические дисциплины обычно легко адаптируют математические методы. Однако 421 | инженерия программного обеспечения не идет таким путем. Хотя прошло более 25 422 | лет исследований по использованию математических методов в процессе создания 423 | ПО, воздействие этих методов все же ограничено. Так называемые формальные методы 424 | широко не используются. Многие компании, разрабатывающие ПО, не считают 425 | экономически выгодным применение этих методов в процессе разработки.” 426 | 427 | ### Методы прототипирования (Prototyping Methods) 428 | 429 | Эта тема охватывает методы, основанные на прототипировании программного 430 | обеспечения. Они разделены на три категории: 431 | 432 | - Стили прототипирования. Идентифицированы следующие подходы, касающиеся стилей 433 | прототипирования – создание временно используемых прототипов (throwaway), 434 | эволюционное прототипирование (в подавляющем большинстве случаев предполагает 435 | превращение прототипа в конечный продукт) и разработка исполняемых спецификаций 436 | (часто основывается как на формальных методах). 437 | - Цели прототипирования. Примерами таких целей служат требования, архитектурный 438 | дизайн или пользовательский интерфейс. 439 | - Техники оценки/исследования (evaluation) результатов прототипирования. Эти 440 | аспекты касаются того, как именно будут использованы результаты создания 441 | прототипа (например, будет ли он трансформирован в продукт, создается он для 442 | оценки нагрузочных способностей и других аспектов масштабируемости и т.п.). 443 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | MAKRDOWN_FILES += 01_introduction.md 2 | MAKRDOWN_FILES += 02_software_requirements.md 3 | MAKRDOWN_FILES += 03_software_design.md 4 | MAKRDOWN_FILES += 04_software_construction.md 5 | MAKRDOWN_FILES += 05_software_testing.md 6 | MAKRDOWN_FILES += 06_software_maintenance.md 7 | MAKRDOWN_FILES += 07_software_configuration_management.md 8 | MAKRDOWN_FILES += 08_software_engineering_management.md 9 | MAKRDOWN_FILES += 09_software_engineering_process.md 10 | MAKRDOWN_FILES += 10_software_engineering_tools_and_methods.md 11 | MAKRDOWN_FILES += 11_software_quality.md 12 | MAKRDOWN_FILES += software_lifecycle_models.md 13 | MAKRDOWN_FILES += bibliography.md 14 | 15 | PANDOC = pandoc 16 | PANDOC_OPT += --toc 17 | PANDOC_OPT += title.txt $(MAKRDOWN_FILES) 18 | 19 | NAME = swebok_2004_ru 20 | 21 | all: $(NAME).html $(NAME).epub $(NAME).fb2 22 | 23 | $(NAME).epub: $(MAKRDOWN_FILES) title.txt 24 | $(PANDOC) $(PANDOC_OPT) -o $(NAME).epub 25 | 26 | $(NAME).fb2: $(MAKRDOWN_FILES) title.txt 27 | $(PANDOC) $(PANDOC_OPT) -o $(NAME).fb2 28 | 29 | $(NAME).html: $(MAKRDOWN_FILES) 30 | $(PANDOC) $(PANDOC_OPT) --embed-resources --standalone -o $(NAME).html 31 | 32 | $(NAME).zip: $(NAME).html images 33 | zip -r $(NAME).zip $< images 34 | 35 | release: $(NAME).epub $(name).fb2 $(NAME).zip 36 | 37 | clean: 38 | rm -f $(NAME).html $(NAME).epub $(NAME).fb2 $(NAME).zip 39 | 40 | .PHONY: clean 41 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## Основы Программной Инженерии (по SWEBOK) 2 | 3 | Форматы: [EPUB](https://bronevichok.ru/static/swebok_2004_ru.epub), [FB2](https://bronevichok.ru/static/swebok_2004_ru.fb2) и [HTML](https://bronevichok.ru/static/swebok_2004_ru.html) 4 | 5 | ![The Terrace](images/Terrace.jpg) 6 | 7 | "Основы программной инженерии" разработаны на базе IEEE Guide to SWEBOK® 2004 в соответствии с IEEE SWEBOK 2004 Сopyright and Reprint 8 | Permissions: "This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations provided that 9 | (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy." 10 | 11 | Русский перевод SWEBOK 2004 с замечаниями и комментариями подготовлены [Сергеем 12 | Орликом](https://www.linkedin.com/in/sorlik) при участии [Юрия Булуя](https://ru.linkedin.com/in/yurybuluy). 13 | Дополнительные главы написаны Сергеем Орликом. 14 | 15 | "Основы программной инженерии" Сopyright © 2004-2010 Сергей Орлик. Все права защищены. 16 | 17 | SWEBOK Сopyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved. 18 | 19 | ["The Terrace" illusion Copyright](http://www.cambiguities.com/Illusion_Site/Cambiguities_David_Macdonald_Illusions___Image___Terrace_Illusion.html) © [David Macdonald](http://users.skynet.be/fa414202/Cambiguities/Illusion_Site/Cambiguities_David_Macdonald_Illusions___Image___Terrace_Illusion.html). All rights reserved. (используется с разрешения автора) 20 | 21 | - [Рекомендации по преподаванию программной инженерии и информатики в университетах](https://oops.math.spbu.ru/SE/se2004r.pdf) 22 | - [Guide to the Software Engineering Body of Knowledge Version 3 (SWEBOK)](https://github.com/ligurio/swebook-v3/) 23 | -------------------------------------------------------------------------------- /bibliography.md: -------------------------------------------------------------------------------- 1 | # Дополнительная библиография 2 | 3 | - [Ambler, 2004] - Scott W. Ambler. One Piece at a Time. Software Development 4 | Magazine, December 2004. http://www.sdmagazine.com/ 5 | - [Ambler, 2005] - Scott W. Ambler, John Nalbone, Michael J. Vizdos. The 6 | Enterprise Unified Process: Extending the Rational Unified Process. Prentice 7 | Hall PTR (ISBN 0-13-191451-0) 2005 8 | - [APM PMBoK, 2000] - Project Management Body of Knowledge. Fourth Edition. 9 | Association of Project Management, 2000. 10 | http://www.apm.org.uk/ 11 | - [Boehm, 1988] – Barry W. Boehm. A Spiral Model of Software Development and 12 | Enhancement, Computer, May 1988, pp. 61-72. 13 | http://www.computer.org/computer/homepage/misc/Boehm/index.htm 14 | - [Boehm, 2000] – Barry W. Boehm. Spiral Development: Experience, Principles, 15 | and Refinements. Spiral Experience Workshop, February 9, 2000 / Special Report 16 | CMU/SEI-2000-SR-008, July, 2000. http://www.sei.cmu.edu/cbs/spiral2000/Boehm 17 | - [Chaos, 2004] – CHAOS Research Results. 2004 Third Quarter Research Report. 18 | The Standish Group International, Inc., 2004. 19 | - [CMMI 1.1, 2002] - Capability Maturity Model Integration, Version 1.1. [CMMI 20 | 1.1, 2002] - Capability Maturity Model Integration, Version 1.1. CMMISM for 21 | Systems Engineering, Software Engineering, Integrated Product and Process 22 | Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1). Software 23 | Engineering Institute (SEI), Carnegie Mellon University (CMU), 2002. 24 | http://www.sei.cmu.edu/cmmi/ 25 | - [DeMarco, 1999] – The Paradox of Software Architecture and Design”, Stevens 26 | Prize Lecture, August, 1999. 27 | - [E-Gov, 2002] – E-Gov Enterprise Architecture Guidance (Common Reference 28 | Model), FEA Working Group (Draft), July 25, 2002]. 29 | http://www.feapmo.gov/resources/E-Gov_Guidance_Final_Draft_v2.0.pdf 30 | - [Fred Brooks, 1987] – Классическая статья Фреда Брукса (Frederick P. Brooks, 31 | Jr.), заставившая по-новому взглянуть индустрию программного обеспечения на 32 | самою себя. - No Silver Bullet: Essence and Accidents of Software Engineering. 33 | IEEE Computer, April, 1987. http://www.computer.org/computer/homepage/misc/Brooks/ 34 | - [PMBOK US DoD Ext, 2003] - U.S. Department of Defense (DoD) Extension to: A 35 | Guide to the Project Management Body of Knowledge (PMBOK Guide). First Edition, 36 | Version 1.0. PMI Standard. The Defense Acquisition University (DAU), June, 2003. http://www.dau.mil/pubs/gdbkspmbok.asp 37 | - [PMI PMBOK, 2000] – A Guide to the Project Management Body of Knowledge. 38 | (PMBOK® Guide). Second Edition. Project Management Institute, Inc., 2000. 39 | http://www.pmi.org/ 40 | - [PMI PMBOK3, 2004] – A Guide to the Project Management Body of Knowledge. 41 | (PMBOK® Guide). Third Edition. Project Management Institute, Inc., 2004. 42 | http://www.pmi.org/ 43 | - [PMI PMBOK3, 2004, Рус] – Руководство к Своду знаний по управлению проектами. 44 | (Руководство PMBOK®). Третье издание. Издание на русском языке. Project 45 | Management Institute, Inc., 2004. http://www.pmi.org/ 46 | - [PMI WBS, 2001] - Practice Standard for Work Breakdown Structures. Project 47 | Management Institute, Inc., 2001. http://www.pmi.org/ 48 | - [SE, 2004] - Software Engineering 2004. Curriculum Guidelines for 49 | Undergraduate Degree Programs in Software Engineering. A Volume of the 50 | Computing Curricula Series. The Joint Task Force on Computing Curricula, IEEE 51 | Computer Society, Association for Computing Machinery, August 23, 2004. 52 | http://sites.computer.org/ccse/ 53 | - [SWEBOK, 2004] - Guide to Software Engineering Base of Knowledge (SWEBOK). 54 | IEEE Computer Society, 2004. http://www.swebok.org/ 55 | - [TOGAF, 2003] – The Open Group Architecture Framework (TOGAF). Version 8.1 56 | The Open Group, 2003. http://www.opengroup.org/architecture/togaf8/index8.htm 57 | - [Zachman] – The Zachman Framework for Enterprise Architecture, John A. 58 | Zachman, ZIFA - Zachman Institute for Framework Advancement. http://www.zifa.com 59 | - [Амблер, 2002] – Скотт Амблер. Гибкие технологии: экстремальное 60 | программирование и унифицированный процесс разработки. Wiley (ISBN 61 | 0-471-20282-7), 2002 - Scott W. Ambler, Agile Modeling: Effective Practices for 62 | Extreme Programming, 2002; перевод и издание на русском языке: ЗАО Издательский 63 | дом “Питер” (ISBN 5-94723-545-5), 2005 64 | - [Арчибальд, 2003] – Рассел Д. Арчибальд. Управление высоко-технологичными 65 | программами и проектами. Издание третье, переработанное и дополненное. John 66 | Wiley & Sons, Inc. (ISBN 0-471-26557-8) 1976 – Russel D. Archibald, 2003; 67 | перевод и издание на русском языке: АйТи (ISBN 5-98453-002-3) - ДМК Пресс 68 | (ISBN 5-94074-214-9) 2004. 69 | - [Арчибальд, 2005] – Рассел Д. Арчибальд. Искусство управления проектами: 70 | состояние и перспективы. Возможности и уровень зрелости организации в 71 | управлении проектами. Информационно-аналитический журнал “Управление 72 | проектами”, N1 (1), март 2005, стр. 14-23. http://www.pmmagazine.ru 73 | - [Брукс, 1995] – Фредерик Брукс. Мифический человеко-месяц или как создаются 74 | программные системы. 2-е издание, юбилейное. Addison-Wesley Longman, Inc. (ISBN 75 | 0-201-83595-9), 1995. Издательство Символ-Плюс (ISBN 5-93286-005-7), 2000, 2005. 76 | - [Вигерс, 2003] – Карл И. Вигерс. Разработка требований к программному 77 | обеспечению. Издательско-торговый дом “Русская редакция”, перевод на русский 78 | язык второй редакции книги – Microsoft Corporation (ISBN 5-7502-0240-2), 2004. 79 | Оригинальное издание на английском языке: Software Requirements. Second 80 | Edition. Karl E. Wiegers, Microsoft Press (ISBN 0-7356-1879-8), 2003. 81 | - [Грей и Ларсон, 2003] – Клиффорд Ф. Грей, Эрик У. Ларсон. Управление 82 | проектами: Практическое руководство. Издательство “Дело и Сервис” (ISBN 83 | 5-8018-0152-9), 2003. The McGraw-Hill Companies, Inc. (ISBN 0-07-365812-X), 2000. 84 | - [ГОСТ 12207, 1999] – Информационная технология. Процессы Жизненного Цикла 85 | Программных Средств. ГОСТ Р ИСО/МЭК 12207-99, Государственный Стандарт 86 | Российской Федерации, 1999. Госстандарт России, Москва, 2000. 87 | - [ГОСТ 34, 1990] – Информационная технология. Комплекс стандартов и 88 | руководящих документов на автоматизированные системы. Термины и определения. 89 | ГОСТ 34.003-90, Государственный Стандарт Российской Федерации, 1999. 90 | Госстандарт России, Москва, 1990. 91 | - [Кантор, 2002] – Марри Кантор. Управление программными проектами. 92 | Практическое руководство по разработке успешного программного обеспечения. 93 | Издательский дом “Вильямс” (ISBN 5-8459-0294-0), 2002. Addison Wesley (ISBN 94 | 0-2017-0044-1), 2002. 95 | - [СОВНЕТ НТК, 2000] - Национальные требования к компетентности специалистов по 96 | Управлению Проектами (НТК). Ассоциация по Управлению Проектами СОВНЕТ, 2000. 97 | http://www.sovnet.ru/ntk2000/index.php 98 | - [Соммервилл, 2000] – Иан Соммервилл. Инженерия программного обеспечения. 6-е 99 | издание. Издательский дом “Вильямс” (ISBN 5-8459-0330-0), 2002. Addison Wesley 100 | (ISBN 0-201-39815-X), 2001. 101 | - [Товб А., Ципес Г., 2003] – А.С. Товб, Г.Л. Ципес. Управление проектами: 102 | стандарты, методы, опыт. Второе издание. Товб А.С., Ципес Г.Л., 2003 – ЗАО 103 | “Олимп-Бизнес” (ISBN 5-9693-0038-1) 2003, 2005. 104 | - [Фатрелл, Шафер и Шафер, 2003] – Роберт Т. Фатрелл, Дональд Ф. Шафер, Линда 105 | И. Шафер. Управление программными проектами: достижение оптимального качества 106 | при минимуме затрат. Издательский дом “Вильямс” (ISBN 5-8459-0413-7), 2003. 107 | Addison-Wesley Publishing Company, Inc. (ISBN 0-13-091297-2), 2002. 108 | - [Фаулер, 2004] – Мартин Фаулер. UML. Основы. Краткое руководство по 109 | стандартному языку объектного моделирования. 3-е издание. Издательство 110 | “Символ-Плюс” (ISBN 5-93286-060-X), Санкт-Петербург, 2004. 111 | -------------------------------------------------------------------------------- /images/SWEBOK_logo_v2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/SWEBOK_logo_v2.jpg -------------------------------------------------------------------------------- /images/Terrace.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/Terrace.jpg -------------------------------------------------------------------------------- /images/configuration_management_1-activities.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/configuration_management_1-activities.jpg -------------------------------------------------------------------------------- /images/configuration_management_3-tools_and_processes.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/configuration_management_3-tools_and_processes.jpg -------------------------------------------------------------------------------- /images/configuration_management_4-elements.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/configuration_management_4-elements.jpg -------------------------------------------------------------------------------- /images/configuration_management_5-changes.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/configuration_management_5-changes.jpg -------------------------------------------------------------------------------- /images/configuration_management_area_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/configuration_management_area_small.jpg -------------------------------------------------------------------------------- /images/construction_area.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/construction_area.jpg -------------------------------------------------------------------------------- /images/design_area_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/design_area_small.jpg -------------------------------------------------------------------------------- /images/lifecycle_categories-ambler.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/lifecycle_categories-ambler.jpg -------------------------------------------------------------------------------- /images/lifecycle_evolution.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/lifecycle_evolution.jpg -------------------------------------------------------------------------------- /images/lifecycle_spiral-boehm.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/lifecycle_spiral-boehm.jpg -------------------------------------------------------------------------------- /images/lifecycle_spiral-orlik.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/lifecycle_spiral-orlik.jpg -------------------------------------------------------------------------------- /images/lifecycle_waterfall.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/lifecycle_waterfall.jpg -------------------------------------------------------------------------------- /images/maintenance_2-activities.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/maintenance_2-activities.jpg -------------------------------------------------------------------------------- /images/maintenance_3-process.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/maintenance_3-process.jpg -------------------------------------------------------------------------------- /images/maintenance_area_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/maintenance_area_small.jpg -------------------------------------------------------------------------------- /images/maintenance_categories.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/maintenance_categories.jpg -------------------------------------------------------------------------------- /images/management_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/management_small.jpg -------------------------------------------------------------------------------- /images/process_area_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/process_area_small.jpg -------------------------------------------------------------------------------- /images/process_in-out.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/process_in-out.jpg -------------------------------------------------------------------------------- /images/quality_area_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/quality_area_small.jpg -------------------------------------------------------------------------------- /images/requirements_area_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/requirements_area_small.jpg -------------------------------------------------------------------------------- /images/requirements_wiegers.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/requirements_wiegers.jpg -------------------------------------------------------------------------------- /images/swe_1-5_en.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/swe_1-5_en.jpg -------------------------------------------------------------------------------- /images/swe_1-5_ru.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/swe_1-5_ru.jpg -------------------------------------------------------------------------------- /images/swe_6-10_en.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/swe_6-10_en.jpg -------------------------------------------------------------------------------- /images/swe_6-10_ru.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/swe_6-10_ru.jpg -------------------------------------------------------------------------------- /images/swe_other-ka_en.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/swe_other-ka_en.jpg -------------------------------------------------------------------------------- /images/swe_other-ka_ru.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/swe_other-ka_ru.jpg -------------------------------------------------------------------------------- /images/testing_area_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/testing_area_small.jpg -------------------------------------------------------------------------------- /images/tools_area_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ligurio/swebok-2004-in-russian/1bf8f12ff91e5849bd7dfb555899d589623bff9c/images/tools_area_small.jpg -------------------------------------------------------------------------------- /software_lifecycle_models.md: -------------------------------------------------------------------------------- 1 | # Модели жизненного цикла программного обеспечения 2 | 3 | Одним из ключевых понятий управления проектами, в том числе в приложении к 4 | индустрии программного обеспечения, является *жизненный цикл проекта* (*Project 5 | Lifecycle Management* - PLM). 6 | 7 | Известный эксперт по управлению высокотехнологичными проетами Арчибальд так 8 | определяет жизненный цикл проекта [Арчибальд Р., 2003, с.58-59] [Арчибальд Р., 9 | 2005]: 10 | 11 | > “Жизненный цикл проекта имеет определенные начальную и конечную точки, 12 | привязанные к временной шкале. Проект в своем естественном развитии проходит 13 | ряд отдельных фаз. 14 | 15 | > Жизненный цикл проекта включает все фазы от момента инициации до момента 16 | завершения. Переходы от одного этапа к другому редко четко определены, за 17 | исключением тех случаев, когда они формально разделяются принятием предложения 18 | или получением разрешения на продолжение работы. Однако, в начале 19 | концептуальной фазы часто возникают сложности с точным определением момента, 20 | когда работу можно уже идентифицировать как проект (в терминах управления 21 | проектами), особенно если речь идет о разработке нового продукта или новой 22 | услуги. 23 | 24 | > Существует общее соглашение о выделении четырех обобщенных фаз жизненного 25 | цикла (в скобках приведены используемые в различных источниках альтернативные 26 | термины): 27 | - концепция (инициация, идентификация, отбор) 28 | - определение (анализ) 29 | - выполнение (практическая реализация или внедрение, производство и 30 | развертывание, проектирование или конструирование, сдача в эксплуатацию, 31 | инсталляция, тестирование и т.п.) 32 | - закрытие (завершение, включая оценивание после завершения) 33 | 34 | > Однако, эти фазы столь широки, что ... необходимы конкретные определения, 35 | быть может пяти-десяти основных фаз для каждой категории и подкатегории 36 | проекта, обычно с несколькими подфазами, выделяемыми внутри каждой из этих фаз. 37 | 38 | > ...Нередко можно наблюдать частичное совмещение или одновременное выполнение 39 | фаз проекта, называемое “быстрым проходом” в строительных и инжиниринговых 40 | проектах и “параллелизмом” – в военных и аэрокосмических. Это усложняет 41 | планирование проекта и координацию усилий его участников, а также делает более 42 | важной роль менеджера проектов.” 43 | 44 | В общем случае, *жизненный цикл определяется моделью и описывается в форме 45 | методологии (метода)*. *Модель* или *парадигма* жизненного цикла определяет 46 | концептуальный взгляд на организацию жизненного цикла и, часто, основные фазы 47 | жизненного цикла и принципы перехода между ними. *Методология* (метод) задает 48 | комплекс работ, их детальное содержание и ролевую ответственность специалистов 49 | на всех этапах выбранной модели жизненного цикла, обычно определяет и саму 50 | модель, а также рекомендует *практики (best practices)*, позволяющие 51 | максимально эффективно воспользоваться соответствующей методологией и ее 52 | моделью. 53 | 54 | В индустрии программного обеспечения можно (так как это уже конкретная область 55 | приложения концепций и практик проектного управления) и необходимо (для 56 | обеспечения возможности управления) более четкое разграничение фаз проекта (что 57 | не подразумевает их линейного и последовательного выполнения). 58 | 59 | Ниже приведены определения модели жизненного цикла программной системы, 60 | даваемые, например, в различных вариантах стандартов ГОСТ: 61 | - Модель жизненного цикла - структура, состоящая из процессов, работ и задач, 62 | включающих в себя разработку, эксплуатацию и сопровождение программного 63 | продукта, охватывающая жизнь системы от установления требований к ней до 64 | прекращения ее использования [ГОСТ 12207, 1999]. 65 | - Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных 66 | процессов создания и последовательного изменения состояния АС, от формирования 67 | исходных требований к ней до окончания эксплуатации и утилизации комплекса 68 | средств автоматизации АС [ГОСТ 34, 1990]. 69 | 70 | Один из них - ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта 71 | ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий 72 | стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в 73 | СССР самостоятельно, как стандарт на содержание и оформление документов на 74 | программные системы в рамках Единой системы программной документации (ЕСПД) и 75 | Единой системы конструкторской документации (ЕСКД). В последние годы, акцент 76 | делается на стандарты ГОСТ, соответствующие международным стандартам. В то же 77 | время, 34-я серия является важным дополнительным источником информации для 78 | разработки и стандартизации внутрикорпоративных документов и формирования 79 | целостного понимания и видения концепций жизненного цикла в области 80 | программного обеспечения. 81 | 82 | В определённом контексте, “модель” и “методология” могут использоваться 83 | взаимозаменяемым образом, например, когда мы обсуждаем разграничение фаз 84 | проекта. Говоря “жизненный цикл” мы, в первую очередь, подразумеваем “модель 85 | жизненного цикла”. Несмотря на данное в стандартах 12207 определение модели 86 | жизненного цикла, все же, *модель* чаще подразумевает именно *общий принцип* 87 | организации жизненного цикла, чем детализацию соответствующих работ. 88 | Соответственно, определение и выбор модели, в первую очередь, касается вопросов 89 | определенности и стабильности требований, жесткости и детализированности плана 90 | работ, а также частоты сборки работающих версий создаваемой программной 91 | системы. 92 | 93 | Скотт Амблер (Scott W. Ambler) [Ambler, 2005], автор концепций и практик 94 | гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение 95 | Rational Unified Process), предлагает следующие уровни жизненного цикла, 96 | определяемые соответствующим содержанием работ (см. рис.1): 97 | 98 | - Жизненный цикл разработки программного обеспечения – проектная деятельность 99 | по разработке и развертыванию программных систем 100 | - Жизненный цикл программной системы – включает разработку, развертывание, 101 | поддержку и сопровождение 102 | - Жизненный цикл информационных технологий (ИТ) – включает всю деятельность 103 | ИТ-департамента 104 | - Жизненный цикл организации/бизнеса – охватывает всю деятельность организации 105 | в целом 106 | 107 | ![Рисунок 1. Содержание четырех категорий жизненного цикла по Амблеру(используется с разрешения автора) [Ambler, 2005]](images/lifecycle_categories-ambler.jpg) 108 | 109 | В данном контексте, SWEBOK описывает области знаний *жизненного цикла системы* 110 | и *жизненного цикла разработки* программного обеспечения. В свою очередь, как 111 | упоминается в SWEBOK, одним из фундаментальных взглядов на жизненный цикл 112 | является стандарт процессов жизненного цикла ISO/IEC, IEEE, ГОСТ Р ИСО/МЭК 113 | 12207. 114 | 115 | ## Стандарт 12207: Процессы жизненного цикла программного обеспечения 116 | 117 | В 1997 году Международная Организация по Стандартизации - ИСО (International 118 | Organization for Standardization - ISO) и Международная Электротехническая 119 | Комиссия - МЭК (International Electrotechnical Commission - IEC) создали 120 | Совместный Технический Комитет по Информационным Технологиям - Joint Technical 121 | Committee (JTC1) on Information Technology. Содержание работ JTC1 определено 122 | как “стандартизация в области систем и оборудования информационных технологий 123 | (включая микропроцессорные системы)”. В 1989 году этот комитет инициировал 124 | разработку стандарта ISO/IEC 12207, создав для этого подкомитет SC7 125 | (SuСommittee 7) по программной инженерии. Соответствующий стандарт впервые был 126 | опубликован 1-го августа 1995 года под заголовком “Software Life Cycle 127 | Processes” – “Процессы жизненного цикла программного обеспечения”. Национальный 128 | стандарт [ГОСТ 12207, 1999] получил название “Процессы жизненного цикла 129 | программных средств”. 130 | 131 | Цель разработки данного стандарта была определена как создание общего 132 | фреймворка по организации жизненного цикла программного обеспечения для 133 | формирования общего понимания жизненного цикла ПО всеми заинтересованными 134 | сторонами и участниками процесса разработки приобретения, поставки, 135 | эксплуатации, поддержки и сопровождения программных систем, а также возможности 136 | управления, контроля и совершенствования процессов жизненного цикла. 137 | 138 | Данный стандарт определяет жизненный цикл как структуру декомпозиции работ. 139 | Детализация, техники и метрики проведения работ – вопрос программной инженерии. 140 | Организация последовательности работ – модель жизненного цикла. Совокупность 141 | моделей, процессов, техник и организации проектной группы задаются 142 | методологией. В частности, выбор и применение метрик оценки качества 143 | программной системы и процессов находятся за рамками стандарта 12207, а 144 | концепция совершенствования процессов рассматривается в стандарте ISO/IEC 15504 145 | “Information Technology - Software Process Assessment” (“Оценка процессов в 146 | области программного обеспечения”). 147 | 148 | Необходимо отметить заложенные в стандарте ключевые концепции рассмотрения 149 | жизненного цикла программных систем. 150 | 151 | ### Организация стандарта и архитектура жизненного цикла 152 | 153 | Стандарт определяет область его применения, дает ряд важных определений (таких, 154 | как заказчик, разработчик, договор, оценка, выпуск – релиз, программный 155 | продукт, аттестация и т.п.), процессы жизненного цикла и включает ряд 156 | примечаний по процессу и вопросам адаптации стандарта. 157 | 158 | Стандарт описывает 17 процессов жизненного цикла, распределенных по трем 159 | категориям – группам процессов (названия представлены с указанием номеров 160 | разделов стандарта, следуя определениям на русском и английском языке, 161 | определяемыми [ГОСТ 12207, 1999] и оригинальной версией ISO/IEC 12207, 162 | соответственно): 163 | 164 | ### Основные процессы жизненного цикла - Primary Processes 165 | 166 | 5.1 Заказ - Acquisition 167 | 5.2 Поставка - Supply 168 | 5.3 Разработка - Development 169 | 5.4 Эксплуатация - Operation 170 | 5.5 Сопровождение - Maintenance 171 | 172 | ### Вспомогательные процессы жизненного цикла – Supporting Processes 173 | 174 | 6.1 Документирование - Documentation 175 | 6.2 Управление конфигурацией – Configuration Management 176 | 6.3 Обеспечение качества – Quality Assurance 177 | 6.4 Верификация - Verification 178 | 6.5 Аттестация - Validation 179 | 6.6 Совместный анализ – Joint Review 180 | 6.7 Аудит - Audit 181 | 6.8 Решение проблем – Problem Resolution 182 | 183 | ### Организационные процессы жизненного цикла – Organizational Processes 184 | 185 | 7.1 Управление - Management 186 | 7.2 Создание инфраструктуры - Infrastructure 187 | 7.3 Усовершенствование - Improvement 188 | 7.4 Обучение - Training 189 | 190 | Стандарт определяет высокоуровневую архитектуру жизненного цикла. Жизненный 191 | цикл начинается с идеи или потребности, которую необходимо удовлетворить с 192 | использованием программных средств (может быть и не только их). Архитектура 193 | строится как набор процессов и взаимных связей между ними. Например, основные 194 | процессы жизненного цикла обращаются к вспомогательным процессам, в то время, 195 | как организационные процессы действуют на всем протяжении жизненного цикла и 196 | связаны с основными процессами. 197 | 198 | Дерево процессов жизненного цикла представляет собой структуру декомпозиции 199 | жизненного цикла на соответствующие процессы (группы процессов). Декомпозиция 200 | процессов строится на основе двух важнейших принципов , определяющих правила 201 | разбиения (partitioning) жизненного цикла на составляющие процессы. Эти 202 | принципы: 203 | 204 | Модульность 205 | 206 | - задачи в процессе являются функционально связанными; 207 | - связь между процессами – минимальна; 208 | - если функция используется более, чем одним процессом, она сама является 209 | процессом; 210 | - если Процесс Y используется Процессом X и только им, значит Процесс Y 211 | принадлежит (является его частью или его задачей) Процессу X, за исключением 212 | случаев потенциального использования Процесса Y в других процессах в будущем. 213 | 214 | Ответственность 215 | 216 | - каждый процесс находится под ответственностью конкретного лица (управляется 217 | и/или контролируется им), определенного для заданного жизненного цикла, 218 | например, в виде роли в проектной команде; 219 | - функция, чьи части находятся в компетенции различных лиц, не может 220 | рассматриваться как самостоятельный процесс. 221 | 222 | Общая иерархия (декомпозиция) составных элементов жизненного цикла выглядит 223 | следующим образом: 224 | 225 | * группа процессов 226 | * процессы 227 | * работы 228 | * задачи 229 | 230 | В общем случае, разбиение процесса базируется на широко распространённом PDCA-цикле: 231 | 232 | - “P” – Plan – Планирование 233 | - “D” – Do – Выполнение 234 | - “C” – Check – Проверка 235 | - “A” – Act – Реакция (действие) 236 | 237 | Рассмотрим вкратце, какие работы составляют процессы жизненного цикла, помня, 238 | что полное определение работ, как и определение составляющих их задач, дано 239 | непосредственно в стандарте. Ниже приведен краткий обзор основных процессов 240 | жизненного цикла, явно демонстрирующий связь вопросов, касающихся 241 | непосредственно самой программной системы, с системными аспектами ее 242 | функционирования и обеспечения ее эксплуатации. 243 | 244 | ### Основные процессы жизненного цикла 245 | 246 | #### Приобретение (5.1) 247 | 248 | Процесс приобретения (как его называют в ГОСТ – “заказа”) определяет работы и 249 | задачи заказчика, приобретающего программное обеспечение или услуги, связанные 250 | с ПО, на основе контрактных отношений. Процесс приобретения состоит из 251 | следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой 252 | перевод названий работ оригинального стандарта): 253 | 254 | - Inititation – инициирование (подготовка) 255 | - Request-for-proposal preparation – подготовка запроса на предложение 256 | (подготовка заявки на подряд) 257 | - Contract preparation and update –подготовка и корректировка договора 258 | - Supplier monitoring – мониторинг поставщика (надзор за поставщиком) 259 | - Acceptance and completion – приемка и завершение (приемка и закрытие договора) 260 | 261 | Все работы проводятся в рамках проектного подхода. 262 | 263 | #### Поставка (5.2) 264 | 265 | Процесс поставки, в свою очередь, определяет работы и задачи поставщика. Работы 266 | также проводятся с использованием проектного подхода. Процесс включает 267 | следующие работы: 268 | 269 | - Inititation – инициирование (подготовка) 270 | - Preparation of response – подготовка предложения (подготовка ответа) 271 | - Contract – разработка контракта (подготовка договора) 272 | - Planning - планирование 273 | - Execution and control – выполнение и контроль 274 | - Review and evaluation –проверка и оценка 275 | - Delivery and completion – поставка и завершение (поставка и закрытие 276 | договора) 277 | 278 | #### Разработка (5.3) 279 | 280 | Процесс разработки определяет работы и задачи разработчика. Процесс состоит из 281 | следующих работ: 282 | 283 | - Process implementation – определение процесса (подготовка процесса) 284 | - System requirements analysis – анализ системных требований (анализ требований 285 | к системе) 286 | - System design – проектирование системы (проектирование системной архитектуры) 287 | - Software requirements analysis – анализ программных требований (анализ 288 | требований к программным средствам) 289 | - Software architectural design – проектирование программной архитектуры 290 | - Software detailed design – детальное проектирование программной системы 291 | (техническое проектирование программных средств) 292 | - Software coding and testing – кодирование и тестирование (программирование и 293 | тестирование программных средств) 294 | - Software integration – интеграция программной системы (сборка программных 295 | средств) 296 | - Software qualification testing – квалификационные испытания программных 297 | средств 298 | - System integration – интеграция системы в целом (сборка системы) 299 | - System qualification testing – квалификационные испытания системы 300 | - Software installation – установка (ввод в действие) 301 | - Software acceptance support – обеспечение приемки программных средств 302 | 303 | Стандарт отмечает, что работы проводятся с использованием проектного подхода и 304 | могут пересекаться по времени, т.е. проводиться одновременно или с наложением, 305 | а также могут предполагать рекурсию и разбиение на итерации. 306 | 307 | #### Эксплуатация (5.4) 308 | 309 | Процесс разработки определяет работы и задачи оператора службы поддержки. 310 | Процесс включает следующие работы: 311 | 312 | - Process implementation – определение процесса (подготовка процесса) 313 | - Operational testing – операционное тестирование (эксплуатационные испытания) 314 | - System operation – эксплуатация системы 315 | - User support – поддержка пользователя 316 | 317 | #### Сопровождение (5.5) 318 | 319 | Процесс разработки определяет работы и задачи, проводимые специалистами службы 320 | сопровождения. Процесс включает следующие работы: 321 | 322 | - Process implementation – определение процесса (подготовка процесса) 323 | - Problem and modification analysis – анализ проблем и изменений 324 | - Modification implementation – внесение изменений 325 | - Maintenance review/acceptance – проверка и приемка при сопровождении 326 | - Migration – миграция (перенос) 327 | - Software retirement – вывод программной системы из эксплуатации (снятие с 328 | эксплуатации) 329 | 330 | Важно понимать, что стандарт 12207 не определяет последовательность и разбиение 331 | выполнения процессов во времени, адресуя этот вопрос также работам по адаптации 332 | стандарта к конкретным условиям и окружению и применению выбранных моделей, 333 | практик, техник и т.п. 334 | 335 | ### Адаптация стандарта 336 | 337 | Адаптация стандарта* подразумевает применение требований стандарта к 338 | конкретному проекту или проектам, например, в рамках создания 339 | внутрикорпоративных регламентов ведения проектов программного обеспечения. 340 | 341 | Адаптация включает следующие виды работ: 342 | 343 | - Определение исходной информации для адаптации стандарта 344 | - Определение условий выполнения проекта 345 | - Отбор процессов, работ и задач, используемых в проекте или соответствующих регламентах 346 | - Документирование требований, решений и процессов, связанных с адаптацией и 347 | полученных в ее результате 348 | 349 | Адаптация также подразумевает выбор модели (или комбинации моделей) жизненного 350 | цикла, а также применение соответствующих методологий, детализирующих процедуры 351 | выполнения процессов, работ и задач в рамках заданных границ (содержания) 352 | жизненного цикла программного обеспечения и организационной структуры и ролевой 353 | ответственности в конкретной организации (ее подразделении) и/или в проектной 354 | группе. 355 | 356 | * Необходимо отметить, что существует еще один стандарт жизненного цикла - 357 | ISO/IEC 15288 (выпущен в 2002 году), фокусирующийся на вопросах организации 358 | процессов жизненного цикла системного уровня (Life Cycle Processes – System) и 359 | включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию 360 | жизненного цикла к конкретным требованиям и ограничениям, существующим или 361 | принятым в конкретной организации/подразделении или для заданного проекта. 362 | 363 | ## Модели жизненного цикла 364 | 365 | Наиболее часто говорят о следующих моделях жизненного цикла: 366 | 367 | - Каскадная (водопадная) или последовательная 368 | - Итеративная и инкрементальная – эволюционная (гибридная, смешанная) 369 | - Спиральная (spiral) или модель Боэма 370 | 371 | Легко обнаружить, что в разное время и в разных источниках приводится разный 372 | список моделей и их интерпретация. Например, ранее, инкрементальная модель 373 | понималась как построение системы в виде последовательности сборок (релизов), 374 | определенной в соответствии с заранее подготовленным планом и заданными (уже 375 | сформулированными) и неизменными требованиями. Сегодня об инкрементальном 376 | подходе чаще всего говорят в контексте постепенного наращивания 377 | функциональности создаваемого продукта. 378 | 379 | Может показаться, что индустрия пришла, наконец, к общей “правильной” модели. 380 | Однако, каскадная модель, многократно “убитая” и теорией и практикой, 381 | продолжает встречаться в реальной жизни. Спиральная модель является ярким 382 | представителем эволюционного взгляда, но, в то же время, представляет собой 383 | единственную модель, которая уделяет явное внимание анализу и предупреждению 384 | рисков. Поэтому, я попытался именно представленным выше образом выделить три 385 | модели – каскадную, эволюционную и спиральную. Их мы и обсудим. 386 | 387 | ### Каскадная (водопадная) модель 388 | 389 | Данная модель предполагает строго последовательное (во времени) и однократное 390 | выполнение всех фаз проекта с жестким (детальным) предварительным планированием 391 | в контексте предопределенных или однажды и целиком определенных требований к 392 | программной системе. 393 | 394 | ![Рисунок 2. Каскадная модель жизненного цикла.](images/lifecycle_waterfall.jpg) 395 | 396 | На рисунке изображены типичные фазы каскадной модели жизненного цикла и 397 | соответствующие активы проекта, являющиеся для одних фаз выходами, а для других 398 | - входами. Марри Кантор [Кантор, 2002, с.145-146] отмечает ряд важных аспектов, 399 | характерных для водопадной модели: “Водопадная схема включает несколько важных 400 | операций, применимых ко всем проектам: 401 | 402 | - составление плана действий по разработке системы; 403 | - планирование работ, связанных с каждым действием; 404 | - применение операции отслеживания хода выполнения действий с контрольными 405 | этапами. 406 | 407 | В связи с тем, что упомянутые задачи являются неотъемлемым элементом всех 408 | хорошо управляемых процессов, практически не существует причин, препятствующих 409 | утверждению полнофункциональных, классических методов руководства проектом, 410 | таких как анализ критического пути и промежуточные контрольные этапы. Я часто 411 | встречался с программными менеджерами, которые ломали себе голову над тем, 412 | почему же столь эффективный набор методик на практике оборачивается 413 | неудачей...” 414 | 415 | Будучи активно используема (де факто и, например, в свое время, как часть 416 | соответствующего отраслевого стандарта в США), эта модель продемонстрировала 417 | свою “проблемность” в подавляющем большинстве ИТ-проектов, за исключением, 418 | может быть, отдельных проектов обновления программных систем для 419 | критически-важных программно-аппаратных комплексов (например, авионики или 420 | медицинского оборудования). Практика показывает, что в реальном мире, особенно 421 | в мире бизнес-систем, каскадная модель не должна применяться. Специфика таких 422 | систем (если можно говорить о “специфике” для подавляющего большинства 423 | создаваемых систем) - требования характеризуются высокой динамикой 424 | корректировки и уточнения, невозможностью четкого и однозначного определения 425 | требований до начала работ по реализации (особенно, для новых систем) и быстрой 426 | изменчивостью в процессе эксплуатации системы. 427 | 428 | Фредерик Брукс во втором издании своего классического труда “Мифический 429 | человеко-месяц” так описывает главную беду каскадной модели [Брукс, 1995, 430 | с.245]: 431 | 432 | > “Основное заблуждение каскадной модели состоит в предположениях, что проект 433 | проходит через весь процесс один раз, архитектура хороша и проста в 434 | использовании, проект осуществления разумен, а ошибки в реализации устраняются 435 | по мере тестирования. Иными словами, каскадная модель исходит из того, что все 436 | ошибки будут сосредоточены в реализации, а потому их устранение происходит 437 | равномерно во время тестирования компонентов и системы.” 438 | 439 | В каскадной модели переход от одной фазы проекта к другой предполагает полную 440 | корректность результата (выхода) предыдущей фазы. Однако, например, неточность 441 | какого-либо требования или некорректная его интерпретация, в результате, 442 | приводит к тому, что приходится “откатываться” к ранней фазе проекта и 443 | требуемая переработка не просто выбивает проектную команду из графика, но 444 | приводит часто к качественному росту затрат и, не исключено, к прекращению 445 | проекта в той форме, в которой он изначально задумывался. Кроме того, эта 446 | модель не способна гарантировать необходимую скорость отклика и внесение 447 | соответствующих изменений в ответ на быстро меняющиеся потребности 448 | пользователей, для которых программная система является одним из инструментов 449 | исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой 450 | модели, можно привести достаточно много. Достаточно для чего? Для отказа от 451 | каскадной модели жизненного цикла. 452 | 453 | ### Итеративная и инкрементальная модель – эволюционный подход 454 | 455 | Итеративная модель предполагает разбиение жизненного цикла проекта на 456 | последовательность итераций, каждая из которых напоминает “мини-проект”, 457 | включая все фазы жизненного цикла в применении к созданию меньших фрагментов 458 | функциональности, по сравнению с проектом, в целом. Цель каждой итерации – 459 | получение работающей версии программной системы, включающей функциональность, 460 | определенную интегрированным содержанием всех предыдущих и текущей итерации. 461 | Результата финальной итерации содержит всю требуемую функциональность продукта. 462 | Таким образом, с завершением каждой итерации, продукт развивается 463 | инкрементально. 464 | 465 | С точки зрения структуры жизненного цикла такую модель называют итеративной 466 | (iterative). С точки зрения развития продукта – инкрементальной (incremental). 467 | Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов 468 | изолировано. Чаще всего такую смешанную эволюционную модель называют просто 469 | итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании 470 | функциональности продукта). 471 | 472 | Эволюционная модель подразумевает не только сборку работающей (с точки зрения 473 | результатов тестирования) версии системы, но и её развертывание в реальных 474 | операционных условиях с анализом откликов пользователей для определения 475 | содержания и планирования следующей итерации. “Чистая” инкрементальная модель 476 | не предполагает развертывания промежуточных сборок (релизов) системы и все 477 | итерации проводятся по заранее определённому плану наращивания 478 | функциональности, а пользователи (заказчик) получает только результат финальной 479 | итерации как полную версию системы. С другой стороны, Скотт Амблер [Ambler, 480 | 2004], например, определяет эволюционную модель как сочетание итеративного и 481 | инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47] 482 | пишет: “Итеративную разработку называют по-разному: инкрементальной, 483 | спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины 484 | разный смысл, но эти различия не имеют широкого признания и не так важны, как 485 | противостояние итеративного метода и метода водопада.” 486 | Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему: 487 | 488 | - можно очень рано начать тестирование пользователями; 489 | - можно принять стратегию разработки в соответствии с бюджетом, полностью 490 | защищающую от перерасхода времени или средств (в частности, за счет сокращения 491 | второстепенной функциональности). 492 | 493 | Таким образом, Значимость эволюционного подхода на основе организации итераций 494 | особо проявляется в снижении неопределенности с завершением каждой итерации. В 495 | свою очередь, снижение неопределенности позволяет уменьшить риски. Рисунок 3 496 | иллюстрирует некоторые идеи эволюционного подхода, предполагая, что 497 | итеративному разбиению может быть подвержен не только жизненный цикл в целом, 498 | включающий перекрывающиеся фазы – формирование требований, проектирование, 499 | конструирование и т.п., но и каждая фаза может, в свою очередь, разбиваться на 500 | уточняющие итерации, связанные, например, с детализацией структуры декомпозиции 501 | проекта – например, архитектуры модулей системы. 502 | 503 | ![Рисунок 3. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла.](images/lifecycle_evolution.jpg) 504 | 505 | Наиболее известным и распространённым вариантом эволюционной модели является 506 | спиральная модель, ставшая уже по сути самостоятельной моделью, имеющей 507 | различные сценарии развития и детализации. 508 | 509 | ### Спиральная модель 510 | 511 | Спиральная модель (представлена на рисунке 4) была впервые сформулирована Барри 512 | Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой 513 | модели является специальное внимание рискам, влияющим на организацию жизненного 514 | цикла. 515 | 516 | Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков 517 | (используется с разрешения автора): 518 | 519 | 1. Дефицит специалистов. 520 | 1. Нереалистичные сроки и бюджет. 521 | 1. Реализация несоответствующей функциональности. 522 | 1. Разработка неправильного пользовательского интерфейса. 523 | 1. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание 524 | деталей. 525 | 1. Непрекращающийся поток изменений. 526 | 1. Нехватка информации о внешних компонентах, определяющих окружение системы 527 | или вовлеченных в интеграцию. 528 | 1. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. 529 | 1. Недостаточная производительность получаемой системы. 530 | 1. “Разрыв” в квалификации специалистов разных областей знаний. 531 | 532 | Большая часть этих рисков связана с организационными и процессными аспектами 533 | взаимодействия специалистов в проектной команде. 534 | 535 | ![Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму (используется с разрешения автора) [Boehm, 1988]](images/lifecycle_spiral-boehm.jpg) 536 | 537 | Сам Барри Боэм так характеризует спиральную модель разработки (используется с 538 | разрешения автора): 539 | 540 | > “Главное достижение спиральной модели состоит в том, что она предлагает 541 | спектр возможностей адаптации удачных аспектов существующих моделей процессов 542 | жизненного цикла. В то же время, ориентированный на риски подход позволяет 543 | избежать многих сложностей, присутствующих в этих моделях. В определенных 544 | ситуациях спиральная модель становится эквивалентной одной из существующих 545 | моделей. В других случаях она обеспечивает возможность наилучшего соединения 546 | существующих подходов в контексте данного проекта. 547 | 548 | > Спиральная модель обладает рядом преимуществ: 549 | 550 | > Модель уделяет специальное внимание раннему анализу возможностей повторного 551 | использования. Это обеспечивается, в первую очередь, в процессе идентификации и 552 | оценки альтернатив. 553 | 554 | > Модель предполагает возможность эволюции жизненного цикла, развитие и 555 | изменение программного продукта. Главные источники изменений заключены в целях, 556 | для достижения которых создается продукт. Подход, предусматривающий скрытие 557 | информации о деталях на определённом уровне дизайна, позволяет рассматривать 558 | различные архитектурные альтернативы так, как если бы мы говорили о 559 | единственном проектном решении, что уменьшает риск невозможности согласования 560 | функционала продукта и изменяющихся целей (требований). 561 | 562 | > Модель предоставляет механизмы достижения необходимых параметров качества как 563 | составную часть процесса разработки программного продукта. Эти механизмы 564 | строятся на основе идентификации всех типов целей (требований) и ограничений на 565 | всех “циклах” спирали разработки. Например, ограничения по безопасности могут 566 | рассматриваться как риски на этапе специфицирования требований. 567 | 568 | > Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию 569 | ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах 570 | проекта. Это достигается явно определёнными работами по анализу рисков, 571 | проверке различных характеристик создаваемого продукта (включая архитектуру, 572 | соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше 573 | на каждом “цикле” процесса разработки. 574 | 575 | > Модель позволяет контролировать источники проектных работ и соответствующих 576 | затрат. По-сути речь идет об ответе на вопрос – как много усилий необходимо 577 | затратить на анализ требований, планирование, конфигурационное управление, 578 | обеспечение качества, тестирование, формальную верификацию и т.д. Модель, 579 | ориентированная на риски, позволяет в контексте конкретного проекта решить 580 | задачу приложения адекватного уровня усилий, определяемого уровнем рисков, 581 | связанных с недостаточным выполнением тех или иных работ. 582 | 583 | > Модель не проводит различий между разработкой нового продукта и расширением 584 | (или сопровождением) существующего. Этот аспект позволяет избежать часто 585 | встречающегося отношения к поддержке и сопровождению как ко “второсортной” 586 | деятельности. Такой подход предупреждает большого количество проблем, 587 | возникающих в результате одинакового уделения внимания как обычному 588 | сопровождению, так и критичным вопросам, связанным с расширением 589 | функциональности продукта, всегда ассоциированным с повышенными рисками. 590 | 591 | > Модель позволяет решать интегрированные задачи системной разработки, 592 | охватывающей и программную и аппаратную составляющие создаваемого продукта. 593 | Подход, основанный на управлении рисками и возможности своевременного 594 | отбрасывания непривлекательных альтернатив (на ранних стадиях проекта) 595 | сокращает расходы и одинаково применим и к аппаратной части, и к программному 596 | обеспечению.” 597 | 598 | Описывая созданную спиральную модель, Боэм обращает внимание на то, что обладая 599 | явными преимуществами по сравнению с другими взглядами на жизненный цикл, 600 | необходимо уточнить, детализировать шаги, т.е. циклы спиральной модели для 601 | обеспечения целостного контекста для всех лиц, вовлеченных в проект (Боэм это 602 | формулирует так: “Need for further elaboration of spiral model steps. In 603 | general, the spiral model process steps need further elaboration to ensure that 604 | all software development participants are operating in a consistent context.”). 605 | Организация ролей (ответственности членов проектной команды), детализация 606 | этапов жизненного цикла и процессов, определение активов (артефактов), значимых 607 | на разных этапах проекта, практики анализа и предупреждения рисков – все это 608 | вопросы уже конкретного процессного фреймворка или, как принято говорить, 609 | *методологии разработки*. 610 | 611 | Действительно, детализация процессов, ролей и активов – вопрос методологии. 612 | Однако, рассматривая (спиральную) модель разработки, являясь концептуальным 613 | взглядом на создание продукта, требует, как и в любом проекте, *определения 614 | ключевых контрольных точек проекта - milestones*. Это, в большой степени, 615 | связано с попыткой ответить на вопрос “где мы?”. Вопрос, особенно актуальный 616 | для менеджеров и лидеров проектов, отслеживающих ход их выполнения и 617 | планирующих дальнейшие работы. 618 | В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели 619 | и, в частности, построенного на его основе подхода MBASE - Model-Based (System) 620 | Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых 621 | характеристик или практик, обеспечивающих успешное применение спиральной 622 | модели: 623 | 624 | 1. Параллельное, а не последовательное определение артефактов (активов) проекта 625 | 1. Согласие в том, что на каждом цикле уделяется внимание: 626 | 627 | - целям и ограничениям, важным для заказчика 628 | - альтернативам организации процесса и технологических решений, закладываемых в продукт 629 | - идентификации и разрешению рисков 630 | - оценки со стороны заинтересованных лиц (в первую очередь заказчика) 631 | - достижению согласия в том, что можно и необходимо двигаться дальше 632 | 1. Использование соображений, связанных с рисками, для определения уровня 633 | усилий, необходимого для каждой работы на всех циклах спирали. 634 | 1. Использование соображений, связанных с рисками, для определения уровня 635 | детализации каждого артефакта, создаваемого на всех циклах спирали. 636 | 1. Управление жизненным циклом в контексте обязательств всех заинтересованных 637 | лиц на основе трех контрольных точек: 638 | - Life Cycle Objectives (LCO) 639 | - Life Cycle Architecture (LCA) 640 | - Initial Operational Capability (IOC) 641 | 1. Уделение специального внимания проектным работам и артефактам создаваемой 642 | системы (включая непосредственно разрабатываемое программное обеспечение, ее 643 | окружение, а также эксплуатационные характеристики) и жизненного цикла 644 | (разработки и использования). 645 | 646 | Эволюционирование спиральной модели, таким образом, связано с вопросами 647 | детализации работ. Особенно стоит выделить акцент на большем внимании вопросам 648 | уточнения – требований, дизайна и кода, т.е. придание большей важности вопросам 649 | итеративности, в том числе, увеличения их количества при сокращении 650 | длительности каждой итерации. 651 | 652 | В результате, можно определить общий набор контрольных точек в сегодняшней 653 | спиральной модели: 654 | 655 | - *Concept of Operations (COO)* – концепция использования системы; 656 | - *Life Cycle Objectives (LCO)* – цели и содержание жизненного цикла; 657 | - *Life Cycle Architecture (LCA)* – архитектура жизненного цикла; здесь же 658 | возможно говорить о готовности концептуальной архитектуры целевой программной 659 | системы; 660 | - *Initial Operational Capability (IOC)* – первая версия создаваемого продукта, 661 | пригодная для опытной эксплуатации; 662 | - *FinalOperationalCapability (FOC)* – готовый продукт, развернутый 663 | (установленный и настроенный) для реальной эксплуатации. 664 | Таким образом, мы приходим к возможному современному взгляду (см., например, 665 | представление спиральной модели в [Фатрелл, Шафер и Шафер, 2003, с.159]) на 666 | итеративный и инкрементальный – эволюционный жизненный цикл в форме спиральной 667 | модели, изображенной на рисунке 5. 668 | 669 | ![Рисунок 5. Обновленная спиральная модель c контрольными точками проекта. (данное представление создано Сергеем Орликом на основе оригинальной модели Боэма и ее модификациях)](images/lifecycle_spiral-orlik.jpg) 670 | 671 | Похоже, нам удалось более четко и естественно определить контрольные точки 672 | проекта, в определенной степени, подчеркнув эволюционную природу жизненного 673 | цикла. Теперь же пора взглянуть на жизненный цикл в контексте методологий, не 674 | просто детализирующих ту или иную модель, но добавляющих к ним ключевой элемент 675 | – людей. Роли, как представление различных функциональных групп работ, 676 | связывает создание, модификацию и использование активов проектов с конкретными 677 | участниками проектных команд. В совокупности с процессами и активами 678 | (артефактами) они позволяют нам создать целостную и подробную картину 679 | жизненного цикла. 680 | 681 | Так как взглядов на детализацию описания жизненного цикла может быть много – 682 | безусловно, существуют различные методологии, среди которых наибольшее 683 | распространение получили: 684 | 685 | - Rational Unified Process (RUP) 686 | - Enterprise Unified Process (EUP) 687 | - Microsoft Solutions Framework (MSF) в обоих представлениях: MSF for Agile и 688 | MSF for CMMI (анонсированная изначально как “MSF Formal”) 689 | - Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), 690 | Dynamic Systems Development Method (DSDM), SCRUM,...). 691 | -------------------------------------------------------------------------------- /title.txt: -------------------------------------------------------------------------------- 1 | --- 2 | title: Основы Программной Инженерии (по SWEBOK) 3 | author: Сергей Орлик 4 | cover-image: images/Terrace.jpg 5 | rights: SWEBOK Сopyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved. 6 | language: ru-RU 7 | ... 8 | --------------------------------------------------------------------------------