RU2793750C1 - Способ подтверждения повторно используемых требований к программному обеспечению в процессе управления изменениями - Google Patents

Abstract

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

Description

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

В процессе управления требованиями можно выделить основные этапы: определение требований (идентификация и выявление), документирование, анализ, отслеживание, проверку (подтверждение или валидация), управление изменениями. Управление изменениями описаны в книге «Принципы работы с требованиями к программному обеспечению. Унифицированный подход» – Дин Леффингуэлл, Дон Уидриг. – 2002. – 448с (глава 34 – http://www.dialektika.com/PDF/5-8459-0275-4/part34.pdf).

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

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

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

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

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

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

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

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

В статье «Приемы управления требованиями к ПО» (https://analytics.infozone.pro/requirements-analysis/requirements-management-methods/) процесс управления изменениями следующий: предложение изменений, анализ влияния изменений, принятие решений, обновление отдельных требований, обновление наборов требований, обновление планов, оценка изменчивости требований.

Процесс управления изменениями рассматривается в рамках одной спецификации (проекта), в рамках которой и происходит анализ влияния изменений. Не рассматривается вариант повторного использования требований, их изменение и влияние на элементы тех систем, в которых оно используется.

В статье «Формирование требований и классификация требований» приводится анализ проблем изменения спецификации в процессе управления изменениями. (https://analytics.infozone.pro/formation-requirements-and-classification-requirements/)

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

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

В статье «Анализ требований по Вигерсу (2004). Этапы сбора требований» раскрывается подтверждение требований через тестирование. «Тестирование требований. На основе пользовательских требований создайте сценарии функционального тестирования и задокументируйте ожидаемое поведение продукта в конкретных условиях. Совместно с клиентами изучите сценарии тестирования и убедитесь, что они отражают нужное поведение системы. Проследите связь сценариев тестирования с функциональными требованиями и удостоверьтесь, что ни одно требование не пропущено и что для всех требований есть соответствующие сценарии тестирования. Запустите сценарии, чтобы удостовериться в правильности моделей анализа и прототипов.» (https://analytics.infozone.pro/requirements-analysis/analysis-of-requirements-wiegers-2004/)

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

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

Данный способ по технической сущности является наиболее близким к предлагаемому и выбран в качестве прототипа.

Недостатками прототипа являются:

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

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

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

Техническими проблемами изобретения являются:

• Повышение качества требований к программному обсечению;

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

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

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

Описание ситуации:

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

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

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

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

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

Способ реализуется следующим образом:

Реализация способа представлена на чертеже (фиг.1).

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

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

Для каждого требования из N из основной спецификации формируют сценарии тестирования для подтверждения валидности требований (M).

Выполняют сценарии тестирования. Если при выполнении тестирования обнаруживаются невалидные требования (F), то требование корректируется, корректируются сценарии тестирования. Для F требований проводится тестирование и подтверждение. И так до тех пор, пока все требования из N не будут валидны.

Берется смежная спецификация (i=1) из числа K. Для нее определяют Mi – количество используемых в ней требований из N. Для Mi требований формируются сценарии функционального тестирования для смежной спецификации. В ходе выполнения тестирования подтверждаются Mi требований.

Если требования невалидные, то в список невалидных требований добавляются те, что не прошли подтверждение.

И осуществляется переход к следующей смежной спецификации (i=i+1). И так до тех пор, пока для всех смежных спецификаций не будет проверено всех Mi требований.

Если после проверки всех смежных спецификаций есть невалидные требования (T), то выполняют исправление (корректировку невалидных требований) и повторяют подтверждение требований начиная с основной спецификации, но не для всех, а только для исправленных требований (N=T).

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

Способ был опробован в процессе управления требованиями на разработку программного обеспечения приборов управления современных космических аппаратов производства АО «ИСС».

С использованием данного способа проведено тестирование встроенного программного обеспечения вычислительного устройства блоков управления и блоков интерфейсных бортового комплекса управления современных и перспективных КА производства АО «ИСС».

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

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

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

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

Claims (1)

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

Images