Specifikacija od kupca. Kako napraviti jednostavan tehnički zadatak i ne izgubiti novac i živce

Kako napisati tehnički zadatak za program u skladu s GOST 19.201-78?

Datum kreiranja 15.02.2010 15:50:53

Napomena od 11.06.2014. - Poštovane dame i gospodo! Vjerojatno svaki drugi ili treći vaš projektni zadatak za programe koji je nekako završio u rukama autora sadrži autentične tekstove iz ovog članka. Ovo je sjajno i vraški lijepo, ali treba uzeti u obzir činjenicu da je od prvog članka prošlo skoro desetljeće, a za to vrijeme se puno toga promijenilo, pogotovo dijelom. Naravno, ne možete izbaciti riječi iz pjesme, ali se uključite u kreativu i smislite neke modernije aranžmane. I ne zaboravite da je ovo , a ne "" dokument.

Projektni zadatak u skladu s na listovima formata 11 i 12 u skladu s GOST 2.301-68, u pravilu, bez popunjavanja lista. Brojevi listova (stranica) pričvršćeni su na vrhu lista iznad [iz klauzule 1.1 GOST 19.201-78]

List odobrenja i naslovna stranica

List i naslovna stranica sastavljaju se u skladu s GOST 19.104-78.

Informativni dio(ovi), list za registraciju promjena ne može biti uključen u dokument [iz klauzule 1.2 GOST 19.201-78]

Ovu priliku treba iskoristiti. Manje riječi, manje pitanja.

Izmjene i dopune

Za izradu ili dopunu projektnog zadatka za naknadnu ili objavu dopune. i dodaci projektnom zadatku provode se istim redoslijedom koji je utvrđen za projektni zadatak [iz klauzule 1.3 GOST 19.201-78]

Nemoguće je uzeti u obzir sve detalje na početku, stoga se u praksi ovaj pristup vrlo često koristi. U „Faze i faze razvoja“ potrebno je izričito naznačiti mogućnost izmjene i dopune projektnog zadatka: „Sadržaj dijelova ovog projektnog zadatka može se mijenjati i dopunjavati u dogovoru s naručiteljem. "

Sastav dijelova projektnog zadatka

Projektni zadatak treba sadržavati sljedeće:

• Uvod;
• razlozi za;
• svrha razvoja;
• do ili;
• zahtjevi za;
• tehnički i ekonomski pokazatelji;
• red i;
• dopušteno je uključivanje prijava u projektni zadatak.

Ovisno o značajkama programa ili softverskog proizvoda, dopušteno je razjasniti sadržaj odjeljaka, uvesti nove odjeljke ili kombinirati pojedinačne [iz klauzule 1.4 GOST 19.201-78]

Sve manipulacije odjeljcima - strogo prema str.

Zasebni pododjeljci projektnog zadatka mogu djelovati na uvjetnog kupca kao crvena krpa na bika. Kupca, čak i uvjetnog, ne treba nervirati. U kontroverznim pododjeljcima razmotrit će se načini pronalaženja kompromisnih rješenja. Ključne pozicije, u kojima je popuštanje mušteriji ravno stezanju omče oko vrata izvođača, također će biti komentirane s opravdanjem za izvođački tvrd stav.

Kako ne bismo nepotrebno opterećivali tijek pripovijedanja, koristit ćemo se kao pravi program c, koji pruža mogućnost izvođenja nekoliko funkcija predloška. Neka takav program postane jednostavan.

Uvod

U odjeljku "Uvod" navode kratak opis opsega ili objekta u kojem se koristi program ili softverski proizvod [iz klauzule 2.1 GOST 19.201-78]

Osnovno pravilo rada s - detaljima, dijeljenje teksta u strukturne jedinice - odjeljke, pododjeljke, odlomke i podstavke, pogledajte članak "" dokumenta će imati jasnu strukturu koja pridonosi jednostavnosti potrebnog materijala. Tekst dokumenta postat će strukturiran i lak za čitanje. Stvorite pododjeljke:

Naziv programa

Naziv programa je “Uređivač teksta za rad s rtf datotekama”.

Kratak opis opsega

Program je namijenjen za korištenje u specijaliziranim odjelima u objektima korisnika.

Sadržaj pojedinih stavki nije uvijek jasan. U slučaju poteškoća, treba pristupiti formalno. dokument će biti moguć u tijeku tehničkog zadatka s kupcem.

Razlozi za razvoj

Odjeljak Osnova za razvoj treba sadržavati:

• dokument (dokumenti) na temelju kojeg se provodi razvoj;
• , ovaj dokument i datum njegovog odobrenja;
• i (ili) oznaka teme razvoja.

[iz klauzule 2.2 GOST 19.201-78]

Osnova za razvoj

Osnova za razvoj je Ugovor (pismo, itd.) br. 666 od 32. ožujka 2004. (dolazni br. takav i takav od tog i tog). Ugovor je odobrio direktor Saveznog državnog jedinstvenog poduzeća "Spetstyazhmontazhstroyselkhozavtomatika" Ivanov Petr Ivanovich, u daljnjem tekstu Naručitelj, a odobrio ga je generalni direktor OAO Supersoft Blumkins Ivan Aronovich, u daljnjem tekstu Izvođač, na to i to ožujka 2004.

Prikladno je koristiti odjeljak " Opće informacije“, budući da programer ima puno pravo nadopunjavati i brisati dijelove uvjeta rada prema vlastitom nahođenju. Istodobno, gore navedeni podaci sadržani su u ugovoru. Hoće li ih trebati dati u projektnom zadatku ovisi o konkretnom slučaju.

Naziv i simbol razvojne teme

Naziv razvojne teme je “Razvoj uređivača teksta za rad s rtf datotekama”. Simbol razvojne teme (kod teme) - "RTF-007"

Svrha razvoja

U odjeljku "Svrha razvoja" također mora biti naznačena operativna svrha ili [iz klauzule 2.3 GOST 19.201-78]

Funkcionalna namjena

Funkcionalna svrha programa je pružiti korisniku mogućnost rada s tekstualnim dokumentima u rtf formatu.

Pododjeljak treba naznačiti "uvećano" funkcionalna namjena programa. Pojedinosti - popis značajki itd. - bit će dani u nastavku u relevantnim odjeljcima.

Operativna svrha može se tumačiti prilično široko. Gdje, kako, tko, s čime treba upravljati programom?

Guma jedne standardne veličine može se uspješno koristiti na Zhiguliju i Volgi, ali ne i na Kamazu. Zbog odsutnosti. I obrnuto. Ali za svaku specifičnu veličinu gume može se odrediti njezina radna svrha.

Uzmimo formalni pristup:

Operativna svrha

Program se mora izvoditi u specijaliziranim odjelima u objektima korisnika. moraju biti zaposlenici relevantnih odjela kupčevih objekata.

Zadnje dvije rečenice su van teme. Prilikom pregovora sa stvarnim kupcem, pododjeljak će se prilagoditi.

Zahtjevi za program ili softverski proizvod

Odjeljak "Zahtjevi za program ili softverski proizvod" treba sadržavati sljedeće pododjeljke:

• zahtjevi izvedbe;
• zahtjevi za;
• zahtjevi za sastav i parametre;
• zahtjevi za i;
• zahtjevi za i;
• zahtjevi za i;
• posebni zahtjevi.

[iz klauzule 2.4 GOST 19.201-78]

Ako postoje standardi koji sadrže opće (tehničke) zahtjeve za program ili, na primjer, „GOST 12345-67. Automatizirani informacijsko-mjerni sustavi. Opći (tehnički) zahtjevi”, izrada tehničke specifikacije uvelike je pojednostavljena. Većina sadržaja navedene norme jednostavno je prepisana u projektni zadatak.

Zahtjevi za sastav funkcija koje se obavljaju

Program mora omogućiti izvođenje sljedećih funkcija:

• funkcije za stvaranje nove (prazne) datoteke;
• funkcije za otvaranje (učitavanje) postojeće datoteke;
• funkcije za uređivanje otvorene (u daljnjem tekstu tekuće) datoteke unosom sadržaja datoteke pomoću standardnih;
• funkcije uređivanja trenutne datoteke s aplikacijom;
• funkcije datoteka s izvorom;
• funkcije za spremanje datoteke s nazivom drugačijim od izvornog;
• funkcije za slanje sadržaja trenutne datoteke e-poštom pomoću vanjskog klijentskog programa za poštu;
• funkcije za prikaz online pomoći u (savjeti);
• funkcije;
• funkcije za prikaz naziva programa, verzije programa, autorskih prava i komentara razvojnih programera.

