Priprema za laboratorijski rad

Pročitajte materijal predavanja na temu „Modeli životnog ciklusa softvera. Faze životnog ciklusa u skladu sa GOST 19.102-77. Izjava o problemu" discipline "Razvoj i standardizacija PS i IT".

1. Proučite relevantne dijelove u publikacijama.

Teorijski dio. Razvoj projektni zadatak

Tehnički zadatak je dokument koji formuliše glavne ciljeve razvoja, zahteve za softverski proizvod, utvrđuje uslove i faze razvoja i reguliše proces testova prihvatanja. U izradu projektnog zadatka uključeni su i predstavnici naručioca i predstavnici izvođača radova. Ovaj dokument se zasniva na početnim zahtjevima naručitelja, analizi napredne tehnologije, rezultatima naučnog istraživanja, predprojektnom istraživanju, naučnim prognozama itd.

Redoslijed izrade tehničkih specifikacija

Izrada tehničkih specifikacija vrši se u sljedećem redoslijedu. Prije svega, oni uspostavljaju skup funkcija koje treba izvršiti, kao i listu i karakteristike početnih podataka. Zatim se utvrđuje lista rezultata, njihove karakteristike i metode prezentacije.

Zatim specificiraju okruženje za rad softvera: specifičnu konfiguraciju i parametre tehnička sredstva, verziju operativnog sistema koji se koristi, i eventualno verzije i postavke drugog instaliranog softvera sa kojim će budući softverski proizvod komunicirati.

U slučajevima kada razvijeni softver prikuplja i pohranjuje neke informacije ili je uključen u upravljanje bilo kojim tehničkim procesom, potrebno je i jasno regulisati postupanje programa u slučaju nestanka opreme i struje.

1. Opće odredbe

1.1. Projektni zadaci se sastavljaju u skladu sa GOST 19.106-78 na listovima formata A4 i A3 u skladu sa GOST 2.301-68, u pravilu, bez popunjavanja polja lista. Brojevi listova (stranica) se stavljaju na vrh lista iznad teksta.

1.2. List odobrenja i naslovna stranica sastavljeni su u skladu sa GOST 19.104-78. Informativni dio (sažetak i sadržaj), list za registraciju promjena ne može biti uključen u dokument.

1.3. Za izmjene i dopune tehničke pozadine u narednim fazama razvoja programa ili softverskog proizvoda, izdaje se dodatak tome. Usklađivanje i odobravanje dopuna projektnog zadatka vrši se na isti način kao što je utvrđeno za projektni zadatak.

1.4. Projektni zadatak treba da sadrži sljedeće dijelove:

Uvod;

Naziv i obim;

Osnova za razvoj;

Svrha razvoja;

Tehnički uslovi na program ili softverski proizvod;

Tehnički i ekonomski pokazatelji;

Faze i faze razvoja;

Procedura kontrole i prihvatanja;

Prijave.

U zavisnosti od karakteristika programa ili softverskog proizvoda, dozvoljeno je razjasniti sadržaj sekcija, uvesti nove sekcije ili kombinovati neke od njih. Ako je potrebno, dozvoljeno je uključiti prijave u projektni zadatak.

2.1.Uvod treba uključiti kratak opis obim programa ili softverskog proizvoda, kao i objekt (na primjer, sistem) u kojem bi se trebao koristiti. Osnovna svrha uvoda je da se pokaže relevantnost ovog razvoja i pokaže koje mjesto ovaj razvoj zauzima među sličnim.

2.2 U odeljku „Naziv i opseg“ navesti naziv, kratak opis obima programa ili softverskog proizvoda i objekta u kojem se program ili softverski proizvod koristi.

2.3. U odeljku „Osnove za razvoj“ mora se navesti sledeće:

Dokument (dokumenti) na osnovu kojeg se vrši razvoj. Takav dokument može biti plan, nalog, ugovor itd.;

Organizacija koja je odobrila ovaj dokument i datum njegovog odobrenja;

Ime i (ili) simbol razvojne teme.

2.4. Odjeljak Svrha razvoja treba da naznači funkcionalnu i operativnu svrhu programa ili softverskog proizvoda.

2.5. Odjeljak "Tehnički zahtjevi za program ili softverski proizvod" treba da sadrži sljedeće pododjeljke:

zahtjevi za performanse;

Zahtjevi za pouzdanost;

Radni uslovi;

Zahtjevi za sastav i parametre tehničkih sredstava;

Zahtjevi za kompatibilnost informacija i softvera;

Zahtjevi za označavanje i pakovanje;

Zahtjevi za transport i skladištenje;

Posebni zahtjevi.

2.5.1.U pododjeljku "Zahtjevi za funkcionalne karakteristike" treba navesti zahtjeve za sastav funkcija koje se obavljaju, organizaciju ulaznih i izlaznih podataka, vremenske karakteristike itd.

2.5.2 U pododjeljku "Zahtjevi za pouzdanost" moraju se navesti zahtjevi za osiguranje pouzdanog rada (osiguranje stabilnog rada, kontrola ulaznih i izlaznih informacija, vrijeme oporavka nakon kvara, itd.).

2.5.3 U pododeljku „Radni uslovi“ moraju se navesti radni uslovi (temperatura ambijentalnog vazduha, relativna vlažnost itd. za odabrane tipove nosača podataka) pod kojima se moraju obezbediti navedene karakteristike, kao i tip usluga, potreban iznos i kvalifikacije osoblja.

2.5.4 U pododjeljku "Zahtjevi za sastav i parametre tehničkih sredstava" navesti potreban sastav tehničkih sredstava, naznačiti njihov specifikacije.

2.5.5 U pododjeljku „Zahtjevi za kompatibilnost informacija i programa“ treba navesti zahtjeve za informacijske strukture na ulazu i izlazu i metode rješenja, izvorne kodove, programske jezike. Gdje je potrebno, informacije i programi trebaju biti zaštićeni.

2.5.6 U pododjeljku „Zahtjevi za označavanje i pakovanje“, u opštem slučaju, navedeni su zahtjevi za označavanje softverskih proizvoda, mogućnosti pakovanja i metode.

2.5.7 U pododjeljku "Zahtjevi za transport i skladištenje" za softverski proizvod moraju se navesti uslovi transporta, lokacije skladištenja, uslovi skladištenja, uslovi skladištenja, rokovi skladištenja pod različitim uslovima.

2.5.8. U odeljku "Tehničko-ekonomski pokazatelji" treba navesti: procenjenu ekonomsku efikasnost, procenjenu godišnju potrebu, ekonomske prednosti razvoja u odnosu na najbolje domaće i strane uzorke ili analoge.

2.6. U odeljku "Faze i faze razvoja" potrebne su faze razvoja, faze i sadržaj rada (spisak programskih dokumenata koji se moraju izraditi, usaglasiti i odobriti), kao i, po pravilu, razvoj utvrđuju se rokovi i određuju izvršioci.

2.7 U odeljku „Procedura za kontrolu i prijem“ vrste ispitivanja i Opšti zahtjevi prihvatiti posao.

2.8 U aneksima projektnog zadatka, ako je potrebno, navesti:

Spisak istraživačkih i drugih radova koji potkrepljuju razvoj;

Algoritamske šeme, tabele, opisi, opravdanja, proračuni i drugi dokumenti koji se mogu koristiti u izradi;

Drugi izvori razvoja.

U slučajevima kada klijent ne iznese bilo kakve zahtjeve predviđene projektnim zadatkom, na odgovarajućem mjestu treba navesti „Nema zahtjeva“.

Primjeri izrade projektnog zadatka dati su u dodacima B i C.

test pitanja

1. Dajte koncept modela životni ciklus ON.

2. Navedite faze razvoja softvera.

3. Šta uključuje izjava o problemu i pretprojektno istraživanje?

4. Navedite funkcionalne i operativne zahtjeve za softverski proizvod.

5. Navedite pravila za izradu projektnog zadatka.

6. Navedite glavne dijelove projektnog zadatka.

Aneks A

Opcije zadatka

Za istu opciju izvode se laboratorijski radovi br. 1-5.

1. Razviti softverski modul „Obračun napretka učenika“. Softverski modul je dizajniran tako da promptno bilježi napredak studenata na sjednici od strane dekana, prodekana i dekanskog osoblja. Podatke o napredovanju studenata treba čuvati tokom čitavog perioda studiranja i koristiti u pripremi potvrda o položenim predmetima i dodataka diplomi.

2. Razviti programski modul "Lični dosijei studenata". Softverski modul je namijenjen za dobijanje informacija o studentima od strane radnika dekanata, sindikalnog odbora i kadrovske službe. Podaci se moraju čuvati tokom čitavog perioda školovanja učenika i koristiti u izradi potvrda i izvještaja.

3. Razviti softverski modul "Rješenje kombinatornih optimizacijskih problema". Modul treba da sadrži algoritme za pronalaženje ciklusa minimalne dužine (problem trgovačkog putnika), pronalaženje najkraće staze i pronalaženje minimalnog razapinjućeg stabla.

4. Razviti softverski modul "Matrična obrada". Modul treba da sadrži algoritme za pronalaženje zbira i proizvoda elemenata matrice po redovima i kolonama, kao i izračunavanje prosječne, minimalne i maksimalne vrijednosti u matrici.

5. Razvijte Windows aplikaciju "Organizator". Aplikacija je dizajnirana za snimanje, pohranjivanje i traženje adresa i telefonskih brojeva pojedinci i organizacije, kao i rasporedi, sastanci itd. Aplikacija je dizajnirana za svakog korisnika računara.

6. Razviti Windows aplikaciju "Kalkulator". Aplikacija je namijenjena svakom korisniku i treba da sadrži sve aritmetičke operacije (u odnosu na prioritete) i po mogućnosti (ali nije obavezno) nekoliko matematičkih funkcija.

