Program description. How to describe a program Document description of the application of the program example

GOST 19.101-77 defines a program description as a set of information about the logical structure and functioning of the program. The program description should consist of four main parts: title part, information part, main part, part of registration of changes.

Main part should contain the following sections: general information, functional purpose, description of the logical structure used technical means, call and load, input data, output data.

Depending on the features of the program, it is possible to introduce new sections or combine individual sections. When describing software product containing several program units (programs, subprograms), a description according to the specified scheme is given for each program unit, while adhering to the layout hierarchy of the overall software product. So, for example, if general program Control includes a call to the FileExist function and the Brackets procedure, which in turn refers to the Error procedure, and the general diagram of the hierarchy of this software product is shown in Figure 6, then the description must begin with the Control program unit, then describe the FileExist, Brackets, Stack program units, then describe the Error program unit as part of Brackets

An example of the hierarchy of a complex software product is shown in Figure 6.

Control program

placement of brackets

in programs


Brackets FileExist Stack

Test procedure Test function Module

correct existence for work

placement of brackets in a file with a stack

Procedure InitStack EmptyStack InStack OutStack

Explanations Procedure Function Procedure Procedure

initialization errors check enable extraction

stack void element element stack

to stack from stack

Figure 6 – Program structure diagram


In chapter "General information" the designation and name of the program, software (operating environment, application programs) necessary for the functioning of the described program are indicated. If different processing modes require different application programs, a table should be given that shows which software is required for each mode. You must specify the programming language in which the program is written.

In chapter "Functional purpose" the class of problems to be solved and (or) the purpose of the program is determined. This paragraph should clearly list all the functions that the program performs in the established order or at the user's choice. Restrictions on the use of the program must be specified.

In chapter "Description of the logical structure" a structural diagram of the program is provided, which indicates the names and purposes of the component modules and subroutines (Figure 6). A verbal description of the structural units of the program is accompanied by a presentation of enlarged algorithm diagrams, in general, no more than three sheets. The first sheet shows an enlarged diagram of the functioning algorithm main program. In addition, diagrams of algorithms for those subroutines that reflect the essence of the method for solving the problem are presented. Examples of algorithm diagrams are shown in Figures 7, 8, 9, 10.

The design of algorithm diagrams must comply with the requirements of GOST 19.701-90 "Schemes of algorithms, programs, data and systems." The first block in any circuit is the START (or START) block:

The connecting lines in the diagram, otherwise called flow lines, should not intersect; for this, intrapage connectors are used


and interpage connectors