Klišej "omogući izvršavanje" odnosi se na moderni softver razvijen s grafičkim korisničkim sučeljem. Ovi programski alati uglavnom su u "mirovanju" (idle), čekaju. Korištenje klišeja - konstrukcija predložaka fraza - detaljno je opisano u članku "".

Zahtjevi za organizaciju ulaznih podataka

programi moraju biti organizirani kao zasebne RFC-kompatibilne rtf datoteke... Datoteke navedenog formata moraju biti postavljene () na lokalno ili uklonjivo mjesto, prema potrebi operacijski sustav.

Bilo koji drugi, ali s ekstenzijom rtf, ne bi se trebao otvoriti.

Datoteke http://domain.net/file.rtf ili ftp://domain.net/file.rtf ne bi trebale biti otvorene. Ako je datotečni sustav formatiran kao FAT32, datoteke iz lokalnog ili prijenosnog formata, formatirane, na primjer, u ext3 formatu, ne bi se trebale otvarati.

Zahtjevi za organizaciju izlaznih podataka

Zahtjevi su isti kao i za organizaciju izlaznih podataka. Upravo onaj slučaj kada obje točke tehničkog zadatka treba kombinirati.

Vremenski zahtjevi

Ne postoje zahtjevi za vremenske karakteristike programa.

Treba razjasniti postavlja li kupac zahtjeve za brzinu programa, na primjer, koliko dugo se program treba pokretati, otvarati i zatvarati datoteke zadane veličine. Ako kupac navede određene brojke, trebali biste se uvjeriti i postaviti zahtjeve za sastav i parametre tehničke opreme u vrijednosti od 2500 USD ili više. Istina, takav će se iznos morati opravdati. Ako vremenske karakteristike za kupca nisu temeljne, potrebno je pisati o odricanju od zahtjeva za vremenske karakteristike, vidi gornji tekst.

Zahtjevi za pouzdanost

Pododjeljak "Zahtjevi za pouzdanost" treba navesti zahtjeve za osiguranje funkcioniranja (pružanje, kontrola ulaznih i izlaznih informacija, nakon, itd.) [iz klauzule 2.4.2 GOST 19.201-78]

- tanka i vrlo opasna stvar. Ali popis funkcija i njihovih vrsta, prema klauzuli 1.3.2. , naručitelj je dužan izraditi i dogovoriti s izvođačem.

Najvjerojatnije neće biti moguće čekati nešto razumljivo od kupca. Vrijedi objasniti kupcu da pouzdano funkcioniranje programa ne ovisi toliko o izvođaču, koliko o pouzdanosti tehničkih sredstava i, a također predložiti kupcu niz strogih mjera za povećanje i.

Zahtjevi za osiguranje pouzdanog (održivog) rada programa

Pouzdan (održiv) rad programa mora se osigurati implementacijom skupa organizacijskih i tehničkih mjera od strane korisnika, čiji je popis naveden u nastavku:

• organizacija neprekidnog napajanja tehničkih sredstava;
• korištenje softvera;
• redovito provođenje preporuka Ministarstva rada i društveni razvoj RF, navedeno u Uredbi od 23. srpnja 1998. "O odobrenju međusektorskih standardnih normi vremena za održavanje osobnih računala i uredske opreme i održavanje softvera";
• redovito ispunjavanje zahtjeva GOST 51188-98. Zaštita informacija. Testovi dostupnosti softvera.

Na popis bi se mogli dodati još deseci. Tijekom početnog odobravanja projektnog zadatka, kupac će najvjerojatnije početi pokazivati ​​sklonost kompromisu.

Moguć je i humaniji pristup. Pod pouzdanošću (međutim, sustavi, prema istom GOST-u) može se smatrati izvedba određene i-te funkcije tijekom određenog vremenskog intervala. Ponudit ćemo kupcu da razmotri kriterij pouzdan rad Program ima sljedeći pokazatelj: korisnik otvori i zatvori datoteku 100 puta unutar sat vremena. Ako program ne uspije unutar navedenog vremenskog intervala, smatra se da su dovršeni.

Ako se naručitelj, konačno, uvjerio da pouzdanost ne ovisi toliko o izvođaču, koliko o pouzdanosti tehničkih sredstava i operativnog sustava, i odmahnuo rukom, u odjeljku treba napisati sljedeći izraz:

Ne postoje zahtjevi za osiguranje pouzdanog (održivog) funkcioniranja programa.

Vrijeme oporavka nakon kvara

Uzrokovano nestankom struje tehničkih sredstava (drugi vanjski čimbenici), a ne fatalnim kvarom (ne padom) operativnog sustava, ne bi trebalo prelaziti toliko minuta, podložno poštivanju hardvera i softvera. Vrijeme oporavka nakon kvara uzrokovanog kvarom hardvera, fatalnim kvarom (padom) operativnog sustava, ne bi trebalo premašiti vrijeme potrebno za uklanjanje hardvera i ponovnu instalaciju softvera.

Svitak hitnim slučajevima situacije također sastavlja kupac i usklađuje s izvođačem. Zapravo, ovo je vrijeme za ponovno pokretanje operativnog sustava, ako kvar nije fatalan, nije uzrokovan padom operativnog sustava ili kvarom tehničkih sredstava.

Kvarovi zbog pogrešnih postupaka operatera

Mogući su kvarovi programa zbog interakcije s operativnim sustavom. Kako bi se izbjegla pojava programskih kvarova iz gore navedenog razloga, potrebno je osigurati da korisnik radi bez pružanja administrativnih.

Uvjeti korištenja

Pododjeljak "Radni uvjeti" treba navesti (relativna vlažnost, itd. za odabrane tipove) pod kojima treba osigurati navedene karakteristike, kao i potreban broj osoblja [iz klauzule 2.4.3 GOST 19.201-78]

Vrlo opasan pododjeljak za one koji poduzimaju prve korake u izradi projektnog zadatka.

Klimatski uvjeti iskorištavanje

Klimatski uvjeti rada, pri kojima se moraju osigurati navedene karakteristike, moraju ispunjavati zahtjeve za tehničku opremu u pogledu njihovih radnih uvjeta.

Program će savršeno raditi od plus 5 do plus 35 °C pri relativnoj vlažnosti od 90% i atmosferski pritisak 462 mm Hg, budući da takvi uvjeti približno odgovaraju uvjetima rada modernih neindustrijskih računala. Ali čim je projektni zadatak konkretan i zadatak odobren, naručitelj dobiva izvrsnu priliku prisiliti izvođača da izvrši u potpunosti o trošku izvođača.

Prije mnogo godina, autor članka, zbog svoje mladosti i neukrotive želje da obrani svoju poziciju (osobito u projektnom zadatku), "upao je u klimatske promjene", hladno željezo. Autor članka odmah je naučio što znači "pokazati Kuz'kinovu majku" i "gdje rakovi hiberniraju". Ne daj Bože da se "na klimu"!

Bilješka od 10. veljače 2011. - Ironično, stručnjaci "Tehničke dokumentacije" ne tako davno ponovno su "upali u klimu", točnije, razvili su program i metodologiju za ispitivanje utjecaja vanjskih čimbenika i pripremili ga , otkrivajući još jednu za sebe. Nije ni čudo što kažu da se povijest razvija u uzlaznoj spirali ...

Zahtjevi za vrste usluga

Program ne zahtijeva držanje bilo koje vrste.

Vrste usluga treba posuditi iz pododjeljka "Zahtjevi za osiguranje pouzdanog (održivog) funkcioniranja".

Ukoliko se naručitelj prilikom ugovaranja projektnog zadatka pozove na odsutnost ili želju za obavljanjem svih vrsta usluga sami po sebi, ima smisla predložiti izradu tehničkih specifikacija za poseban novac u zasebnom ugovoru. Odbiti - trebali biste razmotriti program.

Zahtjevi za broj i osposobljenost osoblja

Minimalni broj osoblja potrebnog za rad programa treba biti minimalno 2 radna mjesta - administrator sustava i korisnik programa - operater.

