Veebisaidi loomine on lihtne, kui kasutate veebikonstruktoreid. Kuid nad on kõik nii sarnased, et mainekad ettevõtted peavad otsima veebihaldureid või võtma ühendust IT-ettevõtetega. Selles ressursi loomise etapis on äärmiselt oluline täpsustada viisardi tööd, st koostada saidi arendamiseks tehniline ülesanne.
Milleks sellele aega raisata?
Ükskõik kui haritud inimene ka poleks, jääb ta ikkagi inimeseks ja püüab igal viisil oma tööd lihtsamaks teha. Seetõttu ei saa kliendid alati aru, miks kirjutada saidi arendamiseks tehniline ülesanne. Lõppude lõpuks on palju lihtsam paluda veebihalduril teha "sinine veebisait, mille avalehel on ettevõtte logo". Kui aga saabub projekti elluviimise aeg, näeb klient hoopis midagi muud, kui ta soovis. Ja veebihaldur peab ressurssi ikka ja jälle uuesti tegema.
Lähteülesanne ei ole "bürokraatia", vaid ratsionaalne tegu, mis säästab aega, närve ja raha. Näiteks peab teatud ettevõte arenemaesitlussaidil kahe nädala jooksul. Ja kui kulutate 2-3 päeva veebisaidi arendamise lähteülesande näidise koostamiseks, siis võite tähtaja lõpus saada valmistoote. See vastab kõikidele nõuetele, mida kliendid võivad kiires kuumuses mainimata unustada. Teisest küljest on saidi arendamise lähteülesanne tasu tagatis.
Mineviku tarkus
Kui kliendi ees seisab tehniliste kirjelduste väljatöötamine, ei pea ta jalgratast uuesti leiutama, parem on pöörduda päritolu poole, mida on tõestanud mitmeaastane praktiline kogemus. See tähendab, et saidi arendamiseks on vaja vastav alt GOST-ile kirjutada näidis ülesandest. Tundub ebareaalne rakendada 1978. aasta standardeid tänapäeva saitidel, kuid Nõukogude Liidus olid mõned asjad suurepärased ja standardite väljatöötamine pole erand ja pealegi on need endiselt aktuaalsed. Erilist tähelepanu tuleks pöörata järgmistele standarditele:
- Nõuded sisule ja kujundusele (GOST 19.201-78).
- Automatiseeritud süsteemi loomise tingimused (GOST 34.602-78).
Esimene dokument sobib tavasaitidele. Selles kirjeldatakse, kuidas TOR-i õigesti koostada, samuti jaotisi, mida peaksite saidi arendamise lähteülesande koostamisel kindlasti arvesse võtma. Nende hulka kuuluvad:
- Sissejuhatus, mis näitab kliendiettevõtte või ressursi nime, selle lühikirjeldust ja ulatust.
- Loomise põhjused. Siin on vajamärkige teema, märkige dokumendid, mis kinnitavad ressursi loomise vajadust, selle dokumendi kinnitanud organisatsiooni nimi. Näiteks turu-uuringute tulemused näitavad, et enamik kasutajaid otsib tooteid Interneti kaudu ja see on saidi loomise aluseks.
- Sihtkoht. Näidatud on ressursi funktsionaalne eesmärk. Informeerimine, müümine jne
- Ressursinõuded. See on suurim rubriik, kus klient kirjeldab kõiki oma soove seoses tulevase veebitootega. Siin tuleb määrata funktsionaalsus, määrata töökindluse tase, kirjeldada töötingimusi, sisu, disaini jne.
- Tarkvaranõuded.
- Tehnilised ja majandusnäitajad. See tähendab, et soovitakse välja tuua ümberehituse tase, eelised konkurentide ees, majanduslik efektiivsus.
- Arenguetapid. Tellija määrab ülesande täitmise tähtaja.
- Juht. Kinnitamise tüübid on näidatud.
Teine GOST sobib keeruka funktsionaalsusega portaalide loomiseks. Üldiselt ei erine peamised eesmärgid ja punktid palju esimesest dokumendist, neil on lihts alt ulatuslikumad omadused. Ainult GOST-standardi kohaste dokumentide teabe põhjal saate luua saidi arendamise lähteülesannete täieõigusliku näite.
Joonistuse omadused TK
Kuidas koostada tehniline ülesanne saidi arendamiseks? TOR-i koostamisel on kõige olulisem mõelda pidev alt tulevase dokumendi põhieesmärkidele: see peab olema kirjutatud keelesmillest nii arendajad kui ka kliendid aru saavad.
Saidi arendamise tehnilise ülesande näite koostamisel peetakse kõige sagedamini järgmisi punkte:
- Kliendiinfo. Vajalik on lühid alt kirjeldada tegevusala, ettevõtte ajalugu ja teha nimekiri peamistest konkurentidest. Tõenäoliselt pole see teave programmeerijatele kasulik, kuid disainerid ja tekstide autorid vajavad seda.
- Saidi eesmärk. See plokk peaks sisaldama põhiteavet, mis võimaldab teil mõista tulevase ressursi struktuuri, funktsionaalsust ja disaini üldist suunda. See kirjeldab ka peamist sihtrühma.
- Ressursinõuded. Suurim jaotis, kus peate märkima oma soovid struktuuri, funktsionaalsuse, disaini, tarkvara, hostimise jms osas. Siia peate lisama ka lehtede pisipildid ja saidikaardi.
- Tegevuskava. Iga saidi arendamise lähteülesande mall peaks sisaldama oma kirjelduses arendusetappe, teatud etapis tehtavate tööde loendit ja tellimuse ajastust.
- Töö kontroll ja vastuvõtmine. Objekti arendamise lähteülesande näidis peaks selgelt kirjeldama, kuidas kontrollitakse valminud objekti vastavust etteantud nõuetele. Oluline on hoolik alt läheneda selle töö teostamisele, et vältida arusaamatusi kliendiga.
Kui olete kõik need punktid üksikasjalikult läbi töötanud, saate kiiresti õppida, kuidas saidi arendamise lähteülesandeid õigesti koostada.
Kes peaks seda tegema?
Põhimõtteliselt näidisLehekülje arendamise lähteülesande võib koostada igaüks. Näiteks vajab ilusalongi omanik visiitkaartide veebisaiti. Siin on lähteülesanne, aga kas sellisest tehnilisest spetsifikatsioonist on kasu, on teine küsimus.
Tavaliselt on esinejal hea tehniline taust. Siiski mõistab veebiarendaja saitide loomist rohkem kui ilusalongi omanik. Kuid see ei tähenda sugugi, et klient on kogu protsessi vältel eemal. Järgides saidi arendamise lähteülesande põhireegleid, peab klient:
- Tutvustage esinejatele ettevõtet, selle tooteid, teenuseid ja sihtrühma.
- Selgitage, miks tal seda saiti vaja oli.
- Jagage oma soove tulevase ressursi osas.
- Näidake tema arvates heade saitide näiteid.
- Vastake disaineri ja veebiarendaja (kui neid on) küsimustele.
Klient võib TK visandada ka ise, kuid nagu praktika näitab, visatakse sellised amatöörlikud visandid tavaliselt vaikselt prügikasti.
Täpsus ja kordumatus
Kõik, mis on kirjas objekti arendamise tehniliste kirjelduste näidetes ja näidistes, peaks olema tellijale ja töövõtjale arusaadav. Mõisteid nagu ilus, kaasaegne, ainulaadne jt ei saa kasutada, sest igaüks tajub neid omal moel. See kehtib ka mitmetähenduslikult mõistetavate formulatsioonide kohta. Kõik peab olema selge ja täpne. Te ei saa kirjutada, et sait talub suuremat koormust, sest pole selge, kui palju nad taluvadsuur. Arusaamatust tuleb kohe eitada, täpsustades, et ressurss suudab korraga vastu pidada 50 tuhandele külastajale. Mis tahes sõnastust tuleks toetada numbrite ja täpsete tunnustega.
Muud üksikasjad
Saidi loomisega seotud töid planeerides tuleb teavitada kõiki arenduses osalejaid, millega ettevõte tegeleb ja kes on selle peamine sihtrühm. Samuti peate täpsustama saidi eesmärgi ja kirjeldama funktsionaalseid eelistusi, et te ei saaks tõsise veebipoe asemel meelelahutusblogi.
Mõnel juhul lisatakse veebisaidi arendamise lähteülesandesse sõnastik. Kõik keerulised terminid on kirjeldatud arusaadavas keeles, et teadmatul kliendil ei tekiks küsimusi selle kohta, mida ja kuidas ta oma saidiga peale hakkab.
Kindlasti täpsustage, millisel hostil ressurss peaks asuma. Samuti märgivad lugupeetud tegijad lähteülesandes sellise üksuse kui "töönõuded", kus nad näitavad, et ressurssi tuleks kuvada kõigis brauserites. See nõue on muidugi juba mõistetav, kuid parem on see kirja panna, et klient oleks kaitstud hoolimatute esinejate eest.
Lisaks arutatakse kliendiga struktuuri, disaini ja paigutust, selguse huvides saab klient joonistada vooskeemi. Klient peab selgitama, mille jaoks saidi iga leht on mõeldud ja millised elemendid sellel võivad olla.
Kui peate looma keeruka ja mittestandardse liidesega ressursi, ei piisa ainult näitamisesteskiis ja lehe struktuur. Äärmiselt oluline on, et kogu arendusmeeskond ja klient mõistaksid, kuidas keskmine külastaja lehte kasutama hakkab. Seetõttu on vaja välja töötada skript. Tema skeem on väga lihtne:
- Kasutaja tegevus.
- Veebisaidi vastus.
- Tulemus.
Sisu ja kujundus
Samuti tuleb eelnev alt otsustada, kes sisu eest vastutab. Mõnel juhul saab arendaja kohe teha sisuga veebisaidi, kaasates professionaalseid tekstikirjutajaid, kuid siis on ressursi maksumus kallim. See tuleb eelnev alt kokku leppida ja kõik soovid sisu osas ära näidata.
Tõsi, sisu on raske objektiivselt kirjeldada, sest igaühel on huvitavast ja kasulikkusest oma arusaamad, lihtsam on kirjutada, et see on kordumatu. Seda on lihtne kontrollida ja tarbetuid pretensioone pole. See probleem puudutab ka disainikirjeldusi. Parim lahendus oleks saidi kujunduse väljatöötamise lähteülesandesse kirjutada, millist värvilahendust klient soovib, millises kirjatüübis pealdised tehakse jne. See tähendab, et märkida kõik positsioonid, milles täpsus ilmneb. Võib-olla on need kõik saidi arendamise lähteülesande koostamise reeglid. Nüüd peate need praktikas rakendama ja proovima ise luua pädeva TK.
Veebisaidi arendamise lähteülesande mall
Selle TOR-i esimesel lehel on terminite tabel, et kõik oleks selge, millest arutatakse. Tuleb märkida, et terminite tähistust ei kopeerita"Wikipedia" või muud allikad, kuid need on kirjutatud lähteülesande väljatöötav isik. Terminite loend võib sisaldada selliseid mõisteid nagu:
- IP-aadress.
- www (ülemaailmne veeb).
- Ressursi administratiivne osa, administraator.
- Pildi alternatiivne pealkiri.
- Veebiliides.
- Link, link.
- Veebisaidi kujundus, lehekujunduse mall.
- Dünaamiline ja staatiline leht.
- Domeeni nimi.
- Meta silt.
- Sisu.
- Osa ressursist on avalik.
- Varundamine, andmebaasid, failistruktuur.
- Majutus.
- CMS.
Pärast sõnastiku loomist võite asuda otse lähteülesannet kirjutama. Esiteks on kirjas üldine teave. See lõik on tinglikult jagatud neljaks lõiguks:
- Dokumendi eesmärk. Saidi arendamise lähteülesanne on peamine dokument, mis reguleerib ressursi loomise ja vastuvõtmise protsessi.
- Kliendiandmed. Märgitud on järgmised koordinaadid: ettevõtte nimi, kontaktandmed, juriidiline aadress, tegelik aadress, e-post, veebisait (kui seda muudetakse), kontaktisik, kontakttelefon.
- Lühike teave ettevõtte kohta. Saidi arendamise lähteülesannete näidise saamiseks kaaluge ettevõtet Fortuna LLC. LLC "Fortuna" toodab (kaupu) Novosibirski turu jaoks. Ettevõte jälgib hoolik alt tootmishügieeni, tooraine puhtust ja kvaliteetivalmistatud tooteid. Ettevõte teostab sertifitseeritud kontrolli tööstuskaupade kvaliteedi ja ohutuse üle, lähtudes rahvusvahelise HACCP süsteemi põhimõtetest.
- Arengu alus. Lähteülesande väljatöötamise aluseks on Leping nr _.
Ressursi eesmärgid ja eesmärk
Saidi eesmärk on suurendada ettevõtte turuosa ja tõsta ettevõtte mainet veebis. Ressurss luuakse selleks, et suurendada uute klientide voogu, luua soodsat mainet, suurendada Fortuna LLC kaubamärgi populaarsust. Lisaks toimib see ressurss reklaamikampaaniate lisaplatvormina, meelitab ligi uusi kliente ja toob täiendavat kasumit.
Ressursi põhiülesanne on pakkuda kasutajale täielikku teavet toote ja teenuse kohta. Peamine sihtrühm on jaemüüjad, eelkõige naiskoduperenaised ja hulgimüüjad.
Saidil peaks olema mugav administraatoripaneel, lehe laadimine peaks olema optimeeritud erinevatele seadmetele. Ressursi tuleb kaitsta väliste rünnakute eest, kasutada kaupade ja teenuste reklaamimise elemente. Lisaks täielikule teabele toote kohta nõuab tootekaart kaasasolevate dokumentide olemasolu, näiteks kvaliteedisertifikaadid.
Saidi tehnilised nõuded
Sait peab olema Internetis saadaval domeeninime all (kliendi valikul) ja olema teabestruktuur, mis koosneb omavahel seotud sektsioonidest, millel on selgelt määratletud funktsioonid. Töötajad ei tohiks saidi ja selle toimimise säilitamiseksnõuavad erioskusi ja -teadmisi tarkvara vallas.
Ressursihaldussüsteemis on oluline teabe varundamise mehhanism, mis töötab automaatselt.
Saidi teave on avalik. Sõltuv alt juurdepääsuõiguste ulatusest jagatakse kasutajad kolme rühma:
- Külastajad – pääsevad ligi ainult saidi avalikule osale.
- Toimetaja – on võimeline jaotise materjale muutma.
- Administraator – saab määrata toimetajaid, lisada või eemaldada jaotisi.
Juurdepääs saidi haldusosale peaks olema kaitstud sisselogimise ja parooliga.
Tehnilised funktsioonid peavad vastama otsingumootorite soovitustele. Esiteks peab lehtedel olema sama kodeering. Teiseks tuleb linkide üleminekud realiseerida sildi "A" abil. Kolmandaks peate määrama HTTP päistes kodeeringu ja saidile saidile saidile saidi site.ru lingi kaudu sisenemisel peate määrama 301 ümbersuunamise domeenile www.site.ru.
Ressurss peaks töötama kõigis kaasaegsetes brauserites, seega on vaja testida:
- IE 11.
- Safari ja Chrome iOS 9.0–9.2 jaoks.
- Chrome 48.
- Firefox 44.
- Safari 9.
- Edge 13.
- Ooper 34.
Kui külastaja kasutab aegunud brauserit, peaks ilmuma aken, mis palub teil seda värskendada.
Saidil peab olema loogiline vahe kasutaja- ja haldusosade vahel. Esiteksvastutab teabe edastamise eest, teine - ressursi sisuga täitmise eest. Staatilised lehed koosnevad pealkirjast, tekstist ja illustratsioonidest. Klient saab neid muuta oma äranägemise järgi, kuna see teave ei tohiks olla seotud saidi konfiguratsiooniga.
Majutus, sisu, struktuur
Järgmisena kirjeldatakse vajalikke süsteeminõudeid, näidatakse arenduskeel (PHP andmebaasidega või tavaline HTML CSS-iga).
Mis puudutab sisu, siis klient annab arendajale kõik vajalikud materjalid, mis vastavad kohustusliku sisu loetelule. Saadud andmete põhjal töötatakse välja ja postitatakse saidile ainulaadne sisu.
TOR-i arendamise järgmises etapis töötatakse välja saidi struktuur. Kõigepe alt kirjeldatakse põhilehte ja peamenüü üksusi. Pärast iga lisatakse alamüksuste loend. Seda saab graafiliselt kujutada, kuid peate ka kirjeldama iga jaotist, mis seal peaks olema ja milliseid eesmärke see taotleb.
Näiteks Fortuna LLC veebisaidi avalehel on jaotis "Tootmine". Siin on oluline paljastada ettevõtte eelised konkurentide taustal ja selgitada tarbijale arusaadav alt, miks Fortuna LLC on parem. Määrake teave enim ostetud kaupade kohta eraldi alapunktides ja toetage seda foto- ja videomaterjalidega. Teised jaotised on välja töötatud sarnasel viisil.
Disain ja funktsionaalsed nõuded
Kui ressurssi täiustatakse, tuleb märkida, kasikoonid, fondid ja värvid. Uue saidi jaoks on kõik need ametikohad ette nähtud. Näiteks kollakasroheline värv on 9ACD32. Parem on anda kliendile palett ja määrata TOR-is värvikood, et vältida ebatäpsusi. Iga ressurss peaks kuvama kõigis seadmetes sama kvaliteediga ja dünaamiliselt kohanduma ekraanisuurustega.
Igal saidil on dünaamilised ja staatilised jaotised. Dünaamiline administraator saab muutuda iseseisv alt ja staatiline administraator jääb muutumatuks. TOR peab esitama avalehe prototüübid. Veebipoe veebilehe arendamise lähteülesanne peab sisaldama kataloogide ja tootekaartide prototüüpe. Tavaliselt teeb disainer need ja näitab kliendile, alles pärast seda jõuavad need spetsifikatsiooni.
Kindlasti valmistage ette tüüpiline lehepaigutus tekstivormingu ja teabeväljundi erinevate variatsioonidega.
Sisu ja esitamisprotsess
Klient võib paluda ressurssi esmase teabega täita, kuid sel juhul võtab ta vastutuse esitajatele õigete andmete esitamise eest. Seda aktsepteeritakse ainult elektroonilisel kujul ja viimases arendusetapis.
Saidi aktsepteerimise põhjused on järgmised:
- Vastavus TK-le.
- Piltide õige kuvamise testimine.
- Funktsionaalsuse testimine.
Iga TOR-i lõppu peate kirjutama projekti järjekorra ja ajastuse. Üldiselt võib kogu töö jagada 3 etappi:
- Disaini arendus,kinnitus, eskiis paigutus.
- Tarkvara arendus.
- Saidi täitmine teabega.
Kõigi nende üksuste lähedal on näidatud tähtaeg päevades. Vastav alt Lepingule võib periood erineda. Kui seda ei ole sätestatud, toimub tähtaegade muutmine poolte kirjalikul kokkuleppel.
Kasu
Lähteülesanne on kasulik nii tellijale kui ka töövõtjale. Esimesed saavad aru, mille eest nad raha maksavad, näevad kohe esineja pädevust ja kindlustavad end ebaausa töö tegemise vastu. TK omakorda aitab töövõtjal mõista, mida tellija soovib ja seeläbi kindlustada end ootamatute muutuste eest. See kehtib eriti siis, kui projekt on peaaegu valmis, kuid klient tahtis midagi muuta, sest selle "millegi" tõttu tuleb kogu töö uuesti teha.
