Процессы поддержки программных средств

Процессы поддержки Г1С предусматривают совокупность операций, направленных на содействие выполнению процессов реализации ПС и других процессов, предусмотренных стандартом ГОСТ Р ИСО/МЭК 12207—2010 (например, процессов соглашения).

1. Процесс менеджмента программной документации (7.2.1) заключается в разработке и сопровождении документально зарегистрированной информации по ПС, созданной некоторым процессом.

В ходе процесса:

• — формируется стратегия идентификации документации, реализуемая в течение жизненного цикла программного продукта или услуги;
• — устанавливаются стандарты, применяемые при разработке программной документации;
• — определяется документация, которая будет формироваться в ходе реализации процессов или проекта;
• — устанавливаются, согласовываются и утверждаются содержание и цели всей документации;
• — разрабатывается и сопровождается в соответствие с определенными критериями необходимая документация, доступная для заинтересованных сторон па основе настоящего стандарта и принятых политик.

Реализация процесса осуществляется в соответствие с разработанным планом, определяющим перечень документов, которые должны формироваться в течение жизненного цикла программного продукта. Идентифицированная документация должна содержать:

• — заголовок или название;
• — цели и содержание;
• — круг пользователей, для которых она предназначена; процедуры и меры ответственности при формировании исходных

данных, разработке, ревизиях, модификации, утверждении, производстве, хранении, распределении, сопровождении и менеджменте конфигурации;

— графики создания промежуточных и окончательных версий.

Разработка регламентированных в проекте документов должна осуществляться в соответствие с действующими стандартами на документацию, определяющими все аспекты ее подготовки, оформления, выбора носителей, хранения, иллюстрирования, копирования, распространения, обеспечения нрав собственности и соблюдения режима секретности.

Правомерность источников используемой в документации информации должна документально подтверждаться. Важные материалы должны храниться в соответствии с установленными требованиями, исходя из содержания документа, его защиты от случайных или преднамеренных несанкционированных изменений, обеспечения разграничения доступа к нему, поддержки сопровождения документа с целью его актуализации и возможной необходимости восстановления документа по его резервной копии. При подготовке и редактировании документов следует соблюдать стандартизованные требования по их оформлению, стилю изложения и техническому содержанию. Соответствие положений документов реальным процессам должно быть подтверждено уполномоченным персоналом.

2. Процесс менеджмента конфигурации ПС (7.2.2) заключается в установлении и сопровождении целостности программных модулей, блоков и составных частей процесса или проекта и обеспечении их доступности для всех заинтересованных сторон.

В ходе процесса:

• — формируется стратегия менеджмента конфигурации ПС;
• — идентифицируются и определяются базовые элементы, порождаемые процессом или проектом;
• — контролируются модификации и выпуски составных частей, устанавливается их статус и обеспечивается доступность для заинтересованных сторон;
• — устанавливаются факты гарантированной завершенности и согласованности составных частей процессов, условия их хранения, сроки обработки и поставки.

Реализация процесса осуществляется на основе плана менеджмента конфигурации ПС, который может быть частью плана менеджмента конфигурации всей информационной системы. В плане должны быть описаны действия менеджмента конфигурации, процедуры и графики выполняемых при этом работ, организации и лица, ответственные за реализацию указанных действий, формы взаимоотношений между участниками глобального проекта.

Управление конфигурацией заключается в идентификации и регистрации заявок на изменения, анализе и оценке изменений, принятии или отклонении заявок, реализации, верификации и выпуске программных модификаций. Для отслеживания последствий модификаций следует проводить проверочные испытания и аудит доступа к контролируемым программным модулям, блокам и составным частям, критически важным с точки зрения обеспечения безопасности и (или) защиты информации.

Состояние конфигурации должно постоянно отслеживаться путем выполнения хронологических записей по причинам и следствиям изменения управляемых программных элементов.

Для оценки конфигурации следует гарантированно определять функциональную и физическую завершенность программных модулей, блоков и составных частей проекта относительно ранее установленных, согласованных и утвержденных требований.

Поставки программных продуктов и документации должны официально поддерживаться на протяжении всего жизненного цикла системы.

