Читать онлайн «Человеческий фактор в программировании». Страница 82

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

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

По материалам журнала Object Magazine, июнь 1997 г.

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

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

По многим причинам руководители проектов по разработке программного обеспечения в первую очередь применяют метрику размера и сложности. То, что измеряется, является очевидным и может быть легко интерпретировано. Измерения размера и сложности позволяют отслеживать продвижение разработки и количественно оценивать продуктивность разработчиков. В сочетании с хорошей базой статистических данных такие измерения дают возможность намного точнее и надежнее оценить время разработки и связанные с ней расходы, чем это можно сделать при помощи более распространенных субъективных подходов, которые зачастую сводятся к выдумыванию ex nihilo[42] и последующему умножению на какой-нибудь взятый с потолка коэффициент.

Для разработчиков количественные измерения качества проектирования потенциально являются более важными, чем простые измерения количества кода. Проектная метрика основана на исчисляемых и измеряемых аспектах проекта, которые описывают важные стороны законченного продукта — все, что интересует разработчиков с точки зрения предполагаемого метода реализации, работы и обслуживания данного программного обеспечения. Например, компонентное сцепление и межкомпонентное связывание, два известных измеримых параметра проектирования, описывают, насколько легко можно будет модернизировать или расширить программу с помощью частичной декомпозиции на взаимосвязанные элементы. Термины «сцепление» и «связывание», впервые появившиеся в раннюю эпоху структурного проектирования (Yourdon и Constantine, 1979 [70]), со временем перешли в объектно-ориентированное проектирование в виде мер сцепления классов и межклассового связывания. Формы этих мер были широко исследованы — как классическая, так и объектно-ориентированная (Henderson-Sellers, Constantine и Graham, 1996 [39]).

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

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