Основы программной инженерии

1. Основы программной инженерии 3 2. Модели жизненного цикла 17 3. Качество и эффективность в программной инженерии 27 4. Модели качества процессов конструирования 36 5. Стандартизация и сертификация программного обеспечения 55 6. Извлечение программных требований 73 7. Управление требованиями 85 8. Проектирование программных средств 94 9. Подходы и методы проектирования программного обеспечения 103 10. Использование UML в программной инженерии 111 11. Тестирование программного обеспечения 118 12. Сопровождение программного обеспечения 129 13. Конфигурационное управление 147 14. Инструменты и методы программной инженерии 159 Основы программной инженерии 1.1. Кризисы программирования и возникновение программной инженерии На рубеже 60-х – 70-х годов прошлого века стоимость программного обеспечения стала приближаться к стоимости аппаратного обеспечения (компьютеров), а динамика её роста позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ Это событие явилось первым кризисом программирования. Благодаря ему появилась идея для сокращения стоимости программ использовать инженерные методы в производстве программ, которая постепенно оформилась в программную инженерию (или технологию программирования в нашей стране). С тех пор программная инженерия бурно развивается. Причём этапы её развития связаны с решением очередной системной проблемы: 1. Появление модульного подхода к программированию На начальных этапах становления программной инженерии большие затраты на создание программ часто были связаны с разработкой однотипных фрагментов кода, поскольку в разных программах зачастую решались одинаковые задачи. Очевидной идеей явилось использование при создании новых программ ранее написанных фрагментов. В результате возник модульный подход к программированию. Суть модульного подхода к программированию состоит в выделении типовых фрагментов и оформлении их в виде модулей. Каждый модуль снабжается описанием, содержащим правила его использования в разделе интерфейса модуля, который устанавливал связи модуля с основной программой. Наиболее простыми в этом отношении оказались модули решения математических задач: решения уравнений, систем уравнений, задач оптимизации. К настоящему времени накоплены и успешно используются большие библиотеки таких модулей. Для многих других типов модулей возможность их повторного использования оказалась проблематичной в виду сложности их связей с основной программой. Повторное использование модулей со сложными интерфейсами является проблемой, достаточно актуальной и по сей день. Для ее решения разрабатываются специальные формы (структуры) представления модулей и организации их интерфейсов. 2. Формирование структурного подхода к программированию В дальнейшем, с возникновением задач по созданию сложных программных комплексов, таких как: автоматизированные системы управления производствами, системы управления сложными техническими объектами (например, самолётом) и т.д. резко выросла сложность программного обеспечения. В результате объёмы программного кода, коллективы разработчиков и количество модулей стали стремительно увеличиваться, что стало приводить к крупным провалам и общему снижению эффективности разработки таких систем. Оказалось, что львиная доля стоимости больших систем приходится не на их создание, а на их внедрение и эксплуатацию. Появилась идея управления жизненным циклом программного продукта, как последовательностью конкретных стадий: проектирования, разработки, тестирования, внедрения и сопровождения. Стадия сопровождения программного комплекса традиционно связана с исправлением ошибок и внесением изменений в программу в соответствии с изменившимися требованиями пользователей. Низкое качество программного кода и, особенно, программной документации явились причина высокой стоимости (а порой и невозможности выполнения) сопровождения программного комплекса. В результате сформировались основные принципы технологии структурного проектирования, призванные обеспечить заданное качество и кода, и документации: • использование нисходящего функционального проектирования, основанном на методе пошаговой структурной декомпозиции; • применение специальных языков проектирования, которые сейчас принято называть CASE-средствами и средств автоматизации использования этих языков; • стандартизация всех этапов жизненного цикла программного комплекса; • стандартизация оформления и содержания программных документов; • отказ в программировании от свободного использования операторов безусловного перехода. 3. Становление объектно-ориентированного подхода Дальнейшее развитие программной инженерии высветило проблему определения требований и управления ими, поскольку в отличие от других инженерий, где заказчик – это обычно следующее звено в цепочке создания продукта, в программной инженерии заказчик, как правило, – совершенно не представляет конечную модель программного продукта и, соответственно, не может сформулировать корректные требования к нему. В результате создание программного продукта превратилось в его постоянную модернизацию и даже перепроектирование. Возникла необходимость обеспечения возможности внесений изменений в программу, не меняя ранее написанного кода. Решением указанной проблемы стало использование объектно-ориентированного подхода к проектированию, основанного на понятии класса, являющегося развитием понятия модуля с определенными свойствами и поведением, характеризующими его. Каждый класс может порождать объекты – экземпляры данного класса, которые поддерживают следующие механизмы: 1. Инкапсуляция – объединение в классе свойств и методов. 2. Наследование – возможность порождения нового класса из существующего с частичным изменением свойств и методов. 3. Полиморфизм – определение свойств и методов объекта по контексту. Объектно-ориентированный подход позволил успешно перейти к спиральной модели разработки программных продуктов, значительно снизив потери от необходимости учёта всё новых требований заказчика. Таким образом, развитие программной инженерии, направленной на снижение себестоимости создания программ, стимулируется всё новыми проблемами и очевидно ещё далеко от завершения. 1.2. Программная инженерия и сущность инженерного подхода к созданию программного обеспечения Программная инженерия – это интегрирование принципов информатики и компьютерных наук с инженерными подходами, разработанными для материального производства. Дисциплина программной инженерии может рассматриваться как инженерная область, имеющая более тесные связи с компьютерными науками, чем другие инженерные области. Среди инженерных дисциплин она выделяется нематериальной природой программного обеспечения и его принципиальной несводимостью к физическим процессам окружающего мира. Используя достижения информатики, программная инженерия занимается решением задач удешевления программных продуктов за счёт разработки методов массового производства высококачественного программного обеспечения. Термин «инженерия программного обеспечения» появился впервые в 1968 году на Конференции НАТО «Инженерия программного обеспечения» и предназначался, чтобы спровоцировать размышления относительно текущего в то время «кризиса программного обеспечения» [википедия]. В 1972 году IEEE* выпустил первый номер 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**. В 1995 году группа этой комиссии SC7 «Software Engineering» выпустила первую версию международного стандарта ISO/IEC 12207 «Software Lifecycle Processes» [2]. Этот стандарт стал первым опытом создания единого общего взгляда на программную инженерию. Соответствующий национальный стандарт России – ГОСТ Р ИСО/МЭК 12207-99 [2] содержит полный аутентичный перевод текста международного стандарта ISO/IEC 12207-95 (1995 года). В свою очередь, IEEE и ACM ***, начав совместные работы еще в 1993 году с кодекса этики и профессиональной практики в данной области (ACM/IEEE-CS Code of Ethics and Professional Practice), к 2004 году сформулировали два ключевых описания того, что сегодня мы и называем основами программной инженерии: 1. Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 Version - Руководство к Своду Знаний по Программной Инженерии, в дальнейшем просто “SWEBOK” [SWEBOK, 2004]; 2. Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering – Учебный План для Преподавания Программной Инженерии в ВУЗах* (данное название на русском языке представлено в вольном смысловом переводе) [SE, 2004]. * IEEE - Computer Society of the Institute for Electrical and Electronic Engineers, IEEE Computer Society – IEEE-CS (Компьютерное Общество) или просто IEEE. http://www.ieee.org ** ISO – International Organization for Standardization. http://www.iso.ch ; IEC – International Electrotechnical Commission; JTC 1 – Joint Technical Committee 1, Information technology *** ACM – Association of Computer Machinery Оба стандарта стали результатом консенсуса ведущих представителей индустрии и признанных авторитетов в области программной инженерии – по аналогии с тем, как был создан PMI PMBOK. Следовательно, программная инженерия возникла как ответ на кризисы программирования и в качестве науки решает задачу повышения эффективности и качества, главным образом, самого процесса создания, внедрения и сопровождения программных средств. В этой связи программная инженерия гораздо шире, чем собственно программирование и является скорее практическим применением, набирающей популярность в последнее время, системной инженерии. 1.3. Управление жизненным циклом программных средств 1.3.1. Понятие жизненного цикла Жизненный цикл (ЖЦ) программного средства (ПС) определяется как период времени, который начинается с момента принятия решения о необходимости создания ПС и заканчивается в момент его полного изъятия из эксплуатации. Такой подход соответствует закону жизненной кривой теории систем. ПС обычно являются компонентами жизненного цикла технических систем, но по своей природе значительно отличаются от технических изделий, поэтому их жизненный цикл имеет характерные особенности, по сравнению с другими техническими объектами. Типовая модель процессов жизненного цикла сложной системы начинается с концепции идеи системы или потребности в ней, охватывает проектирование, разработку, применение и сопровождение системы, и заканчивается снятием системы с эксплуатации. Программные средства служат для выполнения определенных функций систем на компьютерах. Модель жизненного цикла системы обычно разделяют на последовательные периоды реализации — стадии или этапы. Каждый подобный период включает основные реализуемые в нем процессы, работы и задачи, при завершении которых может потребоваться переход к следующему периоду реализации. Общую модель жизненного цикла сложной системы обычно разделяют на следующие основные этапы с последующей адаптацией каждого из них в модели жизненного цикла конкретной системы: • определение потребностей; • исследование и описание основных концепций; • проектирование и разработка; • испытания системы; • создание и производство; • распространение и продажа; • эксплуатация; • сопровождение и мониторинг; • снятие с эксплуатации (утилизация). 1.3.2. Масштабы программных средств По особенностям и свойствам жизненного цикла программ их целесообразно делить на ряд классов и категорий, из которых наиболее различающимися являются два крупных класса – малые и большие. Первый класс составляют относительно небольшие программы, создаваемые одиночками или небольшими коллективами (3–5) специалистов, которые: • создаются преимущественно для получения конкретных результатов автоматизации научных исследований или для анализа относительно простых процессов самими разработчиками программ; • не предназначены для массового тиражирования и распространения как программного продукта на рынке, их оценивают качественно и интуитивно преимущественно как «художественные произведения»; • не имеют конкретного независимого заказчика-потребителя, определяющего требования к программам и их финансирование; • не ограничиваются заказчиком допустимой стоимостью, трудоемкостью и сроками их создания, требованиями заданного качества и документирования; • не подлежат независимому тестированию, гарантированию качества и/или сертификации. Для таких, а также для многих других видов относительно не сложных программ, нет необходимости в регламентировании их жизненного цикла, в длительном применении и сопровождении множества версий, в формализации и применении профилей стандартов и сертификации качества программ. Их разработчики не знают и не применяют регламентирующих, нормативных документов, вследствие чего жизненный цикл таких изделий имеет не предсказуемый характер по структуре, содержанию, качеству и стоимости основных процессов “творчества”. Второй класс составляют крупномасштабные комплексы программ для сложных систем управления и обработки информации, оформляемые в виде программных продуктов с гарантированным качеством, и отличаются следующими особенностями и свойствами их жизненного цикла: • большая размерность, высокая трудоемкость и стоимость создания таких комплексов программ определяют необходимость тщательного анализа экономической эффективности всего их жизненного цикла и возможной конкурентоспособности на рынке; • от заказчика, финансирующего проект программного средства и/или базы данных, разработчикам необходимо получать квалифицированные конкретные требования к функциям и характеристикам проекта и продукта, соответствующие выделенному финансированию и квалификации исполнителей проекта; • для организации и координации деятельности специалистов-разработчиков при наличии единой, крупной целевой задачи, создания и совершенствования программного продукта, необходимы квалифицированные менеджеры проектов; • в проектах таких сложных программных средств и баз данных с множеством различных, функциональных компонентов, участвуют специалисты разной квалификации и специализации, от которых требуется высокая ответственность за качество результатов деятельности каждого из них; • от разработчиков проектов требуются гарантии высокого качества, надежности функционирования и безопасности применения компонентов и поставляемых программных продуктов, в которые не допустимо прямое вмешательство заказчика и пользователей для изменений, не предусмотренных эксплуатационной документацией разработчиков; • необходимо применять индустриальные, регламентированные стандартами процессы, этапы и документы, а также методы, методики и комплексы средства автоматизации, технологии обеспечения жизненного цикла комплексов программ. Такие крупномасштабные комплексы программ являются компонентами систем, реализующими обычно их основные, функциональные свойства, увеличивающими сложность и создающими предпосылки для последующих изменений их жизненного цикла. Реализация ЖЦ, методологии управления и изменения ПС зависит от многих факторов, от персонала, технических, организационных и договорных требований и сложности проекта. Множество текущих состояний и модификаций компонентов сложных ПС менеджерам необходимо упорядочивать, контролировать их развитие и применение участниками проекта. Организованное, контролируемое и методичное отслеживание динамики изменений в жизненном цикле программ и данных, их слаженная разработка при строгом учете и контроле каждого изменения, является основой эффективного, поступательного развития каждой крупной системы методами программной инженерии. 1.3.3. Классификация процессов жизненного цикла по ИСО/МЭК 12207 Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами. Каждый процесс разделен на набор действий, каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным). Согласно ГОСТ Р ИСО/МЭК 12207 выделяют следующие процессы жизненного цикла [ГОСТ Р ИСО/МЭК 12207]: Основные процессы: • приобретение; • поставка; • разработка; • эксплуатация; • сопровождение. Вспомогательные процессы: • документирование; • управление конфигурацией; • обеспечение качества; • верификация; • аттестация; • совместная оценка; • аудит; • разрешение проблем. Организационные процессы: • управление; • усовершенствование; • создание инфраструктуры; • обучение. 1.3.4. Стадии разработки программных средств по ЕСПД Теперь рассмотрим набор типовых стадий создания ПС, изучение которого позволит понимать процесс разработки и более осознанно относиться к созданию качества ПС. Эти стадии предусмотрены ГОСТ 19.102-77 ЕСПД. Стадии разработки. Стадии – наиболее укрупненные составляющие процесса разработки, для завершения которых характерно получение ПО в определённой стадии готовности. Рисунок Выделяют следующие стадии разработки программного обеспечения: 1 Стадия технического задания (предпроектная стадия) состоит из: • сбора исходных данных; • определения цели разработки – желаемого набора основных свойств и функций разрабатываемого ПС; • обоснования и выбора критерия эффективности и качества разработки; • формирования на верхнем уровне состава входной и выходной документации по решаемой задаче; • выбора принципиальных методов решения задач; • определения требований к комплексу технических средств и операционному окружению; • определения инструментальных средств, используемых для разработки; • планирования, т.е. декомпозиции процесса на стадии и этапы с установлением сроков их выполнения; • разработки документа, называемого «Техническое задание». 2 Эскизное проектирование На данной стадии выполняется: • детализация состава и структуры входной и выходной информации; • детализация метода решения задач. На этапе эскизного проектирования нужно создать предварительную версию программного средства (возможно в виде модели) и выяснить принципиальные вопросы, устраняя возможные разногласия между разработчиком и заказчиком. При этом выполняется: • определение предварительной технологии решения задачи; • прогнозирование эффективности решения задачи на конкретном объекте; • ведется освоение инструментальных средств (апробирование, обучение персонала). 3 Техническое проектирование (технический проект) На данном этапе: • окончательно определяется состав и структура информации; • разрабатывается интерфейс во всех его компонентах; • технология решения задачи доводится автоматизма; • полностью определяется конфигурация тех средств, на которых ведется разработка ПС; • определяется структура базы данных, где храниться информация о работе ПС; • разрабатывается тестовый набор для проверки правильности программной реализации; • начинается разработка программной документации; • полностью определяется структура ПС (модули, компоненты). Технический проект может рассматриваться как постановка задачи, передаваемой специалистом-постановщиком специалисту по программной реализации. 4 Рабочее проектирование (рабочий проект) Результат рабочего проектирования – получение ПС в состоянии операционной готовности, в котором устранены синтаксические и семантические ошибки, как в программном коде так и в программной документации. Основные работы этой стадии: • программная реализация (написание программного кода, привязка его к специфике конкретного объекта, адаптация и настройка программных модулей); • отладка (автономная – в лабораторных условиях и комплексная – на объекте); • разработка эксплуатационной документации; • организация внедрения ПС. 5 Внедрение На этапе внедрения осуществляют: • подготовку персонала к эксплуатации; • подготовку базы данных; • проверку работоспособности ПС на реальных данных (опытная эксплуатация); • доводку – окончательное устранение всех ошибок в коде и документации. По отдельным компонентам может быть откат на предыдущие стадии. В процессе разработки стадии могут объединяться. Объединяют эскизный и технический или технический и рабочий проекты. Иногда могут сразу объединять эскизный, технический и рабочий проекты. Обычно это производится, если в разрабатываемом ПС можно использовать значительный объём предыдущих разработок. 2. Модели жизненного цикла 2.1. Типичная схема управления процессом создания программного обеспечения Управление процессами при разработке программного обеспечения в общем случае реализуется по спиральной схеме и состоит из следующих повторяемых действий [44]: • создание инфраструктуры процесса (Establish Process Infrastructure). На данном этапе обеспечивается достижение согласия заинтересованных лиц (обычно это руководство организации) в работах по реализации или изменению процесса, определяется потребность в необходимых ресурсах и выполняется распределение обязанностей (ответственности); • планирование (Planning), в ходе которого формулируются текущие бизнес-цели и потребности в процессе, необходимые отдельным специалистам, проекту и/или организации, в целом, определяются и описываются сильные и слабые стороны существующего процесса и планируемых на данной итерации нововведений и/или изменений и разрабатывается план реализации и изменения процесса; • реализация и изменение процесса (Process Implementation and Change), предусматривающая выполнение разработанного плана по внедрению нового (усовершенствованного) процесса, в результате чего он процесс должен быть внедрен в практику организации; • оценка процесса (Process Evaluation), позволяющая выяснить уровень качества реализации процесса, а также степень достижения ожидаемых эффектов от его внедрения, после чего происходит либо выход, либо возвращение к первой итерации. 2.2. Фундаментальные модели жизненного цикла ПС Существует множество моделей процессов жизненного цикла систем и программных средств, но три из них в международных стандартах обычно квалифицируются как фундаментальные: каскадная; инкрементная; эволюционная. Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла конкретного проекта. При этом конкретную модель жизненного цикла системы или ПС следует выбирать так, чтобы процессы и задачи были связаны между собой, и определены их взаимосвязи с предшествующими процессами, видами деятельности и задачами. Согласно ГОСТ Р ИСО/МЭК 12207 выделяют следующие модели жизненного цикла [ГОСТ Р ИСО/МЭК 12207]: • каскадная (водопадная) или последовательная; • итеративная и инкрементальная – эволюционная (гибридная, смешанная); • спиральная (spiral) или модель Боэма. 2.2.1. Каскадная (водопадная) модель Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе. Рисунок. Каскадная модель жизненного цикла. На рисунке изображены типичные фазы каскадной модели жизненного цикла и соответствующие активы проекта, являющиеся для одних фаз выходами, а для других – входами. Практика показывает, что каскадная модель не эффективна для большинства ИТ-проектов. В программной инженерии – высокая «подвижность» требований, которые часто корректируются и уточняются, в силу невозможности их четкого и однозначного определения требований до начала работ по реализации. В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако, например, неточность какого-либо требования или некорректная его интерпретация, в результате, приводит к тому, что приходится “откатываться” к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. Кроме того, эта модель не способна гарантировать необходимую скорость отклика и внесение соответствующих изменений в ответ на быстро меняющиеся потребности пользователей, для которых программная система является одним из инструментов исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой модели, можно привести достаточно много. Достоинство: • наличие чёткого плана и временного графика по всем этапам проекта. Недостатки: • высокие издержки по причине частых откатов; • реальные проекты часто требуют отклонения от стандартной последовательности шагов; • цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично); • результаты проекта доступны заказчику только в конце работы. Сфера применения: • программные средства, являющиеся элементами аппаратных систем, требования к которым хорошо определены и изменяются не часто; • программные средства, применяемые в оборонной, медицинской, космической или авиационной отрасли. 2.2.2. Итеративная и инкрементальная модель – эволюционный подход Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых представляет собой самостоятельный проект, но в миниатюре, включая все фазы жизненного цикла. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результатом финальной итерации является версия ПС, которая реализует всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально. Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. Значимость эволюционного подхода на основе организации итераций особо проявляется в снижении неопределенности с завершением каждой итерации. В свою очередь, снижение неопределенности позволяет уменьшить риски. Рисунок 3 иллюстрирует некоторые идеи эволюционного подхода, предполагая, что итеративному разбиению может быть подвержен не только жизненный цикл в целом, включающий перекрывающиеся фазы – формирование требований, проектирование, конструирование и т.п., но и каждая фаза может, в свою очередь, разбиваться на уточняющие итерации, связанные, например, с детализацией структуры декомпозиции проекта – например, архитектуры модулей системы. Рисунок . Снижение неопределенности и инкрементальное расширение функциональности при итеративной организации жизненного цикла. Достоинства: • снижение неопределённости в требованиях по мере проектирования, позволяющее уменьшать число откатов; • совмещение относительно строгой последовательности шагов и итеративного подхода обеспечивает достаточно сбалансированный по рискам затрат план работ. Недостатки: • трудность прогнозирования сроков окончания проекта; • возможность отката при интеграции отдельных компонентов, что может приводить к откатам и связанным с ними затратам. Сфера применения: • программные средства, имеющие относительно несложную структуру в несколько десятков модулей, компоненты которой можно достаточно легко сочетать. Наиболее известным и распространенным вариантом эволюционной модели является спиральная модель, ставшая уже, по сути, самостоятельной моделью, имеющей различные сценарии развития и детализации. 2.2.3. Спиральная модель Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует перечень наиболее распространенных (по приоритетам) рисков [44]: • Дефицит специалистов.  • Нереалистичные сроки и бюджет. • Реализация несоответствующей функциональности. • Разработка неправильного пользовательского интерфейса. • “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей. • Непрекращающийся поток изменений. • Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию. • Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. • Недостаточная производительность получаемой системы. • “Разрыв” в квалификации специалистов разных областей знаний. Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде. Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели и, в частности, построенного на его основе подхода MBASE – Model-Based (System) Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых характеристик или практик, обеспечивающих успешное применение спиральной модели: 1. Параллельное, а не последовательное определение артефактов (активов) проекта 2. Согласие в том, что на каждом цикле уделяется внимание: ◦ целям и ограничениям, важным для заказчика ◦ альтернативам организации процесса и технологических решений, закладываемых в продукт ◦ идентификации и разрешению рисков ◦ оценки со стороны заинтересованных лиц (в первую очередь заказчика) ◦ достижению согласия в том, что можно и необходимо двигаться дальше 3. Использование соображений, связанных с рисками, для определения уровня усилий, необходимого для каждой работы на всех циклах спирали. 4. Использование соображений, связанных с рисками, для определения уровня детализации каждого артефакта, создаваемого на всех циклах спирали. 5. Управление жизненным циклом в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек: • Life Cycle Objectives (LCO) • Life Cycle Architecture (LCA) • Initial Operational Capability (IOC) 6. Уделение специального внимания проектным работам и артефактам создаваемой системы (включая непосредственно разрабатываемое программное обеспечение, ее окружение, а также эксплуатационные характеристики) и жизненного цикла (разработки и использования). Эволюционирование спиральной модели, таким образом, связано с вопросами детализации работ. Особенно стоит выделить акцент на большем внимании вопросам уточнения – требований, дизайна и кода, т.е. придание большей важности вопросам итеративности, в том числе, увеличения их количества при сокращении длительности каждой итерации. В результате, можно определить общий набор контрольных точек в сегодняшней спиральной модели: • Concept of Operations (COO) – концепция <использования> системы; • Life Cycle Objectives (LCO) – цели и содержание жизненного цикла; • Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы; • Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации; • FinalOperationalCapability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации. Достоинства: • большое внимание раннему анализу возможностей повторного использования; • предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта; • большое внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта, за счёт работ по анализу рисков, проверке различных характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки; • контроль источников проектных работ и соответствующих затрат; • возможность использования модели как для разработки нового продукта, так и для расширения (или сопровождения) существующего; • возможность решения интегрированных задач системной разработки, охватывающих и программную и аппаратную составляющие создаваемого продукта. Недостатки: • высокая нагрузка на заказчика, который становится, по сути, участником разработки; • большая сложность в прогнозировании окончания проектных работ; • наличие риска снижения качества финальной версии ПС по причине отказа от последних итераций для снижения сроков разработки. Сфера применения: • программные средства широкого применения (операционные системы, офисные программы, бизнес-приложения, игры и т.д.), разрабатываемые для коммерческого использования и некритичные к некоторому количеству небольших ошибок; • программное обеспечение информационных систем, разработка которого может без потерь продолжаться и в процессе сопровождения. Следует отметить, что с позиций отечественных стандартов существует только каскадная модель жизненного цикла, регламентированная в ГОСТ 19.102-77. Однако форма изложения стандарта позволяет с некоторыми уточнениями использовать его и для других моделей жизненного цикла. 3. Качество и эффективность в программной инженерии 3.1. Обеспечение качества программного обеспечения Качество – степень, с которой совокупность собственных характеристик объекта выполняет требования [определение международного стандарта ISO 9000-2008]. Качество программного средства – совокупность свойств программного продукта, которые обуславливают возможность удовлетворить определенные потребности пользователя в соответствии с его назначением. Такое понятное для сферы материального производства, понятие качества очень сложно и неоднозначно в сфере информационных технологий. Между тем, единое представление о качестве разрабатываемого продукта должно быть и у заказчиков, и у разработчиков, и у специалистов по сопровождению. 3.1.1. Качество программного продукта Формирование представлений о качестве, вернее, уровне качества разрабатываемого программного средства закладывается ещё на этапе формирования требований к нему. Следовательно, аналитики (специалисты по управлению требованиями) должны во взаимодействии, в первую очередь с заказчиками, извлечь требования к качеству и определить приоритеты в соотношении скорость разработки – качество конечного продукта. Стандарт ГОСТ Р ИСО/МЭК 9126-93 [39] служит гидом в деле определения качества программных средств и определяет, связанные характеристики качества, а также метрики, полезные для оценки качества программных продуктов. В стандарте понятие «продукт» расширено включением всех элементов, создаваемых на выходе всех процессов, используемых для создания конечного программного продукта, таких как: спецификация системных требований, спецификация программных требований для программных компонент системы, модели, код, тестовая документация, отчеты, создаваемые в результате работ по анализу качества. Обычно термин «качество» используется в отношении конечного продукта и поведения системы в процессе эксплуатации. 3.1.2. Культура и этика программной инженерии С точки зрения SWEBOK [44] предполагается, что инженеры по программному обеспечению должны воспринимать вопросы качества программного обеспечения как часть своей профессиональной культуры. Этические аспекты могут играть значительную роль в обеспечении качества программного обеспечения, культуре и отношении инженеров к своей работе. IEEE Computer Society и ACM разработали кодекс этики («моральный кодекс») и профессиональной практики, основанный на восьми принципах, помогающих инженерам укрепить их отношение к качеству и независимость в решении вопросов обеспечения достойного качества создаваемых программных продуктов в их повседневной работе. 3.1.3. Значение и стоимость качества Не все характеристики качества могут быть необходимы в конкретном проекте, некоторые из них могут требоваться не полно, в определённой степени. Значит, возникает возможность уменьшить трудоёмкость разработки, исключив из проекта избыточные требования. В зависимости от этого формируется и себестоимость качества. Стоимость качества может быть дифференцирована на стоимость предупреждения дефектов, стоимость оценки (контроля), стоимость внутренних, а также внешних сбоев [Кросби – затраты на качество]. Рис. 1 Составляющие затрат на качество Создаваемое программное средство должно обладать определенной ценностью для потребителя, которая может выражаться как в форме стоимости, так и в других формах. Заказчик имеет свои представления о максимальных возможностях по инвестированию в разработку и свои ожидания в отношении качества программного средства, которые являются ограничениями для проекта. Хотя нет универсальных рекомендаций о правилах выбора подходов к обеспечению качества, инженеры должны уметь генерировать альтернативы, определяющие соотношение различного уровня качества и стоимости, основываясь на идеи уменьшения затрат за счёт использования процессного подхода. 3.1.4. Повышение качества ПС с использованием процессного подхода Качество программного обеспечения можно повышать за счет итеративного процесса постоянного улучшения с одновременным управлением: • процессами жизненного цикла; • процессом обнаружения, устранения  и предотвращения сбоев/дефектов; • процессов улучшения качества. К программной инженерии применимы методы совершенствования качества, известные в промышленности. Например, предотвращение несоответствий, непрерывное улучшение, ориентация на потребителя и др. В основу этих методов положена идея о том, что качество продукта определяется качеством используемых для его создания процессов. Подходы TQM (Total Quality Management – всеобщее управление качеством) PDCA (Plan, Do, Check, Act – Планирование, Действие, Проверка, Реакция/Корректировка), являются инструментами в сфере управления качеством и также вполне применимы в рамках программной инженерии. Рис. 4.2 Цикл управления PDCA (взято из []) 3.1.5. Показатели качества программных средств Основные затруднения в определении показателей связаны с тем, что они носят качественный характер и должны оценивать различные свойства сопоставляемых программных изделий. А эти свойства присущи не самому программному изделию, а связаны с объектом применения ПС. Таким образом, качество ПС относительное понятие, которое имеет смысл только лишь в связи с реальными условиями применения. Рассмотрим показатели, приведённые в ISO/IEC 9126 [22]: 1. Функциональные возможности – набор атрибутов характеризующий, соответствие функциональных возможностей ПС набору требуемой пользователем функциональности. Это наиболее неопределенная и объективно трудно оцениваемая характеристика программного средства. Области применения, номенклатура и функции комплексов программ охватывают столь разнообразные сферы деятельности человека, что невозможно выделить и унифицировать небольшое число атрибутов для оценки и сравнения этой характеристики в различных комплексах программ. Функциональная пригодность ПС и конкретные показатели для её оценки: • пригодность по применению для решения задач – связь функционального назначения ПС с задачами, которые оно должно решать; • корректность (точность) – возможность ведения БД, насколько алгоритм формирования результата обеспечивает точность его получения; • защищенность – требования к надежности из ТЗ (от ошибок, несанкционированного доступа, возможность восстановления) • способность к взаимодействию – с другими ПС, включающую; ▪ согласованность со стандартами отрасли; ▪ согласованность со стандартами проектирования. 2. Надежность – набор атрибутов, относящихся к способности ПО сохранять свой уровень качества функционирования в установленных условиях за определенный период времени. Надёжность определяет измерение количественных метрик атрибутов характеристик в использовании. Износ или старение программного обеспечения не происходит. Ограничения надежности проявляются из-за ошибок в требованиях, проекте и реализации. Отказы из-за этих ошибок зависят от способа использования программного обеспечения и ранее выбранных версий программ. Надежность характеризуется: • уровнем завершенности и готовности (отсутствие остаточных ошибок после ввода в эксплуатацию); • устойчивостью к ошибкам в эксплуатации; • обратной связью по оценке продукта потребителем; • восстанавливаемостью – возможностью восстановления БД в случае нарушения её работы. 3. Практичность – набор атрибутов, относящихся к объему работ, требуемых для исполнения и индивидуальной оценки такого исполнения определенным или предполагаемым кругом пользователей. Практичность включает определение понятности, простоты использования, изучаемости и привлекательности программного средства. В основном это качественная (и субъективная) оценка в баллах, однако некоторые атрибуты можно оценить количественно по трудоемкости и длительности выполнения операций при использовании программного средства, а также по объему документации, необходимой для их изучения. Применимость включает: • понятность пользовательского интерфейса (насколько интерфейс приспособлен к уровню подготовки пользователя); • привлекательностью (визуальная привлекательность для пользователя); • характер предоставления эксплуатирующей документации (её вид, носит ли она функциональную направленность); • простоту обучения (наличие тематических справочников и развитой советующей и обучающей системой). 4. Эффективность – набор атрибутов, относящихся к соотношению между уровнем качества функционирования ПО и объемом используемых ресурсов при установленных условиях. Для корректного определения предельной пропускной способности информационной системы с данным программным средством нужно измерить экстремальные и средние значения длительностей исполнения функциональных групп программ и маршруты, на которых они достигаются. Если предварительно в процессе проектирования производительность компьютера не оценивалась, то, скорее всего, понадобится большая доработка или даже замена компьютера на более быстродействующий. Эффективность включает: • ресурсную эффективность – насколько требования к использованию ресурсов применимы к результатам решения задач; • временную эффективность. 5. Сопровождаемость – набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций). Сопровождаемость можно оценивать полнотой и достоверностью документации о состояниях программного средства и его компонентов, всех предполагаемых и выполненных изменениях, позволяющей установить текущее состояние версий программ в любой момент времени и историю их развития. Она должна определять стратегию, стандарты, процедуры, распределение ресурсов и планы создания, изменения и применения документов на программы и данные. Сопровождаемость включает: • удобство для анализа (удобство локализации ошибок, хорошо структурированных ПС); • изменяемость (возможность проводить изменения); • стабильность (сроком безотказной работы); • тестируемость (простотой формирования тестов). 6. Мобильность (переносимость) – набор атрибутов, относящихся к способности ПС быть перенесенным из одного окружения в другое. Количественно эту характеристику программного средства и совокупность ее атрибутов можно (и целесообразно) оценить в экономических показателях: стоимости, трудоемкости и длительности реализации процедур переноса на иные платформы определенной совокупности программ и данных. Переносимость характеризуется: • адаптируемостью – простотой адаптации пользователя и аппаратных средств; • замещаемостью – возможностью замещения ПС своей предыдущей версии и возможностью испытания элементов ПС в следующих версиях замещающего его ПС; • сосуществованием – возможностью без конфликтов с другими ПС функционировать в новом операционном окружении; • внедряемостью – трудоемкостью работ по установке ПС. 3.1.6. Количественная оценка качества программного обеспечения Если характеристики качества выбраны правильно, такие измерения могут поддержать качество (уровень качества) многими способами. Метрики могут помочь в управлении процессом принятия решений. Метрика программного обеспечения (англ. software metric) – мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций. Метрики могут способствовать поиску проблемных аспектов и узких мест в процессах. Метрики являются инструментом оценки качества своей работы самими инженерами – как в целях, определенных при управлении качеством, так и с точки зрения более долгосрочного процесса совершенствования качества [Error: Reference source not found]. По мере увеличения внутренней сложности программного обеспечения, всё острее встаёт вопрос – насколько достигаются количественно оцениваемые цели в области качества программного средства. Хотя, как количественные оценки характеристик качества могут полезны сами по себе, могут эффективно применяться математические и графические техники, облегчающие интерпретацию значений метрик. Такие техники вполне естественно классифицируются, например, следующим образом: • статистические методы (анализ Парето, нормальное распределение и т.п.); • статистические тесты; • анализ тенденций (сравнительный анализ); • предсказание (модели надежности). Техники, основанные на статистических методах и статистические тесты, обычно используются для выявления проблемных мест исследуемого программного продукта. Результирующие графики и диаграммы визуально помогают лицам, принимающим решения, в определении аспектов, на которых необходимо сфокусировать ресурсы проекта. Результаты анализа тенденций, позволяющие выявить скрытые дефекты, проявляющиеся в негативных тенденциях изменения отдельных характеристик. Техники предсказания помогают в планировании времени тестов и в предсказании сбоев. На основе методов количественной оценки могут быть сформированы, так называемые профили дефектов для конкретных прикладных областей. В дальнейшем, для будущих программных систем в данной организации, такие профили могут направлять процессы обеспечения качества программных средств, увеличивая усилия, направленные на наиболее вероятные источники проблем в создаваемых продуктах. Аналогично этому, результаты эталонных сравнений или типовое для данной прикладной области количество дефектов могут служить в качестве вспомогательных средств для определения момента, когда продукт готов для передачи в эксплуатацию. 4. Модели качества процессов конструирования В условиях жесткой конкуренции, важно гарантировать высокое качество процесса конструирования программных средств. 4.1.1. Качество процессов ISO/IEC определяет три связанных модели качества программного обеспечения – внутреннее качество, внешнее качество и качество в процессе эксплуатации, а также  набор соответствующих работ по оценке качества программного обеспечения (ISO/IEC 14598 [7, 8]). Модели качества в современном понимании строятся на управлении качеством и обеспечении качества процессов, в частности, программной инженерии. Качество процесса напрямую влияет на характеристики качества продукта, которые, в свою очередь, отражаются в восприятии качества продукта в процессе эксплуатации со стороны заказчика. Существует два основных подхода в области качества программного обеспечения: • Европейский подход TickIT, рассмотривающий общую систему менеджмента качества ISO 9001 в приложении к программным проектам и представленный, также, в виде специальных рекомендаций ISO 90003-04. • Американский подход CMMI предоставляющий рекомендации по совершенствованию (повышению зрелости) отдельных процессов. 4.1.2. CMM/CMMI Наверное, самым именитым стандартом качества следует считать Capability Maturity Model (CMM) – модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше – основные его положения были опубликованы еще в 1986 г. Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания ПО. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства. Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA). Название уровня Ключевые области процесса Начальный Самый примитивный статус организации. Организация способна разрабатывать ПО. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. Один проявляет инициативу и команда следует его указаниям. Успех одного проекта не гарантирует успех другого. При завершении проекта не фиксируются данные о трудозатратах, расписании и качестве. Повторяемый В некоторой степени отслеживается процесс. Делаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. Установленный Имеют определенный, документированный и установленный процесс работы, не зависящий от отдельных личностей. Т.е. Вводятся согласованные проф. Стандарты, а разработчики их выполняют. Такие организации в состоянии достаточно надежно предсказывать затраты на проекты, аналогичные выполненным ранее. Управляемый Могут точно предсказать сроки и стоимость работ. Есть база данных накопленных измерений. Но нет изменений при появления новых технологий и парадигм Оптимизированный Есть постоянно действующая процедура поиска и освоения новых и улучшенных методов и инструментов Таблица 1. Уровни модели CMM Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки. Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (табл. 2). Притом он получил новое имя – SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов. Таблица 2. Развитие стандартов CMM Название стандарта Описание System Engineering CMM (SE-CMM) Ориентирован на вопросы системного инжиниринга – разработку продуктов (анализ требований, проектирование систем продукта и их интеграция) и их производство (планирование производственных линий и функционирование) Trusted CMM (T-CMM) Предназначен для обслуживания чувствительных и закрытых программных систем, которые требуют гарантии высокого качества ПО System Security Engineering CMM (SSE-CMM) Сфокусирован на аспектах безопасности программной инженерии, обеспечивает безопасный процесс разработки, в том числе и безопасность членов команды создателей People CMM (P-CMM) Рассматривает вопросы развития персонала в софтверных организациях Software Acquisition CMM (SA-CMM) Охватывает вопросы приобретения программных продуктов у внешних организаций Integrated Product Development CMM (IPD-CMM) Служит средой для интеграции усилий по разработке на всех этапах жизненного цикла и со стороны каждого отдела компании Однако практическое применение стандартов серии CMM показало, что они не обеспечивают безоговорочного успеха в разработке ПС. Эти стандарты не были хорошо согласованы между собой – одновременное внедрение различных модификаций CMM могло оказаться достаточно сложной задачей и приводило в недоумение специалистов организаций, которые с этим сталкивались. Также существенная проблема CMM состоит в необходимости «выравнивания» всех процессов. Если организация пытается сертифицироваться на определенный уровень, то она должна обеспечить соответствующий уровень для всех своих процессов. Даже если специфика, методология или особенности разработки не располагают к выполнению определенных процессов, сертификация это требует. Еще одна проблема вызвана тем положением, которое заняли стандарты CMM в современной индустрии ПС. Поскольку организация, обладающая высоким уровнем в соответствии с CMM, должна обеспечивать более высокие показатели программных продуктов по сравнению с теми, кто сертифицирован на низших уровнях, то стандарт стал применяться в качестве критерия отбора для участия в тендерах на разработку ПС или в аутсорсинговых проектах. Спрос на сертифицированные организации породил предложение по «быстрой и безболезненной сертификации». Подобная ситуация стала возможной благодаря недостаткам процесса сертификации. Сертификации подлежит не вся организация в целом, а только определенный проект. Ничто не мешает организации создать «образцово-показательный» проект, выполняемый с учетом всех требований высоких уровней стандарта CMM, получить соответствующий уровень сертификации и заявить о том, что все продукты отвечают такому-то уровню стандарта. Разрешить большинство проблем CMM призван новый стандарт SEI – Capability Maturity Model Integrated (CMMI) – Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний. Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления – классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA). В табл. 3 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI. Таблица 3. Соответствие уровней CMM/CMMI № уровня Уровень зрелости CMM Уровень зрелости многоуровневого представления CMMI Уровень возможностей непрерывного представления CMMI – – Незавершенный 1 Начальный Начальный Выполнимый 2 Повторяющийся Управляемый Управляемый 3 Определенный Определенный Определенный 4 Управляемый Управляемый количественно Управляемый количественно 5 Оптимизируемый Оптимизируемый Оптимизируемый SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, вводя новые классы, позволяющие сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO. Однако факт остается фактом: в современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу. 4.1.3. TickIT TickIT – схема сертификации систем менеджмента качества ИТ–компаний на основе стандартов ISO серии 9000, предложенная группой ведущих фирм и некоммерческих организаций Великобритании, работающих в области информатики. Стандарты ISO серии 9000 – обширная и наиболее распространенная во всем мире серия стандартов качества. Они охватывают множество отраслей современной индустрии и периодически обновляются. Изначально стандарты ISO серии 9000 слабо учитывали специфику отрасли ПО и были больше ориентированы на производственную сферу. Однако в конце 1980-х годов был выпущен первый ориентированный на области разработки ПО стандарт, получивший название ISO 9000-3:1997. Несмотря на то, что ISO 9000-3 оперировал терминологией, которая используется при разработке ПО, и рассматривал характерные для программной индустрии вопросы, он являлся не более чем расширенным вариантом ISO 9001:1994, а потому не всегда соответствовал специфике программных проектов. Сегодня на смену ISO 9000-3 пришел стандарт ISO/IEC 90003:2004 [29], который, в свою очередь, является проекцией промышленного стандарта ISO 9001:2008 на программную индустрию. По сравнению с предыдущим он гораздо более приспособлен к специфике отрасли, в частности, ссылается на модели жизненного цикла программных систем и детально рассматривает вопросы, характерные для разработки ПО. Однако стандарт ISO 90003:2004 – это стандарт обеспечения качества и не может быть использован для оценки уровня зрелости и предсказания результата программного проекта. В таких случаях прибегают к стандарту ISO/IEC 15504 [40, 41], который предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI. Его текущая версия предусматривает шесть уровней возможностей (от нулевого до пятого), которые соответствуют уровням возможностей непрерывного представления стандарта CMMI (табл. 4). Таблица 4. Уровни CMMI (2004) № уровня Название уровня возможностей стандарта ISO/IEC 15504 Название уровня возможностей непрерывного представления CMMI Незавершенный Незавершенный 1 Выполнимый Выполнимый 2 Управляемый Управляемый 3 Установленный Определенный 4 Предсказуемый Управляемый количественно 5 Оптимизируемый Оптимизируемый Следует отметить, что в целом стандарты ISO/IEC 15504 и CMMI взаимозаменяемы, в частности, для CMMI предусматривается режим сертификации, в соответствии с которым одновременно проводится и сертификация по ISO/IEC 15504. Качество программного продукта регламентирует стандарт ISO/IEC 9126, состоящий из отдельных частей, которые выпускаются независимо. ISO/IEC 9126 предлагает комплексную иерархическую структуру для описания качественных характеристик ПО. Несмотря на то, что ISO позже, чем SEI взялась за разработку стандартов для программной индустрии, она имеет немало шансов завоевать передовую позицию. Стандарты ISO весьма обширны, процедура сертификации хорошо отработана. Отметим, что ISO требует периодической ресертификации, чего SEI не проводила для CMM. 4.1.4. Прочие подходы Начало методологии шести сигм (Six Sigma) было положено в Motorola в конце 1980-х годов. Motorola провозгласила курс на повышение качества производимой продукции, одним из направлений которого было снижение количества дефектов до уровня 6σ (где σ – дисперсия) – 3,4 дефекта на миллион возможных (на самом деле 3,4 дефекта на миллион возможных означает не 6, а 4,5 сигмы, однако разработчики методологии добавили полторы сигмы для того, чтобы учесть нестабильность процессов). Подобное значение было избрано не случайно – в результате проведенных в компании исследований было установлено, что именно такой уровень качества обеспечит, кроме явных преимуществ в виде повышения конкурентоспособности продукции, также сокращение издержек за счет уменьшения затрат на доводку некачественных разработок и устранение дефектов. Реализация шести сигм происходит в виде процесса DMAIC (Define, Measure, Analyze, Improve, Control): • определение; • измерение; • анализ; • совершенствование; • управление. Этот процесс построен на количественных методах принятия решений. Сильная сторона шести сигм – ориентация на интенсивное применение математического аппарата. Несмотря на промышленное происхождение, методология шесть сигм получила популярность среди разработчиков ПО. Ориентация на количественные методы позволила применять шесть сигм как инструмент для обеспечения постоянного совершенствования процесса. Особенно заметно его преимущество при использовании в организациях, которые достигли высоких уровней зрелости в соответствии с CMM/CMMI и ISO/IEC 15504. Недостатки: 1 Основное преимущество шести сигм одновременно является и основным недостатком методологии: ориентация на количественные методы предусматривает наличие возможностей для их применения. Организация должна приложить определенные усилия для того, чтобы внедрить методы количественной оценки производительности труда, показателей качества и т. д. Количественная оценка в отрасли ПО – весьма сложная задача. 2 Шесть сигм ориентирована на совершенствование процесса и не предусматривает изначального повышения показателей его эффективности. Для этих целей необходимы другие подходы. На практике шесть сигм очень часто успешно применяется совместно с другими стандартами и системами обеспечения качества, позволяя выявить причины проблем и помочь их устранить. Весьма популярная в Европе методология ITIL (IT Infrastructure Library) ориентирована на обеспечение функционирования IT-инфраструктуры. ITIL разработана при участии правительства Великобритании в конце 80-х – начале 90-х годов XX в. и первоначально получила распространение в правительственных проектах этой страны. ITIL – это зрелая и обширная методология, охватывающая практически все вопросы, связанные с разворачиванием и использованием информационных систем. Библиотека состоит из семи книг, в которых изложен комплекс вопросов по всем аспектам управления ИТ ресурсами предприятия [45]: • Предоставление сервисов (Service Delivery) – содержит описание процессов, направленных на выявление требований заказчиков в качестве ИТ сервисов и согласование этих требований с возможностями информационной инфраструктуры. • Поддержка сервисов (Service Support) – содержит описание процессов, направленных на обеспечение поддержки качества предоставления сервисов на согласованном с заказчиками уровне. • Управление ИТ инфраструктурой (ICT Infrastructure Management) – описывает деятельность, связанную с организацией эффективного управления информационной и телеком-муникационной инфраструктурой, служащей основой для предоставления ИТ сервисов, включая функциональные области дизайна и планирования, разработки и внедрения, эксплуатации, поддержки. • Управление приложениями (Application Management) – предоставляет целостное описание всех процессов управления, которые должны выполняться в течение жизненного цикла приложения, начиная с анализа потребностей и заканчивая выводом из эксплуатации. • Управление безопасностью (Security Management) – детализирует подходы к планированию и управлению безопасностью информации и ИТ сервисов. • Бизнес–перспектива (The Business Perspective) – описывает подходы к организации деятельности ИТ подразделений как бизнес–подразделений, охватывает вопросы организации взаимоотношений с потребителями и поставщиками, вопросы коммуникаций и обмена знаниями, согласования на стратегическом уровне потребностей бизнеса и возможностей ИТ. • Планирование внедрения сервисного подхода (Planning to Implement Service Management) – содержит описание подходов к планированию, реализации и совершенствованию процессов управления ИТ сервисами в организациях. Новая третья версия библиотеки ITIL сосредотачивается главным образом на ИТ-стратегии в рамках организации и на постоянном улучшении сервисов. Библиотека состоит из трёх частей: ядро (core), дополнительные книги (complementary) и интернет-часть (Web). Идеологическая часть ITIL® v3 - ядро - включает пять книг: по сервисной стратегии (service strategy), проектированию сервисов (service design), передаче сервисов (service transition), эксплуатации сервисов (service operation) и их постоянному улучшению (continual service improvement). ITIL хорошо согласуется со стандартами серии ISO 9000 и может служить основой для проведения по ним последующей сертификации. Однако данная методология не затрагивает непосредственно процессов разработки ПО, а потому обычно в софтверных компаниях применяется совместно с другими, более ориентированными на специфику ПО стандартами, например CMMI. Особую популярность ITIL получила в таких смежных с разработкой ПО областях, как служба поддержки, внедрение и сопровождение ПО, предоставление услуг по поддержке IT-инфраструктуры. Заметим, что эта методология допускает достаточно неоднозначную интерпретацию, поэтому ее внедрение должно происходить при участии опытных специалистов во избежание упрощения и неверной трактовки ее положений. 4.2. Процессы управления качеством программного обеспечения Процессы управления качеством многообразны: одни процессы позволяют напрямую находить дефекты, другие помогают определить где именно может быть важно провести более детальные исследования. Специализированные процессы управления качеством программного обеспечения определены в стандарте 12207 []: • процесс обеспечения качества; • процесс верификации; • процесс аттестации; • процесс совместного анализа; • процесс аудита. Процессы управления качеством помогают в обеспечении лучшего качества программного обеспечения в конкретном проекте. Они предоставляют менеджерам основную информацию по каждому продукту и, кроме того, включают параметры качества всего процесса программной инженерии. Процессы управления качеством состоят из задач и техник, предназначенных для оценки того, как начинают реализовываться планы по созданию программного обеспечения и насколько хорошо промежуточные и конечные продукты соответствуют заданным требованиям. Результаты выполнения этих задач представляются в виде отчетов для менеджеров перед тем, как будут предприняты соответствующие корректирующие действия. Процессы управления качеством тесно связаны между собой. Они могут перекрываться, а иногда даже и совмещаться. 4.2.1. Подтверждение качества программного обеспечения Процессы подтверждения качества программных средств обеспечивают подтверждение того, что программные продукты и процессы жизненного цикла проекта соответствуют заданным требованиям [44]. Подтверждение проводится на основе планирования, постановки задач (работ) и исполнения набора действий, направленных на то, чтобы качество стало неотъемлемой частью программного обеспечения. Такой подход обеспечивает точное формулирование требований к соответствующему решению. Процессы подтверждения качества функционируют для обеспечения качества в процессе разработки и сопровождения за счет выполнения различных действий на всех этапах жизненного цикла, что позволяет идентифицировать проблемы на ранних стадиях, которые практически неизбежны в любой сложной деятельности. Такая идентификация возможна во многих случаях, когда проблема еще является риском и ее предотвращение возможно. Поэтому управление рисками является серьезным дополнительным инструментом для обеспечения качества программного обеспечения. Роль процессов подтверждения качества состоит в том, чтобы обеспечить соответствующее планирование процессов, дальнейшее исполнение процессов на основе заданного плана и проведение необходимых измерений процессов с передачей результатов измерений заинтересованным сторонам (организационными структурам и лицам). 4.2.2. Проверка (верификация) и аттестация Проверка и аттестация программного обеспечения – упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований [44]. Верификация и аттестация напрямую адресуется вопросам качества программного обеспечения и использует соответствующие техники тестирования для обнаружения тех или иных дефектов. Верификация и аттестация может применяться для промежуточных продуктов, однако, в том объеме, который соответствует промежуточным шагам процессов жизненного цикла. Процесс верификации и аттестации определяет степень соответствия продукта (результата) тех или иных работ по разработке и сопровождению требованиям, сформулированным в рамках этих работ, а конечного продукта заданным целям и пользовательским требованиям. Верификация – попытка обеспечить правильную разработку продукта, в том значении, что получаемый в рамках соответствующей деятельности продукт соответствует спецификациям, заданным в процессе предыдущей деятельности. Аттестация – попытка обеспечить создание правильного продукта, с точки зрения достижения поставленной цели применения. Оба процесса – верификация и аттестация – начинаются на ранних стадиях разработки и сопровождения. Они обеспечивают исследованию (экспертизу) ключевых возможностей продукта как в контексте непосредственно предшествующих результатов (промежуточных продуктов), так и с точки зрения удовлетворения соответствующих спецификаций. 4.2.3. Оценка и аудит Оценки можно поделить на управленческие и технические: 1 Назначение управленческих оценок состоит в отслеживании развития проекта (продукта), определения статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности управленческих подходов, используемых для достижения поставленных целей. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Управленческие оценки поддерживают принятие решений о внесении изменений и выполнении корректирующих действий, необходимых в процессе выполнения программного проекта. Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), 2 Назначением технических оценок является исследование программного продукта для определения его пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с утвержденными спецификациями и стандартами. [IEEE 1028-97 “IEEE Standard for Software Reviews]. Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее решения, лидер оценки, регистратор, а также технический персонал, поддерживающий (непосредственно исполняющий) действия по оценке. Техническая оценка требует, в обязательном порядке, наличия следующих входных данных: • формулировки целей; • конкретного программного продукта (подвергаемого оценке); • заданного плана проекта (плана управления проектом); • списка проблем (вопросов), ассоциированных с продуктом; • процедуры технической оценки. Команда технической оценки следует заданной процедуре оценки. Квалифицированные лица представляют обзор продукта (представляя команду разработки). Исследование продукта проводится в течение одной и более встреч с разработчиками. Техническая оценка завершается после того, как выполнены все предписанные действия по исследованию продукта. В дополнение к оценкам ISO 12207 [”] вводит понятия инспекций, прогонок и аудитов: 1 Назначение инспекций состоит в обнаружении и идентификации аномалий в программном продукте. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Существует два серьезных отличия инспекций от оценок (управленческой и технической): • лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам команды инспектирования, не должны участвовать в инспекциях; • инспекция должна вестись под руководством непредвзятого (независимого от проекта и его целей) лидера, обученного техникам инспектирования. Инспектирование программного обеспечения всегда вовлекает авторов промежуточного или конечного продукта, в отличие от оценок, которые не требуют этого в обязательном порядке. Инспекции (как временные организационные единицы – группы, команды) включают лидера, регистратора, рецензента и нескольких (от 2 до 5) инспекторов. Инспекционные встречи занимают, обычно, несколько часов, в отличие от технической оценки и аудита, предполагающих, в большинстве случаев, больший объем работ и, соответственно, длящиеся дольше. 2 Назначение прогонки состоит в оценке программного продукта. Прогонка может проводиться с целью ознакомления (обучения) аудитории с программным продуктом. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Главные цели прогонки состоят (по IEEE 1028) в: • Поиске аномалий • Улучшении продукта • Обсуждении альтернативных путей реализации • Оценке соответствия стандартам и спецификациям Прогонка похожа на инспекцию, однако, обычно проводится менее формальным образом. В основном, прогонка организуется инженерами для других членов команды с целью получения отклика от них на свою работу, как одного из элементов (техник) обеспечения качества. 3 Назначением аудита программного обеспечения является независимая оценка программных продуктов и процессов на предмет их соответствия применимым регулирующим документам, стандартам, руководящим указаниям, планам и процедурам. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Аудит является формально организованной деятельностью, участники которой выполняют определенные роли, такие как главный аудитор, второй аудитор, регистратор и инициатор. В аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате аудита идентифицируются случаи несоответствия и формируется отчет, необходимый команде разработки для принятия корректирующих действий. 4.2.4. Характеристика дефектов Процессы управления качеством обеспечивают нахождение несоответствий (дефектов), описание которых играет основную роль в понимании продукта, облегчает корректировку процесса или продукта, а также  информирует менеджеров проектов и заказчиков о статусе (состоянии) процесса или продукта. Существуют множество классификаций дефектов (сбоев). Характеристика дефектов (аномалий) также используется в аудите и оценках, когда лидер оценки часто представляет для обсуждения на соответствующих встречах список аномалий, сформированный членами оценочной команды. Управления качеством ПС обеспечивает сбор информации на всех стадиях разработки и сопровождения программного обеспечения. Различные стандарты предполагают различное смысловое наполнение терминов, связанных с понятием «дефект». Частичные определения понятий такого рода (из стандарта IEEE 610.12-90 “ IEEE Standard Glossary of Software Engineering Terminology ”) выглядят следующим образом: • Ошибка (error): “Отличие … между корректным результатом и вычисленным результатом < полученным с использованием программного обеспечения>” • Недостаток (fault): “Некорректный шаг, процесс или определение данных в компьютерной программе” • Сбой (failure): “<Некорректный> результат, полученный в результате недостатка” • Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее к некорректному результату” Под дефектом будем понимать результат сбоя программного обеспечения. По результатам работ, направленных на обнаружение дефектов, выполняются действия по удалению дефектов из исследуемого продукта. Кроме того, проводится анализ и подведение итогов по обнаруженным несоответствиям / дефектам, использование техник количественной оценки (получение метрик) для улучшения продукта и процесса, отслеживание дефектов и удаления их из системы (с управленческим и техническим контролем проведения необходимых корректирующих действий). Данные о несоответствиях и дефектах, найденных в процессе реализации процессов обеспечения качества, должны фиксироваться для предотвращения их потери. Для некоторых техник, присутствие регистратора – обязательно, именно для фиксирования такой информации, наравне с вопросами и принятыми решениями. Отчеты о дефектах направляются управленческому звену организации/организационной единицы или структуры. 4.2.5. Методы управления качеством программного обеспечения Методы управления качеством программных средств могут быть распределены по нескольким категориям: • статические; • техники коллективной оценки; • аналитические; • динамические. Статические техники Статические техники предполагают детальное исследование проектной документации, программного обеспечения и другой информации о программном продукте без его исполнения. Эти техники могут включать другие, действия по коллективной оценке или индивидуальному анализу, вне зависимости от степени использования средств автоматизации. Техники коллективной оценки Форма такого рода техник, включая оценку и аудит, может варьироваться от формальных собраний до неформальных встреч или обсуждения продукта даже без обращения к его коду. Обычно, такого рода техники предполагают очного взаимодействия минимум двух, а в большинстве случаев, и более специалистов. При этом, такие встречи могут требовать предварительной подготовки. К ресурсам, используемым в таких техниках, наравне с исследуемыми артефактами могут относиться листы проверки и результаты аналитических техник и работ по тестированию. Аналитические техники Инженеры, занимающиеся программным обеспечением, как правило, применяют аналитические техники. Иногда, несколько инженеров используют одну и ту же технику, но в отношении разных частей продукта. Некоторые техники базируются на специфике применяемых инструментальных средств, другие – предполагают “ручную” работу. Многие могут помогать находить дефекты напрямую, но чаще всего они используются для поддержки других техник. Ряд техник также включает различного рода экспертизу (assessment) как составной элемент общего анализа качества. Каждый тип анализа обладает конкретным назначением и не все типы применимы к любому проекту. Примером техники поддержки является анализ сложности, который полезен для определения фрагментов дизайна системы, обладающих слишком высокой сложностью для корректной реализации, тестирования или сопровождения. Для программного обеспечения с обширной алгоритмической логикой крайне важно применять алгоритмические техники, особенно в тех случаях, когда некорректный алгоритм может привести к катастрофическим результатам (например, программное обеспечение авионики, для которой вопросы безопасности использования играют решающую роль).   Другие, более формальные типы аналитических техник известны как формальные методы. Они иногда применяются для проверки требований и дизайна. Проверка корректности применяется к критическим фрагментам программного обеспечения. Чаще всего они используются для верификации особо важных частей критически-важных систем, например, конкректных требований информационной безопасности и надежности. Динамические техники В процессе разработки и сопровождения программного обеспечения приходится обращаться к различным видам динамических техник. В основном, это техники тестирования. Однако, в качестве динамических техник могут рассматриваться техники симуляции, проверки моделей и  “символического” исполнения (предполагает использование модулей-“заглушек” с точки зрения выполняемой логики при рассмотрении общего сценария поведения многомодульных систем). В зависимости от организации ведения проекта, определенные работы по тестированию могут выполняться при разработке программных систем в процессах управления качеством и процессах верификации и аттестации. 5. Стандартизация и сертификация программного обеспечения 5.1. Стандартизация качества программного обеспечения 5.1.1. Стандарты в сфере программной инженерии Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие: • стандарт проектирования; • стандарт оформления проектной документации; • стандарт пользовательского интерфейса. Стандарт проектирования должен устанавливать: • набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; • правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.; • требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.; • механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д. Стандарт оформления проектной документации должен устанавливать: • комплектность, состав и структуру документации на каждой стадии проектирования; • требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.), • правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; • требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; • требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать: • правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; • правила использования клавиатуры и мыши; • правила оформления текстов помощи; • перечень стандартных сообщений; • правила обработки реакции пользователя. 5.1.2. Стандартизация программных продуктов в ЕСПД В процессе стандартизации вырабатываются нормы, правила, требования, характеристики, касающиеся объекта стандартизации, которые оформляются в виде нормативного документа. Документирование разработки, сопровождения и эксплуатации программ выполняют в соответствии с группой стандартов ГОСТ 19.ХХХ-ХХ. Предусматривается построение обозначений стандартов в следующем порядке: • номер 19 – класс стандартов ЕСПД; • после 19 ставится точка и далее одна цифра – код классификационной группы стандартов, определенной группы стандартов; • далее идет двузначное число – порядковый номер стандарта в группе; • через тире за ним ставится двузначное число – год регистрации стандарта. Ниже приведены государственные стандарты на компоненты, стандартизируемой продукции. ГОСТ 19.101-77, введен с 1981 г. Виды программ и программных документов. ГОСТ 19.102-77. Стадии разработки. ГОСТ 19.103-77. Обозначения программ и программных продуктов. ГОСТ 19.104-78, введен с 1981 г. Основные надписи. ГОСТ 19.105-78, введен с 1981 г. Общие требования к программным документам. ГОСТ 19.106-78, введен с 1981 г. Требования к программным документам, выполненным печатным способом. ГОСТ 19.201-78, введен с 1981 г. ТЗ. Требования к содержанию и оформлению. ГОСТ 19.202-78. Спецификация. ГОСТ 19.301-79, введен с 1983 г. Программа и методика испытаний. ГОСТ 19.401-78, введен с 1983 г. Текст программы. ГОСТ 19.402-78, введен с 1981 г. Описание программы. ГОСТ 19.403-79. Ведомость держателей подлинников. ГОСТ 19.404-79. Пояснительная записка. ГОСТ 19.501-78. Формуляр. ГОСТ 19.502-78, введен с 1981 г. Описание применения. ГОСТ 19.503-79, введен с 1981 г. Руководство системного программиста. ГОСТ 19.504-79, введен с 1981 г. Руководство программиста. ГОСТ 19.505-79, введен с 1981 г. Руководство оператора. ГОСТ 19.506-79, введен с 1981 г. Описание языка. ГОСТ 19.507-79, введен с 1981 г. Ведомость эксплуатационных документов. ГОСТ 19.508-79. Руководство по техническому обслуживанию. ГОСТ 19.601-78. Общие правила дублирования, учета и хранения. ГОСТ 19.602-78. Правила дублирования, учета и хранения программных документов, выполненным печатным способом. ГОСТ 19.603-78, введен с 1981 г. Общие правила внесения изменений. ГОСТ 19.604-78, введен с 1981 г. Правила внесения изменений в программные документы, выполненные печатным способом. ГОСТ 19.701-90, введен с 1992 г. Схемы алгоритмов, программ, данных и систем. Стандартизация помогла унифицировать и автоматизировать процесс создания программ на базе инструментальных и программных средств, создать системы автоматизированного программирования с использованием инструментальных и программных средств. К настоящему времени АС позволяют унифицировано выполнять следующие процессы: • анализ задачи, разбиение её на подзадачи; • анализ структур данных; • запись требований к программе и разработку ее общей структуры; • выделение модулей, написание их спецификаций, определение интерфейса между ними; • вычерчивание блок-схем алгоритмов; • непосредственно программирование (кодирование); • отладку и тестирование; • анализ качества и количества затраченного труда на разработку ПС. Стандартизация улучшает контроль и регламентацию труда программистов, поэтому иногда она встречает у них психологический барьер. 5.1.3. Виды стандартных программных документов Программные документы и их содержание: • спецификация – перечень и назначение всех файлов ПС, включая файлы документации; • ведомость держателей подлинников – список предприятий, хранящих подлинники программных документов, составляется только для сложных ПС; • текст программы – запись кодов программы и комментарии к ним; • описание программы – информация о логической структуре и функционировании программы; • программа и методика испытаний – перечень и описание требований, которые должны быть проверены в ходе испытания программы, методы контроля; • техническое задание – документ, в котором излагаются назначение и область применения программы, требования к ПС, стадии и сроки разработки, виды испытаний; • пояснительная записка – обоснование принятых и примененных технических и технико-экономических решений, схемы и описание алгоритмов, общее описание работы ПС. К программным документам отнесены также документы, обеспечивающие функционирование и эксплуатацию программ – эксплуатационные документы: • ведомость эксплуатационных документов – содержит список эксплуатационных документов на ПС, к которым относятся формуляр, описание применения, руководство системного программиста, руководство программиста, руководство оператора, описание языка, руководство по техническому обслуживанию; • формуляр – содержит основные характеристики ПС, состав и сведения об эксплуатации программы; • описание применения – содержит информацию о назначении и области применения ПИ, ограничениях при применении, классе и методах решаемых задач, конфигурации технических средств; • руководство системного программиста – содержит сведения для проверки, настройки и функционирования программы при конкретном применении; • руководство программиста – содержит сведения для эксплуатации ПС; • руководство оператора – содержит подробную информацию для пользователя, обеспечивающую его общение с ЭВМ в процессе выполнения ПС; • описание языка – содержит синтаксис и семантику языка; • руководство по техническому обслуживанию – содержит сведения для применения тестовых и диагностических программ при обслуживании технических средств. Необходимость составления остальных документов устанавливается при разработке и утверждении технического задания (ТЗ). Допускается объединять отдельные виды эксплуатационных документов. Например, часто разрабатывают документ, называемый «Руководство пользователя», в который включают различные сведения из руководства системного программиста, руководства программиста и оператора. «Руководство пользователя» должно учитывать все требования инструкций, необходимых пользователю и содержать, как правило, общие сведения о ПС, описание установки и запуска, подробные инструкции по работе, т. е. описание режимов работы, форматов ввода-вывода информации, различных настроек и другой необходимой информации для пользователя. Большую роль для унификации при программировании играет стандарт ГОСТ 19.701-90 (ИСО 5807-85) «Схемы алгоритмов, программ, данных и систем», где приведены условные обозначения в схемах алгоритмов, программ, данных и систем, устанавливаются правила выполнения схем для решения различных задач. В этом стандарте описаны последовательности описания схем: • данных (отображают путь данных, этапы обработки, носители); • программы (отображают последовательность операций в программе); • работы системы (отображают управление операциями и поток • данных в системе); • взаимодействия программ (отображают путь активаций программ и взаимодействий с соответствующими данными); • ресурсов системы (отображают конфигурацию блоков: данных и обрабатывающих). Виды программных документов и их содержание Код Вид программного документа Содержание программного документа - Спецификация Состав программы и документации на нее 05 Ведомость держателей подлинников Перечень предприятий, на которых хранят подлинники программных документов 12 Текст программы Запись программы с необходимыми комментариями 13 Описание программы Сведения о логической структуре и функционировании программы 51 Программа и методика испытаний Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля - Техническое задание Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний 81 Пояснительная записка Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений - Эксплуатационные документы Сведения для обеспечения функционирования и эксплуатации программы Виды эксплуатационных документов и их содержание Код Вид эксплуатационного документа Содержание эксплуатационного документа 20 Ведомость эксплуатационных документов Перечень эксплуатационных документов на программу 30 Формуляр Основные характеристики программы, комплектность и сведения об эксплуатации программы 31 Описание применения Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств 32 Руководство системного программиста Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения 33 Руководство программиста Сведения для эксплуатации программы 34 Руководство оператора Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы 35 Описание языка Описание синтаксиса и семантики языка 46 Руководство по техническому обслуживанию Сведения для применения тестовых и диагностических программ при обслуживании технических средств 5.1.4. Действующие международные стандарты в сфере разработки программных средств и информационных технологий 1 ISO/IEC 90003:2004. Техника программного обеспечения. Рекомендации по применению ISO 9001:2000 к компьютерному программному обеспечению. 2 ISO/IEC 15504-1:2004. Информационные технологии. Оценка процессов. Часть 1. Общие понятия и словарь. 3 ISO/IEC 15504-2:2003. Информационные технологии. Оценка процессов. Часть 2. Выполнение оценки 4 ISO/IEC 15504-3:2004. Информационные технологии. Оценка процесса. Часть 3. Руководство по выполнению оценки. 5 ISO/IEC 15504-4:2004. Информационные технологии. Оценка процесса. Часть 4. Руководство для усовершенствования процессов и определения их результативности. 6 ISO/IEC TR 15504-5:1999. Информационные технологии. Оценка процессов программного обеспечения. Часть 5. Оценочная модель и руководящие указания по индикации. 7 ISO/IEC 14756:1999. Информационные технологии. Измерение и оценка эксплуатационных характеристик автоматизированных систем программного обеспечения. 8 ISO/IEC TR 14759:1999. Разработка программного обеспечения. Макет и прототип. Категоризация моделей макета и прототипа программного обеспечения и их применение. 9 ISO/IEC TR 12182:1998. Информационные технологии. Классификация программного обеспечения 10 ISO/IEC 12207:1995. Информационные технологии. Процессы жизненного цикла программного обеспечения. 11 ISO/IEC TR 15271:1998. Информационные технологии. Руководство по применению ISO/IEC 12207 (Процессы жизненного цикла программных средств). 12 ISO/IEC TR 16326:1999. Разработка программного обеспечения. Руководство по применению ISO/IEC 12207 к управлению проектом. 13 ISO/IEC 12207:1995/Amd.1:2002. Информационные технологии. Процессы жизненного цикла программного обеспечения. Изменение 1 14 ISO/IEC 12207:1995/Amd.2:2004. Информационные технологии. Процессы жизненного цикла программного обеспечения. Изменение 2. 15 ISO/IEC 16085:2004. Информационные технологии. Процессы жизненного цикла программного обеспечения. Управление рисками. 16 ISO/IEC TR 19759:2005. Совокупность знаний о разработке программного обеспечения. Руководство. 17 ISO/IEC 15026:1998. Информационные технологии. Системные и программные уровни целостности. 18 ISO/IEC 25000:2005. Технология программного обеспечения. Требования и оценка качества программного продукта. Руководство. 19 ISO/IEC 25010:2011. Разработка программного обеспечения и проектирование систем. Требования к качеству и оценка систем и программного продукта (SQuaRE). Модели качества системы и программного продукта 20 ISO/IEC 14598-1:1999. Информационные технологии. Оценка программного продукта. Часть 1. Общий обзор. 21 ISO/IEC 14598-2:2000. Разработка программного обеспечения. Оценка программного продукта. Часть 2. Планирование и руководство. 22 ISO/IEC 14598-3:2000. Разработка программного обеспечения. Оценка программного продукта. Часть 3. Процесс для разработчиков.ISO/IEC 14598-4:1999. Разработка программного обеспечения. Оценка продукта. Часть 4. Процесс для закупщика. 23 ISO/IEC 14598-5:1998. Информационные технологии. Оценка программного продукта. Часть 5. Процесс для оценщика. 24 ISO/IEC 14598-6:2001. Разработка программного обеспечения. Оценка продукта. Часть 6. Документирование модулей оценки 25 ISO/IEC 15939:2002. Технология программного обеспечения. Процесс измерения программного обеспечения 26 ISO/IEC TR 9294:2005. Руководство по управлению документированием программного обеспечения. 27 ISO/IEC 15910:1999. Информационные технологии. Процесс создания документации пользователя программного обеспечения. 28 ISO/IEC 18019:2004. Программное обеспечение и системотехника. Рекомендации по проектированию и подготовке документации пользователя для прикладного программного обеспечения. 29 ISO/IEC 6592:2000. Информационные технологии. Руководящие указания по разработке документации на компьютерные прикладные системы. 30 ISO 9127:1988. Системы обработки информации. Документация пользователя и сопроводительная информация программных пакетов потребителя. 31 ISO/IEC 14764:1999. Информационные технологии. Сопровождение программного обеспечения. 32 ISO/IEC TR 15846:1998. Информационные технологии. Процессы жизненного цикла программного обеспечения. Управление конфигурацией. 33 ISO/IEC 15408-1:2005. Информационные технологии. Методы защиты. Критерии оценки для информационных технологий. Часть 1. Введение и общая модель. 34 ISO/IEC 15408-2:1999. Информационные технологии. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности. 35 ISO/IEC 15408-3:1999. Информационные технологии. Методы защиты. Критерии оценки безопасности информационных технологий. Часть 3. Требования к обеспечению защиты. 36 ISO/IEC 13335-1:2004. Информационные технологии. Способы защиты. Управление защитой информационных и коммуникационных технологий. Часть 1. Понятия и модели для управления защитой информационных и коммуникационных технологий. 37 ISO/IEC TR 13335-3:1998. Информационные технологии. Руководящие указания по управлению защитой информационных технологий. Часть 3. Методы управления защитой информационных технологий. 38 ISO/IEC TR 13335-4:2000. Информационные технологии (ИТ). Руководящие указания по управлению защитой ИТ. Часть 4. Выбор защитных мер. 39 ISO/IEC TR 13335-5:2001. Информационные технологии (ИТ). Руководящие указания по управлению защитой ИТ. Часть 5. Административное руководство по обеспечению безопасности сетей. 40 ISO/IEC 14143-1:1998. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 1. Определение понятий. 41 ISO/IEC 14143-2:2002. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 2. Оценка соответствия методов измерения размера программного обеспечения стандарту ИСО/МЭК 14143-1:1998. 42 ISO/IEC TR 14143-3:2003. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 3. Проверка методов измерения функционального размера. 43 ISO/IEC TR 14143-4:2002. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 4. Эталонная модель. 44 ISO/IEC TR 14143-5:2004. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 5. Определение функциональных доменов, используемых для измерения функционального размера. 45 ISO/IEC 2382-20:1990. Информационные технологии. Словарь. Часть 20. Разработка системы. 46 ISO/IEC 8211:1994. Информационные технологии. Спецификация описательного файла данных для обмена информацией. 47 ISO/IEC 14102:1995. Информационные технологии. Руководство по оцениванию и выбору инструментальных CASE-средств. 5.2. Сертификация программных средств 5.2.1. Правовые акты по сертификации программных продуктов Прежде всего, программист должен хорошо знать действующие в стране законы, регламентирующие области работ, с которыми он соприкасается. Ему должны быть хорошо известны основные поло­жения следующих федеральных законов: 1. «О сертификации продукции и услуг» от 27 апреля 1993 г. № 5151-1 (в ред. от 27 декабря 1995г. № 211-ФЗ; от 2 марта 1998 г. № 30-ФЗ; от 31 июля 1998 г. № 154-ФЗ); 1. «Об информации, информатизации и защите информации» от 20 февраля 1995 г. № 24-ФЗ; 2. «О правовой охране программ для электронных вычислитель­ных машин и баз данных» от 23 сентября 1992 г. № 3523-1; 3. «Об участии в международном информационном обмене» от 4 июля 1996 г. № 85-ФЗ; 4. «Об авторском праве и смежных правах» от 9 июля 1993 г. № 5351-1 (в ред. от 19 июля 1995 г. № 110-ФЗ). В соответствии со первым законом «сертификация продукции (далее – сертификация) – процедура подтверждения соответствия, посредством которой независимая от изготовителя (продавца, ис­полнителя) и потребителя (покупателя) организация удостоверяет в письменной форме, что продукция соответствует установленным требованиям». Сертификация осуществляется в целях: • содействия потребителям в компетентном выборе продукции; • зашиты потребителя от недобросовестности изготовителя (продавца, исполнителя); • контроля безопасности продукции для окружающей среды, жизни, здоровья и имущества; • подтверждения показателей качества продукции, заявленных изготовителем. Сертификация может иметь обязательный и добровольный ха­рактер». Обязательная сертификация проводится в случаях, предусмот­ренных законодательными актами РФ. Организация и проведение работ по обязательной сертификации возложены на Госстандарт России и другие федеральные органы исполнительной власти РФ. Добровольная сертификация проводится по инициативе заяви­телей (изготовителей, продавцов, исполнителей) для того, чтобы подтвердить соответствие продукции требованиям стандартов, тех­нических условий и других документов, определяемых заявителем. Проводится она на условиях договора между заявителем и органом по сертификации. Во втором законе определены основные принципы разработки, производства, сертификации и лицензирования информационных систем, технологий и средств их обеспечения (а следовательно и ПО).о В третьем законе установлены многие основные понятия и определения создания и использования программ. Например, про­грамма для ЭВМ определяется как «объективная форма представле­ния совокупности данных и команд, предназначенных для функ­ционирования ЭВМ и других компьютерных устройств с целью по­лучения определенного результата, включая подготовительные материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею аудиовизуальные отображения». База данных опре­деляется как «объективная форма представления и организации со­вокупности данных, систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ». В четвёртом законе определен правовой режим участия в междуна­родном информационном обмене и установлены правила контроля и ответственности при осуществлении международного информаци­онного обмена. В пятом законе даны основные понятия авторского права, правила использования и зашиты авторских произведений, в том числе программ для ЭВМ. В ст. 25 этого закона «Свободное воспро­изведение программ для ЭВМ и баз данных. Декомпилирование программ для ЭВМ» описаны условия, при которых можно исполь­зовать программу без получения разрешения автора или иного обла­дателя прав на нее. Это только лица, правомерно владеющие экземп­ляром программы для ЭВМ или БД. Ни при каких обстоятельствах не должны быть ущемлены законные интересы автора или иного обладателя исключительных прав на программу для ЭВМ или БД. 5.2.2. Сертификация ПС Имеется два сертификационных документа: серти­фикат соответствия и знак соответствия. Сертификат соответствия – это документ, выданный по пра­вилам системы сертификации для подтверждения соответствия сер­тифицированной продукции установленным требованиям. Знак соответствия – это зарегистрированный в установленном порядке знак, которым по правилам определенной системы серти­фикации подтверждается соответствие маркированной им продук­ции установленным требованиям Система сертификации – совокупность участников сертифика­ции, которые проводят сертификацию продукции по устанавливае­мым в этой системе определенным правилам в соответствии с зако­ном. Система сертификации создается федеральными органами ис­полнительной власти. Сертификация включает следующие этапы: 1. подача заявки на сертификацию; 2. рассмотрение и принятие решения по заявке; 3. проведение необходимых проверок (анализ документов, ис­пытания, проверка и т. п.); 4. анализ полученных результатов и принятие решения о воз­можности выдачи сертификата соответствия; 5. выдача сертификата и лицензии (разрешения) на применение знака соответствия; 6. инспекционный контроль за сертифицированным объектом в соответствии со схемой сертификации. Все данные, в том числе выявленные несоответствия, полученные при анализе документации ПО, заносятся в протоколы испытаний. Перечень документов, сопровождающих ПО, объем и методы проверки документации могут корректироваться соглашением между исполнителем и заказчиком аттестации ПО. В соответствии со ст. 21 Федерального закона «О техническом регулировании» орган по сертификации: • осуществляет подтверждение соответствия объектов добровольного подтверждения соответствия, в том числе при необходимости создает или привлекает на договорной основе испытательные лаборатории, в которых организует проведение испытаний ПО (ПП) по согласованным с заказчиком методикам; • выдает Сертификаты соответствия на объекты, прошедшие добровольную сертификацию; • предоставляет заявителю право на применение знака соответствия; • приостанавливает или прекращает действие выданных им Сертификатов соответствия. Орган по сертификации не имеет права принимать участие в подготовке организации к сертификации, поскольку это противоречит принципу независимости аудита. Испытательные лаборатории выполняют следующие функции: • проводят испытания ПО (ПП) по согласованным с заказчиком методикам; • оформляют результаты испытаний соответствующими протоколами, на основании которых орган по сертификации принимает решение о выдаче или об отказе в выдаче Сертификатов соответствия. Схема сертификации – определенная совокупность действий, официально принимаемая в качестве доказательства соответствия продукции заданным требованиям. 5.2.3. Перечень объектов, подлежащих сертификации и их характеристики Объектами, подлежащими добровольной сертификации, являются: • программное обеспечение средств измерений как автономное, так и встроенное; • программное обеспечение измерительных и информационно-измерительных систем; • программное обеспечение контроллеров и вычислительных блоков, не входящих в состав информационно-измерительных систем. Каждая позиция в перечне программного обеспечения (программных продуктов), подаваемом заявителем для прохождения процедуры добровольной сертификации, должна содержать следующую информацию: • описание структуры ПО (ПП) и выполняемых функций, в том числе последовательность обработки данных; • описание функций и параметров ПО (ПП), подлежащих метрологическому контролю; • описание реализованных в ПО (ПП) расчетных алгоритмов, а также их блок-схемы; • описание модулей ПО (ПП); • перечень интерфейсов и перечень команд для каждого интерфейса, включая заявление об их полноте; • список, значение и действие всех команд, получаемых от клавиатуры, мыши и других устройств ввода; • описание реализованной методики идентификации ПО (ПП); • описание реализованных методов защиты ПО (ПП) и данных; • описание интерфейсов пользователя, всех меню и диалогов; • описание хранимых или передаваемых наборов данных; • руководство пользователя; • характеристики требуемых системных и аппаратных средств, если эта информация не приведена в руководстве пользователя. Перечень документов, сопровождающих ПО (ПП), может корректироваться соглашением между исполнителем и заказчиком сертификации ПО. Графическая и текстовая информация в документации выполняется таким образом, чтобы она была пригодна для полного и однозначного понимания. Характеристиками ПО СИИИС, подлежащими процедуре добровольного подтверждения соответствия, являются характеристики, являющиеся количественными или качественными представлениями требований, предъявляемых к ПО (ПП) и устанавливаемых НД ПО, а именно: 1) требований к структуре, т.е. к выделению частей, подлежащих метрологическому контролю, а также к наличию и правильности функционирования защищенных интерфейсов; 2) требований к идентификации; 3) требований к защите измерительной и иной хранимой и передаваемой информации; 4) требований к соответствию характеристик тем, которые были установлены и приписаны ПО (ПП) при испытаниях СИ и других устройств с целью утверждения типа; 5) требований к степени влияния на метрологические и информационные характеристики средств измерений, информационно-измерительных систем. Для подтверждения гарантий обеспечения соответствия ПО (ПП) установленным СДС ПО СИИИС требованиям в любой период деятельности заявителя в организации (фирме) должна быть организована документально оформленная Система контроля ПО СИИИС. 6. Извлечение программных требований 6.1.1. Программные требования Программные требования – свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований. Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты. Только систематичная работа с требованиями позволяет корректным образом обеспечить моделирование задач реального мира и формулирование необходимых приемочных тестов для того, чтобы убедиться в соответствии создаваемых программных систем критериям, заданным реальными практическими потребностями [Error: Reference source not found]. Требование – условие или особенность, которой должна удовлетворять система. Требованием может быть: • функциональность, необходимая заказчику или пользователю для разрешения проблем (или получения прибыли); • функциональность, которая должна быть реализована в системе в соответствии с контрактом, стандартом, спецификацией, инструкцией или другим официальным документом; • ограничение, наложенное заинтересованным лицом. 6.1.2. Функциональные и нефункциональные требования Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase. Систематизируя работы Вигерса, Лефингвелла и Видрига, Коберна, а также других экспертов, Возможно и необходимо привести классификацию различных категорий (видов) требований и связанных с ними понятий, важнейших с точки зрения их понимания и дальнейшего практического применения: • Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы. • Группа функциональных требований - Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения. - Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). - Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. • Группа нефункциональных требований (Non-Functional Requirements) - Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. - Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей. - Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п. - Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам. • Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем. 6.1.3. Требования с количественной оценкой Требования с количественной оценкой – требования, поддающиеся количественному измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост пропускной способности” без указания конкретных количественных характеристик является просто некорректно определенным требованием. При этом, например, требование “система должна вести журнал подключений пользователей” может и должно детализироваться с точки зрения описания информации, которую необходимо сохранять в журнале, однако, такое требование уже не будет являться количественным требованием. А требование с формулировкой “система должна обладать интуитивно-понятным пользовательским интерфейсом” - непроверяем. В определенных случаях, по мнению автора книги, это может выглядеть просто издевкой, даже не являясь изначально таковой – все зависит от точки зрения: например, в устах “целевого” пользователя специализированного программного обеспечения – системного администратора, привыкшего работать в kshell (популярной командной оболочке Unix/Linux), объясняющего свои потребности аналитику, фиксирующему запросы пользователя и привыкшего оперировать Microsoft Office ;) Может ли такое требование быть переформулировано и/или детализировано для адекватности интерпретации? Да. Например, так – средний показатель ошибок оператора не должен превышать 2% от объема вводимой информации и 85% пользователей должны дать положительную оценку прототипу пользовательского интерфейса на этапе опытной эксплуатации. Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с численными величинами – как часто? насколько быстро? в каком количестве? и т.п. Большинство требований с количественной оценкой относится к атрибутам качества. В качестве примера можно привести реальное требование, присутствующее в реальном проекте по электронному документообороту: “Система должна производить поиск документов <определенного вида> за время, не превышающее 5 секунд”. Это типичное требование с количественной оценкой, в котором определена верхняя граница диапазона времени, за которое должен быть осуществлен поиск документов. Несомненно, этот атрибут качества системы существует в контексте определенного функционального требования о возможности поиска документов по определенным критериям. И этот контекст или связь должна быть определена либо явно, в рамках иерархии требований, либо посредством трассировки, между требованиями разных видов (функционального и атрибута качества). Примечательно, что Вигерс в своей книге выделяет требования по производительности системы в отдельный вид требований, тем не менее входящих в понятие нефункциональных требований или атрибутов качества. 6.1.4. Системные требования и программные требования Системные требования и программные требования (System Requirements and Software Requirements) – данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов <созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”; таким образом, подразумевается, что система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности. Часто в литературе по управлению требованиями встречается описание системных требований как “пользовательских требований” (user requirements), SWEBOK ограничивает применение понятия “пользовательское требование” требованиями к системе конечных пользователей/заказчиков. Системные требования по SWEBOK, в свою очередь, окружают пользовательские требования (или требования других заинтересованных лиц – stakeholders, например, регулирование полномочий) без указания идентифицируемого источника-человека. 6.1.5. Характеристики программных требований Перечислим основные характеристики программных требований: Недвусмысленность Должен существовать только один путь интерпретации требования. Иногда двусмысленность проявляется в виде неопределенных акронимов. Пример: Треб.1: Система не должна принимать пароли более 15-ти символов. Не совсем ясно, что система должна делать: • Система не должна позволять пользователю вводить более чем 15 символов. • Система должна отсекать введенную строку до 15-ти символов. • Система не должна отображать сообщение об ошибке, если пользователь вводит более чем 15 символов. Исправленное требование содержит пояснение: Треб.1: Система не должна принимать пароли более 15-ти символов. Если пользователь вводит более 15-ти символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля. Тестируемость (Возможность Проверки) Тестеры должны иметь возможность проверить, было ли требование реализовано корректно. Тестирование должно быть либо пройдено, либо нет. Чтобы быть пригодным для тестирования, требование должно быть ясным, точным и недвусмысленным. Использование некоторых слов может сделать требование невозможным для тестирования: • Некоторые прилагательные: устойчивый, безопасный, точный, эффективный, целесообразный, гибкий, настраиваемый, надежный, дружелюбный, адекватный. • Некоторые наречия и фразы с ними: быстро, безопасно, своевременно. • Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined). Треб.1: Система должна препятствовать одновременному доступу большого числа пользователей. Какое количество здесь имеется в виду под «большим числом» - 10, 100 или 1000? Ясность (Краткость, Сжатость, Простота, Точность) Требования не должны содержать ненужных выражений или информации. Они должны быть изложены кратко и просто: Треб.1: Иногда пользователь будет вводить Airport Code (Код Аэропорта), который система будет распознавать. Но иногда код можно заменить близлежащим городом, и тогда пользователю не нужно знать код аэропорта, т.к. система будет понимать название города. Это предложение может быть заменено на более простое: Треб.1: Система должна идентифицировать аэропорт на основании Airport Code (Кода Аэропорта) или City Name (Названия Города). Корректность Если требование содержит факты, эти факты должны быть достоверны: Треб.1: Цены на аренду машин должны включать все соответствующие налоги (включая налог штата - 6%) Налог зависит от штата, так что представленная цифра в 6 % - некорректна. Понятность Требования должны быть грамматически правильные, написаны в соответствующем стиле. Должны быть использованы стандартные соглашения. Слово «должен» должно быть использовано вместо «будет», «обязан» или «может». Реалистичность (Правдоподобность, Выполнимость) Требование должно быть выполнимо в рамках существующих ограничений, таких как время, деньги и доступные ресурсы. Треб.1: Система должна иметь интерфейс на естественном языке, который будет понимать команды на английском языке. Это требование может быть нереальным из-за короткого периода времени разработки. Независимость Чтобы понять требование, не нужно знать какое-либо другое требование. Треб.1: Список доступных рейсов должен включать номер рейса, время отправления и время прибытия для каждого отрезка пути. Треб.2: Он должен быть отсортирован по ценам. Слово «Он» во втором предложении относится к предыдущему требованию. И если порядок требований изменить, это требование будет непонятно. Элементарность Требование должно содержать отдельный трассируемый элемент (для которого возможно отслеживание связи): Треб.1: Система должна предоставлять возможность бронировать рейс, покупать билет, бронировать номер в гостинице, бронировать машину, а также предоставлять информацию о развлечениях. Это требование содержит пять элементарных требований, которые затрудняют трассировку. Предложения, включающие предлоги «и» или «но» должны быть пересмотрены на предмет разделениях их на элементарные требования. Необходимость В требовании нет необходимости, если: • ни одному заинтересованному лицу требование не нужно; • удаление требования не повлияет на систему. Пример требования, которое может быть удалено, т.к. оно не предоставляет никакой новой информации: Треб.1: Все требования, указанные в документе Концепции должны быть реализованы и протестированы. Независимость от Реализации (Абстрактность) Требования не должны содержать ненужной информации о дизайне и реализации системы: Треб.1: Информация должна храниться в текстовом файле. Решение того, каким образом информация будет храниться, и затем передаваться пользователю, должно приниматься дизайнерами или архитекторами системы. Постоянство Не должно существовать конфликтов между требованиями. Конфликты могут быть прямые и косвенные. Прямые конфликты возникают, когда ожидается различное поведение системы в одной и той же ситуации: Треб.1: Дата должна отображаться в формате мм/дд/гггг. Треб.1: Дата должна отображаться в формате дд/мм/гггг. Иногда возможно разрешить конфликт путем анализа условий, которые явились источником данных требований. Например, если Треб.1 поступило от американского пользователя, а Треб.2 от французского, то предыдущие требования могут быть переписаны следующим образом: Треб.1: Для пользователей США дата должна отображаться в формате мм/дд/гггг. Треб.2: Для пользователей Франции дата должна отображаться в формате дд/мм/гггг. Немногословность Каждое требование должно быть обозначено только один раз, и не должно перекрываться другим требованием: Треб.1: Для удобства ввода даты рейса в системе должен быть доступен календарь. Треб.2: Система должна отображать всплывающее окно с календарем при вводе любой даты. Первое требование (относящееся только к дате рейса) является частью второго требования (относящееся к любой дате, вводимой пользователем). Завершенность Требование должно быть описано для всех возможных условий. Хорошее требование должно удовлетворять как можно большему количеству критериев. Однако они могут быть выражены в виде комбинации вышеперечисленных критериев. 6.1.5.1 Пирамида требований В зависимости от формата, источника и общих характеристик, требования могут быть разделены на различные типы. Несколько типов требований, наиболее часто использующихся в проектах: • потребности заинтересованного лица: требование от заинтересованного лица; • функциональная особенность: предоставляемая системой функциональность, обычно формулируемая бизнес-аналитиком; назначение особенности – удовлетворить потребности заказчика; • сценарий Использования (Use Case): описание поведения системы в терминах последовательности действий; • дополнительное требование: другое требование (обычно нефункциональное), которое не может быть охвачено сценариями использования; • тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов; • сценарий (Алгоритм, Scenario): особая последовательность действий; определенный путь по сценариям использования. Эти типы требований могут быть представлены в виде пирамиды, как показано на Рисунке 1.1. На верхнем уровне располагаются потребности заинтересованного лица. На последующих уровнях находятся функциональные особенности, сценарии использования и дополнительные требования. Достаточно часто на разных уровнях этих требований могут быть выяснены детали различного уровня. Чем ниже уровень, тем более детально описывается требование. Например, потребность может быть следующей: «Данные должны быть неизменными». Функциональная особенность этого требования будет: «Система должна использовать реляционную базу данных». На уровне дополнительных требований, требование еще более точное: «Система должна использовать базу данных Oracle 9i». Чем дальше вниз, тем более детальным становится требование. Один из лучших способов управления требованиями – обобщать требования, по крайней мере, на двух различных уровнях. Например, документ Концепция («Vision») содержит высокоуровневые требования (особенности), а низшие уровни пирамиды представляют требования на более детальном уровне. У вышестоящих заинтересованных лиц (таких, как вице-президент) нет времени читать 200 страниц детально описанных требований. Но можно надеяться, что они смогут прочитать 12 страниц Концепции. Рисунок. Пирамида требований. Главное отличие между потребностями и функциональными особенностями – в источнике требований. Потребности поступают от заинтересованных лиц, а функциональные особенности формулируются бизнес-аналитиками. Роль тестовых сценариев – проверить, корректно ли были реализованы сценарии использования и дополнительные требования. Алгоритмы помогают получить сценарии использования из тестовых сценариев, а также способствуют проектированию и реализации определенных путей через сценарии использования. 7. Управление требованиями 7.1.1. Процесс управления требованиями Самое простое описание процесса управления требованиями содержит следующие основные пункты: • формирование плана управления требованиями; • сбор требований; • разработка документа Концепции (Vision); • создание сценариев использования (Use Cases); • дополнительная спецификация; • создание тестовых сценариев (Test Cases) из сценариев использования (Use Cases); • создание тестовых сценариев (Test Cases) из дополнительной спецификации; • проектирование системы. Первый шаг (план управления требованиями) определяет пирамиду требований. На каждом из последующих семи шагов строится один элемент пирамиды. Таблица 1.1. описывает, какие типы требований и какая документация создаются на каждом шаге. Как Вы видите, процесс проходит через пирамиду сверху вниз и слева направо. Таблица 1.1. Требования и документы, созданные на каждом шаге. Шаг Тип требований Документы Сбор требований Потребности заинтересованного лица Запросы заинтересованного лица Разработка документа Концепции (Vision) Функциональные особенности Концепция Создание сценариев использования (Use cases) Сценарии использования, алгоритмы Спецификация Сценариев Использования Дополнительная спецификация Дополнительные требования Дополнительная спецификация Создание тестовых сценариев (test cases) из сценариев использования (use cases) Тестовые сценарии Тестовые сценарии Создание тестовых сценариев (test cases) из дополнительной спецификации Тестовые сценарии Тестовые сценарии Проектирование системы Диаграммы классов, диаграммы взаимодействий UML-диаграммы Управление требованиями – это интерактивный процесс. На типичной итерации предполагается полное прохождение по пирамиде. На любой итерации мы можем вернуться назад на несколько шагов и повторить действия. Например, в процессе создания тестовых сценариев, мы можем обнаружить, что отсутствует некоторая информация, и нам нужно получить ее от заинтересованного лица. Таким образом, мы возвращаемся на шаг сбора требований. Для обеспечения целостности модели, важно обновлять все соответствующие требования. На начальных итерациях акцент делается на первых нескольких шагах (в вершине пирамиды), а затем, на последующих итерациях, больше времени проводится на низших уровнях пирамиды. 7.1.2. Извлечение требований Идентификация заинтересованных лиц, их взаимодействия, выполняемых ими бизнес-процессов ключевые вопросы, закладывающие основы успеха проекта. Необходимо идентифицировать все возможные источники требований, значимые для решения задач проекта, к которым относят: • цели; • знания предметной области; • заинтересованных лиц; • операционное окружение; • организационную среду. Под заинтересованным лицом понимают личность, на которую оказывает влияние разрабатываемая система. Два главных типа заинтересованных лиц – это пользователи и заказчики. Пользователи – это лица, которые будут пользоваться системой. Заказчики – лица, кто заказывает систему и отвечает в дальнейшем за приемку системы. Обычно заказчики платят за разработку системы. Кроме заказчиков и пользователей, есть и другие типы заинтересованных лиц. В качестве заинтересованного лица можно рассматривать: • участников разработки системы (бизнес-аналитики, дизайнеры, кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению, дизайнеры сценариев использования, графические дизайнеры); • поставщиков знаний в систему (эксперты предметной области, авторы документов, которые были использованы для сбора требований, собственники веб-сайтов, ссылки на которые были предоставлены); • руководство (президент компании, которого представляют заказчики, директор отдела информационных технологий компании, проектирующей и разрабатывающей систему); • обслуживающий персонал, вовлеченный в управление, настройку и сопровождение системы (хостинговая компания, справочная служба). • поставщики стандартов и регламентов (стандарты устанавливаются поисковыми механизмами согласно содержанию веб-сайта, политическим нормам, а также порядку налогообложения в конкретном штате). После идентификации источников требований, производится сбор требований, являющийся, сложным и конфликтным процессом извлечения информации из источников. Выделяют следующие причины, которые приводят к дальнейшим ошибкам и потерям на качестве ПС: • недопонимание между аналитиком и заинтересованными лицами; • упущение некоторых аспектов, изначально кажущихся второстепенными; • неоднозначность или некорректность интерпретации информации, полученной от заинтересованных лиц. Существует множество практик и подходов, позволяющих добиться действительно стройной системы требований, отвечающих реальным потребностям и приоритетам заказчиков: • интервьюрирование – традиционный подход извлечения требований посредствам опроса экспертов, в роли которых выступают пользователи или другие заинтересованные лица; • использование сценариев – моделирование ситуаций для сбора пользовательских требований, определяющих ответы на вопросы «что если» и «как это делается» в отношении бизнес-процессов, реализуемых пользователями; • создание прототипов – инструмент для постепенного перехода от «бумажных» моделей до пилотных подсистем, реализуемых как самостоятельные проекты или бета-версий продуктов, при этом прототипы могут постепенно трансформироваться в результаты проекта и использоваться для проверки и утверждения требований; • разъясняющие встречи – мероприятия, в ходе которых заинтересованные лиц совместно с аналитиками ищут пути решения проблем, определения и предупреждения рисков и т.п.; • наблюдение – непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов; Существуют и другие, достаточно эффективные практики, описание которых можно найти в литературе и которые вы, наверняка, сами используете в своей работе. 7.1.3. Анализ программных требований При анализе требований происходит трансформация информации, полученной от заинтересованных лиц в четко и однозначно определенные требования, передаваемые инженерам для реализации в программном коде. Анализ требований включает: • обнаружение и разрешение конфликтов между требованиями; • определение границ задачи, решаемой создаваемым программным обеспечением; • детализация системных требований для установления программных требований. Вне зависимости от выразительных средств, которые являются лишь инструментом анализа и фиксирования результатов, результатом анализа требований должны быть однозначно интерпретируемые требований, реализация которых проверяема, а стоимость и ресурсы – предсказуемы. Требования могут классифицироваться по следующим параметрам: • функциональные и нефункциональные требования; • внутренние (с другими требованиями) или внешние зависимости; • требования к процессу или продукту; • приоритет требований; • содержание требований в отношении конкретных подсистем создаваемого программного обеспечения; • изменяемость/стабильность требований. Разработка модели проблемы реального мира (концептуальное моделирование) – ключевой элемент анализа требований. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы. Объем моделей, их детализация и средства представления могут быть различны. Их выбор диктуется предпочтениями и компетенциями организаций, вовлеченных в проект. Среди факторов, которые влияют на выбор модели, метода и детализации её представления, степени связанности с программным кодом и другими вопросами: • природа проблемы (проблемной области); • экспертиза и опыт инженеров; • требования заказчика к процессу; • доступность методов и инструментов; • внутрикорпоративные стандарты и регламенты; • культура разработки. Вопросы моделирования тесно связаны с применяемыми методами и подходами. Поэтому, частные методы или нотации, обычно следуют распространенным в индустрии практикам и тяготеют к тем формам, с которыми связаны накопленный опыт и подтвержденные общепринятой практикой знания. Архитектурное проектирование очень близко к концептуальному моделированию. Непосредственное отображение бизнес-сущностей реального мира на программные компоненты не является обязательным, поэтому и существует такое разделение между моделированием и проектированием. Деятельность по моделированию определяет порядок проектирования (то, «что» надо сделать), а архитектура – процедуры («как» это будет реализовано). 7.1.4. Документирование требований Для сложных систем существует целый комплекс документов (спецификаций), которые являются результатом сбора и анализа требований, их моделирования и архитектурного проектирования. Управление этими документами требует их анализа, изменения, пересмотра и утверждения. Обычно для описания требований в комплексных проектах используется три основных документа (спецификации): • определение системы; • системные требования; • программные требования. 7.1.5. Проверка требований (верификация и аттестация) Определение требований напрямую связано с процедурами проверки и утверждения (аттестации или валидации)). Без этих процедур требования считаются не полностью описанными, поскольку определены способы их проверки (при верификации) и утверждения (при аттестации). Если стандарты жизненного цикла описывают как правильно создавать продукт, то стандарты (в том числе, внутрикорпоративные) отвечают за создание правильного продукта, то есть того продукта, который соответствует ожиданиям пользователей и других заинтересованных лиц. Для достижения этой цели применяются следующие методы: Обзор требований Один из распространенных методов проверки требований - инспекция или обзор требований. Суть его заключается в том, что ряд лиц, вовлеченных в проект (для крупных проектов – специально выделенные специалисты), “вычитывают” требования в поисках необоснованных предположений, описаний требований, допускающих множественные интерпретации, противоречий, несогласованности, недостаточной степени детализации, отклонений от принятых стандартов и т.п. Прототипирование В общем случае, прототипирование подразумевает проверку инженерной интерпретации программных требований и извлечение новых требований, неопределенных или неясных на ранних итерациях сбора требований. Существует множество подходов к прототипированию, как с точки зрения детализации, так и того, чему уделяется внимание при прототипировании. Наиболее часто прототипы создаются для оценки способа реализации пользовательского интерфейса и проверки архитектурных подходов и решений. При всей безусловной полезности прототипирования для обеспечения проверки требований и решений, необходимо понимать, что с прототипированием связан ряд вопросов способных привести к негативным последствиям или, как минимум, работам, требующим дополнительного времени и средств. Среди возможных негативных последствий прототипирования стоит выделить следующие: • смещение внимания с целевых функций прототипа и, как следствие, неудовлетворенность пользователей огрехами прототипа, отсутствием стоящей за ним реальной функциональности (для прототипов пользовательского интерфейса), ошибками в прототипе и т.п.; • превращение прототипа в реальную систему за счет постоянного добавления новых свойств и функциональности “для проверки” – часто бывает нарушена архитектурная целостность, необеспеченная необходимая масштабируемость и качество получаемого программного продукта; • переключение внимания заинтересованных лиц на эргономику и детали дизайна графического пользовательского интерфейса с начальной цели выявления функциональных и иных требований. Аттестация Аттестация модели связана с вопросами обеспечения приемлемого качества продукта. Уверенность в соответствии модели заданным требованиям может быть закреплена формально со стороны пользователей/заказчика. В то же время, проверка и аттестация модели, например, объектно-ориентированного представления бизнес-сущностей и связей между ними может быть проведена с той или иной степенью использования формальных методов. Это – другая сторона утверждения модели. Приемочные тесты Требования должны быть верифицируемы. Требования, которые не могут быть проверены и аттестованы, могут выступать только в форме рекомендаций, даже если они очень важны для пользователей. Если описанное требование не сопровождается процедурами проверки – в большинстве случаев говорят о недостаточной детализации или неполном описании требования и, соответственно, спецификация требований должна быть отправлена на доработку и если необходимо, должны быть предприняты дополнительные усилия, направленные на сбор требований. Можно говорить о том, что процедура анализа требований считается выполненной только тогда, когда все требования, включенные в спецификацию, обладают методами оценки соответствия им создаваемого программного продукта. Чаще всего столь строгое ограничение на степень законченности спецификации накладывается на функциональные требования и атрибуты качества (например, время отклика системы). Идентификация и разработка приемочных тестов для нефункциональных требований часто оказывается наиболее трудоемкой задачей. Для ее решения обычно “ищут точку опоры”, то есть возможность взгляда на описываемые требования с количественной точки зрения, в плоть до переформулирования и большей степени детализации описания таких требований. 7.1.6. Измерение программных требований Для обеспечения качества программных требований полезно иметь методы, определяющие «объем» требований для создаваемого программного продукта. Такая оценка полезна для исследования предполагаемых изменений в требованиях, оценки стоимостных характеристик разработки и поддержки программной системы, опосредовано – оценки продуктивности разработки и эффективности поддержки на этапах реализации требований и внесения изменений и т.п. [Error: Reference source not found] 8. Проектирование программных средств Проектирование в основном рассматривается как двух-шаговый процесс [Error: Reference source not found]: • Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент; • Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент. Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде. 8.1. Принципы проектирования В качестве основных принципов проектирования выделим следующие: Абстракция Абстракция – отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения [википедия]. Абстракция – модель, упрощающая поставленную проблему до рамок, значимых для заданного контекста [Error: Reference source not found]. В контексте проектирования программных систем существует два механизма абстракции – параметризация и детализация. При этом, абстракция через детализацию может быть: процедурной (связанной с поведением), абстракцией данных (связанной с информацией) и абстракцией контроля (связанной с управлением системой и обрабатываемой ею информацией). Связанность и соединение Связанность – определяет силу взаимосвязи между модулями. Соединение – определяет взаимосвязь элементов внутри модуля, внутренние связи.  Декомпозиция и разбиение на модули Декомпозиция и разбиение на модули сложных программных систем производится с целью получения более мелких и относительно независимых программных компонентов, каждый из которых несет различную функциональность. Инкапсуляция  Предполагает группировку и упаковку элементов и внутренних деталей абстракции в отношении реализации с тем, чтобы эти детали были недоступны пользователям элементов. В качестве «пользователя» одного компонента может выступать другой компонент. Более того, при использовании объектно-ориентированного подхода, наследники компонентов могут не иметь доступа ко внутренним деталям реализации компонента, который является их предком. Разделение интерфейса и реализации Данная техника предполагает отделение компонента через специфицирование интерфейса, известного и доступного клиентам (или другим компонентам), от непосредственных деталей реализации. Достаточность, полнота и простота Создаваемые программные компоненты должны обладать всеми необходимыми характеристиками, определенными абстракцией (моделью), но не должны включать функциональность, отсутствующую в модели. 8.2. Структура и архитектура программного обеспечения Архитектура программного обеспечения (англ. software architecture) – это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними [википедия]. Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований. Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц. Примеры видов: • Функциональный/логический вид • Вид код/модуль • Вид разработки (development)/структурный • Вид параллельности выполнения/процесс/поток • Физический вид/вид развертывания • Вид с точки зрения действий пользователя • Вид с точки зрения данных На сегодняшний день сформировался взгляд на архитектуру, как на приложение общих принципов организации программных компонент, что привело к накоплению множества подходов и созданию различных архитектурных «фреймворков», то есть систематизированных комплексов методов, практик и инструментов, призванных формализовать имеющийся в индустрии опыт. Фреймворк (англ. framework — каркас, структура) – структура программной системы или программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. В отличие от библиотек, которые объединяют набор подпрограмм близкой функциональности, фреймворк содержит в себе большое количество разных по назначению библиотек. Некоторые авторы используют слово «каркас» в качестве основного. С их точки зрения можно говорить о каркасном подходе как о подходе к построению программ, где любая конфигурация программы строится из двух частей: первая, постоянная часть – каркас, не меняющийся от конфигурации к конфигурации и несущая в себе гнезда, в которых размещается вторая, переменная часть – сменные модули (или точки расширения) [википедия]. Фреймворк реализуется как множество конкретных и абстрактных классов, а также определений способов их взаимоотношения. Конкретные классы обычно реализуют взаимные отношения между классами. Абстрактные классы представляют собой точки расширения, в которых каркасы могут быть использованы или адаптированы. Точка расширения — это та часть фреймворка, для которого не приведена реализация. Соответственно каркас концептуальной модели состоит из концептуальных классов, а каркас программной системы из классов языка программирования общего назначения. Процесс создания фреймворка заключается в выборе подмножества задач проблемы и их реализаций. В ходе реализаций общие средства решения задач заключаются в конкретных классах, а изменяемые средства выносятся в точки расширения. Примеры такой систематизации в форме фреймворков: TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент первичного написания данной главы доступен в версии 8.1, впервые опубликованной в декабре 2003 года; в 2009 году вышла версия TOGAF 9) Модель Захмана – Zachman Framework [Error: Reference source not found]. Руководство по архитектуре электронного правительства E-Gov Enterprise Architecture Guidance [E-Gov, 2002] 8.2.1.1 Архитектурные структуры и точки зрения Принцип сужения предметной области с использованием точки зрения [пособие по ТССА] широко используется в программной инженерии. Система может рассматриваться с разных точек зрения – поведенческой, структурной, логической, физической и т.п. Следовательно, можно получить множество различных архитектурных представлений. Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы. Дизайн системы – комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения требований, предъявляемых к системе. Архитектурная структура – применение архитектурной точки зрения и представления к конкретной системе и описания тех деталей, которые необходимы для реализации системы, но отсутствуют в используемом представлении. Таким образом, представление, концентрируясь на заданном подмножестве свойств является составной частью и/или результатом точки зрения, а архитектурная структура – дальнейшей детализацией в отношении проектируемой системы [Error: Reference source not found]. В качестве примера архитектурных точек зрения можно рассматривать модель Захмана [Error: Reference source not found]. 8.2.1.2 Архитектурные стили Архитектурный стиль – это мета-модель или шаблон проектирования макро-архитектуры – на уровне модулей, «крупноблочного» взгляда. Архитектурный стиль – набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям [Error: Reference source not found]. 8.2.1.3 Шаблоны проектирования Архитектурный стиль определяет макро-архитектуру системы, а шаблоны проектирования задают микро-архитектуру, то есть определяют частные аспекты деталей архитектуры. Чаще всего говорят о следующих группах шаблонов проектирования: • Шаблоны создания (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 8.2.1.4 Семейства программ и фреймворков Один из возможных подходов к повторному использованию архитектурных решений и компонент заключается в формировании линий продуктов на основе общего дизайна. В объектно-ориентированном программировании аналогичную смысловую нагрузку несут «фреймворки», обеспечивающие решение одних и тех же задач – например, внутренней организации компонентов пользовательского интерфейса или общей логики работы распределенных систем [Error: Reference source not found]. 8.3. Анализ качества и оценка программного дизайна 8.3.1.1 Атрибуты качества Атрибуты для оценки качественного дизайна ПС можно разбить на следующие группы: • применимые во время выполнения системы, например, среднее время отклика системы; • используемые в режиме разработки, например, среднее количество методов в классе, среднее количество свойств объекта и т.д.; • атрибуты качества архитектурного дизайна, например, концептуальная целостность дизайна, непротиворечивость, полнота, завершенность. Существуют атрибуты, которые сложно измерить, например, такой как безопасность. Не стоит путать атрибуты качества дизайна с атрибутами качества, фигурирующими в ряду требований, предъявляемых к системе. Часть из них может отображаться друг на друга и нести эквивалентную смысловую нагрузку, некоторые могут быть связаны, большая часть атрибутов является специфичной именно для дизайна и не связана с требованиями [Error: Reference source not found]. 8.3.1.2 Анализ качества и техники оценки Известно немало различных инструментов и методов, предназначенных для формирования качественного дизайна ПС: • обзор дизайна, например, неформальный обзор архитектуры членами проектной команды; • статический анализ, например, трассировка с требованиями; • симуляция и прототипирование – динамические техники проверки дизайна в целом или отдельных его атрибутов качества; например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым [Error: Reference source not found]. 8.3.1.3 Измерения Измерения используются для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, сложности структуры ПС или качества требований, предъявляемых к производительности. Обычно метрики разделяют на 2 класса: • функционально-ориентированные; • объектно-ориентированные [Error: Reference source not found]. 8.4. Нотации проектирования Нотация – система условных обозначений, принятая в какой-либо области знаний или деятельности. Нотация включает множество символов используемых для представления понятий и их взаимоотношений, составляющее алфавит нотации, а также правила их применения [википедия]. Следовательно, нотация – соглашение о представлении некоторой абстракции в визуальной (графической) форме. Нотация может задаваться: • стандартом; • общепринятой практикой; • внутренним методом проектной команды. Определенные нотации используются на стадии концептуального проектирования, ряд нотаций ориентирован на создание детального дизайна, многие могут использоваться на обеих стадиях. Кроме того, нотации чаще всего используют в контексте применяемой методологии или подхода [Error: Reference source not found]. 8.4.1.1 Структурные описания Следующие нотации, в основном, являются графическими, описывая и представляя структурные аспекты программного дизайна: • языки описания архитектуры, такие как текстовые языки, обычно используемые для описания программной архитектуры в терминах компонентов; • диаграммы классов и объектов, применяемые для представления набора классов и связей между ними (например, наследования); • диаграммы компонентов используемые для представления набора компонентов и связей между ними с учётом того, что компонент в отличие от класса является реализуемым элементом; • карточки функциональности и связей класса, используемые для обозначения имени класса, его функции и связей с другими сущностями (классами, компонентами и т.п.); • диаграммы развёртывания, применяемые для представления физических узлов, связей между ними и моделирования других физических аспектов системы; • диаграммы сущность-связь, служащие для представления информационной модели или концептуальной модели данных, хранимых в ходе работы информационной системы; • языки описания (определения) интерфейса, предназначенные для определения интерфейсов программных компонентов (имён и типов экспортируемых или публикуемых операций); • структурные диаграммы Джексона, описывающие структуры данных в терминах последовательности, выбора и итераций (повторений); • структурные схемы, применяемые для описания структуры вызовов в программах [Error: Reference source not found]. 8.4.1.2 Поведенческие (динамические) описания Рассмотрим нотации и языки, используемые для описания динамического поведения программных систем и их компонентов: • диаграммы деятельности или операций, применяемые для описания потоков работ и управления; • диаграммы сотрудничества, демонстрирующие динамическое взаимодействие, осуществляемое в группе объектов и концентрирующиеся на объектах, связях между ними и сообщениях, которыми обмениваются объекты посредством этих  связей; • диаграммы потоков данных, описывающие потоки данных внутри набора процессов; • таблицы и диаграммы принятия решений, используемые для представления сложных комбинаций условий и действий (операций); • схемы алгоритмов и структурированные схемы алгоритмов, служащие для представления потоков управления (контроля) и связанных операций; • диаграммы последовательности, демонстрирующие взаимодействие внутри группы объектов по времени; • диаграммы перехода и карты состояний, применяемые для описания потоков управления переходами между состояниями; • формальные языки спецификации или текстовые языки, использующие основные понятия из математики для строгого и абстрактного определения интерфейсов и поведения программных компонентов; • псевдокод и программные языки проектирования, описывающие поведение процедур и методов, в основном на стадии детального проектирования [Error: Reference source not found]. 9. Подходы и методы проектирования программного обеспечения Различают подходы и методы проектирования ПС. Подходы к программированию определяют стратегию работ по проектированию. В отличие от подходов, методы проектирования более специфичны, предлагая и предоставляя нотации для использования совместно с этими методами, а также процессы, которым необходимо следовать в рамках используемого метода. Таким образом, методы выступают как более общие понятия, это – методологии, сконцентрированные на процессе и предполагающие следование определенным правилам и соглашениям, в том числе – по используемым выразительным средствам. Такие методы полезны как инструмент систематизации (иногда, формализации) и передачи знаний в виде общего фреймворка не только для отдельных специалистов, но для команд и проектных групп программных проектов. 9.1.1.1 Общие подходы Наиболее часто используются следующие общепринятые подходы: • метод пошаговой декомпозиции; • нисходящий и восходящий подход к проектированию; • абстракция и инкапсуляция; • итеративный и инкрементальный подход. Метод пошаговой декомпозиции Структурный подход требует представления задачи в виде иерархии подзадач простейшей структуры. Для получения такой иерархии применяется метод пошаговой детализации, который заключается в следующем: • определяется общая структура программы в виде одного из трех вариантов: • последовательности подзадач (например, ввод данных, преобразование данных, вывод данных), • альтернативы подзадач (например, добавление записей к файлу или их поиск), • повторения подзадачи (например, циклически повторяемая обработка данных); • каждая подзадача, в свою очередь, разбивается на подзадачи с использованием тех же структур; • процесс продолжается, пока на очередном уровне не получается подзадача, которая достаточно просто реализуется средствами используемого языка (1 - 2 управляющих оператора языка). Нисходящий и восходящий подход к проектированию Нисходящим методом проектирование программы ведется от общего к ча­стному, ко все большей детализации на каждом этапе. При этом сначала оп­ределяется задача в целом, в виде последовательности этапов, реализующих самостоятельные смысловые части алгоритма. Затем она поэтапно детализи­руется. Процесс детализации алгоритма продолжается до тех пор, пока реа­лизуемые части алгоритма не станут достаточно простыми и легко програм­мируемыми. Результатом этого процесса может быть структура программы. Это направленный граф, определяющий взаимосвязи подпрограмм в виде бло­ков подпрограмм и их вызовов. На последнем этапе каждый модуль представ­ляется в виде детального описания его функций, например с помощью схемы алгоритма. Схема алгоритма – это направленный граф, который определяет процесс обработки данных. Альтернативным методом по отношению к методу нисходящего проектиро­вания является метод восходящего проектирования. При этом вначале разра­батываются модули низшего уровня, а затем они объединяются с помощью модулей более высокого уровня. Сложные программные системы восходящим методом создавать значительно труднее и дольше, чем нисходящим. На прак­тике часто используют смешанный метод, т. е. в основном используют метод нисходящего проектирования, а в некоторых случаях, по мере необходимос­ти, – восходящее проектирование. Абстракция и инкапсуляция Абстракция – это придание объекту характеристик, которые четко определяют его концептуальные границы, отличая от всех других объектов. Основная идея состоит в том, чтобы отделить способ использования составных объектов данных от деталей их реализации (инкапсуляция) в виде более простых объектов, подобно тому, как функциональная абстракция разделяет способ использования функции и деталей её реализации в терминах более примитивных функций, таким образом, данные обрабатываются функцией высокого уровня с помощью вызова функций низкого уровня [Error: Reference source not found]. Инкапсуляция – свойство языка программирования, позволяющее пользователю не задумываться о сложности реализации используемого программного компонента, а взаимодействовать с ним посредством предоставляемого интерфейса, а также объединить и защитить жизненно важные для компонента данные. При этом пользователю предоставляется только интерфейс — спецификация объекта. Итеративный и инкрементальный подход Итеративный подход – выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle). Преимущества итеративного подхода: • снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение; • организация эффективной обратной связи проектной команды с потребителем (а также заказчиками, стейкхолдерами) и создание продукта, реально отвечающего его потребностям; • акцент усилий на наиболее важные и критичные направления проекта; • непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом; • раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта; • более равномерная загрузка участников проекта; • эффективное использование накопленного опыта; • реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении. • затраты распределяются по всему проекту, а не группируются в его конце [Error: Reference source not found]. 9.1.1.2 Функционально-ориентированное (структурное) проектирование Классический метод проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций “сверху-вниз”. Структурное проектирование, обычно, используется после проведения системного анализа с применением диаграмм потоков данных, функциональных моделей и схем алгоритмов. 9.1.1.3 Объектно-ориентированное проектирование Представляет собой совокупность методов проектирования, базирующихся на концепции объектов. Главную роль в ООП играют полиморфизм и инкапсуляция, наследование и абстракция. 9.1.1.4 Проектирование на основе структур данных В данном подходе фокус сконцентрирован в большей степени на структурах данных, которыми управляет система, чем на функциях системы. Инженеры по программному обеспечению часто вначале описывают структуры данных входов и выходов, а, затем, разрабатывают структуру управления этими данными (или, например, их трансформации). 9.1.1.5 Компонентное проектирование Данный подход призван решить задачи использования, разработки и интеграции программных компонент с целью повышения повторного использования активов. Компонентно-ориентированное проектирование является одной из наиболее динамично развивающихся концепций проектирования. 9.1.2. Гибкие методы разработки Гибкие методы разработки ПО появились в 90-е годы 20-го века в качестве альтернативы формальным методологиям, перегруженных значительным объёмом документирования и проверок, которые зачастую, особенно небольших коммерческих проектах, неэффективны. Основными положениями гибких методов являются следующее: • индивидуальные методы и взаимодействие вместо процессов и программных средств; • работающее ПО вместо сложной документации; • взаимодействие с заказчиком вместо жестких контрактов; • реакция на изменения вместо следования плану. Гибкие методологии предполагают создание небольших, самоорганизующихся команд, состоящих из высококвалифицированных и энергичных людей, ориентированных на бизнес. Экстремальное программирование Самым известным гибким методом является экстремальное программирование (Extreme Programming или сокращенное название – XP), созданный специалистом в области программной инженерии Кентом Беком в результате его работы в 1996-1999 годах над системой контроля платежей компании "Крайслер". Модель процесса по XP выглядит как частая последовательность выпусков продукта, столь частых, сколь это возможно. Но при этом обязательно, чтобы в выпуск входила новая функциональность. Основные принципы организации процесса по XP: • планирование, основанное на принципе, что разработка ПО является диалогом между возможностями и желаниями, при этом изменятся и то и другое; • простой дизайн – против избыточного проектирования; • метафора – суть проекта должна умещаться в 1-2 емких фразах или в некотором образе; • рефакторинг – процесс постоянного улучшения (упрощения) структуры ПО, необходимый в связи с добавлением новой функциональности; • парное программирование – один программирует, другой думает над подходом в целом, о новых тестах, об упрощении структуры программы и т.д.; • коллективное владение кодом – все участники проекта должны уметь писать код; • участие заказчика в разработке – представитель заказчика входит в команду разработчика; • создание и использование стандартов кодирования в проекте – при написании кода используются стандарты на имена идентификаторов, составление комментариев и т.д.; • тестирование – разработчики сами тестируют свое ПО, перемежая этот процесс с разработкой (при этом рекомендуется создавать тесты до того, как будет реализована соответствующая функциональность с привлечением заказчика); • непрерывная интеграция – разработка представляется как последовательность выпусков; • 40-часовая рабочая неделя. Однако в полном объеме XP не была использована даже ее авторами. Кроме того, известны и внедряются отдельные практики XP, как, например, парное программирование, коллективное владение кодом, рефакторинг кода. Однако идея простого, неизбыточного дизайна проекта также оказала значительное влияние на мир разработчиков ПО. Более практичным гибким методом разработки является Scrum. Метод схватки или Scrum В 1986 японские специалисты Hirotaka Takeuchi и Ikujiro Nonaka опубликовали сообщение о новом подходе к разработке новых сервисов и продуктов (не обязательно программных). Основу подхода составляла сплоченная работа небольшой универсальной команды, которая разрабатывает проект на всех фазах. Приводилась аналогия из регби, где вся команда двигается к воротам противника как единое целое, передавая (пасуя) мяч своим игрокам как вперед, так и назад. В начале 90-х годов данный подход стал применяться в программной индустрии и обрел название Scrum (термин из регби, означающий – схватка), в 1995 году Jeff Sutherland и Ken Schwaber представили описание этого подхода на OOPSLA '95 – одной из самых авторитетных конференций в области программирования. С тех пор метод активно используется в индустрии и многократно описан в литературе. Scrum активно используется также в России. Общее описание. Метод Scrum позволяет гибко разрабатывать проекты небольшими командами (7 человек плюс/минус 2) в ситуации изменяющихся требований. При этом процесс разработки итеративен и предоставляет большую свободу команде. Кроме того, метод очень прост – легко изучается и применяется на практике. Его схема изображена на рисунке. Рис. 11.1. Вначале создаются требования ко всему продукту. Потом из них выбираются самые актуальные и создается план на следующую итерацию. В течение итерации планы не меняются (этим достигается относительная стабильность разработки), а сама итерация длится 2-4 недели. Она заканчивается созданием работоспособной версии продукта (рабочий продукт), которую можно предъявить заказчику, запустить и подемонстрировать, пусть и с минимальными функциональными возможностями. После этого результаты обсуждаются и требования к продукту корректируются. Это удобно делать, имея после каждой итерации продукт, который уже можно как-то использовать, показывать и обсуждать. Далее происходит планирование новой итерации и все повторяется. 10. Использование UML в программной инженерии 10.1.1. Основные компоненты UML UML представляет собой методологию или язык визуального моделирования, разработанный для описания, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. UML является простым и мощным средством моделирования, используемым для построения концептуальных, логических и графических моделей сложных систем различного назначения. Язык вобрал в себя наилучшие подходы программной инженерии. Использование UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования, таких как абстригирование, принцип неполноты модели и принцип её иерархического построения. Рис. 3.1. Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования Основные задачи, решаемые с помощью UML: 1. Реализация функционала языка визуального моделирования, предназначенного для разработки и документирования моделей сложных систем. Благодаря чему системный анализ прочно вошёл в практику проектирования и объектно-ориентированный подход постепенно стал доминирующим в программной инженерии. 2. Обеспечение возможности расширения и специализации UML для повышения качества моделирования систем в предметной области. 3. Независимость UML от конкретных языков программирования и инструментальных средств проектирования программных систем, что означает, что конструкции языка UML не должны зависеть от особенностей их реализации в применяемых языках программирования. 4. Наличие семантического базиса в описании UML для понимания общих особенностей ООП, что означает претензию UML на понимание общих принципов ООП. 5. Обеспечение развития рынка объектно-ориентированных инструментальных средств за счёт популяризации UML и распространение объектно-ориентированных технологий и соответствующих понятий ООАП. 6. Интеграция в UML последних достижений объектно-ориентированных технологий за счёт его дальнейшей интеграции с другими современными технологиями моделирования и методами программной инженерии. Описание UML состоит из двух взаимодействующих частей, таких как: ◦ семантика языка UML, представляющая собой метамодель, которая определяющую синтаксис и семантику понятий объектно-ориентированного моделирования с использованием UML; ◦ нотация языка UML, реализуемую графической нотацией для визуального представления семантики UML. Абстрактный синтаксис и семантика UML описываются с использованием некоторого подмножества нотации. В дополнение к этому, нотация UML описывает соответствие или отображение графической нотации в базовые понятия семантики. Таким образом, с функциональной точки зрения эти две части дополняют друг друга. При этом семантика UML описывается на основе метамодели, имеющей три отдельных представления: абстрактный синтаксис, правила корректного построения выражений и семантику. Рассмотрение семантики языка UML предполагает не полностью формализованный стиль изложения, объединяющий естественный и формальный языки для представления базовых понятий и правил их расширения. Семантика определяется для двух видов объектных моделей: структурных моделей и моделей поведения. Структурные (статические) модели описывают структуру сущностей или компонентов некоторой системы, включая их классы, интерфейсы, атрибуты и отношения. Модели поведения (динамические модели) описывают поведение объектов системы, включая их методы, взаимодействие и связи между ними, а также процесс смены состояний компонентов и системы в целом. Нотация UML включает в себя описание отдельных семантических элементов, которые могут применяться при построении диаграмм. Формальное описание UML основывается на общей иерархической структуре модельных представлений, состоящей из четырех уровней:  • мета-метамодель; • метамодель; • модель; • объекты пользователя. Верхний уровень является основой для всех метамодельных представлений. Назначение уровня состоит в определении языка для спецификации метамодели. Мета-метамодель определяет модель UML на самом высоком уровне абстракции и является наиболее компактным ее описанием. Мета-метамодель может описывать несколько метамоделей. Метамодель является экземпляром мета-метамодели. Главная задача уровня метамодели – определение языка для формирования моделей. Данный уровень обладает более развитой семантикой базовых понятий. Основные понятия UML относятся как раз к уровню метамодели. Примеры таких понятий — класс, атрибут, операция, компонент, ассоциация и многие другие. Модель в контексте UML является экземпляром метамодели в том смысле, что любая конкретная модель системы должна использовать только понятия метамодели, конкретизировав их применительно к данной ситуации. Это уровень для описания информации о конкретной предметной области. Однако если для построения модели используются понятия языка UML, то необходима полная согласованность понятий уровня модели с базовыми понятиями языка UML уровня метамодели. Примерами понятий уровня модели могут служить имена соответствующих информационных атрибутов, например, имена полей проектируемой базы данных, такие как имя и фамилия сотрудника, возраст, должность, адрес, телефон. Конкретизация понятий модели происходит на уровне объектов. Объект является экземпляром модели, поскольку содержит конкретную информацию относительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проектируемой базе данных: "Илья Петров, 30 лет, иллюзионист, ул. Невидимая, 10-20, 100-0000". Метамодель UML является больше логической моделью, чем физической или моделью реализации. Особенность логической модели заключается в том, что она концентрирует внимание на декларативной или концептуальной семантике, опуская детали конкретной физической реализации моделей. При этом отдельные реализации, использующие данную логическую метамодель, должны быть согласованы с ее семантикой, а также поддерживать возможности импорта и экспорта отдельных логических моделей. В то же время, логическая метамодель может быть реализована различными способами для обеспечения требуемого уровня производительности и надежности соответствующих инструментальных средств. В этом заключается недостаток логической модели, которая не содержит на уровне семантики требований, обязательных для ее эффективной последующей реализации. Однако согласованность метамодели с конкретными моделями реализации является обязательной для всех разработчиков программных средств, обеспечивающих поддержку UML. В рамках UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм. В терминах UML определены следующие виды диаграмм: • диаграмма вариантов использования (use case diagram); • диаграмма классов (class diagram); • диаграммы поведения (behavior diagrams); ◦ диаграмма состояний (statechart diagram); ◦ диаграмма деятельности (activity diagram); ◦ диаграммы взаимодействия (interaction diagrams); ▪ диаграмма последовательности (sequence diagram); ▪ диаграмма кооперации (collaboration diagram); • диаграммы реализации (implementation diagrams); ◦ диаграмма компонентов (component diagram); ◦ Диаграмма развертывания (deployment diagram). Из перечисленных выше диаграмм некоторые служат для обозначения двух и более других подвидов диаграмм. При этом в качестве самостоятельных представлений в языке UML используются следующие диаграммы: • диаграмма вариантов использования; • диаграмма классов; • диаграмма состояний; • диаграмма деятельности; • диаграмма последовательности; • диаграмма кооперации; • диаграмма компонентов; • диаграмма развертывания. Перечень этих диаграмм и их названия представляют собой неотъемлемую часть графической нотации языка UML. Более того, процесс ООП неразрывно связан с процессом построения этих диаграмм. При этом совокупность построенных таким образом диаграмм содержит практически всю информацию, которая необходима для реализации проекта сложной системы. Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML. Диаграмма вариантов использования представляет собой наиболее общую концептуальную модель сложной системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов является, по своей сути, логической моделью, отражающей статические аспекты структурного построения сложной системы. Диаграммы поведения также являются разновидностями логической модели, которые отражают динамические аспекты функционирования сложной системы. Диаграммы реализации служат для представления физических компонентов сложной системы и поэтому относятся к ее физической модели. Таким образом, интегрированная модель сложной системы в нотации UML представляется в виде совокупности указанных выше диаграмм. Рис. 3.10. Интегрированная модель сложной системы в нотации UML 11. Тестирование программного обеспечения 11.1.1. Основы тестирования Тестирование (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-) и интеграционное тестирование все чаще рассматривают как неотъемлемый элемент деятельности по конструированию. Критерии отбора тестов могут использоваться как для создания набора тестов, так и для проверки, насколько выбранные тесты адекватны решаемым задачам (тестирования). При этом, обсуждаемые критерии помогают определить, когда можно или необходимо прекратить тестирование. 1. Эффективность тестирования/Цели тестирования (Test effectiveness/Objectives for testing) Тестирование – это наблюдение за выполнением программы, запущенной в целях тестирования с заданными параметрами, по заданному сценарию или с другими заданными начальными условиями или целями тестирования. Эффективность теста может быть определена только в контексте заданных условий. 2. Тестирование для идентификации дефектов (Testing for defect identification) Данный случай тестирования подразумевает успешность процедуры тестирования, если дефект найден. Это отличается от подхода в тестировании, когда тесты запускаются для демонстрации того, что программное обеспечение удовлетворяет предъявляемым требованиями и, соответственно, тест считается успешным, если не найдено дефектов. 3. Проблема оракула (The oracle problem) “Оракул”, в данном контексте, любой агент (человек или программа), оценивающий поведение программы, формулируя вердикт - тест пройден (“pass”) или нет (“fail”). 4. Теоретические и практические ограничения тестирования (Theoretical and practical limitation of testing) Теория тестирования выступает против необоснованного уровня доверия к серии успешно пройденных тестов. К сожалению, большинство установленных результатов теории тестирования – негативны, означая, по словам Дейкстры (Dijkstra), то, что “тестирование программы может использоваться для демонстрации наличия дефектов, но никогда не покажет их отсутствие”. Основная причина этого в том, что полное (всеобъемлющее) тестирование недостижимо для реального программного обеспечения. 5. Проблема неосуществимых путей (The problem of infeasible paths) Эта сложнейшая проблема автоматизированного тестирования связана с тем, что путь, по которому выполняются потоки работ тестируемой программной системы, не могут быть заданы входными параметрами. 6. Тестируемость (Testability) Это понятие может подразумевать две различных идеи. Первая описывает степень легкости описания критериев покрытия тестами для заданной программной системы. Вторая определяет возможность вероятность, возможность статистического измерения того, что при тестировании проявится сбой программной системы. Обе интерпретации этого понятия одинаково важны для тестирования. Тестирование программного обеспечения отличается от статических техник управления качеством, проверки корректности, отладки и программирования, но связано со всеми этими работами. Полезно рассматривать тестирование с точки зрения аналитиков и специалистов по сертификации качества. 11.1.2. Уровни тестирования 11.1.2.1 Над чем производятся тесты Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Уровень тестирования определяет “над чем” производятся тесты: над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий. 2.1.1 Модульное тестирование (Unit testing) Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию. 2.1.2 Интеграционное тестирование (Integration testing) Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями. Классические стратегии интеграционного тестирования – “сверху-вниз” и “снизу-вверх” – используются для традиционных, иерархически структурированных систем и их сложно применять, например, к тестированию слабосвязанных систем, построенных в сервисно-ориентированных архитектурах (SOA). Современные стратегии в большей степени зависят от архитектуры тестируемой системы и строятся на основе идентификации функциональных “потоков” (например, потоков операций и данных). Интеграционное тестирование – постоянно проводимая деятельность, предполагающая работу на достаточно высоком уровне абстракции. Наиболее успешная практика интеграционного тестирования базируется на инкрементальном подходе, позволяющем избежать проблем проведения разовых тестов, связанных с тестированием результатов очередного длительного этапа работ, когда количество выявленных дефектов приводит к серьезной переработке кода (традиционно, негативный опыт выпуска и тестирования только крупных релизов называют “big bang”). 2.1.3 Системное тестирование (System testing) Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п. На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д. 11.1.2.2 Виды тестирования Тестирование проводится в соответствии с определенными целями (могут быть заданы явно или неявно) и различным уровнем точности. Определение цели точным образом, выражаемым количественно, позволяет обеспечить контроль результатов тестирования. Тестовые сценарии могут разрабатываться как для проверки функциональных требований (известны как функциональные тесты), так и для оценки нефункциональных требований. При этом, существуют такие тесты, когда количественные параметры и результаты тестов могут лишь опосредованно говорить об удовлетворении целям тестирования (например, “usability” – легкость, простота использования, в большинстве случаев, не может быть явно описана количественными характеристиками). Можно выделить следующие, наиболее распространенные и обоснованные цели (а, соответственно, виды) тестирования: 2.2.1 Приёмочное тестирование (Acceptance/qualification testing) Проверяет поведение системы на предмет удовлетворения требований заказчика. Это возможно в том случае, если заказчик берет на себя ответственность, связанную с проведением таких работ, как сторона “принимающая” программную систему, или специфицированы типовые задачи, успешная проверка (тестирование) которых позволяет говорить об удовлетворении требований заказчика. Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них. 2.2.2 Установочное тестирование (Installation testing) Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении. 2.2.3 Альфа- и бета-тестирование (Alpha and beta testing) Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки. Данный вид тестирования не может быть заранее спланирован. 2.2.4 Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing) Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик. 2.2.5 Достижение и оценка надежности (Reliability achievement and evaluation) Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут применяться для статистической оценки надежности. Обе цели – повышение и оценка надежности – могут достигаться при использовании моделей повышения надежности. Эти вопросы затрагиваются и в тематическом фрагменте 4.1.4 “Life test, reliability evaluation”. 2.2.6 Регрессионное тестирование (Regression testing) Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходит и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимеся ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты. 2.2.7 Тестирование производительности (Performance testing) Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Существует особый подвид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения. 2.2.8 Нагрузочное тестирование (Stress testing) Необходимо понимать отличия между рассмотренным выше тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы. 2.2.9 Сравнительное тестирование (Back-to-back testing) Единичный набор тестов, позволяющих сравнить две версии системы. 2.2.10 Восстановительные тесты (Recovery testing) Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы (disaster), влияющей на функционирование операционной среды, в которой выполняется система. 2.2.11 Конфигурационное тестирование (Configuration testing) В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях. 2.2.12 Тестирование удобства и простоты использования (Usability testing) Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; насколько эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя. 2.2.13 Разработка, управляемая тестированием (Test-driven development) По-сути, это не столько техника тестирования, сколько стиль организации процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью требований (и соответствующих спецификаций) вместо того, чтобы рассматриваться независимой деятельностью по проверке удовлетворения требований программной системой. Иногда говорят о таком стиле разработки как о самостоятельной методологии – TDD. Насколько это верно, зависит от того, что именно понимать под методологией разработки. Скорее, с точки зрения автора, это техника, практика или стиль организации работы, чем самостоятельная методология. В меньшей степени это относится к FDD – Feature-Driven Development (разработка на основе функциональных возможностей). TDD может естественно рассматриваться как составная часть XP или, как минимум Agile-методов. В свою очередь, FDD может рассматриваться как один из методов гибкой разработки. В чем отличие столь близких, на первый взгляд, подходов (и, кстати, соответствующих аббревиатур)? Причина – проста. Тесты – инструмент достижения характеристик системы, удовлетворяющей заданным требованиям, то есть потребностям пользователей, а “возможности” (features) – практически сами (чаще – функциональные) требования, воплощенные (в идеальном случае) в код. 11.2. Техники тестирования 3.1 Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuition and experience) 3.1.1 Специализированное тестирование (Ad hoc testing) Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий. Данный вид тестирования может быть полезен для идентификации тех тестов, которые не охватываются рассматривавшимеся выше более формализованными техниками. 3.1.2 Исследовательское тестирование (Exploratory testing) Такое тестирование определяется как одновременное обучение, проектирование теста и его исполнение. Данный вид тестирования заранее не определяется в плане тестирования и такие тесты создаются, выполняются и модифицируются динамически, по мере необходимости. Эффективность исследовательских тестов напрямую зависит от знаний инженера, формируемых на основе поведения тестируемого продукта в процессе проведения тестирования, степени знакомства с приложением, платформой, типами возможных сбоев и дефектов, рисками, ассоциированными с конкретным продуктом и т.п. 3.2 Техники, базирующиеся на спецификации (Specification-based techniques) 3.2.1 Эквивалентное разделение <приложения> (Equivalence partitioning) Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик <спецификации>. Репрезентативный набор тестов (иногда – только один тест) формируется из тестов эквивалентных классов (или наборов классов). 3.2.2 Анализ граничных значений (Boundary-value analysis) Тесты строятся с ориентацией на использование тех величин, которые определяют предельные характеристики тестируемой системы. Расширением этой техники являются тесты оценки живучести (robustness testing) системы, проводимые с величинами, выходящими за рамки специфицированных пределов значений. 3.2.3 Таблицы принятия решений (Decision table) Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве “входов”) и действиями  (могут рассматриваться как “выходы”). Набор тестов строится последовательным рассмотрением всех возможных кросс-связей в такой таблице. 3.2.4 Тесты на основе конечного автомата (Finite-state machine-based) Строятся как комбинация тестов для всех состояний и переходов между состояниями, представленных в соответствующей модели (переходов и состояний приложения). 3.2.5 Тестирование на основе формальной спецификации (Testing from formal specification) Для спецификации, определенных с использованием формального языка, возможно автоматически создавать и тесты для функциональных требований. В ряде случаев могут строится на основе модели, являющейся частью спецификации, не использующей формального языка описания. 3.2.6 Случайное тестирование (Random testing) В отличие от статистического тестирования (будет рассматриваться в 3.5.1 “Operational profile”), сами тесты генерируются случайным образом по списку заданного набора специфицированных характеристик. 3.3 Техники, ориентированные на код (Code-based techniques) 3.3.1 Тесты, базирующиеся на блок-схеме (Control-flow-based criteria) Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов. Максимальная отдача от тестов на основе блок-схемы получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии потоков работ (поведения) тестируемой системы. Адекватность таких тестов оценивается как процент покрытия всех возможных путей блок-схемы. 3.3.2 Тесты на основе потоков данных (Data-flow-based criteria) В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть до уничтожения (неопределенности). В реальной практике используются нестрогое тестирование такого вида, ориентированное, например, только на проверку задания начальных значений всех переменных или всех вхождений переменных в код, с точки зрения их использования. 3.3.3 Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph) Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на основе анализа кода). 3.4 Тестирование, ориентированное на дефекты (Fault-based techniques) Как это ни странно звучит на уровне названия таких техник тестирования, они, действительно, ориентированы на ошибки. Точнее – на специфические категории ошибок. 3.4.1 Предположение ошибок (Error guessing) Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, в результате анализа рисков. 3.4.2 Тестирование мутаций (Mutation testing) Мутация – небольшое изменение тестируемой программы, произошедшее за счет частных синтаксических изменений кода (в частности, рефакторинга). Соответствующие тесты запускаются для оригинального и всех “мутировавших” вариантов тестируемой программы. SWEBOK фокусируется на возможности, с помощью тестов, определять отличия между мутантами и исходным вариантом кода. Если такое отличие установлено, мутанта “убивают”, а тест считается успешным. Обычно, данный подход фокусируется на синтаксических ошибках, на практике отслеживаемых современными средами разработки и, конечно, компиляторами. 3.5 Техники, базирующиеся на условиях использования (Usage-based techniques) 3.5.1 Операционный профиль (Operational profile) Базируется на условиях использования системы. Тестирование для оценки надёжности системы должно проводиться в таком тестовом окружении, которое максимально приближено к реальным условиям работы системы. Результаты таких тестов позволяют оценить поведение системы в реальных условиях. Входные параметры тестов задаются на основе вероятностного распределения соответствующих параметров или их наборов при эксплуатации (входные данные могут прогнозироваться исходя из частоты возможных сценариев работы пользователей). 3.5.2 Тестирование, базирующееся на надежности инженерного процесса (Software Reliability Engineered Testing) Базируется на условиях разработки системы. Соответствующие тесты (обозначаемые также аббревиатурой SRET от Software Reliability Engineered Testing) проектируются в контексте используемого процесса разработки и методик тестирования. 3.6 Техники, базирующиеся на природе приложения (Techniques based on the nature of the application) Описанные выше техники могут применяться к любым типам программных систем. В то же время, в зависимости от технологической или архитектурной природы приложений, могут также применять специфические техники, важные именно для заданного типа приложения. Среди таких техник: • Объектно-ориентированное тестирование • Компонентно-ориентированное тестирование • Web-ориентированное тестирование • Тестирование на соответствие протоколам • Тестирование систем реального времени 3.7 Выбор и комбинация различных техник (Selecting and combining techniques) 3.7.1 Функциональное и структурное (Functional and structural) Техники тестирования, строящиеся на основе спецификаций или кода часто называют функциональными или структурными, соответственно. Оба подхода не должны противопоставляться, но дополнять друг друга. 3.7.1 Определенное или случайное (Deterministic vs. random) Обычно тесты можно распределить по данным группам на основе используемой политики выбора или определения входных параметров тестов. 11.2.1. Измерение результатов тестирования 11.2.1.1 Оценка программ в процессе тестирования Часто техники тестирования путают с целями тестирования. Степень покрытия тестами - не то же самое, что высокое качество тестируемой системы. Однако, эти вопросы связаны. Чем выше степень покрытия, чем больше вероятность обнаружения скрытых дефектов. Когда мы говорим о результатах тестирования, мы должны подходить к их оценке, как оценке самой тестируемой системы. Именно количественные оценки результатов тестирования (но не самих тестов, например, покрытия ими возможных сценариев работы системы) освещаются ниже. В свою очередь, метрики самих тестов или процесса тестирования, как такового – вопросы, рассматриваемые в областях знаний “Процессы программной инженерии” (Software Engineering Process) и “Управление инженерной деятельностью” (Software Engineering Management). Измерения являются инструментом анализа качества. Измерение результатов тестирования касается оценки качества получаемого продукта – программной системы. История измерений демонстрирует прогресс достижения приемлемого качества. Такая история является инструментом менеджмента качества. 4.1 Оценка программ в процессе тестирования (Evaluation of the program under test, IEEE 982.1-98) 4.1.1 Измерения программ как часть планирования и разработки тестов (Program measurements to aid in planning and design testing) Данные измерения могут базироваться на размере программ (например, в терминах количества строк кода или функциональных точек) или их структуре (например, с точки зрения оценки ее сложности в тех или иных архитектурных терминах). Структурные измерения могут также включать частоту обращений одних модулей программы к другим. 4.1.2 Типы дефектов, их классификация и статистика возникновения (Fault types, classification and statistics) В литературе по тестированию встречается большое количество различных классификаций дефектов. Эффективность тестирования может быть достигнута в том случае, если мы понимаем какие типы дефектов могут быть найдены в процессе тестирования программной системы и как изменяется их частота во времени (подразумевая историческую перспективу развития системы, а не её сбоев в процессе работы). Эта информация позволяет прогнозировать качество системы и помогает совершенствовать процесс разработки, в целом. Стандарт IEEE 1044-93 классифицирует возможные программные “аномалии”. 4.1.3 Плотность дефектов (Fault density) Тестируемая программа может оцениваться на основе подсчета и классификации найденных дефектов. Для каждого класса дефектов можно определить отношение между количеством соответствующих дефектов и размером программы (в терминах выбранных метрик оценки размера). 4.1.4 Жизненный цикл тестов, оценка надежности (Life test, reliability evaluation) Статистические ожидания в отношении надежности программной системы (см. выше 2.2.5 “Достижение и оценка надежности ”) могут использоваться для принятия решения о продолжении или прекращении (окончании) тестирования, исходя из заданных параметров приемлемого качества (например, плотности дефектов заданного класса). 4.1.5 Модели роста надежности (Reliability growth models) Данные модели обеспечивают возможности прогнозирования надежности системы, базируясь на обнаруженных сбоях (см. выше 2.2.5). Модели такого рода разбиваются на две группы – по количеству сбоев (failure-count) и времени между сбоями (time-between-failure). 11.2.1.2 Оценка выполненных тестов 4.2.1 Метрики покрытия/глубины тестирования (Coverage/thoroughness measures) Критерии “адекватности” тестирования, в ряде случаев, требуют систематического выполнения тестов для определенных набора элементов программы, задаваемых ее архитектурой или спецификацией. Соответствующие метрики позволяют оценить степень охвата характеристик системы (например, процент различных тестируемых параметров производительности) и глубину их детализации (например, случайное тестирование параметров производительности или с учетом граничных значений и т.п.). Такие метрики помогают прогнозировать вероятностное достижение заданных параметров качества системы. 4.2.2 Введение искусственных дефектов (Fault seeding) “Своими руками?! Никогда! ...” – такова, обычно, первая реакция на идею искусственного внесения дефектов, например, в программный код. На практике, этот подход помогает классифицировать возможные ошибки и следующие за ними сбои, применяя в дальнейшем полученные результаты для моделирования (пусть, часто, и интуитивного) возможных причин реальных сбоев, обнаруженных в процессе тестирования. Безусловно, данная техника должна использоваться с максимальной осторожностью опытными специалистами, хорошо представляющими общую архитектуру тестируемой программной системы и разбирающимеся во её внутренних связях. 4.2.3 Оценка мутаций (Mutation score) Получаемое в процессе тестирования мутаций (см. выше 3.4.2) отношение “убитых” к общему числу сгенерированных мутантов помогает измерить эффективность выполняемых тестов. В силу специфики такой техники тестирования, количественные оценки мутаций имеют практическое значение только для определенных типов систем. 4.2.4 Сравнение и относительная эффективность различных техник тестирования (Comparison and relative effectiveness of different techniques) Различные исследования в области тестирования связаны с попытками сравнения (с точки зрения достигаемого качества продукта) разных подходов к тестированию. Когда мы говорим об “эффективности” тестирования надо чётко договориться, что именно мы подразумеваем под эффективностью, желательно, в количественном выражении. Возможные варианты интерпретации этого понятия – число тестов (данной техники), необходимых для обнаружения первого дефекта; отношение количества всех обнаруженных дефектов к дефектам, найденным с применением заданного подхода и т.п. Только обладая такого рода данными можно говорить о корректности сравнения и оценки эффективности. 12. Сопровождение программного обеспечения Сопровождение в жизненном цикле, обычно, начинается сразу после передачи продукта и действует в течение периода гарантии или, чаще, технической поддержки. Но целый ряд функций, связанных с сопровождением, выполняется ещё на этапе разработки. Сопровождение программного обеспечения определяется как совокупность деятельности, необходимой для обеспечения экономически эффективной поддержки программных систем [44]. Эти работы делятся на предварительные, которые выполняются как перед вводом системы в эксплуатацию, и основные – выполняемые после. Предварительные работы включают планирование деятельности по сопровождению системы, а также организацию перехода к её полнофункциональному использованию. Основные работы связаны с поддержкой программных систем: • отслеживанием запросов на модификацию; • оценкой влияния предлагаемых изменений; • модификацией кода и других артефактов продукта; • проведение тестирования; • выпуск обновленных версий продукта. Кроме того, проводится обучение пользователей и обеспечивается их ежедневная поддержка при работе с текущей версией продукта. Область знаний «Сопровождение программного обеспечения» связана с другими аспектами программной инженерии. По-сути, описание этой области знаний непосредственно пересекается со всеми другими дисциплинами. Рисунок 6. Область знаний “Сопровождение программного обеспечения” [44, с.6-2, рис. 1] 12.1.1. Основы сопровождения программного обеспечения 12.1.1.1 Определения и терминология Сопровождение программного обеспечения определяется стандартом IEEE Standard for Software Maintenance (IEEE 1219) как модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов) продукта, или адаптации продукта для использования в модифицированном окружении. В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных процессов жизненного цикла. Этот стандарт описывает сопровождение как процесс модификации программного продукта в части его кода и документации для решения возникающих проблем при эксплуатации или реализации потребностей в улучшениях тех или иных характеристик продукта. Задача состоит в модификации продукта при условии сохранения его целостности. Международный стандарт ISO/IEC 14764 [10] определяет сопровождение программного обеспечения в тех же терминах, что и стандарт 12207, придавая особое значение работам по подготовке к деятельности по сопровождению до передачи системы в реальную эксплуатацию, например, вопросам планирования регламентов и операций по сопровождению. 12.1.1.2 Назначение сопровождения Сопровождение необходимо для обеспечения того, чтобы программный продукт на протяжении всего периода эксплуатации удовлетворяет требованиям пользователей. Деятельность по сопровождению применима для программного обеспечения, созданного с использованием любой модели жизненного цикла (например, спиральной) и методологии разработки. Изменения программной системы могут быть обусловлены как действиями по корректировке ее поведения или несвязанные с необходимостью корректировки. В общем случае, работы по сопровождению должны проводиться для решения следующих задач: • устранение сбоев; • модификации дизайна; • расширения функциональных возможностей; • создание (дополнение) интерфейсов взаимодействия с другими (внешними) системами; • адаптация для возможности работы на другой или обновленной аппаратной платформе, применения новых системных возможностей, функционирования в среде обновленной телекоммуникационной инфраструктуры и т.п.; миграции унаследованного программного обеспечения; вывода программного обеспечения из эксплуатации. Деятельность персонала сопровождения включает следующие аспекты: поддержка управляемости программного обеспечения в течение всего цикла эксплуатации; поддержка модификаций программных систем; совершенствование существующих процессов сопровождения; предотвращение падения производительности программной системы до неприемлемого заказчиком уровня. 12.1.1.3 Факторы стоимости и категории сопровождения Работы по сопровождению потребляют значительную часть финансовых ресурсов жизненного цикла программного обеспечения. Общее понимание сопровождения подразумевает лишь устранение сбоев. Однако, исследования и опросы на протяжении многих лет показывают, что более 80% усилий по сопровождению связаны не столько устранением сбоев, сколько с другими работами, не связанными с исправлением дефектов. Существуют как технические, так и другие факторы, оказывающие влияние на стоимость сопровождения, в целом: • тип приложения; • новизна программного обеспечения; • наличие и квалификация персонала по сопровождению; • длительность использования программной системы; • характеристики и специфика аппаратной части (а также телекоммуникационной инфраструктуры); • качество дизайна (например, модульность или масштабируемость), кода, документации и соответствующих работ по тестированию системы. Сегодня принято говорить о четырех категориях сопровождения: • Корректирующее сопровождение (corrective maintenance): “реактивная” модификация программного продукта, выполняемая уже после передачи в эксплуатацию для устранения сбоев; • Адаптирующее сопровождение (adaptive maintenance): модификация программного продукта на этапе эксплуатации для обеспечения продолжения его использования с заданной эффективностью (с точки зрения удовлетворения потребностей пользователей) в изменившемся или находящемся в процессе изменения окружении; в первую очередь, подразумевается изменение бизнес-окружения, порождающее новые требования к системе; • Совершенствующее сопровождение (perfective maintenance): модификация программного продукта на этапе эксплуатации для повышения характеристик производительности и удобства сопровождения; • Профилактическое сопровождение (preventive maintenance): модификация программного продукта на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до того, когда они приведут к реальным сбоям. ISO/IEC 14764 [10] классифицирует адаптивное и совершенствующее сопровождение как работы по расширению функциональности продукта. Этот стандарт также объединяет корректирующую и профилактическую деятельность в общую категорию работ по корректировке системы. Профилактическое сопровождение наиболее часто проводится для программных систем, связанных с вопросами безопасности человека. Таблица 1. Категории сопровождения программного обеспечения. 12.1.2. Основные проблемы сопровождения программного обеспечения Для обеспечения эффективного сопровождения программных систем необходимо множество проблем, связанных с соответствующими работами. Процесс сопровождения предъявляет специфические технические и управленческие требования к персоналу, занимающемуся сопровождениям. Попытка найти дефект в продукте, содержащем 500 тысяч строк кода, написанных другими инженерами – яркий пример сложностей, с которыми приходится сталкиваться инженерам по сопровождению. Другой пример, уже организационный, постоянная борьба за ресурсы с разработчиками (это чаще всего проявляется в вопросах отвлечения разработчиков от текущей работы для помощи в решении проблем сопровождения, а также в конкуренции за приоритеты финансирование разработки новой системы или сопровождения существующей). Одновременное планирование перспективной версии системы, реализация следующей версии и подготовка критических патчей для текущей версии – еще один классический пример проблем, с которыми приходится сталкиваться в процессе эксплуатации программного обеспечения. Проблемы, связанные с сопровождением, сгруппированы в следующие категории: • технические проблемы; • управленческие проблемы; • проблемы оценки стоимости; • проблемы измерения. 12.1.2.1 Технические проблемы В число технических проблем входят: • Проблема ограничения понимания, подразумевающая как быстро инженер по сопровождению может понять где необходимо внести исправления или изменения в код системы, которую он не разрабатывал. Этот процесс более сложен в случае анализа текстового представления системы – её исходного кода. • Проблема тестирования, связанная с тем, что стоимость повторения полного набора тестов для основных модулей системы может быть существенным как по времени, так и по стоимости. Для сопровождения системы особо значимым является выборочное регрессионное тестирование системы или его компонент для проверки того, что внесенные изменения не привели к непреднамеренному изменению поведения программного обеспечения. • Проблема анализа влияния, состоящая в необходимости полного анализа возможных последствий и влияний изменений, вносимых в существующую систему. Персонал сопровождения должен обладать необходимыми знаниями о специфике системы (в идеальном случае, иметь полное представление о системе на уровне ее разработчиков) – ее содержании и структуре. Инженеры используют эти знания для выполнения работ по анализу влияния, идентифицируя все системы и программные продукты, на которые могут повлиять изменения, вносимые в обслуживаемую программную систему. При этом, должны быть определены риски, связанные с внесением обсуждаемых изменений. Цели анализа влияния могут быть сформулированы следующим образом: • определение содержания изменений для задания работ по планированию и реализации; • получение максимально возможной оценки ресурсов, необходимых для проведения соответствующих работ; • анализ стоимости и выгоды от внесения запрошенных изменений (обычно касается пожеланий, запросов на расширение системы); • обсуждение сложности вопросов, связанных с внесением соответствующих изменений. Если программное обеспечение изначально разрабатывалось с учетом дальнейшей поддержки, это может существенно облегчить анализ влияний, как одной из ключевых работ по сопровождению. • Проблема возможности сопровождения или сопровождаемости программной системы определяется, например, глоссарием IEEE (стандарт 610.12-90 Standard Glossary for Software Engineering Terminology, обновление 2002 года) как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований. Для уменьшения стоимости дальнейшего сопровождения, на протяжении всего процесса разработки необходимо специфицировать, оценивать и контролировать характеристики, влияющие на возможность сопровождения. Если такие работы проводятся регулярно, это облегчает дальнейшее сопровождение, повышая его сопровождаемость (в частности, как характеристику качества). • Проблема отсутствия системной документации (системной модели), мешающая формированию понимания системы и, как следствие, невозможности адекватного анализа влияния. Технические проблемы могут быть решены при использовании систематического подхода к построению зрелых процессов, применению соответствующих техник и автоматизации необходимых задач по поддержке жизненного цикла с помощью специализированных инструментальных средств. 12.1.2.2 Управленческие проблемы К управленческим проблемам сопровождения относятся: • Проблема согласования с организационными целями, состоящая в том, что цели проектирования и сопровождения принципиально отличны. При разработке основная задача – выпуск системы, отвечающей потребностям пользователей, в заданные сроки и в рамках бюджета, а сопровождение системы преследует цели максимального продления срока эксплуатации программного обеспечения. При сопровождении, оценка возврата инвестиций становится более сложной и приводит к формированию точки зрения старшего менеджмента, что деятельность по сопровождению потребляет значительную часть ресурсов без явно выраженной и количественно определяемой отдачи для организации. • Проблемы кадрового обеспечения, связанная с вопросами привлечения и удержания квалифицированного персонала по сопровождению, поскольку обычно эта работа не выглядит привлекательной. • Проблема уникальных работ в процессе, связанная с тем, что на уровне процесса, деятельность по сопровождению программного обеспечения имеет очень много общего с разработкой, но при этом сопровождение включает работы, не представленные в процессе разработки, что требует от менеджмента специального внимания и специальных знаний. • Проблема организации сопровождения, состоящая в необходимости решения вопросов ответственности за конкретные функции деятельности по сопровождению. Команда, разрабатывавшая программный продукт, далеко не всегда отвечает за его сопровождение. Это не только стандартное управленческое решение независимых поставщиков программного обеспечения, но, также, часто встречается в организациях, использующих программные продукты в целях автоматизации своих бизнес-функций. • Проблема аутсоурсинга, связанная с необходимостью передачи работ, в первую очередь, вспомогательных (непрофильных для организации) другим компаниям. Крупные компании могут передавать в управление другим организациям целые портфели программных систем, а, иногда, и целиком всю ИТ-инфраструктуру. Вопросы выбора процессов для аутсорсинга и отслеживания их качества и эффективности становятся дополнительной проблемой менеджеров. 12.1.2.3 Проблемы оценки стоимости сопровождения С точки зрения планирования, как составной части проектной и управленческой деятельности, оценка стоимости является важной проблемой деятельности по сопровождению программного обеспечения. Для оценки стоимости сопровождения используют: • методы использования параметрических моделей, использующих данные предыдущих проектов; • методы экспертного мнения, позволяющие повысить точность оценок, полученных при использовании параметрических моделей за счёт применения опыта (в форме экспертного мнения, например, при использовании техники оценки «Delphi»), аналогий, а также структуры декомпозиции работ. Наилучшие результаты получаются в случае сочетания эмпирических методов с имеющимся опытом. Получаемые данные используются как результат программы измерения аспектов сопровождения. 12.1.2.4 Проблемы измерения в сопровождении программного обеспечения Формы и данные измерений в процессе сопровождения могут объединяться в единую программу количественных оценок, проводимых в отношении программного обеспечения. Многие организации используют популярный и практичный подход для измерений, базирующийся на оценке количества проблем и статуса их решений. Идеи этого подхода систематизированы в проекте Practical Software and Systems Measurement (PSM). Существуют общие метрики и их категории, в частности, определяемые Институтом Программной Инженерии университета Карнеги-Меллон (Software Engineering Institute, Carnegie-Mellon University – SEI CMU): размер, усилия, расписание и качество. Существуют различные методы внутренней оценки продуктивности (benchmarking) персонала сопровождения для сравнения работы различных групп сопровождения. Организация, ведущая сопровождение, должна определить метрики, по которым будут оцениваться соответствующие работы. Стандарты IEEE 1219 (Standard for Software Maintenance) и ISO/IEC 25010 [22] предлагают специализированные метрики, ориентированные именно на вопросы сопровождения и соответствующие программы. Типичные метрики оценки работ по сопровождению, соответствующих распространенной классификации эксплуатационных характеристик программного обеспечения следующие: • анализируемость (Analyzability): оценка (в первую очередь, дополнительных) усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для идентификации тех фрагментов программной системы, которые должны быть модифицированы; • изменяемость (Changeability): оценка усилий, необходимых для проведения заданных модификаций; • стабильность (Stability): оценка случаев непредусмотренного поведения системы, включая ситуации, обнаруженные в процессе тестирования; • тестируемость (Testability): оценка усилий персонала сопровождения и пользователей по тестированию модифицированного программного обеспечения. 12.1.3. Процесс сопровождения 12.1.3.1 Функции процесса сопровождения Процессы сопровождения описывают необходимые работы и детальные входы/выходы этих работ. Эти процессы рассматриваются в стандартах IEEE 1219 (Standard for Software Maintenance) и ISO/IEC 14764 [10]. Процесс сопровождения начинается по стандарту IEEE 1219 с момента передачи программной системы в эксплуатацию (post-delivery stage) и касается таких вопросов, как планирование деятельности по сопровождению. Рисунок 2. Работы в процессе сопровождения по стандарту IEEE 1219. Стандарт ISO/IEC 14764[10] уточняет положения, связанные с процессом сопровождения, стандарта жизненного цикла 12207[2]. Работы по сопровождению, описанные в этом стандарте аналогичны работам в IEEE 1219, за исключением того, что сгруппированы несколько иначе. Рисунок 3. Процесс сопровождения по стандарту ISO/IEC 14764 [10]. Работы по сопровождению в стандарте разбиты на задачи: • реализация процесса; • анализ проблем и необходимых модификаций; • проведение модификаций (реализация изменений); • оценка и принятие проведенных работ при сопровождении; • миграция (на модифицированную или новую версию программного обеспечения); • вывод из эксплуатации (прекращение эксплуатации программного обеспечения). 12.1.3.2 Работы по сопровождению Деятельность по сопровождению схожа с разработкой: анализ, проектирование, кодирование, тестирование и документирование свойственны обоим процессам. Тем не менее, деятельность по сопровождению обладает и определенными специфическими особенностями, которые следует учитывать. 1. Уникальные работы (Unique activities) Согласно [44] имеются следующие процессы, работы и практики, уникальные для деятельности по сопровождению: • Передача (Transition) – контролируемая и координируемая деятельность по передаче программного обеспечения от разработчиков группе, службе или организации, отвечающей за дальнейшую поддержку. • Принятие/отклонение запросов на модификацию (Modification Request Acceptance/Rejection) – деятельность по принятию решений о приёме и передаче в работу запросов на изменения, либо отклонении их. Такие решения могут приниматься на основе приоритетности, оценке обоснованности, отсутствии ресурсов, наличия утвержденного плана по реализации в следующей версии и т.п. • Средства извещения персонала сопровождения и отслеживания статуса запросов на модификацию и отчетов об ошибках (Modification Request and Problem Report Help Desk) – функция поддержки конечных пользователей, инициирующая работы по оценке, анализу приоритетности и стоимости модификаций, связанных с поступившим запросом или сообщенной проблемой. • Анализ влияния (Impact Analysis) – анализ возможных последствий изменений, вносимых в существующую систему. • Поддержка программного обеспечения (Software Support) – работы по консультированию пользователей, проводимые в ответ на их информационные запросы, проверки содержания данных и специфических вопросов пользователей и их сообщений о проблемах (ошибках, сбоях, непредусмотренному поведению, непониманию аспектов работы с системой и т.п.). • Контракты и обязательства, такие как соглашение об уровне предоставляемого сервиса, а также другие договорные аспекты, на основании которых, группа/служба/организация по сопровождению выполняет соответствующие работы. 2. Дополнительные работы, поддерживающие процесс сопровождения (Support activities) Такие работы включают: • планирование сопровождения; • конфигурационное управление; • проверка и аттестация; • оценка качества программного обеспечения; • различные аспекты обзора, анализа и оценки; • аудит; • обучение пользователей; • обучение персонала сопровождения. Рассмотрим подробнее каждую из этих работ: 1 Работы по планированию сопровождения Планирование является необходимым для проведения работ по сопровождению и затрагивает связанные с этим вопросов с нескольких точек зрения: • Бизнес-планирование (организационный уровень). • Планирование непосредственных работ по сопровождению. • Планирование релизов/версий (уровень программного обеспечения). • Планирование обработки конкретных запросов на изменение (уровень запроса). На уровне индивидуального запроса, работы по планированию проводятся вместе с проведением анализа влияния. В свою очередь, планирование релизов/версий требует от персонала сопровождения выполнения задач: • Получения и сбора информации о датах размещения индивидуальных запросов и отчетов. • Достижения соглашения с пользователями о содержании (функциональности, поведении и т.п.) последующих релизов/версий программного обеспечения. • Идентификации потенциальных конфликтов и возможных альтернатив. • Оценки рисков для функционирования текущего релиза и разработки плана «отката» на немодифицированный вариант системы, в случае возникновения проблем, связанных с модификацией. • Информирования всех заинтересованных лиц. Оценка ресурсов – важная неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должны быть заложены в бюджет еще при разработке системы. Планирование работ по сопровождению должно начинаться одновременно с принятием решения о создании системы и согласоваться с целями обеспечения качества (IEEE 1061-98 Standard for a Software Quality Metrics Methodology). Началом работ по сопровождению должна явиться концепция сопровождения. Согласно стандарту ISO/IEC 14764 [10] она должна включать: • содержания деятельности по сопровождению; • адаптации процесса сопровождения; • идентификации организации, которая будет заниматься сопровождением; • оценки стоимости сопровождения. На основе концепции деятельности по сопровождению должен быть разработан план сопровождения. Документ должен создаваться одновременно с разработкой программной системы и должен определять правила размещения пользователями своих запросов на модификацию (изменения) и сообщения об ошибках, сбоях и проблемах. На уровне бизнес-вопросов, структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающееся бюджетирования, финансового менеджмента и управления человеческими ресурсами, так же, как и любое другое (в том числе, профильное, если речь идет о потребителях ИТ) подразделение организации/компании. 2) Конфигурационное управление (Software configuration management) Стандарт IEEE 1219, посвященный организации сопровождения программного обеспечения, определяет конфигурационное управление как критически важный элемент процесса сопровождения. Процедуры конфигурационного управления должны обеспечивать проверку, аттестацию и аудит на всех шагах, требуемых для идентификации, авторизации, реализации и выпуска программного продукта. Подробнее о конфигурационном управлении речь пойдёт в параграфе 13. 3) Качество программного обеспечения (Software quality) Для поддержки процесса сопровождения  должны планироваться и реализовываться соответствующие процедуры и процессы, направленные на повышение качества. Работы и техники по обеспечению качества (Software Quality Assurance, SQA), проверке и аттестации (V&V, verification and validation), обзору, анализу и оценке (review), а также аудиту, должны отбираться в контексте взаимодействия и согласования со всеми другими процессами, направленными на достижение желаемого уровня качества. Отдельно качество программного обеспечения рассмотрено в главе 3. 12.1.4. Методы сопровождения Рассмотрим два наиболее распространённых методах сопровождения, применяемые сегодня на практике. 12.1.4.1 Реинжиниринг Реинжиниринг программного обеспечения – его детальная оценка и перестройка для формирования понимания, воссоздания и дальнейшей реализации его функций в новой, более совершенной форме [44]. Как правило, реинжиниринг провидится для замены устаревшего программного обеспечения, а не для улучшения возможностей сопровождения, сколько. Реинжиниринг целесообразно рассматривать как самостоятельный проект, включающий в себя, как отмечает SWEBOK [44], формирование концепции, применение соответствующих инструментов и техник, анализ и приложения опыта проведения реинжиниринга, а также оценку рисков и преимуществ, связанных с такими работами. Реализация продукта в новом качестве (форме) при сохранении основной функциональности оригинального продукта, является неотъемлемой и определяющей частью реинжиниринга, в отличие от обратного инжиниринга, рассматриваемого ниже и являющегося важной составной частью реинжиниринга. 12.1.4.2 Обратный инжиниринг «Обратный» инжиниринг – это процесс анализа программного обеспечения с целью идентификации программных компонент и связей между ними, а также формирования представления о программном обеспечении, с дальнейшей перестройкой в новой форме. Обратный инжиниринг является пассивным, предполагая отсутствие деятельности по изменению или созданию нового программного обеспечения. Обычно, в результате усилий по обратному инжинирингу создаются модели вызовов и потоков управления на основе исходного кода системы. Примерами обратного инжиниринга являются: • создание новой документации на существующую систему; • восстановление дизайна системы и т.п. К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также относятся работы по рефакторингу [Error: Reference source not found]. Рефакторинг – трансформация программного обеспечения, в процессе которой программная система реорганизуется (не переписываясь) с целью улучшения структуры, без изменения поведения. Сохранение «формы» (платформы, архитектурных и технологических решений) существующей программной системы позволяет рассматривать рефакторинг как один из вариантов обратного инжиниринга. С точки зрения [Error: Reference source not found] и для реинжиниринга и для обратного инжиниринга возможно применение слова реконструкция, в зависимости от контекста, означающее как полную перестройку или воссоздание чего-либо, идентичного по определенным характеристикам оригинальному образцу, так и восстановление какой-либо сущности по сохранившимся и/или доступным внешним признакам, где восстановление может подразумевать опять-таки создание нового образца или представления об оригинальной сущности. 13. Конфигурационное управление Работы по конфигурационному управлению программного обеспечения включают: управление и планирование процессов управления конфигурацией ПО (SCM), идентификацию программных конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также управление выпуском (release management) и поставкой (delivery). Управление конфигурацией связано с всеми областями знаний в программной инженерии, так как объектами её приложения являются все компоненты продукта, создаваемые и используемые в процессах программной инженерии. Конфигурация системы – функциональные и/или физические характеристики аппаратного, программно-аппаратного, программного обеспечения или их комбинации, сформулированные в технической документации и реализованные в продукте. 13.1.1. Управление конфигурационным процессом Конфигурационное управление (CM – Configuration Management) – дисциплина идентификации конфигурации системы в определенные (заданные) моменты времени, с целью систематического контроля изменений конфигурации, а также поддержки и сопровождения целостной и отслеживаемой (трассируемой) конфигурации на протяжении всего жизненного цикла системы. В соответствии с ГОСТ Р ИСО/МЭК (ISO/IEC, IEEE) 12207 [], конфигурационное управление в области программного обеспечения – Software Configuration Management (SCM) – один из вспомогательных процессов жизненного цикла по стандарту 12207, поддерживающих проектный менеджмент, деятельность по разработке и сопровождению, обеспечению качества, а также, заказчиков и пользователей конечного продукта. Управление конфигурацией ПО (SCM-деятельность) контролирует эволюцию и целостность продукта, идентифицируя его элементы, управляя и контролируя изменения, а также, проверяя, записывая и обеспечивая отчетность по конфигурационной информации. С инженерной точки зрения, SCM способствует разработке и реализации изменений. Успешное внедрение SCM требует точного планирования и управления, что предполагает понимание организационного контекста и тех ограничений, которые связаны с проектированием и реализацией процесса конфигурационного управления. 13.1.1.1 Организационный контекст управления конфигурацией ПО Для планирования SCM-процесса важно понимать организационный контекст и связи между организационными элементами. Организационные элементы, отвечающие за процессы поддержки программной инженерии, могут быть структурированы несколькими способами. Несмотря на то, что ответственность за выполнение определенных SCM-задач может быть распределена между различными лицами или подразделениями организации, общая ответственность за конфигурационное управление часто возлагается на отдельный (специализированный) организационный элемент или назначенную персону. Программное обеспечение в предметной области прикладной информатики обычно разрабатывается как составная часть большей системы, содержащей аппаратные и программно-аппаратные/встраиваемые элементы. В этом случае, деятельность по управлению конфигурацией ПО ведется параллельно с работами по конфигурационному управлению (CM) в отношении аппаратной или программно-аппаратной части, строго согласуясь с общим конфигурационным управлением на уровне системы, в целом. Иными словами, SCM осуществляется в сочетании с контекстом, в рамках которого проводится такая деятельность. SCM может играть роль интерфейса к работам, направленным на обеспечение качества. Некоторые элементы, находящиеся под управлением SCM, могут также служить объектами рассмотрения в рамках организационных программ по обеспечению качества. Управление несогласующемися элементами обычно относится к работам по управлению качеством, но и SCM может обеспечить существенную помощь в отслеживании и создании отчетности по элементам программных конфигураций, попадающих в такую категорию. В зависимости от контекста, существует множество подходов и практик в части выполнения задач конфигурационного управления в приложении к программному обеспечению. Часто, одни и те же инструменты поддерживают и разработку, и сопровождение, обеспечивая достижение целей и содержания SCM. 13.1.1.2 Ограничения и правила управления конфигурацией ПО Ограничения и правила в отношении процесса конфигурационного управления порождаются различными источниками: • политики и процедуры, формулируемые на корпоративном или другом организационном уровне, могут влиять или предписывать структуру и реализацию SCM-процесса для заданного проекта; • контракт между заказчиком и поставщиком может содержать положения, затрагивающие процесс конфигурационного управления; • если разрабатываемый программный продукт потенциально затрагивает аспекты публичной безопасности, могут налагаться определенные ограничения со стороны соответствующих регулирующих органов; • на структуру и реализацию SCM-процесса в проекта влияют выбранные процессы жизненного цикла и инструменты, применяемые для реализации программной системы. • рекомендации по структуре и реализации SCM-процесса могут быть также результатом применения лучших практик (best practices), представленных в стандартах, выпущенных соответствующими стандартизирующими организациями. Лучшие практики также отражены в моделях совершенствования и оценки процессов, речь о которых пойдёт в параграфах 3 и 4.2. 13.1.1.3 Планирование при управлении конфигурацией ПО Планирование процесса конфигурационного управления для заданного проекта должно согласовываться с организационным контекстом, соответствующими ограничениями, общепринятыми рекомендациями, а также характеристиками и природой самого проекта (например, его размером или значимостью). Основные работы, проводимые при планировании 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). Дополнительно следует учитывать: организационные вопросы, обязанности, ресурсы и расписание, выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а также, контроль интерфейсов взаимодействия программных модулей: 1 Организация и обязанности (SCM organization and responsibilities) Для предотвращения путаницы в том, кто будет выполнять заданные работы и задачи конфигурационного управления, должны быть четко идентифицированы организации (организационные структуры), вовлеченные в SCM-процесс. Конкретные обязанности по выполнению заданных работ и задач SCM должны быть назначены соответствующим организационным сущностям. Также, должны быть идентифицированы общие полномочия и пути  отчетности, даже если это выполняется в процессе планирования управления проектом или деятельности по обеспечению качества. 2 Ресурсы и расписание (SCM resources and schedules) В процессе планирования конфигурационного управления идентифицируется персонал и инструменты, привлекаемые для выполнения соответствующих работ и задач SCM. Планирование касается вопросов определения расписания, устанавливая последовательность задач конфигурационного управления и идентифицируя их связь с расписанием проекта и его вехами, определенными на стадии планирования проекта. Также должны быть специфицированы требования по обучению персонала, необходимые для реализации планов. 3 Выбор инструментов и реализация (Tool selection and implementation) SCM-деятельность поддерживается различными типами инструментальных средства и процедур по их использованию. В зависимости от ситуации, эти инструменты могут включать комбинацию различных возможностей – автоматизированные средства могут решать отдельные задачи SCM, интегрированные средства могут обслуживать потребности многих участников процесса программной инженерии (например, SCM, разработку, проверку и аттестацию и т.п.). Значимость инструментальной поддержки конфигурационного управления (как и других аспектов деятельности в области программной инженерии) растет с каждым днем вместе со сложностью внедрения, ростом размера проектов и сложности проектного окружения. Возможности инструментальных средств развиваются для обеспечения поддержки: • SCM-библиотек (проектно-ориентированных баз знаний, прим. автора) • Запросов на изменения (software change request - SCR) и процедур утверждения (approval) • Управления кодом (и связанных рабочих продуктов) и изменениями • Отчетности по статусу конфигураций и сбору соответствующих метрических показателей • Аудиту конфигураций • Управлению и отслеживанию <состояния и полноты> программной документации • Выполнению задач по сборке программных продуктов и их модулей • Управлению, контролю и поставке выпусков (релизов) программных продуктов Инструменты, используемые для обеспечения конфигурационного управления, могут также предоставлять метрики, необходимые для совершенствования процессов. SWEBOK [44] обращает внимание (рекомендуя соответствующий первоисточник) на следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and Progress) и индикаторы качества – поток изменений (Change Traffic), стабильность  <конфигураций> (Stability), раздробленность (Breakage), модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility), среднее время между сбоями (MTBF – Mean Time Between Failures), зрелость/полнота <информации> (Maturity). Отчетность по этим индикаторам может быть организована различным образом, например, по элементам конфигураций или по типу запросов на изменения. Рисунок 3 демонстрирует отображение инструментальных возможностей и процедур на работы по конфигурационному управлению. Рисунок 3. Характеристики SCM-инструментов и связанные процедуры. [44, с.7-4, рис. 3] В этом примере система управления кодом поддерживает программные библиотеки контролируя доступ к элементам библиотек, координирует действия  множества пользователей и помогает в проведении рабочих процедур. Другие инструменты поддерживают процесс сборки и выпуска программного обеспечения и документации на основе программных элементов, содержащихся в библиотеках. Инструменты для управления запросами на изменения программного обеспечения используются для контролируемых <системой конфигурационного управления> программных элементов. Другие инструменты могут обеспечивать управление базой данных и необходимыми менеджменту отчетными средствами, а также деятельностью по разработке и обеспечению качества. Как уже упоминалось выше, в рамках SCM-системы может быть объединен целый ряд инструментов различных типов. При этом сама система конфигурационного управления может быть тесно связана и поддерживать другие виды работ, касающиеся не только SCM. В процессе планирования инженеры выбирают те SCM-средства, которые применимы для решения стоящих перед ними задач. В процесс планирования рассматриваются аспекты, которые могут “всплыть” в процессе внедрения (и, даже, на этапе эксплуатации) выбираемой системы конфигурационного управления. В частности, обсуждаются и вопросы возможных “культурных” изменений, если это необходимо (с точки зрения поставленных целей – проекта и/или совершенствования процессов). Дополнительная информация, затрагивающая SCM-инструментарий, представлена в области знаний [44]. 4 Контроль поставщиков/подрядчиков (Vendor/Subcontractor Control) Программные проекты могут требовать необходимости приобретать или использовать уже приобретенное программное обеспечение – компиляторы и другие инструменты (среды разработки, библиотеки компонент). Планирование должно касаться вопросов – надо и, если надо, то как помещать эти инструменты (например, интегрируя в программные библиотеки проекта) под управление SCM-системы и как их изменения и обновления будут оцениваться и управляться. Аналогичные соображения существуют и в отношении программного обеспечения, создаваемого подрядчиками. В этом случае, в отношении SCM-процесса подрядчика предъявляются специальные требования со стороны заказчика и они вносятся в контракт, предполагая не только возможность мониторинга, но и соответствие его возможностей заданным требованиям. В последнее время все чаще отмечается важность доступности SCM-информации для эффективного мониторинга соответствия (compliance monitoring). 5 Контроль интерфейсов (Interface Control) Когда программные элементы должны связываться с другими программными или аппаратными элементами, изменения в одних элементах могут влиять на другие элементы. Планирование SCM-процесса рассматривает, в частности, как будут идентифицироваться связанные элементы и как будут управляться и сообщаться их изменения. Конфигурационное управление может быть частью более масштабного процесса системного уровня (т.е. в рамках всей системы, к которой относятся соответствующие программные элементы) по определению и контролю интерфейсов, включая описание в соответствующих спецификациях интерфейсов, планах контроля интерфейсов и других документах. В этом случае, SCM-планирование контроля интерфейсов проводится в контексте процесса системного уровня. 13.1.1.4 План конфигурационного управления Результаты SCM-планирования для заданного проекта определяются в плане конфигурационного управления (Software Configuration Management Plan, SCMP), который является документом, используемом в качестве описание SCM-процесса. Он поддерживается в актуальном состоянии на протяжении всего жизненного цикла. Создание и сопровождение плана конфигурационного управления основывается на информации, получаемой в процессе работ по планированию. Стандарт IEEE 828-98 “Standard for Software Configuration Management Plans” даёт рекомендации по созданию и сопровождению плана и описывает требования к информации, содержащейся в плане конфигурационного управления, а также определяет категории SCM-информации, содержащейся в плане: • введение (Introduction) – описывает цели, содержание и используемые термины; • управление (SCM Management) – описывает структуру, обязанности, полномочия, политики, директивы (указания, обязательные для исполнения) и процедуры; • работы (SCM Activities) – определяет идентификацию конфигураций, их контроль и т.п.; • расписание (SCM Schedule) – определяет связь работ по конфигурационному управлению с другими аспектами и процессами проектной деятельности; • ресурсы (SCM Resources) – описывает инструменты, физические ресурсы, персонал и т.п.; • сопровождение плана (SCMP Maintenance) – определяет правила, по которым в план вносятся изменения и описывает как эти изменения внедряются в повседневный SCM-процесс. 13.1.1.5 Контроль выполнения процесса управления конфигурацией ПО После внедрения процесса конфигурационного управления требуется контролировать SCM-процесс для обеспечения того, что SCM-план исполняется надлежащим образом. В ряде случаев определяются конкретные требования по обеспечению качества (SQA), контролирующие исполнение процессов и процедур конфигурационного управления. Для этого может быть необходимо введение соответствующих полномочий и назначение обязанностей по контролю выполнения задач SCM. Аналогичные полномочия и обязанности по надзору над SCM-процессом могут существовать в контексте SQA-деятельности. Использование интегрированных SCM-инструментов с возможностью контроля процесса может сделать процедуру надзора более легкой и прозрачной. Некоторые инструменты предоставляют высокий уровень настраиваемости для обеспечения гибкой адаптации процессов. Другие инструменты являются менее гибкими, диктуя те или иные процессы и их характеристики. Требования контроля (надзора), с одной стороны, и уровень гибкости и адпатируемости, с другой, являются определяющими критериями выбора того или иного инструмента. Рассмотрим 2 подхода к такого рода контролю: 1 Метрики и процесс количественной оценки в SCM (SCM measures and measurement) Количественные показатели (метрики) могут определяться для обеспечения информации о разрабатываемом продукте или для оценки исполнения самого процесса конфигурационного управления. Связанной целью SCM-мониторинга может быть и раскрытие возможностей по совершенствованию процесса (не только SCM-процесса, но и других процессов программной инженерии). Количественная оценка SCM-процессов предоставляет хорошие средства для мониторинга эффективности деятельности по конфигурационному управлению на постоянной основе. Эти измерения полезны для оценки текущего состояния процесса и проведения сравнений во времени (как прогресса в отношении развития продукта, так и качества выполнения процесса, как такового). Анализ измерений позволяет понять причины изменения процесса и внести соответствующие коррективы в план конфигурационного управления (SCMP). Программные библиотеки и различные возможности SCM-средств предоставляют источники для получения информации о характеристиках SCM-процесса (наравне с проектной информацией и данными, необходимыми для принятия тех или иных управленческих решений). Например, информация о времени, необходимом для выполнения различных типов изменений, может быть полезна для оценки критериев того, какой уровень полномочий оптимален для утверждения определенных типов изменений. Необходимо сохранять фокус на проведении анализа измерений и формировании соответствующих выводов, вместо проведения “измерений ради измерений” (к сожалению, последнее встречается слишком часто, чтобы не отметить этот факт). Обсуждение количественных оценок в отношении процесса и продукта представлено в области знаний “Процесс программной инженерии”. Программа проведения количественных оценок обсуждается в области знаний “Управление программной инженерией”. 2 Аудит в рамках SCM (In-process audits of SCM) Аудит может проводится на протяжении всего процесса программной инженерии для определения текущего статуса заданных элементов конфигураций или оценки реализации процесса конфигурационного управления. SCM-аудит предоставляет более формальный механизм мониторинга выбранных аспектов процесса и может координироваться с работами в области обеспечения качества (SQA; см. секцию “5. Software Configuration Auditing”). 14. Инструменты и методы программной инженерии 14.1. Инструменты Программные инструменты предназначены для обеспечения поддержки процессов жизненного цикла программного обеспечения, позволяя автоматизировать отдельные повторяющиеся действия и уменьшить загрузку специалистов по программной инженерии однообразными операциями. Инструменты составляют средства программной инженерии. По своему содержанию они могут варьироваться от поддержки отдельных индивидуальных задач до охвата всего жизненного цикла (платформа разработки). В свою очередь, методы программной инженерии формируют некоторую процедуру действий, направленных на достижение успеха в некоторой конкретной сфере. Методы обычно предоставляют соответствующие нотации, словари терминов и процедуры выполнения определённого набора задач, а также рекомендации по оценке и проверке выполняемого процесса и получаемого в его результате продукта. Методы, как и инструменты могут иметь различный масштаб. В данном разделе рассматриваются только методы, охватывающих несколько этапов жизненного цикла. Конкретные методы описаны в соответствующих разделах. Рисунок 1. Область знаний “Инструменты и методы программной инженерии” [SWEBOK, 2004, с.10-1, рис. 1] 14.1.1. Инструменты работы с требованиями Согласно SWEBOK [44] инструменты, применяемые для работы с требованиями, могут быть классифицированы на средства моделирования и средства трассировки. На практике моделирование требований, как и трассировка, являются частью управления требований. Но в силу своей значимости при проведении анализа требований инструменты трассировки могут быть рассмотрены как самостоятельная категория. Но моделирование требований лишь часть управления требованиями. Поэтому согласно [Error: Reference source not found] используется термин «инструменты управления требованиями», что отличается от оригинального текста SWEBOK. Таким образом, для работы с требованиями используются: • инструменты управления требованиями, применяемые для извлечения, анализа, специфицирования и проверки программных требований; • инструменты трассировки требований, применяемые для представления отношений между требованиями различного уровня в системе. 14.1.2. Инструменты проектирования и конструирования К инструментам проектирования относятся инструменты, используемые для создания и проверки программного дизайна. В качестве классификационных признаков можно выделить такие критерии как: • применяемые базовые нотации моделирования и проектирования (SADT/IDEF, UML, BPMN/BPEL, Microsoft DSL и т.п.); • целевые задачи (бизнес-моделирование, проектирование БД, объектно-ориентированное проектирование, интеграционное/SOA-проектирование и т.п.) [Error: Reference source not found]. К инструментам конструирования относятся инструменты, используемые для производства и трансляции программного представления (например, исходного кода), достаточно детального и явного для машинного выполнения [Error: Reference source not found]: • Редакторы, применяемые для создания и модификации исходного кода программ и ассоциированной с ними документации. Это могут быть как редакторы “общего назначения” (что на протяжении многих лет наблюдается в UNIX и unix-подобных средах) или специализированные редакторы с поддержкой специфики целевого языка программирования (что является, в большинстве случаев, прерогативой интегрированных сред разработки – IDE). В то же время, документирование все же является не только и не столько частью редактора, сколько самостоятельной функциональностью, пусть часто и тесно интегрированной с редактором. • Компиляторы и генераторы кода, традиционно выполнявшие покомандную трансляцию исходного кода. Однако существует тенденция интеграции компиляторов и редакторов в интегрированные среды программирования. К этому классу также относятся препроцессоры, линковщики/загрузчики, а также генераторы кода (за исключением, объектно-ориентированных средств проектирования). • Интерпретаторы, обеспечивающие исполнение программ посредством эмуляции. Они могут поддерживать действия по конструированию программного обеспечения, предоставляя для исполнения программ окружение, более контролируемое и поддающееся наблюдению, чем это обычно способна сделать та или иная операционная система. Существует явная тенденция к интеграции функций компиляторов и интерпретаторов в единых инструментах. Например, компиляция just-in-time (компиляции «на лету»), когда промежуточный программный код, по мере исполнения или с опережением преобразуется в набор инструкций, исполняемых непосредственно средствами операционной системы, но под контролем среды исполнения. Такого рода подход стал родоначальником ряда современных программных платформ, например, Java и .NET. • Отладчики, которые поддерживают процесс конструирования программного обеспечения, но, в то же время, функционально отличаются от редакторов и компиляторов. Кроме того, необходимо выделить «интегрированные средства разработки» (IDE – integrated developers environment), программные библиотеки/библиотеки компонент, а также «программные платформы» (например, Java, J2EE и Microsoft .NET) и «платформы облачных вычислений» (например, Microsoft Azure, Amazon и др.), которые включают наравне с инструментами, как таковыми, и определенные модели конструирования, преобразования и выполнения кода. 14.1.3. Инструменты тестирования К числу инструментов данного класса относятся: • генераторы тестов, поддерживающие функцию разработки сценариев тестирования; • средства выполнения тестов, формирующие среду исполнения тестовых сценариев в окружении, позволяющем отслеживать поведение тестируемого объекта; • средства оценки тестов, поддерживающие оценку результатов выполнения тестов для определения соответствия наблюдаемого поведения тестируемого объекта ожидаемому; • менеджеры тестами, обеспечивающие поддержку всех аспектов процесса тестирования программного обеспечения; • инструменты анализа производительности, используемые для количественной оценки и анализа производительности программного обеспечения, включающие инструменты функционального тестирования, средства тестирования безопасности, инструменты тестирования пользовательского интерфейса, инструменты нагрузочного тестирования и прочие. 14.1.4. Инструменты сопровождения Инструменты сопровождения существующего программного обеспечения, согласно SWEBOK [44] можно поделить две категории: • инструменты облегчения понимания (демонстрации), служащие для помощи в понимании человеком программ, например, различные средства визуализации; • инструменты реинжиниринга, обеспечивающие функции по реорганизации процессов жизненного цикла для повышения их эффективности, управляемости, безопасности и т.д. Средства «обратного» инжиниринга помогают в процессе восстановления для существующего программного обеспечения таких артефактов, как спецификация и описание дизайна (архитектуры), которые, в дальнейшем, могут быть трансформированы для генерации нового продукта на основе функциональности существующего [Error: Reference source not found]. 14.1.5. Инструменты конфигурационного управления Инструменты конфигурационного управления по [44] делятся на три категории: • инструменты отслеживания дефектов, расширений и проблем; • инструменты управления версиями; • инструменты сборки и выпуска, предназначенные для управления задачами сборки и выпуска продуктов, а также включают средства инсталляции. 14.1.6. Инструменты управления инженерной деятельностью Средства управления деятельностью по программной инженерии делятся на три категории [44]: • инструменты планирования и отслеживания проектов, применяемые для календарного планирования работ, количественной оценки усилий и стоимостных ожиданий, связанных с проектами (например, Microsoft Project); • инструменты управления рисками, используемые для идентификации, оценки ожиданий и мониторинга рисков (например, Project Expert). • инструменты количественной оценки, обеспечивающие ведение измерений и помогающие в выполнении работ, связанных с программой количественной оценки, проводимой в отношении проектов программного обеспечения. 14.1.7. Инструменты поддержки процессов К числу поддерживающих процессы можно отнести инструменты, используемые для создания условий для разработки ПС: • инструменты моделирования, позволяющие, описать модели процессов, именно как модели; • инструменты управления проектами, обеспечивающие возможности для управления процессами. • инструменты конфигурационного управления, поддерживающие работу с актуальными версиями и задающие основные параметры проекта. • ролевые платформы разработки программного обеспечения, охватывающие все стадии жизненного цикла и, на сегодняшний день, являющиеся развитием интегрированных средств разработки и CASE-инструментов в направлении поддержки “смежной” функциональности – управления требованиями, работ по конфигурационному управлению с поддержкой управления изменениями, тестирования и оценки качества [Error: Reference source not found]. 14.1.8. Инструменты обеспечения качества Средства обеспечения качества делятся на две категории [44]: • инструменты инспектирования, служащие для поддержки обзора и аудита процессов; • инструменты анализа, используемые для анализа программных артефактов, данных, потоков работ и зависимостей и для проверки определенных свойств или артефактов на соответствие заданным характеристикам. 14.2. Методы 14.2.1. Эвристические методы Эвристические методы – последовательность предписаний или процедур обработки информации, выполняемая с целью поиска более рациональных и новых конструктивных решений [википедия]. Эвристические методы обычно противопоставляют формальным методам решения, опирающимся на точные математические модели. В психологической и кибернетической литературе под эвристическими методами понимаются любые методы, направленные на сокращение перебора, или индуктивные методы решения задач. К их числу относят: • структурные методы, предполагающие построение системы с функциональной точки зрения, начиная с высокоуровневого понимания поведения системы с постепенным уточнением деталей на более низких уровнях; • методы, ориентированные на данные, ориентированные на разработку структур данных, которыми манипулирует создаваемое программное обеспечение, а функции при этом рассматриваются как вторичные. • объектно-ориентированные методы, представляющие программную систему в виде совокупности объектов; • методы, ориентированные на конкретную область применения и специализированные методы разрабатываются с учетом конкретных решаемых задач, например, всевозможные системы защиты информации. 14.2.2. Формальные методы «Термин формальные методы подразумевает ряд операций, в состав которых входит создание формальной спецификации системы, анализ и доказательство спецификаций, реализация системы на основе преобразования формальной спецификации в программы и верификация программ. Все эти действия зависят от формальной спецификации программного обеспечения. Формальная спецификация – это системная спецификация, записанная на языке, словарь, синтаксис и семантика которого определены формально. Необходимость формального определения языка предполагает, что этот язык основывается на математических концепциях. Здесь используется область математики, которая называется дискретной математикой и основывается на алгебре, теории множеств и алгебре логики» [Error: Reference source not found]. Формальные методы можно классифицировать на следующие категории: • языки и нотации спецификаций, которые могут быть ориентированы на модель, свойства и поведение, например формальные методы описания требований; • методы трансформации, основанные на уточнении (трансформации) превращении спецификаций в конечный результат, максимально близкий желаемому – исполнимый программный продукт; • методы подтверждения, основывающиеся на строгом математическом доказательстве точности любых характеристик исходных предпосылок и получаемого продукта с использованием теорем и проверки точности моделей. Следует отметить, что строгие формальные методы обычно не эффективны в области разработки прикладных систем, поскольку они требуют выполнения сложных и трудоёмких доказательств на основе обычно весьма неполных данных. Более того, успех проекта по разработке ПС зависит от такого количества непредсказуемых факторов, то формальные методы далеко не всегда гарантируют его достижение. 14.2.3. Методы прототипирования Методы прототипирования можно разделить на три категории: • стили прототипирования, подразумевающие создание временно используемых прототипов и эволюционное прототипирование; • цели прототипирования, такие как требования, архитектурный дизайн или пользовательский интерфейс; • техники оценки / исследования результатов прототипирования, касающиеся того, как будут использованы результаты создания прототипа. Библиография 1. ISO 9127:1988. Системы обработки информации. Документация пользователя и сопроводительная информация программных пакетов потребителя. 26 c. 2. ISO/IEC 12207:2008. Информационные технологии. Процессы жизненного цикла программного обеспечения. М.: «СтандартИнформ», 2008. 138 c. 3. ISO/IEC 14102:2008. Информационные технологии. Руководство по оцениванию и выбору инструментальных CASE-средств. М.: «СтандартИнформ», 2008, 48 c. 4. ISO/IEC 14143-1:2007. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 1. Определение понятий. 5. ISO/IEC 14143-2:2011. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 2. Оценка соответствия методов измерения размера программного обеспечения стандарту ИСО/МЭК 14143-1:1998. 6. ISO/IEC 14143-6:2012 Информационные технологии. Измерение программного обеспечения. Измерение функционального размера. Часть 6. Руководство по использованию стандартов серии ISO/IEC 14143 и связанных с ними международных стандартов 7. ISO/IEC 14598-5:1998. Информационные технологии. Оценка программного продукта. Часть 5. Процесс для оценщика. М.: «СтандартИнформ», 1998, 42 c. 8. ISO/IEC 14598-6:2001. Разработка программного обеспечения. Оценка продукта. Часть 6. Документирование модулей оценки. М.: «СтандартИнформ», 2001, 38 c. 9. ISO/IEC 14756:1999. Информационные технологии. Измерение и оценка эксплуатационных характеристик автоматизированных систем программного обеспечения. 10. ISO/IEC 14764:2006 Разработка программного обеспечения. Процессы жизненного цикла программного обеспечения. Сопровождение. М.: «СтандартИнформ», 2006, 58 c. 11. ISO/IEC 15026-2:2011Проектирование систем и разработка программного обеспечения. Гарантирование систем и программного обеспечения. Часть 2. Обоснование гарантии. М.: «СтандартИнформ», 2011, 18 c. 12. ISO/IEC 15026-3:2011Проектирование систем и разработка программного обеспечения. Гарантирование систем и программного обеспечения. Часть 3. Уровни целостности системы. М.: «СтандартИнформ», 2011, 40 c. 13. ISO/IEC 15026-4:2012 Проектирование систем и разработка программного обеспечения. Гарантирование систем и программного обеспечения. Часть 4. Гарантия в контексте жизненного цикла. М.: «СтандартИнформ», 2012, 32 c. 14. ISO/IEC 15408-1:2009 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности ИТ. Часть 1. Введение и общая модель. М.: «СтандартИнформ», 2009, 72 c. 15. ISO/IEC 15408-2:2008 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности ИТ. Часть 2. Функциональные требования безопасности. М.: «СтандартИнформ», 2008, 240 c. 16. ISO/IEC 15408-3:2008 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности ИТ. Часть 3. Требования к обеспечению защиты. М.: «СтандартИнформ», 2008, 184 c. 17. ISO/IEC 15939:2007. Технология программного обеспечения. Процесс измерения программного обеспечения. М.: «СтандартИнформ», 2007, 46 c. 18. ISO/IEC 16085:2006 Системы и разработка программного обеспечения. Процессы жизненного цикла. Управление рисками. М.: «СтандартИнформ», 2006, 51 c. 19. ISO/IEC 2382-20:1990. Информационные технологии. Словарь. Часть 20. Разработка системы. 34 c. 20. ISO/IEC 25000:2005. Технология программного обеспечения. Требования и оценка качества программного продукта. Руководство. М.: «СтандартИнформ», 2005, 48 c. 21. ISO/IEC 25001:2007 Программирование. Требования к качеству программного продукта и его оценка. Планирование и менеджмент. Процесс оценки. М.: «СтандартИнформ», 2007, 22 c. 22. ISO/IEC 25010:2011 Разработка программного обеспечения и проектирование систем. Требования к качеству и оценка систем и программного продукта (SQuaRE). Модели качества системы и программного продукта. М.: «СтандартИнформ», 2011. 44 с. 23. ISO/IEC 25040:2011 Проектирование систем и разработка программного обеспечения. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Процесс оценки. М.: «СтандартИнформ», 2011, 54 c. 24. ISO/IEC 25041:2012 Разработка систем и программ. Требования и оценивание качества систем и программ. Руководство по оцениванию для разработчиков, покупателей и независимых оценщиков. М.: «СтандартИнформ», 2012, 62 c. 25. ISO/IEC 26514:2008 Разработка систем и программ. Требования к дизайнерам и разработчикам пользовательской документации. М.: «СтандартИнформ», 2008, 154 c. 26. ISO/IEC 27005:2011 Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности. М.: «СтандартИнформ», 2011, 76 c. 27. ISO/IEC 27033-1:2009 Информационная технология. Методы и средства обеспечения безопасности. Сетевая безопасность. Часть 1. Обзор и концепции. М.: «СтандартИнформ», 2009, 88 c. 28. ISO/IEC 8211:1994. Информационные технологии. Спецификация описательного файла данных для обмена информацией. 79 c. 29. ISO/IEC 90003:2004. Техника программного обеспечения. Рекомендации по применению ISO 9001:2000 к компьютерному программному обеспечению. М.: «СтандартИнформ», 2004. 108 с. 30. ISO/IEC TR 14143-3:2003. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 3. Проверка методов измерения функционального размера. 31. ISO/IEC TR 14143-4:2002. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 4. Эталонная модель. 32. ISO/IEC TR 14143-5:2004. Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Часть 5. Определение функциональных доменов, используемых для измерения функционального размера. 33. ISO/IEC TR 14763-2:2000 Информационные технологии. Ввод и функционирование кабельной системы в помещении пользователя. Часть 2. Планирование и установкаISO/IEC TR 12182:1998. Информационные технологии. Классификация программного обеспечения. М.: «СтандартИнформ», 2010. 42 c. 34. ISO/IEC TR 15026-1:2010 (Техническая поправка 1, 2012) Проектирование систем и разработка программного обеспечения. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь. М.: «СтандартИнформ», 2010, 102 c. 35. ISO/IEC TR 19759:2005. Совокупность знаний о разработке программного обеспечения. Руководство. «СтандартИнформ», 2005, 210 c. 36. ISO/IEC TR 20004:2012 Информационные технологии. Методы обеспечения безопасности. Уточненный анализ чувствительности программного обеспечения по SO/IEC 15408 и ISO/IEC 18045. М.: «СтандартИнформ», 2012, 24 c. 37. ISO/IEC TR 9294:2005. Руководство по управлению документированием программного обеспечения. М.: «СтандартИнформ», 2005, 22 c. 38. ISO/IEC/IEEE 26512:2011 Разработка систем и программ. Требования к закупщикам и поставщикам документации для пользователей. М.: «СтандартИнформ», 2011, 48 c. 39. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. 12 c. 40. ГОСТ Р ИСО/МЭК 15504-1-2009. Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь. М.: «СтандартИнформ», 2010. 41. ГОСТ Р ИСО/МЭК 15504-2-2009 Информационная технология. Оценка процесса. Часть 2. Проведение оценки. М.: «СтандартИнформ», 2010. 42. ГОСТ Р ИСО/МЭК ТО 15271-2002 Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств). М.: «СтандартИнформ», 2003, 45 c. 43. ГОСТ Р ИСО/МЭК ТО 16326-2002 Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (при управлении проектом). М.: «СтандартИнформ», 2003, 40 c. 44. [SWEBOK, 2004] - Guide to Software Engineering Base of Knowledge (SWEBOK). IEEE Computer Society, 2004. http://www.swebok.org/ 45. IT Infrastructure Library [электронный ресурс] // http://www.itexpert.ru/rus/biblio/itil_v3/