Учебное пособие санктПетербург 2015
 Скачать 3.34 Mb.
|
|
Связь качества программного обеспечения и инженерии требований ческого контроля качества, основных характеристик и целенаправленного воздействия на них с целью посто- янного обеспечения необходимого уровня качества. Характеризоваться свойства информационных систем (программного обеспечения) могут как единич- ными показателями, так и комплексными. Единичный показатель качества — показатель качества информа- ционной системы, относящийся только к одному из её свойств. Комплексный показатель качества — показа- тель качества информационной системы, относящий- ся к нескольким её свойствам. 1.2. Инженерия требований На сегодняшний день все проекты, в которых за- действованы информационные технологии, включают в себя создание определённого программного обеспе- чения. В большей степени это связано с желанием про- ектной команды создать комплексное решение, в рам- ках которого все происходящие процессы можно будет с лёгкостью контролировать. Какое бы предназначение не имела разрабатываемая система, её пользователи вза- имодействуют непосредственно с программной средой, ассоциируя с ней всю систему целиком. Многие из них могут даже не иметь представления о сложной внутрен- ней структуре и количестве аппаратных компонентов, задействованных в ней. Подобная тенденция обуслов- лена следующими факторами: Отсутствие ограничений на сложность разра- батываемых систем. Наличие механизмов быстрого распростране- ния программного обеспечения. Наличие огромного количества библиотек с готовыми модулями, на основе которых можно созда- вать новые продукты [50]. 1. 2. 3. 18 Методы оценки и измерения характеристик информационных систем Указанные факторы предоставляют возможность существенно увеличить прибыль от разработки новой технологии или продукта за счёт сокращения сроков их реализации, при этом, без необходимости в привле- чении больших производственных мощностей. В результате этого, одним из главных показа- телей нового продукта является время его выхода на рынок (time to market). В связи с этим, очевидной яв- ляется необходимость в его сокращении. Однако стра- тегическим показателем необходимо считать время выхода на рынок с «правильным» продуктом (time to market with the right product), то есть потенциальные пользователи должны видеть в нём ряд важных для себя преимуществ и функциональных особенностей, использование которых позволит удовлетворить их потребности. [50]. Применение подхода управления требованиями как раз и позволит определить те самые особенности, реализация которых привлечёт потенциальных клиен- тов. Требования, в первую очередь, позволяют опреде- лить саму предметную область реализуемого проекта, далее выделить возможные проблемы при его реализа- ции, а затем последовательно привести в соответствие с ними все последующие технические решения. Использование такого подхода позволит увели- чить удовлетворённость заказчиков и потенциальных пользователей, а также повысить рентабельность. Это связано с тем, что правильно составленные требования определяют необходимые потребности заинтересован- ных сторон (stakeholders), функциональные возможнос- ти разрабатываемого решения и способы проверки, де- монстрирующие корректную реализацию всех заявлен- ных особенностей. Создание правильных требований является очень трудоёмкой процессом, ошибки в кото- 19 Связь качества программного обеспечения и инженерии требований ром приводят к значительным финансовым потерям, как на внесение каких-либо изменений в реализуемое решение, так и на его полную переработку. Необходимо заметить, что все члены проек- тной команды должны одинаковым образом пони- мать и интерпретировать существующие требова- ния. Для этого, требования стараются писать на естественном языке и без использования профес- сиональных терминов. Со временем потребности заинтересованных сторон могут изменяться, причём в некоторых случа- ях и вовсе вступать в конфликт друг с другом. Также потребности могут быть нечётко сформулированы, их удовлетворение может быть ограничено факторами, контроль над которыми не возможен, и другими це- лями проекта, изменение которых в процессе работы также может произойти. Таким образом, отсутствие стабильных базовых и согласованных требований не позволит осуществлять разработку в рамках установ- ленного графика, а в некоторых случаях и вовсе при- водит к краху проекта. Стабильные и согласованные требования представляют собой фундамент, использующийся для планирования разработки решения и его сдачи в эксплуатацию. Они в значительной степени об- легчают работу при необходимости формирования компромиссов между потребностями заинтересо- ванных сторон и, что практически неизбежно, при внесении различных изменений в рамках проекта. С помощью требований можно дать оценку влия- ния предполагаемого изменения без необходимос- ти детальной проработки модели разрабатываемого решения или оценить последствия отмены внесён- ных ранее изменений. 20 Методы оценки и измерения характеристик информационных систем Стоит также заметить, что правильная организа- ция работы с требованиями позволяет управлять рис- ками на самых ранних стадиях разработки. То есть су- ществует возможность отследить риск, возникающий из определённого требования, оценить степень его влияния, вероятность появления. На основании этого можно разработать план по предотвращению и уст- ранению последствий этого риска. Все эти действия позволят избежать значительных финансовых потерь и предоставить потенциальным клиентам определён- ные гарантии. Можно сделать вывод, что требования играю важную роль в следующих областях: – планирование проекта; – управление рисками; – приемочные тестирования; – формирование компромиссов (согласований); – управление изменениями. Очевидным становится факт использования тре- бований во всём жизненном цикле проекта. Для демонстрации взаимосвязи стадий проекта и процесса управления требованиями существует клас- сическая V-модель (V-model), приведённая на рисунке 8. [50] V-модель визуализирует связь между требова- ниями и методами их тестирования, а также отобража- ет системную разработку в терминах уровней (layers), где каждый уровень соотноситься с определенным этапом разработки. Стоит заметить, что основной при- нцип работы с требованиями на всех уровнях остаётся неизменным. Ещё одной областью, где использование требо- ваний может принести существенную пользу, является связь между проектами. Большинство разработчиков желают [50]: 21 Связь качества программного обеспечения и инженерии требований – максимально увеличить использование нарабо- ток в разных проектах; – управлять семействами сходных продуктов; – использовать программное управление для со- гласования действий; – оптимизировать разработку, используя опыт предыдущих проектов. Корректно составленные требования заинте- ресованных сторон (stakeholders requirements) могут послужить хорошим и лаконичным описанием жела- емого результата для высшего руководства, поскольку, как уже было отмечено, формулируются без использо- вания специфических терминов и понятий. Точно также, системные требования (system requirements) могут послужить прекрасным техничес- ким описанием проекта. Оба этих набора требований служат основой для всех последующих действий в рамках проекта, а опыт, получаемый при его реализации, в дальнейшем ока- зывает благотворное влияние на процесс составления Рисунок 8 – Связь требований с тестированием [50] 22 Методы оценки и измерения характеристик информационных систем этих типов требований. Тривиальным фактом являет- ся возможность в будущих проектах заранее предус- матривать возможности для предотвращения проблем, выявленных в рамках схожих с ними проектов. Схема получения и распространения опыта в организации показана на рисунке 9. Данная схема демонстрирует нисходящий про- цесс получения опыта и восходящий процесс распро- странения опыта. Это связано с тем, что сам опыт, представляемый применением специфичных техноло- гий, промышленных фреймворков, технологических решений и т.п. может быть получен исключительно в процессе реализации конкретного проекта, то есть по- этапного декомпозиции задач и подбора подходящих способов их решения. Процесс распространения опы- та, с другой стороны, возможен только при наличии какой-либо базы реализованных проектов, из которой можно заимствовать существующие решения конкрет- ных задач и применять их к текущим проектам. Рисунок 9 – Схема получения и распространения опыта в организации [50] 23 Связь качества программного обеспечения и инженерии требований Как уже было замечено, требования очень часто меняются и не реагировать на их изменения нельзя, так как это может повлечь за собой частичное или полное неудовлетворение потребностей пользова- телей, в результате чего, разрабатываемый продукт окажется невостребованным на рынке, а, следова- тельно, нерентабельным. На основании этого мож- но смело утверждать, что разработка требований и управление их изменениями тесно связанные между собой процессы. При возникновении необходимости внесения ка- ких-либо изменений в проект необходимо учесть их влияние на следующие аспекты: – качество выпускаемого продукта; – стоимость выпускаемого продукта; – график работ по выпуску. После проведённого анализа процесс внесения изменений сводится к нескольким шагам: – принять или отклонить изменение; – согласовать стоимость изменения с заказчика- ми/поставщиками; – организовать работы по переделке. Для того чтобы провести анализ влияния изме- нений на разрабатываемый продукт, существует базо- вая концепция установления и контроля связей между требованиями (requirement traceability). Основной концепцией, позволяющей проводить анализ влияний такого рода, является возможность ус- тановления и последующего контроля связей между требованиями. Таким образом, можно утверждать, что управление изменениями (change management) явля- ется важной частью процесса работы с требованиями. Возможное влияние изменений в требования показано на рисунке 10. 24 Методы оценки и измерения характеристик информационных систем Очевидным становится факт зависимости спо- собности управления проектом и процесса работы с требованиями. Не имея требований очень трудно кор- ректно оценить прогресс работ, а в момент внесения изменений в первоначальное задание не будет возмож- ности отследить их влияние на ход проекта. Также стоит отметить, что корректно сформули- рованные на каждом уроне требования, предоставля- ют руководителю проекта правильное представление о проекте, о ходе его выполнения и прогрессе реали- зации, а также дают возможность эффективнее выпол- нять свою роль в управлении общим процессом разра- ботки. Для того чтобы чётко понимать взаимосвязь тре- бований на всех уровнях необходимо явным образом создавать и анализировать связи между ними. В боль- шей степени это необходимо для понимания трансля- ции требований верхнего уровня (пользовательских) в требования подсистем и их компонентов. Рисунок 10 – Риски управления изменениями связанные с взаимосвязанностью требований [50] 25 Связь качества программного обеспечения и инженерии требований В контексте разработки требований, создание и анализ связей необходимы, в первую очередь, для по- нимания того, как требования высокого уровня – об- щие цели, задачи, пожелания, предполагаемые ожида- ния, нужды и т.п. – трансформируются в требования низкого уровня. Следовательно, в основном, связи нужны между различными уровнями информации. Использование связей может принести следую- щие выгоды: – большая уверенность в достижении целей (ус- тановление связей и формализация их контроля при- водит к четкому пониманию того, как именно достига- ются цели); – возможность оценить влияние изменений (су- ществование связей между требованиями дает воз- можность проводить разного рода анализ влияния вносимых изменений); – возможность оценить вклад работников, под- рядчиков и субподрядчиков (появляется возможность ясно оценить ту часть работы, которую выполняют по проекту сотрудники и другие организации); – возможность контролировать ход проекта и оценивать объем выполненной работы; – возможность сопоставлять затраты и возмож- ную выгоду (однозначное определение связи между требованиями и определенными компонентами систе- мы, позволяет соизмерять затраты с предполагаемым положительным эффектом от их реализации) [50]. Можно выделить два основных типа связей: – связи между требованиями разных уровней (обыч- но имеют тип «многие ко многим» и одно требование ниж- него уровня может быть связано с несколькими требовани- ями более высокого уровня, как, впрочем, и наоборот); – связи между требованиями одного уровня. 26 Методы оценки и измерения характеристик информационных систем Стрелки на линиях связей всегда проставляются от приёмника информации к источнику. Для такого со- глашения есть две причины: – такой формат стрелки зачастую соответствует хронологическому порядку появления информации (связь всегда указывает на информацию, появившую- ся ранее); – очень часто это соответствует также и правам на владение информацией (одному человеку при- надлежат исходящие из документа связи, другому – входящие). Пример связей между требованиями представ- лен на рисунке 11. Рисунок 11 – Связи между требованиями [50] 27 Связь качества программного обеспечения и инженерии требований Можно выделить три основных метода анализа связей между требованиями: анализ влияния, анализ последствий и анализ покрытия. Краткая характерис- тика этих методов приведена в таблице 1. Таблица 1 – Методы анализа связей между требованиями [50] Метод анализа Описание Поддерживаемый процесс Анализ влияния Анализ входящих свя- зей для оценки пос- ледствий изменения требований Процесс измене- ния Анализ последствий Анализ исходящих связей для оценки це- лесообразности изме- нения Анализ экономи- ческой целесооб- разности Анализ покрытия Анализ входящих связей для оценки прогресса работ Проектирование и отчётность руко- водству Анализ влияния позволяет оценить количество элементов более низкого уровня, на которые повлияет вносимое в конкретный элемент изменение, и насколь- ко сильно это на них отразится. Другими словами, ана- лиз влияния помогает ответить на вопрос: «Что будет, если изменить это требование?». Анализ последствий является полной проти- воположностью анализа связей. В рассмотрение берутся элементы более низкого уровня, а затем проверяется их соответствие элементам более вы- сокого уровня. Если элементы нижних уровней не имеют связей с элементами верхних уровней, то, вероятно, они лишь увеличивают затраты на про- 28 Методы оценки и измерения характеристик информационных систем изводство продукта и могут быть исключены. То есть анализ последствий отвечает на вопрос: «Это действительно нужно?». Схема процессов анализа влияния и последствий представлена на рисунке 12. Анализ покрытия, как и анализ влияния, рас- сматривает входящие связи. С его помощью можно проверить наличие связей между всеми элементами более высоких уровней с элементами более низких уровней, а также с необходимыми для этих элементов Рисунок 12 – Анализ влияния и анализ последствий [50] 29 Связь качества программного обеспечения и инженерии требований тестами. Отсутствие связей между уровнями тестами свидетельствует о невозможности удовлетворить или протестировать конкретное требование. В тоже время, наличие подобных связей не гарантирует возможность удовлетворить и протестировать требование. Анализ покрытия представлен на рисунке 13 [50]. Также анализ покрытия можно использовать для измерения прогресса работ (сколько изначально заявленных требований удовлетворены и протести- рованы). Подразумевается, что системные инженеры разрабатывают системные требования, отвечающие требованиям пользователей, или, как еще говорят, «покрывающие» их. Рисунок 13 – Схема анализа покрытия [50] 30 Методы оценки и измерения характеристик информационных систем В процессе разработки, каждое системное требование связано с теми пользовательскими тре- бованиями, для удовлетворения которых оно пред- назначено. Завершённость системных требований на любом этапе проекта может быть определена как процент покрытия пользовательских требова- ний системными. Аналогичный принцип может применяться для измерения прогресса разработки планов тестирования. Завершённость готовых планов тестирования опреде- ляется как процент покрытия требований тестами. Следует особы выделить наличие взаимосвязи между разработкой требований и системным моде- лированием. В контексте управления требованиями системное моделирование используется для описа- ния и наглядного отображения различных аспектов разрабатываемой системы, причём обычно использу- ется несколько различных моделей, возможно даже взаимосвязанных. При этом некоторые аспекты сис- темы можно просто описать требованиями (в тексту- альном виде). Преимуществом такого подхода является то, что небольшой объем связанной информации, относя- щийся к определенному аспекту системы, может быть собран в одной модели, обработан, структурирован и проанализирован методами, которые наиболее всего подходят для работы с информацией такого типа. Моделирование помогает системному инженеру в анализе требований для: – обсуждения разрабатываемой системы с заказ- чиком и улучшения взаимопонимания с коллегами; – анализа системы с целью убедиться в наличии желаемых системных свойств (emergent properties) и в отсутствии нежелательных свойств; |