Гост описание программы пример. Как написать хорошее описание к приложению? Краткий алгоритм оформления программы

Данный документ относится к типу программно-эксплуатационной. Применяется к программе, комплексу, ПАК, программному компоненту или системе.
Целевая аудитория: лица, которые принимают решение о покупке и вводе в эксплуатацию программы. Документ содержит информацию о функциональных возможностях программы и сфере её применения.

ГОСТы и стандарты

Структуру и оформление документа определяется в .
Информационная часть (аннотации и содержания) в соответствии с .

В каких случаях необходим

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

Всю необходимую информацию они смогут получить из этого документа: описание программы и ее применение.

В описании программы и описании применения указываются:

Задачи, которые решает программа;
Затрачиваемые ресурсы для работы;
Вводная информация;
Выходные данные.

Акцент делается на описательной части программы, её функциях и назначении. В меньшей степени на описании применения. Делается описание именно о возможностях программы и задач, которая она решает, а не её внутреннего устройства. При определённых особенностях программы допускается объединять разделы или вводить новые (дополнительные).

Структура описания программы (ГОСТ 19.402-78):

1. Общие сведения.
2. Функциональное назначение программы.
3. Описание логической структуры.
4. Технические средства, которые используются.
5. Вызов и загрузка.
6. Входные данные.
7. Выходные данные.

Структура описания применения (ГОСТ 19.502-78):

1. Назначение программы.
2. Условия применения.
3. Описательная часть задачи.
4. Входные и выходные данные.
5. приложения (таблицы, иллюстрации и т.д.).

Вы можете заказать разработку документа или полного комплекта документации на программное обеспечение.

В.Э. Карпов

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ (ГОСТ 19.201-78)

1. Общие положения

СТАДИИ РАЗРАБОТКИ (ГОСТ 19.102-77)

ОПИСАНИЕ ПРОГРАММЫ (ГОСТ 19.402-78)

ТЕКСТ ПРОГРАММЫ (ГОСТ 19.401-78)

ПРОГРАММА И МЕТОДИКА ИСПЫТАНИЙ (ГОСТ 19.301-79)

ТРЕБОВАНИЯ К ПРОГРАММНЫМ ДОКУМЕНТАМ, ВЫПОЛНЕННЫМ ПЕЧАТНЫМ СПОСОБОМ (ГОСТ 19.106-78)

Стандартизация в области документирования программных средств

Как двигаться вперед

Подготовка документации на программные средства (ПС) в соответствии с имеющимися ГОСТами

2. Общая характеристика состояния

2.3. Государственные стандарты РФ (ГОСТ Р)

2.4. Международный стандарт ISO/IEC 12207: 1995-08-01

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

Во-первых, умение создавать программную документацию определяет профессиональный уровень программиста. Заказчик не будет вникать в тонкости и особенности даже самой замечательной программы. Заказчик будет сначала читать документацию. Большую роль играет в этом и психологический фактор. В частности, во всем мире ценилась (и ценится сейчас) былая советская школа программирования. Современные же отечественные программисты котироваться перестали. Класс не тот. Нынче программы уже не пишутся, а составляются (а это - "две большие разницы"). Так вот, созданный в "классическом" стиле пакет программной документации (далее - ПД) создаст у вашего заказчика или работодателя самое что ни на есть благоприятное впечатление. Тем более, если автор ПД будет избегать фраз вида "кликните на скроллбар…", "винт" и т.п. К сожалению, за подобной жаргонной трескотней обычно скрывается либо скудость мыслей, либо полная пустота (неизгладимое впечатление произвел на автора рассказ одного его знакомого о неком "геймере", который с кем-то там то ли "чатился", то ли "модераторством" занимался или что-то в этом роде.). Язык ПД - это своего рода бюрократический, весьма консервативный язык. Есть в нем своя особая прелесть. Согласитесь, что термины НЖМД, НГМД, ручной манипулятор типа "мышь" (или "колобок", как значилось в одном из старинных пакетов ПД) звучат совсем иначе, нежели соответствующие "винт", "флоп" и просто "мышь". Между прочим, дело уже дошло до того, что, говорят, появилась даже особая специальность - технический писатель, т.е. человек, умеющий создавать программную документацию.

Во-вторых, грамотно составленный (точнее, созданный) пакет ПД избавит вас от многих неприятностей. В частности, избавиться от назойливых вопросов и необоснованных претензий можно просто отослав пользователя к документации. Это касается прежде всего важнейшего документа - Технического задания. Об этом мы будем говорить ниже, а сейчас можно напомнить о многомиллионном иске к компании IBM. Этот иск предъявило одно крупное издательство, неудовлетворенное качеством ВТ и программного обеспечения. IBM суд выиграла. И выиграла только благодаря тому, что предъявила подписанное обеими сторонами Техническое задание. Было это давно, еще в 70-х гг., однако сути дела это не меняет.

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

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

  • ИПК "Издательство стандартов", Территориальный отдел распространения НТД (магазин "Стандарты"), 17961, Москва, ул. Донская, д. 8, тел. 236-50-34, 237-00-02, факс/тел. 236-34-48 (в части ГОСТ и ГОСТ Р).
  • ВНИИКИ Госстандарта России (читальный зал), 103001, Москва, Гранатный пер. д. 4, тел. 290-50-94 (в части международных, зарубежных стандартов и других НТД).

