Å lage et nettsted er en enkel sak hvis du bruker online-konstruktører. Men de er alle så like at anerkjente firmaer må se etter webmastere eller kontakte IT-selskaper. På dette stadiet av å opprette en ressurs er det ekstremt viktig å spesifisere arbeidet til veiviseren, det vil si å utarbeide en teknisk oppgave for utviklingen av nettstedet.
Hvorfor kaste bort tid på dette?
Uansett hvor utdannet en person er, forblir han en person og prøver på noen måte å gjøre arbeidet sitt enklere. Derfor forstår ikke kundene alltid hvorfor skrive en teknisk oppgave for utviklingen av nettstedet. Det er tross alt mye lettere å be en webmaster lage en «nettside i blått med logoen til selskapet på hovedsiden». Men når tiden kommer for levering av prosjektet, ser kunden noe helt annet enn det han ønsket. Og nettredaktøren må gjøre om ressursen igjen og igjen.
Vilkår er ikke et «byråkrati», men en rasjonell handling som sparer tid, nerver og penger. For eksempel må en bestemt bedrift utvikle segpresentasjonsside, for en periode på to uker. Og hvis du bruker 2-3 dager på å lage et utvalg av vilkårene for utvikling av et nettsted, kan du på slutten av terminen få et ferdig produkt. Den vil oppfylle alle kravene som kunder i innspurtens hete kanskje glemmer å nevne. På den annen side er referansevilkårene for utviklingen av nettstedet en garanti for godtgjørelse.
Fortidens visdom
Hvis kunden står overfor oppgaven med å utvikle tekniske spesifikasjoner, trenger han ikke å finne opp hjulet på nytt, det er bedre å vende seg til opprinnelsen, som har blitt bekreftet av mange års praktisk erfaring. Det vil si at det er nødvendig å skrive et utvalg av referansevilkårene for utviklingen av nettstedet i samsvar med GOST. Det ville virke urealistisk å bruke 1978-standardene på dagens nettsteder, men i Sovjetunionen var noen ting bra, og standardutvikling er intet unntak, og dessuten er de fortsatt relevante. Spesiell oppmerksomhet bør rettes mot følgende standarder:
- Krav til innhold og design (GOST 19.201-78).
- Referansevilkår for opprettelse av et automatisert system (GOST 34.602-78).
Det første dokumentet passer for vanlige nettsteder. Den beskriver hvordan du skal utarbeide TOR på riktig måte, samt seksjonene som du definitivt bør ta i betraktning når du utarbeider referansevilkårene for utviklingen av nettstedet. Disse inkluderer:
- Introduksjon, som angir navnet på kundeselskapet eller ressursen, dens korte beskrivelse og omfang.
- Grunn for opprettelse. Her trenger duangi emnet, angi dokumentene som bekrefter behovet for å opprette en ressurs, navnet på organisasjonen som godkjente dette dokumentet. For eksempel viser resultatene av markedsundersøkelser at flertallet av brukerne ser etter produkter via Internett, og dette vil være grunnlaget for å lage et nettsted.
- Destinasjon. Det funksjonelle formålet med ressursen er angitt. Informere, selge osv.
- Ressurskrav. Dette er den største delen hvor kunden beskriver alle sine ønsker angående fremtidens nettprodukt. Her må du spesifisere funksjonaliteten, bestemme pålitelighetsnivået, beskrive driftsforholdene, innhold, design osv.
- Programvarekrav.
- Tekniske og økonomiske indikatorer. Det vil si at det angis ønsker angående konverteringsnivå, fordeler fremfor konkurrenter, økonomisk effektivitet.
- Utviklingsstadier. Kunden setter fristen for å fullføre oppgaven.
- Kontroll. Bekreftelsestypene er angitt.
Den andre GOST er egnet for å lage portaler med kompleks funksjonalitet. Generelt skiller ikke hovedmålene og punktene seg mye fra det første dokumentet, de har bare mer omfattende egenskaper. Basert kun på informasjonen fra dokumentene i henhold til GOST-standarden, kan du lage et fullverdig eksempel på referansevilkårene for utviklingen av nettstedet.
Funksjoner ved utkast TK
Hvordan utarbeide en teknisk oppgave for utviklingen av siden? Det viktigste når du kompilerer TOR er å hele tiden tenke på hovedmålene for det fremtidige dokumentet: det må være skrevet på et språksom både utviklere og kunder vil forstå.
Som oftest, når du kompilerer et eksempel på en teknisk oppgave for utvikling av et nettsted, regnes følgende punkter som de viktigste:
- Kundeinformasjon. Det er nødvendig å kort beskrive omfanget av aktiviteten, historien til selskapet, og lage en liste over hovedkonkurrentene. Denne informasjonen er neppe nyttig for programmerere, men designere og tekstforfattere trenger den.
- Formålet med nettstedet. Denne blokken bør inneholde nøkkelinformasjon som lar deg forstå strukturen til den fremtidige ressursen, funksjonaliteten og den generelle retningen til designet. Den beskriver også hovedmålgruppen.
- Ressurskrav. Den største delen hvor du må angi dine ønsker angående struktur, funksjonalitet, design, programvare, hosting osv. Du må også legge ved sideminiatyrbilder og sidekart her.
- Handlingsplan. Enhver mal med mandat for utviklingen av nettstedet bør inkludere i beskrivelsen utviklingsstadiene, listen over arbeid som vil bli utført på et bestemt stadium og tidspunktet for bestillingen.
- Kontroll og aksept av arbeid. Referanseeksemplet for utviklingen av området bør tydelig beskrive hvordan det ferdige områdets samsvar med de spesifiserte kravene vil bli kontrollert. Det er viktig å nærme seg gjennomføringen av dette arbeidet nøye for å unngå misforståelser med kunden.
Etter å ha gjennomarbeidet alle disse punktene i detalj, kan du raskt lære hvordan du korrekt komponerer referansevilkårene for utviklingen av nettstedet.
Hvem bør gjøre det?
I utgangspunktet en prøveReferansevilkårene for utviklingen av nettstedet kan utarbeides av hvem som helst. For eksempel trenger eieren av en skjønnhetssalong et visittkortnettsted. Her er referansevilkårene, men om en slik teknisk spesifikasjon vil være nyttig er et annet spørsmål.
Vanligvis er utøveren en god teknisk bakgrunn. Likevel forstår en nettutvikler opprettelsen av nettsteder mer enn eieren av en skjønnhetssalong. Men dette betyr slett ikke at klienten er fraværende gjennom hele denne prosessen. I henhold til de grunnleggende reglene i vilkårene for utvikling av nettstedet, må kunden:
- Introduser utøvere for firmaet, dets produkter, tjenester og målgruppe.
- Forklar hvorfor han trengte nettstedet.
- Del dine ønsker for en fremtidig ressurs.
- Vis eksempler på nettsteder han synes er bra.
- Svar på spørsmål fra designeren og nettutvikleren (hvis noen).
Kunden kan skissere TK på egen hånd, men som praksis viser, blir slike amatørske sketsjer vanligvis stille kastet i søpla.
Presisjon og unikhet
Alt som er skrevet i eksemplene og prøvene på tekniske spesifikasjoner for utvikling av tomten skal være forståelig for byggherren og entreprenøren. Begreper som vakkert, moderne, unikt og andre kan ikke brukes, fordi alle oppfatter dem på sin egen måte. Dette gjelder også formuleringer som kan forstås tvetydig. Alt skal være klart og presist. Du kan ikke skrive at nettstedet tåler mer belastning, fordi det ikke er klart hvor mye destor. Det er nødvendig å umiddelbart benekte misforståelsen, og spesifisere at ressursen er i stand til å motstå 50 tusen besøkende samtidig. Alle ordlyder bør støttes av tall og presise karakteristikker.
Andre detaljer
Når du planlegger arbeid med å lage et nettsted, må du varsle alle utviklingsdeltakere om hva selskapet gjør og hvem dens hovedmålgruppe er. Du må også spesifisere formålet med nettstedet og beskrive funksjonelle preferanser slik at du ikke får en underholdningsblogg i stedet for en seriøs nettbutikk.
I noen tilfeller er en ordliste inkludert i referansevilkårene for utvikling av et nettsted. Alle komplekse termer er beskrevet på et forståelig språk slik at en uinformert kunde ikke har spørsmål om hva og hvordan de vil gjøre med nettstedet hans.
Pass på å spesifisere hvilken hosting ressursen skal være. Også respektable utøvere vil i referansevilkårene angi et slikt element som "arbeidskrav", der de indikerer at ressursen skal vises i alle nettlesere. Selvfølgelig er dette kravet allerede forståelig, men det er bedre å skrive det ned slik at klienten er beskyttet mot skruppelløse utøvere.
I tillegg diskuteres struktur, design og layout med kunden, for oversiktens skyld kan kunden tegne et flytskjema. Klienten må forklare hva hver side på nettstedet er for og hvilke elementer som kan være på den.
Hvis du må lage en ressurs med et komplekst og ikke-standard grensesnitt, vil det ikke være nok bare å viseskisse og sidestruktur. Det er ekstremt viktig at hele utviklingsteamet og kunden forstår hvordan den gjennomsnittlige besøkende vil bruke siden. Derfor vil det være nødvendig å utvikle et manus. Planen hans er veldig enkel:
- Brukerhandling.
- Nettstedssvar.
- Resultat.
Innhold og design
Det er også nødvendig å bestemme på forhånd hvem som skal være ansvarlig for innholdet. I noen tilfeller kan en utvikler umiddelbart lage en nettside med innhold, som involverer profesjonelle tekstforfattere, men da blir kostnaden for ressursen dyrere. Dette må avtales på forhånd og angi alle ønsker angående innholdet.
Sant, det vil være vanskelig å objektivt beskrive innholdet, fordi alle har sine egne ideer om interessanthet og nytte, det er lettere å skrive at det vil være unikt. Dette er enkelt å sjekke, og det vil ikke komme unødvendige krav. Denne problemstillingen gjelder også designbeskrivelser. Den beste løsningen vil være å skrive i referansevilkårene for utvikling av nettstedsdesignet hvilket fargevalg kunden ønsker, hvilken font inskripsjonene skal lages i, osv. Det vil si, angi alle posisjoner hvor nøyaktighet vises. Kanskje dette er alle reglene for å lage referansevilkår for utviklingen av nettstedet. Nå må du sette dem i praksis og prøve å lage en kompetent TK på egen hånd.
Referansemal for nettstedutvikling
I denne TOR er en tabell med vilkår gitt på første side slik at alt er klart hva som skal diskuteres. Det skal bemerkes at betegnelsen på begreper ikke er kopiert fra"Wikipedia" eller andre ressurser, men er skrevet av personen som utvikler referansevilkårene. Listen over termer kan inneholde begreper som:
- IP-adresse.
- www (world wide web).
- Administrativ del av ressursen, administrator.
- Alternativ bildetekst for bildet.
- Nettgrensesnitt.
- Link, link.
- Nettsteddesign, sidedesignmal.
- Dynamisk og statisk side.
- domenenavn.
- Metatag.
- Innhold.
- En del av ressursen er offentlig.
- Sikkerhetskopiering, databaser, filstruktur.
- Hosting.
- CMS.
Etter at ordlisten er opprettet, kan du begynne å skrive referansevilkårene direkte. Først og fremst skrives generell informasjon. Dette avsnittet er betinget delt inn i fire underavsnitt:
- Formålet med dokumentet. Referansevilkårene for utviklingen av nettstedet er hoveddokumentet som regulerer prosessen med å opprette og akseptere en ressurs.
- Kundedata. Følgende koordinater er angitt: firmanavn, kontaktdetaljer, juridisk adresse, faktisk adresse, e-post, nettside (hvis den blir endret), kontaktperson, kontakttelefonnummer.
- Kort informasjon om selskapet. For et utvalg av referansevilkårene for utviklingen av nettstedet, vurder selskapet Fortuna LLC. LLC "Fortuna" produserer (varer) for markedet i Novosibirsk. Selskapet overvåker nøye produksjonshygiene, renhet av råvarer og kvalitetproduserte produkter. Selskapet utfører sertifisert kontroll over kvaliteten og sikkerheten til produserte varer basert på prinsippene i det internasjonale HACCP-systemet.
- Grunnlaget for utvikling. Grunnlaget for utviklingen av referansevilkårene er kontrakt nr. _.
Formål og formål med ressursen
Nettstedet er designet for å øke selskapets markedsandel og heve selskapets image på nettet. Ressursen er opprettet for å øke strømmen av nye kunder, skape et gunstig bilde, øke populariteten til Fortuna LLC-merket. Denne ressursen vil også fungere som en ekstra plattform for reklamekampanjer, tiltrekke nye kunder og gi ekstra fortjeneste.
Ressursens hovedoppgaver er å gi brukeren fullstendig informasjon om produktet og tjenesten. Hovedmålgruppen er detaljhandelskjøpere, spesielt kvinnelige husmødre og grossister.
Nettstedet bør ha et praktisk administrasjonspanel, sideinnlasting bør være optimalisert for forskjellige enheter. Ressursen må beskyttes mot eksterne angrep, brukselementer for promotering av varer og tjenester. I tillegg til full informasjon om produktet, krever produktkortet at det er medfølgende dokumenter, for eksempel kvalitetssertifikater.
Tekniske krav for nettstedet
Siden skal være tilgjengelig på Internett under et domenenavn (etter valg av kunden) og være en informasjonsstruktur bestående av sammenkoblede seksjoner med klart definerte funksjoner. For å vedlikeholde området og dets drift, bør personell ikkekrever spesielle ferdigheter og kunnskaper innen programvare.
I et ressursstyringssystem er det viktig å ha en mekanisme for sikkerhetskopiering av informasjon som vil fungere automatisk.
Nettstedets informasjon er offentlig. Avhengig av omfanget av tilgangsrettigheter er brukerne delt inn i tre grupper:
- Besøkende - har kun tilgang til den offentlige delen av nettstedet.
- Editor - har muligheten til å endre seksjonsmaterialet.
- Administrator - kan utnevne redaktører, legge til eller fjerne seksjoner.
Tilgang til den administrative delen av nettstedet bør beskyttes med pålogging og passord.
Teknisk funksjonalitet må være i samsvar med anbefalingene fra søkemotorer. Først må sidene ha samme koding. For det andre må koblingsoverganger implementeres ved å bruke "A"-taggen. For det tredje må du spesifisere kodingen i HTTP-hodene, og når du får tilgang til nettstedet ved å bruke site.ru-koblingen, må du angi en 301-viderekobling til www.site.ru-domenet.
Ressursen skal fungere i alle moderne nettlesere, så det er nødvendig å teste i:
- IE 11.
- Safari og Chrome for iOS 9.0-9.2.
- Chrome 48.
- Firefox 44.
- Safari 9.
- Edge 13.
- Opera 34.
Hvis den besøkende bruker en utdatert nettleser, skal det vises et vindu som ber deg om å oppdatere den.
Nettstedet må ha et logisk skille mellom bruker- og administrative deler. Førstansvarlig for å gi informasjon, den andre - for å fylle ressursen med innhold. Statiske sider består av en tittel, tekst og illustrasjoner. Kunden kan redigere dem etter eget skjønn, siden denne informasjonen ikke skal være relatert til nettstedets konfigurasjon.
Hosting, content, structure
Deretter beskrives de nødvendige systemkravene, utviklingsspråket er angitt (PHP med databaser eller vanlig HTML med CSS).
Når det gjelder innholdet, gir kunden utvikleren alt nødvendig materiale som samsvarer med listen over obligatorisk innhold. Basert på dataene som mottas, utvikles unikt innhold og legges ut på nettstedet.
På neste trinn av utviklingen av TOR utvikles strukturen til nettstedet. Først beskrives hovedsiden og hovedmenyelementene. Etter hver er det lagt til en liste over underelementer. Dette kan avbildes grafisk, men du må også beskrive hver seksjon, hva som skal være der og hvilke mål den vil forfølge.
For eksempel, på hovedsiden til Fortuna LLC-nettstedet er det en seksjon "Produksjon". Her er det viktig å avsløre fordelene til selskapet mot konkurrenters bakgrunn og forklare forbrukeren på en tilgjengelig måte hvorfor Fortuna LLC er bedre. Definer informasjon om de mest kjøpte varene i separate underavsnitt og støtte den med foto- og videomateriell. Andre seksjoner er utviklet på lignende måte.
Design og funksjonelle krav
Hvis en ressurs blir forbedret, bør det noteres omikoner, fonter og farger. For et nytt nettsted er alle disse stillingene foreskrevet. For eksempel er fargen gul-grønn 9ACD32. Det er bedre å gi kunden en palett og foreskrive fargekoden i TOR for å unngå unøyaktigheter. Hver ressurs skal vise samme kvalitet på alle enheter og dynamisk justere til skjermstørrelser.
Hvert nettsted har dynamiske og statiske deler. Dynamisk administrator kan endres uavhengig, og statisk forblir uendret. TOR må gi prototyper av hovedsiden. Referansevilkårene for utvikling av en nettbutikks nettside skal inneholde prototyper av kataloger og produktkort. Vanligvis lager designeren dem og viser dem til kunden, først etter det kommer de inn i spesifikasjonen.
Pass på å forberede et typisk sideoppsett med forskjellige varianter av tekstformatering og informasjonsutgang.
Prosess for innhold og innsending
Kunden kan be om å fylle ressursen med primærinformasjon, men i dette tilfellet tar han ansvar for å gi korrekte data til utøverne. Det aksepteres bare i elektronisk form og på siste utviklingsstadium.
Begrunnelsen for å godta nettstedet er:
- Overholdelse av TK.
- Tester for riktig visning av bilder.
- Testfunksjonalitet.
På slutten av hver TOR må du skrive rekkefølgen og tidspunktet for prosjektet. Generelt kan alt arbeid deles inn i 3 trinn:
- Designutvikling,godkjenning, skisselayout.
- Programvareutvikling.
- Fyller nettstedet med informasjon.
Nær hver av disse varene er forfallsdatoen i dager angitt. I henhold til avtalen kan perioden variere. Dersom dette ikke er gitt, foretas endring av fristtiden etter skriftlig avtale mellom partene.
Benefit
Referansene er nyttige for både byggherren og entreprenøren. Førstnevnte forstår hva de betaler penger for, kan umiddelbart se kompetansen til utøveren og forsikre seg mot uærlig utførelse av arbeid. På sin side hjelper TK entreprenøren å forstå hva kunden ønsker og dermed sikre seg mot plutselige endringer. Dette gjelder spesielt når prosjektet er nesten ferdig, men kunden ønsket å endre noe, på grunn av dette "noe" må alt arbeidet gjøres om.
