Куперс

Вы написали программу или приложение? Вы хотите ее продать. А готова ли эта программа к тому, чтобы достойно конкурировать на рынке «софта». Оказывается, об этом задумываются далеко не все разработчики, даже те, кто занимается программированием профессионально.

Первое, что неплохо бы сделать перед распространением программы или приложения — провести предпродажное тестирование. В отличие от отладки, которая в основном подразумевает «доведение до ума» отдельных модулей (Все более-менее сложные программные продукты являются многомодульными), полное тестирование проводят, когда все модули подключены. Это может показаться очевидным, но этот шаг часто упускается из виду многими разработчиками (Безусловный лидер подобного разгильдяйства, корпорация Microsoft). Не верите? Посмотрите на современное программное обеспечение, «глюк» на «глюке». Не убедило? Обратитесь в любое отделение форума CompuServe занимающегося контролем программного обеспечения. Почти каждое крупное предложение имеет «дыры» некоторые, из которых на столько велики, что остается только руками разводить.

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

Во время отладки ошибки можно распределить по степеням опасности для нормальной работы приложения, а также вашего кармана и самолюбия.

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

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

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

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

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

Большинство пользовательских приложений сейчас пишется на языках, работающих c объектами (Borland Delphi, Visual Basic) в том числе и с графическими. Эти языки позволяют без особых временных затрат создавать приложения, в которых ввод данных можно упростить до «клика» мышью. В классических языках программирования создание удобного интерфейса — задача достаточно трудоемкая. Эти свойства нынешних сред разработки рекомендуется использовать как можно шире. Ведь в системе человек/компьютер ошибаться может только человек. А попробуйте засадить оператора за работу с приложением, в которое за день приходиться вводить до тысячи длинных названий и кодов более чем из двадцати символов. В скольких из них он сделает ошибки?

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

Раньше, когда почти не существовало графических оболочек и операционных систем (речь идет о PC-технике), а интерфейсы программ создавались в только в текстовым режиме, о внешнем виде того, что продают, заботились мало. Теперь ситуация изменилась в корне. Лозунг «чем красивее, тем лучше», пущенный в свет Б. Гейтсом, стал основополагающим для многих. Что же, и нам отставать не след.

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

Вид приложения не должен существенно отличаться от общепринятых. Каждому хочется сделать что-то оригинальное, такое, чего нет у других. Но не стоит забывать, что интерфейс должен быть не только красивым и «навороченым», но также интуитивно понятным и простым для восприятия. Самым распространенным, самым привычным, а следовательно, наиболее приемлемым на сегодняшний день можно считать интерфейс «а-ля Microsoft Office».

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

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

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

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

• Название программного продукта (большими красивыми буквами).
• Номер версии программного продукта.
• Информацию об изготовителе.
• Сообщение об авторских правах.

Если в заставке используется рисунок, постарайтесь, чтобы он соответствовал функции приложения. Классический пример в этом случае — заставка от Word 6.0: ручка и лист бумаги.

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

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

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

Хорошо написанная, контекстно-зависимая справочная система — это уже гораздо интересней, как для пользователя, так и для разработчика. Она резко поднимет акции вашего приложения.

Последний элемент, рассматриваемый перед распространением приложения, — уровень защиты. Все системы программирования имеют встроенные средства защиты, но полагаться на них полностью я бы не рискнул. Например, модель защиты Access 2.0 рекламировалась Microsoft как самая надежная из всех существующих. Но, как выяснилось, даже среднего уровня разработчик Access может взломать ее за полчаса, причем с использованием минимума кода. Просто примите это к сведению.

Когда все готово, протестировано, отлажено и причесано, можно искать способ распространения Вашего программного продукта. Распространение включает в себя поставку всех файлов, необходимых для работы приложения, на каком либо носителе, например, на дискете или компакт-диске. Также можно воспользоваться электронными возможностями сети Internet. На носителе должна содержаться программа установки, автоматизирующая перенесение (копирование) файлов на компьютер будущего пользователя, настраивающая все необходимые компоненты, производящая процесс регистрации и вносящая необходимые изменения в системные реестры. Такие действия обычно выполняются с помощью Developer Toolkit (пакет разработчика). В разных системах программирования они имеют разные названия, но присутствуют практически в любой.

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

Кирилл Кириллов

Это перевод страницы, написанной на английском языке.

Продажа свободных программ

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

Многие убеждены, что дух проекта GNU состоит в том, что вы не должны брать денег за распространение копий программ или что вы должны брать как можно меньше — только чтобы покрыть расходы. Это заблуждение.

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

У слова «свободный” есть два правомерных общих значения: оно может означать свободу или цену. Когда мы говорим о «свободных программах”, мы говорим о свободе, а не о цене. (Думайте о «вольной речи”, а не о «бесплатном пиве”.) Конкретно это означает, что пользователь волен выполнять программу, изучать, дорабатывать программу и перераспространять программу с изменениями или без них.

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

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

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

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

Распространение свободных программ — возможность получить средства на разработку. Не упускайте ее!

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

Повредит ли более высокая плата за распространение некоторым пользователям?

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

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

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

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

Помешает ли повышенная плата за распространение пользоваться свободной программой?

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

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

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

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

Выражение «продажа программ” может и вводить в заблуждение

Строго говоря, «продажа” означает обмен товаров на деньги. Продажа копии свободной программы законна, и мы поощряем это.

Однако когда люди думают о «продаже программ”, они обычно представляют себе то, как это делает большинство компаний: эти компании делают программы несвободными.

Таким образом, если вы не намерены тщательно проводить различия, как это делается в нашей статье, то мы предлагаем избегать употребления термина «продажа программ» и выбрать вместо этого какое-нибудь другое выражение. Например, можно было бы говорить «распространение свободных программ за плату” — это не порождает двусмысленностей.

Высокая или низкая плата и GNU GPL

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

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

Иногда компании, чья деятельность выходит за черту, которую проводит GNU GPL, выпрашивают разрешение, говоря, что они «не будут брать деньги за программы GNU” и тому подобное. Таким образом от нас нельзя добиться ничего. Свободные программы означают свободу, а следить за соблюдением GPL значит защищать свободу. Когда мы защищаем свободу пользователей, мы не отвлекаемся на такие смежные вопросы, как величина платы за распространение. Мы думаем о свободе, только о свободе и ни о чем, кроме свободы.