Нефункциональные требования к ПО. Критерии качества

Программирование Технология и методы программирования Нефункциональные требования к ПО. Критерии качества

Помечено: 

В этой теме 0 ответов, 1 участник, последнее обновление  Васильев Владимир Сергеевич 2 года/лет, 3 мес. назад.

  • Автор
    Сообщения
  • #3585
    @admin

    Когда-то давным-давно, в одной далекой-предалекой галактике, когда я сдавал в университете на первом курсе экзамен по программированию, у меня в билете был вопрос «Критерии качества программы». Я на него, естественно, не ответил. То есть, не ответил правильно, поскольку тогда у меня был только один критерий — «Программа работает». Шло время, и я постепенно начинал понимать, что для качественной программы этого мало.

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

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

    Если вы не являетесь демосценером, кулхацкером, GNU-шником, БэХоЦе-шником или каким-либо другом фанатиком, а являетесь здоровым, полноценным и здравомыслящим человеком, то у вас должна быть одна конечная цель — создать конкурентноспособный продукт, выпустить его на рынок и заработать деньги. Для достижения этой цели, естественно, необходимо работать, то есть, затрачивать определенные ресурсы.

    В процессе создания программы затрачивается два типа ресурсов: время и деньги. При этом, ценность ресурса «время» я ставлю на несоизмеримо более высокий уровень нежели стоимость ресурса «деньги». Время — самый ценный ресурс. Тезис этот не мой, но я с ним согласен на все 120%. Да и в общем-то сомневаться тут и не в чем — потраченное время, в отличие от потраченных денег, невозможно восполнить. Помните старый советский кинофильм «Сказка о потерянном времени»?

    Время — не деньги!

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

    Следование вышеупомянутому критерию заставит вас писать легко масштабируемые программы. Предположим, в вашей программе два потока и она обслуживает одно сетевое соединение. Много ли изменений вам придется внести, чтобы ваша программа смогла так же стабильно работать в десятки тысяч потоков и столько же постоянно возникающих и обрывающихся сетевых соединений? Много?.. — Плохо! Мало?.. — Хорошо! Нисколько?.. — Прекрасно! Нисколько, и при этом нет никакого оверхеда на масштабируемость, так как вся масштабируемость заложена в compile-time-овых структурах, свойствах и механизмах, и имеет полноценный data driven подход?.. — Идеально!

    Зарисовка из жизни

    Вариант первый, как это обычно бывает:

    — Мне нужна программа!
    — Давай много денег и вот тебе уже и программа!
    — А теперь нужно чтобы эта программа обслуживала в сто раз больше пользователей!
    — Хм… Видимо придется все переписать… 🙁

    Вариант второй, уже неплохо:

    — Мне нужна программа!
    — Давай много денег и вот тебе уже и программа!
    — А теперь нужно чтобы эта программа обслуживала в сто раз больше пользователей!
    — Купи комп в сто раз мощнее 😉

    Вариант третий, и самый лучший:

    — Мне нужна программа!
    — Давай много денег и вот тебе уже и программа!
    — А теперь нужно чтобы эта программа обслуживала в сто раз больше пользователей!
    — Установи прогу на сто компов 🙂

    Лучше день потерять

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

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

    Помните мультик «Крылья, ноги и хвосты»? Была там такая фраза: «Лучше день потерять, потом за пять минут долететь». Эта фраза очень хорошо отражает процесс создания программного обеспечения. День потерять — создание движка (библиотеки, и так далее, то есть вновь используемого кода), за пять минут долететь — создание конкретной программы на движке (то есть одноразового кода).

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

    Нефункциональные требования к программному обеспечению

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

    Как и для любых показателей, которые определяются на этапе проектирования, кроме желаемых характеристик, следует также, в первую очередь, выявить их минимально допустимые значения. Например, если система будет доступна в рабочем состоянии меньше 100 часов в неделю (Availability = 100/168 ~ 59.52%), то такая система для бизнеса будет не интересна (убыточна, не приносить никакой пользы). Зачем это нужно?
    Дело в том, что далеко не все базы данных, сервера приложений или технологические платформы могут обеспечить необходимые показатели доступности (availability), масштабируемости, надежности и т.д.. Выбор тех или иных решений должен зависеть от этих характеристик.

    Краткий список нефункциональных показатели системы (Non-functional QoS):

    • Scalabitlity — Масштабируемость. Возможность увеличивать производительность системы пропорционально выделенным ресурсам. Бывает горизонтальная и вертикальная. Вертикальная — докупаем более быструю память, более шустрый жесткий диск или переносим всё на один еще более мощный сервер. Горизонтальная — покупаем еще один сервер и запускаем приложения в кластерном режиме, в случае необходимости — докупаем еще один сервер и втыкаем к двум уже работающим и так далее.
    • Extensibility — Расширяемость. Возможность добавление дополнительного функционала.
    • Flexibility — Гибкость. Возможность менять существующую архитектуру (например в зависимости от ценовой политики). В отличие от Extensibility, речь идет только об изменениях без дополнительного функционала. Например у заказчика нет денег на нормальную СУБД (допустим ORACLE). Наша задача сделать систему настолько гибкой, чтобы в случае необходимости мы смогли её подпилить так, чтобы она смогла бы обойтись чем-нибудь бесплатным (MySQL или PostgreSQL).
      Насколько должна уметь прогибаться система, желательно, по мере возможности, определить по-раньше…
    • Maintainablity — Поддерживаемость, ремонтопригодность. Способность поддерживать систему в работоспособном состоянии. Показатель определяет насколько легко (или сложно) вносить исправления в работающую систему, возможно ли повторное развертывание и запуск системы после сбоя, возможность восстановить из резервных хранилищ и т.д.
    • Availability — коэффициент доступности(готовности). Процент времени проведенного системой в работоспособном состоянии к общему времени работы системы.

      $$A = \frac{Uptime}{Uptime+Downtime}$$

      часто высоко доступные (High Availability) системы меряются девятками:

      1. 99,9 % (три девятки) = система недоступна не более 8,76 часов/год
      2. 99,99 % (четыре девятки)= не более 52,6 минуты/год
      3. 99,999 % (пять девяток) = не более 5,26 минуты/год
    • Manageability — управляемость. Возможность отслеживать и предотвращать возможные сбои в системе. Это в первую очередь наличие логирование (журналирование), системы оповещения о сбоях, возможность предотвратить возникновения ошибки.
    • Reliability — надежность. Вероятность безошибочного выполнения операций в определенный период времени в определенном окружении.

Для ответа в этой теме необходимо авторизоваться.