Привет, Вы узнаете о том , что такое качества в проектах программных средств, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое качества в проектах программных средств , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

12.1. Принципы выбора характеристик качества в проектах программных средств

Описание в стандарте ISO 9126:1-4 характеристик качества программных средств не содержит рекомендаций и методик выбора их значений в требованиях к конкретным проектам. Необходимо, прежде всего, установить рациональные диапазоны мер и шкал для каждой характеристики и ее атрибутов, которые можно будет использовать в качестве первичных ограничений при выборе их значений для реальных проектов. Далее должны быть разработаны процессы выбора, установления и представления в спецификациях требований к атрибутам каждой характеристики качества. Эти требования должны учитывать реальные ограничения ресурсов, доступных для обеспечения ЖЦ ПС. Ресурсы этих процессов и атрибуты характеристик качества ниже, по возможности, сводятся к трудоемкости и длительности их реализации, а также к соответствующему влиянию этих параметров в функциональную пригодность.

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

342

12.1. Принципы выбора характеристик качества в проектах программных средств

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

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

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

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

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

343

Лекция 12. Выбор характеристик качества в проектах программных средств

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

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

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

344

12.1. Принципы выбора характеристик качества в проектах программных средств

нивают конкурентоспособность продукции на рынке по величине отношения:

• возможной экономической эффективности (ценности) применения и качества программного продукта и способности удовлетворить пользователями свои потребности при его использовании;

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

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

Такие проекты обычно относительно невелики по объему и срокам реализации первой версии, однако могут предполагать длительный ЖЦ и множество модификаций для адаптации к нуждам и среде пользователей. Отбраковка вариантов реализации ПС ведется по показателю эффективность/стоимость для пользователей, с учетом конкурентоспособности и распространения на рынке. Этот сценарий экономического обоснования проектов ПС требует специфических маркетинговых исследований рынка подобных продуктов и их характеристик качества. Однако при этом должны обязательно учитываться затраты ресурсов на непосредственную разработку и обеспечение ЖЦ ПС, и возможная рентабельность проекта с учетом прогноза его жизненного цикла и распространения на рынке. Для этого в начале проектирования разработчикам необходимо прогнозировать затраты на создание и весь ЖЦ ПС, что анализируется при втором сценарии.

Второй сценарий предполагает наличие определенного заказчика — потребителя проекта ПС, который определяет основные технические и

345

Лекция 12. Выбор характеристик качества в проектах программных средств

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

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

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

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

346

12.1. Принципы выбора характеристик качества в проектах программных средств

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

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

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

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

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

На первом этапе следует использовать всю базовую номенклатуру характеристик, субхарактеристик и атрибутов, стандартизированных в ISO 9126:1-4. Об этом говорит сайт https://intellect.icu . Их описания желательно предварительно упорядочить по приоритетам с учетом назначения и сферы применения конкретного ПС. Далее необходимо выделить и ранжировать по приоритетам потребителей, которым необходимы определенные показатели качества ПС с учетом их специализации и профессиональных интересов. Широкая номенклатура характеристик, представленная в стандарте ISO 9126:1-4, поддерживает

347

Лекция 12. Выбор характеристик качества в проектах программных средств

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

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

12.2. Пример выбора и формирования требований к характеристикам качества программного средства

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

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

348

12.2. Пример выбора и формирования требований к характеристикам качества...

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

Таблица 12.1

Пример распределения приоритетов требований к характеристикам качества программного средства

Стандартизированные в ISO 9126:1-4 характеристики качества ПС различаются по степени влияния на системную эффективность — функциональнуюпригодность их применения по прямому назначению. Вследствие реальной ограниченности ресурсов, которые доступны в жизненном цикле ПС, их необходимо выделять с учетом влияния на эту эффективность. Для этого целесообразно в процессе системного анализа присваивать и учитывать уровень приоритета требований к каждой субхарактеристике. В таблице 12.1 представлен пример возможного распределения приоритетов требований заказчика к субхарактеристикам ПС для принятого

349

Лекция 12. Выбор характеристик качества в проектах программных средств

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

Выбор требований к мерам характеристик качества, естественно, должен начинаться с определения необходимых свойств и значений группы показателей, отражающих функциональные возможности ПС, куда по стандарту ISO 9126:1-4 входят субхарактеристики: функциональная пригодность, корректность, способность к взаимодействию и защищенность — безопасность. Пример содержания и возможных диапазонов изменений атрибутов качества этих субхарактеристик был представлен выше в таблице 11.1 (см. лекцию 11). Для конкретного проекта ПС перечень атрибутов качества следует адаптировать и уточнять с учетом его назначения и функций.

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

Требования к субхарактеристике корректность могут представляться в виде описания двух основных свойств, которым должны соответство-

350

12.2. Пример выбора и формирования требований к характеристикам качества...

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

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

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

351

Лекция 12. Выбор характеристик качества в проектах программных средств

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

Таблица 12.2