7. Razviti softverski modul "Odsjek", koji sadrži podatke o osoblju odsjeka (naziv, pozicija, akademska diploma, discipline, obim posla, socijalni rad, honorarni poslovi, itd.). Modul je namijenjen za korištenje zaposlenima u kadrovskoj službi i dekanatu.

8. Razviti softverski modul "Laboratorija", koji sadrži podatke o osoblju laboratorije (ime, pol, godine, bračno stanje, prisustvo djece, radno mjesto, akademsko zvanje). Modul je namijenjen za korištenje zaposlenima u sindikalnim odborima i kadrovskoj službi.

9. Razviti programski modul "Kemijsko čišćenje". Prilikom registracije za uslugu popunjava se prijava u kojoj se navodi puno ime vlasnika, opis proizvoda, vrsta usluge, datum prijema narudžbe i cijena usluge. Nakon obavljenog posla, štampa se račun.

10.Razviti softverski modul „Obračunavanje kršenja pravila saobraćaja". Za svaki automobil (i njegovog vlasnika) lista prekršaja se pohranjuje u bazi podataka. Za svaki prekršaj evidentira se datum, vrijeme, vrsta prekršaja i visina kazne. Kada se plate sve kazne, auto se briše iz baze podataka.

11. Razviti softverski modul „Kartoteka auto shopa“, namijenjen zaposlenima u agenciji. Baza podataka sadrži informacije o automobilima (marka, veličina motora, datum izdavanja, itd.). Kada se primi nalog za kupovinu, vrši se pretraga odgovarajuća opcija. Ako to nije slučaj, klijent se unosi u bazu klijenata i obavještava se kada se pojavi opcija.

12. Razviti softverski modul "Kartoteka pretplatnika ATS-a". Kartica sadrži informacije o telefonima i njihovim vlasnicima. Popravlja zaostale obaveze (pretplatničke i vremenske). Vjeruje se da je već uvedeno plaćanje po satu lokalnih telefonskih poziva.

13. Razviti softverski modul "Avtokassa", koji sadrži informacije o raspoloživosti mjesta na autobuskim linijama. Baza podataka treba da sadrži podatke o broju leta, ruti, vozaču, vrsti autobusa, datumu i vremenu polaska, kao i cijene karata. Kada se primi zahtjev za karte, program traži odgovarajući let.

14. Razviti softverski modul "Knjižara", koji sadrži podatke o knjigama (autor, naslov, izdavač, godina izdanja, cijena). Kupac popunjava aplikaciju za knjige koje su mu potrebne, ako ih nema, unosi se u bazu podataka i obavještava se kada potrebne knjige stignu u radnju.

15. Razviti softverski modul "Parking". Program sadrži podatke o marki automobila, njegovom vlasniku, datumu i vremenu ulaska, troškovima parkinga, popustima, zaostalim plaćanjima itd.

16. Izraditi programski modul "Agencija za zapošljavanje", koji sadrži informacije o slobodnim radnim mjestima i životopisima. Softverski modul je dizajniran kako za pronalaženje radnika koji ispunjava zahtjeve menadžera kompanije, tako i za pronalaženje odgovarajućeg posla.

LAB #1

Faze razvoja softvera u strukturnom pristupu programiranju. Faza "Terms of Reference"

Cilj: Upoznajte se sa pravilima za pisanje tehničkih specifikacija.

Priprema za laboratorijski rad

Pročitajte materijal predavanja na temu „Modeli životnog ciklusa softvera. Faze životnog ciklusa u skladu sa GOST 19.102-77. Izjava o problemu" discipline "Razvoj i standardizacija PS i IT".

Proučite relevantne dijelove u publikacijama.

Teorijski dio. Izrada tehničkih specifikacija

Tehnički zadatak je dokument koji formuliše glavne ciljeve razvoja, zahteve za softverski proizvod, utvrđuje uslove i faze razvoja i reguliše proces testova prihvatanja. U izradu projektnog zadatka uključeni su i predstavnici naručioca i predstavnici izvođača radova. Ovaj dokument se zasniva na početnim zahtjevima naručitelja, analizi napredne tehnologije, rezultatima naučnog istraživanja, predprojektnom istraživanju, naučnim prognozama itd.

Redoslijed izrade tehničkih specifikacija

Izrada tehničkih specifikacija vrši se u sljedećem redoslijedu. Prije svega, oni uspostavljaju skup funkcija koje treba izvršiti, kao i listu i karakteristike početnih podataka. Zatim se utvrđuje lista rezultata, njihove karakteristike i metode prezentacije. Zatim se specificira softversko operativno okruženje: specifična konfiguracija i parametri hardvera, verzija operativnog sistema koji se koristi i, eventualno, verzije i parametri drugog instaliranog softvera sa kojim će budući softverski proizvod biti u interakciji. U slučajevima kada razvijeni softver prikuplja i pohranjuje neke informacije ili je uključen u upravljanje bilo kojim tehničkim procesom, potrebno je i jasno regulisati postupanje programa u slučaju nestanka opreme i struje. 1. Opšte odredbe

Projektni zadaci se sastavljaju u skladu sa GOST 19.106-78 na listovima formata A4 i A3 u skladu sa GOST 2.301-68, u pravilu, bez popunjavanja polja lista. Brojevi listova (stranica) se stavljaju na vrh lista iznad teksta. List odobrenja i naslovna stranica sastavljeni su u skladu sa GOST 19.104-78. Informativni dio (sažetak i sadržaj), list za registraciju promjena možda neće biti uključeni u dokument. Za izmjene i dopune tehničke pozadine u narednim fazama razvoja programa ili softverskog proizvoda, izdaje se dodatak tome. Usklađivanje i odobravanje dopuna projektnog zadatka vrši se na isti način kao što je utvrđeno za projektni zadatak. Projektni zadatak treba da sadrži sljedeće dijelove:

uvod; naziv i obim;

osnova za razvoj; svrha razvoja; tehnički zahtjevi za program ili softverski proizvod; tehničko-ekonomski pokazatelji; faze i faze razvoja; postupak kontrole i prihvatanja; aplikacije.

U zavisnosti od karakteristika programa ili softverskog proizvoda, dozvoljeno je razjasniti sadržaj sekcija, uvesti nove sekcije ili kombinovati neke od njih. Ako je potrebno, dozvoljeno je uključiti prijave u projektni zadatak. 2. Sadržaj odjeljaka

Uvod treba da sadrži kratak opis obima programa ili softverskog proizvoda, kao i objekta (na primjer, sistema) u kojem bi se trebao koristiti. Osnovna svrha uvoda je da se pokaže relevantnost ovog razvoja i pokaže koje mjesto ovaj razvoj zauzima među sličnim. U rubrici „Naziv i opseg“ navedite naziv, kratak opis opsega programa ili softverskog proizvoda i objekt u kojem se program ili softverski proizvod koristi. U odeljku Osnove za razvoj treba navesti sledeće:

dokument (dokumenta) na osnovu kojeg se vrši razvoj. Takav dokument može biti plan, nalog, ugovor itd.; organizacija koja je odobrila ovaj dokument i datum njegovog odobrenja; naziv i (ili) simbol razvojne teme. 2.4. Odjeljak Svrha razvoja treba da naznači funkcionalnu i operativnu svrhu programa ili softverskog proizvoda. 2.5. Odjeljak "Tehnički zahtjevi za program ili softverski proizvod" treba da sadrži sljedeće pododjeljke:

zahtjevi za performanse; zahtjevi za pouzdanost; pravila korištenja; zahtjeve za sastav i parametre tehničkih sredstava;

zahtjevi za kompatibilnost informacija i softvera;

zahtjevi za etiketiranje i pakovanje; zahtjevi za transport i skladištenje; posebne zahtjeve.

U pododjeljku "Zahtjevi za funkcionalne karakteristike" treba navesti zahtjeve za sastav izvršenih funkcija, organizaciju ulaznih i izlaznih podataka, vremenske karakteristike itd. U pododjeljku "Zahtjevi za pouzdanost" treba navesti zahtjeve za osiguranje pouzdanog rada (osiguranje stabilan rad, kontrola ulaznih i izlaznih informacija, vrijeme oporavka nakon kvara, itd.). U pododeljku „Uslovi rada“ treba navesti uslove rada (temperatura ambijentalnog vazduha, relativna vlažnost itd. za odabrane tipove nosača podataka) pod kojima treba obezbediti navedene karakteristike, kao i vrstu usluge, potreban broj i kvalifikacije osoblja. U pododjeljku "Zahtjevi za sastav i parametre tehničkih sredstava" navesti potrebni sastav tehničkih sredstava sa naznakom njihovih tehničkih karakteristika. U pododjeljku “Zahtjevi za kompatibilnost informacija i programa” treba navesti zahtjeve za informacijske strukture na ulazu i izlazu i metode rješenja, izvorne kodove, programske jezike. Gdje je potrebno, informacije i programi trebaju biti zaštićeni. U pododjeljku „Zahtjevi za označavanje i pakovanje“, u opštem slučaju, navedeni su zahtjevi za označavanje softverskih proizvoda, mogućnosti pakiranja i metode. U pododjeljku „Zahtjevi za transport i skladištenje“ moraju se navesti uslovi transporta, lokacije skladištenja, uslovi skladištenja, uslovi skladištenja, rokovi skladištenja pod različitim uslovima za softverski proizvod.

2.5.8. U odeljku "Tehničko-ekonomski pokazatelji" treba navesti: procenjenu ekonomsku efikasnost, procenjenu godišnju potrebu, ekonomske prednosti razvoja u odnosu na najbolje domaće i strane uzorke ili analoge.

U odeljku "Faze i faze razvoja" potrebne su faze razvoja, faze i sadržaj rada (spisak programskih dokumenata koji se moraju izraditi, usaglasiti i odobriti), kao i, po pravilu, vremenski okvir i utvrditi izvršioci su uspostavljeni. U odeljku „Procedura za kontrolu i prijem“ navesti vrste ispitivanja i opšte uslove za prijem radova. U aneksima projektnog zadatka, ako je potrebno, navedite:

spisak istraživačkih i drugih radova koji potkrepljuju razvoj; algoritamske šeme, tabele, opisi, opravdanja, proračuni i drugi dokumenti koji se mogu koristiti u razvoju; drugi izvori razvoja.

U slučajevima kada klijent ne iznese bilo kakve zahtjeve predviđene projektnim zadatkom, na odgovarajućem mjestu treba navesti „Nema zahtjeva“. Primjeri izrade projektnog zadatka dati su u dodacima B i C.

Radni nalog

Razvijte opis poslova za softverski proizvod prema vašoj verziji (pogledajte opcije u Dodatku A) Pripremite rad u skladu sa GOST 19.106-78. Za registraciju koristite MS Office. Pošaljite i zaštitite svoj rad.

Zaštita laboratorijskih izvještaja

Izvještaj o laboratorijskom radu treba biti sastavljen na osnovu STP-a i sastoji se od sljedećih strukturnih elemenata:

naslovna stranica; tekstualni dio; aplikacija: razvijena prema projektnom zadatku za softverski proizvod.

Tekstualni dio izvještaja treba da sadrži sljedeće stavke:

zadatak; nalog za izvršenje.

Učvršćeni izvještaj o laboratorijskom radu sastoji se od prezentovanja rezultata nastavniku u obliku datoteke i demonstracije stečenih vještina u odgovoru na pitanja nastavnika.

test pitanja

Dajte koncept modela životnog ciklusa softvera. Navedite faze razvoja softvera. Šta uključuje izjava o problemu i istraživanje prije projekta? Navedite funkcionalne i operativne zahtjeve za softverski proizvod. Navedite pravila za izradu tehničkih specifikacija. Navedite glavne dijelove projektnog zadatka.

Bibliografija

Bedrina S.L., Razvoj i standardizacija softvera. - Vladivostok: Izdavačka kuća VSUES, 2006. Blagodatskikh V.A., Volnin V.A., Poskakalov K.F. Standardizacija razvoja softvera. - M: Financije i statistika, 2003. GOST 19.102-77 ESPD. Faze razvoja

Aneks A

Opcije zadatka

Za istu opciju izvode se laboratorijski radovi br. 1-5.

Razviti softverski modul „Obračun napretka učenika“. Softverski modul je dizajniran tako da promptno bilježi napredak studenata na sjednici od strane dekana, prodekana i dekanskog osoblja. Podatke o napredovanju studenata treba čuvati tokom čitavog perioda studiranja i koristiti u pripremi potvrda o položenim predmetima i dodataka diplomi. Razviti programski modul "Lični dosijei studenata". Softverski modul je namijenjen za dobijanje informacija o studentima od strane radnika dekanata, sindikalnog odbora i kadrovske službe. Podaci se moraju čuvati tokom čitavog perioda školovanja učenika i koristiti u izradi potvrda i izvještaja. Razviti softverski modul "Rješenje kombinatornih optimizacijskih problema". Modul treba da sadrži algoritme za pronalaženje ciklusa minimalne dužine (problem trgovačkog putnika), pronalaženje najkraće staze i pronalaženje minimalnog razapinjućeg stabla. Razviti softverski modul "Matrična obrada". Modul treba da sadrži algoritme za pronalaženje zbira i proizvoda elemenata matrice po redovima i kolonama, kao i izračunavanje prosječne, minimalne i maksimalne vrijednosti u matrici. Razviti Windows aplikaciju "Organizator". Aplikacija je dizajnirana za snimanje, pohranjivanje i traženje adresa i brojeva telefona pojedinaca i organizacija, kao i rasporeda, sastanaka itd. Aplikacija je dizajnirana za svakog korisnika računara. Razvijte aplikaciju Windows Calculator. Aplikacija je namijenjena svakom korisniku i treba da sadrži sve aritmetičke operacije (u odnosu na prioritete) i po mogućnosti (ali nije obavezno) nekoliko matematičkih funkcija. Razviti softverski modul "Odsjek", koji sadrži podatke o osoblju odsjeka (naziv, položaj, akademski stepen, discipline, opterećenje, socijalni rad, honorarni rad, itd.). Modul je namijenjen za korištenje zaposlenima u kadrovskoj službi i dekanatu. Razviti softverski modul "Laboratorija", koji sadrži podatke o osoblju laboratorije (ime, pol, godine, bračno stanje, prisustvo djece, radno mjesto, akademski stepen). Modul je namijenjen za korištenje zaposlenima u sindikalnim odborima i kadrovskoj službi. Razviti programski modul "Kemijsko čišćenje". Prilikom registracije za uslugu popunjava se prijava u kojoj se navodi puno ime vlasnika, opis proizvoda, vrsta usluge, datum prijema narudžbe i cijena usluge. Nakon obavljenog posla, štampa se račun. Razviti softverski modul "Obračun kršenja saobraćajnih pravila". Za svaki automobil (i njegovog vlasnika) lista prekršaja se pohranjuje u bazi podataka. Za svaki prekršaj evidentira se datum, vrijeme, vrsta prekršaja i visina kazne. Kada se plate sve kazne, auto se briše iz baze podataka. Razviti softverski modul "Kartoteka autoshopa", namijenjen za korištenje zaposlenima u agenciji. Baza podataka sadrži informacije o automobilima (marka, veličina motora, datum izdavanja, itd.). Kada se primi zahtjev za kupovinu, traži se odgovarajuća opcija. Ako to nije slučaj, klijent se unosi u bazu klijenata i obavještava se kada se pojavi opcija. Razviti softverski modul "Kartoteka pretplatnika ATS-a". Kartica sadrži informacije o telefonima i njihovim vlasnicima. Popravlja zaostale obaveze (pretplatničke i vremenske). Vjeruje se da je već uvedeno plaćanje po satu lokalnih telefonskih poziva. Razviti softverski modul "Avtokassa", koji sadrži informacije o raspoloživosti mjesta na autobuskim linijama. Baza podataka treba da sadrži podatke o broju leta, ruti, vozaču, vrsti autobusa, datumu i vremenu polaska, kao i cijene karata. Kada se primi zahtjev za karte, program traži odgovarajući let. Razviti softverski modul "Knjižara", koji sadrži podatke o knjigama (autor, naslov, izdavač, godina izdanja, cijena). Kupac popunjava aplikaciju za knjige koje su mu potrebne, ako ih nema, unosi se u bazu podataka i obavještava se kada potrebne knjige stignu u radnju. Razviti softverski modul "Parking". Program sadrži informacije o marki automobila, njegovom vlasniku, datumu i vremenu ulaska, troškovima parkiranja, popustima, zaostalim plaćanjima itd. Razviti softverski modul Agencije za zapošljavanje koji sadrži informacije o slobodnim radnim mjestima i životopisima. Softverski modul je dizajniran kako za pronalaženje radnika koji ispunjava zahtjeve menadžera kompanije, tako i za pronalaženje odgovarajućeg posla.

Bilješka. Kada razvijate program, nemojte se ograničavati na funkcije date u varijanti, dodajte nekoliko svojih funkcija. Obavezno je koristiti strukturne i modularne pristupe programiranju.

Aneks B

Primjer 1 Izraditi projektni zadatak za softverski proizvod dizajniran da učenicima vizualno demonstrira grafove funkcija jednog argumenta y= f(x). Program koji se razvija mora izračunati tablicu vrijednosti i izgraditi graf funkcija na datom segmentu prema datoj formuli i promijeniti korak argumenta i granice segmenta. Osim toga, program mora zapamtiti unesene formule.

1. Uvod

Ovaj projektni zadatak odnosi se na razvoj programa za sortiranje jednodimenzionalnog niza metodom mjehurića, direktne selekcije, Shell i brzog sortiranja, namijenjenog za korištenje srednjoškolcima prilikom izučavanja školskog kursa informatike. 2. Fondacija za razvoj

Program je razvijen na osnovu nastavnog plana i programa Odsjeka za računarstvo i softver računarski sistemi". Naziv posla:

"Program za sortiranje jednodimenzionalnog niza".

Izvršilac: kompanija BcstSoft. Saradnici: ist.

3. Imenovanje Program je namijenjen za korištenje školarcima prilikom izučavanja teme "Obrada jednodimenzionalnih nizova" na predmetu "Informatika". 4. Zahtjevi za program ili softverski proizvod 4.1. zahtjevi performansi 4.1.1. Program bi trebao pružiti mogućnost izvođenja sljedećih funkcija:

unos veličine niza i samog niza; niz i memorija za pohranu; izbor metode sortiranja; prikaz tekstualnog opisa metode sortiranja; izlaz rezultata sortiranja.

4.1.2. Početni podaci:

veličina niza, data kao cijeli broj; niz.

Organizacija ulaznih i izlaznih podataka.

Unos dolazi sa tastature. Rezultat se prikazuje na ekranu i, ako je potrebno, štampa.

Zahtjevi za pouzdanost

Omogućite kontrolu nad ulaznim informacijama. Osigurati blokiranje pogrešnih radnji korisnika pri radu sa sistemom.

Zahtjevi za sastav i parametre tehničkih sredstava.

Sistem mora raditi na IBM-kompatibilnim personalnim računarima. Minimalna konfiguracija:

tip procesora Pentium ili noviji; količina memorije sa slučajnim pristupom 32 MB ili više; količina slobodnog prostora na tvrdom disku je 40 MB.

Preporučena konfiguracija:

tip procesora Pentium II 400; količina memorije sa slučajnim pristupom 128 MB; količina slobodnog prostora na tvrdom disku je 60 MB.

4.4. Zahtjevi za kompatibilnost softvera.
Program mora da radi pod Win 32 familijom operativnih sistema (Windows 95/98/2000/ME/XP, itd.).

Razvijeni softverski moduli moraju biti samodokumentirajući, odnosno programski tekstovi moraju sadržavati sve potrebne komentare. Izrađeni program treba da sadrži pozadinske informacije o radu programa, opisima metoda sortiranja i savjetima za studente. Prateća dokumentacija treba da sadrži:

Objašnjenje na pet listova, sa opisom razvoja. Korisnički vodič.

Aneks B

Primjer 2 Izraditi projektni zadatak za razvoj „Modula za automatizovani sistem za operativnu dispečersku kontrolu snabdevanja toplotom u zgradama Moskovskog instituta“.

1. Uvod

Radovi se odvijaju u okviru projekta „Automatizovani sistem operativne dispečerske kontrole snabdevanja električnom toplotom zgrada Moskovskog instituta“. 2. Fondacija za razvoj

Osnov za ovaj posao je ugovor broj 1234 od 10.03.2003.

Naziv posla:

"Modul automatizovanog sistema za operativno dispečersko upravljanje snabdevanjem toplotom zgrada Moskovskog instituta."

Izvođači: OJSC "Laboratorija za kreiranje softvera".

Pratioci: ne.

3. Svrha razvoja Izrada modula za praćenje i operativno prilagođavanje stanja glavnih parametara obezbeđenja zgrada Moskovskog instituta. 4. Tehnički zahtjevi 4.1. zahtjevi performansi. 4.1.1. Sastav izvršenih funkcija. Razvijeni softver treba da obezbedi:

prikupljanje i analiza informacija o utrošku toplotne, tople i hladnom vodom prema SA-94 mjeračima topline na svim toplinskim otvorima; prikupljanje i analiza informacija sa upravljačkih uređaja za sisteme grijanja zraka i klimatizacije kao što su RT1 i RT2 (izrada Odjeljenja za SMME i TC); preliminarna analiza informacija u cilju pronalaženja parametara u prihvatljivim granicama i signalizacija kada parametri prelaze granice tolerancije;

izdavanje preporuka o dalji rad;

prikaz trenutnog stanja po skupu parametara - ciklično konstantno (rad non-stop), uz održavanje učestalosti praćenja ostalih parametara; vizualizacija informacija o potrošnji rashladne tekućine:

struja, slična očitanjima brojila; sa akumulacijom za prošli dan, sedmicu, mjesec - u obliku satnog grafikona za informacije za dan i sedmicu; dnevna potrošnja - za informaciju za mjesec.

Za uređaje za kontrolu dovodne ventilacije, trenutne informacije moraju sadržavati broj dovodnog sistema i sve parametre prikazane na vlastitom indikatoru. Na zahtjev se vrše interna podešavanja. Na kraju izvještajnog perioda, sistem mora arhivirati podatke. 4.1.2. Organizacija ulaznih i izlaznih podataka. Početni podaci ulaze u sistem u obliku vrijednosti sa senzora instaliranih u prostorijama instituta. Ove vrijednosti se prikazuju na kompjuteru dispečera. Nakon analize primljenih informacija, operater kontrolne sobe postavlja potrebne parametre za uređaje koji regulišu grijanje i ventilaciju u prostorijama. Također je moguće automatski postaviti neke parametre za upravljačke uređaje. Glavni način korišćenja sistema je svakodnevni rad. 4.2. zahtjevi za pouzdanost. Da bi se osigurala pouzdanost, potrebno je provjeriti ispravnost podataka primljenih od senzora. 4.3. Uslovi rada i zahtevi za sastav i parametre tehničkih sredstava. Za rad sistema mora biti dodijeljen odgovorni operater. Zahtjevi za sastav i parametre tehničkih sredstava utvrđuju se u fazi idejnog projekta sistema. 4.4. Zahtjevi za informacije i kompatibilnost softvera. Program mora raditi na Windows 98/NT/2000 platformama.

4.5. Zahtjevi za transport i skladištenje.

Program se isporučuje na laserskom nosaču podataka. Programska dokumentacija se dostavlja u elektronskom i štampanom obliku. 4.6. Posebni zahtjevi:

softver mora imati interfejs prilagođen korisniku dizajniran za kvalifikacije korisnika (u smislu kompjuterske pismenosti); zbog obima projekta predviđeno je da se zadaci rješavaju po fazama, dok softverski moduli kreirani u različito vrijeme treba da obezbijede mogućnost proširenja sistema i da budu međusobno kompatibilni, pa je stoga dokumentacija za usvojenu operativnu softver treba da sadrži pune informacije potrebno da programeri rade s njim; programski jezik - po izboru izvođača, treba da obezbedi mogućnost integracije softvera sa nekim vrstama periferne opreme (npr. SA-94 brojač i sl.).

5. Zahtjevi za softversku dokumentaciju Glavni dokumenti koji regulišu razvoj budućih programa treba da budu dokumenti Jedinstvenog sistema programske dokumentacije (ESPD): uputstvo za upotrebu, uputstvo za administratore, opis aplikacije. 6. Tehnički i ekonomski pokazatelji Efikasnost sistema određena je jednostavnošću korišćenja sistema za praćenje i upravljanje glavnim parametrima snabdevanja toplotom u prostorijama Moskovskog instituta, kao i ekonomskom dobiti koja se dobija od implementacije hardversko-softverskog kompleksa. 7. Postupak kontrole i prihvatanja Nakon što Izvođač prenese poseban funkcionalni modul programa Naručiocu, isti ima pravo da testira modul u roku od 7 dana. Nakon testiranja, Kupac mora prihvatiti rad za ovu fazu ili pismeno navesti razlog odbijanja prihvata. U slučaju opravdanog odbijanja, Izvođač se obavezuje da modifikuje modul.

1. Projektni zadatak za nabavku opreme za razvoj informatičke infrastrukture vatrogasne službe i hitne službe. Predmet državnog ugovora

   Tehnički zadatak

   za nabavku opreme za razvoj informaciono-tehnološke infrastrukture vatrogasne službe i hitne službe.

2. Projektni zadatak za kompleks projektantskih i građevinskih radova

   Tehnički zadatak

   2.1. Izvođenje radova prema ovom projektnom zadatku podrazumijeva izvođenje od strane Izvođača cjelokupnog spektra istraživanja, projektovanja i građevinski radovi za rekonstrukciju (preopremanje, preuređenje) građevinskog objekta po sistemu ključ u ruke, uklj.

3. Projektni zadaci za realizaciju radova na izradi stranice listova

   Tehnički zadatak

   zahtjevi RD 50-34.698-90 „Smjernice. Informaciona tehnologija. Skup standarda i smjernica za automatizovani sistemi.

4. Projektni zadatak za provođenje istraživanja tehničkog stanja stambenih zgrada za velike popravke. Niskostrujni sistem. Komunikacija, alarm, sigurnost

   Tehnički zadatak

   Automatski sistem za dojavu požara, kao i sistem za upozorenje i kontrolu evakuacije, sastavni je dio sistema za održavanje života zgrada.

5. Projektni zadatak Lot br. 1 Nabavka strane literature za biblioteku SevKavgtu

   Tehnički zadatak

   Procedura utvrđivanja cijene ugovora: cijena ugovora mora uključivati ​​sve troškove Dobavljača u vezi sa ispunjenjem ugovora, uključujući troškove isporuke, istovar literature u prostorije biblioteke, plaćanje PDV-a i plaćanje

6. Projektni zadatak za dokumentaciju na otvorenoj aukciji u elektronskoj formi broj 624-ea za pravo zaključivanja

   Tehnički zadatak

   2. Uslovi za rok i (ili) obim davanja garancija kvaliteta proizvoda: garantni rok za isporučeni proizvod mora biti najmanje 24 meseca od dana puštanja u rad.

U ovom članku pokušao sam detaljno razmotriti problem izrade Projektnog zadatka. Tema je stara koliko i problem. Ali i dalje se često rješava "kako ide".
Kao što je Henry Shaw rekao: "Najviše nas brinu male stvari: lakše je izbjeći slona nego muvu."

Izrada tehničkih specifikacija. Šta je to, zašto je potrebno, odakle početi i kako bi trebalo da izgleda?

O čemu je ovaj članak?

Često me pitaju: "Kako izraditi tehnički zadatak za automatizovani sistem?". O sličnoj temi se stalno raspravlja na raznim forumima. Ovo pitanje je toliko široko da je nemoguće odgovoriti ukratko. Stoga sam odlučio da napišem poduži članak na ovu temu. U procesu rada na članku shvatio sam da ne bi uspjelo sve staviti u jedan članak, jer. ispast će ispod 50 stranica i odlučio sam ga podijeliti na 2 dijela:

• U prvom dijelu" Izrada tehničkih specifikacija. Šta je to, zašto je potrebno, odakle početi i kako bi trebalo da izgleda? Pokušat ću detaljno odgovoriti na pitanja iz teme, razmotriti strukturu i svrhu Projektnog zadatka i dati neke preporuke o formuliranju zahtjeva.
• Drugi dio" Izrada tehničkih specifikacija. Kako formulisati zahteve? biće u potpunosti posvećen identifikaciji i formulisanju zahteva za informacioni sistem.

Prvo morate shvatiti koje pitanje zaista zanima one koji pitaju "Kako razviti tehnički zadatak?" Činjenica je da će pristup izradi tehničkih specifikacija u velikoj mjeri ovisiti o svrhama u koje se to radi, kao io tome ko će ga koristiti. O kojim opcijama govorim?

• 
  Jedna komercijalna organizacija odlučila je da implementira automatizovani sistem. Nema sopstveni IT servis i odlučio je da uradi sledeće: Zainteresovana osoba mora izraditi Projektni zadatak i dati ga na razvoj trećoj organizaciji;