12 [from the sheet...

12 [per sheet...

An arrow pointing towards a connector means that control is transferred to the block whose number is indicated inside the connector. An arrow pointing away from the connector means that control is transferred from the block whose number is indicated inside the connector. Each algorithm diagram for a separate program unit is depicted in a separate figure. Figures are numbered consecutively within one document. Each drawing has a name, which is written above the drawing, and a number, which is written below the drawing. The name of the picture depicting the algorithm diagram can be the name of the corresponding program unit, for example: “Algorithm diagram of the control program” or “Algorithm diagram of the Error subroutine”. Examples of algorithm diagrams are shown in Figures 7, 8, 9, 10.


Figure 8 - FileExist Function Figure 9 - Error Procedure



Figure 10 – Scheme of the Brackets procedure algorithm


When accompanying a software tool, the description of the logical structure is the material on which that part of the program text that needs to be modified or upgraded is located. When describing the logic of the program in accordance with the given algorithm diagram, it is necessary to describe the work performed by each block.

In chapter "Technical means used" it is necessary to indicate the types of computers, the configuration of the computer complex for which the described software tool. If the program takes into account the characteristics of the operating environment, then you should indicate the operating environment in which this program runs.

the method for calling the program from the corresponding storage medium and the input parameters when starting the program are specified. It is allowed to indicate the volume of the program, information about the use of operational and external memory. It is necessary to indicate how program execution actually begins, what messages are expected during this initial period.

In chapter "Input data" it is necessary to indicate the nature, organization and preliminary preparation input data. It is necessary to describe all types of input data and the purpose of each type. If the input information can be represented by a sequence of some larger logical units, then it is necessary to describe ways of combining the input data into these larger logical units. You must specify the format and purpose of all fields in the logical data record. It is also necessary to specify restrictions on the size and number of input data. The output data is described with the same degree of detail as the input data. If the output is one or more messages, then it is necessary to indicate how the user should interpret each message, how he can use the information contained in each message.

Most sites, especially those on free hosting, do not store “large” information like movies, music and games on their disk space. The site contains only links with descriptions of resources, for downloading which the site owner often receives a reward in the form of payment.

For this reward to occur more often, considerable imagination is required in terms of describing the resource, and the main task descriptions - attract the user, highlighting this description from thousands of similar ones.

For example, correct descriptions of films that are about to be released are very important. Some webmasters seem to have an established approach to this problem: there is a video player on the site, a link to a famous teaser, a description of the film and its technical data.

But, if you look closely, it turns out that the teaser does not contain a Russian translation, the description was translated by Google translator from the IMDB database, and the technical data was generally copied from other sites. And how much interest will the viewer show when looking at a description of 1-2 lines? This requires more thorough work.

You need to approach the description of programs in exactly the same way. For example, what is the point of notifying a future client about its version if the description in no way implies that there were other versions at all?

To say that the program has version “1.5.6” is to say nothing, because the user, if interested, will definitely go to Wikipedia or the official website to find the release date of this very version. If it turns out to be fresh, then he will download it from the official resource or torrent.

Here is the rule: when describing a program, always write the update date. In general, the description should be written in such a way that the client does not need additional information, but is usually interested in the following:

  • What exactly is the name of the program?
  • Who is its author?
  • Was this program previously known under a different name?
  • Is it paid or free?
  • Exact limitations of the free version.
  • The difference between this version and the previous one.
  • Real reviews and problems associated with the program.
  • Screenshots of the program.
  • System requirements (minimum, usual and recommended).
  • Installation features.
  • Distribution volume, installed application size.
  • Availability of Russification (built-in, external). Is the help system Russified, is there a Russian-language support forum, is it possible to write to the support service in Russian. For example, Avast is already perceived as a Russian program, but communication with developers is based only on the English language.
  • What additional addons and add-ons may the user need when working with the program.
  • Are there any conflicts with the operating system or other installed software(firewalls, optimization and security utilities, antiviruses, etc.).
  • Does the program require Internet access during installation and operation? This is also an important point, since many programs work through a system of obscure bootloaders, imposed by boot managers, etc.

The more description options you provide, the more attention you will attract to your resource, and this is exactly what was required.

Previous publications:

Why do you need an application description?

To quote Captain Obvious, it's important to let your customers know what your app is about. What is it for? From a developer’s point of view, the description is an opportunity to “hook” the buyer. You need to sell the idea. You need to tell them why they should download your app and not any other.

Anyone reading your description has already found your app in search. The title and screenshots already seemed attractive enough for him to click the “more” button. Figuratively speaking, he has already taken out his wallet; all that remains is to force him to pay for the purchase.

Introduction

You have a limited number of words at your disposal. Take a look at the description of the applications - under the icon in App Store Only a couple of lines fit.

The most severe restrictions are imposed by the iPhone screen - you only have 225 characters. This is the most important part of your description. The entire description is limited to four thousand characters, but it is the first two hundred that determine whether buyers want to read the rest.

You need to express yourself clearly and clearly. The name of the application - and screenshots - should already tell the buyer in general what it is. Now we need to strengthen this impression.

The introduction to the description should be a call to action. Try to put yourself in your customer's shoes. What does he need?

There are a few simple rules here.

  • Capture your buyer's attention. Place nouns and verbs at the beginning of the sentence to make the phrase dynamic and as clear as possible.
  • Don't use jargon, it can be off-putting. Cut off everything unnecessary: ​​introductory words, adverbial phrases, overly flowery expressions.
  • What is the value of your application? What will the buyer get, learn or experience when they download it?
  • To see what your application description will look like on iPhone screen or iPad, use the preview in free program.
  • Now that the bait is on the hook, it’s time to cast the line. In other words, we’re done with the introduction, let’s continue with the description.

Details

Explain what exactly the user will get from your application. After a couple of introductory phrases—an emotional call to action—offer them the details.

How you distribute the information depends on the specific application you have. But in general, you should adhere to the same principles as journalists who write news stories - the most important information comes first, less important - at the end.

Don't neglect paragraphs. People get scared when they see a text “canvas”. Vary the length of the sentence - this makes the text more expressive. Use subheadings and line breaks. Lists are also a good way to break up text and make it more attractive.

Lists

While we're on the topic of lists, they are the easiest and most popular way to communicate the features of your app. Here are some tips on how to use them correctly:

  • don't make them too long;
  • two of the most important points place at the top of the list, the rest at the bottom;
  • You probably didn’t read this paragraph;
  • You definitely won't read this one.

It is tempting to write down all the features of an application in a list. You can try, but keep in mind that people usually read the first two paragraphs and the last one. They skip the middle, just like sentences that begin with the same words.

So it would be better to break a long list into several small ones, united by one topic.

Search

People who search for an app in iTunes don't look for the description: they tend to pay more attention to the title, keywords and other factors. However, keywords in the description are indexed search engines. Thus, a proper description is the key to high search rankings.

Your description must contain keywords. It's important not to overdo it. They must be appropriate. Don’t try to write overtly “selling” text - it will inevitably alienate the potential user. If you need help and the prospect of paying for it doesn’t put you off, you can contact Appnique or Sensor Tower (for English-language texts, editor’s note).

Localization

Localizing your app is a relatively inexpensive and easy way to increase downloads. It has virtually no flaws. A study conducted by Common Sense Advisory of 3,000 consumers from 10 non-English speaking countries shows that more than 75% of respondents want an app in their native language.

The report, entitled “If I Don’t Read, I Don’t Buy,” also states that 55% of users only make purchases on sites that provide information in their native language. Interestingly, 50% of respondents noted that they would be satisfied even with navigation and some of the content in their native language. That is, even a partial translation will give top scores than its complete absence.

Considering this fact, translate at least the description, if not the entire application.

Provides a list of localized applications with the ability to sort by genre - thus, it is possible to analyze where it is better to concentrate your efforts. You can also see a list of the most used words in the app description in different languages.

Make sure that the translation company has the appropriate skills. Google Translate is unlikely to be able to convey the shades of meaning that you put into the text.

If a popular website or celebrity wrote a review of your app, then it’s worth quoting them. If you've won an award, that should be mentioned too. If your app is very popular among your family... It's probably better to remain silent (unless, of course, your last name is Kardashian).

Apple's rules stipulate that you can "only place user reviews, praise, or recommendations at the end of the description if you deem it necessary."

Updates

Don't think that the app's description is akin to the Ten Commandments and is set in stone. You, obviously, will have to report what's new in the application after the update. Plus, if you suddenly come up with a brilliant phrase, or users share a remark that inspired you, or the best website on the entire Internet left a cool review of your app, don’t hesitate to improve your description. If there were errors in the application that affected the work, do not forget to inform them after they have been fixed that they have been fixed.

The description is not only a window into your application, but also an opportunity to get a high search ranking.

There are four things to consider to benefit from referencing/citations. Firstly, you always need to have a website for your application - with screenshots, texts and links where you can buy it. Secondly, you need a link to the support team - an email or forum address where you can write if you have any questions or problems. Third - links to your project page in in social networks. And lastly, you need links to your other applications.

Make sure your support team responds to queries immediately. If people have a hard time connecting with you, they will leave you low ratings and maybe even write a nasty review.

If users keep asking the same questions, consider creating an FAQ section on the app's website.

If you already have a successful project, don't forget to mention it. Or you can leave a “if you liked this, you might like this” description at the end of your other app.

Common mistakes and how to avoid them

Typos and punctuation/grammatical errors. Invite a specially trained copywriter or, as a last resort, include in text editor spell checking.

Confused and tongue-tied description. If the user does not understand you, then he will not download the application.

Abuse of hyperbole and clichés. Is your app truly revolutionary? Is the company really young and dynamically developing? Find less cliché ways to communicate this.

Everything secret becomes clear. The truth about your app will be revealed within seconds of downloading - and then stored in Google's cache forever. So don't lie.

Too many keywords. I already mentioned that clumsy attempts to cram as many keywords into the text as possible will only turn off the buyer.

The description does not take into account the interests of the target audience. Write not for yourself and not for competitors - write for the buyer.

Important details are missing. How much does the application weigh? How much does a subscription cost? This is not information that should be ignored.

So let's get started

I'll let you down brief summary: It needs to be prepared, written, polished, translated and then updated as needed.

Do your research and preparation before you start writing your description. Find the right keywords and phrases. Write down the features of your application in a list and rank them from most important to least important.

Write a draft description or hire a talented copywriter for this purpose.

Edit, adjust and rewrite for maximum effect. Check how the description will look on the iPhone or iPad screen. Work until it is smooth, polished and attractive.

Translate it to additional language, starting with those that are especially important in terms of downloads.

Make sure the description reflects any changes that have happened to your app, highlight major improvements in the descriptions, and highlight positive reviews or awards.

A good app description will help sell it and encourage downloads.

5.6. EXAMPLE OF DESCRIPTION OF THE PROGRAM "TEXT EDITOR"

Below is an example of a description of the Text Editor program, compiled by one of the students. The example gives the external functional specification first and then the internal specification.

The "Text Editor" program is designed to create new and correct existing MS DOS text files in an interactive (user-computer) operating mode. The computer generates a screen with a window in which a section of text from a text file is displayed (the screen layout corresponds to the internal editor of the Norton Commander program). The user is provided with the ability to insert into the text in the screen window any keyboard character behind the character marked on the screen by the cursor. The exception is a number of symbols that are signs of control commands or unused symbols (a list of symbols is provided). After the user issues a write command, all text changes made by the user are written to the file.

The basic principle of operation of the text editor is to transfer lines of text from the necessary sections of the file, first into a buffer memory array of 65535 bytes (characters) in length, and then copy the necessary lines from the buffer array to the screen window.

The program is launched by a command indicating the name of the file being edited. Next, until the correct file name is specified, the algorithm “Requesting the user to enter or correct the file name” can begin to be executed repeatedly.

Then the initial values ​​of the structured variable “Coordinate System” are set, which contains the following fields: “Cursor position relative to the file”; "Cursor position relative to editor buffer window"; "The position of the editor buffer window relative to the file."

Afterwards, the buffer array of the string variable editor is cleared from 5 * 23 = 115 lines of 225 characters each.

Next, with the “First line of file” parameter, the algorithm “Loading lines of the file, starting from the specified line, into the editor’s buffer array” is executed. Then, before the user submits one of the commands to complete editing with saving information (or without saving), the main program loop is executed. Finally, if a completion command was given while saving information, then the information from the buffer array is rewritten to a file. The program ends by clearing the screen.

Controlling the name of the file being edited is as follows. If the file with specified name is missing on the disk, a warning message is displayed indicating that a new “empty” file is being created. If the user did not specify the name of the file being edited or refused to work with the created “empty” file, the program terminates abnormally with an explanation of the reason for termination.

Inside the main program loop, a series of three sequential actions are performed. "Algorithm display" displays 23 lines of text from a buffer array on the screen, starting from a given line. Next, the display cursor is set to the specified screen position. The code of the pressed key is entered. If the code of the pressed key matches a control key, then one of the alternative actions to execute the command that corresponds to this key is performed. Otherwise, the character is inserted into the text.

From the book Software Packages. Quality requirements and testing author author unknown

From the Linux for the User book author Kostromin Viktor Alekseevich

12.2. Programs for viewing texts in different formats I read somewhere that the UNIX tradition was to create a separate command for each elementary action. This observation is well illustrated by the presence in Linux of a whole set of individual programs to view files.

From the book Introduction to OpenGL author Computers Author unknown -

12.5.3 CoolEdit - built-in editor of the Midnight Commander program CoolEdit is an easy-to-use program with control key combinations familiar to most users (especially those who have worked with Norton Commander under DOS or FAR under WINDOWS). In addition, it must be taken into account that

From the book Programming Technologies author Kamaev V A

Example program The result of executing this program is the construction of a tetrahedron with rings rotating around it, on which a texture is applied. In the MS Visual C++ environment, the program can be compiled without changes, but when compiling in Borland C++ you will have to comment out

From the book What Delphi books don't write about author Grigoriev A. B.

5.5. EXAMPLE OF DEVELOPMENT OF A DESCRIPTION OF THE PROCESS “BOILING WATER IN A KETTLE” The step-by-step implementation of the design procedure is shown below using the example of developing a description of the process “Boiling water in a kettle”. Complete this description with visual drawings on sheet 1 yourself. Sheet 2.

From the book Programming in Ruby [Language ideology, theory and practice of application] by Fulton Hal

From the book Programming in Prolog for Artificial Intelligence author Bratko Ivan

1.2.5. Example Program In any tutorial, the first program that prints the string Hello, world! is always given, but we will look at something more meaningful. Here is a small interactive console program that allows you to convert temperature from Fahrenheit to Fahrenheit

From the book VBA for Dummies by Steve Cummings

16.1.3. Example of Programming Sample-driven systems have their own special style of programming that requires a specific programmer's thinking. We are talking in this case about programming in terms of patterns. As an illustration, consider

From the book How to Find and Download Any Files on the Internet author Reitman M.A.

Example Program To make the discussion of VBA element hierarchy a little less abstract, let's look at the following program code module. This module contains all the elements mentioned above (except the project, since modules are contained in projects, and

From the Linux book: Complete Guide author Kolisnichenko Denis Nikolaevich

Text editor and web page editor OpenOffice.org Writer Word processor OpenOffice.org Writer (hereinafter simply Writer) is the most famous application of the office software package. This program allows you to create and edit text documents, insert images and

From the book Protection from Hackers corporate networks author author unknown

21.4. Example of a program in C In paragraph 9.2.3, I talked about process states and listed among them the “zombie” state. A zombie is a process that has already terminated, but its parent has not yet received a signal that it has terminated and has not removed its structure from the process table. This could happen

From the book The C Language - A Guide for Beginners by Prata Steven

22.3. An example of program debugging Let's write a program that resets the elements of array a. Yes, the program does not do anything useful, but using its example you can demonstrate how to work with the gdb debugger. Here is the program listing: Listing 22.1. Demonstration program

From the book Programming for Linux. Professional approach by Mitchell Mark

Example of a Vulnerable Program Using an example of a vulnerable program, let's look at how an attacker can exploit format string vulnerabilities to achieve their goals. Of greatest interest are methods for remote exploitation of vulnerabilities

From the author's book

EXAMPLE OF A SIMPLE PROGRAM IN C LANGUAGE Let's look at a simple program in C language. It should be said right away that we need such an example only to identify some of the main features of any program written in the C language. Next we will give explanations for each line, but before

From the author's book

EXAMPLE PROGRAM In Fig. 5.8 shows a program that may be useful to those who run, and which illustrates some of the points of this chapter. It looks quite long, but all calculations in it are performed by six statements placed

From the author's book

5.1.6. Sample Program The program in Listing 5.1 illustrates the memory sharing technique. Listing 5.1. (shm.c) Memory sharing example#include #include #include int main() ( int segment_id; char* shared_memory; struct shmid_ds shmbuffer; int segment_size; const

General information.

The program is called jane and is saved in the file jane.dpr. The program uses auxiliary modules main, new, dmData, about, respectively saved in the files main.pas, new.pas, about.pas, dmData.pas. The program is written in the Delphi programming language. The program uses data from database tables otdel.db, sotrudnik.db, family.db, obrazovanie.db

Functional purpose.

Implementation of a dialogue graph.

Typically the interface between the user and the computer includes a monitor screen, a keyboard and a mouse, which is what presents information to the user and receives information from the user. ,

Practically, a program written using Delphi is accessible through a graphical user interface. Graphical interface implemented application program This is a kind of dialogue that takes place between a computer and its user. In other words, an interface is that part of a program that, in order to perform certain functions, translates user actions into one or more requests and provides feedback with the user in accordance with the sequence of his actions.

The user has the ability to select system functions using push-button and pictographic menus. The user sees the contents of the database in front of him in the form of a screen document. Interaction with the user is carried out through screen forms. The implementation of the dialogue graph is shown in Figure 17.

Figure 17. Tree of screen forms

Description of the logical structure.

The program is event driven. When you click on a button, a message is sent to the program, and the corresponding handler procedure is called, which processes this event. The results of processing can be seen on the monitor screen. For example: when you click on the “Work” button in the “Diploma Project” form, the procedure contained in the New module is called, which hides the “Diploma Project” form, displays the “Personnel Accounting” form on the monitor screen, and control is transferred to the Main module.

To run the program you need to download it to personal computer Delphi shell, compile the source text of the program contained in the jane.dpr file. Call the exe file and then work with it. Before starting work, you must go through the authorization procedure (Figure 18).

Figure 18. Password entry form

Input and output data.

Input data:

department name,

Name of the boss,

Full name of employees, position,

employment date,

place of last work,

length of service as of the date of admission,

a sign of education,

a sign of having a family,

amount of children,

Family status,

dates of birth,

type of education,

form of education,

educational institution,

expiration date,

speciality.

Output data: all results of user actions when working with databases are displayed on the monitor screen; these results, displayed as a database on the screen, are the output to the program. Also, the result of working with this “Personnel Accounting” database can be the generation of orders and printing them, which greatly facilitates the user’s work and eliminates the need to manually draw up documents such as orders for dismissal or hiring of employees and their personal cards.