И никаких цитат и вторичных источников. ГОСТ - это закон. И тем более, никаких Интернетов (представьте себе суд, выносящий приговор, пользуясь распечаткой Уголовного Кодекса, скачанного с какого-нибудь сайта). Не верьте никому, кроме оригинала. Тем не менее, далее автору придется прибегать к цитированию ЕСПД, снимая при этом с себя всяческую ответственность.

Начнем с общих положений о Единой системе программной документации (которые тоже определены в соответствующем стандарте ГОСТ 19.001-77).

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

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

  • основополагающие и организационно-методические стандарты;
  • стандарты, определяющие формы и содержание программных документов, применяемых при обработке данных;
  • стандарты, обеспечивающие автоматизацию разработки программных документов.

Вообще перечень документов ЕСПД очень обширен. В него, в частности, входят следующие ГОСТы:

  • ГОСТ 19.001-77 ЕСПД. Общие положения.
  • ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов (переиздан в ноябре 1987г с изм.).
  • ГОСТ 19.102-77 ЕСПД. Стадии разработки.
  • ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.
  • ГОСТ 19.104-78 ЕСПД. Основные надписи.
  • ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.
  • ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.
  • ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.
  • ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.
  • ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний.
  • ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.
  • ГОСТ 19.402-78 ЕСПД. Описание программы.
  • ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.
  • ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.
  • ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.
  • ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.
  • ГОСТ 19.504-79 ЕСПД. Руководство программиста.
  • ГОСТ 19.505-79 ЕСПД. Руководство оператора.
  • ГОСТ 19.506-79 ЕСПД. Описание языка.
  • ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
  • ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.
  • ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
  • ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Как видно, основная часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Частично эти стандартны морально устарели, к тому же они не лишены некоторых недостатков. Во-первых, в них не отражены некоторые современные тенденции оформления программ и программной документации, во-вторых, в этих стандартах наличествует многократное дублирование фрагментов программной документации. Тем не менее, за неимением лучшего ориентироваться приходится именно на них.

Итак, стандарты ЕСПД упорядочивают процесс документирования программных систем. Однако, во-первых, предусмотренный стандартами ЕСПД состав программных документов вовсе не такой "жесткий", как может показаться: стандарты позволяют вносить в комплект документации на программной системы (ПС) дополнительные виды, а, во-вторых, исходя из требований заказчика, допустимы некоторые изменения как в структуре, так и в содержании установленных видов ПД. Более того, можно отметить, что стандарты ЕСПД (а это относится и ко всем другим стандартам в области ПС - ГОСТ 34, Международному стандарту ISO/IEC, и др.) носят рекомендательный характер. Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе - т.е. при ссылке на них в договоре на разработку (поставку) ПС.

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

И еще. Описывая свой продукт, разработчик зачастую путает понятия компонента и комплекса. Это - разные виды программ. Компонент определяется как "программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса" , а комплекс - это "программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса" .

Согласно ГОСТу, настоящий стандарт (переизданный в ноябре 1987 г.) устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

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

Техническое задание оформляют на листах формата А4 и/или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

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

Техническое задание должно содержать следующие разделы:

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

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

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

В разделе Основание для разработки должны быть указаны:

  • документ (документы), на основании которых ведется разработка;
  • организация, утвердившая этот документ, и дата его утверждения;
  • наименование и (или) условное обозначение темы разработки.

Применительно к специфике учебного процесса основанием может служить задание на курсовое проектирование, приказ по институту от __.__. за N ___., договор __.__. за N ___. , и т.п.

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

Например: Программа представляет собой ядро автоматизированного рабочего места (АРМ) разработчика непрерывных линейных систем автоматического управления (САУ), позволяющее пользователю решать задачи анализа простых моделей.

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

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

Иными словами, здесь начинается конкретика. Описывается то, что должна делать программа и как она должна выглядеть.

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

Например: Программа должна позволять … вычислять … строить… создавать …

Исходные данные: текстовый файл с заданной …

Выходные данные: графическая и текстовая информация - результаты анализа системы…; текстовые файлы - отчеты о … диагностика состояния системы и сообщения о всех возникших ошибках.

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

Здесь "выгадать" что-то сложно. В лучшем случае может пройти вариант, при котором ваша программа работает только с абсолютно корректными данными. Обычно Заказчик на это не идет, но попробовать можно.

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

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