3. Процесс обеспечения гарантии качества ПС (7.2.3) заключается в гарантированном подтверждении полного соответствия рабочей продукции и процессов предварительно установленным параметрам.

В результате осуществления процесса:

• — формируется стратегия обеспечения гарантии качества;
• — разрабатываются и подтверждаются средства, свидетельствующие о гарантии качества;
• - определяются и фиксируются проблемные, не соответствующие требованиям программные блоки и участки;
• - выполняется верификация разработанных программных элементов, действий и процессов на предмет соблюдения соответствующих стандартов, процедур и заданных требований.

Действия процесса следует координировать со связанными с ним процессами верификации ПС, их валидации, ревизии и аудита.

План реализации процесса должен разрабатываться, документально оформляться, выполняться и сопровождаться в течение всего срока контракта. В плане процесса должны быть определены:

• — стандарты качества, официальные методики процедуры и технологии или ссылки на них, использование которых способствует обеспечению гарантии качества анализируемых программных элементов;
• — процедуры пересмотра контракта и их координация;
• — процедуры выявления, сбора, регистрации, сопровождения и распространения записей о качестве;
• — людские и программно-технические ресурсы, графики работ и ответственные за проведение операций по обеспечению гарантии качества;
• — действия и задачи из смежных процессов верификации, валидации, ревизии и аудита, использование которых способствует решению проблем в ПС.

Все запланированные действия и задачи процесса должны быть реализованы. При обнаружении проблем или несоответствий с обусловленными требованиями контракта, они должны быть документально зафиксированы с целью передачи на вход процесса решения проблем.

По ходу реализации проекта заказчику должны предоставляться гарантии на продукты и процессы их разработки:

• - что все требуемые по контракту планы документально оформлены, соответствуют условиям, взаимосогласованы и подлежат безусловному выполнению;
• - что программные продукты и соответствующая программная документация отвечают требованиям контракта и разрабатываются с учетом плановых заданий;
• - что поставляемые программные продукты полностью удовлетворяют согласованным при заключении контракта с приобретающей стороной требованиям;
• - что все процессы жизненного цикла Г1С, используемые в ходе реализации проекта, соответствуют контрактным условиям и выполняются по утвержденному плану;
• - что принятая в организации — разработчике ПС среда и технология разработки и тестирования программных продуктов, библиотеки повторно используемых модулей соответствуют требованиям контракта;
• — что при передаче главного контракта подрядчику не нарушаются установленные требования по всем параметрам разработки, согласованные с заказчиком;
• — что заказчик и другие стороны, участвующие в проекте, обеспечены необходимой поддержкой на условиях контракта, договоренностей и планов;
• — что программный продукт и процесс измерений его параметров соответствуют установленным стандартам и процедурам;
• — что штатный персонал организации-разработчика, задействованный в реализации проекта, достаточно квалифицирован, имеет требуемые навыки, знания и умения, позволяющие разработать проект с заявленными функциональными возможностями и заданными ограничениями, и получает при необходимости надлежащее обучение.
• 4. Процесс верификации ПС (7.2.4) заключается в подтверждении факта, что каждые из программных рабочих продуктов и (или) услуг процесса или проекта должным образом отражают заданные требования.

Процесс предполагает:

• — разработку и осуществление стратегии верификации;
• — определение критериев верификации всех необходимых программных рабочих продуктов;
• — выполнение требуемых действия по верификации;
• — определение и регистрацию дефектов;
• — обеспечение доступности результатов верификации заказчику и другим заинтересованным сторонам.

В ходе процесса должны быть определены условия его реализации. Требования проекта должны быть проанализированы на критичность, оцениваемой в терминах:

• — «потенциального наличия необнаруженной ошибки в требованиях к системе или программным средствам, приводящей к гибели или травматизму персонала, невыполнению задания, финансовому ущербу, катастрофической утрате или повреждению оборудования»^[1];
• — степени отработки технологии программных средств и рисков, связанных с ее применением;
• — доступности фондов и ресурсов.

Верификация может проводиться независимой организацией.

Виды деятельности и задачи верификации, включая соответствующие методы, технические приемы и инструментарий для выполнения задач, должны определяться в зависимости от особенностей предназначения и специфики программного продукта, условий его применения и величины возможного ущерба вследствие неполноты проверки продукта на соответствие заявленным требованиям.

