Het maken van een website is een eenvoudige zaak als je online constructors gebruikt. Maar ze lijken allemaal zo op elkaar dat gerenommeerde bedrijven webmasters moeten zoeken of contact moeten opnemen met IT-bedrijven. In deze fase van het maken van een hulpmiddel is het uiterst belangrijk om het werk van de wizard te specificeren, dat wil zeggen om een technische taak op te stellen voor de ontwikkeling van de site.
Waarom hier tijd aan verspillen?
Hoe goed iemand ook is opgeleid, hij blijft een persoon en probeert hoe dan ook zijn werk gemakkelijker te maken. Daarom begrijpen klanten niet altijd waarom ze een technische taak schrijven voor de ontwikkeling van de site. Het is immers veel makkelijker om een webmaster te vragen om een "website in blauw met het logo van het bedrijf op de hoofdpagina" te maken. Maar wanneer de tijd rijp is voor de oplevering van het project, ziet de klant iets heel anders dan hij wilde. En de webmaster moet de bron keer op keer opnieuw doen.
Terms of reference is geen "bureaucratie", maar een rationele handeling die tijd, zenuwen en geld bespaart. Een bepaald bedrijf moet zich bijvoorbeeld ontwikkelenpresentatiesite, voor een periode van twee weken. En als u 2-3 dagen besteedt aan het maken van een voorbeeld van de referentievoorwaarden voor het ontwikkelen van een website, dan kunt u aan het einde van de termijn een afgewerkt product krijgen. Het voldoet aan alle eisen die klanten in het heetst van de strijd misschien vergeten te noemen. Aan de andere kant is het referentiekader voor de ontwikkeling van de site een garantie voor vergoeding.
Wijsheid van het verleden
Als de klant wordt geconfronteerd met de taak om technische specificaties te ontwikkelen, hoeft hij het wiel niet opnieuw uit te vinden, maar is het beter om naar de oorsprong te gaan, die is geverifieerd door jarenlange praktische ervaring. Dat wil zeggen, het is noodzakelijk om een voorbeeld van de taakomschrijving te schrijven voor de ontwikkeling van de site in overeenstemming met GOST. Het lijkt onrealistisch om de normen van 1978 toe te passen op de sites van vandaag, maar in de Sovjet-Unie waren sommige dingen geweldig, en de ontwikkeling van normen is geen uitzondering, en bovendien zijn ze nog steeds relevant. Bijzondere aandacht moet worden besteed aan de volgende normen:
- Vereisten voor inhoud en ontwerp (GOST 19.201-78).
- Referentievoorwaarden voor het maken van een geautomatiseerd systeem (GOST 34.602-78).
Het eerste document is geschikt voor reguliere sites. Het beschrijft hoe je de TOR goed opstelt, evenals de onderdelen waar je zeker rekening mee moet houden bij het opstellen van de taakomschrijving voor de ontwikkeling van de site. Deze omvatten:
- Introductie, die de naam van het bedrijf of de resource van de klant aangeeft, de korte beschrijving en reikwijdte ervan.
- Grond voor creatie. Hier heb je nodiggeef het onderwerp aan, geef de documenten aan die de noodzaak bevestigen om een hulpmiddel te creëren, de naam van de organisatie die dit document heeft goedgekeurd. De resultaten van marktonderzoek laten bijvoorbeeld zien dat de meerderheid van de gebruikers producten zoekt via internet, en dit zal de basis zijn voor het maken van een site.
- Bestemming. Het functionele doel van de bron wordt aangegeven. Informeren, verkopen, etc.
- Resourcevereisten. Dit is het grootste gedeelte waar de klant al zijn wensen met betrekking tot het toekomstige webproduct beschrijft. Hier moet u de functionaliteit specificeren, het betrouwbaarheidsniveau bepalen, de bedrijfsomstandigheden, inhoud, ontwerp, enz. beschrijven.
- Softwarevereisten.
- Technische en economische indicatoren. Dat wil zeggen dat er wensen worden aangegeven met betrekking tot het conversieniveau, voordelen ten opzichte van concurrenten, economische efficiëntie.
- Stadia van ontwikkeling. De klant bepa alt de deadline voor het voltooien van de taak.
- Control. De soorten verificatie worden aangegeven.
De tweede GOST is geschikt voor het maken van portals met complexe functionaliteit. Over het algemeen verschillen de belangrijkste doelstellingen en punten niet veel van het eerste document, ze hebben alleen uitgebreidere kenmerken. Alleen op basis van de informatie uit de documenten volgens de GOST-standaard, kunt u een volwaardig voorbeeld maken van de referentievoorwaarden voor de ontwikkeling van de site.
Kenmerken van het opstellen van TK
Hoe een technische opdracht opstellen voor de ontwikkeling van de site? Het belangrijkste bij het samenstellen van TOR is om constant na te denken over de hoofddoelen van het toekomstige document: het moet in een taal zijn geschrevendie zowel ontwikkelaars als klanten zullen begrijpen.
Meestal, bij het samenstellen van een voorbeeld van een technische taak voor de ontwikkeling van een site, worden de volgende punten als de belangrijkste beschouwd:
- Klantinformatie. Het is noodzakelijk om de reikwijdte van de activiteit, de geschiedenis van het bedrijf, kort te beschrijven en een lijst te maken van de belangrijkste concurrenten. Het is onwaarschijnlijk dat deze informatie nuttig is voor programmeurs, maar ontwerpers en copywriters hebben ze nodig.
- Het doel van de site. Dit blok moet belangrijke informatie bevatten waarmee u de structuur van de toekomstige bron, functionaliteit en de algemene richting van het ontwerp kunt begrijpen. Het beschrijft ook de belangrijkste doelgroep.
- Resourcevereisten. Het grootste gedeelte waar u uw wensen met betrekking tot de structuur, functionaliteit, ontwerp, software, hosting, etc. moet aangeven. Ook moet u hier paginaminiaturen en een sitemap bijvoegen.
- Actieplan. Elk referentiekader voor de ontwikkeling van de site moet in de beschrijving de ontwikkelingsstadia bevatten, de lijst met werkzaamheden die in een bepaalde fase zullen worden uitgevoerd en de timing van de bestelling.
- Controle en acceptatie van werk. De voorbeeldopdracht voor de ontwikkeling van de site moet duidelijk beschrijven hoe de conformiteit van de voltooide site met de gespecificeerde vereisten zal worden gecontroleerd. Het is belangrijk om de uitvoering van dit werk zorgvuldig te benaderen om misverstanden bij de klant te voorkomen.
Nadat je al deze punten in detail hebt doorgenomen, kun je snel leren hoe je het bestek voor de ontwikkeling van de site correct kunt opstellen.
Wie moet het doen?
Kortom, een voorbeeldHet reglement voor de ontwikkeling van de site kan door iedereen worden opgesteld. De eigenaar van een schoonheidssalon heeft bijvoorbeeld een website met visitekaartjes nodig. Hier zijn de referentievoorwaarden, maar of zo'n technische specificatie nuttig zal zijn, is een andere vraag.
Meestal is de artiest een goede technische achtergrond. Toch begrijpt een webontwikkelaar het maken van sites meer dan de eigenaar van een schoonheidssalon. Maar dat betekent helemaal niet dat de cliënt gedurende dit hele proces afwezig is. Volgens de basisregels van het referentiekader voor de ontwikkeling van de site, moet de klant:
- Introduceer artiesten aan het bedrijf, zijn producten, diensten en doelgroep.
- Leg uit waarom hij de site nodig had.
- Deel uw wensen voor een toekomstige hulpbron.
- Laat voorbeelden zien van sites waarvan hij denkt dat ze goed zijn.
- Beantwoord vragen van de ontwerper en webontwikkelaar (indien aanwezig).
De klant kan de TK zelf schetsen, maar, zoals de praktijk laat zien, worden zulke amateuristische schetsen meestal stilletjes in de prullenbak gegooid.
Precisie en uniekheid
Alles wat is geschreven in de voorbeelden en voorbeelden van technische specificaties voor de ontwikkeling van de site, moet begrijpelijk zijn voor de klant en de aannemer. Begrippen als mooi, modern, uniek en andere kunnen niet worden gebruikt, omdat iedereen ze op zijn eigen manier waarneemt. Dit geldt ook voor formuleringen die dubbelzinnig kunnen worden begrepen. Alles moet duidelijk en nauwkeurig zijn. Je kunt niet schrijven dat de site meer belasting kan weerstaan, omdat het niet duidelijk is hoeveel ze hebbengroot. Het is noodzakelijk om het misverstand onmiddellijk te ontkennen en aan te geven dat de bron tegelijkertijd 50 duizend bezoekers kan weerstaan. Elke formulering moet worden ondersteund door cijfers en precieze kenmerken.
Overige details
Bij het plannen van werkzaamheden aan het maken van een site, moet u alle ontwikkelingsdeelnemers informeren over wat het bedrijf doet en wie zijn belangrijkste doelgroep is. Je moet ook het doel van de site specificeren en functionele voorkeuren beschrijven, zodat je geen entertainmentblog krijgt in plaats van een serieuze online winkel.
In sommige gevallen is een woordenlijst opgenomen in de taakomschrijving voor de ontwikkeling van een website. Alle complexe termen worden beschreven in begrijpelijke taal zodat een onwetende klant geen vragen heeft over wat en hoe ze met zijn site gaan doen.
Zorg ervoor dat u aangeeft op welke hosting de bron moet staan. Ook zullen respectabele artiesten in de referentievoorwaarden een item als "werkvereisten" aangeven, waarbij ze aangeven dat de bron in alle browsers moet worden weergegeven. Natuurlijk is deze vereiste al begrijpelijk, maar het is beter om het op te schrijven zodat de klant wordt beschermd tegen gewetenloze artiesten.
Daarnaast wordt de opbouw, vormgeving en lay-out met de klant besproken, voor de duidelijkheid kan de klant een stroomschema tekenen. De klant moet uitleggen waar elke pagina van de site voor is en welke elementen erop kunnen staan.
Als je een hulpmiddel moet maken met een complexe en niet-standaard interface, is het niet genoeg om het te laten zienschets en paginastructuur. Het is uiterst belangrijk dat het hele ontwikkelteam en de klant begrijpen hoe de gemiddelde bezoeker de site zal gebruiken. Daarom zal het nodig zijn om een script te ontwikkelen. Zijn schema is heel eenvoudig:
- Gebruikersactie.
- Website reactie.
- Resultaat.
Content & Design
Het is ook noodzakelijk om vooraf te beslissen wie verantwoordelijk is voor de inhoud. In sommige gevallen kan een ontwikkelaar direct een website met inhoud maken, waarbij professionele copywriters worden ingeschakeld, maar dan zijn de kosten van de bron duurder. Dit moet vooraf worden afgesproken en alle wensen met betrekking tot de inhoud aangeven.
Het is waar, het zal moeilijk zijn om de inhoud objectief te beschrijven, omdat iedereen zijn eigen ideeën heeft over interessantheid en bruikbaarheid, het is gemakkelijker om te schrijven dat het uniek zal zijn. Dit is eenvoudig te controleren en er zullen geen onnodige claims zijn. Dit probleem geldt ook voor ontwerpbeschrijvingen. De beste oplossing zou zijn om in de referentievoorwaarden voor de ontwikkeling van het siteontwerp te schrijven welk kleurenschema de klant wil, in welk lettertype de inscripties zullen worden gemaakt, enz. Dat wil zeggen, alle posities aangeven waarin de nauwkeurigheid wordt weergegeven. Misschien zijn dit alle regels voor het maken van een referentiekader voor de ontwikkeling van de site. Nu moet je ze in de praktijk brengen en proberen om zelf een competente TK te creëren.
Template van referentievoorwaarden voor websiteontwikkeling
In deze TOR wordt op de eerste pagina een tabel met termen gegeven, zodat alles duidelijk is wat er wordt besproken. Opgemerkt moet worden dat de aanduiding van termen niet wordt gekopieerd van"Wikipedia" of andere bronnen, maar zijn geschreven door de persoon die de taakomschrijving ontwikkelt. De lijst met termen kan concepten bevatten zoals:
- IP-adres.
- www (wereldwijde web).
- Administratief deel van de bron, beheerder.
- Alternatief bijschrift voor de afbeelding.
- Webinterface.
- Link, link.
- Website-ontwerp, pagina-ontwerpsjabloon.
- Dynamische en statische pagina.
- Domeinnaam.
- Metatag.
- Inhoud.
- Een deel van de bron is openbaar.
- Back-up, databases, bestandsstructuur.
- Hosting.
- CMS.
Nadat de woordenlijst is gemaakt, kunt u direct beginnen met het schrijven van de referentievoorwaarden. Allereerst wordt algemene informatie geschreven. Deze paragraaf is voorwaardelijk onderverdeeld in vier subparagrafen:
- Het doel van het document. Het referentiekader voor de ontwikkeling van de site is het belangrijkste document dat het proces van het maken en accepteren van een bron regelt.
- Klantgegevens. De volgende coördinaten worden vermeld: bedrijfsnaam, contactgegevens, wettelijk adres, feitelijk adres, e-mail, website (als deze wordt hernoemd), contactpersoon, telefoonnummer van de contactpersoon.
- Korte informatie over het bedrijf. Voor een voorbeeld van de referentievoorwaarden voor de ontwikkeling van de site, overweeg het bedrijf Fortuna LLC. LLC "Fortuna" produceert (goederen) voor de markt van Novosibirsk. Het bedrijf bewaakt zorgvuldig de productiehygiëne, zuiverheid van grondstoffen en kwaliteitgefabriceerde producten. Het bedrijf voert gecertificeerde controle uit over de kwaliteit en veiligheid van gefabriceerde goederen op basis van de principes van het internationale HACCP-systeem.
- De basis voor ontwikkeling. De basis voor de ontwikkeling van de taakomschrijving is Contract No. _.
Doel en doel van de bron
De site is ontworpen om het marktaandeel van het bedrijf te vergroten en het imago van het bedrijf op het web te vergroten. De bron is gemaakt om de stroom van nieuwe klanten te vergroten, een gunstig imago te creëren en de populariteit van het merk Fortuna LLC te vergroten. Deze bron zal ook fungeren als een extra platform voor advertentiecampagnes, nieuwe klanten aantrekken en extra winst opleveren.
De belangrijkste taken van de bron zijn om de gebruiker volledige informatie over het product en de service te geven. De belangrijkste doelgroep zijn inkopers in de detailhandel, in het bijzonder vrouwelijke huisvrouwen en groothandelaren.
De site moet een handig beheerderspaneel hebben, het laden van pagina's moet worden geoptimaliseerd voor verschillende apparaten. De bron moet worden beschermd tegen aanvallen van buitenaf, gebruik elementen van de promotie van goederen en diensten. Naast volledige informatie over het product, vereist de productkaart de aanwezigheid van begeleidende documenten, zoals kwaliteitscertificaten.
Technische vereisten voor de site
De site moet op internet beschikbaar zijn onder een domeinnaam (naar keuze van de klant) en een informatiestructuur zijn die bestaat uit onderling verbonden secties met duidelijk gedefinieerde functies. Om de site en de werking ervan te onderhouden, mag het personeel niet:vereisen speciale vaardigheden en kennis op het gebied van software.
In een bronbeheersysteem is het belangrijk om een mechanisme te hebben voor het maken van een back-up van informatie die automatisch werkt.
De site-informatie is openbaar. Afhankelijk van de mate van toegangsrechten, worden gebruikers verdeeld in drie groepen:
- Bezoekers - hebben alleen toegang tot het openbare deel van de site.
- Editor - heeft de mogelijkheid om de sectiematerialen aan te passen.
- Beheerder - kan redacteuren aanstellen, secties toevoegen of verwijderen.
Toegang tot het administratieve gedeelte van de site moet worden beveiligd met een login en wachtwoord.
Technische functionaliteit moet voldoen aan de aanbevelingen van zoekmachines. Ten eerste moeten de pagina's dezelfde codering hebben. Ten tweede moeten linkovergangen worden geïmplementeerd met behulp van de "A" -tag. Ten derde moet u de codering in de HTTP-headers specificeren en wanneer u de site opent met behulp van de site.ru-link, moet u een 301-omleiding instellen naar het www.site.ru-domein.
De bron zou in alle moderne browsers moeten werken, dus het is noodzakelijk om te testen in:
- IE 11.
- Safari & Chrome voor iOS 9.0-9.2.
- Chrome 48.
- Firefox 44.
- Safari 9.
- Edge 13.
- Opera 34.
Als de bezoeker een verouderde browser gebruikt, zou er een venster moeten verschijnen waarin u wordt gevraagd deze bij te werken.
De site moet een logisch onderscheid hebben tussen gebruikers- en administratieve delen. Eerstverantwoordelijk voor het verstrekken van informatie, de tweede - voor het vullen van de bron met inhoud. Statische pagina's bestaan uit een titel, tekst en illustraties. De klant kan ze naar eigen goeddunken bewerken, aangezien deze informatie niet gerelateerd mag zijn aan de siteconfiguratie.
Hosting, inhoud, structuur
Vervolgens worden de noodzakelijke systeemvereisten beschreven, de ontwikkeltaal aangegeven (PHP met databases of gewone HTML met CSS).
Wat de inhoud betreft, voorziet de klant de ontwikkelaar van al het benodigde materiaal dat overeenkomt met de lijst met verplichte inhoud. Op basis van de ontvangen gegevens wordt unieke inhoud ontwikkeld en op de site geplaatst.
In de volgende fase van de ontwikkeling van de TOR wordt de structuur van de site ontwikkeld. Eerst worden de hoofdpagina en hoofdmenu-items beschreven. Na elk wordt een lijst met subitems toegevoegd. Dit kan grafisch worden weergegeven, maar je moet ook elke sectie beschrijven, wat er zou moeten zijn en welke doelen het zal nastreven.
Op de hoofdpagina van de Fortuna LLC-website is er bijvoorbeeld een sectie "Productie". Hierbij is het belangrijk om de voordelen van het bedrijf te laten zien tegen de achtergrond van concurrenten en op een toegankelijke manier aan de consument uit te leggen waarom Fortuna LLC beter is. Definieer informatie over de meest gekochte goederen in aparte alinea's en ondersteun deze met foto- en videomateriaal. Andere secties zijn op een vergelijkbare manier ontwikkeld.
Ontwerp- en functionele eisen
Als een bron wordt verbeterd, moet worden opgemerkt of depictogrammen, lettertypen en kleuren. Voor een nieuwe site zijn al deze posities voorgeschreven. De kleur geelgroen is bijvoorbeeld 9ACD32. Het is beter om de klant een palet te geven en de kleurcode voor te schrijven in de TOR om onnauwkeurigheden te voorkomen. Elke bron moet op alle apparaten dezelfde kwaliteit weergeven en zich dynamisch aanpassen aan de schermformaten.
Elke site heeft dynamische en statische secties. Dynamische beheerder kan onafhankelijk veranderen en statisch blijft ongewijzigd. De TOR moet prototypes van de hoofdpagina aanleveren. Het referentiekader voor de ontwikkeling van een website voor een online winkel moet prototypes van catalogi en productkaarten bevatten. Meestal maakt de ontwerper ze en toont ze aan de klant, pas daarna komen ze in de specificatie.
Zorg ervoor dat u een typische paginalay-out voorbereidt met verschillende variaties van tekstopmaak en informatie-uitvoer.
Inhoud en indieningsproces
De klant kan vragen om de bron te vullen met primaire informatie, maar in dit geval neemt hij de verantwoordelijkheid voor het verstrekken van de juiste gegevens aan de artiesten. Het wordt alleen geaccepteerd in elektronische vorm en in de laatste ontwikkelingsfase.
De gronden voor het accepteren van de site zijn:
- Naleving van TK.
- Testen voor de juiste weergave van afbeeldingen.
- Testfunctionaliteit.
Aan het einde van elke TOR moet je de volgorde en timing van het project schrijven. Over het algemeen kunnen alle werkzaamheden in 3 fasen worden verdeeld:
- Ontwerpontwikkeling,goedkeuring, schetslay-out.
- Softwareontwikkeling.
- De site vullen met informatie.
Bij elk van deze items wordt de vervaldatum in dagen aangegeven. Overeenkomstig de Overeenkomst kan de periode variëren. Als dit niet wordt verstrekt, wordt een wijziging in de deadline uitgevoerd door schriftelijke instemming van de partijen.
Voordeel
De taakomschrijving is nuttig voor zowel de opdrachtgever als de opdrachtnemer. De eersten begrijpen waarvoor ze geld betalen, zien onmiddellijk de bekwaamheid van de uitvoerder en verzekeren zich tegen oneerlijke uitvoering van het werk. Op zijn beurt helpt de TK de opdrachtnemer te begrijpen wat de klant wil en zich zo te verzekeren tegen plotselinge veranderingen. Dit is vooral het geval wanneer het project bijna klaar is, maar de klant iets wilde veranderen, vanwege dit "iets" zal al het werk opnieuw moeten worden gedaan.
