гост. 19621_ГОСТ Р 56920_Определения (1). Системная и программная инженерия
 Скачать 0.52 Mb.
|
|
5.3.1 Подпроцессы проекта разработки и их результаты Разработка программного обеспечения и разработка системы обычно состоят из нескольких общих стандартных блоков. В индустрии программного обеспечения эти стандартные блоки обычно называют: "фазы", "этапы", "шаги", "уровни" или в общем случае - "подпроцессы разработки". В подпроцессы разработки могут входить: - инженерия требований; - проектирование архитектуры; - детальное проектирование; - кодирование. Конкретный подход к разработке системы, принятый в целом в организации или отдельном проекте, определяет организацию этих подпроцессов разработки. В проекте последовательной разработки анализ требований может быть самостоятельным начальным процессом. В проекте динамичной разработки требования будут определяться каждые несколько недель для каждой разрабатываемой части. В каждом из подпроцессов разработки что-то производится. Это может быть высокоструктурированный подробный документ, неофициальное документированное или недокументированное решение. В любом конкретном проекте разработки отдельные подпроцессы разработки могут быть выполнены только один раз, а могут повторяться столько раз, сколько необходимо. Общие подпроцессы разработки и связанные с ними рабочие продукты, подсистемы и завершенная программная система показаны на рисунке 7. Рисунок 7 - Пример подпроцессов разработки  Рисунок 7 - Пример подпроцессов разработки Каждый рабочий продукт, компонент программной системы и полная программная система - это потенциальный элемент тестирования. Следует отметить, что определение модели разработки выходит за рамки применения настоящего стандарта. Фазы, показанные на рисунке 7, являются только примерами для иллюстрации применения тестирования при разработке. 5.3.2 Текущее сопровождение и его результаты Текущее сопровождение имеет место в период функционирования жизненного цикла программного обеспечения, то есть после начальной разработки, и им можно управлять в контексте Управления Приложениями или структуры процессов Менеджмента Услуг ИТ. В проекте может быть предусмотрено непрерывное обслуживание, и этим он зачастую сильно отличается от проекта разработки, например финансовая модель может быть другой. Одна из распространенных финансовых моделей планирует количество бюджетных средств на сопровождение на определенный период. Это может быть закреплено в соглашении об уровне обслуживания (SLA) между потребителем и обслуживающей организацией. Процесс текущего сопровождения обычно предусматривает поддержание приемлемого или согласованного уровня надежности и готовности системы. Это включает производство новых версий системы с исправлением обнаруженных при функционировании наиболее приоритетных дефектов и, возможно, внедрение приоритетных изменений функциональности. Такие версии могут реализовываться в виде "живой" системы либо на разовой основе по завершении исправлений и изменений, либо с заданной частотой, например каждые три месяца. Если корректировка по ходу обслуживания осуществляется на разовой основе, то реализация и внедрение необходимых исправлений и/или изменений обычно выполняются как можно быстрее. Если период корректировки по ходу обслуживания фиксирован, то реализуется столько необходимых исправлений и/или изменений, сколько возможно реализовать в этот период времени с учетом последовательности внедрения согласно перечню приоритетов. Основные результаты такого периода реализации показаны на рисунке 8. Рисунок 8 - Пример периода корректировки по ходу обслуживания  Рисунок 8 - Пример периода корректировки по ходу обслуживания В зависимости от назначения реализации каждый из выходов, показанных на рисунке 8, может быть произведен за один период реализации, но может случиться и так, что потребуется несколько периодов. Например, может случиться так, что оперативная коррекция не повлияет на требования и проект, но затронет только код и завершенную систему, или может случиться, что все рабочие продукты будут затронуты несколько раз перед тем, как система будет готова к выпуску. Периоды корректировки по ходу обслуживания повторяются по мере необходимости в период функционирования жизненного цикла системы. 5.3.3 Процессы поддержки в жизненном цикле разработки программного обеспечения Процессы поддержки необходимы в организации для обеспечения поддержки жизненного цикла разработки программного обеспечения. Некоторые из этих процессов: - обеспечение качества; - менеджмент проектов; - менеджмент конфигурации; - совершенствование процессов. 5.3.3.1 Обеспечение качества и тестирование Обеспечение Качества - это совокупность запланированных и систематических процессов и действий поддержки, необходимых для обеспечения надлежащего уровня уверенности в том, что процесс или рабочий продукт удовлетворяет установленным техническим требованиям или требованиям к качеству. Достигается это сочетанием методов, стандартов, инструментов и навыков, признанных как соответствующая практика. Процесс Обеспечения Качества использует результаты тестирования и другую информацию для анализа, оценки и информирования о любой проблеме (включая любой риск) в проектировании, планировании или выполнении процессов программной инженерии. В ходе тестирования необходимо собирать показатели, поскольку они могут обеспечить информацию о качестве процессов тестирования и/или элементов тестирования и результативности их использования в каждом проекте. 5.3.3.2 Менеджмент проектов и тестирование Менеджмент проектов относится к процессам поддержки, которые используются для планирования и контроля выполнения проекта, включая менеджмент проекта тестирования в составе всего проекта. Независимо от того, кто несет ответственность за отдельные процессы, процессы менеджмента проектов и менеджмента тестирования тесно связаны между собой, как показано на рисунке 9. Рисунок 9 - Взаимосвязь всего проекта и проекта тестирования  Рисунок 9 - Взаимосвязь всего проекта и проекта тестирования Оценка, анализ рисков и планирование тестирующих действий должны составлять единое целое с планированием всего проекта. Поэтому для процесса менеджмента проекта тестирования план проекта, который является выходным информационным элементом процесса менеджмента проектов, является входом. В ходе выполнения проекта тестирования измерения, полученные в результате конкретных тестирующих действий, анализируются менеджером тестирования и передаются менеджеру проекта для анализа в контексте проекта. Это может привести к изменениям в плане проекта, затрагивающим проект тестирования, к обновлению плана проекта и формированию соответствующих директив для проекта тестирования, необходимых для обеспечения гарантии, что проект тестирования держится под контролем. По завершении подпроцесса тестирования или проекта тестирования менеджеру проекта представляется отчет о завершении, в котором суммированы ход и результаты подпроцесса тестирования или проекта тестирования. 5.3.3.3 Менеджмент конфигурации и тестирование Менеджмент конфигурации - это другая совокупность процессов поддержки, с которыми тесно связано тестирование. Цель менеджмента конфигурации состоит в том, чтобы установить и поддерживать целостность рабочих продуктов. Для того чтобы выяснить, соответствует ли организация или проект предъявляемым требованиям, рекомендуется проверить систему менеджмента конфигурации организации или проекта перед ее практическим использованием. Процессы менеджмента конфигурации включают в себя уникальную идентификацию, управляемое хранение, аудит реализации, контроль изменений и отчетность о состоянии отдельных рабочих продуктов, системных компонентов и систем в течение времени жизни продукта. Объект менеджмента конфигурации вызывают элементом конфигурации. Процессы менеджмента конфигурации управляются событиями, то есть все они инициируются независимо друг от друга в зависимости от требований других процессов. Рабочие продукты процесса тестирования, которые могут быть переданы в менеджмент конфигурации, включают в себя: - Организационные Спецификации Тестирования (например, Политика Тестирования, Организационная Стратегия Тестирования). - Планы тестирования. - Спецификации тестирования. - Элементы конфигурации тестовой среды, такие как инструменты тестирования, тестовые данные (основа), драйверы и заглушки. Все три уровня модели процесса тестирования, определенной в настоящем стандарте, могут взаимодействовать с менеджментом конфигурации. Элементы конфигурации, предоставленные процессу тестирования, являются рабочими продуктами потребности, необходимыми для процесса в качестве входа, и являются объектами менеджмента конфигурации. Элементы конфигурации, получаемые из процесса тестирования, являются рабочими продуктами, произведенными процессом тестирования, должны быть переданы под контроль менеджмента конфигурации. Результатами Организационного Процесса Тестирования могут, например, быть Политика Тестирования и Организационная Стратегия Тестирования, которые передаются под контроль менеджмента конфигурации. Менеджер тестирования проекта может взять копию Плана Проекта, который является объектом менеджмента конфигурации, и использовать эту копию в качестве базы для Плана Тестирования Проекта, который далее передается под контроль менеджмента конфигурации. Выполняющие подпроцесс динамического тестирования могут взять копию спецификации требований, которая является объектом менеджмента конфигурации, и использовать эту копию в качестве базы для спецификации тестирования, которая далее передается под контроль менеджмента конфигурации. Для обеспечения возможности воссоздать проблему для дальнейшего анализа рекомендуется (там, где это возможно), чтобы система менеджмента конфигурации была всеобъемлющей и устойчивой для того, чтобы тестирование могло быть повторено при тех же условиях, как прежде. Такая практика приемлема для того, чтобы исключить определенные типы тестирования, например поблочное тестирование, из требования повторяемости при условии, что исключение заявлено в Организационной Стратегии Тестирования или Плане Проекта. Отчеты менеджмента конфигурации для процесса тестирования должны предоставить подробные результаты, которые могут потребоваться для анализа прогресса и состояния инцидентов. 5.3.3.4 Совершенствование процессов и тестирование Совершенствование процессов осуществляет меры, направленные на такие изменения процессов организации, которые обеспечат более эффективное и результативное достижение бизнес-целей организации. Процессы тестирования и процесс совершенствования процессов взаимодействуют двумя способами: 1 Процессы тестирования предоставляют информацию, на которой могут базироваться действия совершенствования процессов (помимо информации, полученной из других источников). 2 Сами процессы тестирования могут быть объектами совершенствования процессов. В случае предоставления совершенствованию процессов информации тестированием обычно имеет место взаимодействие между процессом менеджмента тестирования, примененного на уровне проекта, и процессом совершенствования процессов. Тестовые измерения могут быть переданы непосредственно из процессов менеджмента тестирования. Процесс совершенствования процессов может также получить некоторые связанные с тестированием метрики из менеджмента конфигурации, если он присутствует и охватывает контроль изменений. Совершенствование процессов тестирования может осуществляться в рамках улучшения всей организации или может быть в рамках совершенствования процессов тестирования независимо от всей организации. В любом случае для того, чтобы определить, какие процессы тестирования должны быть улучшены, как это можно сделать и какими должны быть усовершенствованные процессы, процессы совершенствования процессов должны получать информацию из разных источников. Результатом будут новые версии каждого из отобранных процессов тестирования, которые затем должны быть развернуты для соответствующих пользователей. Идентифицированные улучшения могут быть применены только для конкретного проекта или могут быть реализованы для всех проектов организации. Необходимо контролировать новые процессы тестирования, чтобы оценить, производят ли они ожидаемый эффект. 5.4 Тестирование на базе рисков Исчерпывающая проверка программной системы невозможна, поэтому тестирование представляет собой действия выборочного обследования. Для подбора надлежащей выборки тестирования имеется множество понятий тестирования (например, практика, методы и типы), которые определяются и обсуждаются в настоящем стандарте. Ключевая предпосылка настоящего стандарта состоит в проведении оптимального в рамках заданных ограничений и контекста тестирования, с использованием основанного на рисках подхода. Этот подход обеспечивает определение относительной стоимости различных стратегий тестирования с точки зрения снижаемых рисков для заинтересованных в завершенной системе сторон и с точки зрения разрабатывающей систему стороны. Выполнение тестирования на базе рисков обеспечивает во время тестирования наиболее тщательный анализ рисков с самым высоким приоритетом. В определении рисков функционирующих систем могут быть полезны другие стандарты, например ИСО/МЭК 16085 "Менеджмент рисков". Риски могут быть классифицированы многими способами. Например, риски могут быть идентифицированы с точки зрения неудовлетворения нормативных и/или законных требований, невыполнения договорных обязательств, связанного с неуспешным ходом и завершением проекта (риски проекта), и необеспечения ожидаемого поведения рабочего продукта (риски продукта). При проведении тестирования на базе рисков анализ рисков используется для их идентификации и ранжирования таким образом, чтобы выявленные в разрабатываемой системе риски (и в разработке этой системы) могли быть ранжированы, выстроены по приоритету и классифицированы, а впоследствии снижены. 5.4.1 Использование тестирования на базе рисков в Организационном Процессе Тестирования Организационная Политика Тестирования устанавливает контекст проведения тестирования в организации. При этом необходимо идентифицировать организационные риски, которые могут повлиять на процесс тестирования. Например, организации, производящей медицинское программное обеспечение, вероятно, придется соответствовать строгим стандартам качества. Организационная Политика Тестирования для этой организации может включать в себя требования соответствия связанным с безопасностью стандартам и таким образом попытаться смягчить воздействие того, что не удается реализовать в проекте. Организационная Стратегия Тестирования должна учитывать подход к менеджменту рисков в процессе тестирования. В вышеупомянутом примере организации, производящей медицинское программное обеспечение, Организационная Стратегия Тестирования может разработать руководящие материалы о том, каким образом в организации должно выполняться тестирование, чтобы обеспечивать управление риском несоответствия нормативным стандартам. В дополнение к этому Организационная Стратегия Тестирования может предписать использование конкретного подхода к применению менеджмента рисков для использования в процессах менеджмента тестирования. 5.4.2 Использование тестирования на базе рисков в процессах менеджмента тестирования Классифицированный профиль риска (идентифицированный набор рисков и их рангов) используется для того, чтобы определить, какое тестирование должно применяться в проекте. Это записано в стратегии тестирования, которая является частью плана тестирования. Оценки рисков, например, могут использоваться для определения строгости тестирования (подпроцессов тестирования, методов проектирования тестирования, критериев завершения тестирования). Расстановка приоритетов рисков может использоваться для формирования графика тестирования (Тестирование, связанное с высокоприоритетными рисками, обычно выполняется раньше). Тип риска может быть использован для выбора выполнения наиболее подходящей формы тестирования. Например, если имеется риск, выявленный в интерфейсах между компонентами, то необходимо интеграционное тестирование, а если есть выявленный риск того, что пользователи могут испытывать затруднения в использовании приложения, то необходимо выполнить тестирование удобства использования. Хорошей практикой является привлечение к этим действиям максимально широкого круга заинтересованных сторон для обеспечения согласования идентификации максимального числа рисков и соответствующих действий по их смягчению (или, возможно, отказа от учета некоторых рисков). Преимущество использования этого подхода состоит в том, что в любой момент риск поставки может быть просто доведен до заинтересованных сторон как остаточный риск. Результаты выполнения тестирования выявленных рисков и также развитие бизнеса естественным образом приводят к изменениям с течением времени профиля риска, а, следовательно, тестирование на базе рисков необходимо рассматривать в качестве длительной деятельности. |