Sarcina tehnică
La modernizarea site-ului

Yekaterinburg.

1. Motivele pentru dezvoltarea site-ului web. 3.

1.1. Numele complete și scurte ale sistemului de informații .. 3

1.2. Numele sistemului clienți și detaliile acestuia .. 3

1.3 O listă de documente bazate pe sistem. 3.

1.4. Termenele planificate ale începutului și sfârșitului lucrărilor la crearea sistemului. 3

2. Cerințe pentru sistem. patru.

2.1. Modernizarea site-ului oficial al Comitetului de Investigație la Procuratura Federației Ruse (denumită în continuare - site-ul SCP). patru.

2.2. Pagina principală. cinci

2.3. Pagina internă tipică. opt

2.4. Cerințe pentru plasarea posturilor de știri. nouă

2.5. Cerințe pentru formarea și afișarea listei de documente. unsprezece

2.6. Cerințe pentru afișarea modulului (catalog) 11

2.7. Blog. 13.

2.8. Galerie foto. şaisprezece

2.9. Video player. şaisprezece

2.10. Etichete. şaisprezece

2.11. Cerințe pentru modulul de colectare și analize Date privind statisticile vizitelor site-ului Internet 16

2.12. Cerințe pentru modulul de căutare. 17.

2.13. Cerințe pentru modulul "oficiali". optsprezece

2.14. Cerințe pentru harta migrației. douăzeci

2.15. Cerințe pentru modulul "Colectați apelurile utilizatorilor". douăzeci

2.16. Cerințele de gestionare a resurselor. 21

2.17. Cerințe pentru suportul tehnic. 22

2.18. Cerințe pentru unificare și standardizare. 22.

2.19. Dezvoltarea documentației operaționale. 22.

2.20. Organizarea și desfășurarea formării specialiștilor Comitetului de investigație la Procuratura din Federația Rusă. 23.

3. Site-uri de apel. 24.

3.1. Cerințe generale. 24.

3.2. Text text. 25.

3.3. Știri. 26.

3.4. Întrebări și răspunsuri. 28

3.5. Arhivă de fișiere. 29.

3.6. Formular de colectare. treizeci

3.7. Harta site-ului. treizeci

3.8. Cerințe pentru crearea și îndepărtarea siturilor. 31.

3.10. Cerințe pentru proiectare. 31.

3.11. Cerințe pentru sprijinul lingvistic. 31.

3.12. Dezvoltarea platformei software unificate SCP ... 31

3.13. Cerințe pentru rezultatele muncii. 32.

1. Bazele pentru dezvoltarea site-ului

1.1. Numele complete și scurte ale sistemului de informații

Numele complet al sistemului este site-ul oficial al Comitetului de Investigație la Procuratura din Federația Rusă.

Numele scurt al sistemului - "site-ul SCP", "System", "Site".

1.2. Numele sistemului clienți și detaliile acestuia

Denumire: Comitetul de investigație sub procuratura din Federația Rusă

Locație: Moscova, aleea tehnică, casa 2

Adresa reală: a

Persoana de contact a clientului:

Telefon: (4, (4;

Adresa de e-mail

1.3 Lista documentelor bazate pe sistem

Contractul de stat nr. ________________ de la ___ ___________ 2010

1.4. Momentul programat al începutului și sfârșitului muncii la crearea sistemului

Definită în conformitate cu contractul.

2. Cerințe de sistem

2.1. Modernizarea site-ului oficial al comitetului de investigație în cadrul Procuraturii Federației Ruse (denumită în continuare - site-ul SCP)

Ca parte a modernizării, este necesar să se implementeze:

· Redesignați pagina principală a site-ului SCP, inclusiv rearanjarea blocurilor existente pe pagina principală;

· Crearea unei unități separate pe pagina principală "spunând reprezentanți ai puterii și a mass-media, despre activitatea Comitetului de investigație". Secțiunea trebuie implementată ca listă datată cu posibilitatea de a atașa imagini;

· Setarea fonturilor sistemului implicit propus pentru diferite tipuri de text: pentru antete și text de bază;

· Implementarea posibilității de a înlocui elementele grafice cu textul corespunzător (în cazul caracteristicilor dezactivate din partea laterală a utilizatorului de încărcare a utilizatorului);

· Optimizarea paginilor site-ului SCP în ceea ce privește datele;

· Adaptarea site-ului SCP la un nou design;

· Optimizarea siguranței pentru a preveni posibilele atacuri externe;

· Actualizarea meniului principal, inclusiv următoarele modificări:

Să creeze o secțiune "privind comitetul de investigație";

Această secțiune trebuie să fie o pagină separată a site-ului SCP, cu posibilitatea de a plasa textul și imaginile formatate.

Creați o secțiune "Blogul președintelui";

În secțiunile cu un volum mare de text ("interviu", "publicații" și "cadru de reglementare"), simplificăm informații de la anii.

Structura site-ului aparatului central

· Principalul

· Despre comisia (pagina de text)

· Ghid (modul de catalog)

Ø Lista directorilor (subsecțiunea directorului)

o Descrierea ofițerului (pagina de text)

· Structura (pagina de text)

· Cadrul de reglementare (pagina de text)

· Știri (Modul "Știri")

Ø Lista de știri (subsecțiunea)

o Descrierea știrilor (pagina de text)

· Informații juridice (pagina de text)

· Serviciul de sistem (pagina de text)

· Anti-corupție (modul de director)

Ø Evenimente și documente

o Lista de evenimente (subsecțiunea)

§ Descrierea evenimentului (pagina de text)

Ø Investigarea crimelor de corupție

o Lista de evenimente (subsecțiunea)

§ Descrierea evenimentului (pagina de text)

· Blog (modul "Blog")

· Versiune pentru versiunea cu deficiențe de vedere (modul "pentru persoanele cu deficiențe de vedere")

· Procedura de examinare a apelurilor și a primării cetățenilor (pagina de text)

· Organisme de investigație pe subiecții Federației Ruse (pagina de text)

· Publicații tipărite (modul de catalog)

Ø Bulletin SCB No. 4 (subsecțiunea)

Ø Bulletin SCB nr. 3 (subsecțiunea)

o Descrierea camerei (pagina de text)

· Media din Comitetul de investigație (Modulul "Știri")

Ø Lista publicațiilor (subsecțiunea)

o Descrierea publicării (pagina de text)

· Interacțiunea cu mass-media (modulul "Catalog")

Ø Lista subsecțiilor (subsecțiunea directorului)

o Descrierea subsecțiunii (pagina de text)

· Interviu (Modul "Știri")

Ø Lista de interviuri (subsecțiunea)

o Descrierea interviului (pagina de text)

· Sitemap (modul "Sitemap")

2.2. Pagina principală

În plus față de elementele de identificare și elementele de proiectare, pagina principală a site-ului trebuie să conțină următoarele elemente:

· Meniu principal

Meniul principal al site-ului este un element permanent al fiecărei pagini a site-ului. Meniul trebuie să aibă următoarele linkuri:

ü Despre Comitetul

ü Ghid

ü Structura.

ü Baza de reglementare

ü Știri

ü Informații juridice

ü Service în sistem

ü Anti-corupție

Grila paginii principale este prezentată în fig. unu.

Adevărat "În sistemul de administrare, adică dacă acest steag este zdrobit, știrile se vor potrivi în blocul" relevant "și este acolo până când acest pavilion este eliminat.

· Blochează "spunând reprezentanți ai puterii și a mass-mediei" - Trebuie să fie o listă datată cu un reprezentant al autorității sau mass-media, poziția, imaginea și citatul.

· Banner. - Trebuie să fie o imagine flash sau foto, când apăsați pe site-ul sau secțiunea specificată în sistemul de management al site-ului.

· Blochează "organisme de investigare la subiectele Federației Ruse" - Trebuie să fie o imagine flash a hărții Rusiei cu diviziune de către districtele federale. Când faceți clic pe acesta sau în acel cartier ar trebui să mergeți la o pagină cu o descriere a textului acestui district.

· Blocul "Blogul președintelui"- Trebuie să fie o listă a celor trei subiecte recente create sub forma subiectului și data publicării sale. Titlul subiectului va fi o referință, când faceți clic pe care ar trebui să se traducă în pagina blogului cu o descriere a acestui subiect. De asemenea, în acest bloc ar trebui să fie plasat video, care poate fi reprodus fără a părăsi pagina principală. Videoclipul ar trebui să aibă un link "comentarii", care este numărul de comentarii despre această imagine video. Linkul "Comentarii" ar trebui să conducă la o pagină de blog cu comentarii la videoclipul prezentat.

subsol

Footerul trebuie să conțină un câmp de căutare, informații despre drepturile de autor etc.

2.3. Pagina interioară tipică

Grila unei pagini interne tipice este prezentată în fig. 2.

Smochin. 2. Pagina internă tipică.

Scop:

O pagină internă tipică trebuie să fie un document text cu titlu și o descriere a ceva. Trebuie să conțină fotografii și imagini video, precum și fișierele imbricate pentru descărcare.

2.4. Cerințe pentru plasarea posturilor de știri

Modulul de plasare a mesajelor trebuie să furnizeze:

· Plasarea mesajelor de știri pe site-urile de internet publicate în ordine cronologică (casete de știri);

· Concluzie pe paginile listei de știri ale site-urilor Internet și textele lor complete;

· Căutați după știri de arhivă;

· Exporturile de știri în format RSS 2.0.

Pentru a lucra cu elementele feed-ului de știri, trebuie furnizat un editor HTML, ceea ce vă permite să adăugați și să editați mesaje de știri de către utilizatorii care nu au cunoștințe despre limbile software specializate.

Modulul trebuie să fie o arhitectură pe două niveluri reprezentată ca o listă a tuturor știrilor și o descriere a fiecărei știri.

Lista de știri trebuie prezentată sub formă de știri de nume și datele publicației sale (figura 3)

https://pandia.ru/text/78/390/images/image005_109.jpg "width \u003d" 646 "înălțime \u003d" 525 src \u003d "\u003e

Smochin. 4. Pagina de plasă "Notă Știri".

2.5. Cerințe pentru formarea și afișarea listei de documente

Modulul de formare și afișare al listei de documente ar trebui să permită:

· Organizați publicarea documentelor pe paginile site-ului sub forma unei liste cu posibilitatea de defalcare a paginilor și sortarea prin data publicării;

· Administrator și manager de conținut al site-urilor Internet îndeplinesc următoarele:

o Navigarea listei de documente

o Adăugați documente noi

o Editați și ștergeți documentele adăugate.

2.6. Cerințe pentru afișarea modulului (catalog)

Modulul de afișare a listei trebuie să furnizeze:

· Afișarea pe paginile listelor formatate (lista posturilor vacante, o listă de ramuri, o listă de întrebări și răspunsuri frecvente la ele etc.) sub forma unei liste de referințe la elementele de pagină ale listei;

· Furnizarea de administratori și administratori de conținut ai site-urilor Internet din următoarele funcționalități:

o Editați, adăugați și ștergeți elemente de listă;

o Crearea de noi liste de elemente;

o Ștergeți listele existente.

Modulul trebuie să fie o arhitectură multi-nivel cu o structură ramificată. Secțiunea principală a catalogului trebuie să aibă subsecțiuni trimise ca o listă de subiecte (figura 5)

Smochin. 5. Directorul subsecțirii rețelei.

Când faceți clic pe numele uneia dintre subsecțiuni, trebuie deschisă o descriere a acestei subsecțiuni sub forma unei pagini tipice interne.

Gridul "Descriere subsecțiune" este prezentat în fig. 6.

https://pandia.ru/text/78/390/images/image008_83.jpg "width \u003d" 625 "înălțime \u003d" 526 "\u003e

Smochin. 7. Pagina de plasă "Lista subiectelor dintr-un blog".

Când faceți clic pe unul dintre subiectele, ar trebui să existe o pagină cu o descriere completă a temei și comentariilor la acesta (figura 8)

2.8. Galerie foto

Folosind acest modul, imaginile trebuie plasate pe paginile site-ului, trebuie să fie generată lista de imagini, trebuie să apară o zoom imagine când faceți clic pe imagine.

2.9. Video player

Cu acest modul, imaginile video trebuie plasate pe paginile site-ului, când faceți clic pe videoclip, trebuie afișat video.

2.10. Etichete

Mecanismul de etichetă ar trebui să fie conceput pentru a lega toate știrile, interviurile și alte materiale de pe site. Adică diverse materiale ale site-ului ar trebui să poată aparține unui singur element general.

2.11. Cerințe pentru colectarea și analizele datelor privind statisticile vizitelor site-ului web

Modulul de colectare și analize a datelor privind statisticile vizitelor site-ului ar trebui să furnizeze și să afișeze administratorii de informații despre informații despre vizitele pe site-urile Internet de către utilizatori și dinamica prezenței. Următoarea funcționalitate a modulului trebuie implementată:

· Contabilizarea statisticilor online și lucrați cu date direct pe site;

· Efectuarea colectării și calculării datelor statistice la deschiderea unui vizitator la fiecare pagină fără a plasa butoane, imagine sau cod de program suplimentar în corpul paginii;

· Selectarea fluxurilor vizitatorilor conform uneia dintre criterii:

o Lista site-urilor de trimitere;

o motor de căutare;

o Pagini care au venit;

o Parametrii avansați: țară, utilizator, rețea IP și altele.

· Analiza modurilor pe site cu capacitatea de a selecta o perioadă de analiză, numărul de pagini din cale, prima pagină a căii, ultima pagină a căii, orice pagină a căii și alți parametri de eșantionare a datelor cu un Filtru extins;

· Analiza participării secțiunilor și a paginilor cu posibilitatea de a selecta o perioadă de analiză, partiție și alți parametri ai eșantionării de date cu un filtru extins;

· Analiza punctelor de intrare ale site-ului cu capacitatea de a selecta o perioadă de analiză, partiție și alți parametri ai eșantionării datelor cu un filtru extins;

· Analiza participării site-ului pe graficul general de zile cu prezentarea datelor: hit-uri, sesiuni, vizitatori, gazde, vizitatori noi, evenimente, favorite;

· Analiza statisticilor consolidate ale site-ului, reprezentând date în perioadele anterioare ale următoarelor tipuri:

o Evenimente;

o vizitatori (noi, toate adăugarea la favorite, online);

o Top 10 cele mai active tipuri de evenimente de pe site;

o Top 10 site-uri de trimitere;

o Top 10 cele mai populare fraze de căutare de astăzi;

o Top 10 cele mai active roboți de căutare pe zi.

· Analiza site-urilor de referință; capacitatea de a analiza dinamica pe zi; Contabilitate pentru un modul de căutare încorporat ca motor de căutare cu toate instrumentele de analiză;

· Definirea automată a motoarelor de căutare și a roboților pentru a completa tabelul motorului de căutare;

· Analiza dinamicii evenimentelor pe zi și reprezentând rezultatele sub forma unei diagrame circulare;

· Analiza dinamicii evenimentelor pe zi și reprezentând graficul tipurilor de evenimente.

2.12. Cerințe pentru modulul de căutare

Modulul de căutare trebuie să asigure căutarea site-urilor Internet care conțin cuvinte cheie definite de utilizator. Următoarele funcții trebuie implementate:

· În urma căutării atât pe site-ul selectat, cât și pe inelul site-urilor, luând în considerare morfologia rusă;

· Executarea căutării în același timp în conținutul static al site-ului și al informațiilor dinamice (știri, articole, fotografii)

· Utilizarea limbii de interogare în formarea unei interogări de căutare;

· Utilizați operatori logici pentru interogările de căutare complexe;

· Indexarea automată a tuturor documentelor de site-uri publicate printr-o interfață web sub formă de pagini HTML statice sau prin module de blocare a informațiilor;

· Sortați rezultatele căutării.

2.13. Cerințe pentru modulul "Oficial"

Modulul "oficiali" trebuie să furnizeze:

· Menținerea directorilor de funcționari ai organismelor de investigație asupra entităților constitutive ale Federației Ruse (nivelul șefului și șefului adjunct al organului teritorial al Comitetului de investigație sub procuratura din Federația Rusă).

· Depozitarea informațiilor privind gestionarea organismelor de investigație asupra entităților constitutive ale Federației Ruse ca parte a:

o poziția

o imagine,

o Biografie

o listă datată (bandă) a publicațiilor și discursurilor.

Modulul trebuie să fie o structură ierarhică de subordonare a funcționarilor (figura 9)

https://pandia.ru/text/78/390/images/image011_72.jpg "width \u003d" 646 "înălțime \u003d" 614 src \u003d "\u003e

Smochin. 10. GRIDUL paginii "Descrierea ofițerului".

2.14. Cerințe pentru modulul Harta site-ului

2.15. Cerințe pentru modulul "Colectați apelurile utilizatorilor"

Modulul trebuie să asigure funcționalitatea colectării de apeluri ale cetățenilor Federației Ruse printr-o formă specializată Postat pe site-urile de Internet ale autorităților de investigare:

· Trimiterea rezultatelor completării formularului de pe angajatul responsabil cu e-mail;

· Salvarea formularelor de date în baza de date;

· Asigurarea protecției împotriva formularului de umplere automată introducând codul grafic al controlului.

Gridul de pagină cu forma de manipulare a utilizatorilor este prezentat în fig. unsprezece

Smochin. 11. Grid din pagina "formă de recurs".

Pagina ar trebui să fie un formular cu câmpurile situate pe acesta pentru a umple "numele complet", "E-mail", "numărul de telefon", "adresa" și "textul mesajului". La completarea acestor câmpuri, codul de protecție și apăsați butonul Trimitere a informațiilor trebuie trimise la baza de date și trebuie trimisă o scrisoare adecvată unui e-mail al unui angajat care este responsabil pentru acceptarea aplicațiilor. Apoi, pe ecran în aceeași fereastră, utilizatorul trebuie să prezinte numărul de aplicație pe care la trimis.

2.16. Cerințele de gestionare a resurselor

Pentru a gestiona conținutul informațiilor despre site-urile Internet, inelele de situri, partiții, meniuri și drepturile de acces ar trebui să fie utilizate de sistemul unificat de gestionare a conținutului (CMS) datorită dezvoltării platformei existente dezvoltate ca parte a creării site-ului oficial a Comitetului de investigație sub procuratura din Federația Rusă, asigurând următoarele caracteristici:

· Interfață de administrare unificată și gestionarea online a conținutului;

· Editarea conținutului de secțiuni și pagini ale site-ului internet selectat utilizând un editor grafic;

· Managementul meniului selectat selectat;

· Gestionarea structurii site-ului selectat;

· Menținerea unei partiții interactive ale cărților de internet;

· Plasarea mesajelor de știri având o legare clară a timpului;

· Menținerea arhivei mesajelor de știri, cu posibilitatea de a căuta până la data publicării tuturor site-urilor Internet;

· Căutați informații despre site-urile Internet;

· Publicarea documentelor pe site-urile Internet;

· Camera de învățare este asigurată de client.

· Locul și timpul de învățare ar trebui să fie coordonate cu clientul.

Formarea trebuie efectuată pe parcursul funcționalității sistemului.

Ca parte a formării, este necesar să se efectueze conținutul informațiilor al unui loc pilot al inelelor site-urilor Comitetului de investigație la Procuratura din Federația Rusă.

3. Site-uri de apel

Toate funcționalitățile sistemului trebuie implementate în cadrul modulelor software individuale datorită dezvoltării platformei existente a site-ului SCP. Funcționarea în comun a diferitelor module de site-uri Internet ar trebui să fie prevăzută cu miezul componentei software-ului software-ului software-ului. Modulele care oferă funcționalități specificate trebuie conectate separat pentru fiecare dintre site-urile de internet incluse în inelele site-urilor. Toate modulele software care implementează site-uri Internet trebuie să utilizeze principiile generale de funcționare, indiferent de site-ul inclus în inelul site-ului.

Componentele programului Comitetului de investigație din cadrul Procuraturii din Federația Rusă ar trebui să fie utilizate ca componentă de bază "Siteți inel"

3.1. Cerințe generale

Sistemul creat trebuie să îndeplinească următoarele cerințe:

· Inelul site-ului ar trebui să asigure funcționarea simultan neîntreruptă a Comitetului de investigație al Comitetului de investigație în cadrul Procuraturii a Federației Ruse pe temei Federației Ruse;

· Inelul site-ului trebuie să fie construit pe o schemă de interacțiune cu client-server cu un client subțire. Paginile web stocate și generate pe partea serverului trebuie să fie descărcate pe Internet pe computerele utilizatorilor finali;

· Proiectarea și dezvoltarea inelelor software ale site-urilor ar trebui să fie efectuate utilizând principiile și abordările arhitecturii modulare a soluțiilor software;

· Site-urile web ale site-urilor web ar trebui să ofere acces la resursele informaționale ale organismelor de investigație pe subiecții Federației Ruse și posibilitatea de a pune în aplicare materiale informative regionale;

· Software-ul inelului site-ului trebuie să ofere gestionarea centralizată a conținutului de informații a organelor de investigație, utilizând o interfață grafică care nu necesită utilizatori cunoașterii limbilor de programare specializate.

Site-urile web ale site-urilor web trebuie să includă următoarele tipuri de pagini de informații:

· Pagini text;

· Bandă de știri;

· Intrebari si raspunsuri;

· Arhiva fișierului;

· Formular de colectare a aplicațiilor;

· Harta site-ului.

3.2. Pagina de text

Grid-ul paginii de text tipic este prezentat în fig. 12.

Smochin. 12. Plasă de o pagină de text internă tipică.

Pagina de text tipică trebuie să conțină un antet, o imagine și o descriere a textului. De asemenea, ar trebui să puteți introduce fișiere pentru descărcare.

3.3. știri

Știrile despre banda de pagină sunt prezentate în fig. 13.

Smochin. 13. Pagina de grilă "Feed de știri".

Lista de știri ar trebui să fie formată în ordine cronologică și să conțină informații despre data publicării și numele știrilor.

Când faceți clic pe numele uneia dintre știri, trebuie deschisă o pagină cu o descriere completă a știrilor (fig.14)

Smochin. 14. Gridul paginii "Descrierea știrilor".

Această pagină ar trebui să includă un titlu de știri, o imagine, o descriere a textului, precum și un videoclip care ar trebui redat în aceeași fereastră fără a reporni pagina.

3.4. Intrebari si raspunsuri

Gridul de pagină "Întrebare și răspunsuri" este prezentat în fig. cincisprezece

Smochin. 15. Pagina de plasă "Întrebări și răspunsuri".

Pagina trebuie să fie o listă de întrebări. Când faceți clic pe numele întrebării, trebuie deschis un formular cu răspuns fără repornire a paginii.

3.5. Arhiva fișierului

Trebuie să fie o pagină cu o listă de fișiere pentru descărcare. Când faceți clic pe numele fișierului, trebuie să descărcați automat fișierul fără a reporni pagina (figura 16)

https://pandia.ru/text/78/390/images/image018_31.jpg "width \u003d" 646 "înălțime \u003d" 505 "\u003e

Smochin. 17. Grid din pagina "formă de recurs".

3.7. Harta site-ului

Modulul Harta site-ului trebuie să asigure afișarea informațiilor despre structura partițională a site-ului internet selectat.

Numele partițiilor site-ului ar trebui să fie afișate ca o listă de legături către secțiunea corespunzătoare. Cu ajutorul legăturilor, utilizatorul trebuie să primească capacitatea de a naviga pe site-ul internet selectat.

3.8. Cerințe pentru crearea și mecanismul de eliminare a site-ului

Ca parte a dezvoltării platformei software existente a site-ului Internet al Comitetului de investigație la Procuratura Federației Ruse, este necesar să se dezvolte un mecanism de adăugare a noilor și de a șterge site-urile internet existente ale inelelor de site-uri bazate pe un singur șablon în concordanță cu clientul. Crearea și eliminarea site-urilor Internet trebuie efectuate fără aplicarea limbilor de programare. Acest mecanism ar trebui să asigure posibilitatea de a crea ambele site-uri web cu numele de domeniu al celui de-al treilea nivel și site-urile cu numele de domeniu al celui de-al doilea nivel.

3.9. Cerințe de informare

Ca parte a creării unor inele de situri, trebuie furnizată clientului o umplere primară a unui site pilot de internet cu materiale informative.

3.10. Cerințe pentru proiectare

Pentru site-urile Internet ale inelelor de site-uri, ar trebui să se dezvolte un singur design de pagini și controale, care corespunde deciziei de stil sau color al site-ului Internet al Comitetului de investigație la Procuratura din Federația Rusă. Designul ar trebui să fie convenit cu clientul și să asigure calitatea de membru al site-ului internet la obiectul relevant al Federației Ruse.

Designul site-urilor Internet trebuie să respecte cerințele moderne de proiectare a site-urilor. Gama de culori a inelelor de site-uri ar trebui să fie în concordanță cu clientul ca parte a creării unui sistem.

Designul site-urilor Internet ale inelelor de site-uri trebuie să îndeplinească următoarele caracteristici de stil: stricte, de afaceri, concise, ergonomice, informative.

3.11. Cerințe de sprijin lingvistic

Interfețele inelului de site-uri trebuie efectuate în limba rusă și engleză. Interfețele administrative ale inelelor de situri trebuie îndeplinite numai în limba rusă.

3.12. Dezvoltarea platformei software unificate SCP

Ca parte a dezvoltării, este necesar să se implementeze:

· Conținutul de informații al unui loc pilot al inelelor de situri în cantitate suficientă pentru a verifica întreaga funcționalitate a sistemului, care trebuie pusă în aplicare în cadrul formării;

· Efectuarea unei operațiuni experimentate;

· Introduceți funcționarea comercială.

3.13. Cerințe pentru rezultatele muncii

1. Site-urile inelului de software ale Comitetului de investigație la Procuratura din Federația Rusă

2. Documentație operațională în următoarea compoziție:

· Metode de program și testare;

· Ghidul administratorului;

· Manual de manager de conținut;

· Ghid de instalare;

· Manualul programatorului.

Materialele de raportare trebuie să fie furnizate în două exemplare. Software-ul sunt furnizate numai pe suporturi electronice într-o singură instanță.

Datorită faptului că este adesea rugată să aducă exemple de TK, împărtășesc o parte comunitară a evoluțiilor mele. Valoarea comercială (de ani de configurare) Aceste documente nu au, dar sper că pot fi utile ca mostre.

Sarcina tehnică:

Automatizat

sistemul "Vânzări".

Sarcina tehnică

Pe foi

"_" ______________ 2010

1.General

Numele sistemului automatizat

"Ca vânzări"

Client

Executor testamentar

Baza pentru muncă

Momentul programat al începutului și sfârșitului muncii la crearea sistemului

Începerea muncii: 01.09.2010

Finisarea muncii: 12/31/2010

Numirea și scopul creării unui sistem

Scopul sistemului

Sistemul automatizat dezvoltat este conceput pentru a automatiza procesele de vânzări ale întreprinderii.

Obiectivele creării de sistem

Obiectivele creării unui sistem automatizat

Obiectivele dezvoltării "ca vânzări" sunt:

1. 3. Caracteristicile obiectului de automatizare

3.1 Procese de afaceri Enterprise

3.1. 1 proces de afaceri "încheierea contractului"

3.1.2. Procesul de afaceri "acumularea plății"

1. 4. Cerințe pentru sistem.

4.1. Cerințele pentru sistem în ansamblu.

4.1.1. Metodele și modurile software dezvoltate în AC ar trebui să conțină capacitatea de a dezvolta în continuare sistemul.

5.1.1. Sistemul dezvoltat ar trebui să fie alcătuit din sisteme automatizate, subsisteme și module contabile alocate de scop funcțional, în conformitate cu metodologia stabilită pentru construirea sistemelor de clasă financiară și economică automată.

5.1.2. UA dezvoltată ar trebui să ofere ușurința configurației unui loc de muncă automată (brațe) a fiecărui interpret particular, în conformitate cu sistemul de contabilitate curent.

5.1.3. AC dezvoltat ar trebui să asigure delimitarea drepturilor de acces ale utilizatorilor și să ofere acces la informații în suma necesară și suficientă pentru îndeplinirea îndatoririlor fiecărui contractor.

5.1.4. Protecția informațiilor de la accesul neautorizat trebuie pusă în aplicare utilizând următoarele mecanisme:

1. Restricții privind drepturile de acces la nivelul platformei 1C: întreprinderea 8.1.

2. Restricții suplimentare privind mediul de executare.

5.1.4.1. Prioritățile ar trebui să fie restricții privind nivelul de acces al platformei. Eliminarea limitărilor suplimentare la nivelul mediului de execuție nu permite drepturile de acces la obiecte sau funcții de sistem dacă se aplică o limită de sistem.

5.1.4.2. Informații privind nivelul platformei

· Protecția informațiilor la nivelul platformei este asigurată de mijloacele de sistem. Acest lucru este guvernat de drepturile de citire și editare a obiectelor de sistem, utilizarea interfețelor, a funcțiilor sistemului și a executării operațiunilor de reglementare cu datele sistemului de informare.

· Toate drepturile de acces trebuie să fie sistematizate în seturile corespunzătoare - rolurile sistemului informatic.

· Lista utilizatorilor sistemului informatic trebuie determinată de administratorul de sistem.

· Fiecare permisiune de utilizator ar trebui să fie determinată de un set de roluri ale sistemului de informații disponibile.

· Seturile de roluri ale sistemului de informații disponibile pentru fiecare utilizator ar trebui să definească administratorul de sistem.

· Când începeți să lucrați în sistem, utilizatorul trebuie să transmită procedura de autorizare prin specificarea numelui său în sistem și parolă.

5.1.4.3. Protecția informațiilor la mediul de implementare

Pentru o serie de cărți de referință din sistem, trebuie furnizate restricții suplimentare ale drepturilor de editare.

Referințele pentru care trebuie să stabiliți o interdicție privind editarea în sistem:

• Reducerile de adrese
• Valutele
• Tipuri de așezări reciproce
• Tipuri de activitate a contractorilor
• Grupul de utilizatori
• Documente care certifică personalitatea
• Pozițiile organizațiilor
• Diviziile
• Utilizatori
• Articole de numerar
• Cheltuieli
• Tarifele

5.1.5. Pentru a asigura siguranța informațiilor în timpul accidentelor, ar trebui furnizată arhivarea automată a datelor automate.

5.1.6. Cerințe pentru ergonomie și estetica tehnică

5.1.6.1. Pentru a asigura unificarea interfețelor utilizator, prestabilitele trebuie utilizate pentru bara de instrumente și meniurile context generate automat de platforma 1C.

5.1.6.2. Cartușul utilizat pentru a desemna obiecte și acțiuni ale utilizatorilor din sistem trebuie să respecte terminologia standard a zonei subiectului.

5.2. Cerințe pentru structura și funcționarea AU "Vânzări".

5.2.1. Vânzările de "vânzări" ar trebui să cuprindă următoarele subsisteme automate:

Introducerea subsistemului de informații primare asupra abonatului (încheierea contractului);

Subsistemul pentru formarea de documente pentru plată;

Subsistemul de comunicare cu sistem de asumare;

Subsistemul de comunicare cu terminale de plată.

5.2.2. Componența subsistemului de introducere a informațiilor primare (încheierea contractului) trebuie să fie după cum urmează:

Documentul "Contract cu abonatul";

5.2.3. Componența subsistemului de formare a documentelor de plată ar trebui să fie după cum urmează:

Documentul "Destinația" "

Documentul "Accrual of sancțiuni"

Document "Energie curbată"

Verificarea modulului stadiului de așezări reciproce

5.2.4. Componența subsistemului de comunicare cu sistemul AUCEE ar trebui să fie după cum urmează:

Modul de comunicare cu sistem de asumare.

5.2.5. Componența subsistemului de comunicare cu terminalele de plată trebuie să fie după cum urmează:

Modul de comunicare cu terminale de plată.

5.3. Cerințe pentru funcțiile subsistemului de intrare al abonatului Abonatului (încheierea contractului)

5.3.1. Subsistemul de intrare a abonatului pentru abonat (încheierea contractului) trebuie să efectueze următoarele funcții:

Introducerea și stocarea informațiilor despre capacitatea instalată a contrapartidei (în viitorul abonat);

Introducerea și stocarea informațiilor despre contoarele de abonați stabilite;

Introducerea și stocarea informațiilor despre tarifele abonaților;

Introducerea și stocarea informațiilor privind condițiile de acumulare a sancțiunilor abonatului;

Introducerea și stocarea informațiilor despre termenii contractului;

5.4. Cerințe privind funcțiile subsistemului de formare a documentelor pentru plată

5.4.1. Subsistemul de formare a documentelor de plată ar trebui să efectueze următoarele funcții:

Determinarea stării așezărilor reciproce cu abonatul și determinarea condițiilor de apariție a sancțiunilor.

Formarea documentelor pentru plată (chitanțe sau facturi pentru plată).

5.5. Cerințe pentru funcțiile subsistemului de comunicare cu sistemul de Asuce

5.5.1. Subsistemul de comunicare cu sistemul de asumare ar trebui să efectueze următoarele funcții:

Transferul datelor privind contractele nou încheiate cu abonații. Cheia de conectare trebuie să fie unicitatea ID-ului abonatului - "Codul Tratatului de abonat".

Obținerea datelor privind energia electrică consumată de către abonat. Cheia de comunicare ar trebui să fie unicitatea perechei "Counter ID" - "Counter Code".

5.6. Cerințe privind funcțiile subsistemului de comunicare cu terminalele de plată

5.6.1. Subsistemul de comunicare cu sistemul de asumare ar trebui să efectueze următoarele funcții:

Obținerea datelor privind plățile efectuate de plăți pentru energia electrică prin terminalele de plată.

1. 6. Procedura de monitorizare și acceptare a "vânzării" AIS.

6.1. Următoarea procedură de prezentare și livrare a rezultatelor lucrărilor este aplicată clientului:

6.1.1. Contractantul demonstrează performanța software-ului în exemplul de control.

6.1.2. Datele pentru exemplul de control sunt pregătite de reprezentanții clienților.

6.1.3. Contractantul transmite software-ul la Departamentul de Informații al Clientului și efectuează administratorul clientului.

6.1.4. În conformitate cu rezultatele deciziei exemplului de control, ar trebui să fie pregătit un act de transmitere la operațiunea de judecată.

6.1.5. În cazul nerespectării funcționalității cerințelor TK, Contractantul elimină observațiile din costul total al dezvoltării AC.

6.1.6. Dacă există cerințe suplimentare ale clientului la TK, TK suplimentar este compilat pentru rafinament.

6.1.7. Prezența cerințelor suplimentare ale clientului nu ar trebui să fie baza refuzului de a semna un act privind transmiterea operațiunii de încercare.

6.1.8. După transferul de software la operațiunea de încercare, în conformitate cu implementarea implementării, contractantul face o scurtă formare a personalului clientului care lucrează cu software și transferă instrucțiunile de lucru cu software pentru fiecare subzistență.

6.1.9. La introducerea software-ului (operațiunea de încercare), clientul efectuează:

Introducerea NSI necesară;

Introducerea datelor reale;

Formarea raportării și verificării rezultatelor muncii.

6.1.10. În procesul de implementare, contractantul trebuie să asiste clientului ca parte a programului de implementare.

6.1.11. În cazul unei pregătiri slabe a personalului clienților, trebuie întocmită punerea în aplicare a contractantului pentru implementarea cu succes a software-ului, trebuie elaborate minutele suplimentare de coordonare a furnizării contractuale de informații și de consultanță.

6.2. găsirea de acompanieri în continuare a sarcinilor ca "vânzări".

6.2.1. După punerea în funcțiune, îmbunătățirea și dorințele suplimentare ale clientului pot fi implementate în conformitate cu TK în concordanță cu clientul.

TK ar trebui să indice complexitatea și costul muncii privind punerea în aplicare a cerințelor suplimentare.

6.2.2. Contractantul se angajează să sprijine telefonul "Hotline Hot" prin acompaniament de software.

6.2.3. La cererea clientului, contractantul poate efectua sprijin pentru software direct de la client, care ar trebui să se desfășoare pe baza unui acompaniament suplimentar al contractului.

6.2.4. Erorile identificate de client timp de șase luni de la data punerii în funcțiune ar trebui eliminate de către contractant operațional și gratuit.

În cazul în care Contractantul constată că eroarea a apărut ca urmare a acțiunilor incorecte ale clientului, timpul petrecut de contractant pentru căutarea și eliminarea sa trebuie plătit suplimentar.

6.2.5. Clientul, în cursul anului după achiziționarea de 1C: întreprindere, are dreptul să primească toate actualizările de la o firmă 1C asociată cu dezvoltarea programelor 1C și o modificare a legislației. Setarea modificărilor trebuie efectuate de către clientul ACS.

6.2.6. Contractantul garantează menținerea confidențialității conținutului bazelor de date ale clienților și a oricăror alte informații primite de la client în procesul de dezvoltare, implementare sau întreținere AC.

Proiect tehnic:

Apreciez că supun aprobării

"" ______________ 2010 "" "_______________ 2010

Anexă la atribuirea tehnică din "____" ________ 2010

Automatizat

sistemul "Vânzări".

Proiect tehnic

Pe foi

Acționează cu "__" ____________ 2010

Directoare. 3.

Contoare. 3.

Tarife .. 3.

Stație. 3.

Penalități penalități. 3.

Enumerare. patru.

Tipuri de acumulari. patru.

Registrele de informații. patru.

Valoarea tarifelor. patru.

Tarifele de abonat. patru.

Datele de date. cinci

Registrele de acumulare. cinci

Consum de energie. cinci

Documente .. 6.

Contract cu abonatul .. 6

Energia consumată. 6.

Primire. 7.

Acumularea de sancțiuni. nouă

Prelucrare. 10.

Obținerea datelor din sistemul de asumare. 10.

Obținerea datelor din sistemul de plată. 11

Directoare

Contoare

Rechizite:

Tarifele

Detalii: Nu.

Penalități penalități

Detalii: Nu.

Listare.

Tipuri de acumulare

Valori:

Registrele de informații

Termeni de acțiune a contractelor

Periodicitate: non-periodică

Scop: concepută pentru a stoca termenele de contracte cu abonații

Măsurători

Înțeles tarifele

Periodicitate: Ziua

Scop: concepute pentru depozitarea tarifelor și a datelor, din care începe tarifele să acționeze

Măsurători

Recuzită		Scop
		Ziua Tarifului în timpul zilei
		Costul tarifului de noapte (nu poate fi specificat)

Tarifele de abonat.

Periodicitate: Ziua

Scop: concepute pentru stocarea tarifelor atribuite abonatului în cadrul contractelor

Măsurători

Recuzită		Scop
	Tarifele de referință	Rata abonatului

Contoare de date.

Periodicitate: Ziua

Scop: concepute pentru a stoca citirile contorului pentru acumularea ulterioară a plăților

Măsurători

Recuzită		Scop
Indicaţie		Citirea metrului
Justiune		Citirea metrului

Registrele de acumulare

Consumul de energie

Scop: Proiectat pentru stocarea informațiilor privind consumul de energie pentru acumularea de plată ulterioară

Tipul de înregistrare: Problemă

Măsurători

Documentație

Contract cu abonatul

Scop: concepută pentru a reflecta faptul de încheiere a unui contract cu abonatul

Recuzită		Scop
Contrapartidă	Directorul directorului directorului
Contracturerant
	Tarifele de referință
Putere montată		Depozitarea puterii de abonat instalate în kW
Saladiație de date		Data cu care contractul este valabil
Centre de date		Data sfârșitului contractului
Organizare	Directorul organizației
OptionStrafov.
Nomenclatură	Nomenclatura de manual
Ajustarea manuală		Semnul de ajustare manuală a cablului de documente

Tabsal: contoare și tarife

Conducând documente

Documentul este deținut:

Conform registrului informațiilor "contoare" mărturie "în care sunt prescrise contoarele abonaților și mărturia inițială a contoarelor;

Conform Registrului informațiilor "Tarifele de abonat" în cazul în care tariful este prescris de către abonat de la data începerii contractului

În conformitate cu Registrul informațiilor "Termeni de acțiune" în cazul în care contractul este prescris, data începerii și data finale a contractului

Energia consumată

Scop: Conceput pentru a reflecta citirile contorului pentru o anumită dată

Completarea documentului

Documentul poate fi completat în două moduri: intrare manuală și prin apelarea procesării "Obținerea datelor din sistemul AUCEE"

Conducând documente

Documentul este deținut:

Conform registrului informațiilor "Memor Cititings", unde citirile contorului prescriu la data documentului;

Prin înregistrarea economiilor "consumate în conformitate cu următorul algoritm:

1. Citirile de contoare sunt preluate din raportul "citirilor contoarelor" pe data documentului și valorile anterioare ale citirilor contorului.

2. Diferențele valorilor citirilor sunt introduse în resursele corespunzătoare ale registrului de acumulare.

Formulare tipărite

Înregistrați mărturia contoarelor

Primire.

Scop: Proiectat pentru a reflecta acumularea abonaților

Completarea documentului

Documentul poate fi completat în două moduri: introducerea manuală și prin apelarea procesului de procesare "de plată"

Tab-uri: citiri de metri

Recuzită		Scop
Contrapartidă	Directorul directorului directorului
Contracturerant	Tratatele contractoarelor directorului
Nomenclatură	Nomenclatura de manual
	Tarifele de referință	Rata abonaților conform contractului
	Contoare de directoare
Vizibil	Speed \u200b\u200bListing.
Consumate de energie		Consuetanenenggia
Valoarea tarifului		Valoarea tarifară la data documentului
Acumulate		Suma abonatului acumulator

Conducând documente

Documentul este deținut:

Potrivit planului de conturi, impozitul:

Formulare tipărite

Registrul de acumulare

Algoritmul de umplere

Documentul este completat pe baza cărții de referință a contractului contractorilor.

1. Din cartea de referință, sunt alese acorduri, care, în conformitate cu registrul informațiilor "Termeni de acțiune", mai puțin de data documentului și efectuarea datelor este mai mare decât data documentului;
2. Contoarele sunt selectate corespunzător acestor tratate;
3. Pentru metri, consumul de energie este determinat ca o cifră de afaceri a registrului de acumulare "consum de energie" în perioada cuprinsă între data documentului și data documentului anterior, dacă data documentului anterior nu este cunoscută, atunci întreaga cifră de afaceri este luate în registru. Valoarea rezultată este înregistrată în câmpul "Consimțit Energy".
4. Tariful este stabilit în conformitate cu contractul și valoarea tarifului la data documentului;
5. Se stabilește tipul de acumulare "conform mărturiei contorului";
6. Câmpul calculează ca o bucată de energie consumată pe un infarct.

Algoritmul de exploatație

CT. 90.01 cu analitice de subcontoxation1 - Nomenclatură. Grupul nomenclat, subcontratul2 - Nomenclatura. Standard.

Dacă există un sold de împrumut în cont 62.02, atunci o plată în avans este deținută cu cablurile

Dt. 62.02 cu Analytics Subcontodt1 - contrapartidă, subcontodt2 - Contract contractual

Cantitatea cablajului este valoarea minimă din soldul împrumutului din cont 62.02 și valorile necesare "acumulate")

Dt. 90.03 cu Analytics Subkontodt1 - Nomenclatură. Grupul de la Nonenclature, Subcontodt2 - Nomenclatură. Standard

CT. 62.01 cu subcontoxatul de analiză1 - contrapartidă, subcontrocalizarea2 - Contract contractual

Cantitatea de cablare \u003d "acumulată" * STAVATAND / (100 + STAVANAS), unde Stavankands - "Nomenclature.stavkands"

Acumularea de sancțiuni

Scop: Conceput pentru a reflecta acumulari ale abonaților cu amenzi

Completarea documentului

Documentul poate fi completat în două moduri: intrarea manuală și prin apelarea procesului de prelucrare a amenzilor "

Tab-uri: citiri de metri

Recuzită		Scop
Contrapartidă	Directorul directorului directorului
Contracturerant	Tratatele contractoarelor directorului
OptionStrafov.	Opțiuni director pentru încarierea sancțiunilor
Acumulate		Suma abonatului acumulator

Conducând documente

Documentul este deținut:

Conform planului de conturi, scump:

Potrivit planului de conturi, impozitul:

Formulare tipărite

Registrul de acumulare

Primirea pentru plată cu cod de bare

Codul de bare este format din Font "InfograferBode"

Algoritmul pentru formarea șirului "0000" + codul contractului Abonatului + acumulat

Layout-ul de primire este atașat în fișierul sq_1.mxl

Algoritmul de exploatație

Pentru fiecare rând al părții tabulare a "citirilor contoarelor", trebuie făcute următoarele cabluri:

Dt. 62.01 Cu Analytics Subcontodt1 - contrapartidă, subcontodt2 - Contract contractual

CT. 91.01 cu subcontoxatul de analiză1 - Alte venituri.

Cantitatea de cablare este valoarea necesară a cerințelor "acumulate";

Prelucrare

Obținerea datelor din sistemul de asumare

			Precizie	Scop
				Countr-codul în sistemul "Vânzări", se înmoaie cu ID-ul sistemului de asumare
				Citirile contorului în rata zilei
				Cookwing-ul la rata de noapte

Procomenzi de procesare

Algoritmul de procesare:

1. Obțineți un cod de contoare de la linia de fișiere de date
2. Găsiți pe codul corespunzător din directorul "Contori" dacă elementul nu este găsit, atunci nu veți da un mesaj "Contorul cu codul ..."
3. Dacă se găsește elementul, adăugați un șir la tabelul de valori, unde: "Counter" - element găsit, "Citire" - "zi", "Articulație" - "Night"
4. Dacă procesarea este cauzată de documentul "energie curbată" și numărul de rânduri

În tabelul de valori, mai mult de 0, apoi scrieți conținutul tabelului de valori în partea de masă a documentului și conduceți un document.

1. Dacă există rânduri și prelucrare în tabelul de valori, nu se numește din documentul "Energie consumată", apoi creează un document "consumat energie" cu data datei curente și apoi efectuați un document.

Obținerea datelor din sistemul de plăți

Formatul fișierului de transfer de date - DBF;

Structura fișierului de transfer de date:

Procomenzi de procesare

Algoritmul de procesare:

1. Creați un tabel de valori cu structura:

1. Selectați linii de fișiere de date
2. Porniți un ciclu pe rândurile de fișiere de date ale liniei
3. Citiți șirul liniei de transfer de date
4. Obțineți codul contractului de la linia de fișiere de date
5. Găsiți elementul corespunzător în codul din directorul Ghidului Contractului, dacă elementul nu este găsit, apoi dați un mesaj "Contractul nu a fost găsit cu codul ..."
6. Dacă elementul se găsește, adăugați un șir la tabela de valori, unde: "Tratat" - element găsit, "Data" - "Data_plat", "Număr" - "Nomm_plat", "Suma" - "Summa_plat"
7. După primirea ultimelor linii de fișier de transfer de fișiere de date. Ciclul final
8. Pentru fiecare rând din tabelul valorii creării unui document "Plata primită de bani". La crearea unui document, verificați disponibilitatea în sistemul unui document cu o astfel de dată și numărul documentului primit. Dacă documentul este prezent în sistem, documentul nu este creat.
9. Reguli pentru completarea detaliilor documentului:

Recuzită	Valoarea este umplută
Tipul de operare
	Strfotable. Date.
Numărul de documente primite	Strfotables.
Data documentului primit	Strfotable. Date.
Contract de contract.	Strfotable. Sign.

Adesea am pus prototipurile paginilor astfel încât clientul să înțeleagă cum arată site-ul său. Apoi fac o sarcină separată pentru Cameraracher - cu detalii tehnice și explicații care vor ajuta la activitatea sa.

Sarcina mai dificilă, cu atât mai mult ar trebui să fie tk. Când am participat la proiecte mari, am văzut în vrac și 30 de pagini.

Gura lui Sipka, fondator al Media Didjital Studio Udix

În primul rând, TK trebuie să fie client - astfel încât să înțeleagă ceea ce va fi site-ul său și ce bani merg. Dacă ceva nu este făcut așa - se poate referi la TK și va cere remake-ul.

TK este managerul de proiect după comunicarea cu clientul și discutați sarcina cu designerul.

Clienții mari solicită adesea un TK foarte detaliat, în care este descris fiecare buton. Companiile mici, dimpotrivă, nu-i plac documentele meticuloase pentru 100 de pagini.

Un exemplu de sarcină tehnică privind rafinamentul site-ului

General

Numele sistemului automatizat

"Ca vânzări"

Client

Executor testamentar

Baza pentru muncă

Momentul programat al începutului și sfârșitului muncii la crearea sistemului

Începerea muncii: 01.09.2010

Finisarea muncii: 12/31/2010

Numirea și scopul creării unui sistem

Scopul sistemului

Sistemul automatizat dezvoltat este conceput pentru a automatiza procesele de vânzări ale întreprinderii.

Obiectivele creării de sistem

Obiectivele creării unui sistem automatizat

Obiectivele dezvoltării "ca vânzări" sunt:

1. 3. Caracteristicile obiectului de automatizare

3.1 Procese de afaceri Enterprise

3.1. 1 proces de afaceri "încheierea contractului"

Acesta va deveni scutul dvs., în acest document, în cazul căruia, puteți să vă loviți degetul unui dezvoltator nedrept și cereți să vă aduceți site-ul în conformitate cu acesta.

Sarcina tehnică (Pe scurt "TK") este un document care, în cele mai detalii, reflectă fără echivoc cerințele pentru viitorul dvs. site.

Site-ul creează tocmai pe baza TK. Cu cât va fi mai detaliată și mai evidentă, cu atât mai mult site-ul dvs. nou se va potrivi așteptărilor dvs.

TK la crearea site-ului - ca lege, nu ar trebui să permită interpretări și discrepanțe.

Tot ceea ce nu este scris în dezvoltatorul TK la discreția sa.

· Ghidul administratorului;

· Manual de manager de conținut;

· Ghid de instalare;

· Manualul programatorului.

2.20. Organizarea și desfășurarea formării specialiștilor Comitetului de investigație la Procuratura Federației Ruse

Următoarele cerințe de formare sunt impuse:

· Artistul trebuie să desfășoare formarea angajaților Comitetului de investigație la Procuratura din Federația Rusă, ca parte a celor mai mult de 10 persoane.

· Formarea ar trebui să aibă loc în limba rusă.

· Camera de învățare este asigurată de client.

· Locul și timpul de învățare ar trebui să fie coordonate cu clientul.

Formarea trebuie efectuată pe parcursul funcționalității sistemului.

Ca parte a formării, este necesar să se efectueze conținutul informațiilor al unui loc pilot al inelelor site-urilor Comitetului de investigație la Procuratura din Federația Rusă.

3.

Sample de sarcină tehnică privind îmbunătățirea site-ului

Important

În procesul de implementare, contractantul trebuie să asiste clientului ca parte a programului de implementare.

6.1.11. În cazul unei pregătiri slabe a personalului clienților, trebuie întocmită punerea în aplicare a contractantului pentru implementarea cu succes a software-ului, trebuie elaborate minutele suplimentare de coordonare a furnizării contractuale de informații și de consultanță.

6.2. Găsirea în continuare acompaniament a sarcinilor vânzărilor de "vânzări".

După punerea în funcțiune, îmbunătățirea și dorințele suplimentare ale clientului pot fi implementate în conformitate cu TK în concordanță cu clientul.

TK ar trebui să indice complexitatea și costul muncii privind punerea în aplicare a cerințelor suplimentare.

6.2.2. Contractantul se angajează să sprijine telefonul "Hotline Hot" prin acompaniament de software.

Valoarea interacțiunii Înainte de a trece la pregătirea procesului de creare a unei alocări tehnice, să vorbim despre un cvadriclu în care interpretul și clientul intră în proiect. Cerințe - comportamentul dorit al sistemului descris de client sau deținătorul procesului care urmează să fie implementat. De regulă, cerințele sunt formate pe baza experienței de muncă, prezentarea comportamentului adecvat al programului.

Acestea sunt informații cheie pentru dezvoltator (furnizor), însă este în stadiul de colectare a cerințelor pe care se ridică cel mai mare număr de coliziuni, erori, cereri inutile și așa mai departe.

Resurse - Oameni, mașini, echipamente, mediu de dezvoltare, timp și bani care urmează să fie utilizate în procesul de punere în aplicare a cerințelor. Resursele necesită o planificare și o evaluare clară în stadiul de aprobare a sarcinii tehnice.

Aceasta include cerințele pentru diferite sortare, integrare cu capabilități de chat, telefonie.

Nivelul serviciului - De fapt, cerințele acestui nivel ar trebui să fie primele care intră în clădiri noi cu remedii. Acestea sunt sarcini pentru viteza răspunsului sistemului, care lucrează sub sarcină mare, securitate.

Atenţie

În versiunea ideală, Vendor nu ar trebui să aibă astfel de îmbunătățiri - Software-ul corporativ nu trebuie să încetinească, să piardă datele, să se prăbușească și să distribuie permisiunile unui nivel. Dar dacă a apărut cerința și nu este legată de paraniza sau problemele personale ale clientului din partea hardware-ului, merită să o acordăm o atenție deosebită pentru el.

Nivelul de tehnologie - Ultima pe listă, dar în importanță și dificultate este înaintea restului.

Acestea pot fi cerințele clienților asociate cu platforma, sistemul de operare sau dispozitive. De exemplu, o colecție de asamblare sub MacOS.

Microsoft World sau Microsoft Excel.

Personal, la dezvoltarea paginii de destinație, folosim produse software speciale.

Cu ajutorul lor, puteți face rapid și ușor proiecte chiar și site-uri complexe - acest lucru este, de exemplu, balsamiq. Cu toate acestea, pe măsură ce facem întregul prototip deja discutat în articol.

Pe această temă: prototiparea site-ului: crearea, instrumentele și programele.

Proiectarea pre-proiect poate fi făcută împreună cu dezvoltatorul sau schimbându-l complet pe umeri.
Principalul lucru, nu uitați, atunci sunteți de acord și să semnați cele două părți.

Lifehaki pentru pregătirea lui tk

Aceste elemente se referă în mod egal atât la umplerea BRIF, cât și la pregătirea sarcinii tehnice.

Și în ele, vă voi dezvălui trucuri mici, cum să faceți TK pentru site și să vă eliberați și fără viața complexă a antreprenorului:

1.

Asigurați-vă că clientul și performerul se înțeleg corect reciproc. "

În sarcina tehnică nu ar trebui să fie adjective de înaltă calitate: frumos, fiabil, modern. Ele nu pot fi înțelese fără echivoc. Toată lumea are propriile sale concepte de frumusețe și modernitate.

Uite. Cineva la urma urmei, a considerat acest design frumos și a permis să utilizeze pe site-ul său web:

Același lucru - cu formulările vagi care nu înseamnă nimic singur:

• Site-ul ar trebui să-i placă clientul. Și dacă are o dispoziție proastă?
• Site-ul trebuie să fie convenabil. Ce înseamnă? Convenabil pentru ce?
• Site-ul trebuie să reziste la sarcini grele. 10 mii de vizitatori? Sau 10 milioane?
• Conținutul de experți calitativi. Ei bine, ați înțeles.

Verificați dacă nu există ambiguitate în text. Dacă există - rescrie.

A decis să comande un site (el și aterizare)? Ca spectacole practice, nu este atât de simplu. Sute de clienți, văzând site-ul lor finit, consideră că nu le se potrivește: Designul nu este cel, locația este lame, textele de către, a înșurubat o grămadă de funcții inutile.

Pentru a evita astfel de consecințe, aveți nevoie de o sarcină tehnică pentru dezvoltarea site-ului.

Am nevoie de ea?!

Indiferent cine va fi interpretul site-ului - voi, ruda, freelancerii pentru plata modestă, o companie specializată pentru o sumă imensă de bani ...

Sarcina tehnică de pe site ar trebui să fie.

De exemplu, vă puteți cere să creați un raport personalizat pentru Regionsoft CRM și puteți comanda integrarea cu site-ul. Acest lucru este complet diferit în ceea ce privește sarcina, aici este o prioritate foarte importantă. După colectarea cerințelor, analizate și coordonate cu angajații și gestionarea, puteți începe să creați o sarcină tehnică.
Puteți cere forma vânzătorului sau puteți face singur - în orice caz, există mai multe reguli de fier, care vor salva de la durerea de cap și de dvs. și furnizorul dvs. CRM.

Anatomia sarcinii tehnice

Dacă vorbim despre procesul de creare a unei sarcini tehnice, atunci există mai multe etape. Pasajul lor consistent și conduce clientul la rafinamentul dorit.
Aici sunt ei.

Este important să ascultați opinia vânzătorului, așa cum știe exact la ce oră merge la una sau altă sarcină. Crede-mă, dezvoltatorul nu este profitabil să tragă timpul și să vâneze termenul - este profitabil pentru aceasta să completeze cât mai multe proiecte și să o facă bine pentru a nu primi o lovitură reputației.

În ceea ce privește realismul, evitați cererile de a termina CRM la nivelul sistemului de gestionare a coliziunilor pur și simplu: ar trebui să fie inclusă în cerințele a ceea ce este într-adevăr necesar în acest moment și în viitorul previzibil.

De exemplu, regiunile CRM este un program desktop, nu avem un client pentru un browser. Întrebându-ne să creăm o aplicație web pentru o singură companie, este lipsită de sens, este o dezvoltare majoră, se desfășoară acum și nu este posibilă perfecționarea pentru o singură companie.

Numele complete și scurte ale sistemului de informații

Numele complet al sistemului este site-ul oficial al Comitetului de Investigație la Procuratura din Federația Rusă.

Numele scurt al sistemului - "site-ul SCP", "System", "Site".

1.2. Numele sistemului clienți și detaliile acestuia

Denumire: Comitetul de investigație sub procuratura din Federația Rusă

Locul de amplasare: G.

Info.

Moscova, aleea tehnică, casa 2

Adresa reală: a

Persoana de contact a clientului:

Telefon: (4, (4;

Adresa de e-mail

1.3 Lista documentelor bazate pe sistem

Contractul de stat nr. ________________ de la ___ ___________ 2010

1.4.

Momentul programat al începutului și sfârșitului muncii la crearea sistemului

Definită în conformitate cu contractul.

2. Cerințe de sistem

2.1.

Data de plată

Numărul de plată

Numărul de plată în sistemul de plăți

Suma de plata

1. Selectați linii de fișiere de date
2. Porniți un ciclu pe rândurile de fișiere de date ale liniei
3. Citiți șirul liniei de transfer de date
4. Obțineți codul contractului de la linia de fișiere de date
5. Găsiți elementul corespunzător în codul din directorul Ghidului Contractului, dacă elementul nu este găsit, apoi dați un mesaj "Contractul nu a fost găsit cu codul ..."
6. Dacă elementul se găsește, adăugați un șir la tabela de valori, unde: "Tratat" - element găsit, "Data" - "Data_plat", "Număr" - "Nomm_plat", "Suma" - "Summa_plat"
7. După primirea ultimelor linii de fișier de transfer de fișiere de date. Ciclul final
8. Pentru fiecare rând din tabelul valorii creării unui document "Plata primită de bani".

Umplerea unui scurt sau constituirea TK pe designul site-ului, nu lăsați spații în ea.

Trebuie să înțelegeți că "la discreția dezvoltatorului" înseamnă "ceea ce vreau, că și gruge" sau "tot ceea ce nu este specificat se efectuează la discreția artistului". Și crede-mă, nu este doar o lacună, ci o fereastră întreagă în Europa pentru dezvoltator.

Și, bineînțeles, nu se întâmplă întotdeauna.

Dacă un specialist competent te-a prins, atunci nu vă puteți îngrijora de rezultat.

Dar apoi apare o altă problemă, poate face acest lucru într-adevăr după cum este necesar, și nu vă place pur subiectiv. Și totul va fi ca un cunoscut anecdote pentru mulți dezvoltatori:

Pe scurt despre principalul lucru

Cu siguranță, nu regreți timpul petrecut pentru întocmirea și potrivirea sarcinii tehnice pentru a crea un site web sau de creditare.

La urma urmei, acesta este cel mai bun instrument pentru monitorizarea și rezolvarea dezacordurilor care apar în acest proces.

Când faceți clic pe acesta sau în acel cartier ar trebui să mergeți la o pagină cu o descriere a textului acestui district.

· Blocul "Blogul președintelui" - Trebuie să fie o listă a celor trei subiecte recente create sub forma subiectului și data publicării sale. Titlul subiectului va fi o referință, când faceți clic pe care ar trebui să se traducă în pagina blogului cu o descriere a acestui subiect. De asemenea, în acest bloc ar trebui să fie plasat video, care poate fi reprodus fără a părăsi pagina principală. Videoclipul ar trebui să aibă un link "comentarii", care este numărul de comentarii despre această imagine video. Linkul "Comentarii" ar trebui să conducă la o pagină de blog cu comentarii la videoclipul prezentat.

Footerul trebuie să conțină un câmp de căutare, informații despre drepturile de autor etc.

2.3.

Briff. - Acesta este un chestionar cu întrebări despre conținutul, proiectarea, capacitățile tehnice ale viitorului dvs. site.

Desigur, o scurtă descriere detaliată, semnată de două părți, poate înlocui sarcina tehnică.

La urma urmei, este practic aceeași, singura diferență este că scurta este viziunea ta, iar sarcina tehnică este un document final bazat pe comentariile dvs. scurte și ale dezvoltatorului.

Dacă elementele individuale cauzează dificultăți, atunci nu ezitați să întrebați întrebările dezvoltatorului pe tipul "Ce înseamnă asta?", "Cum va afecta lucrarea site-ului meu?" Din moment ce nu toți dezvoltatorii sub o singură înțelegere la fel ca tine.

Fie în numără "informații suplimentare" asigurați-vă că specificați toate dorințele dvs. care nu au fost incluse în răspunsurile la întrebări.

Dacă acest grafic este absent, adăugați-le doar la sfârșitul scurt.

VK, Google, Facebook.

3.2.2 În contul personal în secțiunea de comandă, adăugați un câmp pentru a adăuga un cod promoțional.

3.2.3 În loc de o pagină care vine la utilizator după o solicitare de recuperare a parolei (vizualizați name.com/bitrix/admin/index.php?change_password\u003dyes&lang\u003dru&user_checkword\u003d) Faceți o pagină (name.com/login/forgot/ Shange_password \u003d YES & LANG \u003d EN & User_CheckWord \u003d), care va afișa conținutul site-ului, va avea câmpul "Email când înregistrați", verificați linia, parola nouă, confirmarea parolei, butonul Trimiteți date.

3.2.4 La adăugarea de bunuri în coș, trebuie afișat un mesaj pe care produsul îl adaugă la coș.

3.2.5 Adăugați mesajul de ieșire că parola nu se potrivește cu parametrii fără pericol atunci când înregistrează un nou utilizator.

Automatizatsistemul "Vânzări".Sarcina tehnicăPe foaching cu "__" ____________ 2010

»_" ______________ 2010

Treptat, schimbările au intrat în eliberare și mai târziu au permis să creeze un produs nou pentru magazinele cu ridicata, cu amănuntul și hipermarketurile - Retail Retail.

Nivelul utilizatorului sau grupul de utilizatori. La acest nivel, sarcinile sunt implementate cu privire la revizuirea interfeței existente. De exemplu, utilizatorul poate dori ca atunci când deplasați un cursor, apare o fereastră cu numărul și starea ultimei comenzi sau a existat un raport personalizat cu o grupare specială de date.

Rafinăria la acest nivel ocupă mai puțin timp, dar pot exista multe dintre ele - de exemplu, mai multe cerințe din partea departamentului de marketing, logistică și suport tehnic.

Nivelul funcționalității. Este adesea dificil să o separați de cel precedent, un criteriu formal funcționează aici - rafinamentul nu este la nivelul de afișare a nimic în interfață, ci la nivelul rafinării logicii sistemului.

Dacă porridge este scris acolo - poate că merită să se rostogolească și să nu se uite în jur.

• Îndreptați-vă împotriva lipsitenței artistului. Când site-ul este gata, acesta poate fi verificat în funcție de sarcina tehnică. Există inconsecvențe? Dezvoltatorul trebuie să le corecteze. Dacă cooperezi oficial și a încheiat un contract - chiar puteți forța prin instanță.
• Simplificați înlocuirea artiștilor interpreți sau executanți. În cazul în care clientul și dezvoltatorul s-au maturizat și au fugit, crearea site-ului poate fi puternic întârziată. Când există o economie detaliată, aceasta poate fi transferată într-o echipă nouă - se va transforma în lucru uneori mai repede.
• Aflați costul dezvoltării unui produs complex. Evaluați timpul exact și costul dezvoltării unui serviciu web complex nu poate fi selectat. Mai întâi trebuie să înțelegeți cum va funcționa serviciul și ce funcții vor fi în ea.

Există acces la rădăcină, adrese de IP proprii, porturi, reguli de filtrare și tabele de rutare.

Insightele Google PageSpeed \u200b\u200beste un serviciu de recomandare gratuită pentru site-urile web pentru a accelera afișarea paginii în browserul utilizatorului (https://developers.google.com/speed/pagespeed/inspirges/).

Optimizarea motorului de căutare (sau SEO) este un set de măsuri privind optimizarea internă și externă pentru a ridica poziția site-ului în rezultatele emiterii motoarelor de căutare pentru anumite solicitări de utilizator.

Optimizarea site-ului extern este site-ul de înregistrare în motoarele de căutare, promovarea în rețelele sociale, extinderea greutății de referință prin atragerea de legături de la alte resurse la un site promovat, publicitate banner, publicitate contextuală.

Optimizarea site-ului intern este optimizarea textului, adreselor URL-urilor, editarea structurii site-ului, depășirea, verificați răspunsurile serverului.

Materiale disponibile link-uri către site-uri plăcute, precum și broșuri, reviste, fotografii - orice, și poate aveți un fag de brand gata. Atașat de o arhivă separată. Dispozitivele minime de rezoluție și afișare în acest moment indică ce dispozitive sunt de așteptat să vizualizeze site-ul - PC-uri, laptopuri, smartphone-uri ... monitoare PC de la 19 la 27 inci; Laptop-uri de la 15,6 la 17,3 inci; Smartphone-uri de la 3,5 la 6 inci; Plăci de la 7 la 12 inci Aveți nevoie de o versiune mobilă? Da Cerințe funcționale Set de module (pentru utilizatori) În această secțiune, trebuie să enumerați toate funcționalitățile pe care doriți să le vedeți pe site.

Acesta poate fi un coș, filtre de directoare de către diferiți parametri, capacitatea de a face o comandă online, lăsați o aplicație pentru un apel invers, abonați la newsletter-ul și orice alte filtre de opțiuni pentru preț, alfabetic, de către producător.
Cultcj9b: s »xvzb╟▌╤└u╟j_ ■ E╘dj» J ■ ╛EHHJ (GTT┬PB╟▌╤└u╟╛ # ╜┘al + Ka KQ X3┴i≈² & F╒ # ┐╜ ╙┐█ Ts╜iwa▓bo└vsb╟▌╤└u╟╛ # ╜┘al + Kaxg [B: Bvzb╟▌╤└u╟╛ # ╜┘al + Kaxg [B: BVZB╟▌╤└u╟ ╛ # ╜ ┘al + kaxg [B: bvzb╟▌╤└u╟╛ # ╜│Ce & v█7┬m3aqnyjy╕ ° vzb╟▌╤└u╟╛ # ╜┘al + kaxg [B: bvzb╟▌ ╤└u╟╛ # ╜┘al + Kaxg [B: LZB╟▌╤└u╟╛ # ╜┘al + Kaxg [B: LZB╟▌╤└u╟╛ # ╜┘al + Kaxg [B: LZB╒ ▀┬y╥xuf ≈k & Oqte╦▒ '% [H╓≥lk "[C (B╖ ~ B╖ ~ B╖ ~ B╖ ~ B╖ ~ B╖ ~ B ~ ╚б╖ ~ B╖ ~ B ╖ ~ B╖ ~ B╖ ~ B╖ ~ B╖ ~ B╖ ~ Bd '\\ ┘ * Nlkz ⌡ ┐ \\ ┘ ╖ ╒ ╒ ┐ ┐ ┘ ┘ ╒ ╒ ⌡ ┐ ┐ ┘ ╒ ╒ ╒ ┐ ┐ ┐ ╔ ╒ ╒ ╒ ┐ ┐ ╔ ╔ ∙ ╒ ╒ ∙ ╔ ╔ ∙ ∙ ╒ ╔ ╤ ∙ ∙ ∙ ╔ ∙ ╤SQ ≥╒ ° ╒ ╒ ╒ ╒ ╒ ∙ ∙ RRMVC╪ ┬7┴ + ISO (╦ ° RB╒┴ ■ E4SCH┬╨ Z╖ ┘╤M ° С ÷ Um╦wymdr '% r ^ & ╔gt╖yhd] ZT╪ l╝i ▌▀s_2╫j) E + H © O22K% J ┼╖┼╖SSA≈K▐F2YCH▐HD╟FG╬LN ∙ ╥ ╥ ⌡<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Din punctul de vedere al oaspeților *, în cadrul căruia sunt reglementate activitățile privind dezvoltarea software-ului și a sistemelor automate (AC) - acesta este documentul principal care definește cerințele și procedura de dezvoltare sau modernizare (denumită în continuare - creația) automată sistem, în conformitate cu care AC și acceptarea sa se dezvoltă la intrarea în acțiune.

• * GOST 19.201-78 Sistem unificat de documentație software. Sarcină tehnică. Cerințe pentru conținut și design;
• GOST 34.602-89 Tehnologia informației. Set de standarde pentru sisteme automate. Sarcina tehnică pentru a crea un sistem automatizat.

Din păcate, GOST nu are o definiție mai clară, prin urmare, având în vedere interesele părților interacționale - integratorul și clientul, va da corect o definiție mai precisă. Sarcina tehnică, fiind principalul document cu privire la proiectarea sistemului automat, stabilește principalele caracteristici și alocări ale AC, determină etapele necesare creării documentației și a compoziției sale și este, de asemenea, o justificare parțială.

De ce aveți nevoie de o sarcină tehnică

Principalele probleme ale proiectului apar din cauza unor cerințe de proiect formulate incorect sau pierdute. Cerințele de bază pentru rezultatul ar trebui să fie descrise în sarcina tehnică, care este formată de specialiștii tehnici ai contractantului și nu de către Client.

Astfel, add-urile la definiție au fost deja formulate mai sus. Aș dori să adaug că acest document care conține cerințele trebuie formulat pe limbajul prietenos cu clienții. Legăturile la particularitățile implementării tehnice ale UA nu se face. Acestea. În stadiul TK, în principiu, nu contează, pe care platformă vor fi implementate aceste cerințe. Calculul și formularea cerințelor, precum și proiectarea sarcinii tehnice, ar trebui să facă un analist de afaceri și nici un programator (deși combinând rolurile, această opțiune este posibilă), deoarece este analistul care vorbește cu clientul în el Limba de afaceri.

Sarcina tehnică corectă, scrisă și coordonată între toți persoanele interesate și responsabile, este cheia implementării cu succes a oricărui proiect.

Care dezvoltă o sarcină tehnică

Clientul, de regulă, nu este un specialist în domeniul tehnologiei informației, astfel încât cerințele de bază pentru rezultatul trebuie să fie descrise în sarcina tehnică, care este formată de specialiștii tehnici ai contractantului, nu de client.

Erori tipice la dezvoltarea unei sarcini tehnice

Documentul se bazează pe GOST 34.602-89, care oferă o structură formalizată, dar nu are cerințe clare pentru prezentarea secțiunilor și alineatelor. Această caracteristică a standardului este puterea și slăbiciunea acesteia. Libertatea prezentării poate duce la cerințele secțiunilor (în special funcționale):

• Subliniat nu sistemic, fără a se lega de nici o structură (module de sistem, procese de afaceri);
• Duplicat;
• Diferite niveluri de detalii.

Ipotezele de eroare în elaborarea unei sarcini tehnice conduc la o creștere a costurilor și duratei proiectului. Principala sarcină a sarcinii tehnice este de a emite cerințele clientului în mod ușor de înțeles și posibil pentru a pune în aplicare formatul.

Implementarea cerințelor clientului este imposibilă fără o sarcină tehnică propusă. Chiar și cu prezența unei competențe ridicate a angajaților, pot apărea erori. Cel mai adesea sunt următoarele:

• Detalii excesive;
• Cerințele contrare reciproc;
• Formularea inexactă.

Mulți clienți insuficient necesită cerința de a descrie o descriere detaliată a sistemului sistemului, dar accentul ar trebui să se concentreze asupra rezultatului și nu asupra modului în care ar trebui să arate sistemul.

Cerințele nu ar trebui să fie contradictorii. De asemenea, este de dorit să se evite formularea vagă, nespecifică. La dezvoltarea TK, cerințele de bază și scopul proiectului sunt determinate, funcționalitatea acestuia.

Cum să evitați erorile în compilarea tk

Regula principală: mai multe specifice. La întocmirea cerințelor, este necesar să se utilizeze referințe la GOST, documentele de reglementare ale clientului, care vor evita interpretarea dublă sau neînțelegerea între Client și Interpret.

La dezvoltarea TK, este necesar să se aplice un stil de prezentare uscat, științific, să evite utilizarea comparațiilor. Rezultă terminologia industriei, sfera în care se dezvoltă proiectul.

Urmați următoarele reguli:

• Formarea TK este lucrarea comună a contractantului și a clientului;
• Riscurile artistului trebuie să fie minimizate și nu trebuie să depășească similar cu clientul (altfel va duce la o creștere a costului proiectului);
• Cerințele sunt formate obiectiv, nu se recomandă utilizarea vizei subiective a clientului;
• Nu este permisă utilizarea termenilor adoptați într-o comunicare largă de afaceri, dar contradictorii adoptate în industrie și standard;
• Accentul se pune pe descrierea rezultatelor cerute de client. De exemplu, clientul trebuie să primească un raport privind circulația mărfurilor în reducerile analitice adecvate, apoi parametrii de raport (șirurile, analiticii, perioada pentru care se întocmește raportul) și sursele de date ar trebui să fie descrise în TK . Cel mai important lucru aici este de a preveni interpretarea extinsă a sarcinii tehnice, în caz contrar, dacă nu specificați o perioadă sau o sursă de date, rezultatul final poate diferi foarte mult de cerințele clientului, iar rafinamentul va necesita instrumente și timp suplimentari .

Dezvoltare, de exemplu, programul "drept" TK 1C implică o imersie completă în subiect, cunoașterea tuturor aspectelor și subtilităților sale. TK ar trebui să răspundă nu numai la întrebarea "Ce ar trebui să facă un programator", dar mai întâi de toate - "Ce sarcini ar trebui să rezolve sistemul 1C: o întreprindere după muncă". Cerințele trebuie formulate în detaliu, dar fără informații inutile. Acest lucru va reduce probabilitatea de inexactități și erori. Acesta este motivul pentru care exemplul versatil al sarcinii tehnice 1c nu este posibil - fiecare caz de TK pe dezvoltarea 1c este unic.

Sarcina tehnică este un document de service care descrie regulile de efectuare a lucrărilor și cerințelor contractorului.

De ce este important să stabilească întregul proces de lucru sub formă de documentație tehnică?

1. TK este prescris între interpret și clientul care este dificil de exprimat în contract datorită utilizării terminologiei specifice specifice.
2. Acest lucru va economisi timp pe comunicații: soluțiile tehnice fixe vor scăpa de numeroase retelinguri, confirmări, confuzie în mărturie.
3. Documentul vă va permite să împărțiți în mod clar zonele de responsabilitate între părțile la proiect.
4. TK face posibilă analizarea viitorului proiect și identificarea problemelor la etapa de planificare.
5. Sarcina corectă compilată va face comportamentul tuturor participanților la lucrarea previzibilă și scuti de numeroase neînțelegeri.
6. Din punct de vedere juridic, prezența acestui document va facilita părțile pentru a rezolva momente controversate.
7. Economia face posibilă planificarea financiară, care este cheia unei afaceri de succes. Clientul va fi văzut în prealabil, la care cheltuiesc fondurile sale.

Fiecare proiect trebuie indicat de limite - în ceea ce privește costul, volumul de muncă efectuat, calendarul de execuție și calitatea. Toate acestea trebuie fixate în TK.

Dacă una dintre părți dorește să coopereze fără economie

Acest lucru poate însemna următoarele:

Clientul nu stabilește cerințe clare în mod specific, apoi să facă parte din lucrarea gratuit sau nu este sigur / nu știe / nu a decis / nu înțelege ce are nevoie.

Dezvoltatorul speră pentru o continuare permanentă a lucrării în detrimentul clientului, argumentând acest lucru cu o anumită incertitudine.

Într-o astfel de situație, partidul opus trebuie insistat să creeze o sarcină tehnică cu granițe clare și definirea sarcinilor. Fără acest lucru, va fi dificil pentru părțile să dovedească că lucrarea a fost făcută sau, dimpotrivă, nu au fost făcute în mod corespunzător.

Participanți la proiect

Dacă proiectul este mareÎn plus, participanții pot adăuga:

• Manager de produs.
• Manager de proiect
• Sponsor al proiectului
• Testere
• Scriitori tehnici
• Curatori
• Utilizatori / consumatori (de exemplu, pentru testare finală)
• Si etc.

Dacă proiectul este mic, apoi client și interpret, de regulă, lucrează direct. În acest caz, testarea preia clientul, iar dezvoltatorul însuși controlează calendarul și pune prioritățile.

Ce oferă părților fiecare secțiune TK:

Secțiunea Tz.	+ PentruClient	+ PentruDezvoltator
Definirea unui obiectiv	Conștientizarea sarcinilor care rezolvă proiectul sau rafinamentul acesteia	Înțelegerea esenței sarcinii
Descrierea produsului	Ideea modului în care va fi produsul finit	Încrederea în înțelegerea corectă a rezultatului final
Termenele limită	Orientare în ceea ce privește munca și primirea rezultatelor planificate	Evaluarea costurilor forței de muncă și a cerințelor resurselor
Bugetul proiectului	Determinarea unei cantități mai mari sau mai puțin precise a costurilor și planificării bugetului	Contabilitate consecventă a tuturor lucrărilor de proiect
Lista de lucrări	Descrierea detaliată a lucrării și a fiecărei etape a implementării proiectului	Lucrul la tehnologia instalată. Abilitatea de a abandona lucrarea care nu este prevăzută de sarcină sau de a le include în TK pentru o taxă suplimentară
Evaluarea rezultatului muncii	Verificarea proiectului pentru testarea programului pentru respectarea cerințelor sarcinii	Abilitatea de a vă asigura că în activitatea neîntreruptă a proiectului și în conformitate cu cerințele lui tk
Serviciul de proiect	Planificarea costurilor serviciului și o idee de sprijin suplimentar pentru proiect	Performanța muncii cu menținerea proiectului în perspectivă
Identificarea problemelor	Planificarea îmbunătățirilor proiectului	Rafinament în conformitate cu nevoi noi

Consecințele pregătirii unei alocări de calitate slabă

Un programator sau o echipă de dezvoltare operează "orbește", dezagreabilă, fără a avea o idee clară despre rezultatul final al proiectului. Rezultatul va fi în zadar petrecut în timp și bani, relații răsfățate cu clientul.

Rezultatul proiectului nu corespunde așteptărilor clientului. Bugetul suplimentar și timpul de rafinament vor fi necesare.

În mod obișnuit, dezvoltarea TK de înaltă calitate este împiedicată de următoarele puncte:

Clientul nu este gata să plătească până la 40% din costul proiectului numai pentru dezvoltarea sarcinii. De exemplu, este posibil să scrieți toate cazurile de testare înainte de designul designului și să se așeze în TK. Dar, în acest caz, valoarea sarcinii cu cazurile de testare poate depăși costul dezvoltării, iar pregătirea sa va dura mai mult de o lună. Dar elimină complet problema cu erori în muncă și simplifică acceptarea.

Clientul nu cunoaște toate detaliile proiectului înainte de începerea funcționării rezultatului gata.

Interfața nu este pregătită fără plată adecvată pentru a cheltui mai multe resurse pentru dezvoltarea TK.

Artistul și clientul nu pot prevedea toate problemele posibile. Participanții la proiecte experimentați pe ambele părți pot prevedea o serie de probleme tipice și unice în avans, dar acest lucru nu garantează că toate lucrările pe proiect vor fi salariale.

De exemplu, am uitat să mă înregistrez în cazul prezenței unui buton, iar după proiect sa dovedit că era imposibil să se folosească pe deplin fără ea. Pentru a adăuga același buton, este necesar să remake jumătate din arhitectura bazei de date interne și, prin urmare, o parte din codul programului pentru a rescrie. Cine dintre partide este de vina în această situație?

Cele mai multe dintre aceste probleme rezolvă o agilă (o abordare flexibilă la locul de muncă), dar acest lucru nu anulează necesitatea de a compune TK. Utilizați Agile atunci când dezvoltați proiecte de incertitudine ridicată. De regulă, există numai clienți împotriva acestui lucru, deoarece nu văd granița exactă a prețului și a calendarului. Dar produsul final este garantat pentru a efectua sarcinile set - Agile uneori reduce numărul de proiecte finite care au fost abandonate datorită faptului că nu își îndeplinesc funcțiile.

Părțile ar trebui să înțeleagă că majoritatea proiectelor se desfășoară cu o mare parte din incertitudine și negociază în avans cum să interacționeze în caz de probleme.

Economia trebuie să răspundă la întrebări:

1. Ce? (Ce funcționează, conținutul elementelor)
2. Unde? (localizarea elementelor)
3. Cand? (Secvența executării și termenelor limită pentru muncă)
4. Cum? (Implementarea tehnologiei, designul, principiul muncii.) De regulă, orice obiect trebuie să aibă funcții: adăugați, afișați, editați, ștergeți. Și descrie, de asemenea, dependențele și interacțiunile cu alte obiecte. Uneori moderarea, validarea, actualizările automate, arhivarea etc. sunt adăugate.
5. Unde? / Unde sa? (când este transferat etc.)
6. Pentru ce? (Justificarea muncii, dacă sarcina trebuie să fie coordonată cu cea de-a treia față)
7. Caracteristici.

1. Cu cât este mai mare amploarea proiectului, cu atât mai volumetrică ar trebui să fie o sarcină tehnică.
2. Este necesar să se indice limitele efective de timp pentru îndeplinirea timpului la coordonarea documentației de proiect și a activităților de acceptare. Este demn de acord cu atenție la responsabilitatea clientului pentru inacțiunea din partea sa sau pentru forța majoră, care sunt inhibate performanța muncii.
3. Programatorul are nevoie de condiții clare. Formularea "ca opțiune", "aproximativ", "despre", "undeva în apropiere", "unde este mai bine în opinia dvs." este inacceptabilă. Cerințe și caracteristici care sunt subiective în natură nu sunt lipsite de sens practice și eronate din punct de vedere juridic.
4. Pentru a face o sarcină pentru a crea un modul funcțional care este de înțeles pentru un programator, în lămpile tehnice Plasați hyperlink-urile la acele pagini în care există elementele necesare ale interfeței și funcțiilor și să le dați explicații detaliate. De asemenea, au fost atașate capturi de ecran cu alocarea fragmentului de interes.
5. Dacă nu există un design pentru pagini sau nu este atât de important pentru client, programatorul poate utiliza prototipuri, care după aprobare este indicată în sarcină.
6. TK trebuie să fie convenabil și înțeles pentru toate părțile proiectului, descrie în detaliu toate etapele și paragrafele chiar și de cea mai mică lucrare. Programatorul și managerul nu au întotdeauna o idee că este necesar clientului, deci este important să se detecteze și să coordoneze toate detaliile inconsistente.

7 erori tipice

1. Obiective și sarcini fuzzy.
2. Câteva detalii în informațiile tehnice.
3. Date neclară sau neidentificate.
4. Nu există o coerență cu privire la toate problemele dintre părți.
5. Nu există reguli de interacțiune.
6. Nu există persoane responsabile.
7. Nu există criterii de evaluare a rezultatului.

Un exemplu de sarcină tehnică potrivită pentru a rafina proiectul

O sarcină:
Postați pe site www.site.name.ru. O nouă pagină în care vor fi plasate contacte și fotografii ale vânzătorilor de consultanți, precum și chat-ul online.

Descriere:

1. UNDE? Adăugați la Meniu major Meniu Site Meniu nou Secțiunea "Consultantul dvs." între "Blog" și "Clienții noștri".
2. UNDE SA? Noua pagină URL Marcă: /vash_konsultant.htm
3. LA FEL DE? Amenajarea noii pagini ia de la "medicii noștri". Numai în loc de medici vor fi consultanți.
4. CE? Structura paginii următoare:
   • titlu: Consultantul dvs. - în centru (în stilul altor anteturi ale paginilor site-ului);
   • 3 blocuri la rând, având câmpuri:
     • cu fotografii de vânzători de dimensiuni de 400 * 600 (aliniere în centru);
     • NUMELE COMPLET. Vânzătorii sub fotografii (format text cu posibilitatea de editare);
     • telefonul este comun tuturor: 555-555-55 sub fi. (Format text cu posibilitatea de editare);
     • adresa electronică sub telefon (e-mail: site-ul.[E-mail protejat] poștă. rU.);
     • butonul "Consultare" sub toate câmpurile, dimensiunea butonului, culoarea și forma în stilul butoanelor de pe site (consultați butonul "Comenzi" de pe adresa URL: /katalog.ru).
5. Unde? Consultanții ar trebui să se pronunțe în editorul site-ului. Titlu, descriere, etichetele H1 ar trebui, de asemenea, editate.

Dacă lucrarea este efectuată pentru scopuri SEO - nu uitați să puneți toate elementele necesare pe pagină.

De asemenea, plasați formularul de comandă.

1. UNDE? Sub lista consultanților, deasupra subsolului.
2. CE? Trei câmpuri:
   • Nume
   • Numar de telefon
   • Conținutul aplicației
3. LA FEL DE? Obligatoriu pentru completarea câmpului: numele și numărul de telefon. Înregistrarea se face în funcție de formularul de feedback. Dacă câmpul necesar nu este umplut, mesajul trebuie afișat ca în formularul de feedback.
4. UNDE SA? Aplicație Trimiteți la clientul de e-mail: info.@ uZUAL.. com.
5. LA FEL DE? Înregistrarea scrisorilor în formă liberă.
6. Caracteristici Protecția împotriva roboților pentru a pune pe formă de feedback.
   Când trimiteți o cerere, dacă totul este complet corect, evenimentul "Trimiterea unei aplicații" trebuie trimis la Yandex-Metric.
7. Nu uitați de regulile de acceptare
   Verifica:
   • Pagina nu trebuie deblocată etichete HTML.
   • Verificați adaptarea pe dispozitivele mobile Android cu permisiune *** x **** și **** x **** și tablete cu o rezoluție de 1280 x 1024.
   • Verificați lucrul în browserele Safari, Chrome, Mozilla.

PS. Costul și calendarul executării sunt, de obicei, indicate separat în anexa la contract. Interfața va expune costul muncii, pe baza sarcinilor prescrise în lansarea tehnică. Cele mai multe dorințe - cu atât mai mare costul.