• Jedna komercijalna organizacija odlučila je da implementira automatizovani sistem. Ima sopstvenu IT uslugu. Odlučili smo da uradimo ovo: izradimo Projektni zadatak, zatim ga koordiniramo između IT službe i zainteresovanih strana i implementiramo ga sami;
• Državna struktura odlučila je da pokrene IT projekat. Ovdje je sve tako blatnjavo, puno formalnosti, mitinga, rezova itd. Ovu opciju neću razmatrati u ovom članku.
• IT kompanija se bavi uslugama razvoja i/ili implementacije automatizovanih sistema. Ovo je najviše težak slučaj, jer morate raditi u raznim uslovima:
  • Klijent ima svoje stručnjake sa sopstvenim stavovima, i oni imaju specifične zahteve za Projektni zadatak;
  • Projektni zadaci su razvijeni za naše vlastite programere (klijenta nije briga);
  • Projektni zadaci se izrađuju za prijenos na izvođača (tj. grupu programera koji su izvan osoblja kompanije, ili pojedinog stručnjaka);
  • Postoji nesporazum između kompanija i klijenta u vezi sa postignutim rezultatom, a kompanija iznova postavlja pitanje: „Kako treba izraditi Projektni zadatak?“. Potonji slučaj može izgledati kao paradoks, ali je istina.
  • Moguće su i druge, manje uobičajene opcije;

Mislim da bi sada čitalac trebalo da ima pitanja:

• Zašto se projektni zadatak ne može razvijati uvijek na isti način?
• Postoje li neki standardi, metode, preporuke? Gdje ih nabaviti?
• Ko bi trebao izraditi Projektni zadatak? Da li ova osoba mora imati neka posebna znanja?
• Kako razumjeti da li je projektni zadatak dobro napisan ili ne?
• O čijem trošku ga treba razvijati i da li je uopšte potrebno?

Ova lista bi mogla biti beskonačna. Govorim tako samouvjereno jer se bavim profesionalnim razvojem softvera već 15 godina, a pitanje projektnog zadatka se pojavljuje u svakom timu programera s kojim moram raditi. Razlozi za to su različiti. Pokrećući temu izrade Projektnog zadatka, dobro sam svjestan da ga neću moći 100% prezentirati za sve zainteresovane za ovu temu. Ali, pokušaću, kako kažu, "sve staviti na police". Oni koji su već upoznati sa mojim člancima znaju da ne koristim "copy-paste" tuđe radove, ne preštampam tuđe knjige, ne citiram standarde na više stranica i druge dokumente koje i sami možete pronaći na internetu, propuštajući ih kao svoje briljantne misli. Dovoljno je da u pretraživač ukucate "Kako izraditi Projektni zadatak" i moći ćete pročitati mnogo zanimljivog, ali, nažalost, mnogo puta ponovljenog. U pravilu, oni koji vole da budu pametni na forumima (pokušajte ipak pretraživati!), nikada sami nisu napravili razuman projektni zadatak i neprestano citiraju preporuke GOST-a po ovom pitanju. A oni koji se zaista ozbiljno bave ovim pitanjem obično nemaju vremena da sjede po forumima. Usput, razgovarat ćemo i o GOST-ovima. Tokom godina mog rada, video sam mnoge varijante tehničke dokumentacije koju su sastavljali kako pojedinačni stručnjaci, tako i eminentni timovi i konsultantske kuće. Ponekad radim i takve aktivnosti: odvajam vrijeme za sebe i tražim informacije o temi koja me zanima iz neobičnih izvora (kao što je malo inteligencije). Kao rezultat toga, morao sam vidjeti dokumentaciju o takvim čudovištima kao što su Gazprom, Ruske željeznice i mnoge druge zanimljive kompanije. Naravno, pridržavam se politike povjerljivosti, uprkos činjenici da mi ovi dokumenti dolaze iz javnih izvora ili neodgovornosti konsultanata (razbacuju informacije po internetu). Stoga odmah kažem: ne dijelim povjerljive informacije koje pripadaju drugim kompanijama, bez obzira na izvore nastanka (profesionalna etika).

Šta je tehnički zadatak?

Prva stvar koju ćemo sada uraditi je da shvatimo o kakvoj se životinji radi, “Zahtjev za rad”.

Da, zaista postoje GOST-ovi i standardi u kojima se pokušava regulirati ovaj dio aktivnosti (razvoj softvera). Nekada su svi ovi GOST-ovi bili relevantni i aktivno korišteni. Sada postoje različita mišljenja o relevantnosti ovih dokumenata. Neki tvrde da su GOST-ove razvili vrlo dalekovidi ljudi i da su još uvijek relevantni. Drugi kažu da su beznadežno zastarjeli. Možda je neko sada pomislio da je istina negdje na sredini. Odgovorio bih Geteovim rečima: „Kažu da između dva suprotna mišljenja leži istina. Ni u kom slučaju! Između njih leži problem." Dakle, između ovih mišljenja nema istine. Jer GOST-ovi ne otkrivaju praktične probleme modernog razvoja, a oni koji ih kritikuju ne nude alternative (specifične i sistemske).

Imajte na umu da GOST jasno ne daje čak ni definiciju, već samo kaže: „Terminal za nuklearnu elektranu je glavni dokument koji definiše zahtjeve i proceduru za stvaranje (razvoj ili modernizaciju - daljnje stvaranje) automatiziranog sistema, u skladu sa koji se vrši izrada NEK i njen prijem nakon puštanja u rad."

Ako se neko pita o kojim GOST-ovima govorim, evo ih:

• GOST 2.114-95 jedan sistem projektnu dokumentaciju. Specifikacije;
• GOST 19.201-78 Jedinstveni sistem programske dokumentacije. Tehnički zadatak. Zahtjevi za sadržaj i dizajn;
• GOST 34.602-89 Informaciona tehnologija. Set standarda za automatizovane sisteme. Projektni zadatak za kreiranje automatizovanog sistema.

Mnogo bolja definicija je predstavljena na Wikipediji (istina o TK-u općenito, a ne samo za softver): “ Tehnički zadatak je originalni projektni dokument tehnički objekt. Tehnički zadatak utvrđuje glavnu namjenu objekta koji se razvija, njegove tehničko-taktičko-tehničke karakteristike, pokazatelje kvaliteta i tehničko-ekonomske zahtjeve, uputstva za završetak potrebnih faza izrade dokumentacije (projektantske, tehnološke, softverske i dr.) i njen sastav, kao i kao i posebne zahtjeve. Zadatak kao izvorni dokument za kreiranje nečeg novog postoji u svim oblastima delatnosti, koji se razlikuje po nazivu, sadržaju, redosledu izvođenja itd. (npr. projektantski zadatak u građevinarstvu, borbeni zadatak, domaći zadatak, ugovor za književno djelo itd.)"

I tako, kao što slijedi iz definicije, glavna svrha Projektnog zadatka je da formuliše zahtjeve za objekt koji se razvija, u našem slučaju, za automatizirani sistem.

To je glavni, ali jedini. Vrijeme je da preuzmete glavnu stvar: da sve stavite "na police", kao što je obećano.

Šta trebate znati o zahtjevima? Mora se jasno shvatiti da svi zahtjevi moraju biti podijeljeni po vrsti i svojstvima. Sada ćemo naučiti kako to učiniti. Da odvojimo zahtjeve prema vrsti, GOST će nam samo pomoći. Spisak tipova zahteva koji je tamo predstavljen je dobar primer o tome koje vrste zahteva treba uzeti u obzir. Na primjer:

• zahtjevi funkcionalnosti;
• Zahtjevi za sigurnost i prava pristupa;
• Zahtjevi za kvalifikacijom osoblja;
• …. itd. O njima možete pročitati u spomenutom GOST-u (a u nastavku ću ih također razmotriti malo detaljnije).

Mislim da vam je očigledno da su dobro formulisani zahtjevi za funkcionalnošću ključ uspješnog Projektnog zadatka. Upravo tim zahtjevima posvećena je većina radova i metoda o kojima sam govorio. Zahtjevi funkcionalnosti su 90% složenosti izrade Projektnog zadatka. Sve ostalo je često "kamuflaža" koja se stavlja na ove zahtjeve. Ako su zahtjevi loše formulirani, onda bez obzira kakvu lijepu kamuflažu stavite na njih, uspješan projekt neće uspjeti. Da, formalno će svi zahtjevi biti ispunjeni (prema GOST J), TOR je razvijen, odobren i potpisan, a novac je za to primljen. Pa šta? A onda počinje zabava: šta da se radi? Ako je ovo projekt na državnom nalogu, onda nema problema - postoji takav budžet da neće stati ni u jedan džep, sve će se razjasniti u procesu implementacije (ako postoji). Tacno tako se pilje vecina budzeta projekata po drzavnim narudzbinama (zapalili "TK", spojili deset miliona, ali nisu poceli da rade projekat. Ispunjene su sve formalnosti, nije bilo krivih, novi auto blizu kuća. Ljepota!). Ali mi pričamo o tome komercijalne organizacije gdje se računa novac, a potreban je drugačiji rezultat. Stoga, hajde da se pozabavimo glavnom stvari, kako se razvijati korisni i radni Zadaci.

Rekao sam o vrstama zahtjeva, ali šta je sa svojstvima? Ako vrste zahtjeva mogu biti različite (ovisno o ciljevima projekta), onda je sa svojstvima sve jednostavnije, postoje 3 njih:

1. Zahtjev mora biti razumljivo;
2. Zahtjev mora biti specifično;
3. Zahtjev mora biti testirano;

Štaviše, posljednje svojstvo je nemoguće bez dva prethodna, tj. je svojevrsni "lakmus test". Ako se rezultat zahtjeva ne može testirati, onda on ili nije jasan ili nije specifičan. Razmisli o tome. U posedovanju ova tri svojstva zahteva leže veština i profesionalizam. U stvari, sve je vrlo jednostavno. Kad to shvatiš.

Ovu priču o tome šta je Projektni zadatak, moglo bi se završiti i preći na ono glavno: kako formulisati zahtjeve. Ali nije sve tako brzo. Postoji još jedna izuzetno važna tačka:

• na kom jeziku (u smislu složenosti razumijevanja) treba napisati projektni zadatak?
• Treba li u njemu opisati specifikaciju različitih funkcija, algoritama, tipova podataka i drugih tehničkih stvari?
• A šta je tehnički dizajn, koji se, inače, također spominje u GOST-ovima, i kako je povezan s Projektnim zadatkom?

Postoji jedna vrlo podmukla stvar u odgovorima na ova pitanja. Zbog toga se često javljaju sporovi o dovoljnosti ili nepostojanju potrebnih detaljnih zahtjeva, o razumljivosti dokumenta od strane Naručioca i Izvođača, o redundantnosti, formatu prezentacije itd. A gdje je granica između projektnog zadatka i tehničkog projekta?

Tehnički zadatak je dokument zasnovan na zahtjevima formulisanim na jeziku koji je razumljiv (uobičajen, poznat) Kupcu. U ovom slučaju se može i treba koristiti terminologija koja je razumljiva Kupcu. Ne bi trebalo biti nikakvih vezivanja za karakteristike tehničke implementacije. One. u fazi TK, u principu, nije bitno na kojoj će platformi ovi zahtjevi biti implementirani. Iako postoje izuzeci. Ako je riječ o implementaciji sistema baziranog na postojećem softverskom proizvodu, onda se takvo uvezivanje može dogoditi, ali samo na nivou ekranskih obrazaca, obrazaca izvještaja itd. poslovni analitičar. I sigurno ne programer (osim ako ne kombinuje ove uloge, to se dešava). One. ova osoba treba da razgovara sa Klijentom na jeziku njegovog poslovanja.

Tehnički projekat- ovo je dokument koji je namijenjen tehničkoj implementaciji zahtjeva formuliranih u projektnom zadatku. Upravo ovaj dokument opisuje strukture podataka, pokretače i pohranjene procedure, algoritme i druge stvari koje će biti potrebne tehnički stručnjaci. Uopšte nije neophodno da se kupac upušta u ovo (možda ne razume takve uslove). Tehnički projekat radi System Architect(Ovdje je kombinacija ove uloge sa programerom sasvim normalna). Ili bolje rečeno, grupa stručnjaka na čelu sa arhitektom. Što je projekat veći, više ljudi radi na Projektnom zadatku.

Šta imamo u praksi? Smiješno je gledati kada direktora dovode na odobrenje Projektni zadatak, koji je prepun tehničke terminologije, opisa tipova podataka i njihovih vrijednosti, strukture baze podataka itd. On se, naravno, trudi da razumije, jer je to neophodno tvrditi, pokušavajući pronaći poznate riječi između redova i ne izgubiti poslovne zahtjeve lanca. Šta, poznata situacija? I kako se to završava? Takav TOR se po pravilu odobrava, potom sprovodi i u 80% slučajeva onda uopšte ne odgovara činjenici obavljenog posla, jer mnogo stvari su odlučili da promene, poprave, pogrešno shvatili, pogrešno mislili itd. itd. A onda počinje serija primopredaje. “Ali ovdje nije onako kako nam treba”, već “neće nam uspjeti”, “previše je komplikovano”, “nezgodno je” itd. Poznat?! Tako da znam, morao sam na vrijeme popuniti neravnine.

Dakle, šta imamo u praksi? Ali u praksi imamo zamagljenu granicu između projektnog zadatka i tehničkog projekta. Lebdi između TK i TP na razne načine. I to je loše. A ispada jer je razvojna kultura oslabila. To je dijelom zbog kompetentnosti stručnjaka, dijelom zbog želje za smanjenjem budžeta i rokova (na kraju krajeva, dokumentacija oduzima puno vremena - to je činjenica). Postoji još jedan važan faktor koji utiče na upotrebu tehničkog projekta kao zasebnog dokumenta: brzi razvoj alata za brzi razvoj, kao i razvojnih metodologija. Ali ovo je posebna priča, o tome ću reći nekoliko riječi u nastavku.

Još jedna mala, ali važna tačka. Ponekad se Projektni zadaci nazivaju malim zahtjevima, jednostavnim i razumljivim. Na primjer, da biste precizirali pretragu objekta prema nekim uvjetima, dodajte kolonu u izvještaj itd. Ovakav pristup je sasvim opravdan, čemu komplicirati život. Ali ne koristi se na velikim projektima, već na manjim poboljšanjima. Rekao bih da je ovo bliže održavanju softverskog proizvoda. U ovom slučaju, Projektni zadaci mogu također opisati određene tehničko rješenje implementacija zahtjeva. Na primjer, "Učiniti takvu i takvu promjenu u algoritmu", što ukazuje na specifičnu proceduru i specifičnu promjenu za programera. To je slučaj kada je granica između projektnog zadatka i tehničkih projekata potpuno izbrisana, jer ne postoji ekonomska izvodljivost da se naduvava papirologija tamo gde nije potrebna, a stvara se koristan dokument. I to je tačno.

Da li vam je zaista potrebna tehnička specifikacija? Šta je sa inženjerskim projektom?

Jesam li pregrijana? Da li je ovo uopšte moguće bez projektni zadatak? Zamislite možda (tačnije, javlja se), a ovaj pristup ima mnogo sljedbenika, a njihov broj se povećava. U pravilu, nakon što mladi stručnjaci pročitaju knjige o Scrum-u, Agile-u i drugim tehnologijama brzog razvoja. Zapravo, ovo su divne tehnologije i rade, samo što ne kažu doslovno „nema potrebe za tehničkim poslovima“. Kažu „minimum papirologije“, posebno nepotrebne, bliže Kupcu, više konkretnih stvari i brži rezultati. Ali niko nije otkazao fiksiranje uslova i to je tamo jasno navedeno. Tu se utvrđuju zahtjevi na osnovu tri divna svojstva o kojima sam gore govorio. Samo što je kod nekih svest uređena tako da ako se nešto može pojednostaviti, hajde da uprostimo do potpunog odsustva. Kao što je Ajnštajn rekao " Neka bude što jednostavnije, ali ne jednostavnije od toga." . Zlatne riječi idu uz sve. Tako da Tehnički zadatak neophodno, inače nećete vidjeti uspješan projekat. Drugo je pitanje kako komponovati i šta tu uključiti. U svjetlu metodologija brzog razvoja, morate se fokusirati samo na zahtjeve, a sva "kamuflaža" se može odbaciti. U suštini, slažem se sa ovim.

Šta je sa tehničkim projektom? Ovaj dokument je veoma koristan i nije izgubio na važnosti. Štaviše, često je jednostavno nemoguće bez toga. Pogotovo kada je u pitanju outsourcing razvojnih poslova, tj. po principu outsourcinga. Ako se to ne učini, postoji rizik da naučite mnogo o tome kako bi sistem koji imate na umu trebao izgledati. Treba li ga kupac upoznati? Ako hoće zašto ne, ali insistirajte i tvrdite ovaj dokument nema potrebe, samo će kočiti i ometati rad. Gotovo je nemoguće dizajnirati sistem do najsitnijih detalja. U tom slučaju ćete morati kontinuirano unositi izmjene u Tehnički dizajn, što oduzima dosta vremena. A ako je organizacija jako birokratizirana, onda općenito ostavite sve živce tamo. Upravo se o ovoj vrsti smanjenja dizajna raspravlja u savremenim metodologijama brzog razvoja, koje sam već spomenuo. Inače, svi su bazirani na klasičnom pristupu XP (ekstremno programiranje), starom već oko 20 godina. Zato napravite visokokvalitetan Projektni zadatak, razumljiv kupcu, i koristite Tehnički dizajn kao interni dokument za odnos između arhitekte sistema i programera.

Zanimljiv detalj o tehničkom dizajnu: neki razvojni alati raspoređeni po principu predmetne orijentacije (kao što je 1C i slično) sugeriraju da je dizajn (što znači proces dokumentacije) potreban samo za stvarno teška područja, gdje je potrebna interakcija između cijelih podsistema. U najjednostavnijem slučaju, na primjer, za kreiranje referentne knjige, dokumenta, dovoljni su samo pravilno formulirani poslovni zahtjevi. O tome svjedoči i poslovna strategija ove platforme u smislu obuke stručnjaka. Ako pogledate ispitni list nekog specijaliste (tako se zove, a ne „programera“), vidjet ćete da tu postoje samo poslovni zahtjevi, a kako ih implementirati u programskom jeziku je zadatak specijalista. One. onaj dio zadatka za koji je tehnički projekt osmišljen da riješi, specijalista mora riješiti „u glavu“ (govorimo o zadacima srednje složenosti), a ovdje i sada, slijedeći određene standarde razvoja i dizajna, koji su opet formirana od strane 1C kompanije za svoju platformu. Tako, od dva specijalista, čiji rezultat rada izgleda isto, jedan može da položi ispit, a drugi ne, jer. grubo narušeni razvojni standardi. Odnosno, očigledno se pretpostavlja da stručnjaci moraju imati takve kvalifikacije da mogu sami dizajnirati tipične zadatke, bez uključivanja sistemskih arhitekata. I ovaj pristup funkcionira.

Nastavimo proučavanje pitanja: "Koje zahtjeve treba uključiti u Projektni zadatak?"

Formulisanje zahteva za informacioni sistem. Struktura projektnog zadatka

Odmah da razjasnimo: govorit ćemo o formulaciji zahtjeva za informacioni sistem, tj. pod pretpostavkom da su poslovi razvoja poslovnih zahtjeva, formalizacije poslovnih procesa i svi dosadašnji konsultantski poslovi već završeni. Naravno, neke dorade se mogu izvesti u ovoj fazi, ali samo dorade. Sam projekat automatizacije ne rješava poslovne probleme - imajte to na umu. Ovo je aksiom. Iz nekog razloga, neki menadžeri to pokušavaju opovrgnuti, vjerujući da će, ako kupe program, red doći u haotičnom poslu. Ali na kraju krajeva, aksiom je aksiom koji ne zahtijeva dokaz.