Sistemski administrator mora imati višu stručnu spremu i proizvođača operativnog sustava. Popis zadataka koje obavlja administrator sustava trebao bi uključivati:

• poslovi održavanja tehničkih sredstava;
• poslovi instalacije (ugradnje) i održavanja operativnosti sistemskih programskih alata – operacijskog sustava;
• zadatak instaliranja (instaliranja) programa.

Korisnik programa (operator) mora imati praktične vještine u radu s operativnim sustavom.

Osoblje mora biti certificirano za kvalifikacijsku skupinu II iz električne sigurnosti (za rad s uredskom opremom).

U nedostatku same ključne fraze u odobrenom projektnom zadatku, naručitelj ima pravo zahtijevati od izvođača izradu priručnika za rad grafičkog korisničkog sučelja operacijskog sustava, pozivajući se na činjenicu da operater " ne nosi" s programom.

Osoblje koje nema II kvalifikacijsku skupinu za električnu sigurnost nema pravo ni približiti se uredskoj opremi.

Zahtjevi za sastav i parametre tehničkih sredstava

U pododjeljku "Zahtjevi za sastav i parametre tehničkih sredstava" navedite potrebni sastav s naznakom njihovih glavnih tehnički podaci[iz klauzule 2.4.4 GOST 19.201-78]

Treba ga odabrati ne lošije od onog na kojem će se odvijati razvoj. Logično je tražiti da naručitelj nabavi opremu najkasnije u navedenom roku. Riječ je o, naravno, o računalu.

Hardver mora uključivati ​​IBM kompatibilan Osobno računalo(PC), uključujući:

• procesor Pentium-1000 s frekvencijom takta, GHz - 10, ne manje;
• matična ploča s FSB, GHz - 5, ne manje;
• volumen RAM-a, TB - 10, ne manje;
• i tako dalje…

Zahtjevi za informacijsku i softversku kompatibilnost

U pododjeljku “Zahtjevi za informacije i kompatibilnost programa” trebaju biti naznačeni zahtjevi za informacijske strukture na ulazu i izlazu te rješenja koja koristi program.

Ako je potrebno, također ga treba osigurati [iz klauzule 2.4.5 GOST 19.201-78]

Zahtjevi za informacijske strukture i metode rješenja

Informacijska struktura datoteke mora uključivati ​​tekst koji sadrži specifikaciju rtf formata.

Nema zahtjeva za informacijske strukture (datoteke) na ulazu i izlazu, kao ni za metode rješavanja.

Zahtjevi za izvorne kodove i programske jezike

Izvorni kodovi programa moraju biti implementirani u C++. Okruženje Borland C++ Buider mora se koristiti kao integrirani program.

Zahtjevi za softver koji koristi program

Program koji koristi mora biti predstavljen licenciranom lokaliziranom verzijom operativnog sustava takav i takav. Dopušteno je primijeniti paket ažuriranja takav i takav.

Zahtjevi za zaštitu podataka i programa

Nema zahtjeva za i programe.

Takve zahtjeve treba izbjegavati ako nema posebne želje za razvojem nečega poput koncepta informacijske sigurnosti u skladu s Omogućite neku razinu i programe, sigurnost je nemoguća. Kupac je, najvjerojatnije, toga svjestan i neće biti uporan.

Zahtjevi za označavanje i pakiranje

U pododjeljku "Zahtjevi za označavanje i pakiranje", općenito, navedite zahtjeve za označavanje, mogućnosti i metode pakiranja [iz klauzule 2.4.6 GOST 19.201-78]

Program se isporučuje kao programski proizvod - na distribucijskom (eksternom) mediju (CD). Govorimo, naravno, o označavanju i pakiranju distribucije.

Zahtjev za označavanje

Softverski proizvod mora biti označen oznakom razvojne tvrtke, vrstom (nazivom), brojem verzije, serijskim brojem, datumom proizvodnje i brojem Državnog standarda Rusije (ako postoji). Označavanje se mora primijeniti na softverski proizvod u obliku naljepnice izrađene tiskarskim putem, uzimajući u obzir zahtjeve GOST 9181-74.

Kvaliteta oznake provjerava se na najsofisticiranije načine - prvo se oznaka pokušava isprati vodom, zatim benzinom i drugim organskim otapalima. Za nekvalitetno označavanje neka odgovara tiskara. Zadatak izvođača je sakriti se iza potvrde o sukladnosti (zatražiti potvrdu od tiskara).

Zahtjevi za pakiranje

Pakiranje softverskog proizvoda mora se izvršiti u spremniku za pakiranje ().

To je proizvođač (dobavljač). Izvođač ne može i ne smije snositi veću odgovornost od proizvođača (dobavljača) spremnika.

Uvjeti pakiranja

Pakiranje softverskog proizvoda mora se provoditi u zatvorenim ventiliranim prostorijama na temperaturi od +15 do +40 °C i relativnoj vlažnosti ne većoj od 80% u odsutnosti agresivnih nečistoća u okolišu.

Kupac će dobiti softverski proizvod ispravnog izgleda. U slučaju povrata softverskog proizvoda (softvera) u neprikladnom obliku (prisutnost ogrebotina, pukotina itd.), izvođač će moći podnijeti zahtjeve u vezi s kršenjem uvjeta pakiranja od strane kupca i ne prihvatiti softver proizvod.

Redoslijed pakiranja

Programski proizvodi pripremljeni za pakiranje stavljaju se u spremnik, koji je kutija izrađena od valovitog kartona (GOST 7376-89 ili GOST 7933-89) prema crtežima proizvođača spremnika.

Softverski proizvod pakiran je pomoću omota od vodonepropusnog filma uz obaveznu prisutnost kemijski neagresivnog sredstva za sušenje (silika gel).

Za punjenje slobodan prostor valovitog kartona ili stiropora stavljaju se u spremnik za pakiranje.

moraju biti smješteni u potrošačku ambalažu zajedno sa softverskim proizvodom.

Na gornji sloj materijal za amortizaciju je složen - popis pakiranja i popis pakiranja.

Potrošačka ambalaža mora biti zalijepljena ljepljivom trakom 6-70 prema GOST 18251-87.

Programske proizvode zapakirane u potrošačke spremnike treba staviti na paletu, vezati trakom kako bi se spriječio gubitak oblika tereta i pakirati u polietilensku foliju M 0,2 radi zaštite od vlage.

Dokumentacija o otpremi, uključujući popis pakiranja u skladu s GOST 25565-88, mora biti priložena u kutiji za palete.

Dimenzije paketa ne smiju biti veće od 1250 820 1180 mm.

NETO težina - ne više od 200 kg.

BRUTO težina - ne više od 220 kg.

Redoslijed pakiranja iz prethodno razvijenog dokumenta za neke tehnička sredstva. Izgleda pomalo neobično u kontekstu softverskog proizvoda. Govoreći jednostavnim ruskim, to je potpuna šala, ali postoje zahtjevi i ostaju zahtjevi.

Zahtjevi za transport i skladištenje

U pododjeljku "Zahtjevi za prijevoz i skladištenje", uvjeti, mjesta, uvjeti skladištenja, uvjeti skladištenja, u raznim uvjetima[iz klauzule 2.4.7 GOST 19.201-78]

Pododjeljak daje uvjete za prijevoz i skladištenje od prethodno izrađenog dokumenta do nekog tehničkog sredstva. Ovo se također odnosi na zahtjeve za pakiranje. Izgleda pomalo neobično u kontekstu softverskog proizvoda.

Kupac nema pravo kršiti uvjete prijevoza i skladištenja. Izvođač će moći odbiti vratiti softverski proizvod kupcu, s obrazloženjem da je neprikladan izgled softverski proizvod je posljedica nepoštivanja uvjeta prijevoza i skladištenja.

Uvjeti transporta i skladištenja

Dopušteno je transportirati softverski proizvod u transportnom kontejneru svim prijevoznim sredstvima (uključujući grijane stlačne odjeljke zrakoplova bez ograničenja udaljenosti). Kada se prevozi u željezničkim vagonima, vrsta pošiljke je mala, niskotonažna.

Tijekom transporta i skladištenja softverskog proizvoda, zaštita od ulaska i. Nije dopušteno naginjati softverski proizvod. Klimatski uvjeti prijevoza navedeni su u nastavku:

• temperatura okolnog zraka, °S - od plus 5 do plus 50;
• , kPa - takav i takav;
• relativna vlažnost na 25°C.

Posebni zahtjevi

Program mora osigurati interakciju s korisnikom () kroz, razvijen prema preporukama proizvođača operacijskog sustava.

Programeri ovog standarda gledali su u budućnost. Tih godina nije bilo programa s grafičkim korisničkim sučeljem.

Zahtjevi za softversku dokumentaciju

Odjeljak "Zahtjevi za dokumentaciju softvera" treba navesti preliminarni sastav i, ako je potrebno, posebne zahtjeve za njega [iz klauzule 2.5a GOST 19.201-78]

Preliminarni sastav programske dokumentacije

Programska dokumentacija treba sadržavati:

Program i metodologija testiranja bit će potrebni kako bi se kupcu pokazalo da program koji je izradio izvođač udovoljava zahtjevima dogovorenog i odobrenog projektnog zadatka. Nakon obavljenih zajedničkih (prijemnih) ispitivanja naručitelj i izvođač potpisuju. I, dakle, posao će biti zatvoren, uvjeti ugovora su ispunjeni.

Dopušteno je kombinirati određene vrste operativnih dokumenata (osim i). Potreba je naznačena u Spojenom dokumentu također se dodjeljuje oznaka jednog od spojenih dokumenata. Spojeni dokumenti moraju sadržavati informacije koje moraju biti uključene u svaki spojeni dokument [iz klauzule 2.6 GOST 19.101-77]

Ali za one koji su prvi put uključeni u razvoj softverske dokumentacije, bolje je pridržavati se načela "muhe odvojeno, kotleti odvojeno."

Tehnički i ekonomski pokazatelji

Odjeljak "Tehnički i ekonomski pokazatelji" treba navesti: procijenjenu ekonomsku, procijenjenu godišnju potrebu, ekonomske prednosti razvoja u usporedbi s najboljim domaćim i stranim uzorcima ili analogima [iz klauzule 2.5 GOST 19.201-78]

Procijenjena ekonomska učinkovitost nije izračunata. Očekivani broj korištenja programa godišnje je 365 radnih sati na jednom radnom mjestu.

Pretpostavimo da kupac programom opremi desetak radnih mjesta. Izvođač je tražio 1000 dolara za razvoj. Kupac je mogao instalirati softverski proizvod treće strane na radne stanice, po cijeni od 500 USD po kompletu za distribuciju i 100 USD po licenci za svaki radno mjesto.

Ekonomske koristi razvoja

Ekonomske prednosti razvoja u usporedbi s najboljim domaćim i stranim analogama bit će:

U fazi "Tehnički (i radni) projekt" moraju se završiti sljedeće faze rada:

• razvoj programa;
• izrada programske dokumentacije;
• testiranje programa.

U fazi "Implementacija" treba provesti fazu razvoja "Priprema i prijenos programa".

U fazi izrade projektnog zadatka potrebno je izvršiti sljedeće radove:

• formulacija problema;
• definiranje i pojašnjenje zahtjeva za tehnička sredstva;
• definiranje zahtjeva za program;
• određivanje faza, faza i rokova izrade programa i dokumentacije za njega;
• izbor programskih jezika;
• koordinacija i odobravanje projektnog zadatka.

U fazi razvoja programa, rad na (kodiranju) i.

U fazi razvoja programske dokumentacije, razvoj programskih dokumenata treba provesti u skladu sa zahtjevima GOST 19.101-77.

U fazi testiranja programa moraju se izvršiti sljedeće vrste radova:

• razvoj, koordinacija i odobravanje programa (u GOST-u, čini se, pogreška pri upisu - "narudžba") i metode ispitivanja;
• provođenje testova prihvatljivosti;
• prilagodba programa i programske dokumentacije na temelju rezultata ispitivanja.

U fazi pripreme i prijenosa programa mora se obaviti rad na pripremi i prijenosu programa i programske dokumentacije u pogon kod naručitelja.

Postupak kontrole i prijema

U odjeljku "Postupak kontrole i prihvaćanja" treba navesti vrste i opće zahtjeve za prihvaćanje rada [iz klauzule 2.7 GOST 19.201-78]

broj radnih mjesta		razvoj	ekonomske koristi

Vrste testova

mora se izvršiti u objektu kupca na vrijeme ...

Prijemna ispitivanja programa moraju se provesti u skladu s "Programom i metodama ispitivanja" koje je izradio (najkasnije do tog i tog datuma) izvođač i s kojima se složio kupac.

Napredak testova prihvaćanja dokumentiraju kupac i izvođač c.

Opći uvjeti za prihvaćanje posla

Na temelju izvješća o ispitivanju izvođač, zajedno s naručiteljem, donosi akt o prijemu i puštanju programa u rad.

Prijave

U prilozima projektnog zadatka po potrebi navesti:

• popis drugih radova koji potkrepljuju razvoj;
• dijagrami, tablice, opisi, opravdanja, izračuni i drugi dokumenti koji se mogu koristiti u izradi;
• drugi izvori razvoja.

[iz klauzule 2.8 GOST 19.201-78]

Ako postoji, zašto ne donijeti. I svakako sastavite popis GOST-ova na temelju kojih bi se trebao provesti razvoj. Na primjer:

• GOST 19.201-78. Projektni zadatak, zahtjevi za sadržaj i dizajn;
• i tako dalje..

zaključke

Ovaj standard, unatoč znatnoj starosti, omogućuje vam da razvijete punopravni projektni zadatak za moderan program s grafičkim korisničkim sučeljem. Programeri GOST 19.201-78 gledali su u budućnost i uzeli u obzir gotovo sve aspekte vezane uz razvoj softvera.

Što je ostalo neobjašnjeno? Uvjeti, obujmi i faze financiranja? Projektni zadatak uvijek se izrađuje na temelju Ugovora, pisama itd. Navedene informacije moraju biti sadržane u Ugovoru.

Koje su točke prijepora? Nedostatak posebnih zahtjeva u standardu, na primjer, za korisničko sučelje? Programeri standarda osiguravaju odjeljak "Posebni zahtjevi", mogućnost dodavanja novih odjeljaka, na primjer, odjeljaka "Dodatni zahtjevi" ili "Zahtjevi za sučelje".

• GOST 19.201-78 Jedinstveni sustav programske dokumentacije. Tehnički zadatak. Zahtjevi za sadržaj i dizajn

Projektni zadatak je važan i za izvođača i za naručitelja. Pomaže izvođaču da bolje razumije što kupac želi, da se osigura od iznenadnih "želja" od strane klijenta, da ubrza rad na zadatku. Klijentu - reći točno što želi, pojednostaviti kontrolu kvalitete, dobiti točnu cijenu usluge. Reći ćemo vam kako pravilno sastaviti TOR i što s njim kasnije.

Što je tehnički zadatak

Projektni zadatak - dokument koji odražava sve zahtjeve za budući proizvod. Opisuje sve tehničke zahtjeve. Obično se TK sastavlja u obliku tekstualnog dokumenta, rijetko u drugim formatima.

TK koriste svi programeri web stranica. Slagačima, programerima, dizajnerima pomaže da bolje razumiju zahtjeve klijenta i naprave resurs koji ispunjava njegova očekivanja. Osim toga, TZ se koristi iu svim drugim oblastima, npr. u:

• razvoj aplikacija;
• dizajn kuće;
• pisanje tekstova i dr.

Ako radite u skladu s projektnim zadatkom, rizik od sporova i dugotrajnih sudskih sporova sveden je na minimum.

Kako sastaviti tehnički zadatak: struktura tehničkih specifikacija za stranicu

Prije početka rada:

• Odlučite tko će napisati projektni zadatak
• Objasnite pojmove
• Izbjegavajte subjektivne termine

Na prvi pogled se čini da tehničke specifikacije za stranicu treba izraditi naručitelj, jer on naručuje resurs i postavlja zahtjeve prema njemu. Zapravo, oboje bi trebali sudjelovati u procesu: klijent izgovara zahtjeve, a izvođač ih zapisuje konkretno, točno i jasno. Na primjer, klijent kaže da želi stranicu prilagođenu svim korisnicima, a programer propisuje zahtjeve prilagodljivosti za 4 dostupne veličine - računala, prijenosna računala, tableti, pametni telefoni.