С этим пунктом сложностей обычно не возникает. К сожалению, пункт о профессиональности пользователя Заказчиком подразумевается обязательно. Это, конечно, лишний повод придраться к вашей программе. Впрочем, здесь можно ограничиться фразами вида "Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК", "Программа должная быть рассчитана на непрофессионального пользователя." и т.п.

Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.

Здесь главное - ничего не забыть и все предусмотреть, с одной стороны (а то подсунут какой-нибудь IBM PC/XT с монохромным дисплеем и без мыши), а с другой - не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя.

Например: Необходимо наличие IBM PC - совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство - не менее 600 Кб, объем свободной оперативной памяти - не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа "мышь".

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

Например: Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования - Turbo Pascal 6.0.

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

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

Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.

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

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

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

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

Здесь описываются стандартные этапы. Главное - грамотно определиться со сроками. По возможности, старайтесь равномерно распределить этапы по срокам (и суммам). Помните, что не все проекты доживают до последней стадии. А отчеты должны быть по каждому этапу. Помните также, что больше всего времени займет рабочий проект. Если вы не успеете сделать в срок документацию, то Заказчик имеет полное право вообще не принять работу со всеми вытекающими последствиями.

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

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

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

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

Например: В ходе разработки программы должен быть подготовлен следующий графический материал:

    • технико-экономические показатели;
    • структура программы;
    • формат представления входных данных программы;
    • общая схема алгоритма (2 листа);
    • основные вычислительные алгоритмы;
    • пример работы программы.

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

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

В Приложениях к техническому заданию, при необходимости, приводят:

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

Этот стандарт устанавливает стадии разработки программ, программной документации, а также этапы и содержание работ:

Стадии разработки

Этапы работ

Техническое задание

Обоснование необходимости разработки программы

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

Научно-исследователь-ские работы

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

Разработка и утверждение технического задания

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

Эскизный проект

Разработка эскизного проекта

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

Утверждение эскизного проекта


Согласование и утверждение эскизного проекта

Технический проект

Разработка технического проекта

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

Утверждение технического проекта

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

Рабочий проект

Разработка программы

Программирование и отладка программы

Разработка программной документации

Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.

Испытания программы

Разработка, согласование и утверждение программы и методики испытаний.
Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний.
Корректировка программы и программной документации по результатам испытаний.

Внедрение

Подготовка и передача программы

Подготовка и передача программы и программной документации для сопровождения и (или) изготовления.
Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.
Передача программы в фонд алгоритмов и программ.

Примечания:

  1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях - вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.
  2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.

Этот стандарт ориентирован на документирование результирующего продукта разработки.

Строго говоря, существуют два разных документа, имеющих, правда, много общего. Это ОБЩЕЕ ОПИСАНИЕ (ГОСТ 19.502-78) и ОПИСАНИЕ ПРОГРАММЫ (ГОСТ 19.402-78). Однако, в силу того, что реально создать качественно и тот, и другой, не прибегая к почти полному дублированию, выдирая куски, весьма сложно, было бы достаточно реализовать один, более общий, "гибридный" документ. Назовем его "Описанием программы".

На самом деле "Описание программы" в своей содержательной части может дополняться разделами и пунктами, взятыми и из стандартов для других описательных документов и руководств: ГОСТ 19.404-79 ЕСПД. Пояснительная записка, ГОСТ 19.503-79 ЕСПД. Руководство системного программиста, ГОСТ 19.504-79 ЕСПД. Руководство программиста, ГОСТ 19.505-79 ЕСПД. Руководство оператора и т.п. В частности, из Пояснительной записки можно взять схему алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений.

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

Основная часть документа должна состоять из вводной части и следующих разделов:

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

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

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

Например: Программа "Автоматизированное рабочее место разработчика САУ" предназначена для … реализована на …. Программа поддерживает …

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

Например: Программа предназначена для решения задач … Программа представляет собой ядро автоматизированного рабочего места …

Пользователь имеет возможность …, осуществить …, запустить …, проанализировать …, получить результаты анализа и обработки …, построить … и т.п.

В разделе "Описание логики " указывают:

  • описание структуры программы и ее основных частей

(например: В состав программы входит следующее:

  • пользовательский интерфейс,
  • модуль определения путей в графе,
  • модуль расчета передаточной функции,
  • модуль построения амплитудно- и фазочастотных характеристик,
  • модуль построения реакции на полиномиальное воздействие,
  • текстовый редактор) .

Например: Программа состоит из шести модулей: интерфейсный модуль; модуль определения …; модуль расчета …; модуль …и т.п..

Интерфейсный модуль построен на двух типах диалогов: диалог "вопрос - ответ" и диалог типа "меню". Интерфейсный модуль управляет …

Модуль определения … Он является …

Модуль расчета …и т.д.

  • сведения о языке программирования;

Например: Программа написана на языке …с использованием компилятора …

  • описание входных и выходных данных для каждой из составных частей;

