Рис. 1 — Эволюционное пространство [Fel 2003]
Источник: Хухко Г. Эволюция требовний к программному обеспечению [Электронный ресурс].
Гарри Хухко
Хельсинский университет
Кафедра компьютерных наук
В настоящей статье инженерия требований рассматривается с эволющионной точки зрения. Программные системы должны адаптироваться, иначе они становятся менее пригодными к использоваонию
[Leh 2001]. По меньшей мере, есть два аспекта. Практический заключается в том, как справиться с меняющимися требованиями, и он тесно связан с управлением и отслеживаемостью требований. Детальнее эти аспекты освещены в других темах семинара. Мы же проанализируем природу эволюции в разработке требований. Вначале представлены некоторые основные понятия эволюции. В третьем разделе обсуждаются результаты предыдущих исследований, в которых проанализирвана история эволюции требований. В четвёртом разделе представлено краткое обсуждение эволюции. Пятый раздел завершает статью.
Эволюция требований относится к изменениям, которые происходят в наборе требований после начальной стадии разработки требований [Ant 2001]. Таким образом, изменения в требованиях, которые могут произойти на начальных этапах сбора, анализа, спецификации и проверки, не являются эволюционными. Изменения в требованиях - это дополнения, пропуски или модификации требований [Sta 1999].
Эволюция требований связана с другими формами эволюции в компьютерных системах. На следующем рисунке представлена таксономия элементов в эволюционном пространстве [Fel 2003]:
Рис. 1 — Эволюционное пространство [Fel 2003]
Измерение Эволюция в дизайне - Эволюция в использовании относится к временному измерению. Измерение Тяжёлые Изменения - Лёгкие Изменения относится к месту, где происходит эволюция в системе. Эволюция программного обеспечения отражает точку зрения продукта, а эволюция архитектуры - точку зрения дизайна. Они принадлежат к сложной эволюции, которая подчеркивает технические аспекты. Эволюция компьютерных систем относится к человеческим факторам, а эволюция организации - к взаимодействию между компьютерной системой и окружающей средой. Эволюция требований находится в средней позиции, которая связывает жесткие и мягкие аспекты компьютерной системы вместе. Поэтому это естественное место, где можно собирать информацию об эволюции компьютерных систем
[Fel 2003].
Функциональное требование - это то, что позволяет пользователю или, в более широком смысле, заинтересованному лицу достичь своих целей1.]. Если мы хотим эмпирически изучить существующие программные системы, то требования устанавливаются как услуги, предоставляемые системой. Служба, которая не поддерживает какие-либо цели или не поддерживает ее, но по неоправданной цене бессмысленна или декоративна. Иногда новая услуга является бременем для заинтересованной стороны, потому что причиняется больше вреда, чем пользы. Например, если новые услуги бесполезны для заинтересованного лица, ему, возможно, все же придется изменить способ взаимодействия с системой, который причиняет ему вред. Полезные услуги можно разделить на основные услуги и услуги второго порядка или модулирующие услуги. Основные сервисы напрямую связаны с прикладной областью, тогда как модулирующие сервисы основаны на создании или передаче знаний о системе. В телефонной системе основная служба должна иметь возможность разговаривать по телефону, а модулирующая служба должна знать, кто звонит, без необходимости отвечать на телефонные звонки [Ant 2001]2.].
Одна из самых длинных записей услуг в компьютерных системах может быть найдена в телефонных услугах. В исследовании, проведенном Антоном и др., Были сведены в таблицу справочники телефонных справочников Атланты за 1950-1999 гг. Как и в эволюционной биологии, интересная проблема заключается в том, происходит ли эволюция в компьютерных системах постепенно или быстро за короткие промежутки времени. В случае телефонных услуг в Атланте в течение нескольких лет наблюдался явный скачок в количестве услуг (1971, 1980, 1989) (см. Рисунок 2). Это поддерживает пунктуальную форму эволюции. После быстрого роста произошло постепенное снижение количества услуг. Кроме того, когда услуги классифицировались в соответствии с их профилями выгоды / бремени, результаты по-прежнему способствовали пунктуации эволюции [Ant 2001].
Рис. 2 — Рост сферы услуг в течение более 50 лет [Ant 2001]
Основываясь на предыдущих результатах, можно утверждать, что программный продукт развивается либо стабильно более длительные периоды, либо быстро в течение короткого периода времени. Это должно влиять на то, как технические и управленческие процессы организованы в организации по разработке. Сокращение количества услуг после расширения может быть объяснено избыточностью между новыми и старыми услугами, что приводит к вытеснению старых услуг новыми [Ant 2001].
Другой вывод по делу Атланты состоит в том, что полезные услуги для тех заинтересованных сторон, которые используют систему, непосредственно предшествуют услугам для других групп заинтересованных сторон. В телефонии первые услуги были связаны с общением с другими. Доступность для других доминировала на более поздних этапах развития. Это говорит о том, что требования, полученные от заинтересованных сторон, должны иметь приоритет над другими заинтересованными сторонами. Основные услуги, связанные с созданием и передачей информации, имеют приоритет над услугами, основанными на информации об основных услугах. Эти сервисы метауровня имеют дело с информацией о состоянии системы и предназначены для того, чтобы помочь справиться со сложностями, возникающими в основных сервисах. Это указывает на относительную неважность сервисов мета-уровня, таких как настройка, в ранних выпусках продукта [Ant 2001].
В другом исследовании, проведенном Андерсоном и Феличи, была рассмотрена система, критическая для безопасности авионики [And 2001]. Как и в предыдущей телефонной системе в Атланте, количество новых услуг между выпусками значительно отличалось. Индекс зрелости программного обеспечения (RMI) использовался для измерения относительного изменения количества требований:
(1)
где RT - количество требований в текущем выпуске; RC - это количество требований, которые были добавлены, изменены или удалены из предыдущего выпуска. На рисунке 3 показана RMI системы авионики для всех функциональных требований
Рис. 3 — RMI системы авионики [And 2001]
Когда число изменений требований было рассчитано для различных 8 функций системы, был получен следующий график:
Рис. 4 — Совокупное количество изменений требований для каждой функции [And 2001]
Из рисунка 4 видно, что функция F1 является стабильной частью системы. F1 отвечает за взаимодействие аппаратной архитектуры системы. Поэтому, на мой взгляд, даже эта функция может демонстрировать пунктуальное развитие, когда система импортируется на новое оборудование. Похоже, что функции, которые меняются в ранних выпусках, позже стали стабильными, а функции, которые стабильны в ранних выпусках, позже меняются [And 2001].
В исследовании Stark et al. Было исследовано 44 выпуска программного обеспечения, охватывающих 7 продуктов. Требования во всех выпусках были перечислены по типу изменения (добавление, удаление и изменение). На рисунке 5 показано распределение этих изменений [Sta 1999].
Рис. 5 — Распределение требований по типу [Sta 1999]
Дополнение является доминирующим типом изменений, как и следовало ожидать, за которым следует удаление и модификация.
Требования были также перечислены заинтересованными сторонами. Были идентифицированы четыре группы людей, участвующих в процессе формирования требований: команда разработчиков подрядчика и команда управления приобретением, которые принадлежат обслуживающей организации и персоналу по управлению пользователями, а также отдельным аналитикам сайта, которые принадлежат организации-клиенту. Распределение показано на рисунке 6 [Sta 1999].
Рис. 6 — Распределение требований между заинтересованными сторонами [Sta 1999]
Согласно этим данным изменения в требованиях происходят в равной степени от сопровождающих и клиентов. Другие выводы в исследовании были [Sta 1999]:
Очевидный способ критиковать эмпирические тематические исследования - утверждать, что их результаты не могут выявить общих черт. В эволюционной биологии классическое дарвиновское утверждение состоит в том, что эволюция является существенной конкуренцией. Это утверждение может быть подтверждено многими случаями в природе. Но в равной степени есть свидетельства того, что сложные биологические структуры, такие как глаз, являются результатом сотрудничества. Поэтому я считаю, что можно найти программные системы, которые развивались стабильно или почти не развивались после их первого выпуска. Но кажется очевидным, что программное обеспечение в конкурентной среде должно быстро развиваться, чтобы оставаться в бизнесе. Обычно существует основной выпуск, который содержит много новых функций, за которыми следуют второстепенные версии, которые в основном устраняют проблемы, содержащиеся в основном выпуске.
Лично я считаю, что наряду с управлением изменениями и требованиями очень хорошая начальная подготовка к вероятным типам изменений является ключом к успешной эволюции программной системы. В требованиях инженерные требования должны быть классифицированы по вероятности их изменения. Также не все требования выполняются (обычно из-за ограниченных ресурсов) и те, которые не являются естественной основой для эволюции. Это можно принять во внимание на этапе проектирования архитектуры, чтобы типичное нефункциональное требование модифицируемость
было описано в конкретных терминах. Существуют также методы для оценки архитектур, где различные заинтересованные стороны тестируют архитектуру, описывая сценарии, которые архитектура должна уметь обрабатывать. Различные виды сценариев изменений полезны при тестировании модифицируемости архитектуры и при информировании о потребностях изменений, испытываемых различными заинтересованными сторонами [Bas 2003]
Согласно исследованиям, представленным в этой статье, системы программного обеспечения ещё долго продолжают развиваться после их первоначального выпуска. Эволюция пунктуальна; Есть длительные периоды устойчивого прогресса и короткие всплески числа новых функций. Можно выяснить, так ли это в конкретной системе, используя простые методы, описанные в разделе 3: табулирование количества новых сервисов в каждой версии (и, возможно, в каждой функции). Более сложные регрессионные модели могут использоваться для оценки рабочей нагрузки, связанной с различными наборами требований.
← Назад в библиотеку