Objašnjenje pojmova - vrlo važna točka . Preporučljivo je objasniti sve usko specijalizirane pojmove na samom početku - klijenti ne znaju uvijek što je podrum (footer), CMS, riba. Što su objašnjenja jednostavnija i jasnija, to će TOR biti jasniji za obje strane.

Subjektivni pojmovi mogu izazvati nepotrebne polemike. Nemojte pisati "dizajn bi trebao biti lijep" - koncept ljepote je drugačiji za svakoga. Isto vrijedi i za pridjeve kvalitete “praktičan”, “jednostavan za korištenje”, “velik”. Koristite određene brojeve i parametre: na primjer, opišite shemu boja ili raspored elemenata.

Struktura tehničkog zadatka može biti bilo koja. Kao primjer nudimo jednostavnu strukturu TOR-a za stranicu.

Opišite mjesto

Recite nam koju vrstu stranice trebate, tko će je koristiti, za što je stvorena. Na primjer, napišite da vam je potrebna internetska trgovina, odredišna stranica za prodaju proizvoda ili web-stranica posjetnica s 10 stranica. Navedite okvirni broj stranica ako ne znate točan broj.

Ako projekt ima određenu ciljanu publiku, opišite je. To će pomoći u stvaranju resursa koji će se svidjeti korisnicima - na primjer, korištenjem odgovarajućeg jezika u člancima ili dizajnom koji se sviđa mladima ili starijim ljudima.

Reci mi nešto o strukturi

Bez razumijevanja strukture, nemoguće je razviti normalno mjesto. Opišite koje će stranice biti na web-mjestu i pokažite njihove razine ugniježđenja. To možete učiniti na različite načine:

• shema
• stol
• popis

Glavna stvar je da je na kraju jasno koje će se stranice nalaziti u izborniku, gdje će voditi, koju nadređenu stranicu ima svaki odjeljak. Preporučamo korištenje dijagrama toka - oni su jednostavniji i lakši za čitanje od popisa i tablica, pomažu u procjeni cijele strukture stranice u nekoliko sekundi.

Primjer najjednostavnije strukture u obliku blok dijagrama

Opišite što će biti na svakoj stranici

Recite nam kako vidite stranice stranice. Poželjno je to učiniti u formatu prototipa kako bi se jasno prikazalo mjesto svakog elementa. Zahtjeve možete opisati popisom, na primjer, reći što će biti u zaglavlju stranice na kojoj se nalazi obrazac Povratne informacije, koji će biti u besplatnoj bočnoj traci.

Ako su sve stranice web-mjesta približno slične - na primjer, planirate stvoriti web-mjesto s posjetnicama, možete se snaći s dva prototipa: za glavnu stranicu i druge odjeljke. Ako postoji nekoliko grupa sličnih stranica - na primjer, odjeljci u katalogu internetske trgovine, blog s člancima i opisom usluga isporuke / montaže / instalacije, bolje je napraviti vlastiti prototip za svaku grupu.

Primjer prototipa glavne stranice web mjesta: sve je jednostavno, praktično, razumljivo

Postavite zahtjeve za dizajn

Ako postoji razvijen izgled, super - možete ga jednostavno umetnuti u projektni zadatak. Ako ne, morate zapisati zahtjeve za Shema boja korištene slike, logotipi. Na primjer:

• Navedite koje se korporativne boje mogu koristiti u dizajnu, a koje nijanse apsolutno ne
• Navedite logotip koji mora biti prisutan u zaglavlju stranice
• Navedite fontove koje želite koristiti za dizajn stranica, izbornika, podnožja, sadržaja

Ako nema jasnih zahtjeva - to jest, sam klijent ne može formulirati svoju viziju web mjesta, možete mu ponuditi nekoliko standardnih izgleda na izbor ili samostalno razviti izgled, a zatim se složiti s njim. To se mora učiniti prije odobrenja TOR-a, inače razlika u ukusima može značajno odgoditi projekt.

Opišite zahtjeve za alate, kod, hosting, domenu

Ovo je neophodno kako biste unaprijed znali s kojim alatima možete raditi, a s kojima ne. Opišite u zasebnom bloku:

• Na kojoj stranici treba biti - WordPress, Joomla, Modex i tako dalje
• Koji se programski jezik može koristiti - PHP, JavaScript, HTML, drugi
• Na kojem hostingu iu kojoj domenskoj zoni treba biti smještena stranica, koji naziv domene se može koristiti
• Koja se softverska platforma može koristiti - .NET, OpenGL, DirectX
• I tako dalje

Ako klijent ništa ne razumije u korištenim terminima, objasnite po čemu se WordPress razlikuje od Modexa, PHP od HTML-a, domena u .ru zoni od domene u .com zoni. Zajedno napravite zahtjeve tako da odgovaraju klijentu.

Navedite zahtjeve za mjesto

Prema zadanim postavkama, stranica bi trebala raditi za korisnike svih uređaja, u različitim preglednicima, izdržati hakerske napade i ostati budna kada 1000 korisnika posjeti u isto vrijeme. Ali bolje je to napisati u zasebnom bloku. Navedite:

• Prihvatljiva brzina učitavanja stranice za vas ili standardna vrijednost - 1–5 sekundi
• Kompatibilnost s više preglednika - opišite u kojim preglednicima se stranica treba otvoriti
• Responzivnost - odredite veličine zaslona kojima se dizajn treba prilagoditi i uređaje koji se koriste
• Otpor opterećenja - koliko ljudi treba biti na mjestu u isto vrijeme kako ne bi "ležao"
• Otpornost na hakerske i dDos napade: stranica mora izdržati male napade

Napišite scenarije za mjesto

Opišite kako bi korisnik trebao komunicirati sa web mjestom i koje bi se akcije trebale dogoditi na resursu kao odgovor. To se može učiniti u obliku jednostavnog numeriranog popisa ili razgranatog algoritma ako korisnici imaju izbor između radnji. Ako postoji mnogo interaktivnih usluga, napišite skriptu za svaku od njih.

Primjer najjednostavnijeg scenarija stranice

Saznajte tko radi sadržaj.

Neki programeri sami pišu tekstove, netko ih naručuje od copywritera, netko koristi ribu. Odmah razjasnite je li pružanje sadržaja uključeno u uslugu razvoja. Ako da, možete odmah pisati Dodatni zahtjevi, na primjer, za:

• - ne manje od 95% prema Advego, Text.ru, Content.Watch
• Mučnina (spam) - ne više od 10% prema Advego ili 65% prema Text.ru
• Bodovi za Glavred - najmanje 6,5 ili 7 bodova

Naravno, različite usluge nisu lijek za sve, ali minimiziraju rizik da će biti "vodenast" ili spamiran. Osim toga, tako se pojavljuju točni kriteriji za ocjenu kvalitete tekstova.

Navedite uvjete

To se često zaboravlja. Većina projektnih zadataka mora specificirati termine, inače se razvoj može otegnuti nekoliko mjeseci, pola godine, godine. Nemojte koristiti netočne riječi - na primjer, "za mjesec dana." Napišite točan datum: npr. 1. prosinca 2018.

Life hack: bolje je izraditi projektni zadatak kao dodatak ugovoru o suradnji. Tako popravljate sve zahtjeve za razvoj stranice, au slučaju sporova možete dobiti slučaj na sudu.

Zapamtite: u svakom TK treba postojati nekoliko glavnih blokova:

• Ciljevi - o tome zašto ste uopće stvorili TK, što želite učiniti s proizvodom
• Kakav bi trebao biti proizvod - općeniti opis
• Tehnički zahtjevi- područje kuće, volumen teksta, funkcionalnost aplikacije i tako dalje
• Rokovi - važni su za otklanjanje sporova.

Primjer izrade tehničke specifikacije softvera

Moramo stvoriti softver. Tehnički zahtjevi - ispod.

Opis: program za pretraživanje članaka po ključnoj riječi na svim mjerodavnim stranicama, potrebno je ručno unijeti adrese mjerodavnih stranica.

Što softver treba učiniti:nakon ulaska ključna riječ pronalazi članke na stranicama koje su unaprijed unesene kao vjerodostojni izvori, prikazuje popis podudaranja u ovom formatu:

• Veza
• Naslov članka
• Glavni paragraf

Ako postoji više od 10 podudaranja, trebate podijeliti na stranice - po 10 na svakoj.

Tehnički zahtjevi:programski jezik - bilo koji, nije bitno. Najvažnije je da se program tada može finalizirati i predstaviti kao online usluga. Idealno bi bilo da usluga traži 10 sekundi.

Vrijeme: do 15.09.2018.

Naravno, ovaj TOR se može poboljšati - dali smo ga kao primjer. I kako mislite, kako poboljšati projektni zadatak da bude još jasniji, jednostavniji, praktičniji?

Što je tehnički zadatak? Kako to učiniti i zašto je to potrebno? Primjeri, uzorci, savjeti i trikovi.

Čini se kako je sjajno kada vas savršeno razumiju. Izrekao je nekoliko rečenica i evo ga, upravo ono što ste zamislili. Nažalost, to tako ne ide.

Problem percepcije informacija je vječan. Efekt "pokvarenog telefona" je česta pojava. A što reći ako jednostavno ne znate kako postaviti zadatak? Da, i to se događa i s tim se morate nekako riješiti, ali kako? Kako bi rezultati zadataka koje ste postavili ispunili vaša očekivanja, napišite projektni zadatak.

Što je tehnički zadatak

Projektni zadatak (ili TOR) - dokument koji sadrži zahtjeve kupca za proizvode ili usluge koje pruža izvođač. Jednostavnim riječima: Želim tako i tako da postoji sedam međusobno okomitih linija, pa čak i neke crvene, a neki bezbojni crtež (video o ovoj temi na kraju materijala, savjetujem vam da ga pogledate).

Odjel dizajna

Ovaj dokument može zauzimati jednu A4 stranicu ili cijeli tom, sve ovisi o zadacima i željama koje sadrži. Na primjer, možete napisati tehnički zadatak za malu odredišnu stranicu (mjesto s jednom stranicom) ili za složenu softver sa strojnim učenjem i drugim trikovima.

Zašto vam je potreban tehnički zadatak

• Postaviti zadatak izvođačima.
• Da detaljno opišete što želite dobiti na kraju.
• Da se dogovorimo o redoslijedu rada.
• Ocijeniti i prihvatiti rad nakon implementacije.
• Za ... (dodajte svoje opcije u komentarima).

Zapravo, ima mnogo više termina i prednosti tehničkog zadatka nego na gornjem popisu. Meni osobno glavni zadatak koji TK rješava je implementacija onoga što mi treba, uz minimalna odstupanja od očekivanja (mojih očekivanja).

Zahvaljujući TK uvijek se možete raspitati o vremenu, novcu i usklađenosti s deklariranim karakteristikama finalnog proizvoda ili usluge.

Zapravo, ovo je ozbiljan dokument koji sastavljaju naručitelj i izvođač. Sve do toga da su propisane kazne i obveze stranaka. Postoji niz GOST-ova, pročitajte više na Habréu.

Izrada tehničkih specifikacija

Ako govorimo o igrici “na odrasli način”, na primjer, projektnom zadatku za izradu mobilne aplikacije ili web stranice, onda je to zaseban posao za koji se plaća puno novca. Dovedete osobu, obično bivšeg ili sadašnjeg tehničkog direktora, i zamolite je da vam pomogne.

Brada nije obavezna

Ovisno o obujmu projekta/zadataka, ova osoba prikuplja sve vaše “liste želja”, prevodi ih na tehnički jezik, možda priprema skice (kako bi to otprilike trebalo izgledati) i daje vam gotov dokument. Zatim taj dokument prenesete na izvođače (tim unutar vaše tvrtke ili za outsourcing), dogovorite novac, uvjete i bacite se na posao.

Savjet: CTO mora biti u vašem timu, inače najvjerojatnije nećete primijetiti nešto u procesu implementacije. Jednostavno nemate dovoljno znanja za sve. Tko je učestvovao u pisanju TK, on ​​provjerava.

Što je specifikacija

Sve će ovisiti o predlošku koji odaberete (kasnije ću dati neke veze na predloške/primjere), ali postoje osnovni blokovi koji su uključeni u projektni zadatak:

1. Opis projekta/zadatka. Ukratko napišemo kakav projekt ili zadatak treba izvršiti.
2. Svrha i ciljevi. Koji su ciljevi projekta.
3. Zahtjevi. Dizajn, karakteristike, tehnologije koje su potrebne.
4. Opis radova. Što, kada i kako će se raditi.
5. Postupak kontrole i prijema. Kako će posao biti prihvaćen, što se može smatrati završenim.
6. Prijave. Skice, skice, prototipovi.

Troškovi radova obično se izdvajaju posebnim aneksom ugovora, ali to se događa kada strane ugovore iznose u samom projektnom zadatku.

Oprostite što vas prekidam u čitanju. Pridružite se mom telegram kanalu. Svježe najave članaka, razvoj digitalnih proizvoda i grow hack, sve je tu. Čekam te! Nastavljamo ...

Primjeri projektnih zadataka

Unatoč činjenici da je razvoj tehničkih specifikacija složen proces, ali vrlo zanimljiv. Vaš zadatak je ponovno stvoriti sliku konačnog rezultata, a zatim ga opisati u dijelovima.

Primjer jedne od mojih tehničkih specifikacija za ažuriranje Smart TV aplikacije. Zadaci za složenije i kompleksnije proizvode već su sastavljeni uz pomoć kolega iz tehničkog odjela. Slobodno zatražite pomoć od svojih suradnika, uključite ih što češće u proces. I ne zaboravite dati povratne informacije! Nema ništa gore od ulaganja vremena i truda u nešto bez znanja o rezultatima. Recite nam kako vam je savjet te osobe bio koristan u radu, inače je to jednostrana igra.

Projektni zadatak za razvoj internet trgovine

Projektni zadatak za izradu mobilne aplikacije

TK na mjestu

ToR za usluge/ažuriranja

Ako trebate više uzoraka, samo guglajte.

Glavna preporuka je da to učinite. Nevolja je u tome što majčina lijenost svakoga svlada i nije joj se lako oduprijeti. Skupite svu volju u šaku i počnite pisati projektni zadatak, samo pišite i nemojte stati. Ne brinite da neće uspjeti "savršeno", otkrit ću vam tajnu, to se ne događa. Samo pišite, svaki put će biti sve bolje i bolje.

Tako i treba biti

Moji prvi začeci pisanja tehničkih specifikacija počeli su se pojavljivati ​​prije nekoliko godina. Radio sam s dizajnerima i postavio sam zadatak izrade kreativa za reklamne kampanje. Nesuvisli to žele i to se pretvorilo u hrpu izgubljenog vremena i objašnjavanja. S vremenom se postavljanje zadataka počelo pretvarati u nekakve semantičke blokove, a zatim u svojevrsni tehnički zadatak.

Na primjer, za zadatak "gumb Sviđa mi se na web mjestu":

1. Opis: Morate stvoriti gumb "Sviđa mi se" na našoj web stranici.
2. Svrha i ciljevi: uključivanje korisnika, izdavanje / ocjenjivanje materijala prema broju lajkova.
3. Zahtjevi: takav dizajn (primjer: poveznica na nešto slično), funkcionalnost (svaki korisnik može ocijeniti sliku i lajkati je, sustav stranice uzima u obzir broj lajkova i mijenja izlaz materijala), tehnologija (dostupna na desktop i mobilne verzije stranice).
4. Opis rada: nacrtati 3 opcije za izgled gumba (datum završetka: 01.10.17.), razviti sustav za izdavanje materijala lajkovima (datum: 14.10.17.), testiranje funkcije (datum: 16.10.17.) , izdanje (datum: 17.10.17.)
5. Prijem radova: korisnik klikne na gumb like, sustav broji klik, isporuka materijala se mijenja.
6. Primjene: skice, skice, primjeri projekata u kojima radi slična funkcija.

Ostavite za sebe one dijelove i dijelove strukture koji su potrebni za vaše zadatke. Na primjer, šesti blok "Aplikacije" može se opisati u funkcionalnim zahtjevima. Glavni savjet: na ovaj ili onaj način opišite zadatak prema strukturi projektnog zadatka. Tako nećete propustiti važne trenutke i spasiti sebe nepotrebnih pitanja, a svojim kolegama olakšati život.

