commit e1f8392c8c392c100a1cd65878b436ab5acd657f from: Sergey Bronnikov date: Sat Jan 20 11:46:33 2024 UTC Replace extension .markdown with .md commit - 7da603ded1215505208a4e3bc5ba572a0d5ccfbd commit + e1f8392c8c392c100a1cd65878b436ab5acd657f blob - 07378492c1e705ec5ea1213666e81a910b7dd1b7 (mode 644) blob + /dev/null --- 0_introduction.markdown +++ /dev/null @@ -1,194 +0,0 @@ -# Введение - -В конце 90-х годов прошлого века знания и опыт, которые были накоплены в -индустрии программного обеспечения за предшествующие 30-35 лет, а также более -чем 15-летних попыток применения различных моделей разработки, все это, -наконец, оформилось в то, что принято называть дисциплиной программной -инженерии – Software Engineering. В какой-то мере, такое формирование -дисциплины на основе широко распространенного практического опыта напоминает те -процессы, которые происходили в управлении проектами. Возникали и развивались -профессиональные ассоциации, специализированные институты, комитеты по -стандартизации и другие образования, которые, в конце концов, пришли к общему -мнению о необходимости сведения профессиональных знаний по соответствующим -областям и стандартизации соответствующих программ обучения. - -## Программная инженерия как дисциплина - -В 1958 всемирно известный статистик Джон Тьюкей (John Tukey) впервые ввел -термин *software* – программное обеспечение. В 1972 году IEEE[^1] выпустил первый -номер *Transactions on Software Engineering* – Труды по Программной Инженерии. -Первый целостный взгляд на эту область профессиональной деятельности появился -1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730 -по качеству программного обеспечения. После 7 лет напряженной работы, в 1986 -году IEEE выпустило IEEE Std 1002 “Taxonomy of Software Engineering Standards”. - -Наконец, в 1990 году началось планирование всеобъемлющих *международных* -стандартов, в основу которых легли концепции и взгляды стандарта IEEE Std 1074 -и результатов работы образованной в 1987 году совместной комиссии ISO/IEC JTC 1[^2]. -В 1995 году группа этой комиссии SC7 “Software Engineering” -выпустила первую версию международного стандарта ISO/IEC 12207 “Software -Lifecycle Processes”. Этот стандарт стал первым опытом создания единого общего -взгляда на программную инженерию. Соответствующий национальный стандарт России -– ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207, 1999] содержит полный аутентичный -перевод текста международного стандарта ISO/IEC 12207-95 (1995 года). - -В свою очередь, IEEE и ACM[^3], начав совместные работы еще в 1993 году -с кодекса этики и профессиональной практики в данной области (ACM/IEEE-CS Code -of Ethics and Professional Practice), к 2004 году сформулировали два ключевых -описания того, что сегодня мы и называем основами программной инженерии – -Software Engineering: -- *Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 -Version* - Руководство к Своду Знаний по Программной Инженерии, в дальнейшем -просто “SWEBOK” [SWEBOK, 2004]; -- *Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree -Programs in Software Engineering* – Учебный План для Преподавания Программной -Инженерии в ВУЗах (данное название на русском языке представлено в -вольном смысловом переводе) [SE, 2004]. - -[^1]: IEEE - Computer Society of the Institute for Electrical and Electronic -Engineers, IEEE Computer Society – IEEE-CS (Компьютерное Общество) или просто -IEEE. https://www.ieee.org - -[^2]: ISO – International Organization for Standardization. https://www.iso.ch ; -IEC – International Electrotechnical Commission; JTC 1 – Joint Technical -Committee 1, Information technology - -[^3]: ACM – Association of Computer Machinery - -Оба стандарта стали результатом консенсуса ведущих представителей индустрии и -признанных авторитетов в области программной инженерии - по аналогии с тем, как -был создан PMI PMBOK. Так мы пришли к сегодняшнему состоянию Software -Engineering как дисциплины. - -## SWEBOK: Руководство к своду знаний по программной инженерии - -C 1993 года IEEE и ACM координируют свои работы в рамках специального совместного комитета - Software Engineering Coordinating Committee (SWECC - http://www.computer.org/tab/swecc). Проект SWEBOK был инициирован этим комитетом в 1998 году. Оцененный предположительный объем содержания SWEBOK и другие факторы привели к тому, что было рекомендовано проводить работы по реализации проекта не только силами добровольцев из рядов экспертов индустрии и представителей крупнейших потребителей и производителей программного обеспечения, но и на основе принципа “полной занятости”. Базовый комплекс работ, в соответствии со специальным контрактом, был передан в Software Engineering Management Research Laboratory Университета Квебек в Монреале (Universite du Quebec a Montreal). Среди компаний, поддержавших этот уникальный проект были Boeing, MITRE, Raytheon, SAP. В результате проекта, оcуществленного при финансовой поддержке этих и других компаний и организаций, а также с учетом его значимости для индустрии, SWEBOK Advisory Committee (SWAC) принял решение сделать SWEBOK 2004 trial edition общедоступной. В перспективе, в зависимости от финансирования, SWAC считал необходимым законченную версию SWEBOK (изначально планировалось, что она будет готова в 2008 году) сделать также свободно доступной на Web-сайте проекта – http://www.swebok.org. Сегодняшняя “публичность” (общедоступность) результатов проекта стала возможна, в первую очередь, именно благодаря поддержке SWEBOK Industrial Advisory Board (IAB) – структуры, объединяющей представителей компаний, поддержавших проект. - -Проект SWEBOK планировался в виде трех фаз: *Strawman* (“соломенный человек”), -*Stoneman* (“каменный человек”) и *Ironman* (“железный человек”). К 2004 году -была выпущена версия Руководства по Своду Знаний 3-ей фазы - Ironman, то есть -максимально приближенная к окончательному варианту и одобренная IEEE в феврале -2005 года к публикации в качестве Trial-версии. Основная цель текущей “пробной” -версии SWEBOK – улучшить представление, целостность и полезность материала -руководства на основе сбора и анализа откликов на данную версию с тем, чтобы -выпустить финальную редакцию документа в 2008 году. Однако версии 2008 не -появилось, хотя ряд дополнений на начало 2010 года и находится уже в виде -драфтов, что не исключает расширения SWEBOK в ближайшей перспективе и, в то же -время, не принижает значимости уже выпущенной версии 2004. - -По ряду обоснованных причин, “SWEBOK является достаточно консервативным” -[SWEBOK, 2004, с.B-2]. После 6 лет непосредственных работ над документом, -SWEBOK включал “лишь” 10 *областей знаний* (*knowledge areas*, KA). При этом, -что справедливо и для PMBOK, добавление новых областей знаний в SWEBOK -достаточно прозрачно. Все, что для этого необходимо, зрелость (или, по крайней -мере, явный и быстрый процесс достижения зрелости) и общепринятость[^4] -соответствующей области знаний, если это не приведет к серьезному усложнению -SWEBOK. - -[^4]: Концепция “общепринятости” - generally accepted – определена в IEEE -Std 1490-1998, Adoption of PMI Standard — A Guide to the Project Management -Body of Knowledge - -Важно понимать, что программная инженерия является развивающейся дисциплиной. -Более того, данная дисциплина не касается вопросов конкретизации применения тех -или иных языков программирования, архитектурных решений или, тем более, -рекомендаций, касающихся более или менее распространенных или развивающихся с -той или иной степенью активности/заметности технологий (например, web-служб). -Руководство к своду знаний, каковым является SWEBOK, включает базовое -определение и описание областей знаний (например, конфигурационное управление – -configuration management) и, безусловно, является *недостаточным* для охвата -всех вопросов, относящихся к вопросам создания программного обеспечения, но, в -то же время *необходимым* для их понимания. - -Необходимо отметить, что одной из важнейших целей SWEBOK является именно -определение и систематизация тех аспектов деятельности, которые составляют суть -профессии инженера-программиста. - -## Структура и содержание SWEBOK - -Описание областей знаний в SWEBOK построено по иерархическому принципу, как -результат структурной декомпозиции. Такое иерархическое построение обычно -насчитывает два-три уровня детализации, принятых для идентификации тех или иных -общепризнанных аспектов программной инженерии. При этом, структура декомпозиции -областей знаний детализирована только до того уровня, который необходим для -понимания природы соответствующих тем и возможности нахождения источников -компетенции и других справочных данных и материалов. В принципе, считается, что -как таковой “свод знаний” по программной инженерии представлен не в обсуждаемом -руководстве (SWEBOK), а в первоисточниках (как указанных в нем, так и -представленных за его рамками) [SWEBOK, 2004, с.1-2]. - -SWEBOK описывает 10 областей знаний: - -- Software requirements – программные требования -- Software design – дизайн (архитектура) -- Software construction – конструирование программного обеспечения -- Software testing - тестирование -- Software maintenance – эксплуатация (поддержка) программного обеспечения -- Software configuration management – конфигурационное управление -- Software engineering management – управление в программной инженерии -- Software engineering process – процессы программной инженерии -- Software engineering tools and methods – инструменты и методы -- Software quality – качество программного обеспечения - -В дополнение к ним, SWEBOK также включает обзор смежных дисциплин, связь с -которыми представлена как фундаментальная, важная и обоснованная для -программной инженерии: - -- Computer engineering -- Computer science -- Management -- Mathematics -- Project management -- Quality management -- Systems engineering - -Стоит отметить, что принятые разграничения между областями знаний, их -компонентами (subareas) и другими элементами достаточно произвольны. При этом, -в отличие от PMBOK, области знаний SWEBOK не включают “входы” и “выходы”. В -определенной степени такая декомпозиция связаны с тем, что SWEBOK не -ассоциирован с той или иной моделью (например, жизненного цикла) или методом. -Хотя на первый взгляд первые пять областей знаний в SWEBOK представлены в -традиционной последовательной (каскадной - waterfall) модели, это не более чем -следование принятой последовательности освещения соответствующих тем. Остальные -области и структура декомпозиции областей представлены в алфавитном порядке. - -Для каждой области знаний SWEBOK описывает ключевые акронимы, представляет -область в виде “подобластей” (subareas) или как их часто называют в самом -SWEBOK – “секций” и дает декомпозицию каждой секции в форме списка тем (topics) -с их описанием. - -![Рисунок 1-а. Первые пять областей знаний SWEBOK на английском языке](images/swe_1-5_en.jpg) - -![Рисунок 1-б. Первые пять областей знаний SWEBOK на русском языке](images/swe_1-5_ru.jpg) - -![Рисунок 2-а. Вторые пять областей знаний SWEBOK на английском языке](images/swe_6-10_en.jpg) - -![Рисунок 2-б. Вторые пять областей знаний SWEBOK на русском языке](images/swe_6-10_ru.jpg) - -![Рисунок 3-а. Области знаний связанных дисциплин на английском языке](images/swe_other-ka_en.jpg) - -![Рисунок 3-б. Области знаний связанных дисциплин на русском языке](images/swe_other-ka_ru.jpg) - - -## Перевод SWEBOK на русский язык - -Учитывая, что существует ряд неоднозначностей и фактически отсутствует -консенсус по соответствующей терминологии на русском языке, далее в книге будут -использоваться как оригинальные термины на английском языке, так и те их -представления по-русски, которые кажутся представляются наиболее адекватными в -соответствующем контексте. - -К моменту начала работы над представленным переводом SWEBOK в 2004 году, каких-либо даже фрагментарных переводов SWEBOK на русский язык не существовало. В то же время, несмотря на спорность некоторых положений SWEBOK, значимость его для индустрии программного обеспечения как первой коллективной попытки систематизации накопленных знаний просто сложно переоценить. Представленный далее перевод SWEBOK - Руководство к своду знаний по программной инженерии необходимо рассматривать как авторский перевод с замечаниями и комментариями ключевых положений SWEBOK. Такой подход ни в коем случае не подменяет оригинального SWEBOK и является всего лишь авторским прочтением последнего. - -> Представленный перевод SWEBOK 2004 никак не заменяет первоисточника и создан -> [Сергеем Орликом](https://www.linkedin.com/in/sorlik) при участии [Юрия -> Булуя](http://www.linkedin.com/in/yurybuluy) без какой-либо поддержки IEEE или -> других структур по собственной инициативе в полном соответствии со SWEBOK -> Copyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc. -> All rights reserved. Copyright and Reprint 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 (1) alterations are clearly marked as alterations -> and (2) this copyright notice is included unmodified in any copy. Далее перевод -> соответствующих глав SWEBOK включает расширения (замечания и комментарии), -> помеченные цветом, отличным от цвета перевода оригинального содержания -> SWEBOK. blob - /dev/null blob + 07378492c1e705ec5ea1213666e81a910b7dd1b7 (mode 644) --- /dev/null +++ 0_introduction.md @@ -0,0 +1,194 @@ +# Введение + +В конце 90-х годов прошлого века знания и опыт, которые были накоплены в +индустрии программного обеспечения за предшествующие 30-35 лет, а также более +чем 15-летних попыток применения различных моделей разработки, все это, +наконец, оформилось в то, что принято называть дисциплиной программной +инженерии – Software Engineering. В какой-то мере, такое формирование +дисциплины на основе широко распространенного практического опыта напоминает те +процессы, которые происходили в управлении проектами. Возникали и развивались +профессиональные ассоциации, специализированные институты, комитеты по +стандартизации и другие образования, которые, в конце концов, пришли к общему +мнению о необходимости сведения профессиональных знаний по соответствующим +областям и стандартизации соответствующих программ обучения. + +## Программная инженерия как дисциплина + +В 1958 всемирно известный статистик Джон Тьюкей (John Tukey) впервые ввел +термин *software* – программное обеспечение. В 1972 году IEEE[^1] выпустил первый +номер *Transactions on Software Engineering* – Труды по Программной Инженерии. +Первый целостный взгляд на эту область профессиональной деятельности появился +1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730 +по качеству программного обеспечения. После 7 лет напряженной работы, в 1986 +году IEEE выпустило IEEE Std 1002 “Taxonomy of Software Engineering Standards”. + +Наконец, в 1990 году началось планирование всеобъемлющих *международных* +стандартов, в основу которых легли концепции и взгляды стандарта IEEE Std 1074 +и результатов работы образованной в 1987 году совместной комиссии ISO/IEC JTC 1[^2]. +В 1995 году группа этой комиссии SC7 “Software Engineering” +выпустила первую версию международного стандарта ISO/IEC 12207 “Software +Lifecycle Processes”. Этот стандарт стал первым опытом создания единого общего +взгляда на программную инженерию. Соответствующий национальный стандарт России +– ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207, 1999] содержит полный аутентичный +перевод текста международного стандарта ISO/IEC 12207-95 (1995 года). + +В свою очередь, IEEE и ACM[^3], начав совместные работы еще в 1993 году +с кодекса этики и профессиональной практики в данной области (ACM/IEEE-CS Code +of Ethics and Professional Practice), к 2004 году сформулировали два ключевых +описания того, что сегодня мы и называем основами программной инженерии – +Software Engineering: +- *Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 +Version* - Руководство к Своду Знаний по Программной Инженерии, в дальнейшем +просто “SWEBOK” [SWEBOK, 2004]; +- *Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree +Programs in Software Engineering* – Учебный План для Преподавания Программной +Инженерии в ВУЗах (данное название на русском языке представлено в +вольном смысловом переводе) [SE, 2004]. + +[^1]: IEEE - Computer Society of the Institute for Electrical and Electronic +Engineers, IEEE Computer Society – IEEE-CS (Компьютерное Общество) или просто +IEEE. https://www.ieee.org + +[^2]: ISO – International Organization for Standardization. https://www.iso.ch ; +IEC – International Electrotechnical Commission; JTC 1 – Joint Technical +Committee 1, Information technology + +[^3]: ACM – Association of Computer Machinery + +Оба стандарта стали результатом консенсуса ведущих представителей индустрии и +признанных авторитетов в области программной инженерии - по аналогии с тем, как +был создан PMI PMBOK. Так мы пришли к сегодняшнему состоянию Software +Engineering как дисциплины. + +## SWEBOK: Руководство к своду знаний по программной инженерии + +C 1993 года IEEE и ACM координируют свои работы в рамках специального совместного комитета - Software Engineering Coordinating Committee (SWECC - http://www.computer.org/tab/swecc). Проект SWEBOK был инициирован этим комитетом в 1998 году. Оцененный предположительный объем содержания SWEBOK и другие факторы привели к тому, что было рекомендовано проводить работы по реализации проекта не только силами добровольцев из рядов экспертов индустрии и представителей крупнейших потребителей и производителей программного обеспечения, но и на основе принципа “полной занятости”. Базовый комплекс работ, в соответствии со специальным контрактом, был передан в Software Engineering Management Research Laboratory Университета Квебек в Монреале (Universite du Quebec a Montreal). Среди компаний, поддержавших этот уникальный проект были Boeing, MITRE, Raytheon, SAP. В результате проекта, оcуществленного при финансовой поддержке этих и других компаний и организаций, а также с учетом его значимости для индустрии, SWEBOK Advisory Committee (SWAC) принял решение сделать SWEBOK 2004 trial edition общедоступной. В перспективе, в зависимости от финансирования, SWAC считал необходимым законченную версию SWEBOK (изначально планировалось, что она будет готова в 2008 году) сделать также свободно доступной на Web-сайте проекта – http://www.swebok.org. Сегодняшняя “публичность” (общедоступность) результатов проекта стала возможна, в первую очередь, именно благодаря поддержке SWEBOK Industrial Advisory Board (IAB) – структуры, объединяющей представителей компаний, поддержавших проект. + +Проект SWEBOK планировался в виде трех фаз: *Strawman* (“соломенный человек”), +*Stoneman* (“каменный человек”) и *Ironman* (“железный человек”). К 2004 году +была выпущена версия Руководства по Своду Знаний 3-ей фазы - Ironman, то есть +максимально приближенная к окончательному варианту и одобренная IEEE в феврале +2005 года к публикации в качестве Trial-версии. Основная цель текущей “пробной” +версии SWEBOK – улучшить представление, целостность и полезность материала +руководства на основе сбора и анализа откликов на данную версию с тем, чтобы +выпустить финальную редакцию документа в 2008 году. Однако версии 2008 не +появилось, хотя ряд дополнений на начало 2010 года и находится уже в виде +драфтов, что не исключает расширения SWEBOK в ближайшей перспективе и, в то же +время, не принижает значимости уже выпущенной версии 2004. + +По ряду обоснованных причин, “SWEBOK является достаточно консервативным” +[SWEBOK, 2004, с.B-2]. После 6 лет непосредственных работ над документом, +SWEBOK включал “лишь” 10 *областей знаний* (*knowledge areas*, KA). При этом, +что справедливо и для PMBOK, добавление новых областей знаний в SWEBOK +достаточно прозрачно. Все, что для этого необходимо, зрелость (или, по крайней +мере, явный и быстрый процесс достижения зрелости) и общепринятость[^4] +соответствующей области знаний, если это не приведет к серьезному усложнению +SWEBOK. + +[^4]: Концепция “общепринятости” - generally accepted – определена в IEEE +Std 1490-1998, Adoption of PMI Standard — A Guide to the Project Management +Body of Knowledge + +Важно понимать, что программная инженерия является развивающейся дисциплиной. +Более того, данная дисциплина не касается вопросов конкретизации применения тех +или иных языков программирования, архитектурных решений или, тем более, +рекомендаций, касающихся более или менее распространенных или развивающихся с +той или иной степенью активности/заметности технологий (например, web-служб). +Руководство к своду знаний, каковым является SWEBOK, включает базовое +определение и описание областей знаний (например, конфигурационное управление – +configuration management) и, безусловно, является *недостаточным* для охвата +всех вопросов, относящихся к вопросам создания программного обеспечения, но, в +то же время *необходимым* для их понимания. + +Необходимо отметить, что одной из важнейших целей SWEBOK является именно +определение и систематизация тех аспектов деятельности, которые составляют суть +профессии инженера-программиста. + +## Структура и содержание SWEBOK + +Описание областей знаний в SWEBOK построено по иерархическому принципу, как +результат структурной декомпозиции. Такое иерархическое построение обычно +насчитывает два-три уровня детализации, принятых для идентификации тех или иных +общепризнанных аспектов программной инженерии. При этом, структура декомпозиции +областей знаний детализирована только до того уровня, который необходим для +понимания природы соответствующих тем и возможности нахождения источников +компетенции и других справочных данных и материалов. В принципе, считается, что +как таковой “свод знаний” по программной инженерии представлен не в обсуждаемом +руководстве (SWEBOK), а в первоисточниках (как указанных в нем, так и +представленных за его рамками) [SWEBOK, 2004, с.1-2]. + +SWEBOK описывает 10 областей знаний: + +- Software requirements – программные требования +- Software design – дизайн (архитектура) +- Software construction – конструирование программного обеспечения +- Software testing - тестирование +- Software maintenance – эксплуатация (поддержка) программного обеспечения +- Software configuration management – конфигурационное управление +- Software engineering management – управление в программной инженерии +- Software engineering process – процессы программной инженерии +- Software engineering tools and methods – инструменты и методы +- Software quality – качество программного обеспечения + +В дополнение к ним, SWEBOK также включает обзор смежных дисциплин, связь с +которыми представлена как фундаментальная, важная и обоснованная для +программной инженерии: + +- Computer engineering +- Computer science +- Management +- Mathematics +- Project management +- Quality management +- Systems engineering + +Стоит отметить, что принятые разграничения между областями знаний, их +компонентами (subareas) и другими элементами достаточно произвольны. При этом, +в отличие от PMBOK, области знаний SWEBOK не включают “входы” и “выходы”. В +определенной степени такая декомпозиция связаны с тем, что SWEBOK не +ассоциирован с той или иной моделью (например, жизненного цикла) или методом. +Хотя на первый взгляд первые пять областей знаний в SWEBOK представлены в +традиционной последовательной (каскадной - waterfall) модели, это не более чем +следование принятой последовательности освещения соответствующих тем. Остальные +области и структура декомпозиции областей представлены в алфавитном порядке. + +Для каждой области знаний SWEBOK описывает ключевые акронимы, представляет +область в виде “подобластей” (subareas) или как их часто называют в самом +SWEBOK – “секций” и дает декомпозицию каждой секции в форме списка тем (topics) +с их описанием. + +![Рисунок 1-а. Первые пять областей знаний SWEBOK на английском языке](images/swe_1-5_en.jpg) + +![Рисунок 1-б. Первые пять областей знаний SWEBOK на русском языке](images/swe_1-5_ru.jpg) + +![Рисунок 2-а. Вторые пять областей знаний SWEBOK на английском языке](images/swe_6-10_en.jpg) + +![Рисунок 2-б. Вторые пять областей знаний SWEBOK на русском языке](images/swe_6-10_ru.jpg) + +![Рисунок 3-а. Области знаний связанных дисциплин на английском языке](images/swe_other-ka_en.jpg) + +![Рисунок 3-б. Области знаний связанных дисциплин на русском языке](images/swe_other-ka_ru.jpg) + + +## Перевод SWEBOK на русский язык + +Учитывая, что существует ряд неоднозначностей и фактически отсутствует +консенсус по соответствующей терминологии на русском языке, далее в книге будут +использоваться как оригинальные термины на английском языке, так и те их +представления по-русски, которые кажутся представляются наиболее адекватными в +соответствующем контексте. + +К моменту начала работы над представленным переводом SWEBOK в 2004 году, каких-либо даже фрагментарных переводов SWEBOK на русский язык не существовало. В то же время, несмотря на спорность некоторых положений SWEBOK, значимость его для индустрии программного обеспечения как первой коллективной попытки систематизации накопленных знаний просто сложно переоценить. Представленный далее перевод SWEBOK - Руководство к своду знаний по программной инженерии необходимо рассматривать как авторский перевод с замечаниями и комментариями ключевых положений SWEBOK. Такой подход ни в коем случае не подменяет оригинального SWEBOK и является всего лишь авторским прочтением последнего. + +> Представленный перевод SWEBOK 2004 никак не заменяет первоисточника и создан +> [Сергеем Орликом](https://www.linkedin.com/in/sorlik) при участии [Юрия +> Булуя](http://www.linkedin.com/in/yurybuluy) без какой-либо поддержки IEEE или +> других структур по собственной инициативе в полном соответствии со SWEBOK +> Copyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc. +> All rights reserved. Copyright and Reprint 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 (1) alterations are clearly marked as alterations +> and (2) this copyright notice is included unmodified in any copy. Далее перевод +> соответствующих глав SWEBOK включает расширения (замечания и комментарии), +> помеченные цветом, отличным от цвета перевода оригинального содержания +> SWEBOK. blob - 4877e7925e1d965f0a387ff4ce2d161a5336f203 (mode 644) blob + /dev/null --- 10_software_quality.markdown +++ /dev/null @@ -1,1067 +0,0 @@ -# Качество программного обеспечения - -Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - -SWEBOK. - -Содержит перевод описания области знаний SWEBOK “Software Quality”, с -замечаниями и комментариями. - -Что такое качество и почему оно должно быть столь глубоко представлено (в виде -самостоятельной области знаний) в SWEBOK? На протяжении многих лет отдельные -авторы и целые организации определяли термин “качество” по-разному. Фил Кросби -(Phil Crosby) в 1979 году дал определение качеству как “соответствие -пользовательским требованиям”. Уотс Хемпфри (Watts Hamphrey, оригинальный автор -концепции модели оценки зрелости CMM, а также PSP и TSP – People Software -Process и Team Software Process) описывает качество как “достижение отличного -уровня пригодности к использованию”. Компания IBM, в свою очередь, ввела в -оборот фразу “качество, управляемое рыночными потребностями” (“market-driven -quality”). Критерий Бэлдриджа (Baldrige) для организационного качества (см. -NIST - National Institute of Standards and Technology, “Baldrige National -Quality Program”, http://www.quality.nist.gov) использует похожую фразу - -“качество, задаваемое потребителем” (“customer-driven quality”), рассматривая -удовлетворение потребителя в качестве главного соображения в отношении -качества. Чаще, понятие качества используется в соответствии с определением -системы менеджмента качества ISO 9001 как “степень соответствия присущих -характеристик требованиям” (именно так это сформулировано в официальном -переводе ИСО 9000-2000 "Системы менеджмента качества. Основные положения и -словарь"). - -Эти взгляды перекликаются и с предлагаемым в этом переводе термином “приемлемое -качество”, определяемым не только уровнем запросов конечных потребителей в -отношении параметров создаваемого продукта, но и заданным -контекстом/ограничениями проекта. Это не значит, что “приемлемое качество” -противопоставляется “качеству, диктуемому заказчиком”. Конечно, не стоит и -проводить параллель “приемлемого качества” с “продуктом второй свежести”. -Введение категории “приемлемости” в отношении качества является лишь -прагматичным взглядом на желаемую степень совершенства создаваемого продукта -(услуги), способную удовлетворить пользователей и достижимую в рамках заданных -проектных ограничений. Интересно, что и сама “степень приемлемости” также -выступает в роли ограничения проекта, а в приложении к индустрии программного -обеспечения представлена практически во всех областях проектной деятельности – -от управления требованиями (“атрибуты качества” как категория нефункциональных -требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF - -Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, -и т.п. ). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем -обслуживания в рамках заданного SLA – Service Level Agreement, давно уже -принятого на вооружение в телекоммуникационной индустрии. Таким образом, -приемлемое качество может рассматриваться как <количественно выраженный> -компромисс между заказчиком и исполнителем в отношении характеристик продукта, -создаваемого исполнителем в интересах <решения задач> заказчика с учетом других -ограничений проекта (в частности, стоимостью, что часто именуется как “cost of -quality” – “стоимость качества”). Можно сказать, что такой взгляд может в -какой-то степени рассматриваться как расширение определения ISO 9001 с учетом -достигнутого компромисса между заказчиком и исполнителем (поставщиком) в -отношении характеристик качества. - -Данная глава (область знаний) рассматривает вопросы качества программного -обеспечения, выходя за рамки <отдельных> процессов жизненного цикла. Качество -программного обеспечения является постоянным объектом заботы программной -инженерии и обсуждается во многих областях знаний (что вполне обосновано, если -учесть поистине катастрофический уровень проваленных проектов и -неудовлетворённость пользователей программных продуктов, ставшая притчей во -языцех для программной индустрии). В общем случае, SWEBOK описывает ряд путей -достижения качества программного обеспечения. В частности, эта область знаний -касается статических техник, не требующих выполнения оцениваемых программных -систем, в отличие от динамических техник, рассмотренных в области знаний SWEBOK -“Тестирование”. - -![Рисунок 1. Область знаний “Качество программного обеспечения” [SWEBOK, 2004, с.10-2, рис. 1]](images/quality_area_small.jpg) - -## Основы качества программного обеспечения (Software Quality Fundamentals) - -Согласие, достигнутое по требованиями к качеству (в оригинале - quality -requirements), наравне с четким доведением до инженеров того, что составляет -качество <получаемого продукта>, требуют обсуждения и формального определения -многих аспектов качества. - -Инженеры должны понимать смысл, вкладываемый в концепцию качества, -характеристики и значение качества в отношении разрабатываемого или -сопровождаемого программного обеспечения. - -Важной идеей является то, что программные требования определяют требуемые -характеристики качества программного обеспечения, а также влияют на методы -количественной оценки и сформулированные для оценки этих характеристик -<соответствующие> критерии приемки. - -### Культура и этика программной инженерии (Software Engineering Culture and Ethics) - -Ожидается, что инженеры по программному обеспечению воспринимают вопросы -качества программного обеспечения как часть своей <профессиональной> культуры. -SWEBOK дает ссылки на источники, описывающие здоровую культуру программной -инженерии. - -Этические аспекты могут играть значительную роль в обеспечении качества -программного обеспечения, культуре и отношении инженеров <к своей работе>. IEEE -Computer Society и ACM разработали кодекс этики (“моральный кодекс” – code of -ethics) и профессиональной практики, основанный на восьми принципах, помогающих -инженерам укрепить их отношение к качеству и независимость <в решении вопросов -обеспечения достойного качества создаваемых программных продуктов> в их -повседневной работе. - -### Значение и стоимость качества (Value and Costs of Quality) - -Понятие “качество”, на самом деле, не столь очевидно и просто, как это может -показаться на первый взгляд. Для любого инженерного продукта существует -множество <интерпретаций> качества, в зависимости от конкретной “системы -координат” (в оригинале – “перспективы”). Множество этих точек зрения -необходимо обсудить и определить на этапе выработки требований к программному -продукту. Характеристики качества могут требоваться в той или иной степени, -могут отсутствовать или могут задавать определенные требования, все это может -быть результатом определенного компромисса (что вполне перекликается с -пониманием “приемлемого качества”, как менее жесткой точки зрения на -обеспечение качества, как достижение совершенства). - -Стоимость качества (cost of quality) может быть дифференцирована на стоимость -предупреждения <дефектов> (prevention cost), стоимость оценки (appraisal cost), -стоимость внутренних (internal failure cost), а также внешних сбоев (external -failure cost). - -Движущей силой программных проектов является желание создать программное -обеспечение, обладающее определенной ценностью (значимое для решения -определенных задач или достижения целей). Ценность программного обеспечения -может выражаться в форме стоимости, а может и нет. Заказчик, обычно, имеет свое -представление о максимальных стоимостных вложениях, возврат которых ожидается в -случае достижения основных целей создания программного обеспечения. Заказчик -может, также, иметь определенные ожидания в отношении качества ПО. Иногда, -заказчики не задумываются о вопросах качества и связанной с ними стоимостью. -Является ли характеристики качества чисто декоративными (умозрительными) или, -все же, это неотъемлемая часть программного обеспечения? Ответ, вероятно, -находится где-то посередине, как почти всегда бывает в таких случаях, и -является предметом обсуждения степени вовлечения заказчика в процесс принятия -решений и полного понимания заказчиком стоимости и выгоды, связанной с -достижением того или иного уровня качества. В идеальном случае, большинство -такого рода решений должно приниматься процессе работы с требованиями (см. -область знаний SWEBOK “Программные требования”), однако эти вопросы могут (и -должны) подниматься на протяжении всего жизненного цикла программного -обеспечения. Не существует каких-то <“стандартных”> правил того, как именно -необходимо принимать такие решения. Однако, инженеры должны быть способны -представить различные альтернативы (в достижении различного уровня качества) и -их стоимость. Здесь SWEBOK приводит некоторые источники, в которых более -подробно обсуждаются вопросы значимости качества и соответствующих -характеристик стоимости. - -### Модели и характеристики качества (Models and Quality Characteristics) - -В различных источниках (таксономиях и моделях) терминология характеристик -качества программного обеспечения отличается. Каждая модель включает различное -число уровней иерархии и общее число <”распознанных”> характеристик качества. -Различные авторы создали разные модели качества со своим набором характеристик -и атрибутов (в частности, Барри Боэм, автор спиральной модели жизненного цикла -разработки программного обеспечения, которая рассматривается в отдельной -дополнительной главе). Эти модели могут быть полезны для обсуждения, -планирования, (адаптации) и оценки качества программных продуктов. ISO/IEC -определяет три связанных модели качества программного обеспечения (ISO 9126-01 -Software Engineering - Product Quality, Part 1: Quality Model) – внутреннее -качество, внешнее качество и качество в процессе эксплуатации, а также набор -соответствующих работ по оценке качества программного обеспечения (ISO14598-98 -Software Product Evaluation). - -#### Качество процессов программного обеспечения (Software engineering process quality) - -Управление качеством (software quality management) и качество процессов -программной инженерии (software engineering process quality) имеют -непосредственное отношение к качеству создаваемого программного продукта. - -Модели и критерии оценки возможностей организаций, занимающихся разработкой -программного обеспечения, прежде всего касаются рассмотрения организации -проектных работ и аспектов управления. Соответственно, они рассматриваются в -областях знаний SWEBOK “Управление программной инженерией” и “Процесс -программной инженерии”. - -Конечно, невозможно полностью отделить качество процесса от качества продукта. - -Качество процесса, обсуждаемое в области знаний “Процесс программной -инженерии”, влияют на характеристики качества продукта, которые, в свою -очередь, отражаются в восприятии качества продукта в процессе эксплуатации со -стороны заказчика. - -Существует два важнейших стандарта в области качества программного обеспечения. -TickIT - касается рассмотрения общей системы менеджмента качества ISO 9001-00 в -приложении к программным проектам (и, в частности, сочетания такого взгляда с -положениями стандарта жизненного цикла ISO 12207) и представленный, также, в -виде специальных рекомендаций ISO 90003-04 “Software and Systems Engineering - -Guidelines for the Application of ISO9001:2000 to Computer Software”. - -Другой важный стандарт – CMMI, обсуждаемый в области знаний “Процесс -программной инженерии”, предоставляет рекомендации по совершенствованию -процесса. (здесь нельзя не упомянуть и ISO 15504 “Information Technology - -Software Process Assessment”, известный как SPICE - Software Process -Improvement and Capability dEtermination, который также рассматривается в -упомянутой области знаний). Непосредственно с управлением качеством связаны -процессные области (области компетенции) CMMI: обеспечение качества процесса и -продукта (process and product quality assurance, категория процессов CMMI -“Support”), проверка (verification, категория “Engineering”) и аттестация -(validation, категория “Engineering”). При этом, CMMI классифицирует обзор -(review) и аудит (audit) в качестве методов верификации, но не как -самостоятельные процессы, в отличие, например, от стандарта 12207. - -Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для -обеспечения качества программного обеспечения – CMMI или ISO 9001, продолжаются -с самого создания этих стандартов. Сегодня можно сказать о том, что данные -стандарты все же рассматривают как взаимодополняющие и, что сертификация по ISO -9001 помогает в достижении старших уровней зрелости по CMMI. - -#### Качество программного продукта (Software product quality) - -Прежде всего, инженеры должны определить цели создания программного -обеспечения. В этом контексте, особо важно помнить, что требования заказчика - -первичны и содержат требования в отношении качества, а не только -функциональности (функциональные требования). Таким образом, инженеры -ответственны за извлечение требований к качеству, которые не всегда -представлены явно, а также обсуждение их важности и степени сложности их -достижения. Все процессы, ассоциированные с качеством (например, сборка, -проверка и повышение качества), должны проектироваться с учетом этих требований -и несут на себе тяжесть дополнительных расходов (как важную составную часть -стоимости программного обеспечения). - -Стандарт ISO 9126-01 (Software Engineering - Product Quality, Part 1: Quality -Model) определяет для двух из трех описанных в нем моделей, связанные -характеристики и "суб-характеристики" качества, а также метрики, полезные для -оценки качества программных продуктов. - -Понимание термина “продукт” расширено включением всех артефактов, создаваемых -на выходе всех процессов, используемых для создания конечного программного -продукта. Примерами продукта являются (но не ограничиваются этим): полная -спецификация системных требований (system requirements specification), -спецификация программных требований для программных компонент системы (software -requirements specification, SRS), модели, код, тестовая документация, отчеты, -создаваемые в результате работ по анализу качества. Хотя, чаще всего термин -качество используется в отношении конечного продукта и поведения системы в -процессе эксплуатации, хорошей инженерной практикой является требование к тому, -чтобы соответствие заданным характеристикам качества оценивалось и для -промежуточных результатов/продуктов жизненного цикла в рамках всех процессов -программной инженерии. - -### Повышение качества (Quality Improvement) - -Качество программного обеспечения может повышаться за счет итеративного -процесса постоянного улучшения. Это требует контроля, координации и обратной -связи в процессе управления многими одновременно выполняемыми процессами: (1) -процессами жизненного цикла, (2) процессом обнаружения, устранения и -предотвращения сбоев/дефектов и (3) процессов улучшения качества. - -К программной инженерии применимы теории и концепции, лежащие в основе -совершенствования качества. Например, предотвращение и ранняя диагностика -ошибок, постоянное совершенствование (continuous improvement) и внимание к -требованиям заказчика (customer focus), составляющие принцип “building in -quality”. Эти концепции основываются на работах экспертов по качеству, -пришедших к мнению, что качество продукта напрямую связано с качеством -используемых для его создания процессов. - -Такие подходы, как TQM (Total Quality Management – всеобщее управление -качеством) PDCA (Plan, Do, Check, Act – Планирование, Действие, Проверка, -Реакция/Корректировка), являются инструментами достижения задач, связанных с -качеством. Поддержка менеджмента помогает в выполнении процессов, оценке -продуктов и получению всех необходимых данных. Кроме этого, разрабатываемая -программа совершенствования (improvement program, обычно является целевой и -охватывает работу подразделения или организации, в целом) детально -идентифицирует все действия и проекты по улучшению <отдельных аспектов -деятельности> в рамках определенного периода времени, за который такие проекты -можно осуществить с успешным решением соответствующих задач. При этом, -поддержка менеджмента означает, что все проекты по улучшению обладают -достаточными ресурсами для достижением поставленных целей. Поддержка -менеджмента тесно связана с реализацией активного взаимодействия в коллективе, -и должна предупреждать возникновение потенциальных проблем (и пассивного или -даже активного противодействия реализации программы совершенствования или -отдельных ее проектов). Формирование рабочих групп, поддержка менеджеров -среднего звена и выделенные ресурсы на уровне проекта – эти вопросы обсуждаются -в области знаний “Процесс программной инженерии”. - -## Процессы управления качеством программного обеспечения (Software Quality Processes) - -Управление качеством программного обеспечения (SQM, Software Quality -Management) применяется ко всем аспектам процессов, продуктов и ресурсов. SQM -определяет процессы, владельцев процессов, а также требования к процессам, -измерения процессов и их результатов, плюс – каналы обратной связи. - -Процессы управления качеством содержат много действий. Некоторые из них -позволяют напрямую находить дефекты, в то время, как другие помогают определить -где именно может быть важно провести более детальные исследования, после чего, -опять-таки, проводятся работы по непосредственному обнаружению ошибок. Многие -действия также могут вестись с целью достижения и тех и других целей. -Планирование качества программного обеспечения включает: - -1. Определение требуемого продукта в терминах характеристик качества (см., -например, область знаний “Управление программной инженерией”). -1. Планирование процессов для получения требуемого продукта (см., например, -области знаний “Проектирование” и “Конструирование”). - -Эти процессы отличаются от процессов SQM, как таковых, которые, в свою очередь, -направлены на оценку планируемых характеристик качества, а не на реальную -реализацию этих планов. Процессы управления качеством должны адресоваться -вопросам, насколько хорошо продукт будет удовлетворять потребностям заказчика и -требованиям заинтересованных лиц, обладать ценностью для заказчика и -заинтересованных лиц и качеством, необходимым для соответствия сформулированным -требованиям к программному обеспечению. - -SQM может использоваться для оценки и конечных и промежуточных продуктов. - -Некоторые из специализированных процессов SQM определены в стандарте 12207: - -- Процесс обеспечения качества (quality assurance process) -- Процесс верификации (verification process) -- Процесс аттестации (validation process) -- Процесс совместного анализа (joint review process) -- Процесс аудита (audit process) - -Все эти процессы поддерживают стремление к достижению качества и, кроме того, -помогают в поиске возможных ошибок. Однако, они отличаются в том, на чем -концентрируют внимание. - -Процессы SQM помогают в обеспечении лучшего качества программного обеспечения в -данном проекте. Они предоставляют менеджерам основную информацию по каждому -продукту и, кроме того, включают параметры качества всего процесса программной -инженерии. Области знаний SWEBOK “Процесс программной инженерии” и “Управление -программной инженерией” обсуждают программы качества для организаций, -занимающихся разработкой программного обеспечения. SQM может предоставить -соответствующую обратную связь для этих областей. - -Процессы SQM состоят из задач и техник, предназначенных для оценки того, как -начинают реализовываться планы по созданию программного обеспечения и насколько -хорошо промежуточные и конечные продукты соответствуют заданным требованиям. -Результаты выполнения этих задач представляются в виде отчетов для менеджеров -перед тем, как будут предприняты соответствующие корректирующие действия. -Управление SQM-процессом ведется исходя из уверенности, что данные отчетов -точны. - -Как описано в данной области знаний, процессы SQM тесно связаны между собой. -Они могут перекрываться, а иногда даже и совмещаться. Они кажутся реактивными -по своей природе, в силу того, что они рассматривают процессы в контексте -полученной практики и уже произведенные продукты. Однако, они играют главную -роль на стадии планирования, являясь проактивными как процессы и процедуры, -необходимые для достижения характеристик и уровня качества, востребованных -заинтересованными лицами <проекта> программного обеспечения. - -Управление рисками также может играть значительную роль для выпуска -качественного программного обеспечения. Включение “регулярного” (как постоянно -действующего, а не периодического; в оригинале – disciplined) анализа рисков и -<соответствующих> техник управления <рисками> в процессы жизненного цикла -программного обеспечения может увеличить потенциал для производства -качественного продукта. Более подробную информацию по управлению рисками можно -найти в области знаний “Управление программной инженерией”. - -### Подтверждение качества программного обеспечения (Software Quality Assurance, SQA) - -Процессы SQA обеспечивают подтверждение того, что программные продукты и -процессы жизненного цикла проекта соответствуют заданным требованиям. Такое -подтверждение проводится на основе планирования (planning), постановки <работ> -(enacting) и исполнения (performing) набора действий, направленных на то, чтобы -качество стало неотъемлемой частью программного обеспечения (см. выше -определения качества). Такой взгляд подразумевает ясное и точное формулирование -проблемы, а также то, что определены и четко выражены (полны и однозначно -интерпретируемы) требования к соответствующему <программному> решению. SQA -добивается обеспечения качества в процессе разработки и сопровождения за счет -выполнения различных действий на всех этапах <жизненного цикла>, что позволяет -идентифицировать проблемы еще на ранних стадиях, которые практически неизбежны -в любой сложной деятельности. - -Такая идентификация возможна во многих случаях (если даже не в большинстве -ситуаций), когда проблема еще является риском и возможно ее предотвращение. Это -– задача управления рисками, которое вполне можно было бы вынести в качестве -самостоятельной области знаний SWEBOK, в силу уже достаточно большого -совокупного опыта не только индустрии ИТ или дисциплины управления проектами. -Так или иначе, можно сказать, что уже было подчеркнуто при обсуждении SQM, -управление рисками (Risk Management) является серьезным дополнительным -инструментом для обеспечения качества программного обеспечения. Однако, -ограничиваться упоминанием управления рисками только в контексте SQM было бы -неправильно, так как сегодняшнее понимание Risk Management включает в себя не -только вопросы предупреждения рисков, но и управление процессом разрешения -проблем. - -SQA, как это сформулировано SWEBOK, концентрируется на процессах. Роль SQA -состоит в том, чтобы обеспечить соответствующее планирование процессов, -дальнейшее исполнение процессов на основе заданного плана и проведение -необходимых измерений процессов с передачей результатов измерений -заинтересованным сторонам (организационными структурам и лицам). - -SQA-план определяет средства, которые будут использоваться для обеспечения -соответствия разрабатываемого продукта заданным пользовательским требованиям с -максимальным уровнем качества, возможным при заданных ограничениях проекта -(т.е., в предлагаемой в данном переводе терминологии – приемлемым уровнем -качества). Для того, чтобы этого добиться, в первую очередь необходимо, чтобы -цели качества были четко определены и понимаемы (а также, однозначно -интерпретируемы, что является обязательным условием любых целей и -соответствующих требований). Это, в обязательном порядке, должно быть отражено -в соответствующих планах управления <проектом>, разработки и сопровождения. -Подробности можно найти в стандарте IEEE 730-02 “IEEE Standard for Software -Quality Assurance Plans”. - -Конкретные работы и задачи по обеспечению качества структурируются с -детализацией требований по их стоимости и ассоциированным ресурсам, целям с -точки зрения управления и соответствующим расписанием в контексте целей, -заданных планами управления, разработки и сопровождения. SQA-план должен -согласовываться с планом конфигурационного управления (см. область знаний -“Software Configuration Management”). План SQA идентифицирует документы, -стандарты, практики и соглашения, применяемые при контроле проекта, а также то, -как эти аспекты будут проверяться и отслеживаться для обеспечения достаточности -и соответствия заданному плану. Также, SQA-план идентифицирует метрики, -статистические техники, процедуры формирования сообщений о проблемах и -проведения корректирующих действий, такие средства (в оригинале SWEBOK -используется термин resources), как инструменты, техники и методологии, вопросы -безопасности физических носителей (это, скорее, вопрос базовой инфраструктуры -проектов, а не SQA-плана), тренинги, а также формирование отчетности и -документации, относящиеся к вопросам SQA. Кроме того, SQA-план касается и -вопросов работ по обеспечению качества, относящихся к другим типам -деятельности, описанным в <различных> планах по созданию программного -обеспечения, к которым также относятся поставка, установка, обслуживание -(поддержка и сопровождение) заказных и/или тиражируемых/готовых программных -решений (commercial off-the-shelf, COTS), необходимых для данного проекта -программного обеспечения. Наконец, SQA-план может содержать необходимые для -обеспечения качества критерии приемки программного обеспечения и действия по -формированию отчетности и управлению <и контролю над> работами. - -### Проверка (верификация) и аттестация (Verification and Validation, V&V) - -С целью краткости <изложения> (что, не мешало их детализировать достаточным -образом, в виде соответствующих "подтем" в рамках формата SWEBOK, так как, -будучи тесно связанными и взаимодополняющими, проверка и аттестация все же -обладают и самостоятельным содержанием), проверка (верификация) и аттестация – -Validation and Verification (V&V*) – рассмотрены в SWEBOK в рамках единой темы. -В свою очередь, они являются самостоятельными темами, например, в стандарте -жизненного цикла программного обеспечения 12207. Стандарт IEEE 1059-93 “IEEE -Guide for Software Verification and Validation Plans” дает такое определение -V&V*: “Проверка и аттестация программного обеспечения – упорядоченный подход в -оценке программных продуктов, применяемый на протяжении всего жизненного цикла. -Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на -обеспечение качества как неотъемлемой характеристики программного обеспечения и -удовлетворение пользовательских требований” (здесь и далее, как и при -обсуждении SQA, пользовательские требования, скорее, не user requirements в -понимании управления требованиями, а потребности пользователей, ради -удовлетворения которых создается программное обеспечение). - -* здесь и далее в переводе намеренно используется обозначение V&V, как -общепринятое в индустрии программного обеспечения - -V&V напрямую адресуется вопросам качества программного обеспечения и использует -соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V -может применяться для промежуточных продуктов, однако, в том объеме, который -соответствует промежуточным “шагам” <соответствующих> процессов жизненного -цикла. - -V&V напрямую адресуется вопросам качества программного обеспечения и использует -соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V -может применяться для промежуточных продуктов, однако, в том объеме, который -соответствует промежуточным “шагам” <соответствующих> процессов жизненного -цикла. - -Процесс V&V определяет в какой степени продукт (результат) тех или иных работ -по разработке и сопровождению соответствует требованиям, сформулированным в -рамках этих работ, а конечный продукт удовлетворяет заданным целям и -пользовательским требованиям (корректнее было бы говорить не только и, может -быть, не столько о “требованиях”, то есть потребностях, сколько об ожиданиях). -Верификация – попытка обеспечить правильную разработку продукта (продукт -построен правильным образом; обычно, для промежуточных, иногда, для конечного -продукта), в том значении, что получаемый в рамках соответствующей деятельности -продукт соответствует спецификациям, заданным в процессе предыдущей -деятельности. Аттестация – попытка обеспечить создание правильного продукта -(построен правильный продукт; обычно, в контексте конечного продукта), с точки -зрения достижения поставленной цели. Оба процесса – верификация и аттестация – -начинаются на ранних стадиях разработки и сопровождения. Они обеспечивают -исследованию (экспертизу) ключевых возможностей продукта как в контексте -непосредственно предшествующих результатов (промежуточных продуктов), так и с -точки зрения удовлетворения соответствующих спецификаций. - -Целью планирования V&V является обеспечение процессов верификации и аттестации -необходимыми ресурсами, четкое назначение ролей и обязанностей. Получаемый план -V&V документирует и <детально> описывает различные ресурсы, роли и действия, а -также используемые техники и инструменты. Понимание различных целей каждого -действия в рамках V&V может помочь в точном планировании техник и ресурсов -(включая, финансовые), необходимых для достижения заданных целей. Стандарты -IEEE 1012-98 “Software Verification and Validation” и 1059-93 “IEEE Guide for -Software Verification and Validation Plans” (Appendix A) определяют типичное -содержание плана проверки и аттестации. - -План также касается аспектов управления, коммуникаций (взаимодействия), политик -и процедур в отношении действий по верификации и аттестации и их -взаимодействия. Кроме того, в нем могут быть отражены вопросы формирования -отчетности по дефектам и документирования требований (конечно, с точки зрения -выполнения задач по проверке и аттестации продуктов). - -### Оценка (обзор) и аудит (Review and Audits) - -В целях краткости изложения, оценка (review) и аудит объединены в SWEBOK в одну -тему (в данном случае, такое объединение выглядит более обоснованным, чем в -случае V&V, где частью процесса аттестации могут быть, например, -приемо-сдаточные испытания, наверняка отсутствующие при верификации; оценка же -и аудит, на практике, часто отличаются лишь степенью детализации, акцентам в -отношении исследуемых аспектов, лицом/органом, выполняющим соответствующие -работы, а также степенью формализации процесса). В стандарте жизненного цикла -12207 эти работы разделены на самостоятельные темы. Более детально они описаны -в стандарте IEEE 1028-97 “IEEE Standard for Software Reviews”, в котором -представлено пять типов оценок и аудитов (обратите внимание, что классификация -рассматривает аудит лишь как один из типов оценки): - -- Управленческие оценки (management reviews) -- Технические оценки (technical reviews) -- Инспекции (inspections) -- “Прогонки” (walk-throughs) -- Аудиты (audtis) - -#### Управленческие оценки (Management Reviews) - -“Назначение управленческих оценок состоит в отслеживании развития -<проекта/продукта>, определения статуса планов и расписаний, утверждения -требования и распределения ресурсов, или оценки эффективности управленческих -подходов, используемых для достижения поставленных целей.” - IEEE 1028-97 “IEEE -Standard for Software Reviews”. Управленческие оценки поддерживают принятие -решений о внесении изменений и выполнении корректирующих действий, необходимых -в процессе выполнения программного проекта. Управленческие оценки определяют -адекватность планов, расписаний и требований, в то же время, контролируя их -прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, -будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), -V&V-отчетов, а также различных типов планов – управления рисками, -проекта/проектного управления, конфигурационного управления, безопасности -<использования> программного обеспечения (safety), оценки рисков и т.п. -Информация, связанная с данными вопросами, также представлена в областях знаний -“Управление программной инженерией” и “Конфигурационное управление”. - -#### Технические оценки (Technical Reviews) - -“Назначением технических оценок является исследование программного продукта для -определения его пригодности для использования в надлежащих целях. Цель состоит -в идентификации расхождений с утвержденными спецификациями и стандартами.” - -IEEE 1028-97 “IEEE Standard for Software Reviews”. - -Для обеспечения технических оценок необходимо распределение следующих ролей: -лицо, принимающее решения (decision-maker); лидер оценки (review leader); -регистратор (recorder); а также технический персонал, поддерживающий -(непосредственно исполняющий) действия по оценке. Техническая оценка требует, в -обязательном порядке, наличия следующих входных данных: - -- Формулировки целей -- Конкретного программного продукта (подвергаемого оценке) -- Заданного плана проекта (плана управления проектом) -- Списка проблем (вопросов), ассоциированных с продуктом -- Процедуры технической оценки - -Команда <технической оценки> следует заданной процедуре оценки. -Квалифицированные (с технической точки зрения) лица представляют обзор продукта -(представляя команду разработки). Исследование <продукта> проводится в течение -одной и более встреч (между теми, кто представляет продукт и теми, кто провидит -оценку). Техническая оценка завершается после того, как выполнены все -предписанные действия по исследованию продукта. - -#### Инспекции (Inspections) - -“Назначение инспекций состоит в обнаружении и идентификации аномалий в -программном продукте.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. -Существует два серьезных отличия инспекций от оценок (управленческой и -технической): - -Лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам -команды инспектирования, не должны участвовать в инспекциях. - -Инспекция должна вестись под руководством непредвзятого (независимого от -проекта и его целей) лидера, обученного техникам инспектирования. - -Инспектирование программного обеспечения всегда вовлекает авторов -промежуточного или конечного продукта, в отличие от оценок, которые не требуют -этого в обязательном порядке. Инспекции (как временные организационные единицы -– группы, команды) включают лидера, регистратора, рецензента и нескольких (от 2 -до 5) инспекторов. Члены команды инспектирования могут специализироваться в -различных областями экспертизы (обладать различными областями компетенции), -например, предметной области, методах проектирования, языке и т.п. В заданный -момент (промежуток) времени инспекции проводятся в отношении отдельного -небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных -функциональных или других характеристиках; часто, отталкиваясь от отдельных -бизнес-правил, функциональных требований или атрибутов качества). Каждый член -команды должен исследовать программный продукт и другие входные данные до -проведения инспекционной встречи, применяя, возможно, те или иные аналитические -техники (описанные ниже в подтеме 3.3.3) к небольшим фрагментам продукта или к -продукту, в целом, рассматривая в последнем случае только один его аспект, -например, интерфейсы. Любая найденная аномалия должна документироваться, а -информация передаваться лидеру инспекции. В процессе инспекции лидер руководит -сессией <инспекции> и проверяет, что все <члены команды> подготовились к -инспектированию. Общим инструментом, используемым при инспектировании, является -проверочный лист (checklist), содержащий аномалии и вопросы, связанные с -аспектами <программного продукта>, вызывающими интерес. Результирующий лист -часто классифицирует аномалии (см. стандарт IEEE 1044-93 “IEEE Standard for the -Classification of Software Anomalies”) и оценивается командой с точки зрения -его завершенности и точности. Решение о завершении инспекции принимается в -соответствии с одним (любым) из трех критериев: - -- Принятие <продукта> с отсутствием либо малой необходимостью переработки -- Принятие <продукта> с проверкой переработанных фрагментов -- Необходимость повторной инспекции -- Инспекционные встречи занимают, обычно, несколько часов, в отличие от -технической оценки и аудита, предполагающих, в большинстве случаев, больший -объем работ и, соответственно, длящиеся дольше. - -#### Прогонки (Walk-throughs) - -“Назначение прогонки состоит в оценке программного продукта. Прогонка может -проводиться с целью ознакомления (обучения) аудитории с программным продуктом.” -- IEEE 1028-97 “IEEE Standard for Software Reviews”. Главные цели прогонки -состоят (по IEEE 1028) в: - -- Поиске аномалий -- Улучшении продукта -- Обсуждении альтернативных путей реализации -- Оценке соответствия стандартам и спецификациям - -Прогонка похожа на инспекцию, однако, обычно проводится менее формальным -образом. В основном, прогонка организуется инженерами для других членов команды -с целью получения отклика от них на свою работу, как одного из элементов -(техник) обеспечения качества. - -#### Аудиты (Audits) - -“Назначением аудита программного обеспечения является независимая оценка -программных продуктов и процессов на предмет их соответствия применимым -регулирующим документам, стандартам, руководящим указаниям, планам и -процедурам.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Аудит -является формально организованной деятельностью, участники которой выполняют -определенные роли, такие как главный аудитор (lead auditor), второй аудитор -(another auditor), регистратор (recorder) и инициатор (initiator). В аудите -принимает участие представитель оцениваемой организации/организационной -единицы. В результате аудита идентифицируются случаи несоответствия и -формируется отчет, необходимый команде <разработки> для принятия корректирующих -действий. - -При том, что существуют различные формальные названия (и классификации) оценок -и аудита (например, как мы видели в стандарте IEEE 1028-97), важно отметить, -что такого рода действия могут проводиться почти для любого продукта на любой -стадии процесса разработки или сопровождения. - -## Практические соображения (Practical Considerations) - -### Требования к качеству программного обеспечения (Software Quality Requirements) - -#### Факторы влияния (Influence factors) - -На планирование, управление и выбор SQM-действий и техник оказывают влияние -различные факторы, среди которых: - -- Область применения системы, в которой будет работать программное обеспечение -(критичное для безопасности <людей>), критичное для бизнеса и т.п.) -- Системные и программные требования -- Какие компоненты используются в системе – коммерческие (внешние) или -стандартные (внутренние) -- Какие стандарты программной инженерии применимы в заданном контексте -- Каковы методы и программные инструменты, применяемые для разработки и -сопровождения, а также для обеспечения качества и совершенствования (продукта и -процессов) -- Бюджет, персонал, организация проектной деятельности, планы и расписания для -всех процессов -- Кто целевые пользователи и каково назначение системы -- Уровень целостности системы - -Информация об этих факторах влияет на то, как именно будут организованы и -документированы процессы SQM, какие SQM-работы будут отобраны -(стандартизированы в рамках проекта, команды, организационной единицы, -организации), какие необходимы ресурсы и каковы ограничения, накладываемые в -отношении усилий, направляемых на обеспечение качества. - -#### Гарантоспособность (Dependability) - -(Гарантоспособость – гарантия <высокой> надежности, защищенности от сбоев) - -В случаях, когда сбой системы может привести к крайне тяжелым последствиям -(такие системы иногда называют в англоязычных источниках “high confidence” или -“high integrity system”, в русском языке к ним иногда применяют название -“системы повышенной надежности”, “высокой доступности” и т.п.), общая -(совокупная) гарантоспособность системы (как сочетания аппаратной части, -программного обеспечения и человека) является главным и приоритетным -требованием качества, по отношению к основной функциональности <системы>. -Гарантоспособность (dependability) программного обеспечения включает такие -характеристики, как защищенность от сбоев (fault-tolerance), безопасность -использования (safety – безопасность в контексте приемлемого риска для здоровья -людей, бизнеса, имущества и т.п. ), информационная безопасность или -защищенность (security – защита информации от несанкционированных операций, -включая доступ на чтение, а также гарантия доступности информации -авторизованным пользователям, в объеме заданных для них прав), а также удобство -и простота использования (usability). Надежность (reliability) также является -критерием, который может быть определен в терминах гарантоспособности (см. -стандарт ISO/IEC 9126-1:2001 “Software Engineering - Product Quality, Part 1: -Quality Model”). - -В обсуждении данного вопроса существенную роль играет обширная литература по -системам повышенной надежности. При этом, применяется терминология, пришедшая -из области традиционных механических и электрических систем (в т.ч. не -включающих программное обеспечение) и описывающая концепции опасности, рисков, -целостности систем и т.п. SWEBOK приводит ряд источников, где подробно -обсуждаются эти вопросы. - -#### Уровни целостности программного обеспечения (Integrity levels of software) - -Уровень целостности программного обеспечения определяется на основании -возможных последствий сбоя программного обеспечения и вероятности возникновения -такого сбоя. Когда важны различные аспекты безопасности (применения и -информационной безопасности), при разработке планов работ в области -идентификации возможных очагов аварий могут использоваться техники анализа -опасностей (в контексте безопасности использования, safety) и анализа угроз (в -информационной безопасности, security). История сбоев аналогичных систем может -также помочь в идентификации наиболее полезных техник, направленных на -обнаружение сбоев и <всесторонней> оценки качества программного обеспечения. -Уровни целостности (например, градации целостности) предлагаются, в частности, -стандартом IEEE 1012-98 “IEEE Standard for Software Reviews”. - -При более детальном рассмотрении целостности программного обеспечения в -контексте конкретных проектов, необходимо уделять специальное внимание (выделяя -соответствующие ресурсы и проводя необходимые работы) не только SQM-процессам -(особенно, формальным, включая аудит и аттестацию), но и аспектам управления -требованиями (в части критериев целостности), управления рисками (включая -планирование рисков как на этапе разработки, так и на этапе эксплуатации и -сопровождения системы), проектирования (которое, для повышения -гарантоспособности, в обязательном порядке предполагает глубокий анализ и -проверку планируемых к применению архитектурных и технологических решений, -часто, посредством создания пилотных проектов, демонстрационных стендов и т.п.) -и тестирования (для обеспечения всестороннего исследования поведенческих -характеристик системы, в том числе с эмуляцией рабочего окружения/конфигурации, -в которых система должна использоваться в процессе эксплуатации). - -### Характеристика дефектов (Defect Characterization) - -SQM-процессы обеспечивают нахождение дефектов. Описание характеристик дефектов -играет основную роль в понимании продукта, облегчает корректировку процесса или -продукта, а также информирует менеджеров проектов и заказчиков о статусе -(состоянии) процесса или продукта. Существуют множество таксономий -(классификации и методов структурирования) дефектов (сбоев). На сегодняшний -день нет четкого консенсуса по этому вопросу и SWEBOK приводит некоторые -источники, освещающие его более подробно, упоминая, в частности, стандарт IEEE -1044-93 “IEEE Standard for the Classification of Software Anomalies”. -Характеристика дефектов (аномалий) также используется в аудите и оценках, когда -лидер оценки часто представляет для обсуждения на соответствующих встречах -список аномалий, сформированный членами оценочной команды. - -На фоне эволюции (и появления новых) методов проектирования и языков, наравне с -новыми программными технологиями, появляются и новые классы дефектов. Это -требует огромных усилий по интерпретации (и корректировке) ранее определенных -классов дефектов (сбоев). При отслеживании дефектов инженер интересуется не -только их количеством, но и типом. Данный аспект (а именно, распределение -дефектов по типам) особенно важен для определения наиболее слабых элементов -системы, с точки зрения используемых технологий и архитектурных решений, что -приводит к необходимости их углубленного изучения, создания специализированных -пилотных проектов, дополнительной проверки концепции (proof of concept, POC – -часто применяемый подход при использовании новых технологий), привлечения -сторонних экспертов и т.п. SWEBOK отмечает, что сама по себе информация, без -классификации, часто бывает просто бесполезна для обнаружения причин сбоев, так -как для определения путей решения проблем необходима их группировка по -соответствующим типам. Вопрос состоит в определении такой таксономии дефектов, -которая будет значима для инженеров и организации, в целом. -SQM обеспечивает сбор информации на всех стадиях разработки и сопровождения -программного обеспечения. Обычно, когда мы говорим “дефект”, мы подразумеваем -“сбой”, в соответствии с определением, представленным ниже. Однако, различные -культуры и стандарты могут предполагать различное смысловое наполнение этих -терминов. Частичные определения понятий такого рода (из стандарта IEEE -610.12-90 “ IEEE Standard Glossary of Software Engineering Terminology ”) -выглядят следующим образом: - -- Ошибка (error): “Отличие … между корректным результатом и вычисленным -результатом < полученным с использованием программного обеспечения>” -- Недостаток (fault): “Некорректный шаг, процесс или определение данных в -компьютерной программе” -- Сбой (failure): “<Некорректный> результат, полученный в результате -недостатка” -- Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее -к некорректному результату” - -Данные понятия достаточно детально рассматриваются в области знаний SWEBOK -“Тестирование программного обеспечения”. - -При обсуждении данной темы, под дефектом (defect) понимается результат сбоя -программного обеспечения. Модели надежности строятся на основании данных о -сбоях, собранных в процессе тестирования программного обеспечения или его -использования. Такие модели могут быть использованы для предсказания будущих -сбоев и помогают в принятии решения о прекращении тестирования. - -По результатам SQM-работ, направленных на обнаружение дефектов, выполняются -действия по удалению дефектов из исследуемого продукта. Однако, этим дело не -ограничивается. Есть и другие возможные действия, позволяющие получить полную -отдачу от результатов выполнения соответствующих SQM-работ. Среди них – анализ -и подведение итогов (резюмирование) <по обнаруженным несоответствиям/дефектам>, -использование техник количественной оценки (получение метрик) для улучшения -продукта и процесса, отслеживание дефектов и удаления их из системы (с -управленческим и техническим контролем проведения необходимых корректирующих -действий). Улучшение процесса рассматривается более детально в области знаний -SWEBOK “Процесс программной инженерии”. В свою очередь источником информации -для улучшения процесса, в частности, является SQM-процесс. - -Данные о несоответствиях и дефектах, найденных в процессе реализации -соответствующих техник SQM, должны фиксироваться для предотвращения их потери. -Для некоторых техник (например, технической оценки, аудита, инспекций), -присутствие регистратора (recorder) – обязательно, именно для фиксирования -такой информации, наравне с вопросами (в том числе, требующими дополнительного -рассмотрения) и принятыми решениями. В тех случаях, когда используются -соответствующие средства автоматизации, они могут обеспечить и получение -необходимой выходной информации о дефектах (например, сводную статистику по -статусам дефектов, ответственным исполнителям и т.п.). Данные о дефектах могут -собираться и записываться в форме запросов на изменения (SCR, software change -request) и могут, впоследствии, заноситься в определенные типы баз данных -(например, в целях отслеживания кросс-проектной/исторической статистики для -дальнейшего анализа и совершенствования процессов), как вручную, так и в -автоматическом режиме из соответствующих средств анализа (ряд современных -средств проектирования и специализированных инструментов позволяют -анализировать код и модели с применением соответствующих метрик, значимых для -обеспечения качества продуктов и процессов). Отчеты о дефектах направляются -управленческому звену организации/организационной единицы или структуры (для -принятия соответствующих решений в отношении проекта, продукта, процесса, -персонала, бюджета и т.п.). - -### Техники управления качеством программного обеспечения (Software Quality Management Techniques) - -Техники SQM могут быть распределены по нескольким категориям: - -- статические -- техники, требующие интенсивного использования человеческих ресурсов -- аналитические -- динамические - -#### Статические техники (Static techniques) - -Статические техники предполагают <детальное> исследование (examination) -проектной документации, программного обеспечения и другой информации о -программном продукте без его исполнения. Эти техники могут включать другие, -рассматриваемые ниже, действия по “коллективной” оценке (см. 3.3.2) или -“индивидуальному” анализу (см. 3.3.3), вне зависимости от степени использования -средств автоматизации. - -#### Техники коллективной оценки (People-intensive techniques) - -Действительно, SWEBOK использует термин “people-intensive”, точный перевод -содержания которого, по мнению автора перевода, достаточно пространен: -“Техники, требующие интенсивного использования человеческих ресурсов”. По-сути, -их можно было бы назвать и техниками “очных оценок”, так как их идея -заключается именно в форме прямого - “очного” взаимодействия специалистов. -Однако, такое краткое название не подчеркивало бы фактора вовлеченности -множества специалистов, который имеет важное значение для принятия решения о -выборе и применении таких техник в полном объеме. Именно поэтому, данные -техники в переводе названы “техниками коллективной оценки”. Все же посмотрим, -как именно SWEBOK описывает данные техники. - -Форма такого рода техник, включая оценку и аудит, может варьироваться от -формальных собраний до неформальных встреч или обсуждения продукта даже без -обращения к его коду. Обычно, такого рода техники предполагают очного -взаимодействия минимум двух, а в большинстве случаев, и более специалистов. При -этом, такие встречи могут требовать предварительной подготовки (практически -всегда касающейся определения содержания встреч, то есть перечня выносимых на -обсуждение вопросов). К ресурсам, используемым в таких техниках, наравне с -исследуемыми артефактами (продуктом, документацией, моделями и т.п.) могут -относится различного рода листы проверки (checklists) и результаты -аналитических техник (рассматриваются ниже) и работ по тестированию. Данные -техники рассматриваются, например, в стандарте 12207 при обсуждении оценки -( review) и аудита (audit). SWEBOK приводит и другие полезные источники, -в которых можно найти дополнительную информацию по обсуждаемому вопросу. - -#### Аналитические техники (Analytical techniques) - -Инженеры, занимающиеся программным обеспечением, как правило, применяют -аналитические техники. - -Если в данном случае создатели SWEBOK предполагали смысловую нагрузку -“generally” в отношении применения аналитических техник именно подразумевая -“как правило”, а не “достаточно широко”, то, по мнению автора перевода, такого -рода суждение является крайне консервативным и ограниченным. Особенно это -заметно в контексте широкого (и достаточно успешного) применения Agile-методик -и подходов, в которых individuals and interactions (см.первое положение The -Agile Manifesto) предполагает <непосредственное> общение и постоянное -взаимодействие членов команды (включая представителей заказчика – см. третье -положение Agile Manifesto - customer collaboration). В частности, Agile-взгляд -на SQM, вероятно, требует расширения вариантов форм оценки дополнительными -категориями. - -Иногда, несколько инженеров используют одну и ту же технику, но в отношении -разных частей продукта. Некоторые техники базируются на специфике применяемых -инструментальных средств, другие – предполагают “ручную” работу. Многие могут -помогать находить дефекты напрямую, но чаще всего они используются для -поддержки других техник (например, статической). Ряд техник также включает -различного рода экспертизу (assessment) как составной элемент общего анализа -качества. Примеры таких техник - анализ сложности (complexity analysis), анализ -управляющей логики (или анализ контроля потоков управления - control flow -analysis) и алгоритмический анализ (algorithmic analysis). - -Каждый тип анализа обладает конкретным назначением и не все типы применимы к -любому проекту. Примером техники поддержки является анализ сложности, который -полезен для определения фрагментов дизайна системы, обладающих слишком высокой -сложностью для корректной реализации, тестирования или сопровождения. Результат -анализа сложности может также применяться для разработки тестовых сценариев -(test cases). Такие техники поиска дефектов, как анализ управляющей логики, -может также использоваться и в других случаях. Для программного обеспечения с -обширной алгоритмической логикой крайне важно применять алгоритмические -техники, особенно в тех случаях, когда некорректный алгоритм (не его -реализация, а именно логика) может привести к катастрофическим результатам -(например, программное обеспечение авионики, для которой вопросы безопасности -использования – safety играют решающую роль). Существует обширный спектр -аналитических техник, поэтому приведение их списка здесь выглядит -нецелесообразным. SWEBOK указывает ряд источников, касающийся детального -обсуждения выбора и самого списка аналитических техник. - -Другие, более формальные типы аналитических техник известны как формальные -методы. Они применяются для проверки требований и дизайна (надо признать, лишь -иногда, в реальной сегодняшней практике промышленной разработки программного -обеспечения; см. обсуждение формальных методов в области знаний SWEBOK -“Инструменты и методы программной инженерии”). Проверка корректности -применяется к критическим фрагментам программного обеспечения (что, вообще -говоря, мало связано с формальными методами – это естественный путь достижения -приемлемого качества при минимизации затрат). Чаще всего они используются для -верификации особо важных частей критически-важных систем, например, конкректных -требований <информационной> безопасности и надежности. - -#### Динамические техники (Dynamic techniques) - -В процессе разработки и сопровождения программного обеспечения приходится -обращаться к различным видам динамических техник. В основном, это техники -тестирования. Однако, в качестве динамических техник могут рассматриваться -техники симуляции, проверки моделей и “символического” исполнения (symbolic -execution, часто предполагает использование модулей-“пустышек” с точки зрения -выполняемой логики, с эмулируемым входом и выходом при рассмотрении общего -сценария поведения многомодульных систем; иногда под этим термином понимаются и -другие техники, в зависимости, от выбранного первоисточника). Просмотр (чтение) -кода обычно рассматривается как статическая техника, но опытный инженер может -исполнять код непосредственно “в процессе” его чтения (например, используя -диалоговые средства пошаговой отладки для ознакомления или оценки чужого кода). -Таким образом, данная техника вполне может обсуждаться и как динамическая. -Такие расхождения в классификации техник ясно показывают, что в зависимости от -роли человека в организации, он может принимать и применять одни и те же -техники по-разному. - -В зависимости от организации <ведения> проекта, определенные работы по -тестированию могут выполняться при разработке программных систем в SQA и V&V -процессах. В силу того, что план SQM адресуется вопросам тестирования, данная -тема включает некоторые комментарии по тестированию. В свою очередь, область -знаний SWEBOK “Тестирование” детально обсуждает и дает ссылки (за исключением -стандартов, представленных в переводе, полный список ссылок присутствует только -в оригинальном издании SWEBOK на английском языке, как и для других областей -знаний) по теории, техникам и вопросам автоматизации работ по тестированию. - -#### Тестирование (Testing) - -Процессы подтверждения <качества>, описанные в SQA и V&V <планах>, исследуют и -оценивают любой выходной продукт (включая промежуточный и конечный), связанный -со спецификацией требований к программному обеспечению, на предмет -трассируемости (traceability), согласованности (consistency), -полноты/завершенности (completeness), корректности (correctness) и -непосредственно выполнения <требований> (performance). Такое подтверждение -также охватывает любые выходные артефакты процессов разработки и сопровождения, -сбора, анализа и количественной оценки результатов. SQA-деятельность -обеспечивает гарантию того, что соответствующие (необходимые в заданном -контексте проекта) типы тестов спланированы, разработаны и реализованы, а V&V – -разработку планов тестов, стратегий, сценариев и процедур <тестирования>. - -Вопросы тестирования детально обсуждаются в области знаний “Тестирование”. Два -типа тестирования следуют задачам, задаваемым SQA и V&V, потому как на них -ложится ответственность за качество данных, используемых в проекте: - -- Оценка и тестирование инструментов, используемых в проекте (IEEE 1462-98, -ISO/IEC 14102 “Information Technology - Guideline for the Evaluation and -Selection of CASE Tools.”) -- Тестирование на соответствие (или оценка тестов на соответствие) компонент и -COTS-продуктов (COTS - commercial of-the-shelf, готовый к использованию -продукт) для использования в создаваемом продукте; на это существует -соответствующий стандарт (IEEE Std 1465-1998//ISO/IEC12119:1994, IEEE Standard -Adoption of International Standard IDO/IEC12119:1994(E), Information Technology -– Software Packages - Quality Requirements and Testing) - -Иногда, независимые V&V-организации могут требовать возможности мониторинга -процесса тестирования и, в определенных случаях, заверять (или, чаще, -документировать/фиксировать) реальное выполнение <тестов> на предмет их -проведения в соответствии с заданными процедурами. С другой стороны, может быть -сделано обращение к V&V может быть направлено на оценку и самого тестирования: -достаточности планов и процедур, соответствия и точности результатов. - -Другой тип тестирования, которое проводится под началом V&V-организации – -тестирование третьей стороной (third-party testing). Такая третья сторона сама -не является разработчиком продукта и ни в какой форме не связана с -разработчиком продукта. Более того, третья сторона является независимым -источником оценки, обычно аккредитованным на предмет обладания соответствующими -полномочиями (например, организацией-разработчиком того или иного стандарта, -соответствие которому оценивается независимым экспертом и чьи действия -подтверждены создателем стандарта). Назначение такого рода тестирования состоит -в проверке продукта на соответствие определенному набору требований (например, -по информационной безопасности). - -### Количественная оценка качества программного обеспечения (Software Quality Measurement) - -Модели качества программных продуктов часто включают метрики для определения -уровня каждой характеристики качества, присущей продукту. - -Если характеристики качества выбраны правильно, такие измерения могут -поддержать качество (уровень качества) многими способами. Метрики могут помочь -в управлении процессом принятия решений. Метрики могут способствовать поиску -проблемных аспектов и узких мест в процессах. Метрики являются инструментом -оценки качества своей работы самими инженерами – как в целях, определенных SQA, -так и с точки зрения более долгосрочного процесса совершенствования -<достигаемого> качества. - -С увеличением внутренней сложности, изощренности программного обеспечения, -вопросы качества выходят далеко за рамки констатации факта – работает или не -работает программное обеспечение. Вопрос ставится – насколько хорошо -достигаются количественно оцениваемые цели качества. - -Существует еще несколько тем, предметом обсуждения которых являются метрики, -напрямую поддерживающие SQM. Они включают содействие в принятии решения о -моменте прекращения тестирования. В этом контексте представляются полезными -модели надежности и сравнение с образцами (эталонами, принятыми в качестве -примеров определенного уровня качества – benchmarks). - -Стоимость процесса SQM является одним из <проблемных> вопросов, который всегда -всплывает в процессе принятия решения о том, как будет организован проект -(проектные работы). Часто, используются общие (generic) модели стоимости, -основанные на определении того, когда именно дефект обнаружен и как много -усилий необходимо затратить на его исправление по сравнению с ситуацией, если -бы дефект был найден на более ранних этапах жизненного цикла. Проектные данные -могут помочь в получении более четкой картины стоимости. SWEBOK приводит -источники, в которых эта тема обсуждается более подробно. Связанная информация -по этим вопросам может быть найдена в областях знаний “Процесс программной -инженерии” и “Управление программной инженерией”. - -Наконец, сама по себе SQM-отчетность обладает полезной информацией не только о -самих процессах (подразумевая их текущее состояние), но и о том, как можно -улучшить все процессы жизненного цикла. Обсуждение этой темы, в частности, -представлено в стандарте IEEE 1012-98 “Software Verification and Validation”. - -Хотя, как количественные оценки (в данном случае речь идет о результатах -оценок, а не о процессе измерений) характеристик качества могут полезны сами по -себе (например, число неудовлетворенных требований и пропорция таких -требований), могут <эффективно> применяться математические и графические -техники, облегчающие интерпретацию значений метрик. Такие техники вполне -естественно классифицируются, например, следующим образом: - -Основанные на статистических методах (например, анализ Pareto, нормальное -распределение и т.п.) - -- Статистические тесты -- Анализ тенденций -- Предсказание (например, модели надежности) - -Техники, основанные на статистических методах и статистические тесты часто -предоставляют “снимок” наиболее проблемных областей исследуемого программного -продукта (и, кстати, то же часто верно и в отношении процессов). Результирующие -графики и диаграммы визуально помогают лицам, принимающим решения, в -определении аспектов, на которых необходимо сфокусировать ресурсы <проекта>. -Результаты анализа тенденций могут демонстрировать, что нарушается расписание, -например, при тестировании; или что сбои определенных классов становятся все -более частыми до тех пор, пока не предпринимаются корректирующие действия в -процессе разработки. Техники предсказания помогают в планировании времени -тестов и в предсказании сбоев. Более детальное обсуждение вопросов, касающихся -количественных оценок, можно найти в областях знаний SWEBOK “Процесс -программной инженерии” и “Управление программной инженерией”. Более -специализированная информация по метрикам, используемым при тестировании, -представлена в области знаний “Тестирование программного обеспечения”. - -SWEBOK предоставляет ссылки на источники, в которых более подробно -рассматриваются аспекты анализа дефектов (defect analysis), количественной -оценки возникновения дефектов и последующего применения статистических методов -для формирования понимания типов наиболее часто встречающихся типов дефектов и -отвечая на вопрос соответствующей оценки плотности дефектов <различных типов>. -Они могут, также, помочь в понимании тенденций и оценке того, насколько хорошо -работают техники обнаружения дефектов и насколько успешно развиваются (как в -плане выполнения, так и в контексте совершенствования) процессы разработки и -сопровождения. Оценка покрытия тестами (test coverage) облегчает формирование -ожиданий в отношении оставшегося объема тестирования и предсказании возможного -количества дефектов, которые будут еще обнаружены <до окончания процесса -тестирования>. На основе этих методов количественной оценки могут быть -сформированы, так называемые профили дефектов (defect profiles) для конкретных -прикладных областей (application domains). В дальнейшем, для будущих -программных систем в данной организации, такие профили могут направлять -процессы SQM, увеличивая усилия, направленные на наиболее вероятные источники -проблем в создаваемых продуктах. Аналогично этому, результаты эталонных -сравнений (benchmarks) или типовое для данной прикладной области количество -дефектов могут служить в качестве вспомогательных средств для определения -момента, когда продукт готов для передачи в эксплуатацию (помните обсуждение -концепции “приемлемого качества”?). - -Обсуждение вопросов использования данных, полученных в результате -SQM-деятельности, в целях улучшения процессов разработки и сопровождения, -представлено в областях знаний SWEBOK “Управление программной инженерией” и -“Процесс программной инженерии”. blob - /dev/null blob + 4877e7925e1d965f0a387ff4ce2d161a5336f203 (mode 644) --- /dev/null +++ 10_software_quality.md @@ -0,0 +1,1067 @@ +# Качество программного обеспечения + +Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - +SWEBOK. + +Содержит перевод описания области знаний SWEBOK “Software Quality”, с +замечаниями и комментариями. + +Что такое качество и почему оно должно быть столь глубоко представлено (в виде +самостоятельной области знаний) в SWEBOK? На протяжении многих лет отдельные +авторы и целые организации определяли термин “качество” по-разному. Фил Кросби +(Phil Crosby) в 1979 году дал определение качеству как “соответствие +пользовательским требованиям”. Уотс Хемпфри (Watts Hamphrey, оригинальный автор +концепции модели оценки зрелости CMM, а также PSP и TSP – People Software +Process и Team Software Process) описывает качество как “достижение отличного +уровня пригодности к использованию”. Компания IBM, в свою очередь, ввела в +оборот фразу “качество, управляемое рыночными потребностями” (“market-driven +quality”). Критерий Бэлдриджа (Baldrige) для организационного качества (см. +NIST - National Institute of Standards and Technology, “Baldrige National +Quality Program”, http://www.quality.nist.gov) использует похожую фразу - +“качество, задаваемое потребителем” (“customer-driven quality”), рассматривая +удовлетворение потребителя в качестве главного соображения в отношении +качества. Чаще, понятие качества используется в соответствии с определением +системы менеджмента качества ISO 9001 как “степень соответствия присущих +характеристик требованиям” (именно так это сформулировано в официальном +переводе ИСО 9000-2000 "Системы менеджмента качества. Основные положения и +словарь"). + +Эти взгляды перекликаются и с предлагаемым в этом переводе термином “приемлемое +качество”, определяемым не только уровнем запросов конечных потребителей в +отношении параметров создаваемого продукта, но и заданным +контекстом/ограничениями проекта. Это не значит, что “приемлемое качество” +противопоставляется “качеству, диктуемому заказчиком”. Конечно, не стоит и +проводить параллель “приемлемого качества” с “продуктом второй свежести”. +Введение категории “приемлемости” в отношении качества является лишь +прагматичным взглядом на желаемую степень совершенства создаваемого продукта +(услуги), способную удовлетворить пользователей и достижимую в рамках заданных +проектных ограничений. Интересно, что и сама “степень приемлемости” также +выступает в роли ограничения проекта, а в приложении к индустрии программного +обеспечения представлена практически во всех областях проектной деятельности – +от управления требованиями (“атрибуты качества” как категория нефункциональных +требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF - +Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, +и т.п. ). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем +обслуживания в рамках заданного SLA – Service Level Agreement, давно уже +принятого на вооружение в телекоммуникационной индустрии. Таким образом, +приемлемое качество может рассматриваться как <количественно выраженный> +компромисс между заказчиком и исполнителем в отношении характеристик продукта, +создаваемого исполнителем в интересах <решения задач> заказчика с учетом других +ограничений проекта (в частности, стоимостью, что часто именуется как “cost of +quality” – “стоимость качества”). Можно сказать, что такой взгляд может в +какой-то степени рассматриваться как расширение определения ISO 9001 с учетом +достигнутого компромисса между заказчиком и исполнителем (поставщиком) в +отношении характеристик качества. + +Данная глава (область знаний) рассматривает вопросы качества программного +обеспечения, выходя за рамки <отдельных> процессов жизненного цикла. Качество +программного обеспечения является постоянным объектом заботы программной +инженерии и обсуждается во многих областях знаний (что вполне обосновано, если +учесть поистине катастрофический уровень проваленных проектов и +неудовлетворённость пользователей программных продуктов, ставшая притчей во +языцех для программной индустрии). В общем случае, SWEBOK описывает ряд путей +достижения качества программного обеспечения. В частности, эта область знаний +касается статических техник, не требующих выполнения оцениваемых программных +систем, в отличие от динамических техник, рассмотренных в области знаний SWEBOK +“Тестирование”. + +![Рисунок 1. Область знаний “Качество программного обеспечения” [SWEBOK, 2004, с.10-2, рис. 1]](images/quality_area_small.jpg) + +## Основы качества программного обеспечения (Software Quality Fundamentals) + +Согласие, достигнутое по требованиями к качеству (в оригинале - quality +requirements), наравне с четким доведением до инженеров того, что составляет +качество <получаемого продукта>, требуют обсуждения и формального определения +многих аспектов качества. + +Инженеры должны понимать смысл, вкладываемый в концепцию качества, +характеристики и значение качества в отношении разрабатываемого или +сопровождаемого программного обеспечения. + +Важной идеей является то, что программные требования определяют требуемые +характеристики качества программного обеспечения, а также влияют на методы +количественной оценки и сформулированные для оценки этих характеристик +<соответствующие> критерии приемки. + +### Культура и этика программной инженерии (Software Engineering Culture and Ethics) + +Ожидается, что инженеры по программному обеспечению воспринимают вопросы +качества программного обеспечения как часть своей <профессиональной> культуры. +SWEBOK дает ссылки на источники, описывающие здоровую культуру программной +инженерии. + +Этические аспекты могут играть значительную роль в обеспечении качества +программного обеспечения, культуре и отношении инженеров <к своей работе>. IEEE +Computer Society и ACM разработали кодекс этики (“моральный кодекс” – code of +ethics) и профессиональной практики, основанный на восьми принципах, помогающих +инженерам укрепить их отношение к качеству и независимость <в решении вопросов +обеспечения достойного качества создаваемых программных продуктов> в их +повседневной работе. + +### Значение и стоимость качества (Value and Costs of Quality) + +Понятие “качество”, на самом деле, не столь очевидно и просто, как это может +показаться на первый взгляд. Для любого инженерного продукта существует +множество <интерпретаций> качества, в зависимости от конкретной “системы +координат” (в оригинале – “перспективы”). Множество этих точек зрения +необходимо обсудить и определить на этапе выработки требований к программному +продукту. Характеристики качества могут требоваться в той или иной степени, +могут отсутствовать или могут задавать определенные требования, все это может +быть результатом определенного компромисса (что вполне перекликается с +пониманием “приемлемого качества”, как менее жесткой точки зрения на +обеспечение качества, как достижение совершенства). + +Стоимость качества (cost of quality) может быть дифференцирована на стоимость +предупреждения <дефектов> (prevention cost), стоимость оценки (appraisal cost), +стоимость внутренних (internal failure cost), а также внешних сбоев (external +failure cost). + +Движущей силой программных проектов является желание создать программное +обеспечение, обладающее определенной ценностью (значимое для решения +определенных задач или достижения целей). Ценность программного обеспечения +может выражаться в форме стоимости, а может и нет. Заказчик, обычно, имеет свое +представление о максимальных стоимостных вложениях, возврат которых ожидается в +случае достижения основных целей создания программного обеспечения. Заказчик +может, также, иметь определенные ожидания в отношении качества ПО. Иногда, +заказчики не задумываются о вопросах качества и связанной с ними стоимостью. +Является ли характеристики качества чисто декоративными (умозрительными) или, +все же, это неотъемлемая часть программного обеспечения? Ответ, вероятно, +находится где-то посередине, как почти всегда бывает в таких случаях, и +является предметом обсуждения степени вовлечения заказчика в процесс принятия +решений и полного понимания заказчиком стоимости и выгоды, связанной с +достижением того или иного уровня качества. В идеальном случае, большинство +такого рода решений должно приниматься процессе работы с требованиями (см. +область знаний SWEBOK “Программные требования”), однако эти вопросы могут (и +должны) подниматься на протяжении всего жизненного цикла программного +обеспечения. Не существует каких-то <“стандартных”> правил того, как именно +необходимо принимать такие решения. Однако, инженеры должны быть способны +представить различные альтернативы (в достижении различного уровня качества) и +их стоимость. Здесь SWEBOK приводит некоторые источники, в которых более +подробно обсуждаются вопросы значимости качества и соответствующих +характеристик стоимости. + +### Модели и характеристики качества (Models and Quality Characteristics) + +В различных источниках (таксономиях и моделях) терминология характеристик +качества программного обеспечения отличается. Каждая модель включает различное +число уровней иерархии и общее число <”распознанных”> характеристик качества. +Различные авторы создали разные модели качества со своим набором характеристик +и атрибутов (в частности, Барри Боэм, автор спиральной модели жизненного цикла +разработки программного обеспечения, которая рассматривается в отдельной +дополнительной главе). Эти модели могут быть полезны для обсуждения, +планирования, (адаптации) и оценки качества программных продуктов. ISO/IEC +определяет три связанных модели качества программного обеспечения (ISO 9126-01 +Software Engineering - Product Quality, Part 1: Quality Model) – внутреннее +качество, внешнее качество и качество в процессе эксплуатации, а также набор +соответствующих работ по оценке качества программного обеспечения (ISO14598-98 +Software Product Evaluation). + +#### Качество процессов программного обеспечения (Software engineering process quality) + +Управление качеством (software quality management) и качество процессов +программной инженерии (software engineering process quality) имеют +непосредственное отношение к качеству создаваемого программного продукта. + +Модели и критерии оценки возможностей организаций, занимающихся разработкой +программного обеспечения, прежде всего касаются рассмотрения организации +проектных работ и аспектов управления. Соответственно, они рассматриваются в +областях знаний SWEBOK “Управление программной инженерией” и “Процесс +программной инженерии”. + +Конечно, невозможно полностью отделить качество процесса от качества продукта. + +Качество процесса, обсуждаемое в области знаний “Процесс программной +инженерии”, влияют на характеристики качества продукта, которые, в свою +очередь, отражаются в восприятии качества продукта в процессе эксплуатации со +стороны заказчика. + +Существует два важнейших стандарта в области качества программного обеспечения. +TickIT - касается рассмотрения общей системы менеджмента качества ISO 9001-00 в +приложении к программным проектам (и, в частности, сочетания такого взгляда с +положениями стандарта жизненного цикла ISO 12207) и представленный, также, в +виде специальных рекомендаций ISO 90003-04 “Software and Systems Engineering - +Guidelines for the Application of ISO9001:2000 to Computer Software”. + +Другой важный стандарт – CMMI, обсуждаемый в области знаний “Процесс +программной инженерии”, предоставляет рекомендации по совершенствованию +процесса. (здесь нельзя не упомянуть и ISO 15504 “Information Technology - +Software Process Assessment”, известный как SPICE - Software Process +Improvement and Capability dEtermination, который также рассматривается в +упомянутой области знаний). Непосредственно с управлением качеством связаны +процессные области (области компетенции) CMMI: обеспечение качества процесса и +продукта (process and product quality assurance, категория процессов CMMI +“Support”), проверка (verification, категория “Engineering”) и аттестация +(validation, категория “Engineering”). При этом, CMMI классифицирует обзор +(review) и аудит (audit) в качестве методов верификации, но не как +самостоятельные процессы, в отличие, например, от стандарта 12207. + +Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для +обеспечения качества программного обеспечения – CMMI или ISO 9001, продолжаются +с самого создания этих стандартов. Сегодня можно сказать о том, что данные +стандарты все же рассматривают как взаимодополняющие и, что сертификация по ISO +9001 помогает в достижении старших уровней зрелости по CMMI. + +#### Качество программного продукта (Software product quality) + +Прежде всего, инженеры должны определить цели создания программного +обеспечения. В этом контексте, особо важно помнить, что требования заказчика - +первичны и содержат требования в отношении качества, а не только +функциональности (функциональные требования). Таким образом, инженеры +ответственны за извлечение требований к качеству, которые не всегда +представлены явно, а также обсуждение их важности и степени сложности их +достижения. Все процессы, ассоциированные с качеством (например, сборка, +проверка и повышение качества), должны проектироваться с учетом этих требований +и несут на себе тяжесть дополнительных расходов (как важную составную часть +стоимости программного обеспечения). + +Стандарт ISO 9126-01 (Software Engineering - Product Quality, Part 1: Quality +Model) определяет для двух из трех описанных в нем моделей, связанные +характеристики и "суб-характеристики" качества, а также метрики, полезные для +оценки качества программных продуктов. + +Понимание термина “продукт” расширено включением всех артефактов, создаваемых +на выходе всех процессов, используемых для создания конечного программного +продукта. Примерами продукта являются (но не ограничиваются этим): полная +спецификация системных требований (system requirements specification), +спецификация программных требований для программных компонент системы (software +requirements specification, SRS), модели, код, тестовая документация, отчеты, +создаваемые в результате работ по анализу качества. Хотя, чаще всего термин +качество используется в отношении конечного продукта и поведения системы в +процессе эксплуатации, хорошей инженерной практикой является требование к тому, +чтобы соответствие заданным характеристикам качества оценивалось и для +промежуточных результатов/продуктов жизненного цикла в рамках всех процессов +программной инженерии. + +### Повышение качества (Quality Improvement) + +Качество программного обеспечения может повышаться за счет итеративного +процесса постоянного улучшения. Это требует контроля, координации и обратной +связи в процессе управления многими одновременно выполняемыми процессами: (1) +процессами жизненного цикла, (2) процессом обнаружения, устранения и +предотвращения сбоев/дефектов и (3) процессов улучшения качества. + +К программной инженерии применимы теории и концепции, лежащие в основе +совершенствования качества. Например, предотвращение и ранняя диагностика +ошибок, постоянное совершенствование (continuous improvement) и внимание к +требованиям заказчика (customer focus), составляющие принцип “building in +quality”. Эти концепции основываются на работах экспертов по качеству, +пришедших к мнению, что качество продукта напрямую связано с качеством +используемых для его создания процессов. + +Такие подходы, как TQM (Total Quality Management – всеобщее управление +качеством) PDCA (Plan, Do, Check, Act – Планирование, Действие, Проверка, +Реакция/Корректировка), являются инструментами достижения задач, связанных с +качеством. Поддержка менеджмента помогает в выполнении процессов, оценке +продуктов и получению всех необходимых данных. Кроме этого, разрабатываемая +программа совершенствования (improvement program, обычно является целевой и +охватывает работу подразделения или организации, в целом) детально +идентифицирует все действия и проекты по улучшению <отдельных аспектов +деятельности> в рамках определенного периода времени, за который такие проекты +можно осуществить с успешным решением соответствующих задач. При этом, +поддержка менеджмента означает, что все проекты по улучшению обладают +достаточными ресурсами для достижением поставленных целей. Поддержка +менеджмента тесно связана с реализацией активного взаимодействия в коллективе, +и должна предупреждать возникновение потенциальных проблем (и пассивного или +даже активного противодействия реализации программы совершенствования или +отдельных ее проектов). Формирование рабочих групп, поддержка менеджеров +среднего звена и выделенные ресурсы на уровне проекта – эти вопросы обсуждаются +в области знаний “Процесс программной инженерии”. + +## Процессы управления качеством программного обеспечения (Software Quality Processes) + +Управление качеством программного обеспечения (SQM, Software Quality +Management) применяется ко всем аспектам процессов, продуктов и ресурсов. SQM +определяет процессы, владельцев процессов, а также требования к процессам, +измерения процессов и их результатов, плюс – каналы обратной связи. + +Процессы управления качеством содержат много действий. Некоторые из них +позволяют напрямую находить дефекты, в то время, как другие помогают определить +где именно может быть важно провести более детальные исследования, после чего, +опять-таки, проводятся работы по непосредственному обнаружению ошибок. Многие +действия также могут вестись с целью достижения и тех и других целей. +Планирование качества программного обеспечения включает: + +1. Определение требуемого продукта в терминах характеристик качества (см., +например, область знаний “Управление программной инженерией”). +1. Планирование процессов для получения требуемого продукта (см., например, +области знаний “Проектирование” и “Конструирование”). + +Эти процессы отличаются от процессов SQM, как таковых, которые, в свою очередь, +направлены на оценку планируемых характеристик качества, а не на реальную +реализацию этих планов. Процессы управления качеством должны адресоваться +вопросам, насколько хорошо продукт будет удовлетворять потребностям заказчика и +требованиям заинтересованных лиц, обладать ценностью для заказчика и +заинтересованных лиц и качеством, необходимым для соответствия сформулированным +требованиям к программному обеспечению. + +SQM может использоваться для оценки и конечных и промежуточных продуктов. + +Некоторые из специализированных процессов SQM определены в стандарте 12207: + +- Процесс обеспечения качества (quality assurance process) +- Процесс верификации (verification process) +- Процесс аттестации (validation process) +- Процесс совместного анализа (joint review process) +- Процесс аудита (audit process) + +Все эти процессы поддерживают стремление к достижению качества и, кроме того, +помогают в поиске возможных ошибок. Однако, они отличаются в том, на чем +концентрируют внимание. + +Процессы SQM помогают в обеспечении лучшего качества программного обеспечения в +данном проекте. Они предоставляют менеджерам основную информацию по каждому +продукту и, кроме того, включают параметры качества всего процесса программной +инженерии. Области знаний SWEBOK “Процесс программной инженерии” и “Управление +программной инженерией” обсуждают программы качества для организаций, +занимающихся разработкой программного обеспечения. SQM может предоставить +соответствующую обратную связь для этих областей. + +Процессы SQM состоят из задач и техник, предназначенных для оценки того, как +начинают реализовываться планы по созданию программного обеспечения и насколько +хорошо промежуточные и конечные продукты соответствуют заданным требованиям. +Результаты выполнения этих задач представляются в виде отчетов для менеджеров +перед тем, как будут предприняты соответствующие корректирующие действия. +Управление SQM-процессом ведется исходя из уверенности, что данные отчетов +точны. + +Как описано в данной области знаний, процессы SQM тесно связаны между собой. +Они могут перекрываться, а иногда даже и совмещаться. Они кажутся реактивными +по своей природе, в силу того, что они рассматривают процессы в контексте +полученной практики и уже произведенные продукты. Однако, они играют главную +роль на стадии планирования, являясь проактивными как процессы и процедуры, +необходимые для достижения характеристик и уровня качества, востребованных +заинтересованными лицами <проекта> программного обеспечения. + +Управление рисками также может играть значительную роль для выпуска +качественного программного обеспечения. Включение “регулярного” (как постоянно +действующего, а не периодического; в оригинале – disciplined) анализа рисков и +<соответствующих> техник управления <рисками> в процессы жизненного цикла +программного обеспечения может увеличить потенциал для производства +качественного продукта. Более подробную информацию по управлению рисками можно +найти в области знаний “Управление программной инженерией”. + +### Подтверждение качества программного обеспечения (Software Quality Assurance, SQA) + +Процессы SQA обеспечивают подтверждение того, что программные продукты и +процессы жизненного цикла проекта соответствуют заданным требованиям. Такое +подтверждение проводится на основе планирования (planning), постановки <работ> +(enacting) и исполнения (performing) набора действий, направленных на то, чтобы +качество стало неотъемлемой частью программного обеспечения (см. выше +определения качества). Такой взгляд подразумевает ясное и точное формулирование +проблемы, а также то, что определены и четко выражены (полны и однозначно +интерпретируемы) требования к соответствующему <программному> решению. SQA +добивается обеспечения качества в процессе разработки и сопровождения за счет +выполнения различных действий на всех этапах <жизненного цикла>, что позволяет +идентифицировать проблемы еще на ранних стадиях, которые практически неизбежны +в любой сложной деятельности. + +Такая идентификация возможна во многих случаях (если даже не в большинстве +ситуаций), когда проблема еще является риском и возможно ее предотвращение. Это +– задача управления рисками, которое вполне можно было бы вынести в качестве +самостоятельной области знаний SWEBOK, в силу уже достаточно большого +совокупного опыта не только индустрии ИТ или дисциплины управления проектами. +Так или иначе, можно сказать, что уже было подчеркнуто при обсуждении SQM, +управление рисками (Risk Management) является серьезным дополнительным +инструментом для обеспечения качества программного обеспечения. Однако, +ограничиваться упоминанием управления рисками только в контексте SQM было бы +неправильно, так как сегодняшнее понимание Risk Management включает в себя не +только вопросы предупреждения рисков, но и управление процессом разрешения +проблем. + +SQA, как это сформулировано SWEBOK, концентрируется на процессах. Роль SQA +состоит в том, чтобы обеспечить соответствующее планирование процессов, +дальнейшее исполнение процессов на основе заданного плана и проведение +необходимых измерений процессов с передачей результатов измерений +заинтересованным сторонам (организационными структурам и лицам). + +SQA-план определяет средства, которые будут использоваться для обеспечения +соответствия разрабатываемого продукта заданным пользовательским требованиям с +максимальным уровнем качества, возможным при заданных ограничениях проекта +(т.е., в предлагаемой в данном переводе терминологии – приемлемым уровнем +качества). Для того, чтобы этого добиться, в первую очередь необходимо, чтобы +цели качества были четко определены и понимаемы (а также, однозначно +интерпретируемы, что является обязательным условием любых целей и +соответствующих требований). Это, в обязательном порядке, должно быть отражено +в соответствующих планах управления <проектом>, разработки и сопровождения. +Подробности можно найти в стандарте IEEE 730-02 “IEEE Standard for Software +Quality Assurance Plans”. + +Конкретные работы и задачи по обеспечению качества структурируются с +детализацией требований по их стоимости и ассоциированным ресурсам, целям с +точки зрения управления и соответствующим расписанием в контексте целей, +заданных планами управления, разработки и сопровождения. SQA-план должен +согласовываться с планом конфигурационного управления (см. область знаний +“Software Configuration Management”). План SQA идентифицирует документы, +стандарты, практики и соглашения, применяемые при контроле проекта, а также то, +как эти аспекты будут проверяться и отслеживаться для обеспечения достаточности +и соответствия заданному плану. Также, SQA-план идентифицирует метрики, +статистические техники, процедуры формирования сообщений о проблемах и +проведения корректирующих действий, такие средства (в оригинале SWEBOK +используется термин resources), как инструменты, техники и методологии, вопросы +безопасности физических носителей (это, скорее, вопрос базовой инфраструктуры +проектов, а не SQA-плана), тренинги, а также формирование отчетности и +документации, относящиеся к вопросам SQA. Кроме того, SQA-план касается и +вопросов работ по обеспечению качества, относящихся к другим типам +деятельности, описанным в <различных> планах по созданию программного +обеспечения, к которым также относятся поставка, установка, обслуживание +(поддержка и сопровождение) заказных и/или тиражируемых/готовых программных +решений (commercial off-the-shelf, COTS), необходимых для данного проекта +программного обеспечения. Наконец, SQA-план может содержать необходимые для +обеспечения качества критерии приемки программного обеспечения и действия по +формированию отчетности и управлению <и контролю над> работами. + +### Проверка (верификация) и аттестация (Verification and Validation, V&V) + +С целью краткости <изложения> (что, не мешало их детализировать достаточным +образом, в виде соответствующих "подтем" в рамках формата SWEBOK, так как, +будучи тесно связанными и взаимодополняющими, проверка и аттестация все же +обладают и самостоятельным содержанием), проверка (верификация) и аттестация – +Validation and Verification (V&V*) – рассмотрены в SWEBOK в рамках единой темы. +В свою очередь, они являются самостоятельными темами, например, в стандарте +жизненного цикла программного обеспечения 12207. Стандарт IEEE 1059-93 “IEEE +Guide for Software Verification and Validation Plans” дает такое определение +V&V*: “Проверка и аттестация программного обеспечения – упорядоченный подход в +оценке программных продуктов, применяемый на протяжении всего жизненного цикла. +Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на +обеспечение качества как неотъемлемой характеристики программного обеспечения и +удовлетворение пользовательских требований” (здесь и далее, как и при +обсуждении SQA, пользовательские требования, скорее, не user requirements в +понимании управления требованиями, а потребности пользователей, ради +удовлетворения которых создается программное обеспечение). + +* здесь и далее в переводе намеренно используется обозначение V&V, как +общепринятое в индустрии программного обеспечения + +V&V напрямую адресуется вопросам качества программного обеспечения и использует +соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V +может применяться для промежуточных продуктов, однако, в том объеме, который +соответствует промежуточным “шагам” <соответствующих> процессов жизненного +цикла. + +V&V напрямую адресуется вопросам качества программного обеспечения и использует +соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V +может применяться для промежуточных продуктов, однако, в том объеме, который +соответствует промежуточным “шагам” <соответствующих> процессов жизненного +цикла. + +Процесс V&V определяет в какой степени продукт (результат) тех или иных работ +по разработке и сопровождению соответствует требованиям, сформулированным в +рамках этих работ, а конечный продукт удовлетворяет заданным целям и +пользовательским требованиям (корректнее было бы говорить не только и, может +быть, не столько о “требованиях”, то есть потребностях, сколько об ожиданиях). +Верификация – попытка обеспечить правильную разработку продукта (продукт +построен правильным образом; обычно, для промежуточных, иногда, для конечного +продукта), в том значении, что получаемый в рамках соответствующей деятельности +продукт соответствует спецификациям, заданным в процессе предыдущей +деятельности. Аттестация – попытка обеспечить создание правильного продукта +(построен правильный продукт; обычно, в контексте конечного продукта), с точки +зрения достижения поставленной цели. Оба процесса – верификация и аттестация – +начинаются на ранних стадиях разработки и сопровождения. Они обеспечивают +исследованию (экспертизу) ключевых возможностей продукта как в контексте +непосредственно предшествующих результатов (промежуточных продуктов), так и с +точки зрения удовлетворения соответствующих спецификаций. + +Целью планирования V&V является обеспечение процессов верификации и аттестации +необходимыми ресурсами, четкое назначение ролей и обязанностей. Получаемый план +V&V документирует и <детально> описывает различные ресурсы, роли и действия, а +также используемые техники и инструменты. Понимание различных целей каждого +действия в рамках V&V может помочь в точном планировании техник и ресурсов +(включая, финансовые), необходимых для достижения заданных целей. Стандарты +IEEE 1012-98 “Software Verification and Validation” и 1059-93 “IEEE Guide for +Software Verification and Validation Plans” (Appendix A) определяют типичное +содержание плана проверки и аттестации. + +План также касается аспектов управления, коммуникаций (взаимодействия), политик +и процедур в отношении действий по верификации и аттестации и их +взаимодействия. Кроме того, в нем могут быть отражены вопросы формирования +отчетности по дефектам и документирования требований (конечно, с точки зрения +выполнения задач по проверке и аттестации продуктов). + +### Оценка (обзор) и аудит (Review and Audits) + +В целях краткости изложения, оценка (review) и аудит объединены в SWEBOK в одну +тему (в данном случае, такое объединение выглядит более обоснованным, чем в +случае V&V, где частью процесса аттестации могут быть, например, +приемо-сдаточные испытания, наверняка отсутствующие при верификации; оценка же +и аудит, на практике, часто отличаются лишь степенью детализации, акцентам в +отношении исследуемых аспектов, лицом/органом, выполняющим соответствующие +работы, а также степенью формализации процесса). В стандарте жизненного цикла +12207 эти работы разделены на самостоятельные темы. Более детально они описаны +в стандарте IEEE 1028-97 “IEEE Standard for Software Reviews”, в котором +представлено пять типов оценок и аудитов (обратите внимание, что классификация +рассматривает аудит лишь как один из типов оценки): + +- Управленческие оценки (management reviews) +- Технические оценки (technical reviews) +- Инспекции (inspections) +- “Прогонки” (walk-throughs) +- Аудиты (audtis) + +#### Управленческие оценки (Management Reviews) + +“Назначение управленческих оценок состоит в отслеживании развития +<проекта/продукта>, определения статуса планов и расписаний, утверждения +требования и распределения ресурсов, или оценки эффективности управленческих +подходов, используемых для достижения поставленных целей.” - IEEE 1028-97 “IEEE +Standard for Software Reviews”. Управленческие оценки поддерживают принятие +решений о внесении изменений и выполнении корректирующих действий, необходимых +в процессе выполнения программного проекта. Управленческие оценки определяют +адекватность планов, расписаний и требований, в то же время, контролируя их +прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, +будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), +V&V-отчетов, а также различных типов планов – управления рисками, +проекта/проектного управления, конфигурационного управления, безопасности +<использования> программного обеспечения (safety), оценки рисков и т.п. +Информация, связанная с данными вопросами, также представлена в областях знаний +“Управление программной инженерией” и “Конфигурационное управление”. + +#### Технические оценки (Technical Reviews) + +“Назначением технических оценок является исследование программного продукта для +определения его пригодности для использования в надлежащих целях. Цель состоит +в идентификации расхождений с утвержденными спецификациями и стандартами.” - +IEEE 1028-97 “IEEE Standard for Software Reviews”. + +Для обеспечения технических оценок необходимо распределение следующих ролей: +лицо, принимающее решения (decision-maker); лидер оценки (review leader); +регистратор (recorder); а также технический персонал, поддерживающий +(непосредственно исполняющий) действия по оценке. Техническая оценка требует, в +обязательном порядке, наличия следующих входных данных: + +- Формулировки целей +- Конкретного программного продукта (подвергаемого оценке) +- Заданного плана проекта (плана управления проектом) +- Списка проблем (вопросов), ассоциированных с продуктом +- Процедуры технической оценки + +Команда <технической оценки> следует заданной процедуре оценки. +Квалифицированные (с технической точки зрения) лица представляют обзор продукта +(представляя команду разработки). Исследование <продукта> проводится в течение +одной и более встреч (между теми, кто представляет продукт и теми, кто провидит +оценку). Техническая оценка завершается после того, как выполнены все +предписанные действия по исследованию продукта. + +#### Инспекции (Inspections) + +“Назначение инспекций состоит в обнаружении и идентификации аномалий в +программном продукте.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. +Существует два серьезных отличия инспекций от оценок (управленческой и +технической): + +Лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам +команды инспектирования, не должны участвовать в инспекциях. + +Инспекция должна вестись под руководством непредвзятого (независимого от +проекта и его целей) лидера, обученного техникам инспектирования. + +Инспектирование программного обеспечения всегда вовлекает авторов +промежуточного или конечного продукта, в отличие от оценок, которые не требуют +этого в обязательном порядке. Инспекции (как временные организационные единицы +– группы, команды) включают лидера, регистратора, рецензента и нескольких (от 2 +до 5) инспекторов. Члены команды инспектирования могут специализироваться в +различных областями экспертизы (обладать различными областями компетенции), +например, предметной области, методах проектирования, языке и т.п. В заданный +момент (промежуток) времени инспекции проводятся в отношении отдельного +небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных +функциональных или других характеристиках; часто, отталкиваясь от отдельных +бизнес-правил, функциональных требований или атрибутов качества). Каждый член +команды должен исследовать программный продукт и другие входные данные до +проведения инспекционной встречи, применяя, возможно, те или иные аналитические +техники (описанные ниже в подтеме 3.3.3) к небольшим фрагментам продукта или к +продукту, в целом, рассматривая в последнем случае только один его аспект, +например, интерфейсы. Любая найденная аномалия должна документироваться, а +информация передаваться лидеру инспекции. В процессе инспекции лидер руководит +сессией <инспекции> и проверяет, что все <члены команды> подготовились к +инспектированию. Общим инструментом, используемым при инспектировании, является +проверочный лист (checklist), содержащий аномалии и вопросы, связанные с +аспектами <программного продукта>, вызывающими интерес. Результирующий лист +часто классифицирует аномалии (см. стандарт IEEE 1044-93 “IEEE Standard for the +Classification of Software Anomalies”) и оценивается командой с точки зрения +его завершенности и точности. Решение о завершении инспекции принимается в +соответствии с одним (любым) из трех критериев: + +- Принятие <продукта> с отсутствием либо малой необходимостью переработки +- Принятие <продукта> с проверкой переработанных фрагментов +- Необходимость повторной инспекции +- Инспекционные встречи занимают, обычно, несколько часов, в отличие от +технической оценки и аудита, предполагающих, в большинстве случаев, больший +объем работ и, соответственно, длящиеся дольше. + +#### Прогонки (Walk-throughs) + +“Назначение прогонки состоит в оценке программного продукта. Прогонка может +проводиться с целью ознакомления (обучения) аудитории с программным продуктом.” +- IEEE 1028-97 “IEEE Standard for Software Reviews”. Главные цели прогонки +состоят (по IEEE 1028) в: + +- Поиске аномалий +- Улучшении продукта +- Обсуждении альтернативных путей реализации +- Оценке соответствия стандартам и спецификациям + +Прогонка похожа на инспекцию, однако, обычно проводится менее формальным +образом. В основном, прогонка организуется инженерами для других членов команды +с целью получения отклика от них на свою работу, как одного из элементов +(техник) обеспечения качества. + +#### Аудиты (Audits) + +“Назначением аудита программного обеспечения является независимая оценка +программных продуктов и процессов на предмет их соответствия применимым +регулирующим документам, стандартам, руководящим указаниям, планам и +процедурам.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Аудит +является формально организованной деятельностью, участники которой выполняют +определенные роли, такие как главный аудитор (lead auditor), второй аудитор +(another auditor), регистратор (recorder) и инициатор (initiator). В аудите +принимает участие представитель оцениваемой организации/организационной +единицы. В результате аудита идентифицируются случаи несоответствия и +формируется отчет, необходимый команде <разработки> для принятия корректирующих +действий. + +При том, что существуют различные формальные названия (и классификации) оценок +и аудита (например, как мы видели в стандарте IEEE 1028-97), важно отметить, +что такого рода действия могут проводиться почти для любого продукта на любой +стадии процесса разработки или сопровождения. + +## Практические соображения (Practical Considerations) + +### Требования к качеству программного обеспечения (Software Quality Requirements) + +#### Факторы влияния (Influence factors) + +На планирование, управление и выбор SQM-действий и техник оказывают влияние +различные факторы, среди которых: + +- Область применения системы, в которой будет работать программное обеспечение +(критичное для безопасности <людей>), критичное для бизнеса и т.п.) +- Системные и программные требования +- Какие компоненты используются в системе – коммерческие (внешние) или +стандартные (внутренние) +- Какие стандарты программной инженерии применимы в заданном контексте +- Каковы методы и программные инструменты, применяемые для разработки и +сопровождения, а также для обеспечения качества и совершенствования (продукта и +процессов) +- Бюджет, персонал, организация проектной деятельности, планы и расписания для +всех процессов +- Кто целевые пользователи и каково назначение системы +- Уровень целостности системы + +Информация об этих факторах влияет на то, как именно будут организованы и +документированы процессы SQM, какие SQM-работы будут отобраны +(стандартизированы в рамках проекта, команды, организационной единицы, +организации), какие необходимы ресурсы и каковы ограничения, накладываемые в +отношении усилий, направляемых на обеспечение качества. + +#### Гарантоспособность (Dependability) + +(Гарантоспособость – гарантия <высокой> надежности, защищенности от сбоев) + +В случаях, когда сбой системы может привести к крайне тяжелым последствиям +(такие системы иногда называют в англоязычных источниках “high confidence” или +“high integrity system”, в русском языке к ним иногда применяют название +“системы повышенной надежности”, “высокой доступности” и т.п.), общая +(совокупная) гарантоспособность системы (как сочетания аппаратной части, +программного обеспечения и человека) является главным и приоритетным +требованием качества, по отношению к основной функциональности <системы>. +Гарантоспособность (dependability) программного обеспечения включает такие +характеристики, как защищенность от сбоев (fault-tolerance), безопасность +использования (safety – безопасность в контексте приемлемого риска для здоровья +людей, бизнеса, имущества и т.п. ), информационная безопасность или +защищенность (security – защита информации от несанкционированных операций, +включая доступ на чтение, а также гарантия доступности информации +авторизованным пользователям, в объеме заданных для них прав), а также удобство +и простота использования (usability). Надежность (reliability) также является +критерием, который может быть определен в терминах гарантоспособности (см. +стандарт ISO/IEC 9126-1:2001 “Software Engineering - Product Quality, Part 1: +Quality Model”). + +В обсуждении данного вопроса существенную роль играет обширная литература по +системам повышенной надежности. При этом, применяется терминология, пришедшая +из области традиционных механических и электрических систем (в т.ч. не +включающих программное обеспечение) и описывающая концепции опасности, рисков, +целостности систем и т.п. SWEBOK приводит ряд источников, где подробно +обсуждаются эти вопросы. + +#### Уровни целостности программного обеспечения (Integrity levels of software) + +Уровень целостности программного обеспечения определяется на основании +возможных последствий сбоя программного обеспечения и вероятности возникновения +такого сбоя. Когда важны различные аспекты безопасности (применения и +информационной безопасности), при разработке планов работ в области +идентификации возможных очагов аварий могут использоваться техники анализа +опасностей (в контексте безопасности использования, safety) и анализа угроз (в +информационной безопасности, security). История сбоев аналогичных систем может +также помочь в идентификации наиболее полезных техник, направленных на +обнаружение сбоев и <всесторонней> оценки качества программного обеспечения. +Уровни целостности (например, градации целостности) предлагаются, в частности, +стандартом IEEE 1012-98 “IEEE Standard for Software Reviews”. + +При более детальном рассмотрении целостности программного обеспечения в +контексте конкретных проектов, необходимо уделять специальное внимание (выделяя +соответствующие ресурсы и проводя необходимые работы) не только SQM-процессам +(особенно, формальным, включая аудит и аттестацию), но и аспектам управления +требованиями (в части критериев целостности), управления рисками (включая +планирование рисков как на этапе разработки, так и на этапе эксплуатации и +сопровождения системы), проектирования (которое, для повышения +гарантоспособности, в обязательном порядке предполагает глубокий анализ и +проверку планируемых к применению архитектурных и технологических решений, +часто, посредством создания пилотных проектов, демонстрационных стендов и т.п.) +и тестирования (для обеспечения всестороннего исследования поведенческих +характеристик системы, в том числе с эмуляцией рабочего окружения/конфигурации, +в которых система должна использоваться в процессе эксплуатации). + +### Характеристика дефектов (Defect Characterization) + +SQM-процессы обеспечивают нахождение дефектов. Описание характеристик дефектов +играет основную роль в понимании продукта, облегчает корректировку процесса или +продукта, а также информирует менеджеров проектов и заказчиков о статусе +(состоянии) процесса или продукта. Существуют множество таксономий +(классификации и методов структурирования) дефектов (сбоев). На сегодняшний +день нет четкого консенсуса по этому вопросу и SWEBOK приводит некоторые +источники, освещающие его более подробно, упоминая, в частности, стандарт IEEE +1044-93 “IEEE Standard for the Classification of Software Anomalies”. +Характеристика дефектов (аномалий) также используется в аудите и оценках, когда +лидер оценки часто представляет для обсуждения на соответствующих встречах +список аномалий, сформированный членами оценочной команды. + +На фоне эволюции (и появления новых) методов проектирования и языков, наравне с +новыми программными технологиями, появляются и новые классы дефектов. Это +требует огромных усилий по интерпретации (и корректировке) ранее определенных +классов дефектов (сбоев). При отслеживании дефектов инженер интересуется не +только их количеством, но и типом. Данный аспект (а именно, распределение +дефектов по типам) особенно важен для определения наиболее слабых элементов +системы, с точки зрения используемых технологий и архитектурных решений, что +приводит к необходимости их углубленного изучения, создания специализированных +пилотных проектов, дополнительной проверки концепции (proof of concept, POC – +часто применяемый подход при использовании новых технологий), привлечения +сторонних экспертов и т.п. SWEBOK отмечает, что сама по себе информация, без +классификации, часто бывает просто бесполезна для обнаружения причин сбоев, так +как для определения путей решения проблем необходима их группировка по +соответствующим типам. Вопрос состоит в определении такой таксономии дефектов, +которая будет значима для инженеров и организации, в целом. +SQM обеспечивает сбор информации на всех стадиях разработки и сопровождения +программного обеспечения. Обычно, когда мы говорим “дефект”, мы подразумеваем +“сбой”, в соответствии с определением, представленным ниже. Однако, различные +культуры и стандарты могут предполагать различное смысловое наполнение этих +терминов. Частичные определения понятий такого рода (из стандарта IEEE +610.12-90 “ IEEE Standard Glossary of Software Engineering Terminology ”) +выглядят следующим образом: + +- Ошибка (error): “Отличие … между корректным результатом и вычисленным +результатом < полученным с использованием программного обеспечения>” +- Недостаток (fault): “Некорректный шаг, процесс или определение данных в +компьютерной программе” +- Сбой (failure): “<Некорректный> результат, полученный в результате +недостатка” +- Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее +к некорректному результату” + +Данные понятия достаточно детально рассматриваются в области знаний SWEBOK +“Тестирование программного обеспечения”. + +При обсуждении данной темы, под дефектом (defect) понимается результат сбоя +программного обеспечения. Модели надежности строятся на основании данных о +сбоях, собранных в процессе тестирования программного обеспечения или его +использования. Такие модели могут быть использованы для предсказания будущих +сбоев и помогают в принятии решения о прекращении тестирования. + +По результатам SQM-работ, направленных на обнаружение дефектов, выполняются +действия по удалению дефектов из исследуемого продукта. Однако, этим дело не +ограничивается. Есть и другие возможные действия, позволяющие получить полную +отдачу от результатов выполнения соответствующих SQM-работ. Среди них – анализ +и подведение итогов (резюмирование) <по обнаруженным несоответствиям/дефектам>, +использование техник количественной оценки (получение метрик) для улучшения +продукта и процесса, отслеживание дефектов и удаления их из системы (с +управленческим и техническим контролем проведения необходимых корректирующих +действий). Улучшение процесса рассматривается более детально в области знаний +SWEBOK “Процесс программной инженерии”. В свою очередь источником информации +для улучшения процесса, в частности, является SQM-процесс. + +Данные о несоответствиях и дефектах, найденных в процессе реализации +соответствующих техник SQM, должны фиксироваться для предотвращения их потери. +Для некоторых техник (например, технической оценки, аудита, инспекций), +присутствие регистратора (recorder) – обязательно, именно для фиксирования +такой информации, наравне с вопросами (в том числе, требующими дополнительного +рассмотрения) и принятыми решениями. В тех случаях, когда используются +соответствующие средства автоматизации, они могут обеспечить и получение +необходимой выходной информации о дефектах (например, сводную статистику по +статусам дефектов, ответственным исполнителям и т.п.). Данные о дефектах могут +собираться и записываться в форме запросов на изменения (SCR, software change +request) и могут, впоследствии, заноситься в определенные типы баз данных +(например, в целях отслеживания кросс-проектной/исторической статистики для +дальнейшего анализа и совершенствования процессов), как вручную, так и в +автоматическом режиме из соответствующих средств анализа (ряд современных +средств проектирования и специализированных инструментов позволяют +анализировать код и модели с применением соответствующих метрик, значимых для +обеспечения качества продуктов и процессов). Отчеты о дефектах направляются +управленческому звену организации/организационной единицы или структуры (для +принятия соответствующих решений в отношении проекта, продукта, процесса, +персонала, бюджета и т.п.). + +### Техники управления качеством программного обеспечения (Software Quality Management Techniques) + +Техники SQM могут быть распределены по нескольким категориям: + +- статические +- техники, требующие интенсивного использования человеческих ресурсов +- аналитические +- динамические + +#### Статические техники (Static techniques) + +Статические техники предполагают <детальное> исследование (examination) +проектной документации, программного обеспечения и другой информации о +программном продукте без его исполнения. Эти техники могут включать другие, +рассматриваемые ниже, действия по “коллективной” оценке (см. 3.3.2) или +“индивидуальному” анализу (см. 3.3.3), вне зависимости от степени использования +средств автоматизации. + +#### Техники коллективной оценки (People-intensive techniques) + +Действительно, SWEBOK использует термин “people-intensive”, точный перевод +содержания которого, по мнению автора перевода, достаточно пространен: +“Техники, требующие интенсивного использования человеческих ресурсов”. По-сути, +их можно было бы назвать и техниками “очных оценок”, так как их идея +заключается именно в форме прямого - “очного” взаимодействия специалистов. +Однако, такое краткое название не подчеркивало бы фактора вовлеченности +множества специалистов, который имеет важное значение для принятия решения о +выборе и применении таких техник в полном объеме. Именно поэтому, данные +техники в переводе названы “техниками коллективной оценки”. Все же посмотрим, +как именно SWEBOK описывает данные техники. + +Форма такого рода техник, включая оценку и аудит, может варьироваться от +формальных собраний до неформальных встреч или обсуждения продукта даже без +обращения к его коду. Обычно, такого рода техники предполагают очного +взаимодействия минимум двух, а в большинстве случаев, и более специалистов. При +этом, такие встречи могут требовать предварительной подготовки (практически +всегда касающейся определения содержания встреч, то есть перечня выносимых на +обсуждение вопросов). К ресурсам, используемым в таких техниках, наравне с +исследуемыми артефактами (продуктом, документацией, моделями и т.п.) могут +относится различного рода листы проверки (checklists) и результаты +аналитических техник (рассматриваются ниже) и работ по тестированию. Данные +техники рассматриваются, например, в стандарте 12207 при обсуждении оценки +( review) и аудита (audit). SWEBOK приводит и другие полезные источники, +в которых можно найти дополнительную информацию по обсуждаемому вопросу. + +#### Аналитические техники (Analytical techniques) + +Инженеры, занимающиеся программным обеспечением, как правило, применяют +аналитические техники. + +Если в данном случае создатели SWEBOK предполагали смысловую нагрузку +“generally” в отношении применения аналитических техник именно подразумевая +“как правило”, а не “достаточно широко”, то, по мнению автора перевода, такого +рода суждение является крайне консервативным и ограниченным. Особенно это +заметно в контексте широкого (и достаточно успешного) применения Agile-методик +и подходов, в которых individuals and interactions (см.первое положение The +Agile Manifesto) предполагает <непосредственное> общение и постоянное +взаимодействие членов команды (включая представителей заказчика – см. третье +положение Agile Manifesto - customer collaboration). В частности, Agile-взгляд +на SQM, вероятно, требует расширения вариантов форм оценки дополнительными +категориями. + +Иногда, несколько инженеров используют одну и ту же технику, но в отношении +разных частей продукта. Некоторые техники базируются на специфике применяемых +инструментальных средств, другие – предполагают “ручную” работу. Многие могут +помогать находить дефекты напрямую, но чаще всего они используются для +поддержки других техник (например, статической). Ряд техник также включает +различного рода экспертизу (assessment) как составной элемент общего анализа +качества. Примеры таких техник - анализ сложности (complexity analysis), анализ +управляющей логики (или анализ контроля потоков управления - control flow +analysis) и алгоритмический анализ (algorithmic analysis). + +Каждый тип анализа обладает конкретным назначением и не все типы применимы к +любому проекту. Примером техники поддержки является анализ сложности, который +полезен для определения фрагментов дизайна системы, обладающих слишком высокой +сложностью для корректной реализации, тестирования или сопровождения. Результат +анализа сложности может также применяться для разработки тестовых сценариев +(test cases). Такие техники поиска дефектов, как анализ управляющей логики, +может также использоваться и в других случаях. Для программного обеспечения с +обширной алгоритмической логикой крайне важно применять алгоритмические +техники, особенно в тех случаях, когда некорректный алгоритм (не его +реализация, а именно логика) может привести к катастрофическим результатам +(например, программное обеспечение авионики, для которой вопросы безопасности +использования – safety играют решающую роль). Существует обширный спектр +аналитических техник, поэтому приведение их списка здесь выглядит +нецелесообразным. SWEBOK указывает ряд источников, касающийся детального +обсуждения выбора и самого списка аналитических техник. + +Другие, более формальные типы аналитических техник известны как формальные +методы. Они применяются для проверки требований и дизайна (надо признать, лишь +иногда, в реальной сегодняшней практике промышленной разработки программного +обеспечения; см. обсуждение формальных методов в области знаний SWEBOK +“Инструменты и методы программной инженерии”). Проверка корректности +применяется к критическим фрагментам программного обеспечения (что, вообще +говоря, мало связано с формальными методами – это естественный путь достижения +приемлемого качества при минимизации затрат). Чаще всего они используются для +верификации особо важных частей критически-важных систем, например, конкректных +требований <информационной> безопасности и надежности. + +#### Динамические техники (Dynamic techniques) + +В процессе разработки и сопровождения программного обеспечения приходится +обращаться к различным видам динамических техник. В основном, это техники +тестирования. Однако, в качестве динамических техник могут рассматриваться +техники симуляции, проверки моделей и “символического” исполнения (symbolic +execution, часто предполагает использование модулей-“пустышек” с точки зрения +выполняемой логики, с эмулируемым входом и выходом при рассмотрении общего +сценария поведения многомодульных систем; иногда под этим термином понимаются и +другие техники, в зависимости, от выбранного первоисточника). Просмотр (чтение) +кода обычно рассматривается как статическая техника, но опытный инженер может +исполнять код непосредственно “в процессе” его чтения (например, используя +диалоговые средства пошаговой отладки для ознакомления или оценки чужого кода). +Таким образом, данная техника вполне может обсуждаться и как динамическая. +Такие расхождения в классификации техник ясно показывают, что в зависимости от +роли человека в организации, он может принимать и применять одни и те же +техники по-разному. + +В зависимости от организации <ведения> проекта, определенные работы по +тестированию могут выполняться при разработке программных систем в SQA и V&V +процессах. В силу того, что план SQM адресуется вопросам тестирования, данная +тема включает некоторые комментарии по тестированию. В свою очередь, область +знаний SWEBOK “Тестирование” детально обсуждает и дает ссылки (за исключением +стандартов, представленных в переводе, полный список ссылок присутствует только +в оригинальном издании SWEBOK на английском языке, как и для других областей +знаний) по теории, техникам и вопросам автоматизации работ по тестированию. + +#### Тестирование (Testing) + +Процессы подтверждения <качества>, описанные в SQA и V&V <планах>, исследуют и +оценивают любой выходной продукт (включая промежуточный и конечный), связанный +со спецификацией требований к программному обеспечению, на предмет +трассируемости (traceability), согласованности (consistency), +полноты/завершенности (completeness), корректности (correctness) и +непосредственно выполнения <требований> (performance). Такое подтверждение +также охватывает любые выходные артефакты процессов разработки и сопровождения, +сбора, анализа и количественной оценки результатов. SQA-деятельность +обеспечивает гарантию того, что соответствующие (необходимые в заданном +контексте проекта) типы тестов спланированы, разработаны и реализованы, а V&V – +разработку планов тестов, стратегий, сценариев и процедур <тестирования>. + +Вопросы тестирования детально обсуждаются в области знаний “Тестирование”. Два +типа тестирования следуют задачам, задаваемым SQA и V&V, потому как на них +ложится ответственность за качество данных, используемых в проекте: + +- Оценка и тестирование инструментов, используемых в проекте (IEEE 1462-98, +ISO/IEC 14102 “Information Technology - Guideline for the Evaluation and +Selection of CASE Tools.”) +- Тестирование на соответствие (или оценка тестов на соответствие) компонент и +COTS-продуктов (COTS - commercial of-the-shelf, готовый к использованию +продукт) для использования в создаваемом продукте; на это существует +соответствующий стандарт (IEEE Std 1465-1998//ISO/IEC12119:1994, IEEE Standard +Adoption of International Standard IDO/IEC12119:1994(E), Information Technology +– Software Packages - Quality Requirements and Testing) + +Иногда, независимые V&V-организации могут требовать возможности мониторинга +процесса тестирования и, в определенных случаях, заверять (или, чаще, +документировать/фиксировать) реальное выполнение <тестов> на предмет их +проведения в соответствии с заданными процедурами. С другой стороны, может быть +сделано обращение к V&V может быть направлено на оценку и самого тестирования: +достаточности планов и процедур, соответствия и точности результатов. + +Другой тип тестирования, которое проводится под началом V&V-организации – +тестирование третьей стороной (third-party testing). Такая третья сторона сама +не является разработчиком продукта и ни в какой форме не связана с +разработчиком продукта. Более того, третья сторона является независимым +источником оценки, обычно аккредитованным на предмет обладания соответствующими +полномочиями (например, организацией-разработчиком того или иного стандарта, +соответствие которому оценивается независимым экспертом и чьи действия +подтверждены создателем стандарта). Назначение такого рода тестирования состоит +в проверке продукта на соответствие определенному набору требований (например, +по информационной безопасности). + +### Количественная оценка качества программного обеспечения (Software Quality Measurement) + +Модели качества программных продуктов часто включают метрики для определения +уровня каждой характеристики качества, присущей продукту. + +Если характеристики качества выбраны правильно, такие измерения могут +поддержать качество (уровень качества) многими способами. Метрики могут помочь +в управлении процессом принятия решений. Метрики могут способствовать поиску +проблемных аспектов и узких мест в процессах. Метрики являются инструментом +оценки качества своей работы самими инженерами – как в целях, определенных SQA, +так и с точки зрения более долгосрочного процесса совершенствования +<достигаемого> качества. + +С увеличением внутренней сложности, изощренности программного обеспечения, +вопросы качества выходят далеко за рамки констатации факта – работает или не +работает программное обеспечение. Вопрос ставится – насколько хорошо +достигаются количественно оцениваемые цели качества. + +Существует еще несколько тем, предметом обсуждения которых являются метрики, +напрямую поддерживающие SQM. Они включают содействие в принятии решения о +моменте прекращения тестирования. В этом контексте представляются полезными +модели надежности и сравнение с образцами (эталонами, принятыми в качестве +примеров определенного уровня качества – benchmarks). + +Стоимость процесса SQM является одним из <проблемных> вопросов, который всегда +всплывает в процессе принятия решения о том, как будет организован проект +(проектные работы). Часто, используются общие (generic) модели стоимости, +основанные на определении того, когда именно дефект обнаружен и как много +усилий необходимо затратить на его исправление по сравнению с ситуацией, если +бы дефект был найден на более ранних этапах жизненного цикла. Проектные данные +могут помочь в получении более четкой картины стоимости. SWEBOK приводит +источники, в которых эта тема обсуждается более подробно. Связанная информация +по этим вопросам может быть найдена в областях знаний “Процесс программной +инженерии” и “Управление программной инженерией”. + +Наконец, сама по себе SQM-отчетность обладает полезной информацией не только о +самих процессах (подразумевая их текущее состояние), но и о том, как можно +улучшить все процессы жизненного цикла. Обсуждение этой темы, в частности, +представлено в стандарте IEEE 1012-98 “Software Verification and Validation”. + +Хотя, как количественные оценки (в данном случае речь идет о результатах +оценок, а не о процессе измерений) характеристик качества могут полезны сами по +себе (например, число неудовлетворенных требований и пропорция таких +требований), могут <эффективно> применяться математические и графические +техники, облегчающие интерпретацию значений метрик. Такие техники вполне +естественно классифицируются, например, следующим образом: + +Основанные на статистических методах (например, анализ Pareto, нормальное +распределение и т.п.) + +- Статистические тесты +- Анализ тенденций +- Предсказание (например, модели надежности) + +Техники, основанные на статистических методах и статистические тесты часто +предоставляют “снимок” наиболее проблемных областей исследуемого программного +продукта (и, кстати, то же часто верно и в отношении процессов). Результирующие +графики и диаграммы визуально помогают лицам, принимающим решения, в +определении аспектов, на которых необходимо сфокусировать ресурсы <проекта>. +Результаты анализа тенденций могут демонстрировать, что нарушается расписание, +например, при тестировании; или что сбои определенных классов становятся все +более частыми до тех пор, пока не предпринимаются корректирующие действия в +процессе разработки. Техники предсказания помогают в планировании времени +тестов и в предсказании сбоев. Более детальное обсуждение вопросов, касающихся +количественных оценок, можно найти в областях знаний SWEBOK “Процесс +программной инженерии” и “Управление программной инженерией”. Более +специализированная информация по метрикам, используемым при тестировании, +представлена в области знаний “Тестирование программного обеспечения”. + +SWEBOK предоставляет ссылки на источники, в которых более подробно +рассматриваются аспекты анализа дефектов (defect analysis), количественной +оценки возникновения дефектов и последующего применения статистических методов +для формирования понимания типов наиболее часто встречающихся типов дефектов и +отвечая на вопрос соответствующей оценки плотности дефектов <различных типов>. +Они могут, также, помочь в понимании тенденций и оценке того, насколько хорошо +работают техники обнаружения дефектов и насколько успешно развиваются (как в +плане выполнения, так и в контексте совершенствования) процессы разработки и +сопровождения. Оценка покрытия тестами (test coverage) облегчает формирование +ожиданий в отношении оставшегося объема тестирования и предсказании возможного +количества дефектов, которые будут еще обнаружены <до окончания процесса +тестирования>. На основе этих методов количественной оценки могут быть +сформированы, так называемые профили дефектов (defect profiles) для конкретных +прикладных областей (application domains). В дальнейшем, для будущих +программных систем в данной организации, такие профили могут направлять +процессы SQM, увеличивая усилия, направленные на наиболее вероятные источники +проблем в создаваемых продуктах. Аналогично этому, результаты эталонных +сравнений (benchmarks) или типовое для данной прикладной области количество +дефектов могут служить в качестве вспомогательных средств для определения +момента, когда продукт готов для передачи в эксплуатацию (помните обсуждение +концепции “приемлемого качества”?). + +Обсуждение вопросов использования данных, полученных в результате +SQM-деятельности, в целях улучшения процессов разработки и сопровождения, +представлено в областях знаний SWEBOK “Управление программной инженерией” и +“Процесс программной инженерии”. blob - 6b9594b6daf791cb304862a36d2ccdc70171bf7a (mode 644) blob + /dev/null --- 1_software_requirements.markdown +++ /dev/null @@ -1,1178 +0,0 @@ -# Программные требования - -Глава базируется на IEEE Guide To The Software Engineering Body Of Knowledge - -SWEBOK. - -Содержит перевод описания области знаний swebok “software requirements”, с -замечаниями и комментариями. - -Программные требования – software requirements – свойства программного -обеспечени, которые должны быть надлежащим образом представлены в нём для -решения конкретных практических задач. Данная область знаний касается вопросов -извлечения (сбора), анализа, специфицирования и утверждения требований. - -Опыт индустрии информационных технологий однозначно показывает, что вопросы, -связанные с управлением требованиями, оказывают критически-важное влияние на -программные проекты, в определенной степени - на сам факт возможности успешного -завершения проектов. Только систематичная работа с требованиями позволяет -корректным образом обеспечить моделирование задач реального мира и -формулирование необходимых приемочных тестов для того, чтобы убедиться в -соответствии создаваемых программных систем критериям, заданным реальными -практическими потребностями. - -На практике часто применяется подход, используемый в различных методологиях -разработки по и базирующийся на определении групп требований к продукту. Такой -подход обычно включает группы (типы, категории) требований, например: -системные, программные, функциональные, нефункциональные (в частности, атрибуты -качества) и т.п. Классический пример (см. рисунок 1) высокоуровневого -структурирования групп требований как требований к продукту описан в работах -одного из классиков дисциплины управления требованиями – Карла Вигерса. - -![рисунок 1. Уровни требований по Вигерсу [Вигерс, 2003, с.8, рис. 1-1]](images/requirements_wiegers.jpg) - -SWEBOK охватывает не только вопросы структурирования и систематизации -требований, но и различных процессов этапов и процессов работы с требованиями, -а также некоторые практические соображения. - -![рисунок 2. Область знаний “Программные требования” [swebok, 2004, с.2-2, рис. 1]](images/requirements_area_small.jpg) - -Сама же структура обсуждаемой области знаний в большой степени совместима со -стандартами IEEE 12207.x, ISO/IEC, ГОСТ Р ИСО/МЭК 12207. Такая структура -построена исходя из идеи выделения ключевых групп вопросов дисциплины. - -Область знаний управления требованиями включает 7 секций, каждая из которых -представлена в виде ключевых тем (см. рисунок 2). Кроме того, данная область -знаний тесно связана со следующими областями: - -- Software Design -- Software Testing -- Software Maintenance -- Software Configuration Management -- Software Engineering Management -- Software Engineering Process -- Software Quality - -## Основы программных требований (Software Requirements Fundamentals) - -Эта секция включает определение программных требований как таковых и описывает -основные типы требований и их отличия: к продукту и процессу, функциональные и -нефункциональные требования и т.п. - -Темы данной секции: - -### Определение требований (Definition of a Software Requirement) - -В данном случае подразумевается не процесс определения (извлечения, сбора, формирования, -формулирования) требований, а дается само понятие “требования”, как такового, и -отмечаются его основные характеристики, например, верифицируемость -(проверяемость) требования. - -По мнению авторов, необходимо обратить внимание на следующие определения -понятия “требование” (на основе работ Вигерса и стандарта IEEE Standard -Glossary Of Software Engineering Terminology, 1990): - -- Условие или возможность, требуемая пользователем для решения задач или -достижения целей. -- Условие или возможность, которые должны удовлетворяться системой/компонентом -системы или которыми система/компонент системы должна обладать для обеспечения -условий контракта, стандартов, спецификаций или др. регулирующими документами. -- Документальная репрезентация (зафиксированное представление, определение, -описание) условий или возможностей, перечисленных в предыдущих пунктах. - -### Требования к продукту и процессу (Product and Process Requirements) - -Проводится разграничение соответствующих требований как свойств продукта, -который необходимо получить, и процесса, с помощью которого продукт будет -создаваться; отмечается, что ряд требований может быть заложен неявно и -программные требования могут порождать требования к процессу, например: работа -в режиме 24x7 (как бизнес-требование) наверняка приведет к ограничению выбора -тех или иных программных средств, платформ развертывания и архитектурных -решений; в свою очередь, выбор платформы j2ee (Java 2 Enterprise Edition) и ее -реализации в виде конкретного сервера приложений практически наверняка -потребует применения модульного тестирования (Unit Testing) как практики -процесса разработки и JUnit, как инструмента реализации этой практики. - -### Функциональные и нефункциональные требования (Functional and Non-Functional Requirements) - -Функциональные требования задают “что” система должна делать; -нефункциональные – с соблюдением “каких условий” (например, скорость отклика -при выполнении заданной операции); часто функциональные требования представляют -в виде сценариев (вариантов использования) use сase. - -Систематизируя работы Вигерса, Лефингвелла и Видрига, Коберна, а также других -экспертов, возможно и необходимо привести классификацию различных категорий -(видов) требований и связанных с ними понятий, важнейших с точки зрения их -понимания и дальнейшего практического применения: - -- Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, -которые должны быть соотнесены с использованием или приобретением системы. -- Группа функциональных требований - - Бизнес-требования (business requirements) – определяют высокоуровневые цели -организации или клиента (потребителя) – заказчика разрабатываемого программного -обеспечения. - - Пользовательские требования (user requirements) – описывают цели/задачи -пользователей системы, которые должны достигаться/выполняться пользователями -при помощи создаваемой программной системы. Эти требования часто представляют в -виде вариантов использования (use cases). - - Функциональные требования (functional requirements) – определяют -функциональность (поведение) программной системы, которая должна быть создана -разработчиками для предоставления возможности выполнения пользователями своих -обязанностей в рамках бизнес-требований и в контексте пользовательских -требований. - -- Группа нефункциоНальных Требований (non-functional requirements) - - Бизнес-правила (business rules) – включают или связаны с корпоративными -регламентами, политиками, стандартами, законодательными актами, -внутрикорпоративными инициативами (например, стремление достичь зрелости -процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и -т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого -рода требованиям со стороны сотрудников ит-департаментов и, в частности, -технических специалистов, вовлеченных в проект. Business Rules Group дает -понимание бизнес-правила, как “положения, которые определяют или ограничивают -некоторые аспекты бизнеса. они подразумевают организацию структуры бизнеса, -контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют -распределение ответственности в системе, отвечая на вопрос “кто будет -осуществлять конкретный вариант, сценарий использования” или диктуют появление -некоторых функциональных требований. - - В контексте дисциплины управления проектами (уже вне проекта разработки -программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) -такие правила обладают высокой значимостью и, именно они, часто определяют -ограничения бизнес-проектов, для автоматизации которых создается -соответствующее программное обеспечение. - - - Внешние интерфейсы (external interfaces) – часто подменяются -“пользовательским интерфейсом”. На самом деле вопросы организации -пользовательского интерфейса безусловно важны в данной категории требований, -однако, конкретизация аспектов взаимодействия с другими системами, операционной -средой (например, запись в журнал событий операционной системы), возможностями -мониторинга при эксплуатации – все это не столько функциональные требования (к -которым ошибочно приписывают иногда такие характеристики), сколько вопросы -интерфейсов, так как функциональные требования связаны непосредственно с -функциональностью системы, направленной на решение бизнес-потребностей. - - - Атрибуты качества (quality attributes) – описывают дополнительные -характеристики продукта в различных “измерениях”, важных для пользователей -и/или разработчиков. Атрибуты касаются вопросов портируемости, -интероперабельности (прозрачности взаимодействия с другими системами), -целостности, устойчивости и т.п. - - - Ограничения (constraints) – формулировки условий, модифицирующих требования -или наборы требований, сужая выбор возможных решений по их реализации. В -частности, к ним могут относиться параметры производительности, влияющие на -выбор платформы реализации и/или развертывания (протоколы, серверы приложений, -баз данных, ...), которые, в свою очередь, могут относиться, например, к -внешним интерфейсам. - -- Системные требования (system requirements) – иногда классифицируются как -составная часть группы функциональных требований (не путайте с как таковыми -“функциональными требованиями”). Описывают высокоуровневые требования к -программному обеспечению, содержащему несколько или много взаимосвязанных -подсистем и приложений. При этом, система может быть как целиком программной, -так и состоять из программной и аппаратной частей. В общем случае, частью -системы может быть персонал, выполняющий определенные функции системы, -например, авторизация выполнения определенных операций с использованием -программно-аппаратных подсистем. - -Необходимо сделать несколько важных замечаний по бизнес-правилам. Бизнес -правила, как таковые, являются предметом пристального изучения различных -специалистов в области как бизнес-моделирования, так и программной инженерии в -целом. Практика разработки программных требований включает идентификацию и -описание бизнес-правил как самостоятельных артефактов. Например, методология -RUP выделяет отдельный артефакт Business Rule в рамках дисциплины Business -Modeling. Все бизнес-правила, в рамках данной дисциплины, идентифицируются и -описываются в документе business rules document. При разработке требований, в -сценариях use cases обычно включается ссылка на уже описанное бизнес-правило. -Скотт Амблер (см. www.agilemodeling.com/artifacts/) так же выделяет -бизнес-правило как один из артефактов, который используют в семействе Agile -методологий. - -В настоящее время разработаны методы и подходы формального представления -бизнес-правил, вплоть до формальных языков описания (использование OCL – Object -Constraint Language, BRML – Business Rules Markup Language). - -Бизнес-правила могут быть не только использованы при определении требований к -разрабатываемому ПО, но и могут отдельно оформляться в дизайне ПО (класс или -группа классов), отражаясь в конечном итоге в программном коде на определенном -языке программирования. Существуют специализированные инструментальные средства -и библиотеки, позволяющие разрабатывать и поддерживать приложения, интенсивно -использующие бизнес-правила. - -Рассматривая бизнес-правила, как артефакты относящиеся к области программных -требований можно отметить, вернее дать одно из пояснений, почему бп относят к -нефункциональным требованиям: например, при написании определенного шага в -сценарии use case, используется ссылка на бизнес правило: «… система производит -расчет стоимости в соответствии с бизнес-правилом BP41 …». В свою очередь -данное бизнес-правило может определять алгоритм расчета стоимости. Т.е. налицо -«с соблюдением каких условий система делает расчет». - -Одним из наиболее известных специалистов по BR является Рональд Росс, автор -книги «Principles of the Business Rule Approach» (Ronald G. Ross. «Principles -of the Business Rule Approach», 2003). - -Наравне с представленной классификацией требований, могут использоваться и другие подходы. -Даже в рамках этой классификации, существуют и различные взгляды на ее -интерпретацию и детализацию. Например, как результат определения целевой -аудитории и в рамках маркетинговой стратегии продвижения тиражируемого решения, -возможно определять высокоуровневые возможности (ключевые характеристики, -особенности) – “фичи” (features) разрабатываемого продукта. Иногда, такие -возможности детализируются в смысле функциональных требований в некоторых -agile-техниках, например, FDD – Feature-Driven Development (как вы видите -вплоть до самого названия целого комплекса практик, метода разработки). - -Вигерс, описывает feature как “множество логически связанных функциональных -требований, которые предоставляют определенные возможности для пользователя и -удовлетворяют бизнес-целям <организации>”. С точки зрения маркетинга -программного обеспечения, как отмечает Вигерс, feature это «группа требований, -узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия -решения по приобретению ПО – это список <отличительных особенностей или -возможностей, характеристик>, присутствующий в описании продукта». В то же -время, Леффингвелл и Видриг (D.Leffingwell, D. Widrig, Managing Software -Requirements: A Use Case Approach, Second Edition, 2003) определяют feature как -“сервисы, которые оказывает система для удовлетворения одной или более -потребностей заинтересованных лиц (stakeholders needs)”. Ими же отмечается, что -в реальных проектах могут быть не определены stakeholders needs (а их часто -выделяют, особенно если у проекта/продукта есть много заинтересованных лиц со -своими потребностями, и эти потребности могут носить взаимоисключающий -характер), но существовать features могут и самостоятельно (как и stakeholder -needs), и конечно же возможно существование и stakeholder needs и features со -взаимной трассировкой. - -Развивая тему features -- Kurt Bittner & Ian Spence в своей книге “Use Case -Modeling” (Kurt Bittner, Ian Spence. Use Case Modeling, 2002), дают схожее, -хотя и более формальное определение features. Они отмечают, что features могут -быть как относящимся к функциональным, так и к нефункциональным требованиям. И -могут изменяться от версии к версии продукта. - -Анализируя различные источники на предмет работы с features, следует отметить -следующее: - -С точки зрения инженерии требований, features являются самостоятельным -артефактом, который может быть соотнесен как с функциональными требованиями, -так и с нефункциональными (в т.ч. с ограничениями проектирования или атрибутами -качества). - -Необходимо также отметить, что Features обладают определенным дуализмом в своей -интерпретации, зависимым от контекста конкретного продукта – с одной стороны -это может быть «тот самый список характеристик, указанный на коробке продукта» -в случае создания «коробочного ПО», с другой стороны это может список -высокоуровневых возможностей системы, например при заказной разработке ПО -автоматизации бизнес-процессов конкретной организации. - -Features могут быть разного уровня детализации – от выражения высокоуровневых -возможностей системы (например, «Расчет заработной платы …»), до достаточно -конкретных требований (например, «Автоматическое уведомление Клиента по e-mail -о резервировании товара на складе») - -### Независимые или общие свойства (Emergent Properties) - -Эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть -соотнесены с отдельнымы ее элементами. Т.е. данные требования относятся к тому -синергетическому эффекту, которым может обладать такая система («целое больше, -чем сумма его частей»). Примером может служить требования к «пропускной -способности» коллцентра, которая будут зависеть от того, каким образом будут -взаимодействовать коммуникационное оборудование, оператор и программное -обеспечение в конкретных условиях. - -### Требования с количественной оценкой (Quantifiable Requirements) - -Требования, поддающиеся количественному определению/измерению, например, -система должна обеспечить пропускную способность “столько-то запросов в -секунду”; в то же самое время, крайне важно понимать, что постановка вопроса -(то есть формулирование требования) в форме “система должна обеспечить рост -пропускной способности” без указания конкретных количественных характеристик -является просто некорректно определенным требованием. - -При этом, например, требование “система должна вести журнал подключений -пользователей” может и должно детализироваться с точки зрения описания -информации, которую необходимо сохранять в журнале, однако, такое требование -уже не будет являться количественным требованием. А требование с формулировкой -“система должна обладать интуитивно-понятным пользовательским интерфейсом” - -непроверяем. В определенных случаях, по мнению автора книги, это может -выглядеть просто издевкой, даже не являясь изначально таковой – все зависит от -точки зрения: например, в устах “целевого” пользователя специализированного -программного обеспечения – системного администратора, привыкшего работать в -kshell (популярной командной оболочке Unix/Linux), объясняющего свои -потребности аналитику, фиксирующему запросы пользователя и привыкшего -оперировать Microsoft Office ;) Может ли такое требование быть -переформулировано и/или детализировано для адекватности интерпретации? Да. -Например, так – средний показатель ошибок оператора не должен превышать 2% от -объема вводимой информации и 85% пользователей должны дать положительную оценку -прототипу пользовательского интерфейса на этапе опытной эксплуатации. - -Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с -численными величинами – как часто? насколько быстро? в каком количестве? и т.п. - -Большинство требований с количественной оценкой относится к атрибутам качества. - -В качестве примера можно привести реальное требование, присутствующее в -реальном проекте по электронному документообороту: “Система должна производить -поиск документов <определенного вида> за время, не превышающее 5 секунд”. Это -типичное требование с количественной оценкой, в котором определена верхняя -граница диапазона времени, за которое должен быть осуществлен поиск документов. -Несомненно, этот атрибут качества системы существует в контексте определенного -функционального требования о возможности поиска документов по определенным -критериям. И этот контекст или связь должна быть определена либо явно, в рамках -иерархии требований, либо посредством трассировки, между требованиями разных -видов (функционального и атрибута качества). Примечательно, что Вигерс в своей -книге выделяет требования по производительности системы в отдельный вид -требований, тем не менее входящих в понятие нефункциональных требований или -атрибутов качества. - -### Системные требования и программные требования (System Requirements and Software Requirements) - -Данное разделение базируется на определении “системы”, -данном INCOSE (International Council on Systems Engineering) “комбинация -взаимодействующих элементов <созданная> для достижения определенных целей; -может включать аппаратные средства, программное обеспечение, встроенное ПО, -другие средства, людей, информацию, техники (подходы), службы и другие -поддерживающие элементы”; таким образом, подразумевается, что система является -более ёмким понятием, чем программное обеспечения и включает окружение, в -котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают -требования к системе в целом и программному обеспечению (или программной -системе), в частности. Часто в литературе по управлению требованиями -встречается описание системных требований как “пользовательских требований” -(user requirements), SWEBOK ограничивает применение понятия “пользовательское -требование” требованиями к системе конечных пользователей/заказчиков. Системные -требования по SWEBOK, в свою очередь, окружают пользовательские требования (или -требования других заинтересованных лиц – stakeholders, например, регулирование -полномочий) без указания идентифицируемого источника-человека. - -## Процесс работы с требованиями (Requirements Process) - -Данная секция вводит процессы, касающиеся вопросов работы с требованиями, и в -определенной степени “сшивает” в единое целое оставшиеся пять секций области -знаний, посвященной требованиям к программному обеспечению. - -Цель данной темы, в соответствии с SWEBOK, дать понимание того, что такое -процесс работы с требованиями, как таковой. В русском языке также устойчиво -используется его название как “процесс определения требований”. Мы его будем -использовать взаимозаменяемым образом, подразумевая весь процесс работы с -требованиями по SWEBOK. - -Что ж, рассмотрим структуру декомпозиции тем процесса работы с требованиями: - -### Модель процесса определения требований: - -- Не является дискретным; это постоянно действующий процесс на всех этапах -жизненного цикла программного обеспечения. Процесс работы с требованиями -инициируется в начале проекта и продолжается на протяжении всего жизненного -цикла, в плоть до завершения проекта. Например, функциональные тесты создаются -в соответствии с функциональными требованиями к программной системе и обычно -выполняются, в том числе, при проведении приемочных испытаний. Как вы уже -заметили, в переводе использовалась все же “работа с требованиями” для -акцентирования внимания на том факте, что требования не только “определяются” -на начальных этапах работ, но и модифицируются и используются во всем жизненном -цикле. -- Идентифицирует программные требования как элементы конфигурации (в терминах -конфигурационного обеспечения) и контролирует их с использованием тех же -практик конфигурационного управления, что и для других активов программных -проектов (например, файлов или запросов на изменения). -- Требует адаптации к проектному и/или организационному контексту, в рамках -которого ведется соответствующий программный проект. - -В частности, тема процесса определения требований касается тех вопросов, -которые охватываются в рамках сбора, анализа, специфицирования и утверждения -требований с точки зрения организации этих видов деятельности для различных -типов проектов и значимости тех или иных ограничений по отношению к процессу. В -большинстве случаев, процесс определения, работы с требованиями выделен в -самостоятельный набор и описан как последовательность (сценарии) действий, -связанных с ними ролей и непосредственных результатов (их часто называют -“артефактами”, например, в RUP – Rational Unified Process), в рамках конкретных -методологий разработки программного обеспечения, наиболее популярные из которых -мы рассмотрим позднее. - -### Участники процессов (Process Actors) - -В этой теме вводится понятие “роли” и дается понимание “ролей” для людей, -которые участвуют в процессе работы с требованиями (чувствуете отличие между -“определением” требований и “работой” с ними?). Таких людей также называют -“заинтересованными лицами” (в данном контексте - software stakeholders). -Заинтересованное лицо – некто, имеющий возможность (в том числе, материальную) -повлиять на реализацию проекта/продукта. - -Типичные примеры ролей: - -- Пользователи (Users): группа, охватывающая тех людей, кто будет -непосредственно использовать программное обеспечение; пользователи могут -описать задачи, которые они решают (планируют решать) с использованием -программной системы, а также ожидания по отношению к атрибутам качества, -отображаемые в пользовательских требованиях. -- Заказчики (Customers): те, кто отвечают за заказ программного обеспечения -или, в общем случае, являются целевой аудиторией на рынке программного -обеспечения (образуют целевой рынок ПО); - -Стандарт 12207 (его обзор будет приведен в другой главе) определяет более -суженное понятие “заказчика” (обратите внимание – acquirer, а не customer, хотя -часто оба термина переводятся на русский язык одинаково) как организацию, -которая приобретает или получает систему, программный продукт или программную -услугу от поставщика. Здесь возможно использовать такое общее определение: -заказчик – лицо или организация, получающие прямую или косвенную выгоду от -использования продукта. Клиентами считают тех заинтересованных лиц, кто -требует, оплачивает, выбирает, использует или получает результаты работы -программного обеспечения. В этом плане, “заказчик” в понимании стандарта 12207 -скорее ближе к “клиенту” в такой интерпретации. - -- Аналитики (Market analysts): продукты массового рынка программного -обеспечения (как и других массовых рынков, например, бытовой техники) не -обладают “заказчиками” в понимании персонификации тех, кто “заказывает -разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в -идентификации потребностей и обращению к тем, кто может играть роль -<квалифицированных> “представителей” потребителей; - -- Регуляторы (Regulators): многие области применения (“домены”) являются -регулируемыми, например, телекоммуникации или банковский сектор. Программное -обеспечение для ряда целевых рынков (в первую очередь, корпоративного сектора) -требует соответствия руководящим документам и прохождения процедур, -определяемых уполномоченными органами. - -- Инженеры по программному обеспечению, иженеры-программисты (Software -Enginner): лица, обладающие обоснованным интересом к разработке программного -обеспечения, например, повторному использованию тех или иных компонент, -библиотек, средств и инструментов. Именно инженеры ответственны за техническую -оценку путей решения поставленных задач и последующую реализацию требований -заказчиков. - -SWEBOK особо подчеркивает, что если невозможно в точности (в оригинале – -“perfectly”) удовлетворить требования каждого заинтересованного лица, именно -работа инженера включает проведение переговоров и поиск компромисса, -приемлемого для ключевых заинтересованных лиц (“стейкхолдеров”) и -удовлетворяющего бюджетным, техническим, временным и другим ограничениям -проекта. Необходимо понимать, что такая деятельность практически наверняка -приведет к изменениям в требованиях, как минимум, на уровне соответствующих -приоритетов требований и, следовательно, работ по их реализации. - -### Управление и поддержка процессов (Process Support and Management) - -Эта тема затрагивает вопросы распределения ресурсов, необходимых для -осуществления проектной деятельности, устанавливая контекст для первой секции -“Инициация и определение содержания” (Initiation and Scope Definition) области -знаний “Управление в программной инженерии” (Software Engineering Management). -Основная цель данной темы – обеспечение связи между процессами и деятельностью, -определенными в 2.1 “модели процесса определения требований” и вопросами -использования проектных ресурсов – стоимостью, человеческими ресурсами, -инструментами и т.п. - -### Качество и улучшение процессов (Process Quality and Improvement) - -Эта тема связана с оценкой качества процессов работы с программными -требованиями и улучшением этих процессов. Особое значение данной темы -заключается в подчеркивании значимости работы с требованиями, ключевой роли -этих процессов для определения стоимостных и временных ресурсов, необходимых -для реализации программного проекта, в целом. - -Удовлетворение потребностей заказчика является целью любого программного -проекта. Соответственно, обеспечение адекватности реализации требований в -проекте просто невозможно представить без адекватных процессов работы с ними – -начиная со сбора требований, заканчивая проверкой соответствия получаемого -программного продукта этим требованиям на всех этапах его создания. - -Улучшение процессов и в частности процессов разработки и управления -требованиями должно предваряться формулировкой проблемы. Т.е. нет смысла -заниматься улучшением ради улучшения, нужно четко понимать какая в настоящее -время есть проблема в работе с требованиями, и насколько эта проблема значима, -и только потом приступать к ее устранению, в частности через улучшение -процессов. Реальная отечественная практика многих организаций, занимающихся -разработкой ПО, показывает, что очень немногие имеют действительно четкое -представление о том, каким образом организация работы с требованиям может -повлиять на успех компании в целом. Обычно, отечественные компании, в лучшем -случае просто документируют требования, выпуская документы, например, -Техническое задание по ГОСТ. Но действительно ли в этом документе можно увидеть -требования – увы. Следуя только рекомендациям, которые есть в ГОСТ можно только -соответствующим образом оформить разделы, что практически никак не влияет на -качество и информативность документа. Вопросы совершенствования процессов – -process improvement будут рассматриваться как в главах, посвященных CMMI, так и -в других частях этой книги. - -Данная тема тесно связана с областями знаний “Качество программного -обеспечения” (Software Quality) и “Процесс программной инженерии” (Software -Engineering Process). В этом контексте, фокусы обсуждаемой темы – определение -атрибутов и метрик качества, а также определение соответствующих процессов в -применении к программным требованиям, которые можно свести в три группы -практик: - -- Покрытие процессов работы с требованиями с точки зрения стандартов и моделей -улучшения процессов, в целом; -- Измерение и количественная оценка (benchmarking) процессов работы с -требованиями; -- Планирование и реализация процесса улучшения, как такового. - -## Извлечение требований (Requirements Elicitation) - -Данная секция освещает вопросы сбора требований как с точки зрения организации -процесса, так и определения источников, откуда поступают требования. Это первая -стадия построения видения автоматизируемой проблемной области. Идентификация -заинтересованных лиц, их взаимодействия, выполняемых ими бизнес-процессов – все -это является ключевыми вопросами, без четкого и однозначного ответа на которые -даже не стоит думать об успешности проекта (кстати, не только программного...). - -Один из ключевых принципов программной инженерии заключается в обеспечении -взаимодействия между пользователями и инженерами. Прежде, чем начинается -разработка программного обеспечения, именно специалисты “по требованиям” – -аналитики перекидывают тот самый “мостик” между заказчиками и исполнителями, -который задает тот уровень коммуникаций и взаимопонимания между ними, который -необходим для решения задач проекта. - -### Источники требований (Requirement Sources) - -Необходимо идентифицировать все возможные источники требований, значимые для -решения задач проекта. Только после этого можно определить их влияние на -проект. Данная тема касается вопросов понимания информированности источников -требований и их значимости. - -Тема фокусируется на: - -- Целях -- Знании предметной области -- Заинтересованных лицах -- Операционном окружении -- Организационной среде - -Выделение приоритетов, однозначность требований, передаваемых инженерам, связь -между требованиями и их взаимное влияние друг на друга – все это является -следствием четкого и однозначного понимания источников требований. - -### Техники извлечения требований (Elicitation Techniques) - -Идентифицировав источники требований мы не должны “покоится на лаврах”. Даже -обладая пониманием того, кто владеет необходимой информацией, мы далеко не -застрахованы от проблем, связанных с получением требований, необходимых для -дальнейшей работы. Осуществление своей профессиональной деятельности -пользователями далеко не гарантирует, к сожалению, способность ясно, четко и -однозначно сформулировать то, что они делают и что именно им необходимо для -решения их задач сегодня и завтра. Во многом, поэтому, сбор требований, -зачастую, превращается в столь тяжелый и часто порождающий конфликты процесс -действительно извлечения, “вытаскивания” информации, без которой невозможно -переходить к дальнейшим проектным работам. Недопонимание между аналитиком и -пользователем, упущение тех или иных аспектов, на первый взгляд кажущихся -второстепенными, неоднозначность или тем более некорректность интерпретации -информации, полученных от пользователей – все это наиболее типичные причины -“сверх-затрат” (времени, денег и т.п.), а иногда, и полного провала проектов. - -Существует множество практик и подходов, позволяющих добиться действительно -стройной системы требований, отвечающих реальным потребностям и приоритетам -заказчиков. Среди них можно выделить следующие: - -- Интервьюрирование – традиционный подход извлечения требований; не стоит -забывать, что получение информации от пользователя “не равно” получению -требований; информация должна быть проанализирована и трансформирована в -требования, таким образом, информация от пользователя является “входом” в -процессы сбора требований, а сами требования – “выходом” этих процессов; -- Сценарии – контекст для сбора пользовательских требований, определяющий -ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, -реализуемых пользователями; -- Прототипы – отличный инструмент для уточнения и/или детализации требований; -существуют разные подходы к прототипированию – от “бумажных” моделей до -пилотных подсистем, реализуемых как самостоятельные (в терминах управления -ресурсами) проекты или бета-версии продуктов; часто прототипы постепенно -трансформируются в результаты проекта и используются для проверки и утверждения -требований; -- “Разъясняющие встречи” - в оригинале звучит как “facilitated meetings”; -достаточно емкий по смыслу термин, пришедший из общей практики менеджмента и -базирующийся на идеях сотрудничества заинтересованных лиц для совместного -анализа путей решения проблем, определения и предупреждения рисков и т.п. В -отличие от “обычного”, с позволения сказать, “мозгового штурма”, как -исключительной формы обсуждения тех или иных задач (часто в критические моменты -работ над проектом), “запланированный мозговой штурм” – особая форма встреч -участников проекта и заинтересованных лиц со стороны заказчика, посвященная -обсуждению тех вопросов, ответы на которые не могут быть определены в -результате обычных интервью и которые требуют вовлечения большего количества -лиц, чем просто пары “пользователь-аналитик”; я позволили себе сконструировать -на русском языке этот термин еще и как “запланированный мозговой штурм”, так -как такого рода встречи действительно обычно планируются с заданной -периодичностью для обеспечения однозначности интерпретации информации, значимой -для проекта и, что очень важно – проведения таких встреч до того, как связанные -с данными вопросами риски не превратились в реальные проблемы, требующие -решения “вчера”, а, следовательно, и дополнительных (изначально -незапланированных) ресурсов времени, денег и т.д.; -- Наблюдение (observation) – подразумевает непосредственное присутствие -аналитиков и инженеров рядом с пользователем в процессе выполнения последним -его работ по обеспечению функционирования бизнес-процессов: в определенной -степени можно провести аналогию с практикой присутствия представителя заказчика -в проектной группе исполнителя ( типовая практика в eXtreme Programming -“on-site customer” – “присутствующий заказчик”); данная техника является -достаточно затратной, но, в то же время, очень эффективной, а иногда – просто -незаменимой, особенно, если речь идет о достаточно сложных и взаимосвязанных -бизнес-процессах; - -Существуют и другие, достаточно эффективные практики, описание которых можно -найти в литературе и которые вы, наверняка, сами используете в своей работе -(например, Requirements Workshop, Role Playing, Storyboarding и т.п.). -Некоторые из них будут также упоминаться в контексте конкретных методологий. - -## Анализ требований (Requirements Analysis) - -Эта секция посвящена процессам анализа требований, то есть трансформации -информации, полученной от пользователей (и других заинтересованных лиц) в четко -и однозначно определенные требования, передаваемые инженерам для реализации в -программном коде. - -Анализ требований включает: - -- Обнаружение и разрешение конфликтов между требованиями; -- Определение границ задачи, решаемой создаваемым программным обеспечением; в -общем случае - определение “scope” (или “bounds”), границ и содержания -программного проекта; -- Детализация системных требований для установления программных требований; - -Практически всегда, хотя это явно и не отмечено в описании анализа требований -как секции SWEBOK, на практике выделяется и детализация бизнес-требований для -установления программных требований. Например, пресловутый режим работы 24x7, -сформулированный в виде бизнес-требования, накладывает достаточно жесткие рамки -на выбор технологической платформы и архитектурных решений как технических -требований к разрабатываемой программной системе. - -- SWEBOK отмечает, что традиционный взгляд на анализ требований часто -сфокусирован или уменьшен до вопросов концептуального моделирования с -использованием соответствующих аналитических методов, одним из которых является -SADT – Structured Analysis and Design Technique (методология структурного -анализа и техники проектирования), знакомый многим по нотациям IDEF0 -(функциональное моделирование – стандарт IEEE 1320.1), IDEF1X (информационное -моделирование – стандарт IEEE 1320.2, известный также как IDEFObject), часто -применяемым как для моделирования бизнес-процессов, так и структур данных, в -частности – реляционных баз данных. - -Так или иначе, вне зависимости от выразительных средств, которые являются лишь -инструментом анализа и фиксирования результатов, результатом анализа требований -должны быть однозначно интерпретируемые требований, реализация которых -проверяема, а стоимость и ресурсы – предсказуемы. - -### Классификация требований (Requirements Classification) - -Требования могут классифицироваться по целому ряду параметров, например: - -- Функциональные и нефункциональные требования -- Внутренние (с другими требованиями) или внешние зависимости -- Требования к процессу или продукту -- Приоритет требований -- Содержание требований в отношении конкретных подсистем создаваемого программного обеспечения -- Изменяемость/стабильность требований - -Другие варианты классификации могут, и часто базируются, на принятых в -организации подходах, применяемых методологиях, методах и практиках, а, -зачастую, и специфике проектов и даже требованиях заказчиков к процессу -разработки и, в частности, определения требований и форме представления -результатов их анализа. - -### Концептуальное моделирование (Conceptual Modeling) - -Разработка модели проблемы реального мира – ключевой элемент анализа -требований. Цель моделирования – понимание проблемы, задачи и методов их -решения до того, как начнется решение проблемы. - -Часто приходится слышать, что прагматичность подхода в отношении программных -проектов заключается в “пропуске” этапа (или стадии, фазы) моделирования. В -свою очередь, часто ставят знак равенства между моделированием и “этими -красивыми квадратиками со стрелочками”. Ни то, ни другое утверждение неверны. -Например, в XP и в других гибких (Agile) практиках существуют и истории -пользователей, и карточки задач, и процедуры анализа (в частности, связанных с -ними “мозговых штурмов”, как запланированных, так и, к сожалению, не очень) , в -результате которого мы сформулировали задачи, высокоуровневые возможности - -“фичи” продукта (feature - особенность), а также необходимые модели (см. -[Амблер, 2002]). Объем моделей, их детализация и средства представления могут -быть различны. Их выбор базируется и/или диктуется конкретным культурным -контекстом организаций, вовлеченных в проект, и практик, применяемых проектной -группой. Именно не форма, но сама идея моделирования как попытка упростить и -однозначно интерпретировать на концептуальном уровне проблематику деятельности -в реальном мире – обязательная составляющая как управления требованиями, так и -программной инженерии, в целом. - -Среди факторов, которые влияют на выбор модели, метода и детализации ее -представления, степени связанности с программным кодом и другими вопросами: - -- Природа проблемы (проблемной области) -- Экспертиза и опыт инженеров -- Требования заказчика к процессу -- Доступность методов и инструментов -- Внутрикорпоративные стандарты и регламенты -- Культура разработки - -В любом случае, моделирование рассматривается в программном контексте, а не -только с точки зрения бизнес-задач как таковых, Это обусловлено необходимостью -понимания операционного и системного контекста, то есть окружения, в котором -программная система будет реально использоваться и которое накладывает свои, -иногда достаточно жесткие ограничения. - -Вопросы моделирования тесно связаны с применяемыми методами и подходами. -Однако, частные методы или нотации, как отмечается в SWEBOK, так или иначе -следуют распространенным в индустрии практикам и тяготеют к тем формам, с -которыми связаны накопленный опыт и подтвержденные общепринятой практикой -знания. SWEBOK отмечает, что могут быть разработаны различные виды моделей, -включающие потоки работ и данных, модели состояний, трассировки событий, -взаимодействия пользователей, объектные модели, модели структур данных, и т.п. -Кстати, именно такая ситуация сложилась с UML, все чаще воcпринимаемым в -качестве общепринятого или de-facto стандарта в моделировании и включающем -целый комплекс моделей (в UML 2.0 включено 14 моделей, представленные в двух -группах – статические модели и поведенческие), связанных и объединенных общей -архитектурой, на основе концепции метамоделей. - -Cовременное состояние стандарта UML (унифицированного языка моделирования -Unified Modeling Language, разрабатываемого консорциумом OMG – www.omg.org ) -версии 2.0 вполне позволяет говорить о расширении его применимости в “чистом” -бизнес-моделировании. На фоне богатства выразительных средств, появления -соответствующего инструментального обеспечения работы с UML 2.0, длительной -истории успешного применения стандарта UML 1.x, инструментов на его основе и -повсеместного использования UML в области объектно-ориентированного анализа и -проектирования не только аналитиками, но архитекторами и разработчиками ПО, -можно с уверенностью говорить о смещении фокуса индустрии программного -обеспечения в сторону UML и отходу (как минимум, частичному) от IDEF, в -применении к аналитической деятельности. Темпы такой “миграции”, конечно, -зависят от степени консервативности взглядов конкретных -специалистов-аналитиков. Однако, давление рынка, требование унификации, в -частности, выразительных средств описания активов проектов в рамках всей -проектной команды – те причины, по которым, по мнению автора, аналитики, не -воспринявшие UML-ориентированный тренд, могут оказаться за бортом серьезных -корпоративных ИТ-проектов. Даже на фоне “неприятия” UML некоторыми игроками -рынка, критическая масса знаний и практик по его применению уже оказалась -достаточно велика, чтобы игнорировать его применение. В то же самое время, не -стоит воспринимать UML как панацею – это касается любой технологии, практики -или подхода. Создан, активно развивается и уже поддержан индустрией стандарт -BPMN – Business Process Management Notation (см. www.bpmi.org). Таким образом, -все определяется конкретным “культурным” контекстом. Просто надо помнить об -этом и оставаться “прагматиками”, в положительном понимании этого слова, не -теряя креативности в повседневной деятельности. - -Необходимо отметить, что на практике наблюдается тенденция разделения вопросов -определения требований и моделирования. Это, например, заметно в современных -методологиях, таких как RUP (Rational Unified Process), где работа с -требованиями и моделирование/проектирование – суть две разные дисциплины. - -### Архитектурное проектирование и распределение требований (Architectural Design and Requirements Allocation) - -Считается, что создание архитектуры программных решений является обязательным -элементов успешности таких проектов. Архитектурное проектирование перекрывается -с программным и системным дизайном (проектированием) и иллюстрирует насколько -сложно провести четкую грань между различными аспектами проектирования. Данная -тема работы с программными требованиями тесно связана с секцией “Структура и -архитектура программного обеспечения” (Software Structure and Architecture) -области знаний “Проектирование программного обеспечения” (Software Design). Во -многих случаях, инженеры действуют как архитекторы, потому как процессы анализа -и выработки требований зависят от программных компонент, создаваемых для -решения поставленных заданными требованиями задач, призванных, в конечном -счете, добиться реализации поставленных перед проектом целей. - -Архитектурное проектирование очень близко к концептуальному моделированию. -Непосредственное отображение бизнес-сущностей реального мира на программные -компоненты не является обязательным. Во многом поэтому и существует такое -разделение между моделированием и проектированием. В принципе, можно говорить о -том, что деятельность по моделированию в большей степени касается того, ”что” -надо сделать, а архитектура - “как” это будет реализовано. - -Существует ряд стандартов и общепринятых практик, связанных с архитектурным -проектированием. Среди них наиболее популярны: - -- Стандарт IEEE 1471-2000 “Recommended Practice for Architectural Description -of Software Intensive Systems” -- Модель Захмана – Zachman Framework (www.zifa.com) -- TOGAF – The Open Group Architecture Framework (www.opengroup.org/architecture/) - -Важно заметить, что ни в коем случае не надо путать архитектурные рекомендации -(Architectural Guidelines) с практиками и стандартами архитектурного -проектирования. Одни (например, Federal Enterprise Architecture Framework FEAF) -дают рекомендации по конкретным архитектурно-технологическим решениям. Другие -концентрируются именно на том, чему стоит уделить внимание при создании -архитектуры, как ее описать и детализировать, и что из себя представляет -архитектура, как таковая (например, ISO 15704 Industrial Automation Systems – -Requirements for Enterprise-Reference Architectures and Methodologies). - -## Спецификация требований (Requirements Specification) - -На инженерном жаргоне, да и в терминологии ряда методологий, устоялся термин -“software requirements specification” (SRS) – спецификация программных -требований. Для сложных систем, на самом деле, существует целый комплекс -спецификаций, документов, которые являются результатом сбора и анализа -требований, их моделирования и архитектурного проектирования. Эти документы -систематически анализируются, в них вносятся изменения, они пересматриваются и -утверждаются. Чаще всего, для описания комплексных проектов (в части -требований) используется три основных документа (спецификации): - -- Определение системы (system definition) -- Системные требования (system requirements) -- Программные требования (software requirements) - -### Определение системы (System Definition Document) - -Данный документ, часто называемый как “спецификация пользовательских -требований” (user requirements specification) или “концепция” (concept ), описывает системные требования. Содержание документа определяет -высокоуровневые требования, часто – стратегические цели, для достижения которых -создается программная система. Принципиальным моментом является то, что такой -документ описывает требования к системе с точки зрения области применения - -“домена”. Соответственно, изложение требований в нем ведется в терминах -прикладной области. Документ описывает системные требования вместе с -необходимой информацией о бизнес-процессах, операционном окружении с точки -зрения бизнес-процедур и организационных и других регламентов. Примером -стандарта для создания и структурирования такого документа является IEEE 1362 -“Concept of Operations Document”. - -### Спецификация системных требований (System Requirements Specification) - -В сложных проектах принято разделять спецификацию системных требований (system -requirements) и спецификацию программных требований (software requirements). -При таком подходе программные требования порождаются системными требованиями и -детализируют требования к компонентам и подсистемам программного обеспечения. -Документ описывает программную систему в контексте системной инженерии (system -engineering), идеи которой кратко описаны в Главе 12 SWEBOK “Связанные -дисциплины программной инженерии”. Строго говоря, спецификация системных -требований описывает деятельность системных инженеров и выходит за рамки -обсуждения SWEBOK. Стандарт IEEE 1233 является одним из признанных руководств -по разработке системных требований. И, как уже отмечалось ранее, не стоит -забывать о том, что понятие система, в общем случае, охватывает программное -обеспечение, аппаратную часть и людей. Системная инженерия (см. материалы -INCOSE – www.incose.org ), в свою очередь, самостоятельная и не менее объемная -дисциплина чем программная инженерия. SWEBOK рассматривает системную инженерию -как важную связанную дисциплину. Ну а системные требования – один из элементов -реального связывания различной инженерной деятельности - программной и -системной. - -### Спецификация программных требований (Software Requirements Specification - SRS) - -Часто эту спецификацию называют “требованиями к программному обеспечению”. Все -же, учитывая существование дисциплин системной и программной инженерии, мы -используем термин “программные требования”, как более точно подходящий по -смыслу по моему мнению. - -Программные требования устанавливают основные соглашения между пользователями -(заказчиками) и разработчиками (исполнителями) в отношении того, что будет -делать система и чего от нее не стоит ожидать. Документ может включать -процедуры проверки получаемого программного обеспечения на соответствие -предъявляемым ему требованиям (вплоть до содержания планов тестирования), -характеристики, определяющие качество и методы его оценки, вопросы безопасности -и многое другое. Часто программные требования описываются на обычном языке. В -то же время, существуют полуформальные и формальные методы и подходы, -используемые для спецификации программных требований. В любом случае, задача -состоит в том, чтобы программные требования были ясны, связи между ними -прозрачны, а содержание данной спецификации не допускало разночтений и -интерпретаций, способных привести к созданию программного продукта, не -отвечающего потребностям заинтересованных лиц. Стандарт IEEE 830 является -классическим примером стандарта на содержание структурирование и методы -описания программных требований – “Recommended Practice for Software -Requirements Specifications”. - -Необходимо отметить, что в документацию на требования не следует вносить -элементы дизайна системы (скажем, логическую модель базы данных). А вот -сценарии использования Use Case часто включают в спецификацию требований -наравне с трассировкой (traces) к соответствующим моделям в форме диаграмм, -например, к UML Use Case, UML Activity, BPMN и т.п. . Говоря о написании -спецификаций требований, то есть одно серьезное заблуждение, которое делают -обычно неопытные аналитики – это фактическая подмена требований как таковых, -моделями графического пользовательского интерфейса, т.е. когда в -документы-спецификации требований просто включаются «картинки» -пользовательского интерфейса с небольшими пояснениям. Это отнюдь не означает, -что с заинтересованными лицами и в частности с пользователями, не следует -вообще обсуждать дизайн GUI, часто это имеет смысл делать, но для этого -существует, например, прототипирование. Мне довелось изучить многие документы -требований в разных организациях и практически все они имели одни и те же -проблемы: - -- Терминологическая неопределенность. Часто используются термины, которые -обладают многозначностью, и такие термины не определены в глоссариях, чтобы -можно было четко понять, что конкретно автор имеет в виду в данном случае (это -не всегда бывает понятно из контекста). Как пример можно привести собственно -использование (и, что немаловажно, понимания!) термина «требования». Под этим -ёмким термином можно понимать как требования к бизнес процессам, так и -функциональные или нефункциональные требования к ПО вообще. Интересно, что на -уровне многих стандартов (к сожалению, в основном, англоязычных) прописано -использование тех или иных глаголов, форм и структурирование предложений, -описывающих требования – например использование глаголов (will, shall, should, -may, can – перечислены в порядке “убывания директивности”). Действительно, -“программный модуль X отсылает уведомление на e-mail адрес пользователя...” -несет, мягко говоря, иную смысловую нагрузку, чем “отсылается сообщение”. -- Отсутствие представления о классификации требований. Подмена одних категорий -требований – другими и смешение требований (например, такое часто случается с -функциональными требованиями, бизнес-требованиями и бизнес-правилами). Как -результат – создаваемые документы тяжело читать и извлекать полезную для -разработки ПО информацию. Зачастую в одном абзаце, можно встретить перемешанные -как описания необходимой функциональности и тут же элементы предполагаемого -пользовательского интерфейса, который должен воплотить разработчик. Или -проектные решения, например, использование таблиц баз данных или полей. И -помимо этого, содержится несистематизированная и фрагментарная информация о -бизнес-процессах организации. Все это скрывает истинные требования к -разрабатываемому ПО, что в свою очередь затрудняет как разработку, так и -согласование требований. Корректная и однозначная интерпретация требований и -анализ влияний становятся практически неосуществимыми, что напрямую сказывается -на адекватности удовлетворения потребностей заказчика/пользователей. -- Фокусировка на деталях пользовательского интерфейса. В документах встречается -акцентирование не на необходимой функциональности, а на деталях -пользовательского интерфейса. -- Излишнее акцентирование внимания на деталях реализации. Попытка отразить в -документе с требованиями к создаваемому ПО не ЧТО должна делать система, а то -КАК она это будет делать. Это одна из ключевых проблем. Во многом, поэтому, -часто выделяют внутренние технические требования к системе, которые не проходят -аттестации со стороны пользователей и разрабатываются не аналитиками, а -архитектором и ведущими разработчиками уже на этапе проектирования – software -design (см. следующую область знаний SWEBOK). -- Слабая формализация бизнес-процессов. В документах перемешивается описание -бизнеса и требования к ПО, что приводит сложностям в понимании сути и общему -пониманию как должна быть спроектирована система. - -## Проверка требований (Requirements Validation) - -Определение требований напрямую связано с процедурами проверки (verification) и -утверждения (аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC -12207). Вообще говоря, принято считать, что требования описаны неполностью, -если для них не заданы правила V&V (verification&validation – проверка и -аттестация), то есть не определены способы проверки и утверждения. Процедуры -проверки являются отправной точкой для инженеров-тестировщиков и специалистов -по качеству, непосредственно отвечающих за соответствие получаемого -программного продукта предъявляемым к нему требованиям. - -К сожалению, как уже комментировалось выше, часто, в крупных организациях -вместо полноценной проверки сути и содержания документов, все сводиться к так -называемому "нормоконтролю" -- когда проверка документов требований заключается -в проверке на соблюдение принятых стандартов внешнего оформления документа -(отступы и размеры поля, подписи таблиц/рисунков и т.п.), но никак ни оценки -качества требований. И совершенно неверно считать такой "нормоконтроль" -полноценной проверкой требований. - -Если стандарты жизненного цикла описывают как правильно создавать продукт, то -стандарты (в том числе, внутрикорпоративные) отвечают за создание правильного -продукта, то есть того продукта, который соответствует ожиданиям пользователей -и других заинтересованных лиц. - -Для достижения этой цели применяется ряд практик, в том числе, представленных -ниже. - -### Обзор требований (Requirements Review) - -Один из распространенных методов проверки требований - инспекция или обзор -требований. Суть его заключается в том, что ряд лиц, вовлеченных в проект (для -крупных проектов – специально выделенные специалисты), “вычитывают” требования -в поисках необоснованных предположений, описаний требований, допускающих -множественные интерпретации, противоречий, несогласованности, недостаточной -степени детализации, отклонений от принятых стандартов и т.п. - -Вопросы обзора требований, вообще говоря, имеют непосредственное отношение к -теме качества, поэтому они также описываются в области знаний SWEBOK “Качество -программного обеспечения” (Software Quality) в теме 2.3 “Обзор и аудит” (Review -and Audit). - -### Прототипирование (Prototyping) - -В общем случае, прототипирование подразумевает проверку инженерной -интерпретации программных требований и извлечение новых требований, -неопределенных или неясных на ранних итерациях сбора требований. Существует -множество подходов к прототипированию, как с точки зрения детализации, так и -того, чему уделяется внимание при прототипировании. Наиболее часто прототипы -создаются для оценки способа реализации пользовательского интерфейса и проверки -архитектурных подходов и решений. - -При всей безусловной полезности прототипирования для обеспечения проверки -требований и решений, необходимо понимать, что с прототипированием связан ряд -вопросов способных привести к негативным последствиям или, как минимум, -работам, требующим дополнительного времени и средств. Среди возможных -негативных последствий прототипирования стоит выделить следующие: - -- Смещение внимания с целевых функций прототипа и, как следствие, -неудовлетворенность пользователей огрехами прототипа, отсутствием стоящей за -ним реальной функциональности (для прототипов пользовательского интерфейса), -ошибками в прототипе и т.п. -- Превращение прототипа в реальную систему за счет постоянного добавления новых -свойств и функциональности “для проверки” – часто бывает нарушена архитектурная -целостность, необеспечена необходимая масштабируемость и качество получаемого -программного продукта; - -Здесь хотелость бы добавить и еще одну типичную проблему - переключение -внимания заинтересованных лиц на эргономику и детали дизайна графического -пользовательского интерфейса, при начальной цели построения прототипа для -выявления функциональных и иных требований и наоборот. Проблема не во внимании -пользовательскому интерфейсу, проблема в подмене, если так можно выразиться, -функциональной составляющей пользовательским интерфейсом (вспомните, как часто -вы сами говорили или слышали – “я не о ‘кнопочках’ и ‘окошках’, я о задаче -...”). - -Конечно, ясно, что эти факторы можно превратить и в положительные стороны -прототипа. Кроме того, не стоит считать что прототип это всегда нечто, -воплощенное в код. Прототипом пользовательского интерфейса может быть, -например, просто “прорисованный” на бумаге или в электронной форме набор -переходов между экранами/диалоговыми окнами системы (кстати, это подход, часто -используемый в Agile-практиках, но отнюдь не заменяющий требований к системе). - -Так или иначе, выбор того или иного метода прототипирования, да и самого факта -такого способа проверки требований или технологических идей, должен -основываться на временных и других имеющихся ресурсах, опыте в прототипировании -и, конечно, степени сложности создаваемой программной системы. - -### Утверждение модели (Model Validation) - -Утверждение или аттестация модели связана с вопросами обеспечения приемлемого -качества продукта. Уверенность в соответствии модели заданным требованиям может -быть закреплена формально со стороны пользователей/заказчика. В то же время, -проверка и аттестация модели, например, объектно-ориентированного представления -бизнес-сущностей и связей между ними может быть проверена с той или иной -степенью использования формальных методов, например, статического анализа -(поиск связей и путей взаимодействия между описанными объектами и выделение -различного рода несоответствий). Это – другая сторона утверждения модели. - -### Приемочные тесты (Acceptance Tests) - -Требования должны быть верифицируемы. Требования, которые не могут быть -проверены и аттестованы (утверждены) – это всего лишь “пожелания”. Именно так -они буду восприниматься разработчиками, даже в случае их высокой значимости для -пользователей. Если описанное требование не сопровождается процедурами проверки -– в большинстве случаев говорят о недостаточной детализации или неполном -описании требования и, соответственно, спецификация требований должна быть -отправлена на доработку и если необходимо, должны быть предприняты -дополнительные усилия, направленные на сбор требований. - -Можно говорить о том, что процедура анализа требований считается выполненной -только тогда, когда все требования, включенные в спецификацию, обладают -методами оценки соответствия им создаваемого программного продукта. Чаще всего -столь строгое ограничение на степень законченности спецификации накладывается -на функциональные требования и атрибуты качества (например, время отклика -системы). - -Идентификация и разработка приемочных тестов для нефункциональных требований -часто оказывается наиболее трудоемкой задачей. Для ее решения обычно “ищут -точку опоры”, то есть возможность взгляда на описываемые требования с -количественной точки зрения, в плоть до переформулирования и большей степени -детализации описания таких требований. - -Дополнительная информация, связанная с приемочными тестами представлена в -области знаний SWEBOK “Тестирование программного обеспечения” (Software -Testing) в описании 2.2.4 “Тесты соответствия” (Conformance testing). - -## Практические соображения (Practical Considerations) - -Первый уровень декомпозиции секций данной области знаний напоминает описание -последовательности действий. Это, безусловно, упрощенный взгляд на процесс -работы с требованиями. Данный процесс, точнее, комплекс процессов, охватывает -весь жизненный цикл программного обеспечения. Управление изменениями и -сопровождение, поддержка актуальности требований и их реализации – ключ к -успешным процессам программной инженерии. - -Далеко не каждая организация обладает культурой документирования и управления -требованиями. Особенно часто это встречается в молодых небольших компаниях, -выводящих на рынок новые продукты и обладающие “сильным вижином”, четким -пониманием целей, для которых создается продукт, но не имеющих достаточно -ресурсов и, во многом поэтому считающих, что динамизм – залог успеха. -Постепенно такие компании вырастают, проекты – усложняются и, как следствие -складывается ситуация, когда отследить все необходимые требования в -неформальной форме уже просто невозможно. Эта тема практически неисчерпаема. -Многие средние по масштабам компании пытаются сохранить тот же вровень гибкости -и динамизма, который применялся во времена рождения компании, когда она еще -была “стартапом” (start-up – название молодых компаний, которые раскручивали -свои проекты во времена интернет-бума конца 90-х и которое прижилось для вновь -образующихся малых бизнесов, растущих не столько на внешних инвестициях, -сколько на идеях и упорстве ее создателей). Так или иначе, динамизм присущ не -только компаниям, но и продуктам, самим требованиям к ним. Управление -изменениями, концепцией, видением продукта не может быть хаотическим – история -индустрии однозначно это показывает. Поэтому отношение к управлению -требованиями как к постоянно действующему бизнес-процессу – абсолютно -обоснованный подход, требующий применения определенных практик. В противном -случае, мы практически гарантировано столкнемся с теми негативными -последствиями, которые не раз описывались и упоминались выше. - -### Итеративная природа процесса работы с требованиями (Iterative Nature of the Requirements Process) - -В большинстве случаев, понимание и интерпретация требований продолжает -эволюционировать в процессе проектирования и разработки программного -обеспечения. Кроме того, требования часто меняются в силу изменений -бизнес-контекста для которого создается и в котором эксплуатируется программное -обеспечение. Необходимо понимать неизбежность изменений и планировать шаги по -уменьшению проблем, связанных с изменениями. В то же самое время, современные -практики гибкой разработки говорят о том, что необходимо концентрироваться -только на том, что требует внимания “прямо сейчас”, не закладываясь на -предупреждение всех возможных рисков, в том числе связанных с изменениями, -включая изменения требований. Говорить о том, какой подход – предупреждение или -реагирование является гарантировано приводит к успеху – сложно сказать. Более -того, если кто-то однозначно настаивает только на одной из идей и полностью -отвергает другую – это профанация. Восприятие изменений и возможность их -своевременной обработки - вопрос способности проектной команды работать в -условиях постоянно меняющихся условий, принимаемых архитектурных решений и -многих других культурных, технологических и организационных факторов. Так или -иначе, понимание меняющейся природы требований – один из факторов адекватного -реагирования на сами изменения, а, следовательно, и возможности успешного -завершения проекта. - -### Управление изменениями (Change Management) - -Управление изменениями – одна из ключевых тем управления требованиями. -Необходимость определения процедур для обработки изменений совсем не то же -самое, что и их детальная формализация. Такие процедуры необходимы. Им -посвящена тема управления изменениями в приложении к требованиям. В то же -время, рассматривать изменение требований в отрыве от других процессов, по -меньшей мере, кажется странным. Соответственно, данный вопрос является -составной частью управления изменениями и конфигурациями программного -обеспечения (Software Configuration and Change Management, SCCM), которое -сегодня принято называть просто конфигурационным управлением (Software -Configuration Management, SCM), подразумевая, что это не только вопросы -контроля версий, но управление всеми активами проекта, включая код, требования, -запросы на изменения – change requests (в том числе, отчеты об ошибках – defect -или bug reports), задачи (в терминах проектного менеджмента) и т.п. - -Общий комплекс вопросов конфигурационного управления рассматривается в области -знаний SWEBOK “Управление конфигурациями программного обеспечения” (Software -Configuration Management). - -### Атрибуты требований (Requirements Attributes) - -Требования должны состоять не только из описания того, что необходимо сделать, -но и содержать информацию, необходимую для интерпретации требований и -управления ими. Например, с пользовательскими требованиями часто ассоциируют -сценарии Use Case (как в текстовом, так и графическом представлении) и, в то же -время, функциональные требования часто трансформируются в задачи в терминах -проектного управления, с которыми связаны параметры законченности (например, в -процентах), ответственности (например, кто является “владельцем” требования, -кто из инженеров назначается исполнителем или принимает на себя обязанности, -связанные с реализацией заданной функциональности, как это принято, например, в -XP или FDD). Примеров существует множество и, в зависимости от применяемых -практик и методов, сложившейся проектной и организационной культуры, спектр -атрибутов может меняться достаточно широко, практически, неограниченно. - -Необходимо также помнить, что к обсуждаемым атрибутам также относятся -параметры, связанные с классификацией требований (см. выше тему 4.1 -“Классификация требований”). В свою очередь, принадлежность к тому или иному -классу (категории, типу, виду) требований означает не только семантику того, -“чему посвящены” требования (функциональности, параметрам качества и т.п.), но -и комплекс атрибутов, общий для всех требований данного класса. - -В какой-то степени можно провести параллель между требованиями и записями -(строками) в реляционной базе данных, где каждая запись обладает набором -атрибутов (столбцов). В определенном смысле, можно и необходимо говорить о том -или ином уровне атомарности требований (что не исключает связей между -требованиями), представляемой такой метафорой. - -### Трассировка требований (Requirements Tracing) - -Трассировка требований обеспечивает связь между требованиями и отслеживание -источников требований. Трассировка является фундаментальной основой проведения -анализа влияния (impact analysis) при изменении требований, помогая -предсказывать эффект от внесения таких изменений. Трассировка предполагает -направленную связь (представляется в виде сложного направленного ациклического -графа) между требованиями, то есть зависимости. - -Требования (B) обладают обратной зависимостью (то есть вторичны) по отношению к -требованиям (A) и заинтересованным лицам, которые являются источником либо -образуют причину появления рассматриваемых требований (B). И, наоборот, -требования (A) трассируются напрямую к тем требованиям (B) и элементам дизайна -(например, модели или, в общем случае, кода, запросов на изменения и т.п.), -которые порождаются или удовлетворяют требованиям (A). - -### Измерение требований (Measuring Requirements) - -С практической точки зрения, обычно полезно иметь нечто, позволяющее определить -“объем” требований для заданного (создаваемого) программного продукта. Это -число полезно для исследования “масштабов” изменений в требованиях, оценки -стоимостных характеристик (cost estimation) разработки и поддержки программной -системы, опосредовано – оценки продуктивности разработки и эффективности -поддержки на этапах реализации требований и внесения изменений и т.п. - -Измерение объема функциональности (Functional Size Measurement, FSM) техника -такого рода численной оценки, определена на концептуальном уровне в стандарте -IEEE 14143.1. Стандарты ISO/IEC и другие источники описывают частные методы FSM -(например, модель COCOMO II для оценки стоимости, например, может -использоваться в тесной связи с методами функциональных точек – functional -points для оценки масштабов функциональности, то есть требований, предъявляемых -заданной программной системе). - -Дополнительная информация по стандартам и подходам в оценке масштабов -представлена в области знаний “Процесс программной инженерии” (Software -Engineering Process). - -В дополнение к практическим соображениям, представленным в SWEBOK, на фоне -общей тенденции разработки моделей <оценки> зрелости, стоит отметить, что -существуют определенные работы и по созданию различных моделей зрелости -требований. Например, наиболее популярная модель зрелости в индустрии -программного обеспечения – CMMI включает разный объем и содержание работ по -определению и управлению требованиями для уровней зрелости 2 и 3. blob - /dev/null blob + 6b9594b6daf791cb304862a36d2ccdc70171bf7a (mode 644) --- /dev/null +++ 1_software_requirements.md @@ -0,0 +1,1178 @@ +# Программные требования + +Глава базируется на IEEE Guide To The Software Engineering Body Of Knowledge - +SWEBOK. + +Содержит перевод описания области знаний swebok “software requirements”, с +замечаниями и комментариями. + +Программные требования – software requirements – свойства программного +обеспечени, которые должны быть надлежащим образом представлены в нём для +решения конкретных практических задач. Данная область знаний касается вопросов +извлечения (сбора), анализа, специфицирования и утверждения требований. + +Опыт индустрии информационных технологий однозначно показывает, что вопросы, +связанные с управлением требованиями, оказывают критически-важное влияние на +программные проекты, в определенной степени - на сам факт возможности успешного +завершения проектов. Только систематичная работа с требованиями позволяет +корректным образом обеспечить моделирование задач реального мира и +формулирование необходимых приемочных тестов для того, чтобы убедиться в +соответствии создаваемых программных систем критериям, заданным реальными +практическими потребностями. + +На практике часто применяется подход, используемый в различных методологиях +разработки по и базирующийся на определении групп требований к продукту. Такой +подход обычно включает группы (типы, категории) требований, например: +системные, программные, функциональные, нефункциональные (в частности, атрибуты +качества) и т.п. Классический пример (см. рисунок 1) высокоуровневого +структурирования групп требований как требований к продукту описан в работах +одного из классиков дисциплины управления требованиями – Карла Вигерса. + +![рисунок 1. Уровни требований по Вигерсу [Вигерс, 2003, с.8, рис. 1-1]](images/requirements_wiegers.jpg) + +SWEBOK охватывает не только вопросы структурирования и систематизации +требований, но и различных процессов этапов и процессов работы с требованиями, +а также некоторые практические соображения. + +![рисунок 2. Область знаний “Программные требования” [swebok, 2004, с.2-2, рис. 1]](images/requirements_area_small.jpg) + +Сама же структура обсуждаемой области знаний в большой степени совместима со +стандартами IEEE 12207.x, ISO/IEC, ГОСТ Р ИСО/МЭК 12207. Такая структура +построена исходя из идеи выделения ключевых групп вопросов дисциплины. + +Область знаний управления требованиями включает 7 секций, каждая из которых +представлена в виде ключевых тем (см. рисунок 2). Кроме того, данная область +знаний тесно связана со следующими областями: + +- Software Design +- Software Testing +- Software Maintenance +- Software Configuration Management +- Software Engineering Management +- Software Engineering Process +- Software Quality + +## Основы программных требований (Software Requirements Fundamentals) + +Эта секция включает определение программных требований как таковых и описывает +основные типы требований и их отличия: к продукту и процессу, функциональные и +нефункциональные требования и т.п. + +Темы данной секции: + +### Определение требований (Definition of a Software Requirement) + +В данном случае подразумевается не процесс определения (извлечения, сбора, формирования, +формулирования) требований, а дается само понятие “требования”, как такового, и +отмечаются его основные характеристики, например, верифицируемость +(проверяемость) требования. + +По мнению авторов, необходимо обратить внимание на следующие определения +понятия “требование” (на основе работ Вигерса и стандарта IEEE Standard +Glossary Of Software Engineering Terminology, 1990): + +- Условие или возможность, требуемая пользователем для решения задач или +достижения целей. +- Условие или возможность, которые должны удовлетворяться системой/компонентом +системы или которыми система/компонент системы должна обладать для обеспечения +условий контракта, стандартов, спецификаций или др. регулирующими документами. +- Документальная репрезентация (зафиксированное представление, определение, +описание) условий или возможностей, перечисленных в предыдущих пунктах. + +### Требования к продукту и процессу (Product and Process Requirements) + +Проводится разграничение соответствующих требований как свойств продукта, +который необходимо получить, и процесса, с помощью которого продукт будет +создаваться; отмечается, что ряд требований может быть заложен неявно и +программные требования могут порождать требования к процессу, например: работа +в режиме 24x7 (как бизнес-требование) наверняка приведет к ограничению выбора +тех или иных программных средств, платформ развертывания и архитектурных +решений; в свою очередь, выбор платформы j2ee (Java 2 Enterprise Edition) и ее +реализации в виде конкретного сервера приложений практически наверняка +потребует применения модульного тестирования (Unit Testing) как практики +процесса разработки и JUnit, как инструмента реализации этой практики. + +### Функциональные и нефункциональные требования (Functional and Non-Functional Requirements) + +Функциональные требования задают “что” система должна делать; +нефункциональные – с соблюдением “каких условий” (например, скорость отклика +при выполнении заданной операции); часто функциональные требования представляют +в виде сценариев (вариантов использования) use сase. + +Систематизируя работы Вигерса, Лефингвелла и Видрига, Коберна, а также других +экспертов, возможно и необходимо привести классификацию различных категорий +(видов) требований и связанных с ними понятий, важнейших с точки зрения их +понимания и дальнейшего практического применения: + +- Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, +которые должны быть соотнесены с использованием или приобретением системы. +- Группа функциональных требований + - Бизнес-требования (business requirements) – определяют высокоуровневые цели +организации или клиента (потребителя) – заказчика разрабатываемого программного +обеспечения. + - Пользовательские требования (user requirements) – описывают цели/задачи +пользователей системы, которые должны достигаться/выполняться пользователями +при помощи создаваемой программной системы. Эти требования часто представляют в +виде вариантов использования (use cases). + - Функциональные требования (functional requirements) – определяют +функциональность (поведение) программной системы, которая должна быть создана +разработчиками для предоставления возможности выполнения пользователями своих +обязанностей в рамках бизнес-требований и в контексте пользовательских +требований. + +- Группа нефункциоНальных Требований (non-functional requirements) + - Бизнес-правила (business rules) – включают или связаны с корпоративными +регламентами, политиками, стандартами, законодательными актами, +внутрикорпоративными инициативами (например, стремление достичь зрелости +процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и +т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого +рода требованиям со стороны сотрудников ит-департаментов и, в частности, +технических специалистов, вовлеченных в проект. Business Rules Group дает +понимание бизнес-правила, как “положения, которые определяют или ограничивают +некоторые аспекты бизнеса. они подразумевают организацию структуры бизнеса, +контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют +распределение ответственности в системе, отвечая на вопрос “кто будет +осуществлять конкретный вариант, сценарий использования” или диктуют появление +некоторых функциональных требований. + + В контексте дисциплины управления проектами (уже вне проекта разработки +программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) +такие правила обладают высокой значимостью и, именно они, часто определяют +ограничения бизнес-проектов, для автоматизации которых создается +соответствующее программное обеспечение. + + - Внешние интерфейсы (external interfaces) – часто подменяются +“пользовательским интерфейсом”. На самом деле вопросы организации +пользовательского интерфейса безусловно важны в данной категории требований, +однако, конкретизация аспектов взаимодействия с другими системами, операционной +средой (например, запись в журнал событий операционной системы), возможностями +мониторинга при эксплуатации – все это не столько функциональные требования (к +которым ошибочно приписывают иногда такие характеристики), сколько вопросы +интерфейсов, так как функциональные требования связаны непосредственно с +функциональностью системы, направленной на решение бизнес-потребностей. + + - Атрибуты качества (quality attributes) – описывают дополнительные +характеристики продукта в различных “измерениях”, важных для пользователей +и/или разработчиков. Атрибуты касаются вопросов портируемости, +интероперабельности (прозрачности взаимодействия с другими системами), +целостности, устойчивости и т.п. + + - Ограничения (constraints) – формулировки условий, модифицирующих требования +или наборы требований, сужая выбор возможных решений по их реализации. В +частности, к ним могут относиться параметры производительности, влияющие на +выбор платформы реализации и/или развертывания (протоколы, серверы приложений, +баз данных, ...), которые, в свою очередь, могут относиться, например, к +внешним интерфейсам. + +- Системные требования (system requirements) – иногда классифицируются как +составная часть группы функциональных требований (не путайте с как таковыми +“функциональными требованиями”). Описывают высокоуровневые требования к +программному обеспечению, содержащему несколько или много взаимосвязанных +подсистем и приложений. При этом, система может быть как целиком программной, +так и состоять из программной и аппаратной частей. В общем случае, частью +системы может быть персонал, выполняющий определенные функции системы, +например, авторизация выполнения определенных операций с использованием +программно-аппаратных подсистем. + +Необходимо сделать несколько важных замечаний по бизнес-правилам. Бизнес +правила, как таковые, являются предметом пристального изучения различных +специалистов в области как бизнес-моделирования, так и программной инженерии в +целом. Практика разработки программных требований включает идентификацию и +описание бизнес-правил как самостоятельных артефактов. Например, методология +RUP выделяет отдельный артефакт Business Rule в рамках дисциплины Business +Modeling. Все бизнес-правила, в рамках данной дисциплины, идентифицируются и +описываются в документе business rules document. При разработке требований, в +сценариях use cases обычно включается ссылка на уже описанное бизнес-правило. +Скотт Амблер (см. www.agilemodeling.com/artifacts/) так же выделяет +бизнес-правило как один из артефактов, который используют в семействе Agile +методологий. + +В настоящее время разработаны методы и подходы формального представления +бизнес-правил, вплоть до формальных языков описания (использование OCL – Object +Constraint Language, BRML – Business Rules Markup Language). + +Бизнес-правила могут быть не только использованы при определении требований к +разрабатываемому ПО, но и могут отдельно оформляться в дизайне ПО (класс или +группа классов), отражаясь в конечном итоге в программном коде на определенном +языке программирования. Существуют специализированные инструментальные средства +и библиотеки, позволяющие разрабатывать и поддерживать приложения, интенсивно +использующие бизнес-правила. + +Рассматривая бизнес-правила, как артефакты относящиеся к области программных +требований можно отметить, вернее дать одно из пояснений, почему бп относят к +нефункциональным требованиям: например, при написании определенного шага в +сценарии use case, используется ссылка на бизнес правило: «… система производит +расчет стоимости в соответствии с бизнес-правилом BP41 …». В свою очередь +данное бизнес-правило может определять алгоритм расчета стоимости. Т.е. налицо +«с соблюдением каких условий система делает расчет». + +Одним из наиболее известных специалистов по BR является Рональд Росс, автор +книги «Principles of the Business Rule Approach» (Ronald G. Ross. «Principles +of the Business Rule Approach», 2003). + +Наравне с представленной классификацией требований, могут использоваться и другие подходы. +Даже в рамках этой классификации, существуют и различные взгляды на ее +интерпретацию и детализацию. Например, как результат определения целевой +аудитории и в рамках маркетинговой стратегии продвижения тиражируемого решения, +возможно определять высокоуровневые возможности (ключевые характеристики, +особенности) – “фичи” (features) разрабатываемого продукта. Иногда, такие +возможности детализируются в смысле функциональных требований в некоторых +agile-техниках, например, FDD – Feature-Driven Development (как вы видите +вплоть до самого названия целого комплекса практик, метода разработки). + +Вигерс, описывает feature как “множество логически связанных функциональных +требований, которые предоставляют определенные возможности для пользователя и +удовлетворяют бизнес-целям <организации>”. С точки зрения маркетинга +программного обеспечения, как отмечает Вигерс, feature это «группа требований, +узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия +решения по приобретению ПО – это список <отличительных особенностей или +возможностей, характеристик>, присутствующий в описании продукта». В то же +время, Леффингвелл и Видриг (D.Leffingwell, D. Widrig, Managing Software +Requirements: A Use Case Approach, Second Edition, 2003) определяют feature как +“сервисы, которые оказывает система для удовлетворения одной или более +потребностей заинтересованных лиц (stakeholders needs)”. Ими же отмечается, что +в реальных проектах могут быть не определены stakeholders needs (а их часто +выделяют, особенно если у проекта/продукта есть много заинтересованных лиц со +своими потребностями, и эти потребности могут носить взаимоисключающий +характер), но существовать features могут и самостоятельно (как и stakeholder +needs), и конечно же возможно существование и stakeholder needs и features со +взаимной трассировкой. + +Развивая тему features -- Kurt Bittner & Ian Spence в своей книге “Use Case +Modeling” (Kurt Bittner, Ian Spence. Use Case Modeling, 2002), дают схожее, +хотя и более формальное определение features. Они отмечают, что features могут +быть как относящимся к функциональным, так и к нефункциональным требованиям. И +могут изменяться от версии к версии продукта. + +Анализируя различные источники на предмет работы с features, следует отметить +следующее: + +С точки зрения инженерии требований, features являются самостоятельным +артефактом, который может быть соотнесен как с функциональными требованиями, +так и с нефункциональными (в т.ч. с ограничениями проектирования или атрибутами +качества). + +Необходимо также отметить, что Features обладают определенным дуализмом в своей +интерпретации, зависимым от контекста конкретного продукта – с одной стороны +это может быть «тот самый список характеристик, указанный на коробке продукта» +в случае создания «коробочного ПО», с другой стороны это может список +высокоуровневых возможностей системы, например при заказной разработке ПО +автоматизации бизнес-процессов конкретной организации. + +Features могут быть разного уровня детализации – от выражения высокоуровневых +возможностей системы (например, «Расчет заработной платы …»), до достаточно +конкретных требований (например, «Автоматическое уведомление Клиента по e-mail +о резервировании товара на складе») + +### Независимые или общие свойства (Emergent Properties) + +Эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть +соотнесены с отдельнымы ее элементами. Т.е. данные требования относятся к тому +синергетическому эффекту, которым может обладать такая система («целое больше, +чем сумма его частей»). Примером может служить требования к «пропускной +способности» коллцентра, которая будут зависеть от того, каким образом будут +взаимодействовать коммуникационное оборудование, оператор и программное +обеспечение в конкретных условиях. + +### Требования с количественной оценкой (Quantifiable Requirements) + +Требования, поддающиеся количественному определению/измерению, например, +система должна обеспечить пропускную способность “столько-то запросов в +секунду”; в то же самое время, крайне важно понимать, что постановка вопроса +(то есть формулирование требования) в форме “система должна обеспечить рост +пропускной способности” без указания конкретных количественных характеристик +является просто некорректно определенным требованием. + +При этом, например, требование “система должна вести журнал подключений +пользователей” может и должно детализироваться с точки зрения описания +информации, которую необходимо сохранять в журнале, однако, такое требование +уже не будет являться количественным требованием. А требование с формулировкой +“система должна обладать интуитивно-понятным пользовательским интерфейсом” - +непроверяем. В определенных случаях, по мнению автора книги, это может +выглядеть просто издевкой, даже не являясь изначально таковой – все зависит от +точки зрения: например, в устах “целевого” пользователя специализированного +программного обеспечения – системного администратора, привыкшего работать в +kshell (популярной командной оболочке Unix/Linux), объясняющего свои +потребности аналитику, фиксирующему запросы пользователя и привыкшего +оперировать Microsoft Office ;) Может ли такое требование быть +переформулировано и/или детализировано для адекватности интерпретации? Да. +Например, так – средний показатель ошибок оператора не должен превышать 2% от +объема вводимой информации и 85% пользователей должны дать положительную оценку +прототипу пользовательского интерфейса на этапе опытной эксплуатации. + +Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с +численными величинами – как часто? насколько быстро? в каком количестве? и т.п. + +Большинство требований с количественной оценкой относится к атрибутам качества. + +В качестве примера можно привести реальное требование, присутствующее в +реальном проекте по электронному документообороту: “Система должна производить +поиск документов <определенного вида> за время, не превышающее 5 секунд”. Это +типичное требование с количественной оценкой, в котором определена верхняя +граница диапазона времени, за которое должен быть осуществлен поиск документов. +Несомненно, этот атрибут качества системы существует в контексте определенного +функционального требования о возможности поиска документов по определенным +критериям. И этот контекст или связь должна быть определена либо явно, в рамках +иерархии требований, либо посредством трассировки, между требованиями разных +видов (функционального и атрибута качества). Примечательно, что Вигерс в своей +книге выделяет требования по производительности системы в отдельный вид +требований, тем не менее входящих в понятие нефункциональных требований или +атрибутов качества. + +### Системные требования и программные требования (System Requirements and Software Requirements) + +Данное разделение базируется на определении “системы”, +данном INCOSE (International Council on Systems Engineering) “комбинация +взаимодействующих элементов <созданная> для достижения определенных целей; +может включать аппаратные средства, программное обеспечение, встроенное ПО, +другие средства, людей, информацию, техники (подходы), службы и другие +поддерживающие элементы”; таким образом, подразумевается, что система является +более ёмким понятием, чем программное обеспечения и включает окружение, в +котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают +требования к системе в целом и программному обеспечению (или программной +системе), в частности. Часто в литературе по управлению требованиями +встречается описание системных требований как “пользовательских требований” +(user requirements), SWEBOK ограничивает применение понятия “пользовательское +требование” требованиями к системе конечных пользователей/заказчиков. Системные +требования по SWEBOK, в свою очередь, окружают пользовательские требования (или +требования других заинтересованных лиц – stakeholders, например, регулирование +полномочий) без указания идентифицируемого источника-человека. + +## Процесс работы с требованиями (Requirements Process) + +Данная секция вводит процессы, касающиеся вопросов работы с требованиями, и в +определенной степени “сшивает” в единое целое оставшиеся пять секций области +знаний, посвященной требованиям к программному обеспечению. + +Цель данной темы, в соответствии с SWEBOK, дать понимание того, что такое +процесс работы с требованиями, как таковой. В русском языке также устойчиво +используется его название как “процесс определения требований”. Мы его будем +использовать взаимозаменяемым образом, подразумевая весь процесс работы с +требованиями по SWEBOK. + +Что ж, рассмотрим структуру декомпозиции тем процесса работы с требованиями: + +### Модель процесса определения требований: + +- Не является дискретным; это постоянно действующий процесс на всех этапах +жизненного цикла программного обеспечения. Процесс работы с требованиями +инициируется в начале проекта и продолжается на протяжении всего жизненного +цикла, в плоть до завершения проекта. Например, функциональные тесты создаются +в соответствии с функциональными требованиями к программной системе и обычно +выполняются, в том числе, при проведении приемочных испытаний. Как вы уже +заметили, в переводе использовалась все же “работа с требованиями” для +акцентирования внимания на том факте, что требования не только “определяются” +на начальных этапах работ, но и модифицируются и используются во всем жизненном +цикле. +- Идентифицирует программные требования как элементы конфигурации (в терминах +конфигурационного обеспечения) и контролирует их с использованием тех же +практик конфигурационного управления, что и для других активов программных +проектов (например, файлов или запросов на изменения). +- Требует адаптации к проектному и/или организационному контексту, в рамках +которого ведется соответствующий программный проект. + +В частности, тема процесса определения требований касается тех вопросов, +которые охватываются в рамках сбора, анализа, специфицирования и утверждения +требований с точки зрения организации этих видов деятельности для различных +типов проектов и значимости тех или иных ограничений по отношению к процессу. В +большинстве случаев, процесс определения, работы с требованиями выделен в +самостоятельный набор и описан как последовательность (сценарии) действий, +связанных с ними ролей и непосредственных результатов (их часто называют +“артефактами”, например, в RUP – Rational Unified Process), в рамках конкретных +методологий разработки программного обеспечения, наиболее популярные из которых +мы рассмотрим позднее. + +### Участники процессов (Process Actors) + +В этой теме вводится понятие “роли” и дается понимание “ролей” для людей, +которые участвуют в процессе работы с требованиями (чувствуете отличие между +“определением” требований и “работой” с ними?). Таких людей также называют +“заинтересованными лицами” (в данном контексте - software stakeholders). +Заинтересованное лицо – некто, имеющий возможность (в том числе, материальную) +повлиять на реализацию проекта/продукта. + +Типичные примеры ролей: + +- Пользователи (Users): группа, охватывающая тех людей, кто будет +непосредственно использовать программное обеспечение; пользователи могут +описать задачи, которые они решают (планируют решать) с использованием +программной системы, а также ожидания по отношению к атрибутам качества, +отображаемые в пользовательских требованиях. +- Заказчики (Customers): те, кто отвечают за заказ программного обеспечения +или, в общем случае, являются целевой аудиторией на рынке программного +обеспечения (образуют целевой рынок ПО); + +Стандарт 12207 (его обзор будет приведен в другой главе) определяет более +суженное понятие “заказчика” (обратите внимание – acquirer, а не customer, хотя +часто оба термина переводятся на русский язык одинаково) как организацию, +которая приобретает или получает систему, программный продукт или программную +услугу от поставщика. Здесь возможно использовать такое общее определение: +заказчик – лицо или организация, получающие прямую или косвенную выгоду от +использования продукта. Клиентами считают тех заинтересованных лиц, кто +требует, оплачивает, выбирает, использует или получает результаты работы +программного обеспечения. В этом плане, “заказчик” в понимании стандарта 12207 +скорее ближе к “клиенту” в такой интерпретации. + +- Аналитики (Market analysts): продукты массового рынка программного +обеспечения (как и других массовых рынков, например, бытовой техники) не +обладают “заказчиками” в понимании персонификации тех, кто “заказывает +разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в +идентификации потребностей и обращению к тем, кто может играть роль +<квалифицированных> “представителей” потребителей; + +- Регуляторы (Regulators): многие области применения (“домены”) являются +регулируемыми, например, телекоммуникации или банковский сектор. Программное +обеспечение для ряда целевых рынков (в первую очередь, корпоративного сектора) +требует соответствия руководящим документам и прохождения процедур, +определяемых уполномоченными органами. + +- Инженеры по программному обеспечению, иженеры-программисты (Software +Enginner): лица, обладающие обоснованным интересом к разработке программного +обеспечения, например, повторному использованию тех или иных компонент, +библиотек, средств и инструментов. Именно инженеры ответственны за техническую +оценку путей решения поставленных задач и последующую реализацию требований +заказчиков. + +SWEBOK особо подчеркивает, что если невозможно в точности (в оригинале – +“perfectly”) удовлетворить требования каждого заинтересованного лица, именно +работа инженера включает проведение переговоров и поиск компромисса, +приемлемого для ключевых заинтересованных лиц (“стейкхолдеров”) и +удовлетворяющего бюджетным, техническим, временным и другим ограничениям +проекта. Необходимо понимать, что такая деятельность практически наверняка +приведет к изменениям в требованиях, как минимум, на уровне соответствующих +приоритетов требований и, следовательно, работ по их реализации. + +### Управление и поддержка процессов (Process Support and Management) + +Эта тема затрагивает вопросы распределения ресурсов, необходимых для +осуществления проектной деятельности, устанавливая контекст для первой секции +“Инициация и определение содержания” (Initiation and Scope Definition) области +знаний “Управление в программной инженерии” (Software Engineering Management). +Основная цель данной темы – обеспечение связи между процессами и деятельностью, +определенными в 2.1 “модели процесса определения требований” и вопросами +использования проектных ресурсов – стоимостью, человеческими ресурсами, +инструментами и т.п. + +### Качество и улучшение процессов (Process Quality and Improvement) + +Эта тема связана с оценкой качества процессов работы с программными +требованиями и улучшением этих процессов. Особое значение данной темы +заключается в подчеркивании значимости работы с требованиями, ключевой роли +этих процессов для определения стоимостных и временных ресурсов, необходимых +для реализации программного проекта, в целом. + +Удовлетворение потребностей заказчика является целью любого программного +проекта. Соответственно, обеспечение адекватности реализации требований в +проекте просто невозможно представить без адекватных процессов работы с ними – +начиная со сбора требований, заканчивая проверкой соответствия получаемого +программного продукта этим требованиям на всех этапах его создания. + +Улучшение процессов и в частности процессов разработки и управления +требованиями должно предваряться формулировкой проблемы. Т.е. нет смысла +заниматься улучшением ради улучшения, нужно четко понимать какая в настоящее +время есть проблема в работе с требованиями, и насколько эта проблема значима, +и только потом приступать к ее устранению, в частности через улучшение +процессов. Реальная отечественная практика многих организаций, занимающихся +разработкой ПО, показывает, что очень немногие имеют действительно четкое +представление о том, каким образом организация работы с требованиям может +повлиять на успех компании в целом. Обычно, отечественные компании, в лучшем +случае просто документируют требования, выпуская документы, например, +Техническое задание по ГОСТ. Но действительно ли в этом документе можно увидеть +требования – увы. Следуя только рекомендациям, которые есть в ГОСТ можно только +соответствующим образом оформить разделы, что практически никак не влияет на +качество и информативность документа. Вопросы совершенствования процессов – +process improvement будут рассматриваться как в главах, посвященных CMMI, так и +в других частях этой книги. + +Данная тема тесно связана с областями знаний “Качество программного +обеспечения” (Software Quality) и “Процесс программной инженерии” (Software +Engineering Process). В этом контексте, фокусы обсуждаемой темы – определение +атрибутов и метрик качества, а также определение соответствующих процессов в +применении к программным требованиям, которые можно свести в три группы +практик: + +- Покрытие процессов работы с требованиями с точки зрения стандартов и моделей +улучшения процессов, в целом; +- Измерение и количественная оценка (benchmarking) процессов работы с +требованиями; +- Планирование и реализация процесса улучшения, как такового. + +## Извлечение требований (Requirements Elicitation) + +Данная секция освещает вопросы сбора требований как с точки зрения организации +процесса, так и определения источников, откуда поступают требования. Это первая +стадия построения видения автоматизируемой проблемной области. Идентификация +заинтересованных лиц, их взаимодействия, выполняемых ими бизнес-процессов – все +это является ключевыми вопросами, без четкого и однозначного ответа на которые +даже не стоит думать об успешности проекта (кстати, не только программного...). + +Один из ключевых принципов программной инженерии заключается в обеспечении +взаимодействия между пользователями и инженерами. Прежде, чем начинается +разработка программного обеспечения, именно специалисты “по требованиям” – +аналитики перекидывают тот самый “мостик” между заказчиками и исполнителями, +который задает тот уровень коммуникаций и взаимопонимания между ними, который +необходим для решения задач проекта. + +### Источники требований (Requirement Sources) + +Необходимо идентифицировать все возможные источники требований, значимые для +решения задач проекта. Только после этого можно определить их влияние на +проект. Данная тема касается вопросов понимания информированности источников +требований и их значимости. + +Тема фокусируется на: + +- Целях +- Знании предметной области +- Заинтересованных лицах +- Операционном окружении +- Организационной среде + +Выделение приоритетов, однозначность требований, передаваемых инженерам, связь +между требованиями и их взаимное влияние друг на друга – все это является +следствием четкого и однозначного понимания источников требований. + +### Техники извлечения требований (Elicitation Techniques) + +Идентифицировав источники требований мы не должны “покоится на лаврах”. Даже +обладая пониманием того, кто владеет необходимой информацией, мы далеко не +застрахованы от проблем, связанных с получением требований, необходимых для +дальнейшей работы. Осуществление своей профессиональной деятельности +пользователями далеко не гарантирует, к сожалению, способность ясно, четко и +однозначно сформулировать то, что они делают и что именно им необходимо для +решения их задач сегодня и завтра. Во многом, поэтому, сбор требований, +зачастую, превращается в столь тяжелый и часто порождающий конфликты процесс +действительно извлечения, “вытаскивания” информации, без которой невозможно +переходить к дальнейшим проектным работам. Недопонимание между аналитиком и +пользователем, упущение тех или иных аспектов, на первый взгляд кажущихся +второстепенными, неоднозначность или тем более некорректность интерпретации +информации, полученных от пользователей – все это наиболее типичные причины +“сверх-затрат” (времени, денег и т.п.), а иногда, и полного провала проектов. + +Существует множество практик и подходов, позволяющих добиться действительно +стройной системы требований, отвечающих реальным потребностям и приоритетам +заказчиков. Среди них можно выделить следующие: + +- Интервьюрирование – традиционный подход извлечения требований; не стоит +забывать, что получение информации от пользователя “не равно” получению +требований; информация должна быть проанализирована и трансформирована в +требования, таким образом, информация от пользователя является “входом” в +процессы сбора требований, а сами требования – “выходом” этих процессов; +- Сценарии – контекст для сбора пользовательских требований, определяющий +ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, +реализуемых пользователями; +- Прототипы – отличный инструмент для уточнения и/или детализации требований; +существуют разные подходы к прототипированию – от “бумажных” моделей до +пилотных подсистем, реализуемых как самостоятельные (в терминах управления +ресурсами) проекты или бета-версии продуктов; часто прототипы постепенно +трансформируются в результаты проекта и используются для проверки и утверждения +требований; +- “Разъясняющие встречи” - в оригинале звучит как “facilitated meetings”; +достаточно емкий по смыслу термин, пришедший из общей практики менеджмента и +базирующийся на идеях сотрудничества заинтересованных лиц для совместного +анализа путей решения проблем, определения и предупреждения рисков и т.п. В +отличие от “обычного”, с позволения сказать, “мозгового штурма”, как +исключительной формы обсуждения тех или иных задач (часто в критические моменты +работ над проектом), “запланированный мозговой штурм” – особая форма встреч +участников проекта и заинтересованных лиц со стороны заказчика, посвященная +обсуждению тех вопросов, ответы на которые не могут быть определены в +результате обычных интервью и которые требуют вовлечения большего количества +лиц, чем просто пары “пользователь-аналитик”; я позволили себе сконструировать +на русском языке этот термин еще и как “запланированный мозговой штурм”, так +как такого рода встречи действительно обычно планируются с заданной +периодичностью для обеспечения однозначности интерпретации информации, значимой +для проекта и, что очень важно – проведения таких встреч до того, как связанные +с данными вопросами риски не превратились в реальные проблемы, требующие +решения “вчера”, а, следовательно, и дополнительных (изначально +незапланированных) ресурсов времени, денег и т.д.; +- Наблюдение (observation) – подразумевает непосредственное присутствие +аналитиков и инженеров рядом с пользователем в процессе выполнения последним +его работ по обеспечению функционирования бизнес-процессов: в определенной +степени можно провести аналогию с практикой присутствия представителя заказчика +в проектной группе исполнителя ( типовая практика в eXtreme Programming +“on-site customer” – “присутствующий заказчик”); данная техника является +достаточно затратной, но, в то же время, очень эффективной, а иногда – просто +незаменимой, особенно, если речь идет о достаточно сложных и взаимосвязанных +бизнес-процессах; + +Существуют и другие, достаточно эффективные практики, описание которых можно +найти в литературе и которые вы, наверняка, сами используете в своей работе +(например, Requirements Workshop, Role Playing, Storyboarding и т.п.). +Некоторые из них будут также упоминаться в контексте конкретных методологий. + +## Анализ требований (Requirements Analysis) + +Эта секция посвящена процессам анализа требований, то есть трансформации +информации, полученной от пользователей (и других заинтересованных лиц) в четко +и однозначно определенные требования, передаваемые инженерам для реализации в +программном коде. + +Анализ требований включает: + +- Обнаружение и разрешение конфликтов между требованиями; +- Определение границ задачи, решаемой создаваемым программным обеспечением; в +общем случае - определение “scope” (или “bounds”), границ и содержания +программного проекта; +- Детализация системных требований для установления программных требований; + +Практически всегда, хотя это явно и не отмечено в описании анализа требований +как секции SWEBOK, на практике выделяется и детализация бизнес-требований для +установления программных требований. Например, пресловутый режим работы 24x7, +сформулированный в виде бизнес-требования, накладывает достаточно жесткие рамки +на выбор технологической платформы и архитектурных решений как технических +требований к разрабатываемой программной системе. + +- SWEBOK отмечает, что традиционный взгляд на анализ требований часто +сфокусирован или уменьшен до вопросов концептуального моделирования с +использованием соответствующих аналитических методов, одним из которых является +SADT – Structured Analysis and Design Technique (методология структурного +анализа и техники проектирования), знакомый многим по нотациям IDEF0 +(функциональное моделирование – стандарт IEEE 1320.1), IDEF1X (информационное +моделирование – стандарт IEEE 1320.2, известный также как IDEFObject), часто +применяемым как для моделирования бизнес-процессов, так и структур данных, в +частности – реляционных баз данных. + +Так или иначе, вне зависимости от выразительных средств, которые являются лишь +инструментом анализа и фиксирования результатов, результатом анализа требований +должны быть однозначно интерпретируемые требований, реализация которых +проверяема, а стоимость и ресурсы – предсказуемы. + +### Классификация требований (Requirements Classification) + +Требования могут классифицироваться по целому ряду параметров, например: + +- Функциональные и нефункциональные требования +- Внутренние (с другими требованиями) или внешние зависимости +- Требования к процессу или продукту +- Приоритет требований +- Содержание требований в отношении конкретных подсистем создаваемого программного обеспечения +- Изменяемость/стабильность требований + +Другие варианты классификации могут, и часто базируются, на принятых в +организации подходах, применяемых методологиях, методах и практиках, а, +зачастую, и специфике проектов и даже требованиях заказчиков к процессу +разработки и, в частности, определения требований и форме представления +результатов их анализа. + +### Концептуальное моделирование (Conceptual Modeling) + +Разработка модели проблемы реального мира – ключевой элемент анализа +требований. Цель моделирования – понимание проблемы, задачи и методов их +решения до того, как начнется решение проблемы. + +Часто приходится слышать, что прагматичность подхода в отношении программных +проектов заключается в “пропуске” этапа (или стадии, фазы) моделирования. В +свою очередь, часто ставят знак равенства между моделированием и “этими +красивыми квадратиками со стрелочками”. Ни то, ни другое утверждение неверны. +Например, в XP и в других гибких (Agile) практиках существуют и истории +пользователей, и карточки задач, и процедуры анализа (в частности, связанных с +ними “мозговых штурмов”, как запланированных, так и, к сожалению, не очень) , в +результате которого мы сформулировали задачи, высокоуровневые возможности - +“фичи” продукта (feature - особенность), а также необходимые модели (см. +[Амблер, 2002]). Объем моделей, их детализация и средства представления могут +быть различны. Их выбор базируется и/или диктуется конкретным культурным +контекстом организаций, вовлеченных в проект, и практик, применяемых проектной +группой. Именно не форма, но сама идея моделирования как попытка упростить и +однозначно интерпретировать на концептуальном уровне проблематику деятельности +в реальном мире – обязательная составляющая как управления требованиями, так и +программной инженерии, в целом. + +Среди факторов, которые влияют на выбор модели, метода и детализации ее +представления, степени связанности с программным кодом и другими вопросами: + +- Природа проблемы (проблемной области) +- Экспертиза и опыт инженеров +- Требования заказчика к процессу +- Доступность методов и инструментов +- Внутрикорпоративные стандарты и регламенты +- Культура разработки + +В любом случае, моделирование рассматривается в программном контексте, а не +только с точки зрения бизнес-задач как таковых, Это обусловлено необходимостью +понимания операционного и системного контекста, то есть окружения, в котором +программная система будет реально использоваться и которое накладывает свои, +иногда достаточно жесткие ограничения. + +Вопросы моделирования тесно связаны с применяемыми методами и подходами. +Однако, частные методы или нотации, как отмечается в SWEBOK, так или иначе +следуют распространенным в индустрии практикам и тяготеют к тем формам, с +которыми связаны накопленный опыт и подтвержденные общепринятой практикой +знания. SWEBOK отмечает, что могут быть разработаны различные виды моделей, +включающие потоки работ и данных, модели состояний, трассировки событий, +взаимодействия пользователей, объектные модели, модели структур данных, и т.п. +Кстати, именно такая ситуация сложилась с UML, все чаще воcпринимаемым в +качестве общепринятого или de-facto стандарта в моделировании и включающем +целый комплекс моделей (в UML 2.0 включено 14 моделей, представленные в двух +группах – статические модели и поведенческие), связанных и объединенных общей +архитектурой, на основе концепции метамоделей. + +Cовременное состояние стандарта UML (унифицированного языка моделирования +Unified Modeling Language, разрабатываемого консорциумом OMG – www.omg.org ) +версии 2.0 вполне позволяет говорить о расширении его применимости в “чистом” +бизнес-моделировании. На фоне богатства выразительных средств, появления +соответствующего инструментального обеспечения работы с UML 2.0, длительной +истории успешного применения стандарта UML 1.x, инструментов на его основе и +повсеместного использования UML в области объектно-ориентированного анализа и +проектирования не только аналитиками, но архитекторами и разработчиками ПО, +можно с уверенностью говорить о смещении фокуса индустрии программного +обеспечения в сторону UML и отходу (как минимум, частичному) от IDEF, в +применении к аналитической деятельности. Темпы такой “миграции”, конечно, +зависят от степени консервативности взглядов конкретных +специалистов-аналитиков. Однако, давление рынка, требование унификации, в +частности, выразительных средств описания активов проектов в рамках всей +проектной команды – те причины, по которым, по мнению автора, аналитики, не +воспринявшие UML-ориентированный тренд, могут оказаться за бортом серьезных +корпоративных ИТ-проектов. Даже на фоне “неприятия” UML некоторыми игроками +рынка, критическая масса знаний и практик по его применению уже оказалась +достаточно велика, чтобы игнорировать его применение. В то же самое время, не +стоит воспринимать UML как панацею – это касается любой технологии, практики +или подхода. Создан, активно развивается и уже поддержан индустрией стандарт +BPMN – Business Process Management Notation (см. www.bpmi.org). Таким образом, +все определяется конкретным “культурным” контекстом. Просто надо помнить об +этом и оставаться “прагматиками”, в положительном понимании этого слова, не +теряя креативности в повседневной деятельности. + +Необходимо отметить, что на практике наблюдается тенденция разделения вопросов +определения требований и моделирования. Это, например, заметно в современных +методологиях, таких как RUP (Rational Unified Process), где работа с +требованиями и моделирование/проектирование – суть две разные дисциплины. + +### Архитектурное проектирование и распределение требований (Architectural Design and Requirements Allocation) + +Считается, что создание архитектуры программных решений является обязательным +элементов успешности таких проектов. Архитектурное проектирование перекрывается +с программным и системным дизайном (проектированием) и иллюстрирует насколько +сложно провести четкую грань между различными аспектами проектирования. Данная +тема работы с программными требованиями тесно связана с секцией “Структура и +архитектура программного обеспечения” (Software Structure and Architecture) +области знаний “Проектирование программного обеспечения” (Software Design). Во +многих случаях, инженеры действуют как архитекторы, потому как процессы анализа +и выработки требований зависят от программных компонент, создаваемых для +решения поставленных заданными требованиями задач, призванных, в конечном +счете, добиться реализации поставленных перед проектом целей. + +Архитектурное проектирование очень близко к концептуальному моделированию. +Непосредственное отображение бизнес-сущностей реального мира на программные +компоненты не является обязательным. Во многом поэтому и существует такое +разделение между моделированием и проектированием. В принципе, можно говорить о +том, что деятельность по моделированию в большей степени касается того, ”что” +надо сделать, а архитектура - “как” это будет реализовано. + +Существует ряд стандартов и общепринятых практик, связанных с архитектурным +проектированием. Среди них наиболее популярны: + +- Стандарт IEEE 1471-2000 “Recommended Practice for Architectural Description +of Software Intensive Systems” +- Модель Захмана – Zachman Framework (www.zifa.com) +- TOGAF – The Open Group Architecture Framework (www.opengroup.org/architecture/) + +Важно заметить, что ни в коем случае не надо путать архитектурные рекомендации +(Architectural Guidelines) с практиками и стандартами архитектурного +проектирования. Одни (например, Federal Enterprise Architecture Framework FEAF) +дают рекомендации по конкретным архитектурно-технологическим решениям. Другие +концентрируются именно на том, чему стоит уделить внимание при создании +архитектуры, как ее описать и детализировать, и что из себя представляет +архитектура, как таковая (например, ISO 15704 Industrial Automation Systems – +Requirements for Enterprise-Reference Architectures and Methodologies). + +## Спецификация требований (Requirements Specification) + +На инженерном жаргоне, да и в терминологии ряда методологий, устоялся термин +“software requirements specification” (SRS) – спецификация программных +требований. Для сложных систем, на самом деле, существует целый комплекс +спецификаций, документов, которые являются результатом сбора и анализа +требований, их моделирования и архитектурного проектирования. Эти документы +систематически анализируются, в них вносятся изменения, они пересматриваются и +утверждаются. Чаще всего, для описания комплексных проектов (в части +требований) используется три основных документа (спецификации): + +- Определение системы (system definition) +- Системные требования (system requirements) +- Программные требования (software requirements) + +### Определение системы (System Definition Document) + +Данный документ, часто называемый как “спецификация пользовательских +требований” (user requirements specification) или “концепция” (concept ), описывает системные требования. Содержание документа определяет +высокоуровневые требования, часто – стратегические цели, для достижения которых +создается программная система. Принципиальным моментом является то, что такой +документ описывает требования к системе с точки зрения области применения - +“домена”. Соответственно, изложение требований в нем ведется в терминах +прикладной области. Документ описывает системные требования вместе с +необходимой информацией о бизнес-процессах, операционном окружении с точки +зрения бизнес-процедур и организационных и других регламентов. Примером +стандарта для создания и структурирования такого документа является IEEE 1362 +“Concept of Operations Document”. + +### Спецификация системных требований (System Requirements Specification) + +В сложных проектах принято разделять спецификацию системных требований (system +requirements) и спецификацию программных требований (software requirements). +При таком подходе программные требования порождаются системными требованиями и +детализируют требования к компонентам и подсистемам программного обеспечения. +Документ описывает программную систему в контексте системной инженерии (system +engineering), идеи которой кратко описаны в Главе 12 SWEBOK “Связанные +дисциплины программной инженерии”. Строго говоря, спецификация системных +требований описывает деятельность системных инженеров и выходит за рамки +обсуждения SWEBOK. Стандарт IEEE 1233 является одним из признанных руководств +по разработке системных требований. И, как уже отмечалось ранее, не стоит +забывать о том, что понятие система, в общем случае, охватывает программное +обеспечение, аппаратную часть и людей. Системная инженерия (см. материалы +INCOSE – www.incose.org ), в свою очередь, самостоятельная и не менее объемная +дисциплина чем программная инженерия. SWEBOK рассматривает системную инженерию +как важную связанную дисциплину. Ну а системные требования – один из элементов +реального связывания различной инженерной деятельности - программной и +системной. + +### Спецификация программных требований (Software Requirements Specification - SRS) + +Часто эту спецификацию называют “требованиями к программному обеспечению”. Все +же, учитывая существование дисциплин системной и программной инженерии, мы +используем термин “программные требования”, как более точно подходящий по +смыслу по моему мнению. + +Программные требования устанавливают основные соглашения между пользователями +(заказчиками) и разработчиками (исполнителями) в отношении того, что будет +делать система и чего от нее не стоит ожидать. Документ может включать +процедуры проверки получаемого программного обеспечения на соответствие +предъявляемым ему требованиям (вплоть до содержания планов тестирования), +характеристики, определяющие качество и методы его оценки, вопросы безопасности +и многое другое. Часто программные требования описываются на обычном языке. В +то же время, существуют полуформальные и формальные методы и подходы, +используемые для спецификации программных требований. В любом случае, задача +состоит в том, чтобы программные требования были ясны, связи между ними +прозрачны, а содержание данной спецификации не допускало разночтений и +интерпретаций, способных привести к созданию программного продукта, не +отвечающего потребностям заинтересованных лиц. Стандарт IEEE 830 является +классическим примером стандарта на содержание структурирование и методы +описания программных требований – “Recommended Practice for Software +Requirements Specifications”. + +Необходимо отметить, что в документацию на требования не следует вносить +элементы дизайна системы (скажем, логическую модель базы данных). А вот +сценарии использования Use Case часто включают в спецификацию требований +наравне с трассировкой (traces) к соответствующим моделям в форме диаграмм, +например, к UML Use Case, UML Activity, BPMN и т.п. . Говоря о написании +спецификаций требований, то есть одно серьезное заблуждение, которое делают +обычно неопытные аналитики – это фактическая подмена требований как таковых, +моделями графического пользовательского интерфейса, т.е. когда в +документы-спецификации требований просто включаются «картинки» +пользовательского интерфейса с небольшими пояснениям. Это отнюдь не означает, +что с заинтересованными лицами и в частности с пользователями, не следует +вообще обсуждать дизайн GUI, часто это имеет смысл делать, но для этого +существует, например, прототипирование. Мне довелось изучить многие документы +требований в разных организациях и практически все они имели одни и те же +проблемы: + +- Терминологическая неопределенность. Часто используются термины, которые +обладают многозначностью, и такие термины не определены в глоссариях, чтобы +можно было четко понять, что конкретно автор имеет в виду в данном случае (это +не всегда бывает понятно из контекста). Как пример можно привести собственно +использование (и, что немаловажно, понимания!) термина «требования». Под этим +ёмким термином можно понимать как требования к бизнес процессам, так и +функциональные или нефункциональные требования к ПО вообще. Интересно, что на +уровне многих стандартов (к сожалению, в основном, англоязычных) прописано +использование тех или иных глаголов, форм и структурирование предложений, +описывающих требования – например использование глаголов (will, shall, should, +may, can – перечислены в порядке “убывания директивности”). Действительно, +“программный модуль X отсылает уведомление на e-mail адрес пользователя...” +несет, мягко говоря, иную смысловую нагрузку, чем “отсылается сообщение”. +- Отсутствие представления о классификации требований. Подмена одних категорий +требований – другими и смешение требований (например, такое часто случается с +функциональными требованиями, бизнес-требованиями и бизнес-правилами). Как +результат – создаваемые документы тяжело читать и извлекать полезную для +разработки ПО информацию. Зачастую в одном абзаце, можно встретить перемешанные +как описания необходимой функциональности и тут же элементы предполагаемого +пользовательского интерфейса, который должен воплотить разработчик. Или +проектные решения, например, использование таблиц баз данных или полей. И +помимо этого, содержится несистематизированная и фрагментарная информация о +бизнес-процессах организации. Все это скрывает истинные требования к +разрабатываемому ПО, что в свою очередь затрудняет как разработку, так и +согласование требований. Корректная и однозначная интерпретация требований и +анализ влияний становятся практически неосуществимыми, что напрямую сказывается +на адекватности удовлетворения потребностей заказчика/пользователей. +- Фокусировка на деталях пользовательского интерфейса. В документах встречается +акцентирование не на необходимой функциональности, а на деталях +пользовательского интерфейса. +- Излишнее акцентирование внимания на деталях реализации. Попытка отразить в +документе с требованиями к создаваемому ПО не ЧТО должна делать система, а то +КАК она это будет делать. Это одна из ключевых проблем. Во многом, поэтому, +часто выделяют внутренние технические требования к системе, которые не проходят +аттестации со стороны пользователей и разрабатываются не аналитиками, а +архитектором и ведущими разработчиками уже на этапе проектирования – software +design (см. следующую область знаний SWEBOK). +- Слабая формализация бизнес-процессов. В документах перемешивается описание +бизнеса и требования к ПО, что приводит сложностям в понимании сути и общему +пониманию как должна быть спроектирована система. + +## Проверка требований (Requirements Validation) + +Определение требований напрямую связано с процедурами проверки (verification) и +утверждения (аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC +12207). Вообще говоря, принято считать, что требования описаны неполностью, +если для них не заданы правила V&V (verification&validation – проверка и +аттестация), то есть не определены способы проверки и утверждения. Процедуры +проверки являются отправной точкой для инженеров-тестировщиков и специалистов +по качеству, непосредственно отвечающих за соответствие получаемого +программного продукта предъявляемым к нему требованиям. + +К сожалению, как уже комментировалось выше, часто, в крупных организациях +вместо полноценной проверки сути и содержания документов, все сводиться к так +называемому "нормоконтролю" -- когда проверка документов требований заключается +в проверке на соблюдение принятых стандартов внешнего оформления документа +(отступы и размеры поля, подписи таблиц/рисунков и т.п.), но никак ни оценки +качества требований. И совершенно неверно считать такой "нормоконтроль" +полноценной проверкой требований. + +Если стандарты жизненного цикла описывают как правильно создавать продукт, то +стандарты (в том числе, внутрикорпоративные) отвечают за создание правильного +продукта, то есть того продукта, который соответствует ожиданиям пользователей +и других заинтересованных лиц. + +Для достижения этой цели применяется ряд практик, в том числе, представленных +ниже. + +### Обзор требований (Requirements Review) + +Один из распространенных методов проверки требований - инспекция или обзор +требований. Суть его заключается в том, что ряд лиц, вовлеченных в проект (для +крупных проектов – специально выделенные специалисты), “вычитывают” требования +в поисках необоснованных предположений, описаний требований, допускающих +множественные интерпретации, противоречий, несогласованности, недостаточной +степени детализации, отклонений от принятых стандартов и т.п. + +Вопросы обзора требований, вообще говоря, имеют непосредственное отношение к +теме качества, поэтому они также описываются в области знаний SWEBOK “Качество +программного обеспечения” (Software Quality) в теме 2.3 “Обзор и аудит” (Review +and Audit). + +### Прототипирование (Prototyping) + +В общем случае, прототипирование подразумевает проверку инженерной +интерпретации программных требований и извлечение новых требований, +неопределенных или неясных на ранних итерациях сбора требований. Существует +множество подходов к прототипированию, как с точки зрения детализации, так и +того, чему уделяется внимание при прототипировании. Наиболее часто прототипы +создаются для оценки способа реализации пользовательского интерфейса и проверки +архитектурных подходов и решений. + +При всей безусловной полезности прототипирования для обеспечения проверки +требований и решений, необходимо понимать, что с прототипированием связан ряд +вопросов способных привести к негативным последствиям или, как минимум, +работам, требующим дополнительного времени и средств. Среди возможных +негативных последствий прототипирования стоит выделить следующие: + +- Смещение внимания с целевых функций прототипа и, как следствие, +неудовлетворенность пользователей огрехами прототипа, отсутствием стоящей за +ним реальной функциональности (для прототипов пользовательского интерфейса), +ошибками в прототипе и т.п. +- Превращение прототипа в реальную систему за счет постоянного добавления новых +свойств и функциональности “для проверки” – часто бывает нарушена архитектурная +целостность, необеспечена необходимая масштабируемость и качество получаемого +программного продукта; + +Здесь хотелость бы добавить и еще одну типичную проблему - переключение +внимания заинтересованных лиц на эргономику и детали дизайна графического +пользовательского интерфейса, при начальной цели построения прототипа для +выявления функциональных и иных требований и наоборот. Проблема не во внимании +пользовательскому интерфейсу, проблема в подмене, если так можно выразиться, +функциональной составляющей пользовательским интерфейсом (вспомните, как часто +вы сами говорили или слышали – “я не о ‘кнопочках’ и ‘окошках’, я о задаче +...”). + +Конечно, ясно, что эти факторы можно превратить и в положительные стороны +прототипа. Кроме того, не стоит считать что прототип это всегда нечто, +воплощенное в код. Прототипом пользовательского интерфейса может быть, +например, просто “прорисованный” на бумаге или в электронной форме набор +переходов между экранами/диалоговыми окнами системы (кстати, это подход, часто +используемый в Agile-практиках, но отнюдь не заменяющий требований к системе). + +Так или иначе, выбор того или иного метода прототипирования, да и самого факта +такого способа проверки требований или технологических идей, должен +основываться на временных и других имеющихся ресурсах, опыте в прототипировании +и, конечно, степени сложности создаваемой программной системы. + +### Утверждение модели (Model Validation) + +Утверждение или аттестация модели связана с вопросами обеспечения приемлемого +качества продукта. Уверенность в соответствии модели заданным требованиям может +быть закреплена формально со стороны пользователей/заказчика. В то же время, +проверка и аттестация модели, например, объектно-ориентированного представления +бизнес-сущностей и связей между ними может быть проверена с той или иной +степенью использования формальных методов, например, статического анализа +(поиск связей и путей взаимодействия между описанными объектами и выделение +различного рода несоответствий). Это – другая сторона утверждения модели. + +### Приемочные тесты (Acceptance Tests) + +Требования должны быть верифицируемы. Требования, которые не могут быть +проверены и аттестованы (утверждены) – это всего лишь “пожелания”. Именно так +они буду восприниматься разработчиками, даже в случае их высокой значимости для +пользователей. Если описанное требование не сопровождается процедурами проверки +– в большинстве случаев говорят о недостаточной детализации или неполном +описании требования и, соответственно, спецификация требований должна быть +отправлена на доработку и если необходимо, должны быть предприняты +дополнительные усилия, направленные на сбор требований. + +Можно говорить о том, что процедура анализа требований считается выполненной +только тогда, когда все требования, включенные в спецификацию, обладают +методами оценки соответствия им создаваемого программного продукта. Чаще всего +столь строгое ограничение на степень законченности спецификации накладывается +на функциональные требования и атрибуты качества (например, время отклика +системы). + +Идентификация и разработка приемочных тестов для нефункциональных требований +часто оказывается наиболее трудоемкой задачей. Для ее решения обычно “ищут +точку опоры”, то есть возможность взгляда на описываемые требования с +количественной точки зрения, в плоть до переформулирования и большей степени +детализации описания таких требований. + +Дополнительная информация, связанная с приемочными тестами представлена в +области знаний SWEBOK “Тестирование программного обеспечения” (Software +Testing) в описании 2.2.4 “Тесты соответствия” (Conformance testing). + +## Практические соображения (Practical Considerations) + +Первый уровень декомпозиции секций данной области знаний напоминает описание +последовательности действий. Это, безусловно, упрощенный взгляд на процесс +работы с требованиями. Данный процесс, точнее, комплекс процессов, охватывает +весь жизненный цикл программного обеспечения. Управление изменениями и +сопровождение, поддержка актуальности требований и их реализации – ключ к +успешным процессам программной инженерии. + +Далеко не каждая организация обладает культурой документирования и управления +требованиями. Особенно часто это встречается в молодых небольших компаниях, +выводящих на рынок новые продукты и обладающие “сильным вижином”, четким +пониманием целей, для которых создается продукт, но не имеющих достаточно +ресурсов и, во многом поэтому считающих, что динамизм – залог успеха. +Постепенно такие компании вырастают, проекты – усложняются и, как следствие +складывается ситуация, когда отследить все необходимые требования в +неформальной форме уже просто невозможно. Эта тема практически неисчерпаема. +Многие средние по масштабам компании пытаются сохранить тот же вровень гибкости +и динамизма, который применялся во времена рождения компании, когда она еще +была “стартапом” (start-up – название молодых компаний, которые раскручивали +свои проекты во времена интернет-бума конца 90-х и которое прижилось для вновь +образующихся малых бизнесов, растущих не столько на внешних инвестициях, +сколько на идеях и упорстве ее создателей). Так или иначе, динамизм присущ не +только компаниям, но и продуктам, самим требованиям к ним. Управление +изменениями, концепцией, видением продукта не может быть хаотическим – история +индустрии однозначно это показывает. Поэтому отношение к управлению +требованиями как к постоянно действующему бизнес-процессу – абсолютно +обоснованный подход, требующий применения определенных практик. В противном +случае, мы практически гарантировано столкнемся с теми негативными +последствиями, которые не раз описывались и упоминались выше. + +### Итеративная природа процесса работы с требованиями (Iterative Nature of the Requirements Process) + +В большинстве случаев, понимание и интерпретация требований продолжает +эволюционировать в процессе проектирования и разработки программного +обеспечения. Кроме того, требования часто меняются в силу изменений +бизнес-контекста для которого создается и в котором эксплуатируется программное +обеспечение. Необходимо понимать неизбежность изменений и планировать шаги по +уменьшению проблем, связанных с изменениями. В то же самое время, современные +практики гибкой разработки говорят о том, что необходимо концентрироваться +только на том, что требует внимания “прямо сейчас”, не закладываясь на +предупреждение всех возможных рисков, в том числе связанных с изменениями, +включая изменения требований. Говорить о том, какой подход – предупреждение или +реагирование является гарантировано приводит к успеху – сложно сказать. Более +того, если кто-то однозначно настаивает только на одной из идей и полностью +отвергает другую – это профанация. Восприятие изменений и возможность их +своевременной обработки - вопрос способности проектной команды работать в +условиях постоянно меняющихся условий, принимаемых архитектурных решений и +многих других культурных, технологических и организационных факторов. Так или +иначе, понимание меняющейся природы требований – один из факторов адекватного +реагирования на сами изменения, а, следовательно, и возможности успешного +завершения проекта. + +### Управление изменениями (Change Management) + +Управление изменениями – одна из ключевых тем управления требованиями. +Необходимость определения процедур для обработки изменений совсем не то же +самое, что и их детальная формализация. Такие процедуры необходимы. Им +посвящена тема управления изменениями в приложении к требованиям. В то же +время, рассматривать изменение требований в отрыве от других процессов, по +меньшей мере, кажется странным. Соответственно, данный вопрос является +составной частью управления изменениями и конфигурациями программного +обеспечения (Software Configuration and Change Management, SCCM), которое +сегодня принято называть просто конфигурационным управлением (Software +Configuration Management, SCM), подразумевая, что это не только вопросы +контроля версий, но управление всеми активами проекта, включая код, требования, +запросы на изменения – change requests (в том числе, отчеты об ошибках – defect +или bug reports), задачи (в терминах проектного менеджмента) и т.п. + +Общий комплекс вопросов конфигурационного управления рассматривается в области +знаний SWEBOK “Управление конфигурациями программного обеспечения” (Software +Configuration Management). + +### Атрибуты требований (Requirements Attributes) + +Требования должны состоять не только из описания того, что необходимо сделать, +но и содержать информацию, необходимую для интерпретации требований и +управления ими. Например, с пользовательскими требованиями часто ассоциируют +сценарии Use Case (как в текстовом, так и графическом представлении) и, в то же +время, функциональные требования часто трансформируются в задачи в терминах +проектного управления, с которыми связаны параметры законченности (например, в +процентах), ответственности (например, кто является “владельцем” требования, +кто из инженеров назначается исполнителем или принимает на себя обязанности, +связанные с реализацией заданной функциональности, как это принято, например, в +XP или FDD). Примеров существует множество и, в зависимости от применяемых +практик и методов, сложившейся проектной и организационной культуры, спектр +атрибутов может меняться достаточно широко, практически, неограниченно. + +Необходимо также помнить, что к обсуждаемым атрибутам также относятся +параметры, связанные с классификацией требований (см. выше тему 4.1 +“Классификация требований”). В свою очередь, принадлежность к тому или иному +классу (категории, типу, виду) требований означает не только семантику того, +“чему посвящены” требования (функциональности, параметрам качества и т.п.), но +и комплекс атрибутов, общий для всех требований данного класса. + +В какой-то степени можно провести параллель между требованиями и записями +(строками) в реляционной базе данных, где каждая запись обладает набором +атрибутов (столбцов). В определенном смысле, можно и необходимо говорить о том +или ином уровне атомарности требований (что не исключает связей между +требованиями), представляемой такой метафорой. + +### Трассировка требований (Requirements Tracing) + +Трассировка требований обеспечивает связь между требованиями и отслеживание +источников требований. Трассировка является фундаментальной основой проведения +анализа влияния (impact analysis) при изменении требований, помогая +предсказывать эффект от внесения таких изменений. Трассировка предполагает +направленную связь (представляется в виде сложного направленного ациклического +графа) между требованиями, то есть зависимости. + +Требования (B) обладают обратной зависимостью (то есть вторичны) по отношению к +требованиям (A) и заинтересованным лицам, которые являются источником либо +образуют причину появления рассматриваемых требований (B). И, наоборот, +требования (A) трассируются напрямую к тем требованиям (B) и элементам дизайна +(например, модели или, в общем случае, кода, запросов на изменения и т.п.), +которые порождаются или удовлетворяют требованиям (A). + +### Измерение требований (Measuring Requirements) + +С практической точки зрения, обычно полезно иметь нечто, позволяющее определить +“объем” требований для заданного (создаваемого) программного продукта. Это +число полезно для исследования “масштабов” изменений в требованиях, оценки +стоимостных характеристик (cost estimation) разработки и поддержки программной +системы, опосредовано – оценки продуктивности разработки и эффективности +поддержки на этапах реализации требований и внесения изменений и т.п. + +Измерение объема функциональности (Functional Size Measurement, FSM) техника +такого рода численной оценки, определена на концептуальном уровне в стандарте +IEEE 14143.1. Стандарты ISO/IEC и другие источники описывают частные методы FSM +(например, модель COCOMO II для оценки стоимости, например, может +использоваться в тесной связи с методами функциональных точек – functional +points для оценки масштабов функциональности, то есть требований, предъявляемых +заданной программной системе). + +Дополнительная информация по стандартам и подходам в оценке масштабов +представлена в области знаний “Процесс программной инженерии” (Software +Engineering Process). + +В дополнение к практическим соображениям, представленным в SWEBOK, на фоне +общей тенденции разработки моделей <оценки> зрелости, стоит отметить, что +существуют определенные работы и по созданию различных моделей зрелости +требований. Например, наиболее популярная модель зрелости в индустрии +программного обеспечения – CMMI включает разный объем и содержание работ по +определению и управлению требованиями для уровней зрелости 2 и 3. blob - 106abb9f63ec35345bed7fdc99c8118bb5ab3441 (mode 644) blob + /dev/null --- 2_software_design.markdown +++ /dev/null @@ -1,634 +0,0 @@ -# Проектирование программного обеспечения - -Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK. - -Содержит перевод описания области знаний SWEBOK “Software Design”, с замечаниями и комментариями. - -Процесс определения архитектуры, компонентов, интерфейсов и других -характеристик системы или ее компонентов называется *проектированием*. -Результат процесса проектирования – *дизайн*. Рассматриваемое как процесс, -проектирование есть инженерная деятельность в рамках жизненного цикла (в данном -контексте – программного обеспечения), в которой надлежащим образом -анализируются требования для создания описания внутренней структуры ПО, -являющейся основой для конструирования программного обеспечения как такового. -Программный дизайн (как результат деятельности по проектированию) должен -описывать архитектуру программного обеспечения, то есть представлять -декомпозицию программной системы в виде организованной структуры компонент и -интерфейсов между компонентами. Важнейшей характеристикой готовности дизайна -является тот уровень детализации компонентов, который позволяет заняться их -конструированием. Термины дизайн и архитектура могут использоваться -взаимозаменяемым образом, но чаще говорят о дизайне как о целостном взгляде на -архитектуру системы. - -Проектирование играет важную роль в процессах жизненного цикла создания -программного обеспечения (Software Development Life Cycle), например, IEEE и -ISO/IEC (ГОСТ Р ИСО.МЭК) 12207. Проектирование программных систем можно -рассматривать как деятельность, результат которой состоит из двух составных -частей: - -- Архитектурный или высокоуровневый дизайн (software architectural design, -top-level design) – описание высокоуровневой структуры и организации -компонентов системы; -- Детализированная архитектура (software detailed design) – описывающая каждый -компонент в том объеме, который необходим для конструирования. - -В результате консенсуса, принятого создателями SWEBOK, данная область знаний не -описывает все сущности или понятия, имеющие в своем названии слово “дизайн” или -“архитектура”. В 1999 году Том ДеМарко (Tom DeMarco) [DeMarco, 1999], один из -известных специалистов в программной инженерии, предложил терминологическое -разделение различных видов дизайна: - -- *D-дизайн (D-design, decomposition design)* – декомпозиция структуры программного обеспечения в виде набора фрагментов или компонент; -- *FP-дизайн (FP-design, family pattern design)* – семейство архитектурных представлений, базирующихся на шаблонах; -- *I-дизайн (I-design, invention)* – создание высоко-уровневой концепции, видения того, что из себя будет представлять программная система; данный вид дизайна является результатом процесса анализа требований и их трансформации в подходы к реализации. - -Если обсуждать данную область знаний в терминах ДеМарко, проектирование -программного обеспечения в понимании программной инженерии подразумевает D- и -FP-дизайн. I-дизайн в большей степени относится к работе с программными -требованиями. - -Соответственно, данная область знаний тесно связана со следующими областями -программной инженерии: - -- Software Requirements -- Software Construction -- Software Maintenance -- Software Engineering Management -- Software Quality - -Сама же область знаний по проектированию программного обеспечения представлена -в виде 6 секций, структурированных по темам. - -![Рисунок 3. Область знаний “Проектирование программного обеспечения” [SWEBOK, 2004, с.3-2, рис. 1]](images/design_area_small.jpg) - -## Основы проектирования (Software Design Fundamentals) - -Эта секция вводит концепции, понятия и терминологию в качестве основы для -понимания роли и содержания проектирования (как деятельности) и дизайна -(архитектуры, как результата) программного обеспечения. - -Темы данной секции: - -### Общие концепции проектирования (General Design Concepts) - -К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, -используемые представления и решения. -Например, архитектурный фреймворк – TOGAF [TOGAF, 2003], разработанный и -развиваемый консорциумом The Open Group (www.opengroup.org), предлагает -следующие <возможные> цели (goals): - -- Улучшение и повышение продуктивности бизнес-процессов -- Уменьшение затрат -- Улучшение операционной бизнес-деятельности -- Повышение эффективности управления -- Уменьшение рисков -- Повышение эффективности ИТ-организации -- Повышение продуктивности работы пользователей -- Повышение интероперабельности (возможности и прозрачности взаимодействия) -- Уменьшение стоимости <поддержки> жизненного цикла -- Улучшение характеристик безопасности -- Повышение управляемости - -### Контекст проектирования (Context of Software Design) - -Для понимания роли проектирования программного обеспечения важно понимать -контекст, в котором осуществляется проектирование и используются его -результаты. В качестве такого контекста выступает жизненный цикл программной -инженерии, а проектирование напрямую связано с результатами анализа требований, -конструированием программных систем и их тестированием. Стандарты жизненного -цикла, например, IEEE и ISO/IEC (ГОСТ Р) 12207 уделяют специальное внимание -вопросам проектирования и детализируют их, описывая контекст проектирования – -от требований до тестов. - -### Процесс проектирования (Software Design Process) - -Проектирование в основном рассматривается как двух-шаговый процесс: - -#### Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент; - -#### Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент. - -Выходом этого процесса является набор моделей и артефактов, содержащих -результаты решений, принятых по способам реализации требований в программном -коде. - -### Техники применения (Enabling Techniques) - -Принципы проектирования, также называемые техниками применения, являются -ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в -различных методах и подходах к проектированию программного обеспечения. - -##### Абстракция (Abstraction) - -В контексте проектирования программных систем существует два механизма -абстракции – параметризация и специфицирование (может интерпретироваться как -детализация). При этом, абстракция через специфицирование бывает трех видов: -процедурная абстракция (динамическая, то есть в отношении поведения), -абстракция данных (статическая, то есть в отношении информации) и абстракция -контроля (то есть управления системой и обрабатываемой ею информацией). - -Обычно под абстракций, как результатом процесса абстракции, понимают модель, -упрощающую поставленную проблему до рамок, значимых для заданного контекста. - -#### Связанность и соединение (Coupling and Cohesion) - -*Связанность (Coupling)* – определяет силу связи (часто, взаимного влияния) -между модулями. Соединение (Cohesion) – определяет как тот или иной элемент -обеспечивает связь внутри модуля, внутреннюю связь. - -Значение оригинальных терминов очень близко и, в зависимости от контекста, -“связанность” и “соединение” могут рассматриваться как степень -самодостаточности или ее отсутствия (coupling) и функциональная зависимость -(cohesion) , соответственно. - -Хочется особенно подчеркнуть значимость этих понятий, так как с развитием -сервисно-ориентированной архитектуры (Service-Oriented Architecture, SOA), -слабосвязанной по своей природе (то есть со слабым “сопряжением”, слабой “силой -связи” между модулями), по сравнению, например, с OMG CORBA (Common Object -Request Broker Architecture), все чаще приходится сравнивать различные подходы -и решения, определяемые способом и степенью связанности различных модулей, -компонент и самих программных систем. - -#### Декомпозиция и разбиение на модули (Decomposition and Modularization) - -Декомпозиция и разбиение на модули сложных программных систем производится с -целью получения более мелких и относительно независимых программных -компонентов, каждый из которых несет различную функциональность (логически -связанные группы функциональности). - -#### Инкапсуляция/сокрытие информации (Encapsulation/information hiding) - -Данная концепция предполагает группировку и упаковку (с точки зрения подготовки -к развертыванию и эксплуатации) элементов и внутренних деталей абстракции (то -есть модели) в отношении реализации с тем, чтобы эти детали (как малозначимые -для использования компонента или по другим причинам) были недоступны -пользователям элементов (компонент). При этом, в качестве “пользователя” одного -компонента может выступать другой компонент. Более того, при использовании -объектно-ориентированного подхода, наследники компонентов могут не иметь -доступа ко внутренним деталям реализации компонента, который является их -предком (зависит от объектно-ориентированной модели конкретного языка -программирования или платформы). - -#### Разделение интерфейса и реализации (Separation of interface and implementation) - -Данная техника предполагает определение компонента через специфицирование -интерфейса, известного (описанного) и доступного клиентам (или другим -компонентам), от непосредственных деталей реализации. - -#### Достаточность, полнота и простота (Sufficiency, completeness and primitiviness) - -Этот подход подразумевает, что создаваемые программные компоненты обладают -всеми необходимыми характеристиками, определенными абстракцией (моделью), но не -более того. То есть не включают функциональность, отсутствующую в модели. - -Данный принцип особенно ярко выделен и явно представлен в виде рекомендуемых -практик (best practices) методологий гибкого моделирования и экстремального -программирования, где “все, что надо, но ни граммом больше” лежит в основе -самой концепции “прагматичного” подхода (и на стадии моделирования, и в -отношении реализации в коде). В оригинале этот принцип звучит как YAGNI – “You -Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”. - -## Ключевые вопросы проектирования (Key Issues in Software Design) - -В какой-то мере, данную секцию стоило перевести как ключевые проблемы. Как -проводить декомпозицию? Как организовать и объединить компоненты в единую -систему? Как обеспечить необходимую производительность? Наконец, как обеспечить -приемлемое качество системы? Все это – фундаментальные вопросы и проблемы -проектирования, вне зависимости от используемых при проектировании подходов. - -### Параллелизм (Concurrency) - -Эта тема охватывает вопросы, подходы и методы организации процессов, задач и -потоков для обеспечения эффективности, атомарности, синхронизации и -распределения (по времени) обработки информации. - -### Контроль и обработка событий (Control and Handling of Events) - -В самом названии данной темы заложен комплекс обсуждаемых вопросов. В -частности, данная тема касается и неявных методов обработки событий, часто -реализуемых в виде функции обратного вызова (call-back), как одной из -фундаментальных концепций обработки событий. - -### Распределение компонентов (Distribution of Components) - -Распределение (и выполнение) по различным узлам обработки в терминах -аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших -вопросов данной темы – использование связующего программного обеспечения -(middleware[^5]) - -[^5]: Часто middleware переводят как “промежуточное программное обеспечение”. Такой -вариант перевода, к сожалению, рассматривает связующее ПО во второстепенной – -“промежуточной” роли. Читатель, безусловно, может не согласиться с такой -трактовкой, однако, многолетняя практика автора в обсуждении архитектурных -вопросов с различными специалистами демонстрирует именно такой взгляд -пользователей, не знакомых или не имеющих успешного опыта разработки и -эксплуатации распределённых систем. - -### Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости (Errors and Exception Handling and Fault Tolerance) - -Вопрос темы, как ни странно, формулируется достаточно просто – как -предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее -функционирование системы. - -### Взаимодействие и представление (Interaction and Presentation) - -Тема касается вопросов представления информации пользователям и взаимодействия -пользователей с системой, с точки зрения реакции системы на действия -пользователей. Речь в этой теме идет о реакции системы в ответ на действия -пользователей и организации ее отклика с точки зрения внутренней организации -взаимодействия, например, в рамках популярной концепции Model-View-Controller. - -Ни в коем случае не надо путать данную тему с вопросами организации -пользовательского интерфейса, являющимеся частью “Эргономики программного -обеспечения” – Software Ergonomics (см. “Связанные дисциплины”). - -### Сохраняемость данных (Data Persistence) - -Именно сохраняемость, а не сохранность, так как тема касается не доступа к -базам данных, как такового, а также не гарантий сохранности информации. Суть -вопроса – как должны обрабатываться “долгоживущие” данные. - -## Структура и архитектура программного обеспечения (Software Structure and Architecture) - -В строгом значении архитектура программного обеспечения (software architecture) -– описание подсистем и компонент программной системы, а также связей между -ними. Архитектура пытается определить внутреннюю структуру получаемой системы, -задавая способ, которым система организована или конструируется. - -В середине 90-х, на волне распространения клиент-серверного подхода и начала -его трансформации в “многозвенный клиент-сервер”, призванный обеспечить -централизованное развертывание и управление общей (для клиентских приложений) -бизнес-логикой, вопросы организации архитектуры программного обеспечения стали -складываться в самостоятельную и достаточно обширную дисциплину. В результате, -сформировалась точка зрения на архитектуру не только в приложении к конкретной -программной системе, но и развился взгляд на архитектуру, как на приложение -общих (generic) принципов организации программных компонент. В итоге, уже на -сегодняшний день, на фоне такого развития понимания архитектуры, накоплен целый -комплекс подходов и созданы (и продолжают создаваться и развиваться !) -различные архитектурные “фреймворки”, то есть систематизированные комплексы -методов, практик и инструментов, призванные в той или иной степени -формализовать имеющийся в индустрии опыт (как положительный – например, design -patterns, так и отрицательный – например, anti-patterns). -Примеры такой систематизации в форме фреймворков: - -- TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент -первичного написания данной главы доступен в версии 8.1, впервые опубликованной -в декабре 2003 года; в 2009 году вышла версия TOGAF 9) -- Модель Захмана – Zachman Framework [Zachman] -- Руководство по архитектуре электронного правительства E-Gov Enterprise -Architecture Guidance [E-Gov, 2002] - -### Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints) - -Любая система может рассматриваться с разных точек зрения – например, -поведенческой (динамической), структурной (статической), логической -(удовлетворение функциональным требованиям), физической (распределенность), -реализации (как детали архитектуры представляются в коде) и т.п. В результате, -мы получаем различные архитектурные представления (view). Архитектурное -представление может быть определено, как частные аспекты программной -архитектуры, рассматривающие специфические свойства программной системы. В свою -очередь, дизайн системы – комплекс архитектурных представлений, достаточный для -реализации системы и удовлетворения требований, предъявляемых к системе. - -SWEBOK не дает явного определения, что такое “архитектурная структура”. В то же -время это понятие достаточно важно. Я хотел бы предложить его толкование как -применение архитектурной точки зрения и представления к конкретной системе и -описания тех деталей, которые необходимы для реализации системы, но отсутствуют -(в силу достаточно общего взгляда) в используемом представлении. Таким образом, -представление (view), концентрируясь на заданном подмножестве свойств является -составной частью и/или результатом точки зрения, а архитектурная структура – -дальнейшей детализацией в отношении проектируемой системы. - -Модель Захмана [Zachman] является великолепным и, кстати, классическим -источником комплекса архитектурных точек зрения и представлений, построенных в -системе координат “вопрос-уровень детализации”. Каждое архитектурное -представление является результатом ответа на вопрос (Как? Что? Где? и т.п.) в -контексте необходимого уровня абстракции (содержание, то есть концепция: -бизнес-модель, то есть функциональность и т.д.). Например, физическая модель -данных (Physical Data Model) является ответом на вопрос “что?” в контексте -технологической модели, а логическая модель данных, отвечая на тот же вопрос, -находится на один уровень абстракции выше – в контексте системной или -логической модели. - -### Архитектурные стили (Architectural Styles) - -В рассматриваемой редакции SWEBOK допущено несоответствие между структурой -декомпозиции данной области знаний и описанием охватываемых ею тем. Если -архитектурные стили присутствуют в декомпозиции, в самом описании области -знаний темы 3.1 и 3.2 смешаны (по форматированию и структуре) в рамках темы -“3.1”, (о чем сообщено ассоциированному редактору данной части SWEBOK). - -Архитектурный стиль, по своей сути, мета-модель или шаблон проектирования -макро-архитектуры - на уровне модулей, "крупноблочного" взгляда. Например, -архитектура распределенной сервисно-ориентированной системы может строится в -стиле обмена сообщениями через соответствующие очереди сообщений, может -проектироваться на основе идеи взаимодействия между компонентами и приложениями -через общую объектную шину, а может использовать концепцию брокера как единого -узла пересылки запросов. В то же время, на более концептуальном уровне, мы -можем говорить о выборе клиент-серверного стиля или распределенного стиля -архитектуры системы. Таким образом, архитектурный стиль – набор ограничений, -определяющих семейство архитектур, которые удовлетворяют этим ограничениям. - -### Шаблоны проектирования (Design Patterns) - -Наиболее краткая формулировка того, что такое шаблон проектирования, может -звучать так – “общее решение общей проблемы в заданном контексте”. Что это -значит в реальной жизни? Если мы хотим организовать системы таким образом, -чтобы существовал один и только один экземпляр заданного ее компонента в -процессе работы с данной системой – мы можем использовать шаблон проектирования -“Singleton”, описывающий такое общее поведение. - -В то время, как архитектурный стиль определяет макро-архитектуру системы, -шаблоны проектирования задают микро-архитектуру, то есть определяют частные -аспекты деталей архитектуры. - -Чаще всего говорят о следующих группах шаблонов проектирования: - -- Шаблоны создания (Creational patterns) - builder, factory, prototype, -singleton -- Структурные шаблоны (Structural patterns) - adapter, bridge, composite, -decorator, facade, flyweight, proxy -- Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator, -mediator, memento, observer, state, strategy, template, visitor - -В SWEBOK данная тема, в силу упомянутого выше несоответствия между структурной -декомпозицией и описанием области знаний “проектирование”, имеет номер 3.2 -(следующая тема, в свою очередь, представлена в SWEBOK как 3.3). - -### Семейства программ и фреймворков (Families of Programs and Frameworks) - -Один из возможных подходов к повторному использованию архитектурных решений и -компонент заключается в формировании линий продуктов (product lines) на основе -общего дизайна. В объектно-ориентированном программировании аналогичную -смысловую нагрузку несут “фреймворки”, обеспечивающие решение одних и тех же -задач – например, внутренней организации компонентов пользовательского -интерфейса или общей логики работы распределенных систем. - -## Анализ качества и оценка программного дизайна (Software Design Quality Analysis and Evaluation) - -### Атрибуты качества (Quality Attributes) - -Существует целый спектр различных атрибутов, помогающих оценить и добиться -качественного дизайна. Эти атрибуты могут описывать многие характеристики -системы и элементов дизайна как такового – “тестируемость”, “переносимость”, -“модифицируемость”, “производительность”, “безопасность” и т.п. - -Важно понимать, что обсуждаемые атрибуты касаются только дизайна (как -результата), но не проектирования (как процесса). В принципе, все эти атрибуты -можно разбить на несколько групп: - -- применимые к run-time, то есть ко времени выполнения системы; например, -среднее время отклика системы позволяющий оценить качество дизайна с точки -зрения производительности; -- ориентированные на design-time, то есть позволяющие оценивать качество -получаемого дизайна еще на этапе проектирования или, в общем случае, вплоть до -тестирования, включительно; например, средняя нагруженность классов -бизнес-методами (предположим бизнес-методов в каждом классе в среднем 30 – -интересно, насколько легко можно поддерживать, модифицировать и развивать -систему с такой внутренней структурой....); -- атрибуты качества архитектурного дизайна как такового, например, -концептуальная целостность дизайна, непротиворечивость, полнота, завершенность; -например, любой определенный бизнес-метод является вызываемым, то есть создан -не просто потому что может понадобиться в будущем, а определен в соответствии с -требованиями или необходим для реализации дизайна в выбранном архитектурном -стиле. - -Необходимо понимать, что существуют атрибуты, которые сложно измерить. -Например, портируемость или безопасность. Не стоит путать атрибуты качества -дизайна с атрибутами качества, фигурируемыми в ряду требований, предъявляемых к -системе. Часть из них может отображаться друг на друга и нести эквивалентную -смысловую нагрузку, некоторые могут быть связаны, большая часть атрибутов -является специфичной именно для дизайна и не связана с требованиями. Например, -если мы используем платформу J2EE (Java 2 Enterprise Edition) и ориентируемся -на использование компонентой модели EJB (Enterprise JavaBeans), существуют -признаки хорошего дизайна, специфичные для данной платформы и компонентной -модели, но абсолютно никак не связанные с какими-либо требованиями к -создаваемой на этой платформе программной системе. Если вернуться к измеряемым -атрибутам качества, они описываются определенными метриками. Приведенный выше -пример с количеством бизнес-методов на класс является метрикой, относящейся к -теме 4.3 “Измерения”. Эта же метрика позволяет оценить атрибуты качества -“модифицируемость” и “сложность” системы. - -### Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques) - -В индустрии распространены многие инструменты, техники и практики, помогающие -добиться качественного дизайна: - -- обзор дизайна (software design review); например, неформальный обзор -архитектуры членами проектной команды; -- статический анализ (static analysis); например, трассировка с требованиями; -- симуляция и прототипирование (simulation and prototyping) – динамические -техники проверки дизайна в целом или отдельных его атрибутов качества; -например, для оценки производительности используемых архитектурных решений при -симуляции нагрузки, близкой к прогнозируемым пиковым; - -### Измерения (Measures) - -Также известные как метрики. Могут быть использованы для количественной оценки -ожиданий в отношении различных аспектов конкретного дизайна, например, размера -<проекта>, структуры (ее сложности) или качества (например, в контексте -требований, предъявляемых к производительности). Чаще всего, все метрики -разделяют по двум категориям: - -- функционально-ориентированные -- объектно-ориентированные - -## Нотации проектирования (Software Design Notations) - -Нотация есть соглашение о представлении. Часто под нотацией подразумевают -визуальное (графическое) представление. Нотация может задаваться: - -- стандартом; например, OMG UML – Unified Modeling Language, развиваемый -консорциумом OMG (Object Management Group, http://www.omg.org); -- общепринятой практикой; например, в eXtreme Programming часто используются -карточки функциональной ответственности и связей класса - Class Responsibility -Collaborator или CRC Card (CRC по свое природе является текстовой, то есть -невизуальной нотацией); -- внутренним методом проектной команды (“будем рисовать и обозначать так...”). - -Определенные нотации используются на стадии концептуального проектирования, ряд -нотаций ориентирован на создание детального дизайна, многие могут -использоваться на обеих стадиях. Кроме того, нотации чаще всего используют в -контексте (выбор нотации может быть обусловлен таким контекстом) применяемой -методологии или подхода (см. 6 “Software Design Strategies and Methods” данной -области знаний). Ниже мы будем рассматривать нотации, исходя из описания -структурного (статического) или поведенческого (динамического) представления. - -### Структурные описания, статический взгляд (Structural Descriptions, static view) - -Следующие нотации, в основном (но, не всегда), являются графическими, описывая -и представляя структурные аспекты программного дизайна. Чаще всего они касаются -основных компонент и связей между ними (статических связей, например, таких как -отношения “один-ко-многим”). - -- *Языки описания архитектуры (Architecture description language, ADL)*: -текстовые языки, часто – формальные, используемые для описания программной -архитектуры в терминах компонентов и коннекторов (специализированных -компонентов, реализующих не функциональность, но обеспечивающих взаимосвязь -функциональных компонентов между собой и с “внешним миром”); -- *Диаграммы классов и объектов (Class and object diagrams)*: используются для -представления набора классов и <статических> связей между ними (например, -наследования); -- *Диаграммы компонентов или компонентные диаграммы (Component diagrams)*: в -определенной степени аналогичны диаграммам классов, однако, в силу специфики -концепции или понятия компонента[^6], обычно, представляются в другой -визуальной форме; -- *Карточки <функциональной> ответственности и связей класса (Class -responsibility collaborator card, CRC)*: используются для обозначения имени -класса, его ответственности (то есть, что он должен делать) и других сущностей -(классов, компонентов, актёров/ролей и т.п.), с которыми он связан; часто их -называют карточками “класс-обязанность-кооперация”; -- *Диаграммы развёртывания (Deployment diagrams)*: используется для -представления (физических) узлов, связей между ними и моделирования других -физических аспектов системы; -- *Диаграммы сущность-связь (Entity-relationship diagram, ERD или ER)*: -используется для представления концептуальной модели данных, сохраняемых в -процессе работы информационной системы; -- *Языки описания/определения интерфейса (Interface Description Languages, -IDL)*: языки, подобные языкам программирования, не включающие возможностей -описания логики системы и предназначенные для определения интерфейсов -программных компонентов (имён и типов экспортируемых или публикуемых операций); -- *Структурные диаграммы Джексона (Jackson structure diagrams)*: используются -для описания структур данных в терминах последовательности, выбора и итераций -(повторений); -- *Структурные схемы (Structure charts)*: описываю структуру вызовов в -программах (какой модуль вызывает, кем и как вызываем). - -[^6]: Здесь необходимо отметить различие в понятиях класса (или объекта) и -компонента: компонент рассматривается как физически реализуемый элемент -программного обеспечения, несущий <в определенной степени> самодостаточную -логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде -комплекса классов); - -### Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view) - -Следующие нотации и языки (часть из которых – графические, часть - текстовые) -используются для описания динамического поведения программных систем и их -компонентов. Многие из этих нотаций успешно используются для проектирования -деталей дизайна, но не только для этого. - -- *Диаграммы деятельности или операций (Activity diagrams)*: используются для -описания потоков работ и управления; -- *Диаграммы сотрудничества (Collaboration diagrams)*: показывают динамическое -взаимодействие, происходящее в группе объектов и уделяют особое внимание -объектам, связям между ними и сообщениям, которыми обмениваются объекты -посредством этих связей; -- *Диаграммы потоков данных (Data flow diagrams, DFD)*: описывают потоки данных -внутри набора процессов (не в терминах процессов операционной среды, но в -понимании обмена информацией в бизнес-контексте); -- *Таблицы и диаграммы <принятия> решений (Decision tables and diagrams)*: -используются для представления сложных комбинаций условий и действий -(операций); -- *Блок-схемы и структурированные блок-схемы (Flowcharts and structured -flowcharts)*: применяются для представления потоков управления (контроля) и -связанных операций; -- *Диаграммы последовательности (Sequence diagrams)*: используются для показа -взаимодействий внутри группы объектов с акцентом на временной -последовательности сообщений/вызовов; -- *Диаграммы перехода и карты состояний(State transition and statechart -diagrams)*: применяются для описания потоков управления переходами между -состояниями; -- *Формальные языки спецификации (Formal specification languages)*: текстовые -языки, использующие основные понятия из математики (например, множества) для -строгого и абстрактного определения интерфейсов и поведения программных -компонентов, часто в терминах пред- и пост-условий; -- *Псевдокод и программные языки проектирования (Pseudocode and program design -languages, PDL)*: языки, используемые для описания поведения процедур и -методов, в основном на стадии детального проектирования; подобны структурным -языкам программирования. - -## Стратегии и методы проектирования программного обеспечения (Software Design Strategies and Methods) - -Существуют различные общие стратегии, помогающие в проведении работ по -проектированию. В отличие от общих стратегий, методы проектирования более -специфичны и, в основном, предлагают и предоставляют нотации (или наборы -нотаций) для использования совместно с этими методами, а также процессы, -которым необходимо следовать в рамках используемого метода. - -Таким образом, методы в данном контексте это не просто некие -“слабоформализованные” или просто частные практические подходы или техники. -Методы здесь являются более общими понятиями, это - методологии, -сконцентрированные на процессе (в частности, проектирования) и предполагающие -следование определенным правилам и соглашениям, в том числе – по используемым -выразительным средствам. Такие методы полезны как инструмент систематизации -(иногда, формализации) и передачи знаний в виде общего фреймворка (то есть -комплексного набора понятий, подходов, техник и инструментов) не только для -отдельных специалистов, но для команд и проектных групп программных проектов. - -### Общие стратегии (General Strategies) - -Это обычно часто упоминаемые и общепринятые стратегии: - -- “разделяй-и-властвуй” и пошаговое уточнение -- проектирование “сверху-вниз” и “снизу-вверх” -- абстракция данных и сокрытие информации -- итеративный и инкрементальный подход -- и другие... - -### Функционально-ориентированное или структурное проектирование (Function-Oriented – Structured Design) - -Это один из классических методов проектирования, в котором декомпозиция -сфокусирована на идентификации основных программных функций и, затем, детальной -разработке и уточнении этих функций “сверху-вниз”. Структурное проектирование, -обычно, используется после проведения структурного анализа с применением -диаграмм потоков данных и связанным описанием процессов. Исследователи -предлагают различные стратегии и метафоры или подходы для трансформации DFD в -программную архитектуру, представляемую в форме структурных схем. Например, -сравнивая управление и поведение с получаемым эффектом. - -### Объектно-ориентированное проектирование (Object-Oriented Design) - -Представляет собой множество методов проектирования, базирующихся на концепции -объектов. Данная область активно эволюционирует с середины 80-х годов, -основываясь на понятиях объекта (сущности), метода (действия) и атрибута -(характеристики). Здесь главную роль играют полиморфизм и инкапсуляция, в то -время, как в компонентно-ориентированном подходе большее значение придается -мета-информации, например, с применением технологии отражения (reflection). -Хотя корни объектно-ориентированного проектирования лежат в абстракции данных -(к которым добавлены поведенческие характеристики), так называемый -responsibility-driven design или проектирование на основе <функциональной> -ответственности по SWEBOK* может рассматриваться как альтернатива -объектно-ориентированному проектированию. - -*Такое противопоставление – достаточно спорный вопрос, так как функциональная -ответственность столь же близка принципам современного -объектно-ориентированного проектирования, сколь и абстракция данных. Это вопрос -эволюционирования взглядов и степени их консерватизма. - -### Проектирование на основе структур данных (Data-Structure-Centered Design) - -В данном подходе фокус сконцентрирован в большей степени на структурах данных, -которыми управляет система, чем на функциях системы. Инженеры по программному -обеспечению часто вначале описывают структуры данных входов (inputs) и выходов -(outputs), а, затем, разрабатывают структуру управления этими данными (или, -например, их трансформации). - -### Компонентное проектирование (Component-Based Design) - -Программные компоненты являются независимыми единицами, которые обладают -однозначно-определенными (well-defined) интерфейсами и зависимостями (связями) -и могут собираться и развертываться независимо друг от друга. Данный подход -призван решить задачи использования, разработки и интеграции таких компонент с -целью повышения повторного использования активов (как архитектурных, так и в -форме кода). - -Компонентно-ориентированное проектирование является одной из наиболее динамично -развивающихся концепций проектирования и может рассматриваться как предвестник -и основа сервисно-ориентированного подхода (Service-Oriented Architecture, SOA) -в проектировании, не рассматриваемого, к сожалению, в SWEBOK, но все более -активно использующегося в индустрии и смещающего акценты с аспектов организации -связи интерфейс-реализация к обмену информацией на уровне интерфейс-интерфейс -(то есть – межкомпонентному взаимодействию). По мнению автора книги, уже -наступил тот момент, когда необходимо вводить отдельную тему, посвященную -сервисно-ориентированному подходу в проектировании и сервисно-ориентированным -архитектурам, как моделям. В частности, нотация UML 2.0 уже позволяет решать -ряд вопросов, связанных с визуальным представлением соответствующих -архитектурных решений, где сервисы (службы) могут рассматриваться как -публикуемая функциональность одиночных компонентов и групп компонентов, -объединенных в более “крупные” блоки, обеспечивающие предоставление -соответствующей сервисной функциональности. - -### Другие методы (Other Methods) - -Другие интересные, но менее распространенные подходы, в основном, представляют -собой формальные и точные (строгие) методы, а также, методы трансформации. blob - /dev/null blob + 106abb9f63ec35345bed7fdc99c8118bb5ab3441 (mode 644) --- /dev/null +++ 2_software_design.md @@ -0,0 +1,634 @@ +# Проектирование программного обеспечения + +Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK. + +Содержит перевод описания области знаний SWEBOK “Software Design”, с замечаниями и комментариями. + +Процесс определения архитектуры, компонентов, интерфейсов и других +характеристик системы или ее компонентов называется *проектированием*. +Результат процесса проектирования – *дизайн*. Рассматриваемое как процесс, +проектирование есть инженерная деятельность в рамках жизненного цикла (в данном +контексте – программного обеспечения), в которой надлежащим образом +анализируются требования для создания описания внутренней структуры ПО, +являющейся основой для конструирования программного обеспечения как такового. +Программный дизайн (как результат деятельности по проектированию) должен +описывать архитектуру программного обеспечения, то есть представлять +декомпозицию программной системы в виде организованной структуры компонент и +интерфейсов между компонентами. Важнейшей характеристикой готовности дизайна +является тот уровень детализации компонентов, который позволяет заняться их +конструированием. Термины дизайн и архитектура могут использоваться +взаимозаменяемым образом, но чаще говорят о дизайне как о целостном взгляде на +архитектуру системы. + +Проектирование играет важную роль в процессах жизненного цикла создания +программного обеспечения (Software Development Life Cycle), например, IEEE и +ISO/IEC (ГОСТ Р ИСО.МЭК) 12207. Проектирование программных систем можно +рассматривать как деятельность, результат которой состоит из двух составных +частей: + +- Архитектурный или высокоуровневый дизайн (software architectural design, +top-level design) – описание высокоуровневой структуры и организации +компонентов системы; +- Детализированная архитектура (software detailed design) – описывающая каждый +компонент в том объеме, который необходим для конструирования. + +В результате консенсуса, принятого создателями SWEBOK, данная область знаний не +описывает все сущности или понятия, имеющие в своем названии слово “дизайн” или +“архитектура”. В 1999 году Том ДеМарко (Tom DeMarco) [DeMarco, 1999], один из +известных специалистов в программной инженерии, предложил терминологическое +разделение различных видов дизайна: + +- *D-дизайн (D-design, decomposition design)* – декомпозиция структуры программного обеспечения в виде набора фрагментов или компонент; +- *FP-дизайн (FP-design, family pattern design)* – семейство архитектурных представлений, базирующихся на шаблонах; +- *I-дизайн (I-design, invention)* – создание высоко-уровневой концепции, видения того, что из себя будет представлять программная система; данный вид дизайна является результатом процесса анализа требований и их трансформации в подходы к реализации. + +Если обсуждать данную область знаний в терминах ДеМарко, проектирование +программного обеспечения в понимании программной инженерии подразумевает D- и +FP-дизайн. I-дизайн в большей степени относится к работе с программными +требованиями. + +Соответственно, данная область знаний тесно связана со следующими областями +программной инженерии: + +- Software Requirements +- Software Construction +- Software Maintenance +- Software Engineering Management +- Software Quality + +Сама же область знаний по проектированию программного обеспечения представлена +в виде 6 секций, структурированных по темам. + +![Рисунок 3. Область знаний “Проектирование программного обеспечения” [SWEBOK, 2004, с.3-2, рис. 1]](images/design_area_small.jpg) + +## Основы проектирования (Software Design Fundamentals) + +Эта секция вводит концепции, понятия и терминологию в качестве основы для +понимания роли и содержания проектирования (как деятельности) и дизайна +(архитектуры, как результата) программного обеспечения. + +Темы данной секции: + +### Общие концепции проектирования (General Design Concepts) + +К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, +используемые представления и решения. +Например, архитектурный фреймворк – TOGAF [TOGAF, 2003], разработанный и +развиваемый консорциумом The Open Group (www.opengroup.org), предлагает +следующие <возможные> цели (goals): + +- Улучшение и повышение продуктивности бизнес-процессов +- Уменьшение затрат +- Улучшение операционной бизнес-деятельности +- Повышение эффективности управления +- Уменьшение рисков +- Повышение эффективности ИТ-организации +- Повышение продуктивности работы пользователей +- Повышение интероперабельности (возможности и прозрачности взаимодействия) +- Уменьшение стоимости <поддержки> жизненного цикла +- Улучшение характеристик безопасности +- Повышение управляемости + +### Контекст проектирования (Context of Software Design) + +Для понимания роли проектирования программного обеспечения важно понимать +контекст, в котором осуществляется проектирование и используются его +результаты. В качестве такого контекста выступает жизненный цикл программной +инженерии, а проектирование напрямую связано с результатами анализа требований, +конструированием программных систем и их тестированием. Стандарты жизненного +цикла, например, IEEE и ISO/IEC (ГОСТ Р) 12207 уделяют специальное внимание +вопросам проектирования и детализируют их, описывая контекст проектирования – +от требований до тестов. + +### Процесс проектирования (Software Design Process) + +Проектирование в основном рассматривается как двух-шаговый процесс: + +#### Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент; + +#### Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент. + +Выходом этого процесса является набор моделей и артефактов, содержащих +результаты решений, принятых по способам реализации требований в программном +коде. + +### Техники применения (Enabling Techniques) + +Принципы проектирования, также называемые техниками применения, являются +ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в +различных методах и подходах к проектированию программного обеспечения. + +##### Абстракция (Abstraction) + +В контексте проектирования программных систем существует два механизма +абстракции – параметризация и специфицирование (может интерпретироваться как +детализация). При этом, абстракция через специфицирование бывает трех видов: +процедурная абстракция (динамическая, то есть в отношении поведения), +абстракция данных (статическая, то есть в отношении информации) и абстракция +контроля (то есть управления системой и обрабатываемой ею информацией). + +Обычно под абстракций, как результатом процесса абстракции, понимают модель, +упрощающую поставленную проблему до рамок, значимых для заданного контекста. + +#### Связанность и соединение (Coupling and Cohesion) + +*Связанность (Coupling)* – определяет силу связи (часто, взаимного влияния) +между модулями. Соединение (Cohesion) – определяет как тот или иной элемент +обеспечивает связь внутри модуля, внутреннюю связь. + +Значение оригинальных терминов очень близко и, в зависимости от контекста, +“связанность” и “соединение” могут рассматриваться как степень +самодостаточности или ее отсутствия (coupling) и функциональная зависимость +(cohesion) , соответственно. + +Хочется особенно подчеркнуть значимость этих понятий, так как с развитием +сервисно-ориентированной архитектуры (Service-Oriented Architecture, SOA), +слабосвязанной по своей природе (то есть со слабым “сопряжением”, слабой “силой +связи” между модулями), по сравнению, например, с OMG CORBA (Common Object +Request Broker Architecture), все чаще приходится сравнивать различные подходы +и решения, определяемые способом и степенью связанности различных модулей, +компонент и самих программных систем. + +#### Декомпозиция и разбиение на модули (Decomposition and Modularization) + +Декомпозиция и разбиение на модули сложных программных систем производится с +целью получения более мелких и относительно независимых программных +компонентов, каждый из которых несет различную функциональность (логически +связанные группы функциональности). + +#### Инкапсуляция/сокрытие информации (Encapsulation/information hiding) + +Данная концепция предполагает группировку и упаковку (с точки зрения подготовки +к развертыванию и эксплуатации) элементов и внутренних деталей абстракции (то +есть модели) в отношении реализации с тем, чтобы эти детали (как малозначимые +для использования компонента или по другим причинам) были недоступны +пользователям элементов (компонент). При этом, в качестве “пользователя” одного +компонента может выступать другой компонент. Более того, при использовании +объектно-ориентированного подхода, наследники компонентов могут не иметь +доступа ко внутренним деталям реализации компонента, который является их +предком (зависит от объектно-ориентированной модели конкретного языка +программирования или платформы). + +#### Разделение интерфейса и реализации (Separation of interface and implementation) + +Данная техника предполагает определение компонента через специфицирование +интерфейса, известного (описанного) и доступного клиентам (или другим +компонентам), от непосредственных деталей реализации. + +#### Достаточность, полнота и простота (Sufficiency, completeness and primitiviness) + +Этот подход подразумевает, что создаваемые программные компоненты обладают +всеми необходимыми характеристиками, определенными абстракцией (моделью), но не +более того. То есть не включают функциональность, отсутствующую в модели. + +Данный принцип особенно ярко выделен и явно представлен в виде рекомендуемых +практик (best practices) методологий гибкого моделирования и экстремального +программирования, где “все, что надо, но ни граммом больше” лежит в основе +самой концепции “прагматичного” подхода (и на стадии моделирования, и в +отношении реализации в коде). В оригинале этот принцип звучит как YAGNI – “You +Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”. + +## Ключевые вопросы проектирования (Key Issues in Software Design) + +В какой-то мере, данную секцию стоило перевести как ключевые проблемы. Как +проводить декомпозицию? Как организовать и объединить компоненты в единую +систему? Как обеспечить необходимую производительность? Наконец, как обеспечить +приемлемое качество системы? Все это – фундаментальные вопросы и проблемы +проектирования, вне зависимости от используемых при проектировании подходов. + +### Параллелизм (Concurrency) + +Эта тема охватывает вопросы, подходы и методы организации процессов, задач и +потоков для обеспечения эффективности, атомарности, синхронизации и +распределения (по времени) обработки информации. + +### Контроль и обработка событий (Control and Handling of Events) + +В самом названии данной темы заложен комплекс обсуждаемых вопросов. В +частности, данная тема касается и неявных методов обработки событий, часто +реализуемых в виде функции обратного вызова (call-back), как одной из +фундаментальных концепций обработки событий. + +### Распределение компонентов (Distribution of Components) + +Распределение (и выполнение) по различным узлам обработки в терминах +аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших +вопросов данной темы – использование связующего программного обеспечения +(middleware[^5]) + +[^5]: Часто middleware переводят как “промежуточное программное обеспечение”. Такой +вариант перевода, к сожалению, рассматривает связующее ПО во второстепенной – +“промежуточной” роли. Читатель, безусловно, может не согласиться с такой +трактовкой, однако, многолетняя практика автора в обсуждении архитектурных +вопросов с различными специалистами демонстрирует именно такой взгляд +пользователей, не знакомых или не имеющих успешного опыта разработки и +эксплуатации распределённых систем. + +### Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости (Errors and Exception Handling and Fault Tolerance) + +Вопрос темы, как ни странно, формулируется достаточно просто – как +предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее +функционирование системы. + +### Взаимодействие и представление (Interaction and Presentation) + +Тема касается вопросов представления информации пользователям и взаимодействия +пользователей с системой, с точки зрения реакции системы на действия +пользователей. Речь в этой теме идет о реакции системы в ответ на действия +пользователей и организации ее отклика с точки зрения внутренней организации +взаимодействия, например, в рамках популярной концепции Model-View-Controller. + +Ни в коем случае не надо путать данную тему с вопросами организации +пользовательского интерфейса, являющимеся частью “Эргономики программного +обеспечения” – Software Ergonomics (см. “Связанные дисциплины”). + +### Сохраняемость данных (Data Persistence) + +Именно сохраняемость, а не сохранность, так как тема касается не доступа к +базам данных, как такового, а также не гарантий сохранности информации. Суть +вопроса – как должны обрабатываться “долгоживущие” данные. + +## Структура и архитектура программного обеспечения (Software Structure and Architecture) + +В строгом значении архитектура программного обеспечения (software architecture) +– описание подсистем и компонент программной системы, а также связей между +ними. Архитектура пытается определить внутреннюю структуру получаемой системы, +задавая способ, которым система организована или конструируется. + +В середине 90-х, на волне распространения клиент-серверного подхода и начала +его трансформации в “многозвенный клиент-сервер”, призванный обеспечить +централизованное развертывание и управление общей (для клиентских приложений) +бизнес-логикой, вопросы организации архитектуры программного обеспечения стали +складываться в самостоятельную и достаточно обширную дисциплину. В результате, +сформировалась точка зрения на архитектуру не только в приложении к конкретной +программной системе, но и развился взгляд на архитектуру, как на приложение +общих (generic) принципов организации программных компонент. В итоге, уже на +сегодняшний день, на фоне такого развития понимания архитектуры, накоплен целый +комплекс подходов и созданы (и продолжают создаваться и развиваться !) +различные архитектурные “фреймворки”, то есть систематизированные комплексы +методов, практик и инструментов, призванные в той или иной степени +формализовать имеющийся в индустрии опыт (как положительный – например, design +patterns, так и отрицательный – например, anti-patterns). +Примеры такой систематизации в форме фреймворков: + +- TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент +первичного написания данной главы доступен в версии 8.1, впервые опубликованной +в декабре 2003 года; в 2009 году вышла версия TOGAF 9) +- Модель Захмана – Zachman Framework [Zachman] +- Руководство по архитектуре электронного правительства E-Gov Enterprise +Architecture Guidance [E-Gov, 2002] + +### Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints) + +Любая система может рассматриваться с разных точек зрения – например, +поведенческой (динамической), структурной (статической), логической +(удовлетворение функциональным требованиям), физической (распределенность), +реализации (как детали архитектуры представляются в коде) и т.п. В результате, +мы получаем различные архитектурные представления (view). Архитектурное +представление может быть определено, как частные аспекты программной +архитектуры, рассматривающие специфические свойства программной системы. В свою +очередь, дизайн системы – комплекс архитектурных представлений, достаточный для +реализации системы и удовлетворения требований, предъявляемых к системе. + +SWEBOK не дает явного определения, что такое “архитектурная структура”. В то же +время это понятие достаточно важно. Я хотел бы предложить его толкование как +применение архитектурной точки зрения и представления к конкретной системе и +описания тех деталей, которые необходимы для реализации системы, но отсутствуют +(в силу достаточно общего взгляда) в используемом представлении. Таким образом, +представление (view), концентрируясь на заданном подмножестве свойств является +составной частью и/или результатом точки зрения, а архитектурная структура – +дальнейшей детализацией в отношении проектируемой системы. + +Модель Захмана [Zachman] является великолепным и, кстати, классическим +источником комплекса архитектурных точек зрения и представлений, построенных в +системе координат “вопрос-уровень детализации”. Каждое архитектурное +представление является результатом ответа на вопрос (Как? Что? Где? и т.п.) в +контексте необходимого уровня абстракции (содержание, то есть концепция: +бизнес-модель, то есть функциональность и т.д.). Например, физическая модель +данных (Physical Data Model) является ответом на вопрос “что?” в контексте +технологической модели, а логическая модель данных, отвечая на тот же вопрос, +находится на один уровень абстракции выше – в контексте системной или +логической модели. + +### Архитектурные стили (Architectural Styles) + +В рассматриваемой редакции SWEBOK допущено несоответствие между структурой +декомпозиции данной области знаний и описанием охватываемых ею тем. Если +архитектурные стили присутствуют в декомпозиции, в самом описании области +знаний темы 3.1 и 3.2 смешаны (по форматированию и структуре) в рамках темы +“3.1”, (о чем сообщено ассоциированному редактору данной части SWEBOK). + +Архитектурный стиль, по своей сути, мета-модель или шаблон проектирования +макро-архитектуры - на уровне модулей, "крупноблочного" взгляда. Например, +архитектура распределенной сервисно-ориентированной системы может строится в +стиле обмена сообщениями через соответствующие очереди сообщений, может +проектироваться на основе идеи взаимодействия между компонентами и приложениями +через общую объектную шину, а может использовать концепцию брокера как единого +узла пересылки запросов. В то же время, на более концептуальном уровне, мы +можем говорить о выборе клиент-серверного стиля или распределенного стиля +архитектуры системы. Таким образом, архитектурный стиль – набор ограничений, +определяющих семейство архитектур, которые удовлетворяют этим ограничениям. + +### Шаблоны проектирования (Design Patterns) + +Наиболее краткая формулировка того, что такое шаблон проектирования, может +звучать так – “общее решение общей проблемы в заданном контексте”. Что это +значит в реальной жизни? Если мы хотим организовать системы таким образом, +чтобы существовал один и только один экземпляр заданного ее компонента в +процессе работы с данной системой – мы можем использовать шаблон проектирования +“Singleton”, описывающий такое общее поведение. + +В то время, как архитектурный стиль определяет макро-архитектуру системы, +шаблоны проектирования задают микро-архитектуру, то есть определяют частные +аспекты деталей архитектуры. + +Чаще всего говорят о следующих группах шаблонов проектирования: + +- Шаблоны создания (Creational patterns) - builder, factory, prototype, +singleton +- Структурные шаблоны (Structural patterns) - adapter, bridge, composite, +decorator, facade, flyweight, proxy +- Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator, +mediator, memento, observer, state, strategy, template, visitor + +В SWEBOK данная тема, в силу упомянутого выше несоответствия между структурной +декомпозицией и описанием области знаний “проектирование”, имеет номер 3.2 +(следующая тема, в свою очередь, представлена в SWEBOK как 3.3). + +### Семейства программ и фреймворков (Families of Programs and Frameworks) + +Один из возможных подходов к повторному использованию архитектурных решений и +компонент заключается в формировании линий продуктов (product lines) на основе +общего дизайна. В объектно-ориентированном программировании аналогичную +смысловую нагрузку несут “фреймворки”, обеспечивающие решение одних и тех же +задач – например, внутренней организации компонентов пользовательского +интерфейса или общей логики работы распределенных систем. + +## Анализ качества и оценка программного дизайна (Software Design Quality Analysis and Evaluation) + +### Атрибуты качества (Quality Attributes) + +Существует целый спектр различных атрибутов, помогающих оценить и добиться +качественного дизайна. Эти атрибуты могут описывать многие характеристики +системы и элементов дизайна как такового – “тестируемость”, “переносимость”, +“модифицируемость”, “производительность”, “безопасность” и т.п. + +Важно понимать, что обсуждаемые атрибуты касаются только дизайна (как +результата), но не проектирования (как процесса). В принципе, все эти атрибуты +можно разбить на несколько групп: + +- применимые к run-time, то есть ко времени выполнения системы; например, +среднее время отклика системы позволяющий оценить качество дизайна с точки +зрения производительности; +- ориентированные на design-time, то есть позволяющие оценивать качество +получаемого дизайна еще на этапе проектирования или, в общем случае, вплоть до +тестирования, включительно; например, средняя нагруженность классов +бизнес-методами (предположим бизнес-методов в каждом классе в среднем 30 – +интересно, насколько легко можно поддерживать, модифицировать и развивать +систему с такой внутренней структурой....); +- атрибуты качества архитектурного дизайна как такового, например, +концептуальная целостность дизайна, непротиворечивость, полнота, завершенность; +например, любой определенный бизнес-метод является вызываемым, то есть создан +не просто потому что может понадобиться в будущем, а определен в соответствии с +требованиями или необходим для реализации дизайна в выбранном архитектурном +стиле. + +Необходимо понимать, что существуют атрибуты, которые сложно измерить. +Например, портируемость или безопасность. Не стоит путать атрибуты качества +дизайна с атрибутами качества, фигурируемыми в ряду требований, предъявляемых к +системе. Часть из них может отображаться друг на друга и нести эквивалентную +смысловую нагрузку, некоторые могут быть связаны, большая часть атрибутов +является специфичной именно для дизайна и не связана с требованиями. Например, +если мы используем платформу J2EE (Java 2 Enterprise Edition) и ориентируемся +на использование компонентой модели EJB (Enterprise JavaBeans), существуют +признаки хорошего дизайна, специфичные для данной платформы и компонентной +модели, но абсолютно никак не связанные с какими-либо требованиями к +создаваемой на этой платформе программной системе. Если вернуться к измеряемым +атрибутам качества, они описываются определенными метриками. Приведенный выше +пример с количеством бизнес-методов на класс является метрикой, относящейся к +теме 4.3 “Измерения”. Эта же метрика позволяет оценить атрибуты качества +“модифицируемость” и “сложность” системы. + +### Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques) + +В индустрии распространены многие инструменты, техники и практики, помогающие +добиться качественного дизайна: + +- обзор дизайна (software design review); например, неформальный обзор +архитектуры членами проектной команды; +- статический анализ (static analysis); например, трассировка с требованиями; +- симуляция и прототипирование (simulation and prototyping) – динамические +техники проверки дизайна в целом или отдельных его атрибутов качества; +например, для оценки производительности используемых архитектурных решений при +симуляции нагрузки, близкой к прогнозируемым пиковым; + +### Измерения (Measures) + +Также известные как метрики. Могут быть использованы для количественной оценки +ожиданий в отношении различных аспектов конкретного дизайна, например, размера +<проекта>, структуры (ее сложности) или качества (например, в контексте +требований, предъявляемых к производительности). Чаще всего, все метрики +разделяют по двум категориям: + +- функционально-ориентированные +- объектно-ориентированные + +## Нотации проектирования (Software Design Notations) + +Нотация есть соглашение о представлении. Часто под нотацией подразумевают +визуальное (графическое) представление. Нотация может задаваться: + +- стандартом; например, OMG UML – Unified Modeling Language, развиваемый +консорциумом OMG (Object Management Group, http://www.omg.org); +- общепринятой практикой; например, в eXtreme Programming часто используются +карточки функциональной ответственности и связей класса - Class Responsibility +Collaborator или CRC Card (CRC по свое природе является текстовой, то есть +невизуальной нотацией); +- внутренним методом проектной команды (“будем рисовать и обозначать так...”). + +Определенные нотации используются на стадии концептуального проектирования, ряд +нотаций ориентирован на создание детального дизайна, многие могут +использоваться на обеих стадиях. Кроме того, нотации чаще всего используют в +контексте (выбор нотации может быть обусловлен таким контекстом) применяемой +методологии или подхода (см. 6 “Software Design Strategies and Methods” данной +области знаний). Ниже мы будем рассматривать нотации, исходя из описания +структурного (статического) или поведенческого (динамического) представления. + +### Структурные описания, статический взгляд (Structural Descriptions, static view) + +Следующие нотации, в основном (но, не всегда), являются графическими, описывая +и представляя структурные аспекты программного дизайна. Чаще всего они касаются +основных компонент и связей между ними (статических связей, например, таких как +отношения “один-ко-многим”). + +- *Языки описания архитектуры (Architecture description language, ADL)*: +текстовые языки, часто – формальные, используемые для описания программной +архитектуры в терминах компонентов и коннекторов (специализированных +компонентов, реализующих не функциональность, но обеспечивающих взаимосвязь +функциональных компонентов между собой и с “внешним миром”); +- *Диаграммы классов и объектов (Class and object diagrams)*: используются для +представления набора классов и <статических> связей между ними (например, +наследования); +- *Диаграммы компонентов или компонентные диаграммы (Component diagrams)*: в +определенной степени аналогичны диаграммам классов, однако, в силу специфики +концепции или понятия компонента[^6], обычно, представляются в другой +визуальной форме; +- *Карточки <функциональной> ответственности и связей класса (Class +responsibility collaborator card, CRC)*: используются для обозначения имени +класса, его ответственности (то есть, что он должен делать) и других сущностей +(классов, компонентов, актёров/ролей и т.п.), с которыми он связан; часто их +называют карточками “класс-обязанность-кооперация”; +- *Диаграммы развёртывания (Deployment diagrams)*: используется для +представления (физических) узлов, связей между ними и моделирования других +физических аспектов системы; +- *Диаграммы сущность-связь (Entity-relationship diagram, ERD или ER)*: +используется для представления концептуальной модели данных, сохраняемых в +процессе работы информационной системы; +- *Языки описания/определения интерфейса (Interface Description Languages, +IDL)*: языки, подобные языкам программирования, не включающие возможностей +описания логики системы и предназначенные для определения интерфейсов +программных компонентов (имён и типов экспортируемых или публикуемых операций); +- *Структурные диаграммы Джексона (Jackson structure diagrams)*: используются +для описания структур данных в терминах последовательности, выбора и итераций +(повторений); +- *Структурные схемы (Structure charts)*: описываю структуру вызовов в +программах (какой модуль вызывает, кем и как вызываем). + +[^6]: Здесь необходимо отметить различие в понятиях класса (или объекта) и +компонента: компонент рассматривается как физически реализуемый элемент +программного обеспечения, несущий <в определенной степени> самодостаточную +логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде +комплекса классов); + +### Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view) + +Следующие нотации и языки (часть из которых – графические, часть - текстовые) +используются для описания динамического поведения программных систем и их +компонентов. Многие из этих нотаций успешно используются для проектирования +деталей дизайна, но не только для этого. + +- *Диаграммы деятельности или операций (Activity diagrams)*: используются для +описания потоков работ и управления; +- *Диаграммы сотрудничества (Collaboration diagrams)*: показывают динамическое +взаимодействие, происходящее в группе объектов и уделяют особое внимание +объектам, связям между ними и сообщениям, которыми обмениваются объекты +посредством этих связей; +- *Диаграммы потоков данных (Data flow diagrams, DFD)*: описывают потоки данных +внутри набора процессов (не в терминах процессов операционной среды, но в +понимании обмена информацией в бизнес-контексте); +- *Таблицы и диаграммы <принятия> решений (Decision tables and diagrams)*: +используются для представления сложных комбинаций условий и действий +(операций); +- *Блок-схемы и структурированные блок-схемы (Flowcharts and structured +flowcharts)*: применяются для представления потоков управления (контроля) и +связанных операций; +- *Диаграммы последовательности (Sequence diagrams)*: используются для показа +взаимодействий внутри группы объектов с акцентом на временной +последовательности сообщений/вызовов; +- *Диаграммы перехода и карты состояний(State transition and statechart +diagrams)*: применяются для описания потоков управления переходами между +состояниями; +- *Формальные языки спецификации (Formal specification languages)*: текстовые +языки, использующие основные понятия из математики (например, множества) для +строгого и абстрактного определения интерфейсов и поведения программных +компонентов, часто в терминах пред- и пост-условий; +- *Псевдокод и программные языки проектирования (Pseudocode and program design +languages, PDL)*: языки, используемые для описания поведения процедур и +методов, в основном на стадии детального проектирования; подобны структурным +языкам программирования. + +## Стратегии и методы проектирования программного обеспечения (Software Design Strategies and Methods) + +Существуют различные общие стратегии, помогающие в проведении работ по +проектированию. В отличие от общих стратегий, методы проектирования более +специфичны и, в основном, предлагают и предоставляют нотации (или наборы +нотаций) для использования совместно с этими методами, а также процессы, +которым необходимо следовать в рамках используемого метода. + +Таким образом, методы в данном контексте это не просто некие +“слабоформализованные” или просто частные практические подходы или техники. +Методы здесь являются более общими понятиями, это - методологии, +сконцентрированные на процессе (в частности, проектирования) и предполагающие +следование определенным правилам и соглашениям, в том числе – по используемым +выразительным средствам. Такие методы полезны как инструмент систематизации +(иногда, формализации) и передачи знаний в виде общего фреймворка (то есть +комплексного набора понятий, подходов, техник и инструментов) не только для +отдельных специалистов, но для команд и проектных групп программных проектов. + +### Общие стратегии (General Strategies) + +Это обычно часто упоминаемые и общепринятые стратегии: + +- “разделяй-и-властвуй” и пошаговое уточнение +- проектирование “сверху-вниз” и “снизу-вверх” +- абстракция данных и сокрытие информации +- итеративный и инкрементальный подход +- и другие... + +### Функционально-ориентированное или структурное проектирование (Function-Oriented – Structured Design) + +Это один из классических методов проектирования, в котором декомпозиция +сфокусирована на идентификации основных программных функций и, затем, детальной +разработке и уточнении этих функций “сверху-вниз”. Структурное проектирование, +обычно, используется после проведения структурного анализа с применением +диаграмм потоков данных и связанным описанием процессов. Исследователи +предлагают различные стратегии и метафоры или подходы для трансформации DFD в +программную архитектуру, представляемую в форме структурных схем. Например, +сравнивая управление и поведение с получаемым эффектом. + +### Объектно-ориентированное проектирование (Object-Oriented Design) + +Представляет собой множество методов проектирования, базирующихся на концепции +объектов. Данная область активно эволюционирует с середины 80-х годов, +основываясь на понятиях объекта (сущности), метода (действия) и атрибута +(характеристики). Здесь главную роль играют полиморфизм и инкапсуляция, в то +время, как в компонентно-ориентированном подходе большее значение придается +мета-информации, например, с применением технологии отражения (reflection). +Хотя корни объектно-ориентированного проектирования лежат в абстракции данных +(к которым добавлены поведенческие характеристики), так называемый +responsibility-driven design или проектирование на основе <функциональной> +ответственности по SWEBOK* может рассматриваться как альтернатива +объектно-ориентированному проектированию. + +*Такое противопоставление – достаточно спорный вопрос, так как функциональная +ответственность столь же близка принципам современного +объектно-ориентированного проектирования, сколь и абстракция данных. Это вопрос +эволюционирования взглядов и степени их консерватизма. + +### Проектирование на основе структур данных (Data-Structure-Centered Design) + +В данном подходе фокус сконцентрирован в большей степени на структурах данных, +которыми управляет система, чем на функциях системы. Инженеры по программному +обеспечению часто вначале описывают структуры данных входов (inputs) и выходов +(outputs), а, затем, разрабатывают структуру управления этими данными (или, +например, их трансформации). + +### Компонентное проектирование (Component-Based Design) + +Программные компоненты являются независимыми единицами, которые обладают +однозначно-определенными (well-defined) интерфейсами и зависимостями (связями) +и могут собираться и развертываться независимо друг от друга. Данный подход +призван решить задачи использования, разработки и интеграции таких компонент с +целью повышения повторного использования активов (как архитектурных, так и в +форме кода). + +Компонентно-ориентированное проектирование является одной из наиболее динамично +развивающихся концепций проектирования и может рассматриваться как предвестник +и основа сервисно-ориентированного подхода (Service-Oriented Architecture, SOA) +в проектировании, не рассматриваемого, к сожалению, в SWEBOK, но все более +активно использующегося в индустрии и смещающего акценты с аспектов организации +связи интерфейс-реализация к обмену информацией на уровне интерфейс-интерфейс +(то есть – межкомпонентному взаимодействию). По мнению автора книги, уже +наступил тот момент, когда необходимо вводить отдельную тему, посвященную +сервисно-ориентированному подходу в проектировании и сервисно-ориентированным +архитектурам, как моделям. В частности, нотация UML 2.0 уже позволяет решать +ряд вопросов, связанных с визуальным представлением соответствующих +архитектурных решений, где сервисы (службы) могут рассматриваться как +публикуемая функциональность одиночных компонентов и групп компонентов, +объединенных в более “крупные” блоки, обеспечивающие предоставление +соответствующей сервисной функциональности. + +### Другие методы (Other Methods) + +Другие интересные, но менее распространенные подходы, в основном, представляют +собой формальные и точные (строгие) методы, а также, методы трансформации. blob - e923769328017e0519ee8cb88a27a26dbde9f27c (mode 644) blob + /dev/null --- 3_software_construction.markdown +++ /dev/null @@ -1,547 +0,0 @@ -# Конструирование программного обеспечения - -Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - -SWEBOK. - -Содержит перевод описания области знаний SWEBOK “Software Construction”, с -замечаниями и комментариями. - -Конструирование программного обеспечения (Software Construction) - -Термин конструирование программного обеспечения (software construction) -описывает детальное создание рабочей программной системы посредством комбинации -кодирования, верификации (проверки), модульного тестирования (unit testing), -интеграционного тестирования и отладки. - -Данная область знаний связана с другими областями. Наиболее сильная связь -существует с проектированием (Software Design) и тестированием (Software -Testing). Причиной этого является то, что сам по себе процесс конструирования -программного обеспечения затрагивает важные аспекты деятельности по -проектированию и тестированию. Кроме того, конструирование отталкивается от -результатов проектирования, а тестирование (в любой своей форме) предполагает -работу с результатами конструирования. Достаточно сложно определить границы -между проектированием, конструированием и тестированием, так как все они -связаны в единый комплекс процессов жизненного цикла и, в зависимости от -выбранной модели жизненного цикла и применяемых методов (методологии), такое -разделение может выглядеть по разному. - -Хотя ряд операций по проектированию детального дизайна может происходить до -стадии конструирования, большой объем такого рода проектных работ происходит -параллельно с конструированием или как его часть. Это есть суть связи с -областью знаний “Проектирование программного обеспечения”. - -В свою очередь, на протяжении всей деятельности по конструированию, инженеры -используют модульное и интеграционное тестирование. Таким образом связана -данная область знаний с “Тестированием программного обеспечения”. - -В процессе конструирования обычно создается большая часть активов программного -проекта - конфигурационных элементов (configuration items). Поэтому в реальных -проектах просто невозможно рассматривать деятельность по конструированию в -отрыве от области знаний “Конфигурационного управления” (Software Configuration -Management). - -Так как конструирование невозможно без использования соответствующего -инструментария и, вероятно, данная деятельность является наиболее -инструментально-насыщенной, важную роль в конструировании играет область знаний -“Инструменты и методы программной инженерии” (Software Engineering Tools and -Methods). - -Безусловно, вопросы обеспечения качества значимы для всех областей знаний и -этапов жизненного цикла. В то же время, код является основным результирующим -элементом программного проекта. Таким образом, явно напрашивается и -присутствует связь обсуждаемых вопросов с областью знаний “Качество -программного обеспечения” (Software Quality). - -Из связанных дисциплин программной инженерии (Related Disciplines of Software -Engineering) наиболее тесная и естественная связь данной области знаний -существует с компьютерными науками (computer science). Именно в них, обычно, -рассматриваются вопросы построения и использования алгоритмов и практик -кодирования. Наконец, конструирование касается и управления проектами (project -management), причем, в той степени, насколько деятельность по управлению -конструированием важна для достижения результатов конструирования. - -![Рисунок 4. Область знаний “Конструирование программного обеспечения” [SWEBOK, 2004, с.4-2, рис. 1]](images/construction_area.jpg) - -## Основы конструирования (Software Construction Fundamentals) - -Фундаментальные основы конструирования программного обеспечения включают: - -- Минимизация сложности -- Ожидание изменений -- Конструирование с возможностью проверки -- Стандарты в конструировании - -Первые три концепции применяются не только к конструированию, но и -проектированию, и лежат в основе современных методологий управления жизненным -циклом программных систем. - -### Минимизация сложности (Minimizing Complexity) - -Основной причиной того, почему люди используют компьютеры в бизнес-целях, -являются ограниченные возможности людей в обработке и хранении сложных структур -и больших объемов информации, в частности, на протяжении длительного периода -времени. Это соображение является одной из основных движущих сил в -конструировании программного обеспечения: минимизация сложности. Потребность в -уменьшении сложности влияет на все аспекты конструирования и особенно критична -для процессов верификации (проверки) и тестирования результатов -конструирования, т.е. самих программных систем. - -Уменьшение сложности в конструировании программного обеспечения достигается при -уделении особого внимания созданию простого и легко читаемого кода, пусть и в -ущерб стремлению сделать его идеальным (например, с точки зрения гибкости или -следования тем или иным представлениям о красоте, утончённости кода, ловкости -тех или иных приемов, позволяющих его сократить в ущерб размерам и т.п.). Это -не значит, что должно ущемляться применение тех или иных развитых языковых -возможностей используемых средств программирования. Это подразумевает “лишь” -придание большей значимости читаемости кода, простоте тестирования, приемлемому -уровню производительности и удовлетворению заданных критериев, вместо -постоянного совершенствования кода, не оглядываясь на сроки, функциональность и -другие характеристики и ограничения проекта. - -Минимизация сложности достигается, в частности, следованием стандартам -(обсуждаются в теме 1.4 “Стандарты в конструировании”), использованием ряда -специфических техник (освещаются в 3.3 “Кодирование”) и поддержкой практик, -направленных на обеспечение качества в конструировании (3.5 “Качество -конструирования”). - -### Ожидание изменений (Anticipating Changes) - -Большинство программных систем изменяются с течением времени. Причин этому – -множество. Ожидание изменений является одной из движущих сил конструирования -программного обеспечения. Программное обеспечение не является изолированным от -внешнего окружения (как системного, так и с точки зрения области деятельности, -для автоматизации задач и проблем которого оно применяется). Более того, -программные системы являются частью изменяющейся среды и должны меняться вместе -с ней, а, иногда, и быть источником изменений самой среды. - -Ожидание изменений поддерживается рядом техник, представленных в теме 3.3 -“Кодирование”. - -### Конструирование с возможностью проверки (Constructing for Verification) - -“Конструирование для проверки” (а именно такой смысл заложен в оригинальное -название данной темы) предполагает, что построение программных систем должно -вестись таким образом, чтобы сама программная система помогала вести поиск -причин сбоев, будучи прозрачной для применения различных методов проверки (и, -кстати, внесения необходимых изменений), как на стадии независимого -тестирования (например, инженерами-тестировщиками), так и в процессе -операционной деятельности - эксплуатации, когда особенно важна возможность -быстрого обнаружения и исправления возникающих ошибок. - -Среди техник, направленных на достижение такого результата конструирования: - -- обзор, оценка кода (code review) -- модульное тестирование (unit-testing) -- структурирование кода для автоматизированных средств тестирования (automated testing) -- ограниченное применение сложных или тяжелых для понимания языковых структур - -### Стандарты в конструировании (Standards in Constructing) - -Стандарты, которые напрямую применяются при конструировании, включают: - -- коммуникационные методы (например, стандарты форматов документов и -<оформления> содержания) -- языки программирования и соответствующие стили кодирования (например, Java -Language Specification, являющийся частью стандартной документации JDK – Java -Development Kit и Java Style Guide, предлагающий общий стиль кодирования для -языка программирования Java) -- платформы (например, стандарты программных интерфейсов для вызовов функций -операционной среды, такие как прикладные программные интерфейсы платформы -Windows - Win32 API, Application Programming Interface или .NET Framework SDK, -Software Development Kit) -- инструменты (не в терминах сред разработки, но возможных средств -конструирования – например, UML как один из стандартов для определения нотаций -для диаграмм, представляющих структура кода и его элементов или некоторых -аспектов поведения кода) - -Использование внешних стандартов. Конструирование зависит от внешних -стандартов, связанных с языками программирования, используемым инструментальным -обеспечением, техническими интерфейсами и взаимным влиянием Конструирования -программного обеспечения и других областей знаний программной инженерии (в том -числе, связанных дисциплин, например, управления проектами). Стандарты -создаются разными источниками, например, консорциумом OMG – Object Management -Group (в частности. Стандарты CORBA, UML, MDA, …), международными организациями -по стандартизации такими, как ISO/IEC, IEEE, TMF, …, производителями платформ, -операционных сред и т.д. (например, Microsoft, Sun Microsystems, CISCO, NOKIA, -…), производителями инструментов, систем управления базами данных ит.п. -(Borland, IBM, Microsoft, Sun, Oracle, ...). Понимание этого факта позволяет -определить достаточный и полный набор стандартов, применяемых в проектной -команде или организации в целом. - -Использование внутренних стандартов. Определенные стандарты, соглашения и -процедуры могут быть также созданы внутри организации или даже проектной -команды. Эти стандарты поддерживают координацию между определенными видами -деятельности, группами операций, минимизируют сложность (в том числе при -взаимодействии членов проектной группы и за ее пределами), могут быть связаны с -вопросами ожидания и обработки изменений, рисков и вопросами конструирования -для проверки и дальнейшего тестирования. В сочетании со внешними стандартами, -внутренние стандарты призваны определить общие правила игры для всех членов -проектной команды, договорившись о терминах, процедурах и других значимых -соглашениях, вне зависимости от степени формализации процессов конструирования, -в частности, и процессов жизненного цикла, в общем случае. - -## Управление конструированием (Managing Construction) - -### Модели конструирования (Construction Models) - -Модели конструирования определяют комплекс операций, включающих -последовательность, результаты (например, исходный код и соответствующие -unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. В -большинстве случаев, модели конструирования определяются используемым -стандартом жизненного цикла, применяемыми методологиями и практиками. Некоторые -стандарты жизненного цикла, по своей природе, являются ориентированными на -конструирование – например, экстремальное программирование (XP- eXtreme -Programming). Некоторые рассматривают конструирование в неразрывной связи с -проектированием (в части моделирования), например, RUP (Rational Unified -Process). - -Создано множество моделей разработки программного обеспечения. Ряд из них в -большей степени сфокусирован на конструировании программного обеспечения, как -таковом. - -Некоторые модели являются более линейными с точки зрения конструирования ПО. К -ним относятся, например, водопадная (waterfall) и поэтапная (staged-delivery) -модели жизненного цикла (моделям жизненного цикла посвящена специальная глава, -написанная Сергеем Орликом и доступная как часть представленных здесь "Основ -программной инженерии"). Эти модели рассматривают конструирование как -деятельность, которая начинает проводиться только после завершения определенных -обязательных к выполнению (prerequisite) работ, включающих детальное -определение требований, подробный дизайн и детальное планирование. Более -линейные подходы стараются подчеркнуть действия, предваряющие конструирование -(т.е. требования и дизайн) и создать более четкое разделение между такими -различными типами деятельности. В таких моделях основным содержанием -конструирования может быть кодирование. - -Другие модели более итеративны, к ним относятся – эволюционное -прототипирование, экстремальное программирование и Scrum. Эти подходы сходятся -к рассмотрению конструирования как деятельности, которая ведется одновременно -с другими видами работ по созданию программного обеспечения и пересекаясь с -ними (видимо, здесь имеется в виду взаимозависимость и влияние друг на друга), -включая определение требований, проектирование и планирование. Эти подходы -смешивают проектирование, кодирование и тестирование, часто рассматривая их -комбинацию как конструирование. - -Соответственно, что именно подразумевается под “конструированием” зависит в -определенной степени от используемой модели жизненного цикла. - -### Планирование конструирования (Construction Planning) - -Выбор метода (методологии) конструирования является ключевым аспектом для -планирования конструкторской деятельности. Такой выбор значим для всей -конструкторской деятельности, а также необходимых условий её осуществления, -определяя порядок соответствующих операций и уровень выполнения заданных -условий перед тем как начнется конструирование или составляющие его действия. -Например, модульное тестирование в ряде методов является частью работ, после -написания соответствующего функционального кода, в то время, как ряд гибких -(agile) практик, например, XP (кстати, первыми начавшие использовать такие -методы верификации кода), требуют написания Unit-тестов до того, как пишется -соответствующий код, требующий тестирования. - -Используемый подход к конструированию влияет на возможность уменьшения (в -идеале - минимизации) сложности, готовности к изменениям и конструировании с -возможностью проверки. - -Планирование конструкторской деятельности определяет порядок, в котором -создаются компоненты и другие активы данной области знаний (фазы деятельности), -проводятся работы по обеспечению качества получаемого программного обеспечения, -распределяются* задачи и соответствующие ресурсы, в том числе, определяются -назначения/отображения работ конкретным инженерам-программистам, членам -проектной группы. Все это, конечно, происходит, следуя правилам, определяемым -используемым методом (методологией, практиками и т.п.). - -*Заметьте – не распределяют, а распределяются, подразумевая процесс, приводящий -к обеспечению явной связи между задачей и ресурсами. В нечетко -регламентированных (это ни в коем случае не ругательство, это определение – -ведь существует же понятие нечёткая логика, неструктурированные базы данных, -например, в отношении нереляционных систем и т.п.) и неформальных методах, -таких, как XP, члены проектной группы сами принимают на себя ответственность по -решению определенных задач, а “владение” кодом является совместным на основе -сотрудничества, как одного из ключевых принципов работы проектной команды. - -### Измерения в конструировании (Construction Measurement) - -Большая часть результатов, да и самой деятельности по конструированию -программного обеспечения, может быть измерена, в том числе - количественно. Это -и исходный разработанный код, и модифицированный объем кода, и степень -повторного использования, и многие другие характеристики. Эти измерения, или -как их еще принято называть – результаты аудита кода и метрики кода, несут -большую пользу как для оценки рисков и качества (приводящих к соответствующим -операциям по снижению рисков и повышению качества), а также, для управления -конструированием и программными проектами, в целом. О каком планировании может -идти речь, если мы не способны предсказать (например, на основе оценки -результатов предыдущих проектов) ни длительность работ, ни стоимость отдельных -задач, ни вероятность возникновения дефектов против заданных параметров -приемлемого качества? - -Код является одним из наиболее четко детерминированных активов проекта -(постепенно такими становятся и модели, строящиеся на основе структур -метаданных, и тесно связанные с кодом - например, UML). Код является и самим -носителям требуемой функциональности. Соответственно, применение измерений в -отношении кода становится тем инструментом, который влияет и на управление и на -сам код. - -Последнее время, большое внимание многие профессиональные разработчики, то есть -инженеры-конструкторы программного обеспечения, уделяют рефакторинг кода, как -методы его реструктурирования, призванные без изменения содержания (то есть -функциональности и функциональной целостности) обеспечить решение задач -минимизации сложности, готовности к изменениям (гибкости), прозрачности -документирования и многих других актуальных аспектов конструирования. Но, к -сожалению, многие забывают о необходимости мотивированности изменений, даже на -уровне рефакторинга. Применение измерений, в частности, метрик, позволяет -определить необходимость внесения таких изменений, проведения рефакторинга. И -не потому что “так, наверное, будет всё же лучше, красивше...”, а потому, что в -иерархии наследования из 10 поколений классов – 9 являются абстрактными (“из -любви к искусству”), а на 10-м (в силу превышений сроков проекта, после того, -как долго и “в кайф” создавали архитектурно-красивый код) “повешено” 20 (!) -бизнес-методов. Вот это – действительно обоснованная причина для рефакторинга, -который, даже с применением самых совершенных инструментальных средств, вместе -с обдумыванием необходимости рефакторинга, а потом, иногда, и борьбой с его -последствиями из-за несогласованности членов команды (а это уже жизнь, даже в -самом идеальном коллективе, где люди понимают друг друга с полуслова) часто -является просто тратой времени. Если применяется рефакторинг, но не применяются -метрики – в подавляющем большинстве случаев, это отрицательно влияет на проект. -И таких примеров работ, требующих применения измерений, но, к несчастью, -игнорирующих их, можно приводить достаточно долго. Вы, наверняка, сами можете -рассказать на эту тему много примеров из жизни. - -Почему “авторизованный перевод” этой темы SWEBOK оказался столь эмоционален? -Практика автора показывает, что в погоне за “красотой”, разработчики слишком -часто забывают о цели их работы и воспринимают деятельность по управлению -проектами (не буду спорить, иногда лишь формальную, для “прикрытия” всего, что -только можно …) со стороны менеджеров и, тем более, любой аудит – как -однозначную помеху “полёту мысли”. Зря. Если все именно так обстоит в вашем -случае – проект, с большой вероятностью, а иногда и просто, “если не случится -чудо”, можно считать пусть и не провальным (“фуух... не закрыли....”), то, -наверняка, выйдущим за рамки тех или иных ограничений, будь то сроки, деньги, -качество или, наконец, время, которое разработчик мог провести с семьей. И не -сидеть ночью, дописывая функциональность или отлавливая очередную ошибку за -несколько дней до передачи проекта в эксплуатацию. Все эти вопросы преследуют -одну единственную цель – предсказуемость работ и результата. И измерения – -важный инструмент достижения этой цели. - -Область знаний “Software Engineering Process” уделяет специальное внимание -вопросам измерений при создании программного обеспечения. - -## Практические соображения (Practical Considerations) - -Конструирование – деятельность, в рамках которой программное обеспечение -приводится к соглашению с произвольными (иногда - хаотическими) ограничениями -реального мира, которые требуют от программного обеспечения точного следования -им. Приближаясь к ограничениям реального мира, конструирование (в большей -степени, чем любая другая область знаний) ведется на основе практических -соображений и техник. - -### Проектирование в конструировании (Construction Design) - -Некоторые проекты предполагают больший объем работ по проектированию именно на -стадии конструирования; другие проекты явно выделяют проектную деятельность в -форме фазы дизайна. Вне зависимости от четкости выделения деятельности по -проектированию, как таковой, практически всегда на стадии конструирования -приходится заниматься и вопросами детального дизайна системы. Такие проектные -работы имеют стремление к следованию устойчивым ограничениям, навязываемым -конкретными проблемами, решение которых должно быть обеспечено использованием -конструируемой программной системы. - -Детали деятельности по проектированию на стадии конструирования в основном те -же самые, что и описанные в области знаний “Проектирование программного -обеспечения” (Software Design). Отличие заключается в большем внимании деталям. - -### Языки конструирования (Construction Languages) - -Языки конструирования включают все формы коммуникаций, с помощью которых -человек может задать решение проблемы, выполняемое на компьютере. - -Простейший тип языков конструирования – *конфигурационный язык (configuration -language)*, позволяющий задавать параметры выполнения программной системы. - -*Инструментальный язык (toolkit language)* – язык конструирования из -повторно-используемых элементов; обычно строится как сценарный язык (script), -выполняемый в соответствующей среде. - -*Язык программирования (programming language)* – наиболее гибкий тип языков -конструирования. Содержит минимальный объем информации о конкретных областях -приложения и процессе разработки, требуя больше всего (по сравнению с другими -типами языков конструирования) усилий на изучение и наработку опыта для -эффективного применения при решении конкретных задач. - -Существует три основных вида нотаций используемых при определении языков -программирования: - -- лингвистическая -- формальная -- визуальная - -*Лингвистические нотации* характеризуются, в частности, использованием строк -текста, содержащих специализированные “слова”, представляющие сложные -программные конструкции, и комбинируемые в шаблоны, напоминающие предложения, -построенные в соответствии с определенным синтаксисом. В случае корректного -использования таких нотаций, каждая получаемая строка обладает строгой -смысловой нагрузкой (семантикой), обеспечивающей интуитивное понимание того, -что будет происходить когда будет выполняться программное обеспечение, -построенное с использованием такого языка конструирования. - -Формальные нотации являются менее интуитивными, чем лингвистические, и часто -базируются на точных формальных (математических) определениях. Формальные -нотации конструкций и формальные методы являются ядром практически всех форм -системного программирования, точнее – поведения систем во времени. Такие -нотации обеспечивают наибольшую готовность получаемого кода к тестированию, что -намного важнее, чем просто возможность отображения на обычный человеческий -язык. Формальные конструкции также используют точный метод определения -комбинаций применяемых символов, что позволяет избежать неоднозначностей, -присущих конструкциям естественных языков. - -*Визуальные нотации* наименее связаны с текстово-ориентированными подходами, -предполагая непосредственную интерпретацию визуальных конструкций в процессе -исполнения описываемой логики. При этом логика в визуальных нотациях задается -расположением соответствующих визуальных сущностей, ответственных за те или -иные операции и структуры данных. - -Использование визуальных конструкций ограничено сложностью визуального -представления сложных выражений и утверждений только за счет перемещения -визуальных сущностей на диаграмме (визуальном представлении). Однако, -визуальная нотация может играть роль достаточно мощного инструмента, когда -применяется в тех задачах программирования, где необходимо построение -пользовательского интерфейса. - -Сегодняшние работы (и их состояние) в области архитектур и приложений, -управляемых моделями, в первую очередь - OMG MDA (Model-Driven Architecture -www.omg.org/mda)/UML (Unified Modeling Language www.omg.org/uml), Microsoft DSL -(Domain-Specific Language), направлены на то, чтобы использовать ту или иную -визуальную нотацию, базирующуюся на мета-моделях, в качестве инструмента, -применяемого и для определения функциональной логики системы. Можно ли в чистом -виде считать эти нотации именно визуальными - вопрос спорный. Но в терминах, -предлагаемых SWEBOK, они относятся именно к визуальным нотациям, так как -предполагают однозначную интерпретацию визуального представления в виде текста -и наоборот. Кроме того, исторически эти нотации определялись изначально как -нотации визуального представления функциональности и уже в дальнейшем эти -визуальные представления были отражены на уровне соответствующих мета-моделей -(хотя это в большей степени верно для UML, чем DSL, но DSL можно рассматривать -и как аналог UML, предполагающий бо́льшую свободу применений и интегрированность -с конкретной платформой - Microsoft). Другая область стандартов, направленных -на применение визуальных нотаций для описания функциональности – Business -Process Management Notation (BPMN - www.omg.org/bpmn) и связанный с ней язык -Business Process Execution Language, построенный на базе XML. Таким образом, -область обоснованного применения визуальных нотаций для конструирования -программных систем качественно расшириться и, не исключено, мы станем -свидетелями де-факто формирования новой категории нотаций, соглашений и -смешанных типов языковых средств, предназначенных для конструирования -программного обеспечения как естественного продолжения проектирования. - -### Кодирование (Coding) - -Практика конструирования программного обеспечения показывает активное -применение следующих соображений и техник: - -- техники создания легко понимаемого исходного кода на основе использования -соглашений об именовании, форматирования и структурирования кода; -- использование классов, перечисляемых типов, переменных, именованных констант -и других выразительных сущностей; -- организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и -другие структуры) -- использование структур управления; -- обработка ошибочных условий и исключительных ситуаций; -- предотвращение возможных брешей в безопасности (например, переполнение буфера -или выход за пределы индекса в массиве) -- использование ресурсов на основе применения механизмов исключения (из -рассмотрения) и порядка доступа к параллельно используемым ресурсам (например, -на основе блокировки данных, использования потоков и их синхронизации и т.п.) -- документирование кода -- тонкая “настройка” кода -- рефакторинг (не упоминается SWEBOK) - -### Тестирование в конструировании (Construction Testing) - -При конструировании используются две формы тестирования, проводимого -инженерами, непосредственно создающими исходный код: - -- модульное тестирование (unit testing) -- интеграционное тестирование (integration testing) - -Главная цель тестирования в конструировании уменьшить временной разрыв между -моментом проявления ошибок, имеющихся в коде, и моментом их обнаружения. Во -многих случаях, тестирование в конструировании производится после того, как код -написан. В ряде случаев, тесты (что отмечалось ранее, на примере XP) пишутся до -того, как создается код. - -Тестировании в конструировании обычно включает подмножество видов тестирования, -описанных в области знаний “Тестирование программного обеспечения” (Software -Testing). Например, тестирование в конструировании обычно не включает -системного тестирования, нагрузочного тестирования, usability-тестирования -(оценки прозрачности использования) и других видов тестовой деятельности. - -IEEE опубликовал два стандарта, посвященных данной теме: - -- IEEE Std 829-1998: “IEEE Standard for Software Test Documentation” -- IEEE Std 1008-1987: “IEEE Standard for Software Unit Testing” - -Напрямую с данной темой связаны под-темы SWEBOK 2.1.1 “Unit Testing” и 2.1.2 -“Integration Testing”. - -### Повторное использование (Reuse) - -Во введении в стандарт IEEE Std. 1517-99 “IEEE Standard for Information -Technology – Software Lifecycle Process – Reuse Processes” даётся следующее -понимание повторному использованию в программном обеспечении: “Реализация -повторного использования программного обеспечения подразумевает и влечёт за -собой нечто большее, чем просто создание и использование библиотек активов. Оно -требует формализации практики повторного использования на основе интеграции -процессов и деятельности по повторному использованию в сам жизненный цикл -программного обеспечения.” В то же время, повторное использование достаточно -важно и непосредственно при конструировании программных систем, что -подчеркивается включением этой темы в обсуждаемую область знаний -конструирования ПО. - -Задачи, связанные с повторным использованием в процессе конструирования и -тестирования, включают: - -- выбор единиц (units), баз данных тестовых процедур, данных <полученных в -результате> тестов и самих тестов, подлежащих повторному использованию -- оценку потенциала повторного использования кода и тестов -- отслеживание информации и создание отчетности по повторному использованию в -новом коде, тестовых процедурах и данных, полученных в результате тестов. - -### Качество конструирования (Construction Quality) - -Существует ряд техник, предназначенных для обеспечения качества кода, -выполняемых по мере его конструирования. Основные техники обеспечения качества, -используемые в процессе конструирования, включают: - -- модульное (unit) и интеграционное (integration) тестирование -- разработка с первичностью тестов (test-first development - тесты пишутся до -конструирования кода) -- пошаговое кодирование (деятельность по конструированию кода разбивается на -мелкие шаги, только после тестирования результатов которых производится переход -к следующему шагу кодирования; известен также как итеративное кодирование с -тестированием) -- использование процедур утверждений (assertion) -- отладка (в привычном понимании - debugging) -- технические обзоры и оценки (review) -- статический анализ - -Выбор и использование конкретных техник часто диктуется стандартами -(внутренними и внешними), используемыми проектной командой, а также зависят от -опыта и подготовленности специалистов, занимающихся конструированием кода. - -Деятельность по обеспечению качества в конструировании отличается от других -операций по обеспечению качества. Основное отличие заключается в фокусе на -программном (исходном) коде и других артефактах (активах), тесно связанных с -кодом, в частности, детальных моделях. - -### Интеграция (Integration) - -Одна из ключевых деятельностей, осуществляемых в процессе конструирования, - -интеграция отдельно сконструированных операций (процедур), классов, компонентов -и подсистем (модулей). В дополнение к этому, некоторые программные системы -нуждаются в специальной интеграции с другим программным и аппаратным -обеспечением. - -Кроме упомянутых аспектов интеграции, к обсуждаемым интеграционным вопросам -конструирования относятся: - -- планирование последовательности, в которой интегрируются компоненты; -- обеспечение поддержки создания промежуточных версий программного обеспечения; -- задание “глубины” тестирования (в частности, на основе критериев -“приемлемого” качества) и других работ по обеспечению качества интегрируемых в -дальнейшем компонент; -- наконец, определение этапных точек проекта, когда будут тестироваться -промежуточные версии конструируемой программной системы. blob - /dev/null blob + e923769328017e0519ee8cb88a27a26dbde9f27c (mode 644) --- /dev/null +++ 3_software_construction.md @@ -0,0 +1,547 @@ +# Конструирование программного обеспечения + +Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - +SWEBOK. + +Содержит перевод описания области знаний SWEBOK “Software Construction”, с +замечаниями и комментариями. + +Конструирование программного обеспечения (Software Construction) + +Термин конструирование программного обеспечения (software construction) +описывает детальное создание рабочей программной системы посредством комбинации +кодирования, верификации (проверки), модульного тестирования (unit testing), +интеграционного тестирования и отладки. + +Данная область знаний связана с другими областями. Наиболее сильная связь +существует с проектированием (Software Design) и тестированием (Software +Testing). Причиной этого является то, что сам по себе процесс конструирования +программного обеспечения затрагивает важные аспекты деятельности по +проектированию и тестированию. Кроме того, конструирование отталкивается от +результатов проектирования, а тестирование (в любой своей форме) предполагает +работу с результатами конструирования. Достаточно сложно определить границы +между проектированием, конструированием и тестированием, так как все они +связаны в единый комплекс процессов жизненного цикла и, в зависимости от +выбранной модели жизненного цикла и применяемых методов (методологии), такое +разделение может выглядеть по разному. + +Хотя ряд операций по проектированию детального дизайна может происходить до +стадии конструирования, большой объем такого рода проектных работ происходит +параллельно с конструированием или как его часть. Это есть суть связи с +областью знаний “Проектирование программного обеспечения”. + +В свою очередь, на протяжении всей деятельности по конструированию, инженеры +используют модульное и интеграционное тестирование. Таким образом связана +данная область знаний с “Тестированием программного обеспечения”. + +В процессе конструирования обычно создается большая часть активов программного +проекта - конфигурационных элементов (configuration items). Поэтому в реальных +проектах просто невозможно рассматривать деятельность по конструированию в +отрыве от области знаний “Конфигурационного управления” (Software Configuration +Management). + +Так как конструирование невозможно без использования соответствующего +инструментария и, вероятно, данная деятельность является наиболее +инструментально-насыщенной, важную роль в конструировании играет область знаний +“Инструменты и методы программной инженерии” (Software Engineering Tools and +Methods). + +Безусловно, вопросы обеспечения качества значимы для всех областей знаний и +этапов жизненного цикла. В то же время, код является основным результирующим +элементом программного проекта. Таким образом, явно напрашивается и +присутствует связь обсуждаемых вопросов с областью знаний “Качество +программного обеспечения” (Software Quality). + +Из связанных дисциплин программной инженерии (Related Disciplines of Software +Engineering) наиболее тесная и естественная связь данной области знаний +существует с компьютерными науками (computer science). Именно в них, обычно, +рассматриваются вопросы построения и использования алгоритмов и практик +кодирования. Наконец, конструирование касается и управления проектами (project +management), причем, в той степени, насколько деятельность по управлению +конструированием важна для достижения результатов конструирования. + +![Рисунок 4. Область знаний “Конструирование программного обеспечения” [SWEBOK, 2004, с.4-2, рис. 1]](images/construction_area.jpg) + +## Основы конструирования (Software Construction Fundamentals) + +Фундаментальные основы конструирования программного обеспечения включают: + +- Минимизация сложности +- Ожидание изменений +- Конструирование с возможностью проверки +- Стандарты в конструировании + +Первые три концепции применяются не только к конструированию, но и +проектированию, и лежат в основе современных методологий управления жизненным +циклом программных систем. + +### Минимизация сложности (Minimizing Complexity) + +Основной причиной того, почему люди используют компьютеры в бизнес-целях, +являются ограниченные возможности людей в обработке и хранении сложных структур +и больших объемов информации, в частности, на протяжении длительного периода +времени. Это соображение является одной из основных движущих сил в +конструировании программного обеспечения: минимизация сложности. Потребность в +уменьшении сложности влияет на все аспекты конструирования и особенно критична +для процессов верификации (проверки) и тестирования результатов +конструирования, т.е. самих программных систем. + +Уменьшение сложности в конструировании программного обеспечения достигается при +уделении особого внимания созданию простого и легко читаемого кода, пусть и в +ущерб стремлению сделать его идеальным (например, с точки зрения гибкости или +следования тем или иным представлениям о красоте, утончённости кода, ловкости +тех или иных приемов, позволяющих его сократить в ущерб размерам и т.п.). Это +не значит, что должно ущемляться применение тех или иных развитых языковых +возможностей используемых средств программирования. Это подразумевает “лишь” +придание большей значимости читаемости кода, простоте тестирования, приемлемому +уровню производительности и удовлетворению заданных критериев, вместо +постоянного совершенствования кода, не оглядываясь на сроки, функциональность и +другие характеристики и ограничения проекта. + +Минимизация сложности достигается, в частности, следованием стандартам +(обсуждаются в теме 1.4 “Стандарты в конструировании”), использованием ряда +специфических техник (освещаются в 3.3 “Кодирование”) и поддержкой практик, +направленных на обеспечение качества в конструировании (3.5 “Качество +конструирования”). + +### Ожидание изменений (Anticipating Changes) + +Большинство программных систем изменяются с течением времени. Причин этому – +множество. Ожидание изменений является одной из движущих сил конструирования +программного обеспечения. Программное обеспечение не является изолированным от +внешнего окружения (как системного, так и с точки зрения области деятельности, +для автоматизации задач и проблем которого оно применяется). Более того, +программные системы являются частью изменяющейся среды и должны меняться вместе +с ней, а, иногда, и быть источником изменений самой среды. + +Ожидание изменений поддерживается рядом техник, представленных в теме 3.3 +“Кодирование”. + +### Конструирование с возможностью проверки (Constructing for Verification) + +“Конструирование для проверки” (а именно такой смысл заложен в оригинальное +название данной темы) предполагает, что построение программных систем должно +вестись таким образом, чтобы сама программная система помогала вести поиск +причин сбоев, будучи прозрачной для применения различных методов проверки (и, +кстати, внесения необходимых изменений), как на стадии независимого +тестирования (например, инженерами-тестировщиками), так и в процессе +операционной деятельности - эксплуатации, когда особенно важна возможность +быстрого обнаружения и исправления возникающих ошибок. + +Среди техник, направленных на достижение такого результата конструирования: + +- обзор, оценка кода (code review) +- модульное тестирование (unit-testing) +- структурирование кода для автоматизированных средств тестирования (automated testing) +- ограниченное применение сложных или тяжелых для понимания языковых структур + +### Стандарты в конструировании (Standards in Constructing) + +Стандарты, которые напрямую применяются при конструировании, включают: + +- коммуникационные методы (например, стандарты форматов документов и +<оформления> содержания) +- языки программирования и соответствующие стили кодирования (например, Java +Language Specification, являющийся частью стандартной документации JDK – Java +Development Kit и Java Style Guide, предлагающий общий стиль кодирования для +языка программирования Java) +- платформы (например, стандарты программных интерфейсов для вызовов функций +операционной среды, такие как прикладные программные интерфейсы платформы +Windows - Win32 API, Application Programming Interface или .NET Framework SDK, +Software Development Kit) +- инструменты (не в терминах сред разработки, но возможных средств +конструирования – например, UML как один из стандартов для определения нотаций +для диаграмм, представляющих структура кода и его элементов или некоторых +аспектов поведения кода) + +Использование внешних стандартов. Конструирование зависит от внешних +стандартов, связанных с языками программирования, используемым инструментальным +обеспечением, техническими интерфейсами и взаимным влиянием Конструирования +программного обеспечения и других областей знаний программной инженерии (в том +числе, связанных дисциплин, например, управления проектами). Стандарты +создаются разными источниками, например, консорциумом OMG – Object Management +Group (в частности. Стандарты CORBA, UML, MDA, …), международными организациями +по стандартизации такими, как ISO/IEC, IEEE, TMF, …, производителями платформ, +операционных сред и т.д. (например, Microsoft, Sun Microsystems, CISCO, NOKIA, +…), производителями инструментов, систем управления базами данных ит.п. +(Borland, IBM, Microsoft, Sun, Oracle, ...). Понимание этого факта позволяет +определить достаточный и полный набор стандартов, применяемых в проектной +команде или организации в целом. + +Использование внутренних стандартов. Определенные стандарты, соглашения и +процедуры могут быть также созданы внутри организации или даже проектной +команды. Эти стандарты поддерживают координацию между определенными видами +деятельности, группами операций, минимизируют сложность (в том числе при +взаимодействии членов проектной группы и за ее пределами), могут быть связаны с +вопросами ожидания и обработки изменений, рисков и вопросами конструирования +для проверки и дальнейшего тестирования. В сочетании со внешними стандартами, +внутренние стандарты призваны определить общие правила игры для всех членов +проектной команды, договорившись о терминах, процедурах и других значимых +соглашениях, вне зависимости от степени формализации процессов конструирования, +в частности, и процессов жизненного цикла, в общем случае. + +## Управление конструированием (Managing Construction) + +### Модели конструирования (Construction Models) + +Модели конструирования определяют комплекс операций, включающих +последовательность, результаты (например, исходный код и соответствующие +unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. В +большинстве случаев, модели конструирования определяются используемым +стандартом жизненного цикла, применяемыми методологиями и практиками. Некоторые +стандарты жизненного цикла, по своей природе, являются ориентированными на +конструирование – например, экстремальное программирование (XP- eXtreme +Programming). Некоторые рассматривают конструирование в неразрывной связи с +проектированием (в части моделирования), например, RUP (Rational Unified +Process). + +Создано множество моделей разработки программного обеспечения. Ряд из них в +большей степени сфокусирован на конструировании программного обеспечения, как +таковом. + +Некоторые модели являются более линейными с точки зрения конструирования ПО. К +ним относятся, например, водопадная (waterfall) и поэтапная (staged-delivery) +модели жизненного цикла (моделям жизненного цикла посвящена специальная глава, +написанная Сергеем Орликом и доступная как часть представленных здесь "Основ +программной инженерии"). Эти модели рассматривают конструирование как +деятельность, которая начинает проводиться только после завершения определенных +обязательных к выполнению (prerequisite) работ, включающих детальное +определение требований, подробный дизайн и детальное планирование. Более +линейные подходы стараются подчеркнуть действия, предваряющие конструирование +(т.е. требования и дизайн) и создать более четкое разделение между такими +различными типами деятельности. В таких моделях основным содержанием +конструирования может быть кодирование. + +Другие модели более итеративны, к ним относятся – эволюционное +прототипирование, экстремальное программирование и Scrum. Эти подходы сходятся +к рассмотрению конструирования как деятельности, которая ведется одновременно +с другими видами работ по созданию программного обеспечения и пересекаясь с +ними (видимо, здесь имеется в виду взаимозависимость и влияние друг на друга), +включая определение требований, проектирование и планирование. Эти подходы +смешивают проектирование, кодирование и тестирование, часто рассматривая их +комбинацию как конструирование. + +Соответственно, что именно подразумевается под “конструированием” зависит в +определенной степени от используемой модели жизненного цикла. + +### Планирование конструирования (Construction Planning) + +Выбор метода (методологии) конструирования является ключевым аспектом для +планирования конструкторской деятельности. Такой выбор значим для всей +конструкторской деятельности, а также необходимых условий её осуществления, +определяя порядок соответствующих операций и уровень выполнения заданных +условий перед тем как начнется конструирование или составляющие его действия. +Например, модульное тестирование в ряде методов является частью работ, после +написания соответствующего функционального кода, в то время, как ряд гибких +(agile) практик, например, XP (кстати, первыми начавшие использовать такие +методы верификации кода), требуют написания Unit-тестов до того, как пишется +соответствующий код, требующий тестирования. + +Используемый подход к конструированию влияет на возможность уменьшения (в +идеале - минимизации) сложности, готовности к изменениям и конструировании с +возможностью проверки. + +Планирование конструкторской деятельности определяет порядок, в котором +создаются компоненты и другие активы данной области знаний (фазы деятельности), +проводятся работы по обеспечению качества получаемого программного обеспечения, +распределяются* задачи и соответствующие ресурсы, в том числе, определяются +назначения/отображения работ конкретным инженерам-программистам, членам +проектной группы. Все это, конечно, происходит, следуя правилам, определяемым +используемым методом (методологией, практиками и т.п.). + +*Заметьте – не распределяют, а распределяются, подразумевая процесс, приводящий +к обеспечению явной связи между задачей и ресурсами. В нечетко +регламентированных (это ни в коем случае не ругательство, это определение – +ведь существует же понятие нечёткая логика, неструктурированные базы данных, +например, в отношении нереляционных систем и т.п.) и неформальных методах, +таких, как XP, члены проектной группы сами принимают на себя ответственность по +решению определенных задач, а “владение” кодом является совместным на основе +сотрудничества, как одного из ключевых принципов работы проектной команды. + +### Измерения в конструировании (Construction Measurement) + +Большая часть результатов, да и самой деятельности по конструированию +программного обеспечения, может быть измерена, в том числе - количественно. Это +и исходный разработанный код, и модифицированный объем кода, и степень +повторного использования, и многие другие характеристики. Эти измерения, или +как их еще принято называть – результаты аудита кода и метрики кода, несут +большую пользу как для оценки рисков и качества (приводящих к соответствующим +операциям по снижению рисков и повышению качества), а также, для управления +конструированием и программными проектами, в целом. О каком планировании может +идти речь, если мы не способны предсказать (например, на основе оценки +результатов предыдущих проектов) ни длительность работ, ни стоимость отдельных +задач, ни вероятность возникновения дефектов против заданных параметров +приемлемого качества? + +Код является одним из наиболее четко детерминированных активов проекта +(постепенно такими становятся и модели, строящиеся на основе структур +метаданных, и тесно связанные с кодом - например, UML). Код является и самим +носителям требуемой функциональности. Соответственно, применение измерений в +отношении кода становится тем инструментом, который влияет и на управление и на +сам код. + +Последнее время, большое внимание многие профессиональные разработчики, то есть +инженеры-конструкторы программного обеспечения, уделяют рефакторинг кода, как +методы его реструктурирования, призванные без изменения содержания (то есть +функциональности и функциональной целостности) обеспечить решение задач +минимизации сложности, готовности к изменениям (гибкости), прозрачности +документирования и многих других актуальных аспектов конструирования. Но, к +сожалению, многие забывают о необходимости мотивированности изменений, даже на +уровне рефакторинга. Применение измерений, в частности, метрик, позволяет +определить необходимость внесения таких изменений, проведения рефакторинга. И +не потому что “так, наверное, будет всё же лучше, красивше...”, а потому, что в +иерархии наследования из 10 поколений классов – 9 являются абстрактными (“из +любви к искусству”), а на 10-м (в силу превышений сроков проекта, после того, +как долго и “в кайф” создавали архитектурно-красивый код) “повешено” 20 (!) +бизнес-методов. Вот это – действительно обоснованная причина для рефакторинга, +который, даже с применением самых совершенных инструментальных средств, вместе +с обдумыванием необходимости рефакторинга, а потом, иногда, и борьбой с его +последствиями из-за несогласованности членов команды (а это уже жизнь, даже в +самом идеальном коллективе, где люди понимают друг друга с полуслова) часто +является просто тратой времени. Если применяется рефакторинг, но не применяются +метрики – в подавляющем большинстве случаев, это отрицательно влияет на проект. +И таких примеров работ, требующих применения измерений, но, к несчастью, +игнорирующих их, можно приводить достаточно долго. Вы, наверняка, сами можете +рассказать на эту тему много примеров из жизни. + +Почему “авторизованный перевод” этой темы SWEBOK оказался столь эмоционален? +Практика автора показывает, что в погоне за “красотой”, разработчики слишком +часто забывают о цели их работы и воспринимают деятельность по управлению +проектами (не буду спорить, иногда лишь формальную, для “прикрытия” всего, что +только можно …) со стороны менеджеров и, тем более, любой аудит – как +однозначную помеху “полёту мысли”. Зря. Если все именно так обстоит в вашем +случае – проект, с большой вероятностью, а иногда и просто, “если не случится +чудо”, можно считать пусть и не провальным (“фуух... не закрыли....”), то, +наверняка, выйдущим за рамки тех или иных ограничений, будь то сроки, деньги, +качество или, наконец, время, которое разработчик мог провести с семьей. И не +сидеть ночью, дописывая функциональность или отлавливая очередную ошибку за +несколько дней до передачи проекта в эксплуатацию. Все эти вопросы преследуют +одну единственную цель – предсказуемость работ и результата. И измерения – +важный инструмент достижения этой цели. + +Область знаний “Software Engineering Process” уделяет специальное внимание +вопросам измерений при создании программного обеспечения. + +## Практические соображения (Practical Considerations) + +Конструирование – деятельность, в рамках которой программное обеспечение +приводится к соглашению с произвольными (иногда - хаотическими) ограничениями +реального мира, которые требуют от программного обеспечения точного следования +им. Приближаясь к ограничениям реального мира, конструирование (в большей +степени, чем любая другая область знаний) ведется на основе практических +соображений и техник. + +### Проектирование в конструировании (Construction Design) + +Некоторые проекты предполагают больший объем работ по проектированию именно на +стадии конструирования; другие проекты явно выделяют проектную деятельность в +форме фазы дизайна. Вне зависимости от четкости выделения деятельности по +проектированию, как таковой, практически всегда на стадии конструирования +приходится заниматься и вопросами детального дизайна системы. Такие проектные +работы имеют стремление к следованию устойчивым ограничениям, навязываемым +конкретными проблемами, решение которых должно быть обеспечено использованием +конструируемой программной системы. + +Детали деятельности по проектированию на стадии конструирования в основном те +же самые, что и описанные в области знаний “Проектирование программного +обеспечения” (Software Design). Отличие заключается в большем внимании деталям. + +### Языки конструирования (Construction Languages) + +Языки конструирования включают все формы коммуникаций, с помощью которых +человек может задать решение проблемы, выполняемое на компьютере. + +Простейший тип языков конструирования – *конфигурационный язык (configuration +language)*, позволяющий задавать параметры выполнения программной системы. + +*Инструментальный язык (toolkit language)* – язык конструирования из +повторно-используемых элементов; обычно строится как сценарный язык (script), +выполняемый в соответствующей среде. + +*Язык программирования (programming language)* – наиболее гибкий тип языков +конструирования. Содержит минимальный объем информации о конкретных областях +приложения и процессе разработки, требуя больше всего (по сравнению с другими +типами языков конструирования) усилий на изучение и наработку опыта для +эффективного применения при решении конкретных задач. + +Существует три основных вида нотаций используемых при определении языков +программирования: + +- лингвистическая +- формальная +- визуальная + +*Лингвистические нотации* характеризуются, в частности, использованием строк +текста, содержащих специализированные “слова”, представляющие сложные +программные конструкции, и комбинируемые в шаблоны, напоминающие предложения, +построенные в соответствии с определенным синтаксисом. В случае корректного +использования таких нотаций, каждая получаемая строка обладает строгой +смысловой нагрузкой (семантикой), обеспечивающей интуитивное понимание того, +что будет происходить когда будет выполняться программное обеспечение, +построенное с использованием такого языка конструирования. + +Формальные нотации являются менее интуитивными, чем лингвистические, и часто +базируются на точных формальных (математических) определениях. Формальные +нотации конструкций и формальные методы являются ядром практически всех форм +системного программирования, точнее – поведения систем во времени. Такие +нотации обеспечивают наибольшую готовность получаемого кода к тестированию, что +намного важнее, чем просто возможность отображения на обычный человеческий +язык. Формальные конструкции также используют точный метод определения +комбинаций применяемых символов, что позволяет избежать неоднозначностей, +присущих конструкциям естественных языков. + +*Визуальные нотации* наименее связаны с текстово-ориентированными подходами, +предполагая непосредственную интерпретацию визуальных конструкций в процессе +исполнения описываемой логики. При этом логика в визуальных нотациях задается +расположением соответствующих визуальных сущностей, ответственных за те или +иные операции и структуры данных. + +Использование визуальных конструкций ограничено сложностью визуального +представления сложных выражений и утверждений только за счет перемещения +визуальных сущностей на диаграмме (визуальном представлении). Однако, +визуальная нотация может играть роль достаточно мощного инструмента, когда +применяется в тех задачах программирования, где необходимо построение +пользовательского интерфейса. + +Сегодняшние работы (и их состояние) в области архитектур и приложений, +управляемых моделями, в первую очередь - OMG MDA (Model-Driven Architecture +www.omg.org/mda)/UML (Unified Modeling Language www.omg.org/uml), Microsoft DSL +(Domain-Specific Language), направлены на то, чтобы использовать ту или иную +визуальную нотацию, базирующуюся на мета-моделях, в качестве инструмента, +применяемого и для определения функциональной логики системы. Можно ли в чистом +виде считать эти нотации именно визуальными - вопрос спорный. Но в терминах, +предлагаемых SWEBOK, они относятся именно к визуальным нотациям, так как +предполагают однозначную интерпретацию визуального представления в виде текста +и наоборот. Кроме того, исторически эти нотации определялись изначально как +нотации визуального представления функциональности и уже в дальнейшем эти +визуальные представления были отражены на уровне соответствующих мета-моделей +(хотя это в большей степени верно для UML, чем DSL, но DSL можно рассматривать +и как аналог UML, предполагающий бо́льшую свободу применений и интегрированность +с конкретной платформой - Microsoft). Другая область стандартов, направленных +на применение визуальных нотаций для описания функциональности – Business +Process Management Notation (BPMN - www.omg.org/bpmn) и связанный с ней язык +Business Process Execution Language, построенный на базе XML. Таким образом, +область обоснованного применения визуальных нотаций для конструирования +программных систем качественно расшириться и, не исключено, мы станем +свидетелями де-факто формирования новой категории нотаций, соглашений и +смешанных типов языковых средств, предназначенных для конструирования +программного обеспечения как естественного продолжения проектирования. + +### Кодирование (Coding) + +Практика конструирования программного обеспечения показывает активное +применение следующих соображений и техник: + +- техники создания легко понимаемого исходного кода на основе использования +соглашений об именовании, форматирования и структурирования кода; +- использование классов, перечисляемых типов, переменных, именованных констант +и других выразительных сущностей; +- организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и +другие структуры) +- использование структур управления; +- обработка ошибочных условий и исключительных ситуаций; +- предотвращение возможных брешей в безопасности (например, переполнение буфера +или выход за пределы индекса в массиве) +- использование ресурсов на основе применения механизмов исключения (из +рассмотрения) и порядка доступа к параллельно используемым ресурсам (например, +на основе блокировки данных, использования потоков и их синхронизации и т.п.) +- документирование кода +- тонкая “настройка” кода +- рефакторинг (не упоминается SWEBOK) + +### Тестирование в конструировании (Construction Testing) + +При конструировании используются две формы тестирования, проводимого +инженерами, непосредственно создающими исходный код: + +- модульное тестирование (unit testing) +- интеграционное тестирование (integration testing) + +Главная цель тестирования в конструировании уменьшить временной разрыв между +моментом проявления ошибок, имеющихся в коде, и моментом их обнаружения. Во +многих случаях, тестирование в конструировании производится после того, как код +написан. В ряде случаев, тесты (что отмечалось ранее, на примере XP) пишутся до +того, как создается код. + +Тестировании в конструировании обычно включает подмножество видов тестирования, +описанных в области знаний “Тестирование программного обеспечения” (Software +Testing). Например, тестирование в конструировании обычно не включает +системного тестирования, нагрузочного тестирования, usability-тестирования +(оценки прозрачности использования) и других видов тестовой деятельности. + +IEEE опубликовал два стандарта, посвященных данной теме: + +- IEEE Std 829-1998: “IEEE Standard for Software Test Documentation” +- IEEE Std 1008-1987: “IEEE Standard for Software Unit Testing” + +Напрямую с данной темой связаны под-темы SWEBOK 2.1.1 “Unit Testing” и 2.1.2 +“Integration Testing”. + +### Повторное использование (Reuse) + +Во введении в стандарт IEEE Std. 1517-99 “IEEE Standard for Information +Technology – Software Lifecycle Process – Reuse Processes” даётся следующее +понимание повторному использованию в программном обеспечении: “Реализация +повторного использования программного обеспечения подразумевает и влечёт за +собой нечто большее, чем просто создание и использование библиотек активов. Оно +требует формализации практики повторного использования на основе интеграции +процессов и деятельности по повторному использованию в сам жизненный цикл +программного обеспечения.” В то же время, повторное использование достаточно +важно и непосредственно при конструировании программных систем, что +подчеркивается включением этой темы в обсуждаемую область знаний +конструирования ПО. + +Задачи, связанные с повторным использованием в процессе конструирования и +тестирования, включают: + +- выбор единиц (units), баз данных тестовых процедур, данных <полученных в +результате> тестов и самих тестов, подлежащих повторному использованию +- оценку потенциала повторного использования кода и тестов +- отслеживание информации и создание отчетности по повторному использованию в +новом коде, тестовых процедурах и данных, полученных в результате тестов. + +### Качество конструирования (Construction Quality) + +Существует ряд техник, предназначенных для обеспечения качества кода, +выполняемых по мере его конструирования. Основные техники обеспечения качества, +используемые в процессе конструирования, включают: + +- модульное (unit) и интеграционное (integration) тестирование +- разработка с первичностью тестов (test-first development - тесты пишутся до +конструирования кода) +- пошаговое кодирование (деятельность по конструированию кода разбивается на +мелкие шаги, только после тестирования результатов которых производится переход +к следующему шагу кодирования; известен также как итеративное кодирование с +тестированием) +- использование процедур утверждений (assertion) +- отладка (в привычном понимании - debugging) +- технические обзоры и оценки (review) +- статический анализ + +Выбор и использование конкретных техник часто диктуется стандартами +(внутренними и внешними), используемыми проектной командой, а также зависят от +опыта и подготовленности специалистов, занимающихся конструированием кода. + +Деятельность по обеспечению качества в конструировании отличается от других +операций по обеспечению качества. Основное отличие заключается в фокусе на +программном (исходном) коде и других артефактах (активах), тесно связанных с +кодом, в частности, детальных моделях. + +### Интеграция (Integration) + +Одна из ключевых деятельностей, осуществляемых в процессе конструирования, - +интеграция отдельно сконструированных операций (процедур), классов, компонентов +и подсистем (модулей). В дополнение к этому, некоторые программные системы +нуждаются в специальной интеграции с другим программным и аппаратным +обеспечением. + +Кроме упомянутых аспектов интеграции, к обсуждаемым интеграционным вопросам +конструирования относятся: + +- планирование последовательности, в которой интегрируются компоненты; +- обеспечение поддержки создания промежуточных версий программного обеспечения; +- задание “глубины” тестирования (в частности, на основе критериев +“приемлемого” качества) и других работ по обеспечению качества интегрируемых в +дальнейшем компонент; +- наконец, определение этапных точек проекта, когда будут тестироваться +промежуточные версии конструируемой программной системы. blob - cfe3acabbc28bc1f2820504131014bff7b142939 (mode 644) blob + /dev/null --- 4_software_testing.markdown +++ /dev/null @@ -1,878 +0,0 @@ -# Тестирование программного обеспечения - -Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - -SWEBOK. - -Содержит перевод описания области знаний SWEBOK “Software Testing”, с -замечаниями и комментариями. - -Тестирование (software testing) – деятельность, выполняемая для оценки и -улучшения качества программного обеспечения. Эта деятельность, в общем случае, -базируется на обнаружении дефектов и проблем в программных системах. - -Тестирование программных систем состоит из динамической верификации поведения -программ на конечном (ограниченном) наборе тестов (set of test cases), -выбранных соответствующим образом из обычно выполняемых действий прикладной -области и обеспечивающих проверку соответствия ожидаемому поведению системы. - -В данном определении тестирования выделены слова, определяющие основные -вопросы, которым адресуется данная область знаний: - -- Динамичность (dynamic): этот термин подразумевает тестирование всегда -предполагает выполнение тестируемой программы с заданными входными данными. При -этом, величины, задаваемые на вход тестируемому программному обеспечению, не -всегда достаточны для определения теста. Сложность и недетерминированность -систем приводит к тому, что система может по разному реагировать на одни и те -же входные параметры, в зависимости от состояния системы. В данной области -знаний термин “вход” (input) будет использоваться в рамках соглашения о том, -что вход может также специфицировать состояние системы, в тех случаях, когда -это необходимо. Кроме динамических техник проверки качества, то есть -тестирования, существуют также и статические техники, рассматриваемые в области -знаний “Software Quality”. -- Конечность (ограниченность, finite): даже для простых программ теоретически -возможно столь большое количество тестовых сценариев, что исчерпывающее -тестирование может занять многие месяцы и даже годы. Именно поэтому, с -практической точки зрения, всестороннее тестирование считается бесконечным. -Тестирование всегда предполагает компромисс между ограниченными ресурсами и -заданными сроками, с одной стороны, и практически неограниченными требованиями -по тестированию, с другой. То есть мы снова говорим об определении -характеристик “приемлемого” качества, на основе которых планируем необходимы -объем тестирования. -- Выбор (selection): многие предлагаемые техники тестирования отличаются друг -от друга в том, как выбираются сценарии тестирования. Инженеры по программному -обеспечению должны обладать представлением о том, что различные критерии выбора -тестов могут давать разные результаты, с точки зрения эффективности -тестирования. Определение подходящего набора тестов для заданных условий -является очень сложной проблемой. Обычно, для выбора соответствующих тестов -совместно применяют техники анализа рисков, анализ требований и соответствующую -экспертизу в области тестирования и заданной прикладной области. -- Ожидаемое поведение (expected behaviour): Хотя это не всегда легко, все же -необходимо решить, какое наблюдаемое поведение программы будет приемлемо, а -какое – нет. В противном случае, усилия по тестированию – бесполезны. -Наблюдаемое поведение может рассматриваться в контексте пользовательских -ожиданий (подразумевая “тестирования для проверки” - testing for validation), -спецификации (“тестирование для аттестации” - testing for verification) или, -наконец, в контексте предсказанного поведения на основе неявных требований или -обоснованных ожиданий. См. тему SWEBOK 6.4 “Приемочные тесты” области знаний -“Software Requirements”. - -Общий взгляд на тестирование программного обеспечения последние годы активно -эволюционировал, становясь все более конструктивным, прагматичным и -приближенным к реалиям современных проектов разработки программных систем. -Тестирование более не рассматривается как деятельность, начинающаяся только -после завершения фазы конструирования. Сегодня тестирование рассматривается как -деятельность, которую необходимо проводить на протяжении всего процесса -разработки и сопровождения и является важной частью конструирования программных -продуктов. Действительно, планирование тестирования должно начинаться на ранних -стадиях работы с требованиями, необходимо систематически и постоянно развивать -и уточнять планы тестов и соответствующие процедуры тестирования. Даже сами по -себе сценарии тестирования оказываются очень полезными для тех, кто занимается -проектированием, позволяя выделять те аспекты требований, которые могут -неоднозначно интерпретироваться или даже быть противоречивыми. - -Не секрет, что легче предотвратить проблему, чем бороться с ее последствиями. -Тестирование, наравне с управлением рисками, является тем инструментом, который -позволяет действовать именно в таком ключе. Причем действовать достаточно -эффективно. С другой стороны, необходимо осознавать, что даже если приемочные -тесты показали положительные результаты, это совсем не означает, что полученный -продукт не содержит ошибок. Этим вопросам, в частности, адресована область -знаний “Сопровождение программного обеспечения” (Software Maintenance). Однако, -адекватное внимание вопросам тестирования качественно снижает риск -возникновения ошибок на этапе эксплуатации, обеспечивая более высокую -удовлетворенность пользователей, что и является, по существу, целью любого -проекта. - -В области знаний “Качество программного обеспечения” (Software Quality) техники -управления качеством четко разделены на статические (без выполнения кода) и -динамические (с выполнением кода). Обе эти категории важны. Данная область -знаний - “Тестирование” – касается динамических техник. - -Как уже отмечалось ранее, тестирование тесно связано с областью знаний -“Конструирование” (Software Construction). Более того, модульное (unit-) и -интеграционное тестирование все чаще рассматривают как неотъемлемый элемент -деятельности по конструированию. - -![Рисунок 5. Область знаний “Тестирование программного обеспечения” [SWEBOK, 2004, с.5-2, рис. 1]](images/testing_area_small.jpg) - -## Основы тестирования (Software Testing Fundamentals) - -Охватывает основные понятия в области тестирования, базовые термины, ключевые -проблемы и их связь другими областями деятельности и знаний. - -### Терминология тестирования (Testing-Related Terminology) - -Определение тестирования и связанной терминологии достаточно полно даётся -в “Глоссарии терминов по программной инженерии” – IEEE Standard 610-90 -(Standard Glossary of Software Engineering Terminology). - -#### Недостатки и сбои (Faults vs. Failures) - -В литературе, посвященной программной инженерии, встречается множество -терминов, описывающих нарушение функционирования программных систем – -недостатки (faults), дефекты (defects), сбои (failures), ошибки (errors) и др. -Соответствующая терминология, как было указано выше в 1.1.1, описана в IEEE -Std. 610-90 также обсуждается в области знаний SWEBOK “Качество программного -обеспечения” (Software Quality). Важно чётко разделять причину нарушения работы -прикладных систем, обычно описываемую терминами недостаток или дефект, и -наблюдаемый нежелательный эффект, вызываемый этими причинами – сбой. Термин -ошибка, в зависимости от контекста, может описывать и как причину сбоя, и сам -сбой. Тестирование позволяет обнаружить дефекты, приводящие к сбоям. - -Необходимо понимать, что причина сбоя не всегда может быть однозначно -определена. Не существует теоретических критериев, позволяющих гарантированно -определить какой именно дефект приводит к наблюдаемому сбою. - -### Ключевые вопросы (Key Issues) - -#### Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования (Test selection criteria/test adequacy criteria, or stopping rules) - -Критерии отбора тестов могут использоваться как для создания набора тестов, так -и для проверки, насколько выбранные тесты адекватны решаемым задачам -(тестирования). При этом, обсуждаемые критерии помогают определить, когда можно -или необходимо прекратить тестирование. - -#### Эффективность тестирования/Цели тестирования (Test effectiveness/Objectives for testing) - -Тестирование – это наблюдение за выполнением программы, запущенной в целях -тестирования с заданными параметрами, по заданному сценарию или с другими -заданными начальными условиями или целями тестирования. Эффективность теста -может быть определена только в контексте заданных условий. - -#### Тестирование для идентификации дефектов (Testing for defect identification) - -Данный случай тестирования подразумевает успешность процедуры тестирования, -если дефект найден. Это отличается от подхода в тестировании, когда тесты -запускаются для демонстрации того, что программное обеспечение удовлетворяет -предъявляемым требованиями и, соответственно, тест считается успешным, если не -найдено дефектов. - -#### Проблема оракула (The oracle problem) - -“Оракул”, в данном контексте, любой агент (человек или программа), оценивающий -поведение программы, формулируя вердикт - тест пройден (“pass”) или нет -(“fail”). - -#### Теоретические и практические ограничения тестирования (Theoretical and practical limitation of testing) - -Теория тестирования выступает против необоснованного уровня доверия к серии -успешно пройденных тестов. К сожалению, большинство установленных результатов -теории тестирования – негативны, означая, по словам Дейкстры (Dijkstra), то, -что “тестирование программы может использоваться для демонстрации наличия -дефектов, но никогда не покажет их отсутствие”. Основная причина этого в том, -что полное (всеобъемлющее) тестирование недостижимо для реального программного -обеспечения. - -#### Проблема неосуществимых путей (The problem of infeasible paths) - -Эта сложнейшая проблема автоматизированного тестирования связана с тем, что -путь, по которому выполняются потоки работ тестируемой программной системы, не -могут быть заданы входными параметрами. - -#### Тестируемость (Testability) - -Это понятие может подразумевать две различных идеи. Первая описывает степень -легкости описания критериев покрытия тестами для заданной программной системы. -Вторая определяет возможность вероятность, возможность статистического -измерения того, что при тестировании проявится сбой программной системы. Обе -интерпретации этого понятия одинаково важны для тестирования. - -### Связь тестирования с другой деятельностью (Relationships of testing with other activities) - -Тестирование программного обеспечения отличается от статических техник -управления качеством, проверки корректности, отладки и программирования, но -связано со всеми этими работами. Полезно рассматривать тестирование с точки -зрения аналитиков и специалистов по сертификации качества. - -## Уровни тестирования (Test Levels) - -### Над чем производятся тесты (The target of the test) - -Тестирование обычно производится на протяжении всей разработки и сопровождения -на разных уровнях. Уровень тестирования определяет “над чем” производятся -тесты: над отдельным модулем, группой модулей или системой, в целом. При этом -ни один из уровней тестирования не может считаться приоритетным. Важны все -уровни тестирования, вне зависимости от используемых моделей и методологий. - -#### Модульное тестирование (Unit testing) - -Этот уровень тестирования позволяет проверить функционирование отдельно взятого -элемента системы. Что считать элементом – модулем системы определяется -контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 -“Standard for Software Unit Testing”, задающем интегрированную концепцию -систематического и документированного подхода к модульному тестированию. - -#### Интеграционное тестирование (Integration testing) - -Данный уровень тестирования является процессом проверки взаимодействия между -программными компонентами/модулями. - -Классические стратегии интеграционного тестирования – “сверху-вниз” и -“снизу-вверх” – используются для традиционных, иерархически структурированных -систем и их сложно применять, например, к тестированию слабосвязанных систем, -построенных в сервисно-ориентированных архитектурах (SOA). - -Современные стратегии в большей степени зависят от архитектуры тестируемой -системы и строятся на основе идентификации функциональных “потоков” (например, -потоков операций и данных). - -Интеграционное тестирование – постоянно проводимая деятельность, предполагающая -работу на достаточно высоком уровне абстракции. Наиболее успешная практика -интеграционного тестирования базируется на инкрементальном подходе, позволяющем -избежать проблем проведения разовых тестов, связанных с тестированием -результатов очередного длительного этапа работ, когда количество выявленных -дефектов приводит к серьезной переработке кода (традиционно, негативный опыт -выпуска и тестирования только крупных релизов называют “big bang”). - -#### Системное тестирование (System testing) - -Системное тестирование охватывает целиком всю систему. Большинство -функциональных сбоев должно быть идентифицировано еще на уровне модульных и -интеграционных тестов. В свою очередь, системное тестирование, обычно -фокусируется на нефункциональных требованиях – безопасности, -производительности, точности, надежности т.п. - -На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному -обеспечению, операционной среде и т.д. - -### Цели тестирования (Objectivies of Testing) - -Тестирование проводится в соответствии с определенными целями (могут быть -заданы явно или неявно) и различным уровнем точности. Определение цели точным -образом, выражаемым количественно, позволяет обеспечить контроль результатов -тестирования. - -Тестовые сценарии могут разрабатываться как для проверки функциональных -требований (известны как функциональные тесты), так и для оценки -нефункциональных требований. При этом, существуют такие тесты, когда -количественные параметры и результаты тестов могут лишь опосредованно говорить -об удовлетворении целям тестирования (например, “usability” – легкость, -простота использования, в большинстве случаев, не может быть явно описана -количественными характеристиками). - -Можно выделить следующие, наиболее распространенные и обоснованные цели (а, -соответственно, виды) тестирования: - -#### Приёмочное тестирование (Acceptance/qualification testing) - -Проверяет поведение системы на предмет удовлетворения требований заказчика. Это -возможно в том случае, если заказчик берет на себя ответственность, связанную с -проведением таких работ, как сторона “принимающая” программную систему, или -специфицированы типовые задачи, успешная проверка (тестирование) которых -позволяет говорить об удовлетворении требований заказчика. - -Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них. - -#### Установочное тестирование (Installation testing) - -Из названия следует, что данные тесты проводятся с целью проверки процедуры -инсталляции системы в целевом окружении. - -#### Альфа- и бета-тестирование (Alpha and beta testing) - -Перед тем, как выпускается программное обеспечение, как минимум, оно должно -проходить стадии альфа (внутреннее пробное использование) и бета (пробное -использование с привлечением отобранных внешних пользователей) версий. Отчеты -об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в -соответствии с определенными процедурами, включающими подтверждающие тесты -(любого уровня), проводимые специалистами группы разработки. - -Данный вид тестирования не может быть заранее спланирован. - -#### Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing) - -Эти тесты могут называться по разному, однако, их суть проста – проверка -соответствия системы, предъявляемым к ней требованиям, описанным на уровне -спецификации поведенческих характеристик. - -#### Достижение и оценка надежности (Reliability achievement and evaluation) - -Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение -надежности программных систем. Случайно генерируемые сценарии тестирования -могут применяться для статистической оценки надежности. Обе цели – повышение и -оценка надежности – могут достигаться при использовании моделей повышения -надежности. Эти вопросы затрагиваются и в тематическом фрагменте 4.1.4 “Life -test, reliability evaluation”. - -#### Регрессионное тестирование (Regression testing) - -Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of -Software Engineering Terminology”) гласит: “повторное выборочное тестирование -системы или компонент для проверки сделанных модификаций не должно приводить к -непредусмотренным эффектам”. На практике это означает, что если система успешно -проходила тесты до внесения модификаций, она должна их проходит и после -внесения таковых. Основная проблема регрессионного тестирования заключается в -поиске компромисса между имеющимеся ресурсами и необходимостью проведения таких -тестов по мере внесения каждого изменения. В определенной степени, задача -состоит в том, чтобы определить критерии “масштабов” изменений, с достижением -которых необходимо проводить регрессионные тесты. - -#### Тестирование производительности (Performance testing) - -Специализированные тесты проверки удовлетворения специфических требований, -предъявляемых к параметрам производительности. Существует особый подвид таких -тестов, когда делается попытка достижения количественных пределов, -обусловленных характеристиками самой системы и ее операционного окружения. - -#### Нагрузочное тестирование (Stress testing) - -Необходимо понимать отличия между рассмотренным выше тестированием -производительности с целью достижения ее реальных (достижимых) возможностей -производительности и выполнением программной системы c повышением нагрузки, -вплоть до достижения запланированных характеристик и далее, с отслеживанием -поведения на всем протяжении повышения загрузки системы. - -#### Сравнительное тестирование (Back-to-back testing) - -Единичный набор тестов, позволяющих сравнить две версии системы. - -#### Восстановительные тесты (Recovery testing) - -Цель – проверка возможностей рестарта системы в случае непредусмотренной -катастрофы (disaster), влияющей на функционирование операционной среды, в -которой выполняется система. - -#### Конфигурационное тестирование (Configuration testing) - -В случаях, если программное обеспечение создается для использования различными -пользователями (в терминах “ролей”), данный вид тестирования направлен на -проверку поведения и работоспособности системы в различных конфигурациях. - -#### Тестирование удобства и простоты использования (Usability testing) - -Цель – проверить, насколько легко конечный пользователь системы может ее -освоить, включая не только функциональную составляющую – саму систему, но и ее -документацию; насколько эффективно пользователь может выполнять задачи, -автоматизация которых осуществляется с использованием данной системы; наконец, -насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от -ошибок пользователя. - -#### Разработка, управляемая тестированием (Test-driven development) - -По-сути, это не столько техника тестирования, сколько стиль организации -процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью -требований (и соответствующих спецификаций) вместо того, чтобы рассматриваться -независимой деятельностью по проверке удовлетворения требований программной -системой. - -Иногда говорят о таком стиле разработки как о самостоятельной методологии – -TDD. Насколько это верно, зависит от того, что именно понимать под методологией -разработки. Скорее, с точки зрения автора, это техника, практика или стиль -организации работы, чем самостоятельная методология. - -В меньшей степени это относится к FDD – Feature-Driven Development (разработка -на основе функциональных возможностей). TDD может естественно рассматриваться -как составная часть XP или, как минимум Agile-методов. В свою очередь, FDD -может рассматриваться как один из методов гибкой разработки. - -В чем отличие столь близких, на первый взгляд, подходов (и, кстати, -соответствующих аббревиатур)? Причина – проста. Тесты – инструмент достижения -характеристик системы, удовлетворяющей заданным требованиям, то есть -потребностям пользователей, а “возможности” (features) – практически сами (чаще -– функциональные) требования, воплощенные (в идеальном случае) в код. - -## Техники тестирования (Test Techniques) - -### Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuition and experience) - -#### Специализированное тестирование (Ad hoc testing) - -Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, -интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся -ранее аналогий. Данный вид тестирования может быть полезен для идентификации -тех тестов, которые не охватываются рассматривавшимеся выше более -формализованными техниками. - -#### Исследовательское тестирование (Exploratory testing) - -Такое тестирование определяется как одновременное обучение, проектирование -теста и его исполнение. Данный вид тестирования заранее не определяется в плане -тестирования и такие тесты создаются, выполняются и модифицируются динамически, -по мере необходимости. Эффективность исследовательских тестов напрямую зависит -от знаний инженера, формируемых на основе поведения тестируемого продукта в -процессе проведения тестирования, степени знакомства с приложением, платформой, -типами возможных сбоев и дефектов, рисками, ассоциированными с конкретным -продуктом и т.п. - -### Техники, базирующиеся на спецификации (Specification-based techniques) - -#### Эквивалентное разделение <приложения> (Equivalence partitioning) - -Рассматриваемая область приложения разделяется на коллекцию наборов или -эквивалентных классов, которые считаются эквивалентными с точки зрения -рассматриваемых связей и характеристик <спецификации>. Репрезентативный набор -тестов (иногда – только один тест) формируется из тестов эквивалентных классов -(или наборов классов). - -#### Анализ граничных значений (Boundary-value analysis) - -Тесты строятся с ориентацией на использование тех величин, которые определяют -предельные характеристики тестируемой системы. Расширением этой техники -являются тесты оценки живучести (robustness testing) системы, проводимые с -величинами, выходящими за рамки специфицированных пределов значений. - -#### Таблицы принятия решений (Decision table) - -Такие таблицы представляют логические связи между условиями (могут -рассматриваться в качестве “входов”) и действиями (могут рассматриваться как -“выходы”). Набор тестов строится последовательным рассмотрением всех возможных -кросс-связей в такой таблице. - -#### Тесты на основе конечного автомата (Finite-state machine-based) - -Строятся как комбинация тестов для всех состояний и переходов между -состояниями, представленных в соответствующей модели (переходов и состояний -приложения). - -#### Тестирование на основе формальной спецификации (Testing from formal specification) - -Для спецификации, определенных с использованием формального языка, возможно -автоматически создавать и тесты для функциональных требований. В ряде случаев -могут строится на основе модели, являющейся частью спецификации, не -использующей формального языка описания. - -#### Случайное тестирование (Random testing) - -В отличие от статистического тестирования (будет рассматриваться в 3.5.1 -“Operational profile”), сами тесты генерируются случайным образом по списку -заданного набора специфицированных характеристик. - -### Техники, ориентированные на код (Code-based techniques) - -#### Тесты, базирующиеся на блок-схеме (Control-flow-based criteria) - -Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В -какой-то степени напоминает тесты на основе конечного автомата. Отличие – в -источнике набора тестов. Максимальная отдача от тестов на основе блок-схемы -получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии -потоков работ (поведения) тестируемой системы. Адекватность таких тестов -оценивается как процент покрытия всех возможных путей блок-схемы. - -#### Тесты на основе потоков данных (Data-flow-based criteria) - -В данных тестах отслеживается полный жизненный цикл величин (переменных) – с -момента рождения (определения), на всем протяжении использования, вплоть до -уничтожения (неопределенности). В реальной практике используются нестрогое -тестирование такого вида, ориентированное, например, только на проверку задания -начальных значений всех переменных или всех вхождений переменных в код, с точки -зрения их использования. - -#### Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph) - -Является не столько техникой тестирования, сколько контролем структуры -программы, представленной в виде дерева вызовов (например, sequence-диаграммы, -определенной в нотации UML и построенной на основе анализа кода). - -### Тестирование, ориентированное на дефекты (Fault-based techniques) - -Как это ни странно звучит на уровне названия таких техник тестирования, они, -действительно, ориентированы на ошибки. Точнее – на специфические категории -ошибок. - -#### Предположение ошибок (Error guessing) - -Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, -в результате анализа рисков. - -#### Тестирование мутаций (Mutation testing) - -Мутация – небольшое изменение тестируемой программы, произошедшее за счет -частных синтаксических изменений кода (в частности, рефакторинга). -Соответствующие тесты запускаются для оригинального и всех “мутировавших” -вариантов тестируемой программы. - -SWEBOK фокусируется на возможности, с помощью тестов, определять отличия между -мутантами и исходным вариантом кода. Если такое отличие установлено, мутанта -“убивают”, а тест считается успешным. Обычно, данный подход фокусируется на -синтаксических ошибках, на практике отслеживаемых современными средами -разработки и, конечно, компиляторами. - -### Техники, базирующиеся на условиях использования (Usage-based techniques) - -#### Операционный профиль (Operational profile) - -Базируется на условиях использования системы. - -Тестирование для оценки надёжности системы должно проводиться в таком тестовом -окружении, которое максимально приближено к реальным условиям работы системы. -Результаты таких тестов позволяют оценить поведение системы в реальных -условиях. Входные параметры тестов задаются на основе вероятностного -распределения соответствующих параметров или их наборов при эксплуатации -(входные данные могут прогнозироваться исходя из частоты возможных сценариев -работы пользователей). - -#### Тестирование, базирующееся на надежности инженерного процесса (Software Reliability Engineered Testing) - -Базируется на условиях разработки системы. - -Соответствующие тесты (обозначаемые также аббревиатурой SRET от Software -Reliability Engineered Testing) проектируются в контексте используемого -процесса разработки и методик тестирования. - -### Техники, базирующиеся на природе приложения (Techniques based on the nature of the application) - -Описанные выше техники могут применяться к любым типам программных систем. В то -же время, в зависимости от технологической или архитектурной природы -приложений, могут также применять специфические техники, важные именно для -заданного типа приложения. Среди таких техник: - -- Объектно-ориентированное тестирование -- Компонентно-ориентированное тестирование -- Web-ориентированное тестирование -- Тестирование на соответствие протоколам -- Тестирование систем реального времени - -### Выбор и комбинация различных техник (Selecting and combining techniques) - -#### Функциональное и структурное (Functional and structural) - -Техники тестирования, строящиеся на основе спецификаций или кода часто называют -функциональными или структурными, соответственно. Оба подхода не должны -противопоставляться, но дополнять друг друга. - -#### Определенное или случайное (Deterministic vs. random) - -Обычно тесты можно распределить по данным группам на основе используемой -политики выбора или определения входных параметров тестов. - -## Измерение результатов тестирования (Test-related measures) - -Часто техники тестирования путают с целями тестирования. Степень покрытия -тестами - не то же самое, что высокое качество тестируемой системы. Однако, эти -вопросы связаны. Чем выше степень покрытия, чем больше вероятность обнаружения -скрытых дефектов. Когда мы говорим о результатах тестирования, мы должны -подходить к их оценке, как оценке самой тестируемой системы. Именно -количественные оценки результатов тестирования (но не самих тестов, например, -покрытия ими возможных сценариев работы системы) освещаются ниже. В свою -очередь, метрики самих тестов или процесса тестирования, как такового – -вопросы, рассматриваемые в областях знаний “Процессы программной инженерии” -(Software Engineering Process) и “Управление инженерной деятельностью” -(Software Engineering Management). - -Измерения являются инструментом анализа качества. Измерение результатов -тестирования касается оценки качества получаемого продукта – программной -системы. История измерений демонстрирует прогресс достижения приемлемого -качества. Такая история является инструментом менеджмента качества. - -### Оценка программ в процессе тестирования (Evaluation of the program under test, IEEE 982.1-98) - -#### Измерения программ как часть планирования и разработки тестов (Program measurements to aid in planning and design testing) - -Данные измерения могут базироваться на размере программ (например, в терминах -количества строк кода или функциональных точек) или их структуре (например, с -точки зрения оценки ее сложности в тех или иных архитектурных терминах). -Структурные измерения могут также включать частоту обращений одних модулей -программы к другим. - -#### Типы дефектов, их классификация и статистика возникновения (Fault types, classification and statistics) - -В литературе по тестированию встречается большое количество различных -классификаций дефектов. Эффективность тестирования может быть достигнута в том -случае, если мы понимаем какие типы дефектов могут быть найдены в процессе -тестирования программной системы и как изменяется их частота во времени -(подразумевая историческую перспективу развития системы, а не её сбоев в -процессе работы). Эта информация позволяет прогнозировать качество системы и -помогает совершенствовать процесс разработки, в целом. - -Стандарт IEEE 1044-93 классифицирует возможные программные “аномалии”. - -#### Плотность дефектов (Fault density) - -Тестируемая программа может оцениваться на основе подсчета и классификации -найденных дефектов. Для каждого класса дефектов можно определить отношение -между количеством соответствующих дефектов и размером программы (в терминах -выбранных метрик оценки размера). - -#### Жизненный цикл тестов, оценка надежности (Life test, reliability evaluation) - -Статистические ожидания в отношении надежности программной системы (см. выше -2.2.5 “Достижение и оценка надежности”) могут использоваться для принятия -решения о продолжении или прекращении (окончании) тестирования, исходя из -заданных параметров приемлемого качества (например, плотности дефектов -заданного класса). - -#### Модели роста надежности (Reliability growth models) - -Данные модели обеспечивают возможности прогнозирования надежности системы, -базируясь на обнаруженных сбоях (см. выше 2.2.5). Модели такого рода -разбиваются на две группы – по количеству сбоев (failure-count) и времени между -сбоями (time-between-failure). - -### Оценка выполненных тестов (Evaluation of the tests performed) - -#### Метрики покрытия/глубины тестирования (Coverage/thoroughness measures) - -Критерии “адекватности” тестирования, в ряде случаев, требуют систематического -выполнения тестов для определенных набора элементов программы, задаваемых ее -архитектурой или спецификацией. Соответствующие метрики позволяют оценить -степень охвата характеристик системы (например, процент различных тестируемых -параметров производительности) и глубину их детализации (например, случайное -тестирование параметров производительности или с учетом граничных значений и -т.п.). Такие метрики помогают прогнозировать вероятностное достижение заданных -параметров качества системы. - -#### Введение искусственных дефектов (Fault seeding) - -“Своими руками?! Никогда! ...” – такова, обычно, первая реакция на идею -искусственного внесения дефектов, например, в программный код. На практике, -этот подход помогает классифицировать возможные ошибки и следующие за ними -сбои, применяя в дальнейшем полученные результаты для моделирования (пусть, -часто, и интуитивного) возможных причин реальных сбоев, обнаруженных в процессе -тестирования. - -Безусловно, данная техника должна использоваться с максимальной осторожностью -опытными специалистами, хорошо представляющими общую архитектуру тестируемой -программной системы и разбирающимеся во её внутренних связях. - -#### Оценка мутаций (Mutation score) - -Получаемое в процессе тестирования мутаций (см. выше 3.4.2) отношение “убитых” -к общему числу сгенерированных мутантов помогает измерить эффективность -выполняемых тестов. В силу специфики такой техники тестирования, количественные -оценки мутаций имеют практическое значение только для определенных типов -систем. - -#### Сравнение и относительная эффективность различных техник тестирования (Comparison and relative effectiveness of different techniques) - -Различные исследования в области тестирования связаны с попытками сравнения (с -точки зрения достигаемого качества продукта) разных подходов к тестированию. -Когда мы говорим об “эффективности” тестирования надо чётко договориться, что -именно мы подразумеваем под эффективностью, желательно, в количественном -выражении. Возможные варианты интерпретации этого понятия – число тестов -(данной техники), необходимых для обнаружения первого дефекта; отношение -количества всех обнаруженных дефектов к дефектам, найденным с применением -заданного подхода и т.п. Только обладая такого рода данными можно говорить о -корректности сравнения и оценки эффективности. - -## Процесс тестирования (Test Process) - -Концепции, стратегии, техники и измерения тестирования должны быть объеденены в -единый процесс тестирования как деятельности по обеспечению качества. Процесс -тестирования поддерживает работы по тестированию и определяет “правила игры” -для членов команды тестирования – от планирования тестов до оценки их -результатов. Хотя, в большинстве современных методов разработки, в частности, -гибких (agile) подходов, тестирование выходит на передний план и является одной -из базовых практик, многостороннее тестирование и, тем более, прогнозирование -на основе полученных результатов, часто подменяется отдельными работами в этой -области, не позволяющими добиться необходимых параметров качества (что, кстати, -ясно показывают уже упоминавшиеся результаты исследований Standish Group -[Chaos, 2004]). Только в том случае, если тестирование рассматривать как один -из важных процессов всей деятельности по созданию и поддержке программного -обеспечения, можно добиться оценки стоимости соответствующих работ и, в конце -концов, соблюсти те ограничения, которые определены для проекта. - -### Практические соображения (Practical considerations) - -#### Программирование без персоналий (Attitudes/Egoless programming) - -Очень важным компонентом успешного тестирования является совместное стремление -участников проекта обеспечить необходимое качество продукта. Менеджеры играют -ключевую роль в организации этой деятельности и на стадии разработки и в -процессе сопровождения программных систем. - -#### Руководства по тестированию (Test guides) - -Работы по тестированию могут руководствоваться различными соображениями и -критериями – от управления рисками до специфицированных сценариев работы -программных систем. В любом случае, желательно, исходя из ресурсов, -количественных оценок и других характеристик, обеспечить использование -различных техник тестирования для многосторонней оценки и улучшения качества -получаемого продукта. - -#### Управление процессом тестирования (Test process management) - -Работы по тестированию, ведущиеся на разных уровнях (см. выше 2. “Уровни -тестирования”), должны быть организованы в единый (однозначно интерпретируемый) -процесс, на основе учета 4 элементов и связанных с ними факторов: людей (в том -числе, в контексте организационной структуры и культуры), инструментов, -регламентов и количественных оценок (измерений). Стандарт жизненного цикла -IEEE, ISO/IEC, ГОСТ Р 12207 не выделяет деятельность по тестированию в качестве -самостоятельного процесса, однако, рассматривает соответствующие принципы работ -по тестированию как неотъемлемую часть процессов жизненного цикла и -сопровождения программных систем. В другом распространенном стандарте IEEE 1074 -деятельность по тестированию также объединена с другими оценочными работами как -интегральная часть полного жизненного цикла. - -#### Документирование тестов и рабочего продукта (Test documentation and work products) - -Документация – составная часть формализации процесса тестирования. Существует -стандарт IEEE 829-98 “Standard for Software Test Documentation”, -предоставляющий прекрасное описание тестовых документов, их связей между собой -и с процессом тестирования. Среди таких документов могут быть: - -- План тестирования -- Спецификация процедуры тестирования -- Спецификация тестов -- Лог тестов -- и др. - -Документирование тестов, в случае его формального ведения, должно быть -актуальным. В противном случае, как и любые другие документы, документация по -тестированию ляжет “мертвым грузом”. В то же время, деятельность по -тестированию, в случае отсутствия соответствующих регламентов и результатов (в -том числе, исторических, для разных проектов), сложно поддается оценке для -прогнозирования и, тем более, улучшению - в общем контексте улучшения -процессов. Если компания-разработчик не ведет соответствующей документации по -тестированию, говорить о сертификации или оценке по тем или иным моделям или -стандартам (CMMI, ISO, SixSigma и т.п.) – просто не представляется возможным. А -это уже вопрос доверия заказчиков, не имевших опыта работы с конкретной -компанией-разработчиком. - -#### Внутренние и независимые команды тестирования (Internal vs. independent test team) - -Формализация процесса тестирования может включать и организационную -формализацию команд(ы) тестирования. В нее могу входить как члены проектной -команды, в частности, разрабатывающие код, так и внешние лица и группы. В -идеале – желательно иметь как внутреннюю команду тестирования, так и внешнюю -группу тестирования (обеспечения качества). Соответствующие организационные -решения принимаются на основе стоимостных характеристик проекта, доступных -ресурсов, анализа стоимости тестирования, как такового, организационной -культуры и т.п. - -#### Оценка стоимости и усилий, а также другие измерения процесса (Cost/effort estimation and other process measures) - -Ряд метрик, связанных с оценкой ресурсов, необходимых для тестирования, как и -оценка эффективности тестирования на разных этапах и уровнях, основывается на -точке зрения и практиках менеджмента проекта (подразделения, компании...) и -используется для оценки и улучшения (оптимизации) процесса тестирования. Разные -техники, концепции и модели тестирования требуют разных затрат – по времени и -необходимым ресурсам. Результат – стоимость тестирования, как затратная -составляющая проекта. Понимание соответствия между стоимостью/усилиями, -необходимыми для той или иной формы тестирования является обязательной частью -современного управления проектами разработки программного обеспечения. - -#### Окончание тестирования (Termination) - -Очень важным аспектом тестирования является решение о том, в каком объеме -тестирование достаточно и когда необходимо завершить процесс тестирования. -Тщательные измерения, такие как достигнутое покрытие кода тестами или охват -функциональности, безусловно, очень полезны. Однако, сами по себе они не могут -определить критериев достаточности тестирования. Принятие решения об окончании -тестирования также включает рассмотрение стоимости и рисков, связанных с -потенциальными сбоями и нарушениями надёжности функционирования тестируемой -программной системы. В то же время, стоимость самого тестирования также -является одним из ограничений, на основе которых принимается решение о -продолжении тех или иных связанных с проектом работ (в частности, тестирования) -или об их прекращении. Cм. также 1.2.1 “Критерии отбора тестов/критерии -адекватности тестов, правила прекращения тестирования”. - -#### Повторное использование и шаблоны тестов (Test reuse and test patterns) - -Доведение тестов до конца и обеспечение сопровождения программной системы -необходимо каждый фрагмент системы тестировать систематическим образом, -повторно используя наработанные тесты. Общий репозиторий тестовых активов -должен находиться под контролем системы конфигурационного управления, с тем, -чтобы любые изменения в требованиях или дизайне могли быть отражены в -используемых наборах тестов, в том числе, с точки зрения их расширения новыми -тестами, если этого требуют соответствующие изменения. - -Шаблоны тестов конструируются на основе тестовых решений, наработанных для -проверки определенных ситуаций или типовых фрагментов программных систем. Такие -шаблоны должны быть документированы с учетом повторного использования, включая -прозрачные возможности их адаптации под специфику программных решений, к -которым такие шаблоны применяются. - -### Тестовые работы (Test Activities) - -Данная тема дает краткий обзор работ по тестированию. При этом подразумевается, -что успешное управление тестовыми работами сильно зависит от процессов -конфигурационного управления (Software Configuration Management), -рассматриваемых позднее как самостоятельная область знаний. - -#### Планирование (Planning) - -Также как и другие аспекты управления проектами, работы по тестированию должно -планироваться заранее. Как минимум, на уровне организации соответствующего -процесса. Ключевые аспекты планирования тестовой деятельности включают: - -- координацию персонала -- управление оборудованием и другими средствами, необходимыми для организации -тестирования -- планирование обработки нежелательных результатов (т.е. является управлением -определенными видами рисков) - -В случае одновременной поддержки и сопровождения нескольких версий программной -системы или нескольких систем, необходимо уделять особое внимание планированию -времени, усилий и ресурсов, связанных с проведением работ по тестированию. -Данная позиция перекликается с вопросами управления портфелями проектов с точки -зрения общего управления проектами. - -#### Генерация сценариев тестирования (Test-case generation) - -Создание тестовых сценариев основывается на уровне и конкретных техниках -тестирования. Тесты должны находиться под управлением системы конфигурационного -управления и описывать ожидаемые результаты тестирования. - -#### Разработка тестового окружения (Test environment development) - -Используемое для тестирования окружение должно быть совместимо с инструментами -программной инженерии (будут рассматриваться позднее как тема самостоятельной -области знаний). Это окружение должно обеспечивать разработку и контроль -тестовых сценариев, ведение журнала тестирования, и возможности восстановления -ожидаемых и отслеживаемых результатов тестирования, самих сценариев, а также -других активов тестирования. - -#### Выполнение тестов (Execution) - -Выполнение тестов должно содержать основные принципы ведения научного эксперимента: - -- должны фиксироваться все работы и результаты процесса тестирования -- форма журналирования таких работ и их результатов должна быть такой, чтобы -соответствующее содержание было понятно, однозначно интрепретируемой и -повторяемо другими лицами (не теми, кто первоначально проводил тестирование) -- тестирование должно проводиться в соответствии с заданными и -документированными процедурами -- тестирование должно производиться над однозначно идентифицируемой версией и -конфигурацией программной системы - -Ряд вопросов выполнения тестов и других работ по тестированию освещен в -стандарте IEEE 1008-87. - -#### Анализ результатов тестирования (Test results evaluation) - -Для определения успешности тестов их результаты должны оцениваться, -анализироваться. В большинстве случаев, “успешность” тестирования -подразумевает, что тестируемое программное обеспечение функционирует так, как -ожидалось и в процессе работы не приводит к непредусмотренным последствиям. Не -все такие последствия обязательно являются сбоями, они могут восприниматься как -“помехи”. Однако, любое непредусмотренное поведение может стать источником -сбоев при изменении конфигурации или условий функционирования системы, поэтому -требуют внимания, как минимум, с точки зрения идентификации причин таких помех. -Перед устранением обнаруженного сбоя, необходимо определить и зафиксировать те -усилия, которые необходимы для анализа проблемы, отладки и устранения. Это -позволит в дельнейшем обеспечить большую глубину измерений, а, соответственно, -в перспективе, иметь возможность улучшения самого процесса тестирования. В тех -случаях, когда результаты тестирования особенно важны, например, в силу -критичности обнаруженного сбоя, может быть сформирована специальная группа -анализа (review board). - -#### Отчёты о проблемах/журнал тестирования (Problem reporting/Test log) - -Во многих случаях, в процессе тестовой деятельности ведётся журнал -тестирования, фиксирующий информацию о соответствующих работах: когда -проводится тест, какой тест, кем проводится, для какой конфигурации программной -системы (в терминах параметров и в терминах идентифицируемой версии контекста -конфигурационного управления) и т.п. Неожиданные или некорректные результаты -тестов могут записываться в специальной подсистеме ведения отчетности по сбоям -(problem-reporting system, обеспечивая формирование базы данных, используемой -для отладки, устранения проблем и дальнейшего тестирования. Кроме того, -аномалии (помехи), которые нельзя идентифицировать как сбои, также могут -фиксироваться в журнале и/или системе ведения отчетности по сбоям. В любом -случае, документирование таких аномалий снижает риски процесса тестирования и -помогает решать вопросы повышения надежности самой тестируемой системы. Отчёты -по тестам могут являться входом для процесса управления изменениями и генерации -запросов на изменения (change request) в рамках процессов конфигурационного -управления (см. далее соответствующую область знаний “Software Configuration -Management”). - -#### Отслеживание дефектов (Defect tracking) - -Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и -ошибками, присутствующими в тестируемой программной системе (также они могут -быть следствием поведения операционного и/или тестового окружения). Такие -дефекты могут (и, чаще всего, должны) анализироваться для определения момента и -места первого появления данного дефекта в системе, какие типы ошибок стали -причиной этих дефектов (например, плохо сформулированные требования, -некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены -впервые. Вся эта информация используется для определения того, как может быть -улучшен сам процесс тестирования и насколько критична необходимость таких -улучшений. blob - /dev/null blob + cfe3acabbc28bc1f2820504131014bff7b142939 (mode 644) --- /dev/null +++ 4_software_testing.md @@ -0,0 +1,878 @@ +# Тестирование программного обеспечения + +Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - +SWEBOK. + +Содержит перевод описания области знаний SWEBOK “Software Testing”, с +замечаниями и комментариями. + +Тестирование (software testing) – деятельность, выполняемая для оценки и +улучшения качества программного обеспечения. Эта деятельность, в общем случае, +базируется на обнаружении дефектов и проблем в программных системах. + +Тестирование программных систем состоит из динамической верификации поведения +программ на конечном (ограниченном) наборе тестов (set of test cases), +выбранных соответствующим образом из обычно выполняемых действий прикладной +области и обеспечивающих проверку соответствия ожидаемому поведению системы. + +В данном определении тестирования выделены слова, определяющие основные +вопросы, которым адресуется данная область знаний: + +- Динамичность (dynamic): этот термин подразумевает тестирование всегда +предполагает выполнение тестируемой программы с заданными входными данными. При +этом, величины, задаваемые на вход тестируемому программному обеспечению, не +всегда достаточны для определения теста. Сложность и недетерминированность +систем приводит к тому, что система может по разному реагировать на одни и те +же входные параметры, в зависимости от состояния системы. В данной области +знаний термин “вход” (input) будет использоваться в рамках соглашения о том, +что вход может также специфицировать состояние системы, в тех случаях, когда +это необходимо. Кроме динамических техник проверки качества, то есть +тестирования, существуют также и статические техники, рассматриваемые в области +знаний “Software Quality”. +- Конечность (ограниченность, finite): даже для простых программ теоретически +возможно столь большое количество тестовых сценариев, что исчерпывающее +тестирование может занять многие месяцы и даже годы. Именно поэтому, с +практической точки зрения, всестороннее тестирование считается бесконечным. +Тестирование всегда предполагает компромисс между ограниченными ресурсами и +заданными сроками, с одной стороны, и практически неограниченными требованиями +по тестированию, с другой. То есть мы снова говорим об определении +характеристик “приемлемого” качества, на основе которых планируем необходимы +объем тестирования. +- Выбор (selection): многие предлагаемые техники тестирования отличаются друг +от друга в том, как выбираются сценарии тестирования. Инженеры по программному +обеспечению должны обладать представлением о том, что различные критерии выбора +тестов могут давать разные результаты, с точки зрения эффективности +тестирования. Определение подходящего набора тестов для заданных условий +является очень сложной проблемой. Обычно, для выбора соответствующих тестов +совместно применяют техники анализа рисков, анализ требований и соответствующую +экспертизу в области тестирования и заданной прикладной области. +- Ожидаемое поведение (expected behaviour): Хотя это не всегда легко, все же +необходимо решить, какое наблюдаемое поведение программы будет приемлемо, а +какое – нет. В противном случае, усилия по тестированию – бесполезны. +Наблюдаемое поведение может рассматриваться в контексте пользовательских +ожиданий (подразумевая “тестирования для проверки” - testing for validation), +спецификации (“тестирование для аттестации” - testing for verification) или, +наконец, в контексте предсказанного поведения на основе неявных требований или +обоснованных ожиданий. См. тему SWEBOK 6.4 “Приемочные тесты” области знаний +“Software Requirements”. + +Общий взгляд на тестирование программного обеспечения последние годы активно +эволюционировал, становясь все более конструктивным, прагматичным и +приближенным к реалиям современных проектов разработки программных систем. +Тестирование более не рассматривается как деятельность, начинающаяся только +после завершения фазы конструирования. Сегодня тестирование рассматривается как +деятельность, которую необходимо проводить на протяжении всего процесса +разработки и сопровождения и является важной частью конструирования программных +продуктов. Действительно, планирование тестирования должно начинаться на ранних +стадиях работы с требованиями, необходимо систематически и постоянно развивать +и уточнять планы тестов и соответствующие процедуры тестирования. Даже сами по +себе сценарии тестирования оказываются очень полезными для тех, кто занимается +проектированием, позволяя выделять те аспекты требований, которые могут +неоднозначно интерпретироваться или даже быть противоречивыми. + +Не секрет, что легче предотвратить проблему, чем бороться с ее последствиями. +Тестирование, наравне с управлением рисками, является тем инструментом, который +позволяет действовать именно в таком ключе. Причем действовать достаточно +эффективно. С другой стороны, необходимо осознавать, что даже если приемочные +тесты показали положительные результаты, это совсем не означает, что полученный +продукт не содержит ошибок. Этим вопросам, в частности, адресована область +знаний “Сопровождение программного обеспечения” (Software Maintenance). Однако, +адекватное внимание вопросам тестирования качественно снижает риск +возникновения ошибок на этапе эксплуатации, обеспечивая более высокую +удовлетворенность пользователей, что и является, по существу, целью любого +проекта. + +В области знаний “Качество программного обеспечения” (Software Quality) техники +управления качеством четко разделены на статические (без выполнения кода) и +динамические (с выполнением кода). Обе эти категории важны. Данная область +знаний - “Тестирование” – касается динамических техник. + +Как уже отмечалось ранее, тестирование тесно связано с областью знаний +“Конструирование” (Software Construction). Более того, модульное (unit-) и +интеграционное тестирование все чаще рассматривают как неотъемлемый элемент +деятельности по конструированию. + +![Рисунок 5. Область знаний “Тестирование программного обеспечения” [SWEBOK, 2004, с.5-2, рис. 1]](images/testing_area_small.jpg) + +## Основы тестирования (Software Testing Fundamentals) + +Охватывает основные понятия в области тестирования, базовые термины, ключевые +проблемы и их связь другими областями деятельности и знаний. + +### Терминология тестирования (Testing-Related Terminology) + +Определение тестирования и связанной терминологии достаточно полно даётся +в “Глоссарии терминов по программной инженерии” – IEEE Standard 610-90 +(Standard Glossary of Software Engineering Terminology). + +#### Недостатки и сбои (Faults vs. Failures) + +В литературе, посвященной программной инженерии, встречается множество +терминов, описывающих нарушение функционирования программных систем – +недостатки (faults), дефекты (defects), сбои (failures), ошибки (errors) и др. +Соответствующая терминология, как было указано выше в 1.1.1, описана в IEEE +Std. 610-90 также обсуждается в области знаний SWEBOK “Качество программного +обеспечения” (Software Quality). Важно чётко разделять причину нарушения работы +прикладных систем, обычно описываемую терминами недостаток или дефект, и +наблюдаемый нежелательный эффект, вызываемый этими причинами – сбой. Термин +ошибка, в зависимости от контекста, может описывать и как причину сбоя, и сам +сбой. Тестирование позволяет обнаружить дефекты, приводящие к сбоям. + +Необходимо понимать, что причина сбоя не всегда может быть однозначно +определена. Не существует теоретических критериев, позволяющих гарантированно +определить какой именно дефект приводит к наблюдаемому сбою. + +### Ключевые вопросы (Key Issues) + +#### Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования (Test selection criteria/test adequacy criteria, or stopping rules) + +Критерии отбора тестов могут использоваться как для создания набора тестов, так +и для проверки, насколько выбранные тесты адекватны решаемым задачам +(тестирования). При этом, обсуждаемые критерии помогают определить, когда можно +или необходимо прекратить тестирование. + +#### Эффективность тестирования/Цели тестирования (Test effectiveness/Objectives for testing) + +Тестирование – это наблюдение за выполнением программы, запущенной в целях +тестирования с заданными параметрами, по заданному сценарию или с другими +заданными начальными условиями или целями тестирования. Эффективность теста +может быть определена только в контексте заданных условий. + +#### Тестирование для идентификации дефектов (Testing for defect identification) + +Данный случай тестирования подразумевает успешность процедуры тестирования, +если дефект найден. Это отличается от подхода в тестировании, когда тесты +запускаются для демонстрации того, что программное обеспечение удовлетворяет +предъявляемым требованиями и, соответственно, тест считается успешным, если не +найдено дефектов. + +#### Проблема оракула (The oracle problem) + +“Оракул”, в данном контексте, любой агент (человек или программа), оценивающий +поведение программы, формулируя вердикт - тест пройден (“pass”) или нет +(“fail”). + +#### Теоретические и практические ограничения тестирования (Theoretical and practical limitation of testing) + +Теория тестирования выступает против необоснованного уровня доверия к серии +успешно пройденных тестов. К сожалению, большинство установленных результатов +теории тестирования – негативны, означая, по словам Дейкстры (Dijkstra), то, +что “тестирование программы может использоваться для демонстрации наличия +дефектов, но никогда не покажет их отсутствие”. Основная причина этого в том, +что полное (всеобъемлющее) тестирование недостижимо для реального программного +обеспечения. + +#### Проблема неосуществимых путей (The problem of infeasible paths) + +Эта сложнейшая проблема автоматизированного тестирования связана с тем, что +путь, по которому выполняются потоки работ тестируемой программной системы, не +могут быть заданы входными параметрами. + +#### Тестируемость (Testability) + +Это понятие может подразумевать две различных идеи. Первая описывает степень +легкости описания критериев покрытия тестами для заданной программной системы. +Вторая определяет возможность вероятность, возможность статистического +измерения того, что при тестировании проявится сбой программной системы. Обе +интерпретации этого понятия одинаково важны для тестирования. + +### Связь тестирования с другой деятельностью (Relationships of testing with other activities) + +Тестирование программного обеспечения отличается от статических техник +управления качеством, проверки корректности, отладки и программирования, но +связано со всеми этими работами. Полезно рассматривать тестирование с точки +зрения аналитиков и специалистов по сертификации качества. + +## Уровни тестирования (Test Levels) + +### Над чем производятся тесты (The target of the test) + +Тестирование обычно производится на протяжении всей разработки и сопровождения +на разных уровнях. Уровень тестирования определяет “над чем” производятся +тесты: над отдельным модулем, группой модулей или системой, в целом. При этом +ни один из уровней тестирования не может считаться приоритетным. Важны все +уровни тестирования, вне зависимости от используемых моделей и методологий. + +#### Модульное тестирование (Unit testing) + +Этот уровень тестирования позволяет проверить функционирование отдельно взятого +элемента системы. Что считать элементом – модулем системы определяется +контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 +“Standard for Software Unit Testing”, задающем интегрированную концепцию +систематического и документированного подхода к модульному тестированию. + +#### Интеграционное тестирование (Integration testing) + +Данный уровень тестирования является процессом проверки взаимодействия между +программными компонентами/модулями. + +Классические стратегии интеграционного тестирования – “сверху-вниз” и +“снизу-вверх” – используются для традиционных, иерархически структурированных +систем и их сложно применять, например, к тестированию слабосвязанных систем, +построенных в сервисно-ориентированных архитектурах (SOA). + +Современные стратегии в большей степени зависят от архитектуры тестируемой +системы и строятся на основе идентификации функциональных “потоков” (например, +потоков операций и данных). + +Интеграционное тестирование – постоянно проводимая деятельность, предполагающая +работу на достаточно высоком уровне абстракции. Наиболее успешная практика +интеграционного тестирования базируется на инкрементальном подходе, позволяющем +избежать проблем проведения разовых тестов, связанных с тестированием +результатов очередного длительного этапа работ, когда количество выявленных +дефектов приводит к серьезной переработке кода (традиционно, негативный опыт +выпуска и тестирования только крупных релизов называют “big bang”). + +#### Системное тестирование (System testing) + +Системное тестирование охватывает целиком всю систему. Большинство +функциональных сбоев должно быть идентифицировано еще на уровне модульных и +интеграционных тестов. В свою очередь, системное тестирование, обычно +фокусируется на нефункциональных требованиях – безопасности, +производительности, точности, надежности т.п. + +На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному +обеспечению, операционной среде и т.д. + +### Цели тестирования (Objectivies of Testing) + +Тестирование проводится в соответствии с определенными целями (могут быть +заданы явно или неявно) и различным уровнем точности. Определение цели точным +образом, выражаемым количественно, позволяет обеспечить контроль результатов +тестирования. + +Тестовые сценарии могут разрабатываться как для проверки функциональных +требований (известны как функциональные тесты), так и для оценки +нефункциональных требований. При этом, существуют такие тесты, когда +количественные параметры и результаты тестов могут лишь опосредованно говорить +об удовлетворении целям тестирования (например, “usability” – легкость, +простота использования, в большинстве случаев, не может быть явно описана +количественными характеристиками). + +Можно выделить следующие, наиболее распространенные и обоснованные цели (а, +соответственно, виды) тестирования: + +#### Приёмочное тестирование (Acceptance/qualification testing) + +Проверяет поведение системы на предмет удовлетворения требований заказчика. Это +возможно в том случае, если заказчик берет на себя ответственность, связанную с +проведением таких работ, как сторона “принимающая” программную систему, или +специфицированы типовые задачи, успешная проверка (тестирование) которых +позволяет говорить об удовлетворении требований заказчика. + +Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них. + +#### Установочное тестирование (Installation testing) + +Из названия следует, что данные тесты проводятся с целью проверки процедуры +инсталляции системы в целевом окружении. + +#### Альфа- и бета-тестирование (Alpha and beta testing) + +Перед тем, как выпускается программное обеспечение, как минимум, оно должно +проходить стадии альфа (внутреннее пробное использование) и бета (пробное +использование с привлечением отобранных внешних пользователей) версий. Отчеты +об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в +соответствии с определенными процедурами, включающими подтверждающие тесты +(любого уровня), проводимые специалистами группы разработки. + +Данный вид тестирования не может быть заранее спланирован. + +#### Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing) + +Эти тесты могут называться по разному, однако, их суть проста – проверка +соответствия системы, предъявляемым к ней требованиям, описанным на уровне +спецификации поведенческих характеристик. + +#### Достижение и оценка надежности (Reliability achievement and evaluation) + +Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение +надежности программных систем. Случайно генерируемые сценарии тестирования +могут применяться для статистической оценки надежности. Обе цели – повышение и +оценка надежности – могут достигаться при использовании моделей повышения +надежности. Эти вопросы затрагиваются и в тематическом фрагменте 4.1.4 “Life +test, reliability evaluation”. + +#### Регрессионное тестирование (Regression testing) + +Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of +Software Engineering Terminology”) гласит: “повторное выборочное тестирование +системы или компонент для проверки сделанных модификаций не должно приводить к +непредусмотренным эффектам”. На практике это означает, что если система успешно +проходила тесты до внесения модификаций, она должна их проходит и после +внесения таковых. Основная проблема регрессионного тестирования заключается в +поиске компромисса между имеющимеся ресурсами и необходимостью проведения таких +тестов по мере внесения каждого изменения. В определенной степени, задача +состоит в том, чтобы определить критерии “масштабов” изменений, с достижением +которых необходимо проводить регрессионные тесты. + +#### Тестирование производительности (Performance testing) + +Специализированные тесты проверки удовлетворения специфических требований, +предъявляемых к параметрам производительности. Существует особый подвид таких +тестов, когда делается попытка достижения количественных пределов, +обусловленных характеристиками самой системы и ее операционного окружения. + +#### Нагрузочное тестирование (Stress testing) + +Необходимо понимать отличия между рассмотренным выше тестированием +производительности с целью достижения ее реальных (достижимых) возможностей +производительности и выполнением программной системы c повышением нагрузки, +вплоть до достижения запланированных характеристик и далее, с отслеживанием +поведения на всем протяжении повышения загрузки системы. + +#### Сравнительное тестирование (Back-to-back testing) + +Единичный набор тестов, позволяющих сравнить две версии системы. + +#### Восстановительные тесты (Recovery testing) + +Цель – проверка возможностей рестарта системы в случае непредусмотренной +катастрофы (disaster), влияющей на функционирование операционной среды, в +которой выполняется система. + +#### Конфигурационное тестирование (Configuration testing) + +В случаях, если программное обеспечение создается для использования различными +пользователями (в терминах “ролей”), данный вид тестирования направлен на +проверку поведения и работоспособности системы в различных конфигурациях. + +#### Тестирование удобства и простоты использования (Usability testing) + +Цель – проверить, насколько легко конечный пользователь системы может ее +освоить, включая не только функциональную составляющую – саму систему, но и ее +документацию; насколько эффективно пользователь может выполнять задачи, +автоматизация которых осуществляется с использованием данной системы; наконец, +насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от +ошибок пользователя. + +#### Разработка, управляемая тестированием (Test-driven development) + +По-сути, это не столько техника тестирования, сколько стиль организации +процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью +требований (и соответствующих спецификаций) вместо того, чтобы рассматриваться +независимой деятельностью по проверке удовлетворения требований программной +системой. + +Иногда говорят о таком стиле разработки как о самостоятельной методологии – +TDD. Насколько это верно, зависит от того, что именно понимать под методологией +разработки. Скорее, с точки зрения автора, это техника, практика или стиль +организации работы, чем самостоятельная методология. + +В меньшей степени это относится к FDD – Feature-Driven Development (разработка +на основе функциональных возможностей). TDD может естественно рассматриваться +как составная часть XP или, как минимум Agile-методов. В свою очередь, FDD +может рассматриваться как один из методов гибкой разработки. + +В чем отличие столь близких, на первый взгляд, подходов (и, кстати, +соответствующих аббревиатур)? Причина – проста. Тесты – инструмент достижения +характеристик системы, удовлетворяющей заданным требованиям, то есть +потребностям пользователей, а “возможности” (features) – практически сами (чаще +– функциональные) требования, воплощенные (в идеальном случае) в код. + +## Техники тестирования (Test Techniques) + +### Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuition and experience) + +#### Специализированное тестирование (Ad hoc testing) + +Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, +интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся +ранее аналогий. Данный вид тестирования может быть полезен для идентификации +тех тестов, которые не охватываются рассматривавшимеся выше более +формализованными техниками. + +#### Исследовательское тестирование (Exploratory testing) + +Такое тестирование определяется как одновременное обучение, проектирование +теста и его исполнение. Данный вид тестирования заранее не определяется в плане +тестирования и такие тесты создаются, выполняются и модифицируются динамически, +по мере необходимости. Эффективность исследовательских тестов напрямую зависит +от знаний инженера, формируемых на основе поведения тестируемого продукта в +процессе проведения тестирования, степени знакомства с приложением, платформой, +типами возможных сбоев и дефектов, рисками, ассоциированными с конкретным +продуктом и т.п. + +### Техники, базирующиеся на спецификации (Specification-based techniques) + +#### Эквивалентное разделение <приложения> (Equivalence partitioning) + +Рассматриваемая область приложения разделяется на коллекцию наборов или +эквивалентных классов, которые считаются эквивалентными с точки зрения +рассматриваемых связей и характеристик <спецификации>. Репрезентативный набор +тестов (иногда – только один тест) формируется из тестов эквивалентных классов +(или наборов классов). + +#### Анализ граничных значений (Boundary-value analysis) + +Тесты строятся с ориентацией на использование тех величин, которые определяют +предельные характеристики тестируемой системы. Расширением этой техники +являются тесты оценки живучести (robustness testing) системы, проводимые с +величинами, выходящими за рамки специфицированных пределов значений. + +#### Таблицы принятия решений (Decision table) + +Такие таблицы представляют логические связи между условиями (могут +рассматриваться в качестве “входов”) и действиями (могут рассматриваться как +“выходы”). Набор тестов строится последовательным рассмотрением всех возможных +кросс-связей в такой таблице. + +#### Тесты на основе конечного автомата (Finite-state machine-based) + +Строятся как комбинация тестов для всех состояний и переходов между +состояниями, представленных в соответствующей модели (переходов и состояний +приложения). + +#### Тестирование на основе формальной спецификации (Testing from formal specification) + +Для спецификации, определенных с использованием формального языка, возможно +автоматически создавать и тесты для функциональных требований. В ряде случаев +могут строится на основе модели, являющейся частью спецификации, не +использующей формального языка описания. + +#### Случайное тестирование (Random testing) + +В отличие от статистического тестирования (будет рассматриваться в 3.5.1 +“Operational profile”), сами тесты генерируются случайным образом по списку +заданного набора специфицированных характеристик. + +### Техники, ориентированные на код (Code-based techniques) + +#### Тесты, базирующиеся на блок-схеме (Control-flow-based criteria) + +Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В +какой-то степени напоминает тесты на основе конечного автомата. Отличие – в +источнике набора тестов. Максимальная отдача от тестов на основе блок-схемы +получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии +потоков работ (поведения) тестируемой системы. Адекватность таких тестов +оценивается как процент покрытия всех возможных путей блок-схемы. + +#### Тесты на основе потоков данных (Data-flow-based criteria) + +В данных тестах отслеживается полный жизненный цикл величин (переменных) – с +момента рождения (определения), на всем протяжении использования, вплоть до +уничтожения (неопределенности). В реальной практике используются нестрогое +тестирование такого вида, ориентированное, например, только на проверку задания +начальных значений всех переменных или всех вхождений переменных в код, с точки +зрения их использования. + +#### Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph) + +Является не столько техникой тестирования, сколько контролем структуры +программы, представленной в виде дерева вызовов (например, sequence-диаграммы, +определенной в нотации UML и построенной на основе анализа кода). + +### Тестирование, ориентированное на дефекты (Fault-based techniques) + +Как это ни странно звучит на уровне названия таких техник тестирования, они, +действительно, ориентированы на ошибки. Точнее – на специфические категории +ошибок. + +#### Предположение ошибок (Error guessing) + +Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, +в результате анализа рисков. + +#### Тестирование мутаций (Mutation testing) + +Мутация – небольшое изменение тестируемой программы, произошедшее за счет +частных синтаксических изменений кода (в частности, рефакторинга). +Соответствующие тесты запускаются для оригинального и всех “мутировавших” +вариантов тестируемой программы. + +SWEBOK фокусируется на возможности, с помощью тестов, определять отличия между +мутантами и исходным вариантом кода. Если такое отличие установлено, мутанта +“убивают”, а тест считается успешным. Обычно, данный подход фокусируется на +синтаксических ошибках, на практике отслеживаемых современными средами +разработки и, конечно, компиляторами. + +### Техники, базирующиеся на условиях использования (Usage-based techniques) + +#### Операционный профиль (Operational profile) + +Базируется на условиях использования системы. + +Тестирование для оценки надёжности системы должно проводиться в таком тестовом +окружении, которое максимально приближено к реальным условиям работы системы. +Результаты таких тестов позволяют оценить поведение системы в реальных +условиях. Входные параметры тестов задаются на основе вероятностного +распределения соответствующих параметров или их наборов при эксплуатации +(входные данные могут прогнозироваться исходя из частоты возможных сценариев +работы пользователей). + +#### Тестирование, базирующееся на надежности инженерного процесса (Software Reliability Engineered Testing) + +Базируется на условиях разработки системы. + +Соответствующие тесты (обозначаемые также аббревиатурой SRET от Software +Reliability Engineered Testing) проектируются в контексте используемого +процесса разработки и методик тестирования. + +### Техники, базирующиеся на природе приложения (Techniques based on the nature of the application) + +Описанные выше техники могут применяться к любым типам программных систем. В то +же время, в зависимости от технологической или архитектурной природы +приложений, могут также применять специфические техники, важные именно для +заданного типа приложения. Среди таких техник: + +- Объектно-ориентированное тестирование +- Компонентно-ориентированное тестирование +- Web-ориентированное тестирование +- Тестирование на соответствие протоколам +- Тестирование систем реального времени + +### Выбор и комбинация различных техник (Selecting and combining techniques) + +#### Функциональное и структурное (Functional and structural) + +Техники тестирования, строящиеся на основе спецификаций или кода часто называют +функциональными или структурными, соответственно. Оба подхода не должны +противопоставляться, но дополнять друг друга. + +#### Определенное или случайное (Deterministic vs. random) + +Обычно тесты можно распределить по данным группам на основе используемой +политики выбора или определения входных параметров тестов. + +## Измерение результатов тестирования (Test-related measures) + +Часто техники тестирования путают с целями тестирования. Степень покрытия +тестами - не то же самое, что высокое качество тестируемой системы. Однако, эти +вопросы связаны. Чем выше степень покрытия, чем больше вероятность обнаружения +скрытых дефектов. Когда мы говорим о результатах тестирования, мы должны +подходить к их оценке, как оценке самой тестируемой системы. Именно +количественные оценки результатов тестирования (но не самих тестов, например, +покрытия ими возможных сценариев работы системы) освещаются ниже. В свою +очередь, метрики самих тестов или процесса тестирования, как такового – +вопросы, рассматриваемые в областях знаний “Процессы программной инженерии” +(Software Engineering Process) и “Управление инженерной деятельностью” +(Software Engineering Management). + +Измерения являются инструментом анализа качества. Измерение результатов +тестирования касается оценки качества получаемого продукта – программной +системы. История измерений демонстрирует прогресс достижения приемлемого +качества. Такая история является инструментом менеджмента качества. + +### Оценка программ в процессе тестирования (Evaluation of the program under test, IEEE 982.1-98) + +#### Измерения программ как часть планирования и разработки тестов (Program measurements to aid in planning and design testing) + +Данные измерения могут базироваться на размере программ (например, в терминах +количества строк кода или функциональных точек) или их структуре (например, с +точки зрения оценки ее сложности в тех или иных архитектурных терминах). +Структурные измерения могут также включать частоту обращений одних модулей +программы к другим. + +#### Типы дефектов, их классификация и статистика возникновения (Fault types, classification and statistics) + +В литературе по тестированию встречается большое количество различных +классификаций дефектов. Эффективность тестирования может быть достигнута в том +случае, если мы понимаем какие типы дефектов могут быть найдены в процессе +тестирования программной системы и как изменяется их частота во времени +(подразумевая историческую перспективу развития системы, а не её сбоев в +процессе работы). Эта информация позволяет прогнозировать качество системы и +помогает совершенствовать процесс разработки, в целом. + +Стандарт IEEE 1044-93 классифицирует возможные программные “аномалии”. + +#### Плотность дефектов (Fault density) + +Тестируемая программа может оцениваться на основе подсчета и классификации +найденных дефектов. Для каждого класса дефектов можно определить отношение +между количеством соответствующих дефектов и размером программы (в терминах +выбранных метрик оценки размера). + +#### Жизненный цикл тестов, оценка надежности (Life test, reliability evaluation) + +Статистические ожидания в отношении надежности программной системы (см. выше +2.2.5 “Достижение и оценка надежности”) могут использоваться для принятия +решения о продолжении или прекращении (окончании) тестирования, исходя из +заданных параметров приемлемого качества (например, плотности дефектов +заданного класса). + +#### Модели роста надежности (Reliability growth models) + +Данные модели обеспечивают возможности прогнозирования надежности системы, +базируясь на обнаруженных сбоях (см. выше 2.2.5). Модели такого рода +разбиваются на две группы – по количеству сбоев (failure-count) и времени между +сбоями (time-between-failure). + +### Оценка выполненных тестов (Evaluation of the tests performed) + +#### Метрики покрытия/глубины тестирования (Coverage/thoroughness measures) + +Критерии “адекватности” тестирования, в ряде случаев, требуют систематического +выполнения тестов для определенных набора элементов программы, задаваемых ее +архитектурой или спецификацией. Соответствующие метрики позволяют оценить +степень охвата характеристик системы (например, процент различных тестируемых +параметров производительности) и глубину их детализации (например, случайное +тестирование параметров производительности или с учетом граничных значений и +т.п.). Такие метрики помогают прогнозировать вероятностное достижение заданных +параметров качества системы. + +#### Введение искусственных дефектов (Fault seeding) + +“Своими руками?! Никогда! ...” – такова, обычно, первая реакция на идею +искусственного внесения дефектов, например, в программный код. На практике, +этот подход помогает классифицировать возможные ошибки и следующие за ними +сбои, применяя в дальнейшем полученные результаты для моделирования (пусть, +часто, и интуитивного) возможных причин реальных сбоев, обнаруженных в процессе +тестирования. + +Безусловно, данная техника должна использоваться с максимальной осторожностью +опытными специалистами, хорошо представляющими общую архитектуру тестируемой +программной системы и разбирающимеся во её внутренних связях. + +#### Оценка мутаций (Mutation score) + +Получаемое в процессе тестирования мутаций (см. выше 3.4.2) отношение “убитых” +к общему числу сгенерированных мутантов помогает измерить эффективность +выполняемых тестов. В силу специфики такой техники тестирования, количественные +оценки мутаций имеют практическое значение только для определенных типов +систем. + +#### Сравнение и относительная эффективность различных техник тестирования (Comparison and relative effectiveness of different techniques) + +Различные исследования в области тестирования связаны с попытками сравнения (с +точки зрения достигаемого качества продукта) разных подходов к тестированию. +Когда мы говорим об “эффективности” тестирования надо чётко договориться, что +именно мы подразумеваем под эффективностью, желательно, в количественном +выражении. Возможные варианты интерпретации этого понятия – число тестов +(данной техники), необходимых для обнаружения первого дефекта; отношение +количества всех обнаруженных дефектов к дефектам, найденным с применением +заданного подхода и т.п. Только обладая такого рода данными можно говорить о +корректности сравнения и оценки эффективности. + +## Процесс тестирования (Test Process) + +Концепции, стратегии, техники и измерения тестирования должны быть объеденены в +единый процесс тестирования как деятельности по обеспечению качества. Процесс +тестирования поддерживает работы по тестированию и определяет “правила игры” +для членов команды тестирования – от планирования тестов до оценки их +результатов. Хотя, в большинстве современных методов разработки, в частности, +гибких (agile) подходов, тестирование выходит на передний план и является одной +из базовых практик, многостороннее тестирование и, тем более, прогнозирование +на основе полученных результатов, часто подменяется отдельными работами в этой +области, не позволяющими добиться необходимых параметров качества (что, кстати, +ясно показывают уже упоминавшиеся результаты исследований Standish Group +[Chaos, 2004]). Только в том случае, если тестирование рассматривать как один +из важных процессов всей деятельности по созданию и поддержке программного +обеспечения, можно добиться оценки стоимости соответствующих работ и, в конце +концов, соблюсти те ограничения, которые определены для проекта. + +### Практические соображения (Practical considerations) + +#### Программирование без персоналий (Attitudes/Egoless programming) + +Очень важным компонентом успешного тестирования является совместное стремление +участников проекта обеспечить необходимое качество продукта. Менеджеры играют +ключевую роль в организации этой деятельности и на стадии разработки и в +процессе сопровождения программных систем. + +#### Руководства по тестированию (Test guides) + +Работы по тестированию могут руководствоваться различными соображениями и +критериями – от управления рисками до специфицированных сценариев работы +программных систем. В любом случае, желательно, исходя из ресурсов, +количественных оценок и других характеристик, обеспечить использование +различных техник тестирования для многосторонней оценки и улучшения качества +получаемого продукта. + +#### Управление процессом тестирования (Test process management) + +Работы по тестированию, ведущиеся на разных уровнях (см. выше 2. “Уровни +тестирования”), должны быть организованы в единый (однозначно интерпретируемый) +процесс, на основе учета 4 элементов и связанных с ними факторов: людей (в том +числе, в контексте организационной структуры и культуры), инструментов, +регламентов и количественных оценок (измерений). Стандарт жизненного цикла +IEEE, ISO/IEC, ГОСТ Р 12207 не выделяет деятельность по тестированию в качестве +самостоятельного процесса, однако, рассматривает соответствующие принципы работ +по тестированию как неотъемлемую часть процессов жизненного цикла и +сопровождения программных систем. В другом распространенном стандарте IEEE 1074 +деятельность по тестированию также объединена с другими оценочными работами как +интегральная часть полного жизненного цикла. + +#### Документирование тестов и рабочего продукта (Test documentation and work products) + +Документация – составная часть формализации процесса тестирования. Существует +стандарт IEEE 829-98 “Standard for Software Test Documentation”, +предоставляющий прекрасное описание тестовых документов, их связей между собой +и с процессом тестирования. Среди таких документов могут быть: + +- План тестирования +- Спецификация процедуры тестирования +- Спецификация тестов +- Лог тестов +- и др. + +Документирование тестов, в случае его формального ведения, должно быть +актуальным. В противном случае, как и любые другие документы, документация по +тестированию ляжет “мертвым грузом”. В то же время, деятельность по +тестированию, в случае отсутствия соответствующих регламентов и результатов (в +том числе, исторических, для разных проектов), сложно поддается оценке для +прогнозирования и, тем более, улучшению - в общем контексте улучшения +процессов. Если компания-разработчик не ведет соответствующей документации по +тестированию, говорить о сертификации или оценке по тем или иным моделям или +стандартам (CMMI, ISO, SixSigma и т.п.) – просто не представляется возможным. А +это уже вопрос доверия заказчиков, не имевших опыта работы с конкретной +компанией-разработчиком. + +#### Внутренние и независимые команды тестирования (Internal vs. independent test team) + +Формализация процесса тестирования может включать и организационную +формализацию команд(ы) тестирования. В нее могу входить как члены проектной +команды, в частности, разрабатывающие код, так и внешние лица и группы. В +идеале – желательно иметь как внутреннюю команду тестирования, так и внешнюю +группу тестирования (обеспечения качества). Соответствующие организационные +решения принимаются на основе стоимостных характеристик проекта, доступных +ресурсов, анализа стоимости тестирования, как такового, организационной +культуры и т.п. + +#### Оценка стоимости и усилий, а также другие измерения процесса (Cost/effort estimation and other process measures) + +Ряд метрик, связанных с оценкой ресурсов, необходимых для тестирования, как и +оценка эффективности тестирования на разных этапах и уровнях, основывается на +точке зрения и практиках менеджмента проекта (подразделения, компании...) и +используется для оценки и улучшения (оптимизации) процесса тестирования. Разные +техники, концепции и модели тестирования требуют разных затрат – по времени и +необходимым ресурсам. Результат – стоимость тестирования, как затратная +составляющая проекта. Понимание соответствия между стоимостью/усилиями, +необходимыми для той или иной формы тестирования является обязательной частью +современного управления проектами разработки программного обеспечения. + +#### Окончание тестирования (Termination) + +Очень важным аспектом тестирования является решение о том, в каком объеме +тестирование достаточно и когда необходимо завершить процесс тестирования. +Тщательные измерения, такие как достигнутое покрытие кода тестами или охват +функциональности, безусловно, очень полезны. Однако, сами по себе они не могут +определить критериев достаточности тестирования. Принятие решения об окончании +тестирования также включает рассмотрение стоимости и рисков, связанных с +потенциальными сбоями и нарушениями надёжности функционирования тестируемой +программной системы. В то же время, стоимость самого тестирования также +является одним из ограничений, на основе которых принимается решение о +продолжении тех или иных связанных с проектом работ (в частности, тестирования) +или об их прекращении. Cм. также 1.2.1 “Критерии отбора тестов/критерии +адекватности тестов, правила прекращения тестирования”. + +#### Повторное использование и шаблоны тестов (Test reuse and test patterns) + +Доведение тестов до конца и обеспечение сопровождения программной системы +необходимо каждый фрагмент системы тестировать систематическим образом, +повторно используя наработанные тесты. Общий репозиторий тестовых активов +должен находиться под контролем системы конфигурационного управления, с тем, +чтобы любые изменения в требованиях или дизайне могли быть отражены в +используемых наборах тестов, в том числе, с точки зрения их расширения новыми +тестами, если этого требуют соответствующие изменения. + +Шаблоны тестов конструируются на основе тестовых решений, наработанных для +проверки определенных ситуаций или типовых фрагментов программных систем. Такие +шаблоны должны быть документированы с учетом повторного использования, включая +прозрачные возможности их адаптации под специфику программных решений, к +которым такие шаблоны применяются. + +### Тестовые работы (Test Activities) + +Данная тема дает краткий обзор работ по тестированию. При этом подразумевается, +что успешное управление тестовыми работами сильно зависит от процессов +конфигурационного управления (Software Configuration Management), +рассматриваемых позднее как самостоятельная область знаний. + +#### Планирование (Planning) + +Также как и другие аспекты управления проектами, работы по тестированию должно +планироваться заранее. Как минимум, на уровне организации соответствующего +процесса. Ключевые аспекты планирования тестовой деятельности включают: + +- координацию персонала +- управление оборудованием и другими средствами, необходимыми для организации +тестирования +- планирование обработки нежелательных результатов (т.е. является управлением +определенными видами рисков) + +В случае одновременной поддержки и сопровождения нескольких версий программной +системы или нескольких систем, необходимо уделять особое внимание планированию +времени, усилий и ресурсов, связанных с проведением работ по тестированию. +Данная позиция перекликается с вопросами управления портфелями проектов с точки +зрения общего управления проектами. + +#### Генерация сценариев тестирования (Test-case generation) + +Создание тестовых сценариев основывается на уровне и конкретных техниках +тестирования. Тесты должны находиться под управлением системы конфигурационного +управления и описывать ожидаемые результаты тестирования. + +#### Разработка тестового окружения (Test environment development) + +Используемое для тестирования окружение должно быть совместимо с инструментами +программной инженерии (будут рассматриваться позднее как тема самостоятельной +области знаний). Это окружение должно обеспечивать разработку и контроль +тестовых сценариев, ведение журнала тестирования, и возможности восстановления +ожидаемых и отслеживаемых результатов тестирования, самих сценариев, а также +других активов тестирования. + +#### Выполнение тестов (Execution) + +Выполнение тестов должно содержать основные принципы ведения научного эксперимента: + +- должны фиксироваться все работы и результаты процесса тестирования +- форма журналирования таких работ и их результатов должна быть такой, чтобы +соответствующее содержание было понятно, однозначно интрепретируемой и +повторяемо другими лицами (не теми, кто первоначально проводил тестирование) +- тестирование должно проводиться в соответствии с заданными и +документированными процедурами +- тестирование должно производиться над однозначно идентифицируемой версией и +конфигурацией программной системы + +Ряд вопросов выполнения тестов и других работ по тестированию освещен в +стандарте IEEE 1008-87. + +#### Анализ результатов тестирования (Test results evaluation) + +Для определения успешности тестов их результаты должны оцениваться, +анализироваться. В большинстве случаев, “успешность” тестирования +подразумевает, что тестируемое программное обеспечение функционирует так, как +ожидалось и в процессе работы не приводит к непредусмотренным последствиям. Не +все такие последствия обязательно являются сбоями, они могут восприниматься как +“помехи”. Однако, любое непредусмотренное поведение может стать источником +сбоев при изменении конфигурации или условий функционирования системы, поэтому +требуют внимания, как минимум, с точки зрения идентификации причин таких помех. +Перед устранением обнаруженного сбоя, необходимо определить и зафиксировать те +усилия, которые необходимы для анализа проблемы, отладки и устранения. Это +позволит в дельнейшем обеспечить большую глубину измерений, а, соответственно, +в перспективе, иметь возможность улучшения самого процесса тестирования. В тех +случаях, когда результаты тестирования особенно важны, например, в силу +критичности обнаруженного сбоя, может быть сформирована специальная группа +анализа (review board). + +#### Отчёты о проблемах/журнал тестирования (Problem reporting/Test log) + +Во многих случаях, в процессе тестовой деятельности ведётся журнал +тестирования, фиксирующий информацию о соответствующих работах: когда +проводится тест, какой тест, кем проводится, для какой конфигурации программной +системы (в терминах параметров и в терминах идентифицируемой версии контекста +конфигурационного управления) и т.п. Неожиданные или некорректные результаты +тестов могут записываться в специальной подсистеме ведения отчетности по сбоям +(problem-reporting system, обеспечивая формирование базы данных, используемой +для отладки, устранения проблем и дальнейшего тестирования. Кроме того, +аномалии (помехи), которые нельзя идентифицировать как сбои, также могут +фиксироваться в журнале и/или системе ведения отчетности по сбоям. В любом +случае, документирование таких аномалий снижает риски процесса тестирования и +помогает решать вопросы повышения надежности самой тестируемой системы. Отчёты +по тестам могут являться входом для процесса управления изменениями и генерации +запросов на изменения (change request) в рамках процессов конфигурационного +управления (см. далее соответствующую область знаний “Software Configuration +Management”). + +#### Отслеживание дефектов (Defect tracking) + +Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и +ошибками, присутствующими в тестируемой программной системе (также они могут +быть следствием поведения операционного и/или тестового окружения). Такие +дефекты могут (и, чаще всего, должны) анализироваться для определения момента и +места первого появления данного дефекта в системе, какие типы ошибок стали +причиной этих дефектов (например, плохо сформулированные требования, +некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены +впервые. Вся эта информация используется для определения того, как может быть +улучшен сам процесс тестирования и насколько критична необходимость таких +улучшений. blob - 02a3e97adb5e3a31bf6e4bde9441b03079c8f3c8 (mode 644) blob + /dev/null --- 5_software_maintenance.markdown +++ /dev/null @@ -1,1106 +0,0 @@ -# Сопровождение программного обеспечения - -Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - -SWEBOK. - -Содержит перевод описания области знаний SWEBOK “Software Maintenance”, с -замечаниями и комментариями. - -Сопровождение программного обеспечения (Software Maintenance) - -Результат усилий по разработке программного обеспечения состоит в передачи в -эксплуатацию программного продукта, удовлетворяющего требованиям пользователей. -Соответственно, в процессе эксплуатации продукт будет изменяться или -эволюционировать. Связано это с обнаружением при реальном использовании скрытых -дефектов, изменениями в операционном окружении, необходимостью покрытия новых -требований и т.п. - -Фаза сопровождения в жизненном цикле, обычно, начинается сразу после -приемки/передачи продукта и действует в течение периода гарантии или, чаще, -технической поддержки. Однако, сама деятельность, связанная с сопровождением, -начинается намного раньше. - -Сопровождение программного обеспечения является составной частью жизненного -цикла. К сожалению, так сложилось, что вопросам сопровождения уделяется -существенно меньше внимания, чем другим фазам жизненного цикла. Исторически, в -большинстве организаций, разработка программных систем явно в фаворе, по -сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно -начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний -ITIL[^7] – IT Infrastructure Library, уделяющей особое внимание -вопросам поддержки и сопровождения инфраструктуры информационных технологий). В -большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций -организаций непосредственно в разработку программных систем, с целью увеличения -сроков использования уже существующего и применяемого ПО. Конечно, с точки -зрения автора, это не единственная причина. Скорее вопросы постоянно -изменяющихся бизнес-потребностей, динамика бизнеса и желание повысить отдачу от -уже эксплуатируемых систем приводит к усилению роли поддержки и сопровождения -программного обеспечения и естественной интеграции такой деятельности в -бизнес-процессы подразделений информационных технологий. - -[^7]: ITIL, в частности, определяет три аспекта управления жизненным циклом -приложений – определение требований, проектирование и разработку, и, наконец, -сопровождение. Все это, в контексте программного обеспечения, относится к -деятельности по управлению приложениями – Application Management в ITIL ICT -Infrastructure Management (ICT - Information and Communications Technology). - -Если проблема 2000 года, в свое время, оказала особое влияние на изменение -отношения к сопровождению на Западе, то расширение применения продуктов Open -Source во всем мире и связанная с ним волна надежд на получение дешевого -решения существующих задач привела к тому, что вопросы сопровождения вышли для -многих организаций на первый план. Ситуация во многих ИТ-подразделениях -показывает, что такие надежды оправдались только частично. Использование -продуктов Open Source не стало дешевой альтернативой и, в ряде случаев, привело -даже к бо́льшим проектным затратам именно в силу недостаточно проработанной -политики эксплуатации и сопровождения построенных на их основе прикладных -решений. Это ни в коем случае не значит, что волна Open Source “захлебнулась”. -Это означает только, что игнорирование оценки стоимости сопровождения привело к -превышению бюджетов, недостатку ресурсов и, в конце концов, частому провалу -инициатив по использованию таких продуктов в корпоративной среде. Неготовность -рассматривать жизненный цикл во времени как продолжающийся и после передачи -системы в эксплуатацию, непроработанность соответствующих процедур -корректировки продукта после его выпуска – основная беда и в бизнес-среде, для -которой программное обеспечение лишь инструмент, и в компаниях-интеграторах, -“забывающих” о необходимости развития успеха после внедрения системы у -заказчика, и у независимых поставщиков программных продуктов, которые, выпуская -новую версию лучшего в своем классе продукта, начинают работать над новой -версией, уделяя недостаточное внимание поддержке и обновлению уже существующих -версий. - -Сопровождение программного обеспечения в SWEBOK определяется как вся -совокупность деятельности, необходимой для обеспечения эффективной (с точки -зрения затрат) поддержки программных систем. Эти работы выполняются как перед -вводом системы в эксплуатацию, так и после этого. Предварительные работы -включают планирование деятельности по сопровождению системы, а также -организацию перехода к ее полнофункциональному использованию. Если новая -система должна заменить старую систему, предназначенную для решения тех же -задач, просто на новом уровне эффективности, стоимости использования, новых -функциональных возможностей, в этом случае важно обеспечить плавный переход со -старой системы на новую, максимально естественный для пользователей. С этим -связано не только планирование, например, переноса информации, хранимой в -соответствующих базах данных, но и обучение пользователей, подготовка, -настройка и проверка “боевой” конфигурации, определение последовательности -операций, организация и обучение службы поддержки (help-desk) и т.п. - -Область знаний “Сопровождение программного обеспечения” связана с другими -аспектами программной инженерии. По-сути, описание этой области знаний -непосредственно пересекается со всеми другими дисциплинами. - -![Рисунок 6. Область знаний “Сопровождение программного обеспечения” [SWEBOK, 2004, с.6-2, рис. 1]](images/maintenance_area_small.jpg) - -## Основы сопровождения программного обеспечения (Software Maintenance Fundamentals) - -Эта секция включает концепции и терминологию, формирующие основы понимания роли -и содержания работ по сопровождению программных систем. Темы данной секции -предоставляют соответствующие определения и описывают, почему именно существует -потребность в сопровождении. Категории сопровождения критически важны для -понимания сути обсуждаемых вопросов. - -### Определения и терминология (Definitions and Terminology) - -Сопровождение программного обеспечения определяется стандартом IEEE Standard -for Software Maintenance (IEEE 1219) как модификация программного продукта -после передачи в эксплуатацию для устранения сбоев, улучшения показателей -производительности и/или других характеристик (атрибутов) продукта, или -адаптации продукта для использования в модифицированном окружении. Интересно, -что данный стандарт также касается вопросов подготовки к сопровождению до -передачи системы в эксплуатацию, однако, структурно это сделано на уровне -соответствующего информационного приложения, включенного в стандарт. - -В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) -позиционирует сопровождение как один из главных процессов жизненного цикла. -Этот стандарт описывает сопровождение как процесс модификации программного -продукта в части его кода и документации для решения возникающих проблем <при -эксплуатации> или реализации потребностей в улучшениях <тех или иных -характеристик продукта>. Задача состоит в модификации продукта при условии -сохранения его целостности. Международный стандарт ISO/IEC 14764 (Standard for -Software Engineering - Software Maintenance) определяет сопровождение -программного обеспечения в тех же терминах, что и стандарт 12207, придавая -особое значение работам по подготовке к деятельности по сопровождению до -передачи системы в реальную эксплуатацию, например, вопросам планирования -регламентов и операций по сопровождению. - -### Природа сопровождения (Nature of Maintenance) - -Сопровождение поддерживает функционирование программного продукта на протяжении -всего операционного жизненного цикла, то есть периода его эксплуатации. В -процессе сопровождения фиксируются и отслеживаются запросы на модификацию -(также называемые “запросами на изменения” – change requests, в частности, в -контексте конфигурационного управления), оценивается влияние предлагаемых -изменений, модифицируется код и другие активы (артефакты) продукта, проводится -необходимое тестирование и, наконец, выпускается обновленная версия продукта. -Кроме того, проводится обучение пользователей и обеспечивается их ежедневная -поддержка при работе с текущей версией продукта. В SWEBOK отмечается, что -сопровождение, с точки зрения операций отслеживания и контроля, обладает -большим содержанием, чем разработка (в общем понимании). Объем и активность -операций по контролю разработки в большой степени зависит от сложившихся -практик, внутрикорпоративных регламентов и требований, а также применяемых -методологий и концепции управления (в частности – проектного менеджмента). Так -или иначе, отслеживание и контроль – ключевые элементы деятельности по -сопровождению программного обеспечения (как и других ИТ-активов предприятия). -Стандарт 12207 определяет понятие “maintainer” - в соответствующем ГОСТ он -именуется как “персонал сопровождения”, подразумевая организацию, выполняющая -работы по сопровождению. SWEBOK использует данный термин, также, и в отношении -лиц (individuals), проводящих определенные работы по сопровождению, в отличие, -например, от разработчиков, занимающихся реализацией системы в программном -коде. - -Стандарт жизненного цикла 12207 также идентифицирует основные работы по -сопровождению: реализация процесса <сопровождения>, анализ проблем и -модификаций (изменений), реализаций модификаций, обзор (оценка)/принятие -<решений> по сопровождению, миграция (с одной версии программного продукта на -другую, с одного продукта на другой) и вывод системы из эксплуатации. Эти -работы описываются далее в теме 3.2 “Работы по сопровождению” (Maintenance -Activities). - -Специалисты по сопровождению (персонал сопровождения) могут получать знания о -программном продукте непосредственно от разработчиков. Взаимодействие с -разработчиками и раннее привлечение этих специалистов помогает уменьшить -усилия, необходимые для адекватного сопровождения программной системы. По -мнению автора, передача знаний персоналу сопровождения, его обучение, должно -начинаться не позднее начала опытной эксплуатации продукта. В противном случае, -усилия на одновременную поддержку прикладной системы и обучение соответствующих -специалистов не только превысит реально допустимые нормы загрузки персонала -(как группы или службы сопровождения и техподдержки, так и разработчиков -системы), но снизит эффективность поддержки пользователей на критически важном -этапе первоначального использования новой системы. По опыту автора и -результатам обсуждения этого вопроса с сотрудниками внутрикорпоративных -ИТ-департаментов, обычно, в зависимости от сложности системы, пик нагрузки на -службу сопровождения приходится в течении первых 2 - 6 недель, с момента -передачи системы в реальную эксплуатацию, тем более, при отказе от -использования старой системы или ее предыдущей версии. SWEBOK отмечает, что, в -некоторых случаях, инженеры (создававшие систему) не могут быть привлечены к -обучению и поддержке персонала сопровождения. Особенно часто это касается -тиражируемых или “коробочных” систем. Это создает дополнительные трудности для -специалистов, обеспечивающих сопровождение. В то же время, инженеры, -занимающиеся технической поддержкой (несколько боле узкий круг в команде -сопровождения, включающей менеджеров, администраторов и других специалистов), -должны (в зависимости от типа продукта) иметь доступ к активам проекта -(например, описанию его внутренней архитектуры), включая код, документацию и -т.п. Именно таким образом начинает формироваться информационная инфраструктура -службы технической поддержки и сопровождения у производителей программных -продуктов. - -Практика показывает, что инженеры по технической поддержке производителя -программного обеспечения (не только “коробочного”, но и создаваемого и -настраиваемого интеграторами, обладающими собственными программными решениями) -должны не просто иметь доступ ко всем ключевым активам проекта (код, -документация, спецификации требований, внутренние модели и т.п.), но в их -обязанности входит создание “патчей” (patch – “заплата”), исправлений ошибок и, -в особых случаях, такие изменения, до выпуска новой версии продукта, создаются -с привлечением непосредственно разработчиков продукта (групп и подразделений -R&D – Research and Development). При этом, разработчики продукта информируются -о найденных ошибках и, в случае нахождения соответствующих решений -специалистами технической поддержки, такие решения передаются разработчикам с -тем, чтобы те либо включили такие изменения в новую версию программного -продукта (безусловно, в случае успешного прохождения всех необходимых тестов), -либо нашли более адекватное решение в контексте новой функциональности либо тех -изменений, которые включены в новую версию продукта. В обязанности инженеров -службы сопровождения, в общем случае, входит: проверка пользовательского -сценария, приводящего к сбою; идентификация причин сбоя, т.е локализация -ошибки/причин ее появления; предоставление соответствующих исправлений или, при -невозможности создания таковых на данном этапе либо в заданные сроки – -предоставление обходного пути решения проблемы для достижения требуемых -бизнес-задач (такие обходные пути, обычно, называют “workaround”); -журналирование всех работ и операций; помещение описания проблемы и ее решения -в базу знаний службы сопровождения; передача всей информации разработчикам; -своевременное информирование пользователя о статусе запроса и некоторые другие -работы, содержание которых может варьироваться, в зависимости от регламентов и -корпоративных стандартов в конкретной организации, либо параметров контракта на -сопровождение и техническую поддержку, если таковой есть. - -### Потребность в сопровождении (Need for Maintenance) - -Сопровождение необходимо для обеспечения того, чтобы программный продукт на -протяжении всего периода эксплуатации удовлетворяет требованиям пользователей. -Деятельность по сопровождению применима для программного обеспечения, -созданного с использованием любой модели жизненного цикла (например, -спиральной) и методологии разработки. На первый взгляд, это утверждение SWEBOK -может показаться тривиальным. Однако, обратитесь к своему опыту разработки и -использования различного программного обеспечения. Наверняка, Вы найдете случаи -из собственной практики или практики коллег, когда столь очевидное утверждение -хорошо бы донести до разработчика того или иного программного продукта. -Изменения программной системы могут быть обусловлены как действиями по -корректировке ее поведения или несвязанные с необходимостью корректировки -(подразумевая уже не исправление ошибок, а, например, повышение -производительности или расширение функциональности). - -В общем случае, работы по сопровождению должны проводиться для решения -следующих задач: - -- устранение сбоев -- улучшение дизайна -- реализация расширений <функциональных возможностей> -- создание интерфейсов взаимодействия с другими (внешними) системами -- адаптация (например, портирование) для возможности работы на другой -аппаратной платформе (или обновленной платформе), применения новых системных -возможностей, функционирования в среде обновленной телекоммуникационной -инфраструктуры и т.п. -- миграции унаследованного (legacy) программного обеспечения -- вывода программного обеспечения из эксплуатации - -Деятельность персонала сопровождения включает четыре ключевых аспекта: - -- поддержка контроля (управляемости) программного обеспечения в течение всего -цикла эксплуатации -- поддержка модификаций программных систем -- совершенствование существующих функций (судя по всему, SWEBOK в данном случае -подразумевает функции не программного обеспечения, а процессов сопровождения и -функции персонала сопровождения, как таковые) -- предотвращение падения производительности программной системы до -неприемлемого уровня - -Говоря о предотвращении деградации производительности, мы должны понимать, что -это, при всем желании совершенствования системы, может делаться и за счет -обновления мощности аппаратной части и/или соответствующей телекоммуникационной -инфраструктуры, если это более обосновано, чем модификация самой программной -системы. На самом деле это вопрос того, что окажется дешевле (и менее -рискованно), т.е. связано с затратами/ стоимостью соответствующих работ, -оборудования и поддержки обновленного системного окружения (что, к сожалению, -часто также не учитывается даже при более-менее сложившейся практике -сопровождения). - -### Приоритет стоимости сопровождения (Majority of Maintenance Costs) - -Работы по сопровождению потребляют если не большую (как отмечает SWEBOK), то -значительную часть финансовых ресурсов жизненного цикла программного -обеспечения. Общее понимание сопровождения подразумевает лишь устранение сбоев. -Однако, исследования и опросы на протяжении многих лет показывают, что более -80% усилий по сопровождению связаны не столько устранением сбоев, сколько с -другими работами, не связанными с исправлением дефектов. Многие менеджеры по -сопровождению объединяют в отчетности вопросы расширения функциональности и -исправления ошибок в поддерживаемых программных системах. Такое смешение -качественно различных работ приводит к неправильному представлению о реальной, -на самом деле, не столь высокой стоимости сопровождения в части устранения -дефектов. Понимание различных категорий работ в рамках деятельности по -сопровождению помогает понять структуру реальных затрат. Кроме того, понимание -факторов, влияющих на возможности сопровождения системы, помогают не только -сохранять необходимый уровень затрат, но и снижать их. - -Существуют как технические, так и другие (например, организационные, -являющиеся, по мнению автора, наиболее сильно влияющими на объем затрат) -факторы, оказывающие влияние на стоимость сопровождения, в целом: - -- тип приложения -- новизна программного обеспечения -- наличие и квалификация персонала по сопровождению -- длительность использования программной системы -- характеристики и специфика аппаратной части (а также телекоммуникационной -инфраструктуры) -- качество дизайна (например, модульность или масштабируемость), кода, -документации и соответствующих работ по тестированию системы - -### Эволюция программного обеспечения (Evolution of Software) - -В 1969 году Леман (см. рекомендуемую литературу к данной секции SWEBOK) впервые -связал деятельность по сопровождению и вопросы эволюции программного -обеспечения. Результаты более чем 20-ти летних исследований во главе с Леманом -привели к формулированию ряда важных положений, ключевое из которых утверждает, -что деятельность по сопровождению, по-сути, представляет собой эволюционную -разработку программных систем. Принятию тех или иных решений в процессе -сопровождения, помогает понимание того, что происходит с программной системой в -процессе ее эксплуатации. Существующее (особенно, корпоративное) программное -обеспечение никогда не бывает полностью завершенным и продолжает -эволюционировать в течение всего срока эксплуатации. В процессе -эволюционирования, программная система становится все более сложной до тех пор, -пока не предпринимаются специальные усилия (в том числе, в рамках специального -проекта по модификации) по уменьшению его сложности. - -В то же самое время, если можно выделить тенденции развития программной системы -и ее поведение достаточно стабильно, его эволюционирование можно измерить. -Последние годы делаются попытки разработать соответствующие модели оценки -усилий по сопровождению. В результате уже создаются определенные средства -(численные и инструментальные) управления работами по сопровождению, ряд из -которых приводится в ссылках к данной секции SWEBOK. - -### Категории сопровождения (Categories of Maintenance) - -Многие источники, в частности, стандарт IEEE 1216, определяют три категории -работ по сопровождению: корректировка, адаптация и совершенствование. Такая -классификация была обновлена в стандарте ISO/IEC 14764 Standard for Software -Engineering - Software Maintenance введением четвертой составляющей. Таким -образом, сегодня говорят о четырех категориях сопровождения: - -- Корректирующее сопровождение (corrective maintenance): “реактивная” -модификация программного продукта, выполняемая уже после передачи в -эксплуатацию для устранения сбоев; -- Адаптирующее сопровождение (adaptive maintenance): модификация программного -продукта на этапе эксплуатации для обеспечения продолжения его использования с -заданной эффективностью (с точки зрения удовлетворения потребностей -пользователей) в изменившемся или находящемся в процессе изменения окружении; в -первую очередь, подразумевается изменение бизнес-окружения, порождающее новые -требования к системе; -- Совершенствующее сопровождение (perfective maintenance): модификация -программного продукта на этапе эксплуатации для повышения характеристик -производительности и удобства сопровождения; -- Профилактическое сопровождение (preventive maintenance): модификация -программного продукта на этапе эксплуатации для идентификации и предотвращения -скрытых дефектов до того, когда они приведут к реальным сбоям. - -ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) -классифицирует адаптивное и совершенствующее сопровождение как работы по -расширению <функциональности> продукта. Этот стандарт также объединяет -корректирующую и профилактическую деятельность в общую категорию работ по -корректировке системы. Профилактическое сопровождение (новейшая категория работ -по сопровождению) наиболее часто проводится для программных систем, связанных с -вопросами безопасности <людей>. - -![Таблица 1. Категории сопровождения программного обеспечения.](images/maintenance_categories.jpg) - -## Ключевые вопросы сопровождения программного обеспечения (Key Issues in Software Maintenance) - -Для обеспечения эффективного сопровождения программных систем необходимо решать -целый комплекс вопросов и проблем, связанных с соответствующими работами. -Необходимо понимать, что процесс сопровождения предъявляет уникальные -технические и управленческие требования к персоналу, занимающемуся -сопровождениям и, в первую очередь, специалистам-инженерам. Попытка найти -дефект в продукте, содержащем 500 тысяч строк кода, написанных другими -инженерами – яркий пример сложностей, с которыми приходится сталкиваться -инженерам по сопровождению. Другой пример, уже организационный, постоянная -борьба за ресурсы с разработчиками (это чаще всего проявляется в вопросах -отвлечения разработчиков от текущей работы для помощи в решении проблем -сопровождения, а также в конкуренции за приоритеты финансирование разработки -новой системы или сопровождения существующей). Одновременное планирование -перспективной версии системы, реализация следующей версии и подготовка -критических патчей для текущей версии – еще один классический пример проблем, с -которыми приходится сталкиваться в процессе эксплуатации программного -обеспечения. - -Данная секция представляет некоторые технические и управленческие вопросы, -связанные с сопровождением программных систем. Эти вопросы и проблемы -сгруппированы в набор тем: - -- Технические вопросы -- Управленческие вопросы -- Оценка стоимости -- Измерения - -### Технические вопросы (Technical Issues) - -#### Ограниченное понимание (Limited understanding) - -Ограниченное понимание подразумевает как быстро инженер по сопровождению может -понять где необходимо внести исправления или изменения в код системы, которую -он не разрабатывал. Исследования показывают, что от 40 до 60 процентов усилий -по сопровождению тратится на анализ и понимание сопровождаемого программного -обеспечения. Формирование целостного взгляда о системе представляет большое -значение для инженеров. Этот процесс более сложен в случае анализа текстового -представления системы – ее исходного кода, особенно, когда процесс эволюции -системы от сборки к сборки, от релиза к релизу, в нем никак не отмечен, не -документирован и когда разработчики не могут объяснить историю и структуру -изменений, что, к сожалению, случается достаточно часто. -Для объектно-ориентированных программ качественно упрощает задачу понимания -кода использование UML-инструментария, способного на основе кода восстановить -не только модель классов, но и их взаимодействия в форме диаграмм классов -(class diagram), коммуникаций или сотрудничества (collaboration в UML1.x, -переименованная в communication в UML 2.0) и, особенно, последовательностей -(sequence diagram), демонстрирующая структуру взаимных вызовов во времени. Если -соответствующий инструментарий предоставляет одновременную визуализацию кода и -диаграммы и обеспечивает взаимную синхронизацию их с точки зрения навигации -(выбор метода в любой из представленных диаграмм автоматически позиционирует -соответствующим образом редактор кода и, наоборот) – такие средства -автоматизации могут качественно сократить время, необходимое для формирования -представления о системе, иногда – даже не в разы, а на порядок (конечно, при -достаточном уровне знания используемых технологий со стороны инженера по -сопровождению). Если к этому добавить документированность (и доступность -соответствующих активов – спецификаций, моделей) архитектуры и ключевых -технологических решений со стороны разработчиков системы – обсуждаемый вопрос, -конечно, не становится тривиальным, однако, превращается во вполне решаемую -задачу. Вообще говоря, использование соответствующих средств автоматизации -построения моделей по коду (задача обратного инжиниринга – reverse engineering) -является обоснованной практикой изучения любой системы или фреймворка. Опыт -показывает, что при достаточной квалификации инженера, формирование общего -архитектурного представления о системе (или фреймворке), понимания того, какие -технологические и структурные подходы и шаблоны использовались при ее -построении, позволяет решать возникающие вопросы корректировки кода и -расширения функциональности системы, не нарушая общие принципы ее построения, -естественным образом обеспечивая ее эволюцию, без ущерба ее целостности. При -таком понимании, даже не заглядывая в код системы или фреймворка, инженер -способен с очень большой вероятностью предположить возможные причины сбоя, а, в -общем случае, и любых аспектов поведения системы. Тема обратного инжиниринга -освещается SWEBOK как самостоятельная техника сопровождения (4.3), однако, -здесь показалось важным особо акцентировать на ней внимание именно в этой части -обсуждения вопросов сопровождения. - -#### Тестирование (Testing) - -Стоимость повторения полного набора тестов для основных модулей системы может -быть существенным как по времени, так и по стоимости. Для сопровождения системы -особо значимым является выборочное регрессионное тестирование (см. область -знаний Software Testing, тему 2.2.6 Регрессионное тестирование) системы или его -компонент для проверки того, что внесенные изменения привели к -непреднамеренному изменению поведения программного обеспечения. Вопрос состоит -в том, что часто сложно найти время для необходимого тестирования. Не меньшей -проблемой является и координации в проведении тестов различными членами группы -сопровождения, занимающимеся решением различных задач. Если же система -выполняет критичные <для бизнеса> функции, временный вывод системы из -эксплуатации (как говорят, перевод системы в offline) для выполнения тестов -часто оказывается просто невозможен. - -Таким образом, одним из ключевых вопросов сопровождения является организация -работ по тестированию модификаций эксплуатируемых систем, вплоть до -предварительного планирования и разработки регламентов, в соответствии с -которыми, например, основываясь на оценке критичности запросов на изменения -(как дефектов, так и важных расширений – будь то новая функциональность или -необходимое расширение интеграционных возможностей), затрагиваемых модулях, -персоналом сопровождения будут проводиться стандартные процедуры. К таким -процедурам, наравне с журналированием запросов и проводимых работ, могут и, -скорее, должны относиться: анализ влияния <изменений> (impact analysis – см. -ниже), оценка рисков, тестирование (различными методами, в различном объеме), -выпуск предварительных версий патчей/обновлений в ограниченное использование -(если это позволяет спецификация системы), использование “клона” системы -(развертывание ее на идентичном оборудовании в идентичной конфигурации) и т.п. - -#### Анализ влияния (Impact analysis) - -Анализ влияния описывает как проводить (в частности, с точки зрения -эффективности затрат) полный анализ возможных последствий и влияний изменений, -вносимых в существующую систему. Персонал сопровождения должен обладать -необходимыми знаниями о специфике системы (в идеальном случае, иметь полное -представление о системе на уровне ее разработчиков) – ее содержании и -структуре. Инженеры используют эти знания для выполнения работ по анализу -влияния, идентифицируя все системы[^8] и программные продукты, на -которые могут повлиять изменения, вносимые в обслуживаемую программную систему. -При этом, должны быть определены риски, связанные с внесением обсуждаемых -изменений. - -[^8]: Как мы видим из описания данных работ в SWEBOK, речь идет не только о -компонентах системы, но и о ее окружении, включая другие системы, -функционирующие в том же операционном/системном окружении. - -Запросы на изменения[^9] (change requests - CR), иногда упоминаемые как -запросы на модификацию (modification request - MR), часто также называемые -отчетами о проблемах (problem report - PR), должны анализироваться и -трансформироваться в термины программной системы. Эти шаги выполняются после -того, как соответствующий запрос на изменение начинает обрабатываться в рамках -процесса управления изменениями или, как принято называть, конфигурационного -управления, и фиксируется в системе конфигурационного управления (см. область -знаний Configuration Management). - -[^9]: Обычно запросы на изменения разделяют на две категории – “пожелания” -(suggestions), относящиеся к расширению системы, и “отчеты об ошибках” (defect -или bug report), направляемые пользователями в службу сопровождения или -инженерами по тестированию разработчикам. - -Цели анализа влияния могут быть сформулированы следующим образом: - -- Определение содержания изменений для задания работ по планированию и -реализации -- Получение максимально возможной оценки ресурсов, необходимых для проведения -соответствующих работ -- Анализ стоимости и выгоды от внесения запрошенных изменений (обычно касается -пожеланий, запросов на расширение системы) -- Обсуждение сложности вопросов, связанных с внесением соответствующих -изменений - -Сложность решения вопроса, поставленного соответствующим запросом на изменения, -часто является основным фактором определения того, когда и как будет решена -проблема. Инженеры идентифицирую компоненты, в которые необходимо внести -изменения. Обычно рассматривается несколько вариантов решения проблемы и -вырабатывается (также, обязательно, фиксируются в соответствующей системе -обработки запросов на изменения) наиболее оптимальный путь ее решения. - -При этом, оптимальность пути не всегда означает наиболее ”красивое” -технологическое решение. Иногда это может быть временное решение, может быть -даже нарушающее архитектурные шаблоны системы, однако, обоснованное с точки -зрения сроков и стоимости его реализации. В то же самое время, результаты -анализа направляются разработчикам системы, обычно работающими над следующей -версией, для включения соответствующего изменения уже в рамках принятого стиля -кодирования, соглашений, архитектурных шаблонов и т.п. Безусловно, такой путь -многим может показаться просто неэтичным, с точки зрения “настоящего” -инженерного подхода. Однако, если разработчики готовят следующую версию -системы, затрагивая модуль, модифицируемый службой сопровождения, с точки -зрения бизнес-решений, “некрасивый”, но быстрый путь достижения требуемого -поведения системы, в большинстве случаев, будет выглядеть более обоснованным, -чем принятие на себя персоналом сопровождения функций разработчиков системы. -Иногда, если требуемое изменение не столь критично, чтобы решение было -предоставлено “вчера” (хотя пользователи, практически всегда, именно так -характеризуют свои запросы в терминах приоритета), логичным выглядит -откладывание проведения соответствующих модификаций и передача этих работ -непосредственно разработчикам. Как это часто можно услышать – “будет доступно в -следующем релизе”. Ничего не напоминает? Но, экономически, это часто бывает -более чем оправдано. - -Если программное обеспечение изначально разрабатывалось с учетом дальнейшей -поддержки, это может существенно облегчить анализ влияний, как одной из -ключевых работ по сопровождению. - -#### Возможность сопровождения (Maintainability) - -Возможность сопровождения или сопровождаемость программной системы -определяется, например, глоссарием IEEE (стандарт 610.12-90 Standard Glossary -for Software Engineering Terminology, обновление 2002 года) как легкость -сопровождения, расширения, адаптации и корректировки для удовлетворения -заданных требований. Стандарт ISO/IEC 9126-01 (Software Engineering – Product -Quality – Part 1: Quality Model, 2001 г.) определяет возможность сопровождения -как одну из характеристик качества. - -Для уменьшения стоимости дальнейшего сопровождения, на протяжении всего -процесса разработки необходимо специфицировать, оценивать и контролировать -характеристики, влияющие на возможность сопровождения. Если такие работы -проводятся регулярно, это облегчает дальнейшее сопровождение, повышая его -сопровождаемость (в частности, как характеристику качества). Часто этого -сложно добиться, потому, что, к сожалению, такого рода характеристики -игнорируются при разработки. Разработчики заняты другими запланированными -работами и также часто пренебрегают требованиями, предъявляемыми к -сопровождаемости системы. - -Одной из ключевых проблем сопровождения является отсутствие системной -документации, мешающее формированию понимания системы и, как следствие, -невозможности адекватного анализа влияния. Эта и другие проблемы могут быть -решены при использовании систематического подхода к построению зрелых -процессов, применению соответствующих техник и автоматизации необходимых задач -по поддержке жизненного цикла с помощью специализированных инструментальных -средств. - -### Управленческие вопросы (Management Issues) - -#### Согласование с организационными целями (Alignment with organizational objectivies) - -Организационные цели описывают как продемонстрировать возврат инвестиций от -деятельности по сопровождению программного обеспечения. Обычно, разработка -ведется на проектной основе, с определенными временными и бюджетными -ограничениями. Главный акцент, при этом, делается на выпуске системы, -отвечающей потребностям пользователей, в заданные сроки и в рамках бюджета. В -отличие от этого, сопровождение системы преследует цели максимального продления -срока эксплуатации программного обеспечения. Такой подход может основываться на -необходимости обновления и расширения программного обеспечения, как отклика на -изменяющиеся потребности пользователей. При этом, оценка возврата инвестиций -становится более сложной и приводит к формированию точки зрения старшего -менеджмента, что деятельность по сопровождению потребляет значительную часть -ресурсов без явно выраженной и количественно определяемой отдачи для -организации. - -#### Проблемы кадрового обеспечения[^10] (Staffing) - -Данная тема касается вопросов привлечения и удержания квалифицированного -персонала по сопровождению. Часто, работа по сопровождению не выглядит -привлекательной, инженеры по поддержке воспринимаются как специалисты “второго -класса” (в SWEBOK используется устойчивое выражение “second-class citizens”), -что приводит к безусловному падению духа коллектива, отвечающего за поддержку -систем. - -Это серьезный вызов для менеджеров, отвечающих за вопросы сопровождения и, -вообще говоря, является классической задачей общего менеджмента. Решение этой -задачи, в первую очередь, находится в руках старшего менеджмента, формирующего -соответствующий стиль отношений между функциональными и вспомогательными -подразделениями. На более высоком уровне, для организаций и бизнесов - -потребителей информационных технологий, эта задача связана с -внутрикорпоративными департаментами автоматизации, в целом, которые слишком -часто воспринимаются только как центры затрат, а информационные технологии не -рассматриваются как актив. В результате, такая позиция приводит к снижению -эффективности работы подразделений автоматизации, а, следовательно, и падению -качества информационного обеспечения бизнеса, что сказывается, в подавляющем -большинстве случаев, и на бизнесе, как таковом. - -[^10]: Такой перевод, вместо просто “кадрового обеспечения”, в большей степени -соответствует принятому использованию термина staffing. Часто, staffing -подразумевает и высокую текучесть кадров. - -#### Процесс (Process) - -Процесс (в общем случае, жизненный цикл, прим. автора) является набором работ -(activities), методов, практик и, своего рода, трансформаций, которые -используются людьми для разработки и сопровождения программных систем и -ассоциированных с ними продуктов. На уровне процесса, деятельность по -сопровождению программного обеспечения имеет очень много общего с разработкой, -например, в части конфигурационного управления, являющегося критически важной -составляющей обоих видов деятельности. В то же время, сопровождение включает -работы, не представленные в процессе разработки (в теме 3.2 представлено -описание такого рода уникальных работ). Эта деятельность требует от менеджмента -специального внимания. - -#### Организационные аспекты сопровождения (Organizational aspects of maintenance) - -В первую очередь, организационные вопросы подразумевают какая организация будет -отвечать и/или какие функции необходимо выполнять для обеспечения деятельности -по сопровождению. Команда, разрабатывавшая программный продукт, далеко не -всегда отвечает за его сопровождение. Это не только стандартное управленческое -решение независимых поставщиков программного обеспечения, но, также, часто -встречается в организациях, использующих программные продукты в целях -автоматизации своих бизнес-функций. - -При решении вопроса, где (кем) будут осуществляться функции по сопровождению, -может быть принято решение оставить их непосредственно тем, кто разрабатывал -систему (как в терминах организации/компании, так и подразумевая -непосредственно коллектив разработчиков), или передать другой команде или -стороне (maintainer). Часто, выбор сопровождающей организации осуществляется -исходя из тех соображений, которые выглядят обоснованными для обеспечения -адекватной поддержки системы и возможности ее эволюционирования для -удовлетворения меняющихся потребностей пользователей. К сожалению (чего, в -принципе, и следовало ожидать), универсальных подходов в решении данного -вопроса, кем будет сопровождаться система – нет. Соответствующие решения -принимаются в каждом конкретном случае, с учетом его специфики (case-by-case). -Но, что действительно важно отметить, делегирование или назначение полномочий и -ответственности по сопровождению должно быть произведено по отношению только к -одной организации или лицу (менеджеру соответствующей команды поддержки). Все, -так или иначе, зависит от организационной структуры организации/компании, -эксплуатирующей программное обеспечение. - -#### Аутсоурсинг (Outsourcing) - -Заимствованный термин “аутсоурсинг” уже прижился не только в среде -ИТ-менеджеров, он стал частью современного бизнеса и управленческих практик. -Суть его заключается в передаче работ, в первую очередь, вспомогательных -(непрофильных для организации) “на сторону”. Крупные корпорации передают в -управление другим организациям целые портфели программных систем, а, иногда, и -целиком всю ИТ-инфраструктуру. В то же время, существенно более часто, -сопровождение передается другим организациям только для “второстепенных” -программных систем (или, как минимум, не критичных для выполнения -бизнес-функций), так как владельцы таких систем не желают терять контроль над -ассоциированными с этими системами данными и/или функциональностью. Отмечается, -что некоторые передают работы по сопровождению “в аутсоурсинг” только в тех -случаях, если убеждены в стратегическом контроле над сопровождением. - -Часто можно наблюдать, когда для решения вопросов сопровождения (при сохранении -“стратегического контроля”), компании, для которых информационные технологии не -являются профильными, но воспринимаются в качестве актива, формируют -специализированные дочерние бизнес-структуры, которым и передаются функции -сопровождения, а также и непосредственно разработки программных систем и, более -того, поддержки и развития всей ИТ-инфраструктуры. Это делается с тем, чтобы -функционируя в качестве самостоятельной бизнес-сущности, уже бывшие -внутрикорпоративные подразделения автоматизации, могли обеспечить большую -прозрачность финансовых потоков, затрат, связанных с информационным -технологиями. Но, это тема уже относится к общим вопросам управления и, -безусловно, требует самостоятельного обсуждения, в контексте, опять-таки, -конкретной организации или бизнес-структуры. Однако, нельзя было не обозначить -важность обсуждаемого вопроса в данном контексте, ведь именно деятельность по -сопровождению часто подвигает организации-потребители ИТ к принятию столь -серьезных организационных и бизнес-решений. - -При этом, подчеркивает SWEBOK, контроль сложно измерить. В свою очередь, перед -аутсоурсером (организацией, принимающей на себя ответственность по -сопровождению) стоит серьезная проблема по определению содержания -соответствующих работ, в том числе, для описания содержания соответствующего -контракта. Отмечается, что около 50% сервисов, предоставляемых аутсоурсером, -проводятся без соответствующего детального и однозначно интерпретируемого -соглашения (service level agreement, SLA). Компании, занимающиеся -аутсоурсингом, обычно затрачивают несколько месяцев на оценку программного -обеспечения прежде, чем заключают соответствующий контракт. Еще один вопрос, -требующий специального внимания, заключается в необходимости определения -процесса и процедур передачи программного обеспечения на внешнее сопровождение. - -### Оценка стоимости сопровождения (Maintenance Cost Estimation) - -Как уже отмечалось, инженеры должны понимать разницу в различных категориях -сопровождения. Это, в большой степени, необходимо для оценки соответствующих -затрат. С точки зрения планирования, как составной части проектной и -управленческой деятельности, оценка стоимости является важным аспектом -деятельности по сопровождению программного обеспечения. - -#### Оценка стоимости (Cost Estimation) - -При обсуждении анализа влияния (см. 2.1.3 Impact Analysis) говорилось о том, -что такой анализ помогает в оценке стоимости работ по сопровождению. На эти -затраты оказывает влияние множество технических и других факторов. ISO/IEC -14764 (Standard for Software Engineering - Software Maintenance)определяет, что -“существует два наиболее популярных метода оценки стоимости сопровождения – -параметрическая модель и использование опыта”. Чаще всего, оба этих подхода -комбинируются для повышения точности оценки. - -#### Параметрические модели (Parametric models) - -SWEBOK приводит ряд источников, подробно рассматривающих вопросы оценки -стоимости сопровождения и, в частности, параметрические модели. Для -использования таких моделей используются данные предыдущих проектов. Наравне с -историческими данными используется метод функциональных точек (см. стандарт -IEEE 14143.1-00). - -#### Опыт (Experience) - -Среди тех подходов, которые позволяют повысить точность оценок, полученных при -использовании параметрических моделей – применение опыта (в форме экспертного -мнения, например, при использовании техники оценки “Delphi”, название которой -происходит от “делфийского оракула”), аналогий, а также структуры декомпозиции -работ. Наилучшие результаты получаются в случае сочетания эмпирических методов -с имеющимся опытом. Получаемые данные используются как результат программы -измерения аспектов сопровождения. - -### Измерения в сопровождении программного обеспечения (Software Maintenance Measurement) - -Формы и данные измерений в процессе сопровождения могут объединяться в единую -программу корпоративную программу количественных оценок, проводимых в отношении -программного обеспечения. Многие организации используют популярный и практичный -подход для измерений, базирующийся на оценке количества проблем и статуса их -решений (issue-driven measurement). Идеи этого подхода систематизированы в -проекте Practical Software and Systems Measurement (PSM). Существуют общие (для -всего жизненного цикла) метрики и, соответственно, их категории, в частности, -определяемые Институтом Программной Инженерии университета Карнеги-Меллон -(Software Engineering Institute, Carnegie-Mellon University – SEI CMU): размер, -усилия, расписание и качество. Применение этих метрик является хорошей -отправной точкой для оценки работ со стороны организации, отвечающей за -сопровождение. - -Более детальное обсуждение вопросов измерений в отношении продуктов и процессов -представлено в области знаний “Процесс программной инженерии (Software -Engineering Process). В свою очередь, вопросы организации программы измерений -относятся к области знаний “Управление программной инженерией” (Software -Engineering Management). - -#### Специализированные метрики (Specific Measures) - -Существуют различные методы внутренней оценки продуктивности (benchmarking) -персонала сопровождения для сравнения работы различных групп сопровождения. -Организация, ведущая сопровождение, должна определить метрики, по которым будут -оцениваться соответствующие работы. Стандарты IEEE 1219 (Standard for Software -Maintenance) и ISO/IEC 9126-01 (Software Engineering – Product Quality – Part -1: Quality Model, 2001 г.) предлагают специализированные метрики, -ориентированные именно на вопросы сопровождения и соответствующие программы. - -Ниже представлены типичные метрики оценки работ по сопровождению, -соответствующих распространенной классификации эксплуатационных характеристик -программного обеспечения: - -- Анализируемость (Analyzability): оценка (в первую очередь, дополнительных) -усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, -а также для идентификации тех фрагментов программной системы, которые должны -быть модифицированы. -- Изменяемость (Changeability): оценка усилий, необходимых для проведения -заданных модификаций. -- Стабильность (Stability): оценка случаев непредусмотренного поведения -системы, включая ситуации, обнаруженные в процессе тестирования. -- Тестируемость (Testability): оценка усилий персонала сопровождения и -пользователей по тестированию модифицированного программного обеспечения. - -## Процесс сопровождения (Maintenance Process) - -Вопросы организации процесса сопровождения напрямую связаны с соответствующими -стандартами и de facto практиками реализации такого процесса. Тема “Работы по -сопровождению” (Maintenance Activities) различает вопросы сопровождения и -разработки и показывает взаимосвязь c другими аспектами деятельности -программной инженерии. - -Типичные и распространенные потребности в процессах программной инженерии -подробно описаны и документированы в различных источниках. Одна из наиболее -детально проработанных и распространенных (на уровне стандарта de facto) -процессных моделей, изначально созданных с ориентацией на программное -обеспечение – CMMI (Capability Maturity Model Integration – интегрированная -модель зрелости), разработанная в Институте программной инженерии университета -Карнеги-Меллон (SEI CMU). CMMI, в частности, уделяет специальное внимание -процессам сопровождения. Существуют и другие, менее распространенные, но тем не -менее развивающиеся модели. - -### Процессы сопровождения (Maintenance Processes) - -Процессы сопровождения описывают необходимые работы и детальные входы/выходы -этих работ. Эти процессы рассматриваются в стандартах IEEE 1219 (Standard for -Software Maintenance) и ISO/IEC 14764 (Standard for Software Engineering - -Software Maintenance). - -Процесс сопровождения начинается по стандарту IEEE 1219 с момента передачи -программной системы в эксплуатацию (post-delivery stage) и касается таких -вопросов, как планирование деятельности по сопровождению (см. рисунок 2). - -![Рисунок 2. Работы в процессе сопровождения по стандарту IEEE 1219.](images/maintenance_2-activities.jpg) - -Стандарт ISO/IEC 14764 уточняет положения, связанные с процессом сопровождения, -стандарта жизненного цикла 12207. Работы по сопровождению, описанные в этом -стандарте аналогичны работам в IEEE 1219, за исключением того, что -сгруппированы несколько иначе (см. рисунок 3). - -![Рисунок 3. Процесс сопровождения по стандарту ISO/IEC 14764.](images/maintenance_3-process.jpg) - -Работы по сопровождению в стандарте 14764 разбиты на задачи: - -- Process Implementation – реализация процесса -- Problem and Modification Analysis – анализ проблем и <необходимых> -модификаций -- Modification Implementation –проведение модификаций (реализация изменений) -- Maintenance Review/Acceptance – оценка и принятие <проведенных работ> при -сопровождении -- Migration – миграция (на модифицированную или новую версию программного -обеспечения) -- Software Retirement – вывод из эксплуатации (прекращение эксплуатации -программного обеспечения) - -В представленных в SWEBOK источниках можно найти описание истории эволюции -соответствующих процессных моделей упоминаемых стандартов ISO/IEC и IEEE. Кроме -того, существует и общая (обобщенная) модель процессов сопровождения. -Agile-методологии, активно развивающиеся в последние годы, предлагают -“облегченные” (light или lightweight) процессы, в том числе, и для организации -деятельности по сопровождению, например, Extreme maintenance (см. -соответствующие источники, указанные в SWEBOK). - -### Работы по сопровождению (Maintenance Activities) - -Как уже отмечалось, многие работы по сопровождению похожи на аспекты -деятельности по разработке. В обоих случаях необходимо проводить анализ, -проектирование, кодирование, тестирование и документирование. Специалисты по -сопровождению должны отслеживать требования так же, как и инженеры-разработчики -и обновлять документацию по мере разработки и/или выпуска обновленных или новых -релизов продукта. Стандарт ISO/IEC 14764 рекомендует, чтобы персонал или -организации, отвечающие за сопровождение, в случае использования элементов -процессов разработки в своей деятельности, адаптировали эти процессы <целиком> -в соответствии со своими потребностями. В то же время, деятельность по -сопровождению обладает и определенными уникальными чертами, что приводит к -необходимости использования специализированных процессов. - -#### Уникальные работы (Unique activities) - -Существует ряд процессов, работ и практик, уникальных для деятельности по -сопровождению. SWEBOK приводит следующие примеры такого рода уникальных -характеристик: - -- Передача (Transition): контролируемая и координируемая деятельность по -передаче программного обеспечения от разработчиков группе, службе или -организации, отвечающей за дальнейшую поддержку; -- Принятие/отклонение запросов на модификацию (Modification Request -Acceptance/Rejection): запросы на изменения могут как приниматься и -передаваться в работу, так и отклоняться по различным обоснованным причинам – -объему и/или сложности требуемых изменений, а также необходимых для этого -усилий. Cоответствующие решения могут также приниматься на основе -приоритетности, оценке обоснованности, отсутствии ресурсов (в том числе, -отсутствия возможности привлечения разработчиков к решению задач по -модификации, при реальном наличии такой потребности), утвержденной -запланированности к реализации в следующем релизе и т.п. -- Средства извещения персонала сопровождения и отслеживания статуса запросов на -модификацию и отчетов об ошибках (Modification Request and Problem Report Help -Desk): функция поддержки конечных пользователей, инициирующая работы по оценке -(assessment, подразумевая в том числе оценку необходимости), анализу -приоритетности и стоимости модификаций, связанных с поступившим запросом или -сообщенной проблемой. -- Анализ влияния (Impact Analysis): анализ возможных последствий изменений, -вносимых в существующую систему - рассматривался выше в теме 2.1.3. -- Поддержка программного обеспечения (Software Support): работы по -консультированию пользователей, проводимые в ответ на их информационные запросы -(request for information), например, касающиеся соответствующих бизнес-правил -(см. область знаний “Требования к программному обеспечению”), проверки, -содержания данных и специфических (ad hoc) вопросов пользователей и их -сообщений о проблемах (ошибках, сбоях, непредусмотренному поведению, -непониманию аспектов работы с системой и т.п.). -- Контракты и обязательства: к ним относятся классическое соглашение об уровне -предоставляемого сервиса - Service Level Agreement (SLA), а также другие -договорные аспекты, на основании которых, группа/служба/организация по -сопровождению выполняет соответствующие работы. - -На практике сложно провести грань между разделяемыми в SWEBOK функциями Help -Desk и Software Support – эти функции, обычно, совмещены с процессной точки -зрения. - -#### Дополнительные работы, поддерживающие процесс сопровождения (Support activities) - -Столь длинный перевод названия данной темы связан с содержанием соответствующих -работ, описываемых SWEBOK, как работы персонала сопровождения, не включающие -явного взаимодействия с пользователями, но необходимые для осуществления -соответствующей деятельности. К таким работам относятся: планирование -сопровождения. Конфигурационное управление (software configuration management), -проверка и аттестация (V&V – verification and validation), оценка качества -программного обеспечения (software quality assessment), различные аспекты -обзора, анализа и оценки (reviews), аудит (audit) и обучение (training) -пользователей. - -Также, к таким специальным (внутренним) работам относится обучение персонала -сопровождения. - -В силу особой значимости (с точки зрения автора - обязательности) ряда -упомянутых работ, им посвящены следующие под-темы данной секции области знаний -по сопровождению программного обеспечения. - -#### Работы по планированию сопровождения (Maintenance planning activity) - -Планирование является более чем необходимым для адекватного проведения работ по -сопровождению и должно касаться связанных с этим вопросов с нескольких точек -зрения: - -- Бизнес-планирование (организационный уровень) -- Планирование непосредственных работ по сопровождению (уровень передачи -программного обеспечения – см. выше 3.2.1) -- Планирование релизов/версий (уровень программного обеспечения) -- Планирование обработки конкретных запросов на изменение (уровень запроса) - -На уровне индивидуального запроса, работы по планированию проводятся вместе с -проведением анализа влияния (см. 2.1.3). В свою очередь, планирование -релизов/версий требует от персонала сопровождения выполнения задач: - -- Получения и сбора информации о датах размещения индивидуальных запросов и -отчетов -- Достижения соглашения с пользователями о содержании (функциональности, -поведении и т.п.) последующих релизов/версий программного обеспечения -- Идентификации потенциальных конфликтов и возможных альтернатив <реализации -необходимых запросов> -- Оценки рисков для <функционирования> текущего релиза и разработки плана -“отката” на немодифицированный (текущий, до внесения изменений, касающихся -рассматриваемого запроса) вариант системы, в случае возникновения проблем, -связанных с модификацией -- Информирования всех заинтересованных лиц - -Несмотря на то, что разработка программных системы, обычно, занимает от -несколько месяцев (что более типично) до нескольких лет, сопровождение (как -деятельность по поддержке использования) и активная эксплуатация систем -занимает несколько лет, а то и более[^11] (5-10-...). Проведение оценки -ресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для -сопровождения должны быть оценены и заложены в бюджет еще при разработке -системы. Планирование работ по сопровождению должно начинаться одновременно с -принятием решения о создании системы и согласоваться с целями обеспечения -качества (отмечается в IEEE 1061-98 Standard for a Software Quality Metrics -Methodology). - -[^11]: Эта оценка согласуется и с опытом Сергея Орлика, когда в начале 90-х он -принимал непосредственное участие в проектировании и разработке системы -автоматизации добровольного медицинского страхования (в одной из крупнейших -российских страховых компаний), выведенной, в дальнейшем, из эксплуатации на -рубеже 2000 года, то есть система функционировала около 7 лет, а некоторые ее -фрагменты как самостоятельные приложения и того дольше. Многие банковские -приложения, особенно, на западе, в первых своих версиях были разработаны еще в -середине 80-х, а некоторые ИТ-системы в мире были созданы (в своем изначальном -варианте) и в 70-е годы, что, в частности, привело к усиленному вниманию к -проблеме 2000 года (Y2K problem). - -Вначале необходимо определить концепцию сопровождения. Такой документ, -например, по стандарту ISO/IEC 14764 (Standard for Software Engineering - -Software Maintenance) должен касаться следующих вопросов: - -- Содержания деятельности по сопровождению -- Адаптации процесса сопровождения -- Идентификации организации, которая будет заниматься сопровождением -- Оценки стоимости сопровождения - -После разработки концепции деятельности по сопровождению должен быть -сформирован соответствующий план сопровождения. Этот план должен -подготавливаться одновременно с разработкой программной системы. План должен -определять как пользователи будут размещать свои запросы на модификацию -(изменения) или сообщать об ошибках, сбоях и проблемах. Вопросам планирования -уделяют специальное внимание уже упоминавшиеся стандарты IEEE 1219 (Standard -for Software Maintenance) и ISO/IEC 14764 (Standard for Software Engineering - -Software Maintenance). Стандарт ISO/IEC 14764 предоставляет специальные -рекомендации (guidelines) по организации плана сопровождения. - -Наконец, на уровне бизнес-вопросов, структура, отвечающая за сопровождение, -должна проводить общую деятельность по бизнес-планированию, касающееся -бюджетирования, финансового менеджмента и управления человеческими ресурсами, -так же, как и любое другое (в том числе, профильное, если речь идет о -потребителях ИТ) подразделение организации/компании. Необходимые знание в -области управления также затрагиваются в области знаний SWEBOK “Связанные -дисциплины”. - -#### Конфигурационное управление (Software configuration management) - -Стандарт IEEE 1219, посвященный организации сопровождения программного -обеспечения, определяет конфигурационное управление как критически важный -элемент процесса сопровождения. Процедуры конфигурационного управления должны -обеспечивать проверку, аттестацию и аудит на всех шагах, требуемых для -идентификации, авторизации, реализации и выпуска программного продукта. - -Более того, недостаточно просто отслеживать запросы на изменения и сообщения о -проблемах (modification requests, problem reports). Должны быть контролируемы и -сам программный продукт, и любые изменения (не только в коде, но документации, -спецификациях и т.п., то есть любых активах продукта и проекта, прим. автора). -Такой контроль устанавливается реализацией и строгим следованием утвержденным -процессам конфигурационного управления (software configuration management, -SCM). Область знаний “Конфигурационное управление” подробно описывает и -обсуждает процессы, в соответствии с которыми, размещаются, оцениваются и -утверждаются запросы на изменения. В ряде отдельных аспектов и характеристик, -конфигурационное управление при сопровождении и разработке несколько -отличается, что должно контролироваться уже на операционном уровне. Реализация -SCM-процесса обеспечивается разработкой и следованием плану конфигурационного -управления и соответствующим процедурам (operating procedures). Организация, -подразделение или группа сопровождения (в лице представителей) участвует в -работе часто формируемого органа Configuration Control Board, отвечающего за -рассмотрение и принятие в работу запросов на изменения. Основной целью такого -участия является, по мнению SWEBOK, определение содержания следующих -релизов/версий. - -#### Качество программного обеспечения (Software quality) - -Недостаточно, всего лишь, надеяться, что в процессе и результате сопровождения, -качество программного обеспечения будет повышаться. Для поддержки процесса -сопровождения должны планироваться и реализовываться соответствующие процедуры -и процессы, направленные на повышение качества. Работы и техники по обеспечению -качества (Software Quality Assurance, SQA), проверке и аттестации (V&V, -verification and validation), обзору, анализу и оценке (review), а также -аудиту, должны отбираться в контексте взаимодействия и согласования со всеми -другими процессами, направленными на достижение желаемого уровня качества. -SWEBOK, основываясь на стандарте ISO/IEC 14764 (Standard for Software -Engineering - Software Maintenance), рекомендует адаптировать соответствующие -процессы, техники и активы, относящиеся к разработке программного обеспечения. -К ним, например, относятся документация по тестированию и результаты тестов. -Дополнительные подробности можно найти в соответствующей области знаний -“Качество программного обеспечения” (Software Quality). - -## Техники сопровождения (Techniques for Maintenance) - -Данная секция вводит некоторые общепринятые техники, используемые в процессе -сопровождения программных систем. - -### Понимание программных систем (Program Comprehension) - -Для реализации изменений программисты тратят значительную часть времени на -чтение и формирование понимания программного продукта. Средства работы с кодом -являются ключевым инструментом для решения этой задачи. Четкая, однозначная и -лаконичная документация обеспечивает адекватное понимание программных систем. - -### Реинжиниринг* (Reengineering) - -Реинжиниринг определяется как детальная оценка (examination) и перестройка -программного обеспечения для формирования понимания, воссоздания (на уровне -модели и, в ряде случаев, требований) и дальнейшей реализации его <функций> в -новой форме (например, с использованием новых технологий и платформ, при -сохранении существующей и расширением и облегчением возможностей добавлений -новой функциональности). Отмечается, что в индустрии существуют различные -позиции в отношении реинжиниринга – одни считают, что реинжиниринг является -наиболее радикальной и затратной формой изменений программных систем, другие, -что такой подход может применяться и для не столь кардинальных изменений -(например, как смена платформы или архитектуры). Реинжиниринг, обычно, -провидится не столько для улучшения возможностей сопровождения -(maintainability), сколько для замены устаревшего программного обеспечения. В -принципе, реинжиниринг можно рассматривать как самостоятельный проект, -включающий в себя, как отмечает SWEBOK, формирование концепции, применение -соответствующих инструментов и техник, анализ и приложения опыта проведения -реинжиниринга, а также оценку рисков и преимуществ, связанных с такими -работами. - -Необходимо отметить, что реализация продукта в новом качестве (форме) при -сохранении основной функциональности оригинального продукта, является -неотъемлемой и определяющей частью реинжиниринга, в отличие от обратного -инжиниринга, рассматриваемого ниже и являющегося важной составной частью -реинжиниринга. - -### Обратный инжиниринг* (Reverse engineering) - -“Обратный” инжиниринг (часто путаемый с реинжинирингом, в том числе, в -понимании SWEBOK) или это процесс анализа программного обеспечения с целью -идентификации программных компонент и связей между ними, а также формирования -представления о программном обеспечении, с дальнейшей перестройкой в новой -форме (уже, в процессе реинжиниринга). Обратный инжиниринг является пассивным, -предполагая отсутствие деятельности по изменению или созданию нового -программного обеспечения. Обычно, в результате усилий по обратному инжинирингу -создаются модели вызовов (call graphs) и потоков управления (control flow -graphs) на основе исходного кода системы. Один из типов обратного инжиниринга – -создание новой документации на существующую систему (redocumentation). Другой -из распространенных типов – восстановление дизайна системы (design recovery). - -К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также -относятся работы по рефакторингу (см. работы Мартина Фаулера, впервые -систематизировавшего и описавшего рефакторинг). Рефакторинг – трансформация -программного обеспечения, в процессе которой программная система реорганизуется -(не переписываясь) с целью улучшения структуры, без изменения поведения. -Сохранение “формы” (платформы, архитектурных и технологических решений) -существующей программной системы позволяет рассматривать рефакторинг как один -из вариантов обратного инжиниринга. - -* для обеих тем – 4.2 и 4.3 возможно применение слова реконструкция, в -зависимости от контекста, означающее как полную перестройку или воссоздание -чего-либо, идентичного по определенным характеристикам оригинальному образцу, -так и восстановление какой-либо сущности по сохранившимся и/или доступным -внешним признакам, где восстановление может подразумевать опять-таки создание -нового образца или представления об оригинальной сущности. - -В принципе, возможно объединение тем данной секции, включая реинжиниринг и -обратный инжиниринг, в общую тему 4.1 “Reverse and Re-engineering” данной -области знаний “Сопровождение”, с дальнейшей детализаций в виде “под-тем” -4.1.x. Такой подход соответствует структуре SWEBOK. При этом, соответствующая -структура может быть организована, например, следующим образом: - -- Формирование представления об эксплуатируемой/сопровождаемой системе: -включает восстановление, в первую очередь, бизнес- и функциональных требований -к системе; -- Восстановление детального дизайна системы: включает идентификацию всех -компонентов системы и создание модели вызовов и других связей между -компонентами; -- Рефакторинг: как возможный процесс структурных изменений, вносимых в -систему, в частности для улучшения возможностей по ее дальнейшему сопровождению -(включая модификацию, связанную с расширением функциональности); -- Переработка системы: создание нового релиза/версии системы в той же -форме (например, с использованием той же технологической платформы), что и -текущая (эксплуатируемая) версия; -- Создание новой системы: рассматривает текущую версию и систему в целом, -как устаревшую – legacy. blob - /dev/null blob + 02a3e97adb5e3a31bf6e4bde9441b03079c8f3c8 (mode 644) --- /dev/null +++ 5_software_maintenance.md @@ -0,0 +1,1106 @@ +# Сопровождение программного обеспечения + +Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - +SWEBOK. + +Содержит перевод описания области знаний SWEBOK “Software Maintenance”, с +замечаниями и комментариями. + +Сопровождение программного обеспечения (Software Maintenance) + +Результат усилий по разработке программного обеспечения состоит в передачи в +эксплуатацию программного продукта, удовлетворяющего требованиям пользователей. +Соответственно, в процессе эксплуатации продукт будет изменяться или +эволюционировать. Связано это с обнаружением при реальном использовании скрытых +дефектов, изменениями в операционном окружении, необходимостью покрытия новых +требований и т.п. + +Фаза сопровождения в жизненном цикле, обычно, начинается сразу после +приемки/передачи продукта и действует в течение периода гарантии или, чаще, +технической поддержки. Однако, сама деятельность, связанная с сопровождением, +начинается намного раньше. + +Сопровождение программного обеспечения является составной частью жизненного +цикла. К сожалению, так сложилось, что вопросам сопровождения уделяется +существенно меньше внимания, чем другим фазам жизненного цикла. Исторически, в +большинстве организаций, разработка программных систем явно в фаворе, по +сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно +начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний +ITIL[^7] – IT Infrastructure Library, уделяющей особое внимание +вопросам поддержки и сопровождения инфраструктуры информационных технологий). В +большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций +организаций непосредственно в разработку программных систем, с целью увеличения +сроков использования уже существующего и применяемого ПО. Конечно, с точки +зрения автора, это не единственная причина. Скорее вопросы постоянно +изменяющихся бизнес-потребностей, динамика бизнеса и желание повысить отдачу от +уже эксплуатируемых систем приводит к усилению роли поддержки и сопровождения +программного обеспечения и естественной интеграции такой деятельности в +бизнес-процессы подразделений информационных технологий. + +[^7]: ITIL, в частности, определяет три аспекта управления жизненным циклом +приложений – определение требований, проектирование и разработку, и, наконец, +сопровождение. Все это, в контексте программного обеспечения, относится к +деятельности по управлению приложениями – Application Management в ITIL ICT +Infrastructure Management (ICT - Information and Communications Technology). + +Если проблема 2000 года, в свое время, оказала особое влияние на изменение +отношения к сопровождению на Западе, то расширение применения продуктов Open +Source во всем мире и связанная с ним волна надежд на получение дешевого +решения существующих задач привела к тому, что вопросы сопровождения вышли для +многих организаций на первый план. Ситуация во многих ИТ-подразделениях +показывает, что такие надежды оправдались только частично. Использование +продуктов Open Source не стало дешевой альтернативой и, в ряде случаев, привело +даже к бо́льшим проектным затратам именно в силу недостаточно проработанной +политики эксплуатации и сопровождения построенных на их основе прикладных +решений. Это ни в коем случае не значит, что волна Open Source “захлебнулась”. +Это означает только, что игнорирование оценки стоимости сопровождения привело к +превышению бюджетов, недостатку ресурсов и, в конце концов, частому провалу +инициатив по использованию таких продуктов в корпоративной среде. Неготовность +рассматривать жизненный цикл во времени как продолжающийся и после передачи +системы в эксплуатацию, непроработанность соответствующих процедур +корректировки продукта после его выпуска – основная беда и в бизнес-среде, для +которой программное обеспечение лишь инструмент, и в компаниях-интеграторах, +“забывающих” о необходимости развития успеха после внедрения системы у +заказчика, и у независимых поставщиков программных продуктов, которые, выпуская +новую версию лучшего в своем классе продукта, начинают работать над новой +версией, уделяя недостаточное внимание поддержке и обновлению уже существующих +версий. + +Сопровождение программного обеспечения в SWEBOK определяется как вся +совокупность деятельности, необходимой для обеспечения эффективной (с точки +зрения затрат) поддержки программных систем. Эти работы выполняются как перед +вводом системы в эксплуатацию, так и после этого. Предварительные работы +включают планирование деятельности по сопровождению системы, а также +организацию перехода к ее полнофункциональному использованию. Если новая +система должна заменить старую систему, предназначенную для решения тех же +задач, просто на новом уровне эффективности, стоимости использования, новых +функциональных возможностей, в этом случае важно обеспечить плавный переход со +старой системы на новую, максимально естественный для пользователей. С этим +связано не только планирование, например, переноса информации, хранимой в +соответствующих базах данных, но и обучение пользователей, подготовка, +настройка и проверка “боевой” конфигурации, определение последовательности +операций, организация и обучение службы поддержки (help-desk) и т.п. + +Область знаний “Сопровождение программного обеспечения” связана с другими +аспектами программной инженерии. По-сути, описание этой области знаний +непосредственно пересекается со всеми другими дисциплинами. + +![Рисунок 6. Область знаний “Сопровождение программного обеспечения” [SWEBOK, 2004, с.6-2, рис. 1]](images/maintenance_area_small.jpg) + +## Основы сопровождения программного обеспечения (Software Maintenance Fundamentals) + +Эта секция включает концепции и терминологию, формирующие основы понимания роли +и содержания работ по сопровождению программных систем. Темы данной секции +предоставляют соответствующие определения и описывают, почему именно существует +потребность в сопровождении. Категории сопровождения критически важны для +понимания сути обсуждаемых вопросов. + +### Определения и терминология (Definitions and Terminology) + +Сопровождение программного обеспечения определяется стандартом IEEE Standard +for Software Maintenance (IEEE 1219) как модификация программного продукта +после передачи в эксплуатацию для устранения сбоев, улучшения показателей +производительности и/или других характеристик (атрибутов) продукта, или +адаптации продукта для использования в модифицированном окружении. Интересно, +что данный стандарт также касается вопросов подготовки к сопровождению до +передачи системы в эксплуатацию, однако, структурно это сделано на уровне +соответствующего информационного приложения, включенного в стандарт. + +В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) +позиционирует сопровождение как один из главных процессов жизненного цикла. +Этот стандарт описывает сопровождение как процесс модификации программного +продукта в части его кода и документации для решения возникающих проблем <при +эксплуатации> или реализации потребностей в улучшениях <тех или иных +характеристик продукта>. Задача состоит в модификации продукта при условии +сохранения его целостности. Международный стандарт ISO/IEC 14764 (Standard for +Software Engineering - Software Maintenance) определяет сопровождение +программного обеспечения в тех же терминах, что и стандарт 12207, придавая +особое значение работам по подготовке к деятельности по сопровождению до +передачи системы в реальную эксплуатацию, например, вопросам планирования +регламентов и операций по сопровождению. + +### Природа сопровождения (Nature of Maintenance) + +Сопровождение поддерживает функционирование программного продукта на протяжении +всего операционного жизненного цикла, то есть периода его эксплуатации. В +процессе сопровождения фиксируются и отслеживаются запросы на модификацию +(также называемые “запросами на изменения” – change requests, в частности, в +контексте конфигурационного управления), оценивается влияние предлагаемых +изменений, модифицируется код и другие активы (артефакты) продукта, проводится +необходимое тестирование и, наконец, выпускается обновленная версия продукта. +Кроме того, проводится обучение пользователей и обеспечивается их ежедневная +поддержка при работе с текущей версией продукта. В SWEBOK отмечается, что +сопровождение, с точки зрения операций отслеживания и контроля, обладает +большим содержанием, чем разработка (в общем понимании). Объем и активность +операций по контролю разработки в большой степени зависит от сложившихся +практик, внутрикорпоративных регламентов и требований, а также применяемых +методологий и концепции управления (в частности – проектного менеджмента). Так +или иначе, отслеживание и контроль – ключевые элементы деятельности по +сопровождению программного обеспечения (как и других ИТ-активов предприятия). +Стандарт 12207 определяет понятие “maintainer” - в соответствующем ГОСТ он +именуется как “персонал сопровождения”, подразумевая организацию, выполняющая +работы по сопровождению. SWEBOK использует данный термин, также, и в отношении +лиц (individuals), проводящих определенные работы по сопровождению, в отличие, +например, от разработчиков, занимающихся реализацией системы в программном +коде. + +Стандарт жизненного цикла 12207 также идентифицирует основные работы по +сопровождению: реализация процесса <сопровождения>, анализ проблем и +модификаций (изменений), реализаций модификаций, обзор (оценка)/принятие +<решений> по сопровождению, миграция (с одной версии программного продукта на +другую, с одного продукта на другой) и вывод системы из эксплуатации. Эти +работы описываются далее в теме 3.2 “Работы по сопровождению” (Maintenance +Activities). + +Специалисты по сопровождению (персонал сопровождения) могут получать знания о +программном продукте непосредственно от разработчиков. Взаимодействие с +разработчиками и раннее привлечение этих специалистов помогает уменьшить +усилия, необходимые для адекватного сопровождения программной системы. По +мнению автора, передача знаний персоналу сопровождения, его обучение, должно +начинаться не позднее начала опытной эксплуатации продукта. В противном случае, +усилия на одновременную поддержку прикладной системы и обучение соответствующих +специалистов не только превысит реально допустимые нормы загрузки персонала +(как группы или службы сопровождения и техподдержки, так и разработчиков +системы), но снизит эффективность поддержки пользователей на критически важном +этапе первоначального использования новой системы. По опыту автора и +результатам обсуждения этого вопроса с сотрудниками внутрикорпоративных +ИТ-департаментов, обычно, в зависимости от сложности системы, пик нагрузки на +службу сопровождения приходится в течении первых 2 - 6 недель, с момента +передачи системы в реальную эксплуатацию, тем более, при отказе от +использования старой системы или ее предыдущей версии. SWEBOK отмечает, что, в +некоторых случаях, инженеры (создававшие систему) не могут быть привлечены к +обучению и поддержке персонала сопровождения. Особенно часто это касается +тиражируемых или “коробочных” систем. Это создает дополнительные трудности для +специалистов, обеспечивающих сопровождение. В то же время, инженеры, +занимающиеся технической поддержкой (несколько боле узкий круг в команде +сопровождения, включающей менеджеров, администраторов и других специалистов), +должны (в зависимости от типа продукта) иметь доступ к активам проекта +(например, описанию его внутренней архитектуры), включая код, документацию и +т.п. Именно таким образом начинает формироваться информационная инфраструктура +службы технической поддержки и сопровождения у производителей программных +продуктов. + +Практика показывает, что инженеры по технической поддержке производителя +программного обеспечения (не только “коробочного”, но и создаваемого и +настраиваемого интеграторами, обладающими собственными программными решениями) +должны не просто иметь доступ ко всем ключевым активам проекта (код, +документация, спецификации требований, внутренние модели и т.п.), но в их +обязанности входит создание “патчей” (patch – “заплата”), исправлений ошибок и, +в особых случаях, такие изменения, до выпуска новой версии продукта, создаются +с привлечением непосредственно разработчиков продукта (групп и подразделений +R&D – Research and Development). При этом, разработчики продукта информируются +о найденных ошибках и, в случае нахождения соответствующих решений +специалистами технической поддержки, такие решения передаются разработчикам с +тем, чтобы те либо включили такие изменения в новую версию программного +продукта (безусловно, в случае успешного прохождения всех необходимых тестов), +либо нашли более адекватное решение в контексте новой функциональности либо тех +изменений, которые включены в новую версию продукта. В обязанности инженеров +службы сопровождения, в общем случае, входит: проверка пользовательского +сценария, приводящего к сбою; идентификация причин сбоя, т.е локализация +ошибки/причин ее появления; предоставление соответствующих исправлений или, при +невозможности создания таковых на данном этапе либо в заданные сроки – +предоставление обходного пути решения проблемы для достижения требуемых +бизнес-задач (такие обходные пути, обычно, называют “workaround”); +журналирование всех работ и операций; помещение описания проблемы и ее решения +в базу знаний службы сопровождения; передача всей информации разработчикам; +своевременное информирование пользователя о статусе запроса и некоторые другие +работы, содержание которых может варьироваться, в зависимости от регламентов и +корпоративных стандартов в конкретной организации, либо параметров контракта на +сопровождение и техническую поддержку, если таковой есть. + +### Потребность в сопровождении (Need for Maintenance) + +Сопровождение необходимо для обеспечения того, чтобы программный продукт на +протяжении всего периода эксплуатации удовлетворяет требованиям пользователей. +Деятельность по сопровождению применима для программного обеспечения, +созданного с использованием любой модели жизненного цикла (например, +спиральной) и методологии разработки. На первый взгляд, это утверждение SWEBOK +может показаться тривиальным. Однако, обратитесь к своему опыту разработки и +использования различного программного обеспечения. Наверняка, Вы найдете случаи +из собственной практики или практики коллег, когда столь очевидное утверждение +хорошо бы донести до разработчика того или иного программного продукта. +Изменения программной системы могут быть обусловлены как действиями по +корректировке ее поведения или несвязанные с необходимостью корректировки +(подразумевая уже не исправление ошибок, а, например, повышение +производительности или расширение функциональности). + +В общем случае, работы по сопровождению должны проводиться для решения +следующих задач: + +- устранение сбоев +- улучшение дизайна +- реализация расширений <функциональных возможностей> +- создание интерфейсов взаимодействия с другими (внешними) системами +- адаптация (например, портирование) для возможности работы на другой +аппаратной платформе (или обновленной платформе), применения новых системных +возможностей, функционирования в среде обновленной телекоммуникационной +инфраструктуры и т.п. +- миграции унаследованного (legacy) программного обеспечения +- вывода программного обеспечения из эксплуатации + +Деятельность персонала сопровождения включает четыре ключевых аспекта: + +- поддержка контроля (управляемости) программного обеспечения в течение всего +цикла эксплуатации +- поддержка модификаций программных систем +- совершенствование существующих функций (судя по всему, SWEBOK в данном случае +подразумевает функции не программного обеспечения, а процессов сопровождения и +функции персонала сопровождения, как таковые) +- предотвращение падения производительности программной системы до +неприемлемого уровня + +Говоря о предотвращении деградации производительности, мы должны понимать, что +это, при всем желании совершенствования системы, может делаться и за счет +обновления мощности аппаратной части и/или соответствующей телекоммуникационной +инфраструктуры, если это более обосновано, чем модификация самой программной +системы. На самом деле это вопрос того, что окажется дешевле (и менее +рискованно), т.е. связано с затратами/ стоимостью соответствующих работ, +оборудования и поддержки обновленного системного окружения (что, к сожалению, +часто также не учитывается даже при более-менее сложившейся практике +сопровождения). + +### Приоритет стоимости сопровождения (Majority of Maintenance Costs) + +Работы по сопровождению потребляют если не большую (как отмечает SWEBOK), то +значительную часть финансовых ресурсов жизненного цикла программного +обеспечения. Общее понимание сопровождения подразумевает лишь устранение сбоев. +Однако, исследования и опросы на протяжении многих лет показывают, что более +80% усилий по сопровождению связаны не столько устранением сбоев, сколько с +другими работами, не связанными с исправлением дефектов. Многие менеджеры по +сопровождению объединяют в отчетности вопросы расширения функциональности и +исправления ошибок в поддерживаемых программных системах. Такое смешение +качественно различных работ приводит к неправильному представлению о реальной, +на самом деле, не столь высокой стоимости сопровождения в части устранения +дефектов. Понимание различных категорий работ в рамках деятельности по +сопровождению помогает понять структуру реальных затрат. Кроме того, понимание +факторов, влияющих на возможности сопровождения системы, помогают не только +сохранять необходимый уровень затрат, но и снижать их. + +Существуют как технические, так и другие (например, организационные, +являющиеся, по мнению автора, наиболее сильно влияющими на объем затрат) +факторы, оказывающие влияние на стоимость сопровождения, в целом: + +- тип приложения +- новизна программного обеспечения +- наличие и квалификация персонала по сопровождению +- длительность использования программной системы +- характеристики и специфика аппаратной части (а также телекоммуникационной +инфраструктуры) +- качество дизайна (например, модульность или масштабируемость), кода, +документации и соответствующих работ по тестированию системы + +### Эволюция программного обеспечения (Evolution of Software) + +В 1969 году Леман (см. рекомендуемую литературу к данной секции SWEBOK) впервые +связал деятельность по сопровождению и вопросы эволюции программного +обеспечения. Результаты более чем 20-ти летних исследований во главе с Леманом +привели к формулированию ряда важных положений, ключевое из которых утверждает, +что деятельность по сопровождению, по-сути, представляет собой эволюционную +разработку программных систем. Принятию тех или иных решений в процессе +сопровождения, помогает понимание того, что происходит с программной системой в +процессе ее эксплуатации. Существующее (особенно, корпоративное) программное +обеспечение никогда не бывает полностью завершенным и продолжает +эволюционировать в течение всего срока эксплуатации. В процессе +эволюционирования, программная система становится все более сложной до тех пор, +пока не предпринимаются специальные усилия (в том числе, в рамках специального +проекта по модификации) по уменьшению его сложности. + +В то же самое время, если можно выделить тенденции развития программной системы +и ее поведение достаточно стабильно, его эволюционирование можно измерить. +Последние годы делаются попытки разработать соответствующие модели оценки +усилий по сопровождению. В результате уже создаются определенные средства +(численные и инструментальные) управления работами по сопровождению, ряд из +которых приводится в ссылках к данной секции SWEBOK. + +### Категории сопровождения (Categories of Maintenance) + +Многие источники, в частности, стандарт IEEE 1216, определяют три категории +работ по сопровождению: корректировка, адаптация и совершенствование. Такая +классификация была обновлена в стандарте ISO/IEC 14764 Standard for Software +Engineering - Software Maintenance введением четвертой составляющей. Таким +образом, сегодня говорят о четырех категориях сопровождения: + +- Корректирующее сопровождение (corrective maintenance): “реактивная” +модификация программного продукта, выполняемая уже после передачи в +эксплуатацию для устранения сбоев; +- Адаптирующее сопровождение (adaptive maintenance): модификация программного +продукта на этапе эксплуатации для обеспечения продолжения его использования с +заданной эффективностью (с точки зрения удовлетворения потребностей +пользователей) в изменившемся или находящемся в процессе изменения окружении; в +первую очередь, подразумевается изменение бизнес-окружения, порождающее новые +требования к системе; +- Совершенствующее сопровождение (perfective maintenance): модификация +программного продукта на этапе эксплуатации для повышения характеристик +производительности и удобства сопровождения; +- Профилактическое сопровождение (preventive maintenance): модификация +программного продукта на этапе эксплуатации для идентификации и предотвращения +скрытых дефектов до того, когда они приведут к реальным сбоям. + +ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) +классифицирует адаптивное и совершенствующее сопровождение как работы по +расширению <функциональности> продукта. Этот стандарт также объединяет +корректирующую и профилактическую деятельность в общую категорию работ по +корректировке системы. Профилактическое сопровождение (новейшая категория работ +по сопровождению) наиболее часто проводится для программных систем, связанных с +вопросами безопасности <людей>. + +![Таблица 1. Категории сопровождения программного обеспечения.](images/maintenance_categories.jpg) + +## Ключевые вопросы сопровождения программного обеспечения (Key Issues in Software Maintenance) + +Для обеспечения эффективного сопровождения программных систем необходимо решать +целый комплекс вопросов и проблем, связанных с соответствующими работами. +Необходимо понимать, что процесс сопровождения предъявляет уникальные +технические и управленческие требования к персоналу, занимающемуся +сопровождениям и, в первую очередь, специалистам-инженерам. Попытка найти +дефект в продукте, содержащем 500 тысяч строк кода, написанных другими +инженерами – яркий пример сложностей, с которыми приходится сталкиваться +инженерам по сопровождению. Другой пример, уже организационный, постоянная +борьба за ресурсы с разработчиками (это чаще всего проявляется в вопросах +отвлечения разработчиков от текущей работы для помощи в решении проблем +сопровождения, а также в конкуренции за приоритеты финансирование разработки +новой системы или сопровождения существующей). Одновременное планирование +перспективной версии системы, реализация следующей версии и подготовка +критических патчей для текущей версии – еще один классический пример проблем, с +которыми приходится сталкиваться в процессе эксплуатации программного +обеспечения. + +Данная секция представляет некоторые технические и управленческие вопросы, +связанные с сопровождением программных систем. Эти вопросы и проблемы +сгруппированы в набор тем: + +- Технические вопросы +- Управленческие вопросы +- Оценка стоимости +- Измерения + +### Технические вопросы (Technical Issues) + +#### Ограниченное понимание (Limited understanding) + +Ограниченное понимание подразумевает как быстро инженер по сопровождению может +понять где необходимо внести исправления или изменения в код системы, которую +он не разрабатывал. Исследования показывают, что от 40 до 60 процентов усилий +по сопровождению тратится на анализ и понимание сопровождаемого программного +обеспечения. Формирование целостного взгляда о системе представляет большое +значение для инженеров. Этот процесс более сложен в случае анализа текстового +представления системы – ее исходного кода, особенно, когда процесс эволюции +системы от сборки к сборки, от релиза к релизу, в нем никак не отмечен, не +документирован и когда разработчики не могут объяснить историю и структуру +изменений, что, к сожалению, случается достаточно часто. +Для объектно-ориентированных программ качественно упрощает задачу понимания +кода использование UML-инструментария, способного на основе кода восстановить +не только модель классов, но и их взаимодействия в форме диаграмм классов +(class diagram), коммуникаций или сотрудничества (collaboration в UML1.x, +переименованная в communication в UML 2.0) и, особенно, последовательностей +(sequence diagram), демонстрирующая структуру взаимных вызовов во времени. Если +соответствующий инструментарий предоставляет одновременную визуализацию кода и +диаграммы и обеспечивает взаимную синхронизацию их с точки зрения навигации +(выбор метода в любой из представленных диаграмм автоматически позиционирует +соответствующим образом редактор кода и, наоборот) – такие средства +автоматизации могут качественно сократить время, необходимое для формирования +представления о системе, иногда – даже не в разы, а на порядок (конечно, при +достаточном уровне знания используемых технологий со стороны инженера по +сопровождению). Если к этому добавить документированность (и доступность +соответствующих активов – спецификаций, моделей) архитектуры и ключевых +технологических решений со стороны разработчиков системы – обсуждаемый вопрос, +конечно, не становится тривиальным, однако, превращается во вполне решаемую +задачу. Вообще говоря, использование соответствующих средств автоматизации +построения моделей по коду (задача обратного инжиниринга – reverse engineering) +является обоснованной практикой изучения любой системы или фреймворка. Опыт +показывает, что при достаточной квалификации инженера, формирование общего +архитектурного представления о системе (или фреймворке), понимания того, какие +технологические и структурные подходы и шаблоны использовались при ее +построении, позволяет решать возникающие вопросы корректировки кода и +расширения функциональности системы, не нарушая общие принципы ее построения, +естественным образом обеспечивая ее эволюцию, без ущерба ее целостности. При +таком понимании, даже не заглядывая в код системы или фреймворка, инженер +способен с очень большой вероятностью предположить возможные причины сбоя, а, в +общем случае, и любых аспектов поведения системы. Тема обратного инжиниринга +освещается SWEBOK как самостоятельная техника сопровождения (4.3), однако, +здесь показалось важным особо акцентировать на ней внимание именно в этой части +обсуждения вопросов сопровождения. + +#### Тестирование (Testing) + +Стоимость повторения полного набора тестов для основных модулей системы может +быть существенным как по времени, так и по стоимости. Для сопровождения системы +особо значимым является выборочное регрессионное тестирование (см. область +знаний Software Testing, тему 2.2.6 Регрессионное тестирование) системы или его +компонент для проверки того, что внесенные изменения привели к +непреднамеренному изменению поведения программного обеспечения. Вопрос состоит +в том, что часто сложно найти время для необходимого тестирования. Не меньшей +проблемой является и координации в проведении тестов различными членами группы +сопровождения, занимающимеся решением различных задач. Если же система +выполняет критичные <для бизнеса> функции, временный вывод системы из +эксплуатации (как говорят, перевод системы в offline) для выполнения тестов +часто оказывается просто невозможен. + +Таким образом, одним из ключевых вопросов сопровождения является организация +работ по тестированию модификаций эксплуатируемых систем, вплоть до +предварительного планирования и разработки регламентов, в соответствии с +которыми, например, основываясь на оценке критичности запросов на изменения +(как дефектов, так и важных расширений – будь то новая функциональность или +необходимое расширение интеграционных возможностей), затрагиваемых модулях, +персоналом сопровождения будут проводиться стандартные процедуры. К таким +процедурам, наравне с журналированием запросов и проводимых работ, могут и, +скорее, должны относиться: анализ влияния <изменений> (impact analysis – см. +ниже), оценка рисков, тестирование (различными методами, в различном объеме), +выпуск предварительных версий патчей/обновлений в ограниченное использование +(если это позволяет спецификация системы), использование “клона” системы +(развертывание ее на идентичном оборудовании в идентичной конфигурации) и т.п. + +#### Анализ влияния (Impact analysis) + +Анализ влияния описывает как проводить (в частности, с точки зрения +эффективности затрат) полный анализ возможных последствий и влияний изменений, +вносимых в существующую систему. Персонал сопровождения должен обладать +необходимыми знаниями о специфике системы (в идеальном случае, иметь полное +представление о системе на уровне ее разработчиков) – ее содержании и +структуре. Инженеры используют эти знания для выполнения работ по анализу +влияния, идентифицируя все системы[^8] и программные продукты, на +которые могут повлиять изменения, вносимые в обслуживаемую программную систему. +При этом, должны быть определены риски, связанные с внесением обсуждаемых +изменений. + +[^8]: Как мы видим из описания данных работ в SWEBOK, речь идет не только о +компонентах системы, но и о ее окружении, включая другие системы, +функционирующие в том же операционном/системном окружении. + +Запросы на изменения[^9] (change requests - CR), иногда упоминаемые как +запросы на модификацию (modification request - MR), часто также называемые +отчетами о проблемах (problem report - PR), должны анализироваться и +трансформироваться в термины программной системы. Эти шаги выполняются после +того, как соответствующий запрос на изменение начинает обрабатываться в рамках +процесса управления изменениями или, как принято называть, конфигурационного +управления, и фиксируется в системе конфигурационного управления (см. область +знаний Configuration Management). + +[^9]: Обычно запросы на изменения разделяют на две категории – “пожелания” +(suggestions), относящиеся к расширению системы, и “отчеты об ошибках” (defect +или bug report), направляемые пользователями в службу сопровождения или +инженерами по тестированию разработчикам. + +Цели анализа влияния могут быть сформулированы следующим образом: + +- Определение содержания изменений для задания работ по планированию и +реализации +- Получение максимально возможной оценки ресурсов, необходимых для проведения +соответствующих работ +- Анализ стоимости и выгоды от внесения запрошенных изменений (обычно касается +пожеланий, запросов на расширение системы) +- Обсуждение сложности вопросов, связанных с внесением соответствующих +изменений + +Сложность решения вопроса, поставленного соответствующим запросом на изменения, +часто является основным фактором определения того, когда и как будет решена +проблема. Инженеры идентифицирую компоненты, в которые необходимо внести +изменения. Обычно рассматривается несколько вариантов решения проблемы и +вырабатывается (также, обязательно, фиксируются в соответствующей системе +обработки запросов на изменения) наиболее оптимальный путь ее решения. + +При этом, оптимальность пути не всегда означает наиболее ”красивое” +технологическое решение. Иногда это может быть временное решение, может быть +даже нарушающее архитектурные шаблоны системы, однако, обоснованное с точки +зрения сроков и стоимости его реализации. В то же самое время, результаты +анализа направляются разработчикам системы, обычно работающими над следующей +версией, для включения соответствующего изменения уже в рамках принятого стиля +кодирования, соглашений, архитектурных шаблонов и т.п. Безусловно, такой путь +многим может показаться просто неэтичным, с точки зрения “настоящего” +инженерного подхода. Однако, если разработчики готовят следующую версию +системы, затрагивая модуль, модифицируемый службой сопровождения, с точки +зрения бизнес-решений, “некрасивый”, но быстрый путь достижения требуемого +поведения системы, в большинстве случаев, будет выглядеть более обоснованным, +чем принятие на себя персоналом сопровождения функций разработчиков системы. +Иногда, если требуемое изменение не столь критично, чтобы решение было +предоставлено “вчера” (хотя пользователи, практически всегда, именно так +характеризуют свои запросы в терминах приоритета), логичным выглядит +откладывание проведения соответствующих модификаций и передача этих работ +непосредственно разработчикам. Как это часто можно услышать – “будет доступно в +следующем релизе”. Ничего не напоминает? Но, экономически, это часто бывает +более чем оправдано. + +Если программное обеспечение изначально разрабатывалось с учетом дальнейшей +поддержки, это может существенно облегчить анализ влияний, как одной из +ключевых работ по сопровождению. + +#### Возможность сопровождения (Maintainability) + +Возможность сопровождения или сопровождаемость программной системы +определяется, например, глоссарием IEEE (стандарт 610.12-90 Standard Glossary +for Software Engineering Terminology, обновление 2002 года) как легкость +сопровождения, расширения, адаптации и корректировки для удовлетворения +заданных требований. Стандарт ISO/IEC 9126-01 (Software Engineering – Product +Quality – Part 1: Quality Model, 2001 г.) определяет возможность сопровождения +как одну из характеристик качества. + +Для уменьшения стоимости дальнейшего сопровождения, на протяжении всего +процесса разработки необходимо специфицировать, оценивать и контролировать +характеристики, влияющие на возможность сопровождения. Если такие работы +проводятся регулярно, это облегчает дальнейшее сопровождение, повышая его +сопровождаемость (в частности, как характеристику качества). Часто этого +сложно добиться, потому, что, к сожалению, такого рода характеристики +игнорируются при разработки. Разработчики заняты другими запланированными +работами и также часто пренебрегают требованиями, предъявляемыми к +сопровождаемости системы. + +Одной из ключевых проблем сопровождения является отсутствие системной +документации, мешающее формированию понимания системы и, как следствие, +невозможности адекватного анализа влияния. Эта и другие проблемы могут быть +решены при использовании систематического подхода к построению зрелых +процессов, применению соответствующих техник и автоматизации необходимых задач +по поддержке жизненного цикла с помощью специализированных инструментальных +средств. + +### Управленческие вопросы (Management Issues) + +#### Согласование с организационными целями (Alignment with organizational objectivies) + +Организационные цели описывают как продемонстрировать возврат инвестиций от +деятельности по сопровождению программного обеспечения. Обычно, разработка +ведется на проектной основе, с определенными временными и бюджетными +ограничениями. Главный акцент, при этом, делается на выпуске системы, +отвечающей потребностям пользователей, в заданные сроки и в рамках бюджета. В +отличие от этого, сопровождение системы преследует цели максимального продления +срока эксплуатации программного обеспечения. Такой подход может основываться на +необходимости обновления и расширения программного обеспечения, как отклика на +изменяющиеся потребности пользователей. При этом, оценка возврата инвестиций +становится более сложной и приводит к формированию точки зрения старшего +менеджмента, что деятельность по сопровождению потребляет значительную часть +ресурсов без явно выраженной и количественно определяемой отдачи для +организации. + +#### Проблемы кадрового обеспечения[^10] (Staffing) + +Данная тема касается вопросов привлечения и удержания квалифицированного +персонала по сопровождению. Часто, работа по сопровождению не выглядит +привлекательной, инженеры по поддержке воспринимаются как специалисты “второго +класса” (в SWEBOK используется устойчивое выражение “second-class citizens”), +что приводит к безусловному падению духа коллектива, отвечающего за поддержку +систем. + +Это серьезный вызов для менеджеров, отвечающих за вопросы сопровождения и, +вообще говоря, является классической задачей общего менеджмента. Решение этой +задачи, в первую очередь, находится в руках старшего менеджмента, формирующего +соответствующий стиль отношений между функциональными и вспомогательными +подразделениями. На более высоком уровне, для организаций и бизнесов - +потребителей информационных технологий, эта задача связана с +внутрикорпоративными департаментами автоматизации, в целом, которые слишком +часто воспринимаются только как центры затрат, а информационные технологии не +рассматриваются как актив. В результате, такая позиция приводит к снижению +эффективности работы подразделений автоматизации, а, следовательно, и падению +качества информационного обеспечения бизнеса, что сказывается, в подавляющем +большинстве случаев, и на бизнесе, как таковом. + +[^10]: Такой перевод, вместо просто “кадрового обеспечения”, в большей степени +соответствует принятому использованию термина staffing. Часто, staffing +подразумевает и высокую текучесть кадров. + +#### Процесс (Process) + +Процесс (в общем случае, жизненный цикл, прим. автора) является набором работ +(activities), методов, практик и, своего рода, трансформаций, которые +используются людьми для разработки и сопровождения программных систем и +ассоциированных с ними продуктов. На уровне процесса, деятельность по +сопровождению программного обеспечения имеет очень много общего с разработкой, +например, в части конфигурационного управления, являющегося критически важной +составляющей обоих видов деятельности. В то же время, сопровождение включает +работы, не представленные в процессе разработки (в теме 3.2 представлено +описание такого рода уникальных работ). Эта деятельность требует от менеджмента +специального внимания. + +#### Организационные аспекты сопровождения (Organizational aspects of maintenance) + +В первую очередь, организационные вопросы подразумевают какая организация будет +отвечать и/или какие функции необходимо выполнять для обеспечения деятельности +по сопровождению. Команда, разрабатывавшая программный продукт, далеко не +всегда отвечает за его сопровождение. Это не только стандартное управленческое +решение независимых поставщиков программного обеспечения, но, также, часто +встречается в организациях, использующих программные продукты в целях +автоматизации своих бизнес-функций. + +При решении вопроса, где (кем) будут осуществляться функции по сопровождению, +может быть принято решение оставить их непосредственно тем, кто разрабатывал +систему (как в терминах организации/компании, так и подразумевая +непосредственно коллектив разработчиков), или передать другой команде или +стороне (maintainer). Часто, выбор сопровождающей организации осуществляется +исходя из тех соображений, которые выглядят обоснованными для обеспечения +адекватной поддержки системы и возможности ее эволюционирования для +удовлетворения меняющихся потребностей пользователей. К сожалению (чего, в +принципе, и следовало ожидать), универсальных подходов в решении данного +вопроса, кем будет сопровождаться система – нет. Соответствующие решения +принимаются в каждом конкретном случае, с учетом его специфики (case-by-case). +Но, что действительно важно отметить, делегирование или назначение полномочий и +ответственности по сопровождению должно быть произведено по отношению только к +одной организации или лицу (менеджеру соответствующей команды поддержки). Все, +так или иначе, зависит от организационной структуры организации/компании, +эксплуатирующей программное обеспечение. + +#### Аутсоурсинг (Outsourcing) + +Заимствованный термин “аутсоурсинг” уже прижился не только в среде +ИТ-менеджеров, он стал частью современного бизнеса и управленческих практик. +Суть его заключается в передаче работ, в первую очередь, вспомогательных +(непрофильных для организации) “на сторону”. Крупные корпорации передают в +управление другим организациям целые портфели программных систем, а, иногда, и +целиком всю ИТ-инфраструктуру. В то же время, существенно более часто, +сопровождение передается другим организациям только для “второстепенных” +программных систем (или, как минимум, не критичных для выполнения +бизнес-функций), так как владельцы таких систем не желают терять контроль над +ассоциированными с этими системами данными и/или функциональностью. Отмечается, +что некоторые передают работы по сопровождению “в аутсоурсинг” только в тех +случаях, если убеждены в стратегическом контроле над сопровождением. + +Часто можно наблюдать, когда для решения вопросов сопровождения (при сохранении +“стратегического контроля”), компании, для которых информационные технологии не +являются профильными, но воспринимаются в качестве актива, формируют +специализированные дочерние бизнес-структуры, которым и передаются функции +сопровождения, а также и непосредственно разработки программных систем и, более +того, поддержки и развития всей ИТ-инфраструктуры. Это делается с тем, чтобы +функционируя в качестве самостоятельной бизнес-сущности, уже бывшие +внутрикорпоративные подразделения автоматизации, могли обеспечить большую +прозрачность финансовых потоков, затрат, связанных с информационным +технологиями. Но, это тема уже относится к общим вопросам управления и, +безусловно, требует самостоятельного обсуждения, в контексте, опять-таки, +конкретной организации или бизнес-структуры. Однако, нельзя было не обозначить +важность обсуждаемого вопроса в данном контексте, ведь именно деятельность по +сопровождению часто подвигает организации-потребители ИТ к принятию столь +серьезных организационных и бизнес-решений. + +При этом, подчеркивает SWEBOK, контроль сложно измерить. В свою очередь, перед +аутсоурсером (организацией, принимающей на себя ответственность по +сопровождению) стоит серьезная проблема по определению содержания +соответствующих работ, в том числе, для описания содержания соответствующего +контракта. Отмечается, что около 50% сервисов, предоставляемых аутсоурсером, +проводятся без соответствующего детального и однозначно интерпретируемого +соглашения (service level agreement, SLA). Компании, занимающиеся +аутсоурсингом, обычно затрачивают несколько месяцев на оценку программного +обеспечения прежде, чем заключают соответствующий контракт. Еще один вопрос, +требующий специального внимания, заключается в необходимости определения +процесса и процедур передачи программного обеспечения на внешнее сопровождение. + +### Оценка стоимости сопровождения (Maintenance Cost Estimation) + +Как уже отмечалось, инженеры должны понимать разницу в различных категориях +сопровождения. Это, в большой степени, необходимо для оценки соответствующих +затрат. С точки зрения планирования, как составной части проектной и +управленческой деятельности, оценка стоимости является важным аспектом +деятельности по сопровождению программного обеспечения. + +#### Оценка стоимости (Cost Estimation) + +При обсуждении анализа влияния (см. 2.1.3 Impact Analysis) говорилось о том, +что такой анализ помогает в оценке стоимости работ по сопровождению. На эти +затраты оказывает влияние множество технических и других факторов. ISO/IEC +14764 (Standard for Software Engineering - Software Maintenance)определяет, что +“существует два наиболее популярных метода оценки стоимости сопровождения – +параметрическая модель и использование опыта”. Чаще всего, оба этих подхода +комбинируются для повышения точности оценки. + +#### Параметрические модели (Parametric models) + +SWEBOK приводит ряд источников, подробно рассматривающих вопросы оценки +стоимости сопровождения и, в частности, параметрические модели. Для +использования таких моделей используются данные предыдущих проектов. Наравне с +историческими данными используется метод функциональных точек (см. стандарт +IEEE 14143.1-00). + +#### Опыт (Experience) + +Среди тех подходов, которые позволяют повысить точность оценок, полученных при +использовании параметрических моделей – применение опыта (в форме экспертного +мнения, например, при использовании техники оценки “Delphi”, название которой +происходит от “делфийского оракула”), аналогий, а также структуры декомпозиции +работ. Наилучшие результаты получаются в случае сочетания эмпирических методов +с имеющимся опытом. Получаемые данные используются как результат программы +измерения аспектов сопровождения. + +### Измерения в сопровождении программного обеспечения (Software Maintenance Measurement) + +Формы и данные измерений в процессе сопровождения могут объединяться в единую +программу корпоративную программу количественных оценок, проводимых в отношении +программного обеспечения. Многие организации используют популярный и практичный +подход для измерений, базирующийся на оценке количества проблем и статуса их +решений (issue-driven measurement). Идеи этого подхода систематизированы в +проекте Practical Software and Systems Measurement (PSM). Существуют общие (для +всего жизненного цикла) метрики и, соответственно, их категории, в частности, +определяемые Институтом Программной Инженерии университета Карнеги-Меллон +(Software Engineering Institute, Carnegie-Mellon University – SEI CMU): размер, +усилия, расписание и качество. Применение этих метрик является хорошей +отправной точкой для оценки работ со стороны организации, отвечающей за +сопровождение. + +Более детальное обсуждение вопросов измерений в отношении продуктов и процессов +представлено в области знаний “Процесс программной инженерии (Software +Engineering Process). В свою очередь, вопросы организации программы измерений +относятся к области знаний “Управление программной инженерией” (Software +Engineering Management). + +#### Специализированные метрики (Specific Measures) + +Существуют различные методы внутренней оценки продуктивности (benchmarking) +персонала сопровождения для сравнения работы различных групп сопровождения. +Организация, ведущая сопровождение, должна определить метрики, по которым будут +оцениваться соответствующие работы. Стандарты IEEE 1219 (Standard for Software +Maintenance) и ISO/IEC 9126-01 (Software Engineering – Product Quality – Part +1: Quality Model, 2001 г.) предлагают специализированные метрики, +ориентированные именно на вопросы сопровождения и соответствующие программы. + +Ниже представлены типичные метрики оценки работ по сопровождению, +соответствующих распространенной классификации эксплуатационных характеристик +программного обеспечения: + +- Анализируемость (Analyzability): оценка (в первую очередь, дополнительных) +усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, +а также для идентификации тех фрагментов программной системы, которые должны +быть модифицированы. +- Изменяемость (Changeability): оценка усилий, необходимых для проведения +заданных модификаций. +- Стабильность (Stability): оценка случаев непредусмотренного поведения +системы, включая ситуации, обнаруженные в процессе тестирования. +- Тестируемость (Testability): оценка усилий персонала сопровождения и +пользователей по тестированию модифицированного программного обеспечения. + +## Процесс сопровождения (Maintenance Process) + +Вопросы организации процесса сопровождения напрямую связаны с соответствующими +стандартами и de facto практиками реализации такого процесса. Тема “Работы по +сопровождению” (Maintenance Activities) различает вопросы сопровождения и +разработки и показывает взаимосвязь c другими аспектами деятельности +программной инженерии. + +Типичные и распространенные потребности в процессах программной инженерии +подробно описаны и документированы в различных источниках. Одна из наиболее +детально проработанных и распространенных (на уровне стандарта de facto) +процессных моделей, изначально созданных с ориентацией на программное +обеспечение – CMMI (Capability Maturity Model Integration – интегрированная +модель зрелости), разработанная в Институте программной инженерии университета +Карнеги-Меллон (SEI CMU). CMMI, в частности, уделяет специальное внимание +процессам сопровождения. Существуют и другие, менее распространенные, но тем не +менее развивающиеся модели. + +### Процессы сопровождения (Maintenance Processes) + +Процессы сопровождения описывают необходимые работы и детальные входы/выходы +этих работ. Эти процессы рассматриваются в стандартах IEEE 1219 (Standard for +Software Maintenance) и ISO/IEC 14764 (Standard for Software Engineering - +Software Maintenance). + +Процесс сопровождения начинается по стандарту IEEE 1219 с момента передачи +программной системы в эксплуатацию (post-delivery stage) и касается таких +вопросов, как планирование деятельности по сопровождению (см. рисунок 2). + +![Рисунок 2. Работы в процессе сопровождения по стандарту IEEE 1219.](images/maintenance_2-activities.jpg) + +Стандарт ISO/IEC 14764 уточняет положения, связанные с процессом сопровождения, +стандарта жизненного цикла 12207. Работы по сопровождению, описанные в этом +стандарте аналогичны работам в IEEE 1219, за исключением того, что +сгруппированы несколько иначе (см. рисунок 3). + +![Рисунок 3. Процесс сопровождения по стандарту ISO/IEC 14764.](images/maintenance_3-process.jpg) + +Работы по сопровождению в стандарте 14764 разбиты на задачи: + +- Process Implementation – реализация процесса +- Problem and Modification Analysis – анализ проблем и <необходимых> +модификаций +- Modification Implementation –проведение модификаций (реализация изменений) +- Maintenance Review/Acceptance – оценка и принятие <проведенных работ> при +сопровождении +- Migration – миграция (на модифицированную или новую версию программного +обеспечения) +- Software Retirement – вывод из эксплуатации (прекращение эксплуатации +программного обеспечения) + +В представленных в SWEBOK источниках можно найти описание истории эволюции +соответствующих процессных моделей упоминаемых стандартов ISO/IEC и IEEE. Кроме +того, существует и общая (обобщенная) модель процессов сопровождения. +Agile-методологии, активно развивающиеся в последние годы, предлагают +“облегченные” (light или lightweight) процессы, в том числе, и для организации +деятельности по сопровождению, например, Extreme maintenance (см. +соответствующие источники, указанные в SWEBOK). + +### Работы по сопровождению (Maintenance Activities) + +Как уже отмечалось, многие работы по сопровождению похожи на аспекты +деятельности по разработке. В обоих случаях необходимо проводить анализ, +проектирование, кодирование, тестирование и документирование. Специалисты по +сопровождению должны отслеживать требования так же, как и инженеры-разработчики +и обновлять документацию по мере разработки и/или выпуска обновленных или новых +релизов продукта. Стандарт ISO/IEC 14764 рекомендует, чтобы персонал или +организации, отвечающие за сопровождение, в случае использования элементов +процессов разработки в своей деятельности, адаптировали эти процессы <целиком> +в соответствии со своими потребностями. В то же время, деятельность по +сопровождению обладает и определенными уникальными чертами, что приводит к +необходимости использования специализированных процессов. + +#### Уникальные работы (Unique activities) + +Существует ряд процессов, работ и практик, уникальных для деятельности по +сопровождению. SWEBOK приводит следующие примеры такого рода уникальных +характеристик: + +- Передача (Transition): контролируемая и координируемая деятельность по +передаче программного обеспечения от разработчиков группе, службе или +организации, отвечающей за дальнейшую поддержку; +- Принятие/отклонение запросов на модификацию (Modification Request +Acceptance/Rejection): запросы на изменения могут как приниматься и +передаваться в работу, так и отклоняться по различным обоснованным причинам – +объему и/или сложности требуемых изменений, а также необходимых для этого +усилий. Cоответствующие решения могут также приниматься на основе +приоритетности, оценке обоснованности, отсутствии ресурсов (в том числе, +отсутствия возможности привлечения разработчиков к решению задач по +модификации, при реальном наличии такой потребности), утвержденной +запланированности к реализации в следующем релизе и т.п. +- Средства извещения персонала сопровождения и отслеживания статуса запросов на +модификацию и отчетов об ошибках (Modification Request and Problem Report Help +Desk): функция поддержки конечных пользователей, инициирующая работы по оценке +(assessment, подразумевая в том числе оценку необходимости), анализу +приоритетности и стоимости модификаций, связанных с поступившим запросом или +сообщенной проблемой. +- Анализ влияния (Impact Analysis): анализ возможных последствий изменений, +вносимых в существующую систему - рассматривался выше в теме 2.1.3. +- Поддержка программного обеспечения (Software Support): работы по +консультированию пользователей, проводимые в ответ на их информационные запросы +(request for information), например, касающиеся соответствующих бизнес-правил +(см. область знаний “Требования к программному обеспечению”), проверки, +содержания данных и специфических (ad hoc) вопросов пользователей и их +сообщений о проблемах (ошибках, сбоях, непредусмотренному поведению, +непониманию аспектов работы с системой и т.п.). +- Контракты и обязательства: к ним относятся классическое соглашение об уровне +предоставляемого сервиса - Service Level Agreement (SLA), а также другие +договорные аспекты, на основании которых, группа/служба/организация по +сопровождению выполняет соответствующие работы. + +На практике сложно провести грань между разделяемыми в SWEBOK функциями Help +Desk и Software Support – эти функции, обычно, совмещены с процессной точки +зрения. + +#### Дополнительные работы, поддерживающие процесс сопровождения (Support activities) + +Столь длинный перевод названия данной темы связан с содержанием соответствующих +работ, описываемых SWEBOK, как работы персонала сопровождения, не включающие +явного взаимодействия с пользователями, но необходимые для осуществления +соответствующей деятельности. К таким работам относятся: планирование +сопровождения. Конфигурационное управление (software configuration management), +проверка и аттестация (V&V – verification and validation), оценка качества +программного обеспечения (software quality assessment), различные аспекты +обзора, анализа и оценки (reviews), аудит (audit) и обучение (training) +пользователей. + +Также, к таким специальным (внутренним) работам относится обучение персонала +сопровождения. + +В силу особой значимости (с точки зрения автора - обязательности) ряда +упомянутых работ, им посвящены следующие под-темы данной секции области знаний +по сопровождению программного обеспечения. + +#### Работы по планированию сопровождения (Maintenance planning activity) + +Планирование является более чем необходимым для адекватного проведения работ по +сопровождению и должно касаться связанных с этим вопросов с нескольких точек +зрения: + +- Бизнес-планирование (организационный уровень) +- Планирование непосредственных работ по сопровождению (уровень передачи +программного обеспечения – см. выше 3.2.1) +- Планирование релизов/версий (уровень программного обеспечения) +- Планирование обработки конкретных запросов на изменение (уровень запроса) + +На уровне индивидуального запроса, работы по планированию проводятся вместе с +проведением анализа влияния (см. 2.1.3). В свою очередь, планирование +релизов/версий требует от персонала сопровождения выполнения задач: + +- Получения и сбора информации о датах размещения индивидуальных запросов и +отчетов +- Достижения соглашения с пользователями о содержании (функциональности, +поведении и т.п.) последующих релизов/версий программного обеспечения +- Идентификации потенциальных конфликтов и возможных альтернатив <реализации +необходимых запросов> +- Оценки рисков для <функционирования> текущего релиза и разработки плана +“отката” на немодифицированный (текущий, до внесения изменений, касающихся +рассматриваемого запроса) вариант системы, в случае возникновения проблем, +связанных с модификацией +- Информирования всех заинтересованных лиц + +Несмотря на то, что разработка программных системы, обычно, занимает от +несколько месяцев (что более типично) до нескольких лет, сопровождение (как +деятельность по поддержке использования) и активная эксплуатация систем +занимает несколько лет, а то и более[^11] (5-10-...). Проведение оценки +ресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для +сопровождения должны быть оценены и заложены в бюджет еще при разработке +системы. Планирование работ по сопровождению должно начинаться одновременно с +принятием решения о создании системы и согласоваться с целями обеспечения +качества (отмечается в IEEE 1061-98 Standard for a Software Quality Metrics +Methodology). + +[^11]: Эта оценка согласуется и с опытом Сергея Орлика, когда в начале 90-х он +принимал непосредственное участие в проектировании и разработке системы +автоматизации добровольного медицинского страхования (в одной из крупнейших +российских страховых компаний), выведенной, в дальнейшем, из эксплуатации на +рубеже 2000 года, то есть система функционировала около 7 лет, а некоторые ее +фрагменты как самостоятельные приложения и того дольше. Многие банковские +приложения, особенно, на западе, в первых своих версиях были разработаны еще в +середине 80-х, а некоторые ИТ-системы в мире были созданы (в своем изначальном +варианте) и в 70-е годы, что, в частности, привело к усиленному вниманию к +проблеме 2000 года (Y2K problem). + +Вначале необходимо определить концепцию сопровождения. Такой документ, +например, по стандарту ISO/IEC 14764 (Standard for Software Engineering - +Software Maintenance) должен касаться следующих вопросов: + +- Содержания деятельности по сопровождению +- Адаптации процесса сопровождения +- Идентификации организации, которая будет заниматься сопровождением +- Оценки стоимости сопровождения + +После разработки концепции деятельности по сопровождению должен быть +сформирован соответствующий план сопровождения. Этот план должен +подготавливаться одновременно с разработкой программной системы. План должен +определять как пользователи будут размещать свои запросы на модификацию +(изменения) или сообщать об ошибках, сбоях и проблемах. Вопросам планирования +уделяют специальное внимание уже упоминавшиеся стандарты IEEE 1219 (Standard +for Software Maintenance) и ISO/IEC 14764 (Standard for Software Engineering - +Software Maintenance). Стандарт ISO/IEC 14764 предоставляет специальные +рекомендации (guidelines) по организации плана сопровождения. + +Наконец, на уровне бизнес-вопросов, структура, отвечающая за сопровождение, +должна проводить общую деятельность по бизнес-планированию, касающееся +бюджетирования, финансового менеджмента и управления человеческими ресурсами, +так же, как и любое другое (в том числе, профильное, если речь идет о +потребителях ИТ) подразделение организации/компании. Необходимые знание в +области управления также затрагиваются в области знаний SWEBOK “Связанные +дисциплины”. + +#### Конфигурационное управление (Software configuration management) + +Стандарт IEEE 1219, посвященный организации сопровождения программного +обеспечения, определяет конфигурационное управление как критически важный +элемент процесса сопровождения. Процедуры конфигурационного управления должны +обеспечивать проверку, аттестацию и аудит на всех шагах, требуемых для +идентификации, авторизации, реализации и выпуска программного продукта. + +Более того, недостаточно просто отслеживать запросы на изменения и сообщения о +проблемах (modification requests, problem reports). Должны быть контролируемы и +сам программный продукт, и любые изменения (не только в коде, но документации, +спецификациях и т.п., то есть любых активах продукта и проекта, прим. автора). +Такой контроль устанавливается реализацией и строгим следованием утвержденным +процессам конфигурационного управления (software configuration management, +SCM). Область знаний “Конфигурационное управление” подробно описывает и +обсуждает процессы, в соответствии с которыми, размещаются, оцениваются и +утверждаются запросы на изменения. В ряде отдельных аспектов и характеристик, +конфигурационное управление при сопровождении и разработке несколько +отличается, что должно контролироваться уже на операционном уровне. Реализация +SCM-процесса обеспечивается разработкой и следованием плану конфигурационного +управления и соответствующим процедурам (operating procedures). Организация, +подразделение или группа сопровождения (в лице представителей) участвует в +работе часто формируемого органа Configuration Control Board, отвечающего за +рассмотрение и принятие в работу запросов на изменения. Основной целью такого +участия является, по мнению SWEBOK, определение содержания следующих +релизов/версий. + +#### Качество программного обеспечения (Software quality) + +Недостаточно, всего лишь, надеяться, что в процессе и результате сопровождения, +качество программного обеспечения будет повышаться. Для поддержки процесса +сопровождения должны планироваться и реализовываться соответствующие процедуры +и процессы, направленные на повышение качества. Работы и техники по обеспечению +качества (Software Quality Assurance, SQA), проверке и аттестации (V&V, +verification and validation), обзору, анализу и оценке (review), а также +аудиту, должны отбираться в контексте взаимодействия и согласования со всеми +другими процессами, направленными на достижение желаемого уровня качества. +SWEBOK, основываясь на стандарте ISO/IEC 14764 (Standard for Software +Engineering - Software Maintenance), рекомендует адаптировать соответствующие +процессы, техники и активы, относящиеся к разработке программного обеспечения. +К ним, например, относятся документация по тестированию и результаты тестов. +Дополнительные подробности можно найти в соответствующей области знаний +“Качество программного обеспечения” (Software Quality). + +## Техники сопровождения (Techniques for Maintenance) + +Данная секция вводит некоторые общепринятые техники, используемые в процессе +сопровождения программных систем. + +### Понимание программных систем (Program Comprehension) + +Для реализации изменений программисты тратят значительную часть времени на +чтение и формирование понимания программного продукта. Средства работы с кодом +являются ключевым инструментом для решения этой задачи. Четкая, однозначная и +лаконичная документация обеспечивает адекватное понимание программных систем. + +### Реинжиниринг* (Reengineering) + +Реинжиниринг определяется как детальная оценка (examination) и перестройка +программного обеспечения для формирования понимания, воссоздания (на уровне +модели и, в ряде случаев, требований) и дальнейшей реализации его <функций> в +новой форме (например, с использованием новых технологий и платформ, при +сохранении существующей и расширением и облегчением возможностей добавлений +новой функциональности). Отмечается, что в индустрии существуют различные +позиции в отношении реинжиниринга – одни считают, что реинжиниринг является +наиболее радикальной и затратной формой изменений программных систем, другие, +что такой подход может применяться и для не столь кардинальных изменений +(например, как смена платформы или архитектуры). Реинжиниринг, обычно, +провидится не столько для улучшения возможностей сопровождения +(maintainability), сколько для замены устаревшего программного обеспечения. В +принципе, реинжиниринг можно рассматривать как самостоятельный проект, +включающий в себя, как отмечает SWEBOK, формирование концепции, применение +соответствующих инструментов и техник, анализ и приложения опыта проведения +реинжиниринга, а также оценку рисков и преимуществ, связанных с такими +работами. + +Необходимо отметить, что реализация продукта в новом качестве (форме) при +сохранении основной функциональности оригинального продукта, является +неотъемлемой и определяющей частью реинжиниринга, в отличие от обратного +инжиниринга, рассматриваемого ниже и являющегося важной составной частью +реинжиниринга. + +### Обратный инжиниринг* (Reverse engineering) + +“Обратный” инжиниринг (часто путаемый с реинжинирингом, в том числе, в +понимании SWEBOK) или это процесс анализа программного обеспечения с целью +идентификации программных компонент и связей между ними, а также формирования +представления о программном обеспечении, с дальнейшей перестройкой в новой +форме (уже, в процессе реинжиниринга). Обратный инжиниринг является пассивным, +предполагая отсутствие деятельности по изменению или созданию нового +программного обеспечения. Обычно, в результате усилий по обратному инжинирингу +создаются модели вызовов (call graphs) и потоков управления (control flow +graphs) на основе исходного кода системы. Один из типов обратного инжиниринга – +создание новой документации на существующую систему (redocumentation). Другой +из распространенных типов – восстановление дизайна системы (design recovery). + +К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также +относятся работы по рефакторингу (см. работы Мартина Фаулера, впервые +систематизировавшего и описавшего рефакторинг). Рефакторинг – трансформация +программного обеспечения, в процессе которой программная система реорганизуется +(не переписываясь) с целью улучшения структуры, без изменения поведения. +Сохранение “формы” (платформы, архитектурных и технологических решений) +существующей программной системы позволяет рассматривать рефакторинг как один +из вариантов обратного инжиниринга. + +* для обеих тем – 4.2 и 4.3 возможно применение слова реконструкция, в +зависимости от контекста, означающее как полную перестройку или воссоздание +чего-либо, идентичного по определенным характеристикам оригинальному образцу, +так и восстановление какой-либо сущности по сохранившимся и/или доступным +внешним признакам, где восстановление может подразумевать опять-таки создание +нового образца или представления об оригинальной сущности. + +В принципе, возможно объединение тем данной секции, включая реинжиниринг и +обратный инжиниринг, в общую тему 4.1 “Reverse and Re-engineering” данной +области знаний “Сопровождение”, с дальнейшей детализаций в виде “под-тем” +4.1.x. Такой подход соответствует структуре SWEBOK. При этом, соответствующая +структура может быть организована, например, следующим образом: + +- Формирование представления об эксплуатируемой/сопровождаемой системе: +включает восстановление, в первую очередь, бизнес- и функциональных требований +к системе; +- Восстановление детального дизайна системы: включает идентификацию всех +компонентов системы и создание модели вызовов и других связей между +компонентами; +- Рефакторинг: как возможный процесс структурных изменений, вносимых в +систему, в частности для улучшения возможностей по ее дальнейшему сопровождению +(включая модификацию, связанную с расширением функциональности); +- Переработка системы: создание нового релиза/версии системы в той же +форме (например, с использованием той же технологической платформы), что и +текущая (эксплуатируемая) версия; +- Создание новой системы: рассматривает текущую версию и систему в целом, +как устаревшую – legacy. blob - f78dc25f689f5b1b60e6d3a65fcf0ce4149c4680 (mode 644) blob + /dev/null --- 6_software_configuration_management.markdown +++ /dev/null @@ -1,988 +0,0 @@ -# Конфигурационное управление - -Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - -SWEBOK. - -Содержит перевод описания области знаний SWEBOK “Software Configuration -Management”, с замечаниями и комментариями. - -Система может быть определена как коллекция компонент, организованных для -выполнения заданных функций или реализации комплекса функциональности (IEEE -610.12-90, Standard Glossary for Software Engineering Terminology). -Конфигурация системы – функциональные и/или физические характеристики -аппаратного, программно-аппаратного, программного обеспечения или их -комбинации, сформулированные в технической документации и реализованные в -продукте. Конфигурация также может восприниматься как сочетание конкретных -версий аппаратных, программно-аппаратных или программных элементов, -объединенных вместе, в соответствии с заданными процедурами сборки и отвечающих -определенному назначению. Конфигурационное управление (CM - Configuration -Management), в свою очередь, дисциплина идентификации конфигурации системы в -определенные (заданные) моменты времени, с целью систематического контроля -изменений конфигурации, а также поддержки и сопровождения целостной и -отслеживаемой (трассируемой) конфигурации на протяжении всего жизненного цикла -системы. - -Конфигурационное управление формально определяется глоссарием IEEE 610 как -“дисциплина приложения технических и административных указаний (инструкций) и -контроля (надзора) для: идентификации и документирования функциональных и -физических характеристик элементов конфигураций, контроля (управления) -изменений этих характеристик, записи (сохранения) и ведения отчетности по -обработке изменений и статусу их реализации, а также проверки (верификации) -соответствия заданным требованиям.” - -В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207, конфигурационное -управление в области программного обеспечения (“6.2 Управление конфигурацией” -по ГОСТ) – Software Configuration Management (SCM[^12]) – один из -вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающих -проектный менеджмент, деятельность по разработке и сопровождению, обеспечению -качества, а также, заказчиков и пользователей конечного продукта. - -[^12]: В ряде источников можно увидеть аббревиатуру SCCM – Software Configuration -and Change Management. При том, что в понимании SWEBOK и соответствующих -стандартов, содержание SCM и SCCM тождественно, термин SCCM иногда используется -для того, чтобы подчеркнуть принципиальную значимость управления изменениями -как составной части конфигурационного управления. - -Концепции конфигурационного управления применяются в отношении всех элементов, -которые необходимо контролировать (несмотря на то, что существуют определенные -отличия между конфигурационным управлением в приложении к аппаратному и -программному обеспечению). - -SCM-деятельность тесно связана с работами по обеспечению качества программного -обеспечения (Software Quality Assurance - SQA). В соответствии с определением -области знаний SWEBOK “Качество программного обеспечения” (Software Quality), -SQA-процессы обеспечивают гарантию того, что программные продукты и процессы -жизненного цикла в проекте соответствуют заданным требованиям, за счет -планирования и выполнения работ, направленных на достижение определенного -(приемлемого) уровня качества создаваемого программного продукта. -SCM-деятельность помогает в достижении этих SQA-целей. В контексте некоторых -проектов, определенные работы по конфигурационному управлению задаются -требованиями SQA (например, в IEEE 730-02 “Standard for Software Quality -Assurance Plans”). - -Работы по конфигурационному управлению <программного обеспечения> включают: -управление и планирование SCM-процессов, идентификацию программных -конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также -управление выпуском (release management) и поставкой (delivery). - -На рисунке 1 изображено стилизованное представление этих работ. - -![Рисунок 1. Работы по конфигурационному управлению (SCM Activities) [SWEBOK, 2004, с.7-1, рис. 1]](images/configuration_management_1-activities.jpg) - -Данная область знаний связана со всеми другими областями знаний и дисциплинами -программной инженерии, так как объектами приложения SCM являются все артефакты, -создаваемые и используемые в процессах программной инженерии. - -К сожалению, SCM-деятельность во многих проектных командах сводится лишь к -контролю версий (version control) исходных текстов и, в лучшем случае, -документации (причем не проектной документации, в целом, а документации на -создаваемое программное обеспечение). Попытка ограничить конфигурационное -управление только вопросами контроля версий, в какой-то степени, является -результатом непонимания того, что результаты проекта – это не только исходный -код, исполняемые модули и пользовательская документация, но и все то, что -создавалось (пусть и для решения тактических задач, как это часто бывает с -некоторыми моделями и результатами пилотных работ по созданию прототипов) на -протяжении всего проекта. Активами проекта (результатами, артефактами) являются -и описания бизнес-процессов и бизнес-сущностей, и архитектурные модели, и -требования, и план проекта/проектные задачи (как комплекс параметров, связанных -с распределением ресурсов), и запросы на изменения (включая информацию о -дефектах) и многое другое. Безусловно, упрощение вопросов конфигурационного -управления до уровня управления версиями, с коньюктурной точки зрения, выгодно -многим поставщикам соответствующих инструментальных средств. В определенных -случаях, особенно, для малых проектов или временно используемых/”одноразовых” -систем (например, по односторонней, “one-way” миграции данных из унаследованной -системы в новую), упрощенный взгляд на конфигурационное управление может быть -вполне обоснован. Однако, как это ни прискорбно, часто приходится наблюдать -позиционирование такой, с позволения сказать, “практики”, как некоего “стиля -гибкой работы”, подменяющей реальную динамику и гибкость agile-подходов -(например, XP) отсутствием управления (важно понимать и помнить, что управление -далеко не всегда является директивным), как такового (например, по определению -содержания проекта на основе консенсуса проектной команды и вовлеченных в -проектные работы представителей заказчика). В свою очередь, даже когда все -активы проекта находятся под контролем соответствующих SCM-систем, необходимо -осознавать, что конфигурационное управление предполагает постоянно действующий -процесс, а не просто комплекс определенных периодически выполняемых операций. -Только восприятие SCM-деятельности в качестве инфраструктурной основы процессов -жизненного цикла может обеспечить эффективность управления программными -проектами, то есть – достижение поставленных целей и создание результатов, -удовлетворяющих заданным критериям. В то же время, конфигурационное управление -- необходимое, но не достаточное условие, так как только совокупность процессов -жизненного цикла, включая управление требованиями, проектирование и другие, не -менее важные аспекты, определяют весь комплекс работ по созданию программных -систем. - -![Рисунок 2. Область знаний “Конфигурационное управление” [SWEBOK, 2004, с.7-3, рис. 2]](images/configuration_management_area_small.jpg) - -## Управление SCM-процессом (Management of SCM Process) - -SCM-деятельность контролирует эволюцию и целостность продукта, идентифицируя -его элементы, управляя и контролируя изменения, а также, проверяя, записывая и -обеспечивая отчетность по конфигурационной информации. С инженерной точки -зрения, SCM способствует разработке и реализации изменений. Успешное внедрение -SCM требует точного планирования и управления. Это, в свою очередь, -предполагает понимание организационного контекста и тех ограничений, которые -связаны с проектированием и реализацией процесса конфигурационного управления. - -### Организационный контекст SCM (Organizational Context for SCM) - -Для планирования SCM-процесса необходимо понимать организационный контекст и -связи между организационными элементами. SCM-работы предполагают взаимодействие -с другими аспектами проектной деятельности (не путайте с управлением проектами -– это, при всей своей значимости, лишь один из видов проектной деятельности) и -организационными элементами. - -Организационные элементы, отвечающие за процессы поддержки программной -инженерии, могут быть структурированы несколькими способами. Несмотря на то, -что ответственность за выполнение определенных SCM-задач может быть назначена -(принята или ассоциирована, в зависимости от управленческих принципов и -установок, т.е. общего менеджмента - general management) различным частям -(лицам, группам, подразделениям и т.п.) организации, например, структуре, -отвечающей за разработку программного обеспечения, общая ответственность за -конфигурационное управление часто возлагается на отдельный (специализированный) -организационный элемент или назначенную персону. - -Программное обеспечение часто разрабатывается как составная часть большей -системы, содержащей аппаратные и программно-аппаратные/встраиваемые элементы. В -этом случае, SCM-деятельность ведется параллельно с работами по -конфигурационному управлению (CM) в отношении аппаратной или -программно-аппаратной части, строго согласуясь с общим конфигурационным -управлением на уровне системы, в целом. Ряд источников (см. библиографию -SWEBOK, связанную с данной областью знаний) описывает SCM в сочетании с -контекстом, в рамках которого проводится такая деятельность. - -SCM может играть роль интерфейса к работам, направленным на обеспечение -качества (quality assurance), вытекающим, например, из отслеживания записей <по -изменениям> и несогласующихся элементов (например, выявленным в процессе сборки -очередной версии системы, прим. автора). С точки зрения составителей <данной -области знаний SWEBOK>, некоторые элементы, находящиеся под управлением SCM -<процесса>, могут также служить объектами рассмотрения в рамках организационных -программ по обеспечению качества. Управление несогласующемися элементами обычно -относится к работам по управлению качеством. Однако, SCM может обеспечить -существенную помощь в отслеживании (трассировке) и создании отчетности по -элементам программных конфигураций, попадающих в такую <проблемную> категорию. - -SWEBOK отмечает, что возможно тесное взаимодействие между организационными -структурами, отвечающими за разработку и сопровождение (и SCM играет роль -инфраструктуры, обеспечивающей такую связь). - -В зависимости от контекста, существует множество подходов и практик в части -выполнения задач конфигурационного управления в приложении к программному -обеспечению. Часто, одни и те же инструменты поддерживают и разработку, и -сопровождение, обеспечивая достижение целей и содержания SCM. - -### Ограничения и правила SCM (Constraints and Guidance for the SCM Process) - -Ограничения и правила в отношении процесса конфигурационного управления -порождаются различными источниками. Политики и процедуры, формулируемые на -корпоративном или другом организационном уровне, могут влиять или предписывать -структуру и реализацию SCM-процесса для заданного проекта. Кроме того, контракт -между заказчиком и поставщиком может содержать положения, затрагивающие процесс -конфигурационного управления. Например, может требоваться проведение -определенных процедур проверки (аудита) или специфицирован набор элементов -(активов, артефактов), передаваемых под управление <процедур и системы> -конфигурационного управления (или в части формализации обработки и контроля -реализации запросов на изменения, поступающих от заинтересованных лиц). Когда -разрабатываемый программный продукт потенциально затрагивает аспекты публичной -безопасности, могут налагаться определенные ограничения со стороны -соответствующих регулирующих органов (например, USNRC Regulatory Guide 1.169, -“Configuration Management Plans for Digital Computer Software Used in Safety -Systems of Nuclear Power Plants”, U.S. Nuclear Regulatory Commission, 1997). -Наконец, на структуру и реализацию SCM-процесса в проекта влияют выбранные (с -точки зрения модели и адаптированных характеристик) процессы жизненного цикла и -инструменты, применяемые для реализации программной системы. - -Рекомендации по структуре и реализации SCM-процесса могут быть также -результатом применения лучших практик (best practices), представленных в -стандартах, выпущенных соответствующими стандартизирующими организациями. -Лучшие практики также отражены в моделях совершенствования и оценки процессов, -например, в CMMI – Capability Maturity Model Integration Института программной -инженерии (SEI – Software Engineering Institute) университета Карнеги-Меллон -(Carnegie-Mello University) и ISO/IEC 15504 (SPICE) “Software Engineering – -Process Assessment”. - -### Планирование в SCM (Planning for SCM) - -Планирование процесса конфигурационного управления для заданного проекта должно -согласовываться с организационным контекстом, соответствующими ограничениями, -общепринятыми рекомендациями, а также характеристиками и природой самого -проекта (например, его размером или значимостью). Основные работы, проводимые -при планировании SCM-деятельности включают: - -- Идентификацию программных конфигураций (Software Configuration -Identification) -- Контроль конфигураций (Software Configuration Control) -- Учет статусов конфигураций (Software Configuration Status Accounting) -- Аудит конфигураций (Software Configuration Auditing) -- Управление выпуском и поставкой (Software Release Management and Delivery) - -Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного управления, как организационные вопросы, обязанности, ресурсы и расписание, выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а также, контроль интерфейсов <взаимодействия программных модулей>. Результаты планирования сводятся в план конфигурационного управления (SCM Plan - SCMP), обычно, являющийся объектом оценки и аудита в рамках деятельности по обеспечению качества (SQA – Software Quality Assurance). - -#### Организация и обязанности (SCM organization and responsibilities) - -Для предотвращения путаницы в том, кто будет выполнять заданные работы и задачи конфигурационного управления, должны быть четко идентифицированы организации (организационные структуры), вовлеченные в SCM-процесс. Конкретные обязанности по выполнению заданных работ и задач SCM должны быть назначены соответствующим организационным сущностям. Также, должны быть идентифицированы общие полномочия и пути отчетности, даже если это выполняется в процессе планирования управления проектом или деятельности по обеспечению качества. - -#### Ресурсы и расписание (SCM resources and schedules) - -В процессе планирования конфигурационного управления идентифицируется персонал -и инструменты, привлекаемые для выполнения соответствующих работ и задач SCM. -Планирование касается вопросов определения расписания, устанавливая -последовательность задач конфигурационного управления и идентифицируя их связь -с расписанием проекта и его вехами, определенными на стадии планирования -проекта. Также должны быть специфицированы требования по обучению персонала, -необходимые для реализации планов. - -#### Выбор инструментов и реализация (Tool selection and implementation) - -SCM-деятельность поддерживается различными типами инструментальных средства и -процедур по их использованию. В зависимости от ситуации, эти инструменты могут -включать комбинацию различных возможностей – автоматизированные средства могут -решать отдельные задачи SCM, интегрированные средства могут обслуживать -потребности многих участников процесса программной инженерии (например, SCM, -разработку, проверку и аттестацию и т.п.). Значимость инструментальной -поддержки конфигурационного управления (как и других аспектов деятельности в -области программной инженерии) растет с каждым днем вместе со сложностью -внедрения, ростом размера проектов и сложности проектного окружения. -Возможности инструментальных средств развиваются для обеспечения поддержки: - -- SCM-библиотек (проектно-ориентированных баз знаний, прим. автора) -- Запросов на изменения (software change request - SCR) и процедур утверждения -(approval) -- Управления кодом (и связанных рабочих продуктов) и изменениями -- Отчетности по статусу конфигураций и сбору соответствующих метрических -показателей -- Аудиту конфигураций -- Управлению и отслеживанию <состояния и полноты> программной документации -- Выполнению задач по сборке программных продуктов и их модулей -- Управлению, контролю и поставке выпусков (релизов) программных продуктов - -Инструменты, используемые для обеспечения конфигурационного управления, могут -также предоставлять метрики, необходимые для совершенствования процессов. -SWEBOK обращает внимание (рекомендуя соответствующий первоисточник) на -следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and -Progress) и индикаторы качества – поток изменений (Change Traffic), -стабильность <конфигураций> (Stability), раздробленность (Breakage), -модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility), -среднее время между сбоями (MTBF – Mean Time Between Failures), -зрелость/полнота <информации> (Maturity). Отчетность по этим индикаторам может -быть организована различным образом, например, по элементам конфигураций или по -типу запросов на изменения. - -Рисунок 3 демонстрирует отображение инструментальных возможностей и процедур на -работы по конфигурационному управлению. - -![Рисунок 3. Характеристики SCM-инструментов и связанные процедуры. [SWEBOK, 2004, с.7-4, рис. 3]](images/configuration_management_3-tools_and_processes.jpg) - -В этом примере система управления кодом поддерживает программные библиотеки -контролируя доступ к элементам библиотек, координирует действия множества -пользователей и помогает в проведении рабочих процедур. Другие инструменты -поддерживают процесс сборки и выпуска программного обеспечения и документации -на основе программных элементов, содержащихся в библиотеках. Инструменты для -управления запросами на изменения программного обеспечения используются для -контролируемых <системой конфигурационного управления> программных элементов. -Другие инструменты могут обеспечивать управление базой данных и необходимыми -менеджменту отчетными средствами, а также деятельностью по разработке и -обеспечению качества. Как уже упоминалось выше, в рамках SCM-системы может быть -объединен целый ряд инструментов различных типов. При этом сама система -конфигурационного управления может быть тесно связана и поддерживать другие -виды работ, касающиеся не только SCM. - -В процессе планирования инженеры выбирают те SCM-средства, которые применимы -для решения стоящих перед ними задач. - -Вопрос выбора SCM-системы должен решаться исходя из целей, сформулированных в -отношении используемых процессов программной инженерии и уровня зрелости этих -процессов. Кроме того, необходимо учитывать и вопросы унификации программных -средств, используемых для поддержки инфраструктуры разработки и сопровождения -всего портфеля программных проектов, выполняемых в организации. В силу -фундаментальной значимости SCM-системы для обеспечения базовых процессов -программной инженерии и управления всеми проектными активами, принимать решение -об использовании той или иной SCM-системы для каждого отдельно взятого проекта -выглядит необоснованным. SCM-система, система управления требованиями (более -чем желательно, связанная с SCM), средства бизнес-моделирования и -проектирования, среды разработки – все это должно быть стандартизировано в -рамках организации, за исключением тех случаев, когда требования в отношении -тех или иных инструментальных средств сформулированы со стороны заказчика и -являются составной частью требований, предъявляемых к проекту. Возвращаясь к -вопросу выбора SCM-системы, безусловно, необходимо учитывать мнение инженеров, -однако, сложившиеся привычки не должны “перевешивать” функциональность -предлагаемых к унификации SCM-средств, обеспечиваемую ими доступность и -прозрачность информации о состоянии проекта в любой момент времени и, конечно, -возможность эффективного администрирования активов проекта, в том числе, в -контексте необходимых для этого трудозатрат. - -В процесс планирования рассматриваются аспекты, которые могут “всплыть” в -процессе внедрения (и, даже, на этапе эксплуатации) выбираемой системы -конфигурационного управления. В частности, обсуждаются и вопросы возможных -“культурных” изменений, если это необходимо (с точки зрения поставленных целей -– проекта и/или совершенствования процессов). Дополнительная информация, -затрагивающая SCM-инструментарий, представлена в области знаний SWEBOK -“Software Engineering Tools and Methods”. - -#### Контроль поставщиков/подрядчиков (Vendor/Subcontractor Control) - -Программные проекты могут требовать необходимости приобретать или использовать -уже приобретенное программное обеспечение – компиляторы и другие инструменты -(среды разработки, библиотеки компонент). Планирование должно касаться вопросов -– надо и, если надо, то как помещать эти инструменты (например, интегрируя в -программные библиотеки проекта) под управление SCM-системы и как их изменения и -обновления будут оцениваться и управляться. - -Аналогичные соображения существуют и в отношении программного обеспечения, -создаваемого подрядчиками. В этом случае, в отношении SCM-процесса подрядчика -предъявляются специальные требования со стороны заказчика и они вносятся в -контракт, предполагая не только возможность мониторинга, но и соответствие его -возможностей заданным требованиям. В последнее время все чаще отмечается -важность доступности SCM-информации для эффективного мониторинга соответствия -(compliance monitoring). - -#### Контроль интерфейсов (Interface Control) - -Когда программные элементы должны связываться с другими программными или -аппаратными элементами, изменения в одних элементах могут влиять на другие -элементы. Планирование SCM-процесса рассматривает, в частности, как будут -идентифицироваться связанные элементы и как будут управляться и сообщаться их -изменения. Конфигурационное управление может быть частью более масштабного -процесса системного уровня (т.е. в рамках всей системы, к которой относятся -соответствующие программные элементы) по определению и контролю интерфейсов, -включая описание в соответствующих спецификациях интерфейсов, планах контроля -интерфейсов и других документах. В этом случае, SCM-планирование контроля -интерфейсов проводится в контексте процесса системного уровня. - -### План конфигурационного управления (SCM Plan) - -Результаты SCM-планирования для заданного проекта определяются в плане -конфигурационного управления (Software Configuration Management Plan, SCMP), -который является документом, используемом в качестве описание SCM-процесса. Он -всегда поддерживается в актуальном состоянии (обновляясь и утверждаясь по мере -внесения в него необходимых изменений) на протяжении всего жизненного цикла. -При описании SCM-плана обычно необходимо разработать ряд детальных процедур, -определяющих как конкретные требования будут выполняться в повседневной -деятельности. - -Создание и сопровождение плана конфигурационного управления основывается на -информации, получаемой в процессе работ по планированию. Рекомендации по -созданию и сопровождению SCMP можно найти, например, в одном из ключевых -SCM-стандартов IEEE 828-98 “Standard for Software Configuration Management -Plans”. Этот стандарт описывает требования к информации, содержащейся в плане -конфигурационного управления, а также определяет шесть категорий -SCM-информации, содержащейся в плане (обычно, представленных в виде -соответствующих разделов, прим. автора): - -- Введение (Introduction) – описывает цели, содержание и используемые термины. -- Управление (SCM Management) – описывает структуру, обязанности, полномочия, -политики, директивы (указания, обязательные для исполнения) и процедуры. -- Работы (SCM Activities) – определяет идентификацию конфигураций, их контроль -и т.п. -- Расписание (SCM Schedule) – определяет связь работ по конфигурационному -управлению с другими аспектами и процессами проектной деятельности. -- Ресурсы (SCM Resources) – описывает инструменты, физические ресурсы, персонал -и т.п. -- Сопровождение плана (SCMP Maintenance) – определяет правила, по которым в -план вносятся изменения и описывает как эти изменения внедряются в повседневный -SCM-процесс. - -### Контроль выполнения SCM-процесса (Surveillance of Software Configuration Management) - -После того, как внедрен процесс конфигурационного управления, может быть -необходимо контролировать (проводить надзор) над SCM-процессом для обеспечения -того, что SCM-план исполняется надлежащим образом. В ряде случаев определяются -конкретные требования по обеспечению качества (SQA), контролирующие исполнение -процессов и процедур конфигурационного управления. Для этого может быть -необходимо введение соответствующих полномочий и назначение обязанностей по -контролю выполнения задач SCM. Аналогичные полномочия и обязанности по надзору -над SCM-процессом могут существовать в контексте SQA-деятельности. - -Использование интегрированных SCM-инструментов с возможностью контроля процесса -может сделать процедуру надзора более легкой и прозрачной. Некоторые -инструменты предоставляют высокий уровень настраиваемости для обеспечения -гибкой адаптации процессов. Другие инструменты являются менее гибкими, диктуя -те или иные процессы и их характеристики. Требования контроля (надзора), с -одной стороны, и уровень гибкости и адпатируемости, с другой, являются -определяющими критериями выбора того или иного инструмента. - -#### Метрики и процесс количественной оценки в SCM (SCM measures and measurement) - -Количественные показатели (метрики) могут определяться для обеспечения -информации о разрабатываемом продукте или для оценки исполнения самого процесса -конфигурационного управления. Связанной целью SCM-мониторинга может быть и -раскрытие возможностей по совершенствованию процесса (не только SCM-процесса, -но и других процессов программной инженерии). Количественная оценка -SCM-процессов предоставляет хорошие средства для мониторинга эффективности -деятельности по конфигурационному управлению на постоянной основе. Эти -измерения полезны для оценки текущего состояния процесса и проведения сравнений -во времени (как прогресса в отношении развития продукта, так и качества -выполнения процесса, как такового). Анализ измерений позволяет понять причины -изменения процесса и внести соответствующие коррективы в план конфигурационного -управления (SCMP). - -Программные библиотеки и различные возможности SCM-средств предоставляют -источники для получения информации о характеристиках SCM-процесса (наравне с -проектной информацией и данными, необходимыми для принятия тех или иных -управленческих решений). Например, информация о времени, необходимом для -выполнения различных типов изменений, может быть полезна для оценки критериев -того, какой уровень полномочий оптимален для утверждения определенных типов -изменений. - -Необходимо сохранять фокус на проведении анализа измерений и формировании -соответствующих выводов, вместо проведения “измерений ради измерений” (к -сожалению, последнее встречается слишком часто, чтобы не отметить этот факт). -Обсуждение количественных оценок в отношении процесса и продукта представлено в -области знаний “Процесс программной инженерии”. Программа проведения -количественных оценок обсуждается в области знаний “Управление программной -инженерией”. - -#### Аудит в рамках SCM (In-process* audits of SCM) - -Аудит может проводится на протяжении всего процесса программной инженерии для -определения текущего статуса заданных элементов конфигураций или оценки -реализации процесса конфигурационного управления. SCM-аудит предоставляет более -формальный механизм мониторинга выбранных аспектов процесса и может -координироваться с работами в области обеспечения качества (SQA; см. секцию “5. -Software Configuration Auditing”). - -* “in-process” подчеркивает непрерывность/периодичность аудита и его -позиционирование как неотъемлемой составной части конфигурационного управления. - -## Идентификация программных конфигураций (Software Configuration Identification) - -Работы по идентификации конфигураций программного обеспечения определяют -контролируемые элементы (items), устанавливают схемы идентификации для -элементов и их версий, а также задают инструменты и описывают техники, -используемые для управления этими элементами (включая их передачу под -управление SCM-процесса и системы). Данная деятельность является основой для -всех других работ по конфигурационному управлению. - -### Идентификация элементов, требующих контроля (Identifying Items to Be Controlled) - -Первый шаг в организации контроля изменений состоит в идентификации программных -элементов, которые необходимо контролировать в рамках SCM-процесса. Это -предполагает понимание программной конфигурации в контексте системной -конфигурации, выбор элементов программной конфигурации, разработку стратегии -отметки (labeling) программных элементов и описание связи между ними, а также -идентификацию базовых линий (baselines, это понятие будет обсуждаться позднее в -этой теме) вместе с процедурами включения элементов в базовую линию. - -#### Программная конфигурация (Software configuration) - -Программная конфигурация – набор функциональных и физических характеристик -программного обеспечения, сформулированная в документации или воплощенная в -продукте (см. IEEE 610.12-90, Standard Glossary for Software Engineering -Terminology). Программная конфигурация может рассматриваться как составная -часть общей системной конфигурации. - -#### Элемент конфигурации (Software configuration item) - -Элемент программной конфигурации (software configuration item, SCI) – фрагмент -программного обеспечения, вовлеченный в процесс конфигурационного управления -(и, возможно, помещенный под управление SCM-системы) и рассматриваемый как одна -(атомарная) сущность в рамках SCM-процесса (см. IEEE 610.12-90). SCM -контролирует множество различных элементов, включая не только программный код. -Программные элементы, потенциально полезные в качестве элементов программной -конфигурации (SCI), включают планы, спецификации и документы (например, -полученные в результате моделирования и проектирования), программные -инструменты, исходный и исполнимый код, библиотеки кода, данные и словари -данных, а также документацию по установке, сопровождению, эксплуатации и -использованию программного обеспечения. - -Выбор SCI является важным процессом, в рамках которого необходимо достигать -баланса между обеспечением адекватного уровня прозрачности представления -(дословно – “видимости”, visibility) в контексте контроля проекта. Правильный -выбор элементов конфигурации важен для обеспечения управляемого набора -контролируемых элементов. SWEBOK дает ссылку на источник, описывающий список -критериев по выбору элементов конфигураций. - -#### Связи между элементами конфигурации (Software configuration item relationships) - -Структурные связи между выбранными элементами конфигурации (и их составляющими) -влияют на другие SCM работы и задачи, например, сборку программного обеспечения -или анализ влияний (impact analysis) предлагаемых изменений. Надлежащее -отслеживание этих связей является важным для поддержания актуальной трассировки -(traceability) между активами проекта. Разработка схемы идентификации элементов -конфигураций (SCI) должна учитывать отображение между идентифицируемыми -элементами и структурой программного обеспечения, а также потребность в -поддержке эволюционирования программных элементов и их связей по мере развития -системы. - -#### Версия программного обеспечения (Software version) - -Программные элементы развиваются по мере выполнения проекта. Версия (version) -программного элемента – конкретно идентифицированный и специфицированный -элемент. Версия элемента может также рассматриваться в качестве определенного -состояния (state) эволюционирующего элемента. Обновление (revision) – новая -версия элемента, предназначенная для замены его старой версии. Вариант -(variant) – новая версия элемента, добавляемая в конфигурацию без замены старой -версии (то есть сосуществующая с другой версией того же элемента). - -#### Базовая линия, срез (Baseline) - -Базовая линия или <фиксированный> срез (baseline) программного обеспечения -–набор элементов программной конфигурации, формально определенный и -зафиксированный по времени в процессе жизненного цикла программного -обеспечения. Этот термин также иногда используется для указания конкретной -версии элемента конфигурации, если это согласовано заранее. В определенных -случаях, базовая линия может изменяться только через формальную процедуру -контроля изменений. Фиксированный срез в сочетании со всеми утвержденными -изменениями в отношении его представляет собой текущую утвержденную -конфигурацию. - -Хотя, упоминаемая в SWEBOK классификация базовых линий в определенной степени -является умозрительной и, безусловно, не единственно возможной, она полезна для -адаптации и выработки внутрикорпоративных стандартов, на основе которых, в -дальнейшем строятся соответствующие планы конфигурационного управления (SCMP). -Приведенную ниже классификацию, соответственно, стоит рассматривать лишь как -пример, но пример достаточно полезный для данного контекста обсуждения. - -В общем случае, используются следующие типы базовых линий – функциональные, -утвержденные, эволюционные или промежуточные, а также, базовые линии продукта. -Функциональный срез соответствует принятым программным требованиям. -Утвержденный срез соответствует принятым программным требованиям и требованиям -в отношении интерфейсов. Базовая линия продукта представляет собой срез -активов, относящихся к продукту, на заданный момент времени (при этом, базовая -линия продукта не всегда является его версией, готовой к выпуску, т.е. к -передаче в эксплуатацию). Полномочия по изменению заданной базовой линии обычно -находятся в ведении организационной структуры, отвечающей за разработку -программного обеспечения, но могут также разделяться и с другими -организационными структурами (например, отвечающей за конфигурационное -управление или тестирование). Базовая линия продукта соответствует завершенному -программному продукту, готовому для проведения работ по интеграции в рамках -целевой системы (system integration). Базовые линии, используемые для данного -проекта, вместе с ассоциированным уровнем полномочий, необходимым для -утверждения изменений, обычно идентифицируется в конфигурационном плане – SCMP. - -Здесь уместно провести параллель между вехами (milestone) проекта и базовыми -линиями. Выглядит вполне обоснованным отображение вех проекта на базовые линии, -как “выходы” (результаты) выполнения процессов проекта к моменту достижения -соответствующей проектной вехи. - -#### Включение элементов в программную конфигурацию (Acquiring software configuration items) - -Различные элементы программной конфигурации передаются под управление -SCM-процесса в различные моменты времени и включаются в базовые линии в -определенных точках жизненного цикла. Инициирующим событием является завершение -определенных форм формального утверждения задач, таких как формальная оценка -(review). Рисунок 4 характеризует развитие базовой линии в процессе жизненного -цикла. Этот рисунок базируется на каскадной (waterfall) модели только в целях -иллюстрации; нижние индексы используются для обозначения версий -эволюционирующих элементов. Запросы на изменения (software change requests, -SCR), присутствующие на рисунке, описываются в теме 3.1 “Requesting, -Evaluating, and Approving Software Changes”. - -![Рисунок 4. Включение элементов в конфигурацию. [SWEBOK, 2004, с.7-7, рис. 4]](images/configuration_management_4-elements.jpg) - -После включения элемента в конфигурацию в качестве SCI, изменения элементов -должны утверждаться формально, как связанные с соответствующими элементами -(SCI) и базовыми линиями, следуя плану конфигурационного управления (SCMP). -После утверждения <запроса на изменение и проведения работ по изменению>, -<измененный> элемент включается в конфигурацию, в соответствии с заданной -процедурой утверждения. - -### Программная библиотека (Software Library) - -Программная библиотека – контролируемая коллекция программных приложений и -связанной с ними документации, предназначенная для использования в процессе -разработки, эксплуатации и сопровождения программного обеспечения (см. IEEE -610.12-90). В качестве <элемента> программной библиотеки, также, может -рассматриваться инструментарий, используемый в работах по выпуску программного -обеспечения и передаче его в эксплуатацию (например, инсталляции). На практике -могут использоваться различные типы библиотек, каждая из которых соответствует -определенному уровню зрелости элементов программного обеспечения. Например, -“рабочая библиотека” (working library) может поддерживать работы по -кодированию, “библиотека поддержки проекта” (project support library) может -поддерживать тестирование, “мастер-библиотека” (master library) может -использоваться для завершенных продуктов (например, как вся совокупность -средств, используемых для разработки и/или выпуска продукта). С каждой -библиотекой ассоциирован соответствующий уровень контроля конфигурационного -управления, также ассоциированный с базовой линией и уровнем полномочий по -внесению изменений. Безопасность (в терминах контроля доступа и средств -резервного копирования) является одним из ключевых аспектов управления -библиотеками. SWEBOK отмечает, что существуют различные модели программных -библиотек, а также приводит соответствующие первоисточники по этой теме. - -Используемые для каждой библиотеки инструменты должны поддерживать контроль -SCM, необходимый для данной библиотеки, как в терминах управления элементами -конфигурации (SCI), так и с точки зрения контроля доступа к библиотеке. На -уровне рабочей библиотеки – это средства управления кодом, обслуживающие -разработчиков, специалистов по сопровождению и SCM-процесс/инструментарий -(например, среда разработки должна обеспечивать интеграцию с SCM-системой). В -данном контексте, рабочая библиотека фокусируется на управлении версиями -программных элементов (к которым, безусловно, относится не только код, но и -запросы на изменения, включая сообщения об обнаруженных дефектах, и т.п.) в -многопользовательской среде. На более высоком уровне контроля, доступ ограничен -сильнее и SCM (процесс и/или система) является основным пользователем -<библиотеки> (например, для осуществления автоматической сборки продукта по -расписанию). - -Все эти библиотеки также являются важным источником информации для -количественной оценки работ, их результата и прогресса <в развитии программных -элементов>. - -## Контроль программных конфигураций (Software Configuration Control) - -Контроль программных конфигураций касается вопросов управления изменениями в -течение жизненного цикла программного обеспечения. Он включает процесс -определения того, какие именно изменения должны быть сделаны, какие полномочия -необходимы для утверждения определенных <типов> изменений, в чем состоит -поддержка реализации этих изменений, а также концепцию формального утверждения -отклонений от проектных требований, также как и отказа от внесения изменений. -Получаемая в результате этого информация полезна для количественной оценки -потока изменений, нарушения целостности <системы> и аспектов “переработки” в -проекте (в большинстве случаев, по времени, стоимости и усилиям - -трудозатратам). - -### Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving Software Changes) - -Первый шаг по управлению изменениями контролируемых элементов состоит в -определении того, какие именно изменения надо производить. Процесс обработки -запросов на изменения (software change request process), представленный на -рисунке 5, включает формальные процедуры по предложению (submitting) и записи -(recording) запросов на изменения, оценки потенциальной стоимости и влияния -предлагаемых изменений, а также принятию, модификации или отказу от внесенных -предложений по изменениям. Запросы на изменения элементов программных -конфигураций могут вноситься любым лицом в любой точке жизненного цикла и может -включать предлагаемые решения и соответствующий уровень приоритетности. Один из -источников запросов на изменения состоит в инициировании корректирующих -действий в ответ на сообщения о проблемах (problem reports). Вне зависимости от -источника запроса, в самом запросе на изменение (software change request, SCR) -обычно записывается информация о его типе (например, “дефект” или “заявка на -расширение функциональных возможностей”/”пожелание” – enhancement/suggestion). - -![Рисунок 5. Поток процесса контроля изменений. [SWEBOK, 2004, с.7-7, рис. 5]](images/configuration_management_5-changes.jpg) - -Такой подход обеспечивает возможность отслеживания дефектов и сбора метрических -показателей о деятельности по обработке и внесению изменений, с группировкой по -типу изменений. Как только получен запрос на изменение (SCR), производится -техническая оценка (включающая, а иногда и называемая анализом влияний – impact -analysis) запрашиваемых изменений для определения масштабов модификаций, -необходимых для удовлетворения параметров запрашиваемых изменений (достаточно -часто, в результате такого анализа формулируются соответствующие требования, -определяющие содержание необходимых работ). Четкое понимание связей между -программными (и, возможно, аппаратными) элементами системы является важной -составной частью данной задачи. Наконец, органы, обладающие полномочиями, -соответствующими затрагиваемой базовой линии, элементам программной -конфигурации и природе изменений, должны оценить технические и управленческие -(организационные) аспекты внесения запрашиваемых изменений, а также принять, -модифицировать, отклонить или отложить предлагаемые изменения. - -#### Совет по конфигурационному контролю (Software Configuration Control Board) - -Полномочия по принятию или отклонению предлагаемых изменений обычно возлагаются -на <организационную> сущность, называемую совет по конфигурационному контролю - -Configuration Control Board (чаще звучит как совет по координации изменений - -Change Control Board, CCB). В небольших проектах такие полномочия могут, в -действительности, принадлежать лидеру или одному назначенному лицу из числа -членов проектной команды. В общем случае может существовать несколько уровней -полномочий в части принятия решений в отношении изменений, в зависимости от -различных критериев, таких как критичность предлагаемых изменений, их -приоритет, природа изменений (например, параметры бюджета или расписания) или -текущая точка жизненного цикла. Решения о том, кто именно будет включен в CCB -для данной системы (проекта) могут варьироваться, в зависимости от данных -критериев. Однако, в CCB всегда должно присутствовать лицо, вовлеченное в -организацию конфигурационного управления. В CCB входят все заинтересованные -лица, чья роль соответствует уровню CCB. Когда содержание полномочий CCB -охватывает только аспекты программного обеспечения, такой совет называется -Software Configuration (Change) Control Board – SCCB. Деятельность CCB обычно -является объектом аудита качества или оценки. - -Учитывая роль управления изменениями в конфигурационном управлении и реальные задачи CCB, более обоснованным выглядит использование именно названия Change Coordination & Control Board – в общем случае звучащий как совет по координации и контролю изменений. - -#### Процесс обработки запросов на изменения (Software change request process) - -Эффективный процесс <обработки> запросов на изменения (SCR process) требует -использования соответствующих средств поддержки и процедур <для данного вида -деятельности>, от “бумажных” форм и документированных процедур (как -последовательности действий или сценариев) до программных инструментов, -позволяющих отсылать запросы на изменения, выполнять процесс обработки таких -запросов (изменять их статус, комментировать, детализировать и т.п.), -фиксировать решения, принятые CCB, а также генерировать отчетную информацию по -процессу обработки запросов на изменения. Связь между этими средствами и -инструментами обработки отчетов об ошибках может существенно облегчить -определение решений для обнаруженных проблем. - -Обработка различных типов запросов на изменения в отношении разрабатываемых или -модифицируемых программных систем, будь то сообщения о проблемах (defect -report) или запросы на расширение функциональности (enhancement request), даже -при разных процессах принятия решений в отношении их, должны быть объединены в -единую систему (в единой базой данных), являющуюся составной и неотъемлемой -частью единой среды конфигурационного управления. Только в этом случае можно -обеспечить однозначную и актуальную связь между запросами различных типов и -другими активами проекта (кодом, документацией, проектными моделями, задачами, -ресурсами и т.п.), что позволяет не только получать актуальную информацию в -любой момент времени, но и оперативно принимать те или иные (в том числе, -управленческие) решения в отношении проекта, основываясь на максимально полном -и корректном объеме информации. - -SWEBOK отмечает, что описания процессов и соответствующих форм (например, формы -сообщения о проблеме) можно найти в большом количестве внешних источников, в -частности, указанных непосредственно в библиографии SWEBOK. - -### Реализация изменений (Implementing Software Changes) - -Принятые (утвержденные) запросы на изменения (SCR) реализуются используя -определенные процедуры, в соответствии с подходящими требованиями в отношении -расписания. Если набор утвержденных запросов на изменения может выполняться -одновременно, необходимо обеспечить отслеживание того, какие именно SCR -реализованы в конкретной версии программного продукта и базовой линии -<конфигурации>. Составной частью процесса “закрытия” изменения (по аналогии с -closure - “закрытием”, то есть завершением проекта), является аудит(ы) -конфигурации(й) и верификация качества программного обеспечения. Это -обеспечивает гарантию того, что были внесены только утвержденные изменения. -Описанный выше процесс обработки запросов на изменения обычно включает -документирование всей информации, связанной с принятым изменением. - -Фактическая реализация изменений поддерживается инструментальными средствами -соответствующей программной библиотеки (см. выше 2.2 “Программная библиотека”), -обеспечивающими управление версиями и поддержку <единого> репозитория кода. Как -минимум, эти инструменты должны поддерживать операции chek-in/check-out -(помещение в репозиторий/ получение из репозитория) и ассоциированные -возможности по контролю версий (например, отметка версии – labeling, сравнение -– compare/diff, слияние – merge и т.п.). Более мощные инструменты могут -поддерживать параллельную разработку (parallel development) и среду -географически распределенной разработки (geographically distributed -environment). Эти инструменты могут объявляться (в рамках организации) как -отдельные специализированные приложения, целиком находящиеся под контролем -независимой SCM-группы (как самостоятельной/выделенной организационной -сущности). Наконец, они могут быть столь элементарными, что включают только -упрощенный контроль версий, например, на уровне файловой системы операционной -среды. - -Безусловно, существует широкий спектр, обоснованных функциональных возможностей -инструментальных средств, используемых для решения различных задач -конфигурационного управления. При этом, при выборе соответствующего инструмента -или комплекса инструментов, необходимо точно понимать их функциональную -нагрузку, уровень интегрируемости, возможности по адаптации с учетом конкретных -процессов жизненного цикла в проектной команде или организации, в целом. Только -с учетом этих критериев и других ограничений можно сформировать оптимальное и -эффективное решение по программному обеспечению SCM-процесса в том объеме, -который обоснован в каждом конкретном случае. - -### Отклонения и отказ от изменений (Deviations and Waivers) - -Ограничения, накладываемые на усилия, прилагаемые к выполнению определенных -работ <программной инженерии>, как и спецификации, созданные в процессе -разработки, могут содержать условия, которые не могут быть удовлетворены в -заданной точке жизненного цикла. Отклонение (deviation) - утверждение -изменений, внесенных относительно предварительно сформулированных условий к -разработке тех или иных аспектов разработки заданных элементов. Отказ (waiver) -– утверждение дальнейшего использования элемента, которое отличается в той или -иной степени от предварительно заданных условий. В обоих случаях используются -формальные процессы (точнее, процедуры) для получения одобрения на отклонение -или отказ от предопределенных ранее условий. - -В большинстве случаев, говорят об отклонении от требований (изменении -реализации требований с одновременной их корректировкой) и отказе от выполнения -запросов на изменения (или отклонении запросов). Как вы уже обратили внимание, -использование слова “отклонение” сильно зависит от контекста, подразумевая, в -первом случае, определенную корректировку условий и работ и, во втором случае, -полный отказ от внесения изменений с утверждением и обоснованием такого отказа. - -## Учет статусов конфигураций (Software Configuration Status Accounting) - -Учет статусов программных конфигураций (Software Configuration Status Accounting, SCSA) подразумевает сохранение (recording) и генерацию отчетности (reporting) для всей информации, необходимой для эффективного управления конфигурациями программного обеспечения. - -### Информация о статусе конфигураций (Software Configuration Status Information) - -Деятельность по учету статуса конфигураций (SCSA) предназначена и выполняется -для получения (и генерации отчетов) информации, необходимой для осуществления -процессов жизненного цикла системы. Как и в любой информационной системе, -информация о статусе конфигураций должна идентифицироваться, собираться и -поддерживаться <в актуальном состоянии> по мере эволюции этих конфигураций. -Различная информация и количественные показатели необходимы для поддержки -процесса конфигурационного управления, а также для генерации отчетности (о -статусе конфигураций), необходимой для управления, выполнения процессов -программной инженерии и других связанных видов деятельности. Типы доступной -информации обычно включают идентификацию утвержденных конфигураций, наравне с -идентификацией и текущим статусом реализации изменений, отклонений и отказов от -изменений. SWEBOK дает ссылки на источники, содержащие возможные (частные) -списки важных информационных элементов. - -Современные инструментальные средства SCM должны включать определенные формы -поддержки сбора и данных и подготовки SCSA-отчетности. Это может быть -реализовано на уровне обращения к соответствующим базам данных, может быть -представлено и в виде самостоятельных приложений, а также являться -функциональной составляющей более крупных интегрированных инструментальных -средств. - -Логично, что только такие интегрированные многофункциональные средства возможно -считать полноценными SCM-инструментами, образующими категорию систем -конфигурационного управления. В противном случае, мы говорим лишь об отдельно -взятых (пусть и взаимодействующих, в той или иной степени) инструментах - -“системе управления заявками на изменения” (change request submission), -“системе сообщения и отслеживания дефектов” (defect-tracking), “системе -контроля версий” (version control), “системе генерации отчетности” -(configuration reporting) и т.п. - -#### Отчетность по статусу конфигураций (Software Configuration Status Reporting) - -Отчетная информация может быть использована различными организационными -единицами или проектными группами, включая команду разработки, команду -сопровождения, управляющих проектами и персоналом, обеспечивающим проверку -качества. Отчетность может предоставляться в специальной форме, следуя -специфическим запросам, но может генерироваться на постоянной основе (с -определенной периодичностью) в соответствии с заданными шаблонами. Определенные -элементы информации, получаемой в процессе деятельности по учету статуса -конфигураций, может становиться составной частью данных, необходимых и -используемых в работах по обеспечению качества (как продуктов, так и -процессов). - -В дополнение к отчетности по текущему статусу конфигураций, информация, -получаемая в процессе SCSA-деятельности, может использоваться как основа для -проведения различных количественных оценок в интересах менеджмента, разработки -или конфигурационного управления. Например, к такого рода данным относятся: -количество запросов на изменения на один конфигурационный элемент; среднее -время, необходимое для реализации запрошенных изменений <заданного типа>. - -## Аудит конфигураций (Software Configuration Auditing) - -Аудит программного обеспечения – деятельность, выполняемая для независимой -оценки программных продуктов и процессов на <формальное> соответствие -(conformance) применимым в данном случае инструкциям, стандартам, руководящим -документам, планам и процедурам (см. IEEE 1028-97 “Standard for Software -Reviews”). Аудиты проводятся в <строгом> соответствии с четко определенными -процессами, содержащими и определяющими различные роли аудиторов и из -обязанности. Каждый аудит должен быть, в свою очередь, четко спланирован и -может требовать привлечения многих специалистов для выполнения различных задач -(определяемых процедурой аудита) за достаточно короткий промежуток времени. -Автоматизированные средства, обеспечивающие поддержку планирования и проведения -аудита, могут существенно облегчить и ускорить этот процесс. SWEBOK отмечает, -что рекомендации по проведению аудита можно найти во многих источниках, в том -числе, включая стандарт IEEE 1028-97 “Standard for Software Reviews”. - -Деятельность по аудиту программных конфигураций определяет степень, в которой -элемент <конфигурации> (SCI) удовлетворяет заданным (например, на уровне -требований и/или запросов на изменения) функциональным и физическим -характеристикам. Неформальный аудит такого типа может быть связан с ключевыми -точками жизненного цикла (вехами проекта, в терминах управления проектами - -milestones). Существует два достаточно распространенных типа формального -аудита (требуемого определенными категориями контрактов, например, на создание -критически-важного программного обеспечения): функциональный аудит конфигураций -(Functional Configuration Audit, FCA) и физический аудит конфигураций (Physical -Configuration Audit, PCA). Успешное (в терминах соответствия результатов -заданным условиям) завершение этих аудитов может быть обязательным требованиям -для фиксирования базовой линии продукта. В то же время, если сравнивать -контекст FCA и PCA для программного и аппаратного обеспечения, перед их -выполнением необходимо четко оценивать реальные потребности в таких видах -аудита (так как они требуют существенных, иногда, просто “неподъемных” затратах -ресурсов, если оценивать их в рамках заданных ограничений проекта). - -### Функциональный аудит программных конфигураций (Software Functional Configuration Audit) - -Цель FCA состоит в том, чтобы убедиться, что контролируемый программный элемент -полностью соответствует заданным спецификациям. “Выход”, то есть результат -проверки и аттестации (V&V, verification and validation) программного -обеспечения является ключевым “входом” (исходными данными) для проведения этого -аудита. - -### Физический аудит программных конфигураций (Software Physical Configuration Audit) - -Цель PCA состоит в том, чтобы убедиться, что дизайн и документация точно -согласуются с самим программным продуктом. - -### Внутренние аудиты базовых линий (In-process Audits of Software Baseline) - -Как уже упоминалось выше, аудиты могут выполняться на протяжении всего процесса -разработки для получения текущего статуса заданных элементов конфигураций. В -данном случае, аудит может проводиться в отношении к выборочным элементам -базовых линий с тем, чтобы убедиться, что соблюдаются заданные спецификациями -характеристики процесса, скорости и качества развития продукта, а также того, -что документация соответствует и поддерживается в согласованном состоянии с -документируемыми элементами продукта в процессе их эволюционирования/на -протяжении жизненного цикла. - -## Управление выпуском и поставкой (Software Release Management and Delivery) - -Термин “релиз” (release, выпуск) используется в данном контексте, подразумевая -распространение <и использование> элементов конфигураций за рамками работ по -разработке программного обеспечения. Это может включать как внутренние релизы, -так и выпуск и передачу программного обеспечения заказчикам. В ситуациях, когда -доступны для поставки различные версии программных элементов (в частности, -различные версии для разных платформ или редакции с различным набором -функциональных возможностей), часто бывает необходимо создавать -специализированные версии и пакеты (сборки) соответствующих материалов -(элементов, активов) для выпуска в качестве <самостоятельной> версии. -Программная библиотека (предоставляющая соответствующий инструментарий для -такой сборки) играет ключевую роль в выполнении таких работ. - -### Сборка программного обеспечения (Software Building) - -Сборка (building) программного обеспечения – деятельность по комбинированию -корректных версий элементов программных конфигураций, проводимая с -использованием соответствующих конфигурационных данных, с целью получения -исполняемой программы (программной системы) для передачи заказчику и/или другим -получателям (например, выполняющим работы по тестированию). Исполняемая -программа для аппаратных и программно-аппаратных систем получается в результате -деятельности по системной сборке (system building). Инструкции по сборке -предоставляют описание необходимых для сборки шагов, представленных в заданной -(корректной) последовательности. Работы по сборке программного обеспечения -выполняются не только для получения нового релиза, но и для повторного создания -предыдущих релизов в целях их восстановления, тестирования, сопровождения или -каких-либо других необходимых действий. - -Программное обеспечение собирается с использованием заданных версий таких -средств поддержки (supporting tools), как компиляторы. В ряде случаев может -требоваться повторная сборка точной копии ранее собранного элемента -конфигурации. В этом случае, средства поддержки и ассоциированные инструкции по -сборке должны находиться под контролем SCM (подразумевая, в зависимости от -контекста, в определенных ситуациях, SCM-систему или только процесс) для -обеспечения доступности корректной версии инструментария. - -Часто бывают полезны возможности инструментов, позволяющие выбирать корректные -для заданного окружения версии программных элементов, а также обеспечивать -автоматизацию процесса сборки (например, по расписанию) программного -обеспечения на основы выбранных версий и соответствующих конфигурационных -данных. Такие возможности инструментов особенно необходимы для крупных проектов -с параллельной разработкой и/или распределенной средой разработки -(географически распределенной команды разработки). Большинство программных -средств, обеспечивающих инфраструктуру разработки поддерживают такую -возможность (или, как минимум, декларируют ее). Эти инструменты сильно -отличаются (по степени комплексности предоставляемого функционала и) по своей -сложности, требуя в ряде случаев изучения специализированного (специфичного для -конкретного инструмента) языка сценариев, или предоставляя графические -возможности, скрывающие сложность настройки “интеллектуальных” средств сборки -программного обеспечения. - -Процесс и результаты сборки могут быть необходимы для последующего -использования <в других процессах, работах и проектах> и часто являются -объектом верификации (проверки) в рамках деятельности по обеспечению качества -(SQA). - -### Управление выпуском программного обеспечения (Software Release Management) - -Управление выпуском (release management) программного обеспечения охватывает -идентификацию, упаковку (сборку) и передачу элементов продукта, например, -исполняемых программ, документации, аннотацию релиза (release note) и -конфигурационные данные. Понимая, что изменения в продукте происходят -постоянно, одной из задач управления выпуском продукта является определение -момента времени, когда именно выпускать продукт (в этом контексте, управление -выпуском может быть тесно связано как с деятельностью по обеспечению качества, -так и с маркетинговыми соображениями в отношении выпускаемого продукта). На это -решение также влияет серьезность проблем, решению которых адресуется релиз, и -количественная оценка плотности сбоев (fault densities) в предыдущих релизах. -Задача упаковки (packaging) состоит в идентификации того, какие элементы -продукта должны быть выпущены (например, на основании функциональных требований -и их трассировки на элементы конфигурации), и в последующем выборе корректных -вариантов этих элементов, задаваемом аспектами применения продукта. -Документирование информации о физическом содержании релиза, обычно, включают в -документ описания версии (version description document). В свою очередь, -аннотация релиза (release note) содержит информацию о новых возможностях, -известных проблемах, а также требованиях к платформе(ам), которые необходимо -соблюдать для предусмотренного режима эксплуатации продукта. Подготовленный к -выпуску пакет (package) также включает инструкции по установке и обновлению -<предыдущей версии>. Создание такой инструкции может быть осложнено тем, что -некоторые текущие пользователи могут иметь устаревшие версии, более ранние, чем -предыдущий выпущенный релиз. Наконец, в ряде случаев, деятельность по -управлению выпуском может требовать отслеживание распространения (поставки) -продукта различным заказчикам или в рамках заданных целевых систем. Например, -возможны ситуации, когда поставщику требуется уведомить заказчика об -обнаруженных проблемах. - -Для поддержки таких функций управления выпуском могут требоваться -соответствующие возможности инструментария поддержки (средств поддержки или -“вспомогательных средств”, если, например, попытаться максимально приблизиться -к русскоязычной терминологии ГОСТ 12207). Также полезна и связь с -инструментальными возможностями поддержки процесса обработки запросов на -изменения для отображения содержимого релиза на полученные запросы на изменения -(SCR - software change request, включая сообщения об обнаруженных ранее и -исправленных в данном релизе ошибках, прим. автора). Эти инструментальные -средства <поддержки управления выпуском продуктов> также могут поддерживать -информацию о различных целевых платформах и <операционном> окружении, -используемом у заказчиков. blob - /dev/null blob + f78dc25f689f5b1b60e6d3a65fcf0ce4149c4680 (mode 644) --- /dev/null +++ 6_software_configuration_management.md @@ -0,0 +1,988 @@ +# Конфигурационное управление + +Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - +SWEBOK. + +Содержит перевод описания области знаний SWEBOK “Software Configuration +Management”, с замечаниями и комментариями. + +Система может быть определена как коллекция компонент, организованных для +выполнения заданных функций или реализации комплекса функциональности (IEEE +610.12-90, Standard Glossary for Software Engineering Terminology). +Конфигурация системы – функциональные и/или физические характеристики +аппаратного, программно-аппаратного, программного обеспечения или их +комбинации, сформулированные в технической документации и реализованные в +продукте. Конфигурация также может восприниматься как сочетание конкретных +версий аппаратных, программно-аппаратных или программных элементов, +объединенных вместе, в соответствии с заданными процедурами сборки и отвечающих +определенному назначению. Конфигурационное управление (CM - Configuration +Management), в свою очередь, дисциплина идентификации конфигурации системы в +определенные (заданные) моменты времени, с целью систематического контроля +изменений конфигурации, а также поддержки и сопровождения целостной и +отслеживаемой (трассируемой) конфигурации на протяжении всего жизненного цикла +системы. + +Конфигурационное управление формально определяется глоссарием IEEE 610 как +“дисциплина приложения технических и административных указаний (инструкций) и +контроля (надзора) для: идентификации и документирования функциональных и +физических характеристик элементов конфигураций, контроля (управления) +изменений этих характеристик, записи (сохранения) и ведения отчетности по +обработке изменений и статусу их реализации, а также проверки (верификации) +соответствия заданным требованиям.” + +В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207, конфигурационное +управление в области программного обеспечения (“6.2 Управление конфигурацией” +по ГОСТ) – Software Configuration Management (SCM[^12]) – один из +вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающих +проектный менеджмент, деятельность по разработке и сопровождению, обеспечению +качества, а также, заказчиков и пользователей конечного продукта. + +[^12]: В ряде источников можно увидеть аббревиатуру SCCM – Software Configuration +and Change Management. При том, что в понимании SWEBOK и соответствующих +стандартов, содержание SCM и SCCM тождественно, термин SCCM иногда используется +для того, чтобы подчеркнуть принципиальную значимость управления изменениями +как составной части конфигурационного управления. + +Концепции конфигурационного управления применяются в отношении всех элементов, +которые необходимо контролировать (несмотря на то, что существуют определенные +отличия между конфигурационным управлением в приложении к аппаратному и +программному обеспечению). + +SCM-деятельность тесно связана с работами по обеспечению качества программного +обеспечения (Software Quality Assurance - SQA). В соответствии с определением +области знаний SWEBOK “Качество программного обеспечения” (Software Quality), +SQA-процессы обеспечивают гарантию того, что программные продукты и процессы +жизненного цикла в проекте соответствуют заданным требованиям, за счет +планирования и выполнения работ, направленных на достижение определенного +(приемлемого) уровня качества создаваемого программного продукта. +SCM-деятельность помогает в достижении этих SQA-целей. В контексте некоторых +проектов, определенные работы по конфигурационному управлению задаются +требованиями SQA (например, в IEEE 730-02 “Standard for Software Quality +Assurance Plans”). + +Работы по конфигурационному управлению <программного обеспечения> включают: +управление и планирование SCM-процессов, идентификацию программных +конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также +управление выпуском (release management) и поставкой (delivery). + +На рисунке 1 изображено стилизованное представление этих работ. + +![Рисунок 1. Работы по конфигурационному управлению (SCM Activities) [SWEBOK, 2004, с.7-1, рис. 1]](images/configuration_management_1-activities.jpg) + +Данная область знаний связана со всеми другими областями знаний и дисциплинами +программной инженерии, так как объектами приложения SCM являются все артефакты, +создаваемые и используемые в процессах программной инженерии. + +К сожалению, SCM-деятельность во многих проектных командах сводится лишь к +контролю версий (version control) исходных текстов и, в лучшем случае, +документации (причем не проектной документации, в целом, а документации на +создаваемое программное обеспечение). Попытка ограничить конфигурационное +управление только вопросами контроля версий, в какой-то степени, является +результатом непонимания того, что результаты проекта – это не только исходный +код, исполняемые модули и пользовательская документация, но и все то, что +создавалось (пусть и для решения тактических задач, как это часто бывает с +некоторыми моделями и результатами пилотных работ по созданию прототипов) на +протяжении всего проекта. Активами проекта (результатами, артефактами) являются +и описания бизнес-процессов и бизнес-сущностей, и архитектурные модели, и +требования, и план проекта/проектные задачи (как комплекс параметров, связанных +с распределением ресурсов), и запросы на изменения (включая информацию о +дефектах) и многое другое. Безусловно, упрощение вопросов конфигурационного +управления до уровня управления версиями, с коньюктурной точки зрения, выгодно +многим поставщикам соответствующих инструментальных средств. В определенных +случаях, особенно, для малых проектов или временно используемых/”одноразовых” +систем (например, по односторонней, “one-way” миграции данных из унаследованной +системы в новую), упрощенный взгляд на конфигурационное управление может быть +вполне обоснован. Однако, как это ни прискорбно, часто приходится наблюдать +позиционирование такой, с позволения сказать, “практики”, как некоего “стиля +гибкой работы”, подменяющей реальную динамику и гибкость agile-подходов +(например, XP) отсутствием управления (важно понимать и помнить, что управление +далеко не всегда является директивным), как такового (например, по определению +содержания проекта на основе консенсуса проектной команды и вовлеченных в +проектные работы представителей заказчика). В свою очередь, даже когда все +активы проекта находятся под контролем соответствующих SCM-систем, необходимо +осознавать, что конфигурационное управление предполагает постоянно действующий +процесс, а не просто комплекс определенных периодически выполняемых операций. +Только восприятие SCM-деятельности в качестве инфраструктурной основы процессов +жизненного цикла может обеспечить эффективность управления программными +проектами, то есть – достижение поставленных целей и создание результатов, +удовлетворяющих заданным критериям. В то же время, конфигурационное управление +- необходимое, но не достаточное условие, так как только совокупность процессов +жизненного цикла, включая управление требованиями, проектирование и другие, не +менее важные аспекты, определяют весь комплекс работ по созданию программных +систем. + +![Рисунок 2. Область знаний “Конфигурационное управление” [SWEBOK, 2004, с.7-3, рис. 2]](images/configuration_management_area_small.jpg) + +## Управление SCM-процессом (Management of SCM Process) + +SCM-деятельность контролирует эволюцию и целостность продукта, идентифицируя +его элементы, управляя и контролируя изменения, а также, проверяя, записывая и +обеспечивая отчетность по конфигурационной информации. С инженерной точки +зрения, SCM способствует разработке и реализации изменений. Успешное внедрение +SCM требует точного планирования и управления. Это, в свою очередь, +предполагает понимание организационного контекста и тех ограничений, которые +связаны с проектированием и реализацией процесса конфигурационного управления. + +### Организационный контекст SCM (Organizational Context for SCM) + +Для планирования SCM-процесса необходимо понимать организационный контекст и +связи между организационными элементами. SCM-работы предполагают взаимодействие +с другими аспектами проектной деятельности (не путайте с управлением проектами +– это, при всей своей значимости, лишь один из видов проектной деятельности) и +организационными элементами. + +Организационные элементы, отвечающие за процессы поддержки программной +инженерии, могут быть структурированы несколькими способами. Несмотря на то, +что ответственность за выполнение определенных SCM-задач может быть назначена +(принята или ассоциирована, в зависимости от управленческих принципов и +установок, т.е. общего менеджмента - general management) различным частям +(лицам, группам, подразделениям и т.п.) организации, например, структуре, +отвечающей за разработку программного обеспечения, общая ответственность за +конфигурационное управление часто возлагается на отдельный (специализированный) +организационный элемент или назначенную персону. + +Программное обеспечение часто разрабатывается как составная часть большей +системы, содержащей аппаратные и программно-аппаратные/встраиваемые элементы. В +этом случае, SCM-деятельность ведется параллельно с работами по +конфигурационному управлению (CM) в отношении аппаратной или +программно-аппаратной части, строго согласуясь с общим конфигурационным +управлением на уровне системы, в целом. Ряд источников (см. библиографию +SWEBOK, связанную с данной областью знаний) описывает SCM в сочетании с +контекстом, в рамках которого проводится такая деятельность. + +SCM может играть роль интерфейса к работам, направленным на обеспечение +качества (quality assurance), вытекающим, например, из отслеживания записей <по +изменениям> и несогласующихся элементов (например, выявленным в процессе сборки +очередной версии системы, прим. автора). С точки зрения составителей <данной +области знаний SWEBOK>, некоторые элементы, находящиеся под управлением SCM +<процесса>, могут также служить объектами рассмотрения в рамках организационных +программ по обеспечению качества. Управление несогласующемися элементами обычно +относится к работам по управлению качеством. Однако, SCM может обеспечить +существенную помощь в отслеживании (трассировке) и создании отчетности по +элементам программных конфигураций, попадающих в такую <проблемную> категорию. + +SWEBOK отмечает, что возможно тесное взаимодействие между организационными +структурами, отвечающими за разработку и сопровождение (и SCM играет роль +инфраструктуры, обеспечивающей такую связь). + +В зависимости от контекста, существует множество подходов и практик в части +выполнения задач конфигурационного управления в приложении к программному +обеспечению. Часто, одни и те же инструменты поддерживают и разработку, и +сопровождение, обеспечивая достижение целей и содержания SCM. + +### Ограничения и правила SCM (Constraints and Guidance for the SCM Process) + +Ограничения и правила в отношении процесса конфигурационного управления +порождаются различными источниками. Политики и процедуры, формулируемые на +корпоративном или другом организационном уровне, могут влиять или предписывать +структуру и реализацию SCM-процесса для заданного проекта. Кроме того, контракт +между заказчиком и поставщиком может содержать положения, затрагивающие процесс +конфигурационного управления. Например, может требоваться проведение +определенных процедур проверки (аудита) или специфицирован набор элементов +(активов, артефактов), передаваемых под управление <процедур и системы> +конфигурационного управления (или в части формализации обработки и контроля +реализации запросов на изменения, поступающих от заинтересованных лиц). Когда +разрабатываемый программный продукт потенциально затрагивает аспекты публичной +безопасности, могут налагаться определенные ограничения со стороны +соответствующих регулирующих органов (например, USNRC Regulatory Guide 1.169, +“Configuration Management Plans for Digital Computer Software Used in Safety +Systems of Nuclear Power Plants”, U.S. Nuclear Regulatory Commission, 1997). +Наконец, на структуру и реализацию SCM-процесса в проекта влияют выбранные (с +точки зрения модели и адаптированных характеристик) процессы жизненного цикла и +инструменты, применяемые для реализации программной системы. + +Рекомендации по структуре и реализации SCM-процесса могут быть также +результатом применения лучших практик (best practices), представленных в +стандартах, выпущенных соответствующими стандартизирующими организациями. +Лучшие практики также отражены в моделях совершенствования и оценки процессов, +например, в CMMI – Capability Maturity Model Integration Института программной +инженерии (SEI – Software Engineering Institute) университета Карнеги-Меллон +(Carnegie-Mello University) и ISO/IEC 15504 (SPICE) “Software Engineering – +Process Assessment”. + +### Планирование в SCM (Planning for SCM) + +Планирование процесса конфигурационного управления для заданного проекта должно +согласовываться с организационным контекстом, соответствующими ограничениями, +общепринятыми рекомендациями, а также характеристиками и природой самого +проекта (например, его размером или значимостью). Основные работы, проводимые +при планировании SCM-деятельности включают: + +- Идентификацию программных конфигураций (Software Configuration +Identification) +- Контроль конфигураций (Software Configuration Control) +- Учет статусов конфигураций (Software Configuration Status Accounting) +- Аудит конфигураций (Software Configuration Auditing) +- Управление выпуском и поставкой (Software Release Management and Delivery) + +Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного управления, как организационные вопросы, обязанности, ресурсы и расписание, выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а также, контроль интерфейсов <взаимодействия программных модулей>. Результаты планирования сводятся в план конфигурационного управления (SCM Plan - SCMP), обычно, являющийся объектом оценки и аудита в рамках деятельности по обеспечению качества (SQA – Software Quality Assurance). + +#### Организация и обязанности (SCM organization and responsibilities) + +Для предотвращения путаницы в том, кто будет выполнять заданные работы и задачи конфигурационного управления, должны быть четко идентифицированы организации (организационные структуры), вовлеченные в SCM-процесс. Конкретные обязанности по выполнению заданных работ и задач SCM должны быть назначены соответствующим организационным сущностям. Также, должны быть идентифицированы общие полномочия и пути отчетности, даже если это выполняется в процессе планирования управления проектом или деятельности по обеспечению качества. + +#### Ресурсы и расписание (SCM resources and schedules) + +В процессе планирования конфигурационного управления идентифицируется персонал +и инструменты, привлекаемые для выполнения соответствующих работ и задач SCM. +Планирование касается вопросов определения расписания, устанавливая +последовательность задач конфигурационного управления и идентифицируя их связь +с расписанием проекта и его вехами, определенными на стадии планирования +проекта. Также должны быть специфицированы требования по обучению персонала, +необходимые для реализации планов. + +#### Выбор инструментов и реализация (Tool selection and implementation) + +SCM-деятельность поддерживается различными типами инструментальных средства и +процедур по их использованию. В зависимости от ситуации, эти инструменты могут +включать комбинацию различных возможностей – автоматизированные средства могут +решать отдельные задачи SCM, интегрированные средства могут обслуживать +потребности многих участников процесса программной инженерии (например, SCM, +разработку, проверку и аттестацию и т.п.). Значимость инструментальной +поддержки конфигурационного управления (как и других аспектов деятельности в +области программной инженерии) растет с каждым днем вместе со сложностью +внедрения, ростом размера проектов и сложности проектного окружения. +Возможности инструментальных средств развиваются для обеспечения поддержки: + +- SCM-библиотек (проектно-ориентированных баз знаний, прим. автора) +- Запросов на изменения (software change request - SCR) и процедур утверждения +(approval) +- Управления кодом (и связанных рабочих продуктов) и изменениями +- Отчетности по статусу конфигураций и сбору соответствующих метрических +показателей +- Аудиту конфигураций +- Управлению и отслеживанию <состояния и полноты> программной документации +- Выполнению задач по сборке программных продуктов и их модулей +- Управлению, контролю и поставке выпусков (релизов) программных продуктов + +Инструменты, используемые для обеспечения конфигурационного управления, могут +также предоставлять метрики, необходимые для совершенствования процессов. +SWEBOK обращает внимание (рекомендуя соответствующий первоисточник) на +следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and +Progress) и индикаторы качества – поток изменений (Change Traffic), +стабильность <конфигураций> (Stability), раздробленность (Breakage), +модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility), +среднее время между сбоями (MTBF – Mean Time Between Failures), +зрелость/полнота <информации> (Maturity). Отчетность по этим индикаторам может +быть организована различным образом, например, по элементам конфигураций или по +типу запросов на изменения. + +Рисунок 3 демонстрирует отображение инструментальных возможностей и процедур на +работы по конфигурационному управлению. + +![Рисунок 3. Характеристики SCM-инструментов и связанные процедуры. [SWEBOK, 2004, с.7-4, рис. 3]](images/configuration_management_3-tools_and_processes.jpg) + +В этом примере система управления кодом поддерживает программные библиотеки +контролируя доступ к элементам библиотек, координирует действия множества +пользователей и помогает в проведении рабочих процедур. Другие инструменты +поддерживают процесс сборки и выпуска программного обеспечения и документации +на основе программных элементов, содержащихся в библиотеках. Инструменты для +управления запросами на изменения программного обеспечения используются для +контролируемых <системой конфигурационного управления> программных элементов. +Другие инструменты могут обеспечивать управление базой данных и необходимыми +менеджменту отчетными средствами, а также деятельностью по разработке и +обеспечению качества. Как уже упоминалось выше, в рамках SCM-системы может быть +объединен целый ряд инструментов различных типов. При этом сама система +конфигурационного управления может быть тесно связана и поддерживать другие +виды работ, касающиеся не только SCM. + +В процессе планирования инженеры выбирают те SCM-средства, которые применимы +для решения стоящих перед ними задач. + +Вопрос выбора SCM-системы должен решаться исходя из целей, сформулированных в +отношении используемых процессов программной инженерии и уровня зрелости этих +процессов. Кроме того, необходимо учитывать и вопросы унификации программных +средств, используемых для поддержки инфраструктуры разработки и сопровождения +всего портфеля программных проектов, выполняемых в организации. В силу +фундаментальной значимости SCM-системы для обеспечения базовых процессов +программной инженерии и управления всеми проектными активами, принимать решение +об использовании той или иной SCM-системы для каждого отдельно взятого проекта +выглядит необоснованным. SCM-система, система управления требованиями (более +чем желательно, связанная с SCM), средства бизнес-моделирования и +проектирования, среды разработки – все это должно быть стандартизировано в +рамках организации, за исключением тех случаев, когда требования в отношении +тех или иных инструментальных средств сформулированы со стороны заказчика и +являются составной частью требований, предъявляемых к проекту. Возвращаясь к +вопросу выбора SCM-системы, безусловно, необходимо учитывать мнение инженеров, +однако, сложившиеся привычки не должны “перевешивать” функциональность +предлагаемых к унификации SCM-средств, обеспечиваемую ими доступность и +прозрачность информации о состоянии проекта в любой момент времени и, конечно, +возможность эффективного администрирования активов проекта, в том числе, в +контексте необходимых для этого трудозатрат. + +В процесс планирования рассматриваются аспекты, которые могут “всплыть” в +процессе внедрения (и, даже, на этапе эксплуатации) выбираемой системы +конфигурационного управления. В частности, обсуждаются и вопросы возможных +“культурных” изменений, если это необходимо (с точки зрения поставленных целей +– проекта и/или совершенствования процессов). Дополнительная информация, +затрагивающая SCM-инструментарий, представлена в области знаний SWEBOK +“Software Engineering Tools and Methods”. + +#### Контроль поставщиков/подрядчиков (Vendor/Subcontractor Control) + +Программные проекты могут требовать необходимости приобретать или использовать +уже приобретенное программное обеспечение – компиляторы и другие инструменты +(среды разработки, библиотеки компонент). Планирование должно касаться вопросов +– надо и, если надо, то как помещать эти инструменты (например, интегрируя в +программные библиотеки проекта) под управление SCM-системы и как их изменения и +обновления будут оцениваться и управляться. + +Аналогичные соображения существуют и в отношении программного обеспечения, +создаваемого подрядчиками. В этом случае, в отношении SCM-процесса подрядчика +предъявляются специальные требования со стороны заказчика и они вносятся в +контракт, предполагая не только возможность мониторинга, но и соответствие его +возможностей заданным требованиям. В последнее время все чаще отмечается +важность доступности SCM-информации для эффективного мониторинга соответствия +(compliance monitoring). + +#### Контроль интерфейсов (Interface Control) + +Когда программные элементы должны связываться с другими программными или +аппаратными элементами, изменения в одних элементах могут влиять на другие +элементы. Планирование SCM-процесса рассматривает, в частности, как будут +идентифицироваться связанные элементы и как будут управляться и сообщаться их +изменения. Конфигурационное управление может быть частью более масштабного +процесса системного уровня (т.е. в рамках всей системы, к которой относятся +соответствующие программные элементы) по определению и контролю интерфейсов, +включая описание в соответствующих спецификациях интерфейсов, планах контроля +интерфейсов и других документах. В этом случае, SCM-планирование контроля +интерфейсов проводится в контексте процесса системного уровня. + +### План конфигурационного управления (SCM Plan) + +Результаты SCM-планирования для заданного проекта определяются в плане +конфигурационного управления (Software Configuration Management Plan, SCMP), +который является документом, используемом в качестве описание SCM-процесса. Он +всегда поддерживается в актуальном состоянии (обновляясь и утверждаясь по мере +внесения в него необходимых изменений) на протяжении всего жизненного цикла. +При описании SCM-плана обычно необходимо разработать ряд детальных процедур, +определяющих как конкретные требования будут выполняться в повседневной +деятельности. + +Создание и сопровождение плана конфигурационного управления основывается на +информации, получаемой в процессе работ по планированию. Рекомендации по +созданию и сопровождению SCMP можно найти, например, в одном из ключевых +SCM-стандартов IEEE 828-98 “Standard for Software Configuration Management +Plans”. Этот стандарт описывает требования к информации, содержащейся в плане +конфигурационного управления, а также определяет шесть категорий +SCM-информации, содержащейся в плане (обычно, представленных в виде +соответствующих разделов, прим. автора): + +- Введение (Introduction) – описывает цели, содержание и используемые термины. +- Управление (SCM Management) – описывает структуру, обязанности, полномочия, +политики, директивы (указания, обязательные для исполнения) и процедуры. +- Работы (SCM Activities) – определяет идентификацию конфигураций, их контроль +и т.п. +- Расписание (SCM Schedule) – определяет связь работ по конфигурационному +управлению с другими аспектами и процессами проектной деятельности. +- Ресурсы (SCM Resources) – описывает инструменты, физические ресурсы, персонал +и т.п. +- Сопровождение плана (SCMP Maintenance) – определяет правила, по которым в +план вносятся изменения и описывает как эти изменения внедряются в повседневный +SCM-процесс. + +### Контроль выполнения SCM-процесса (Surveillance of Software Configuration Management) + +После того, как внедрен процесс конфигурационного управления, может быть +необходимо контролировать (проводить надзор) над SCM-процессом для обеспечения +того, что SCM-план исполняется надлежащим образом. В ряде случаев определяются +конкретные требования по обеспечению качества (SQA), контролирующие исполнение +процессов и процедур конфигурационного управления. Для этого может быть +необходимо введение соответствующих полномочий и назначение обязанностей по +контролю выполнения задач SCM. Аналогичные полномочия и обязанности по надзору +над SCM-процессом могут существовать в контексте SQA-деятельности. + +Использование интегрированных SCM-инструментов с возможностью контроля процесса +может сделать процедуру надзора более легкой и прозрачной. Некоторые +инструменты предоставляют высокий уровень настраиваемости для обеспечения +гибкой адаптации процессов. Другие инструменты являются менее гибкими, диктуя +те или иные процессы и их характеристики. Требования контроля (надзора), с +одной стороны, и уровень гибкости и адпатируемости, с другой, являются +определяющими критериями выбора того или иного инструмента. + +#### Метрики и процесс количественной оценки в SCM (SCM measures and measurement) + +Количественные показатели (метрики) могут определяться для обеспечения +информации о разрабатываемом продукте или для оценки исполнения самого процесса +конфигурационного управления. Связанной целью SCM-мониторинга может быть и +раскрытие возможностей по совершенствованию процесса (не только SCM-процесса, +но и других процессов программной инженерии). Количественная оценка +SCM-процессов предоставляет хорошие средства для мониторинга эффективности +деятельности по конфигурационному управлению на постоянной основе. Эти +измерения полезны для оценки текущего состояния процесса и проведения сравнений +во времени (как прогресса в отношении развития продукта, так и качества +выполнения процесса, как такового). Анализ измерений позволяет понять причины +изменения процесса и внести соответствующие коррективы в план конфигурационного +управления (SCMP). + +Программные библиотеки и различные возможности SCM-средств предоставляют +источники для получения информации о характеристиках SCM-процесса (наравне с +проектной информацией и данными, необходимыми для принятия тех или иных +управленческих решений). Например, информация о времени, необходимом для +выполнения различных типов изменений, может быть полезна для оценки критериев +того, какой уровень полномочий оптимален для утверждения определенных типов +изменений. + +Необходимо сохранять фокус на проведении анализа измерений и формировании +соответствующих выводов, вместо проведения “измерений ради измерений” (к +сожалению, последнее встречается слишком часто, чтобы не отметить этот факт). +Обсуждение количественных оценок в отношении процесса и продукта представлено в +области знаний “Процесс программной инженерии”. Программа проведения +количественных оценок обсуждается в области знаний “Управление программной +инженерией”. + +#### Аудит в рамках SCM (In-process* audits of SCM) + +Аудит может проводится на протяжении всего процесса программной инженерии для +определения текущего статуса заданных элементов конфигураций или оценки +реализации процесса конфигурационного управления. SCM-аудит предоставляет более +формальный механизм мониторинга выбранных аспектов процесса и может +координироваться с работами в области обеспечения качества (SQA; см. секцию “5. +Software Configuration Auditing”). + +* “in-process” подчеркивает непрерывность/периодичность аудита и его +позиционирование как неотъемлемой составной части конфигурационного управления. + +## Идентификация программных конфигураций (Software Configuration Identification) + +Работы по идентификации конфигураций программного обеспечения определяют +контролируемые элементы (items), устанавливают схемы идентификации для +элементов и их версий, а также задают инструменты и описывают техники, +используемые для управления этими элементами (включая их передачу под +управление SCM-процесса и системы). Данная деятельность является основой для +всех других работ по конфигурационному управлению. + +### Идентификация элементов, требующих контроля (Identifying Items to Be Controlled) + +Первый шаг в организации контроля изменений состоит в идентификации программных +элементов, которые необходимо контролировать в рамках SCM-процесса. Это +предполагает понимание программной конфигурации в контексте системной +конфигурации, выбор элементов программной конфигурации, разработку стратегии +отметки (labeling) программных элементов и описание связи между ними, а также +идентификацию базовых линий (baselines, это понятие будет обсуждаться позднее в +этой теме) вместе с процедурами включения элементов в базовую линию. + +#### Программная конфигурация (Software configuration) + +Программная конфигурация – набор функциональных и физических характеристик +программного обеспечения, сформулированная в документации или воплощенная в +продукте (см. IEEE 610.12-90, Standard Glossary for Software Engineering +Terminology). Программная конфигурация может рассматриваться как составная +часть общей системной конфигурации. + +#### Элемент конфигурации (Software configuration item) + +Элемент программной конфигурации (software configuration item, SCI) – фрагмент +программного обеспечения, вовлеченный в процесс конфигурационного управления +(и, возможно, помещенный под управление SCM-системы) и рассматриваемый как одна +(атомарная) сущность в рамках SCM-процесса (см. IEEE 610.12-90). SCM +контролирует множество различных элементов, включая не только программный код. +Программные элементы, потенциально полезные в качестве элементов программной +конфигурации (SCI), включают планы, спецификации и документы (например, +полученные в результате моделирования и проектирования), программные +инструменты, исходный и исполнимый код, библиотеки кода, данные и словари +данных, а также документацию по установке, сопровождению, эксплуатации и +использованию программного обеспечения. + +Выбор SCI является важным процессом, в рамках которого необходимо достигать +баланса между обеспечением адекватного уровня прозрачности представления +(дословно – “видимости”, visibility) в контексте контроля проекта. Правильный +выбор элементов конфигурации важен для обеспечения управляемого набора +контролируемых элементов. SWEBOK дает ссылку на источник, описывающий список +критериев по выбору элементов конфигураций. + +#### Связи между элементами конфигурации (Software configuration item relationships) + +Структурные связи между выбранными элементами конфигурации (и их составляющими) +влияют на другие SCM работы и задачи, например, сборку программного обеспечения +или анализ влияний (impact analysis) предлагаемых изменений. Надлежащее +отслеживание этих связей является важным для поддержания актуальной трассировки +(traceability) между активами проекта. Разработка схемы идентификации элементов +конфигураций (SCI) должна учитывать отображение между идентифицируемыми +элементами и структурой программного обеспечения, а также потребность в +поддержке эволюционирования программных элементов и их связей по мере развития +системы. + +#### Версия программного обеспечения (Software version) + +Программные элементы развиваются по мере выполнения проекта. Версия (version) +программного элемента – конкретно идентифицированный и специфицированный +элемент. Версия элемента может также рассматриваться в качестве определенного +состояния (state) эволюционирующего элемента. Обновление (revision) – новая +версия элемента, предназначенная для замены его старой версии. Вариант +(variant) – новая версия элемента, добавляемая в конфигурацию без замены старой +версии (то есть сосуществующая с другой версией того же элемента). + +#### Базовая линия, срез (Baseline) + +Базовая линия или <фиксированный> срез (baseline) программного обеспечения +–набор элементов программной конфигурации, формально определенный и +зафиксированный по времени в процессе жизненного цикла программного +обеспечения. Этот термин также иногда используется для указания конкретной +версии элемента конфигурации, если это согласовано заранее. В определенных +случаях, базовая линия может изменяться только через формальную процедуру +контроля изменений. Фиксированный срез в сочетании со всеми утвержденными +изменениями в отношении его представляет собой текущую утвержденную +конфигурацию. + +Хотя, упоминаемая в SWEBOK классификация базовых линий в определенной степени +является умозрительной и, безусловно, не единственно возможной, она полезна для +адаптации и выработки внутрикорпоративных стандартов, на основе которых, в +дальнейшем строятся соответствующие планы конфигурационного управления (SCMP). +Приведенную ниже классификацию, соответственно, стоит рассматривать лишь как +пример, но пример достаточно полезный для данного контекста обсуждения. + +В общем случае, используются следующие типы базовых линий – функциональные, +утвержденные, эволюционные или промежуточные, а также, базовые линии продукта. +Функциональный срез соответствует принятым программным требованиям. +Утвержденный срез соответствует принятым программным требованиям и требованиям +в отношении интерфейсов. Базовая линия продукта представляет собой срез +активов, относящихся к продукту, на заданный момент времени (при этом, базовая +линия продукта не всегда является его версией, готовой к выпуску, т.е. к +передаче в эксплуатацию). Полномочия по изменению заданной базовой линии обычно +находятся в ведении организационной структуры, отвечающей за разработку +программного обеспечения, но могут также разделяться и с другими +организационными структурами (например, отвечающей за конфигурационное +управление или тестирование). Базовая линия продукта соответствует завершенному +программному продукту, готовому для проведения работ по интеграции в рамках +целевой системы (system integration). Базовые линии, используемые для данного +проекта, вместе с ассоциированным уровнем полномочий, необходимым для +утверждения изменений, обычно идентифицируется в конфигурационном плане – SCMP. + +Здесь уместно провести параллель между вехами (milestone) проекта и базовыми +линиями. Выглядит вполне обоснованным отображение вех проекта на базовые линии, +как “выходы” (результаты) выполнения процессов проекта к моменту достижения +соответствующей проектной вехи. + +#### Включение элементов в программную конфигурацию (Acquiring software configuration items) + +Различные элементы программной конфигурации передаются под управление +SCM-процесса в различные моменты времени и включаются в базовые линии в +определенных точках жизненного цикла. Инициирующим событием является завершение +определенных форм формального утверждения задач, таких как формальная оценка +(review). Рисунок 4 характеризует развитие базовой линии в процессе жизненного +цикла. Этот рисунок базируется на каскадной (waterfall) модели только в целях +иллюстрации; нижние индексы используются для обозначения версий +эволюционирующих элементов. Запросы на изменения (software change requests, +SCR), присутствующие на рисунке, описываются в теме 3.1 “Requesting, +Evaluating, and Approving Software Changes”. + +![Рисунок 4. Включение элементов в конфигурацию. [SWEBOK, 2004, с.7-7, рис. 4]](images/configuration_management_4-elements.jpg) + +После включения элемента в конфигурацию в качестве SCI, изменения элементов +должны утверждаться формально, как связанные с соответствующими элементами +(SCI) и базовыми линиями, следуя плану конфигурационного управления (SCMP). +После утверждения <запроса на изменение и проведения работ по изменению>, +<измененный> элемент включается в конфигурацию, в соответствии с заданной +процедурой утверждения. + +### Программная библиотека (Software Library) + +Программная библиотека – контролируемая коллекция программных приложений и +связанной с ними документации, предназначенная для использования в процессе +разработки, эксплуатации и сопровождения программного обеспечения (см. IEEE +610.12-90). В качестве <элемента> программной библиотеки, также, может +рассматриваться инструментарий, используемый в работах по выпуску программного +обеспечения и передаче его в эксплуатацию (например, инсталляции). На практике +могут использоваться различные типы библиотек, каждая из которых соответствует +определенному уровню зрелости элементов программного обеспечения. Например, +“рабочая библиотека” (working library) может поддерживать работы по +кодированию, “библиотека поддержки проекта” (project support library) может +поддерживать тестирование, “мастер-библиотека” (master library) может +использоваться для завершенных продуктов (например, как вся совокупность +средств, используемых для разработки и/или выпуска продукта). С каждой +библиотекой ассоциирован соответствующий уровень контроля конфигурационного +управления, также ассоциированный с базовой линией и уровнем полномочий по +внесению изменений. Безопасность (в терминах контроля доступа и средств +резервного копирования) является одним из ключевых аспектов управления +библиотеками. SWEBOK отмечает, что существуют различные модели программных +библиотек, а также приводит соответствующие первоисточники по этой теме. + +Используемые для каждой библиотеки инструменты должны поддерживать контроль +SCM, необходимый для данной библиотеки, как в терминах управления элементами +конфигурации (SCI), так и с точки зрения контроля доступа к библиотеке. На +уровне рабочей библиотеки – это средства управления кодом, обслуживающие +разработчиков, специалистов по сопровождению и SCM-процесс/инструментарий +(например, среда разработки должна обеспечивать интеграцию с SCM-системой). В +данном контексте, рабочая библиотека фокусируется на управлении версиями +программных элементов (к которым, безусловно, относится не только код, но и +запросы на изменения, включая сообщения об обнаруженных дефектах, и т.п.) в +многопользовательской среде. На более высоком уровне контроля, доступ ограничен +сильнее и SCM (процесс и/или система) является основным пользователем +<библиотеки> (например, для осуществления автоматической сборки продукта по +расписанию). + +Все эти библиотеки также являются важным источником информации для +количественной оценки работ, их результата и прогресса <в развитии программных +элементов>. + +## Контроль программных конфигураций (Software Configuration Control) + +Контроль программных конфигураций касается вопросов управления изменениями в +течение жизненного цикла программного обеспечения. Он включает процесс +определения того, какие именно изменения должны быть сделаны, какие полномочия +необходимы для утверждения определенных <типов> изменений, в чем состоит +поддержка реализации этих изменений, а также концепцию формального утверждения +отклонений от проектных требований, также как и отказа от внесения изменений. +Получаемая в результате этого информация полезна для количественной оценки +потока изменений, нарушения целостности <системы> и аспектов “переработки” в +проекте (в большинстве случаев, по времени, стоимости и усилиям - +трудозатратам). + +### Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving Software Changes) + +Первый шаг по управлению изменениями контролируемых элементов состоит в +определении того, какие именно изменения надо производить. Процесс обработки +запросов на изменения (software change request process), представленный на +рисунке 5, включает формальные процедуры по предложению (submitting) и записи +(recording) запросов на изменения, оценки потенциальной стоимости и влияния +предлагаемых изменений, а также принятию, модификации или отказу от внесенных +предложений по изменениям. Запросы на изменения элементов программных +конфигураций могут вноситься любым лицом в любой точке жизненного цикла и может +включать предлагаемые решения и соответствующий уровень приоритетности. Один из +источников запросов на изменения состоит в инициировании корректирующих +действий в ответ на сообщения о проблемах (problem reports). Вне зависимости от +источника запроса, в самом запросе на изменение (software change request, SCR) +обычно записывается информация о его типе (например, “дефект” или “заявка на +расширение функциональных возможностей”/”пожелание” – enhancement/suggestion). + +![Рисунок 5. Поток процесса контроля изменений. [SWEBOK, 2004, с.7-7, рис. 5]](images/configuration_management_5-changes.jpg) + +Такой подход обеспечивает возможность отслеживания дефектов и сбора метрических +показателей о деятельности по обработке и внесению изменений, с группировкой по +типу изменений. Как только получен запрос на изменение (SCR), производится +техническая оценка (включающая, а иногда и называемая анализом влияний – impact +analysis) запрашиваемых изменений для определения масштабов модификаций, +необходимых для удовлетворения параметров запрашиваемых изменений (достаточно +часто, в результате такого анализа формулируются соответствующие требования, +определяющие содержание необходимых работ). Четкое понимание связей между +программными (и, возможно, аппаратными) элементами системы является важной +составной частью данной задачи. Наконец, органы, обладающие полномочиями, +соответствующими затрагиваемой базовой линии, элементам программной +конфигурации и природе изменений, должны оценить технические и управленческие +(организационные) аспекты внесения запрашиваемых изменений, а также принять, +модифицировать, отклонить или отложить предлагаемые изменения. + +#### Совет по конфигурационному контролю (Software Configuration Control Board) + +Полномочия по принятию или отклонению предлагаемых изменений обычно возлагаются +на <организационную> сущность, называемую совет по конфигурационному контролю - +Configuration Control Board (чаще звучит как совет по координации изменений - +Change Control Board, CCB). В небольших проектах такие полномочия могут, в +действительности, принадлежать лидеру или одному назначенному лицу из числа +членов проектной команды. В общем случае может существовать несколько уровней +полномочий в части принятия решений в отношении изменений, в зависимости от +различных критериев, таких как критичность предлагаемых изменений, их +приоритет, природа изменений (например, параметры бюджета или расписания) или +текущая точка жизненного цикла. Решения о том, кто именно будет включен в CCB +для данной системы (проекта) могут варьироваться, в зависимости от данных +критериев. Однако, в CCB всегда должно присутствовать лицо, вовлеченное в +организацию конфигурационного управления. В CCB входят все заинтересованные +лица, чья роль соответствует уровню CCB. Когда содержание полномочий CCB +охватывает только аспекты программного обеспечения, такой совет называется +Software Configuration (Change) Control Board – SCCB. Деятельность CCB обычно +является объектом аудита качества или оценки. + +Учитывая роль управления изменениями в конфигурационном управлении и реальные задачи CCB, более обоснованным выглядит использование именно названия Change Coordination & Control Board – в общем случае звучащий как совет по координации и контролю изменений. + +#### Процесс обработки запросов на изменения (Software change request process) + +Эффективный процесс <обработки> запросов на изменения (SCR process) требует +использования соответствующих средств поддержки и процедур <для данного вида +деятельности>, от “бумажных” форм и документированных процедур (как +последовательности действий или сценариев) до программных инструментов, +позволяющих отсылать запросы на изменения, выполнять процесс обработки таких +запросов (изменять их статус, комментировать, детализировать и т.п.), +фиксировать решения, принятые CCB, а также генерировать отчетную информацию по +процессу обработки запросов на изменения. Связь между этими средствами и +инструментами обработки отчетов об ошибках может существенно облегчить +определение решений для обнаруженных проблем. + +Обработка различных типов запросов на изменения в отношении разрабатываемых или +модифицируемых программных систем, будь то сообщения о проблемах (defect +report) или запросы на расширение функциональности (enhancement request), даже +при разных процессах принятия решений в отношении их, должны быть объединены в +единую систему (в единой базой данных), являющуюся составной и неотъемлемой +частью единой среды конфигурационного управления. Только в этом случае можно +обеспечить однозначную и актуальную связь между запросами различных типов и +другими активами проекта (кодом, документацией, проектными моделями, задачами, +ресурсами и т.п.), что позволяет не только получать актуальную информацию в +любой момент времени, но и оперативно принимать те или иные (в том числе, +управленческие) решения в отношении проекта, основываясь на максимально полном +и корректном объеме информации. + +SWEBOK отмечает, что описания процессов и соответствующих форм (например, формы +сообщения о проблеме) можно найти в большом количестве внешних источников, в +частности, указанных непосредственно в библиографии SWEBOK. + +### Реализация изменений (Implementing Software Changes) + +Принятые (утвержденные) запросы на изменения (SCR) реализуются используя +определенные процедуры, в соответствии с подходящими требованиями в отношении +расписания. Если набор утвержденных запросов на изменения может выполняться +одновременно, необходимо обеспечить отслеживание того, какие именно SCR +реализованы в конкретной версии программного продукта и базовой линии +<конфигурации>. Составной частью процесса “закрытия” изменения (по аналогии с +closure - “закрытием”, то есть завершением проекта), является аудит(ы) +конфигурации(й) и верификация качества программного обеспечения. Это +обеспечивает гарантию того, что были внесены только утвержденные изменения. +Описанный выше процесс обработки запросов на изменения обычно включает +документирование всей информации, связанной с принятым изменением. + +Фактическая реализация изменений поддерживается инструментальными средствами +соответствующей программной библиотеки (см. выше 2.2 “Программная библиотека”), +обеспечивающими управление версиями и поддержку <единого> репозитория кода. Как +минимум, эти инструменты должны поддерживать операции chek-in/check-out +(помещение в репозиторий/ получение из репозитория) и ассоциированные +возможности по контролю версий (например, отметка версии – labeling, сравнение +– compare/diff, слияние – merge и т.п.). Более мощные инструменты могут +поддерживать параллельную разработку (parallel development) и среду +географически распределенной разработки (geographically distributed +environment). Эти инструменты могут объявляться (в рамках организации) как +отдельные специализированные приложения, целиком находящиеся под контролем +независимой SCM-группы (как самостоятельной/выделенной организационной +сущности). Наконец, они могут быть столь элементарными, что включают только +упрощенный контроль версий, например, на уровне файловой системы операционной +среды. + +Безусловно, существует широкий спектр, обоснованных функциональных возможностей +инструментальных средств, используемых для решения различных задач +конфигурационного управления. При этом, при выборе соответствующего инструмента +или комплекса инструментов, необходимо точно понимать их функциональную +нагрузку, уровень интегрируемости, возможности по адаптации с учетом конкретных +процессов жизненного цикла в проектной команде или организации, в целом. Только +с учетом этих критериев и других ограничений можно сформировать оптимальное и +эффективное решение по программному обеспечению SCM-процесса в том объеме, +который обоснован в каждом конкретном случае. + +### Отклонения и отказ от изменений (Deviations and Waivers) + +Ограничения, накладываемые на усилия, прилагаемые к выполнению определенных +работ <программной инженерии>, как и спецификации, созданные в процессе +разработки, могут содержать условия, которые не могут быть удовлетворены в +заданной точке жизненного цикла. Отклонение (deviation) - утверждение +изменений, внесенных относительно предварительно сформулированных условий к +разработке тех или иных аспектов разработки заданных элементов. Отказ (waiver) +– утверждение дальнейшего использования элемента, которое отличается в той или +иной степени от предварительно заданных условий. В обоих случаях используются +формальные процессы (точнее, процедуры) для получения одобрения на отклонение +или отказ от предопределенных ранее условий. + +В большинстве случаев, говорят об отклонении от требований (изменении +реализации требований с одновременной их корректировкой) и отказе от выполнения +запросов на изменения (или отклонении запросов). Как вы уже обратили внимание, +использование слова “отклонение” сильно зависит от контекста, подразумевая, в +первом случае, определенную корректировку условий и работ и, во втором случае, +полный отказ от внесения изменений с утверждением и обоснованием такого отказа. + +## Учет статусов конфигураций (Software Configuration Status Accounting) + +Учет статусов программных конфигураций (Software Configuration Status Accounting, SCSA) подразумевает сохранение (recording) и генерацию отчетности (reporting) для всей информации, необходимой для эффективного управления конфигурациями программного обеспечения. + +### Информация о статусе конфигураций (Software Configuration Status Information) + +Деятельность по учету статуса конфигураций (SCSA) предназначена и выполняется +для получения (и генерации отчетов) информации, необходимой для осуществления +процессов жизненного цикла системы. Как и в любой информационной системе, +информация о статусе конфигураций должна идентифицироваться, собираться и +поддерживаться <в актуальном состоянии> по мере эволюции этих конфигураций. +Различная информация и количественные показатели необходимы для поддержки +процесса конфигурационного управления, а также для генерации отчетности (о +статусе конфигураций), необходимой для управления, выполнения процессов +программной инженерии и других связанных видов деятельности. Типы доступной +информации обычно включают идентификацию утвержденных конфигураций, наравне с +идентификацией и текущим статусом реализации изменений, отклонений и отказов от +изменений. SWEBOK дает ссылки на источники, содержащие возможные (частные) +списки важных информационных элементов. + +Современные инструментальные средства SCM должны включать определенные формы +поддержки сбора и данных и подготовки SCSA-отчетности. Это может быть +реализовано на уровне обращения к соответствующим базам данных, может быть +представлено и в виде самостоятельных приложений, а также являться +функциональной составляющей более крупных интегрированных инструментальных +средств. + +Логично, что только такие интегрированные многофункциональные средства возможно +считать полноценными SCM-инструментами, образующими категорию систем +конфигурационного управления. В противном случае, мы говорим лишь об отдельно +взятых (пусть и взаимодействующих, в той или иной степени) инструментах - +“системе управления заявками на изменения” (change request submission), +“системе сообщения и отслеживания дефектов” (defect-tracking), “системе +контроля версий” (version control), “системе генерации отчетности” +(configuration reporting) и т.п. + +#### Отчетность по статусу конфигураций (Software Configuration Status Reporting) + +Отчетная информация может быть использована различными организационными +единицами или проектными группами, включая команду разработки, команду +сопровождения, управляющих проектами и персоналом, обеспечивающим проверку +качества. Отчетность может предоставляться в специальной форме, следуя +специфическим запросам, но может генерироваться на постоянной основе (с +определенной периодичностью) в соответствии с заданными шаблонами. Определенные +элементы информации, получаемой в процессе деятельности по учету статуса +конфигураций, может становиться составной частью данных, необходимых и +используемых в работах по обеспечению качества (как продуктов, так и +процессов). + +В дополнение к отчетности по текущему статусу конфигураций, информация, +получаемая в процессе SCSA-деятельности, может использоваться как основа для +проведения различных количественных оценок в интересах менеджмента, разработки +или конфигурационного управления. Например, к такого рода данным относятся: +количество запросов на изменения на один конфигурационный элемент; среднее +время, необходимое для реализации запрошенных изменений <заданного типа>. + +## Аудит конфигураций (Software Configuration Auditing) + +Аудит программного обеспечения – деятельность, выполняемая для независимой +оценки программных продуктов и процессов на <формальное> соответствие +(conformance) применимым в данном случае инструкциям, стандартам, руководящим +документам, планам и процедурам (см. IEEE 1028-97 “Standard for Software +Reviews”). Аудиты проводятся в <строгом> соответствии с четко определенными +процессами, содержащими и определяющими различные роли аудиторов и из +обязанности. Каждый аудит должен быть, в свою очередь, четко спланирован и +может требовать привлечения многих специалистов для выполнения различных задач +(определяемых процедурой аудита) за достаточно короткий промежуток времени. +Автоматизированные средства, обеспечивающие поддержку планирования и проведения +аудита, могут существенно облегчить и ускорить этот процесс. SWEBOK отмечает, +что рекомендации по проведению аудита можно найти во многих источниках, в том +числе, включая стандарт IEEE 1028-97 “Standard for Software Reviews”. + +Деятельность по аудиту программных конфигураций определяет степень, в которой +элемент <конфигурации> (SCI) удовлетворяет заданным (например, на уровне +требований и/или запросов на изменения) функциональным и физическим +характеристикам. Неформальный аудит такого типа может быть связан с ключевыми +точками жизненного цикла (вехами проекта, в терминах управления проектами - +milestones). Существует два достаточно распространенных типа формального +аудита (требуемого определенными категориями контрактов, например, на создание +критически-важного программного обеспечения): функциональный аудит конфигураций +(Functional Configuration Audit, FCA) и физический аудит конфигураций (Physical +Configuration Audit, PCA). Успешное (в терминах соответствия результатов +заданным условиям) завершение этих аудитов может быть обязательным требованиям +для фиксирования базовой линии продукта. В то же время, если сравнивать +контекст FCA и PCA для программного и аппаратного обеспечения, перед их +выполнением необходимо четко оценивать реальные потребности в таких видах +аудита (так как они требуют существенных, иногда, просто “неподъемных” затратах +ресурсов, если оценивать их в рамках заданных ограничений проекта). + +### Функциональный аудит программных конфигураций (Software Functional Configuration Audit) + +Цель FCA состоит в том, чтобы убедиться, что контролируемый программный элемент +полностью соответствует заданным спецификациям. “Выход”, то есть результат +проверки и аттестации (V&V, verification and validation) программного +обеспечения является ключевым “входом” (исходными данными) для проведения этого +аудита. + +### Физический аудит программных конфигураций (Software Physical Configuration Audit) + +Цель PCA состоит в том, чтобы убедиться, что дизайн и документация точно +согласуются с самим программным продуктом. + +### Внутренние аудиты базовых линий (In-process Audits of Software Baseline) + +Как уже упоминалось выше, аудиты могут выполняться на протяжении всего процесса +разработки для получения текущего статуса заданных элементов конфигураций. В +данном случае, аудит может проводиться в отношении к выборочным элементам +базовых линий с тем, чтобы убедиться, что соблюдаются заданные спецификациями +характеристики процесса, скорости и качества развития продукта, а также того, +что документация соответствует и поддерживается в согласованном состоянии с +документируемыми элементами продукта в процессе их эволюционирования/на +протяжении жизненного цикла. + +## Управление выпуском и поставкой (Software Release Management and Delivery) + +Термин “релиз” (release, выпуск) используется в данном контексте, подразумевая +распространение <и использование> элементов конфигураций за рамками работ по +разработке программного обеспечения. Это может включать как внутренние релизы, +так и выпуск и передачу программного обеспечения заказчикам. В ситуациях, когда +доступны для поставки различные версии программных элементов (в частности, +различные версии для разных платформ или редакции с различным набором +функциональных возможностей), часто бывает необходимо создавать +специализированные версии и пакеты (сборки) соответствующих материалов +(элементов, активов) для выпуска в качестве <самостоятельной> версии. +Программная библиотека (предоставляющая соответствующий инструментарий для +такой сборки) играет ключевую роль в выполнении таких работ. + +### Сборка программного обеспечения (Software Building) + +Сборка (building) программного обеспечения – деятельность по комбинированию +корректных версий элементов программных конфигураций, проводимая с +использованием соответствующих конфигурационных данных, с целью получения +исполняемой программы (программной системы) для передачи заказчику и/или другим +получателям (например, выполняющим работы по тестированию). Исполняемая +программа для аппаратных и программно-аппаратных систем получается в результате +деятельности по системной сборке (system building). Инструкции по сборке +предоставляют описание необходимых для сборки шагов, представленных в заданной +(корректной) последовательности. Работы по сборке программного обеспечения +выполняются не только для получения нового релиза, но и для повторного создания +предыдущих релизов в целях их восстановления, тестирования, сопровождения или +каких-либо других необходимых действий. + +Программное обеспечение собирается с использованием заданных версий таких +средств поддержки (supporting tools), как компиляторы. В ряде случаев может +требоваться повторная сборка точной копии ранее собранного элемента +конфигурации. В этом случае, средства поддержки и ассоциированные инструкции по +сборке должны находиться под контролем SCM (подразумевая, в зависимости от +контекста, в определенных ситуациях, SCM-систему или только процесс) для +обеспечения доступности корректной версии инструментария. + +Часто бывают полезны возможности инструментов, позволяющие выбирать корректные +для заданного окружения версии программных элементов, а также обеспечивать +автоматизацию процесса сборки (например, по расписанию) программного +обеспечения на основы выбранных версий и соответствующих конфигурационных +данных. Такие возможности инструментов особенно необходимы для крупных проектов +с параллельной разработкой и/или распределенной средой разработки +(географически распределенной команды разработки). Большинство программных +средств, обеспечивающих инфраструктуру разработки поддерживают такую +возможность (или, как минимум, декларируют ее). Эти инструменты сильно +отличаются (по степени комплексности предоставляемого функционала и) по своей +сложности, требуя в ряде случаев изучения специализированного (специфичного для +конкретного инструмента) языка сценариев, или предоставляя графические +возможности, скрывающие сложность настройки “интеллектуальных” средств сборки +программного обеспечения. + +Процесс и результаты сборки могут быть необходимы для последующего +использования <в других процессах, работах и проектах> и часто являются +объектом верификации (проверки) в рамках деятельности по обеспечению качества +(SQA). + +### Управление выпуском программного обеспечения (Software Release Management) + +Управление выпуском (release management) программного обеспечения охватывает +идентификацию, упаковку (сборку) и передачу элементов продукта, например, +исполняемых программ, документации, аннотацию релиза (release note) и +конфигурационные данные. Понимая, что изменения в продукте происходят +постоянно, одной из задач управления выпуском продукта является определение +момента времени, когда именно выпускать продукт (в этом контексте, управление +выпуском может быть тесно связано как с деятельностью по обеспечению качества, +так и с маркетинговыми соображениями в отношении выпускаемого продукта). На это +решение также влияет серьезность проблем, решению которых адресуется релиз, и +количественная оценка плотности сбоев (fault densities) в предыдущих релизах. +Задача упаковки (packaging) состоит в идентификации того, какие элементы +продукта должны быть выпущены (например, на основании функциональных требований +и их трассировки на элементы конфигурации), и в последующем выборе корректных +вариантов этих элементов, задаваемом аспектами применения продукта. +Документирование информации о физическом содержании релиза, обычно, включают в +документ описания версии (version description document). В свою очередь, +аннотация релиза (release note) содержит информацию о новых возможностях, +известных проблемах, а также требованиях к платформе(ам), которые необходимо +соблюдать для предусмотренного режима эксплуатации продукта. Подготовленный к +выпуску пакет (package) также включает инструкции по установке и обновлению +<предыдущей версии>. Создание такой инструкции может быть осложнено тем, что +некоторые текущие пользователи могут иметь устаревшие версии, более ранние, чем +предыдущий выпущенный релиз. Наконец, в ряде случаев, деятельность по +управлению выпуском может требовать отслеживание распространения (поставки) +продукта различным заказчикам или в рамках заданных целевых систем. Например, +возможны ситуации, когда поставщику требуется уведомить заказчика об +обнаруженных проблемах. + +Для поддержки таких функций управления выпуском могут требоваться +соответствующие возможности инструментария поддержки (средств поддержки или +“вспомогательных средств”, если, например, попытаться максимально приблизиться +к русскоязычной терминологии ГОСТ 12207). Также полезна и связь с +инструментальными возможностями поддержки процесса обработки запросов на +изменения для отображения содержимого релиза на полученные запросы на изменения +(SCR - software change request, включая сообщения об обнаруженных ранее и +исправленных в данном релизе ошибках, прим. автора). Эти инструментальные +средства <поддержки управления выпуском продуктов> также могут поддерживать +информацию о различных целевых платформах и <операционном> окружении, +используемом у заказчиков. blob - 265b3cbf3b7f5e91d0bb6f6eb87f1f75aaa43b00 (mode 644) blob + /dev/null --- 7_software_engineering_management.markdown +++ /dev/null @@ -1,873 +0,0 @@ -# Управление программной инженерией - -Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - -SWEBOK. - -Содержит перевод описания области знаний SWEBOK “Software Engineering -Management”, с замечаниями и комментариями. - -Управление программной инженерией (Software Engineering Management) - -Управление программной инженерией может быть определено как приложение вопросов -управления (management activities) – планирования, координации, количественной -оценки, мониторинга, контроля и отчетности – к инженерной деятельности для -систематического, упорядоченного и количественно измеряемого обеспечения -разработки и сопровождения программных систем (IEEE 610.12-90, Standard -Glossary for Software Engineering Terminology). - -Таким образом, область знаний “Управление программной инженерией” определяет -аспекты управления и количественной оценки в программной инженерии. Измерения -являются важным аспектом для всех областей знаний SWEBOK и соответствующая тема -также включена и в описании данной области знаний. - -В принципе, корректно утверждать, что возможно управлять программной инженерией -так же, как и любым другим комплексным процессом. В то же время, существуют -аспекты, специфичные для программных продуктов, а процессы жизненного цикла -программных систем, в какой-то мере, усложняют достижение необходимого уровня -эффективности управления. Среди таких усложняющих факторов: - -- Восприятие клиентов (потребителей, заказчиков) таково, что часто отсутствует -с их стороны понимание сложности, порожденной самой природой программной -инженерии, в частности связанной с влиянием изменяющихся требований. -- Практически неизбежно изменение или появление новых клиентских требований, -как следствие функционирования процессов программной инженерии. -- В результате, программные системы часто строятся с применением итеративных -процессов, вместо последовательного выполнения и закрытия работ (задач). -- Уровень новизны и сложности программных систем часто крайне высок (и не -позволяет в полной мере применять уже существующие наработки и опыт). - -Применяемые технологии обладают высокой скоростью изменения, обновления и -устаревания - -Что касается программной инженерии, управленческая деятельность в этой области -происходит на трех уровнях: - -- Организационное управление и управление инфраструктурой -- Управление проектами -- Планирование и контроль программ количественной оценки - -Последние два уровня описаны в данной области знаний, что никак не принижает -значимости общих вопросов управления организационными аспектами и -инфраструктурой. - -Хотя все области знаний тесно связаны с другими дисциплинами, связь данной -области знаний с общими вопросами менеджмента особенно важны, что и будет более -подробно, в отличие от других областей знаний, представлено в ниже. Вопросы -организационного менеджмента важны с точки зрения влияния на программную -инженерию, например, в контексте управления политиками/полномочиями сотрудников -или других внутрикорпоративных стандартов, в рамках которых выполняется любая -деятельность (например, с точки зрения отчетности по занятости сотрудников), в -том числе - инженерная. Такие политики подвержены влиянию со стороны требований -к организации эффективного процесса разработки и сопровождения и, на практике, -бывает необходимо адаптировать общие и создать специальные для инженерной -деятельности внутренние организационные стандарты, обеспечивающие эффективное -управление программной инженерией. Эти политики являются основой для решения -долгосрочных задач улучшения процессов и повышения производительности труда -специалистов, вовлеченных в работы по созданию и сопровождению программного -обеспечения. - -Другим важным аспектом управления является управление персоналом через политики -и процедуры найма и приема на работу, обучения, и мотивации специалистов, -помощи в развитии навыков для дальнейшего карьерного роста (mentoring in career -development). Все это требует внимания не только в контексте проекта, но в -рамках всей организации. Для инженеров-программистов особо важными, в -частности, являются вопросы обучения и индивидуального внимания менеджмента. В -большой степени это связано с постоянно развивающимеся технологиями и -потребностью в обновлении и расширении знаний для эффективного решения -поставленных задач. Часто не придают необходимого внимания вопросам -коммуникаций между сотрудниками. На самом деле управление коммуникациями, -создание естественных условий (в agile-практиках им придается особое внимание) -для их развития – один из ключевых элементов повышения не только продуктивности -команд разработки и сопровождения, но и, например, точности получаемых от -пользователей требований и запросов на изменения, то есть любой информации, -которая передается между людьми и значима для успешного решения поставленных -задач. Наконец, управление портфелями (проектов разработки и работ по -сопровождению) позволяет сформировать и развивать общее видение в отношении -всех существующих, обновляемых и создаваемых программных активов на уровне -ИТ-подразделения и в организации, в целом. Все это, в конечном счете, -обеспечивает и более эффективное управление ресурсами, а, значит, и возможность -интенсивного, а не экстенсивного развития организации, в которой инновации -начинают играть одну из ключевых ролей. - -Вместе с осознанием специфики управленческой деятельности в приложении к -программной инженерии, ИТ-специалистам необходимо понимать и ключевые аспекты -общего менеджмента и управления проектами. - -Организационная культура, нормы поведения, аспекты корпоративного управления в -вопросах приобретения и поставки, управления цепочками поставок (supply chain -management), маркетинг, продажи, партнерства и т.п. – все это влияет, хотя и -неявно, на организационные процессы программной инженерии. - -В отношении данной области знаний особо уместно подчеркнуть значимость вопросов -управления проектами (project management), так как “конструирование имеющих -ценность программных артефактов” (к которым относятся требования, модели, -документация, тесты и т.п.) обычно ведется в форме проектов или программ -проектов. Принимая это во внимание, создатели SWEBOK особо отмечают связь -данной области знаний c обсуждавшимся уже в этой книге Руководством к Своду -Знаний по Управлению Проектами PMBOK (A Guide to the Project Management Body of -Knowledge. PMBOK® Guide). В контексте управления программной инженерией следует -понимать важность соответствующих областей знаний PMBOK: - -- Управление интеграцией проекта (project integration management) -- Управление содержанием проекта (project scope management) -- Управление сроками проекта (project time management) -- Управление стоимостью проекта (project cost management) -- Управление качеством проекта (project quality management) -- Управление человеческими ресурсами проекта (project human resource management) -- Управление коммуникациями проекта (project communication management) - -Наравне с ними, с точки зрения автора, необходимо уделять не меньшее внимание и -другим областям знаний управления проектами: - -- Управление рисками проекта (project risk management) -- Управление поставками проекта (project procurement management) - -SWEBOK отмечает, что, несомненно, области знаний управления проектами имеют -непосредственное влияние на решение вопросов управления инженерной -деятельностью в области программного обеспечения. Не имеет смысла, да и просто -невозможно дублировать в SWEBOK содержание PMBOK. Вместо этого, PMBOK -рассматривается как ключевой источник информации и знаний по управлению -проектами, настоятельно рекомендуемый всем лицам, в той или иной степени -вовлеченных в управленческую деятельность в программных проектах. Таким -образом, естественно, что управление проектами можно найти в области знаний -SWEBOK “Связанные дисциплины” (Related Disciplines). - -Данная область знаний состоит из пяти секций, посвященных процессам управления -программной инженерией и еще одной секции, касающейся вопросов измерений и -количественных оценок в управлении. Хотя эти два аспекта (управление и -измерения) часто рассматриваются отдельно и, в самом деле, обладают многими -уникальными аспектами, их тесная взаимосвязь играет важную роль в этой области -знаний. К сожалению, сложилось, во многих случаях, обоснованное [Chaos, 2004] -восприятие индустрии программного обеспечения как недостаточно зрелой, в силу -частых срывов сроков, превышения бюджетных ограничений, недостаточного качества -продуктов, неопределенной функциональности и других причин. Управление, -ориентированное на измерения, как один из основных принципов любой инженерной -деятельности, может серьезно помочь в изменении сложившейся неблагоприятной -ситуации и формировании положительного восприятия программной индустрии -потребителями (пользователями и заказчиками). По-сути, управление без -измерений, количественных или качественных, приводит к отсутствию прогресса в -достижении целей, а измерения без управления – к потере контекста и целей. -Однако, в то же время, управление и измерения без необходимого и достаточного -уровня знаний становится неэффективным и, часто, превращается в самоцель (что -приводит, по мнению автора к излишней бюрократизации и неадекватной -загруженности ресурсов). Таким образом, управленческая деятельность, в общем -плане (включая количественные и качественные оценки), должна проводиться -сбалансировано с другими аспектами программной инженерии, не превращая Software -Engineering Management (SEM) в дорогостоящую, но бесполезную работу. -Эффективный менеджмент требует комбинации соответствующих систематических и -упорядоченных подходов в управлении и соответствующего опыта[^13]. - -[^13]: Например, на практике практически невозможно добиться статуса PMP – Project -Management Professional по версии Project Management Institute (PMI), если -претендент не обладает серьезным практическим опыт управления проектами и -пытается сдать соответствующий экзамен только на основе штудирования PMBOK и -теоретических “изысканий”. - -Прежде, чем детализировать данную область знаний, необходимо дать рабочие -определения для понятий “процесс управления” и “измерения”: - -- Процесс управления (Management process) описывает действия (работы - -activities), предпринимаемые для обеспечения того, что процессы программной -иженерии выполняются в согласовании с политиками, целями и стандартами, -принятыми в организации -- Измерения (Measurement) связаны с определением величин и характеристикой -различных аспектов программной инженерии (продуктов, процессов и т.п.), а также -разработкой на их основе моделей[^14] с использованием статистических -методов (и данных), экспертных знаний и других техник. - -[^14]: В данном контексте, SWEBOK видимо подразумевает, что полученные модели -используются для идентификации и анализа рисков, планирования и -совершенствования процессов программной инженерии (процессов жизненного цикла, -включая процессы сопровождения), а также процесса управления. - -Секции (подобласти) данной области знаний, связанные с управлением программной -инженерией, тесно связаны с секций измерений (количественной оценки). - -Вполне естественно, что данная область знаний тесно связана с другими областями -знаний SWEBOK и ее необходимо рассматривать в контексте других областей знаний. -Стоит особо отметить следующие аспекты применения других областей знаний в -управлении программной инженерией и, особо, в управлении программными -проектами: - -- Требования к программному обеспечению (Software Requirements) – -соответствующие действия по работе с требованиями (в первую очередь, их -определение) указанной области знаний должны выполняться в фазе инициирования -(Initiation) и определения содержания (Scope Definition) программных проектов. -- Конфигурационное управление (Software Configuration Management) – связано с -идентификацией, контролем, учетом статуса (активов проекта, включая запросы на -изменения, прим. автора) и аудитом конфигураций (в терминах конфигурационного -управления) в сочетании с управлением релизами (release management) и -развертыванием программных систем. -- Процесс программной инженерии (Software Engineering Process) – процессы и -продукты тесно связаны; указанная область знаний включает аспекты измерений -продуктов и процессов. -- Качество (Software Quality) – качество является одной из постоянных целей -управления и большого комплекса соответствующих работ, которыми необходимо -управлять. - -Данная область знаний рассматривает управление программной инженерий в терминах -организационного процесса, включающего управление процессами и проектами. -Структурная декомпозиция этой области знаний основывается и на определении -соответствующих тем и на рассмотрении жизненного цикла. При этом, основной -отправной точкой дальнейшей детализации является процесс управления -программными проектами (в оригинале SWEBOK в данной области знаний активно -используется термин software engineering project). Таким образом, структура -декомпозиции управления программной инженерией включает шесть основных секций -(подобластей), из которых первые пять, в основном, следуют стандарту IEEE -(ISO/IEC, ГОСТ) 12207 в части “Процесса управления” (Management Process). Вот -эти шесть секций данной области знаний: - -- Инициирование и определение содержания (Initiation and scope definition) – -касается принятия решения о начале программного проекта -- Планирование программного проекта (Software project planning) – относится к -работам, предпринимаемым для подготовки к успешному ведению -программно-инженерной деятельности с точки зрения управления -- Выполнение программного проекта (Software project enactment) – касается -общепринятых (general accepted) действий по управлению программной инженерией в -процессе проведения соответствующих инженерных работ -- Обзор и оценка (Review and evaluation) – относится к работам по проверке -того, что получаемый программный продукт отвечает заданным целям, требованиям, -ограничениям и т.п. -- Закрытие <проекта> (Closure) – относится к фиксированию результатов -программного проекта после передачи полученного программного продукта в -эксплуатацию. -- Измерения в программной инженерии (Software engineering measurement) – -касается разработки и реализации программ по измерению (ведению количественной -оценки) в организациях (в общем смысле, т.е. группах, подразделениях, компаниях -и т.п.), занимающихся инженерной деятельностью в области программного -обеспечения. - -![Рисунок 1. Область знаний “Управление программной инженерией” [SWEBOK, 2004, с.8-2, рис. 1]](images/management_small.jpg) - -Здесь нельзя не сделать замечание, связанное со структурированием этой области -знаний. Обсуждаемая область знаний, действительно, тесно связана с дисциплиной -управления проектами. Более того, речь идет о приложении управления проектами к -программной инженерии. В этом контексте кажется уместным сопоставить -предлагаемый в SWEBOK цикл “Initiation & scope definition – Planning – -Enactment – Review & evaluation – Closure” с процессными группами PMBOK -“Initiation – Planning – Execution – Monitoring & Controlling – Closing”. Как -мы видим, в PMBOK роль работ SWEBOK “Обзор и оценка” (Review and evaluation) -играют действия по мониторингу и контролю процессов - “Monitoring & Controlling -Processes”. Таким образом, с учетом реального содержания секции “Software -project enactment”, ее название и переведено автором как “Выполнение -программного проекта”, хотя “enactment” в большей степени подразумевает -формальный “запуск” работ. Конечно, перевод мог звучать и как “исполнение” -(например, следуя PMBOK), однако, такой перевод, по мнению автора, все же несет -слишком формальный оттенок, что, субъективно, не соответствует ряду -методологических подходов (в первую очередь agile) и культурных “ограничений”. - -## Инициирование и определение содержания (Initiation and Scope Definition) - -Данная секция фокусируется на наборе действий, связанных с эффективным -определением требований к программному обеспечению с использованием различных -методов извлечения требований, а также оценкой осуществимости проекта с -различных точек зрения. Если проект признан осуществимым, следующей задачей -является специфицирование процедур проверки и изменения требований (см. область -знаний “Требования к программному обеспечению” – Software Requirements). - -### Определение и обсуждение требований (Determination and Negotiation of Requirements) - -– выбор и применение методов определения (извлечения), анализа (например, -моделирования сценариев use case), специфицирования и проверки (например, -прототипирования) требований, принимая во внимание позицию различных -заинтересованных лиц. Это является первичными работами, необходимыми для -определения содержания, целей и ограничений проекта. Данные работы важны -всегда, так как позволяют определить четкие границы задач, необходимых для -выполнения, в частности, это особенно заметно для проектов, обладающих большой -степенью “новизны” (идет ли речь о технологических аспектах проекта, его -масштабах, методах и т.п.). - -### Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. (Feasibility Analysis. Technical, Operational, Financial, Social/Political.) - -Инженеры должны убедиться в том, что для успешного завершения проекта (в -заданные сроки, в рамках бюджета и т.п.) доступны необходимые возможности -(capabilities) и ресурсы, будь то люди (те или иные специалисты), экспертиза -(опыт, знания, навыки), средства (например, инструментарий), инфраструктура и -поддержка (как внутренняя, так и внешняя, например, со стороны старших -менеджеров организационной структуры, отвечающей за разработку, и ключевых -менеджеров или других заинтересованных лиц со стороны “заказчика”). Это часто -требует хотя бы приблизительной оценки усилий и стоимости с использованием -соответствующих методов (например, техники, в которой экспертная оценка -базируется на аналогиях). - -### Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements) - -Учитывая неизбежность изменений, жизненно важно определить и согласовать с -заинтересованными лицами процедуры (например, в контексте деятельности по -управлению изменениями) в рамках которых будут проводиться оценка и пересмотр -требований. Это однозначно предполагает, что требования не будут неизменны, но -могут и должны корректироваться в соответствии с заданными и детализированными -процессами (например, design review – оценка дизайна). Если изменения приняты, -необходимо проводить анализ зависимостей (traceability analysis) и рисков (см. -далее тему 2.5 “Управление рисками” – Risk Management) для оценки влияния -рассматриваемых изменений. Такой анализ необходимо проводить, в общем случае, и -при рассмотрении “изменения” для принятия решения о передачи его “в работу” или -отклонении (например, в силу обоснованных причин, таких как проектные решения, -позволяющих отметить его как реализуемое в следующей версии), и уже более -детально, если изменение требования(ий) решено реализовать (в силу, например, -контрактных обязательств со стороны исполнителя) и необходимо определить, как -именно такое изменение повлияет на существующую систему и какие работы -необходимо выполнить, чтобы удовлетворить обновленному(ым) требованиям. SWEBOK -отмечает, что управление изменениями полезно и при оценке результатов проекта -(программного продукта, программной системы), так как содержание и требования -формируют основу оценки успешности проекта. (см. также секцию “Контроль -конфигураций” области знаний Software Configuration Management). - -## Планирование программного проекта (Software Project Planning) - -Процесс планирования является итеративным[^15] и базируется на -содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить, -что различные фазы проекта перекрываются (что, например, специально отмечает -PMBOK) и вместе с определением содержания, детализацией требований и -проведением анализа осуществимости, параллельно с этим сам разрабатываемый план -проекта в той или иной степени детализируется и формируется определенный -комплекс работ, оцениваются необходимые ресурсы и временные границы работ, и -т.п. SWEBOK, основываясь на такой позиции, говорит, что при планировании также -оцениваются и отбираются соответствующие процессы жизненного цикла. Там где это -уместно, проект детализируется в виде структурной декомпозиции работ, для -которых отмечены ассоциируемых с их завершением результаты и их характеристики. -Такие характеристики, обычно, связаны с вопросами качества и другими -установленными атрибутами требований, соблюдением сроков выполнения работ, -усилиями, стоимостью и т.д. Ресурсы распределяются по задачам таким образом, -чтобы обеспечить оптимальную продуктивность (на персональном, командном и -организационном уровне), использование средств (инфраструктуры, -инструментов,...) и оборудования, а также строгое соблюдение проектного -расписания. Также должно проводится управление рисками и, в частности, -необходимо определить “профиль рисков”, принятый соответствующими -заинтересованными лицами. Как составная часть планирования, необходимо -определить необходимые процессы обеспечения качества в форме соответствующих -процедур и обязанностей (responsibilities) по оценке, проверке, аттестации и -аудиту качества (см. область знаний “Качество программного обеспечения” – -Software Quality). Безусловно, что должны быть определены процессы и -обязанности в части управления планом проекта, его оценкой и порядка пересмотра -различных аспектов проекта. - -[^15]: Позднее, при обсуждении жизненного цикла и, в частности, спиральной модели -разработки, мы будем рассматривать ключевые идеи итеративного подхода. - -### Планирование процесса (Process Planning) - -С учетом содержания и требований конкретного проекта необходимо выбрать, -адаптировать и использовать соответствующую модель процессов жизненного цикла -(например, спиральную, с эволюционным прототипированием). Также должны быть -выбраны методы и инструменты. На уровне проекта, методы и инструменты -используются для декомпозиции проекта в виде набора задач (tasks), с -ассоциированными входами, выходами и условиями завершения (completion), -например, в форме структуры декомпозиции работ – WBS (work breakdown -structure). Это влияет на высокоуровневое (первичное) определение проектного -расписания и организационной структуры <проектной команды>. - -### Определение результатов (Determine Deliverables) - -Должен быть определен результат выполнения каждой задачи (например, описание -архитектуры, отчет по анализу, набор тестов и т.п.), то есть какие -активы/артефакты мы должны получить по выполнении соответствующей задачи -проекта. При этом оцениваются возможности повторного использования программных -компонент, созданных ранее, в процессе разработки других программных продуктов, -и потенциал применения готовых к использованию компонент из 3-их источников. -Должно быть определено, какие именно компоненты будут использоваться и как они -будут получены (через каких поставщиков). - -Такие компоненты, обычно, называют “off-the-shelf”, подразумевая в настоящее -время не только коммерческое, но и общедоступное программное обеспечения, если -его использование обосновано в рамках данного проекта. Анализ и выбор -соответствующих компонент может и, в подавляющем большинстве случаев, должен -рассматриваться как самостоятельная задача процесса планирования в контексте -сформулированных высокоуровневых требований, определенного содержания и базовых -ограничений проекта, таких как сроки, ресурсы, стоимость). Это позволяет четко -разделить, в том числе, в контексте затрат, что именно будет разрабатываться -самостоятельно (может быть как отдельный “подпроект”), что будет использоваться -из 3-их источников (3rd party), а что будет являться содержательным (с точки -зрения проекта) результатом работ, то есть его непосредственным активом, -обладающим, например, функциональной, для данного проекта, нагрузкой. - -### Оценка усилий, расписания и стоимостных ожиданий (Efforts, Schedule and Cost Estimation) - -Ожидаемые пределы усилий, необходимых для решения каждой задачи (task) проекта -основываются на разбиении задач, их входах и выходах. Для этого используется -калиброванная (calibrated - настроенная для заданных условий) модель ожиданий -(estimation model), базирующаяся на исторических данных по усилиям, связанным с -объемом задачи (size-effort historical data, часто определяется как -человеко-месяцы к функциональным точкам или количеству строк кода). Также, для -оценки усилий могут применяться и другие методы, например, экспертная оценка -или оценка по типу приложения (встроенное, телекоммуникационное), квалификации -проектной группы и т.п. - -Кроме того, необходимо идентифицировать связи и зависимости между задачами -(tasks dependencies) и потенциально критические аспекты (bottlenecks) проекта. -Такие работы могут быть проведены с использованием, например, метода анализ -критического пути (critical path analysis – достаточно распространенный метод, -относящийся к общей дисциплине управления проектами, применимый и для проектов -программных систем). Если возможно, критические аспекты должны быть разрешены, -а для задач определены ожидаемые сроки выполнения (расписание), включающие -начало, длительность и окончание (например, в форме PERT-диаграмм*). - -* PERT анализ (Program, Evaluation, and Review Technique) – техника оценки -ожиданий в отношении длительности (duration) задач проекта, проводимая на -основе определения среднего весового значения трех оценок длительности - -пессимистической, оптимистической и ожидаемой (то есть наиболее вероятной, при -первичной оценке). Аналогичная техника может и часто используется для оценки -усилий (effort), необходимых для реализации задачи. Наибольший эффект дает -сочетание различных методов оценки. В то же самое время, чем больше методов -оценки используется, тем более трудоемкой (а, следовательно, и ресурсоемкой) -становится такая работа, поэтому задача менеджмента – определить наиболее -оптимальный и эффективный для данного проекта набор методов и техник, -используемых в процессе планирования и корректировки. -Требования к ресурсам (люди, инструменты) транслируются в стоимостные ожидания. - -В совокупности, вся эта деятельность является итеративной и должна обсуждаться -и проводиться до тех пор, пока не будет достигнут консенсус между -соответствующими заинтересованными лицами – в первую очередь, менеджментом -<проекта> и инженерами <входящими в команду проекта>. - -### Распределение ресурсов (Resource Allocation) - -С задачами (для которых назначены сроки), должны быть ассоциированы -оборудование, средства и, конечно, люди. Это подразумевает распределение -(назначение или принятие, в зависимости от стиля и формы управления) -обязанностей/ответственности. Для этого может, например, использоваться -диаграмма Ганта (Gantt chart). Эта деятельность определяется и ограничивается -доступностью ресурсов, их оптимальным использованием в заданном контексте и -вопросами, связанными с персоналом (например, продуктивностью конкретных лиц и -группы, в целом, организационной и командной структурой, подразумевая специфику -коллектива, наравне со штатным расписанием и другие вопросы). - -Крайне необходимо выделить как самостоятельную тему данной секции вопросы -управления персоналом – people management, уделив особое внимание аспектам -экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в -проектной команде. К этой же теме, также стоит отнести вопросы обучения, -прохождения тренингов специалистами проектной команды. Наконец, к теме ресурсов -имеет непосредственное отношение и определение необходимости и объема -привлечения внешних консультантов (не являющихся сотрудниками ни исполнителя, -ни заказчика), к сожалению, не упоминаемое здесь в SWEBOK, но крайне важное, по -опыту автора, для успешности проекта, обладающего высокой степенью новизны -(например, в терминах используемых технологий и, особенно, применения тех или -иных архитектурных решений). - -### Управление рисками (Risk Management) - -В части управления рисками должны проводиться: - -- идентификация и анализ рисков - что, когда и почему может быть сделано -неверно и к чему это может привести; -- оценка критических рисков - какие из рисков наиболее значительны (если им не -уделять должного внимания) и что необходимо сделать, чтобы их избежать; -- смягчение рисков (risk mitigation) и планируемость непредвиденных -обстоятельств (contingency planning) – формирование стратегии, касающейся -рисков и управление профилями рисков. - -Для идентификации и оценки рисков необходимо применять соответствующие методы и -техники (например, построение дерева решений – decision tree или моделирование -процессов – process simulation). Кроме того, со всеми заинтересованными лицами -необходимо определить правила и политики прекращения проекта. - -Наравне с идеями общего управления рисками, важно понимать и управлять рисками, -уникальными для деятельности в области программной инженерии, например, -тенденция добавлять в получаемый программный продукт функциональные и другие -возможности, неопределенные на уровне требований или риски, заложенные в самой -природе программного обеспечения, связанные, в первую очередь с его сложностью -и архитектурно-технологической новизной, присутствующей, в той или иной -степени, в любом программном проекте. - -### Управление качеством (Quality Management) - -Качество определяется в терминах атрибутов, значимых для данного конкретного -проекта и/или ассоциированного с ним продукта. Атрибуты могут выражаться как -качественно, так и количественно. Эти характеристики качества определяются в -спецификации требований к программному обеспечению (см. область знаний -“Требования к программному обеспечению” – Software Requirements). - -Отправной точкой для соблюдения качества является набор индикаторов, -соответствующих ожиданиям заинтересованных лиц. На этой стадии (как мы помним, -речь идет о планировании проекта) также специфицируются процедуры, связанные с -проведением SQA-деятельности (деятельности по обеспечению качества – software -quality assurance) на протяжении всех процессов жизненного цикла и для проверки -и аттестации (V&V – verification and validation) для получаемого продукта и -всех активов (артефактов) проекта (см. область знаний “Качество программного -обеспечения” – Software Quality). - -### Управление планом проекта (Plan Management) - -Наравне с другими аспектами ведения проекта, должно быть определено как проект -будет управляться и как будет управляться план проекта. Отчетность, мониторинг -и контроль проекта должны соответствовать выбранному процессу программной -инженерии и сущности проекта, отражая также в виде различных артефактов именно -то, что будет использоваться в процессе управления. При этом, в изменяющемся -окружении принципиально важно, чтобы и сам план проекта был управляем. Это -требует строгого соблюдения планов, которые должны быть систематически -направляемы, контролируемы, оцениваемы, по которым будет вестись отчетность и, -там где это применимо, корректируемы. Планы, ассоциированные с другими -процессами поддержки, ориентированными на управление, также должны быть -управляемы соответствующим образом (например, это касается вопросов -документирования, конфигурационного управления и разрешения проблем). - -## Выполнение программного проекта (Software Project Enactment) - -План проекта реализуется за счет выполнения процессов, представленных в плане. -Следование плану на протяжении выполнения проекта связано с ожиданиями, что -соблюдение <корректно составленного> плана приводит к успешному удовлетворению -требований заинтересованных лиц и достижению целей проекта. Основой для -успешного выполнения проекта является управленческая деятельность по ведению -оценки и измерений, мониторинга, контроля и отчетности. - -### Реализация планов[^16] (Implementation of Plans) - -Проект инициируется и проектные работы выполняются в соответствии с планом. В -процессе выполнения используются соответствующие ресурсы (например, усилия -персонала, бюджет) и производятся необходимые результаты (deliverables; активы, -артефакты проекта – например, архитектурные документы, тестовые сценарии). - -[^16]: В SWEBOK используется как “план проекта” в единственном числе, так и “планы” -– во множественном числе, подразумевающие, судя по контексту, отдельные задачи -проекта. - -### Управление контрактами с поставщиками (Supplier Contract Management) - -Включает подготовку и выполнение соглашений с поставщиками, мониторинг -деятельности поставщиков, принятие у поставщиков продуктов, использование и -интеграцию этих продуктов в рамках проектных работ. - -### Реализация процесса по ведению измерений (Implementation of Measurement Process) - -Данный процесс выполняется на протяжении всего проекта, обеспечивая сбор всех -необходимых данных (см. 6.2 Plan the Measurement Process и 6.3 Perform the -Measurement Process). - -### Процесс мониторинга (Monitor Process) - -Соблюдение плана проверяется постоянно и через предопределенные интервалы -времени. Анализируются выходы (outputs) и условия завершения <задач>. -Получаемые <в процессе измерений> результаты оцениваются в терминах требуемых -характеристик (например, через процедуры обзора/оценки и аудита – review, -audit). Затраты усилий (efforts), соблюдения расписания, стоимость к данному -моменту, используемые ресурсы – все это исследуется к каждой дате оценки. При -этом, оценивается и корректируется профиль рисков, а также, производится -проверка удовлетворения требований качества. - -Моделируются и анализируются данные измерений. Анализ расхождений (variance -analysis) <плана с реальным выполнением проекта> базируется на оценке -отклонений реальных данных от планируемых и ожидаемых. Такой анализ может -проводиться в отношении оценки перерасхода средств (cost overrun), нарушения -расписания и других важных характеристик – ограничений проекта Часто -выполняется “внешний” (например, с привлечением представителей заказчика) -анализ качества и других измеряемых данных (например, анализ плотности дефектов -– defect density analysis). Проводится повторное (уточняющее) выявление рисков -и оценка их последствий (risk exposure and leverage), разрабатывается дерево -решений, проводится моделирование (рисков и действий по их предотвращению) и -другие работы – уже в контексте полученных данных. Все эти работы позволяют -обнаруживать проблемы и идентифицировать исключения, основываясь на выходе за -рамки приемлемых границ тех или иных параметров проекта (в частности, -характеристик качества). Отчетность по результатам создается в соответствие с -планом, а также, при выходе за заданные ограничения проекта или параметров -отдельных его работ. - -Хотелось бы обратить внимание на то, что современная практика управления -проектами, в частности, разработки и сопровождения программного обеспечения, -требует обеспечения возможности доступна к актуальным данным по проекту в любой -момент времени. По-сути в настоящее время возникает целый класс интегрированных -инструментов и специализированных продуктов, часто называемый project dashboard -(наиболее близкий перевод этого понятия на русский язык может звучать как -“панель управления проектом”). Обычно, такие инструменты не только работают со -“снимками” данных, сводя их воедино, но обращаются непосредственно к данным в -системах конфигурационного управления, управления требованиями, сценариями -тестирования, аудита кода, расписания проекта в соответствующих средствах -управления проектами и т.п. - -### Процесс контроля (Control Process) - -Выходы (результаты) процесса мониторинга обеспечивают базис, на основе которого -принимаются те или иные решения. Изменения в проект вносятся там, где это -необходимо, и где ассоциированные риски и их влияние смоделированы и могут быть -управляемы (контролируемы). Эти изменения могут проводиться в форме -корректирующих действий (например, повторного тестирования определенных -компонент) и могут приводить к изменению плана, работ, документов и других -активов проекта. При этом, важно контролировать (идентифицировать, оценивать и -принимать решения) прямые и косвенные влияния любых изменений. - -В некоторых случаях, это может приводит к прекращению проекта. Во всех случаях -необходимо проводить контроль изменений и процедур конфигурационного управления -(см. предыдущую область знаний Software Configuration Management). При этом, -решения должны документироваться и сообщаться (желательно, перед этим -обсуждаться) всем заинтересованным сторонам, планы – корректироваться (там где -это необходимо), а все необходимые данные должны заноситься в центральную базу -данных проекта (см. тему 6.3 Perform the Measurement Process). - -### Ведение отчетности (Reporting) - -Отчеты проводятся за определенный и согласованный период времени, согласуясь с -планом проекта и адресуясь заинтересованным лицам (в том числе – “внешним”, со -стороны заказчика). В принципе, возможны выделить две группы отчетов – по -общему состоянию проекта (именно, они обычно адресованы и заказчику), а также -детализированные отчеты, подготавливаемые чаще и касающиеся отдельных групп в -команде проекта, отдельных работ, групп требований, функциональных модулей и -т.п. - -## Обзор и оценка (Review and Evaluation) - -В критических точках проекта оценивается общий (по всему проекту) прогресс в -достижении установленных целей и удовлетворении требований заинтересованных -лиц. Аналогично, проводится оценка (assessment) эффективности процессов, -<работы> персонала, а также инструментов и методов, использованных в работах, -проведенных за заданный промежуток времени. - -### Определение удовлетворения требованиям (Determining Satisfaction of Requirements) - -Так как достижение удовлетворения пользователей является одной из наших -принципиальных целей, представляется важным периодическая и формальная оценка -прогресса в данном вопросе. Такая оценка проводится при достижении определенных -вех (milestones) проекта, например, при утверждении разработанной архитектуры). -При этом идентифицируются отклонения от соответствующих ожиданий (планов) и -проводятся необходимые действия, связанные с результатами оценки отклонений -(например, действия по корректировке плана). Как было отмечено выше (см. тему -3.5 “Процесс контроля”), во всех случаях проводится контроль изменений и -процедуры конфигурационного управления, документируются принятые решения и -обеспечивается необходимая отчетность. Дополнительную информацию, также имеющую -отношение к обсуждаемому вопросу, можно найти в области знаний “Тестирование -программного обеспечения” (Software Testing) в темах 2.2 “Цели тестирования” -(Objectivies of Testing) и 2.3 “Оценка и аудит” (Reviews and Audits). - -### Оценка продуктивности/результативности (Reviewing and Evaluation Performance) - -Периодическая оценка продуктивности специалистов, вовлеченных в проект, -обеспечивает понимание того, насколько они следуют плану, и дает возможность -идентифицировать вероятные проблемы (например, конфликты между членами -проектной команды). Для оценки эффективности применяются различные методы, -инструменты и техники. Сам процесс оценки является систематическим, а процедуры -– периодическими. Все это зависит от используемых управленческих техник, -применяемых методологий, организационных принципов, сложившейся культуры, то -есть рассматривается, в том числе, в контексте специфики программной инженерии, -дисциплины управления проектами и общего менеджмента. - -## Закрытие (Closure) - -Проект закрывается/завершается (не путайте с прекращением проекта), когда все -планы и процессы выполнены и завершены. На этой стадии по результатам проекта -применяются критерии оценки его успешности. Когда принимается решение о -закрытии проекта, выполняются действия по архивированию проектных данных, -анализу результатов, полученных в процессе работы над проектом (post mortem -analysis), и улучшению процессов (process improvement). - -### Определение <критериев> закрытия проекта (Determining Closure) - -Проект закрывается, когда завершены специфицированные в плане проекта задачи и -подтверждено <удовлетворительное> достижение критериев завершения (completion -criteria) проекта. При этом, все запланированные результаты (продукт, его -модули и т.п.) должны быть переданы заказчику и/или в эксплуатацию с -приемлемыми (с точки зрения требований) и принятыми (со стороны заказчика) -характеристиками. Удовлетворение требованиям – проверено и -подтверждено/утверждено заказчиком, а цели проекта – достигнуты. Перечисленные -процессы, в общем случае, требуют вовлечения всех заинтересованных лиц. -Результаты их выполнения документируются, включая подтверждения со стороны -заказчика о соответствии результатов проекта заданным требованиям (client -acceptance list, например, по результатам приемочных, или, как их еще называют, -приемо-сдаточных тестов) и, если это необходимо, включая также отчеты об -оставшихся/требующих доработки проблемах (known problems). - -### Работы по закрытию проекта (Closure Activities) - -После того, как принято и утверждено решение о закрытии проекта (также говорят -о “подтверждении закрытия/завершения проекта”) создается архив материалов в -соответствии с утвержденными заинтересованными лицами методами, -местоположением, формой и заданной длительностью хранения. База данных -измерений <в организации> обновляется в соответствии с полученными финальными -данными проекта и проводится пост-проектный анализ этих данных. Анализ по -завершении проекта помогает в оптимизации процессов, практик и организационной -структуры (см. область знаний Software Engineering Process). - -## Измерения в программной инженерии (Software Engineering Measurement) - -Важность и роль количественных оценок - измерений - в управленческих практиках -широко известна, растет с каждым годом и уже не раз подчеркивалась в SWEBOK. -Эффективные измерения становятся одним из краеугольных камней организационной -зрелости. - -Ключевые термины и методы по измерениям в программной инженерии определены в -стандарте ISO/IEC 15939:2002 Software Engineering - Software Measurement -Process (2002 г.), основывающемся на международном словаре метрологии, -выпущенном ISO в 1993 году. Несмотря на это, в различной литературе встречаются -разные термины, например, часто термин “metric” – метрика (на русском языке -выглядит предпочитительным использовать именно этот термин) используется вместо -“measure” – измерение. - -Данная тема следует указанному международному стандарту ISO/IEC 15939, который -описывает процесс, определяющий действия/работы (activities) и задачи (tasks)*, -необходимые для реализации процесса ведения измерений, а также включающий -информационную модель измерений. - -* “действия/работы” - activities, “задачи” – tasks: термин “задача” -используется для более глубокого уровня детализации, чем “действия/работы”; -термины “действия” и “работы”, как вы уже заметили, часто используются -взаимозаменяемым образом. Так или иначе, это вопрос договоренности о -терминологии при организации WBS (Work Breakdown Structure) – структуры -декомпозиции работ. - -### Установление и поддержка процесса ведения измерений (Establish and Sustain Measurement Commitment) - -- Формулируются требования в отношении измерений. Каждая попытка измерения -должна руководствоваться организационными целями и следовать набору измерений, -выполняемых в отношении требований, в соответствии с принятыми организационными -или проектными стандартами. Например, в качестве организационной цели может -выступать “выпуск на рынок новых продуктов первыми”. Это, в свою очередь, может -порождать требование того, что факторы, способствующие достижению цели также -должны быть оценены количественно, с тем, чтобы проект могу быть управляем в -процессе достижения заданного результата. Для этого необходимо: - - - Определить содержание измерений. Необходимость принять, в каких масштабах – -на уровне какой организационной единицы* будут проводиться измерения – только в -одной функциональной области, в рамках проекта, на уровне комплекса проектов -или в организации, в целом. Все последующие задачи по ведению измерений, -связанные с соответствующими требованиями, ведутся в рамках принятого -содержания измерений. Безусловно, в дополнение к этому необходимо -идентифицировать всех заинтересованных лиц, ассоциированных и вовлеченных в -проведение измерений. - - - Заручиться поддержкой менеджеров и персонала в ведении измерений. Такая -поддержка должна быть оформлена формально, сообщена персоналу и поддержана -соответствующими ресурсами (см. ниже). - -* организационная единица - organizational unit: этот термин хоть и не очень -удачен в SWEBOK, но будет использоваться достаточно часто в контексте ведения -измерений для описания границ измерений. При этом часто подразумевается не -фиксированная структурная единица в организации, а некая "единица -деятельности", в отношении которой проводятся измерения – операция, задача, -работа, проект, программа, деятельность организации, в целом. - -- Выделяются соответствующие ресурсы для проведения измерений. Организационная -поддержка измерений является основным фактором успеха, так как назначение -ресурсов просто необходимо для реализации процесса ведения измерений. -Назначение ресурсов включает распределение ответственности (например, -пользователь, аналитик и т.п.) в отношении различных задач процесса измерения и -предоставление необходимого финансирования, обучения, инструментов и поддержки -процесса сопровождения на постоянной основе. - -### Планирование процесса измерений (Plan the Measurement Process) - -- Задание “организационной единицы” (в частности, в понимании “единицы -деятельности”, как описывалось выше). Таким образом обеспечивается явный -контекст измерений и связанные с ним ограничения. В качестве такой “единицы” (в -общем случае) могут выступать организационные процессы, прикладные домены -(области деятельности или отдельных работ) и т.п. См. подробное описание -характеристик организационной единицы в уже упомянутом стандарте ISO 15939-02 -(ISO/IEC 15939:2002 Software Engineering - Software Measurement Process, раздел -5.2.1). -- Идентификация информационных потребностей <в отношении результатов -измерений>. Такие потребности, обычно, базируются на целях, ограничениях, -рисках и проблемах на уровне заданной организационной единицы. В основе -указанных аспектов лежат различные цели – организационные, проектные и т.п. Все -эти аспекты (как и порождающие их цели) должны быть четко идентифицированы и -для них должны быть определены соответствующие приоритеты. Затем, должно быть -выбрано подмножество аспектов, в отношении которых будут проводиться измерения, -и полученные результаты также должны быть документированы, персонал поставлен в -известность о них, а заинтересованным лицам необходимо провести требуемую -оценку аспектов измерений (см. стандарт ISO 15939-02, раздел 5.2.2). -- Выбор метрик (измерений). Кандидаты в метрики должны быть выбраны на основе -приоритетов информационных потребностей и других критериев – таких, как -стоимость сбора данных, возможность срыва процессных работ при сборе данных -(например, в силу недостатка ресурсов), легкость анализа, легкость получения -точных и целостных данных и т.п. (см. стандарт ISO 15939-02, раздел 5.2.3 и -приложение C). -- Определение наборов <собираемых> данных, а также процедур анализа и ведения -отчетности. Это включает в себя коллекцию процедур и расписаний, хранение, -проверку, анализ, отчетность и конфигурационное управление собираемыми данными. -(см. стандарт ISO 15939-02, раздел 5.2.4). -- Определение критериев оценки информационных продуктов (т.е. результатов -измерений). На критерии оценки влияют технические и бизнес цели, -сформулированные прежде для соответствующей организационной единицы. Результаты -измерений* ассоциированы с создаваемым продуктом <являющемся целью проекта>, а -также с процессами, обеспечивающими управление и измерения в проекте. (см. -стандарт ISO 15939-02, раздел 5.2.5 и приложения D, E). -* в данной теме в отношении результатов измерений часто используется термин -“информационный продукт” – information product. -- Оценка, утверждение и предоставление ресурсов для проведения измерений. - - План измерений должен быть оценен и утвержден соответствующими -заинтересованными лицами. Это включает процедуры сбора данных, их хранения, -анализа и отчетности; критерии оценки; расписание и распределение -ответственности. Критерии обзора и оценки этих артефактов должны быть -установлены на уровне организационной единицы или выше. Такие критерии должны -принимать во внимание существующий опыт, доступность ресурсов и потенциальный -срыв проекта когда предлагается изменение существующих практик. Утверждение -(approval) <выделения ресурсов> демонстрирует поддержку и принятие обязательств -по проведению измерений. (см. стандарт ISO 15939-02, раздел 5.2.6.1 и -приложение F). - - Ресурсы должны быть доступны для реализации запланированных и утвержденных -задач по ведению измерений. Доступность ресурсов может быть распределена по -стадиям внедрения изменений в процесс измерений, например, когда изменения -производятся изначально в “пилотном” режиме, а уже затем, становятся составной -частью стандартного процесса (т.е. используемого в рамках всего проекта, -подразделения или организации). Также, необходимо уделять внимание ресурсам, -необходимым для успешного внедрения новых процедур и измерений (метрик). (см. -стандарт ISO 15939-02, раздел 5.2.6.2). -- Овладевание и внедрение технологий поддержки <измерений>. Это включает оценку -доступных технологий, выбор наиболее соответствующих (заданному контексту и -ограничениям) технологий, их приобретение и овладевание ими и, наконец, -внедрение в повседневную практику. (см. стандарт ISO 15939-02, раздел 5.2.7). - -### Выполнение процесса измерений (Perform the Measurement Process) - -- Интеграция процедур проведения измерений с соответствующими процессами. -Процедуры измерения (например, сбор данных) должны быть интегрированы в -оцениваемые процессы. Это может приводить к изменению самих процессов для -адаптации действий по сбору или генерации необходимых данных. Это может -подразумевать и анализ существующих процессов для минимизации дополнительных -усилий, и оценку влияния на сотрудников, необходимые для реального принятия -процедур проведения измерений. Важно понимать и принимать во внимание моральные -и другие аспекты “человеческого фактора”, без которых проведение измерений, как -дополнительная (к функциональной) деятельность будет восприниматься лишь как -помеха основной работе. Более того, процедуры измерений должны обсуждаться с -теми, кто непосредственно предоставляет данные; может потребоваться -соответствующее обучение персонала; необходимо обеспечить и соответствующую -поддержку (по аналогии с технической поддержкой программного обеспечения). -Анализ данных и процедуры отчетности должны быть интегрированы в -организационные и/или проектные процессы. (см. стандарт ISO 15939-02, раздел -5.3.1). -- Сбор данных. Данные должны собираться, верифицироваться и сохраняться <для -дальнейшего использования>. (см. стандарт ISO 15939-02, раздел 5.3.2). -- Анализ данных и создание информационного продукта (как результата измерений, -позволяющего принимать на его основе те или иные решения). Данные могут -агрегироваться, трансформироваться или записываться как часть процесса анализа -в соответствии с природой данных и информационными потребностями. Обычно -результаты анализа представляются в форме соответствующих графиков, численных -характеристик или других индикаторов, интерпретируемых и передаваемых, в конце -концов, заинтересованным лицам. Результаты и сделанные на их основе заключения -должны быть оценены (reviewed) в соответствии с процессом, определенным в -организации (который может быть формальным или неформальным). Лица, -предоставляющие данные и проводящие измерения, должны участвовать в процессе -обзора и оценки (review) данных для обеспечения соответствия их содержательной -стороны и точности, а также выполнения действий, обоснованных результатами -последующего анализа. (см. стандарт ISO 15939-02, раздел 5.3.3 и приложение G). -- Обсуждение результатов. Полученный “информационный продукт” должен быть -документирован и передан пользователям и заинтересованным лицам. (см. стандарт -ISO 15939-02, раздел 5.3.4). - -### Оценка измерений (Evaluate Measurement) - -- Оценка информационного продукта. Такая оценка проводится на соответствие -специфицированным критериям оценки и определяет сильные и слабые стороны -(strengths and weaknesses*) полученного информационного продукта. Оценка может -проводиться в рамках внутренних процессов или внешнего аудита и должна включать -анализ отзывов от лиц, использующих полученные результаты. Сделанные выводы (в -англоязычных источниках по оценке и совершенствованию процессов повсеместно -используется термин “lessons learned” – “полученные уроки”) должны быть -записаны в соответствующую базу данных (иногда называемую также “базой знаний” -– “knowledgebase”). (см. стандарт ISO 15939-02, раздел 5.4.1 и приложение D). -* strengths and weaknesses – два из четырех элементов SWOT-анализа. SWOT - -Strengths, Weaknesses, Opportunities, Threats – сильные стороны, слабые -стороны, возможности, угрозы. Обычно представляется как квадрант четырех -указанных факторов. -- Оценка процесса проведения измерений. Данная оценка проводится на -соответствие специфицированным критериям оценки и определяет сильные и слабые -стороны самого процесса. Оценка может проводиться в рамках внутренних процессов -или внешнего аудита и должна включать анализ отзывов от лиц, использующих -полученные результаты. Сделанные выводы должны быть записаны в соответствующую -базу данных. (см. стандарт ISO 15939-02, раздел 5.4.1 и приложение D). -- Определение потенциальных возможностей улучшения/усовершенствований -(improvements) <процесса проведения измерений>. Такие рекомендации по улучшению -могут заключаться в изменении формата используемых количественных индикаторов, -единиц измерения или изменений в их классификации (категориях метрик). -Необходимо определять стоимости и отдачу (benefits) от предлагаемых улучшений и -отобрать те из них, которые соответствуют целям и критериям измерений, после -чего сформулировать действия, необходимые для внедрения выбранных улучшений. -Предполагаемые улучшения должны быть обсуждены и утверждены заинтересованными -лицами. Отсутствие потенциальных улучшений (если они не были идентифицированы в -результате проведенного анализа) также должно быть обсуждено с -заинтересованными лицами. blob - /dev/null blob + 265b3cbf3b7f5e91d0bb6f6eb87f1f75aaa43b00 (mode 644) --- /dev/null +++ 7_software_engineering_management.md @@ -0,0 +1,873 @@ +# Управление программной инженерией + +Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - +SWEBOK. + +Содержит перевод описания области знаний SWEBOK “Software Engineering +Management”, с замечаниями и комментариями. + +Управление программной инженерией (Software Engineering Management) + +Управление программной инженерией может быть определено как приложение вопросов +управления (management activities) – планирования, координации, количественной +оценки, мониторинга, контроля и отчетности – к инженерной деятельности для +систематического, упорядоченного и количественно измеряемого обеспечения +разработки и сопровождения программных систем (IEEE 610.12-90, Standard +Glossary for Software Engineering Terminology). + +Таким образом, область знаний “Управление программной инженерией” определяет +аспекты управления и количественной оценки в программной инженерии. Измерения +являются важным аспектом для всех областей знаний SWEBOK и соответствующая тема +также включена и в описании данной области знаний. + +В принципе, корректно утверждать, что возможно управлять программной инженерией +так же, как и любым другим комплексным процессом. В то же время, существуют +аспекты, специфичные для программных продуктов, а процессы жизненного цикла +программных систем, в какой-то мере, усложняют достижение необходимого уровня +эффективности управления. Среди таких усложняющих факторов: + +- Восприятие клиентов (потребителей, заказчиков) таково, что часто отсутствует +с их стороны понимание сложности, порожденной самой природой программной +инженерии, в частности связанной с влиянием изменяющихся требований. +- Практически неизбежно изменение или появление новых клиентских требований, +как следствие функционирования процессов программной инженерии. +- В результате, программные системы часто строятся с применением итеративных +процессов, вместо последовательного выполнения и закрытия работ (задач). +- Уровень новизны и сложности программных систем часто крайне высок (и не +позволяет в полной мере применять уже существующие наработки и опыт). + +Применяемые технологии обладают высокой скоростью изменения, обновления и +устаревания + +Что касается программной инженерии, управленческая деятельность в этой области +происходит на трех уровнях: + +- Организационное управление и управление инфраструктурой +- Управление проектами +- Планирование и контроль программ количественной оценки + +Последние два уровня описаны в данной области знаний, что никак не принижает +значимости общих вопросов управления организационными аспектами и +инфраструктурой. + +Хотя все области знаний тесно связаны с другими дисциплинами, связь данной +области знаний с общими вопросами менеджмента особенно важны, что и будет более +подробно, в отличие от других областей знаний, представлено в ниже. Вопросы +организационного менеджмента важны с точки зрения влияния на программную +инженерию, например, в контексте управления политиками/полномочиями сотрудников +или других внутрикорпоративных стандартов, в рамках которых выполняется любая +деятельность (например, с точки зрения отчетности по занятости сотрудников), в +том числе - инженерная. Такие политики подвержены влиянию со стороны требований +к организации эффективного процесса разработки и сопровождения и, на практике, +бывает необходимо адаптировать общие и создать специальные для инженерной +деятельности внутренние организационные стандарты, обеспечивающие эффективное +управление программной инженерией. Эти политики являются основой для решения +долгосрочных задач улучшения процессов и повышения производительности труда +специалистов, вовлеченных в работы по созданию и сопровождению программного +обеспечения. + +Другим важным аспектом управления является управление персоналом через политики +и процедуры найма и приема на работу, обучения, и мотивации специалистов, +помощи в развитии навыков для дальнейшего карьерного роста (mentoring in career +development). Все это требует внимания не только в контексте проекта, но в +рамках всей организации. Для инженеров-программистов особо важными, в +частности, являются вопросы обучения и индивидуального внимания менеджмента. В +большой степени это связано с постоянно развивающимеся технологиями и +потребностью в обновлении и расширении знаний для эффективного решения +поставленных задач. Часто не придают необходимого внимания вопросам +коммуникаций между сотрудниками. На самом деле управление коммуникациями, +создание естественных условий (в agile-практиках им придается особое внимание) +для их развития – один из ключевых элементов повышения не только продуктивности +команд разработки и сопровождения, но и, например, точности получаемых от +пользователей требований и запросов на изменения, то есть любой информации, +которая передается между людьми и значима для успешного решения поставленных +задач. Наконец, управление портфелями (проектов разработки и работ по +сопровождению) позволяет сформировать и развивать общее видение в отношении +всех существующих, обновляемых и создаваемых программных активов на уровне +ИТ-подразделения и в организации, в целом. Все это, в конечном счете, +обеспечивает и более эффективное управление ресурсами, а, значит, и возможность +интенсивного, а не экстенсивного развития организации, в которой инновации +начинают играть одну из ключевых ролей. + +Вместе с осознанием специфики управленческой деятельности в приложении к +программной инженерии, ИТ-специалистам необходимо понимать и ключевые аспекты +общего менеджмента и управления проектами. + +Организационная культура, нормы поведения, аспекты корпоративного управления в +вопросах приобретения и поставки, управления цепочками поставок (supply chain +management), маркетинг, продажи, партнерства и т.п. – все это влияет, хотя и +неявно, на организационные процессы программной инженерии. + +В отношении данной области знаний особо уместно подчеркнуть значимость вопросов +управления проектами (project management), так как “конструирование имеющих +ценность программных артефактов” (к которым относятся требования, модели, +документация, тесты и т.п.) обычно ведется в форме проектов или программ +проектов. Принимая это во внимание, создатели SWEBOK особо отмечают связь +данной области знаний c обсуждавшимся уже в этой книге Руководством к Своду +Знаний по Управлению Проектами PMBOK (A Guide to the Project Management Body of +Knowledge. PMBOK® Guide). В контексте управления программной инженерией следует +понимать важность соответствующих областей знаний PMBOK: + +- Управление интеграцией проекта (project integration management) +- Управление содержанием проекта (project scope management) +- Управление сроками проекта (project time management) +- Управление стоимостью проекта (project cost management) +- Управление качеством проекта (project quality management) +- Управление человеческими ресурсами проекта (project human resource management) +- Управление коммуникациями проекта (project communication management) + +Наравне с ними, с точки зрения автора, необходимо уделять не меньшее внимание и +другим областям знаний управления проектами: + +- Управление рисками проекта (project risk management) +- Управление поставками проекта (project procurement management) + +SWEBOK отмечает, что, несомненно, области знаний управления проектами имеют +непосредственное влияние на решение вопросов управления инженерной +деятельностью в области программного обеспечения. Не имеет смысла, да и просто +невозможно дублировать в SWEBOK содержание PMBOK. Вместо этого, PMBOK +рассматривается как ключевой источник информации и знаний по управлению +проектами, настоятельно рекомендуемый всем лицам, в той или иной степени +вовлеченных в управленческую деятельность в программных проектах. Таким +образом, естественно, что управление проектами можно найти в области знаний +SWEBOK “Связанные дисциплины” (Related Disciplines). + +Данная область знаний состоит из пяти секций, посвященных процессам управления +программной инженерией и еще одной секции, касающейся вопросов измерений и +количественных оценок в управлении. Хотя эти два аспекта (управление и +измерения) часто рассматриваются отдельно и, в самом деле, обладают многими +уникальными аспектами, их тесная взаимосвязь играет важную роль в этой области +знаний. К сожалению, сложилось, во многих случаях, обоснованное [Chaos, 2004] +восприятие индустрии программного обеспечения как недостаточно зрелой, в силу +частых срывов сроков, превышения бюджетных ограничений, недостаточного качества +продуктов, неопределенной функциональности и других причин. Управление, +ориентированное на измерения, как один из основных принципов любой инженерной +деятельности, может серьезно помочь в изменении сложившейся неблагоприятной +ситуации и формировании положительного восприятия программной индустрии +потребителями (пользователями и заказчиками). По-сути, управление без +измерений, количественных или качественных, приводит к отсутствию прогресса в +достижении целей, а измерения без управления – к потере контекста и целей. +Однако, в то же время, управление и измерения без необходимого и достаточного +уровня знаний становится неэффективным и, часто, превращается в самоцель (что +приводит, по мнению автора к излишней бюрократизации и неадекватной +загруженности ресурсов). Таким образом, управленческая деятельность, в общем +плане (включая количественные и качественные оценки), должна проводиться +сбалансировано с другими аспектами программной инженерии, не превращая Software +Engineering Management (SEM) в дорогостоящую, но бесполезную работу. +Эффективный менеджмент требует комбинации соответствующих систематических и +упорядоченных подходов в управлении и соответствующего опыта[^13]. + +[^13]: Например, на практике практически невозможно добиться статуса PMP – Project +Management Professional по версии Project Management Institute (PMI), если +претендент не обладает серьезным практическим опыт управления проектами и +пытается сдать соответствующий экзамен только на основе штудирования PMBOK и +теоретических “изысканий”. + +Прежде, чем детализировать данную область знаний, необходимо дать рабочие +определения для понятий “процесс управления” и “измерения”: + +- Процесс управления (Management process) описывает действия (работы - +activities), предпринимаемые для обеспечения того, что процессы программной +иженерии выполняются в согласовании с политиками, целями и стандартами, +принятыми в организации +- Измерения (Measurement) связаны с определением величин и характеристикой +различных аспектов программной инженерии (продуктов, процессов и т.п.), а также +разработкой на их основе моделей[^14] с использованием статистических +методов (и данных), экспертных знаний и других техник. + +[^14]: В данном контексте, SWEBOK видимо подразумевает, что полученные модели +используются для идентификации и анализа рисков, планирования и +совершенствования процессов программной инженерии (процессов жизненного цикла, +включая процессы сопровождения), а также процесса управления. + +Секции (подобласти) данной области знаний, связанные с управлением программной +инженерией, тесно связаны с секций измерений (количественной оценки). + +Вполне естественно, что данная область знаний тесно связана с другими областями +знаний SWEBOK и ее необходимо рассматривать в контексте других областей знаний. +Стоит особо отметить следующие аспекты применения других областей знаний в +управлении программной инженерией и, особо, в управлении программными +проектами: + +- Требования к программному обеспечению (Software Requirements) – +соответствующие действия по работе с требованиями (в первую очередь, их +определение) указанной области знаний должны выполняться в фазе инициирования +(Initiation) и определения содержания (Scope Definition) программных проектов. +- Конфигурационное управление (Software Configuration Management) – связано с +идентификацией, контролем, учетом статуса (активов проекта, включая запросы на +изменения, прим. автора) и аудитом конфигураций (в терминах конфигурационного +управления) в сочетании с управлением релизами (release management) и +развертыванием программных систем. +- Процесс программной инженерии (Software Engineering Process) – процессы и +продукты тесно связаны; указанная область знаний включает аспекты измерений +продуктов и процессов. +- Качество (Software Quality) – качество является одной из постоянных целей +управления и большого комплекса соответствующих работ, которыми необходимо +управлять. + +Данная область знаний рассматривает управление программной инженерий в терминах +организационного процесса, включающего управление процессами и проектами. +Структурная декомпозиция этой области знаний основывается и на определении +соответствующих тем и на рассмотрении жизненного цикла. При этом, основной +отправной точкой дальнейшей детализации является процесс управления +программными проектами (в оригинале SWEBOK в данной области знаний активно +используется термин software engineering project). Таким образом, структура +декомпозиции управления программной инженерией включает шесть основных секций +(подобластей), из которых первые пять, в основном, следуют стандарту IEEE +(ISO/IEC, ГОСТ) 12207 в части “Процесса управления” (Management Process). Вот +эти шесть секций данной области знаний: + +- Инициирование и определение содержания (Initiation and scope definition) – +касается принятия решения о начале программного проекта +- Планирование программного проекта (Software project planning) – относится к +работам, предпринимаемым для подготовки к успешному ведению +программно-инженерной деятельности с точки зрения управления +- Выполнение программного проекта (Software project enactment) – касается +общепринятых (general accepted) действий по управлению программной инженерией в +процессе проведения соответствующих инженерных работ +- Обзор и оценка (Review and evaluation) – относится к работам по проверке +того, что получаемый программный продукт отвечает заданным целям, требованиям, +ограничениям и т.п. +- Закрытие <проекта> (Closure) – относится к фиксированию результатов +программного проекта после передачи полученного программного продукта в +эксплуатацию. +- Измерения в программной инженерии (Software engineering measurement) – +касается разработки и реализации программ по измерению (ведению количественной +оценки) в организациях (в общем смысле, т.е. группах, подразделениях, компаниях +и т.п.), занимающихся инженерной деятельностью в области программного +обеспечения. + +![Рисунок 1. Область знаний “Управление программной инженерией” [SWEBOK, 2004, с.8-2, рис. 1]](images/management_small.jpg) + +Здесь нельзя не сделать замечание, связанное со структурированием этой области +знаний. Обсуждаемая область знаний, действительно, тесно связана с дисциплиной +управления проектами. Более того, речь идет о приложении управления проектами к +программной инженерии. В этом контексте кажется уместным сопоставить +предлагаемый в SWEBOK цикл “Initiation & scope definition – Planning – +Enactment – Review & evaluation – Closure” с процессными группами PMBOK +“Initiation – Planning – Execution – Monitoring & Controlling – Closing”. Как +мы видим, в PMBOK роль работ SWEBOK “Обзор и оценка” (Review and evaluation) +играют действия по мониторингу и контролю процессов - “Monitoring & Controlling +Processes”. Таким образом, с учетом реального содержания секции “Software +project enactment”, ее название и переведено автором как “Выполнение +программного проекта”, хотя “enactment” в большей степени подразумевает +формальный “запуск” работ. Конечно, перевод мог звучать и как “исполнение” +(например, следуя PMBOK), однако, такой перевод, по мнению автора, все же несет +слишком формальный оттенок, что, субъективно, не соответствует ряду +методологических подходов (в первую очередь agile) и культурных “ограничений”. + +## Инициирование и определение содержания (Initiation and Scope Definition) + +Данная секция фокусируется на наборе действий, связанных с эффективным +определением требований к программному обеспечению с использованием различных +методов извлечения требований, а также оценкой осуществимости проекта с +различных точек зрения. Если проект признан осуществимым, следующей задачей +является специфицирование процедур проверки и изменения требований (см. область +знаний “Требования к программному обеспечению” – Software Requirements). + +### Определение и обсуждение требований (Determination and Negotiation of Requirements) + +– выбор и применение методов определения (извлечения), анализа (например, +моделирования сценариев use case), специфицирования и проверки (например, +прототипирования) требований, принимая во внимание позицию различных +заинтересованных лиц. Это является первичными работами, необходимыми для +определения содержания, целей и ограничений проекта. Данные работы важны +всегда, так как позволяют определить четкие границы задач, необходимых для +выполнения, в частности, это особенно заметно для проектов, обладающих большой +степенью “новизны” (идет ли речь о технологических аспектах проекта, его +масштабах, методах и т.п.). + +### Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. (Feasibility Analysis. Technical, Operational, Financial, Social/Political.) + +Инженеры должны убедиться в том, что для успешного завершения проекта (в +заданные сроки, в рамках бюджета и т.п.) доступны необходимые возможности +(capabilities) и ресурсы, будь то люди (те или иные специалисты), экспертиза +(опыт, знания, навыки), средства (например, инструментарий), инфраструктура и +поддержка (как внутренняя, так и внешняя, например, со стороны старших +менеджеров организационной структуры, отвечающей за разработку, и ключевых +менеджеров или других заинтересованных лиц со стороны “заказчика”). Это часто +требует хотя бы приблизительной оценки усилий и стоимости с использованием +соответствующих методов (например, техники, в которой экспертная оценка +базируется на аналогиях). + +### Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements) + +Учитывая неизбежность изменений, жизненно важно определить и согласовать с +заинтересованными лицами процедуры (например, в контексте деятельности по +управлению изменениями) в рамках которых будут проводиться оценка и пересмотр +требований. Это однозначно предполагает, что требования не будут неизменны, но +могут и должны корректироваться в соответствии с заданными и детализированными +процессами (например, design review – оценка дизайна). Если изменения приняты, +необходимо проводить анализ зависимостей (traceability analysis) и рисков (см. +далее тему 2.5 “Управление рисками” – Risk Management) для оценки влияния +рассматриваемых изменений. Такой анализ необходимо проводить, в общем случае, и +при рассмотрении “изменения” для принятия решения о передачи его “в работу” или +отклонении (например, в силу обоснованных причин, таких как проектные решения, +позволяющих отметить его как реализуемое в следующей версии), и уже более +детально, если изменение требования(ий) решено реализовать (в силу, например, +контрактных обязательств со стороны исполнителя) и необходимо определить, как +именно такое изменение повлияет на существующую систему и какие работы +необходимо выполнить, чтобы удовлетворить обновленному(ым) требованиям. SWEBOK +отмечает, что управление изменениями полезно и при оценке результатов проекта +(программного продукта, программной системы), так как содержание и требования +формируют основу оценки успешности проекта. (см. также секцию “Контроль +конфигураций” области знаний Software Configuration Management). + +## Планирование программного проекта (Software Project Planning) + +Процесс планирования является итеративным[^15] и базируется на +содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить, +что различные фазы проекта перекрываются (что, например, специально отмечает +PMBOK) и вместе с определением содержания, детализацией требований и +проведением анализа осуществимости, параллельно с этим сам разрабатываемый план +проекта в той или иной степени детализируется и формируется определенный +комплекс работ, оцениваются необходимые ресурсы и временные границы работ, и +т.п. SWEBOK, основываясь на такой позиции, говорит, что при планировании также +оцениваются и отбираются соответствующие процессы жизненного цикла. Там где это +уместно, проект детализируется в виде структурной декомпозиции работ, для +которых отмечены ассоциируемых с их завершением результаты и их характеристики. +Такие характеристики, обычно, связаны с вопросами качества и другими +установленными атрибутами требований, соблюдением сроков выполнения работ, +усилиями, стоимостью и т.д. Ресурсы распределяются по задачам таким образом, +чтобы обеспечить оптимальную продуктивность (на персональном, командном и +организационном уровне), использование средств (инфраструктуры, +инструментов,...) и оборудования, а также строгое соблюдение проектного +расписания. Также должно проводится управление рисками и, в частности, +необходимо определить “профиль рисков”, принятый соответствующими +заинтересованными лицами. Как составная часть планирования, необходимо +определить необходимые процессы обеспечения качества в форме соответствующих +процедур и обязанностей (responsibilities) по оценке, проверке, аттестации и +аудиту качества (см. область знаний “Качество программного обеспечения” – +Software Quality). Безусловно, что должны быть определены процессы и +обязанности в части управления планом проекта, его оценкой и порядка пересмотра +различных аспектов проекта. + +[^15]: Позднее, при обсуждении жизненного цикла и, в частности, спиральной модели +разработки, мы будем рассматривать ключевые идеи итеративного подхода. + +### Планирование процесса (Process Planning) + +С учетом содержания и требований конкретного проекта необходимо выбрать, +адаптировать и использовать соответствующую модель процессов жизненного цикла +(например, спиральную, с эволюционным прототипированием). Также должны быть +выбраны методы и инструменты. На уровне проекта, методы и инструменты +используются для декомпозиции проекта в виде набора задач (tasks), с +ассоциированными входами, выходами и условиями завершения (completion), +например, в форме структуры декомпозиции работ – WBS (work breakdown +structure). Это влияет на высокоуровневое (первичное) определение проектного +расписания и организационной структуры <проектной команды>. + +### Определение результатов (Determine Deliverables) + +Должен быть определен результат выполнения каждой задачи (например, описание +архитектуры, отчет по анализу, набор тестов и т.п.), то есть какие +активы/артефакты мы должны получить по выполнении соответствующей задачи +проекта. При этом оцениваются возможности повторного использования программных +компонент, созданных ранее, в процессе разработки других программных продуктов, +и потенциал применения готовых к использованию компонент из 3-их источников. +Должно быть определено, какие именно компоненты будут использоваться и как они +будут получены (через каких поставщиков). + +Такие компоненты, обычно, называют “off-the-shelf”, подразумевая в настоящее +время не только коммерческое, но и общедоступное программное обеспечения, если +его использование обосновано в рамках данного проекта. Анализ и выбор +соответствующих компонент может и, в подавляющем большинстве случаев, должен +рассматриваться как самостоятельная задача процесса планирования в контексте +сформулированных высокоуровневых требований, определенного содержания и базовых +ограничений проекта, таких как сроки, ресурсы, стоимость). Это позволяет четко +разделить, в том числе, в контексте затрат, что именно будет разрабатываться +самостоятельно (может быть как отдельный “подпроект”), что будет использоваться +из 3-их источников (3rd party), а что будет являться содержательным (с точки +зрения проекта) результатом работ, то есть его непосредственным активом, +обладающим, например, функциональной, для данного проекта, нагрузкой. + +### Оценка усилий, расписания и стоимостных ожиданий (Efforts, Schedule and Cost Estimation) + +Ожидаемые пределы усилий, необходимых для решения каждой задачи (task) проекта +основываются на разбиении задач, их входах и выходах. Для этого используется +калиброванная (calibrated - настроенная для заданных условий) модель ожиданий +(estimation model), базирующаяся на исторических данных по усилиям, связанным с +объемом задачи (size-effort historical data, часто определяется как +человеко-месяцы к функциональным точкам или количеству строк кода). Также, для +оценки усилий могут применяться и другие методы, например, экспертная оценка +или оценка по типу приложения (встроенное, телекоммуникационное), квалификации +проектной группы и т.п. + +Кроме того, необходимо идентифицировать связи и зависимости между задачами +(tasks dependencies) и потенциально критические аспекты (bottlenecks) проекта. +Такие работы могут быть проведены с использованием, например, метода анализ +критического пути (critical path analysis – достаточно распространенный метод, +относящийся к общей дисциплине управления проектами, применимый и для проектов +программных систем). Если возможно, критические аспекты должны быть разрешены, +а для задач определены ожидаемые сроки выполнения (расписание), включающие +начало, длительность и окончание (например, в форме PERT-диаграмм*). + +* PERT анализ (Program, Evaluation, and Review Technique) – техника оценки +ожиданий в отношении длительности (duration) задач проекта, проводимая на +основе определения среднего весового значения трех оценок длительности - +пессимистической, оптимистической и ожидаемой (то есть наиболее вероятной, при +первичной оценке). Аналогичная техника может и часто используется для оценки +усилий (effort), необходимых для реализации задачи. Наибольший эффект дает +сочетание различных методов оценки. В то же самое время, чем больше методов +оценки используется, тем более трудоемкой (а, следовательно, и ресурсоемкой) +становится такая работа, поэтому задача менеджмента – определить наиболее +оптимальный и эффективный для данного проекта набор методов и техник, +используемых в процессе планирования и корректировки. +Требования к ресурсам (люди, инструменты) транслируются в стоимостные ожидания. + +В совокупности, вся эта деятельность является итеративной и должна обсуждаться +и проводиться до тех пор, пока не будет достигнут консенсус между +соответствующими заинтересованными лицами – в первую очередь, менеджментом +<проекта> и инженерами <входящими в команду проекта>. + +### Распределение ресурсов (Resource Allocation) + +С задачами (для которых назначены сроки), должны быть ассоциированы +оборудование, средства и, конечно, люди. Это подразумевает распределение +(назначение или принятие, в зависимости от стиля и формы управления) +обязанностей/ответственности. Для этого может, например, использоваться +диаграмма Ганта (Gantt chart). Эта деятельность определяется и ограничивается +доступностью ресурсов, их оптимальным использованием в заданном контексте и +вопросами, связанными с персоналом (например, продуктивностью конкретных лиц и +группы, в целом, организационной и командной структурой, подразумевая специфику +коллектива, наравне со штатным расписанием и другие вопросы). + +Крайне необходимо выделить как самостоятельную тему данной секции вопросы +управления персоналом – people management, уделив особое внимание аспектам +экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в +проектной команде. К этой же теме, также стоит отнести вопросы обучения, +прохождения тренингов специалистами проектной команды. Наконец, к теме ресурсов +имеет непосредственное отношение и определение необходимости и объема +привлечения внешних консультантов (не являющихся сотрудниками ни исполнителя, +ни заказчика), к сожалению, не упоминаемое здесь в SWEBOK, но крайне важное, по +опыту автора, для успешности проекта, обладающего высокой степенью новизны +(например, в терминах используемых технологий и, особенно, применения тех или +иных архитектурных решений). + +### Управление рисками (Risk Management) + +В части управления рисками должны проводиться: + +- идентификация и анализ рисков - что, когда и почему может быть сделано +неверно и к чему это может привести; +- оценка критических рисков - какие из рисков наиболее значительны (если им не +уделять должного внимания) и что необходимо сделать, чтобы их избежать; +- смягчение рисков (risk mitigation) и планируемость непредвиденных +обстоятельств (contingency planning) – формирование стратегии, касающейся +рисков и управление профилями рисков. + +Для идентификации и оценки рисков необходимо применять соответствующие методы и +техники (например, построение дерева решений – decision tree или моделирование +процессов – process simulation). Кроме того, со всеми заинтересованными лицами +необходимо определить правила и политики прекращения проекта. + +Наравне с идеями общего управления рисками, важно понимать и управлять рисками, +уникальными для деятельности в области программной инженерии, например, +тенденция добавлять в получаемый программный продукт функциональные и другие +возможности, неопределенные на уровне требований или риски, заложенные в самой +природе программного обеспечения, связанные, в первую очередь с его сложностью +и архитектурно-технологической новизной, присутствующей, в той или иной +степени, в любом программном проекте. + +### Управление качеством (Quality Management) + +Качество определяется в терминах атрибутов, значимых для данного конкретного +проекта и/или ассоциированного с ним продукта. Атрибуты могут выражаться как +качественно, так и количественно. Эти характеристики качества определяются в +спецификации требований к программному обеспечению (см. область знаний +“Требования к программному обеспечению” – Software Requirements). + +Отправной точкой для соблюдения качества является набор индикаторов, +соответствующих ожиданиям заинтересованных лиц. На этой стадии (как мы помним, +речь идет о планировании проекта) также специфицируются процедуры, связанные с +проведением SQA-деятельности (деятельности по обеспечению качества – software +quality assurance) на протяжении всех процессов жизненного цикла и для проверки +и аттестации (V&V – verification and validation) для получаемого продукта и +всех активов (артефактов) проекта (см. область знаний “Качество программного +обеспечения” – Software Quality). + +### Управление планом проекта (Plan Management) + +Наравне с другими аспектами ведения проекта, должно быть определено как проект +будет управляться и как будет управляться план проекта. Отчетность, мониторинг +и контроль проекта должны соответствовать выбранному процессу программной +инженерии и сущности проекта, отражая также в виде различных артефактов именно +то, что будет использоваться в процессе управления. При этом, в изменяющемся +окружении принципиально важно, чтобы и сам план проекта был управляем. Это +требует строгого соблюдения планов, которые должны быть систематически +направляемы, контролируемы, оцениваемы, по которым будет вестись отчетность и, +там где это применимо, корректируемы. Планы, ассоциированные с другими +процессами поддержки, ориентированными на управление, также должны быть +управляемы соответствующим образом (например, это касается вопросов +документирования, конфигурационного управления и разрешения проблем). + +## Выполнение программного проекта (Software Project Enactment) + +План проекта реализуется за счет выполнения процессов, представленных в плане. +Следование плану на протяжении выполнения проекта связано с ожиданиями, что +соблюдение <корректно составленного> плана приводит к успешному удовлетворению +требований заинтересованных лиц и достижению целей проекта. Основой для +успешного выполнения проекта является управленческая деятельность по ведению +оценки и измерений, мониторинга, контроля и отчетности. + +### Реализация планов[^16] (Implementation of Plans) + +Проект инициируется и проектные работы выполняются в соответствии с планом. В +процессе выполнения используются соответствующие ресурсы (например, усилия +персонала, бюджет) и производятся необходимые результаты (deliverables; активы, +артефакты проекта – например, архитектурные документы, тестовые сценарии). + +[^16]: В SWEBOK используется как “план проекта” в единственном числе, так и “планы” +– во множественном числе, подразумевающие, судя по контексту, отдельные задачи +проекта. + +### Управление контрактами с поставщиками (Supplier Contract Management) + +Включает подготовку и выполнение соглашений с поставщиками, мониторинг +деятельности поставщиков, принятие у поставщиков продуктов, использование и +интеграцию этих продуктов в рамках проектных работ. + +### Реализация процесса по ведению измерений (Implementation of Measurement Process) + +Данный процесс выполняется на протяжении всего проекта, обеспечивая сбор всех +необходимых данных (см. 6.2 Plan the Measurement Process и 6.3 Perform the +Measurement Process). + +### Процесс мониторинга (Monitor Process) + +Соблюдение плана проверяется постоянно и через предопределенные интервалы +времени. Анализируются выходы (outputs) и условия завершения <задач>. +Получаемые <в процессе измерений> результаты оцениваются в терминах требуемых +характеристик (например, через процедуры обзора/оценки и аудита – review, +audit). Затраты усилий (efforts), соблюдения расписания, стоимость к данному +моменту, используемые ресурсы – все это исследуется к каждой дате оценки. При +этом, оценивается и корректируется профиль рисков, а также, производится +проверка удовлетворения требований качества. + +Моделируются и анализируются данные измерений. Анализ расхождений (variance +analysis) <плана с реальным выполнением проекта> базируется на оценке +отклонений реальных данных от планируемых и ожидаемых. Такой анализ может +проводиться в отношении оценки перерасхода средств (cost overrun), нарушения +расписания и других важных характеристик – ограничений проекта Часто +выполняется “внешний” (например, с привлечением представителей заказчика) +анализ качества и других измеряемых данных (например, анализ плотности дефектов +– defect density analysis). Проводится повторное (уточняющее) выявление рисков +и оценка их последствий (risk exposure and leverage), разрабатывается дерево +решений, проводится моделирование (рисков и действий по их предотвращению) и +другие работы – уже в контексте полученных данных. Все эти работы позволяют +обнаруживать проблемы и идентифицировать исключения, основываясь на выходе за +рамки приемлемых границ тех или иных параметров проекта (в частности, +характеристик качества). Отчетность по результатам создается в соответствие с +планом, а также, при выходе за заданные ограничения проекта или параметров +отдельных его работ. + +Хотелось бы обратить внимание на то, что современная практика управления +проектами, в частности, разработки и сопровождения программного обеспечения, +требует обеспечения возможности доступна к актуальным данным по проекту в любой +момент времени. По-сути в настоящее время возникает целый класс интегрированных +инструментов и специализированных продуктов, часто называемый project dashboard +(наиболее близкий перевод этого понятия на русский язык может звучать как +“панель управления проектом”). Обычно, такие инструменты не только работают со +“снимками” данных, сводя их воедино, но обращаются непосредственно к данным в +системах конфигурационного управления, управления требованиями, сценариями +тестирования, аудита кода, расписания проекта в соответствующих средствах +управления проектами и т.п. + +### Процесс контроля (Control Process) + +Выходы (результаты) процесса мониторинга обеспечивают базис, на основе которого +принимаются те или иные решения. Изменения в проект вносятся там, где это +необходимо, и где ассоциированные риски и их влияние смоделированы и могут быть +управляемы (контролируемы). Эти изменения могут проводиться в форме +корректирующих действий (например, повторного тестирования определенных +компонент) и могут приводить к изменению плана, работ, документов и других +активов проекта. При этом, важно контролировать (идентифицировать, оценивать и +принимать решения) прямые и косвенные влияния любых изменений. + +В некоторых случаях, это может приводит к прекращению проекта. Во всех случаях +необходимо проводить контроль изменений и процедур конфигурационного управления +(см. предыдущую область знаний Software Configuration Management). При этом, +решения должны документироваться и сообщаться (желательно, перед этим +обсуждаться) всем заинтересованным сторонам, планы – корректироваться (там где +это необходимо), а все необходимые данные должны заноситься в центральную базу +данных проекта (см. тему 6.3 Perform the Measurement Process). + +### Ведение отчетности (Reporting) + +Отчеты проводятся за определенный и согласованный период времени, согласуясь с +планом проекта и адресуясь заинтересованным лицам (в том числе – “внешним”, со +стороны заказчика). В принципе, возможны выделить две группы отчетов – по +общему состоянию проекта (именно, они обычно адресованы и заказчику), а также +детализированные отчеты, подготавливаемые чаще и касающиеся отдельных групп в +команде проекта, отдельных работ, групп требований, функциональных модулей и +т.п. + +## Обзор и оценка (Review and Evaluation) + +В критических точках проекта оценивается общий (по всему проекту) прогресс в +достижении установленных целей и удовлетворении требований заинтересованных +лиц. Аналогично, проводится оценка (assessment) эффективности процессов, +<работы> персонала, а также инструментов и методов, использованных в работах, +проведенных за заданный промежуток времени. + +### Определение удовлетворения требованиям (Determining Satisfaction of Requirements) + +Так как достижение удовлетворения пользователей является одной из наших +принципиальных целей, представляется важным периодическая и формальная оценка +прогресса в данном вопросе. Такая оценка проводится при достижении определенных +вех (milestones) проекта, например, при утверждении разработанной архитектуры). +При этом идентифицируются отклонения от соответствующих ожиданий (планов) и +проводятся необходимые действия, связанные с результатами оценки отклонений +(например, действия по корректировке плана). Как было отмечено выше (см. тему +3.5 “Процесс контроля”), во всех случаях проводится контроль изменений и +процедуры конфигурационного управления, документируются принятые решения и +обеспечивается необходимая отчетность. Дополнительную информацию, также имеющую +отношение к обсуждаемому вопросу, можно найти в области знаний “Тестирование +программного обеспечения” (Software Testing) в темах 2.2 “Цели тестирования” +(Objectivies of Testing) и 2.3 “Оценка и аудит” (Reviews and Audits). + +### Оценка продуктивности/результативности (Reviewing and Evaluation Performance) + +Периодическая оценка продуктивности специалистов, вовлеченных в проект, +обеспечивает понимание того, насколько они следуют плану, и дает возможность +идентифицировать вероятные проблемы (например, конфликты между членами +проектной команды). Для оценки эффективности применяются различные методы, +инструменты и техники. Сам процесс оценки является систематическим, а процедуры +– периодическими. Все это зависит от используемых управленческих техник, +применяемых методологий, организационных принципов, сложившейся культуры, то +есть рассматривается, в том числе, в контексте специфики программной инженерии, +дисциплины управления проектами и общего менеджмента. + +## Закрытие (Closure) + +Проект закрывается/завершается (не путайте с прекращением проекта), когда все +планы и процессы выполнены и завершены. На этой стадии по результатам проекта +применяются критерии оценки его успешности. Когда принимается решение о +закрытии проекта, выполняются действия по архивированию проектных данных, +анализу результатов, полученных в процессе работы над проектом (post mortem +analysis), и улучшению процессов (process improvement). + +### Определение <критериев> закрытия проекта (Determining Closure) + +Проект закрывается, когда завершены специфицированные в плане проекта задачи и +подтверждено <удовлетворительное> достижение критериев завершения (completion +criteria) проекта. При этом, все запланированные результаты (продукт, его +модули и т.п.) должны быть переданы заказчику и/или в эксплуатацию с +приемлемыми (с точки зрения требований) и принятыми (со стороны заказчика) +характеристиками. Удовлетворение требованиям – проверено и +подтверждено/утверждено заказчиком, а цели проекта – достигнуты. Перечисленные +процессы, в общем случае, требуют вовлечения всех заинтересованных лиц. +Результаты их выполнения документируются, включая подтверждения со стороны +заказчика о соответствии результатов проекта заданным требованиям (client +acceptance list, например, по результатам приемочных, или, как их еще называют, +приемо-сдаточных тестов) и, если это необходимо, включая также отчеты об +оставшихся/требующих доработки проблемах (known problems). + +### Работы по закрытию проекта (Closure Activities) + +После того, как принято и утверждено решение о закрытии проекта (также говорят +о “подтверждении закрытия/завершения проекта”) создается архив материалов в +соответствии с утвержденными заинтересованными лицами методами, +местоположением, формой и заданной длительностью хранения. База данных +измерений <в организации> обновляется в соответствии с полученными финальными +данными проекта и проводится пост-проектный анализ этих данных. Анализ по +завершении проекта помогает в оптимизации процессов, практик и организационной +структуры (см. область знаний Software Engineering Process). + +## Измерения в программной инженерии (Software Engineering Measurement) + +Важность и роль количественных оценок - измерений - в управленческих практиках +широко известна, растет с каждым годом и уже не раз подчеркивалась в SWEBOK. +Эффективные измерения становятся одним из краеугольных камней организационной +зрелости. + +Ключевые термины и методы по измерениям в программной инженерии определены в +стандарте ISO/IEC 15939:2002 Software Engineering - Software Measurement +Process (2002 г.), основывающемся на международном словаре метрологии, +выпущенном ISO в 1993 году. Несмотря на это, в различной литературе встречаются +разные термины, например, часто термин “metric” – метрика (на русском языке +выглядит предпочитительным использовать именно этот термин) используется вместо +“measure” – измерение. + +Данная тема следует указанному международному стандарту ISO/IEC 15939, который +описывает процесс, определяющий действия/работы (activities) и задачи (tasks)*, +необходимые для реализации процесса ведения измерений, а также включающий +информационную модель измерений. + +* “действия/работы” - activities, “задачи” – tasks: термин “задача” +используется для более глубокого уровня детализации, чем “действия/работы”; +термины “действия” и “работы”, как вы уже заметили, часто используются +взаимозаменяемым образом. Так или иначе, это вопрос договоренности о +терминологии при организации WBS (Work Breakdown Structure) – структуры +декомпозиции работ. + +### Установление и поддержка процесса ведения измерений (Establish and Sustain Measurement Commitment) + +- Формулируются требования в отношении измерений. Каждая попытка измерения +должна руководствоваться организационными целями и следовать набору измерений, +выполняемых в отношении требований, в соответствии с принятыми организационными +или проектными стандартами. Например, в качестве организационной цели может +выступать “выпуск на рынок новых продуктов первыми”. Это, в свою очередь, может +порождать требование того, что факторы, способствующие достижению цели также +должны быть оценены количественно, с тем, чтобы проект могу быть управляем в +процессе достижения заданного результата. Для этого необходимо: + + - Определить содержание измерений. Необходимость принять, в каких масштабах – +на уровне какой организационной единицы* будут проводиться измерения – только в +одной функциональной области, в рамках проекта, на уровне комплекса проектов +или в организации, в целом. Все последующие задачи по ведению измерений, +связанные с соответствующими требованиями, ведутся в рамках принятого +содержания измерений. Безусловно, в дополнение к этому необходимо +идентифицировать всех заинтересованных лиц, ассоциированных и вовлеченных в +проведение измерений. + + - Заручиться поддержкой менеджеров и персонала в ведении измерений. Такая +поддержка должна быть оформлена формально, сообщена персоналу и поддержана +соответствующими ресурсами (см. ниже). + +* организационная единица - organizational unit: этот термин хоть и не очень +удачен в SWEBOK, но будет использоваться достаточно часто в контексте ведения +измерений для описания границ измерений. При этом часто подразумевается не +фиксированная структурная единица в организации, а некая "единица +деятельности", в отношении которой проводятся измерения – операция, задача, +работа, проект, программа, деятельность организации, в целом. + +- Выделяются соответствующие ресурсы для проведения измерений. Организационная +поддержка измерений является основным фактором успеха, так как назначение +ресурсов просто необходимо для реализации процесса ведения измерений. +Назначение ресурсов включает распределение ответственности (например, +пользователь, аналитик и т.п.) в отношении различных задач процесса измерения и +предоставление необходимого финансирования, обучения, инструментов и поддержки +процесса сопровождения на постоянной основе. + +### Планирование процесса измерений (Plan the Measurement Process) + +- Задание “организационной единицы” (в частности, в понимании “единицы +деятельности”, как описывалось выше). Таким образом обеспечивается явный +контекст измерений и связанные с ним ограничения. В качестве такой “единицы” (в +общем случае) могут выступать организационные процессы, прикладные домены +(области деятельности или отдельных работ) и т.п. См. подробное описание +характеристик организационной единицы в уже упомянутом стандарте ISO 15939-02 +(ISO/IEC 15939:2002 Software Engineering - Software Measurement Process, раздел +5.2.1). +- Идентификация информационных потребностей <в отношении результатов +измерений>. Такие потребности, обычно, базируются на целях, ограничениях, +рисках и проблемах на уровне заданной организационной единицы. В основе +указанных аспектов лежат различные цели – организационные, проектные и т.п. Все +эти аспекты (как и порождающие их цели) должны быть четко идентифицированы и +для них должны быть определены соответствующие приоритеты. Затем, должно быть +выбрано подмножество аспектов, в отношении которых будут проводиться измерения, +и полученные результаты также должны быть документированы, персонал поставлен в +известность о них, а заинтересованным лицам необходимо провести требуемую +оценку аспектов измерений (см. стандарт ISO 15939-02, раздел 5.2.2). +- Выбор метрик (измерений). Кандидаты в метрики должны быть выбраны на основе +приоритетов информационных потребностей и других критериев – таких, как +стоимость сбора данных, возможность срыва процессных работ при сборе данных +(например, в силу недостатка ресурсов), легкость анализа, легкость получения +точных и целостных данных и т.п. (см. стандарт ISO 15939-02, раздел 5.2.3 и +приложение C). +- Определение наборов <собираемых> данных, а также процедур анализа и ведения +отчетности. Это включает в себя коллекцию процедур и расписаний, хранение, +проверку, анализ, отчетность и конфигурационное управление собираемыми данными. +(см. стандарт ISO 15939-02, раздел 5.2.4). +- Определение критериев оценки информационных продуктов (т.е. результатов +измерений). На критерии оценки влияют технические и бизнес цели, +сформулированные прежде для соответствующей организационной единицы. Результаты +измерений* ассоциированы с создаваемым продуктом <являющемся целью проекта>, а +также с процессами, обеспечивающими управление и измерения в проекте. (см. +стандарт ISO 15939-02, раздел 5.2.5 и приложения D, E). +* в данной теме в отношении результатов измерений часто используется термин +“информационный продукт” – information product. +- Оценка, утверждение и предоставление ресурсов для проведения измерений. + - План измерений должен быть оценен и утвержден соответствующими +заинтересованными лицами. Это включает процедуры сбора данных, их хранения, +анализа и отчетности; критерии оценки; расписание и распределение +ответственности. Критерии обзора и оценки этих артефактов должны быть +установлены на уровне организационной единицы или выше. Такие критерии должны +принимать во внимание существующий опыт, доступность ресурсов и потенциальный +срыв проекта когда предлагается изменение существующих практик. Утверждение +(approval) <выделения ресурсов> демонстрирует поддержку и принятие обязательств +по проведению измерений. (см. стандарт ISO 15939-02, раздел 5.2.6.1 и +приложение F). + - Ресурсы должны быть доступны для реализации запланированных и утвержденных +задач по ведению измерений. Доступность ресурсов может быть распределена по +стадиям внедрения изменений в процесс измерений, например, когда изменения +производятся изначально в “пилотном” режиме, а уже затем, становятся составной +частью стандартного процесса (т.е. используемого в рамках всего проекта, +подразделения или организации). Также, необходимо уделять внимание ресурсам, +необходимым для успешного внедрения новых процедур и измерений (метрик). (см. +стандарт ISO 15939-02, раздел 5.2.6.2). +- Овладевание и внедрение технологий поддержки <измерений>. Это включает оценку +доступных технологий, выбор наиболее соответствующих (заданному контексту и +ограничениям) технологий, их приобретение и овладевание ими и, наконец, +внедрение в повседневную практику. (см. стандарт ISO 15939-02, раздел 5.2.7). + +### Выполнение процесса измерений (Perform the Measurement Process) + +- Интеграция процедур проведения измерений с соответствующими процессами. +Процедуры измерения (например, сбор данных) должны быть интегрированы в +оцениваемые процессы. Это может приводить к изменению самих процессов для +адаптации действий по сбору или генерации необходимых данных. Это может +подразумевать и анализ существующих процессов для минимизации дополнительных +усилий, и оценку влияния на сотрудников, необходимые для реального принятия +процедур проведения измерений. Важно понимать и принимать во внимание моральные +и другие аспекты “человеческого фактора”, без которых проведение измерений, как +дополнительная (к функциональной) деятельность будет восприниматься лишь как +помеха основной работе. Более того, процедуры измерений должны обсуждаться с +теми, кто непосредственно предоставляет данные; может потребоваться +соответствующее обучение персонала; необходимо обеспечить и соответствующую +поддержку (по аналогии с технической поддержкой программного обеспечения). +Анализ данных и процедуры отчетности должны быть интегрированы в +организационные и/или проектные процессы. (см. стандарт ISO 15939-02, раздел +5.3.1). +- Сбор данных. Данные должны собираться, верифицироваться и сохраняться <для +дальнейшего использования>. (см. стандарт ISO 15939-02, раздел 5.3.2). +- Анализ данных и создание информационного продукта (как результата измерений, +позволяющего принимать на его основе те или иные решения). Данные могут +агрегироваться, трансформироваться или записываться как часть процесса анализа +в соответствии с природой данных и информационными потребностями. Обычно +результаты анализа представляются в форме соответствующих графиков, численных +характеристик или других индикаторов, интерпретируемых и передаваемых, в конце +концов, заинтересованным лицам. Результаты и сделанные на их основе заключения +должны быть оценены (reviewed) в соответствии с процессом, определенным в +организации (который может быть формальным или неформальным). Лица, +предоставляющие данные и проводящие измерения, должны участвовать в процессе +обзора и оценки (review) данных для обеспечения соответствия их содержательной +стороны и точности, а также выполнения действий, обоснованных результатами +последующего анализа. (см. стандарт ISO 15939-02, раздел 5.3.3 и приложение G). +- Обсуждение результатов. Полученный “информационный продукт” должен быть +документирован и передан пользователям и заинтересованным лицам. (см. стандарт +ISO 15939-02, раздел 5.3.4). + +### Оценка измерений (Evaluate Measurement) + +- Оценка информационного продукта. Такая оценка проводится на соответствие +специфицированным критериям оценки и определяет сильные и слабые стороны +(strengths and weaknesses*) полученного информационного продукта. Оценка может +проводиться в рамках внутренних процессов или внешнего аудита и должна включать +анализ отзывов от лиц, использующих полученные результаты. Сделанные выводы (в +англоязычных источниках по оценке и совершенствованию процессов повсеместно +используется термин “lessons learned” – “полученные уроки”) должны быть +записаны в соответствующую базу данных (иногда называемую также “базой знаний” +– “knowledgebase”). (см. стандарт ISO 15939-02, раздел 5.4.1 и приложение D). +* strengths and weaknesses – два из четырех элементов SWOT-анализа. SWOT - +Strengths, Weaknesses, Opportunities, Threats – сильные стороны, слабые +стороны, возможности, угрозы. Обычно представляется как квадрант четырех +указанных факторов. +- Оценка процесса проведения измерений. Данная оценка проводится на +соответствие специфицированным критериям оценки и определяет сильные и слабые +стороны самого процесса. Оценка может проводиться в рамках внутренних процессов +или внешнего аудита и должна включать анализ отзывов от лиц, использующих +полученные результаты. Сделанные выводы должны быть записаны в соответствующую +базу данных. (см. стандарт ISO 15939-02, раздел 5.4.1 и приложение D). +- Определение потенциальных возможностей улучшения/усовершенствований +(improvements) <процесса проведения измерений>. Такие рекомендации по улучшению +могут заключаться в изменении формата используемых количественных индикаторов, +единиц измерения или изменений в их классификации (категориях метрик). +Необходимо определять стоимости и отдачу (benefits) от предлагаемых улучшений и +отобрать те из них, которые соответствуют целям и критериям измерений, после +чего сформулировать действия, необходимые для внедрения выбранных улучшений. +Предполагаемые улучшения должны быть обсуждены и утверждены заинтересованными +лицами. Отсутствие потенциальных улучшений (если они не были идентифицированы в +результате проведенного анализа) также должно быть обсуждено с +заинтересованными лицами. blob - b8cfbe31d1930eafecf227beb29441f5ce69a647 (mode 644) blob + /dev/null --- 8_software_engineering_process.markdown +++ /dev/null @@ -1,810 +0,0 @@ -# Процесс программной инженерии - -Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK. - -Содержит перевод описания области знаний SWEBOK “Software Engineering Process”, -с замечаниями и комментариями. - -Процесс программной инженерии (Software Engineering Process) - -Область знаний “Процесс программной инженерии” (Software Engineering Process) -может быть рассмотрена на двух уровнях. Первый уровень содержит техническую и -управленческую деятельность на протяжении процессов жизненного цикла -программного обеспечения, включающих приобретение, разработку, сопровождение и -вывод из эксплуатации программных систем. Второй уровень – “мета-уровень”, -связанный с определением, реализацией, оценкой, измерением, управлением, -изменением и совершенствованием самих процессов жизненного цикла программного -обеспечения. Первый уровень освещен в других областях знаний SWEBOK. Второй -уровень рассматривается в данной области знаний. - -Термин “процесс программной инженерии” (software engineering process) может -интерпретироваться по-разному и это, соответственно, может приводить к -определенной путанице. - -- С одной стороны, учитывая специфику оригинального термина в английском языке, -где (с точки зрения грамматики) может существовать термин the software -engineering process, он будет подразумевать единственно правильный способ -выполнения задач (performing tasks) программной инженерии. Такое предположение -заведомо отбрасывается SWEBOK, так как “единственно правильного” процесса быть -не может. Такие стандарты, как IEEE/ISO/ГОСТ 12207 говорят о процессах (во -множественном числе - processes), подразумевая что программная инженерия -содержит множество процессов, например, процесс разработки (Development -Process) и процесс конфигурационного управления (Configuration Management -Process). -- Вторая интерпретация связана с общим (general) обсуждением процессов, -связанных с программной инженерией. Данная точка зрения отражена в названии -этой области знаний и является одной из наиболее часто подразумеваемых при -использовании термина “процесс программной инженерии”. -- Наконец, третье понимание данного термина может означать реальный набор -действий, предпринимаемых в данной организации и рассматриваемый как единый -процесс на уровне организации. Такой подход также рассматривается в данной -области знаний (та или иная интерпретация обычно зависит от контекста -обсуждения). - -Данная область знаний связана со всеми элементами управления процессами -жизненного цикла программного обеспечения, в которых процедурные -(управленческие) или технологические изменения применяются к совершенствованию -процесса или продукта. - -Процесс программной инженерии касается не только крупных организаций. Более -того, связанные с данным процессом действия могут и должны применяться -небольшими организациями, командами и отдельными специалистами. - -Цель управления процессами программной инженерии состоит в реализации новых и -лучших процессов в реальной практике конкретных специалистов, проектов или -организации (отдельных ее групп подразделений или организации, в целом). -Данная область знаний не адресуется напрямую вопросам управления персоналом -(human resources management, HRM). Эти темы исследуются, например, в People CMM -(People Capabililty Maturity Model) и процессах системной инженерии (см. -стандарты ISO 15288 “Systems Engineering - System Life Cycle Process” и IEEE -1220 “Standard for the Application and Management of the Systems Engineering -Process”). - -Также, необходимо понимать, что многие процессы программной инженерии -порождаются и тесно связаны с другими дисциплинами, например, управлением -(management), хотя иногда эти процессы и называют по-другому в контексте этих -дисциплин. - -![Рисунок 1. Область знаний “Процесс программной инженерии” [SWEBOK, 2004, с.9-2, рис. 1]](images/process_area_small.jpg) - -## Реализация и изменение процесса (Process Implementation and Change) - -Данная секция фокусируется на организационных изменениях. Она описывает -инфраструктуру, действия, модели и практические соображения по реализации -процесса и его изменении. - -Ниже рассматривается ситуация, в которой те или иные процессы реализуются -впервые (например, процесс проведения инспекций в проекте или охват полного -жизненного цикла программного обеспечения) и где изменяются уже существующие -(используемые) процессы. Речь пойдет о том, что называют эволюцией процесса -(process evolution). Существующие практики рассматриваются в контексте часто -необходимой модификации. Если требуемые модификации достаточно обширны, это -приводит и к необходимости изменения организационной культуры. - -### Инфраструктура процесса (Process Infrastructure) - -Эта тема охватывает знания, связанные с инфраструктурой процесса программной -инженерии и, в большой степени, базируется на стандартах IEEE/ISO/ГОСТ 12207 -“Standard for Information Technology - Software Life Cycle Processes” и ISO -15504 “Information Technology - Software Process Assessment” (известен также -как SPICE - Software Process Improvement and Capability dEtermination). - -Для внедрения процессов жизненного цикла необходимо обладать соответствующей -инфраструктурой, подразумевая, что ресурсы (компетентный персонал, инструменты, -финансирование) – доступны, а ответственность – распределена <по членам -проектной команды и/или организационной единицы, в терминах структуры компании -или организации, например, отдела или группы>. Выполнение этих задач является -хорошим индикатором того, что менеджмент <управленческий персонал -проекта/организации> реально прилагает усилия по поддержке процесса программной -инженерии. Как следствие таких усилий могут создаваться различные комитеты и -другие специализированные организационные структуры и органы, в общем случае -называемые steering committee – “управляющий комитет”, обладающий -наблюдательными функциями в отношении усилий, направленных на мониторинг, -контроль и выработку рекомендаций по поддержке и улучшению процесса -программной инженерии. На основе таких функций будем в дальнейшем использовать -термин “наблюдательный орган”, подчеркивая реальные задачи такой комиссии и -возможность как формальной, так и неформальной его организации. - -Наблюдательный орган является основой процессной инфраструктуры в проектной -команде, подразделении или организации, в целом. Обычно, выделяют два типа -инфраструктуры, применяемые на практике Software Engineering Process Group -(SEPG, обычно, в русском языке для такой структуры используется приведенная -англоязычная аббревиатура) и Experience Factory (EF, “фабрика опыта”). - -#### Software Engineering Process Group (SEPG) - -SEPG создается как центральный орган, принимающий на себя работу по -process improvement - совершенствованию процесса(-ов). SEPG берет на себя -ответственность по множеству вопросов, связанных с этой задачей в терминах -инициирования <улучшений> и поддержки <существующего процесса и его постоянного -совершенствования>. - -Часто SEPG формируется из нескольких ведущих членов проектной команды (если, -SEPG создается в рамках проекта) или на уровне подразделения или всей -организации. При этом, в большинстве случаев, SEPG не включает “освобожденных” -специалистов и, таким образом, ее члены всегда находятся в контексте реальных -проблем, с которыми сталкиваются выполняя свои “основные” обязанности. -Исключение, обычно, составляют SEPG, формируемые для достижения определенных -организационных целей - приведения процессов в соответствие тем или иным -требованиям и, в частности, для достижения того или иного уровня зрелости CMMI, -обеспечения качества в рамках ISO или SixSigma и т.п. В этих случаях SEPG -обычно возглавляется выделенным экспертом (или группой) в области постановки и -совершенствования процессов. - -#### Experience Factory (EF) - -Концепция “фабрики опыта” отделяет проектную организацию (например, -организационную структуру, отвечающую за разработку программного обеспечения – -ИТ-подразделение, группу разработки или проектную команду) от организации, -отвечающей за улучшение процесса. Проектная организация, в этом случае, -фокусируется на разработке и сопровождении программного обеспечения, а EF – -занята совершенствованием процесса программной инженерии. - -Основной задачей EF является институализация (внедрение в повседневную -практику) коллективного опыта и полученных уроков в масштабах организации на -основе разработки, обновления и внедрения в проектную организацию “пакетов -опыта” – experience packages (например, руководств, моделей, курсов обучения и -т.п.), <типовых> “активов процесса” – process assets. Проектная организация -предлагает на рассмотрение EF свои продукты, планы, использовавшиеся при -разработке, а также данные, собранные в процессе разработки и эксплуатации. - -Cложно провести четкую грань между SEPG и EF. Скорее, можно говорить о создании -SEPG в форме “фабрики опыта” в крупных ИТ-подразделениях, например, -международных компаний, или достаточно крупных организациях, основной -деятельностью которых является создание программного обеспечения. В этом случае -SEPG проводит пилотное внедрение усовершенствованных или новых процессов в -рамках одного или нескольких выбранных проектов и, затем, распространяет этот -опыт во всей организации. Так или иначе, отдача от SEPG/EF обычно заметна в -проектно-ориентированных или проектных организациях, чья деятельность построена -в форме управления портфелем проектов (более подробную информацию о -проектно-ориентированных организациях можно, например, найти в PMI PMBOK и -других материалах Project Management Institute). В общем случае, говоря об -инфраструктуре процессов, обычно используют именно термин SEPG для обоих типов -организации команд, фокусирующихся на процессе разработки программных систем. - -### Цикл управления программным процессом (Software Process Management Cycle) - -Управление процессами в области программного обеспечения состоит из четырех -действий, представленных в рамках итеративного цикла. Это позволяет получать и -анализировать отклики на постоянной основе и, <более оперативно> -совершенствовать процесс. Вот эти четыре действия, предлагаемые SWEBOK: - -- Establish Process Infrastructure – создание инфраструктуры процесса. Задачи – -обеспечить согласие и поддержку заинтересованных лиц (в первую очередь, -менеджмента) в работах по реализации и изменении процесса; получить возможность -развернуть соответствующую инфраструктуру процесса, выделив необходимые ресурсы -и обеспечив распределение обязанностей (ответственности). -- Planning – планирование. Задача (цель) – понять (сформулировать) текущие -бизнес-цели и потребности в процессе, необходимые отдельным специалистам, -проекту и/или организации, в целом; идентифицировать сильные и слабые стороны -(см. концепцию SWOT-анализа в различных источниках) <существующего процесса и -планируемых на данной итерации нововведений и/или изменений> и разработать план -реализации и изменения процесса. -- Process Implementation and Change – реализация и изменение процесса. Задача -(цель) – выполнение разработанного плана по внедрению нового и/или -модифицированного процесса (включая, например, если это необходимо, -развертывание новых инструментов или проведение тренингов). В результате -заданный процесс должен быть внедрен в практику. -- Process Evaluation – оценка процесса. Задача (цель) – понять, насколько -хорошо процесс реализован, получены или нет ожидаемые преимущества от его -внедрения. Результат анализа становится “входом” для следующей итерации. - -### Модели реализации и изменения процесса (Models for Process Implementation and Change) - -Существует две распространенные модели внедрения процесса – Quality Improvement -Paradigm – QIP (Software Engineering Laboratory, Software Process Improvement -Guidebook, NASA/GSFC, Technical Report SEL-95-102, April 1996, -http://sel.gsfc.nasa.gov/website/documents/online-doc/95-102.pdf) и -разработанная в Институте программной инженерии Университета Карнеги-Меллон SEI -CMU модель IDEAL (Initiating – Diagnosing – Establishing – Acting – Learning). -Во всех случаях оценка может проводиться по качественным и/или количественным -показателям. - -На сегодняшний день наиболее проработанными и распространенными стандартами -оценки и совершенствования процесса программной инженерии являются CMMI (де -факто стандарт) и SCAMPI (разработанная в SEI CMU стандартная методика оценки -совершенствования процессов – Standard CMMI Appraisal Method for Process -Improvement), а также в ISO/IEC 15504 (де юро стандарт), также известном как -SPICE (Software Process Improvement and Capability Determination) и -разработанным для аттестации зрелости процессов. - -### Практические соображения (Practical Considerations) - -Реализация и изменение процесса является составной частью организационных -изменений. В большинстве успешных случаев усилия, направленные на -организационные изменения рассматриваются как самостоятельный проект со своими -(соответствующими) правами, планами, ресурсами и т.п. - -Обычно составляются соответствующие руководства (guidelines) по реализации и -изменению процесса, включая разработку плана действий (action plan), проводятся -тренинги, согласуется поддержка менеджмента (желательно, высшего -управленческого звена), отбираются пилотные проекты, в которых впервые будут -задействованы соответствующие процессы и инструменты и т.п. Такие рекомендации -можно найти во многих источниках, в том числе, и в указанных в оригинальной -версии SWEBOK. Также, можно найти множество отчетов и исследований по факторам -успеха, значимым для внедрения и изменения процесса (например, многие из таких -исследований связаны с моделью CMMI и представлены на сайте SEI CMU -http://sei.cmu.edu/). - -SWEBOK также отмечает роль “агентов” изменений, как лиц, часто создающих -предпосылки, инициирующих изменения, а также специалистов, постоянно -реализующих изменения в своей практике. Естественно, что реализация и изменение -процесса может рассматриваться как консалтинг. Он может быть внутренний -(например, проводимый силами специалистов SEPG) или внешний (с привлечением -экспертов из других подразделений и организаций, часто специализирующихся в -данной области так же, как мы видим консультантов и внешних управляющих в -области проектного менеджмента). Практика показывает, что достаточно успешным -является подход, предполагающий совместную работу внешних и внутренних -консультантов SEPG, так как в этом случае легче отойти от сложившихся внутри -организации шаблонов восприятия и обеспечить свежий взгляд на возможности и -потенциальную отдачу в совершенствовании процесса, конечно, с учетом опыта -вовлеченных в эти работы специалистов. - -Кроме того, можно увидеть организационные изменения в контексте внедрения тех -или иных технологий (в SWEBOK используется термин technology transfer). При -этом, эти технологии могут касаться как непосредственно самого программного -обеспечения, так и связаны с самим процессом (например, технологии -моделирования). - -Существует два распространенных подхода к оценке реализации и изменения -процесса. Они состоят в оценке самого процесса и в оценке результатов процесса -(process outcomes), соответственно. - -## Определение процесса (Process Definition) - -Определение процесса может быть процедурой, рекомендацией или стандартом. -Процессы жизненного цикла программного обеспечения четко определяются по разным -причинам, в частности, с целью повышения качества получаемого продукта, -улучшения коммуникаций и улучшения понимания различных аспектов программной -инженерии отдельными специалистами, поддержки совершенствования процессов, -поддержки управления процессами, обеспечения автоматизации процессов и т.п. -Используемые типы описаний процессов, часто, зависят (как минимум, частично) от -целей определения процессов. - -Также необходимо отметить, что проектный и организационный контексты помогают -определить наиболее подходящие определения процессов. Важными факторами при -определении процесса являются природа работ (например, разработка или -сопровождение), прикладная область (application domain), модель жизненного -цикла и зрелость самой организации. - -### Модели жизненного цикла программного обеспечения (Software Life Cycle Models) - -Модели жизненного цикла задают высокоуровневое определение фаз (стадий) -разработки программного обеспечения. Их целью не является предоставление -детального определения, но концентрируется на ключевых работах и их -взаимосвязях. Примерами таких моделей[^17] являются водопадная -(каскадная - waterfall), модель прототипирования, эволюционной разработки, -инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения -и критерии выбора моделей, ссылки на некоторые из которых, в частности, даны в -оригинальной версии SWEBOK. - -[^17]: Базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе. - -### Процессы жизненного цикла программного обеспечения (Software Life Cycle Processes) - -Определения процессов жизненного цикла обычно являются более детальными, чем -модели. Однако, определения процессов не описывают порядка их выполнения во -времени (за это как раз и отвечают модели, прим. автора). Это означает, что, в -принципе, процессы жизненного цикла программного обеспечения могут быть -“выстроены” (во времени) соответственно любой модели жизненного цикла. Основным -источником знаний по процессам является стандарт IEEE/ISO/ГОСТ 12207 -“Information Technology – Software Lifecycle Processes” (основные элементы -структуры этого стандарта рассматривается за рамками перевода и комментариев -SWEBOK в самостоятельной главе, посвященной жизненному циклу). - -В рамках данных понятий жизненного цикла - “модель” и “процессы”, возможно -говорить, что совокупность модели, процессов и практик определяет -метод/методологию поддержки жизненного цикла. - -Стандарт IEEE 1074 “Standard for Developing Software Life Cycle Processes” -предоставляет список процессов и действий по разработке и сопровождению -программного обеспечения, а также список действий по поддержке самого -жизненного цикла, который может быть отображен на процессы и организован таким -же образом, как и любая модель жизненного цикла. Кроме того, этот стандарт -идентифицирует и связывает другие стандарты IEEE с действиями по поддержке -процессов жизненного цикла. В принципе, стандарт IEEE 1074 может быть -использован для построения процессов, соответствующих любой модели жизненного -цикла. - -SWEBOK отмечает два стандарта, связанных с процессами сопровождения -программного обеспечения – IEEE 1219 “Standard for Software Maintenance” и ISO -14764 “Standard for Software Engineering -Software Maintenance” (см. область -знаний SWEBOK “Сопровождение программного обеспечения”). - -Другие важные стандарты, предоставляющие определение процессов, включают: - -- IEEE 1540: Standard for Software Risk Management – управление рисками -программного обеспечения -- IEEE 1517: Standard for Software Reuse Processes – процессы повторного -использования программного обеспечения -- ISO/IEC 15939: Standard for Software Measurement Process – процесс измерений -в области программного обеспечения - -В ряде ситуаций процессы программной инженерии определяться принимая во -внимание организационные процессы управления качеством. ISO 9001 формулирует -требования к процессам управления качеством, а ISO 9003 интерпретирует эти -требования в отношении организаций, занимающихся разработкой программного -обеспечения (ISO/IEC 90003:2004, Software and Systems Engineering - Guidelines -for the Application of ISO9001:2000 to Computer Software). - -Некоторые процессы жизненного цикла придают особое значение быстрому вводу в -эксплуатацию (rapid delivery) программных систем и глубокой вовлеченности -пользователей <в процесс разработки>. Такие процессы называют agile-методами – -быстрыми, живыми, подвижными. К ним относится, например, экстремальное -программирование – eXtreme Programming (XP, см. работы Кента Бека – Kent Beck). -Отличительной особенностью этих методов является гибкость в вопросах -планирования, когда план проекта активно корректируется по мере продвижения к -цели проекта. Другие процессы уделяют специальное внимание принятию решений на -основе оценки рисков (см. работы Барри Боэма – Barry W. Boehm). - -### Нотации определения процесса (Notations for Process Definitions) - -Процессы могут определяться на различных уровнях абстракции. В свою очередь, -могут быть определены и различные элементы процессов – действия, продукты -(артефакты) и ресурсы. При этом, могут использоваться детальные фреймворки, -структурирующие типы информации, требуемой для определения процессов. - -Существует ряд нотаций, используемых для определения процессов. Ключевое -отличие между ними заключается в типах информации, которая определяется, -контролируется и используется тем или иным фреймворком. Инженеры должны иметь -представление о следующих подходах: диаграммах потоков данных (data flow -diagrams), в терминах целей процессов и получаемых на их выходе результатов -(outcomes) (см. стандарт ISO 15504 “Information Technology - Software Process -Assessment” - “SPICE”), как наборе процессов и их декомпозиции в работы и -задачи, определенный на естественном языке (см. стандарт IEEE/ISO/ГОСТ 12207), -диаграммах переходов и состояний (statechart), SADT, IDEF0 и многих других. - -Хотя SWEBOK приводит расширенный список диаграмм/нотаций, вероятно, в силу -своей “консервативности”, не упоминает, например, activity-диаграммы UML, хотя -они могут использоваться в практике для описания бизнес-процессов, в частности, -и для описания процессов программной инженерии. Ряд нотаций разработан и -используется в рамках конкретных (частных) фреймворков/методологий, например, -RUP. Кроме того, существует успешный опыт по использованию достаточно нотации -BPMN – Business Process Management Notation для описания процессов программной -инженерии. Спецификация BPMN определяет графическое представление -бизнес-процессов в форме диаграмм бизнес-процессов – Business Process Diagram -(BPD). Первый стандарт BPMN был выпущен 3 мая 2004 года консорциумом The -Business Process Management Initiative – BPMI.org (http://www.bpmi.org). -Предоставляя развитые выразительные средства для определения процессов как -комплекса взаимосвязанных действий, событий и артефактов, сгруппированных по -участникам, BPMN позволяет достаточно легко сформировать в рамках одной -диаграммы BPD цельный взгляд на процессы. - -### Адаптация процесса (Process Adaptation) - -Важно отметить, что предопределенные процессы, даже стандартизированные, должны -адаптироваться в соответствии с локальными (конкретными) потребностями, -например, организационным контекстом, размером проекта, регулирующих -требованиях, индустриальных практиках и корпоративной культурой. Ряд -стандартов, в первую очередь, IEEE/ISO/ГОСТ 12207 и ISO 15504, содержат -механизмы и рекомендации по процессу адаптации и его совершенствованию. - -### Автоматизация (Automation) - -Автоматизированные средства либо поддерживают сами работы по определению -процессов (например, позволяя описывать процессы с использованием тех или иных -диаграмм и нотаций) и/или предоставляют соответствующие руководства по -определению процессов (например, RUP, EUP или MSF). В случаях, когда проводится -процесс анализа, некоторые инструменты обеспечивают различные формы симуляции -моделируемых (определяемых) процессов. - -## Оценка процесса (Process Assessment) - -Оценка процесса (process assessment) проводится с использованием -соответствующих моделей оценки (assessment models) и методов оценки (assessment -methods). Во многих случаях вместо термина “assessment” используется термин -“appraisal” (подразумевая саму процедуру оценки, например, CMMI Appraisal). В -свою очередь, термин “appraisal” заменяют на “capability evaluation”, когда -говорят об оценке способностей/потенциальных возможностей, например, с целью -заключения контракта/договора подряда на проведение соответствующих работ. - -Оценка процесса(-ов) может проводиться как неформально, подразумевая часто -внутрикорпоративные инициативы по повышению качества, и формально (то есть с -получением аттестационного документа), в том числе, с привлечением внешних -специалистов по оценке и, часто, с целью подтверждения соответствующего -качества/уровня зрелости процессов. - -### Модели оценки процесса (Process Assessment Models) - -Модель оценки задает, что именно признается лучшими практиками оценки. Эти -практики могут касаться только “технических” работ программной инженерии -(например, проектирования или кодирования), а могут иметь отношение и к -вопросам управления, системной инженерии, управления персоналом и т.п. - -Стандарт ISO/IEC 15504 (SPICE) определяет типовую (exemplar) модель оценки и -требования соответствия к другим моделям. В каждом конкретном случае -используется та или иная существующая модель – CMM-SW, CMMI, -Bootstrap[^18]. Также имеются и другие модели, например, ISO 9000-3 -(теперь именуемый как ISO 90003) “Software and Systems Engineering - Guidelines -for the Application of ISO9001:2000 to Computer Software”, являющаяся -приложением общей модели качества ISO 9001 “Quality Management Systems - -Requirements” к программной инженерии. Кроме того, существуют частные модели, -охватывающие, например, только вопросы документирования, проектирования и т.п. - -[^18]: В 1990 году стартовала европейская инициатива European Strategic Program for -Information Technology (ESPRIT), целью которой было внедрение современных -программных технологий в Европе. В основу инициативы легли работы Уотса Хампфри -(Watts S. Humphrey) – идеолога CMMI, PSP (People Software Process) и многих -других современных концепций программной инженерии как дисциплины. Результат -этот инициативы был назван “Bootstrap” – “самонастройка”. В то время, как -модель CMM – Capability Maturity Model (в частности, CMM-SW – CMM for -Software), а потом и CMMI, разрабатывались с учетом потребностей крупных -государственных структур США (в первую очередь, министерства обороны) и их -подрядчиков, модель Bootstrap изначально была ориентирована на малые и средние -коммерческие компании, с определенным акцентом на индивидуальные практики. - -Также и в системной инженерии существуют модели зрелости, применимые в -отношении программного обеспечения, когда программы являются частью системы. - -SWEBOK отмечает, что ряд моделей применим к небольшим организациям. - -Существуют две основных архитектуры моделей оценки: непрерывная (continuous) и -этапная (staged). Отличия между ними заключаются во взгляде на порядок оценки -процессов. Выбор соответствующей архитектуры и модели оценки в конкретной -организации должен базироваться на ее целях и потребностях (например, -необходимости совершенствования тех или иных процессных областей или -официального подтверждения внешним асессором достижения организацией четвертого -уровня зрелости всего процесса программной инженерии по CMMI). - -### Методы оценки процесса (Process Assessment Methods) - -Для надлежащего проведения оценки соответствующие методы <оценки> позволяют -получить количественные параметры, характеризующие возможности оцениваемого -процесса (или зрелости организации, в целом). - -Например, метод CBA-IPI (CMM-Based Appraisals for Internal Process Improvement) -фокусируется на совершенствовании процесса внутри организации, а метод SCE -(Software Capability Evaluation) касается процессов у подрядчиков[^19]. -Требования в обоих типах методов отражают те лучшие практики оценки, которые -описаны в стандарте ISO 15504. Эти методы были разработаны для модели CMM-SW. С -выходом CMMI (интегрированной модели, объединяющей различные модели CMM), -соответственно, получило развитие новое семейство методов - SCAMPI (Standard -CMMI Appraisal Method for Process Improvement). Деятельность, выполняемая в -процессе оценки, распределение усилий по соответствующим работам и общая -атмосфера оценки (касающаяся, в первую очередь, степени формализации, -сопутствующей оценке) могут серьезно отличаться, в зависимости от того, -направлена ли оценка на совершенствование процессов или проводится в контексте -контракта/договора подряда. - -[^19]: SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment -– внутренняя деятельность в организации, направленная на оценку и -совершенствование собственного процесса в рамках всей организации. Evaluation -подразумевает аудит и мониторинг процессов поставщика (подрядчика, исполнителя) -со стороны заказчика, в первую очередь, в процессе самого выполнения работ, -т.е. уже после заключения контракта/договора подряда. CBA-IPI относится к общей -категории методов Software Process Assessment (SPA) как части работ по -совершенствованию процессов – Software Process Improvements (SPI). SPI как -деятельность по совершенствованию процесса(-ов) сегодня считается достаточно -общим термином, используемым за рамками CMM/CMMI, например, в контексте таких -фреймворков, как ISO 15504 или TQM (Total Quality Management). - -Существует определенная критика моделей, методов (да и самой идеи) оценки. -Такая критика, обычно, основана на эмпирической природе оценки. Однако, по -прошествии определенного периода времени, после публикации таких критических -материалов, опыт и практика индустрии сформировали достаточно четкие -доказательства (в том числе, собрав необходимые статистические данные – см. -отчеты SEI CMU по результатам внедрения и использования CMMI) обоснованности -современных принципов, моделей и методов оценки. - -## Измерения в отношении процессов и продуктов (Process and Product Measurement) - -В силу того, что приложение количественных оценок к программной инженерии может -быть достаточно сложным, в частности, в терминах моделирования или методов -анализа, существует ряд фундаментальных аспектов измерений в программной -инженерии, лежащих в основе многих более детальных измерений и процессов -анализа. Более того, результаты усилий по совершенствованию процессов и -продуктов, могут быть оценены только в том случае, если установлены -количественные характеристики заданных параметров <процессов и продуктов> для -заданных вех или, более точно (так как измерения, все же, выходят за рамки вех -конкретных проектов, если, конечно, сама SPI-деятельность не позиционировать -как проект, что, конечно, возможно), так называемых “базовых линий” -(baseline[^20]). - -[^20]: Термин baseline обычно используется в контексте управления изменениями, -требованиями и, часто, конфигурациями, в целом, для именования временных -“срезов” всего комплекса соответствующих активов. - -Измерения могут проводиться для поддержки инициирования реализации и изменения -процессов и для оценки результатов таких работ. Также, измерения могут -выполняться и в отношении самих продуктов. - -Ключевые понятия, термины и методы измерений в приложении к программному -обеспечению определены в стандарте ISO 15939 “Software Engineering - Software -Measurement Process” и международном словаре метрологии ISO. ISO 15939 также -определяет стандартный процесс для измерения характеристик процессов и -продуктов. - -Необходимо отметить, что в литературе встречаются некоторые терминологические -отличия, например, термин “метрика” (metric) часто используется вместо термина -“измерение” (measure)[^21]. - -[^21]: В данном переводе эти термины используются взаимозаменяемым образом, за -исключением случаев, когда контекст обсуждения предполагает разделение процесса -измерения – “измерения”, как такового, и критериев/параметров или результатов -измерения – “метрик”. - -### Измерения в отношении процессов (Process Measurement) - -Используемый здесь термин “process measurement” – “измерения в отношении -процесса” подразумевает сбор, анализ и интерпретацию количественной информации -о процессе. Измерения используются для идентификации сильных и слабых сторон -процесса (strengths and weaknessess) и для оценки процесса после того, как он -реализован и/или изменен. - -Также, проведение количественной оценки процесса может преследовать и другие -цели. Например, соответствующие измерения полезны для управления программными -проектами. В обсуждаемом здесь контексте, фокус измерений в отношении процессов -направлен на оценку реализации и/или изменения процесса. - -Рисунок 2 иллюстрирует важность предположений, делаемых в большинстве -программных проектов, в которых процесс непосредственно влияет на результаты -проекта. Соответствующий контекст воздействует на связь между процессом и его -результатом. Другими словами, это означает, что связь процесс-результат -процесса находится в зависимости от контексте. - -![Рисунок 2. Связь между процессом и его результатами (или "выходом процесса" - process outcome).](images/process_in-out.jpg) - -Далеко не каждый процесс обладает положительным влиянием на получаемые -результаты. Например, внедрение инспекции <получаемого> программного -обеспечения может сократить усилия и стоимость по тестированию, но может и -увеличить время, если каждая инспекция приводит к нарушению расписания просто в -силу продолжительности соответствующих инспекционных действий. Поэтому, -рекомендуется использовать множество метрических показателей (метрик), по -которым оценивается процесс и его результат(ы), безусловно, в контексте -значимых для бизнеса характеристик. - -Хотя определенные усилия могут направляться на решение вопросов использования -соответствующего инструментария, главный ресурс, который нуждается управлении – -персонал. Как результат, наиболее важные метрики касаются оценки продуктивности -команд и процессов (например, может использоваться оценка функциональных точек, -производимых на единицу трудозатрат[^22]. – “person-effort”), а также, -ассоциированного с этим уровня опыта в программной инженерии, в целом, и в -отдельных технологиях, в частности. - -[^22]: Трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или -“человеко-месяц”; здесь полезно обратиться к юбилейному второму изданию -классического труда Фреда Брукса “Мифический человеко-месяц” [Брукс, 1995]. - -Результаты процесса могут, например, оцениваться в отношении качества продукта -(как число сбоев на тысячу строк кода – KLOC, Kilo-Lines of Code или на -функциональную точку – FP, Function Point), сопровождаемость (усилия, -необходимые для реализации определенного типа изменений), продуктивность (LOC, -Lines Of Code или FP за человеко-месяц), время вывода продукции на рынок -(time-to-market) или степень удовлетворенности потребителей (по измерениям -результатов опросов пользователей). Метод оценки связи между процессом и его -“выходом” (результатом) зависит от конкретного контекста, например, масштабов -(размеров) организации. - -В общем случае, мы фокусируемся на результатах процесса. Однако, для достижения -заданных результатов (например, в терминах более высокого качества, лучшей -сопровождаемости, большей удовлетворенности пользователей) мы должны внедрить -соответствующие процессы. - -Конечно, не только процессы непосредственно влияют на результат <проекта>. -Существуют и другие факторы, играющие не менее важную роль, например, -возможности инструментов и потенциал, знания и опыт специалистов. Когда -оценивается влияние изменения процессов, такие факторы должны учитываться -(например, попытка внедрения развитых процессов программной инженерии при -отсутствии ресурсов или в неподготовленной организационной среде практически -наверняка приведет к краху таких инициатив). Кроме того, важна степень -институализации процессов (process institualization или process fidelity – -следование заданным процессам как повседневная практика работы). Фактор -институализации в большинстве случаев объясняет, почему “хорошие” процессы не -приводят к желаемому результату, когда процессы полностью или частично остаются -лишь на бумаге. - -### Измерения в отношении программных продуктов[^23] (Software Product Measurement) - -Измерения в отношении программного продукта включают количественную оценку его -размера, структуры и качества. - -[^23]: Данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке -оригинального варианта SWEBOK 2004, поэтому, далее, нумерация тем смещена. - -#### Оценка размера (Size measurement) - -Размер программного продукта чаще всего оценивается по его “длине” (например, в -количестве строк кода в модулях, страниц спецификаций требований и других -документов) или функциональности (например, по количеству функциональных точек -в спецификации). Принципы количественной оценки “функционального” размера -программного обеспечения описываются в стандартах: - -- IEEE 14143-1 “Information Technology - Software Measurement - Functional Size -Measurement - Part 1:Definitions of Concepts” -- ISO 19761 “Software Engineering - Cosmic FPP - A Functional Size Measurement -Method” -- ISO 20926 “Software Engineering - IFPUG 4.1 Unadjusted Functional Size -Measurement Method-Counting Practices Manual” -- ISO 20968 “Software Engineering-MK II Function Point Analysis – Counting -Practices Manual” - -#### Оценка структуры (Structure measurement) - -Существует широкий спектр метрик, которые можно использовать для оценки -структуры программного обеспечения – в отношении высокоуровневого и -низкоуровневого дизайна, а также артефактов кода для анализа потоков работ, -потоков данных, вложенности <вызовов>, структур контроля, модульности, -взаимодействия и т.п. - -#### Оценка качества (Quality measurement) - -Качество, как многомерная характеристика программного обеспечения, наиболее -сложно для количественной оценки, в отличие от других характеристик, описанных -выше. Более того, некоторые параметры качества требуют, в большей степени, -применения качественной, а не количественной оценки. Детальное обсуждение -вопросов оценки качества представлено в области знаний SWEBOK “Software -Quality” (тема 3.4). ISO разработала соответствующие модели качества -программного обеспечения и связанных с ним метрик (см. стандарт ISO 9126 -“Software Engineering - Product Quality”, части 1-4). - -### Качество результатов измерений (Quality Of Measurement Results) - -Качество результатов измерений (точность, воспроизводимость, повторяемость, -изменяемость, случайность ошибок измерений) является основой программ -проведения количественных оценок для получения эффективных и ограниченных -(ограниченного количества значимых) результатов. Ключевые характеристики -результатов измерений и связанного с ними качества инструментов измерения (в -первую очередь, обоснованности используемого математического аппарата) -определены в международном словаре метрологии ISO (International vocabulary on -metrology). - -Теория количественной оценки устанавливает основу для возможных измерений. -Измерения (и соответствующие типы “размерностей” или “шкал”) описаны в этой -теории как систематическое определение численных величин для представления -свойств объектов SWEBOK подчеркивает важность определения масштабов измерений и -понимания каждого типа “размерности” (как мы увидим далее, под этим термином -могут подразумеваться определенные категории метрических показателей - метрик) -с учетом связи с последующим выбором методов анализа данных. Выразительная -сторона размерностей связана с классификацией метрик. Для этого теория -количественных оценок предлагает последовательность наложения все более -детальных ограничений для выделения соответствующих (и все более -специализированных) групп метрик. Если метрические показатели используются -только для отметки объектов с целью классификации (например, в простейшем -случае, бинарной классификации - “да/нет”, “удовлетворяет/не удовлетворяет”), -такие значения называют номинальными (nominal). Если значения определяются для -ранжирования (ranking) объектов (например, “хороший”, “лучший чем”, “наилучший -”), эти показатели называют порядковыми (ordinal). Если величины метрических -показателей определяются относительно заданных единиц измерений, такие -показатели называют интервальными (interval). Наконец, встречаются -пропорциональные (ratio) показатели (основывающиеся на оценке взаимного -отношения различных значений показателей, каждое из которых измеряется разницей -между величиной показателя и нулем). - -Хотелось бы обратить внимание на описание концепции и использования метрических -показателей в специальной главе “Метрические показатели, применяемые при оценке -размера программ” русского перевода книги “Управление программными проектами” -[Фатрелл, Шафер и Шафер, 2003, глава 21, с.692-748]. - -### Информационные модели (Software Information Models) - -По мере сбора данных и наполнения ими репозитория измерений, становится -возможно построить соответствующие информационные модели на основе собранных -данных и имеющихся знаний. - -Эти модели применяются для анализа, классификации и предсказания <характеристик -и поведения измеряемых объектов>. Оценка моделей необходима для обеспечения -достаточной степени точности и понимания их ограничений. Также необходимо -отметить важность работ, направленных на уточнение моделей как в процессе -ведения проекта, так и после его завершения. - -#### Построение модели (Model building) - -Построение модели включает калибрование и оценку модели. Ориентированный на -цель подход к измерениям наполняет процесс построения модели необходимым -содержанием, то есть модель конструируется для ответа на значимые вопросы и -достижения целей совершенствования создаваемого программного обеспечения. На -этот процесс также оказывают влияние неявные ограничения используемых -метрических показателей и связанных с ними методов анализа. Модель калибруется -и оценивается на основании уже накопленных результатов наблюдений (например, по -недавно выполненным проектам или проектам, аналогичным данному по используемым -технологиям и т.п.) и сравнения ее эффективности с точки зрения соответствия -прогнозов реальным данным. - -#### Внедрение модели (Model implementation) - -Внедрение модели включает интерпретацию и уточнение моделей. Откалиброванные -модели применяются в отношении процесса, их результаты интерпретируются и -оцениваются в контексте процесса/проекта, после чего модели уточняются в тех -аспектах, где это необходимо. - -### Техники количественной оценки процессов (Process Measurement Techniques) - -Определенные техники измерения процесса могут использоваться для анализа -процессов программной инженерии и идентификации их преимуществ и недостатков -(сильных и слабых сторон). Такие техники применяются во многих случаях для -инициирования или оценки влияния (последствий) внедрения или изменения -процессов. - -Качество результатов измерений, в терминах точности, повторяемости и -воспроизводимости, связано с инструментальной составляющей и используемой -концепцией оценки и точкой зрения в отношении измерений (например, когда -оценивающее лицо – асессор - выставляет оценки по конкретным процессам). - -Техники измерения процесса классифицируются по двум типам: аналитическая и -эталонная (benchmarking). Эти два типа используются вместе, так как -основываются на различных типах информации. - -#### Аналитические техники (Analytical techniques) - -Аналитические техники характеризуются, как зависящие от “количественных -свидетельств того, где необходимы усовершенствования и где инициативы по -совершенствованию оказались успешны“. Аналитический тип, иллюстрируемый, -например, подходом QIP (Quality Improvement Paradigm) состоит из цикла -“понимание-проверка-приложение”. Техники, представленные ниже, приведены в -качестве других примеров аналитического подхода к измерениям и отражают -достаточно типичную практику реализации такого <аналитического> взгляда на -проведение количественной оценки. Будут или нет использоваться эти техники в -практике конкретной организации зависит, как минимум, от зрелости ее -организационной культуры и используемых процессов. - -- Экспериментальные исследования (Experimental Studies). Проводятся в -специально подготовленном “окружении” для оценки <нового или измененного> -процесса. Обычно новый (или измененный) процесс сравнивается с существующим для -определения того, в какой степени “старый” процесс дает лучшие результаты, по -сравнению с новым процессом. - -Другой тип экспериментальных исследований – “симуляция” процесса (моделирование -его поведения и результатов, прим. автора). Этот тип исследований может -использоваться для анализа поведения процесса, выяснения потенциальных -возможностей усовершенствования процесса, предсказания результатов процесса -(для того случая, если существующий процесс изменяется определенным образом) и -контроля выполнения процесса. В качестве первичных данных для симуляции -процесса, обычно, используются данные текущего (существующего) процесса. -- Обзор (оценка) определения процесса (Process Definition Review) -подразумевает, каким образом оценивается определение процесса для идентификации -его недостатков и потенциальных аспектов совершенствования. Один из легких -способов анализа процесса – сравнение его с существующими стандартами -(например, IEEE/ISO/ГОСТ 12207). При таком подходе метрические показатели -обычно не собираются, или, в случае их наличия, играют лишь “поддерживающую” -(второстепенную) роль. Специалисты, выполняющие анализ определения процесса, -используют свои знания, опыт и другие возможности для принятия решения какие -изменения процесса могут потенциально привести к желаемому результату в -отношении “выходов” процесса (получаемого программного продукта или его -отдельных элементов). Наблюдения (observations) за выполнением процесса также -могут дать дополнительные данные, позволяющие идентифицировать возможные пути -совершенствования процесса. -- Ортогональная классификация дефектов (Orthogonal Defect Classification) – -техника, которая может быть использована для связывания (отображения) сбоев с -их потенциальными причинами. В данном контексте может быть полезен для -детального ознакомления стандарт IEEE 1044 “Standard for the Classification of -Software Anomalies”, классифицирующий возможные сбои (аномалии) в работе -программного обеспечения. -- Анализ причин (Root Case Analysis) является еще одной популярной техникой, -часто используемой на практике. Эта техника предполагает “спуск” от -обнаруженного сбоя к идентификации его причины, изменяя сам процесс (или, по -аналогии, код программного обеспечения, если бы речь шла о поиске дефекта, -приводящего к сбою) до тех пор, пока сбой не исчезнет и реструктурируя процесс -с тем, чтобы обнаруженная проблема не повторялась в будущем. -Описанная выше ортогональная классификация дефектов может использоваться для -определения категорий различных сбоев и, соответственно, путей обнаружения их -причин. Такая классификация добавляет количественные показатели к технике -анализа причин. -- Статистический контроль процесса (Statistical Process Control, SPC) – -эффективный путь для определения стабильности (или отсутствия стабильности) -процесса. -- Индивидуальный программный процесс (Personal Software Process, PSP) -определяет серию возможных улучшений в индивидуальной практике разработки -программного обеспечения. Предполагает движение “снизу-вверх”, включая сбор -персональных данных и их интерпретацию для повышения индивидуальной -продуктивности специалистов. - -Хотя SWEBOK это и не упоминает, однако, существует и развитие PSP – Team -Software Process (TSP), направленный на аспекты повышения качества командной -работы, включая совершенствование взаимодействия между членами проектной -команды. - -#### Эталонные техники (Benchmarking techniques) - -Этот тип техник основывается на идентификации “совершенной” организации -процесса и связанных с ней практиках и инструментах. Предполагается, что если -менее опытная команда (организация, компания) применяет успешные подходы более -опытной организации, принимаемой в качестве эталона, менее опытная команда -также станет “совершенной”, то есть улучшит свои процессы до уровня данного -успешного примера. Данная техника уделяет специальное внимание оценке зрелости -организации и/или потенциальных возможностей ее процессов (ресурсов, культуры, -бизнес-практик и т.п.). - -В определенной степени, CMMI (и аналогичные модели в области управления -проектами, например, PMI OPM3 и менеджмента качества, например, Six Sigma) -предоставляют обоснованный и подтвержденный базис для использования эталонной -техники. blob - /dev/null blob + b8cfbe31d1930eafecf227beb29441f5ce69a647 (mode 644) --- /dev/null +++ 8_software_engineering_process.md @@ -0,0 +1,810 @@ +# Процесс программной инженерии + +Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK. + +Содержит перевод описания области знаний SWEBOK “Software Engineering Process”, +с замечаниями и комментариями. + +Процесс программной инженерии (Software Engineering Process) + +Область знаний “Процесс программной инженерии” (Software Engineering Process) +может быть рассмотрена на двух уровнях. Первый уровень содержит техническую и +управленческую деятельность на протяжении процессов жизненного цикла +программного обеспечения, включающих приобретение, разработку, сопровождение и +вывод из эксплуатации программных систем. Второй уровень – “мета-уровень”, +связанный с определением, реализацией, оценкой, измерением, управлением, +изменением и совершенствованием самих процессов жизненного цикла программного +обеспечения. Первый уровень освещен в других областях знаний SWEBOK. Второй +уровень рассматривается в данной области знаний. + +Термин “процесс программной инженерии” (software engineering process) может +интерпретироваться по-разному и это, соответственно, может приводить к +определенной путанице. + +- С одной стороны, учитывая специфику оригинального термина в английском языке, +где (с точки зрения грамматики) может существовать термин the software +engineering process, он будет подразумевать единственно правильный способ +выполнения задач (performing tasks) программной инженерии. Такое предположение +заведомо отбрасывается SWEBOK, так как “единственно правильного” процесса быть +не может. Такие стандарты, как IEEE/ISO/ГОСТ 12207 говорят о процессах (во +множественном числе - processes), подразумевая что программная инженерия +содержит множество процессов, например, процесс разработки (Development +Process) и процесс конфигурационного управления (Configuration Management +Process). +- Вторая интерпретация связана с общим (general) обсуждением процессов, +связанных с программной инженерией. Данная точка зрения отражена в названии +этой области знаний и является одной из наиболее часто подразумеваемых при +использовании термина “процесс программной инженерии”. +- Наконец, третье понимание данного термина может означать реальный набор +действий, предпринимаемых в данной организации и рассматриваемый как единый +процесс на уровне организации. Такой подход также рассматривается в данной +области знаний (та или иная интерпретация обычно зависит от контекста +обсуждения). + +Данная область знаний связана со всеми элементами управления процессами +жизненного цикла программного обеспечения, в которых процедурные +(управленческие) или технологические изменения применяются к совершенствованию +процесса или продукта. + +Процесс программной инженерии касается не только крупных организаций. Более +того, связанные с данным процессом действия могут и должны применяться +небольшими организациями, командами и отдельными специалистами. + +Цель управления процессами программной инженерии состоит в реализации новых и +лучших процессов в реальной практике конкретных специалистов, проектов или +организации (отдельных ее групп подразделений или организации, в целом). +Данная область знаний не адресуется напрямую вопросам управления персоналом +(human resources management, HRM). Эти темы исследуются, например, в People CMM +(People Capabililty Maturity Model) и процессах системной инженерии (см. +стандарты ISO 15288 “Systems Engineering - System Life Cycle Process” и IEEE +1220 “Standard for the Application and Management of the Systems Engineering +Process”). + +Также, необходимо понимать, что многие процессы программной инженерии +порождаются и тесно связаны с другими дисциплинами, например, управлением +(management), хотя иногда эти процессы и называют по-другому в контексте этих +дисциплин. + +![Рисунок 1. Область знаний “Процесс программной инженерии” [SWEBOK, 2004, с.9-2, рис. 1]](images/process_area_small.jpg) + +## Реализация и изменение процесса (Process Implementation and Change) + +Данная секция фокусируется на организационных изменениях. Она описывает +инфраструктуру, действия, модели и практические соображения по реализации +процесса и его изменении. + +Ниже рассматривается ситуация, в которой те или иные процессы реализуются +впервые (например, процесс проведения инспекций в проекте или охват полного +жизненного цикла программного обеспечения) и где изменяются уже существующие +(используемые) процессы. Речь пойдет о том, что называют эволюцией процесса +(process evolution). Существующие практики рассматриваются в контексте часто +необходимой модификации. Если требуемые модификации достаточно обширны, это +приводит и к необходимости изменения организационной культуры. + +### Инфраструктура процесса (Process Infrastructure) + +Эта тема охватывает знания, связанные с инфраструктурой процесса программной +инженерии и, в большой степени, базируется на стандартах IEEE/ISO/ГОСТ 12207 +“Standard for Information Technology - Software Life Cycle Processes” и ISO +15504 “Information Technology - Software Process Assessment” (известен также +как SPICE - Software Process Improvement and Capability dEtermination). + +Для внедрения процессов жизненного цикла необходимо обладать соответствующей +инфраструктурой, подразумевая, что ресурсы (компетентный персонал, инструменты, +финансирование) – доступны, а ответственность – распределена <по членам +проектной команды и/или организационной единицы, в терминах структуры компании +или организации, например, отдела или группы>. Выполнение этих задач является +хорошим индикатором того, что менеджмент <управленческий персонал +проекта/организации> реально прилагает усилия по поддержке процесса программной +инженерии. Как следствие таких усилий могут создаваться различные комитеты и +другие специализированные организационные структуры и органы, в общем случае +называемые steering committee – “управляющий комитет”, обладающий +наблюдательными функциями в отношении усилий, направленных на мониторинг, +контроль и выработку рекомендаций по поддержке и улучшению процесса +программной инженерии. На основе таких функций будем в дальнейшем использовать +термин “наблюдательный орган”, подчеркивая реальные задачи такой комиссии и +возможность как формальной, так и неформальной его организации. + +Наблюдательный орган является основой процессной инфраструктуры в проектной +команде, подразделении или организации, в целом. Обычно, выделяют два типа +инфраструктуры, применяемые на практике Software Engineering Process Group +(SEPG, обычно, в русском языке для такой структуры используется приведенная +англоязычная аббревиатура) и Experience Factory (EF, “фабрика опыта”). + +#### Software Engineering Process Group (SEPG) + +SEPG создается как центральный орган, принимающий на себя работу по +process improvement - совершенствованию процесса(-ов). SEPG берет на себя +ответственность по множеству вопросов, связанных с этой задачей в терминах +инициирования <улучшений> и поддержки <существующего процесса и его постоянного +совершенствования>. + +Часто SEPG формируется из нескольких ведущих членов проектной команды (если, +SEPG создается в рамках проекта) или на уровне подразделения или всей +организации. При этом, в большинстве случаев, SEPG не включает “освобожденных” +специалистов и, таким образом, ее члены всегда находятся в контексте реальных +проблем, с которыми сталкиваются выполняя свои “основные” обязанности. +Исключение, обычно, составляют SEPG, формируемые для достижения определенных +организационных целей - приведения процессов в соответствие тем или иным +требованиям и, в частности, для достижения того или иного уровня зрелости CMMI, +обеспечения качества в рамках ISO или SixSigma и т.п. В этих случаях SEPG +обычно возглавляется выделенным экспертом (или группой) в области постановки и +совершенствования процессов. + +#### Experience Factory (EF) + +Концепция “фабрики опыта” отделяет проектную организацию (например, +организационную структуру, отвечающую за разработку программного обеспечения – +ИТ-подразделение, группу разработки или проектную команду) от организации, +отвечающей за улучшение процесса. Проектная организация, в этом случае, +фокусируется на разработке и сопровождении программного обеспечения, а EF – +занята совершенствованием процесса программной инженерии. + +Основной задачей EF является институализация (внедрение в повседневную +практику) коллективного опыта и полученных уроков в масштабах организации на +основе разработки, обновления и внедрения в проектную организацию “пакетов +опыта” – experience packages (например, руководств, моделей, курсов обучения и +т.п.), <типовых> “активов процесса” – process assets. Проектная организация +предлагает на рассмотрение EF свои продукты, планы, использовавшиеся при +разработке, а также данные, собранные в процессе разработки и эксплуатации. + +Cложно провести четкую грань между SEPG и EF. Скорее, можно говорить о создании +SEPG в форме “фабрики опыта” в крупных ИТ-подразделениях, например, +международных компаний, или достаточно крупных организациях, основной +деятельностью которых является создание программного обеспечения. В этом случае +SEPG проводит пилотное внедрение усовершенствованных или новых процессов в +рамках одного или нескольких выбранных проектов и, затем, распространяет этот +опыт во всей организации. Так или иначе, отдача от SEPG/EF обычно заметна в +проектно-ориентированных или проектных организациях, чья деятельность построена +в форме управления портфелем проектов (более подробную информацию о +проектно-ориентированных организациях можно, например, найти в PMI PMBOK и +других материалах Project Management Institute). В общем случае, говоря об +инфраструктуре процессов, обычно используют именно термин SEPG для обоих типов +организации команд, фокусирующихся на процессе разработки программных систем. + +### Цикл управления программным процессом (Software Process Management Cycle) + +Управление процессами в области программного обеспечения состоит из четырех +действий, представленных в рамках итеративного цикла. Это позволяет получать и +анализировать отклики на постоянной основе и, <более оперативно> +совершенствовать процесс. Вот эти четыре действия, предлагаемые SWEBOK: + +- Establish Process Infrastructure – создание инфраструктуры процесса. Задачи – +обеспечить согласие и поддержку заинтересованных лиц (в первую очередь, +менеджмента) в работах по реализации и изменении процесса; получить возможность +развернуть соответствующую инфраструктуру процесса, выделив необходимые ресурсы +и обеспечив распределение обязанностей (ответственности). +- Planning – планирование. Задача (цель) – понять (сформулировать) текущие +бизнес-цели и потребности в процессе, необходимые отдельным специалистам, +проекту и/или организации, в целом; идентифицировать сильные и слабые стороны +(см. концепцию SWOT-анализа в различных источниках) <существующего процесса и +планируемых на данной итерации нововведений и/или изменений> и разработать план +реализации и изменения процесса. +- Process Implementation and Change – реализация и изменение процесса. Задача +(цель) – выполнение разработанного плана по внедрению нового и/или +модифицированного процесса (включая, например, если это необходимо, +развертывание новых инструментов или проведение тренингов). В результате +заданный процесс должен быть внедрен в практику. +- Process Evaluation – оценка процесса. Задача (цель) – понять, насколько +хорошо процесс реализован, получены или нет ожидаемые преимущества от его +внедрения. Результат анализа становится “входом” для следующей итерации. + +### Модели реализации и изменения процесса (Models for Process Implementation and Change) + +Существует две распространенные модели внедрения процесса – Quality Improvement +Paradigm – QIP (Software Engineering Laboratory, Software Process Improvement +Guidebook, NASA/GSFC, Technical Report SEL-95-102, April 1996, +http://sel.gsfc.nasa.gov/website/documents/online-doc/95-102.pdf) и +разработанная в Институте программной инженерии Университета Карнеги-Меллон SEI +CMU модель IDEAL (Initiating – Diagnosing – Establishing – Acting – Learning). +Во всех случаях оценка может проводиться по качественным и/или количественным +показателям. + +На сегодняшний день наиболее проработанными и распространенными стандартами +оценки и совершенствования процесса программной инженерии являются CMMI (де +факто стандарт) и SCAMPI (разработанная в SEI CMU стандартная методика оценки +совершенствования процессов – Standard CMMI Appraisal Method for Process +Improvement), а также в ISO/IEC 15504 (де юро стандарт), также известном как +SPICE (Software Process Improvement and Capability Determination) и +разработанным для аттестации зрелости процессов. + +### Практические соображения (Practical Considerations) + +Реализация и изменение процесса является составной частью организационных +изменений. В большинстве успешных случаев усилия, направленные на +организационные изменения рассматриваются как самостоятельный проект со своими +(соответствующими) правами, планами, ресурсами и т.п. + +Обычно составляются соответствующие руководства (guidelines) по реализации и +изменению процесса, включая разработку плана действий (action plan), проводятся +тренинги, согласуется поддержка менеджмента (желательно, высшего +управленческого звена), отбираются пилотные проекты, в которых впервые будут +задействованы соответствующие процессы и инструменты и т.п. Такие рекомендации +можно найти во многих источниках, в том числе, и в указанных в оригинальной +версии SWEBOK. Также, можно найти множество отчетов и исследований по факторам +успеха, значимым для внедрения и изменения процесса (например, многие из таких +исследований связаны с моделью CMMI и представлены на сайте SEI CMU +http://sei.cmu.edu/). + +SWEBOK также отмечает роль “агентов” изменений, как лиц, часто создающих +предпосылки, инициирующих изменения, а также специалистов, постоянно +реализующих изменения в своей практике. Естественно, что реализация и изменение +процесса может рассматриваться как консалтинг. Он может быть внутренний +(например, проводимый силами специалистов SEPG) или внешний (с привлечением +экспертов из других подразделений и организаций, часто специализирующихся в +данной области так же, как мы видим консультантов и внешних управляющих в +области проектного менеджмента). Практика показывает, что достаточно успешным +является подход, предполагающий совместную работу внешних и внутренних +консультантов SEPG, так как в этом случае легче отойти от сложившихся внутри +организации шаблонов восприятия и обеспечить свежий взгляд на возможности и +потенциальную отдачу в совершенствовании процесса, конечно, с учетом опыта +вовлеченных в эти работы специалистов. + +Кроме того, можно увидеть организационные изменения в контексте внедрения тех +или иных технологий (в SWEBOK используется термин technology transfer). При +этом, эти технологии могут касаться как непосредственно самого программного +обеспечения, так и связаны с самим процессом (например, технологии +моделирования). + +Существует два распространенных подхода к оценке реализации и изменения +процесса. Они состоят в оценке самого процесса и в оценке результатов процесса +(process outcomes), соответственно. + +## Определение процесса (Process Definition) + +Определение процесса может быть процедурой, рекомендацией или стандартом. +Процессы жизненного цикла программного обеспечения четко определяются по разным +причинам, в частности, с целью повышения качества получаемого продукта, +улучшения коммуникаций и улучшения понимания различных аспектов программной +инженерии отдельными специалистами, поддержки совершенствования процессов, +поддержки управления процессами, обеспечения автоматизации процессов и т.п. +Используемые типы описаний процессов, часто, зависят (как минимум, частично) от +целей определения процессов. + +Также необходимо отметить, что проектный и организационный контексты помогают +определить наиболее подходящие определения процессов. Важными факторами при +определении процесса являются природа работ (например, разработка или +сопровождение), прикладная область (application domain), модель жизненного +цикла и зрелость самой организации. + +### Модели жизненного цикла программного обеспечения (Software Life Cycle Models) + +Модели жизненного цикла задают высокоуровневое определение фаз (стадий) +разработки программного обеспечения. Их целью не является предоставление +детального определения, но концентрируется на ключевых работах и их +взаимосвязях. Примерами таких моделей[^17] являются водопадная +(каскадная - waterfall), модель прототипирования, эволюционной разработки, +инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения +и критерии выбора моделей, ссылки на некоторые из которых, в частности, даны в +оригинальной версии SWEBOK. + +[^17]: Базовые модели жизненного цикла рассматриваются далее в отдельной дополнительной главе. + +### Процессы жизненного цикла программного обеспечения (Software Life Cycle Processes) + +Определения процессов жизненного цикла обычно являются более детальными, чем +модели. Однако, определения процессов не описывают порядка их выполнения во +времени (за это как раз и отвечают модели, прим. автора). Это означает, что, в +принципе, процессы жизненного цикла программного обеспечения могут быть +“выстроены” (во времени) соответственно любой модели жизненного цикла. Основным +источником знаний по процессам является стандарт IEEE/ISO/ГОСТ 12207 +“Information Technology – Software Lifecycle Processes” (основные элементы +структуры этого стандарта рассматривается за рамками перевода и комментариев +SWEBOK в самостоятельной главе, посвященной жизненному циклу). + +В рамках данных понятий жизненного цикла - “модель” и “процессы”, возможно +говорить, что совокупность модели, процессов и практик определяет +метод/методологию поддержки жизненного цикла. + +Стандарт IEEE 1074 “Standard for Developing Software Life Cycle Processes” +предоставляет список процессов и действий по разработке и сопровождению +программного обеспечения, а также список действий по поддержке самого +жизненного цикла, который может быть отображен на процессы и организован таким +же образом, как и любая модель жизненного цикла. Кроме того, этот стандарт +идентифицирует и связывает другие стандарты IEEE с действиями по поддержке +процессов жизненного цикла. В принципе, стандарт IEEE 1074 может быть +использован для построения процессов, соответствующих любой модели жизненного +цикла. + +SWEBOK отмечает два стандарта, связанных с процессами сопровождения +программного обеспечения – IEEE 1219 “Standard for Software Maintenance” и ISO +14764 “Standard for Software Engineering -Software Maintenance” (см. область +знаний SWEBOK “Сопровождение программного обеспечения”). + +Другие важные стандарты, предоставляющие определение процессов, включают: + +- IEEE 1540: Standard for Software Risk Management – управление рисками +программного обеспечения +- IEEE 1517: Standard for Software Reuse Processes – процессы повторного +использования программного обеспечения +- ISO/IEC 15939: Standard for Software Measurement Process – процесс измерений +в области программного обеспечения + +В ряде ситуаций процессы программной инженерии определяться принимая во +внимание организационные процессы управления качеством. ISO 9001 формулирует +требования к процессам управления качеством, а ISO 9003 интерпретирует эти +требования в отношении организаций, занимающихся разработкой программного +обеспечения (ISO/IEC 90003:2004, Software and Systems Engineering - Guidelines +for the Application of ISO9001:2000 to Computer Software). + +Некоторые процессы жизненного цикла придают особое значение быстрому вводу в +эксплуатацию (rapid delivery) программных систем и глубокой вовлеченности +пользователей <в процесс разработки>. Такие процессы называют agile-методами – +быстрыми, живыми, подвижными. К ним относится, например, экстремальное +программирование – eXtreme Programming (XP, см. работы Кента Бека – Kent Beck). +Отличительной особенностью этих методов является гибкость в вопросах +планирования, когда план проекта активно корректируется по мере продвижения к +цели проекта. Другие процессы уделяют специальное внимание принятию решений на +основе оценки рисков (см. работы Барри Боэма – Barry W. Boehm). + +### Нотации определения процесса (Notations for Process Definitions) + +Процессы могут определяться на различных уровнях абстракции. В свою очередь, +могут быть определены и различные элементы процессов – действия, продукты +(артефакты) и ресурсы. При этом, могут использоваться детальные фреймворки, +структурирующие типы информации, требуемой для определения процессов. + +Существует ряд нотаций, используемых для определения процессов. Ключевое +отличие между ними заключается в типах информации, которая определяется, +контролируется и используется тем или иным фреймворком. Инженеры должны иметь +представление о следующих подходах: диаграммах потоков данных (data flow +diagrams), в терминах целей процессов и получаемых на их выходе результатов +(outcomes) (см. стандарт ISO 15504 “Information Technology - Software Process +Assessment” - “SPICE”), как наборе процессов и их декомпозиции в работы и +задачи, определенный на естественном языке (см. стандарт IEEE/ISO/ГОСТ 12207), +диаграммах переходов и состояний (statechart), SADT, IDEF0 и многих других. + +Хотя SWEBOK приводит расширенный список диаграмм/нотаций, вероятно, в силу +своей “консервативности”, не упоминает, например, activity-диаграммы UML, хотя +они могут использоваться в практике для описания бизнес-процессов, в частности, +и для описания процессов программной инженерии. Ряд нотаций разработан и +используется в рамках конкретных (частных) фреймворков/методологий, например, +RUP. Кроме того, существует успешный опыт по использованию достаточно нотации +BPMN – Business Process Management Notation для описания процессов программной +инженерии. Спецификация BPMN определяет графическое представление +бизнес-процессов в форме диаграмм бизнес-процессов – Business Process Diagram +(BPD). Первый стандарт BPMN был выпущен 3 мая 2004 года консорциумом The +Business Process Management Initiative – BPMI.org (http://www.bpmi.org). +Предоставляя развитые выразительные средства для определения процессов как +комплекса взаимосвязанных действий, событий и артефактов, сгруппированных по +участникам, BPMN позволяет достаточно легко сформировать в рамках одной +диаграммы BPD цельный взгляд на процессы. + +### Адаптация процесса (Process Adaptation) + +Важно отметить, что предопределенные процессы, даже стандартизированные, должны +адаптироваться в соответствии с локальными (конкретными) потребностями, +например, организационным контекстом, размером проекта, регулирующих +требованиях, индустриальных практиках и корпоративной культурой. Ряд +стандартов, в первую очередь, IEEE/ISO/ГОСТ 12207 и ISO 15504, содержат +механизмы и рекомендации по процессу адаптации и его совершенствованию. + +### Автоматизация (Automation) + +Автоматизированные средства либо поддерживают сами работы по определению +процессов (например, позволяя описывать процессы с использованием тех или иных +диаграмм и нотаций) и/или предоставляют соответствующие руководства по +определению процессов (например, RUP, EUP или MSF). В случаях, когда проводится +процесс анализа, некоторые инструменты обеспечивают различные формы симуляции +моделируемых (определяемых) процессов. + +## Оценка процесса (Process Assessment) + +Оценка процесса (process assessment) проводится с использованием +соответствующих моделей оценки (assessment models) и методов оценки (assessment +methods). Во многих случаях вместо термина “assessment” используется термин +“appraisal” (подразумевая саму процедуру оценки, например, CMMI Appraisal). В +свою очередь, термин “appraisal” заменяют на “capability evaluation”, когда +говорят об оценке способностей/потенциальных возможностей, например, с целью +заключения контракта/договора подряда на проведение соответствующих работ. + +Оценка процесса(-ов) может проводиться как неформально, подразумевая часто +внутрикорпоративные инициативы по повышению качества, и формально (то есть с +получением аттестационного документа), в том числе, с привлечением внешних +специалистов по оценке и, часто, с целью подтверждения соответствующего +качества/уровня зрелости процессов. + +### Модели оценки процесса (Process Assessment Models) + +Модель оценки задает, что именно признается лучшими практиками оценки. Эти +практики могут касаться только “технических” работ программной инженерии +(например, проектирования или кодирования), а могут иметь отношение и к +вопросам управления, системной инженерии, управления персоналом и т.п. + +Стандарт ISO/IEC 15504 (SPICE) определяет типовую (exemplar) модель оценки и +требования соответствия к другим моделям. В каждом конкретном случае +используется та или иная существующая модель – CMM-SW, CMMI, +Bootstrap[^18]. Также имеются и другие модели, например, ISO 9000-3 +(теперь именуемый как ISO 90003) “Software and Systems Engineering - Guidelines +for the Application of ISO9001:2000 to Computer Software”, являющаяся +приложением общей модели качества ISO 9001 “Quality Management Systems - +Requirements” к программной инженерии. Кроме того, существуют частные модели, +охватывающие, например, только вопросы документирования, проектирования и т.п. + +[^18]: В 1990 году стартовала европейская инициатива European Strategic Program for +Information Technology (ESPRIT), целью которой было внедрение современных +программных технологий в Европе. В основу инициативы легли работы Уотса Хампфри +(Watts S. Humphrey) – идеолога CMMI, PSP (People Software Process) и многих +других современных концепций программной инженерии как дисциплины. Результат +этот инициативы был назван “Bootstrap” – “самонастройка”. В то время, как +модель CMM – Capability Maturity Model (в частности, CMM-SW – CMM for +Software), а потом и CMMI, разрабатывались с учетом потребностей крупных +государственных структур США (в первую очередь, министерства обороны) и их +подрядчиков, модель Bootstrap изначально была ориентирована на малые и средние +коммерческие компании, с определенным акцентом на индивидуальные практики. + +Также и в системной инженерии существуют модели зрелости, применимые в +отношении программного обеспечения, когда программы являются частью системы. + +SWEBOK отмечает, что ряд моделей применим к небольшим организациям. + +Существуют две основных архитектуры моделей оценки: непрерывная (continuous) и +этапная (staged). Отличия между ними заключаются во взгляде на порядок оценки +процессов. Выбор соответствующей архитектуры и модели оценки в конкретной +организации должен базироваться на ее целях и потребностях (например, +необходимости совершенствования тех или иных процессных областей или +официального подтверждения внешним асессором достижения организацией четвертого +уровня зрелости всего процесса программной инженерии по CMMI). + +### Методы оценки процесса (Process Assessment Methods) + +Для надлежащего проведения оценки соответствующие методы <оценки> позволяют +получить количественные параметры, характеризующие возможности оцениваемого +процесса (или зрелости организации, в целом). + +Например, метод CBA-IPI (CMM-Based Appraisals for Internal Process Improvement) +фокусируется на совершенствовании процесса внутри организации, а метод SCE +(Software Capability Evaluation) касается процессов у подрядчиков[^19]. +Требования в обоих типах методов отражают те лучшие практики оценки, которые +описаны в стандарте ISO 15504. Эти методы были разработаны для модели CMM-SW. С +выходом CMMI (интегрированной модели, объединяющей различные модели CMM), +соответственно, получило развитие новое семейство методов - SCAMPI (Standard +CMMI Appraisal Method for Process Improvement). Деятельность, выполняемая в +процессе оценки, распределение усилий по соответствующим работам и общая +атмосфера оценки (касающаяся, в первую очередь, степени формализации, +сопутствующей оценке) могут серьезно отличаться, в зависимости от того, +направлена ли оценка на совершенствование процессов или проводится в контексте +контракта/договора подряда. + +[^19]: SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment +– внутренняя деятельность в организации, направленная на оценку и +совершенствование собственного процесса в рамках всей организации. Evaluation +подразумевает аудит и мониторинг процессов поставщика (подрядчика, исполнителя) +со стороны заказчика, в первую очередь, в процессе самого выполнения работ, +т.е. уже после заключения контракта/договора подряда. CBA-IPI относится к общей +категории методов Software Process Assessment (SPA) как части работ по +совершенствованию процессов – Software Process Improvements (SPI). SPI как +деятельность по совершенствованию процесса(-ов) сегодня считается достаточно +общим термином, используемым за рамками CMM/CMMI, например, в контексте таких +фреймворков, как ISO 15504 или TQM (Total Quality Management). + +Существует определенная критика моделей, методов (да и самой идеи) оценки. +Такая критика, обычно, основана на эмпирической природе оценки. Однако, по +прошествии определенного периода времени, после публикации таких критических +материалов, опыт и практика индустрии сформировали достаточно четкие +доказательства (в том числе, собрав необходимые статистические данные – см. +отчеты SEI CMU по результатам внедрения и использования CMMI) обоснованности +современных принципов, моделей и методов оценки. + +## Измерения в отношении процессов и продуктов (Process and Product Measurement) + +В силу того, что приложение количественных оценок к программной инженерии может +быть достаточно сложным, в частности, в терминах моделирования или методов +анализа, существует ряд фундаментальных аспектов измерений в программной +инженерии, лежащих в основе многих более детальных измерений и процессов +анализа. Более того, результаты усилий по совершенствованию процессов и +продуктов, могут быть оценены только в том случае, если установлены +количественные характеристики заданных параметров <процессов и продуктов> для +заданных вех или, более точно (так как измерения, все же, выходят за рамки вех +конкретных проектов, если, конечно, сама SPI-деятельность не позиционировать +как проект, что, конечно, возможно), так называемых “базовых линий” +(baseline[^20]). + +[^20]: Термин baseline обычно используется в контексте управления изменениями, +требованиями и, часто, конфигурациями, в целом, для именования временных +“срезов” всего комплекса соответствующих активов. + +Измерения могут проводиться для поддержки инициирования реализации и изменения +процессов и для оценки результатов таких работ. Также, измерения могут +выполняться и в отношении самих продуктов. + +Ключевые понятия, термины и методы измерений в приложении к программному +обеспечению определены в стандарте ISO 15939 “Software Engineering - Software +Measurement Process” и международном словаре метрологии ISO. ISO 15939 также +определяет стандартный процесс для измерения характеристик процессов и +продуктов. + +Необходимо отметить, что в литературе встречаются некоторые терминологические +отличия, например, термин “метрика” (metric) часто используется вместо термина +“измерение” (measure)[^21]. + +[^21]: В данном переводе эти термины используются взаимозаменяемым образом, за +исключением случаев, когда контекст обсуждения предполагает разделение процесса +измерения – “измерения”, как такового, и критериев/параметров или результатов +измерения – “метрик”. + +### Измерения в отношении процессов (Process Measurement) + +Используемый здесь термин “process measurement” – “измерения в отношении +процесса” подразумевает сбор, анализ и интерпретацию количественной информации +о процессе. Измерения используются для идентификации сильных и слабых сторон +процесса (strengths and weaknessess) и для оценки процесса после того, как он +реализован и/или изменен. + +Также, проведение количественной оценки процесса может преследовать и другие +цели. Например, соответствующие измерения полезны для управления программными +проектами. В обсуждаемом здесь контексте, фокус измерений в отношении процессов +направлен на оценку реализации и/или изменения процесса. + +Рисунок 2 иллюстрирует важность предположений, делаемых в большинстве +программных проектов, в которых процесс непосредственно влияет на результаты +проекта. Соответствующий контекст воздействует на связь между процессом и его +результатом. Другими словами, это означает, что связь процесс-результат +процесса находится в зависимости от контексте. + +![Рисунок 2. Связь между процессом и его результатами (или "выходом процесса" - process outcome).](images/process_in-out.jpg) + +Далеко не каждый процесс обладает положительным влиянием на получаемые +результаты. Например, внедрение инспекции <получаемого> программного +обеспечения может сократить усилия и стоимость по тестированию, но может и +увеличить время, если каждая инспекция приводит к нарушению расписания просто в +силу продолжительности соответствующих инспекционных действий. Поэтому, +рекомендуется использовать множество метрических показателей (метрик), по +которым оценивается процесс и его результат(ы), безусловно, в контексте +значимых для бизнеса характеристик. + +Хотя определенные усилия могут направляться на решение вопросов использования +соответствующего инструментария, главный ресурс, который нуждается управлении – +персонал. Как результат, наиболее важные метрики касаются оценки продуктивности +команд и процессов (например, может использоваться оценка функциональных точек, +производимых на единицу трудозатрат[^22]. – “person-effort”), а также, +ассоциированного с этим уровня опыта в программной инженерии, в целом, и в +отдельных технологиях, в частности. + +[^22]: Трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или +“человеко-месяц”; здесь полезно обратиться к юбилейному второму изданию +классического труда Фреда Брукса “Мифический человеко-месяц” [Брукс, 1995]. + +Результаты процесса могут, например, оцениваться в отношении качества продукта +(как число сбоев на тысячу строк кода – KLOC, Kilo-Lines of Code или на +функциональную точку – FP, Function Point), сопровождаемость (усилия, +необходимые для реализации определенного типа изменений), продуктивность (LOC, +Lines Of Code или FP за человеко-месяц), время вывода продукции на рынок +(time-to-market) или степень удовлетворенности потребителей (по измерениям +результатов опросов пользователей). Метод оценки связи между процессом и его +“выходом” (результатом) зависит от конкретного контекста, например, масштабов +(размеров) организации. + +В общем случае, мы фокусируемся на результатах процесса. Однако, для достижения +заданных результатов (например, в терминах более высокого качества, лучшей +сопровождаемости, большей удовлетворенности пользователей) мы должны внедрить +соответствующие процессы. + +Конечно, не только процессы непосредственно влияют на результат <проекта>. +Существуют и другие факторы, играющие не менее важную роль, например, +возможности инструментов и потенциал, знания и опыт специалистов. Когда +оценивается влияние изменения процессов, такие факторы должны учитываться +(например, попытка внедрения развитых процессов программной инженерии при +отсутствии ресурсов или в неподготовленной организационной среде практически +наверняка приведет к краху таких инициатив). Кроме того, важна степень +институализации процессов (process institualization или process fidelity – +следование заданным процессам как повседневная практика работы). Фактор +институализации в большинстве случаев объясняет, почему “хорошие” процессы не +приводят к желаемому результату, когда процессы полностью или частично остаются +лишь на бумаге. + +### Измерения в отношении программных продуктов[^23] (Software Product Measurement) + +Измерения в отношении программного продукта включают количественную оценку его +размера, структуры и качества. + +[^23]: Данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке +оригинального варианта SWEBOK 2004, поэтому, далее, нумерация тем смещена. + +#### Оценка размера (Size measurement) + +Размер программного продукта чаще всего оценивается по его “длине” (например, в +количестве строк кода в модулях, страниц спецификаций требований и других +документов) или функциональности (например, по количеству функциональных точек +в спецификации). Принципы количественной оценки “функционального” размера +программного обеспечения описываются в стандартах: + +- IEEE 14143-1 “Information Technology - Software Measurement - Functional Size +Measurement - Part 1:Definitions of Concepts” +- ISO 19761 “Software Engineering - Cosmic FPP - A Functional Size Measurement +Method” +- ISO 20926 “Software Engineering - IFPUG 4.1 Unadjusted Functional Size +Measurement Method-Counting Practices Manual” +- ISO 20968 “Software Engineering-MK II Function Point Analysis – Counting +Practices Manual” + +#### Оценка структуры (Structure measurement) + +Существует широкий спектр метрик, которые можно использовать для оценки +структуры программного обеспечения – в отношении высокоуровневого и +низкоуровневого дизайна, а также артефактов кода для анализа потоков работ, +потоков данных, вложенности <вызовов>, структур контроля, модульности, +взаимодействия и т.п. + +#### Оценка качества (Quality measurement) + +Качество, как многомерная характеристика программного обеспечения, наиболее +сложно для количественной оценки, в отличие от других характеристик, описанных +выше. Более того, некоторые параметры качества требуют, в большей степени, +применения качественной, а не количественной оценки. Детальное обсуждение +вопросов оценки качества представлено в области знаний SWEBOK “Software +Quality” (тема 3.4). ISO разработала соответствующие модели качества +программного обеспечения и связанных с ним метрик (см. стандарт ISO 9126 +“Software Engineering - Product Quality”, части 1-4). + +### Качество результатов измерений (Quality Of Measurement Results) + +Качество результатов измерений (точность, воспроизводимость, повторяемость, +изменяемость, случайность ошибок измерений) является основой программ +проведения количественных оценок для получения эффективных и ограниченных +(ограниченного количества значимых) результатов. Ключевые характеристики +результатов измерений и связанного с ними качества инструментов измерения (в +первую очередь, обоснованности используемого математического аппарата) +определены в международном словаре метрологии ISO (International vocabulary on +metrology). + +Теория количественной оценки устанавливает основу для возможных измерений. +Измерения (и соответствующие типы “размерностей” или “шкал”) описаны в этой +теории как систематическое определение численных величин для представления +свойств объектов SWEBOK подчеркивает важность определения масштабов измерений и +понимания каждого типа “размерности” (как мы увидим далее, под этим термином +могут подразумеваться определенные категории метрических показателей - метрик) +с учетом связи с последующим выбором методов анализа данных. Выразительная +сторона размерностей связана с классификацией метрик. Для этого теория +количественных оценок предлагает последовательность наложения все более +детальных ограничений для выделения соответствующих (и все более +специализированных) групп метрик. Если метрические показатели используются +только для отметки объектов с целью классификации (например, в простейшем +случае, бинарной классификации - “да/нет”, “удовлетворяет/не удовлетворяет”), +такие значения называют номинальными (nominal). Если значения определяются для +ранжирования (ranking) объектов (например, “хороший”, “лучший чем”, “наилучший +”), эти показатели называют порядковыми (ordinal). Если величины метрических +показателей определяются относительно заданных единиц измерений, такие +показатели называют интервальными (interval). Наконец, встречаются +пропорциональные (ratio) показатели (основывающиеся на оценке взаимного +отношения различных значений показателей, каждое из которых измеряется разницей +между величиной показателя и нулем). + +Хотелось бы обратить внимание на описание концепции и использования метрических +показателей в специальной главе “Метрические показатели, применяемые при оценке +размера программ” русского перевода книги “Управление программными проектами” +[Фатрелл, Шафер и Шафер, 2003, глава 21, с.692-748]. + +### Информационные модели (Software Information Models) + +По мере сбора данных и наполнения ими репозитория измерений, становится +возможно построить соответствующие информационные модели на основе собранных +данных и имеющихся знаний. + +Эти модели применяются для анализа, классификации и предсказания <характеристик +и поведения измеряемых объектов>. Оценка моделей необходима для обеспечения +достаточной степени точности и понимания их ограничений. Также необходимо +отметить важность работ, направленных на уточнение моделей как в процессе +ведения проекта, так и после его завершения. + +#### Построение модели (Model building) + +Построение модели включает калибрование и оценку модели. Ориентированный на +цель подход к измерениям наполняет процесс построения модели необходимым +содержанием, то есть модель конструируется для ответа на значимые вопросы и +достижения целей совершенствования создаваемого программного обеспечения. На +этот процесс также оказывают влияние неявные ограничения используемых +метрических показателей и связанных с ними методов анализа. Модель калибруется +и оценивается на основании уже накопленных результатов наблюдений (например, по +недавно выполненным проектам или проектам, аналогичным данному по используемым +технологиям и т.п.) и сравнения ее эффективности с точки зрения соответствия +прогнозов реальным данным. + +#### Внедрение модели (Model implementation) + +Внедрение модели включает интерпретацию и уточнение моделей. Откалиброванные +модели применяются в отношении процесса, их результаты интерпретируются и +оцениваются в контексте процесса/проекта, после чего модели уточняются в тех +аспектах, где это необходимо. + +### Техники количественной оценки процессов (Process Measurement Techniques) + +Определенные техники измерения процесса могут использоваться для анализа +процессов программной инженерии и идентификации их преимуществ и недостатков +(сильных и слабых сторон). Такие техники применяются во многих случаях для +инициирования или оценки влияния (последствий) внедрения или изменения +процессов. + +Качество результатов измерений, в терминах точности, повторяемости и +воспроизводимости, связано с инструментальной составляющей и используемой +концепцией оценки и точкой зрения в отношении измерений (например, когда +оценивающее лицо – асессор - выставляет оценки по конкретным процессам). + +Техники измерения процесса классифицируются по двум типам: аналитическая и +эталонная (benchmarking). Эти два типа используются вместе, так как +основываются на различных типах информации. + +#### Аналитические техники (Analytical techniques) + +Аналитические техники характеризуются, как зависящие от “количественных +свидетельств того, где необходимы усовершенствования и где инициативы по +совершенствованию оказались успешны“. Аналитический тип, иллюстрируемый, +например, подходом QIP (Quality Improvement Paradigm) состоит из цикла +“понимание-проверка-приложение”. Техники, представленные ниже, приведены в +качестве других примеров аналитического подхода к измерениям и отражают +достаточно типичную практику реализации такого <аналитического> взгляда на +проведение количественной оценки. Будут или нет использоваться эти техники в +практике конкретной организации зависит, как минимум, от зрелости ее +организационной культуры и используемых процессов. + +- Экспериментальные исследования (Experimental Studies). Проводятся в +специально подготовленном “окружении” для оценки <нового или измененного> +процесса. Обычно новый (или измененный) процесс сравнивается с существующим для +определения того, в какой степени “старый” процесс дает лучшие результаты, по +сравнению с новым процессом. + +Другой тип экспериментальных исследований – “симуляция” процесса (моделирование +его поведения и результатов, прим. автора). Этот тип исследований может +использоваться для анализа поведения процесса, выяснения потенциальных +возможностей усовершенствования процесса, предсказания результатов процесса +(для того случая, если существующий процесс изменяется определенным образом) и +контроля выполнения процесса. В качестве первичных данных для симуляции +процесса, обычно, используются данные текущего (существующего) процесса. +- Обзор (оценка) определения процесса (Process Definition Review) +подразумевает, каким образом оценивается определение процесса для идентификации +его недостатков и потенциальных аспектов совершенствования. Один из легких +способов анализа процесса – сравнение его с существующими стандартами +(например, IEEE/ISO/ГОСТ 12207). При таком подходе метрические показатели +обычно не собираются, или, в случае их наличия, играют лишь “поддерживающую” +(второстепенную) роль. Специалисты, выполняющие анализ определения процесса, +используют свои знания, опыт и другие возможности для принятия решения какие +изменения процесса могут потенциально привести к желаемому результату в +отношении “выходов” процесса (получаемого программного продукта или его +отдельных элементов). Наблюдения (observations) за выполнением процесса также +могут дать дополнительные данные, позволяющие идентифицировать возможные пути +совершенствования процесса. +- Ортогональная классификация дефектов (Orthogonal Defect Classification) – +техника, которая может быть использована для связывания (отображения) сбоев с +их потенциальными причинами. В данном контексте может быть полезен для +детального ознакомления стандарт IEEE 1044 “Standard for the Classification of +Software Anomalies”, классифицирующий возможные сбои (аномалии) в работе +программного обеспечения. +- Анализ причин (Root Case Analysis) является еще одной популярной техникой, +часто используемой на практике. Эта техника предполагает “спуск” от +обнаруженного сбоя к идентификации его причины, изменяя сам процесс (или, по +аналогии, код программного обеспечения, если бы речь шла о поиске дефекта, +приводящего к сбою) до тех пор, пока сбой не исчезнет и реструктурируя процесс +с тем, чтобы обнаруженная проблема не повторялась в будущем. +Описанная выше ортогональная классификация дефектов может использоваться для +определения категорий различных сбоев и, соответственно, путей обнаружения их +причин. Такая классификация добавляет количественные показатели к технике +анализа причин. +- Статистический контроль процесса (Statistical Process Control, SPC) – +эффективный путь для определения стабильности (или отсутствия стабильности) +процесса. +- Индивидуальный программный процесс (Personal Software Process, PSP) +определяет серию возможных улучшений в индивидуальной практике разработки +программного обеспечения. Предполагает движение “снизу-вверх”, включая сбор +персональных данных и их интерпретацию для повышения индивидуальной +продуктивности специалистов. + +Хотя SWEBOK это и не упоминает, однако, существует и развитие PSP – Team +Software Process (TSP), направленный на аспекты повышения качества командной +работы, включая совершенствование взаимодействия между членами проектной +команды. + +#### Эталонные техники (Benchmarking techniques) + +Этот тип техник основывается на идентификации “совершенной” организации +процесса и связанных с ней практиках и инструментах. Предполагается, что если +менее опытная команда (организация, компания) применяет успешные подходы более +опытной организации, принимаемой в качестве эталона, менее опытная команда +также станет “совершенной”, то есть улучшит свои процессы до уровня данного +успешного примера. Данная техника уделяет специальное внимание оценке зрелости +организации и/или потенциальных возможностей ее процессов (ресурсов, культуры, +бизнес-практик и т.п.). + +В определенной степени, CMMI (и аналогичные модели в области управления +проектами, например, PMI OPM3 и менеджмента качества, например, Six Sigma) +предоставляют обоснованный и подтвержденный базис для использования эталонной +техники. blob - 94bee7c4314e825ef2f5b6a54fecadebd921a83e (mode 644) blob + /dev/null --- 9_software_engineering_tools_and_methods.markdown +++ /dev/null @@ -1,442 +0,0 @@ -# Инструменты и методы программной инженерии - -Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - -SWEBOK. - -Содержит перевод описания области знаний SWEBOK “Software Engineering Tools and -Methods”, с замечаниями и комментариями. - -Инструменты и методы программной инженерии (Software Engineering Tools and -Methods) - -Программные инструменты предназначены для обеспечения поддержки процессов -жизненного цикла программного обеспечения. Инструменты позволяют -автоматизировать определенные повторяющиеся действия, уменьшая загрузку -инженеров рутинными операциями и помогая им сконцентрироваться на творческих, -нестандартных аспектах реализации выполняемых процессов. Инструменты часто -проектируются с целью поддержки конкретных (частных) методов программной -инженерии, сокращая административную нагрузку, ассоциированную с “ручным” -применением соответствующих методов. Так же, как и методы программной -инженерии, инструменты призваны сделать программную инженерию более -систематической деятельностью и по своему содержанию (предлагаемой -функциональности) могут варьироваться от поддержки отдельных индивидуальных -задач вплоть до охвата всего жизненного цикла (в этом случае часто говорят об -инструментальной платформе или просто платформе разработки). - -Методы программной инженерии накладывают определенные структурные ограничения -на деятельность в рамках программной инженерии с целью приведения этой -деятельности в соответствие с заданным систематическим подходом и более -вероятным и скорым, с точки зрения соответствующего метода, достижением успеха. -Методы обычно предоставляют соответствующие соглашения (нотацию), словарь -<терминов и понятий> и процедуры выполнения идентифицированных (и охватываемых -методом) задач, а также рекомендации по оценке и проверке <выполняемого> -процесса и <получаемого в его результате> продукта. Методы, как и инструменты, -варьируются по содержанию (охватываемой области применения) от отдельной фазы -жизненного цикла (или даже процесса) до всего жизненного цикла. Данная область -знаний касается только методов, охватывающих множество фаз (этапов) жизненного -цикла. Те методы, применение которых фокусируется на отдельных фазах жизненного -цикла или частных процессах, описаны в соответствующих областях знаний. - -Существует множество детальных описаний и руководств по конкретным -инструментам, и исследований, посвященных анализу (и категоризации, в первую -очередь, со стороны аналитиков) уже применяемых и новых инструментальных -средств (и вероятным направлениям их развития). В таком контексте, общее -техническое описание инструментов программной инженерии, действительно, может -отпугнуть. (В то же время, с точки зрения автора, при всей неоднозначности -любой категоризации инструментов, может быть сформирован общий взгляд на их -целевую функциональность, пусть в чем то и спорный, что, отразится в -определенных случаях ниже в соответствующих авторских комментариях). Одна из -основных сложностей такого описания, в общем случае, заключается в высокой -изменчивости и быстром эволюционировании программных инструментов. Конкретные -аспекты функциональности инструментов достаточно быстро изменяются, что -усложняет приведение конкретных актуальных примеров. - -Данная область знаний охватывает все процессы жизненного цикла и, -соответственно, связана со всеми другими областями знаний SWEBOK. - -![Рисунок 1. Область знаний “Инструменты и методы программной инженерии” [SWEBOK, 2004, с.10-1, рис. 1]](images/tools_area_small.jpg) - -## Инструменты программной инженерии (Software Engineering Tools) - -Первые пять тем данной секции соответствуют первым пяти областям знаний SWEBOK -- требования, проектирование, конструирование, тестирование и сопровождение. -Следующие четыре темы касаются оставшихся четырех областей знаний – -конфигурационного управления, управления программной инженерией, процессов и -качества, соответственно. Также в данной секции представлена еще одна тема – -“Дополнительные аспекты инструментального обеспечения” (в оригинале SWEBOK она -называется “Miscellaneous”), посвященная таким вопросам как, например, -интеграция инструментов, которые потенциально касаются всех классов -инструментов. - -### Инструменты работы с требованиями (Software Requirements Tools) - -SWEBOK говорит о том, что инструменты, применяемые для работы с требованиями -могут быть классифицированы в две категории: средства моделирования (modeling) -и средства трассировки (traceability). Однако, на практике, моделирование -требований, все же, является частью управления требований, как, кстати, и -трассировка. В принципе, инструменты трассировки могут быть рассмотрены как -самостоятельная категория, в силу своей значимости при проведении анализа -требований, в первую очередь, анализа влияний требований и изменений (т.н. -“impact analysis”). Но моделирование требований лишь часть управления -требованиями. Поэтому, в приведенной ниже классификации предлагаемая -модификация оригинального SWEBOK состоит в том, что вместо “инструментов -моделирования требований” используется термин “инструменты управления -требованиями”, при сохранении оригинального содержания данной темы SWEBOK. -Соответственно, - -- Инструменты управления требованиями (моделирования требований – Requirements -modeling tools). Эти инструменты используются для извлечения (eliciting), -анализа, специфицирования и проверки программных требований. -- Инструменты трассировки требований (Requirement traceability tools). Эти -инструменты становятся все более важными по мере повышения сложности -программного обеспечения. В силе того, что они также относятся и к другим -процессам жизненного цикла, здесь они представлены в качестве самостоятельной -категории средств работы с требованиями. - -Необходимо заметить, что трассировка является неотъемлемой частью полноценной -работы с требованиями, что приводит к естественному объединению предлагаемых -SWEBOK категорий инструментов в единый класс “инструментов управления -требованиями”, функциональное содержание которых может варьироваться, например, -в зависимости от сложности проектов и уровня зрелости процессов. Если мы -обратимся, например, к модели CMMI Staged, мы увидим, что на 2-м уровне -зрелости речь идет об “управлении требованиями” – Requirement Management, а на -3-м уровне зрелости обсуждается “разработка требований” – Requirement -Development, обладающая более ёмким содержанием. В то же самое время, с -технократической точки зрения, требования могут восприниматься и как элементы -конфигураций, наравне с запросами на изменения и другими активами проекта (см. -область знаний SWEBOK “Конфигурационное управление”). Таким образом, в ряде -случаев (что подтверждается конкретными программными средствами, доступными на -рынке программного обеспечения), в качестве инструмента работы с требованиями -может выступать и система конфигурационного управления, если, конечно, она -изначально не ограничена базовой функциональностью контроля версий <файлов>. С -другой стороны, сегодняшние средства моделирования на основе UML и BPMN могут -также рассматриваться как элементы инструментального обеспечения работы с -требованиями, что часто отражается в их функциональности, включающей тесную -интеграцию с “классическими” средствами управления требованиями, а сама -интеграция воплощена не только в визуальном представлении работы с -репозиториями требований, но и в автоматизации трассировки между моделями -(и/или их элементами) и требованиями, соответственно. - -### Инструменты проектирования (Software Design Tools) - -Эта тема охватывает инструменты для создания и проверки программного дизайна. -Существует большое разнообразие таких инструментов, использующих различные -нотации (соглашения, в том числе визуальные) и методы. Несмотря на такое -разнообразие, <авторами SWEBOK> не было найдено <адекватной> классификации этих -инструментов. - -Однако, в данном случае, все же возможно разделение инструментов по нескольким -критериям, например, применяемым базовым нотациям моделирования и -проектирования (SADT/IDEF, UML, BPMN/BPEL, Microsoft DSL и т.п.) или целевым -задачам (бизнес-моделирование, проектирование БД, объектно-ориентированное -проектирование, интеграционное/SOA-проектирование и т.п.). - -### Инструменты конструирования (Software Construction Tools) - -Данная тема касается инструментальных средств конструирования программного -обеспечения, в соответствии с пониманием “конструирования”, заданным -соответствующей областью знаний SWEBOK, рассматривавшейся ранее. Эти -инструменты используются для производства и трансляции программного -представления (например, исходного кода), достаточно детального и явного для -машинного выполнения. - -- Редакторы (program editors). Эти инструменты используются для создания и -модификации <исходного кода> программ и, возможно, ассоциированной с ними -документации. Это могут быть как редакторы “общего назначения” (что на -протяжении многих лет наблюдается в UNIX и unix-подобных средах) или -специализированные редакторы с поддержкой специфики целевого языка -программирования (что является, в большинстве случаев, прерогативой -интегрированных сред разработки – IDE). В то же время, документирование все же -является не только и не столько частью редактора, сколько самостоятельной -функциональностью, пусть часто и тесно интегрированной с редактором. -- Компиляторы и генераторы кода (compilers and code generators). Традиционно, -компиляторы являлись неинтерактивными (командными) трансляторами исходного -кода. Однако, существует тенденция (с точки зрения автора, более чем явная, что -отмечено ниже) интеграции компиляторов и редакторов в интегрированные среды -программирования. К этому классу также относятся препроцессоры, -линковщики/загрузчики, а также генераторы кода (за исключением, может быть, -объектно-ориентированных средств проектирования, поддерживающих связь с -исходным кодом и имеющих тенденцию быть тесно интегрированными с новым -поколением IDE). -- Интерпретаторы (interpreters). Эти инструменты обеспечивают исполнение -программ посредством эмуляции. Они могут поддерживать действия по -конструированию программного обеспечения, предоставляя для исполнения программ -окружение, более контролируемое и поддающееся наблюдению, чем это обычно -способна сделать та или иная операционная система. -- Хочется отметить определенное “слияние”, если так можно выразиться, между -компиляторами и интерпретаторами. Ярким тому свидетельством является -использование так называемой just-in-time компиляции – компиляции “на лету”, -когда промежуточный программный код, по мере исполнения или с опережением -(например, в процессе запуска/загрузки программы) преобразуется в набор -инструкций, исполняемых непосредственно средствами операционной системы, но под -контролем среды исполнения, в первую очередь, с точки зрения безопасности. -Такого рода подход стал родоначальником ряда современных программных платформ, -например, Java и .NET. На этом фоне, возможно было бы объединить интерпретаторы -с компиляторами и генераторами кода, как средства непосредственной подготовки -(трансляции) исходного кода к исполнению. -- Отладчики (debuggers). Эти инструменты было принято выделить в -самостоятельную категорию, так как они поддерживают процесс конструирования -программного обеспечения, но, в то же время, <функционально> отличаются от -редакторов и компиляторов. - -С точки зрения классификации инструментов необходимо выделить явно и давно -присутствующие на рынке: “интегрированные средства разработки” (IDE - -integrated developers environment), а также программные библиотеки/библиотеки -компонент (frameworks, libraries, components), без которых просто невозможно -представить сегодняшний процесс разработки, да и рынок программных средств, в -целом. Кроме того, в данной теме можно говорить и о таких функционально ёмких -“супер”-категориях, как “программная платформа” (например, Java, J2EE и -Microsoft .NET) и “платформа облачных вычислений” (например, Microsoft Azure, -Amazon и др.), которые включают наравне с инструментами, как таковыми, и -определенные модели конструирования, преобразования и выполнения кода. При -таком подходе, вероятно, обоснованным было бы введение класса “элементарных” -или “базовых инструментов конструирования”, к которому можно было бы отнести -редакторы, компиляторы, интерпретаторы, отладчики, средства документирования и -библиотеки, а также класса “комплексных средств конструирования” – -интегрированных сред и различных платформ, что, безусловно, не претендует на -истину в последней инстанции и является одной из возможных точек зрения. - -### Инструменты тестирования (Software Testing Tools) - -- Генераторы тестов (test generators). Эти инструменты помогают в разработке -сценариев тестирования. -- Средства выполнения тестов (test execution frameworks). Эти средства -обеспечивают среду исполнения тестовых сценариев в контролируемом окружении, -позволяющем отслеживать поведение объекта, подвергаемого тестированию. -- Инструменты оценки тестов (test evaluation tools). Эти инструменты -поддерживают оценку результатов выполнения тестов, помогая определить в какой -степени и где именно обнаруженное поведение <тестируемого объекта> -соответствует ожидаемому поведению. -- Средства управления тестами (test management tools). Эти средства -обеспечивают поддержку всех аспектов процесса тестирования программного -обеспечения. -- Инструменты анализа производительности (performance analysis tools). Эти -инструменты используются для количественной оценки и анализа производительности -программного обеспечения, являющегося специализированным видом тестирования, -цель которого – в оценки поведения программ в части производительности, в -отличие от тестирования <корректности> функционального поведения. - -Последний класс инструментов тестирования, в какой-то степени, показывает -недостаточность предложенной классификации, упуская, например, инструменты -функционального тестирования, средства тестирования безопасности, инструменты -тестирования пользовательского интерфейса, инструменты нагрузочного -тестирования и др., соответствующие, различным целям тестирования, -представленным в секции 2.2 области знаний SWEBOK “Тестирование”, и естественно -задающим “подвиды” возможного класса “специализированных или целевых -инструментов тестирования”, к которым, в частности, относится тестирование -производительности. - -### Инструменты сопровождения (Software Maintenance Tools) - -Эта тема охватывает инструменты, особенно важные для обеспечения сопровождения -существующего программного обеспечения, подверженного модификациям. SWEBOK -идентифицирует две категории таких инструментов: - -- Инструменты облегчения понимания (comprehension tools). Эти инструменты -помогают человеку в понимании программ. Примерами могут служить различные -средства визуализации. -- Инструменты реинжиниринга (reengineering tools). Эти инструменты поддерживают -деятельность по реинжинирингу, описанную в области знаний SWEBOK “Software -Maintenance”. - -Средства “обратного” инжиниринга (reverse engineering) помогают в процессе -восстановления для существующего программного обеспечения таких артефактов, как -спецификация и описание дизайна (архитектуры), которые, в дальнейшем, могут -быть трансформированы для генерации нового продукта на основе функциональности -существующего. - -Последнее замечание, в сочетании с типичной функциональностью современных -средств проектирования, поддерживающих анализ исходного кода (в случае -объектно-ориентированных систем) и его визуализацию (в том числе, -поведенческую, например, в виде диаграмм UML Sequence), позволяет объединить -упомянутые категории инструментов в единый класс “инструментов реинжиниринга”. -В то же время, деятельность по сопровождению и поддержке, в частности, -касающаяся сбоев и исправления обнаруженных ошибок в программном обеспечении, -требует, в определенной степени, отнесения к этой теме и средств -конфигурационного управления, рассматриваемых ниже (например, в части обработки -запросов на изменения). - -### Инструменты конфигурационного управления (Software Configuration Management Tools) - -Инструменты конфигурационного управления делятся на три категории: -- Инструменты отслеживания (tracking) дефектов, расширений и проблем. -- Инструменты управления версиями. -- Инструменты сборки и выпуска. Эти инструменты предназначены для управления -задачами сборки и выпуска продуктов, а также включают средства инсталляции. - -Дополнительная информация по данной теме представлена в области знаний SWEBOK -“Конфигурационное управление”. - -### Инструменты управления инженерной деятельностью (Software Engineering Management Tools) - -Средства управления деятельностью по программной инженерии делятся на три -категории: - -- Инструменты планирования и отслеживания проектов. Эти средства используются -календарного планирования работ, количественной оценки усилий и стоимостных -ожиданий, связанных с проектами. -- Инструменты управления рисками. Эти средства используются для идентификации, -оценки ожиданий и мониторинга рисков. -- Инструменты количественной оценки. Эти инструменты ведения измерений помогают -в выполнении работ, связанных с программой количественной оценки, проводимой в -отношении проектов программного обеспечения. - -Функциональные аспекты управления инженерной деятельностью достаточно детально -представлены в области знаний SWEBOK “Управление программной инженерией” -(Software Engineering Management). - -### Инструменты поддержки процессов (Software Engineering Process Tools) - -В описании этой темы в текущей версии SWEBOK наблюдается противоречие между -кратким делением на категории инструментов и их более детальным определением. -Скорее всего, такая несогласованность связана, в первую очередь, с отсутствием -достигнутого консенсуса в этой области. Базируясь на обеих классификациях, -упомянутых в SWEBOK, хотелость бы отметить несколько типов инструментов из -“смежных” областей, имеющих особое значение в поддержке процессов программной -инженерии: - -- Инструменты моделирования, позволяющие, в частности, описать и модель процессов, как таковую. -- Инструменты управления проектами. -- Инструменты конфигурационного управления, поддерживающие работу с актуальными -версиями всего комплекса артефактов проекта и, что не менее важно, позволяющие -задать поведенческие характеристики (в упрощенном понимании - workflow) и -атрибуты этих артефактов в форме элементов конфигураций. -- Ролевые платформы разработки программного обеспечения, охватывающие все -стадии жизненного цикла и, на сегодняшний день, являющиеся развитием -интегрированных средств разработки и CASE-инструментов в направлении поддержки -“смежной” функциональности – управления требованиями, работ по -конфигурационному управлению с поддержкой управления изменениями, тестирования -и оценки качества. - -Первые три вида инструментов в такой классификации позволяют описать -применяемые процессы программной инженерии. Четвертый класс – -“супер-интегрированные среды разработки”, называемые сегодня ролевыми -платформами разработки, обеспечивают поддержку заданных процессов, описанных, -например, в виде соответствующих правил на уровне глубоко интегрированных в -такие среды инструментов конфигурационного управления. - -### Инструменты обеспечения качества (Software Quality Tools) - -Средства обеспечения качества делятся на две категории: - -- Инструменты инспектирования. Эти средства используются для поддержки обзора -(review) и аудита. -- Инструменты (статического) анализа. Эти средства используются для анализа -программных артефактов, данных, потоков работ и зависимостей. Такие инструменты -предназначены для проверки определенных свойств или артефактов, в целом, на -соответствие <заданным характеристикам>. - -### Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues) - -Эта тема охватывает вопросы, касающиеся всех классов инструментов. Создателями -SWEBOK идентифицированы три категории таких аспектов: - -- Техники интеграции инструментов. Эти техники важны для естественного -использования сочетания различных инструментов. Типичные виды интеграции -инструментов включают платформы, представление, процессы, данные и управление. -- Мета-инструменты. Такие средства генерируют другие инструменты. Например, -классическим примером мета-инструмента является компилятор компиляторов. - -Оценка инструментов. Данная тема представляется достаточно важной в силу -постоянной эволюции инструментов программной инженерии. - -## Методы программной инженерии (Software Engineering Methods) - -Данная секция (подобласть) разделена на три темы: эвристические методы -(heuristic methods), касающиеся неформализованных подходов; формальные методы -(formal methods), обоснованные математически; методы прототипирования -(prototyping methods), базирующиеся на различных формах прототипирования. Эти -три темы не являются изолированными <друг от друга>, скорее они выделены исходя -из их значимости и на основе определенных достаточно явных индивидуальных -особенностей. Например, объектно-ориентированный подход может включать -формальные техники и использовать прототипирование для проверки и аттестации. -Так же как и инструменты, методы программной инженерии постоянно -эволюционируют. Именно поэтому, в описании данной области знаний авторы SWEBOK -постарались избежать, насколько это возможно, упоминания любых конкретных -методологий. - -### Эвристические методы (Heuristic Methods) - -Эта тема содержит четыре категории методов: структурные, ориентированные на -данные, объектно-ориентированные и ориентированные на область применения. - -- Структурные методы (structured methods). При таком подходе системы строится с -функциональной точки зрения, начиная с высокоуровневого понимания поведения -системы с постепенным уточнением низко-уровневых деталей. (такой подход, -иногда, также называют “проектированием сверху-вниз”) -- Методы, ориентированные на данные (data-oriented methods). Отправной точкой -такого подхода являются структуры данных, которыми манипулирует создаваемое -программное обеспечение. Функции в этом случае являются вторичными. -- Объектно-ориентированные методы (object-oriented methods). Система при таком -подходе рассматривается как коллекция объектов, а не функций. -- Методы, ориентированные на конкретную область применения (domain-specific -methods). Такие специализированные методы разрабатываются с учетом специфики -решаемых задач, например, систем реального времени, безопасности -<жизнедеятельности> (safety) и защищенности <от несанкционированного доступа> -(security). - -### Формальные методы (Formal Methods) - -Эта тема касается математических (строгих) методов программной инженерии. - -К сожалению, SWEBOK не дает здесь какого-либо определения формальных методов, -поэтому, хотелось бы привести в данном контексте характеристику, данную им -одним из классиков программной инженерии – Ианом Соммервиллем [Соммервилл, -2002, стр. 188]: “Термин формальные методы подразумевает ряд операций, в состав -которых входит создание формальной спецификации системы, анализ и -доказательство спецификаций, реализация системы на основе преобразования -формальной спецификации в программы и верификация программ. Все эти действия -зависят от формальной спецификации программного обеспечения. Формальная -спецификация – это системная спецификация, записанная на языке, словарь, -синтаксис и семантика которого определены формально. Необходимость формального -определения языка предполагает, что этот язык основывается на математических -концепциях. Здесь используется область математики, которая называется -дискретной математикой и основывается на алгебре, теории множеств и алгебре -логики.” - -Эти методы можно классифицировать в виде следующих категорий: - -- Языки и нотации специфицирования (specification languages and notations). -Языки спецификаций могут быть ориентированы на модель, свойства и поведение. По -мнению автора, ярким примером такого рода методов являются формальные методы -описания требований, интерес к которым периодически возникает на протяжении -всей истории программной инженерии. -- Уточнение (refinement). Данные подходы связаны с уточнением (трансформацией) -превращения спецификаций в конечный результат, максимально близкий желаемому. В -качестве результата применения таких методов рассматривается конечный - -исполнимый программный продукт. -- Подтверждение/доказательство (verification/proving properties). Этот подход -основывается на строгом доказательстве точности <любых> характеристик <исходных -предпосылок и получаемого продукта> с использованием теорем и проверки точности -моделей. - -История программной инженерии показала, что в области разработки прикладных -систем, обоснованность (в частности, в силу трудоемкости) применения формальных -методов не подтверждается на практике, за исключением случаев “скрытого” -(неявного для разработчиков) применения определенных формальных методов на -уровне внутренней реализации конкретных инструментов программной инженерии, -например, в средствах моделирования и проектирования. Иан Соммервилл дает такую -характеристику формальным методам [Соммервилл, 2002, стр. 188]: “Традиционные -технические дисциплины обычно легко адаптируют математические методы. Однако -инженерия программного обеспечения не идет таким путем. Хотя прошло более 25 -лет исследований по использованию математических методов в процессе создания -ПО, воздействие этих методов все же ограничено. Так называемые формальные методы -широко не используются. Многие компании, разрабатывающие ПО, не считают -экономически выгодным применение этих методов в процессе разработки.” - -### Методы прототипирования (Prototyping Methods) - -Эта тема охватывает методы, основанные на прототипировании программного -обеспечения. Они разделены на три категории: - -- Стили прототипирования. Идентифицированы следующие подходы, касающиеся стилей -прототипирования – создание временно используемых прототипов (throwaway), -эволюционное прототипирование (в подавляющем большинстве случаев предполагает -превращение прототипа в конечный продукт) и разработка исполняемых спецификаций -(часто основывается как на формальных методах). -- Цели прототипирования. Примерами таких целей служат требования, архитектурный -дизайн или пользовательский интерфейс. -- Техники оценки/исследования (evaluation) <результатов> прототипирования. Эти -аспекты касаются того, как именно будут использованы результаты создания -прототипа (например, будет ли он трансформирован в продукт, создается он для -оценки нагрузочных способностей и других аспектов масштабируемости и т.п.). blob - /dev/null blob + 94bee7c4314e825ef2f5b6a54fecadebd921a83e (mode 644) --- /dev/null +++ 9_software_engineering_tools_and_methods.md @@ -0,0 +1,442 @@ +# Инструменты и методы программной инженерии + +Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - +SWEBOK. + +Содержит перевод описания области знаний SWEBOK “Software Engineering Tools and +Methods”, с замечаниями и комментариями. + +Инструменты и методы программной инженерии (Software Engineering Tools and +Methods) + +Программные инструменты предназначены для обеспечения поддержки процессов +жизненного цикла программного обеспечения. Инструменты позволяют +автоматизировать определенные повторяющиеся действия, уменьшая загрузку +инженеров рутинными операциями и помогая им сконцентрироваться на творческих, +нестандартных аспектах реализации выполняемых процессов. Инструменты часто +проектируются с целью поддержки конкретных (частных) методов программной +инженерии, сокращая административную нагрузку, ассоциированную с “ручным” +применением соответствующих методов. Так же, как и методы программной +инженерии, инструменты призваны сделать программную инженерию более +систематической деятельностью и по своему содержанию (предлагаемой +функциональности) могут варьироваться от поддержки отдельных индивидуальных +задач вплоть до охвата всего жизненного цикла (в этом случае часто говорят об +инструментальной платформе или просто платформе разработки). + +Методы программной инженерии накладывают определенные структурные ограничения +на деятельность в рамках программной инженерии с целью приведения этой +деятельности в соответствие с заданным систематическим подходом и более +вероятным и скорым, с точки зрения соответствующего метода, достижением успеха. +Методы обычно предоставляют соответствующие соглашения (нотацию), словарь +<терминов и понятий> и процедуры выполнения идентифицированных (и охватываемых +методом) задач, а также рекомендации по оценке и проверке <выполняемого> +процесса и <получаемого в его результате> продукта. Методы, как и инструменты, +варьируются по содержанию (охватываемой области применения) от отдельной фазы +жизненного цикла (или даже процесса) до всего жизненного цикла. Данная область +знаний касается только методов, охватывающих множество фаз (этапов) жизненного +цикла. Те методы, применение которых фокусируется на отдельных фазах жизненного +цикла или частных процессах, описаны в соответствующих областях знаний. + +Существует множество детальных описаний и руководств по конкретным +инструментам, и исследований, посвященных анализу (и категоризации, в первую +очередь, со стороны аналитиков) уже применяемых и новых инструментальных +средств (и вероятным направлениям их развития). В таком контексте, общее +техническое описание инструментов программной инженерии, действительно, может +отпугнуть. (В то же время, с точки зрения автора, при всей неоднозначности +любой категоризации инструментов, может быть сформирован общий взгляд на их +целевую функциональность, пусть в чем то и спорный, что, отразится в +определенных случаях ниже в соответствующих авторских комментариях). Одна из +основных сложностей такого описания, в общем случае, заключается в высокой +изменчивости и быстром эволюционировании программных инструментов. Конкретные +аспекты функциональности инструментов достаточно быстро изменяются, что +усложняет приведение конкретных актуальных примеров. + +Данная область знаний охватывает все процессы жизненного цикла и, +соответственно, связана со всеми другими областями знаний SWEBOK. + +![Рисунок 1. Область знаний “Инструменты и методы программной инженерии” [SWEBOK, 2004, с.10-1, рис. 1]](images/tools_area_small.jpg) + +## Инструменты программной инженерии (Software Engineering Tools) + +Первые пять тем данной секции соответствуют первым пяти областям знаний SWEBOK +- требования, проектирование, конструирование, тестирование и сопровождение. +Следующие четыре темы касаются оставшихся четырех областей знаний – +конфигурационного управления, управления программной инженерией, процессов и +качества, соответственно. Также в данной секции представлена еще одна тема – +“Дополнительные аспекты инструментального обеспечения” (в оригинале SWEBOK она +называется “Miscellaneous”), посвященная таким вопросам как, например, +интеграция инструментов, которые потенциально касаются всех классов +инструментов. + +### Инструменты работы с требованиями (Software Requirements Tools) + +SWEBOK говорит о том, что инструменты, применяемые для работы с требованиями +могут быть классифицированы в две категории: средства моделирования (modeling) +и средства трассировки (traceability). Однако, на практике, моделирование +требований, все же, является частью управления требований, как, кстати, и +трассировка. В принципе, инструменты трассировки могут быть рассмотрены как +самостоятельная категория, в силу своей значимости при проведении анализа +требований, в первую очередь, анализа влияний требований и изменений (т.н. +“impact analysis”). Но моделирование требований лишь часть управления +требованиями. Поэтому, в приведенной ниже классификации предлагаемая +модификация оригинального SWEBOK состоит в том, что вместо “инструментов +моделирования требований” используется термин “инструменты управления +требованиями”, при сохранении оригинального содержания данной темы SWEBOK. +Соответственно, + +- Инструменты управления требованиями (моделирования требований – Requirements +modeling tools). Эти инструменты используются для извлечения (eliciting), +анализа, специфицирования и проверки программных требований. +- Инструменты трассировки требований (Requirement traceability tools). Эти +инструменты становятся все более важными по мере повышения сложности +программного обеспечения. В силе того, что они также относятся и к другим +процессам жизненного цикла, здесь они представлены в качестве самостоятельной +категории средств работы с требованиями. + +Необходимо заметить, что трассировка является неотъемлемой частью полноценной +работы с требованиями, что приводит к естественному объединению предлагаемых +SWEBOK категорий инструментов в единый класс “инструментов управления +требованиями”, функциональное содержание которых может варьироваться, например, +в зависимости от сложности проектов и уровня зрелости процессов. Если мы +обратимся, например, к модели CMMI Staged, мы увидим, что на 2-м уровне +зрелости речь идет об “управлении требованиями” – Requirement Management, а на +3-м уровне зрелости обсуждается “разработка требований” – Requirement +Development, обладающая более ёмким содержанием. В то же самое время, с +технократической точки зрения, требования могут восприниматься и как элементы +конфигураций, наравне с запросами на изменения и другими активами проекта (см. +область знаний SWEBOK “Конфигурационное управление”). Таким образом, в ряде +случаев (что подтверждается конкретными программными средствами, доступными на +рынке программного обеспечения), в качестве инструмента работы с требованиями +может выступать и система конфигурационного управления, если, конечно, она +изначально не ограничена базовой функциональностью контроля версий <файлов>. С +другой стороны, сегодняшние средства моделирования на основе UML и BPMN могут +также рассматриваться как элементы инструментального обеспечения работы с +требованиями, что часто отражается в их функциональности, включающей тесную +интеграцию с “классическими” средствами управления требованиями, а сама +интеграция воплощена не только в визуальном представлении работы с +репозиториями требований, но и в автоматизации трассировки между моделями +(и/или их элементами) и требованиями, соответственно. + +### Инструменты проектирования (Software Design Tools) + +Эта тема охватывает инструменты для создания и проверки программного дизайна. +Существует большое разнообразие таких инструментов, использующих различные +нотации (соглашения, в том числе визуальные) и методы. Несмотря на такое +разнообразие, <авторами SWEBOK> не было найдено <адекватной> классификации этих +инструментов. + +Однако, в данном случае, все же возможно разделение инструментов по нескольким +критериям, например, применяемым базовым нотациям моделирования и +проектирования (SADT/IDEF, UML, BPMN/BPEL, Microsoft DSL и т.п.) или целевым +задачам (бизнес-моделирование, проектирование БД, объектно-ориентированное +проектирование, интеграционное/SOA-проектирование и т.п.). + +### Инструменты конструирования (Software Construction Tools) + +Данная тема касается инструментальных средств конструирования программного +обеспечения, в соответствии с пониманием “конструирования”, заданным +соответствующей областью знаний SWEBOK, рассматривавшейся ранее. Эти +инструменты используются для производства и трансляции программного +представления (например, исходного кода), достаточно детального и явного для +машинного выполнения. + +- Редакторы (program editors). Эти инструменты используются для создания и +модификации <исходного кода> программ и, возможно, ассоциированной с ними +документации. Это могут быть как редакторы “общего назначения” (что на +протяжении многих лет наблюдается в UNIX и unix-подобных средах) или +специализированные редакторы с поддержкой специфики целевого языка +программирования (что является, в большинстве случаев, прерогативой +интегрированных сред разработки – IDE). В то же время, документирование все же +является не только и не столько частью редактора, сколько самостоятельной +функциональностью, пусть часто и тесно интегрированной с редактором. +- Компиляторы и генераторы кода (compilers and code generators). Традиционно, +компиляторы являлись неинтерактивными (командными) трансляторами исходного +кода. Однако, существует тенденция (с точки зрения автора, более чем явная, что +отмечено ниже) интеграции компиляторов и редакторов в интегрированные среды +программирования. К этому классу также относятся препроцессоры, +линковщики/загрузчики, а также генераторы кода (за исключением, может быть, +объектно-ориентированных средств проектирования, поддерживающих связь с +исходным кодом и имеющих тенденцию быть тесно интегрированными с новым +поколением IDE). +- Интерпретаторы (interpreters). Эти инструменты обеспечивают исполнение +программ посредством эмуляции. Они могут поддерживать действия по +конструированию программного обеспечения, предоставляя для исполнения программ +окружение, более контролируемое и поддающееся наблюдению, чем это обычно +способна сделать та или иная операционная система. +- Хочется отметить определенное “слияние”, если так можно выразиться, между +компиляторами и интерпретаторами. Ярким тому свидетельством является +использование так называемой just-in-time компиляции – компиляции “на лету”, +когда промежуточный программный код, по мере исполнения или с опережением +(например, в процессе запуска/загрузки программы) преобразуется в набор +инструкций, исполняемых непосредственно средствами операционной системы, но под +контролем среды исполнения, в первую очередь, с точки зрения безопасности. +Такого рода подход стал родоначальником ряда современных программных платформ, +например, Java и .NET. На этом фоне, возможно было бы объединить интерпретаторы +с компиляторами и генераторами кода, как средства непосредственной подготовки +(трансляции) исходного кода к исполнению. +- Отладчики (debuggers). Эти инструменты было принято выделить в +самостоятельную категорию, так как они поддерживают процесс конструирования +программного обеспечения, но, в то же время, <функционально> отличаются от +редакторов и компиляторов. + +С точки зрения классификации инструментов необходимо выделить явно и давно +присутствующие на рынке: “интегрированные средства разработки” (IDE - +integrated developers environment), а также программные библиотеки/библиотеки +компонент (frameworks, libraries, components), без которых просто невозможно +представить сегодняшний процесс разработки, да и рынок программных средств, в +целом. Кроме того, в данной теме можно говорить и о таких функционально ёмких +“супер”-категориях, как “программная платформа” (например, Java, J2EE и +Microsoft .NET) и “платформа облачных вычислений” (например, Microsoft Azure, +Amazon и др.), которые включают наравне с инструментами, как таковыми, и +определенные модели конструирования, преобразования и выполнения кода. При +таком подходе, вероятно, обоснованным было бы введение класса “элементарных” +или “базовых инструментов конструирования”, к которому можно было бы отнести +редакторы, компиляторы, интерпретаторы, отладчики, средства документирования и +библиотеки, а также класса “комплексных средств конструирования” – +интегрированных сред и различных платформ, что, безусловно, не претендует на +истину в последней инстанции и является одной из возможных точек зрения. + +### Инструменты тестирования (Software Testing Tools) + +- Генераторы тестов (test generators). Эти инструменты помогают в разработке +сценариев тестирования. +- Средства выполнения тестов (test execution frameworks). Эти средства +обеспечивают среду исполнения тестовых сценариев в контролируемом окружении, +позволяющем отслеживать поведение объекта, подвергаемого тестированию. +- Инструменты оценки тестов (test evaluation tools). Эти инструменты +поддерживают оценку результатов выполнения тестов, помогая определить в какой +степени и где именно обнаруженное поведение <тестируемого объекта> +соответствует ожидаемому поведению. +- Средства управления тестами (test management tools). Эти средства +обеспечивают поддержку всех аспектов процесса тестирования программного +обеспечения. +- Инструменты анализа производительности (performance analysis tools). Эти +инструменты используются для количественной оценки и анализа производительности +программного обеспечения, являющегося специализированным видом тестирования, +цель которого – в оценки поведения программ в части производительности, в +отличие от тестирования <корректности> функционального поведения. + +Последний класс инструментов тестирования, в какой-то степени, показывает +недостаточность предложенной классификации, упуская, например, инструменты +функционального тестирования, средства тестирования безопасности, инструменты +тестирования пользовательского интерфейса, инструменты нагрузочного +тестирования и др., соответствующие, различным целям тестирования, +представленным в секции 2.2 области знаний SWEBOK “Тестирование”, и естественно +задающим “подвиды” возможного класса “специализированных или целевых +инструментов тестирования”, к которым, в частности, относится тестирование +производительности. + +### Инструменты сопровождения (Software Maintenance Tools) + +Эта тема охватывает инструменты, особенно важные для обеспечения сопровождения +существующего программного обеспечения, подверженного модификациям. SWEBOK +идентифицирует две категории таких инструментов: + +- Инструменты облегчения понимания (comprehension tools). Эти инструменты +помогают человеку в понимании программ. Примерами могут служить различные +средства визуализации. +- Инструменты реинжиниринга (reengineering tools). Эти инструменты поддерживают +деятельность по реинжинирингу, описанную в области знаний SWEBOK “Software +Maintenance”. + +Средства “обратного” инжиниринга (reverse engineering) помогают в процессе +восстановления для существующего программного обеспечения таких артефактов, как +спецификация и описание дизайна (архитектуры), которые, в дальнейшем, могут +быть трансформированы для генерации нового продукта на основе функциональности +существующего. + +Последнее замечание, в сочетании с типичной функциональностью современных +средств проектирования, поддерживающих анализ исходного кода (в случае +объектно-ориентированных систем) и его визуализацию (в том числе, +поведенческую, например, в виде диаграмм UML Sequence), позволяет объединить +упомянутые категории инструментов в единый класс “инструментов реинжиниринга”. +В то же время, деятельность по сопровождению и поддержке, в частности, +касающаяся сбоев и исправления обнаруженных ошибок в программном обеспечении, +требует, в определенной степени, отнесения к этой теме и средств +конфигурационного управления, рассматриваемых ниже (например, в части обработки +запросов на изменения). + +### Инструменты конфигурационного управления (Software Configuration Management Tools) + +Инструменты конфигурационного управления делятся на три категории: +- Инструменты отслеживания (tracking) дефектов, расширений и проблем. +- Инструменты управления версиями. +- Инструменты сборки и выпуска. Эти инструменты предназначены для управления +задачами сборки и выпуска продуктов, а также включают средства инсталляции. + +Дополнительная информация по данной теме представлена в области знаний SWEBOK +“Конфигурационное управление”. + +### Инструменты управления инженерной деятельностью (Software Engineering Management Tools) + +Средства управления деятельностью по программной инженерии делятся на три +категории: + +- Инструменты планирования и отслеживания проектов. Эти средства используются +календарного планирования работ, количественной оценки усилий и стоимостных +ожиданий, связанных с проектами. +- Инструменты управления рисками. Эти средства используются для идентификации, +оценки ожиданий и мониторинга рисков. +- Инструменты количественной оценки. Эти инструменты ведения измерений помогают +в выполнении работ, связанных с программой количественной оценки, проводимой в +отношении проектов программного обеспечения. + +Функциональные аспекты управления инженерной деятельностью достаточно детально +представлены в области знаний SWEBOK “Управление программной инженерией” +(Software Engineering Management). + +### Инструменты поддержки процессов (Software Engineering Process Tools) + +В описании этой темы в текущей версии SWEBOK наблюдается противоречие между +кратким делением на категории инструментов и их более детальным определением. +Скорее всего, такая несогласованность связана, в первую очередь, с отсутствием +достигнутого консенсуса в этой области. Базируясь на обеих классификациях, +упомянутых в SWEBOK, хотелость бы отметить несколько типов инструментов из +“смежных” областей, имеющих особое значение в поддержке процессов программной +инженерии: + +- Инструменты моделирования, позволяющие, в частности, описать и модель процессов, как таковую. +- Инструменты управления проектами. +- Инструменты конфигурационного управления, поддерживающие работу с актуальными +версиями всего комплекса артефактов проекта и, что не менее важно, позволяющие +задать поведенческие характеристики (в упрощенном понимании - workflow) и +атрибуты этих артефактов в форме элементов конфигураций. +- Ролевые платформы разработки программного обеспечения, охватывающие все +стадии жизненного цикла и, на сегодняшний день, являющиеся развитием +интегрированных средств разработки и CASE-инструментов в направлении поддержки +“смежной” функциональности – управления требованиями, работ по +конфигурационному управлению с поддержкой управления изменениями, тестирования +и оценки качества. + +Первые три вида инструментов в такой классификации позволяют описать +применяемые процессы программной инженерии. Четвертый класс – +“супер-интегрированные среды разработки”, называемые сегодня ролевыми +платформами разработки, обеспечивают поддержку заданных процессов, описанных, +например, в виде соответствующих правил на уровне глубоко интегрированных в +такие среды инструментов конфигурационного управления. + +### Инструменты обеспечения качества (Software Quality Tools) + +Средства обеспечения качества делятся на две категории: + +- Инструменты инспектирования. Эти средства используются для поддержки обзора +(review) и аудита. +- Инструменты (статического) анализа. Эти средства используются для анализа +программных артефактов, данных, потоков работ и зависимостей. Такие инструменты +предназначены для проверки определенных свойств или артефактов, в целом, на +соответствие <заданным характеристикам>. + +### Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues) + +Эта тема охватывает вопросы, касающиеся всех классов инструментов. Создателями +SWEBOK идентифицированы три категории таких аспектов: + +- Техники интеграции инструментов. Эти техники важны для естественного +использования сочетания различных инструментов. Типичные виды интеграции +инструментов включают платформы, представление, процессы, данные и управление. +- Мета-инструменты. Такие средства генерируют другие инструменты. Например, +классическим примером мета-инструмента является компилятор компиляторов. + +Оценка инструментов. Данная тема представляется достаточно важной в силу +постоянной эволюции инструментов программной инженерии. + +## Методы программной инженерии (Software Engineering Methods) + +Данная секция (подобласть) разделена на три темы: эвристические методы +(heuristic methods), касающиеся неформализованных подходов; формальные методы +(formal methods), обоснованные математически; методы прототипирования +(prototyping methods), базирующиеся на различных формах прототипирования. Эти +три темы не являются изолированными <друг от друга>, скорее они выделены исходя +из их значимости и на основе определенных достаточно явных индивидуальных +особенностей. Например, объектно-ориентированный подход может включать +формальные техники и использовать прототипирование для проверки и аттестации. +Так же как и инструменты, методы программной инженерии постоянно +эволюционируют. Именно поэтому, в описании данной области знаний авторы SWEBOK +постарались избежать, насколько это возможно, упоминания любых конкретных +методологий. + +### Эвристические методы (Heuristic Methods) + +Эта тема содержит четыре категории методов: структурные, ориентированные на +данные, объектно-ориентированные и ориентированные на область применения. + +- Структурные методы (structured methods). При таком подходе системы строится с +функциональной точки зрения, начиная с высокоуровневого понимания поведения +системы с постепенным уточнением низко-уровневых деталей. (такой подход, +иногда, также называют “проектированием сверху-вниз”) +- Методы, ориентированные на данные (data-oriented methods). Отправной точкой +такого подхода являются структуры данных, которыми манипулирует создаваемое +программное обеспечение. Функции в этом случае являются вторичными. +- Объектно-ориентированные методы (object-oriented methods). Система при таком +подходе рассматривается как коллекция объектов, а не функций. +- Методы, ориентированные на конкретную область применения (domain-specific +methods). Такие специализированные методы разрабатываются с учетом специфики +решаемых задач, например, систем реального времени, безопасности +<жизнедеятельности> (safety) и защищенности <от несанкционированного доступа> +(security). + +### Формальные методы (Formal Methods) + +Эта тема касается математических (строгих) методов программной инженерии. + +К сожалению, SWEBOK не дает здесь какого-либо определения формальных методов, +поэтому, хотелось бы привести в данном контексте характеристику, данную им +одним из классиков программной инженерии – Ианом Соммервиллем [Соммервилл, +2002, стр. 188]: “Термин формальные методы подразумевает ряд операций, в состав +которых входит создание формальной спецификации системы, анализ и +доказательство спецификаций, реализация системы на основе преобразования +формальной спецификации в программы и верификация программ. Все эти действия +зависят от формальной спецификации программного обеспечения. Формальная +спецификация – это системная спецификация, записанная на языке, словарь, +синтаксис и семантика которого определены формально. Необходимость формального +определения языка предполагает, что этот язык основывается на математических +концепциях. Здесь используется область математики, которая называется +дискретной математикой и основывается на алгебре, теории множеств и алгебре +логики.” + +Эти методы можно классифицировать в виде следующих категорий: + +- Языки и нотации специфицирования (specification languages and notations). +Языки спецификаций могут быть ориентированы на модель, свойства и поведение. По +мнению автора, ярким примером такого рода методов являются формальные методы +описания требований, интерес к которым периодически возникает на протяжении +всей истории программной инженерии. +- Уточнение (refinement). Данные подходы связаны с уточнением (трансформацией) +превращения спецификаций в конечный результат, максимально близкий желаемому. В +качестве результата применения таких методов рассматривается конечный - +исполнимый программный продукт. +- Подтверждение/доказательство (verification/proving properties). Этот подход +основывается на строгом доказательстве точности <любых> характеристик <исходных +предпосылок и получаемого продукта> с использованием теорем и проверки точности +моделей. + +История программной инженерии показала, что в области разработки прикладных +систем, обоснованность (в частности, в силу трудоемкости) применения формальных +методов не подтверждается на практике, за исключением случаев “скрытого” +(неявного для разработчиков) применения определенных формальных методов на +уровне внутренней реализации конкретных инструментов программной инженерии, +например, в средствах моделирования и проектирования. Иан Соммервилл дает такую +характеристику формальным методам [Соммервилл, 2002, стр. 188]: “Традиционные +технические дисциплины обычно легко адаптируют математические методы. Однако +инженерия программного обеспечения не идет таким путем. Хотя прошло более 25 +лет исследований по использованию математических методов в процессе создания +ПО, воздействие этих методов все же ограничено. Так называемые формальные методы +широко не используются. Многие компании, разрабатывающие ПО, не считают +экономически выгодным применение этих методов в процессе разработки.” + +### Методы прототипирования (Prototyping Methods) + +Эта тема охватывает методы, основанные на прототипировании программного +обеспечения. Они разделены на три категории: + +- Стили прототипирования. Идентифицированы следующие подходы, касающиеся стилей +прототипирования – создание временно используемых прототипов (throwaway), +эволюционное прототипирование (в подавляющем большинстве случаев предполагает +превращение прототипа в конечный продукт) и разработка исполняемых спецификаций +(часто основывается как на формальных методах). +- Цели прототипирования. Примерами таких целей служат требования, архитектурный +дизайн или пользовательский интерфейс. +- Техники оценки/исследования (evaluation) <результатов> прототипирования. Эти +аспекты касаются того, как именно будут использованы результаты создания +прототипа (например, будет ли он трансформирован в продукт, создается он для +оценки нагрузочных способностей и других аспектов масштабируемости и т.п.). blob - ef9160eed97aaf5198de653c13e9048edbd7bafb blob + 934da1dda1548c992cbd4abe4a9bf6c779606faf --- Makefile +++ Makefile @@ -1,16 +1,16 @@ -MAKRDOWN_FILES += 0_introduction.markdown -MAKRDOWN_FILES += 1_software_requirements.markdown -MAKRDOWN_FILES += 2_software_design.markdown -MAKRDOWN_FILES += 3_software_construction.markdown -MAKRDOWN_FILES += 4_software_testing.markdown -MAKRDOWN_FILES += 5_software_maintenance.markdown -MAKRDOWN_FILES += 6_software_configuration_management.markdown -MAKRDOWN_FILES += 7_software_engineering_management.markdown -MAKRDOWN_FILES += 8_software_engineering_process.markdown -MAKRDOWN_FILES += 9_software_engineering_tools_and_methods.markdown -MAKRDOWN_FILES += 10_software_quality.markdown -MAKRDOWN_FILES += software_lifecycle_models.markdown -MAKRDOWN_FILES += bibliography.markdown +MAKRDOWN_FILES += 0_introduction.md +MAKRDOWN_FILES += 1_software_requirements.md +MAKRDOWN_FILES += 2_software_design.md +MAKRDOWN_FILES += 3_software_construction.md +MAKRDOWN_FILES += 4_software_testing.md +MAKRDOWN_FILES += 5_software_maintenance.md +MAKRDOWN_FILES += 6_software_configuration_management.md +MAKRDOWN_FILES += 7_software_engineering_management.md +MAKRDOWN_FILES += 8_software_engineering_process.md +MAKRDOWN_FILES += 9_software_engineering_tools_and_methods.md +MAKRDOWN_FILES += 10_software_quality.md +MAKRDOWN_FILES += software_lifecycle_models.md +MAKRDOWN_FILES += bibliography.md PANDOC = pandoc PANDOC_OPT += --toc blob - ca52057605bb170091b6e1bfa7851f6f05ec90eb (mode 644) blob + /dev/null --- bibliography.markdown +++ /dev/null @@ -1,110 +0,0 @@ -# Дополнительная библиография - -- [Ambler, 2004] - Scott W. Ambler. One Piece at a Time. Software Development -Magazine, December 2004. http://www.sdmagazine.com/ -- [Ambler, 2005] - Scott W. Ambler, John Nalbone, Michael J. Vizdos. The -Enterprise Unified Process: Extending the Rational Unified Process. Prentice -Hall PTR (ISBN 0-13-191451-0) 2005 -- [APM PMBoK, 2000] - Project Management Body of Knowledge. Fourth Edition. -Association of Project Management, 2000. -http://www.apm.org.uk/ -- [Boehm, 1988] – Barry W. Boehm. A Spiral Model of Software Development and -Enhancement, Computer, May 1988, pp. 61-72. -http://www.computer.org/computer/homepage/misc/Boehm/index.htm -- [Boehm, 2000] – Barry W. Boehm. Spiral Development: Experience, Principles, -and Refinements. Spiral Experience Workshop, February 9, 2000 / Special Report -CMU/SEI-2000-SR-008, July, 2000. http://www.sei.cmu.edu/cbs/spiral2000/Boehm -- [Chaos, 2004] – CHAOS Research Results. 2004 Third Quarter Research Report. -The Standish Group International, Inc., 2004. -- [CMMI 1.1, 2002] - Capability Maturity Model Integration, Version 1.1. [CMMI -1.1, 2002] - Capability Maturity Model Integration, Version 1.1. CMMISM for -Systems Engineering, Software Engineering, Integrated Product and Process -Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1). Software -Engineering Institute (SEI), Carnegie Mellon University (CMU), 2002. -http://www.sei.cmu.edu/cmmi/ -- [DeMarco, 1999] – The Paradox of Software Architecture and Design”, Stevens -Prize Lecture, August, 1999. -- [E-Gov, 2002] – E-Gov Enterprise Architecture Guidance (Common Reference -Model), FEA Working Group (Draft), July 25, 2002]. -http://www.feapmo.gov/resources/E-Gov_Guidance_Final_Draft_v2.0.pdf -- [Fred Brooks, 1987] – Классическая статья Фреда Брукса (Frederick P. Brooks, -Jr.), заставившая по-новому взглянуть индустрию программного обеспечения на -самою себя. - No Silver Bullet: Essence and Accidents of Software Engineering. -IEEE Computer, April, 1987. http://www.computer.org/computer/homepage/misc/Brooks/ -- [PMBOK US DoD Ext, 2003] - U.S. Department of Defense (DoD) Extension to: A -Guide to the Project Management Body of Knowledge (PMBOK Guide). First Edition, -Version 1.0. PMI Standard. The Defense Acquisition University (DAU), June, 2003. http://www.dau.mil/pubs/gdbkspmbok.asp -- [PMI PMBOK, 2000] – A Guide to the Project Management Body of Knowledge. -(PMBOK® Guide). Second Edition. Project Management Institute, Inc., 2000. -http://www.pmi.org/ -- [PMI PMBOK3, 2004] – A Guide to the Project Management Body of Knowledge. -(PMBOK® Guide). Third Edition. Project Management Institute, Inc., 2004. -http://www.pmi.org/ -- [PMI PMBOK3, 2004, Рус] – Руководство к Своду знаний по управлению проектами. -(Руководство PMBOK®). Третье издание. Издание на русском языке. Project -Management Institute, Inc., 2004. http://www.pmi.org/ -- [PMI WBS, 2001] - Practice Standard for Work Breakdown Structures. Project -Management Institute, Inc., 2001. http://www.pmi.org/ -- [SE, 2004] - Software Engineering 2004. Curriculum Guidelines for -Undergraduate Degree Programs in Software Engineering. A Volume of the -Computing Curricula Series. The Joint Task Force on Computing Curricula, IEEE -Computer Society, Association for Computing Machinery, August 23, 2004. -http://sites.computer.org/ccse/ -- [SWEBOK, 2004] - Guide to Software Engineering Base of Knowledge (SWEBOK). -IEEE Computer Society, 2004. http://www.swebok.org/ -- [TOGAF, 2003] – The Open Group Architecture Framework (TOGAF). Version 8.1 -The Open Group, 2003. http://www.opengroup.org/architecture/togaf8/index8.htm -- [Zachman] – The Zachman Framework for Enterprise Architecture, John A. -Zachman, ZIFA - Zachman Institute for Framework Advancement. http://www.zifa.com -- [Амблер, 2002] – Скотт Амблер. Гибкие технологии: экстремальное -программирование и унифицированный процесс разработки. Wiley (ISBN -0-471-20282-7), 2002 - Scott W. Ambler, Agile Modeling: Effective Practices for -Extreme Programming, 2002; перевод и издание на русском языке: ЗАО Издательский -дом “Питер” (ISBN 5-94723-545-5), 2005 -- [Арчибальд, 2003] – Рассел Д. Арчибальд. Управление высоко-технологичными -программами и проектами. Издание третье, переработанное и дополненное. John -Wiley & Sons, Inc. (ISBN 0-471-26557-8) 1976 – Russel D. Archibald, 2003; -перевод и издание на русском языке: АйТи (ISBN 5-98453-002-3) - ДМК Пресс -(ISBN 5-94074-214-9) 2004. -- [Арчибальд, 2005] – Рассел Д. Арчибальд. Искусство управления проектами: -состояние и перспективы. Возможности и уровень зрелости организации в -управлении проектами. Информационно-аналитический журнал “Управление -проектами”, N1 (1), март 2005, стр. 14-23. http://www.pmmagazine.ru -- [Брукс, 1995] – Фредерик Брукс. Мифический человеко-месяц или как создаются -программные системы. 2-е издание, юбилейное. Addison-Wesley Longman, Inc. (ISBN -0-201-83595-9), 1995. Издательство Символ-Плюс (ISBN 5-93286-005-7), 2000, 2005. -- [Вигерс, 2003] – Карл И. Вигерс. Разработка требований к программному -обеспечению. Издательско-торговый дом “Русская редакция”, перевод на русский -язык второй редакции книги – Microsoft Corporation (ISBN 5-7502-0240-2), 2004. -Оригинальное издание на английском языке: Software Requirements. Second -Edition. Karl E. Wiegers, Microsoft Press (ISBN 0-7356-1879-8), 2003. -- [Грей и Ларсон, 2003] – Клиффорд Ф. Грей, Эрик У. Ларсон. Управление -проектами: Практическое русководство. Издательство “Дело и Сервис” (ISBN -5-8018-0152-9), 2003. The McGraw-Hill Companies, Inc. (ISBN 0-07-365812-X), 2000. -- [ГОСТ 12207, 1999] – Информационная технология. Процессы Жизненного Цикла -Программных Средств. ГОСТ Р ИСО/МЭК 12207-99, Государственный Стандарт -Российской Федерации, 1999. Госстандарт России, Москва, 2000. -- [ГОСТ 34, 1990] – Информационная технология. Комплекс стандартов и -руководящих документов на автоматизированные системы. Термины и определения. -ГОСТ 34.003-90, Государственный Стандарт Российской Федерации, 1999. -Госстандарт России, Москва, 1990. -- [Кантор, 2002] – Марри Кантор. Управление программными проектами. -Практическое руководство по разработке успешного программного обеспечения. -Издательский дом “Вильямс” (ISBN 5-8459-0294-0), 2002. Addison Wesley (ISBN -0-2017-0044-1), 2002. -- [СОВНЕТ НТК, 2000] - Национальные требования к компетентности специалистов по -Управлению Проектами (НТК). Ассоциация по Управлению Проектами СОВНЕТ, 2000. -http://www.sovnet.ru/ntk2000/index.php -- [Соммервилл, 2000] – Иан Соммервилл. Инженерия программного обеспечения. 6-е -издание. Издательский дом “Вильямс” (ISBN 5-8459-0330-0), 2002. Addison Wesley -(ISBN 0-201-39815-X), 2001. -- [Товб А., Ципес Г., 2003] – А.С. Товб, Г.Л. Ципес. Управление проектами: -стандарты, методы, опыт. Второе издание. Товб А.С., Ципес Г.Л., 2003 – ЗАО -“Олимп-Бизнес” (ISBN 5-9693-0038-1) 2003, 2005. -- [Фатрелл, Шафер и Шафер, 2003] – Роберт Т. Фатрелл, Дональд Ф. Шафер, Линда -И. Шафер. Управление программными проектами: достижение оптимального качества -при минимуме затрат. Издательский дом “Вильямс” (ISBN 5-8459-0413-7), 2003. -Addison-Wesley Publishing Company, Inc. (ISBN 0-13-091297-2), 2002. -- [Фаулер, 2004] – Мартин Фаулер. UML. Основы. Краткое руководство по -стандартному языку объектного моделирования. 3-е издание. Издательство -“Символ-Плюс” (ISBN 5-93286-060-X), Санкт-Петербург, 2004. blob - /dev/null blob + ca52057605bb170091b6e1bfa7851f6f05ec90eb (mode 644) --- /dev/null +++ bibliography.md @@ -0,0 +1,110 @@ +# Дополнительная библиография + +- [Ambler, 2004] - Scott W. Ambler. One Piece at a Time. Software Development +Magazine, December 2004. http://www.sdmagazine.com/ +- [Ambler, 2005] - Scott W. Ambler, John Nalbone, Michael J. Vizdos. The +Enterprise Unified Process: Extending the Rational Unified Process. Prentice +Hall PTR (ISBN 0-13-191451-0) 2005 +- [APM PMBoK, 2000] - Project Management Body of Knowledge. Fourth Edition. +Association of Project Management, 2000. +http://www.apm.org.uk/ +- [Boehm, 1988] – Barry W. Boehm. A Spiral Model of Software Development and +Enhancement, Computer, May 1988, pp. 61-72. +http://www.computer.org/computer/homepage/misc/Boehm/index.htm +- [Boehm, 2000] – Barry W. Boehm. Spiral Development: Experience, Principles, +and Refinements. Spiral Experience Workshop, February 9, 2000 / Special Report +CMU/SEI-2000-SR-008, July, 2000. http://www.sei.cmu.edu/cbs/spiral2000/Boehm +- [Chaos, 2004] – CHAOS Research Results. 2004 Third Quarter Research Report. +The Standish Group International, Inc., 2004. +- [CMMI 1.1, 2002] - Capability Maturity Model Integration, Version 1.1. [CMMI +1.1, 2002] - Capability Maturity Model Integration, Version 1.1. CMMISM for +Systems Engineering, Software Engineering, Integrated Product and Process +Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1). Software +Engineering Institute (SEI), Carnegie Mellon University (CMU), 2002. +http://www.sei.cmu.edu/cmmi/ +- [DeMarco, 1999] – The Paradox of Software Architecture and Design”, Stevens +Prize Lecture, August, 1999. +- [E-Gov, 2002] – E-Gov Enterprise Architecture Guidance (Common Reference +Model), FEA Working Group (Draft), July 25, 2002]. +http://www.feapmo.gov/resources/E-Gov_Guidance_Final_Draft_v2.0.pdf +- [Fred Brooks, 1987] – Классическая статья Фреда Брукса (Frederick P. Brooks, +Jr.), заставившая по-новому взглянуть индустрию программного обеспечения на +самою себя. - No Silver Bullet: Essence and Accidents of Software Engineering. +IEEE Computer, April, 1987. http://www.computer.org/computer/homepage/misc/Brooks/ +- [PMBOK US DoD Ext, 2003] - U.S. Department of Defense (DoD) Extension to: A +Guide to the Project Management Body of Knowledge (PMBOK Guide). First Edition, +Version 1.0. PMI Standard. The Defense Acquisition University (DAU), June, 2003. http://www.dau.mil/pubs/gdbkspmbok.asp +- [PMI PMBOK, 2000] – A Guide to the Project Management Body of Knowledge. +(PMBOK® Guide). Second Edition. Project Management Institute, Inc., 2000. +http://www.pmi.org/ +- [PMI PMBOK3, 2004] – A Guide to the Project Management Body of Knowledge. +(PMBOK® Guide). Third Edition. Project Management Institute, Inc., 2004. +http://www.pmi.org/ +- [PMI PMBOK3, 2004, Рус] – Руководство к Своду знаний по управлению проектами. +(Руководство PMBOK®). Третье издание. Издание на русском языке. Project +Management Institute, Inc., 2004. http://www.pmi.org/ +- [PMI WBS, 2001] - Practice Standard for Work Breakdown Structures. Project +Management Institute, Inc., 2001. http://www.pmi.org/ +- [SE, 2004] - Software Engineering 2004. Curriculum Guidelines for +Undergraduate Degree Programs in Software Engineering. A Volume of the +Computing Curricula Series. The Joint Task Force on Computing Curricula, IEEE +Computer Society, Association for Computing Machinery, August 23, 2004. +http://sites.computer.org/ccse/ +- [SWEBOK, 2004] - Guide to Software Engineering Base of Knowledge (SWEBOK). +IEEE Computer Society, 2004. http://www.swebok.org/ +- [TOGAF, 2003] – The Open Group Architecture Framework (TOGAF). Version 8.1 +The Open Group, 2003. http://www.opengroup.org/architecture/togaf8/index8.htm +- [Zachman] – The Zachman Framework for Enterprise Architecture, John A. +Zachman, ZIFA - Zachman Institute for Framework Advancement. http://www.zifa.com +- [Амблер, 2002] – Скотт Амблер. Гибкие технологии: экстремальное +программирование и унифицированный процесс разработки. Wiley (ISBN +0-471-20282-7), 2002 - Scott W. Ambler, Agile Modeling: Effective Practices for +Extreme Programming, 2002; перевод и издание на русском языке: ЗАО Издательский +дом “Питер” (ISBN 5-94723-545-5), 2005 +- [Арчибальд, 2003] – Рассел Д. Арчибальд. Управление высоко-технологичными +программами и проектами. Издание третье, переработанное и дополненное. John +Wiley & Sons, Inc. (ISBN 0-471-26557-8) 1976 – Russel D. Archibald, 2003; +перевод и издание на русском языке: АйТи (ISBN 5-98453-002-3) - ДМК Пресс +(ISBN 5-94074-214-9) 2004. +- [Арчибальд, 2005] – Рассел Д. Арчибальд. Искусство управления проектами: +состояние и перспективы. Возможности и уровень зрелости организации в +управлении проектами. Информационно-аналитический журнал “Управление +проектами”, N1 (1), март 2005, стр. 14-23. http://www.pmmagazine.ru +- [Брукс, 1995] – Фредерик Брукс. Мифический человеко-месяц или как создаются +программные системы. 2-е издание, юбилейное. Addison-Wesley Longman, Inc. (ISBN +0-201-83595-9), 1995. Издательство Символ-Плюс (ISBN 5-93286-005-7), 2000, 2005. +- [Вигерс, 2003] – Карл И. Вигерс. Разработка требований к программному +обеспечению. Издательско-торговый дом “Русская редакция”, перевод на русский +язык второй редакции книги – Microsoft Corporation (ISBN 5-7502-0240-2), 2004. +Оригинальное издание на английском языке: Software Requirements. Second +Edition. Karl E. Wiegers, Microsoft Press (ISBN 0-7356-1879-8), 2003. +- [Грей и Ларсон, 2003] – Клиффорд Ф. Грей, Эрик У. Ларсон. Управление +проектами: Практическое русководство. Издательство “Дело и Сервис” (ISBN +5-8018-0152-9), 2003. The McGraw-Hill Companies, Inc. (ISBN 0-07-365812-X), 2000. +- [ГОСТ 12207, 1999] – Информационная технология. Процессы Жизненного Цикла +Программных Средств. ГОСТ Р ИСО/МЭК 12207-99, Государственный Стандарт +Российской Федерации, 1999. Госстандарт России, Москва, 2000. +- [ГОСТ 34, 1990] – Информационная технология. Комплекс стандартов и +руководящих документов на автоматизированные системы. Термины и определения. +ГОСТ 34.003-90, Государственный Стандарт Российской Федерации, 1999. +Госстандарт России, Москва, 1990. +- [Кантор, 2002] – Марри Кантор. Управление программными проектами. +Практическое руководство по разработке успешного программного обеспечения. +Издательский дом “Вильямс” (ISBN 5-8459-0294-0), 2002. Addison Wesley (ISBN +0-2017-0044-1), 2002. +- [СОВНЕТ НТК, 2000] - Национальные требования к компетентности специалистов по +Управлению Проектами (НТК). Ассоциация по Управлению Проектами СОВНЕТ, 2000. +http://www.sovnet.ru/ntk2000/index.php +- [Соммервилл, 2000] – Иан Соммервилл. Инженерия программного обеспечения. 6-е +издание. Издательский дом “Вильямс” (ISBN 5-8459-0330-0), 2002. Addison Wesley +(ISBN 0-201-39815-X), 2001. +- [Товб А., Ципес Г., 2003] – А.С. Товб, Г.Л. Ципес. Управление проектами: +стандарты, методы, опыт. Второе издание. Товб А.С., Ципес Г.Л., 2003 – ЗАО +“Олимп-Бизнес” (ISBN 5-9693-0038-1) 2003, 2005. +- [Фатрелл, Шафер и Шафер, 2003] – Роберт Т. Фатрелл, Дональд Ф. Шафер, Линда +И. Шафер. Управление программными проектами: достижение оптимального качества +при минимуме затрат. Издательский дом “Вильямс” (ISBN 5-8459-0413-7), 2003. +Addison-Wesley Publishing Company, Inc. (ISBN 0-13-091297-2), 2002. +- [Фаулер, 2004] – Мартин Фаулер. UML. Основы. Краткое руководство по +стандартному языку объектного моделирования. 3-е издание. Издательство +“Символ-Плюс” (ISBN 5-93286-060-X), Санкт-Петербург, 2004. blob - 8a242ba641445ee376386dbc8833dfa36f163b59 (mode 644) blob + /dev/null --- software_lifecycle_models.markdown +++ /dev/null @@ -1,690 +0,0 @@ -# Модели жизненного цикла программного обеспечения - -Одним из ключевых понятий управления проектами, в том числе в приложении к -индустрии программного обеспечения, является *жизненный цикл проекта* (*Project -Lifecycle Management* - PLM). - -Известный эксперт по управлению высокотехнологичными проетами Арчибальд так -определяет жизненный цикл проекта [Арчибальд Р., 2003, с.58-59] [Арчибальд Р., -2005]: - -> “Жизненный цикл проекта имеет определенные начальную и конечную точки, -привязанные к временной шкале. Проект в своем естественном развитии проходит -ряд отдельных фаз. - -> Жизненный цикл проекта включает все фазы от момента инициации до момента -завершения. Переходы от одного этапа к другому редко четко определены, за -исключением тех случаев, когда они формально разделяются принятием предложения -или получением разрешения на продолжение работы. Однако, в начале -концептуальной фазы часто возникают сложности с точным определением момента, -когда работу можно уже идентифицировать как проект (в терминах управления -проектами), особенно если речь идет о разработке нового продукта или новой -услуги. - -> Существует общее соглашение о выделении четырех обобщенных фаз жизненного -цикла (в скобках приведены используемые в различных источниках альтернативные -термины): - - концепция (инициация, идентификация, отбор) - - определение (анализ) - - выполнение (практическая реализация или внедрение, производство и -развертывание, проектирование или конструирование, сдача в эксплуатацию, -инсталляция, тестирование и т.п.) - - закрытие (завершение, включая оценивание после завершения) - -> Однако, эти фазы столь широки, что ... необходимы конкретные определения, -быть может пяти-десяти основных фаз для каждой категории и подкатегории -проекта, обычно с несколькими подфазами, выделяемыми внутри каждой из этих фаз. - -> ...Нередко можно наблюдать частичное совмещение или одновременное выполнение -фаз проекта, называемое “быстрым проходом” в строительных и инжиниринговых -проектах и “параллелизмом” – в военных и аэрокосмических. Это усложняет -планирование проекта и координацию усилий его участников, а также делает более -важной роль менеджера проектов.” - -В общем случае, *жизненный цикл определяется моделью и описывается в форме -методологии (метода)*. *Модель* или *парадигма* жизненного цикла определяет -концептуальный взгляд на организацию жизненного цикла и, часто, основные фазы -жизненного цикла и принципы перехода между ними. *Методология* (метод) задает -комплекс работ, их детальное содержание и ролевую ответственность специалистов -на всех этапах выбранной модели жизненного цикла, обычно определяет и саму -модель, а также рекомендует *практики (best practices)*, позволяющие -максимально эффективно воспользоваться соответствующей методологией и ее -моделью. - -В индустрии программного обеспечения можно (так как это уже конкретная область -приложения концепций и практик проектного управления) и необходимо (для -обеспечения возможности управления) более четкое разграничение фаз проекта (что -не подразумевает их линейного и последовательного выполнения). - -Ниже приведены определения <модели> жизненного цикла программной системы, -даваемые, например, в различных вариантах стандартов ГОСТ: -- Модель жизненного цикла - структура, состоящая из процессов, работ и задач, -включающих в себя разработку, эксплуатацию и сопровождение программного -продукта, охватывающая жизнь системы от установления требований к ней до -прекращения ее использования [ГОСТ 12207, 1999]. -- Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных -процессов создания и последовательного изменения состояния АС, от формирования -исходных требований к ней до окончания эксплуатации и утилизации комплекса -средств автоматизации АС [ГОСТ 34, 1990]. - -Один из них - ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта -ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий -стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в -СССР самостоятельно, как стандарт на содержание и оформление документов на -программные системы в рамках Единой системы программной документации (ЕСПД) и -Единой системы конструкторской документации (ЕСКД). В последние годы, акцент -делается на стандарты ГОСТ, соответствующие международным стандартам. В то же -время, 34-я серия является важным дополнительным источником информации для -разработки и стандартизации внутрикорпоративных документов и формирования -целостного понимания и видения концепций жизненного цикла в области -программного обеспечения. - -В определённом контексте, “модель” и “методология” могут использоваться -взаимозаменяемым образом, например, когда мы обсуждаем разграничение фаз -проекта. Говоря “жизненный цикл” мы, в первую очередь, подразумеваем “модель -жизненного цикла”. Несмотря на данное в стандартах 12207 определение модели -жизненного цикла, все же, *модель* чаще подразумевает именно *общий принцип* -организации жизненного цикла, чем детализацию соответствующих работ. -Соответственно, определение и выбор модели, в первую очередь, касается вопросов -определенности и стабильности требований, жесткости и детализированности плана -работ, а также частоты сборки работающих версий создаваемой программной -системы. - -Скотт Амблер (Scott W. Ambler) [Ambler, 2005], автор концепций и практик -гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение -Rational Unified Process), предлагает следующие уровни жизненного цикла, -определяемые соответствующим содержанием работ (см. рис.1): - -- Жизненный цикл разработки программного обеспечения – проектная деятельность -по разработке и развертыванию программных систем -- Жизненный цикл программной системы – включает разработку, развертывание, -поддержку и сопровождение -- Жизненный цикл информационных технологий (ИТ) – включает всю деятельность -ИТ-департамента -- Жизненный цикл организации/бизнеса – охватывает всю деятельность организации -в целом - -![Рисунок 1. Содержание четырех категорий жизненного цикла по Амблеру(используется с разрешения автора) [Ambler, 2005]](images/lifecycle_categories-ambler.jpg) - -В данном контексте, SWEBOK описывает области знаний *жизненного цикла системы* -и *жизненного цикла разработки* программного обеспечения. В свою очередь, как -упоминается в SWEBOK, одним из фундаментальных взглядов на жизненный цикл -является стандарт процессов жизненного цикла ISO/IEC, IEEE, ГОСТ Р ИСО/МЭК -12207. - -## Стандарт 12207: Процессы жизненного цикла программного обеспечения - -В 1997 году Международная Организация по Стандартизации - ИСО (International -Organization for Standardization - ISO) и Международная Электротехническая -Комиссия - МЭК (International Electrotechnical Commission - IEC) создали -Совместный Технический Комитет по Информационным Технологиям - Joint Technical -Committee (JTC1) on Information Technology. Содержание работ JTC1 определено -как “стандартизация в области систем и оборудования информационных технологий -(включая микропроцессорные системы)”. В 1989 году этот комитет инициировал -разработку стандарта ISO/IEC 12207, создав для этого подкомитет SC7 -(SuСommittee 7) по программной инженерии. Соответствующий стандарт впервые был -опубликован 1-го августа 1995 года под заголовком “Software Life Cycle -Processes” – “Процессы жизненного цикла программного обеспечения”. Национальный -стандарт [ГОСТ 12207, 1999] получил название “Процессы жизненного цикла -программных средств”. - -Цель разработки данного стандарта была определена как создание общего -фреймворка по организации жизненного цикла программного обеспечения для -формирования общего понимания жизненного цикла ПО всеми заинтересованными -сторонами и участниками процесса разработки приобретения, поставки, -эксплуатации, поддержки и сопровождения программных систем, а также возможности -управления, контроля и совершенствования процессов жизненного цикла. - -Данный стандарт определяет жизненный цикл как структуру декомпозиции работ. -Детализация, техники и метрики проведения работ – вопрос программной инженерии. -Организация последовательности работ – модель жизненного цикла. Совокупность -моделей, процессов, техник и организации проектной группы задаются -методологией. В частности, выбор и применение метрик оценки качества -программной системы и процессов находятся за рамками стандарта 12207, а -концепция совершенствования процессов рассматривается в стандарте ISO/IEC 15504 -“Information Technology - Software Process Assessment” (“Оценка процессов <в -области> программного обеспечения”). - -Необходимо отметить заложенные в стандарте ключевые концепции рассмотрения -жизненного цикла программных систем. - -### Организация стандарта и архитектура жизненного цикла - -Стандарт определяет область его применения, дает ряд важных определений (таких, -как заказчик, разработчик, договор, оценка, выпуск – релиз, программный -продукт, аттестация и т.п.), процессы жизненного цикла и включает ряд -примечаний по процессу и вопросам адаптации стандарта. - -Стандарт описывает 17 процессов жизненного цикла, распределенных по трем -категориям – группам процессов (названия представлены с указанием номеров -разделов стандарта, следуя определениям на русском и английском языке, -определяемыми [ГОСТ 12207, 1999] и оригинальной версией ISO/IEC 12207, -соответственно): - -### Основные процессы жизненного цикла - Primary Processes - -5.1 Заказ - Acquisition -5.2 Поставка - Supply -5.3 Разработка - Development -5.4 Эксплуатация - Operation -5.5 Сопровождение - Maintenance - -### Вспомогательные процессы жизненного цикла – Supporting Processes - -6.1 Документирование - Documentation -6.2 Управление конфигурацией – Configuration Management -6.3 Обеспечение качества – Quality Assurance -6.4 Верификация - Verification -6.5 Аттестация - Validation -6.6 Совместный анализ – Joint Review -6.7 Аудит - Audit -6.8 Решение проблем – Problem Resolution - -### Организационные процессы жизненного цикла – Organizational Processes - -7.1 Управление - Management -7.2 Создание инфраструктуры - Infrastructure -7.3 Усовершенствование - Improvement -7.4 Обучение - Training - -Стандарт определяет высокоуровневую архитектуру жизненного цикла. Жизненный -цикл начинается с идеи или потребности, которую необходимо удовлетворить с -использованием программных средств (может быть и не только их). Архитектура -строится как набор процессов и взаимных связей между ними. Например, основные -процессы жизненного цикла обращаются к вспомогательным процессам, в то время, -как организационные процессы действуют на всем протяжении жизненного цикла и -связаны с основными процессами. - -Дерево процессов жизненного цикла представляет собой структуру декомпозиции -жизненного цикла на соответствующие процессы (группы процессов). Декомпозиция -процессов строится на основе двух важнейших принципов , определяющих правила -разбиения (partitioning) жизненного цикла на составляющие процессы. Эти -принципы: - -Модульность - -- задачи в процессе являются функционально связанными; -- связь между процессами – минимальна; -- если функция используется более, чем одним процессом, она сама является -процессом; -- если Процесс Y используется Процессом X и только им, значит Процесс Y -принадлежит (является его частью или его задачей) Процессу X, за исключением -случаев потенциального использования Процесса Y в других процессах в будущем. - -Ответственность - -- каждый процесс находится под ответственностью конкретного лица (управляется -и/или контролируется им), определенного для заданного жизненного цикла, -например, в виде роли в проектной команде; -- функция, чьи части находятся в компетенции различных лиц, не может -рассматриваться как самостоятельный процесс. - -Общая иерархия (декомпозиция) составных элементов жизненного цикла выглядит -следующим образом: - -* группа процессов - * процессы - * работы - * задачи - -В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле: - -- “P” – Plan – Планирование -- “D” – Do – Выполнение -- “C” – Check – Проверка -- “A” – Act – Реакция (действие) - -Рассмотрим вкратце, какие работы составляют процессы жизненного цикла, помня, -что полное определение работ, как и определение составляющих их задач, дано -непосредственно в стандарте. Ниже приведен краткий обзор основных процессов -жизненного цикла, явно демонстрирующий связь вопросов, касающихся -непосредственно самой программной системы, с системными аспектами ее -функционирования и обеспечения ее эксплуатации. - -### Основные процессы жизненного цикла - -#### Приобретение (5.1) - -Процесс приобретения (как его называют в ГОСТ – “заказа”) определяет работы и -задачи заказчика, приобретающего программное обеспечение или услуги, связанные -с ПО, на основе контрактных отношений. Процесс приобретения состоит из -следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой -перевод названий работ оригинального стандарта): - -- Inititation – инициирование (подготовка) -- Request-for-proposal preparation – подготовка запроса на предложение -(подготовка заявки на подряд) -- Contract preparation and update –подготовка и корректировка договора -- Supplier monitoring – мониторинг поставщика (надзор за поставщиком) -- Acceptance and completion – приемка и завершение (приемка и закрытие договора) - -Все работы проводятся в рамках проектного подхода. - -#### Поставка (5.2) - -Процесс поставки, в свою очередь, определяет работы и задачи поставщика. Работы -также проводятся с использованием проектного подхода. Процесс включает -следующие работы: - -- Inititation – инициирование (подготовка) -- Preparation of response – подготовка предложения (подготовка ответа) -- Contract – разработка контракта (подготовка договора) -- Planning - планирование -- Execution and control – выполнение и контроль -- Review and evaluation –проверка и оценка -- Delivery and completion – поставка и завершение (поставка и закрытие -договора) - -#### Разработка (5.3) - -Процесс разработки определяет работы и задачи разработчика. Процесс состоит из -следующих работ: - -- Process implementation – определение процесса (подготовка процесса) -- System requirements analysis – анализ системных требований (анализ требований -к системе) -- System design – проектирование системы (проектирование системной архитектуры) -- Software requirements analysis – анализ программных требований (анализ -требований к программным средствам) -- Software architectural design – проектирование программной архитектуры -- Software detailed design – детальное проектирование программной системы -(техническое проектирование программных средств) -- Software coding and testing – кодирование и тестирование (программирование и -тестирование программных средств) -- Software integration – интеграция программной системы (сборка программных -средств) -- Software qualification testing – квалификационные испытания программных -средств -- System integration – интеграция системы в целом (сборка системы) -- System qualification testing – квалификационные испытания системы -- Software installation – установка (ввод в действие) -- Software acceptance support – обеспечение приемки программных средств - -Стандарт отмечает, что работы проводятся с использованием проектного подхода и -могут пересекаться по времени, т.е. проводиться одновременно или с наложением, -а также могут предполагать рекурсию и разбиение на итерации. - -#### Эксплуатация (5.4) - -Процесс разработки определяет работы и задачи оператора службы поддержки. -Процесс включает следующие работы: - -- Process implementation – определение процесса (подготовка процесса) -- Operational testing – операционное тестирование (эксплуатационные испытания) -- System operation – эксплуатация системы -- User support – поддержка пользователя - -#### Сопровождение (5.5) - -Процесс разработки определяет работы и задачи, проводимые специалистами службы -сопровождения. Процесс включает следующие работы: - -- Process implementation – определение процесса (подготовка процесса) -- Problem and modification analysis – анализ проблем и изменений -- Modification implementation – внесение изменений -- Maintenance review/acceptance – проверка и приемка при сопровождении -- Migration – миграция (перенос) -- Software retirement – вывод программной системы из эксплуатации (снятие с -эксплуатации) - -Важно понимать, что стандарт 12207 не определяет последовательность и разбиение -выполнения процессов во времени, адресуя этот вопрос также работам по адаптации -стандарта к конкретным условиям и окружению и применению выбранных моделей, -практик, техник и т.п. - -### Адаптация стандарта - -Адаптация стандарта* подразумевает применение требований стандарта к -конкретному проекту или проектам, например, в рамках создания -внутрикорпоративных регламентов ведения проектов программного обеспечения. - -Адаптация включает следующие виды работ: - -- Определение исходной информации для адаптации стандарта -- Определение условий выполнения проекта -- Отбор процессов, работ и задач, используемых в проекте или соответствующих регламентах -- Документирование требований, решений и процессов, связанных с адаптацией и -полученных в ее результате - -Адаптация также подразумевает выбор модели (или комбинации моделей) жизненного -цикла, а также применение соответствующих методологий, детализирующих процедуры -выполнения процессов, работ и задач в рамках заданных границ (содержания) -жизненного цикла программного обеспечения и организационной структуры и ролевой -ответственности в конкретной организации (ее подразделении) и/или в проектной -группе. - -* Необходимо отметить, что существует еще один стандарт жизненного цикла - -ISO/IEC 15288 (выпущен в 2002 году), фокусирующийся на вопросах организации -процессов жизненного цикла системного уровня (Life Cycle Processes – System) и -включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию -жизненного цикла к конкретным требованиям и ограничениям, существующим или -принятым в конкретной организации/подразделении или для заданного проекта. - -## Модели жизненного цикла - -Наиболее часто говорят о следующих моделях жизненного цикла: - -- Каскадная (водопадная) или последовательная -- Итеративная и инкрементальная – эволюционная (гибридная, смешанная) -- Спиральная (spiral) или модель Боэма - -Легко обнаружить, что в разное время и в разных источниках приводится разный -список моделей и их интерпретация. Например, ранее, инкрементальная модель -понималась как построение системы в виде последовательности сборок (релизов), -определенной в соответствии с заранее подготовленным планом и заданными (уже -сформулированными) и неизменными требованиями. Сегодня об инкрементальном -подходе чаще всего говорят в контексте постепенного наращивания -функциональности создаваемого продукта. - -Может показаться, что индустрия пришла, наконец, к общей “правильной” модели. -Однако, каскадная модель, многократно “убитая” и теорией и практикой, -продолжает встречаться в реальной жизни. Спиральная модель является ярким -представителем эволюционного взгляда, но, в то же время, представляет собой -единственную модель, которая уделяет явное внимание анализу и предупреждению -рисков. Поэтому, я попытался именно представленным выше образом выделить три -модели – каскадную, эволюционную и спиральную. Их мы и обсудим. - -### Каскадная (водопадная) модель - -Данная модель предполагает строго последовательное (во времени) и однократное -выполнение всех фаз проекта с жестким (детальным) предварительным планированием -в контексте предопределенных или однажды и целиком определенных требований к -программной системе. - -![Рисунок 2. Каскадная модель жизненного цикла.](images/lifecycle_waterfall.jpg) - -На рисунке изображены типичные фазы каскадной модели жизненного цикла и -соответствующие активы проекта, являющиеся для одних фаз выходами, а для других -- входами. Марри Кантор [Кантор, 2002, с.145-146] отмечает ряд важных аспектов, -характерных для водопадной модели: “Водопадная схема включает несколько важных -операций, применимых ко всем проектам: - -- составление плана действий по разработке системы; -- планирование работ, связанных с каждым действием; -- применение операции отслеживания хода выполнения действий с контрольными -этапами. - -В связи с тем, что упомянутые задачи являются неотъемлемым элементом всех -хорошо управляемых процессов, практически не существует причин, препятствующих -утверждению полнофункциональных, классических методов руководства проектом, -таких как анализ критического пути и промежуточные контрольные этапы. Я часто -встречался с программными менеджерами, которые ломали себе голову над тем, -почему же столь эффективный набор методик на практике оборачивается -неудачей...” - -Будучи активно используема (де факто и, например, в свое время, как часть -соответствующего отраслевого стандарта в США), эта модель продемонстрировала -свою “проблемность” в подавляющем большинстве ИТ-проектов, за исключением, -может быть, отдельных проектов обновления программных систем для -критически-важных программно-аппаратных комплексов (например, авионики или -медицинского оборудования). Практика показывает, что в реальном мире, особенно -в мире бизнес-систем, каскадная модель не должна применяться. Специфика таких -систем (если можно говорить о “специфике” для подавляющего большинства -создаваемых систем) - требования характеризуются высокой динамикой -корректировки и уточнения, невозможностью четкого и однозначного определения -требований до начала работ по реализации (особенно, для новых систем) и быстрой -изменчивостью в процессе эксплуатации системы. - -Фредерик Брукс во втором издании своего классического труда “Мифический -человеко-месяц” так описывает главную беду каскадной модели [Брукс, 1995, -с.245]: - -> “Основное заблуждение каскадной модели состоит в предположениях, что проект -проходит через весь процесс один раз, архитектура хороша и проста в -использовании, проект осуществления разумен, а ошибки в реализации устраняются -по мере тестирования. Иными словами, каскадная модель исходит из того, что все -ошибки будут сосредоточены в реализации, а потому их устранение происходит -равномерно во время тестирования компонентов и системы.” - -В каскадной модели переход от одной фазы проекта к другой предполагает полную -корректность результата (выхода) предыдущей фазы. Однако, например, неточность -какого-либо требования или некорректная его интерпретация, в результате, -приводит к тому, что приходится “откатываться” к ранней фазе проекта и -требуемая переработка не просто выбивает проектную команду из графика, но -приводит часто к качественному росту затрат и, не исключено, к прекращению -проекта в той форме, в которой он изначально задумывался. Кроме того, эта -модель не способна гарантировать необходимую скорость отклика и внесение -соответствующих изменений в ответ на быстро меняющиеся потребности -пользователей, для которых программная система является одним из инструментов -исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой -модели, можно привести достаточно много. Достаточно для чего? Для отказа от -каскадной модели жизненного цикла. - -### Итеративная и инкрементальная модель – эволюционный подход - -Итеративная модель предполагает разбиение жизненного цикла проекта на -последовательность итераций, каждая из которых напоминает “мини-проект”, -включая все фазы жизненного цикла в применении к созданию меньших фрагментов -функциональности, по сравнению с проектом, в целом. Цель каждой итерации – -получение работающей версии программной системы, включающей функциональность, -определенную интегрированным содержанием всех предыдущих и текущей итерации. -Результата финальной итерации содержит всю требуемую функциональность продукта. -Таким образом, с завершением каждой итерации, продукт развивается -инкрементально. - -С точки зрения структуры жизненного цикла такую модель называют итеративной -(iterative). С точки зрения развития продукта – инкрементальной (incremental). -Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов -изолировано. Чаще всего такую смешанную эволюционную модель называют просто -итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании -функциональности продукта). - -Эволюционная модель подразумевает не только сборку работающей (с точки зрения -результатов тестирования) версии системы, но и её развертывание в реальных -операционных условиях с анализом откликов пользователей для определения -содержания и планирования следующей итерации. “Чистая” инкрементальная модель -не предполагает развертывания промежуточных сборок (релизов) системы и все -итерации проводятся по заранее определенному плану наращивания -функциональности, а пользователи (заказчик) получает только результат финальной -итерации как полную версию системы. С другой стороны, Скотт Амблер [Ambler, -2004], например, определяет эволюционную модель как сочетание итеративного и -инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47] -пишет: “Итеративную разработку называют по-разному: инкрементальной, -спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины -разный смысл, но эти различия не имеют широкого признания и не так важны, как -противостояние итеративного метода и метода водопада.” -Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему: - -- можно очень рано начать тестирование пользователями; -- можно принять стратегию разработки в соответствии с бюджетом, полностью -защищающую от перерасхода времени или средств (в частности, за счет сокращения -второстепенной функциональности). - -Таким образом, Значимость эволюционного подхода на основе организации итераций -особо проявляется в снижении неопределенности с завершением каждой итерации. В -свою очередь, снижение неопределенности позволяет уменьшить риски. Рисунок 3 -иллюстрирует некоторые идеи эволюционного подхода, предполагая, что -итеративному разбиению может быть подвержен не только жизненный цикл в целом, -включающий перекрывающиеся фазы – формирование требований, проектирование, -конструирование и т.п., но и каждая фаза может, в свою очередь, разбиваться на -уточняющие итерации, связанные, например, с детализацией структуры декомпозиции -проекта – например, архитектуры модулей системы. - -![Рисунок 3. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла.](images/lifecycle_evolution.jpg) - -Наиболее известным и распространенным вариантом эволюционной модели является -спиральная модель, ставшая уже по сути самостоятельной моделью, имеющей -различные сценарии развития и детализации. - -### Спиральная модель - -Спиральная модель (представлена на рисунке 4) была впервые сформулирована Барри -Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой -модели является специальное внимание рискам, влияющим на организацию жизненного -цикла. - -Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков -(используется с разрешения автора): - -1. Дефицит специалистов. -1. Нереалистичные сроки и бюджет. -1. Реализация несоответствующей функциональности. -1. Разработка неправильного пользовательского интерфейса. -1. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание -деталей. -1. Непрекращающийся поток изменений. -1. Нехватка информации о внешних компонентах, определяющих окружение системы -или вовлеченных в интеграцию. -1. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. -1. Недостаточная производительность получаемой системы. -1. “Разрыв” в квалификации специалистов разных областей знаний. - -Большая часть этих рисков связана с организационными и процессными аспектами -взаимодействия специалистов в проектной команде. - -![Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму (используется с разрешения автора) [Boehm, 1988]](images/lifecycle_spiral-boehm.jpg) - -Сам Барри Боэм так характеризует спиральную модель разработки (используется с -разрешения автора): - -> “Главное достижение спиральной модели состоит в том, что она предлагает -спектр возможностей адаптации удачных аспектов существующих моделей процессов -жизненного цикла. В то же время, ориентированный на риски подход позволяет -избежать многих сложностей, присутствующих в этих моделях. В определенных -ситуациях спиральная модель становится эквивалентной одной из существующих -моделей. В других случаях она обеспечивает возможность наилучшего соединения -существующих подходов в контексте данного проекта. - -> Спиральная модель обладает рядом преимуществ: - -> Модель уделяет специальное внимание раннему анализу возможностей повторного -использования. Это обеспечивается, в первую очередь, в процессе идентификации и -оценки альтернатив. - -> Модель предполагает возможность эволюции жизненного цикла, развитие и -изменение программного продукта. Главные источники изменений заключены в целях, -для достижения которых создается продукт. Подход, предусматривающий скрытие -информации о деталях на определенном уровне дизайна, позволяет рассматривать -различные архитектурные альтернативы так, как если бы мы говорили о -единственном проектном решении, что уменьшает риск невозможности согласования -функционала продукта и изменяющихся целей (требований). - -> Модель предоставляет механизмы достижения необходимых параметров качества как -составную часть процесса разработки программного продукта. Эти механизмы -строятся на основе идентификации всех типов целей (требований) и ограничений на -всех “циклах” спирали разработки. Например, ограничения по безопасности могут -рассматриваться как риски на этапе специфицирования требований. - -> Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию -ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах -проекта. Это достигается явно определенными работами по анализу рисков, -проверке различных характеристик создаваемого продукта (включая архитектуру, -соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше -на каждом “цикле” процесса разработки. - -> Модель позволяет контролировать источники проектных работ и соответствующих -затрат. По-сути речь идет об ответе на вопрос – как много усилий необходимо -затратить на анализ требований, планирование, конфигурационное управление, -обеспечение качества, тестирование, формальную верификацию и т.д. Модель, -ориентированная на риски, позволяет в контексте конкретного проекта решить -задачу приложения адекватного уровня усилий, определяемого уровнем рисков, -связанных с недостаточным выполнением тех или иных работ. - -> Модель не проводит различий между разработкой нового продукта и расширением -(или сопровождением) существующего. Этот аспект позволяет избежать часто -встречающегося отношения к поддержке и сопровождению как ко “второсортной” -деятельности. Такой подход предупреждает большого количество проблем, -возникающих в результате одинакового уделения внимания как обычному -сопровождению, так и критичным вопросам, связанным с расширением -функциональности продукта, всегда ассоциированным с повышенными рисками. - -> Модель позволяет решать интегрированные задачи системной разработки, -охватывающей и программную и аппаратную составляющие создаваемого продукта. -Подход, основанный на управлении рисками и возможности своевременного -отбрасывания непривлекательных альтернатив (на ранних стадиях проекта) -сокращает расходы и одинаково применим и к аппаратной части, и к программному -обеспечению.” - -Описывая созданную спиральную модель, Боэм обращает внимание на то, что обладая -явными преимуществами по сравнению с другими взглядами на жизненный цикл, -необходимо уточнить, детализировать шаги, т.е. циклы спиральной модели для -обеспечения целостного контекста для всех лиц, вовлеченных в проект (Боэм это -формулирует так: “Need for further elaboration of spiral model steps. In -general, the spiral model process steps need further elaboration to ensure that -all software development participants are operating in a consistent context.”). -Организация ролей (ответственности членов проектной команды), детализация -этапов жизненного цикла и процессов, определение активов (артефактов), значимых -на разных этапах проекта, практики анализа и предупреждения рисков – все это -вопросы уже конкретного процессного фреймворка или, как принято говорить, -*методологии разработки*. - -Действительно, детализация процессов, ролей и активов – вопрос методологии. -Однако, рассматривая (спиральную) модель разработки, являясь концептуальным -взглядом на создание продукта, требует, как и в любом проекте, *определения -ключевых контрольных точек проекта - milestones*. Это, в большой степени, -связано с попыткой ответить на вопрос “где мы?”. Вопрос, особенно актуальный -для менеджеров и лидеров проектов, отслеживающих ход их выполнения и -планирующих дальнейшие работы. -В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели -и, в частности, построенного на его основе подхода MBASE - Model-Based (System) -Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых -характеристик или практик, обеспечивающих успешное применение спиральной -модели: - -1. Параллельное, а не последовательное определение артефактов (активов) проекта -1. Согласие в том, что на каждом цикле уделяется внимание: - - - целям и ограничениям, важным для заказчика - - альтернативам организации процесса и технологических решений, закладываемых в продукт - - идентификации и разрешению рисков - - оценки со стороны заинтересованных лиц (в первую очередь заказчика) - - достижению согласия в том, что можно и необходимо двигаться дальше -1. Использование соображений, связанных с рисками, для определения уровня -усилий, необходимого для каждой работы на всех циклах спирали. -1. Использование соображений, связанных с рисками, для определения уровня -детализации каждого артефакта, создаваемого на всех циклах спирали. -1. Управление жизненным циклом в контексте обязательств всех заинтересованных -лиц на основе трех контрольных точек: - - Life Cycle Objectives (LCO) - - Life Cycle Architecture (LCA) - - Initial Operational Capability (IOC) -1. Уделение специального внимания проектным работам и артефактам создаваемой -системы (включая непосредственно разрабатываемое программное обеспечение, ее -окружение, а также эксплуатационные характеристики) и жизненного цикла -(разработки и использования). - -Эволюционирование спиральной модели, таким образом, связано с вопросами -детализации работ. Особенно стоит выделить акцент на большем внимании вопросам -уточнения – требований, дизайна и кода, т.е. придание большей важности вопросам -итеративности, в том числе, увеличения их количества при сокращении -длительности каждой итерации. - -В результате, можно определить общий набор контрольных точек в сегодняшней -спиральной модели: - -- *Concept of Operations (COO)* – концепция <использования> системы; -- *Life Cycle Objectives (LCO)* – цели и содержание жизненного цикла; -- *Life Cycle Architecture (LCA)* – архитектура жизненного цикла; здесь же -возможно говорить о готовности концептуальной архитектуры целевой программной -системы; -- *Initial Operational Capability (IOC)* – первая версия создаваемого продукта, -пригодная для опытной эксплуатации; -- *FinalOperationalCapability (FOC)* – готовый продукт, развернутый -(установленный и настроенный) для реальной эксплуатации. -Таким образом, мы приходим к возможному современному взгляду (см., например, -представление спиральной модели в [Фатрелл, Шафер и Шафер, 2003, с.159]) на -итеративный и инкрементальный – эволюционный жизненный цикл в форме спиральной -модели, изображенной на рисунке 5. - -![Рисунок 5. Обновленная спиральная модель c контрольными точками проекта. (данное представление создано Сергеем Орликом на основе оригинальной модели Боэма и ее модификациях)](images/lifecycle_spiral-orlik.jpg) - -Похоже, нам удалось более четко и естественно определить контрольные точки -проекта, в определенной степени, подчеркнув эволюционную природу жизненного -цикла. Теперь же пора взглянуть на жизненный цикл в контексте методологий, не -просто детализирующих ту или иную модель, но добавляющих к ним ключевой элемент -– людей. Роли, как представление различных функциональных групп работ, -связывает создание, модификацию и использование активов проектов с конкретными -участниками проектных команд. В совокупности с процессами и активами -(артефактами) они позволяют нам создать целостную и подробную картину -жизненного цикла. - -Так как взглядов на детализацию описания жизненного цикла может быть много – -безусловно, существуют различные методологии, среди которых наибольшее -распространение получили: - -- Rational Unified Process (RUP) -- Enterprise Unified Process (EUP) -- Microsoft Solutions Framework (MSF) в обоих представлениях: MSF for Agile и -MSF for CMMI (анонсированная изначально как “MSF Formal”) -- Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), -Dynamic Systems Development Method (DSDM), SCRUM,...). blob - /dev/null blob + 8a242ba641445ee376386dbc8833dfa36f163b59 (mode 644) --- /dev/null +++ software_lifecycle_models.md @@ -0,0 +1,690 @@ +# Модели жизненного цикла программного обеспечения + +Одним из ключевых понятий управления проектами, в том числе в приложении к +индустрии программного обеспечения, является *жизненный цикл проекта* (*Project +Lifecycle Management* - PLM). + +Известный эксперт по управлению высокотехнологичными проетами Арчибальд так +определяет жизненный цикл проекта [Арчибальд Р., 2003, с.58-59] [Арчибальд Р., +2005]: + +> “Жизненный цикл проекта имеет определенные начальную и конечную точки, +привязанные к временной шкале. Проект в своем естественном развитии проходит +ряд отдельных фаз. + +> Жизненный цикл проекта включает все фазы от момента инициации до момента +завершения. Переходы от одного этапа к другому редко четко определены, за +исключением тех случаев, когда они формально разделяются принятием предложения +или получением разрешения на продолжение работы. Однако, в начале +концептуальной фазы часто возникают сложности с точным определением момента, +когда работу можно уже идентифицировать как проект (в терминах управления +проектами), особенно если речь идет о разработке нового продукта или новой +услуги. + +> Существует общее соглашение о выделении четырех обобщенных фаз жизненного +цикла (в скобках приведены используемые в различных источниках альтернативные +термины): + - концепция (инициация, идентификация, отбор) + - определение (анализ) + - выполнение (практическая реализация или внедрение, производство и +развертывание, проектирование или конструирование, сдача в эксплуатацию, +инсталляция, тестирование и т.п.) + - закрытие (завершение, включая оценивание после завершения) + +> Однако, эти фазы столь широки, что ... необходимы конкретные определения, +быть может пяти-десяти основных фаз для каждой категории и подкатегории +проекта, обычно с несколькими подфазами, выделяемыми внутри каждой из этих фаз. + +> ...Нередко можно наблюдать частичное совмещение или одновременное выполнение +фаз проекта, называемое “быстрым проходом” в строительных и инжиниринговых +проектах и “параллелизмом” – в военных и аэрокосмических. Это усложняет +планирование проекта и координацию усилий его участников, а также делает более +важной роль менеджера проектов.” + +В общем случае, *жизненный цикл определяется моделью и описывается в форме +методологии (метода)*. *Модель* или *парадигма* жизненного цикла определяет +концептуальный взгляд на организацию жизненного цикла и, часто, основные фазы +жизненного цикла и принципы перехода между ними. *Методология* (метод) задает +комплекс работ, их детальное содержание и ролевую ответственность специалистов +на всех этапах выбранной модели жизненного цикла, обычно определяет и саму +модель, а также рекомендует *практики (best practices)*, позволяющие +максимально эффективно воспользоваться соответствующей методологией и ее +моделью. + +В индустрии программного обеспечения можно (так как это уже конкретная область +приложения концепций и практик проектного управления) и необходимо (для +обеспечения возможности управления) более четкое разграничение фаз проекта (что +не подразумевает их линейного и последовательного выполнения). + +Ниже приведены определения <модели> жизненного цикла программной системы, +даваемые, например, в различных вариантах стандартов ГОСТ: +- Модель жизненного цикла - структура, состоящая из процессов, работ и задач, +включающих в себя разработку, эксплуатацию и сопровождение программного +продукта, охватывающая жизнь системы от установления требований к ней до +прекращения ее использования [ГОСТ 12207, 1999]. +- Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных +процессов создания и последовательного изменения состояния АС, от формирования +исходных требований к ней до окончания эксплуатации и утилизации комплекса +средств автоматизации АС [ГОСТ 34, 1990]. + +Один из них - ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта +ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий +стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в +СССР самостоятельно, как стандарт на содержание и оформление документов на +программные системы в рамках Единой системы программной документации (ЕСПД) и +Единой системы конструкторской документации (ЕСКД). В последние годы, акцент +делается на стандарты ГОСТ, соответствующие международным стандартам. В то же +время, 34-я серия является важным дополнительным источником информации для +разработки и стандартизации внутрикорпоративных документов и формирования +целостного понимания и видения концепций жизненного цикла в области +программного обеспечения. + +В определённом контексте, “модель” и “методология” могут использоваться +взаимозаменяемым образом, например, когда мы обсуждаем разграничение фаз +проекта. Говоря “жизненный цикл” мы, в первую очередь, подразумеваем “модель +жизненного цикла”. Несмотря на данное в стандартах 12207 определение модели +жизненного цикла, все же, *модель* чаще подразумевает именно *общий принцип* +организации жизненного цикла, чем детализацию соответствующих работ. +Соответственно, определение и выбор модели, в первую очередь, касается вопросов +определенности и стабильности требований, жесткости и детализированности плана +работ, а также частоты сборки работающих версий создаваемой программной +системы. + +Скотт Амблер (Scott W. Ambler) [Ambler, 2005], автор концепций и практик +гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение +Rational Unified Process), предлагает следующие уровни жизненного цикла, +определяемые соответствующим содержанием работ (см. рис.1): + +- Жизненный цикл разработки программного обеспечения – проектная деятельность +по разработке и развертыванию программных систем +- Жизненный цикл программной системы – включает разработку, развертывание, +поддержку и сопровождение +- Жизненный цикл информационных технологий (ИТ) – включает всю деятельность +ИТ-департамента +- Жизненный цикл организации/бизнеса – охватывает всю деятельность организации +в целом + +![Рисунок 1. Содержание четырех категорий жизненного цикла по Амблеру(используется с разрешения автора) [Ambler, 2005]](images/lifecycle_categories-ambler.jpg) + +В данном контексте, SWEBOK описывает области знаний *жизненного цикла системы* +и *жизненного цикла разработки* программного обеспечения. В свою очередь, как +упоминается в SWEBOK, одним из фундаментальных взглядов на жизненный цикл +является стандарт процессов жизненного цикла ISO/IEC, IEEE, ГОСТ Р ИСО/МЭК +12207. + +## Стандарт 12207: Процессы жизненного цикла программного обеспечения + +В 1997 году Международная Организация по Стандартизации - ИСО (International +Organization for Standardization - ISO) и Международная Электротехническая +Комиссия - МЭК (International Electrotechnical Commission - IEC) создали +Совместный Технический Комитет по Информационным Технологиям - Joint Technical +Committee (JTC1) on Information Technology. Содержание работ JTC1 определено +как “стандартизация в области систем и оборудования информационных технологий +(включая микропроцессорные системы)”. В 1989 году этот комитет инициировал +разработку стандарта ISO/IEC 12207, создав для этого подкомитет SC7 +(SuСommittee 7) по программной инженерии. Соответствующий стандарт впервые был +опубликован 1-го августа 1995 года под заголовком “Software Life Cycle +Processes” – “Процессы жизненного цикла программного обеспечения”. Национальный +стандарт [ГОСТ 12207, 1999] получил название “Процессы жизненного цикла +программных средств”. + +Цель разработки данного стандарта была определена как создание общего +фреймворка по организации жизненного цикла программного обеспечения для +формирования общего понимания жизненного цикла ПО всеми заинтересованными +сторонами и участниками процесса разработки приобретения, поставки, +эксплуатации, поддержки и сопровождения программных систем, а также возможности +управления, контроля и совершенствования процессов жизненного цикла. + +Данный стандарт определяет жизненный цикл как структуру декомпозиции работ. +Детализация, техники и метрики проведения работ – вопрос программной инженерии. +Организация последовательности работ – модель жизненного цикла. Совокупность +моделей, процессов, техник и организации проектной группы задаются +методологией. В частности, выбор и применение метрик оценки качества +программной системы и процессов находятся за рамками стандарта 12207, а +концепция совершенствования процессов рассматривается в стандарте ISO/IEC 15504 +“Information Technology - Software Process Assessment” (“Оценка процессов <в +области> программного обеспечения”). + +Необходимо отметить заложенные в стандарте ключевые концепции рассмотрения +жизненного цикла программных систем. + +### Организация стандарта и архитектура жизненного цикла + +Стандарт определяет область его применения, дает ряд важных определений (таких, +как заказчик, разработчик, договор, оценка, выпуск – релиз, программный +продукт, аттестация и т.п.), процессы жизненного цикла и включает ряд +примечаний по процессу и вопросам адаптации стандарта. + +Стандарт описывает 17 процессов жизненного цикла, распределенных по трем +категориям – группам процессов (названия представлены с указанием номеров +разделов стандарта, следуя определениям на русском и английском языке, +определяемыми [ГОСТ 12207, 1999] и оригинальной версией ISO/IEC 12207, +соответственно): + +### Основные процессы жизненного цикла - Primary Processes + +5.1 Заказ - Acquisition +5.2 Поставка - Supply +5.3 Разработка - Development +5.4 Эксплуатация - Operation +5.5 Сопровождение - Maintenance + +### Вспомогательные процессы жизненного цикла – Supporting Processes + +6.1 Документирование - Documentation +6.2 Управление конфигурацией – Configuration Management +6.3 Обеспечение качества – Quality Assurance +6.4 Верификация - Verification +6.5 Аттестация - Validation +6.6 Совместный анализ – Joint Review +6.7 Аудит - Audit +6.8 Решение проблем – Problem Resolution + +### Организационные процессы жизненного цикла – Organizational Processes + +7.1 Управление - Management +7.2 Создание инфраструктуры - Infrastructure +7.3 Усовершенствование - Improvement +7.4 Обучение - Training + +Стандарт определяет высокоуровневую архитектуру жизненного цикла. Жизненный +цикл начинается с идеи или потребности, которую необходимо удовлетворить с +использованием программных средств (может быть и не только их). Архитектура +строится как набор процессов и взаимных связей между ними. Например, основные +процессы жизненного цикла обращаются к вспомогательным процессам, в то время, +как организационные процессы действуют на всем протяжении жизненного цикла и +связаны с основными процессами. + +Дерево процессов жизненного цикла представляет собой структуру декомпозиции +жизненного цикла на соответствующие процессы (группы процессов). Декомпозиция +процессов строится на основе двух важнейших принципов , определяющих правила +разбиения (partitioning) жизненного цикла на составляющие процессы. Эти +принципы: + +Модульность + +- задачи в процессе являются функционально связанными; +- связь между процессами – минимальна; +- если функция используется более, чем одним процессом, она сама является +процессом; +- если Процесс Y используется Процессом X и только им, значит Процесс Y +принадлежит (является его частью или его задачей) Процессу X, за исключением +случаев потенциального использования Процесса Y в других процессах в будущем. + +Ответственность + +- каждый процесс находится под ответственностью конкретного лица (управляется +и/или контролируется им), определенного для заданного жизненного цикла, +например, в виде роли в проектной команде; +- функция, чьи части находятся в компетенции различных лиц, не может +рассматриваться как самостоятельный процесс. + +Общая иерархия (декомпозиция) составных элементов жизненного цикла выглядит +следующим образом: + +* группа процессов + * процессы + * работы + * задачи + +В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле: + +- “P” – Plan – Планирование +- “D” – Do – Выполнение +- “C” – Check – Проверка +- “A” – Act – Реакция (действие) + +Рассмотрим вкратце, какие работы составляют процессы жизненного цикла, помня, +что полное определение работ, как и определение составляющих их задач, дано +непосредственно в стандарте. Ниже приведен краткий обзор основных процессов +жизненного цикла, явно демонстрирующий связь вопросов, касающихся +непосредственно самой программной системы, с системными аспектами ее +функционирования и обеспечения ее эксплуатации. + +### Основные процессы жизненного цикла + +#### Приобретение (5.1) + +Процесс приобретения (как его называют в ГОСТ – “заказа”) определяет работы и +задачи заказчика, приобретающего программное обеспечение или услуги, связанные +с ПО, на основе контрактных отношений. Процесс приобретения состоит из +следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой +перевод названий работ оригинального стандарта): + +- Inititation – инициирование (подготовка) +- Request-for-proposal preparation – подготовка запроса на предложение +(подготовка заявки на подряд) +- Contract preparation and update –подготовка и корректировка договора +- Supplier monitoring – мониторинг поставщика (надзор за поставщиком) +- Acceptance and completion – приемка и завершение (приемка и закрытие договора) + +Все работы проводятся в рамках проектного подхода. + +#### Поставка (5.2) + +Процесс поставки, в свою очередь, определяет работы и задачи поставщика. Работы +также проводятся с использованием проектного подхода. Процесс включает +следующие работы: + +- Inititation – инициирование (подготовка) +- Preparation of response – подготовка предложения (подготовка ответа) +- Contract – разработка контракта (подготовка договора) +- Planning - планирование +- Execution and control – выполнение и контроль +- Review and evaluation –проверка и оценка +- Delivery and completion – поставка и завершение (поставка и закрытие +договора) + +#### Разработка (5.3) + +Процесс разработки определяет работы и задачи разработчика. Процесс состоит из +следующих работ: + +- Process implementation – определение процесса (подготовка процесса) +- System requirements analysis – анализ системных требований (анализ требований +к системе) +- System design – проектирование системы (проектирование системной архитектуры) +- Software requirements analysis – анализ программных требований (анализ +требований к программным средствам) +- Software architectural design – проектирование программной архитектуры +- Software detailed design – детальное проектирование программной системы +(техническое проектирование программных средств) +- Software coding and testing – кодирование и тестирование (программирование и +тестирование программных средств) +- Software integration – интеграция программной системы (сборка программных +средств) +- Software qualification testing – квалификационные испытания программных +средств +- System integration – интеграция системы в целом (сборка системы) +- System qualification testing – квалификационные испытания системы +- Software installation – установка (ввод в действие) +- Software acceptance support – обеспечение приемки программных средств + +Стандарт отмечает, что работы проводятся с использованием проектного подхода и +могут пересекаться по времени, т.е. проводиться одновременно или с наложением, +а также могут предполагать рекурсию и разбиение на итерации. + +#### Эксплуатация (5.4) + +Процесс разработки определяет работы и задачи оператора службы поддержки. +Процесс включает следующие работы: + +- Process implementation – определение процесса (подготовка процесса) +- Operational testing – операционное тестирование (эксплуатационные испытания) +- System operation – эксплуатация системы +- User support – поддержка пользователя + +#### Сопровождение (5.5) + +Процесс разработки определяет работы и задачи, проводимые специалистами службы +сопровождения. Процесс включает следующие работы: + +- Process implementation – определение процесса (подготовка процесса) +- Problem and modification analysis – анализ проблем и изменений +- Modification implementation – внесение изменений +- Maintenance review/acceptance – проверка и приемка при сопровождении +- Migration – миграция (перенос) +- Software retirement – вывод программной системы из эксплуатации (снятие с +эксплуатации) + +Важно понимать, что стандарт 12207 не определяет последовательность и разбиение +выполнения процессов во времени, адресуя этот вопрос также работам по адаптации +стандарта к конкретным условиям и окружению и применению выбранных моделей, +практик, техник и т.п. + +### Адаптация стандарта + +Адаптация стандарта* подразумевает применение требований стандарта к +конкретному проекту или проектам, например, в рамках создания +внутрикорпоративных регламентов ведения проектов программного обеспечения. + +Адаптация включает следующие виды работ: + +- Определение исходной информации для адаптации стандарта +- Определение условий выполнения проекта +- Отбор процессов, работ и задач, используемых в проекте или соответствующих регламентах +- Документирование требований, решений и процессов, связанных с адаптацией и +полученных в ее результате + +Адаптация также подразумевает выбор модели (или комбинации моделей) жизненного +цикла, а также применение соответствующих методологий, детализирующих процедуры +выполнения процессов, работ и задач в рамках заданных границ (содержания) +жизненного цикла программного обеспечения и организационной структуры и ролевой +ответственности в конкретной организации (ее подразделении) и/или в проектной +группе. + +* Необходимо отметить, что существует еще один стандарт жизненного цикла - +ISO/IEC 15288 (выпущен в 2002 году), фокусирующийся на вопросах организации +процессов жизненного цикла системного уровня (Life Cycle Processes – System) и +включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию +жизненного цикла к конкретным требованиям и ограничениям, существующим или +принятым в конкретной организации/подразделении или для заданного проекта. + +## Модели жизненного цикла + +Наиболее часто говорят о следующих моделях жизненного цикла: + +- Каскадная (водопадная) или последовательная +- Итеративная и инкрементальная – эволюционная (гибридная, смешанная) +- Спиральная (spiral) или модель Боэма + +Легко обнаружить, что в разное время и в разных источниках приводится разный +список моделей и их интерпретация. Например, ранее, инкрементальная модель +понималась как построение системы в виде последовательности сборок (релизов), +определенной в соответствии с заранее подготовленным планом и заданными (уже +сформулированными) и неизменными требованиями. Сегодня об инкрементальном +подходе чаще всего говорят в контексте постепенного наращивания +функциональности создаваемого продукта. + +Может показаться, что индустрия пришла, наконец, к общей “правильной” модели. +Однако, каскадная модель, многократно “убитая” и теорией и практикой, +продолжает встречаться в реальной жизни. Спиральная модель является ярким +представителем эволюционного взгляда, но, в то же время, представляет собой +единственную модель, которая уделяет явное внимание анализу и предупреждению +рисков. Поэтому, я попытался именно представленным выше образом выделить три +модели – каскадную, эволюционную и спиральную. Их мы и обсудим. + +### Каскадная (водопадная) модель + +Данная модель предполагает строго последовательное (во времени) и однократное +выполнение всех фаз проекта с жестким (детальным) предварительным планированием +в контексте предопределенных или однажды и целиком определенных требований к +программной системе. + +![Рисунок 2. Каскадная модель жизненного цикла.](images/lifecycle_waterfall.jpg) + +На рисунке изображены типичные фазы каскадной модели жизненного цикла и +соответствующие активы проекта, являющиеся для одних фаз выходами, а для других +- входами. Марри Кантор [Кантор, 2002, с.145-146] отмечает ряд важных аспектов, +характерных для водопадной модели: “Водопадная схема включает несколько важных +операций, применимых ко всем проектам: + +- составление плана действий по разработке системы; +- планирование работ, связанных с каждым действием; +- применение операции отслеживания хода выполнения действий с контрольными +этапами. + +В связи с тем, что упомянутые задачи являются неотъемлемым элементом всех +хорошо управляемых процессов, практически не существует причин, препятствующих +утверждению полнофункциональных, классических методов руководства проектом, +таких как анализ критического пути и промежуточные контрольные этапы. Я часто +встречался с программными менеджерами, которые ломали себе голову над тем, +почему же столь эффективный набор методик на практике оборачивается +неудачей...” + +Будучи активно используема (де факто и, например, в свое время, как часть +соответствующего отраслевого стандарта в США), эта модель продемонстрировала +свою “проблемность” в подавляющем большинстве ИТ-проектов, за исключением, +может быть, отдельных проектов обновления программных систем для +критически-важных программно-аппаратных комплексов (например, авионики или +медицинского оборудования). Практика показывает, что в реальном мире, особенно +в мире бизнес-систем, каскадная модель не должна применяться. Специфика таких +систем (если можно говорить о “специфике” для подавляющего большинства +создаваемых систем) - требования характеризуются высокой динамикой +корректировки и уточнения, невозможностью четкого и однозначного определения +требований до начала работ по реализации (особенно, для новых систем) и быстрой +изменчивостью в процессе эксплуатации системы. + +Фредерик Брукс во втором издании своего классического труда “Мифический +человеко-месяц” так описывает главную беду каскадной модели [Брукс, 1995, +с.245]: + +> “Основное заблуждение каскадной модели состоит в предположениях, что проект +проходит через весь процесс один раз, архитектура хороша и проста в +использовании, проект осуществления разумен, а ошибки в реализации устраняются +по мере тестирования. Иными словами, каскадная модель исходит из того, что все +ошибки будут сосредоточены в реализации, а потому их устранение происходит +равномерно во время тестирования компонентов и системы.” + +В каскадной модели переход от одной фазы проекта к другой предполагает полную +корректность результата (выхода) предыдущей фазы. Однако, например, неточность +какого-либо требования или некорректная его интерпретация, в результате, +приводит к тому, что приходится “откатываться” к ранней фазе проекта и +требуемая переработка не просто выбивает проектную команду из графика, но +приводит часто к качественному росту затрат и, не исключено, к прекращению +проекта в той форме, в которой он изначально задумывался. Кроме того, эта +модель не способна гарантировать необходимую скорость отклика и внесение +соответствующих изменений в ответ на быстро меняющиеся потребности +пользователей, для которых программная система является одним из инструментов +исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой +модели, можно привести достаточно много. Достаточно для чего? Для отказа от +каскадной модели жизненного цикла. + +### Итеративная и инкрементальная модель – эволюционный подход + +Итеративная модель предполагает разбиение жизненного цикла проекта на +последовательность итераций, каждая из которых напоминает “мини-проект”, +включая все фазы жизненного цикла в применении к созданию меньших фрагментов +функциональности, по сравнению с проектом, в целом. Цель каждой итерации – +получение работающей версии программной системы, включающей функциональность, +определенную интегрированным содержанием всех предыдущих и текущей итерации. +Результата финальной итерации содержит всю требуемую функциональность продукта. +Таким образом, с завершением каждой итерации, продукт развивается +инкрементально. + +С точки зрения структуры жизненного цикла такую модель называют итеративной +(iterative). С точки зрения развития продукта – инкрементальной (incremental). +Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов +изолировано. Чаще всего такую смешанную эволюционную модель называют просто +итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании +функциональности продукта). + +Эволюционная модель подразумевает не только сборку работающей (с точки зрения +результатов тестирования) версии системы, но и её развертывание в реальных +операционных условиях с анализом откликов пользователей для определения +содержания и планирования следующей итерации. “Чистая” инкрементальная модель +не предполагает развертывания промежуточных сборок (релизов) системы и все +итерации проводятся по заранее определенному плану наращивания +функциональности, а пользователи (заказчик) получает только результат финальной +итерации как полную версию системы. С другой стороны, Скотт Амблер [Ambler, +2004], например, определяет эволюционную модель как сочетание итеративного и +инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47] +пишет: “Итеративную разработку называют по-разному: инкрементальной, +спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины +разный смысл, но эти различия не имеют широкого признания и не так важны, как +противостояние итеративного метода и метода водопада.” +Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему: + +- можно очень рано начать тестирование пользователями; +- можно принять стратегию разработки в соответствии с бюджетом, полностью +защищающую от перерасхода времени или средств (в частности, за счет сокращения +второстепенной функциональности). + +Таким образом, Значимость эволюционного подхода на основе организации итераций +особо проявляется в снижении неопределенности с завершением каждой итерации. В +свою очередь, снижение неопределенности позволяет уменьшить риски. Рисунок 3 +иллюстрирует некоторые идеи эволюционного подхода, предполагая, что +итеративному разбиению может быть подвержен не только жизненный цикл в целом, +включающий перекрывающиеся фазы – формирование требований, проектирование, +конструирование и т.п., но и каждая фаза может, в свою очередь, разбиваться на +уточняющие итерации, связанные, например, с детализацией структуры декомпозиции +проекта – например, архитектуры модулей системы. + +![Рисунок 3. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла.](images/lifecycle_evolution.jpg) + +Наиболее известным и распространенным вариантом эволюционной модели является +спиральная модель, ставшая уже по сути самостоятельной моделью, имеющей +различные сценарии развития и детализации. + +### Спиральная модель + +Спиральная модель (представлена на рисунке 4) была впервые сформулирована Барри +Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой +модели является специальное внимание рискам, влияющим на организацию жизненного +цикла. + +Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков +(используется с разрешения автора): + +1. Дефицит специалистов. +1. Нереалистичные сроки и бюджет. +1. Реализация несоответствующей функциональности. +1. Разработка неправильного пользовательского интерфейса. +1. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание +деталей. +1. Непрекращающийся поток изменений. +1. Нехватка информации о внешних компонентах, определяющих окружение системы +или вовлеченных в интеграцию. +1. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. +1. Недостаточная производительность получаемой системы. +1. “Разрыв” в квалификации специалистов разных областей знаний. + +Большая часть этих рисков связана с организационными и процессными аспектами +взаимодействия специалистов в проектной команде. + +![Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму (используется с разрешения автора) [Boehm, 1988]](images/lifecycle_spiral-boehm.jpg) + +Сам Барри Боэм так характеризует спиральную модель разработки (используется с +разрешения автора): + +> “Главное достижение спиральной модели состоит в том, что она предлагает +спектр возможностей адаптации удачных аспектов существующих моделей процессов +жизненного цикла. В то же время, ориентированный на риски подход позволяет +избежать многих сложностей, присутствующих в этих моделях. В определенных +ситуациях спиральная модель становится эквивалентной одной из существующих +моделей. В других случаях она обеспечивает возможность наилучшего соединения +существующих подходов в контексте данного проекта. + +> Спиральная модель обладает рядом преимуществ: + +> Модель уделяет специальное внимание раннему анализу возможностей повторного +использования. Это обеспечивается, в первую очередь, в процессе идентификации и +оценки альтернатив. + +> Модель предполагает возможность эволюции жизненного цикла, развитие и +изменение программного продукта. Главные источники изменений заключены в целях, +для достижения которых создается продукт. Подход, предусматривающий скрытие +информации о деталях на определенном уровне дизайна, позволяет рассматривать +различные архитектурные альтернативы так, как если бы мы говорили о +единственном проектном решении, что уменьшает риск невозможности согласования +функционала продукта и изменяющихся целей (требований). + +> Модель предоставляет механизмы достижения необходимых параметров качества как +составную часть процесса разработки программного продукта. Эти механизмы +строятся на основе идентификации всех типов целей (требований) и ограничений на +всех “циклах” спирали разработки. Например, ограничения по безопасности могут +рассматриваться как риски на этапе специфицирования требований. + +> Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию +ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах +проекта. Это достигается явно определенными работами по анализу рисков, +проверке различных характеристик создаваемого продукта (включая архитектуру, +соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше +на каждом “цикле” процесса разработки. + +> Модель позволяет контролировать источники проектных работ и соответствующих +затрат. По-сути речь идет об ответе на вопрос – как много усилий необходимо +затратить на анализ требований, планирование, конфигурационное управление, +обеспечение качества, тестирование, формальную верификацию и т.д. Модель, +ориентированная на риски, позволяет в контексте конкретного проекта решить +задачу приложения адекватного уровня усилий, определяемого уровнем рисков, +связанных с недостаточным выполнением тех или иных работ. + +> Модель не проводит различий между разработкой нового продукта и расширением +(или сопровождением) существующего. Этот аспект позволяет избежать часто +встречающегося отношения к поддержке и сопровождению как ко “второсортной” +деятельности. Такой подход предупреждает большого количество проблем, +возникающих в результате одинакового уделения внимания как обычному +сопровождению, так и критичным вопросам, связанным с расширением +функциональности продукта, всегда ассоциированным с повышенными рисками. + +> Модель позволяет решать интегрированные задачи системной разработки, +охватывающей и программную и аппаратную составляющие создаваемого продукта. +Подход, основанный на управлении рисками и возможности своевременного +отбрасывания непривлекательных альтернатив (на ранних стадиях проекта) +сокращает расходы и одинаково применим и к аппаратной части, и к программному +обеспечению.” + +Описывая созданную спиральную модель, Боэм обращает внимание на то, что обладая +явными преимуществами по сравнению с другими взглядами на жизненный цикл, +необходимо уточнить, детализировать шаги, т.е. циклы спиральной модели для +обеспечения целостного контекста для всех лиц, вовлеченных в проект (Боэм это +формулирует так: “Need for further elaboration of spiral model steps. In +general, the spiral model process steps need further elaboration to ensure that +all software development participants are operating in a consistent context.”). +Организация ролей (ответственности членов проектной команды), детализация +этапов жизненного цикла и процессов, определение активов (артефактов), значимых +на разных этапах проекта, практики анализа и предупреждения рисков – все это +вопросы уже конкретного процессного фреймворка или, как принято говорить, +*методологии разработки*. + +Действительно, детализация процессов, ролей и активов – вопрос методологии. +Однако, рассматривая (спиральную) модель разработки, являясь концептуальным +взглядом на создание продукта, требует, как и в любом проекте, *определения +ключевых контрольных точек проекта - milestones*. Это, в большой степени, +связано с попыткой ответить на вопрос “где мы?”. Вопрос, особенно актуальный +для менеджеров и лидеров проектов, отслеживающих ход их выполнения и +планирующих дальнейшие работы. +В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели +и, в частности, построенного на его основе подхода MBASE - Model-Based (System) +Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых +характеристик или практик, обеспечивающих успешное применение спиральной +модели: + +1. Параллельное, а не последовательное определение артефактов (активов) проекта +1. Согласие в том, что на каждом цикле уделяется внимание: + + - целям и ограничениям, важным для заказчика + - альтернативам организации процесса и технологических решений, закладываемых в продукт + - идентификации и разрешению рисков + - оценки со стороны заинтересованных лиц (в первую очередь заказчика) + - достижению согласия в том, что можно и необходимо двигаться дальше +1. Использование соображений, связанных с рисками, для определения уровня +усилий, необходимого для каждой работы на всех циклах спирали. +1. Использование соображений, связанных с рисками, для определения уровня +детализации каждого артефакта, создаваемого на всех циклах спирали. +1. Управление жизненным циклом в контексте обязательств всех заинтересованных +лиц на основе трех контрольных точек: + - Life Cycle Objectives (LCO) + - Life Cycle Architecture (LCA) + - Initial Operational Capability (IOC) +1. Уделение специального внимания проектным работам и артефактам создаваемой +системы (включая непосредственно разрабатываемое программное обеспечение, ее +окружение, а также эксплуатационные характеристики) и жизненного цикла +(разработки и использования). + +Эволюционирование спиральной модели, таким образом, связано с вопросами +детализации работ. Особенно стоит выделить акцент на большем внимании вопросам +уточнения – требований, дизайна и кода, т.е. придание большей важности вопросам +итеративности, в том числе, увеличения их количества при сокращении +длительности каждой итерации. + +В результате, можно определить общий набор контрольных точек в сегодняшней +спиральной модели: + +- *Concept of Operations (COO)* – концепция <использования> системы; +- *Life Cycle Objectives (LCO)* – цели и содержание жизненного цикла; +- *Life Cycle Architecture (LCA)* – архитектура жизненного цикла; здесь же +возможно говорить о готовности концептуальной архитектуры целевой программной +системы; +- *Initial Operational Capability (IOC)* – первая версия создаваемого продукта, +пригодная для опытной эксплуатации; +- *FinalOperationalCapability (FOC)* – готовый продукт, развернутый +(установленный и настроенный) для реальной эксплуатации. +Таким образом, мы приходим к возможному современному взгляду (см., например, +представление спиральной модели в [Фатрелл, Шафер и Шафер, 2003, с.159]) на +итеративный и инкрементальный – эволюционный жизненный цикл в форме спиральной +модели, изображенной на рисунке 5. + +![Рисунок 5. Обновленная спиральная модель c контрольными точками проекта. (данное представление создано Сергеем Орликом на основе оригинальной модели Боэма и ее модификациях)](images/lifecycle_spiral-orlik.jpg) + +Похоже, нам удалось более четко и естественно определить контрольные точки +проекта, в определенной степени, подчеркнув эволюционную природу жизненного +цикла. Теперь же пора взглянуть на жизненный цикл в контексте методологий, не +просто детализирующих ту или иную модель, но добавляющих к ним ключевой элемент +– людей. Роли, как представление различных функциональных групп работ, +связывает создание, модификацию и использование активов проектов с конкретными +участниками проектных команд. В совокупности с процессами и активами +(артефактами) они позволяют нам создать целостную и подробную картину +жизненного цикла. + +Так как взглядов на детализацию описания жизненного цикла может быть много – +безусловно, существуют различные методологии, среди которых наибольшее +распространение получили: + +- Rational Unified Process (RUP) +- Enterprise Unified Process (EUP) +- Microsoft Solutions Framework (MSF) в обоих представлениях: MSF for Agile и +MSF for CMMI (анонсированная изначально как “MSF Formal”) +- Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), +Dynamic Systems Development Method (DSDM), SCRUM,...).