Основы Программной Инженерии (по swebok) Введение Программная инженерия как дисциплина swebok руководство
 Скачать 3.21 Mb.
|
|
Инструменты тестирования (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) <результатов> прототипирования. Эти аспекты касаются того, как именно будут использованы результаты создания прототипа (например, будет ли он трансформирован в продукт, создается он для оценки нагрузочных способностей и других аспектов масштабируемости и т.п.). Качество программного обеспечения Глава базируется на 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] |