Izvoli

Analizirali smo što je tehnički zadatak i kako ga napraviti. Sada imate mogućnost jasnog i jasnog postavljanja ciljeva, komuniciranja svojih misli s drugim ljudima i uštedjeti vrijeme za dodatna objašnjenja. Nadam se da sada znaš što ćeš sa svim ovim.

Pitanje "Je li uopće potrebno izraditi tehnički zadatak (TOR)?" može nastati samo za one koji nikada u životu nisu naručili izradu stranice, budući da se potreba za tim javlja nakon prve komunikacije između kupca i izvođača.

TK je dokument koji opisuje budući projekt detaljan i potpun. Što je detaljniji, točnije će se ideja implementirati i manje će se sukobi i sporovi pojaviti tijekom provedbe projekta, jer se apsolutno sve može učiniti na različite načine. Možete se pozvati na njega ako nešto nije učinjeno ili je učinjeno pogrešno ili su napravljene druge pogreške. Prije početka radova naručitelj obično opisuje budući projekt u obliku diplomskog rada ili ispunjava brief, a izvođač sve te zahtjeve i želje formalizira, po potrebi predlaže prilagodbe. U isto vrijeme, kupac mora biti siguran da je sva njegova "Lista želja" fiksirana u tim zadacima.

Ako se s web studijem ili freelancerom sklopi ugovor o izradi stranice, tada taj zadatak najčešće dolazi kao prilog. I u kontroverznim situacijama vode se onim što tamo piše.

Od čega se sastoji TK?

Pretpostavimo da je u okviru projekta potrebno izraditi tehnički zadatak za izradu web stranice studija za pisanje teksta Pero. Koje stavke treba sadržavati?

Opće informacije (opis)

Ovdje su naznačeni:

Informacije o tvrtki. opće informacije o studiju, čime se bavi. Neće biti suvišno navesti popis pruženih usluga. Ovdje također možete dodati adresu buduće stranice, kontakt podatke.

Faze i rokovi provedbe projekta. Vrlo važna točka, u pravilu, kalendarski plan jer se sve faze rada sastavljaju na samom kraju. Ovaj dio daje razumijevanje što će se učiniti i kada. Na primjer (s datumima):

• Pripremna faza;
• Razvoj koncepta web stranice;
• Oblikovati;
• Izrada dizajna izgleda;
• Razvoj dizajna stranice;
• Raspored;
• Programiranje;
• Sadržaj punjenja;
• SEO optimizacija;
• Testiranje;
• Pokreni.

Možda neće biti nikakvih faza, na primjer, SEO promocija. Ovisi o ciljevima i ciljevima naručitelja i kompetencijama izvođača.

Svrha i ciljevi

Ovdje je formulirano koje će funkcije stranica obavljati i kome je namijenjena.

Svrha stranice. Koji su ciljevi izrade stranice za postizanje? Čemu služi, koje zadatke rješava?

• Oglašavanje i privlačenje novih kupaca;
• Podrška kupcima i partnerima;
• Demonstracija obavljenog posla;
• Upoznavanje s popisom usluga;
• Stvaranje i održavanje imidža tvrtke.

Možda bi neke točke trebalo detaljnije opisati. Na primjer, ako je stranica suočena sa zadatkom informiranja posjetitelja, bolje je objasniti što točno.

Ciljana publika. Tko će koristiti stranicu, za koga je kreirana?

• Webmasteri, blogeri;
• Vlasnici internetske trgovine;
• Vlasnici informativnih portala;
• Oglasni studiji;
• Predstavnici firmi i tvrtki prisutni u online prostoru.

Zahtjevi

Velik i iznimno važan odjeljak, koji uzima u obzir što više aspekata dizajna i razvoja, jer će kupac morati dodatno platiti za funkcionalnost koja nije navedena u TOR-u.

Tip. Kojoj kategoriji pripada web resurs?

• Odredišna stranica;
• Stranica posjetnica;
• Korporativna web stranica;
• Informativni portal;
• Internet trgovina.

Zahtjevi za dizajn. Mogu biti sljedećeg oblika:

• Stranica bi trebala biti minimalistička i istovremeno odražavati vrstu djelatnosti tvrtke.
• Primarne boje: zelena i bijela, prema brand booku ili prema nahođenju dizajnera.
• Animacije, skočni prozori, Flash-elementi, dizajnerski ekscesi ne mogu se koristiti u dizajnu.
• Serif fontovi se ne mogu koristiti (mogu se koristiti standardni fontovi: Verdana, Arial, Tahoma itd.). Veličina treba omogućiti maksimalnu čitljivost (12-16 pt.).

Kada je riječ o zahtjevima dizajna, mogu se primijeniti različiti pristupi. Ako sam kupac točno zna što želi dobiti, tada detaljno opisuje svoje želje, daje primjere stranica koje mu se sviđaju i daje druge specifičnosti. Ali ponekad se dogodi da ni on sam ne zna točno kako bi sve to trebalo izgledati, u ovom slučaju obično polaze od zadataka koje dizajn treba riješiti. Izvođač razvija koncepte, predlaže rješenja, brani svoju ideju i korigira je prema primjedbama naručitelja. Druga opcija je skuplja i zahtijeva više kvalifikacija izvođača.

Jezični zahtjevi. Koji će materinji jezik moći posjetiti resurs? Koje bi jezične verzije stranice trebale biti?

• Ruski;
• Engleski;
• Esperanto.

Zahtjevi kompatibilnosti. S kojih će se uređaja i preglednika stranica ispravno otvoriti? Nedavno je postojao trend prema prilagodljivom izgledu, kada se stranica ispravno prikazuje na bilo kojem uređaju s bilo kojim omjerom slike i razlučivosti zaslona. Ovdje možete navesti preglednike s kojima resurs mora biti jedinstveno kompatibilan. Obično se na svim modernim preglednicima stranice prikazuju na isti način, samo postoje problemi sa starijim verzijama Internet Explorera.

Zahtjevi za CMS. Mogućnosti administracije stranice određuju koji se blokovi mogu uređivati ​​i konfigurirati putem upravljačke ploče, bez uplitanja u kod i bez izravnog uređivanja baze podataka, ali koristeći prikladno vizualno sučelje. Na primjer, možete to postaviti ovako:

• Mogućnost promjene sadržaja na stranicama web stranice;
• Mogućnost upravljanja stranicama (dodavanje, preimenovanje, brisanje, itd.);
• Mogućnost uređivanja strukture stranice i stavki izbornika;
• Funkcije za automatsku obradu grafike (stvaranje pregleda, transformacija na zadanu veličinu, itd.);
• Mogućnost propisivanja jedinstvenih Meta oznaka;

Kao iu drugim pododjeljcima, morate opisati sve zahtjeve i želje.

Često kupac već ima iskustva s nekim od popularnih CMS-ova, tada je preporučljivo potražiti izvođače za određeni motor. Također, pri odabiru CMS-a, bolje je ne zadovoljiti se rješenjima koja ste sami napisali, jer. U budućnosti će to ovisiti o izvođaču. Samostalni motori, po mom mišljenju, opravdani su samo u vrlo velikim projektima gdje je potrebna specifična funkcionalnost ili optimizacija velikih opterećenja.

Struktura i navigacija. Koje će dijelove, pododjeljke i pojedine stranice sadržavati projekt?

• Glavna stranica
• Usluge

• Pisanje teksta
• Prepisivanje
• SEO copywriting
• korektura
• transkripcija
• Upravljanje sadržajem
• Sadržajni marketing

• Portfelj
• O nama
• Kontakti

Učinite i Kratki opis svakoj stranici dajte definicije. Na primjer, što se podrazumijeva pod stranicom "Kontakt"? Treba li sadržavati adresu, telefon i e-mail u tekstualnom obliku? Ili bi trebao postojati obrazac za povratne informacije? Ili možda trebate ugraditi kod Yandex Maps? Ili bi kontakt stranica trebala sadržavati sve navedeno, pa čak i poveznice na predstavljanja na društvenim mrežama?

Prije početka radova s ​​izvođačem poželjno je pripremiti sadržaj ili barem njegov nacrt. To će omogućiti učinkovitiju komunikaciju.