Пример требований к количественным характеристикам качества программного средства

Тактические цели выбора конструктивных характеристик качества стандарта ISO 9126:1-4 последовательно рассмотрены и иллюстрированы таблицами 12.2 и 12.3. Пример требований к основным количественным характеристикам качества ПС сложной административной

352

12.2. Пример выбора и формирования требований к характеристикам качества...

системы представлен в таблице 12.2. Все меры и шкалы для атрибутов характеристик выбраны в соответствии с их содержанием из таблицы 11.2 (лекция 11). Требования к атрибутам характеристики надежность могут быть выбраны с учетом следующих факторов. При отсутствии автоматического рестарта, за счет отладки и при наличии администратора, контролирующего работоспособность ПС, можно считать допустимой наработку на отказ порядка 10 часов. За счет программно-аппаратных механизмов автоматического рестарта эта наработка при проявлении отказов может быть повышена приблизительно в 5 раз, т.е. при 80% отказов возможно их автоматическое обнаружение и оперативное восстановление, вследствие чего наработка на отказ возрастет до 50 часов. По опыту, на обеспечение этого может потребоваться около 10% вычислительных ресурсов системы. Предполагается, что для оперативной работы пользователей административной системы допустимая длительность прерывания работы для полного восстановления нормального функционирования системы может составлять не более 5 минут. В результате при таких значениях атрибутов надежности коэффициент готовности — вероятность застать ПС в работоспособном состоянии — составит достаточно высокую величину 0,998.

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

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

353

Лекция 12. Выбор характеристик качества в проектах программных средств

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

Таблица 12.3 Пример требований к качественным характеристикам

Программного средства

354

12.2. Пример выбора и формирования требований к характеристикам качества...

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

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

Требования к практичности и ее субхарактеристикам — понятности и простоты использования — зависят от назначения и функций ПС и могут качественно формализоваться заказчиками набором свойств, необходимых для удобной и комфортной эксплуатации программ. Количественно простоту использования можно в некоторой степени характеризовать требованиями ограничения средней длительности ввода типовых заданий и времени отклика на них, которое должно быть в несколько раз меньше. Требования к продолжительности изучения ПС, достаточной для эффективной эксплуатации сложной административной системы квалифицированным специалистом, в данном примере могут составить около недели или порядка 50 часов. Для коллектива из четырех человек-эксплуатационников это потребует трудоемкости около 200 человеко-часов. Для обеспечения полноценного изучения процессов применения ПС этими специалистами может быть необходима эксплуатационная документация объемом около 1000 страниц, а также желательны адекватные по содержанию электронные учебники. Малый объем эксплуатационной документации может снизить качество и полноту использования функций сложного ПС, а очень большой объем — также может ухудшить эксплуатацию из-за

355

Лекция 12. Выбор характеристик качества в проектах программных средств

трудности выделения и освоения наиболее существенных свойств и особенностей применения ПС из множества второстепенных деталей.

Требования к компонентам сопровождаемости количественно можно установить для субхарактеристик изменяемости и тестируемости. Требуемые значения зависят от четкости концепции и архитектуры ПС, от унифицированности внутренних, внешних и с пользователями интерфейсов, от качества технологической документации, а также от инструментальной оснащенности ЖЦ данного ПС и еще от некоторых факторов. Обобщенно это отражается на длительности и трудоемкости подготовки и реализации типовых модификаций, обусловленных необходимостью устранения дефектов и небольшими усовершенствованиями функций ПС. В рассматриваемом примере для подготовки и выполнения каждого изменения (без учета затрат времени на обнаружение и локализацию дефекта) можно принять среднюю продолжительность в 5 часов и суммарную трудоемкость двух специалистов около 10 человеко-часов. Требования к продолжительности тестирования таких изменений могут составить также до 5 часов, но трудоемкость может увеличиться до 20 человеко-часов, так как требуемый коллектив тестировщиков может возрасти до трех-четырех специалистов.

Выбор и установление требований к мобильности ПС в данном примере сведены к трудоемкости и длительности процессов: адаптации к характеристикам пользователей и внешней среды, инсталляции версий ПС в среде пользователей и замены крупных компонентов версий ПС по требованиям заказчиков или конкретных пользователей. Наиболее простым и легко формализуемым из перечисленных процессов является инсталляция готовой версии ПС с комплектом документации без дополнительных изменений на платформе пользователя, которая может требовать до 5 часов работы двух специалистов (10 человеко-часов). Более сложный процесс включает адаптацию ПС по формализованным инструкциям к специфической аппаратной и внешней среде конкретного пользователя, которая может потребовать вдвое большего времени и в несколько раз (в примере 5) большего числа специалистов. Еще более сложный и трудоемкий процесс замены крупных компонентов ПС и перенос их на иную аппаратурную и операционную платформу. Для этого процесса в примере требуется не менее 20 часов и коллектив около 5 человек (100 человеко-часов).

356

12.2. Пример выбора и формирования требований к характеристикам качества...

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

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