Например: ВХОДНЫЕ ДАННЫЕ. Входными данными для программы является текстовый файл, описывающий расширенную матрицу инциденций графа исследуемой системы.

ВЫХОДНЫЕ ДАННЫЕ. Выходными данными являются:

  • выводимая на экран графическая и текстовая информация (результаты анализа системы);
  • файлы в одном из графических форматов - копии изображения построенных характеристик (АЧХ,ФЧХ и т.д.);
  • текстовые файлы - отчеты о проведенных исследованиях;
  • диагностика состояния системы и сообщения о всех возникших ошибках.
  • описание логики составных частей (при необходимости следует составлять описание схем программ).

При описании логики программы необходима привязка к тексту программы.

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

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

Например: Программа эксплуатируется на персональном компьютере (ПК) типа IBM PC/AT. Для работы в диалоговом режиме используется экран дисплея, клавиатура и манипулятор типа "мышь". Для поддержки графического режима необходим адаптер EGA (VGA). Входные данные хранятся на флоппи- и/или жестком дисках. Программа работает под управлением ОС …

В приложение к описанию могут быть включены справочные материалы (иллюстрации, таблицы, графики, примеры и т.п.)

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

Вызова и загрузки системы

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

По-прежнему обязательным является составление информационной части - аннотации и содержания.

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

Текст каждого программного файла начинается с "шапки", в которой указывается:

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

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