Dodatni zahtjevi. Sve što nije uključeno u druge paragrafe odjeljka.

Opis odjeljaka stranice

Ovaj stavak sadrži detalje. Obično je sadržaj svih jedinstvenih stranica potpisan: koji će elementi biti tamo, kako će korisnik s njima komunicirati.

Glavna stranica. Formulacija problema može biti u sljedećem obliku.

Glavni dio glavne stranice trebao bi biti napravljen u obliku Landing Page-a. Treba sadržavati sljedeće elemente od vrha do dna:

• Šešir - logo, naziv tvrtke;
• Navigacijski izbornik;
• Informacije o promocijama i popustima;
• gumb za narudžbu;
• Reklamni tekst;
• Blokirajte s pet najbolja djela i poveznicu na dio portfelja;

Pri razvoju bilo kojeg projekta. Kako se priprema ovaj dokument? O tome će se raspravljati u članku.

Tehnički zadatak - što je to?

Prije nego što se bilo koji projekt može započeti, prvo se mora sastaviti plan. Izgradnja, poduzetništvo, stambeni poslovi - apsolutno svako radno područje zahtijeva izradu odgovarajućeg plana. U isto vrijeme, uopće nije važno koliko je težak ili ozbiljan ovaj ili onaj posao. Razvoj tehničkog zadatka i, zapravo, običnog akcijskog plana, ovdje je ključna faza.

Projektni zadatak potreban je objema stranama tijeka rada odjednom: i izvođaču i naručitelju. Često između ove dvije osobe dolazi do svađa, sukoba i nesporazuma. Dobro osmišljen akcijski plan pomoći će striktno regulirati sve obveze svake strane.

Zašto tehnički zadatak kupcu?

Kao što je već spomenuto, izrada projektnog zadatka neophodan je proces koji je koristan za obje strane. ugovor o radu. Međutim, sada vrijedi razgovarati o tome zašto je dostavljeni dokument potreban izravnom kupcu.

Najvažnija stvar koja se može primijetiti je činjenica da projektni zadatak razvija samo kupac. Ovo je svojevrsni akcijski plan, ugovor o pružanju usluga. Uz pomoć ovog dokumenta izvođači mogu jasno definirati svoje radne funkcije, kao i što se točno od njih traži. Dokument koji se razmatra uvijek treba biti izrađen vrlo kvalitetno i pažljivo. Dakle, kupac mora uzeti u obzir sve glavne teze i točke, a također izbjegavati kontradiktorne trenutke. Ako je dokument ispravno sastavljen, kupac će uvijek moći ukazati nezadovoljnom izvođaču na određenu klauzulu ugovora.

Zašto tehnički zadatak izvođaču?

Izvođač dobiva uzorke tehničke specifikacije prije početka izvođenja pojedinog posla. Radnik je dužan pažljivo pročitati sve točke koje se nalaze u dokumentu. Ovaj korak pomoći će u izbjegavanju manipulacije kupca. Dakle, mnogi šefovi mogu od zaposlenika zahtijevati nešto što nije navedeno u opisu posla.

Izvođač mora razjasniti sve potrebne točke i iznos plaćanja. Dakle, vrijedi paziti da se gotovinska plaćanja odnose samo na one točke koje su navedene u dokumentu. Inače, nepažljivi izvođači mogu raditi besplatno.

Stoga bi izvođač trebao što češće paziti na ogledni projektni zadatak. To će mu pomoći da izbjegne nepotrebne probleme i nesporazume.

Pokretanje dokumenta

Gdje da počnem ispunjavati dokument? Projektni zadatak za obavljanje poslova uvijek treba započeti općim odredbama i ciljevima. Što je uključeno u opće odredbe? Prvo, mali rječnik. Naravno, to nije preduvjet. Međutim, ako je dokument usko fokusiran i stoga prepun specifične terminologije, onda je još uvijek vrijedno popraviti mali rječnik. U svakom slučaju, ovo će biti još jedan korak ka međusobnom razumijevanju između naručitelja i izvođača. Drugo, opće odredbe moraju sadržavati podatke o ugovornim stranama.

Što je uključeno u ciljeve tehničkog zadatka? Vjerojatno je lako pogoditi. Dakle, potrebno je ukratko naznačiti kakav se projekt razvija, zašto je potreban i kako se može postići konačni rezultat. Sve zadatke i ciljeve treba opisati što detaljnije i jasnije. Ovaj pristup pomoći će uspostaviti međusobno razumijevanje između ugovornih strana.

Zahtjevi i rokovi

Svakako, svaki projektni zadatak za obavljanje poslova mora sadržavati određene zahtjeve, kao i jasno utvrđene rokove. S vremenom je sve relativno jasno. Iako je vrijedno napomenuti da je bolje uzeti vrijeme s određenom marginom. Osim toga, brzina izvršenja naloga ne bi trebala utjecati na kvalitetu. U slučaju da izvođač prekrši utvrđene rokove za izvođenje, ugovor mora sadržavati određene sankcije za ovaj slučaj.

Što možete reći o zahtjevima? Kupac mora zapamtiti da su svi zahtjevi podijeljeni u dvije glavne vrste: posebne i funkcionalne. Funkcionalni zahtjevi su u određenoj mjeri ilustrativni, figurativni. To su određene slike, elementi, skice onoga što bi kupac želio vidjeti. Posebni zahtjevi su strogo regulirani, ukazujući na određene zadatke i metode izvršenja. Naravno, posebni bi trebali uvelike prevladavati. Inače, izvođač možda jednostavno ne razumije u potpunosti što točno žele od njega.

Odgovornost i izvješćivanje

Vrijedno je reći nešto više o dva najvažnija elementa koja bi trebao sadržavati apsolutno svaki uzorak tehničkih specifikacija. Riječ je o odgovornosti stranaka i odgovornosti. Što je svaki od ovih elemenata?

Poželjno je izvješćivanje generirati u fazama, posebno ako su projektni zadaci veliki. Čim se završi određena faza rada, mogu se podnijeti (obavezno) izvješća. Osim toga, takav sustav omogućuje održavanje izvođača u dobroj formi. U suprotnom, on može učiniti sve u zadnji trenutak, i stoga, izuzetno loše kvalitete.

Što reći o odgovornosti stranaka? Treba odmah napomenuti da takva stavka nije obavezna. Međutim, mnogi korisnici još uvijek smatraju potrebnim regulirati glavne vrste novčanih kazni, kazni i sankcija za razne prekršaje. Preporučljivo je naznačiti glavne elemente odgovornosti u dokumentima kao što su projektni zadaci za nabavu, transport itd.

Izrada projektnog zadatka

Svaki tehnički zadatak (za opskrbu, izgradnju, prijevoz itd.) Mora biti izrađen vrlo kompetentno i visokokvalitetno. To je prije svega potrebno kako u budućnosti ne bi bilo parnica, sporova i sukoba zbog nesporazuma između stranaka. I drugo, zbog jednostavne praktičnosti. Nije svaki kupac u stanju kompetentno sastaviti tehnički zadatak. Često se za ovaj slučaj angažiraju odvjetnici, iako to nema previše smisla.

Zapamtite samo nekoliko jednostavnih pravila:

• ugovor mora biti detaljan i detaljan (međutim, ne biste trebali pretjerivati; malo je vjerojatno da će barem jedan izvođač htjeti pročitati višetomne komentare o zahtjevima);
• ugovor mora biti jasan, bez vode i nepotrebnih podataka;
• zadatak ne bi trebao biti neka vrsta dogme; Vrijedi podsjetiti da je ovo samo naznaka, iako strogo regulirana - radi li se o tehničkom zadatku za održavanje ili o sadnji drveća.

Svi gore navedeni savjeti samo su mali dio onoga što bi se moglo reći. Ipak, kupcima još uvijek možete dati nekoliko uputa. Dakle, projektni zadatak (za održavanje ili izgradnju) može se izraditi prema predlošku. U ovom slučaju nije potrebno uzeti ovaj predložak odnekud; Dakle, ako je pisanje ugovora o pružanju usluga prilično uobičajena dužnost, onda neće biti tako teško izgraditi nekoliko klišeja za sebe.

Vrijedno je podsjetiti koliko je važno provjeriti standarde: bilo da se radi o GOST-u, regulatornim ili pravnim aktima, lokalnim aktima itd.