На основе установленных задач должен быть разработан и документально оформлен план проведения верификации, определяющий предмет верификации и необходимые действия в течение всего контролируемого периода.

Верификация требований предполагает:

• — оценку согласованности, выполнимости и тестируемости системных требований;
• — проверку распределения системных требований по техническим, программным элементам и ручным операциям согласно критериям проекта;
• — оценку согласованности, выполнимости и проверяемости требований к ПС и их точного соответствия системным требованиям;
• — установление строгими методами факта корректности требований к программным средствам, связанных с безопасностью, защитой и критичностью.

Верификация проекта проводится с учетом следующих критериев:

• — корректировка проекта согласуется с требованиями и вызвана необходимостью соблюдения требований;
• — проект надлежащим образом реализует события, входы, выходы, интерфейсы и логические связи; ошибки обнаруживаются и устраняются; сроки исполнения проекта и размеры финансирования соблюдаются;
• — проект соответствует заданным функциональным требованиям, корректно реализует требования по безопасности, защищенности и другим критическим свойствам.

При верификации кода дополнительно проверяется его соответствие стандартам кодирования, корректность реализации обработки данных, интерфейса пользователя с системой, а также обеспечения мер по разграничению доступа, защите и безопасности информации.

При верификации комплексируемости проекта:

• — устанавливается корректность комплектования программных компонентов и модулей в общий программный элемент;
• — проверяется комплексируемость технических и программных элементов, а также ручных операций в программную систему;
• — отмечается срок выполнения задачи комплексирования в соответствие с планом — досрочно или с задержкой.

Процессу верификации подвергается также программная документация. Она должна быть адекватной, полной и согласованной, издаваться своевременно и соответствовать процедурам менеджмента конфигурации документов.

5. Процесс валидации ПС (7.2.5) заключается в подтверждении факта выполнения установленных требований в ходе конкретных применений рабочей версии программного продукта.

В ходе процесса:

• — формируется и реализуется стратегия валидации;
• — определяются критерии валидации для программного продукта в целом и его программных элементов;
• — выполняются требуемые действия по валидации;
• — идентифицируются и регистрируются проблемы;
• — устанавливаются доказательства пригодности созданных рабочих программных продуктов для применения по предназначению;
• — результаты действий по валидации доводятся до заказчика и других заинтересованных сторон.

Реализации процесса предшествует определение условий проведения валидации. Разрабатывается план проведения валидации, в котором, по крайней мере, предусматриваются следующие действия:

• — определяются элементы, подвергаемые валидации;
• — формулируются задачи валидации, которые будут выполняться;

определяются ресурсы, ответственные лица (подразделения) и графики выполнения работ но валидации;

- устанавливаются процедуры передачи отчетов о результатах валидации заказчику и другим заинтересованным сторонам.

В ходе валидации необходима определенная степень организационной независимости. Для установления корректности функционирования программного продукта помимо тестирования могут использоваться другие средства — анализ, моделирование, имитация и т.п.

После выбора и оценки требований к тестированию, тестовых примеров и спецификации для анализа результатов тестирования, выполняют проверку программного продукта. Тестирование производят в условиях повышенной нагрузки, при пиковых и граничных значениях параметров, а также при маловероятных, возможно, противоречивых входных данных. Оценивают способность программного продукта восстанавливаться в случае поступления на вход некорректных данных или после ошибочных действий оператора. Проверяют возможности использования программного продукта основными пользователями системы со стороны заказчика.

В случае успешной валидации программного продукта делается вывод о его соответствии предназначению и возможности функционирования в заданной среде применения. При обнаружении в ходе валидации проблем и несоответствий делаются соответствующие записи и выполняется переход к процессу решения проблем в программных средствах.

6. Процесс ревизии ПС (7.2.6) заключается в выработке общего подхода с правообладателями процесса относительно целей соглашения и формирования рекомендаций по действиям, удовлетворяющих правообладателей и способствующих разработке продукта требуемого функционального назначения. Ревизии программных средств проводят как на уровне менеджмента проекта, так и на техническом уровне, в соответствие с планом в течение всего жизненного цикла проекта.

В ходе процесса:

