Качество ПО

Переносимость (Portability)

Определение: переносимость

Переносимость - это легкость переноса ПО в различные программные и аппаратные среды.

Переносимость имеет дело с разнообразием не только физического оборудования, но чаще аппаратно-программного механизма, того, который мы действительно программируем, включающего операционную систему, систему окон, если она применяется, и другие основные инструменты. В дальнейшем в нашем курсе будет использоваться слово "платформа" для обозначения аппаратно-программного механизма; примером платформы может служить "Intel X86 + Windows NT" (известная как "Wintel").

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

Простота использования (Easy of Use)

Определение: простота использования

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

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

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

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

Желательно, чтобы проектировщики ПО, озабоченные простотой использования, с некоторым недоверием рассматривали принцип "знай пользователя". Изложенный в статье Хансена^{1См. Wilfred Hansen, "User Engineering Principles for interactive Systems", Proceedings of FJSS 39, AFIPS Press, Montvale (NJ), 1971. pp 523-532} , он часто цитируется в литературе, посвященной пользовательским интерфейсам. Подразумевается, что хороший проектировщик должен приложить усилие для понимания того, для каких пользователей предназначена система. Этот взгляд игнорирует одно из свойств успешной системы: она всегда выходит за пределы предполагаемого круга пользователей. Напомню два старых известных примера - язык Fortran разрабатывался как инструмент для решения задачи небольшого сообщества инженеров и ученых, программирующих на IBM 704, операционная система Unix предназначалась для внутреннего использования в Bell Laboratories. Система, изначально спроектированная для особой группы людей, исходит из предположений, которые просто не будут работать для более широкой группы.

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

Принцип построения пользовательского интерфейса

Не делайте вид, что вы знаете пользователя - это не так.

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

Определение: функциональность

Функциональность - это степень возможностей, обеспечиваемых системой.

Одна из самых трудных проблем, с которой сталкивается руководитель проекта, - определение достаточной функциональности. Всегда существует желание добавлять в систему все новые и новые свойства. Желание, известное на языке индустрии как фичеризм (featurism) , часто ползучий фичеризм (creeping featurism) . Его последствия плачевны для внутренних проектов, где давление исходит от разных групп пользователей внутри одной и той же компании. Они еще хуже для коммерческих продуктов, испытывающих давление, например от журналистских сравнительных обзоров, представляющих чаще всего таблицу, включающую одновременно свойства разных конкурирующих продуктов.

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

Каково же решение проблемы? Необходимо снова и снова работать над состоянием всего продукта, пытаясь привести его в соответствие с общим замыслом. Хорошее ПО основывается на небольшом количестве сильных идей. У него может быть много специальных свойств - все они должны быть следствиями основных положений. "Великий план" должен быть виден, и в нем всему должно отводиться свое место.

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

Рис. 1.4. Кривые Осмонда; по [Osmond 1995]

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

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

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

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