Функциональность

Практичность

Атрибуты качества программного обеспечения

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

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

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

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

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

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

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

Существуют факторы, которые могут привести к тому, что созданный продукт не будет отказоустойчивым:

· Враждебность разработчиков по отношению к покупателям;

· Обсуждения с покупателями, при которых разработчики вводят покупателя в заблуждение относительно правильности использования программного обеспечения;

· Недостаточная осведомленность или непонимание того, как покупатель будет использовать продукт;

· Громкие фразы разработчиков о нуждах покупателя, не основанные на объективных данных;

Если вы замечаете какие-либо из этих признаков, начинайте задавать вопросы. При необходимости включите в свой коллектив более опытных разработчиков.

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

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

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

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

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

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

Надежность. О дефектах в программном обеспечении лучше всего думать с точки зрения возможности их возникновения. Большинство пользователей пользуются программами аналогичным образом: они заставляют их выполнять какие-либо сценарии. Такие сценарии должны быть тщательно изучены и протестированы. Любой дефект программного обеспечения, возникающий при их выполнении, будет очень часто возникать и при работе в "полевых" условиях. Это свидетельствует о том, что данная программа очень ненадежна. Время от времени пользователи находят способы нестандартного использования программного обеспечения. Возникающие при этом ошибки найти и устранить тяжелее. На практике поиск таких выполняемых сценариев может занять тысячи часов тестирования. Для обнаружения ошибок необходимо, чтобы система автоматически моделировала поведение различных пользователей, либо перед выпуском продукта необходимо представить программный код на рассмотрение пользователям. Предварительное тестирование кода пользователями является причиной проведения бета-тестирования системы. На практике в хорошем программном обеспечении дефекты легко обнаружить и устранить на ранней стадии тестирования. А плохая программа сразу же выйдет из строя, что затруднит обнаружение и устранение дефектов. При продолжении проведения тестирования надежность системы увеличивается, и каждый последующий дефект обнаружить и устранить все тяжелее. Проведенные исследования подтверждают гипотезу о том, что стоимость поиска дефекта возрастает в геометрической профессии. В итоге руководитель должен решить, когда нужно остановиться, т.е. в какой момент стоимость тестирования и потеря рынка придут в равновесие с ожидаемой эксплуатацион­ной стоимостью. Именно в этот момент продукт считается готовым к выходу на рынок.

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

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

Работоспособность — это процентное соотношение времени, в течение которого программное обеспечение доступно пользователям. На первый взгляд может показаться что хорошим результатом является показатель работоспособности системы, равный 99% Однако в таком случае из 365 дней года программное обеспечение не будет доступным в течение 3,65 дня. Программное обеспечение, показатель работоспособности которого составляет 99,999%, не будет доступным в течение 5 минут t год,что является вполне приемлемым для банковской системы или системы бронирования, но недостаточным для телефонной системы.

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

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

Ремонтопригодность. Существуют два аспекта понятия ремонтопригодность, которые легко перепутать:

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

Более общим определением является стоимость технического обслуживания продукта в условиях его эксплуатации.

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

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

· источники дефектов легко установить;

· устранение одного дефекта не порождает другого.

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

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

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