• - выполняются технические ревизии и ревизии менеджмента на основе потребностей проекта;
• — оцениваются состояние и результаты действий процесса посредством ревизии деятельности;
• - объявляются результаты ревизии всем участвующим сторонам;
• — отслеживаются для закрытия позиции, по которым необходимо предпринимать активные действия, выявленные в результате ревизии;
• - идентифицируются и регистрируются риски и проблемы.

Виды деятельности и задачи процесса:

• - реализация процесса (периодические ревизии должны проводиться в предварительно определенные в планах сроки, быть обеспечены необходимыми ресурсами и персоналом; выявленные проблемы должны регистрироваться и включаться в согласованный итоговый документ);
• — ревизии менеджмента проекта (состояние проекта оценивается по отношению к планам проекта, графикам работ, стандартам и руководящим указаниям; итоговые результаты представляются руководству);
• — технические ревизии (проводятся для оценки программных продуктов или услуг с позиции представления свидетельств их полного укомплектования, соответствия принятым стандартам и спецификациям, корректного выполнения изменений, соответствия действующим стандартам, руководящим указаниям, установленным планам и графикам работ по проектированию, созданию, эксплуатации или сопровождению).
• 7. Процесс аудита ПС (7.2.7) состоит в независимом определении соответствия выбранных продуктов и процессов требованиям, планам и соглашениям.

В ходе процесса:

• — разрабатывается и осуществляется стратегия аудита;
• — устанавливается соответствие отобранных рабочих программных продуктов и (или) услуг или процессов требованиям, планам и соглашениям;
• — выявленные в процессе аудита проблемы идентифицируются, доводятся до сведения ответственных лиц за корректирующие действия для последующего разрешения.

Аудиторские проверки проводятся независимой стороной в предварительно установленные в плане проекта контрольные сроки. Аудиторский персонал не несет ответственности за проверяемые программные продукты и действия. Необходимые для проведения аудитов ресурсы (персонал, место и условия проведения, технические, программные и инструментальные средства) должны быть согласованы участвующими сторонами, в том числе по критериям проведения аудита. Проблемы, выявленные в ходе аудита, регистрируются и передаются для последующего исследования процессу решения проблем в программных средствах 7.2.8.

Аудиторские проверки ПС проводятся с целями получения гарантий, что:

• — по завершении кодирования программные продукты отражают проектную документацию;
• — документированные условия и требования к тестированию пригодны для приемки программной продукции;
• — тестовые данные соответствуют спецификациям;
• — программные продукты успешно протестированы и удовлетворяют спецификациям;
• — отчеты об испытаниях программного продукта правильны, и расхождения между фактическими и ожидаемыми результатами устранены;
• — документация пользователя соответствует стандартам;
• — действия проведены в соответствии с утвержденными требованиями, планами и контрактом;
• — затраты и графики работ согласуются с утвержденными планами.
• 8. Процесс решения проблем в ПС (7.2.8) заключается в обеспечении гарантии того, что все выявленные проблемы идентифицируются, анализируются, контролируются и подвергаются менеджменту для осуществления их решения.

В результате реализации процесса:

• — разрабатывается стратегия менеджмента проблем;
• — выполняется регистрация, идентификация и классификация проблем;
• - проводится анализ и оценка каждой проблемы для принятия приемлемых решений;
• - выполняется решение проблем соответствующим процессом, отслеживается их текущее состояние;
• — ход решения проблем контролируется вплоть до их закрытия.

Реализация процесса основана на циклическом взаимодействии с другими процессами проекта. При обнаружении в других процессах проблем или несоответствий они поступают на вход рассматриваемого процесса. Инициируются необходимые действия, извещаются соответствующие стороны. Причины проблем или несоответствий устанавливаются, анализируются и, по возможности, устраняются. Информация о проблеме или несоответствии отражается в отчетах и доводится до заинтересованных сторон.

Обнаруженные проблемы следует классифицировать и расставлять по приоритетам. Для обнаружения тенденций в известных проблемах следует проводить соответствующий анализ для определения и устранения неблагоприятных трендов.

В отчетах об устранении проблем следует приводить их описание, условия возникновения и действия по их устранению (разрешению).

• [1] ГОСТ Р ИСО/МЭК 12207—2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.