Kao i kod svake aktivnosti, formulacija zahtjeva se može (i treba) podijeliti u faze. Sve ima svoje vrijeme. Ovo je težak intelektualni rad. A ako se tretira s nedovoljnom pažnjom, onda će rezultat biti odgovarajući. Prema procjenama stručnjaka, troškovi izrade Projektnog zadatka mogu biti 30-50%. Ja sam istog mišljenja. Iako je 50 možda previše. Uostalom, Projektni zadatak nije posljednji dokument koji treba izraditi. Uostalom, mora postojati i tehnički dizajn. Ova varijacija je zbog različitih platformi za automatizaciju, pristupa i tehnologija koje koriste projektni timovi tokom razvoja. Na primjer, ako govorimo o razvoju na klasičnom jeziku kao što je C++, onda je detaljan tehnički dizajn neophodan. Ako govorimo o implementaciji sistema na 1C platformi, onda je situacija s dizajnom nešto drugačija, kao što smo vidjeli gore (iako je, kada se razvija sistem od nule, dizajniran prema klasičnoj shemi).

Unatoč činjenici da je izjava o zahtjevima glavni dio Projektnog zadatka, au nekim slučajevima postaje i jedini dio TOR-a, treba obratiti pažnju na činjenicu da je ovo važan dokument i da ga treba sastaviti shodno tome. Gdje početi? Prije svega, morate početi sa sadržajem. Sastavite sadržaj, a zatim ga počnite razvijati. Ja lično radim ovo: prvo skiciram sadržaj, opisujem ciljeve, sve uvodne informacije, a zatim preuzimam glavni dio – formulaciju zahtjeva. Zašto ne i obrnuto? Ne znam, meni je zgodnije. Prvo, ovo je mnogo manji dio vremena (u poređenju sa zahtjevima), a drugo, dok opisujete sve uvodne informacije, prelazite na ono glavno. Pa ko god voli. Vremenom ćete razviti svoj vlastiti predložak zadatka. Za početak, preporučujem da kao sadržaj uzmete upravo onaj koji je opisan u GOST-u. Odličan je za sadržaj! Zatim uzimamo i počinjemo da opisujemo svaki odeljak, ne zaboravljajući preporuke za sledeća tri svojstva: razumljivost, specifičnost i mogućnost testiranja. Zašto toliko insistiram na ovome? Više o tome u sljedećem odjeljku. A sada predlažem potpuno takt da prođemo kroz one točke TK-a koje se preporučuju u GOST-u.

1. opće informacije;
2. svrha i ciljevi stvaranja (razvoja) sistema;
3. karakteristike objekata automatizacije;
4. Zahtjevi sustava;
5. sastav i sadržaj rada na kreiranju sistema;
6. postupak kontrole i prihvatanja sistema;
7. zahtjevi za sastavom i sadržajem rada na pripremi objekta automatizacije za puštanje sistema u rad;
8. zahtjevi za dokumentacijom;
9. razvojni izvori.

Ukupno, 9 odjeljaka, od kojih je svaki također podijeljen na pododjeljke. Uzmimo ih redom. Radi praktičnosti, predstavit ću sve u obliku tabele za svaku stavku.

Odjeljak 1. opšte informacije.

	Šta raditi s tim u praksi
puni naziv sistema i njegov simbol;	Ovdje je sve jasno: pišemo kako će se sistem zvati, njegov kratki naziv
šifra teme ili šifra (broj) ugovora;	Ovo nije relevantno, ali možete odrediti ako je potrebno.
naziv preduzeća (udruženja) programera i korisnika (korisnika) sistema i njihovi detalji;	naznačiti ko (koje organizacije) će raditi na projektu. Također možete odrediti njihove uloge. Općenito možete izbrisati ovaj odjeljak (prilično formalno).
spisak dokumenata na osnovu kojih je sistem kreiran, ko i kada su ti dokumenti odobreni;	Korisne informacije. Ovdje treba navesti regulatornu i referentnu dokumentaciju koju ste dobili da biste se upoznali sa određenim dijelom zahtjeva
planirani datumi početka i završetka radova na kreiranju sistema;	Vremenske želje. Ponekad o tome pišu u TOR-u, ali češće se takve stvari opisuju u ugovorima o radu
podatke o izvorima i postupku finansiranja radova;	Slično, kao u prethodnom paragrafu o vremenu. Relevantnije za vladine naloge (za državne službenike)
postupak formalizovanja i predstavljanja naručiocu rezultata rada na izradi sistema (njegovih delova), na izradi i prilagođavanju pojedinačnih sredstava (hardver, softver, informacija) i softversko-hardverskih (softversko-metodoloških) kompleksa sistem.	Ne vidim potrebu za ovim paragrafom, tk. posebno se izrađuju zahtjevi za dokumentaciju, a pored toga postoji i cijeli poseban odjeljak „Procedura kontrole i prijema“ sistema.

Odjeljak 2. svrha i ciljevi stvaranja (razvoja) sistema.

	Šta raditi s tim u praksi
Svrha sistema	S jedne strane, imenovanje je jednostavno. Ali želio bih biti konkretan. Ako napišete nešto poput “visokokvalitetne automatizacije kontrole zaliha u kompaniji X”, onda možete dugo razgovarati o rezultatu kada se završi, čak i bez obzira na dobro formulisane zahtjeve. Jer Kupac uvijek može reći da je pod kvalitetom mislio na nešto drugo. Općenito, živci mogu dosta pokvariti jedni druge, ali zašto? Bolje je odmah napisati nešto ovako: "Sistem je dizajniran da vodi skladišnu evidenciju u kompaniji X u skladu sa zahtjevima utvrđenim u ovom Projektnom zadatku."
Ciljevi stvaranja sistema	Golovi - ovo je svakako važan dio. Ako ga uključimo, onda moramo biti u stanju formulirati ove ciljeve. Ako imate poteškoća s formuliranjem ciljeva, onda je bolje da ovaj odjeljak potpuno isključite. Primjer neuspješnog cilja: "Osigurati brzu papirologiju od strane menadžera." Šta je brzo? To se onda može dokazivati ​​beskonačno. Ako je ovo važno, onda je bolje ovaj cilj preformulisati na sljedeći način: „Menadžer prodaje bi trebao biti u mogućnosti izdati dokument „Prodaja robe“ od 100 redova za 10 minuta“. Takav cilj može se pojaviti ako, na primjer, menadžer trenutno potroši oko sat vremena na ovo, što je za ovu kompaniju previše i za njih je važno. U ovoj formulaciji cilj se već ukršta sa zahtjevima, što je sasvim prirodno, jer. kada proširujemo stablo ciljeva (tj. dijelimo ih na manje povezane ciljeve), već ćemo pristupiti zahtjevima. Stoga se ne treba zanositi. Općenito, sposobnost identificiranja ciljeva, njihovog formuliranja, izgradnje stabla ciljeva je potpuno zasebna tema. Zapamtite glavnu stvar: ako znate kako - pišite, ako niste sigurni - ne pišite nikako. Šta se dešava ako ne postavite ciljeve? Radit ćete prema zahtjevima, to se često praktikuje.

Odjeljak 3. Karakteristike objekata automatizacije.

Odjeljak 4 Sistemski zahtjevi

	Šta raditi s tim u praksi
Opšti sistemski zahtevi. GOST dešifruje listu takvih zahtjeva: zahtjevi za strukturom i funkcionisanjem sistema; zahtjeve za brojem i kvalifikacijama osoblja sistema i načinom njegovog rada; indikatori odredišta; zahtjevi za pouzdanost; sigurnosni zahtjevi; zahtjevi za ergonomiju i tehničku estetiku; zahtjevi za prenosivosti za mobilni AS; operativni zahtjevi, održavanje, popravka i skladištenje komponenti sistema; zahtjevi za zaštitu informacija od neovlaštenog pristupa; zahtjevi za sigurnost informacija u slučaju nesreća; zahtjevi za zaštitu od utjecaja vanjskih utjecaja; zahtjevi za čistoću patenta; zahtjevi za standardizaciju i unifikacija;	Unatoč činjenici da će glavni, naravno, biti dio sa specifičnim zahtjevima (funkcionalan), ovaj odjeljak također može imati veliki značaj(i u većini slučajeva jeste). Šta može biti važno i korisno: Kvalifikacijski zahtjevi . Moguće je da će sistem koji se razvija zahtijevati prekvalifikaciju stručnjaka. Može biti kao korisnici budući sistem, i IT stručnjaci koji će biti potrebni da ga podrže. Nedovoljna pažnja ovom pitanju često prerasta u probleme. Ukoliko su kvalifikacije postojećeg osoblja očigledno nedovoljne, bolje je propisati uslove za organizaciju obuke, program obuke, termine i sl. Zahtjevi za zaštitu informacija od neovlaštenog pristupa. Ovdje nema komentara. Upravo to su zahtjevi za kontrolu pristupa podacima. Ako su takvi zahtjevi planirani, onda ih je potrebno posebno napisati, što je moguće detaljnije po istim pravilima kao i funkcionalni zahtjevi (razumljivost, specifičnost, provjerljivost). Stoga se ovi zahtjevi mogu uključiti u odjeljak sa funkcionalnim zahtjevima. Zahtjevi za standardizaciju. Ako postoje razvojni standardi koji su primjenjivi na projekat, oni se mogu uključiti u zahtjeve. Takve zahtjeve po pravilu inicira IT služba Kupca. Na primjer, kompanija 1C ima zahtjeve za dizajn programskog koda, dizajn interfejsa itd.; Zahtjevi za strukturu i funkcioniranje sistema. Ovdje se mogu opisati zahtjevi za međusobnu integraciju sistema, predstavljen je opis opšte arhitekture. Češće se integracijski zahtjevi izdvajaju općenito u posebnom dijelu ili čak u zasebnom Projektnom zadatku, jer ovi zahtjevi mogu biti prilično složeni. Svi ostali zahtjevi su manje važni i mogu se izostaviti. Po mom mišljenju, oni samo otežavaju dokumentaciju i od male su praktične koristi. I vrlo je teško opisati zahtjeve za ergonomiju u obliku općih zahtjeva, bolje ih je prenijeti na funkcionalne. Na primjer, može se formulirati zahtjev „Informirajte se o cijeni proizvoda pritiskom na samo jedno dugme“. Po mom mišljenju, ovo je ipak bliže specifičnim funkcionalnim zahtjevima, iako se odnosi na ergonomiju.
Zahtjevi za funkcije (zadatke) koje sistem obavlja	Evo ga, glavne i ključne tačke koja će odrediti uspjeh. Čak i ako je sve ostalo savršeno urađeno, a ovaj dio je na "3", onda će rezultat projekta biti u najboljem slučaju "3", ili će čak i projekat propasti. To su oni kojima ćemo se detaljnije pozabaviti u drugom članku. U ovom trenutku se primjenjuje „pravilo tri svojstva zahtjeva“ o kojem sam govorio.
Zahtjevi za vrste kolaterala GOST razlikuje sljedeće vrste: Matematički informativni Lingvistički Softver Technical metrološki Organizacijski metodički ostalo…	Na prvi pogled može izgledati da ovi zahtjevi nisu važni. Ovo važi za većinu projekata. Ali ne uvek. Kada opisati ove zahtjeve: Nije donesena odluka na kojem će jeziku (ili platformi) biti razvoj; Sistem podliježe zahtjevima višejezičnog sučelja (na primjer, ruski / engleski) Za funkcionisanje sistema potrebno je stvoriti posebnu jedinicu ili zaposliti nove radnike; Da bi sistem funkcionisao, Kupac mora proći kroz promene u metodama rada i te promene moraju biti specificirane i planirane; Pretpostavlja se integracija sa nekom opremom i na nju se postavljaju zahtjevi (na primjer, certifikacija, kompatibilnost, itd.) Moguće su i druge situacije, sve zavisi od konkretnih ciljeva projekta.

