Voorbeeld van GOST-programmabeschrijving. Hoe schrijf ik een goede beschrijving voor een app? Kort algoritme van het programmaontwerp

Dit document behoort tot het type software en is operationeel. Geldt voor een programma, complex, PAK, softwarecomponent of systeem.
Doelgroep: personen die de beslissing nemen om het programma aan te schaffen en in gebruik te nemen. Het document bevat informatie over de functionaliteit van het programma en de reikwijdte ervan.

GOST's en normen

De structuur en vormgeving van het document wordt bepaald in.
Het informatieve gedeelte (annotaties en inhoud) in overeenstemming met.

In welke gevallen is het nodig?

Het document is nodig om potentiële gebruikers en kopers te informeren over het doel van het programma en hoe het te gebruiken. Meer geschikt voor managers (specialisten, systeembeheerders) die zelfstandig besluiten het programma aan te schaffen en in gebruik te nemen.

Het geheel Nodige informatie zij zullen uit dit document kunnen verkrijgen: een beschrijving van het programma en de toepassing ervan.

De programmabeschrijving en applicatiebeschrijving geven aan:

De taken die het programma oplost;
Middelen besteed aan werk;
Inleidende informatie;
Uitgang.

De nadruk ligt op het beschrijvende deel van het programma, de functies en het doel ervan. In mindere mate op de beschrijving van de aanvraag. Er wordt een beschrijving gemaakt over de mogelijkheden van het programma en de taken die het oplost, en niet erover intern apparaat... Met bepaalde functies van het programma is het toegestaan ​​om secties te combineren of nieuwe (extra) te introduceren.

De structuur van de programmabeschrijving (GOST 19.402-78):

1. Algemene informatie.
2. Het functionele doel van het programma.
3. Beschrijving van de logische structuur.
4. De technische middelen die worden ingezet.
5. Bellen en downloaden.
6. Gegevens invoeren.
7. Uitvoergegevens.

De structuur van de applicatiebeschrijving (GOST 19.502-78):

1. Doel van het programma.
2. Gebruiksvoorwaarden.
3. Beschrijvend deel van het probleem.
4. Invoer- en uitvoergegevens.
5. toepassingen (tabellen, illustraties, enz.).

U kunt de ontwikkeling van een document of een complete set softwaredocumentatie bestellen.

V.E. Karpov

Dit document bevat: korte beschrijving UEA-normen, waarvan kennis nodig is voor studenten om cursussen en projecten te ontwerpen die verband houden met het maken van softwaresystemen. Bovendien kan het nuttig zijn vanuit het oogpunt van verbetering van de kwaliteit van het ontwerp van softwaredocumentatie in het algemeen.

TECHNISCHE TAAK (GOST 19.201-78)

1. Algemene bepalingen

ONTWIKKELINGSFASEN (GOST 19.102-77)

BESCHRIJVING VAN HET PROGRAMMA (GOST 19.402-78)

PROGRAMMA TEKST (GOST 19.401-78)

PROGRAMMA EN TESTPROCEDURE (GOST 19.301-79)

VEREISTEN VOOR PROGRAMMADOCUMENTEN UITGEVOERD DOOR DE PRINTMETHODE (GOST 19.106-78)

Standaardisatie op het gebied van softwaredocumentatie

Hoe verder te gaan?

Opstellen van documentatie voor software(PS) in overeenstemming met de bestaande GOST's

2. Algemene kenmerken van de staat

2.3. Staatsnormen van de Russische Federatie (GOST R)

2.4. Internationale norm ISO / IEC 12207: 1995-08-01

Misschien wel de meest onaangename en moeilijkste fase van programmeerwerk is het maken van softwaredocumentatie. Helaas wordt dit meestal helemaal niet geleerd, of in beste geval, besteed geen aandacht aan de kwaliteit van de ontvangen documenten. Beheersing van deze kunst is echter vaak een van de belangrijkste factoren bij het bepalen van de kwaliteit van een programmeur.

Ten eerste bepaalt het vermogen om softwaredocumentatie te maken het professionele niveau van een programmeur. De klant zal niet ingaan op de subtiliteiten en functies van zelfs het meest fantastische programma. De klant leest eerst de documentatie. Daarbij speelt ook de psychologische factor een belangrijke rol. Met name de voormalige Sovjet-programmeerschool was (en wordt nog steeds gewaardeerd) over de hele wereld. Moderne binnenlandse programmeurs worden niet meer geciteerd. De klas is niet hetzelfde. Tegenwoordig worden programma's niet meer geschreven, maar gecompileerd (en dat zijn "twee grote verschillen"). Een pakket softwaredocumentatie (hierna PD genoemd) gemaakt in de "klassieke" stijl zal dus de meest gunstige indruk maken op uw klant of werkgever. Bovendien, als de auteur van de PD zinnen als "klik op de schuifbalk ...", "schroef", enz. Helaas verbergt dergelijk jargongebabbel meestal ofwel gebrek aan gedachten of volledige leegte (de auteur maakte een onuitwisbare indruk op het verhaal van een van zijn kennissen over een bepaalde "gamer" die ofwel met iemand daar "kletste", of bezig was met "gematigdheid". " of iets dergelijks.). De taal van PD is een soort bureaucratische, zeer conservatieve taal. Het heeft zijn eigen speciale charme. Mee eens dat de termen HDD, HDD, handmatige manipulator zoals "muis" (of "kolobok", zoals het was in een van de oude PD-pakketten) totaal anders klinken dan de corresponderende "schroef", "flop" en gewoon "muis" . Trouwens, dingen zijn al zo ver gekomen dat, zeggen ze, zelfs een speciale specialiteit is verschenen - een technisch schrijver, d.w.z. iemand die weet hoe hij softwaredocumentatie moet maken.

Ten tweede bespaart een vakkundig samengesteld (meer precies, gemaakt) PD-pakket u een hoop moeite. In het bijzonder kunt u vervelende vragen en ongegronde claims kwijtraken door de gebruiker eenvoudigweg naar de documentatie te verwijzen. Dit geldt in de eerste plaats voor het belangrijkste document - de Terms of Reference. We zullen hier hieronder over praten, maar nu kunnen we ons de miljoenenzaak tegen IBM herinneren. Deze rechtszaak werd aangespannen door één grote uitgever, ontevreden over de kwaliteit van VT en software. IBM won de proef. En ze won alleen vanwege het feit dat ze de door beide partijen ondertekende Terms of Reference presenteerde. Het is lang geleden, in de jaren 70, maar dat verandert niets aan de essentie van de zaak.

Nog een ding. Het is belangrijk om het eerste PD-pakket te maken. Dit is voldoende om alle volgende op basis daarvan te bouwen en als voorbeeld of sjabloon te gebruiken. Maar dit moet zeer efficiënt gebeuren. ontspannen. Zeer grondig.

Eerst moet je jezelf wapenen met GOST's. GOST definieert alles. Het omvat met name ook het voor ons van belang zijnde Unified System of Program Documentation (ESPD). Misschien is het moeilijkste om de GOST zelf te krijgen. GOST mag alleen in originele gedrukte vorm zijn. Ze worden verkocht (door minstens, zo was het vroeger) in speciale winkels. U kunt met name contact opnemen met de volgende organisaties om documentatienormen te verkrijgen:

• IPK "Standaard Uitgeverij", Territoriale afdeling distributie van NTD (winkel "Standards"), 17961, Moskou, st. Donskaja, 8, tel. 236-50-34, 237-00-02, fax/tel. 236-34-48 (in termen van GOST en GOST R).
• VNIIKI Gosstandart of Russia (leeszaal), 103001, Moskou, Granatny per. 4, tel.nr. 290-50-94 (in termen van internationale, buitenlandse normen en andere NTD's).

En geen citaten of secundaire bronnen. GOST is een wet. En meer nog, geen internet (stel je voor dat een rechtbank een vonnis uitspreekt met behulp van een afdruk van het Wetboek van Strafrecht gedownload van een website). Vertrouw niemand anders dan het origineel. Desalniettemin zal de auteur verder zijn toevlucht moeten nemen tot het citeren van het UEA, terwijl hij zichzelf van alle verantwoordelijkheid ontheft.

Laten we beginnen met de algemene bepalingen over het Unified System of Program Documentation (die ook zijn gedefinieerd in de overeenkomstige standaard GOST 19.001-77).

Een uniform systeem van programmadocumentatie is een reeks staatsnormen die onderling samenhangende regels vaststellen voor de ontwikkeling, het ontwerp en de verspreiding van programma's en programmadocumentatie.

UEA-normen definiëren algemene bepalingen en fundamentele normen, regels voor de implementatie van ontwikkelingsdocumentatie, regels voor de implementatie van fabricagedocumentatie, regels voor de implementatie van onderhoudsdocumentatie, regels voor de implementatie van operationele documentatie, regels voor de verspreiding van programmadocumentatie en andere normen. Het UEA omvat:

• fundamentele en organisatorische en methodologische normen;
• normen die de vorm en inhoud definiëren van programmadocumenten die bij de gegevensverwerking worden gebruikt;
• standaarden die zorgen voor de automatisering van de ontwikkeling van programmadocumenten.

Over het algemeen is de lijst met UEA-documenten zeer uitgebreid. Het omvat in het bijzonder de volgende GOST's:

• GOST 19.001-77 ESPD. Algemene bepalingen.
• GOST 19.101-77 ESPD. Soorten programma's en programmadocumenten (opnieuw gepubliceerd in november 1987, zoals gewijzigd).
• GOST 19.102-77 ESPD. Ontwikkelingsstadia.
• GOST 19.103-77 ESPD. Aanduiding van programma's en programmadocumenten.
• GOST 19.104-78 ESPD. Basis inscripties.
• GOST 19.105-78 ESPD. Algemene vereisten voor programmadocumenten.
• GOST 19.106-78 ESPD. Vereisten voor gedrukte programmadocumenten.
• GOST 19.201-78 ESPD. Technische taak. Eisen aan inhoud en vormgeving.
• GOST 19.202-78 ESPD. Specificatie. Eisen aan inhoud en vormgeving.
• GOST 19.301-79 UPD. Testprogramma en methodiek.
• GOST 19.401-78 ESPD. Programma tekst. Eisen aan inhoud en vormgeving.
• GOST 19.402-78 ESPD. Programma beschrijving.
• GOST 19.404-79 ESPD. Toelichting. Eisen aan inhoud en vormgeving.
• GOST 19.501-78 ESPD. Formulier. Eisen aan inhoud en vormgeving.
• GOST 19.502-78 ESPD. Beschrijving van de aanvraag. Eisen aan inhoud en vormgeving.
• GOST 19.503-79 ESPD. Handleiding voor systeemprogrammeur. Eisen aan inhoud en vormgeving.
• GOST 19.504-79 ESPD. Handleiding voor programmeurs.
• GOST 19.505-79 ESPD. Handleiding.
• GOST 19.506-79 ESPD. Beschrijving van de taal.
• GOST 19.508-79 ESPD. Gids onderhoud... Eisen aan inhoud en vormgeving.
• GOST 19.604-78 ESPD. Regels voor het aanbrengen van wijzigingen in programmadocumenten die in gedrukte vorm worden uitgevoerd.
• GOST 19.701-90 ESPD. Diagrammen van algoritmen, programma's, gegevens en systemen. Symbolen en uitvoeringsregels.
• GOST 19.781-90. Software voor informatieverwerkingssystemen.

Zoals u kunt zien, is het grootste deel van het ESPD-complex ontwikkeld in de jaren '70 en '80. Voor een deel zijn deze normen moreel achterhaald, bovendien zijn ze niet verstoken van enkele tekortkomingen. Ten eerste weerspiegelen ze niet enkele moderne trends in het ontwerp van programma's en softwaredocumentatie, en ten tweede bevatten deze standaarden meerdere duplicatie van fragmenten van softwaredocumentatie. Niettemin, bij gebrek aan de beste, is het noodzakelijk om op hen te focussen.

De UEA-normen stroomlijnen dus het proces van het documenteren van softwaresystemen. Ten eerste is de samenstelling van programmadocumenten zoals bepaald door de UEA-normen helemaal niet zo "rigide" als het lijkt: de normen stellen u in staat om extra typen toe te voegen aan de documentatieset voor het softwaresysteem (PS), en ten tweede , op basis van de eisen van de klant, is het toegestaan ​​om enkele wijzigingen aan te brengen, zowel in de structuur als in de inhoud van de gevestigde typen PD. Bovendien kan worden opgemerkt dat de normen van het UEA (en dit geldt voor alle andere normen op het gebied van PS - GOST 34, Internationale norm ISO/IEC, etc.) adviserend van aard zijn. Het is een feit dat in overeenstemming met de wet van de Russische Federatie "On Standardization" deze normen verplicht worden op contractuele basis - dat wil zeggen. bij verwijzing naar hen in het contract voor de ontwikkeling (levering) van de PS.

Alvorens verder te gaan met de overweging van de regels voor het samenstellen van programmadocumentatie, is het noodzakelijk de volgende opmerking te maken. Het is raadzaam om elk document vooraf te laten gaan met een inleiding. De inleiding spreekt algemene woorden. Over relevantie, noodzaak, etc. Het doel van de Aannemer is hier om het belang en de noodzaak van dit werk te laten zien. Het begin is meestal standaard: "De talrijke systemen die momenteel bestaan ​​... ... openen echte perspectieven in ..." enzovoort. Citaten uit toespraken van verschillende figuren worden hier meestal ingevoegd (dit is een puur psychologisch aspect): "... zoals gezegd tijdens het laatste plenum, congres, conferentie, enz.). U kunt beginnen met het feit dat" .. Vandaag, in het tijdperk van inheemse sociaal-economische transformaties ... enz. "Over het algemeen is het belangrijkste hier niet om het te overdrijven.

En verder. Bij het beschrijven van een product haalt een ontwikkelaar vaak de begrippen component en complex door elkaar. Dit zijn verschillende soorten programma's. Een component wordt gedefinieerd als "een programma dat als een geheel wordt beschouwd, een volledige functie vervult en onafhankelijk of als onderdeel van een complex wordt gebruikt", en een complex is een "programma bestaande uit twee of meer componenten en (of) complexen die onderling gerelateerde functies en zelfstandig of als onderdeel van een ander complex toegepast”.

Volgens GOST legt deze standaard (heruitgegeven in november 1987) de procedure vast voor de constructie en uitvoering van technische specificaties voor de ontwikkeling van een programma of softwareproduct voor computers, complexen en systemen, ongeacht hun doel en reikwijdte.

U moet uiterst voorzichtig en voorzichtig zijn bij het maken ervan, omdat: vaak vakkundig (en vakkundig) opgestelde TOR bepaalt het succes van al het werk. Het is de TK die wordt overeengekomen met de klant, die meestal probeert om zoveel mogelijk tegenstrijdige en overdreven eisen te introduceren. De opdracht van de Aannemer is daarentegen om zijn leven gemakkelijker te maken. Maar nadat de handtekeningen aan beide kanten zijn gezet, is het te laat om nog iets terug te spelen.

De opdrachtomschrijving wordt in de regel op A4- en/of A3-vellen opgesteld zonder de marges van het vel in te vullen. De blad(pagina)nummers worden bovenaan het blad boven de tekst geplaatst.

Om in de volgende stadia van de ontwikkeling van een programma of softwareproduct wijzigingen en aanvullingen op de technische achtergrond aan te brengen, wordt daarop een addendum uitgebracht. Coördinatie en goedkeuring van de aanvulling op referentiekader uitgevoerd in dezelfde volgorde die is vastgesteld voor de taakomschrijving.

De taakomschrijving moet de volgende secties bevatten:

• naam en omvang;
• basis voor ontwikkeling;
• doel van ontwikkeling;
• technische vereisten voor een programma of softwareproduct;
• stadia en stadia van ontwikkeling;
• controle- en acceptatieprocedure;
• toepassingen.

Afhankelijk van de kenmerken van het programma of softwareproduct is het toegestaan ​​om de inhoud van de secties te verduidelijken, nieuwe secties te introduceren of sommige ervan te combineren.

In hoofdstuk Naam en bereik vermeld de naam, een korte omschrijving van de omvang van het programma of softwareproduct en het object waarin het programma of softwareproduct wordt gebruikt.

In hoofdstuk Basis voor ontwikkeling moet worden aangegeven:

• document(en) op basis waarvan de ontwikkeling wordt uitgevoerd;
• de organisatie die dit document heeft goedgekeurd en de datum van goedkeuring;
• naam en (of) aanduiding van het ontwikkelingsthema.

Toegepast op de details onderwijsproces de basis kan een opdracht voor cursusontwerp zijn, een opdracht voor het instituut van __.__. voor N ___., contract __.__. voor N ____. , enzovoort.

In hoofdstuk Ontwikkelingsdoel: het functionele en operationele doel van het programma of softwareproduct moet worden aangegeven. Je kunt je hier beperken tot een of twee zinnen. Het belangrijkste is om duidelijk te definiëren waar dit programma voor is.

Bijvoorbeeld: het programma vormt de kern van een geautomatiseerd werkstation (AWS) voor een ontwikkelaar van continue lineaire automatische controlesystemen (ACS), waarmee de gebruiker problemen bij het analyseren van eenvoudige modellen kan oplossen.

Hoofdstuk Technische benodigdheden naar het programma of software-item moet de volgende subsecties bevatten:

• vereisten om functionele kenmerken;
• betrouwbaarheidseisen;
• gebruiksvoorwaarden;
• vereisten voor samenstelling en parameters technische middelen;
• vereisten voor informatie en softwarecompatibiliteit;
• etiketterings- en verpakkingsvereisten;
• transport- en opslagvereisten;
• speciale vereisten.

Met andere woorden, hier beginnen de details. Beschrijft wat het programma moet doen en hoe het eruit moet zien.

Eisen aan functionele kenmerken. Het moet de vereisten aangeven voor de samenstelling van de uitgeoefende functies, de organisatie van invoer- en uitvoergegevens, tijdkenmerken, enz.

Bijvoorbeeld: Het programma moet toestaan ​​... te berekenen ... te bouwen ... te creëren ...

Initiële gegevens: een tekstbestand met een gegeven ...

Uitvoergegevens: grafische en tekstinformatie - resultaten van systeemanalyse ...; tekstbestanden - rapporten over ... diagnose van de systeemstatus en berichten over eventuele fouten die zijn opgetreden.

Betrouwbaarheidseisen. Vereisten voor een betrouwbare werking (zorgen voor een stabiele werking, controle van invoer- en uitvoerinformatie, hersteltijd na storing, enz.) moeten worden aangegeven.

Hier is het moeilijk om iets te "winnen". In het beste geval kan er een optie komen waarbij je programma alleen werkt met absoluut correcte gegevens. Meestal gaat de Klant er niet voor, maar je kunt het proberen.

Bijvoorbeeld: het programma moet werken met een gegeven uitgebreide matrix van incidenten van de onderzochte grafiek in overeenstemming met het werkingsalgoritme, foutmeldingen geven wanneer de initiële gegevens onjuist zijn gespecificeerd, een dialoogmodus behouden binnen de mogelijkheden die aan de gebruiker worden geboden.

Bedrijfsomstandigheden. De bedrijfsomstandigheden (omgevingstemperatuur, relatieve vochtigheid, etc. voor de geselecteerde typen gegevensdragers), waaronder de gespecificeerde kenmerken moeten worden gegarandeerd, evenals het type service, het vereiste aantal en kwalificaties van het personeel moeten worden aangegeven.

Er zijn meestal geen problemen met dit item. Helaas wordt het punt over de professionaliteit van de gebruiker noodzakelijkerwijs geïmpliceerd door de klant. Dit is natuurlijk nog een reden om fouten in uw programma te vinden. Hier kunt u zich echter beperken tot zinnen als "De gebruiksomstandigheden van het programma komen overeen met de gebruiksomstandigheden van de IBM-pc en compatibele pc's", "Het programma moet zijn ontworpen voor een niet-professionele gebruiker." enzovoort.

Vereisten voor de samenstelling en parameters van technische middelen. Geef de vereiste samenstelling van technische middelen aan met een aanduiding van hun technische kenmerken.

Het belangrijkste hier is om niets te vergeten en alles te voorzien, aan de ene kant (anders zullen ze een IBM PC / XT met een zwart-wit scherm en zonder muis wegglijden), en aan de andere kant, overdrijf het niet met verhoogde eisen , anders zal de Klant een meer conforme Contractant vinden.

Bijvoorbeeld: Vereist een IBM PC - compatibele pc met EGA (VGA) grafische adapter. Vereist schijfruimte- niet minder dan 600 KB, de hoeveelheid vrij RAM - niet minder dan 400 KB. Het is wenselijk om een ​​EMS-stuurprogramma en een muis-type manipulator te hebben.

Vereisten voor informatie en softwarecompatibiliteit. De kenmerken zijn hetzelfde als in de vorige paragraaf. Vereisten voor informatiestructuren aan de input en output en oplossingsmethoden, broncodes, programmeertalen moeten hier worden aangegeven. Waar nodig moet worden gezorgd voor bescherming van informatie en programma's.

Bijvoorbeeld: Het programma moet autonoom werken onder MS DOS OS versie 3.3 of hoger. De basis programmeertaal is Turbo Pascal 6.0.

Etiketterings- en verpakkingsvereisten en transport- en opslagvereisten zijn behoorlijk exotisch. In het algemeen worden hier de vereisten voor etikettering van softwareproducten, opties en verpakkingsmethoden aangegeven. En in de eisen voor transport en opslag moeten de transportvoorwaarden, opslaglocaties, opslagcondities, opslagcondities, opslagtijden onder verschillende omstandigheden voor het softwareproduct worden aangegeven.

Speciale vereisten zijn een zeer belangrijk ding. Het is beter om ze zoveel mogelijk te vermijden. En geef het meteen door.

Bijvoorbeeld: Er zijn geen speciale vereisten voor de timing van het programma. Er zijn geen speciale vereisten voor de capacitieve kenmerken van het programma.

Technische en economische indicatoren. Dit punt, het moeilijkste voor een programmeur, is er niet altijd. Het is vooral nodig als het uw doel is om de enorme effectiviteit en het belang van het uitgevoerde werk te rechtvaardigen. Deze clausule werkt meestal erg goed voor de Klant. Dit is in ieder geval de beste rechtvaardiging voor de ontwikkeltijd en het geld.

In dit gedeelte moet worden aangegeven: de geschatte economische efficiëntie, de geschatte jaarlijkse behoefte (bijvoorbeeld: het geschatte aantal oproepen naar het complex als geheel per jaar - 365 werksessies), de economische voordelen van de ontwikkeling in vergelijking met de beste binnenlandse en buitenlandse monsters of analogen.

Daarnaast is het wenselijk een definitie te geven van zowel de geschatte kosten van het ontwikkelen van een programma als de definitie van de complexiteit van de programmering.

Stadia en stadia van ontwikkeling(dit wordt hieronder in meer detail besproken) de noodzakelijke ontwikkelingsstadia, stadia en inhoud van het werk vast te stellen (een lijst van programmadocumenten die moeten worden ontwikkeld, overeengekomen en goedgekeurd), evenals, in de regel, de timing van de ontwikkeling en bepalen de artiesten.

De standaard stappen worden hier beschreven. Het belangrijkste is om de timing correct te bepalen. Probeer indien mogelijk de etappes gelijkmatig te verdelen over tijdlijn (en hoeveelheid). Bedenk dat niet alle projecten de eindfase halen. En rapporten moeten voor elke fase zijn. Onthoud ook dat het werkproject de langste tijd in beslag zal nemen. Indien u geen tijd heeft om de documentatie op tijd in te vullen, dan heeft de Klant het volste recht om het werk helemaal niet in ontvangst te nemen met alle gevolgen van dien.

De belangrijkste en onmisbare fasen en fasen zijn de technische taak zelf, het conceptontwerp, technische en werkprojecten.

• Voorlopig ontwerp. In dit stadium worden de structuren van de invoer- en uitvoergegevens in detail ontwikkeld, de vorm van hun presentatie bepaald. Is in ontwikkeling algemene beschrijving algoritme, het algoritme zelf, de structuur van het programma. Er wordt gewerkt aan een actieplan voor de ontwikkeling en uitvoering van het programma.
• Technisch project. Het bevat het ontwikkelde algoritme om het probleem op te lossen, evenals methoden om de initiële informatie te controleren. Het ontwikkelt ook middelen voor foutafhandeling en het afgeven van diagnostische berichten, definieert de vormen van presentatie van de initiële gegevens en de configuratie van technische middelen.
• Werkversie. In dit stadium worden het programmeren en debuggen van het programma, de ontwikkeling van programmadocumenten, programma's en testmethoden uitgevoerd. Test- en debuggingvoorbeelden worden voorbereid. Documentatie en afbeeldingen zijn afgerond. Meestal wordt aangegeven dat tijdens de ontwikkeling van het programma de volgende documentatie moet worden opgesteld:

• programma tekst;
• programma beschrijving;
• testprogramma en methodologie;
• toepassingsbeschrijving;
• gebruikershandleiding.

Dit zijn standaard eisen. Als de Klant ermee instemt dat niet al deze lijst kan worden ingediend, betekent dit dat zijn bedoelingen niet serieus zijn met betrekking tot u en uw product.

Er mag geen grafisch materiaal aanwezig zijn. Zeker als je niet gaat rapporteren over de resultaten van je werk. Maar voor serieuze projecten is dit item vereist.

Bijvoorbeeld: Tijdens de ontwikkeling van het programma moet het volgende grafisch materiaal worden voorbereid:

• technische en economische indicatoren;
• opbouw van het programma;
• het formaat voor het presenteren van de invoergegevens van het programma;
• algemeen schema van het algoritme (2 bladen);
• elementaire rekenalgoritmen;
• een voorbeeld van hoe het programma werkt.

In hoofdstuk Controle- en acceptatieprocedure de soorten tests en algemene eisen voor de acceptatie van het werk moeten worden aangegeven. Indien mogelijk, geef dan in deze paragraaf aan dat "controle en acceptatie van ontwikkeling worden uitgevoerd op de apparatuur die door de klant is geleverd", anders bent u mogelijk verplicht de apparatuur mee te nemen.

Bijvoorbeeld: Inspectie en acceptatie van ontwikkeling wordt uitgevoerd op basis van controletests en voorbeelden van debuggen. Dit controleert de prestaties van alle programmafuncties.

V bijlagen naar de taakomschrijving, indien nodig, leiden:

• een lijst van onderzoeken en andere werken die de ontwikkeling rechtvaardigen;
• diagrammen van algoritmen, tabellen, beschrijvingen, rechtvaardigingen, berekeningen en andere documenten die bij de ontwikkeling kunnen worden gebruikt;

• andere ontwikkelingsbronnen.

Deze norm stelt de ontwikkelingsstadia van programma's, programmadocumentatie, evenals de stadia en inhoud van het werk vast:

Opmerkingen:

1. Het is toegestaan ​​om de tweede ontwikkelingsfase uit te sluiten, en in technisch verantwoorde gevallen - de tweede en derde fase. De noodzaak van deze fasen wordt aangegeven in de taakomschrijving.
2. Het is toegestaan ​​om werkfasen en (of) hun inhoud te combineren, uit te sluiten en andere werkfasen in te voeren zoals overeengekomen met de klant.

Deze standaard is gericht op het documenteren van het resulterende ontwikkelproduct.

Strikt genomen zijn er twee verschillende documenten die echter veel gemeen hebben. Dit zijn ALGEMENE BESCHRIJVING (GOST 19.502-78) en PROGRAMMABESCHRIJVING (GOST 19.402-78). Vanwege het feit dat het echter echt moeilijk is om zowel het een als het ander kwalitatief te maken, zonder toevlucht te nemen tot bijna volledige duplicatie, stukjes uitscheuren, is het erg moeilijk, het zou voldoende zijn om een, meer algemene, "hybride" te implementeren document. Laten we het "programmabeschrijving" noemen.

In feite kan de "Beschrijving van het programma" in het inhoudelijke deel worden aangevuld met secties en paragrafen uit de normen voor andere beschrijvende documenten en handleidingen: GOST 19.404-79 ESPD. Toelichting, GOST 19.503-79 ESPD. Handleiding systeemprogrammeur, GOST 19.504-79 ESPD. Programmeursgids, GOST 19.505-79 ESPD. Gebruikershandleiding, enz. In het bijzonder kunt u uit de toelichting een diagram van het algoritme nemen, een algemene beschrijving van het algoritme en (of) de werking van het programma, evenals de reden voor de genomen technische en technische en economische beslissingen.

De beschrijving van het programma moet een informatief gedeelte bevatten - annotatie en inhoud.

Het hoofdgedeelte van het document moet bestaan ​​uit een inleidend gedeelte en de volgende secties:

• functioneel doel;
• beschrijving van logica.
• Gebruiksvoorwaarden;
• samenstelling en functie.

Afhankelijk van de kenmerken van het programma is de introductie van extra secties toegestaan.

V Inleidend deel document geeft informatie algemeen over het programma - volledige naam, benaming, mogelijke toepassingen, enz.

Bijvoorbeeld: Programma "Geautomatiseerd werkplek ACS-ontwikkelaar "is bedoeld voor ... geïmplementeerd op .... Het programma ondersteunt ...

In hoofdstuk Afspraak geef het doel van het programma aan en geef een algemene beschrijving van de werking van het programma, de belangrijkste kenmerken, informatie over de beperkingen die zijn opgelegd aan de reikwijdte van het programma, en geef ook de soorten elektronische computers en apparaten aan die in het werk worden gebruikt .

Bijvoorbeeld: Het programma is ontworpen om problemen op te lossen ... Het programma is de kern van een geautomatiseerd werkstation ...

De gebruiker heeft de mogelijkheid om ..., implementeren ..., uitvoeren ..., analyseren ..., de resultaten van analyse en verwerking krijgen ..., bouwen ... etc.

in hoofdstuk " Beschrijving van de logica"wijzen op:

• beschrijving van de structuur van het programma en de belangrijkste onderdelen ervan

(bijvoorbeeld: het programma omvat het volgende:

• gebruikersomgeving,
• module voor het bepalen van paden in de grafiek,
• overdrachtsfunctie rekenmodule,
• module voor het construeren van amplitude- en fasefrequentiekarakteristieken,
• een module voor het construeren van een reactie op een polynoomactie,
• tekstverwerker).

• Functiebeschrijving onderdelen en verbindingen daartussen;

Bijvoorbeeld: Het programma bestaat uit zes modules: interfacemodule; definitie module ...; rekenmodule ...; module ... enz ..

De interfacemodule is gebaseerd op twee typen dialoogvensters: het "vraag - antwoord"-dialoogvenster en het "menu"-dialoogvenster. De interfacemodule regelt ...

De definitiemodule ... Het is ...

Rekenmodule ... enz.

• informatie over de programmeertaal;

Bijvoorbeeld: Het programma is geschreven in de taal ... met behulp van de compiler ...

• een beschrijving van de invoer- en uitvoergegevens voor elk van de samenstellende delen;

Bijvoorbeeld: INVOERGEGEVENS. De invoergegevens voor het programma zijn een tekstbestand dat de uitgebreide incidentiematrix van de grafiek van het bestudeerde systeem beschrijft.

UITGANG. De uitvoer is:

• grafische en tekstinformatie weergegeven op het scherm (resultaten van systeemanalyse);
• bestanden in een van grafische formaten- kopieën van het beeld van de geconstrueerde kenmerken (frequentierespons, faserespons, enz.);
• tekstbestanden - rapporten over het uitgevoerde onderzoek;
• diagnose van de systeemstatus en berichten over eventuele fouten die zijn opgetreden.

• een beschrijving van de logica van de samenstellende delen (indien nodig moet een beschrijving van de programmaschakelingen worden opgesteld).

Bij het beschrijven van de logica van het programma is het noodzakelijk om te linken naar de tekst van het programma.

In hoofdstuk Samenstelling en functies een beschrijving geven van de samenstelling en functie van programma's, toegepaste methoden voor het oplossen van problemen.

In hoofdstuk Gebruiksvoorwaarden de voorwaarden die nodig zijn voor de uitvoering van het programma zijn aangegeven (vereisten voor de technische middelen die nodig zijn voor dit programma en andere programma's, de algemene kenmerken van de input- en outputinformatie, evenals de vereisten en voorwaarden van organisatorische, technische en technologische aard , enzovoort.).

Bijvoorbeeld: Het programma wordt uitgevoerd op persoonlijke computer(PC) type IBM PC / AT. Om in dialoogmodus te werken, worden een beeldscherm, een toetsenbord en een muis gebruikt. Een EGA (VGA)-adapter is vereist om de grafische modus te ondersteunen. De invoergegevens worden opgeslagen op diskette en/of harde schijven. Het programma draait onder het besturingssysteem ...

De bijlage bij de beschrijving kan bevatten: referentiematerialen(illustraties, tabellen, grafieken, voorbeelden, enz.)

En vergeet niet de naam van de laadmodule te vermelden, evenals een beschrijving van de hele procedure.

Bellen en het systeem laden

De vereisten voor de opmaak van de programmatekst zijn vrij eenvoudig en natuurlijk voor een competente programmeur. Het belangrijkste dat moet worden begeleid bij het maken van dit document, is dat de tekst van het programma leesbaar moet zijn.

Het is nog steeds verplicht om het informatieve deel - annotatie en inhoud - op te stellen.

Het grootste deel van het document moet bestaan ​​uit de teksten van een of meer secties, die titels krijgen.

De tekst van elk programmabestand begint met een "header", die aangeeft:

• naam van het programma,
• auteur,
• datum van aanmaak van het programma,
• versienummer,
• datum laatste wijziging.

Opmerkingen zijn vereist, evenals strikte naleving van de inspringingsregels. Onthoud dat zelfs het onvermogen om softwaredocumentatie te maken, kan worden gerechtvaardigd. En de lelijke tekst van het programma nooit. Verwijzingen naar het feit dat deze tekst begrijpelijk is voor de auteur zelf worden niet serieus genomen. Je hoeft je niet te schamen om andere mensen de teksten van de programma's te laten lezen.

Hieronder een voorbeeld van zo'n goed leesbare tekst van het programma (overgenomen van de site van Nikolai Gekht, e-mail: [e-mail beveiligd], http://users.omskreg.ru/~geht)

/ * Windows-broncode "98

Broncode naar Windows 98 * / #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" # definieer INSTALL = HARD char make_prog_look_big; void main () (terwijl (! 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_HFSProy; disable_RealPlayer; disable_RealPlayer ) write_something (anything); display_copyright_message (); do_nothing_loop (); do_some_stuff (); if (still_not_crashed) (display_copyright_message_loop; do_nothing) (); do_nothing_loop ();)) if (detect_cache ()) disable_cache (); (fast_cpu )) (set_wait_states (veel); set_mouse (snelheid, zeer_langzaam); set_mouse (actie, springerig); set_mouse (reactie, soms);) / * printf ("Welkom bij Windows 3.11"); * / / * printf ("Welkom to Windows 95"); * / printf ("Welkom bij Windows 98"); if (system_ok ()) crash (to_dos_prompt ) else system_memory = open ("a: \ swp0001.swp", O_CREATE); while (something) ( slaap (5);get_user_input (); slapen (5); act_on_user_input (); slapen (5); ) create_general_protection_fault ();

Dit document bevat een beschrijving van wat en hoe er moet gebeuren om er zeker van te zijn (en de Klant te overtuigen) dat het programma correct werkt. Dit document is namelijk bepalend voor acceptatietesten. Een goed ontworpen programma en testmethodiek is de sleutel tot het ondertekenen van het acceptatiecertificaat, d.w.z. waar je zoveel tijd en moeite in hebt gestoken.

Formeel wordt deze GOST gebruikt om planningsdocumenten te ontwikkelen en testwerkzaamheden uit te voeren om de gereedheid en kwaliteit van een softwaresysteem te beoordelen. Het document bevat een beschrijving van het object en doel van het testen, vereisten voor het programma en voor softwaredocumentatie, middelen en procedure voor het testen, evenals een beschrijving van testgevallen.

De samenstellende delen van dit document zijn gemakkelijker en duidelijker direct te beschrijven in de vorm van voorbeelden.

Testobject

Voorbeeld: Het testobject is een programma ... bedoeld voor ...

Het doel van de testen

Voorbeeld: de betrouwbaarheid van het programma controleren.

Vereisten voor het programma

Voorbeeld: De werking van het programma mag niet leiden tot een crash (fatale systeemstoring). De organisatie van de dialoog dient te voorzien in bescherming tegen het invoeren van onjuiste gegevens. Het programma zou een diagnose moeten stellen van de systeemstatus en berichten over eventuele fouten die zijn opgetreden ... enzovoort.

Vereisten voor softwaredocumentatie

Voorbeeld: De samenstelling van de tijdens de test gepresenteerde softwaredocumentatie:

• beschrijving van het programma (GOST 19.402-78);
• testprogramma en methodologie (GOST 19.301-79);
• de tekst van het programma (GOST 19.401-78).

Middelen en testprocedure

Voorbeeld: Het programma werkt in overeenstemming met de bedrijfsomstandigheden van MS DOS (versie niet lager dan 3.0) op een pc zoals IBM PC / AT, evenals op compatibele. Voor de werking is ook een EGA (VGA)-adapter vereist.

Test procedure:

1. Het programma wordt gelanceerd door ….
2. Geselecteerd ...
3. Gedrukt ...
4. Achtereenvolgens geselecteerd...

Testgevallen

Voorbeeld: Voor testen worden ... aangeboden, waarvan de beschrijving is opgenomen in de bestanden ... De inhoud van de testbestanden en de resultaten van het programma staan ​​in bijlage 1.

En tot slot, denk eens aan de laatste UEA-standaard, die wordt genoemd

Deze norm stelt de regels vast voor de uitvoering van softwaredocumenten voor computers, complexen en systemen, ongeacht hun doel en reikwijdte, en voorzien in de UEA-normen.

Algemene vereisten. Het is noodzakelijk om programmadocumenten in te voeren die zijn gemaakt met getypte, machinale en handgeschreven methoden, individuele woorden, formules, conventionele tekens (met de hand in een tekenlettertype), letters van het Latijnse en Griekse alfabet, evenals om diagrammen en tekeningen uit te voeren in zwarte inkt of inkt.

Typfouten en grafische onnauwkeurigheden die tijdens de uitvoering worden gevonden, mogen worden gecorrigeerd door een slecht uitgevoerd deel van de tekst te wissen (tekening) en de gecorrigeerde tekst (grafische afbeeldingen) op hetzelfde blad aan te brengen met typoscript of zwarte inkt, afhankelijk van de methode van document uitvoering.

Beschadiging van vellen documenten, vlekken en sporen van onvolledig verwijderde tekst (afbeeldingen) zijn niet toegestaan.

Programmadocumenten worden opgemaakt op A4-vellen. Daarnaast:

• inschrijving op A3-vellen is toegestaan;
• met de machinemethode voor documentuitvoering zijn afwijkingen in bladformaten die overeenkomen met A4- en A3-formaten toegestaan, bepaald door de mogelijkheden van de gebruikte technische middelen; op vellen A4- en A3-formaat, voorzien door de uitvoerkenmerken van gegevensuitvoerapparaten, bij de vervaardiging van een document met een machine;
• bij het maken van een document met typografische methode is het mogelijk om vellen typografische formaten te gebruiken.

De rangschikking van de materialen van het programmadocument wordt in de volgende volgorde uitgevoerd:

• titel deel:

• goedkeuringsblad (niet inbegrepen in het totale aantal bladen van het document);
• titelpagina (eerste pagina van het document);

• informatief gedeelte:

• annotatie;
• inhoudsblad;

• grootste deel:

• de tekst van het document (met afbeeldingen, tabellen, enz.);
• lijst van termen en hun definities;
• Lijst van afkortingen;
• toepassingen;
• onderwerp index;
• lijst met documenten waarnaar wordt verwezen;

• onderdeel van het registreren van wijzigingen:

• registratieblad wijzigen.

Een document maken. Indien nodig is het toegestaan ​​om het document in delen op te delen. De verdeling in delen wordt uitgevoerd op het niveau dat niet lager is dan de sectie. Elk deel wordt afzonderlijk ingevuld, terwijl aan het einde van de inhoud van het eerste deel de namen van de overige delen moeten worden vermeld.

Het is toegestaan ​​om in het document delen van de programmatekst op te nemen, opgesteld volgens de regels van de taal waarin de programmatekst is geschreven.

De annotatie is geplaatst op aparte pagina(pagina's), zijn voorzien van de titel "ANNOTATIE", genummerd en opgenomen in de inhoud van het document.

De tekst van elk document is, indien nodig, onderverdeeld in paragrafen en paragrafen - in subparagrafen, ongeacht of het document is verdeeld in delen, paragrafen en subparagrafen of niet.

Sectiekoppen worden met een hoofdletter geschreven en symmetrisch geplaatst ten opzichte van de linker- en rechterrand van de tekst. De kopjes van subsecties zijn geschreven vanuit een alinea kleine letters(behalve de eerste hoofdletter). Woordafbreking in kopjes is niet toegestaan. Zet geen punt aan het einde van de titel. Het wordt aanbevolen om elke sectie op een nieuw blad te beginnen.

Secties, subsecties, clausules en subclausules moeten worden genummerd in Arabische cijfers met een punt. Secties moeten een volgnummer hebben (1, 2, enz.)

Documenttekst. De tekst van het document moet kort en duidelijk zijn, zonder de mogelijkheid van verkeerde interpretatie. Termen en definities moeten uniform zijn en voldoen aan gevestigde normen, en bij hun afwezigheid - algemeen aanvaard in de wetenschappelijke en technische literatuur, en worden vermeld in de lijst met termen.

De nodige toelichtingen bij de tekst van het document kunnen worden opgemaakt met voetnoten. Een voetnoot wordt aangeduid met een nummer met een haakje op het niveau van de bovenste snijlijn van het lettertype.

Als de voetnoot verwijst naar: een apart woord, wordt het voetnootteken direct naast dit woord geplaatst, maar als het om de hele zin gaat, dan aan het einde van de zin. De voetnoottekst wordt aan het einde van de pagina geplaatst en van de hoofdtekst gescheiden door een lijn van 3 cm aan de linkerkant van de pagina.

Illustraties. Illustraties kunnen in de tekst van het document en/of in de bijlagen staan. Afbeeldingen, als er meer dan één in dit document is, zijn door het hele document genummerd in Arabische cijfers.

In de bijlagen zijn de afbeeldingen binnen elke bijlage genummerd in de volgorde die is vastgesteld voor de hoofdtekst van het document. Verwijzingen naar afbeeldingen worden gegeven door het type: "Fig.12" of "(Fig.12)". Illustraties kunnen een thematische kop en figuurtekst hebben die de inhoud van de illustratie uitlegt.

Formules. Formules in een document, als er meer dan één is, zijn genummerd in Arabische cijfers, het nummer wordt aan de rechterkant van de pagina geplaatst, tussen haakjes op formuleniveau. Binnen het gehele document of zijn delen worden formules doorlopend genummerd in het geval van het opdelen van het document in delen.

Verwijzingen in de tekst naar het volgnummer van de formule staan ​​tussen haakjes, bijvoorbeeld: "in de formule (3)". Bij het opdelen van een document in delen, wordt het onderdeelnummer ervoor geplaatst serienummer de formule en wordt gescheiden van het laatste punt, bijvoorbeeld: "in de formule (1.4)".

De betekenis van de symbolen in de formule moet direct onder de formule worden gegeven. De betekenis van elk teken is bedrukt met nieuwe lijn in de volgorde waarin ze in de formule worden gegeven. De eerste regel van de decodering moet beginnen met het woord "waar", zonder een dubbele punt erachter.

Koppelingen. V beleidsdocumenten verwijzingen naar normen en andere documenten zijn toegestaan. Er moet worden verwezen naar het document in zijn geheel of naar de onderdelen ervan (met vermelding van de aanduiding en titel van het document, het nummer en de titel van het onderdeel of de bijlage).

Het is toegestaan ​​om alleen de aanduiding van het document en (of) secties aan te geven zonder hun namen te vermelden. Verwijzingen naar afzonderlijke paragrafen, paragrafen en afbeeldingen van een ander document zijn niet toegestaan. Verwijzingen in het document naar paragrafen, illustraties en afzonderlijke subparagrafen zijn toegestaan.

Opmerkingen. In de toelichting bij de tekst en tabellen zijn alleen referentie- en verklarende gegevens aangegeven. Een noot is niet genummerd. Zet na het woord "Opmerking" een punt. Verschillende noten moeten worden genummerd in opeenvolgende Arabische cijfers met een punt. Het woord "Note" wordt gevolgd door een dubbele punt. Opmerkingtekst kan slechts met één regelafstand worden afgedrukt.

Afkortingen. Afkortingen van woorden in de tekst en onderschriften onder afbeeldingen zijn niet toegestaan, met uitzondering van:

• afkortingen vastgelegd in GOST 2.316-68, en algemeen aanvaard in het Russisch;
• afkortingen die worden gebruikt om programma's, hun onderdelen en werkingsmodi aan te duiden, in taakbeheertalen, in programma-instellingen, enz., aangeduid met letters van het Latijnse alfabet.

Toepassingen. Geïllustreerd materiaal, tabellen of tekst hulpkarakter het is toegestaan ​​uit te geven in de vorm van aanvragen. Applicaties zijn ontworpen als een voortzetting van dit document op volgende pagina's of als afzonderlijk document uitgegeven.

Elke aanvraag moet op een nieuwe pagina beginnen met een aanduiding aan de rechterkant bovenhoek de woorden "Toepassing" en hebben een thematische titel. Als het document meer dan één bijlage bevat, worden alle bijlagen genummerd met Arabische cijfers (zonder het hekje), bijvoorbeeld:

Bijlage 1, Bijlage 2, enz.

Wanneer een bijlage als afzonderlijk document wordt vrijgegeven, dient het woord "Appendix" te worden vermeld op de titelpagina onder de naam van het document, en in aanwezigheid van meerdere bijlagen, moet ook het serienummer worden vermeld.

Een handleiding voor het correct schrijven van een beschrijving voor een winkeltoepassing.

App-definitie bestaat uit 3 delen: titel, beschrijving en schermafbeeldingen. Laten we de app-definitie kort en gedetailleerder bekijken.

Kortom.

Naam

De titel moet bevatten: trefwoorden... Zonder hen zal het voor gebruikers moeilijk zijn om uw product te vinden.

Beschrijving

Door structuur:

1. De eerste 1-3 zinnen in de beschrijving moeten het idee van de applicatie zo duidelijk mogelijk beschrijven en vertellen welk probleem het oplost. De maximale lengte van dit onderdeel is 255 tekens.
2. Als de app op TechCrunch heeft gestaan, moet er over worden gepraat.
3. De hoofdtekst van de beschrijving kan 2-3 alinea's bevatten. Hier beschrijven we de kenmerken en details.
4. Aan het einde moet er een lijst zijn van de belangrijkste functies met hun duidelijke beschrijving.
5. Helemaal aan het einde van de beschrijving plaatsen we de sectie "wat is er nieuw?". We hebben bugs opgelost, functies toegevoegd, het sterretje in het hart veranderd - het is er allemaal.

• De beschrijving moet de gebruiker duidelijk uitleggen hoe de applicatie werkt en waarom deze nodig is.
• Trefwoorden moeten worden ingevoegd in de context van de hele beschrijving, niet alleen de titel.
• De beschrijving moet in de tweede persoon worden geschreven, vanuit het oogpunt van de gebruiker, waarbij technische details en dubbelzinnigheden worden vermeden.

Schermafbeeldingen

Het eerste scherm is het belangrijkste, hier moet je de hoofdfunctie van de applicatie beschrijven. Het is het beste om werkwoorden te gebruiken in screenshotbeschrijvingen. Zij zijn degenen die de gebruiker het meest kwalitatief kunnen uitleggen wat er op een specifiek scherm moet gebeuren en hem tot actie kunnen aanzetten. Het werkwoord is het sterkste deel van de spraak.

En nu voor meer details.

1. Wat is de naam van uw product? Waarom is het nodig?

Meestal heeft het product een soort abstracte naam die de gebruiker helemaal niet laat weten waarvoor het bedoeld is. Daarom moet de volledige naam van de app store het directe doel van de applicatie bevatten. Dit is niet alleen belangrijk om het product beter te begrijpen, maar vooral zodat gebruikers uw product kunnen vinden en downloaden.

Het doel van het product is het trefwoord waarmee gebruikers de applicatie vinden in app stores of google. Als we in Google "app-ontwikkelingsbedrijf" scoren, zullen we Yalantis vinden, omdat onze volledige naam is Yalantis is een native iOS- en Android-app-ontwikkelingsbedrijf.

En als we de reis-app googlen, geeft de zoekopdracht ons TripIt (met de volledige naam TripIt Travel Organizer - Free), TripAdvisor (TripAdvisor Hotels Flights Restaurants), TripCase (TripCase - Travel Organizer) en andere reisgerelateerde toepassingen.

Neem bijvoorbeeld Mijn Dag. De naam in app-winkels klinkt als volgt:

Mijn dag - Afteltimer

Het is de countdown-timer, in dit geval de countdown-app, het trefwoord waarmee gebruikers onze applicatie vinden.

Flipboard: uw sociale nieuwsmagazine

Het is duidelijk en begrijpelijk waarom we Flipboard nodig hebben, en er zijn 3 trefwoorden tegelijk: nieuws, sociaal en tijdschrift.

Een van onze recente projecten, Vochi, heet in de App Store:

Vochi-berichten - Toekomstige levering

In dit geval maken we de gebruiker niet alleen duidelijk dat het een messenger is, maar ook zijn voordeel ten opzichte van vergelijkbare producten.

Hier zijn nog enkele voorbeelden van productnamen die hun verschillen met andere vergelijkbare toepassingen benadrukken:

• - Gay, hetzelfde geslacht, bi, sociaal netwerk om te chatten en jongens te ontmoeten
• - Ontdek muziek, artiesten, video's en songteksten
• Polyvore - gepersonaliseerde mode, winkelen en stijl
• Magisto - Video-editor en filmmaker

De toepassingsnaam mag maximaal 25 tekens bevatten. Als er meer woorden zijn, zijn deze simpelweg niet zichtbaar in de zoekopdracht.

Laten we nu beginnen met het samenstellen van een beschrijving voor de app store.

2. Hoe schrijf je een productbeschrijving?

1. Regels

Bij het proberen om de app store-applicatie zo goed mogelijk te beschrijven, moeten de volgende regels worden gevolgd:

• SLAP - Stop, kijk, handel, koop. Met andere woorden, grijp de aandacht van de gebruiker door vanaf het begin monosyllabische onderwerp- en werkwoordzinnen te gebruiken. Door betekenis eenvoudig en duidelijk over te brengen, zet je de gebruiker aan tot actie.
• KISS - Houd het simpel dom. Schrap alle overbodige woorden die nergens op slaan. Gebruik geen jargon, het kan eng zijn.
• WIIFM - Wat heb ik eraan? Wat krijgt, leert, voelt de gebruiker door de applicatie te downloaden? Wat is de waardepropositie van het product?

Het is wenselijk om de beschrijving in de tweede persoon te schrijven, vanuit het oogpunt van hoe de gebruiker het product zal gebruiken.

Om een ​​zinnige beschrijving samen te stellen, moet u de volgende vraag duidelijk beantwoorden.

2. Welke functies vervult uw applicatie?

Doorgaans voeren applicaties nogal wat verschillende functies uit, van registratie tot algemene voorwaarden. We hebben echter niet absoluut alle functies nodig om het product te beschrijven. Het is voldoende om er een paar te noemen, en een van de belangrijkste. Een belangrijke functie is jouw waardepropositie, concurrentievoordeel en positionering van uw product in de markt.

Als uw toepassing wordt gepositioneerd als de beste notebook, focus dan op deze functionaliteit. Het is beter om over één specifieke use-case te praten dan om gedachten in een boom te strooien over alle functies die je in het product hebt gestopt.

Voor onze Mijn Dag is de belangrijkste functie de aftelklok met herinnering. Andere functies die in de beschrijving worden vermeld, zijn achtergronden, vakanties, widgets, kleur- en stijlinstellingen en tijdseenheden die de app kan berekenen. We positioneren My Day als een mooi en handig product, en dit is de waarde ervan.

3. Waaruit bestaat de beschrijving?

Het verhaal over de app voor appstores is op te delen in 5 delen:

1. 255 tekens
2. Beoordeling en onderscheidingen (indien aanwezig)
3. 2-3 alinea's hoofdtekst
4. Lijst met functies
5. Wat is er nieuw?

4.25 eerste tekens

Begin met een sterke, duidelijke zin die uitlegt waarom de gebruiker de app nodig heeft en waarom deze cool is. Beschrijf het probleem en vertel me hoe uw toepassing het oplost. Als er op het eerste gezicht geen probleem is, maak er dan een aan.

Soms is het probleem dat de toepassing oplost duidelijk. Voor een fitnesstoepassing is dit bijvoorbeeld de mogelijkheid om workouts mee te nemen en lichamelijke opvoeding te doen waar je maar wilt. Voor dating-apps vergroot matching op basis van gezichtsherkenningstechnologie de kansen van een gebruiker om hun helft te ontmoeten. Het sociale netwerk voor monteurs geeft hen de mogelijkheid om de batterij te bespreken zonder de garage te verlaten. Een app voor onroerend goed is een gelukkige verlossing van hardnekkige makelaars en een verspilling van tijd.

Zelfs als uw product vermakelijk is, kunt u de beschrijving benaderen vanuit het oogpunt van het probleem en de oplossing ervan. Laten we Vine eens bekijken voor grappige video's.

is het entertainmentnetwerk waar video's en persoonlijkheden heel snel groot worden.

Hier benadrukken de makers dat zowel jij als je video snel populair zullen worden, wat erg belangrijk is voor de doelgroep van Vine.

Bekijk video's die trends creëren, cultuur beïnvloeden en je aan het lachen maken. Ontdek verhalen, personages en remixen die je nergens anders vindt. Hoor als eerste ongelooflijke nieuwe artiesten en liedjes.

Nou, alles, hier ben ik al eindelijk gekocht. Ik kan een trend creëren en lachen, en over het algemeen zijn er verhalen die je nergens anders kunt vinden, dat wil zeggen, Vine is een uniek voorstel.

En opmerken, video's bekijken, verhalen ontdekken, nieuwe artiesten en liedjes zijn duidelijk trefwoorden, correct ingepast in de context.

Het komt echter ook voor dat het probleem niet duidelijk is. Uber en Instacart zijn bijvoorbeeld producten die zijn ontworpen voor comfort. Toen ze voor het eerst werden uitgebracht, wisten gebruikers zelf niet dat ze een probleem hadden dat deze jongens wilden oplossen. Maar nu weten ze het!

Een ander voorbeeld:

Tijdregistratie-app terugspoelen: De beste tijdregistratie-oplossing is degene waar u niet eens over hoeft na te denken. Rewind houdt automatisch uw tijd bij op basis van uw locatie. Je hoeft alleen maar je belangrijke plaatsen in te stellen en je bent klaar.

Laten we zien:

Houdt de tijd bij op basis van uw locatie - dit is de essentie.

De beste tijdregistratie-oplossing is degene waar u niet eens over hoeft na te denken. - en dit is het probleem dat de applicatie oplost.

Je hoeft alleen maar je belangrijke plaatsen in te stellen en je bent klaar. - en hier leest u hoe u de tracker gebruikt.

5. Beoordeling en onderscheidingen

Als het je is gelukt om een ​​recensie van een betrouwbare bron te krijgen, moet je er een citaat uit invoegen in de beschrijving van de aanvraag.

Voorbeelden van beoordelingen:

• Quip - Documenten, Chat, Spreadsheets: ** Uitgelicht in MIT Technology Review's 10 Breakthrough Technologies 2014 **
• Wens - Winkelen leuk gemaakt: “ Liefde, hou van deze app. Het is een leuke app die je kunt wensen over dingen die je leuk vindt en wilt. Beveel het ten zeerste aan aan frndz & fmly, "- Olivia Austin... (google zegt dat deze porno oud is)
• “EEN hebbeding voor mama's!”- TechCrunch

Voorbeelden van onderscheidingen:

• AP mobiel is de bekroonde app van The Associated Press, de definitieve nieuwsbron waarop duizenden kranten, omroepen en digitale nieuwsaanbieders wereldwijd vertrouwen.
• Musixmatch Lyrics Finder: Musixmatch is 's werelds grootste songtekstcatalogus, waarmee je kunt genieten van diverse muziek met gesynchroniseerde songteksten. Uit 155 landen werd het geselecteerd voor de Editor's Choice in de App Store en werd het in 2013 ook verkozen tot App Of The Year.

Dat wil zeggen, nadat u de prijs heeft genoemd, moet u zeggen waarvoor u hem hebt ontvangen:

• nieuwsbron waarop duizenden kranten vertrouwen
• 's werelds grootste songtekstcatalogus

Nou, het slechtste einde, als er geen prijs of recensie is van een gerenommeerde bron, soms een recensie van gewone gebruikers, maar in dit geval heeft de toepassing in de regel een zeer specifieke use-case, bijvoorbeeld medicijnen.

Beoordelingen en onderscheidingen vergroten het vertrouwen van gebruikers in de app, maar zijn niet verplicht.

6. Hoofdtekst

App-beschrijvingen zijn als krantenartikelen: het belangrijkste nieuws komt naar voren en het minder belangrijke en details volgen.

Als u de beschrijving in kleine alinea's schrijft, is het voor de gebruiker gemakkelijker om de inhoud te begrijpen en ervoor te zorgen dat de app moet worden gedownload.

In de eerste 2-3 zinnen hebben we al de belangrijkste dingen gezegd:

Wunderlist helpt miljoenen mensen over de hele wereld bij het vastleggen van hun ideeën, dingen om te doen en plaatsen om te zien. (Wunderlist: takenlijst en taken)

Nu is het tijd om wat dieper in te gaan op de details en specificaties. Bovendien is body-copy een geweldige plek voor zoekwoorden (maar herhaal in geen geval wat u aan het begin zei).

Of je nu een boodschappenlijstje deelt met een geliefde, aan een project werkt of een vakantie plant, Wunderlist maakt het gemakkelijk om je lijsten te delen en samen te werken met iedereen in je leven. Wunderlist synchroniseert direct tussen je telefoon, tablet en computer, zodat je overal toegang hebt tot je lijsten.

Vanaf de eerste regels van de beschrijving begreep ik al waarom Wunderlist nodig is, en nu vertellen ze me wat er precies aan de lijsten kan worden toegevoegd en hoe ze te gebruiken.

Merk op dat Wunderlist, na de lijst met functies, gebruikers in detail vertelt waarvoor ze hem geld moeten geven:

Wunderlist is gratis te downloaden en te gebruiken. Wunderlist Pro verbetert je ervaring en geeft je onbeperkte toegang tot bestanden, toewijzen en subtaken om je te helpen nog meer te bereiken voor $ 4,99 per maand of $ 49,99 per jaar via een automatisch verlengend abonnement.

7. Lijst met functies

Het is wenselijk om 3 tot 7 functies in de lijst te hebben, en ze moeten allemaal een naam en een korte beschrijving hebben. Soms wordt de naam van een kenmerk weergegeven als een kop, gevolgd door een zin met de tekst:

VSCO-dagboek: Publiceer originele inhoud in uw Journal en deel deze met de creatieve gemeenschap. Doe inspiratie op in het VSCO Journal, een publicatie waarin creatievelingen van over de hele wereld worden belicht.

Een ander voorbeeld:

NYC Apartments and Real Estate van StreetEasy is een app die we voor Zillow hebben ontwikkeld. De belangrijkste functie is het zoeken naar onroerend goed, daarom komt de woordzoeker het vaakst voor in de beschrijving in de app store. Daarnaast worden de volgende functies vermeld:

• mogelijkheid om aanbiedingen voor verkoop en verhuur te bekijken, op te slaan en te delen
• e-mail en bel agenten rechtstreeks vanuit de app
• maak gebruik van de database voor allerlei feiten en geschiedenis op markt- en vastgoedniveau

En nog een goed voorbeeld uit de categorie gezondheid & fitness:

FitStar Personal Trainer - Verbrand calorieën en verlies gewicht met video-fitnessworkouts onder leiding van voetballegende Tony Gonzalez (nou ja, een zeer lange titel). De belangrijkste functie van deze app zijn trainingsvideo's. Maar daarnaast staan ​​de volgende features (in het kort) op een rij:

• HD-video's met legende
• Uitdagingen (persoonlijke doelen stellen)
• Apple TV
• Aangepaste audiotracker
• Voortgang bijhouden
• Verbind FitBit, Jawbone UO, MyFitnessPal
• Geïntegreerd met de Gezondheid-app

Bij het beschrijven van functies moeten de volgende regels in acht worden genomen:

1. Maak de functiebeschrijvingen niet te lang.
2. Zet de twee belangrijkste functies aan het begin en de derde belangrijkste aan het einde.
3. Niemand leest hier iets.
4. Niemand leest hier iets.
5. Elke nieuwe functie moet beginnen met een nieuw woord, en het is wenselijk dat het eerste woord in de hele lijst verwijst naar één woordsoort (werkwoorden, bijvoeglijke naamwoorden, zelfstandige naamwoorden).
6. De derde belangrijkste functie.

Vervolgens kun je praten over hoe je applicatie geld verdient en waarom mensen het zouden moeten weggeven, of je kunt het gebruikers direct in de applicatie laten weten. Waar je over geld praat, beslis jij, ik ga verder.

8. Wat is er nieuw?

Bijvoorbeeld:

• Ondersteunt nu iOS 9
• Vind-ik-leuks: kijk wie je bericht leuk vond
• Nu kun je tot 4 hotels tegelijk boeken in de app
• Een bug opgelost die van invloed was op sommige iPhone 6- en 6 Plus-lezers

9. Wat kan er wel en niet in de beschrijving?

Kan:

• Beknopte waardepropositie
• De uitdrukking "ideaal voor"
• Geloof: "Voor altijd vrij!"
• Van de makers van...

Het is verboden:

• Verkeerd gebruik van trefwoorden in de beschrijving (te veel trefwoorden en het gebrek aan verbinding met de context van de beschrijving wordt negatief ervaren door gebruikers)
• Grammaticale en typefouten maken
• Spreek technische taal
• Schrijf iets als: Ons product is gemaakt in New York door de ontwikkelaar Sidorov.
• Liegen (we krijgen slechte recensies in ruil)
• Schrijf verwarrend en abstract
• Hyperboliseren (gebruik woorden als revolutionair, revolutionair, spelveranderend, ontwrichtend, als dit niet echt waar is)

3. Hoe schrijf je beschrijvingen voor screenshots?

• duidelijk
• informatief
• kort

Schermafbeeldingen moeten de belangrijkste functies van de applicatie beschrijven en over specifieke gebruiksscenario's praten. De eerste screenshot is de belangrijkste, deze moet de waardepropositie beschrijven. Er zouden in totaal 5 screenshots moeten zijn.

ShopBob - Damesmode

• Shop de laatste mode en ontvang trendupdates en stylingtips
• Van jurken tot denim, van schoenen tot badkleding, vind wat je nu aan het shoppen bent
• Shop eerst de nieuwste stijlen en creëer een gepersonaliseerde boetiek met favorieten
• Bekijk alle prachtige details van dichtbij
• De ontwerpers om nu op je radar te zetten

ShopBob is een winkel, dus het eerste scherm zegt kopen.

Het is raadzaam om de beschrijving van de schermafbeelding te beginnen met een werkwoord, en als de functionaliteit beperkt is, dan met een zelfstandig naamwoord.

Mijn dag - Afteltimer

Waarom heb je een applicatiebeschrijving nodig?

Om Captain Obvious te citeren: het is noodzakelijk dat uw klanten weten wat uw toepassing is. Waar is het voor. Vanuit het oogpunt van een ontwikkelaar is een beschrijving een kans om een ​​klant te 'haken'. Je moet een idee verkopen. U moet hen vertellen waarom ze uw aanvraag moeten downloaden en niet een andere.

Wie uw beschrijving leest, heeft uw toepassing al gevonden in een zoekopdracht. De titel en screenshots leken hem al aantrekkelijk genoeg om op de "meer"-knop te drukken. Figuurlijk gesproken heeft hij zijn portemonnee al tevoorschijn gehaald - het enige dat overblijft is hem te laten betalen voor de aankoop.

Invoering

Je hebt een beperkt aantal woorden tot je beschikking. Bekijk de beschrijvingen van de applicaties - slechts een paar regels zijn onder het pictogram in de App Store geplaatst.

De zwaarste beperkingen worden opgelegd door het iPhone-scherm - je hebt slechts 225 tekens op voorraad. Dit is het belangrijkste deel van uw beschrijving. De hele beschrijving is beperkt tot vierduizend tekens, maar het hangt van de eerste tweehonderd af of kopers de rest willen lezen.

Je moet jezelf duidelijk en duidelijk uitdrukken. De naam van de app - en de screenshots - hadden de koper al in grote lijnen moeten vertellen wat het is. Nu moeten we deze indruk versterken.

De inleiding tot de beschrijving moet een oproep tot actie zijn. Probeer jezelf in de schoenen van je klant te verplaatsen. Wat wilt hij?

Er zijn een paar eenvoudige regels hier.

• Trek de aandacht van uw klant. Gebruik zelfstandige naamwoorden en werkwoorden aan het begin van een zin om de zin dynamisch en zo duidelijk mogelijk te maken.
• Gebruik geen jargon, dit kan onaangenaam zijn. Knip al het overbodige weg: inleidende woorden, bijwoorden, overdreven bloemige uitdrukkingen.
• Wat is de waarde van uw aanvraag? Wat krijgt, weet of ervaart de klant wanneer hij het downloadt?
• Om te zien hoe de beschrijving van uw toepassing eruit zal zien op het iPhone- of iPad-scherm, gebruikt u voorbeeld in een gratis programma.
• Het aas zit dus aan de haak - het is tijd om de lijn uit te gooien. Met andere woorden, we zijn klaar met de inleiding - we gaan door met de beschrijving.

Details

Leg precies uit wat de gebruiker van uw toepassing krijgt. Na een paar inleidende zinnen - een emotionele oproep tot actie - geef ze details.

Hoe u informatie verspreidt, hangt af van de toepassing die u heeft. Maar over het algemeen moet u zich aan dezelfde principes houden als journalisten die nieuwsberichten schrijven - de belangrijkste informatie komt eerst, minder belangrijke informatie aan het einde.

Negeer alinea's niet. Mensen schrikken als ze de tekst "canvas" zien. Varieer de lengte van de zin - dit maakt de tekst expressiever. Gebruik tussenkopjes en regeleinden. Lijsten zijn ook een goede manier om tekst op te splitsen en aantrekkelijker te maken.

Lijsten

Omdat we het over lijsten hebben, zijn ze de eenvoudigste en populaire manier vertellen over de kenmerken van uw toepassing. Hier zijn enkele tips om ze correct te gebruiken:

• maak ze niet te lang;
• zet de twee belangrijkste punten bovenaan de lijst, de rest onderaan;
• je hebt deze paragraaf waarschijnlijk niet gelezen;
• deze ga je zeker niet lezen.

Het is verleidelijk om alle features van de applicatie op een rijtje te zetten. Je kunt het proberen, maar onthoud: mensen lezen meestal de eerste twee punten en de laatste. Ze slaan het midden over, net als zinnen die met dezelfde woorden beginnen.

Het is dus het beste om de lange lijst op te splitsen in verschillende kleinere, allemaal verenigd door één onderwerp.

Zoeken

Mensen die op iTunes naar een app zoeken, concentreren zich niet op de beschrijving: ze hebben de neiging om meer aandacht te besteden aan de titel, trefwoorden en andere factoren. Trefwoorden in de beschrijving worden echter geïndexeerd door zoekmachines. Dus, juiste beschrijving Is de sleutel tot hoge zoekresultaten.

Uw beschrijving moet trefwoorden bevatten. Het is belangrijk om het niet te overdrijven. Ze moeten passend zijn. Probeer geen openlijk "verkopende" tekst te schrijven - het zal de potentiële gebruiker onvermijdelijk vervreemden. Als je hulp nodig hebt en het vooruitzicht om ervoor te betalen je niet afschrikt, kun je contact opnemen met Appnique of Sensor Tower (voor Engelstalige teksten - noot van de redactie).

Lokalisatie

Het lokaliseren van uw app is een relatief goedkope en gemakkelijke manier om uw downloads te verhogen. Hij heeft praktisch geen gebreken. Uit een onderzoek van Common Sense Advisory onder 3.000 kopers in 10 niet-Engelstalige landen blijkt dat meer dan 75% van de respondenten wil dat de app in hun moedertaal is.

Het rapport, getiteld "Niet lezen - niet kopen", stelt ook dat 55% van de gebruikers alleen winkelt op sites die informatie in hun moedertaal verstrekken. Interessant is dat tegelijkertijd 50% van de respondenten opmerkte dat ze zelfs tevreden zouden zijn met navigatie en een deel van de inhoud in hun moedertaal. Dat wil zeggen, zelfs een gedeeltelijke vertaling geeft topscores dan zijn volledige afwezigheid.

Gezien dit feit, vertaal in ieder geval de beschrijving, zo niet de hele aanvraag.

Biedt een lijst met gelokaliseerde apps gesorteerd op genre - zodat u kunt analyseren waar u uw inspanningen op moet richten. U kunt ook een lijst met de meest gebruikte woorden in de applicatiebeschrijving in verschillende talen bekijken.

Zorg ervoor dat het vertaalbureau over de juiste vaardigheden beschikt. Het is onwaarschijnlijk dat Google Translate in staat is om de betekenisnuances die u in de tekst plaatst, over te brengen.

Als een populaire website of beroemdheid een recensie voor uw app heeft geschreven, is het de moeite waard om deze te citeren. Als u een prijs heeft gewonnen, moet dit ook worden vermeld. Als uw applicatie erg populair is bij uw familieleden ... Misschien is het beter om te zwijgen (tenzij uw achternaam natuurlijk Kardashian is).

De regels van Apple suggereren dat je "gebruikersrecensies, complimenten en aanbevelingen alleen aan het einde van de beschrijving kunt plaatsen, voor het geval je dat nodig acht".

Updates

Denk niet dat de beschrijving van de toepassing verwant is aan de tien geboden en in steen gebeiteld is. Wat er na de update nieuw is in de applicatie, moet je uiteraard wel melden. Als je plotseling een briljante zin bedenkt, of gebruikers een opmerking hebben gedeeld die je inspireerde, of als de beste website op internet een coole recensie voor je app heeft achtergelaten, voel je dan vrij om je beschrijving te verbeteren. Als er fouten in de toepassing waren die het werk beïnvloedden, vergeet dan niet om na het oplossen ervan te melden dat ze zijn opgelost.

Beschrijving is niet alleen een venster naar uw toepassing, maar ook een kans om hoge zoekresultaten te krijgen.

Er zijn vier dingen om te overwegen om te profiteren van links / citaten. Ten eerste moet je altijd een website hebben voor je applicatie - met screenshots, teksten en links waar je deze kunt kopen. Ten tweede heb je een link naar het ondersteuningsteam nodig - een e-mail- of forumadres, waar je kunt schrijven als je vragen of problemen hebt. Derde - links naar uw projectpagina op sociale netwerken. Last but not least heeft u links naar uw andere applicaties nodig.

Zorg ervoor dat uw ondersteuningsteam onmiddellijk op vragen reageert. Als mensen het moeilijk vinden om je te bereiken, zullen ze je lage beoordelingen geven en misschien zelfs een hatelijke recensie schrijven.

Als gebruikers dezelfde vragen stellen, overweeg dan om een ​​FAQ-sectie op de site van de app te maken.

Als je al een succesvol project hebt, vermeld het dan zeker. Of je kunt een beschrijving achterlaten als "als je dit leuk vond, vind je deze misschien nog leuk" aan het einde van je andere appendix.

Veelvoorkomende fouten en hoe ze te vermijden

Typefouten en interpunctie/grammaticale fouten. Nodig een speciaal opgeleide copywriter uit of zet als laatste redmiddel de spellingcontrole in je teksteditor aan.

Verwarrende en taalgebonden beschrijving. Als de gebruiker u niet begrijpt, zal hij de applicatie niet downloaden.

Overmatig gebruik van hyperbolen en clichés. Is jouw app echt revolutionair? Is het bedrijf echt jong en dynamisch in ontwikkeling? Vind minder afgezaagde manieren om dit te communiceren.

Alle geheimen worden onthuld. De waarheid over uw toepassing wordt binnen een paar seconden na het downloaden onthuld - en vervolgens wordt deze opgeslagen in Google-cache voor altijd. Dus lieg niet.

Te veel zoekwoorden. Ik zei al dat onhandige pogingen om zoveel mogelijk trefwoorden in de tekst te proppen de koper alleen maar zullen vervreemden.

De beschrijving houdt geen rekening met de interesses van de doelgroep. Schrijf niet voor uzelf of uw concurrenten - schrijf voor de koper.

Belangrijke details ontbreken. Hoeveel weegt de app? Hoeveel kost een abonnement? Dit is geen informatie om te negeren.

Dus laten we beginnen

Om het kort samen te vatten, moet u voorbereiden, schrijven, aanscherpen, vertalen en vervolgens bijwerken als dat nodig is.

Doe je onderzoek en bereid je voor voordat je begint met het maken van je beschrijving. Vind de juiste trefwoorden en zinnen. Maak een lijst van de kenmerken van uw toepassing en rangschik ze van meest belangrijk naar minst belangrijk.

Schrijf hiervoor een conceptbeschrijving of huur een getalenteerde copywriter in.

Bewerk, tweak en herschrijf voor maximale impact. Controleer hoe de beschrijving eruit zal zien op het scherm van de iPhone of iPad. Werk totdat het glad, gepolijst en aantrekkelijk is.

Vertaal het in andere talen, te beginnen met de talen die vooral belangrijk zijn in termen van downloads.

Zorg ervoor dat de beschrijving alle wijzigingen weerspiegelt die in uw app zijn aangebracht, markeer belangrijke verbeteringen in de beschrijvingen en markeer positieve recensies of onderscheidingen.

Een goede beschrijving van de app zal helpen om deze te verkopen en downloads aan te moedigen.

instructies:

Omschrijven programma, begin met een algemene inleiding. Beschrijf het belangrijkste probleem waarmee de gebruiker wordt geconfronteerd. Dit zou natuurlijk het probleem moeten zijn dat het beschreven programma oplost. Dit is trouwens een manier om meteen de doelgroep van gebruikers in kaart te brengen. Degenen die het nuttig en nodig vinden, zullen het downloaden of kopen. Andere gebruikers zullen tijd besparen en zullen niet verder gaan. Beschrijf ook in de inleiding de belangrijkste kenmerken van het programma. Hiervoor zijn 1-2 zinnen voldoende.

Beschrijf de interface en werk ruimte... Omschrijven programma duidelijker, gebruik de verschillende werkvensters en. Beschrijf de belangrijkste werkbalken, de locatie van menu-items, statusbalken, enz.

Het is onmogelijk om te beschrijven programma zonder in detail te vertellen over de belangrijkste functies. Dit kan in de vorm van een lijst of een lijst. Het is echter belangrijk om in deze paragraaf specifiek te zijn. De uitdrukking "effectief werken met projecten" heeft bijvoorbeeld geen enkele semantische betekenis. Meer precies, er is natuurlijk een semantische lading, maar deze is relatief en brengt geen feiten aan de lezer over.

Nadat u de belangrijkste functies van het programma hebt aangegeven, beschrijft u de extra functies die voor de gebruiker bijzonder handig en nuttig kunnen zijn. Het kan bijvoorbeeld gaan om de mogelijkheid tot snelle integratie met andere software, verbeteringen in de werksnelheid, gebruiksvriendelijke ontwerpelementen, etc.

Omschrijven programma nieuwe versie, vertel ons over de wijzigingen die het heeft ondergaan sinds de vorige update. Beschrijf welke functionaliteit is verwijderd, welke problemen zijn opgelost, wat nieuw was, wat is gewijzigd, herzien en verbeterd. Verschillen met eerdere versies kunnen ook in de vorm van een lijst worden weergegeven.

We kunnen zonder twijfel zeggen dat de doelgroep een sleutelfiguur is in elk bedrijf, degenen voor wie het hele bedrijf in feite is georganiseerd. Simpel gezegd, dit zijn de kopers van uw goederen of diensten.

instructies:

De sleutel tot een succesvol bedrijf is nu volledige en betrouwbare kennis van uw doelgroep. Kom zoveel mogelijk te weten over uw klanten, beantwoord in ieder geval een bepaald minimum aan vragen. Zoek eerst het geslacht van uw doelgroep uit.

Het punt is dat percepties en waarden voor mannen en vrouwen verschillend zijn. Mannen zullen meer aandacht besteden aan rationele argumenten die hen aanzetten tot kopen, terwijl vrouwen meer geïnteresseerd zijn in de emotionele component van een product of dienst. Voor mannen, parameters als status, prestige, merkpopulariteit, gebruiksgemak, garantieservice en Aanvullende diensten... Veiligheid en eenvoud, kortingen en bonussen zijn belangrijk voor een vrouw.

Ten tweede, let op het leeftijdssegment van uw doelgroep. Hoe ouder uw klanten zijn, hoe meer oplosmiddel ze zijn, maar hoe hoger de eisen die zij aan het product stellen.

Het conservatisme van de oudere generatie zal hen ertoe aanzetten een product te kopen dat ze voor een lange tijd (tot 5-6 jaar) zullen gebruiken. Jongeren zijn al gewend aan snelle technologische vooruitgang en vinden het heerlijk om alles nieuw te proberen. De gebruiksduur van een nieuw product is in de regel vrij beperkt en varieert van zes maanden tot twee jaar, afhankelijk van de complexiteit en maakbaarheid van het product.

Voer enquêtes uit en let op parameters zoals inkomen (laag, midden, hoog en andere variaties), opleidingsniveau, gezinssamenstelling, voorkeursmedia (pers, radio, televisie, internet), hobby's en interesses, tijd besteed aan werk en aan de weg.

Verzamel vervolgens een focusgroep - 10-15 mensen die aan uw parameters voldoen, en nodig hen uit om als eerste nieuwe producten te testen en hun indrukken te beschrijven. Zo kunt u fouten op tijd corrigeren en verliezen minimaliseren wanneer u een product of dienst op een grote markt brengt.

Zoals een populair spreekwoord zegt, worden ze begroet door hun kleding en begeleid door hun geest. De eerste indruk die we maken op een potentiële werkgever, echtgenoot, collectief, hangt over het algemeen af ​​van de manier waarop latere relaties zich zullen ontwikkelen. Ondanks het feit dat de aanvankelijke mening over een persoon vaak bedrieglijk is, worden emoties op een onbewust niveau gedeponeerd en is het niet zo eenvoudig om ze in de toekomst te veranderen, het is bijna onmogelijk.

instructies:

Behulpzaam advies

Alles is goed met mate. Zelfvertrouwen, gematigdheid, een duidelijk begrip van de doelen die je wilt bereiken, uiterste eerlijkheid (maar geen domheid) is wat je zal toelaten om, zonder anderen te misleiden, de kortste weg naar het gewenste doel te vinden.

Vereisten voor het schrijven van educatieve programma's op scholen zijn 8 jaar geleden ontwikkeld en goedgekeurd. Sindsdien weet elke leraar een activiteitenplan voor het jaar te schrijven. Maar desondanks hebben docenten voortdurend vragen over wat er precies moet worden weerspiegeld in dit onderwijsprogramma.

instructies:

Ten eerste moet de inhoud van een dergelijk programma aan verschillende parameters voldoen. Het moet ingaan op de kwesties van de prestaties van de wereld en van Rusland, de tradities van hun land en anderen, en het programma moet ook de kwesties van de culturele en nationale kenmerken van de regio's behandelen. Wanneer u educatief schrijft, moet u rekening houden met de leeftijd van degenen voor wie het is ontworpen. Inderdaad, voor de jongere zijn er enkele normen, en voor de oudere absoluut anders. Het is wenselijk dat er in het plan voor de ontwikkeling van kinderen voor het jaar items zijn over aanvullende educatieve programma's. Het kan bijvoorbeeld een sociaal-pedagogische richting zijn, militair-patriottisch, sociaal-economisch en andere. Ook moeten leraren modern zijn en rekening houden met moderne onderwijstechnologieën in hun leerplan (dat wil zeggen, de technologieën die de individualiteit van kinderen zijn, de effectiviteit van hun schoolactiviteiten en andere aspecten).

in inhoud educatief programma vergeet niet te beschrijven welke voorwaarden worden geschapen voor de ontwikkeling van de persoonlijkheid van het kind, hoe de leerling de leermotivatie en creativiteit kan vergroten. Ook dienen leerkrachten rekening te houden met en op hun eigen manier te beschrijven hoe zij het emotionele welzijn van het kind zullen waarborgen, evenals hoe zij van plan zijn het kind universele waarden uit te leggen en bij te brengen. Op verzoek van het ministerie van Rusland moeten leraren in het programma voorschrijven hoe ze voorwaarden willen scheppen zodat het kind in staat is zichzelf te bepalen, zowel als persoon als als professional die al in dienst is.

Vergeet ook niet te vermelden over lichamelijke ontwikkeling studenten, namelijk: welke lessen lichamelijke opvoeding u met hen zult geven, in welke volgorde en waarin u met de ouders kunt afspreken om met hen de gezamenlijke tactieken voor het opvoeden van een kind te bespreken.

Naast aanbevelingen over de interne inhoud van het onderwijsprogramma, zijn er ook: hele regel vereisten voor het ontwerp van een dergelijk document. Zo moet het bijvoorbeeld noodzakelijkerwijs een titelpagina, een toelichting, een curriculum-thematisch plan, de inhoud van de cursus die wordt bestudeerd, een beschrijving van het lesmateriaal en de boeken die worden gebruikt voor extra onderwijs... En natuurlijk moet dit wetenschappelijke onderwijswerk eindigen met een lijst met referenties.

Exe-bestand in besturingssysteem Windows is uitvoerbaar bestand programma's. Het is een speciaal bewerkte code geschreven door een programmeur, gecompileerd en omgezet in een uitvoerbaar type. Daarom is het onmogelijk om kladblok te gebruiken en een exe-bestand te schrijven, zoals het kan met bat- of inf-bestanden.

Je zal nodig hebben

• - kennis van programmeren.

instructies:

Bepaal de taken die uw programma moet uitvoeren. Als dit eenvoudige taken zijn (bijvoorbeeld), begin dan onmiddellijk met het schrijven van een bat-bestand. Meer complexe acties moeten worden beschreven met behulp van een programmeertaal. Welke taal u moet kiezen, hangt af van de specificatie van de taken. Je moet standaard kennis hebben van de programmeertaal om een ​​kleine programma om eventuele specifieke taken uit te voeren.

Nadat je een programmeertaal hebt gekozen, leer je de basisprincipes van coderen in deze taal... Installeer een ontwikkelomgeving en probeer eenvoudige programma's te schrijven. Nadat u de logica van de omgeving en de compiler hebt begrepen, kunt u doorgaan met de implementatie van de taken.

Na het schrijven van het programma, compileer de bestanden programmacode: in de uitvoerbare toepassing door de vereiste bibliotheken en bronnen toe te voegen. Controleer het werkresultaat op eigen computer en vervolgens op de testercomputer om uit te sluiten onverwachte fouten... Meestal kunt u de standaard compiler voor de programmeeromgeving gebruiken. Er is ook speciale software waarmee je verschillende programma's kunt compileren.