Ниже приведен пример подобного хорошо читаемого текста программы (взят с сайта Николая Гехта, e-mail:[email protected], http://users.omskreg.ru/~geht)

/* Исходные тексты Windows"98

Source Code to Windows 98 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" #define INSTALL = HARD char make_prog_look_big; void main() { while(!CRASHED) { display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) { make_50_megabyte_swapfile(); do_nothing_loop(); totally_screw_up_HPFS_file_system(); search_and_destroy_the_rest_of_OS/2(); disable_Netscape(); disable_RealPlayer(); disable_Corel_Products(); hang_system(); } write_something(anything); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(still_not_crashed) { display_copyright_message(); do_nothing_loop(); basically_run_windows_3.1(); do_nothing_loop(); do_nothing_loop(); } } if(detect_cache()) disable_cache(); if(fast_cpu()) { set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(action, jumpy); set_mouse(reaction, sometimes); } /* printf("Welcome to Windows 3.11"); */ /* printf("Welcome to Windows 95"); */ printf("Welcome to Windows 98"); if(system_ok()) crash(to_dos_prompt) else system_memory = open("a:\swp0001.swp", O_CREATE); while(something) { sleep(5); get_user_input(); sleep(5); act_on_user_input(); sleep(5); } create_general_protection_fault();

В этом документе содержится описание того, что и как необходимо сделать, дабы убедиться (и убедить Заказчика) в правильности работы программы. Фактически, этот документ является определяющим для приемо-сдаточных испытаний. Грамотно составленная программа и методика испытаний - это залог подписания акта сдачи-приемки, т.е. того, во имя чего вы потратили столько сил и времени.

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

Составные части этого документа проще и нагляднее описывать сразу в виде примеров.

Объект испытаний

Пример: Объектом испытаний является программа …, предназначенная для …

Цель испытаний

Пример: Проверка надежности функционирования программы.

Требования к программе

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

Требования к программной документации

Пример: Состав программной документации, предъявляемой на испытании:

  • описание программы (ГОСТ 19.402-78);
  • программа и методика испытаний (ГОСТ 19.301-79);
  • текст программы (ГОСТ 19.401-78).

Средства и порядок испытаний

Пример: Программа работает в соответствии с условиями эксплуатации ОС MS DOS (версия не ниже 3.0) на ПК типа IBM PC/AT, а также на совместимых с ним. Для работы необходим также адаптер EGA (VGA).

Порядок проведения испытаний:

    1. Запуск программы осуществляется ….
    2. Выбирается …
    3. Нажимается …
    4. Последовательно выбираются …

Тестовые примеры

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

И, наконец, рассмотрим последний стандарт ЕСПД, который называется

Этот стандарт устанавливает правила выполнения программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения и предусмотренных стандартами ЕСПД.

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

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

Повреждение листов документов, помарки и следы не полностью удаленного текста (графики) не допускаются.

Программные документы оформляют на листах формата А4. Кроме того:

  • допустимо оформление на листах формата А3;
  • при машинном способе выполнения документа допускаются отклонения размеров листов, соответствующих форматам А4 и А3, определяемые возможностями применяемых технических средств; на листах форматов А4 и А3, предусматриваемых выходными характеристиками устройств вывода данных, при изготовлении документа машинным способом;
  • при изготовлении документа типографским способом возможно использование листов типографических форматов.

Расположение материалов программного документа осуществляется в следующей последовательности:

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

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

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

Аннотацию размещают на отдельной странице (страницах), снабжают заголовком "АННОТАЦИЯ", нумеруют и включают в содержание документа.

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

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

Разделы, подразделы, пункты и подпункты следует нумеровать арабскими цифрами с точкой. Разделы должны иметь порядковый номер (1, 2 и т.д.)

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

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

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

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

В приложениях иллюстрации нумеруются в пределах каждого приложения в порядке, установленном для основного текста документа. Ссылки на иллюстрации дают по типу: "рис.12" или "(рис.12)". Иллюстрации могут иметь тематический заголовок и подрисуночный текст, поясняющий содержание иллюстрации.

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

Ссылки в тексте на порядковый номер формулы дают в скобках, например: "в формуле (3)". При делении документа на части номер части ставится перед порядковым номером формулы и отделяется от последней точкой, например: "в формуле (1.4)".

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

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

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

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

Сокращения. Сокращения слов в тексте и надписях под иллюстрациями не допускаются, за исключением:

  • сокращений, установленных в ГОСТ 2.316-68, и общепринятых в русском языке;
  • сокращений, применяемых для обозначения программ, их частей и режимов работы, в языках управления заданиями, в средствах настройки программы и т.п., обозначаемых буквами латинского алфавита.

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

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

Приложение 1, Приложение 2 и т.д.

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

Руководство о том, как правильно составлять описание приложения для магазина.

App Definition включает в себя 3 части: название, описание, и скриншоты. Давайте рассмотрим вопрос app definition кратко и более подробно.

Если кратко.

Название

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

Описание

По структуре:

  1. Первые 1–3 предложения в описании должны максимально четко описывать идею приложения и рассказывать, какую проблему оно решает. Максимальная длина этой части 255 символов.
  2. Если у приложения есть особые заслуги (featured on TechCrunch), о них нужно говорить.
  3. Основной текст описания может иметь 2–3 абзаца. Здесь мы расписываем характеристики и детали.
  4. В конце должен быть список главных функций с их четким описанием.
  5. В самый конец описания мы помещаем секцию “что нового?” Исправили баги, добавили фичи, поменяли звездочку на сердечко – все это здесь.
  • Описание должно понятно объяснить пользователю, как работает приложение и зачем оно нужно.
  • Ключевые слова нужно вставить в контекст всего описания, а не только названия.
  • Писать описание нужно от второго лица, с точки зрения пользователя, избегая технических деталей, и неясностей.

Скриншоты

Первый скрин – самый важный, здесь нужно описать основную функцию приложения. В описании к скриншотам лучше всего использовать глаголы. Именно они могут наиболее качественно объяснить пользователю, что нужно делать на конкретном экране и подталкивают его к действию. Глагол – самая сильная часть речи.

А теперь подробнее.

1. Как называется ваш продукт? Зачем он нужен?

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

Предназначение продукта – это ключевое слово, по которому пользователи находят приложение в апп сторах или google. Забив в google “app development company” мы найдем Yalantis , потому что наше полное название – Yalantis is a native iOS and Android app development company.

А если мы загуглим travel app, то поиск выдаст нам TripIt (с полным названием TripIt Travel Organizer – Free), TripAdvisor (TripAdvisor Hotels Flights Restaurants), TripCase (TripCase – Travel Organizer) и прочие приложения туристической тематики.

Возьмем, к примеру My Day . Его название на апп сторах звучит так:

My Day – Countdown Timer

Именно countdown timer, countdown app в данном случае, ключевое слово, по которому наше приложение находят пользователи.

Flipboard: Your Social News Magazine

Четко и понятно зачем нам нужен Flipboard, и сразу 3 ключевика: news, social и magazine.

Один из наших недавних проектов, Vochi, назвается на App Store:

Vochi messaging – Future Delivery

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

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

  • – Gay, same sex, bi, social network to chat and meet guys
  • – Discover Music, Artists, Videos & Lyrics
  • Polyvore – Personalized Fashion, Shopping and Style
  • Magisto – Video Editor & Movie Maker

В названии приложения допустимо иметь максимум 25 символов. Если слов будет больше, в поиске их просто не будет видно.

Теперь приступим к составлению описания для апп стора.

2. Как написать описание продукта?

1. Правила

Стараясь описать приложение для апп стора как можно лучше, необходимо соблюдать следующие правила:

  • SLAP – Stop, Look, Act, Purchase. Другими словами, захвати внимание пользователя используя односложные предложения с подлежащими и глаголами с самого начала. Передавая смысл просто и ясно, ты подтолкнешь пользователя к действию.
  • KISS – Keep it simple stupid. Вырежь все лишние слова, в которых нет никакого смысла. Не используй жаргон, это может отпугнуть.
  • WIIFM – What’s in it for me? Что пользователь получит, узнает, ощутит, скачав приложение? Какой у продукта value proposition?

Описание желательно писать от второго лица, с точки зрения того, как пользователь будет использовать продукт.

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

2. Какие функции выполняет ваше приложение?

Как правило, приложения выполняют довольно много разных функций от регистрации до terms and conditions. Однако, для описания продукта нам не нужны абсолютно все функции. Достаточно выделить несколько основных, и одну самую важную. Важная функция – это ваше value proposition, конкурентное преимущество и позиционирование вашего продукта на рынке .

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

Для нашего My Day, самая важная функция – countdown clock with reminder. Другие функции, перечисленные в описании, это обои, праздники, виджет, настройки цвета и стиля, и единицы времени, которые аппа способна высчитывать. Мы позиционируем My Day как красивый и удобный продукт, и в этом его ценность.

3. Из чего состоит описание?

Повествование о приложении для апп сторов можно разделить на 5 частей:

  1. 255 символов
  2. Ревью и награды (если есть)
  3. 2–3 абзаца основного текста
  4. Спиcок функций
  5. Что нового?

4. 255 первых символов

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

Иногда проблема, которую решает приложение, очевидна. Например, для фитнес приложения – это возможность брать тренировки с собой и заниматься физкультурой где душе угодно. Для дейтинговых апп, matching на основе технологии face recognition увеличивает шансы пользователя встретить свою половину. Социалочка для механиков дает им возможность обсудить аккумулятор не выходя из гаража. Приложение для недвижимости – счастливое освобождение от несговорчивых риэлторов и траты времени впустую.

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

is the entertainment network where videos and personalities get really big, really fast.

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

Watch videos that create trends, influence culture and make you laugh. Discover stories, characters and remixes you can’t find anywhere else. Be the first to hear incredible new artists and songs.

Ну все, тут меня уже окончательно купили. Я и тренд могу создать, и посмеяться, и вообще, там есть stories you can’t find anywhere else, то есть Vine – уникальное предложение.

И заметьте, watch videos, discover stories, new artists and songs – это явно ключевики, правильно вставленные в контекст.

Однако, бывает и так, что проблема не очевидна. Например, Uber и Instacart – это продукты, созданные ради комфорта. Когда их только выпустили, пользователи и сами не знали, что у них была проблема, которую эти ребята хотели решить. Но теперь-то знают!

Еще пример:

Rewind Time Tracking app : The best time tracking solution is the one you don’t even have to think about. Rewind automatically tracks your time based on your location. You just have to set up your important places and you’re done.

Поглядим:

Tracks time based on your location – вот она суть.

The best time tracking solution is the one you don’t even have to think about. – а вот это проблема, которую решает приложение.

You just have to set up your important places and you’re done. – а вот как пользоваться трекером.

5. Ревью и награды

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

Примеры ревью:

  • Quip – Docs, Chat, Spreadsheets: ** Featured in MIT Technology Review’s 10 Breakthrough Technologies 2014 **
  • Wish – Shopping made fun: “Love, love this app. It’s a fun app that u can wish on things u love and want. Highly recommend it to frndz & fmly,” – Olivia Austin . (гугл говорит, что это порно стар)
  • A must have for moms! ” – TechCrunch

Примеры наград:

  • AP Mobile is the award-winning app from The Associated Press, the definitive news source relied upon by thousands of newspapers, broadcasters and digital news providers worldwide .
  • Musixmatch Lyrics Finder: Musixmatch is the world’s largest lyrics catalog, that lets you enjoy diverse music with synced lyrics. Out of 155 countries it was selected for the Editor’s Choice on the App Store and was also chosen as an App Of The Year in 2013.

То есть, упомянув награду, нужно сказать за что вы ее получили:

  • news source relied upon by thousands of newspapers
  • the world’s largest lyrics catalog

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

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

6. Основной текст

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

Если писать описание маленькими абзацами, пользователю будет проще понять содержание и убедиться в том, что аппу нужно скачать.

В первых 2–3 предложениях мы уже сказали все самое главное:

Wunderlist helps millions of people around the world capture their ideas, things to do and places to see. (Wunderlist: To-Do List & Tasks)

Теперь, пришло время немного углубиться в детали и характеристики. К тому же, основной текст – отличное место для ключевиков (но ни в коем случае не повторяйте то, что уже сказали в начале).

Whether you’re sharing a grocery list with a loved one, working on a project, or planning a vacation, Wunderlist makes it easy to share your lists and collaborate with everyone in your life. Wunderlist instantly syncs between your phone, tablet and computer, so you can access your lists from anywhere.

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

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

Wunderlist is free to download and use. Wunderlist Pro upgrades your experience and gives you unlimited access to Files, Assigning and Subtasks to help you accomplish even more for $4.99 a month or $49.99 a year through an auto-renewing subscription.

7. Список функций

В списке желательно иметь от 3 до 7 функций, и все они должны иметь название и краткое описание. Иногда название фичи выносится заголовком, за которым следует предложение с текстом:

VSCO Journal: Publish original content to your Journal and share with the creative community. Find inspiration on the VSCO Journal, a publication highlighting creatives from around the globe.

Еще пример:

NYC Apartments and Real Estate by StreetEasy – приложение, которые мы разрабатывали для компании Zillow. Его основная функция – это поиск недвижимости, потому и в описании на апп сторе слово search встречается чаще всего. Помимо этого, перечисленны такие функции как:

  • ability to view, save and share for-sale and rental listings
  • email and call agents directly from the app
  • tap into the database for all kinds of market- and property-level facts and history

И еще один удачный пример из категории health & fitness:

FitStar Personal Trainer – Burn Calories & Lose Weight with Video Fitness Workouts led by Football Legend Tony Gonzalez (ну оочень длинное название). Основная функция этого приложения – видео тренировки. Но в добавок, перечислены следующие фичи (вкратце):

  • HD videos with legend
  • Challenges (setting personal goals)
  • Apple TV
  • Custom audio tracker
  • Track progress
  • Connect FitBit, Jawbone UO, MyFitnessPal
  • Integrated with Health app

Описывая функции, нужно соблюдать следующие правила:

  1. Не делай описание функций слишком длинным.
  2. Помести две наиболее важные функции в начале, а третью самую важную в конце.
  3. Здесь никто ничего не читает.
  4. Здесь никто ничего не читает.
  5. Каждая новая функция должна начинаться с нового слова, и желательно, чтобы первое слово во всем списке относилось к одной части речи (глаголы, прилагательные, существительные).
  6. Третья самая важная функция.

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

8. Что нового?

Например:

  • Now supporting iOS 9
  • Likes: See who liked your post
  • Now you can book up to 4 hotels at once on the app
  • Fixed a bug affecting some iPhone 6 and 6 Plus readers

9. Что можно и чего нельзя делать в описании?

Можно :

  • Value proposition в сжатом виде
  • Фраза “ideal for”
  • Убеждение: “Free forever!”
  • From the creators of…

Нельзя :

  • Злоупотрелять ключевыми словами в описании (слишком много ключевиков и отсутствие связи с контекстом описания негативно воспринимается пользователями)
  • Допускать грамматические ошибки и опечатки
  • Говорить техническим языком
  • Писать что-то вроде: Наш продукт был сделан в Нью-Йорке разработчиком Сидоровым.
  • Врать (в ответ получим плохие отзывы)
  • Писать запутанно и абстрактно
  • Гиперболизировать (использовать словечки типо revolutionize, revolutionary, game changing, disruptive, если это не правда на самом деле)

3. Как написать описание к скриншотам?

  • четко
  • информативно
  • коротко

Скриншоты должны описывать главные функции приложения, и говорить о конкретных use cases. Первый скриншот – самый важный, он должен описывать value proposition. Всего скриншотов должно быть 5.

ShopBob – Women’s Fashion

  • Shop the latest fashions and get trend updates and styling tips
  • Dresses to denim, shoes to swimwear, find what you’re shopping for now
  • Shop the latest styles first and create a personalized boutique of favorites
  • See all gorgeous details up close
  • The designers to put on your radar now

ShopBob – магазин, потому первый скрин говорит: купи.

Желательно начинать описание скриншота с глагола, а если функционал ограничен, то с существительного.

My Day – Countdown Timer

Зачем нужно описание приложения?

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

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

Вступление

В вашем распоряжении ограниченное количество слов. Взгляните на описание приложений — под иконкой в App Store помещается всего пара строчек.

Самые жесткие ограничения накладывает экран iPhone — у вас в запасе всего 225 символов. Это — самая важная часть вашего описания. Целиком описание ограничивается четырьмя тысячами символов, но именно от первых двух сотен зависит, захотят ли покупатели прочитать остальные.

Нужно выражаться чётко и ясно. Название приложения — и скриншоты — уже должны были в целом рассказать покупателю о том, что оно из себя представляет. Теперь нужно усилить это впечатление.

Вступление к описанию должно быть призывом к действию. Попытайтесь поставить себя на место своего покупателя. Что ему нужно?

Тут есть несколько простых правил.

  • Завладейте вниманием своего покупателя. Ставьте существительные и глаголы в начале предложения, чтобы сделать фразу динамичной и максимально понятной.
  • Не используйте жаргон, он может оттолкнуть. Отсеките все лишнее: вводные слова, деепричастные обороты, излишне цветистые выражения.
  • В чем ценность вашего приложения? Что покупатель получит, узнает или испытает, когда загрузит его?
  • Для того, чтобы увидеть, как будет выглядеть описание вашего приложения на экране iPhone or iPad, воспользуйтесь предварительным просмотром в бесплатной программе .
  • Итак, наживка на крючке — время закинуть удочку. Иными словами, закончили со вступлением, — продолжаем описание.

Детали

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

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

Не пренебрегайте абзацами. Люди пугаются, когда видят текстовое «полотно». Варьируйте длину предложения — это делает текст более выразительным. Используйте подзаголовки и переносы строки. Списки — тоже неплохой способ «разбить» текст и сделать его более привлекательным.

Списки

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

  • не делайте их слишком длинными;
  • два самых важных момента поместите наверх списка, остальные — внизу;
  • этот пункт вы, наверное, не прочитали;
  • этот точно не прочитаете.

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

Так что лучше будет разбить длинный список на несколько небольших, объединенных одной темой.

Поиск

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

В вашем описании должны присутствовать ключевые слова. Важно не переборщить. Они должны быть уместными. Не пытайтесь написать откровенно «продающий» текст — он неизбежно оттолкнет потенциального пользователя. Если нужна помощь и перспектива платить за нее вас не отталкивает — можете обратиться в Appnique или Sensor Tower (для англоязычных текстов, — прим. редакции) .

Локализация

Локализовать ваше приложение — относительно недорогой и простой способ увеличить количество скачиваний. У него практически нет недостатков. Исследование, которое провела Common Sense Advisory среди 3000 покупателей из 10 неанглоговорящих стран, показывает: более 75% респондентов хотят, чтобы приложение было на их родном языке.

В отчете, который озаглавлен «Не прочитаю — не куплю», помимо этого, указано: 55% пользователей совершают покупки только на тех сайтах, где представлена информация на их родном языке. Интересно, что при этом 50% опрошенных отметили, что их устроила бы даже навигация и часть контента на родном языке. То есть даже частичный перевод даст лучшие результаты, чем его полное отсутствие.

Учитывая этот факт, переведите хотя бы описание, если не все приложение целиком.

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

Убедитесь, что компания, которая занимается переводом, обладает соответствующими навыками. Google Translate вряд ли сможет передать те оттенки смысла, которые вы вложили в текст.

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

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

Обновления

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

Описание — это не только окно в ваше приложение, но еще и возможность получить высокий поисковый рейтинг.

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

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

Если пользователи задают одни и те же вопросы, подумайте над созданием раздела FAQ на сайте приложения.

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

Распространенные ошибки и как их избежать

Опечатки и пунктуационные/грамматические ошибки. Пригласите специально обученного копирайтера или, в крайнем случае, включите в текстовом редакторе проверку орфографии.

Запутанное и косноязычное описание. Если пользователь вас не поймет — то приложение он не скачает.

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

Все тайное становится явным. Правда о вашем приложении вскроется в течение нескольких секунд после загрузки — и потом будет храниться в кеше Google вечно. Так что не врите.

Слишком много ключевых слов. Я уже упоминал, что неуклюжие попытки напихать в текст как можно больше ключевых слов только оттолкнут покупателя.

В описании не учтены интересы ЦА. Пишите не для себя и не для конкурентов, — пишите для покупателя.

Пропущены важные детали. Сколько весит приложение? Сколько стоит подписка? Это не та информация, которой стоит пренебрегать.

Итак, приступаем

Подведу краткие итоги: нужно подготовиться, написать, отточить, перевести и затем обновлять по мере необходимости.

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

Напишите черновик описания или наймите для этой цели талантливого копирайтера.

Правьте, корректируйте и переписывайте заново — для максимального эффекта. Проверьте, как описание будет выглядеть на экране iPhone или iPad. Работайте до тех пор, пока оно не станет гладким, отточенным и привлекательным.

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

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

Хорошее описание к приложению поможет его продать и стимулирует загрузки.

Инструкция

Чтобы описать программу , начните с общего вступления. Опишите основную проблему, с которой сталкивается пользователь. Естественно, это должна быть та самая проблема, которую и решает описываемая программа. Кстати это способ сразу же очертить целевую аудиторию пользователей. Те, кому она будет полезна и необходима, ее скачают или купят. Другие же пользователи сэкономят время и не станут далее . Также во вступлении опишите основные возможности программы. Для этого достаточно 1-2 предложений.

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

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

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

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

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

Инструкция

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

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

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

Консервативность старшего поколения подтолкнет их купить товар, которым они будут пользоваться длительное (до 5-6 лет) время. Молодежь же уже привыкла к стремительному техническому прогрессу и любит пробовать все новое. Как правило, время использование нового товара достаточно ограничено и составляет от полугода до двух лет, в зависимости от сложности и технологичности товара.

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

Далее соберите фокус-группу - 10-15 человек, которые удовлетворяют вашим параметрам, и предложите им первым тестировать новые продукты и описывать впечатления. Таким образом вы сможете вовремя исправить ошибки и минимизировать потери при выводе товара или услуги на большой рынок.

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

Инструкция

Полезный совет

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

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

Инструкция

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

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

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

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

Exe-файл в операционной системе Windows - это исполняемый файл программ. Он представляет собой специальным образом обработанный код, написанный программистом, скомпилированный и преобразованный в исполняемый тип. Поэтому взять блокнот и написать файл exe, как это можно сделать с bat- или inf-файлами, нельзя.

Вам понадобится

  • - знание программирования.

Инструкция

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

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

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