Odjeljak 5. Sastav i sadržaj rada na kreiranju sistema

Odjeljak 6. Procedura za kontrolu i prihvatanje sistema

Šta raditi s tim u praksi

Vrste, sastav, obim i metode ispitivanja sistema i njegovih komponenti (vrste ispitivanja u skladu sa važećim standardima koji se primenjuju na sistem koji se razvija); Opšti uslovi za prijem radova po fazama (spisak preduzeća i organizacija koje učestvuju, mjesto i termin), postupak ugovaranja i odobravanja prijemne dokumentacije;

Ali čak ni prisustvo provjerljivih zahtjeva možda neće biti dovoljno kada se sistem isporuči, ako procedura za prihvatanje i prijenos rada nije jasno navedena. Na primjer, uobičajena zamka: sistem je gotov, potpuno je funkcionalan, ali Kupac iz nekog razloga nije spreman za rad u njemu. Ti razlozi mogu biti bilo koji: jednom su se ciljevi promijenili, neko je odustao, itd. I kaže: „Pošto još ne radimo u novi sistem, tako da ne možemo biti sigurni da radi. Zato naučite ispravno identificirati faze rada, načine za provjeru rezultata ovih faza. Štaviše, takve metode moraju biti jasne Kupcu od samog početka. Ako su oni fiksirani na nivou Projektnog zadatka, onda ih uvijek možete kontaktirati ako je potrebno i završiti posao s prijenosom.

Odjeljak 7. Zahtjevi za sastav i sadržaj rada za pripremu objekta automatizacije za puštanje sistema u rad

	Šta raditi s tim u praksi
Dovođenje informacija koje ulaze u sistem (u skladu sa zahtjevima za informacionom i jezičkom podrškom) u oblik pogodan za obradu pomoću računara;	Veoma važna tačka. Na primjer, da bi sistem funkcionirao kako je predviđeno, možda će biti potrebno koristiti bilo koju industriju ili sve-ruske direktorije i klasifikatore. Ovi direktoriji se na neki način moraju pojaviti u sistemu, biti ažurirani i pravilno korišteni. Mogu postojati neka druga pravila za unos informacija koje je kompanija usvojila (ili planira). Na primjer, ranije su se podaci o ugovoru unosili kao tekstualni red u proizvoljnom obliku, a sada se traži zasebno broj, posebno datum itd. Takvih uslova može biti mnogo. Neki od njih se mogu uočiti uz otpor osoblja, pa je bolje sve takve slučajeve registrovati na nivou zahteva za redosled unosa podataka.
Promjene koje treba napraviti u objektu automatizacije Stvaranje uslova za funkcionisanje objekta automatizacije, pod kojima je zagarantovana usklađenost kreiranog sistema sa zahtjevima sadržanim u TOR-u	Sve promjene koje mogu biti potrebne. Na primjer, kompanija nema lokalnoj mreži, zastarjela flota računara na kojima sistem neće raditi. Možda neke potrebne informacije obrađeno na papiru, a sada se mora unijeti u sistem. Ako se to ne uradi, onda neki modul neće raditi itd. Možda je nešto pojednostavljeno, ali sada o tome treba detaljnije voditi računa, pa neko mora prikupljati informacije po određenim pravilima. Ova lista može biti duga, pogledajte konkretan slučaj vašeg projekta.
Stvaranje podjela i službi neophodnih za funkcionisanje sistema; Vrijeme i procedura za zapošljavanje i obuku osoblja	O tome smo već razgovarali. Možda se sistem razvija za novu strukturu ili vrstu djelatnosti koja prije nije postojala. Ako nema odgovarajućeg kadra, pa čak i obučenog, sistem neće raditi, ma koliko kompetentno nije izgrađen.

Odjeljak 8 Zahtjevi za dokumentaciju

Šta raditi s tim u praksi

Spisak skupova i vrsta dokumenata koje treba izraditi, a dogovoreno od strane programera sistema i korisnika

Posjedovanje kompletne dokumentacije važan je dio rezultata. Svi znamo da je dokumentovanje nečega težak posao. Stoga je potrebno unaprijed dogovoriti sa Kupcem koje će se vrste dokumentacije izraditi, kako će izgledati (sadržaj i po mogućnosti primjeri). Razmislite kako će biti predstavljeni korisnički vodiči. Možda je Kupac prihvatio korporativne standarde, pa ga morate kontaktirati. Ignoriranje zahtjeva za dokumentacijom vrlo često dovodi do najneočekivanijih posljedica na projekte. Na primjer, sve je urađeno i sve radi. Korisnici također znaju kako raditi. Nismo se uopšte dogovorili oko dokumentacije i nismo razgovarali. I odjednom, kada se posao preda, jedan od top menadžera Kupca, koji nije ni učestvovao u projektu, ali učestvuje u prijemu posla, pita vas: „Gde su uputstva za upotrebu?“ I on vas počinje uvjeravati da nije bilo potrebno dogovarati se o dostupnosti korisničkih priručnika, to se "samo po sebi" navodno podrazumijeva. I to je to, on ne želi da uzme tvoj posao. O čijem trošku ćete izraditi smjernice? Mnogi timovi su već nasjeli na ovu udicu.

Odjeljak 9 Izvori razvoja

	Šta raditi s tim u praksi
Navesti dokumente i informativne materijale (studija izvodljivosti, izvještaji o završenim istraživačkim radovima, informativni materijali o domaćim, inostranim analognim sistemima, itd.) na osnovu kojih je izrađen TOR i koji treba koristiti pri kreiranju sistema.	Da budem iskren, bliži je stihovima. Pogotovo kada se govori o ekonomskom efektu i ostalim stvarima koje je gotovo nemoguće objektivno izračunati. One. Ako je moguće, onda će to biti vjerovatnije na papiru, čisto teoretski. Stoga je bolje jednostavno se pozvati na izvještaj ankete, zahtjeve ključnih osoba.

I tako, razmotrili smo sve dijelove koji mogu biti uključeni u Projektni zadatak. „Može“, a ne „Mora“ upravo zato što svaki dokument mora biti razvijen da bi se postigao rezultat. Stoga, ako vam je očigledno da vas neka zasebna sekcija neće približiti rezultatu, onda vam nije potrebna i ne trebate gubiti vrijeme na nju.

Ali bez glavne stvari: funkcionalnih zahtjeva, niti jedan kompetentan projektni zadatak nije potpun. Želim da napomenem da se u praksi susrećemo sa takvim Projektnim zadatkom, i to kako! Postoje brojke koje će moći da razblaže vodu u svim odjeljcima, opišu opće zahtjeve općenito, a dokument se ispostavilo da je vrlo težak, a u njemu ima puno pametnih riječi, pa će se čak i kupcu dopasti to (tj. on će to odobriti). Ali možda neće biti moguće raditi na tome, tj. malo je praktične koristi od toga. U većini slučajeva takvi se dokumenti rađaju kada trebate dobiti puno novca posebno za Projektni zadatak, a to morate učiniti brzo i bez uranjanja u detalje. A pogotovo ako se zna da stvari neće ići dalje, ili će to učiniti potpuno drugi ljudi. Uglavnom, samo za razvoj budžeta, posebno državnog.

U drugom članku ćemo govoriti samo o odeljku 4 „Sistemski zahtevi“, a konkretno, formulisaćemo zahteve iz razloga jasnoće, specifičnosti i mogućnosti testiranja.

Zašto zahtjevi trebaju biti jasni, specifični i provjerljivi.

Jer praksa pokazuje: u početku se većina tehničkih specifikacija koje razvijaju stručnjaci ili ispostavi da nisu tražene (ne odgovaraju stvarnosti), ili postanu problem za onoga ko bi ih trebao implementirati, jer Kupac počinje da manipuliše nespecifičnim uslovima i zahtevima. Navest ću nekoliko primjera na koje sam fraze naišao, do čega je to dovelo, a zatim ću pokušati dati preporuke kako izbjeći takve probleme.

Vrsta zahtjeva

Pogrešna formulacija