Поделиться
ИСК-1, ИСК-3 Сертификация ИС. Раздел 2. Лекция 10_5.docx
При сертификационных испытаниях основные характеристики программного продукта условно можно разделить на две группы: функциональные характеристики, надежность, безопасность и производительность, и обобщенные характеристики качества.
В предыдущей лекции представлены испытания функциональных характеристик и основной группы динамических характеристик программных продуктов.
Обобщенные их свойства проявляются при испытаниях рисков и эксплуатационных характеристик продукта, которые рассмотрены ниже в этой лекции. Сертификационные испытания, отражающие качество программного продукта с наиболее общих позиций, состоят в определении рисков при его функционировании и качества эксплуатационной документации для пользователей.
Ранее отмечалось, что требования к программным продуктам можно оценивать с двух позиций: с положительной - при анализе качества реализации требований к функциям и характеристикам продукта, и с негативной - при определении, допустимого ущерба - риска приме нения программного продукта.
Часто заказчики и разработчики первоначально устанавливают требования к каждой функции и характеристике программного продукта без учета относительных затрат на их достижение, а также без детального анализа их совместного влияния на полную функциональную пригодность и риски у потребителей или для системы.
Это может приводить к несбалансированным значениям требований к отдельным, взаимосвязанным характеристикам, на которые не рационально используются ограниченные ресурсы ЖЦ комплекса про грамм, или к не адекватно низким их значениям.
В крупных проектах это может угрожать значительным повышением стоимости и/или снижением конкурентоспособности создаваемого программного продукта из-за недостаточного уровня качества отдельных функций и характеристик.
Удостоверение качества и завершение сертификационных испытаний программных продуктов:
· испытания для сокращения и ликвидация опасных рисков при применении программного продукта;
· идентификации уровня допустимого интегрального риска программного продукта;
· изменение требований к функциям и характеристикам программного продукта для снижения риска;
- испытания эксплуатационной документации на соответствие требованиям к программному продукту:
· испытания документов на соответствие требованиям к функциям и характеристикам программного продукта;
· испытания эксплуатационной документации на практичность применения;
- завершение сертификационных испытаний программного продукта;
- документирование процессов и результатов сертификации программного продукта:
· базовые нормативные документы качества производства программного продукта;
· исходные документы, характеризующие конкретный программный продукт и его предварительные испытания;
· отчетные документы испытателей, отражающие результаты сертификационных испытаний программного продукта;
- поставка для применения пользователями сертифицированной версии программ продукта;
- анализ результатов сертификации и усовершенствование процессов испытаний программного продукта.
Рис. 11.1
Характеристики программных комплексов имеют различные меры, вследствие чего они в большинстве своем непосредственно несопоставимы между собой. Они предварительно выбираются и устанавливаются заказчиком при последовательном, почти независимом анализе каждого требования, для использования в контракте и техническом задании. Для обобщенного оценивания качества программного продукта необходим учет относительного влияния каждой характеристики на функциональную пригодность.
При этом не всегда удается учитывать ресурсы для их реализации в конкретном комплексе программ.
Это часто приводит к выдвижению ряда нерациональных требований, которые значительно отличаются: либо по степени влияния на функциональную пригодность, либо по величине ресурсов, необходимых для их реализации.
Для целенаправленного эффективного управления сложным проектом целесообразно иметь механизм объединения разнородных характеристик в некоторый интегральный показатель, отражающий их совокупное влияние на его функциональную пригодность.
Таким образом, при разработке проекта выявилась проблема анализа системной эффективности программного продукта и обобщения его свойств в виде рисков, а также оценивания совместного влияния конструктивных характеристик на функциональную пригодность с учетом затрат на их реализацию.
Оценивание опасности рисков программного продукта и выбор эффективных контрмер для их сокращения включает:
· определение возможных последствий, уровней потенциальных опасностей – угроз, и приоритетов каждого класса и категории рисков проекта комплекса программ;
· выделение и упорядочение ограниченной группы наиболее опасных, высокоприоритетных рисков проекта комплекса программ;
· планирование методов и необходимых ресурсов для реализации эффективных контрмер при сокращении каждой категории опасных, приоритетных рисков проекта;
· анализ, определение стратегии и распределение ресурсов на контрмеры для сбалансированного сокращения интегрального риска проекта комплекса программ с учетом приоритетов опасных рисков;
· распределение ответственности специалистов за появление и/или реализацию сокращения конкретных опасных рисков проекта.
Для учета влияния рисков на функциональную пригодность и другие характеристики программного продукта, а также для выбора рациональных контрмер целесообразно ранжировать допустимые риски относительными величинами – приоритетами.
Величины и вероятности проявления рисков, а также ресурсы на контрмеры для их сокращения, желательно оценивать соизмеримыми экономически ми, стоимостными категориями, или унифицированными относи тельными количественными величинами – приоритетами. Аналогично, по такой же шкале экспертами целесообразно оценивать относи тельные затраты ресурсов, которые следует выделять на реализацию сокращения рисков.
Для каждого вида рисков отношение коэффициента влияния на функциональную пригодность к относительным затратам на его достижение можно рассматривать, как обобщенный приоритет этому сокращению риска.
Подобные рейтинги рисков с оценкой их вероятностей и последствий, особенно необходимы для оценивания, сбалансированного прогнозирования и последовательной минимизации интегральных рисков, а также для мониторинга различных контрмер в проектах комплексов программ. Интегральный риск проекта можно оценивать как результат обобщения всех видов рисков с учетом их относительного влияния на функциональную пригодность и другие важнейшие характеристики системы и программного продукта.
Для конкретного программного продукта состав и значения приоритетов следует поэтапно адаптировать и уточнять с учетом их назначения и функций. Наивысший приоритет можно интерпретировать как обязательное выполнение разработчиком соответствующего требования к указанной функции или характеристике с отсутствием риска. Такие, экспертные, качественные оценки позволяют прогнозировать и выявлять наиболее крупные и опасные риски, их долю в интегральном риске проекта комплекса программ и системы, а так же рентабельность контрмер для их снижения.
Для выбора критического уровня допустимых рисков необходимо исследовать особенности проблемно-ориентированной системы, возможную последовательность потенциально опасных событий, любые смягчающие факторы и характеристики, а также природу и частоту возможных негативных последствий идентифицированных угроз в программном продукте и в системе.
При этом для сбалансированного снижения интегрального риска, может оказаться эффективным сравнительное, количественное или качественное ранжирование рисков (присвоение им приоритетов) специалистами, хорошо информированными в проблемной области применения соответствующих систем.
Используя планы управления проектом и рисками, менеджер должен осуществлять распределение ресурсов тестирования и контр мер, направленных на преодоление негативных случайностей при функционировании. Для обеспечения требуемого качества комплекса программ необходима организация контрмер в процессе управления рисками.
Задача менеджера рисков состоит в тестировании для выявления и идентификации источников рисков, противоречий требований характеристик и ресурсов для их реализации и в предложении заказчику и разработчикам рациональных и возможных контрмер, обеспечивающих сокращение рисков до допустимых пределов.
Контрмеры для сокращения рисков можно разделить на три типа:
· сокращение или исключение первичных причин – угроз, дефектов и ошибок в компонентах и комплексе программ, обусловленных недостатками их требований, тестирования, разработки или модификации, отражающихся на рисках функциональной пригодности или характеристиках программного продукта;
· сокращение или ликвидация уязвимости компонентов и комплекса программ при воздействии на них угроз, дефектов и ошибок, путем тестирования и введения средств защиты для блокирования их возможного негативного воздействия на риски функционирования и применения программного продукта;
· непосредственное изменение и сокращение при тестировании последствий проявления рисков функциональной пригодности и ха рактеристик комплекса программ, путем их оперативного обнаружения и ликвидации ущерба при сохранении (возможно) вызывающих их первичных источников и причин.
Для выработки плана анализа рисков и применения контрмер при их сокращении должна быть определена и документально установлена методика применения последовательного анализа угроз, уязвимостей и изменения проявлений рисков. Если менеджеры проекта имеют достаточно большой опыт работы, а процессы развития проекта регламентированы и ведут себя предсказуемо, количество дефектов и угроз последовательно должно убывать и степень риска в ЖЦ проекта должна уменьшаться. После того как менеджеры проекта идентифицируют возможные риски в жизненном цикле комплекса программ, а также уточнят тактику применения контрмер по сокращению их влияния, возникает необходимость в идентификации уровня допустимости остаточного интегрального риска программного продукта.
На этапах проектирования заказчик совместно с разработчиком должны уточнить исходные требования к характеристикам комплекса программ и ограничения для ресурсов, которые могут быть использованы для его реализации и применения. Эти требования и ограничения могут не полностью выполняться на последующих этапах ЖЦ ПС, что приводит к ущербу у заказчиков и пользователей.
Причинами такого ущерба могут быть дефекты и ошибки, а также завышенные заказчиком требования к функциям и характеристикам, которые не могут быть реализованы при выделенных ресурсах, или недостаточное качество технологии и квалификация специалистов – разработчиков, исполняющих проект.
Для сокращения интегрального риска до допустимого значения возможно изменение требований к функциональным характеристикам и/или к используемым ресурсам в технологических процессах ЖЦ комплекса программ.
При этом для обеспечения требуемой функциональной пригодности и минимального интегрального риска разработчиками возможно применение первой стратегии контрмер сокращения рисков:
· изменение соотношения между отдельными, достигаемыми функциональными характеристиками программного комплекса в пределах согласованных требований, зафиксированных в техническом задании и спецификациях;
· изменение соотношения между используемыми видами ресурсов в пределах, заданных исходными ограничениями на их применение.
Таким образом, при управлении контрмерами рисков по первой стратегии необходимо обеспечить соответствие требованиям, достигнутых функциональных и конструктивных характеристик, которые были первоначально установлены в процессе их разработки. Для этого, могут быть перераспределены некоторые имеющиеся ресурсы с целью реализации требуемых отдельных характеристик, и тем самым, в частности, уменьшены риски, с наибольшими значениями или ограничены их последствия.
Однако если при первой стратегии не обеспечивается допустимый минимальный интегральный риск и требуемая функциональная пригодность, то по согласованию с заказчиком, разработчиками может применяться вторая стратегия контрмер сокращения рисков:
· пересмотр и изменение исходных требований к совокупности функциональных и конструктивных характеристик комплекса про грамм и уменьшение за счет этого результирующих значений рисков;
· пересмотр и изменение некоторых ограничений требуемых и используемых ресурсов и технологии обеспечения жизненного цикла программного комплекса для получения допустимых рисков.
При этой стратегии эффект может быть достигнут пересмотром и снижением требований к некоторым функциям и характеристикам программного продукта, определяющих наибольшие риски или увеличением отдельных доступных ресурсов и совершенствованием технологии, отражающихся на необходимом сокращении этих рисков.
Если интегральные риски обусловлены недостаточной вели чиной одного из видов ресурса, то приходится перераспределять доступные ресурсы или искать заказчику способы увеличения некоторого, критического ресурса.
В результате изменения характеристик комплекса и ресурсов, выделяемых на этапы их жизненного цикла, должны достигаться сбалансированные значения их рисков, и минимизироваться интегральный риск программного продукта и системы. В соответствие с их значениями следует откорректировать и утвердить обновленные, экономически и функционально оправданные, требования к функциям и характеристикам, используемым ресурсам и технологии проекта.
При обеих стратегиях наиболее стабильными должны быть требования к функциональной пригодности программного продукта, изменения которых допустимы при исчерпании возможностей сокращения интегральных рисков за счет изменения характеристик качества, используемых ресурсов и других контр мер.
Умение оценивать и обрабатывать риски является основным в деятельности любого менеджера проекта крупного программного продукта. Для менеджеров таких проектов эти навыки представляются важнейшими, поскольку упущения в этой сфере могут катастрофически влиять и блокировать усилия, направленные на ус пешное выполнение проекта всей системы, использующей программный продукт. В некоторых случаях процессы анализа и сокращения рисков могут быть упрощены]. Для этого целесообразно выделять и контролировать только отдельные (2 – 3) риски отклонения от требований, наибольшие по величине последствий и по вероятности негативного проявления, и минимизировать возможный в результате ущерб для функциональной пригодности системы (напри мер, риски надежности и производительности в комплексах программ реального времени).
Приоритет результатов выполнения контрмер и каждого предлагаемого изменения рисков комплекса программ, целесообразно оценивать по следующим критериям:
· насколько данное изменение риска может улучшить эксплуатационные характеристики и функциональную пригодность программного продукта в целом;
· каковы затраты на выполнение корректировок комплекса программ, вследствие изменения рисков при создании новой версии, и их распространение пользователям;
· какова срочность извещения пользователя о разработанной корректировке и целесообразно ли ее распространять до подготовки очередной версии программного продукта;
· для какого числа пользователей может быть полезно данное изменение риска;
· как данное изменение риска отразится на эксплуатации пользователями предыдущих версий программного продукта;
· насколько подготовка и внедрение данного изменения риска может отразиться на сроках создания очередной версии программного продукта.
Выше анализировалось и оценивалось преимущественно изме нение функциональной пригодности и снижение риска при совершенствовании характеристик программного продукта. Однако для заказчика и пользователей доминирующее значение могут иметь номенклатура и особенности реализации некоторых основных функций комплекса программ, которые, как правило, требуют наибольших за трат и определяют основной эффект и риск от применения программ ногопродукта, а также потенциальный уровень спроса на рынке.
Эксплуатационная документация должна обеспечивать эффективное применение программного продукта и точно отражать его назначение, функции, характеристики и требования, для использования квалифицированными специалистами – пользователями. Для этого эксплуатационные документы необходимо тестировать на полное соответствие выполнения всей совокупности требований на программный продукт, согласованных между разработчиками и заказчиком.
В результате эти документы можно использовать при производстве программных продуктов как отдельный, независимый третий эталон (кроме требований и тестов см. лекцию 7), для квалификационного тестирования и испытаний реализации функций и характеристик продукта. Практическое апробирование документов пользователями при применении комплекса программ, является практическим методом тестирования корректности реализации требований к программному продукту, завершающим цикл испытаний и контроля его качества.
Разработчики доку ментов должны обеспечивать комфортное и корректное применение комплекса программ пользователями, на основе ясного и непротиворечивого изложения в документах технологических процедур и операций для его штатного функционирования и получения требуемых результатов при эксплуатации.
Организация документирования должна определять стратегию, стандарты, процедуры, распределение ресурсов и планы создания, изменения и применения документов на комплекс программ.
Для этого в общем случае должны быть выделены специалисты, которые обязаны планировать, утверждать, выпускать, распространять и сопровождать комплекты апробированных и утвержденных эксплуатационных документов. Они должны стимулировать разработчиков программных средств, осуществлять непрерывное, регламентированное документирование процессов и результатов своей деятельности, а также контролировать полноту и качество утвержденных эксплуатационных и от четных документов.
Состав и содержание комплекта документов конкретного про граммного продукта, целесообразно адаптировать разработчиками к его особенностям и свойствам на основе использования стандартов и типовых структур – шаблонов для двух классов продуктов, которые в наибольшей степени различаются особенностями эксплуатации.
Первый класс составляют программные продукты автоматизированного управления динамическими объектами и процессами в реальном масштабе времени. В процессе их применения допускается минимальное вмешательство пользователями в процедуры управления применением, и необходим, соответственно, небольшой объем эксплуатационных документов, выделяемых из стандартизированного комплекта.
Для продуктов второго класса (административные системы) возможно применение пользователями широкого набора процедур управления, которые должны быть регламентированы достаточно полным набором и подробным содержанием документов.
Документация администрирования при эксплуатации системы должна обеспечивать поддержку первичной инсталляции, безопасного функционирования и восстановления программ и данных после сбоев. Администратор системы и программного продукта должен быть информирован о всех изменениях функционирования устройств системы и внешней среды, могущих привести к сбою или возникновению аварийной ситуации, и предпринимать соответствующие профилактические действия.
Для этого требуется полная информация о требованиях программному продукту, к компонентам системы и внешней среды, которые имеют свои особенности в управлении с по мощью специальных программных средств, поддерживающих администрирование и управление системой. Каждый из документов административного управления должен не противоречить международным стандартам на коммуникацию, интерфейсы с пользователями и база ми данных, на защиту и обеспечение безопасности информации.
Документация для оперативных пользователей программ ных продуктов в системе, их функционирования, обработки и анализа результатов должна обеспечивать взаимодействие пользователей с различными аппаратно-программными реализациями терминалов. Для этого необходима унификация концепции, архитектуры, функций и методов визуализации пользовательского интерфейса. Типовые формы-шаблоны документов и процедуры работы с ними, рассматриваемые как объекты стандартизации, относятся в основном к функциональному, оперативному уровню взаимодействия пользователей с системами и программными продуктами.
Стандарты ISO 15910 и ISO 18019 являются наиболее современными нормативными документами, регламентирующими процессы создания эксплуатационной документации для пользователей крупных программных продуктов. В них изложены детальные структуры пла нов документирования, ориентированных на разработчиков документов, соответствующих требованиям на программный продукт, и процедуры контроля реализации плана.
Эксплуатационная документация должна проходить испытания на достоверность, которые должны быть спланированы и реализованы на базе требований к функциям и характеристикам, а также к применению эксплуатационных процедур реального программного продукта.
Стандарты представляют разработчикам документации методы определения и применения процесса документирования при создании конкретного программного продукта.
Основной работой является создание комплексного плана разработки документации, реализация которого обеспечивает достоверное документирование программного продукта. Стандарты также определяют виды информации, представляемой заказчиком разработчику документации для тестирования, проверки и распространения документации.
Стандарты определят реализацию процесса документирования, описанного в ISO 12207, и могут быть адаптированы к условиям и требованиям конкретного проекта.
Минимальный состав документации определяется заказчиком (на пример, с использованием ISO 12207 и/или ISO 6592), что должно быть учтено при разработке плана документирования.
Описание требований эксплуатационной концепции для системы управления и программного продукта должно содержать действия пользователя, необходимые для работы с системой, ее связи с существующими системами и процедурами. Его используют при создании соглашения между поставщиком, разработчиком и пользователями. Данный документ фиксирует текущее состояние системы и программного продукта, назначение, требования, возможности и ограничения в зависимости от режима или конкретного состояния эксплуатации и включает описания:
· конкретной эксплуатационной среды и ее характеристики;
· основных компонентов и функций программного продукта, системы и связей между ними;
· внешних интерфейсов программного продукта и системы;
· возможностей, функций и характеристик программного продукта и системы;
· состава эксплуатационного персонала, его организационной структуры, уровня технической подготовки, обязанностей, взаимодействия;
· форм регистрации обнаруженных дефектов и ошибок;
· соглашений о внесении изменений, возникающих в процессе сопровождения версии программного продукта;
· концепцию поставки новой или модифицированной версии программного продукта, эксплуатационный сценарий;
· информацию о взаимодействии пользователей, поставщика, разработчика и предприятия, осуществляющего поддержку про граммного продукта, во время эксплуатационного периода.
В обязанности документаторов входит обеспечение плодотворных контактов заказчика с разработчиками программного продукта, гарантирующих понимание сути и требований к выпускаемой продукции и соответствующих ей аудиторий.
Обязанностью разработчика является обеспечение полноты, корректности и актуальности всех документов, предъявляемых разработчиком на момент их поставки. В ряде случаев требуется сохранить конфиденциальность и секретность пре доставленных материалов. В договоре должны быть установлены уровни (грифы) конфиденциальности или секретности материалов, представляемых заказчиком документатору.
План документирования должен включать определение ауди тории пользователей документации, уровня образования, квалификации, способностей, подготовки, опыта пользователей и другие характеристики, связанные с содержанием, структурой и использованием документации. Обычно имеется ряд различных групп пользователей, преследующих различные цели при пользовании конкретной документацией. Каждый тип пользователей, включая их характеристики и задачи, решаемые ими при помощи документации, должен определяться отдельно.
План документирования должен быть официально согласован и утвержден, что подтверждает полный учет и тестирование в доку ментах всех требований заказчика к программному продукту. Должны быть определены процессы тестирования и проверки, выполняемые при разработке документации. План документирования дол жен быть подготовлен и утвержден до начала разработки документации, чтобы гарантировать согласование всеми сторонами содержания поставленных задач и используемых в проекте методов. После утверждения плана он должен быть доведен до всех заинтересованных сторон, включая разработчиков документации, а также заказчика и суб-подрядчиков.
Проверка результатов выполнения плана должна проводиться заказчиком с привлечением документаторов. Целью проверки является гарантирование полноты и достоверности, представленных мате риалов и удовлетворения ими возможности выполнения требований заказчика к функциям и характеристикам программного продукта в соответствии с условиями договора и плана документирования.
Проверка должна проводиться персоналом заказчика, обладающим соответствующей квалификацией и полномочиями на изменения в доку
ментах и их утверждению. Заказчик должен хранить копии всех вносимых изменений для сравнения их с последующими проектами документов. Заказчики должны уделять особое внимание структуре, полноте и практичности документации в соответствии с планом-проспектом ее со держания. План документирования должен быть проверен и утвержден до начала работ над первым проектом документации.
Документатор должен обеспечить разработку документации так, чтобы допустить возможность внесения в нее корректировок всех типов. Для этого необходимо, чтобы разработчики документации полу чали учтенные копии изменений требований к программному продукту, подтверждающие внесение соответствующих изменений в данную версию после конкретной даты ее пересмотра.
Испытания эксплуатационной документации на практичность следует рассматривать как дополнение к проводимым проверкам и анализам документации.
При необходимости в плане документирования следует определить внешнюю среду тестирования, которая должна полностью соответствовать эксплуатационной среде конечного пользователя и требованиям к программному продукту. При проведении тестирования документации на практичность, необходимо проверить соответствие и актуальность документов конкретному программному продукту.
При сертификационных испытаниях может быть использовано для оценки практичности определения характеристик качества в стандартах ISO 9126 и ISO 25000.
Практичность - применимость: свойства программного продукта и документации, отражающие сложность их понимания, изучения и использования для квалифицированных пользователей при применении в указанных условиях. Требования к практичности и ее характеристикам - понятности и простоте использования, зависят от назначения и функций продукта и могут формализоваться заказчиками набором свойств, необходимых для обеспечения удобной и комфортной эксплуатации.
Для обеспечения полноценного изучения процессов применения программного продукта специалистами необходима эксплуатационная документация, объем которой существенно зависит от назначения и функций, и может быть задан на основе анализа прецедентов подобных успешных проектов.
Для некоторых проектов, подлежащих широкому тиражированию, могут быть желательны адекватные по содержанию электронные учебники, требования к объему и функциям которых целесообразно оценивать также по прецедентам.
Следует учитывать, что малый объем эксплуатационной документации может снизить качество и полноту использования функций сложного продукта, а очень большой объем – также может ухудшить эксплуатацию из-за трудности выделения из множества второстепенных деталей и освоения, наиболее существенных свойств и особенностей его применения.
В практичности следует учитывать все разнообразие характеристик внешней среды пользователей, на которые может влиять продукт, включая требующуюся подготовку к использованию и оценке результатов функционирования комплекса программ.
Применимость (практичность) использования программного продукта и документации - понятие достаточно субъективное и трудно формализуемое, однако в итоге зачастую значительно определяющее функциональную пригодность и эффективность применения продукта.
В эту группу показателей входят атрибуты с различных сторон, отражающие функциональную понятность, удобство освоения или простоту использования. Некоторые характеристики можно оценивать экономическими показателями - затратами труда и времени специалистов на реализацию соответствующих функций.
Понятность: свойства, обеспечивающие пользователю пони мание документации, является ли программный продукт пригодным для его целей, и как его можно использовать для конкретных задач и условий применения.
Понятность зависит от качества документации и субъективных впечатлений от функций и характеристик программного продукта. Ее можно описать качественно четкостью функциональной концепции, широтой демонстрационных возможностей, пол нотой, комплектностью и наглядностью представления в эксплуатационной документации возможных функций и особенностей их реализации.
Простота использования: возможность пользователю удобно и комфортно эксплуатировать и управлять программным продуктом. Аспекты изменяемости, адаптируемости и легкости инсталляции могут быть предпосылками для простоты использования и выбора конкретного продукта.
Она соответствует управляемости, устойчивости к ошибкам и согласованности с ожиданиями и навыками пользователей. Эта характеристика учитывает физические и психологические особенности пользователей и отражает уровень комфортности условий эксплуатации, возможность предотвращения ошибок пользователей.
Кроме того, удобство использования характеризуется рядом динамических параметров: временем ввода и отклика на задание, дли тельностью решения типовых задач, временем на регистрацию результатов, которые перекрываются с динамическими характеристиками временной эффективности.
Простоту использования комплексов программ административных систем, в значительной степени, характеризует корректность и адекватность описаний интерактивных директив управления, объем и время ввода заданий, и время ожидания пользователями результатов при их исполнении.
Однако некоторые атрибуты этой характеристики доступны для более полной количественной оценки путем измерения трудоемкости и длительности соответствующих процессов подготовки и обучения квалифицированных пользователей к полноценной и эффективной эксплуатации программного продукта.
Изучаемость: свойства программного продукта и документации, обеспечивающие удобное освоение его применения достаточно квалифицированными пользователями. Она может определяться трудоемкостью и длительностью подготовки пользователя к полноценной эксплуатации продукта. Качество изучаемости зависит от внутренних свойств и сложности комплекса программ и документов, а также от субъективных характеристик квалификации конкретных пользователей.
На значения изучаемости существенно влияют демонстрационные возможности справочных средств обучения, качество и объем эксплуатационной документации.
Приобретение, поставка, разработка, функционирование и со провождение программных продуктов, в большой степени, зависит от квалификации персонала.
Поэтому в проекте программного продукта обязательно должно быть запланировано и осуществлено обучение с целью подготовки работы персонала при его приобретении, поставке, разработке или сопровождении.
Для достижения высокого качества программной документации она должна рассматриваться как неотъемлемая часть процесса создания и испытаний программного продукта.
Затраты на создание достаточно полного комплекта эксплуатационной документации практически пропорциональны размеру комплекса программ. Удельные затраты на документацию зависят от класса, назначения и широты применения программного продукта, что трудно учесть в достаточно общем виде.
Эти затраты сопутствуют в некоторой степени всем этапам разработки, однако, оформление эксплуатационных документов обычно локализуется в специиальном этапе работ. Затраты на разработку комплекта эксплуатациионной документации для сложных программных продуктов, подлежащих длительному сопровождению, обычно определяются затрата ми на объем текста документов ориентировочно 5 – 10 страниц на тысячу строк программы.
Предъявляемый заявителем на сертификацию программный продукт должен представляться в комплекте с соответствующей документацией. Перечень и содержание группы этих документов ниже ориентированы на общий случай удостоверения качества версий сложных программных продуктов реального времени.
Комплект документов может сокращаться и адаптироваться по согласованию между заявителем, сертификаторами и руководством производства в соответствии с характеристиками программных продуктов.
Некоторые документы могут объединяться в интегрированные отчеты с чет кой ответственностью определенных специалистов за их выполнение.
Ориентировочный комплект основных документов при сертификации программного продукта состоит из трех групп:
· базовые нормативные документы характеристик качества программных продуктов и их производства, а также подготовленные разработчикам на их основе Программа, Руководство и инструкции, предъявляемые испытателями сертифицирующей организации для испытаний версии программного продукта – рис. 11.2;
· исходные документы, отражающие результаты предвари тельных испытаний и характеристики сертифицируемого программного продукта, подготавливаемые руководством производства продукта (заявителем) для сертификации его качества – рис. 11.3;
· результирующие документы сертификационных испытаний версии программного продукта, представляемые органу сертификации, заявителю и руководству производства для утверждения сертификата и знака качества – рис. 11.4.
Состав и содержание базовых нормативных документов для сертификации программных продуктов зависят от требований к их качеству, а также от характеристик проектирования, разработки и модификации программных средств и особенностей технологической среды. Поэтому необходимый комплект документов для каждого предприятия или проекта следует выбирать и адаптировать – создавать профиль стандартов, применительно к этим характеристикам.
Заявитель должен подготовить и предъявить испытательной лаборатории согласованный между заказчиком и разработчиком и утвержденный комплект исходных документов для проверки их достоверности, достаточности состава и качества изготовления в соответствии с нормативными документами (см. рис. 11.2).
При подготовке для сертификационных испытаний про граммного продукта в составе системы руководителями производства следует зафиксировать результаты :
· завершена разработка всех функций комплекса программ и исправление всех выявленных ошибок;
· все функциональные компоненты размещены под формальный автоматизированный контроль системы управления конфигурацией компонентов проекта;
· тестирование всех функций и исправление всех выявленных дефектов в версии программного продукта;
· подготовлена полная версия программного продукта с контролируемыми изменениями после предварительных испытаний;
· версия программного продукта сопровождается технологической и эксплуатационной документацией, перечнем изменений, со держит список отчетов о дефектах, которые исправлены в версии;
· предоставлена контролируемая полная версия программного продукта, которая установлена в тестовой внешней среде, стабильно функционирует и позволяет получать поддающиеся интерпретации результаты испытаний;
· проведены совещания, посвященные управлению незавершенными работами по устранению дефектов и оценки времени для исправления дефектов;
· в предшествующий, согласованный с заказчиком интервал времени, не произошло сбоев, остановки, неожиданного прекращения процесса или другой аномалии функционирования комплекса про грамм на объектной ЭВМ в системе;
· анализ функционирования продукта показал, что комплекс программ достиг приемлемого уровня качества, стабильности, надежности и безопасности;
· оценки покрытия требований и допустимых рисков показали, что все риски сокращены до допустимых пределов;
· группа управления продуктом и системой установила, что программный продукт, как это определено в ходе заключительного цикла предварительных испытаний, удовлетворяет требованиям заказчика и пользователей;
· проведено совещание разработчиков с заказчиком и установлено, что критерии завершения предварительных испытаний программного продукта выполнены, и его можно предъявить для сертификационных испытаний.
Завершаются предварительные испытания предъявлением заказчику на утверждение комплекта документов, содержащих результаты необходимые для сертификационных испытаний вер сии программного продукта (см. рис. 11.3).
Кроме того, целесообразно подготавливать факультативно, по согласованию, для заказчика и пользователей следующие документы:
· документацию средств автоматизации проектирования, производства, модификации, контроля и предварительных испытаний программного продукта;
· тесты, сценарии и генераторы динамических тестовых данных, использованные для предварительных испытаний программных компонентов и версии продукта в целом;
· результаты и протоколы предварительных испытаний, функциональные и конструктивные характеристики программного продукта в реальной внешней среде;
· отчет о подтверждении заданного качества, полные характеристики достигнутого качества функционирования, а также степени покрытия тестами спецификации требований к программному продукту;
· план, методики и средства автоматизации обучения заказчика и пользователей применению испытанной версии программного продукта;
· технические условия на версию программного продукта, базу данных управления конфигурацией и эксплуатационную документацию для тиражирования и серийного производства;
· руководство по генерации и инсталляции пользовательских версий и загрузке базы данных в соответствии с условиями и характеристиками внешней среды;
· отчет о технико-экономических показателях производства за вершенной версии программного продукта, выполнении планов и ис пользованных ресурсах;
· акт о завершении предварительных испытаний и готовности к поставке и/или предъявлению для сертификационных испытаний версии программного продукта.
На завершающих этапах предварительных испытаний, когда, как правило, на группу тестирования оказывают давление руководители для ускорения и окончания работ, разработчикам полезно иметь в своем распоряжении документ, в котором оговариваются все требования и дополнения заказчика, которые планируется испытать. Специалисты склонны забывать, какие соглашения и требования бы ли достигнуты, а также планы проведения предварительных испытаний. Если проблема возникнет в области, которая не подвергалась тестированию в соответствии с планом и Программой, она должна быть устранена и проверена после выпуска очередной версии программного продукта.
Отчетный доклад о результатах предварительных испытаний должен содержать перечень всех не устраненных дефектов, с соглашением и планом того, будут ли они исправлены в более поздних версиях или же их исправление откладывается на неопределенное время. Необходимо вести наблюдение за такими дефектами, чтобы не тратить дополнительные усилия на их выявление в будущих версиях продукта.
Принимая решение прекратить работы по предварительным испытаниям, руководителям производства следует учитывать несколько факторов, которые играют важную роль при оценке неготовности программного продукта к поставкам:
· количество катастрофических дефектов, обнаруженных в процессе тестирования, которые остаются неисправленными;
· общее количество возможных предсказуемых дефектов, кото рые не были исправлены;
· процентное отношение количества тестов, которые завершились успешным исходом и устранением дефектов, к числу всех за планированных тестов.
· время, отведенное на испытания, истекло, хотя неизвестно достигнутое качество программного продукта, однако любой другой метод прекращения испытаний может давать большую уверенность в качестве сертифицируемого или поставляемого программного про дукта;
· завершены все запланированные циклы тестирования, и план проведения испытаний выполнен, тестовое покрытие лучше, чем в случае, когда просто не хватило времени для доведения тестирования до логического конца;
· профиль устраненных дефектов соответствует критерию вы хода из испытаний и возможное количество не устраненных ошибок на тысячу строк программного кода достигнуто.
С целью выработки оценки готовности версии программного продукта к сертификации следует проводить специальные совещания разработчиков и заказчика.
В некоторых предприятиях оценку готовности определяет группа тестирования; в других организациях со вещание проводит руководитель проекта системы, либо руководитель производства и заказчик программного продукта. В любом случае в задачу группы тестирования и испытаний входит представление результатов и выработка рекомендаций относительно готовности продукта к поставкам для сертификации.
С самого начала проекта необходимо определить, что следует считать успешным прохождением стадии предварительных испытаний, и соответствия исходным требованиям заказчика, когда можно прекратить испытания продукта и начать его поставку или сертификацию.
Результатом сертификационных испытаний должен быть комплект отчетных документов (см. рис. 11.4) и подтверждение результатов, зафиксированных при предварительных испытаниях – рис. 11.2 и 11.3. При сертификационных испытаниях программного продукта целесообразно выборочно или полностью использовать результаты предварительных испытаний с учетом их полноты и достоверности. Утверждение этого комплекта документов для конкретного программного продукта дает право на присвоение ему сертификата и знака качества.
После завершения испытаний новой версий программного продукта, обычно осуществляется процесс ее внедрение для применения (см. рис. 11.1).
Это производится, как правило, в два этапа; силами разработчиков версии в целях обкатки, проверки и выявления ошибок в изменениях на этапе опытной эксплуатации, и/или по средством использования специализированных коллективов сопровождения, для тиражирования и распространения версий программного продукта.
Основные обязанности специалистов сводятся к пере даче физических носителей с текстами программ и комплектом эксплуатационной документации, а также к проведению консультаций для выделенной группы специалистов заказчика и пользователей.
Разработчики и испытатели в этом случае получают возможность не посредственно контролировать работу пользователей с системой и документацией, что обеспечивает высокую оперативность отработки замечаний и рекламаций, формирование квалифицированных предложений для изменений, оценку эффективности применения версии программного продукта.
Кроме того, должны разрабатываться учебно-методический план, подготавливаться учебные пособия, не обходимые для обучения пользователей, а также проводиться обучение выделенной группы специалистов, ответственных за последующее обучение коллективов пользователей.
В процессе жизненного цикла большое значение имеет история эксплуатации программного продукта, развития его версий и соответствующая документация. Еще на стадии проектирования первой версии могут возникать идеи совершенствования комплекса про грамм, которые в то время невозможно реализовать из-за высокой стоимости, ограниченных сроков проектирования или по иным причинам.
Идеи изменения могут быть направлены на коренное улучшение функциональных возможностей программ или некоторые «косметические» улучшения реализуемых функций. Идеи небольших корректировок программ целесообразно накапливать отдельно от предложений по существенному совершенствованию программного продукта. Таким образом, должен создаваться документ - исходные данные для изменения требований и планирования доработок в процессе сопровождения, содержащий разделы:
· выявленные дефекты и ошибки в программном продукте;
· предложения по совершенствованию функций и улучшению качества эксплуатируемых версий программного продукта;
· идеи и предполагаемая экономическая эффективность коренной модернизации, расширения функций и улучшения характеристик версии программного продукта.
После внесения изменений в требования специалисты разрабатывают и испытывают конкретные корректировки программного продукта. Специалисты должны провести проверки каждого внесенного изменения совместно с заказчиком, утвердившим изменение в целях подтверждения целостности и работоспособности измененного программного продукта.
Получить подтверждения того, что внесенные изменения удовлетворяют требованиям заказчика, установленным в договоре, посредством вспомогательного процесса испытаний качества, проведения аудита функциональной и физической конфигурации. Результатами данной работы являются: новая версия программного продукта, включающая в себя принятые изменения требований; от клоненные изменения; отчет о приемке версии; отчеты о проверках и аудитах; отчет об испытаниях откорректированного программного продукта.
Снятие сертифицированной версии программного продукта с эксплуатации и развития версий должны быть подготовлены анализом, обосновывающим это решение.
В анализе следует определить и экономически обосновать: возможность сохранения устаревшей версии комплекса программ, а также необходимость создания и применения новой версии программного продукта. При снятии программного продукта с сопровождения следует определить необходимые для этого действия, а затем разработать и документально оформить этапы работ, обеспечивающие их эффективное выполнение.
Должны быть предусмотрены возможности доступа к полным архивным документам снятого с сопровождения программного продукта.
По окончании разработки версии программного продукта специалистам полезно изучить ход выполнения Программы сертификационных испытаний, чтобы определить, каким образом можно ее усовершенствовать, и в следующем проекте получить преимущества. Испытатели должны постоянно изучать данные, получаемые специалистами контроля качества, и следовать их рекомендациям по исправлению дефектов.
Кроме того, на протяжении всего жизненного цикла комплекса программ целесообразно документировать полученные уроки и оценивать их на каждом промежуточном рубеже испытаний. Измерения, сделанные в процессе тестирования и, особенно, на этапе исполнения тестов, помогут акцентировать внимание на определенных видах требований и конкретных проблемах, требующих решения.
С целью улучшения результатов, испытатели должны периодически диагностировать качество проделанной работы, из меняя при необходимости привычные способы их ведения. Зафиксированные на этом этапе уроки могут оказаться полезными при производстве и проведении испытаний в дальнейшем.
Полученные уроки, оценки измерений характеристик программного продукта, любые связанные с этим действия по устранению недостатков или по совершенствованию работ, должны документироваться на протяжении всего процесса испытаний в централизованной базе данных конфигурационного управления требованиями и тестами.
Наличие отвечающей современным требованиям базы данных, содержащей спецификации требований, применявшиеся тесты, важные проблемы и полученные уроки, позволяет специалистам, занятым в данном проекте, следить за ходом работ и состоянием проблем вплоть до его полного завершения. Для каждого урока желательно указывать измерение, демонстрирующее потенциальный выигрыш (сэкономленные часы труда), если бы было применено определенное действие по совершенствованию процесса. После завершения тестирования специалисты должны сопоставить фактическую реализацию Программы сертификационных испытаний с запланированными критериями.
Усовершенствование процессов сертификационных испытаний целесообразно выполнять итеративно. Испытателям следует выяснять, повторялись ли те или иные дефекты и ошибки, и подтверждать, были ли упущены из виду какие-либо предложения по совершенствованию испытаний. При изучении реализации Программы испытаний следует концентрировать внимание на оценке того, удовлетворяет ли комплекс программ критериям завершения тестирования, и готов ли он к поставкам. Испытатели должны освоить непрерывный итерационный процесс изучения полученных уроков как часть развития культуры тестирования. После сбора полученных уроков и других измерений, и определения корректирующих действий испытатели должны оценивать эффективность Программы испытаний.
Отказ комплекса программ при выполнении тестовой процедуры не всегда вызван его дефектами. Проблема может представлять со бой ложный отрицательный результат, означающий, что тест за вершился неудачей, хотя в тестируемом программном продукте не было ошибки. Случаи ложных отрицательных результатов могут возникать из-за изменений в программах, ошибок в настройке теста, ошибок тестовых процедур, ошибок испытателя, логических ошибок автоматизированного динамического теста или ошибок настройки внешней среды. Если ряд ложных отрицательных результатов указывает на дефект, допущенный при разработке тестовых процедур, неизбежно усовершенствование процесса их создания.
Даже в случае совпадения полученных результатов с ожидаемы ми эталонами, испытателям необходимо убедиться в отсутствии эффекта ложных положительных результатов, когда кажется, что тестовая процедура выполнена успешно, но на самом деле существует проблема, связанная с комплексом программ. Испытатели должны внимательно следить за появлением ложных положительных результатов, к которым может приводить использование инструментов автоматизированного тестирования, недостаточно чувствительных к нюансам конкретного комплекса программ. Наряду с критическим просмотром или экспертной оценкой тестовых процедур, группа тестирования должна оценивать и осуществлять выборочную проверку результатов тестирования даже в том случае, если тест завершился успешно.
Группа тестирования должна выявлять те компоненты и функции, по которым было составлено самое большое число отчетов о проблемах. Такой анализ может указать на необходимость проведения дополнительного тестирования для проверки этих компонентов. Если разработчики заявляют, что дефекты в определенной функциональной области ликвидированы, а регрессионное тестирование обнаруживает там дефекты, испытатель должен выяснить, проблемы заключаются во внешней среде или неудачно реализованы исправления в программном продукте. Кроме того, анализ поможет опреде лить функциональность, с которой связано наибольшее количество обнаруженных дефектов, на чем необходимо сосредоточиться при дальнейшем тестировании и исправлении ошибок.
При необходимости испытатели должны помочь разработчикам понять и воспроизвести дефекты системы и/или программного продукта. Каждый дефект обычно ранжируется в зависимости от приоритета. После того как разработчики устранят выявленные дефекты, испытатели должны провести регрессионное тестирование продукта с целью проверки, можно ли считать тот или иной отчет о проблеме закрытым. После этого отправляется уведомление заинтересованным членам группы управления конфигурацией и группы разработчиков программного продукта, в котором сообщается о по явлении нового отчета о проблеме.
СТАНДАРТЫ, РЕГЛАМЕНТИРУЮЩИЕ ТРЕБОВАНИЯ, ЖИЗНЕННЫЙ ЦИКЛ, ИСПЫТАНИЯ И СЕРТИФИКАЦИЮ КОМПЛЕКСОВ ПРОГРАММ
1. CMMI - Capability Maturity Model Integration for Product and Procеss Development - Интегрированная модель оценивания зре лости продуктов и процессов разработки программных средств.
2. ISO 15288:2002. Системная инженерия. Процессы жизненного цикла систем.
3. ISO 19760:2003. – Системная инженерия. Руководство по приме нению стандарта ISO 15288.
4. ISO 12207:2008. ИТ. Процессы жизненного цикла программных средств.
5. ISO 15271:1998. (ГОСТ Р – 2002). ИТ. Руководство по примене нию ISO 12207.
6. ISO 16326:1999. (ГОСТ Р – 2002). ИТ. Руководство по примене нию ISO 12207 при административном управлении проектами.
7. ISO 15504:15:20032006. ИТ. Процесс аттестации. Ч.1. Концеп ция и словарь. Ч. 2. Выполнение аттестации. Ч. 3. Руководство по производству аттестации. Ч. 4. Руководство пользователей для процессов усовершенствования и определения зрелости процес сов. Ч. 5. Образец модели процессов аттестации.
8. ГОСТ Р 51904 – 2002. Программное обеспечение встроенных сис тем. Общие требования к разработке и документированию.
9. ISO 9000:2000. (ГОСТ Р – 2001). Система менеджмента (админи
стративного управления) качества. Основы и словарь.
10. ISO 9001:2000. (ГОСТ Р – 2001 ). Система менеджмента (админи
стративного управления) качества. Требования.
11. ISO 9004:2000. (ГОСТ Р – 2001). Система менеджмента (админи стративного управления) качества. Руководство по улучшению деятельности.
12. ISO 90003:2004 – Руководство по применению стандарта ISO 9001:2000 к программным средствам.
13. ГОСТ Р 40.003:2005 – Порядок сертификации систем менеджмен та качества на соответствие ГОСТ Р ИСО 9001 – 2001.
14. Система сертификации ГОСТ Р. Временный порядок сертифи кации производств с учетом требований ГОСТ Р ИСО 9001 – 2001.
15. Руководящие указания по аудиту систем менеджмента качества
16. ISO 10005: 2005. (ГОСТ Р – 2007). Менеджмент организации (Ад министративное управление качеством). Руководящие указания по планированию качества.
17. ISO 10006: 1997. (ГОСТ). Руководство по качеству при управле нии проектом.
18. ISO 10007: 2007. (ГОСТ Р – 2007). Административное управление качеством. Руководящие указания при управлении конфигураци ей.
19. ISO 10013: 2001. (ГОСТ Р – 2007). Менеджмент организации (Ад министративное управление качество). Руководство по докумен тированию систем менеджмента качества.
20. ISO 12182:1998. (ГОСТ Р– 2002). ИТ. Классификация программ ных средств.
21. ISO 9126:1991. (ГОСТ – 1993). ИТ. Оценка программного продук та. Характеристики качества и руководство по их применению.
22. ISO 912614: 2002. ИТ. ТО. Качество программных средств: Ч.1. Модель качества. Ч.2. Внешние метрики. Ч. 3. Внутренние метри ки. Ч. 4. Метрики качества в использовании.
23. ISO 1459816:19982000. Оценивание программного продукта. Ч.1. Общий обзор. Ч.2. Планирование и управление. Ч. 3. Процес сы для разработчиков. Ч.4. Процессы для покупателей. Ч.5. Про цессы для оценщиков. Ч.6. Документирование и оценивание моду лей.
24. ISO 25000:2005 ТО. – Руководство для применения новой серии стандартов по качеству программных средств на базе обобщения стандартов ISO 9126:14: 2002 и ISO 14598:16:19982000.
25. ISO 15939: 2002 – Процесс измерения программных средств.
26. IEC 61508:16: 19982000. Функциональная безопасность элек трических / электронных и программируемых электронных сис тем. Часть 3. Требования к программному обеспечению. Часть 6.
Руководство по применению стандартов IEC 615082 и IEC 615083.
27. ISO 15408 13. 1999. (ГОСТ Р – 2002). Методы и средства обеспе чения безопасности. Критерии оценки безопасности информаци онных технологий. Ч.1. Введение и общая модель. Ч. 2. Защита функциональных требований. Ч. 3. Защита требований к качеству.
28. ISO 13335 15. 19961998. ИТ. ТО. Руководство по управлению безопасностью. Ч.1. Концепция и модели обеспечения безопасно сти информационных технологий. Ч.2. Планирование и управле ние безопасностью информационных технологий. Ч.3. Техника управления безопасностью ИТ. Ч.4. Селекция (выбор) средств обеспечения безопасности. Ч.5. Безопасность внешних связей.
29. ISO 10181: 17. ВОС. 19961998. Структура работ по безопасности в открытых системах. Ч.1. Обзор. Ч.2. Структура работ по аутен тификации. Ч.3. Структура работ по управлению доступом. Ч.4. Структура работ по безотказности. Ч.5. Структура работ по кон фиденциальности. Ч.6. Структура работ по обеспечению целост ности. Ч.7. Структура работ по проведению аудита на безопас ность.
30. ISO 14252:1996 (IEEE 1003.0). Руководство по функциональной среде открытых систем POSIX.
31. ISO 9945:14:2003 – ИТ. Интерфейсы переносимых операционных систем. Ч.1. Базовые определения. Ч.2. Системные интерфейсы. Ч.3. Команды управления и сервисные программы. Ч. 4. Обосно вание.
32. ISO 13210:1994. ИТ. Методы тестирования для измерения соот ветствия стандартам POSIX.
33. ISO 14756: 1999. ИТ. Измерение и оценивание производительно сти программных средств компьютерных вычислительных систем.
34. ISO 12119:1994. (ГОСТ Р – 2000 г). ИТ. Требования к качеству и тестирование.
35. ISO 14764: 1999. (ГОСТ Р – 2002). ИТ. Сопровождение программ ных средств.
36. ISO 15846:1998. ТО. Процессы жизненного цикла программных средств. Конфигурационное управление программными средства ми.
37. ISO 16085: 2004 – Характеристики процессов управление рисками при разработке, применении и сопровождении программных средств.
38. ISO 6592:2000 ОИ. – Руководство по документации для вычисли тельных систем.
39. ISO 9294:1990 (ГОСТ-1993). TO. ИТ. Руководство по управлению документированием программного обеспечения.
40. ISO 9127:1990 (ГОСТ-1993). TO. ИТ. Руководство по управлению документированием программного обеспечения.
41. ISO 15910:1999 (ГОСТ Р – 2002) ИТ. Пользовательская докумен тация программных средств.
42. ISO 18019:2004 ИТ. Руководство по разработке пользовательской документации на прикладные программные средства для офисов, бизнеса и профессиональных применений.
43. ГОСТ Р 519012002. Управление надежностью. Анализ риска технологических систем.
44. DO178 B 1995. Соглашение по сертификации бортовых систем и оборудования в части программного обеспечения.
КОТРОЛЬНЫЕ ВОПРОСЫ
Общие вопросы и введение
1. На какие две группы условно делятся основные характеристики программного продукта при сертификационных испытаниях?
2. Какие свойства программного продукта проявляются при испытаниях рисков и эксплуатационных характеристик?
3. С каких двух позиций можно оценивать требования к программным продуктам?
4. К каким негативным последствиям может привести несбалансированное установление требований к характеристикам ПП?
5. Что такое интегральный показатель и для чего он нужен в управлении сложным проектом?
Испытания для
сокращения и ликвидации опасных рисков
6. Что включает в себя процесс оценивания опасности рисков и выбора контрмер?
7. Почему для учета влияния рисков целесообразно использовать относительные
величины — приоритеты?
8. Что такое обобщенный приоритет сокращению риска и как он рассчитывается?
9. Для каких целей необходимы рейтинги рисков с оценкой их вероятностей и последствий?
10. Что необходимо исследовать для выбора критического уровня допустимых
рисков?
11. Какова основная задача менеджера рисков в проекте?
12. Назовите три типа контрмер для сокращения рисков.
13. В чем заключается суть контрмер первого типа (первичные причины)?
14. В чем заключается суть контрмер второго типа (уязвимость)?
15. В чем заключается суть контрмер третьего типа (проявление рисков)?
16. Что должна определять методика применения последовательного анализа рисков?
17. При каких условиях степень риска в ЖЦ проекта должна уменьшаться?
18. Что такое остаточный интегральный риск и когда возникает необходимость его
идентификации?
19. Назовите две стратегии контрмер сокращения рисков, применяемые
разработчиками.
20. В чем заключается первая стратегия контрмер сокращения рисков?
21. В чем заключается вторая стратегия контрмер сокращения рисков и когда она
применяется?
22. Какие требования должны оставаться наиболее стабильными при обеих
стратегиях снижения рисков?
23. Почему для менеджера проекта крупного ПП умение оценивать и обрабатывать
риски является важнейшим?
24. В каких случаях процессы анализа и сокращения рисков могут быть упрощены?
25. По каким шести критериям целесообразно оценивать приоритет результатов
выполнения контрмер?
Испытания эксплуатационной
документации
26. Какую роль должна выполнять эксплуатационная документация для
пользователей?
27. Что является «третьим эталоном» для квалификационного тестирования, кроме
требований и тестов?
28. Каковы обязанности специалистов по организации документирования?
29. На основе чего целесообразно адаптировать состав и содержание документов
для конкретного ПП?
30. На какие два класса делятся программные продукты по особенностям
эксплуатации?
31. Охарактеризуйте первый класс программных продуктов (реального времени).
32. Охарактеризуйте второй класс программных продуктов (административные
системы).
33. Какую поддержку должна обеспечивать документация администрирования?
34. Какую поддержку должна обеспечивать документация для оперативных
пользователей?
35. Какие международные стандарты являются наиболее современными для создания
эксплуатационной документации?
36. Что является основной работой при создании документации согласно
стандартам?
37. Что должно содержать описание требований эксплуатационной концепции?
38. В чем заключаются обязанности документаторов по налаживанию контактов?
39. Что должно включать в себя определение аудитории пользователей
документации?
40. Что подтверждает официальное утверждение плана документирования?
41. Кто и с какой целью проводит проверку результатов выполнения плана
документирования?
42. Что должно быть обеспечено разработчиком документации для возможности
внесения корректировок?
43. Что такое испытания эксплуатационной документации на практичность?
44. Какие стандарты могут быть использованы для оценки практичности?
45. Дайте определение практичности (применимости) программного продукта и
документации.
46. Какие факторы влияют на требуемый объем эксплуатационной документации?
47. Какие негативные последствия может иметь как слишком малый, так и слишком
большой объем документации?
48. Что включает в себя понятие «понятность» документации и ПП?
49. Что включает в себя понятие «простота использования»?
50. Что характеризует изучаемость ПП и документации и от чего она зависит?
51. Почему обучение пользователей является обязательным элементом проекта ПП?
52. Как соотносятся затраты на создание документации с размером комплекса
программ?
53. Каковы ориентировочные затраты на разработку документации для сложных ПП?
Завершение сертификационных
испытаний
54. На какие три группы делятся основные документы при сертификации ПП?
55. От чего зависит состав и содержание базовых нормативных документов для
сертификации?
56. Что такое «профиль стандартов»?
57. Каковы ключевые результаты, которые должны быть зафиксированы
руководителями производства перед сертификацией?
58. Что подтверждает готовность ПП к сертификационным испытаниям?
59. Какие факультативные документы могут подготавливаться для заказчика и
пользователей?
60. Почему полезно иметь документ, оговаривающий все требования и дополнения
заказчика?
61. Что должен содержать отчетный доклад о результатах предварительных
испытаний?
62. Какие факторы играют важную роль при оценке неготовности ПП к поставкам?
63. Назовите три критерия выхода из предварительных испытаний и готовности
версии ПП к сертификации.
64. Кто и как должен проводить оценку готовности версии ПП к сертификации?
65. Что является результатом успешных сертификационных испытаний?
Поставка пользователям
и анализ результатов
66. Как обычно осуществляется процесс внедрения новой версии ПП?
67. В чем заключаются основные обязанности специалистов при поставке
сертифицированной версии?
68. Какую пользу разработчикам и испытателям дает непосредственный контроль за
работой пользователей?
69. Что должен содержать документ «исходные данные для изменения требований»?
70. Какие действия должны быть выполнены после внесения изменений в требования?
71. Что должно быть подготовлено для обоснования решения о снятии версии ПП с
эксплуатации?
72. С какой целью полезно изучать ход выполнения Программы сертификационных
испытаний после завершения проекта?
73. Где должны документироваться полученные уроки и оценки измерений?
74. Что такое «ложный отрицательный результат» при тестировании и каковы его
возможные причины?
75. Что такое «ложный положительный результат» и почему за ним нужно
внимательно следить?
76. Как группа тестирования должна использовать анализ отчетов о проблемах?
77. В чем должна заключаться помощь испытателей разработчикам при воспроизведении
дефектов?
78. Каковы основные этапы процесса усовершенствования сертификационных
испытаний?
ЗАДАНИЯ
Задача 1. Несбалансированные требования в критической системе
· Ситуация: Компания-разработчик заключила контракт на создание системы управления для финансового учреждения. Заказчик, стремясь к идеалу, сформулировал в Техническом Задании (ТЗ) одновременно максимально высокие и равнозначные требования к производительности (время отклика < 100 мс), надежности (доступность 99.99%) и безопасности (соответствие ISO 15408). Бюджет проекта жестко ограничен, а сроки сдачи поджимают. Команда разработки в панике, так как понимает, что достичь всех целей одновременно невозможно.
· Вопросы для анализа:
1. Опишите системные последствия, к которым приведет попытка выполнить все требования одновременно, с точки зрения распределения ресурсов ЖЦ и итогового качества продукта.
2. Какой механизм, описанный в лекции, должен быть применен для преобразования разнородных требований в управляемый формат? Детально опишите процесс его применения.
3. Кто (какие роли: менеджер проекта, заказчик, системный архитектор) должен участвовать в приоритизации этих требований и согласовании допустимых компромиссов? Какую аргументацию они должны использовать?
Задача 2. Кризис управления рисками в авиационном ПО
· Ситуация: При создании бортового программного обеспечения для нового авиалайнера в Реестре рисков идентифицировано 75 потенциальных угроз, ranging от некритичных багов интерфейса до потенциальных отказов системы навигации. Совет директоров требует от менеджера рисков предоставить обоснованный план распределения ограниченного бюджета на контрмеры.
· Вопросы для анализа:
1. Пошагово опишите алгоритм, приведенный в лекции, для выделения и упорядочивания наиболее опасных рисков из всего списка.
2. Помимо классической матрицы "Вероятность/Последствия", какие дополнительные критерии (например, влияние на функциональную пригодность, стоимость отсрочки) следует учесть для расчета итогового приоритета (рейтинга) каждого риска?
3. Какую конкретную ответственность должен нести менеджер рисков на каждом этапе этого процесса: от идентификации до мониторинга эффективности контрмер?
Задача 3. Выбор стратегии снижения неприемлемого риска
· Ситуация: Комплекс программ для АСУ ТП энергоблока показал на испытаниях неприемлемо высокий интегральный риск, связанный с недостаточной отказоустойчивостью. Команда попыталась применить первую стратегию контрмер: перераспределила вычислительные ресурсы между модулями и оптимизировала алгоритмы. Однако требуемого уровня надежности достичь не удалось. Заказчик отказывается от увеличения бюджета.
· Вопросы для анализа:
1. Дайте развернутое определение Второй стратегии контрмер сокращения рисков. Чем она принципиально отличается от Первой?
2. Какие конкретные действия в рамках этой стратегии необходимо инициировать? Составьте примерный перечень.
3. Обоснуйте, почему согласование с Заказчиком на применение Второй стратегии является обязательным и каковы могут быть юридические и финансовые последствия его отсутствия?
Задача 4. Экономическое обоснование дорогостоящей контрмеры
· Ситуация: Аудит безопасности выявил в ядре ОС РВ критическую уязвимость. Ее устранение требует полного пересмотра архитектуры и затрат в размере 40% от первоначального бюджета проекта. Финансовый директор компании-разработчика требует от менеджера проекта четкого технико-экономического обоснования.
· Вопросы для анализа:
1. Как, согласно лекции, следует оценивать "рентабельность" контрмер? Предложите формулу или модель для расчета.
2. В каких единицах измерения (абсолютные денежные затраты, относительные приоритеты, стоимостные категории) целесообразнее всего оценить величину потенциального ущерба от риска и затраты на его устранение в данном случае? Почему?
3. Составьте структуру доклада для финансового директора, где будут отражены не только затраты на контрмеру, но и потенциальные репутационные, юридические и финансовые потери компании в случае реализации данной угрозы.
Задача 5. Идентификация допустимого остаточного риска
· Ситуация: После внедрения всех запланированных контрмер в проекте медицинского диагностического комплекса менеджеры не могут прийти к единому мнению, достигнут ли допустимый уровень интегрального риска. Одни специалисты настаивают на продолжении работ, другие считают продукт готовым.
· Вопросы для анализа:
1. Дайте определение понятию "остаточный интегральный риск". Кто и на каком основании должен принимать решение о его допустимости?
2. Сформируйте состав комиссии, которая должна оценить остаточный риск. Какие специалисты (должности, области компетенции) должны в нее входить?
3. Разработайте протокол решения комиссии, включив в него как качественные (экспертные оценки), так и возможные количественные критерии принятия решения.
Задача 6. Внедрение риск-ориентированного мышления в проект
· Ситуация: Компания, ранее работавшая по интуитивным методам, выиграла тендер на разработку ПО для госструктуры с обязательным внедрением процессов управления рисками по ISO 16085. Команда не понимает, с чего начать.
· Вопросы для анализа:
1. Составьте пошаговый план внедрения процесса управления рисками в проект, начиная с идентификации и заканчивая мониторингом.
2. Какие документы (План управления рисками, Реестр рисков) необходимо создать и какую информацию они должны содержать?
3. Как мотивировать команду разработки, привыкшую только писать код, на активное участие в идентификации и анализе рисков?
Задача 7. Ранжирование рисков с помощью приоритетов
· Ситуация: Группа экспертов провела оценку 20 ключевых рисков проекта, присвоив каждому баллы от 1 до 10 по влиянию на функциональную пригодность и по необходимым затратам на контрмеры. Получены две несопоставимые таблицы чисел.
· Вопросы для анализа:
1. Как, согласно лекции, на основе этих двух наборов данных рассчитать "обобщенный приоритет" для каждого риска?
2. Как интерпретировать полученные значения приоритетов? Что означает "наивысший приоритет" в практическом плане для разработчика?
3. Как использовать этот рейтинг для убедительного обоснования перераспределения ресурсов проекта перед заказчиком?
Задача 8. Контрмеры для устранения первичных причин риска
· Ситуация: Анализ показал, что основной риск проекта — низкая надежность — вызван не недостатком тестирования, а принципиальными ошибками в архитектурных решениях, заложенных на ранних этапах проектирования.
· Вопросы для анализа:
1. К какому типу контрмер (по трехчастной классификации из лекции) относится работа с архитектурными ошибками? Дайте развернутое определение этого типа.
2. Почему такие контрмеры являются наиболее сложными и дорогостоящими, но в долгосрочной перспективе — наиболее эффективными?
3. Какие методы и мероприятия (например, реинжениринг, привлечение внешних архитекторов) можно предложить для реализации данной контрмеры?
Задача 9. Контрмеры для снижения уязвимости системы
· Ситуация: Программный комплекс работает в среде, где периодически происходят скачки напряжения, приводящие к его сбоям. Аппаратное обеспечение изменить нельзя.
· Вопросы для анализа:
1. К какому типу контрмер относится решение данной проблемы? Дайте развернутое определение этого типа.
2. Предложите несколько конкретных программных решений (например, введение механизмов checkpoint/restart, усиление обработки исключений), которые реализуют данный тип контрмер.
3. Как протестировать эффективность предложенных решений, не дожидаясь реального скачка напряжения?
Задача 10. Контрмеры для минимизации последствий реализации риска
· Ситуация: В социальной сети с миллионами пользователей существует риск случайной публикации конфиденциальных данных из-за человеческого фактора модератора. Полностью исключить человеческий фактор невозможно.
· Вопросы для анализа:
1. К какому типу контрмер относится управление данной ситуацией? Дайте развернутое определение этого типа.
2. Какие оперативные механизмы обнаружения и ликвидации ущерба можно внедрить в систему (например, автоматическое сканирование публикаций по ключевым словам, быстрые процедуры удаления)?
3. Какова роль эксплуатационной документации в регламентации действий модераторов и администраторов при наступлении такого события?
Задача 11. Упрощение процесса управления рисками
· Ситуация: Руководство небольшого стартапа со штатом 10 человек считает, что полноценный процесс управления рисками для них избыточен и отнимает время от разработки.
· Вопросы для анализа:
1. В каких случаях, согласно лекции, процессы анализа и сокращения рисков могут быть упрощены?
2. Предложите облегченную методику, при которой команда будет контролировать только 2-3 наиболее критичных риска. Как их выбрать?
3. Какие минимальные документы по управлению рисками должны быть у стартапа для сохранения управляемости?
Задача 12. Распределение ответственности за риски
· Ситуация: В проекте возникла проблемная ситуация, вызванная реализацией идентифицированного риска. Начались взаимные обвинения между менеджерами, архитекторами и тестировщиками.
· Вопросы для анализа:
1. Как должна быть организована система распределения ответственности специалистов за конкретные риски, чтобы избежать такой ситуации?
2. Каковы обязанности и полномочия лица, ответственного за риск, на этапах его мониторинга и при наступлении рискового события?
3. Как этот механизм ответственности должен быть отражен в проектной документации?
Задача 13. Сравнительный анализ приоритетов изменений
· Ситуация: По итогам испытаний предложено три возможных изменения для снижения рисков. Одно улучшает производительность для 80% пользователей, но требует долгого внедрения. Второе — срочное исправление уязвимости для 5% пользователей. Третье — косметическое улучшение для 100% пользователей с минимальными затратами.
· Вопросы для анализа:
1. Используя критерии из лекции, проведите сравнительный анализ приоритетности этих трех изменений.
2. Как на приоритет повлияют такие факторы, как "срочность извещения" и "влияние на сроки создания очередной версии"?
3. Какое решение вы бы приняли и как его обосновать заказчику?
Задача 14. Риск, связанный с человеческим фактором
· Ситуация: Ключевой архитектор проекта, обладающий уникальными знаниями о системе, неожиданно уволился. Реализация критически важных функций оказалась под угрозой срыва.
· Вопросы для анализа:
1. К какому классу рисков (технические, проектные, кадровые) относится данная ситуация?
2. Какие превентивные контрмеры (например, кросс-тренинг, парное программирование, детальное документирование решений) должны были быть внедрены в процесс управления рисками?
3. Какие экстренные контрмеры можно применить сейчас для минимизации ущерба?
Задача 15. Интегральный риск как решающий показатель
· Ситуация: Все основные метрики качества (надежность, производительность, безопасность) по отдельности находятся в "зеленой" зоне, однако заказчик интуитивно чувствует, что система неустойчива и в целом не удовлетворяет его ожиданиям.
· Вопросы для анализа:
1. Что такое "интегральный риск" и почему его оценка может дать более точную картину, чем анализ отдельных характеристик?
2. Опишите методику экспертного оценивания интегрального риска, когда количественные данные недостаточны.
3. Как результаты оценки интегрального риска могут повлиять на решение о выпуске или доработке продукта?
Задача 16. Кризис несоответствия документации и продукта
· Ситуация: На приемочных испытаниях сложного CRM-продукта заказчик обнаружил, что пять ключевых функций, подробно описанных в Руководстве пользователя, либо отсутствуют в рабочей версии, либо работают иначе. Это ставит под угрозу подписание акта сдачи-приемки. Документация объемом 500 страниц была написана параллельно с разработкой.
· Вопросы для анализа:
1. Объясните, почему эксплуатационная документация рассматривается как "третий эталон" (наряду с ТЗ и тестами) и чем опасно ее рассогласование с реальным продуктом для процесса сертификации и дальнейшей эксплуатации.
2. Проанализируйте процесс разработки документации в данном проекте. Какие процедуры контроля и тестирования документации (упомянутые в лекции) были явно пропущены?
3. Предложите подробный план экстренных действий по устранению данного несоответствия. Кто должен его выполнять (документаторы, разработчики, тестировщики) и в какой последовательности?
Задача 17. Выбор объема документации для разных классов продуктов
· Ситуация: Заказчик системы управления станком с ЧПУ (продукт 1-го класса, реального времени) требует от разработчика полный комплект документации, аналогичный по объему и детализации документации для ERP-системы (продукт 2-го класса). Разработчик считает это избыточным и экономически нецелесообразным.
· Вопросы для анализа:
1. Основываясь на лекции, дайте развернутую сравнительную характеристику документации для продуктов 1-го и 2-го классов. Чем принципиально отличаются их назначение, структура и объем?
2. Какие негативные последствия для конечного пользователя станка с ЧПУ может повлечь избыточно подробная документация?
3. Какие международные стандарты (например, ISO 15910, ISO 18019) и их конкретные пункты можно привести в качестве аргумента для обоснования оптимального состава и объема документации для продукта 1-го класса?
Задача 18. Тестирование документации на практичность для смешанной аудитории
· Ситуация: Разрабатывается система статистического анализа для исследовательского института. Аудиторией пользователей являются как опытные PhD-статистики, так и лаборанты без глубоких знаний в статистике. При пилотном внедрении и те, и другие жалуются на неудобство документации: первым не хватает глубины, вторые — не могут понять базовых принципов работы.
· Вопросы для анализа:
1. Дайте подробное определение "практичности" (применимости) документации. Как это свойство распадается на составляющие: понятность, изучаемость, простота использования?
2. Как решение о структуре документации (например, создание двух отдельных руководств: "Быстрый старт для лаборанта" и "Углубленное руководство для исследователя") согласуется с необходимостью унификации и стандартизации?
3. Опишите конкретную процедуру "испытания на практичность", которую можно провести с привлечением представителей обеих групп пользователей. Какие задания им нужно дать и какие метрики собрать?
Задача 19. Планирование документирования с нуля
· Ситуация: Стартап, успешно разработавший прототип инновационного программного комплекса, получил крупные инвестиции с условием выхода на международный рынок и прохождения сертификации. Процесс документирования ранее не был регламентирован.
· Вопросы для анализа:
1. Что такое "План документирования" и какие ключевые разделы он должен содержать согласно лекции? Составьте его подробную структуру.
2. Какие роли (специалисты) должны быть назначены для реализации этого плана? Распишите их зоны ответственности.
3. Как в Плане документирования должен быть отражен учет требований международных стандартов (например, ISO 12207) и как обеспечить, чтобы все эти требования были "тестируемы" в конечных документах?
Задача 20. Ошибка в документации администрирования
· Ситуация: В Руководстве администратора для системы обработки персональных данных была обнаружена ошибка: описанная последовательность действий при аварийном восстановлении приводила к неполному восстановлению базы данных и потере части транзакций за последние сутки. Ошибка была выявлена только во время реального сбоя.
· Вопросы для анализа:
1. К каким категориям рисков (функциональная пригодность, безопасность, финансовые) можно отнести последствия данной ошибки в документации?
2. Какие конкретные виды испытаний документации (например, проверка на соответствие, практичность, достоверность) не были проведены или были проведены некачественно?
3. Разработайте регламент экстренного выпуска исправленной версии документации и ее распространения среди всех пользователей. Какие разделы Плана документирования должны регулировать этот процесс?
Задача 21. Адаптация типовых шаблонов документации
· Ситуация: Компания имеет набор типовых шаблонов документов для своих продуктов. Однако новый проект представляет собой гибридную систему, сочетающую функции реального времени (1-й класс) и мощные административные инструменты (2-й класс).
· Вопросы для анализа:
1. Как следует поступить в данной ситуации: создать два отдельных комплекта документации или интегрированный? Каковы плюсы и минусы каждого подхода?
2. Как на основе имеющихся шаблонов создать адаптированный комплект, который удовлетворит потребности всех групп пользователей (операторов и администраторов)?
3. Кто должен принимать окончательное решение о структуре комплекта документации для такого гибридного продукта?
Задача 22. Определение и описание аудитории пользователей
· Ситуация: Документатор получил задание описать аудиторию для нового графического редактора. Менеджер по продукту сказал лишь: "Наша аудитория — это все, кто работает с графикой".
· Вопросы для анализа:
1. Почему такое описание аудитории является неудовлетворительным с точки зрения стандартов документирования?
2. Составьте детализированную классификацию потенциальных пользователей графического редактора, указав для каждой группы: уровень образования, квалификацию, решаемые задачи.
3. Как различия между этими группами должны повлиять на содержание, структуру и стиль изложения в Руководстве пользователя?
Задача 23. Документирование эксплуатационной концепции
· Ситуация: При создании системы управления складом необходимо разработать документ "Описание требований эксплуатационной концепции".
· Вопросы для анализа:
1. Какова цель этого документа и кто является его основными читателями (поставщик, разработчик, пользователь)?
2. Используя лекцию, составьте подробный план содержания этого документа для складской системы.
3. Как этот документ связан с Техническим Заданием и Планом документирования?
Задача 24. Конфиденциальность в процессе документирования
· Ситуация: Разработка ведется для силового ведомства. Заказчик предоставляет документаторам информацию с грифом "Для служебного пользования". Часть команды документаторов работает удаленно.
· Вопросы для анализа:
1. Какие риски возникают в процессе документирования в данной ситуации?
2. Какие меры должны быть прописаны в Договоре и Плане документирования для обеспечения конфиденциальности?
3. Как организовать процесс тестирования и проверки документации, не нарушая режим секретности?
Задача 25. Борьба с избыточным объемом документации
· Ситуация: Исторически сложилось, что документация на продукты компании насчитывает тысячи страниц. Пользователи постоянно жалуются, что не могут найти нужную информацию, а поддержка тратит много времени, объясняя, в каком документе что искать.
· Вопросы для анализа:
1. Каковы, согласно лекции, прямые и косвенные издержки от избыточного объема документации?
2. Предложите методику ревизии и оптимизации существующего комплекта документации. С чего начать, какие критерии использовать для сокращения?
3. Какие современные подходы к структурированию информации (DITA, многослойные руководства) можно применить для решения проблемы?
Задача 26. Оценка затрат на документирование
· Ситуация: Финансовый отдел запросил у менеджера проекта обоснованный расчет бюджета на создание эксплуатационной документации для нового комплекса программ объемом 500 тыс. строк кода.
· Вопросы для анализа:
1. Какой ориентировочный норматив затрат на документацию приведен в лекции и от чего зависят удельные затраты?
2. Рассчитайте ориентировочный объем текста и трудозатраты для данного проекта.
3. Какие факторы (например, класс продукта, требования к локализации, сложность предметной области) могут существенно скорректировать эту оценку в большую сторону?
Задача 27. Интеграция документации в процесс испытаний
· Ситуация: Тестировщики отказываются использовать эксплуатационную документацию как "третий эталон", утверждая, что им достаточно ТЗ и тест-кейсов.
· Вопросы для анализа:
1. Какую уникальную пользу может принести документация в процессе тестирования, которой нет в ТЗ?
2. Предложите конкретные виды тестов (например, тестирование процедур установки, восстановления, выполнения типовых сценариев по инструкции), которые прямо зависят от качества документации.
3. Как мотивировать тестировщиков активно искать несоответствия между продуктом и документацией?
Задача 28. Практичность vs. Формальная полнота
· Ситуация: Документация прошла все формальные проверки на соответствие требованиям. Однако юзабилити-тест с реальными пользователями показал, что они не могут выполнить базовые операции, не обращаясь в службу поддержки.
· Вопросы для анализа:
1. В чем разница между "формальной полнотой" документации и ее "практичностью"?
2. Какие атрибуты практичности (понятность, простота использования, изучаемость) были, скорее всего, нарушены?
3. Кто в команде (документатор, дизайнер UX, тестировщик) должен нести основную ответственность за практичность документации?
Задача 29. Документирование для обучения
· Ситуация: Заказчик требует не только эксплуатационную документацию, но и полный комплект учебных пособий для проведения курсов повышения квалификации своих сотрудников.
· Вопросы для анализа:
1. Чем учебно-методические материалы должны отличаться от эксплуатационной документации по целям, структуре и стилю изложения?
2. Какие требования к объему и функциям электронных учебников следует оценивать, согласно лекции?
3. Какова роль специалистов по обучению (instructional designers) в создании таких материалов и как их вовлечь в процесс?
Задача 30. Управление изменениями в документации
· Ситуация: В проект поступает постоянный поток мелких изменений от заказчика. Документаторы не успевают вносить правки во все документы, и версионность документации путается.
· Вопросы для анализа:
1. Как должен быть организован процесс получения документаторами "учтенных копий изменений требований"?
2. Предложите систему версионности и учета изменений для документации, которая была бы понятна пользователям.
3. Как интегрировать процесс управления изменениями документации с системой управления конфигурацией программного кода?
Задача 31. Конфликт при готовности к сертификации
· Ситуация: Руководитель разработки, находясь под давлением сроков контракта, настаивает на немедленной передаче продукта на сертификационные испытания, так как формально истекло все отведенное на предварительные испытания время. Руководитель службы тестирования представляет отчет, в котором указано, что 15% тестов не выполнено, а количество неустраненных "критических" дефектов превышает внутренний лимит в 3 раза.
· Вопросы для анализа:
1. Проанализируйте три группы критериев выхода из предварительных испытаний, приведенных в лекции. Какой из них использует руководитель разработки, а какой — руководитель тестирования?
2. Какие долгосрочные риски для бизнеса компании (репутационные, финансовые, юридические) возникают в случае принятия позиции руководителя разработки?
3. Кто, помимо этих двух руководителей (например, представитель заказчика, системный архитектор, менеджер по качеству), должен быть привлечен для принятия взвешенного решения? Предложите процедуру такого решения.
Задача 32. Формирование комплекта документов для сертификации
· Ситуация: Компания-заявитель впервые готовит свой программный комплекс для сертификации. Руководство не понимает, какие именно документы необходимо подготовить, и опасается, как бы их отсутствие или несоответствие не стало формальным поводом для отказа.
· Вопросы для анализа:
1. Основываясь на материалах лекции (Рис. 11.2, 11.3, 11.4), составьте развернутый перечень документов, сгруппированный по трем категориям: базовые нормативные, исходные и результирующие.
2. Для документа из каждой категории поясните, кто его подготавливает (заявитель, разработчик, испытательная лаборатория) и какова его основная цель в процессе сертификации.
3. Что такое "профиль стандартов" и как его создание помогает адаптировать общий перечень документов под конкретный проект?
Задача 33. Анализ дефектов и критерий готовности
· Ситуация: В процессе предварительных испытаний было выявлено 250 дефектов. На момент принятия решения о готовности к сертификации исправлено 240. Руководство требует обосновать, почему нельзя передать продукт с 10 оставшимися дефектами, которые классифицированы как "существенные", но не "критические".
· Вопросы для анализа:
1. Какие факторы "неготовности" продукта, приведенные в лекции, следует проанализировать в данной ситуации помимо абсолютного количества дефектов?
2. Что такое "профиль устраненных дефектов" и как его анализ (распределение дефектов по модулям, типам, критичности) может повлиять на решение?
3. Разработайте шаблон "Отчета о готовности к сертификации", который бы наглядно представлял всю необходимую информацию для принятия решения: покрытие тестами, динамику обнаружения/исправления дефектов, список остаточных рисков и т.д.
Задача 34. Давление на группу тестирования
· Ситуация: За две недели до плановой передачи на сертификацию коммерческий директор требует от команды тестирования прекратить тесты и подписать все акты, чтобы успеть в важный для маркетинга квартальный отчет. Он утверждает, что найденные "баги" незначительны и будут исправлены в первом же патче.
· Вопросы для анализа:
1. Какими аргументами из области управления рисками и профессиональной этики должен апеллировать руководитель тестирования, чтобы противостоять такому давлению?
2. Как формализованный и согласованный на старте проекта "Критерий выхода" мог бы помочь в этой ситуации?
3. Опишите сценарий эскалации проблемы: кому, помимо непосредственного начальства, может (и должен) доложить о ситуации руководитель тестирования, чтобы защитить репутацию компании и качество продукта?
Задача 35. Работа с незавершенными дефектами
· Ситуация: Принято решение передать продукт на сертификацию с 15 известными, но не исправленными дефектами низкого уровня. Часть из них связана с интерфейсом, часть — с редкими ситуациями в работе.
· Вопросы для анализа:
1. Как должен быть оформлен официальный документ, регламентирующий судьбу этих дефектов? Что он должен содержать, кроме списка?
2. Каким образом эти дефекты должны быть отражены в отчетных документах, предоставляемых органу по сертификации, чтобы продемонстрировать прозрачность и осознанное принятие риска?
3. Как организовать мониторинг этих дефектов в будущих версиях, чтобы не тратить ресурсы на их повторное выявление?
Задача 36. Создание профиля стандартов
· Ситуация: Предприятие разрабатывает встроенное программное обеспечение для медицинского прибора. Необходимо выбрать из длинного списка международных и государственных стандартов те, которые будут составлять основу для сертификации.
· Вопросы для анализа:
1. На основе каких характеристик проекта (безопасность, надежность, предметная область) следует производить отбор стандартов в профиль?
2. Выберите 5-7 наиболее критичных стандартов из приведенного в лекции списка (например, IEC 61508, ISO 12207, ГОСТ Р 51904) для данного случая и обоснуйте свой выбор.
3. Кто в организации должен утверждать окончательный профиль стандартов?
Задача 37. Подготовка исходных документов заявителем
· Ситуация: Компания-заявитель должна подготовить пакет исходных документов по рис. 11.3. Внутри компании нет понимания, что означает, например, "анализ функционирования продукта показал приемлемый уровень качества" или "оценки покрытия требований и допустимых рисков".
· Вопросы для анализа:
1. Раскройте содержание двух любых пунктов из списка результатов, которые должны быть зафиксированы руководителями производства (например, "все компоненты под формальный контроль", "стабильно функционирует в тестовой среде").
2. Какие конкретные отчеты и артефакты разработки могут служить доказательной базой для каждого из этих пунктов?
3. Кто внутри компании-разработчика должен нести ответственность за подготовку и достоверность этих документов?
Задача 38. Взаимодействие с органом по сертификации
· Ситуация: Процесс сертификации затягивается, так как орган по сертификации запрашивает все новые и новые уточнения и документы, не все из которых были изначально оговорены.
· Вопросы для анализа:
1. Как должен быть оформлен комплект исходных документов, чтобы минимизировать количество уточняющих вопросов от сертификаторов?
2. Какие права и обязанности есть у заявителя в процессе сертификационных испытаний? Как цивилизованно оспорить избыточные, по мнению заявителя, требования?
3. Какую роль в этом процессе играют результирующие документы (Рис. 11.4) и их утверждение?
Задача 39. Использование результатов предварительных испытаний
· Ситуация: Сертификационная лаборатория требует провести все испытания с "нуля" своими силами, не принимая во внимание объемные отчеты о предварительных испытаниях, проведенных разработчиком.
· Вопросы для анализа:
1. Каков, согласно лекции, рекомендуемый подход к использованию результатов предварительных испытаний при сертификации?
2. Что должно гарантировать "достоверность и полноту" результатов предварительных испытаний, чтобы сертификаторы могли им доверять?
3. Какие виды испытаний (например, испытания на надежность или безопасность) являются исключением, где повторное проведение сертификатором обязательно?
Задача 40. Присвоение сертификата и знака качества
· Ситуация: Сертификационные испытания успешно завершены, комплект отчетных документов передан в орган по сертификации.
· Вопросы для анализа:
1. Кто и на каком основании принимает окончательное решение о присвоении сертификата и знака качества?
2. Что происходит с комплектом документов (базовые, исходные, результирующие) после успешной сертификации? Какой их статус?
3. Какие обязательства берет на себя компания-разработчик, получив сертификат, в отношении дальнейшего сопровождения и модификации продукта?
Задача 41. Стратегия внедрения сертифицированной версии
· Ситуация: Сертификация успешно пройдена. Теперь необходимо организовать поставку и внедрение новой версии программного комплекса для управления сетью диспетчерских у 50 региональных заказчиков. Старые версии работают стабильно, и заказчики не горят желанием тратить ресурсы на обновление.
· Вопросы для анализа:
1. Опишите двухэтапный процесс внедрения, указанный в лекции. Каковы цели и задачи каждого этапа?
2. Какие обязанности, помимо передачи "физических носителей", ложатся на разработчиков и испытателей в процессе внедрения? Какую ценную информацию они могут получить?
3. Разработайте план обучения пользователей. Какие учебно-методические материалы необходимо подготовить и как определить целевую аудиторию для обучения?
Задача 42. Управление изменениями и версиями после выпуска
· Ситуация: В процессе сопровождения сертифицированной версии от пользователей поступил поток предложений по улучшению и сообщений об ошибках. Накопленная база изменений стала неструктурированной и трудноуправляемой.
· Вопросы для анализа:
1. Какой документ, согласно лекции, должен создаваться для систематизации предложений по изменениям? Опишите его рекомендуемую структуру.
2. Разработайте жизненный цикл запроса на изменение: от его поступления до внедрения в новую версию. Какие проверки и согласования должны быть на каждом этапе?
3. Как организовать процесс проверки того, что внесенные изменения удовлетворяют требованиям заказчика и не нарушили работоспособность ранее сертифицированного функционала (регрессионное тестирование)?
Задача 43. Обоснование снятия продукта с эксплуатации
· Ситуация: Компания планирует прекратить поддержку сертифицированной версии программного обеспечения, которой уже 10 лет. Часть ключевых заказчиков продолжает ее использовать, опасаясь затрат и рисков миграции на новую платформу.
· Вопросы для анализа:
1. Что, согласно лекции, должно быть подготовлено для обоснования решения о снятии с эксплуатации? Составьте структуру аналитического отчета.
2. Какие экономические (TCO, ROI новой версии) и технические (риски использования устаревшей платформы, совместимость) аргументы должны быть в него включены?
3. Какие гарантии и действия компания должна предусмотреть для клиентов, которые откажутся от перехода на новую версию? Какую роль здесь играет обеспечение доступа к архивной документации?
Задача 44. Пост-релизный анализ и извлечение уроков
· Ситуация: Проект по сертификации сложного программного комплекса завершен. Руководство поручает менеджеру по качеству провести анализ и выработать рекомендации для улучшения процессов в следующих проектах.
· Вопросы для анализа:
1. Что подразумевается под термином "изучение полученных уроков" (Lessons Learned)? Опишите методику его проведения: кого опрашивать, какие данные анализировать.
2. Какие конкретные данные, собранные в ходе тестирования (метрики покрытия требований, профиль дефектов, временные затраты), являются наиболее ценными для этого анализа?
3. Как должна быть организована "централизованная база данных конфигурационного управления требованиями и тестами", чтобы накапливать знания и обеспечивать их доступность для будущих проектов?
Задача 45. Борьба с ложными результатами тестирования
· Ситуация: При автоматизированном регрессионном тестировании наблюдается аномально высокий процент (около 20%) то ложных падений (ложно-отрицательные результаты), то, наоборот, успешного прохождения тестов там, где есть проблемы (ложно-положительные результаты). Это дискредитирует результаты тестирования и вызывает конфликты между командами разработки и тестирования.
· Вопросы для анализа:
1. Дайте четкие определения "ложно-отрицательного" и "ложно-положительного" результатов тестирования. Приведите по 2-3 конкретные причины возникновения каждого из них в данном контексте.
2. Разработайте план мероприятий по investigation и устранению причин ложных срабатываний. Какие компоненты тестовой системы (тест-кейсы, тестовое окружение, данные, инструменты) необходимо проверить в первую очередь?
3. Какую роль в данном процессе играет "выборочная проверка результатов тестирования даже в том случае, если тест завершился успешно"? Кто и как должен ее проводить?
Задача 46. Анализ проблемных компонентов системы
· Ситуация: Анализ отчетов о проблемах показал, что 60% всех критических дефектов сходятся в одном модуле системы — модуле обработки транзакций. Разработчики заявляют, что этот модуль полностью переписан и протестирован.
· Вопросы для анализа:
1. Как группа тестирования должна использовать такую аналитику для планирования своих действий?
2. Какое дополнительное тестирование (например, нагрузочное, тестирование безопасности, углубленное регрессионное) необходимо запланировать для данного модуля?
3. Если регрессионное тестирование вновь обнаруживает дефекты в этом модуле, какие вопросы должен задать испытатель разработчикам?
Задача 47. Взаимодействие испытателей и разработчиков по дефектам
· Ситуация: Разработчики постоянно возвращают отчеты о дефектах тестировщикам с пометкой "Не воспроизводится", в то время как тестировщики настаивают на наличии проблемы.
· Вопросы для анализа:
1. В чем должна заключаться помощь испытателей разработчикам в понимании и воспроизведении дефектов?
2. Какая дополнительная информация (логи, дампы памяти, видео воспроизведения, точные шаги) должна быть обязательным атрибутом хорошо составленного отчета о дефекте?
3. Разработайте регламент совместного сеанса отладки (debugging session) между тестировщиком и разработчиком для решения проблемы "не воспроизводимости".
Задача 48. Оценка эффективности Программы испытаний
· Ситуация: Проект завершен. Необходимо оценить, насколько успешно была реализована Программа сертификационных испытаний.
· Вопросы для анализа:
1. С какими запланированными критериями следует сопоставить фактические результаты? Составьте checklist для сравнения.
2. Как оценить, были ли упущены из виду предложения по совершенствованию испытаний, и повторялись ли однотипные дефекты?
3. Что подразумевается под "развитием культуры тестирования" и как ее зрелость влияет на эффективность Программы испытаний?
Задача 49. Итеративное усовершенствование процессов
· Ситуация: Руководство компании хочет сделать улучшение процессов испытаний непрерывным, а не разовым актом по итогам проекта.
· Вопросы для анализа:
1. Почему усовершенствование процессов целесообразно выполнять итеративно?
2. Предложите механизм регулярного (например, ежеквартального) сбора "уроков", анализа метрик и определения корректирующих действий.
3. Как оценить эффективность внедренных улучшений в следующем проекте или следующей версии продукта?
Задача 50. Использование стандартов для улучшения процессов
· Ситуация: Компания решила повысить зрелость своих процессов с CMMI уровня 1 на уровень 3. В лекции приведен обширный список стандартов (CMMI, ISO 12207, ISO 15504, ISO 9000 и др.).
· Вопросы для анализа:
1. Как различные стандарты из списка соотносятся друг с другом? Какой из них задает модель зрелости (CMMI), какой — процессы ЖЦ (ISO 12207), а какой — требования к системе менеджмента качества (ISO 9001)?
2. Выберите 2-3 стандарта, внедрение которых окажет наибольшее влияние на улучшение именно процессов испытаний и управления рисками. Обоснуйте выбор.
3. С чего начать практическое внедрение выбранных стандартов в организации? Предложите план первых шагов.
Материалы на данной страницы взяты из открытых источников либо размещены пользователем в соответствии с договором-офертой сайта. Вы можете сообщить о нарушении.
