Miten tekniset tiedot tehdään. Menettely teknisten eritelmien laatimiseksi

G O S U D A R S T V E N Y S T A N D A R T S O U Z A S S S R

Yhtenäinen ohjelmadokumentaatiojärjestelmä	GOST 19.201-78 (ST SEV 1627-79)
TEKNINEN TEHTÄVÄ. SISÄLLÖLLÄ JA SUUNNITTELUA KOSKEVAT VAATIMUKSET
Yhtenäinen järjestelmä ohjelmadokumentaatiolle. Tekniset tiedot kehitystä varten. Vaatimukset sisällölle ja esitysmuodolle

Neuvostoliiton valtion standardikomitean 18. joulukuuta 1978 päivätyllä asetuksella nro 3351 vahvistettiin käyttöönottopäivä

01.01 alkaen. 1980

Tämä standardi määrittelee menettelyn tietokoneiden, kompleksien ja järjestelmien ohjelman tai ohjelmistotuotteen kehittämistä koskevien teknisten eritelmien laatimiseksi ja laatimiseksi niiden tarkoituksesta ja laajuudesta riippumatta.

Standardi on täysin ST SEV 1627-79:n mukainen.

1. YLEISET MÄÄRÄYKSET

1.1. Tehtäväehdot laaditaan GOST 19.106-78:n mukaisesti muotojen 11 ja 12 arkeille GOST 2.301-68:n mukaisesti pääsääntöisesti täyttämättä arkin kenttiä. Arkkien (sivujen) numerot sijoitetaan arkin yläosaan tekstin yläpuolelle.

1.2. Hyväksyntälomake ja otsikkosivu on laadittu standardin GOST 19.104-78 mukaisesti.

Tietoosaa (huomautus ja sisältö), muutosrekisteröintilomaketta ei saa sisällyttää asiakirjaan.

1.3. Jos haluat tehdä muutoksia tai lisäyksiä teknisiin tietoihin ohjelman tai ohjelmistotuotteen myöhemmissä kehitysvaiheissa, siihen julkaistaan ​​lisäys. Teknisten eritelmien lisäysten yhteensovittaminen ja hyväksyminen tapahtuu samalla tavalla kuin teknisille eritelmille on määrätty.

1.4. Toimeksiannon tulee sisältää seuraavat kohdat:

• käyttöönotto;
• syitä kehitykseen;
• kehittämisen tarkoitus;
• ohjelman tai ohjelmistotuotteen vaatimukset;
• ohjelmadokumentaatiota koskevat vaatimukset;
• tekniset ja taloudelliset indikaattorit;
• vaiheet ja kehitysvaiheet;
• valvonta- ja hyväksymismenettely;
• Sovellukset voivat sisältyä teknisiin eritelmiin.

Ohjelman tai ohjelmistotuotteen ominaisuuksista riippuen on mahdollista selventää osioiden sisältöä, lisätä uusia osioita tai yhdistää yksittäisiä.

2.1. Ilmoita "Esittely"-osiossa nimi, lyhyt kuvaus ohjelman tai ohjelmistotuotteen käyttöalueesta ja objektista, jossa ohjelmaa tai ohjelmistotuotetta käytetään.

(Muutettu painos, muutos nro 1)

2.2. Kohdassa "Kehittämisen perusteet" tulee ilmoittaa:

• asiakirja(t), joiden perusteella kehitys suoritetaan;
• tämän asiakirjan hyväksynyt organisaatio ja sen hyväksymispäivämäärä;
• kehittämisaiheen nimi ja (tai) symboli.

(Muutettu painos, muutos nro 1)

2.3. Kohdassa "Kehittämisen tarkoitus" tulee ilmoittaa ohjelman tai ohjelmistotuotteen toiminnallinen ja toiminnallinen tarkoitus.

2.4. "Ohjelman tai ohjelmistotuotteen vaatimukset" -osion tulee sisältää seuraavat alakohdat:

• toiminnallisia ominaisuuksia koskevat vaatimukset;
• luotettavuusvaatimukset;
• käyttöehdot;
• teknisten välineiden koostumusta ja parametreja koskevat vaatimukset;
• tietojen ja ohjelmistojen yhteensopivuusvaatimukset;
• merkintä- ja pakkausvaatimukset;
• kuljetuksen ja varastoinnin vaatimukset;
• erityisvaatimukset.

(Muutettu painos, muutos nro 1)

2.4.1. Alakohdassa "Toimintaominaisuuksia koskevat vaatimukset" on ilmoitettava suoritettavien toimintojen koostumukselle, syöttö- ja lähtötietojen järjestämiselle, ajoitusominaisuuksille jne.

2.4.2. Kohdassa ”Luotettavuusvaatimukset” tulee ilmoittaa vaatimukset luotettavan toiminnan varmistamiseksi (stabiilin toiminnan varmistaminen, tulo- ja lähtötietojen valvonta, toipumisaika vian jälkeen jne.).

2.4.3. Kohdassa "Käyttöolosuhteet" on ilmoitettava käyttöolosuhteet (ympäristön lämpötila, suhteellinen kosteus jne. valituille tallennusvälinetyypeille), joissa määritellyt ominaisuudet on varmistettava, sekä palvelun tyyppi, vaadittava määrä ja pätevyys. henkilöstöä.

2.4.4. Alakohdassa "Teknisten välineiden koostumusta ja parametreja koskevat vaatimukset" ilmoitetaan tarvittava teknisten välineiden koostumus ja ilmoitetaan niiden tärkeimmät tekniset ominaisuudet.

2.4.5. Kohdassa ”Tietojen ja ohjelmistojen yhteensopivuuden vaatimukset” tulee ilmoittaa tietorakenteita koskevat vaatimukset ohjelman syöttö- ja lähtö- ja ratkaisumenetelmissä, lähdekoodeissa, ohjelmointikielissä ja ohjelmistossa.

Tietojen ja ohjelmien suoja on tarvittaessa varmistettava.

(Muutettu painos, muutos nro 1)

2.4.6. Alakohdassa Merkintä- ja pakkausvaatimukset on esitetty yleisesti ohjelmistotuotteen merkitsemisen vaatimukset, pakkausvaihtoehdot ja -tavat.

2.4.7. Kohdassa "Kuljetus- ja varastointivaatimukset" tulee ilmoittaa ohjelmistotuotteen kuljetusolosuhteet, säilytyspaikat, säilytysolosuhteet, säilytysolosuhteet, säilytysajat eri olosuhteissa.

2.5a. Kohdassa ”Ohjelmadokumentaatiota koskevat vaatimukset” tulee ilmoittaa ohjelmadokumentaation alustava kokoonpano ja tarvittaessa sitä koskevat erityisvaatimukset.

(Lisäksi lisätty, tarkistus 1).

2.5. Kohdassa "Tekniset ja taloudelliset indikaattorit" tulee ilmoittaa: arvioitu taloudellinen tehokkuus, arvioitu vuosikysyntä, kehityksen taloudelliset edut verrattuna parhaisiin kotimaisiin ja ulkomaisiin näytteisiin tai analogeihin.

2.6. Kohdassa "Kehitysvaiheet ja -vaiheet" määritellään tarvittavat kehitysvaiheet, vaiheet ja työn sisältö (luettelo kehitettävistä, sovittavista ja hyväksyttävistä ohjelmadokumenteista) sekä pääsääntöisesti kehittämisen aikataulu ja toteuttajat määritellään.

2.7. Kohdassa "Valvonta- ja hyväksymismenettely" tulee ilmoittaa testityypit ja yleiset töiden hyväksymisen vaatimukset.

2.8. Teknisten eritelmien liitteissä ilmoitetaan tarvittaessa:

• luettelo tutkimuksista ja muista kehittämisen perusteista;
• algoritmikaaviot, taulukot, kuvaukset, perustelut, laskelmat ja muut dokumentit, joita voidaan käyttää kehityksen aikana;
• muista kehityslähteistä.

Uudelleenjulkaisu (marraskuu 1987) muutoksella nro 1, hyväksytty heinäkuussa 1981 (IUS 7-81)

Teknisen eritelmän päätarkoituksena on selkeästi määritellä ja kirjata hankintakohteen vaatimukset. Samalla laissa säädetään, että oston nimi ilmoitetaan (23 §:n 4 osa) mukaisesti. Luettelo on hyväksytty valtioneuvoston asetuksella nro 145, 2.8.2017.

Jos ostettujen tuotteiden kuvaus on KTU:ssa, asiakas on velvollinen:

• kuvaile hankintakohde KRU:n toimittamana;
• sisällytä kuvaukseen kirjallinen perustelu (jos kuvaus poikkeaa KTR:ssä esitetystä).

GD:n 6.5.2015 nro 555 hyväksymät säännöt määräävät asiakkaan velvollisuuden ilmoittaa ostokohteen nimi perusteluprosessin aikana.

Asiakas muotoilee vaatimukset hankintakohteen kuvaussääntöjen perusteella (33 artikla). Korostetaan joitain pakollisia ehtoja:

• merkintä vastaavasta;
• pätevyys määräysten tai muiden säädösten perusteella;
• spesifikaatioiden, suunnitelmien, piirustusten, luonnosten, kuvien saatavuus (tarvittaessa);
• tavaran uusi kunto (jos asiakkaalla ei ole muuta tarvetta);
• takuun antamista koskevat vaatimukset.

Mitä tulee sisällyttää teknisiin eritelmiin

• yleistä tietoa;
• tiedot ostetusta esineestä;
• tavarantoimittajia koskevat vaatimukset;
• ehdot ;
• sovellukset (sallittu asiakkaan harkinnan mukaan).

Teknisten eritelmien laatimisen vaiheet

1. Tee luettelo asiakirjassa käytetyistä termeistä, määritelmistä ja lyhenteistä.

2. Anna täydelliset tiedot asiakkaasta:

• nimi (organisaation virallinen nimi, joka osoittaa sen oikeudellisen muodon);
• osoite (julkisista hankinnoista vastaavan organisaation tai yksikön);
• työajat sisäisten työmääräysten mukaisesti.

3. Anna seuraavat tiedot hankintatiedoissa:

• vai ei, ja jos kyllä, jokaisen asiakkaan oikeudet ja velvollisuudet (GD päivätty 28.11.2013 nro 1088);
• keskitetty hankinta, tiedot valtuutetusta elimestä (lain nro 44-FZ 1 osa, 26 §);
• asiantuntijoiden osallistuminen, heidän työnsä menettelytavat.

4. Luettelo julkisista hankinnoista:

• menetelmä toimittajan määrittämiseksi (24 §:n 1 osa);
• perustelu valitulle toimittajan määrittämismenetelmälle (24 artiklan 5 osa).

5. Listaa osallistujille asetettavat vaatimukset: yrityksen maine, tuotantotilojen saatavuus.

6. Ilmoita alkuperäiset ehdot: viite, tuotanto, kokeelliset tiedot, jotka vaikuttavat sopimuksen toteuttamiseen. Esimerkiksi ostetut laitteet on mahdollista huoltaa vain aamulla.

7. Antaa tietoja asiakkaan tuotantoprosessin tai arkkitehtonisen kohteen ominaisuuksista, jotka vaikuttavat sopimuksen toteutusprosessiin. Esimerkiksi teknistä eritelmää laadittaessa saatat joutua ilmoittamaan, että toimituksen aikana on tarpeen kiivetä kolmanteen kerrokseen manuaalisesti hissin puutteen vuoksi.

8. Ilmoita kohteen tarkka sijainti ja tarvittaessa sen täydellinen kuvaus. Tätä voidaan tarvita esimerkiksi kunnallisverkkojen suunnittelussa tai korjauskustannusten tarkassa laskennassa.

9. Tarjoa halutut tulokset (mitä ongelmaa asiakas haluaa ratkaista) ja julkisten hankintojen tavoitteet (13 44-FZ artikla).

10. Ilmoita rahoituslähde.

11. Asetetaan osallistujille vaatimus noudattaa tiettyä sääntelykehystä, mukaan lukien ne, jotka liittyvät sopimuksen kohteeseen, suoritusehtoihin, ehtoihin ja takuuvelvoitteisiin.

12. Määrittää julkisten hankintojen ehdot (osa 1, 19 artikla).

13. Ilmoita julkisen hankinnan kohteen nimi ja perustelu.

14. Kuvaa julkisen hankinnan kohde mahdollisimman tarkasti ja yksityiskohtaisesti (33 artikla).

15. Selvitä ostetun kohteen ympäristöominaisuudet.

16. Ilmoita ostettujen tavaroiden määrä sekä toimitustiheys ja toimitusaika.

17. Määritä takuuaika ja annettujen takuiden laajuus.

18. Asettaa vaatimukset pakkaukselle, merkinnöille, mitä symboleja ja erikoismerkkejä siinä tulee olla.

19. Velvollinen antamaan vahvistuksen uudesta tuotteesta tai eri kuntoisen tuotteen tarpeesta.

20. Määritä käyttökustannukset.

21. Päätä, tarvitaanko asennusta ja säätöä.

22. Määritä toimitus- ja vastaanottomenettely.

23. Ilmoita tarve testata ja kouluttaa henkilöitä, jotka käyttävät ostettua tuotetta.

Esimerkkejä tavaroiden, töiden ja palveluiden teknisistä eritelmistä vuonna 2019

Muista, että liittovaltion laki-44:n yleistä teknistä eritelmää ei ole kehitetty, jokainen osto edellyttää yksilöllistä lähestymistapaa. Tämä on ainoa tapa ottaa huomioon kaikki asiakkaan tarpeet ja ominaisuudet. Ohjeena voit käyttää tätä esimerkkiä 44-FZ:n mukaisesta teknisestä spesifikaatiosta (näyte).

Alla on esimerkki teknisistä eritelmistä tavaroiden toimittamisesta 44-FZ.

Löydät myös esimerkkejä liittovaltion lain-44 mukaisten töiden suorittamisesta järjestelmiä tai järjestelmiä koskevasta materiaalistamme.

Valmistautuminen laboratoriotöihin

Tutustu luentomateriaaliin aiheesta ”Ohjelmiston elinkaarimallit. Elinkaarivaiheet standardin GOST 19.102-77 mukaisesti. Akateemisen tieteenalan ”Ohjelmiston ja IT:n kehittäminen ja standardointi” ongelmanselvitys.

1. Tutustu julkaisujen asiaankuuluviin osioihin.

Teoreettinen osa. Teknisten eritelmien kehittäminen

Tekninen tehtävä on dokumentti, joka muotoilee ohjelmistotuotteelle tärkeimmät kehitystavoitteet, vaatimukset, määrittelee kehittämisen ajoituksen ja vaiheet sekä säätelee hyväksymistestausprosessia. Teknisten eritelmien kehittämiseen osallistuvat sekä tilaajan että urakoitsijan edustajat. Tämä dokumentti perustuu asiakkaan alkuperäisiin vaatimuksiin, edistyneen teknologian saavutusten analyysiin, tutkimustyön tuloksiin, esisuunnittelututkimuksiin, tieteellisiin ennusteisiin jne.

Menettely teknisten eritelmien laatimiseksi

Teknisten eritelmien kehittäminen suoritetaan seuraavassa järjestyksessä. Ensin määritetään suoritettavat toiminnot sekä luettelo ja lähtötietojen ominaisuudet. Sitten määritetään luettelo tuloksista, niiden ominaisuudet ja esitystavat.

Seuraavaksi määritellään ohjelmiston käyttöympäristö: laitteiston erityinen kokoonpano ja parametrit, käytetyn käyttöjärjestelmän versio ja mahdollisesti muiden asennettujen ohjelmistojen versiot ja parametrit, joiden kanssa tuleva ohjelmistotuote on vuorovaikutuksessa.

Tapauksissa, joissa kehitettävä ohjelmisto kerää ja tallentaa jonkin verran tietoa tai sisältyy jonkin teknisen prosessin ohjaukseen, on myös tarpeen säännellä selkeästi ohjelman toimintaa laite- ja virransyöttöhäiriöiden sattuessa.

1. Yleiset määräykset

1.1. Toimeksianto laaditaan standardin GOST 19.106-78 mukaisesti A4- ja A3-muotoisille arkeille GOST 2.301-68:n mukaisesti pääsääntöisesti täyttämättä arkin kenttiä. Arkkien (sivujen) numerot sijoitetaan arkin yläosaan tekstin yläpuolelle.

1.2. Hyväksyntälomake ja otsikkosivu on laadittu standardin GOST 19.104-78 mukaisesti. Tietoosaa (huomautus ja sisältö), muutosrekisteröintilomaketta ei saa sisällyttää asiakirjaan.

1.3. Tehdäkseen muutoksia ja lisäyksiä tekniseen taustaan ​​ohjelman tai ohjelmistotuotteen myöhemmissä kehitysvaiheissa, siihen julkaistaan ​​lisäys. Teknisten eritelmien lisäysten yhteensovittaminen ja hyväksyminen tapahtuu samalla tavalla kuin teknisille eritelmille on määrätty.

1.4. Toimeksiannon tulee sisältää seuraavat kohdat:

Johdanto;

Nimi ja soveltamisala;

Kehittämisen perusta;

Kehittämisen tarkoitus;

Ohjelman tai ohjelmistotuotteen tekniset vaatimukset;

Tekniset ja taloudelliset indikaattorit;

Vaiheet ja kehitysvaiheet;

Valvonta- ja hyväksymismenettely;

Sovellukset.

Ohjelman tai ohjelmistotuotteen ominaisuuksista riippuen on mahdollista selventää osioiden sisältöä, lisätä uusia osioita tai yhdistää yksittäisiä. Tarvittaessa sovelluksia voidaan sisällyttää teknisiin eritelmiin.

2.1.Johdannossa tulee sisältää lyhyt kuvaus ohjelman tai ohjelmistotuotteen käyttöalueesta sekä kohteesta (esimerkiksi järjestelmä), jossa sitä on tarkoitus käyttää. Johdannon päätarkoituksena on havainnollistaa tämän kehityksen relevanssia ja osoittaa, mikä paikka tällä kehitystyöllä on samankaltaisten joukossa.

2.2 Kohdassa "Nimi ja laajuus" ilmoitetaan ohjelman tai ohjelmistotuotteen nimi, lyhyt kuvaus käyttöalueesta ja kohde, jossa ohjelmaa tai ohjelmistotuotetta käytetään.

2.3 Kohdassa "Kehittämisen perusteet" on ilmoitettava:

Asiakirja(t), joiden perusteella kehitystä tehdään. Tällainen asiakirja voi olla suunnitelma, tilaus, sopimus jne.;

Tämän asiakirjan hyväksynyt organisaatio ja sen hyväksymispäivämäärä;

Kehitysaiheen nimi ja (tai) symboli.

2.4. Kohdassa "Kehittämisen tarkoitus" tulee ilmoittaa ohjelman tai ohjelmistotuotteen toiminnallinen ja toiminnallinen tarkoitus.

2.5. Kohdan "Ohjelman tai ohjelmistotuotteen tekniset vaatimukset" tulee sisältää seuraavat alakohdat:

Toiminnallisia ominaisuuksia koskevat vaatimukset;

Luotettavuusvaatimukset;

Käyttöehdot;

Teknisten välineiden koostumusta ja parametreja koskevat vaatimukset;

Tietojen ja ohjelmistojen yhteensopivuuden vaatimukset;

Merkintöjä ja pakkausta koskevat vaatimukset;

Kuljetuksen ja varastoinnin vaatimukset;

Erityisvaatimukset.

2.5.1 Alakohdassa "Toimintaominaisuuksia koskevat vaatimukset" tulee ilmoittaa suoritettavien toimintojen koostumukselle, syöttö- ja lähtötietojen järjestämiselle, ajoitusominaisuuksille jne.

2.5.2 Kohdassa ”Luotettavuusvaatimukset” tulee ilmoittaa vaatimukset luotettavan toiminnan varmistamiseksi (stabiilin toiminnan varmistaminen, tulo- ja lähtötiedot, toipumisaika vian jälkeen jne.).

2.5.3 Alakohdassa "Käyttöolosuhteet" on ilmoitettava käyttöolosuhteet (ympäristön lämpötila, suhteellinen kosteus jne. valituille tallennusvälinetyypeille), joissa määritellyt ominaisuudet on varmistettava, sekä palvelun tyyppi, tarvittava määrä. ja pätevyyshenkilöstö.

2.5.4 Alakohdassa "Teknisten välineiden koostumusta ja parametreja koskevat vaatimukset" ilmoitetaan vaadittu teknisten välineiden koostumus ja niiden tekniset ominaisuudet.

2.5.5 Alakohdassa Tietojen ja ohjelmistojen yhteensopivuutta koskevat vaatimukset tulee määritellä syöttö- ja ulostulon tietorakenteille sekä ratkaisumenetelmille, lähdekoodeille ja ohjelmointikielille. Tietojen ja ohjelmien suoja on tarvittaessa varmistettava.

2.5.6 Alakohdassa ”Merkintä- ja pakkausvaatimukset” on esitetty yleisesti ohjelmistotuotteen merkitsemisen vaatimukset, pakkausvaihtoehdot ja -tavat.

2.5.7 Alakohdassa "Kuljetus- ja varastointivaatimukset" tulee ilmoittaa ohjelmistotuotteen kuljetusolosuhteet, säilytyspaikat, säilytysolosuhteet, säilytysolosuhteet, säilytysajat eri olosuhteissa.

2.5.8. Kohdassa "Tekniset ja taloudelliset indikaattorit" tulee ilmoittaa: arvioitu taloudellinen tehokkuus, arvioitu vuosikysyntä, kehityksen taloudelliset edut verrattuna parhaisiin kotimaisiin ja ulkomaisiin näytteisiin tai analogeihin.

2.6 Kohdassa "Kehitysvaiheet ja -vaiheet" määritellään tarvittavat kehitysvaiheet, työvaiheet ja sisältö (luettelo kehitettävistä, sovittavista ja hyväksyttävistä ohjelma-asiakirjoista) sekä pääsääntöisesti. , määritetään kehitysaikakehys ja toteuttajat.

2.7 Kohdassa "Valvonta- ja hyväksymismenettely" on ilmoitettava koetyypit ja yleiset töiden hyväksymisen vaatimukset.

2.8 Ilmoita tarvittaessa teknisten eritelmien liitteissä:

Luettelo kehittämistä perustelevista tutkimuksista ja muista töistä;

Algoritmikaaviot, taulukot, kuvaukset, perustelut, laskelmat ja muut dokumentit, joita voidaan käyttää kehityksen aikana;

Muut kehityslähteet.

Tapauksissa, joissa asiakas ei esitä teknisissä eritelmissä asetettuja vaatimuksia, tulee sopivaan paikkaan merkitä "Ei vaatimuksia".

Esimerkkejä teknisten eritelmien kehittämisestä on liitteissä B ja C.

Kontrollikysymykset

1. Esitä ohjelmiston elinkaarimallin käsite.

2. Anna ohjelmistokehityksen vaiheet.

3. Mitä ongelmanselvitys ja esiprojektitutkimus sisältävät?

4. Luettele ohjelmistotuotteen toiminnalliset ja toiminnalliset vaatimukset.

5. Luettelo teknisten eritelmien kehittämistä koskevat säännöt.

6. Nimeä teknisten eritelmien pääkohdat.

Liite A

Tehtävävaihtoehdot

Laboratoriotöitä nro 1-5 tehdään samalle vaihtoehdolle.

1. Kehitä ohjelmistomoduuli "Oppilaiden edistymisen laskeminen". Ohjelmistomoduuli on suunniteltu dekaanin, apulaisdekaanien ja dekaanin kansliahenkilöstön opiskelijoiden edistymisen operatiiviseen kirjaamiseen istunnon aikana. Tietoja opiskelijoiden akateemisesta suorituksesta on säilytettävä koko opintojen ajan ja niitä on käytettävä suoritetuista opinnoista annettujen todistusten ja tutkintotodistusten laadinnassa.

2. Kehitä ohjelmistomoduuli ”Opiskelijoiden henkilökohtaiset tiedostot”. Ohjelmistomoduuli on suunniteltu saamaan tietoa opiskelijoista dekanaatin, ammattiyhdistystoimikunnan ja henkilöstöosaston työntekijöiltä. Tietoja tulee säilyttää opiskelijoiden koko opintojen ajan ja käyttää todistusten ja raporttien laadinnassa.

3. Kehitä ohjelmistomoduuli "Kombinatoristen optimointiongelmien ratkaiseminen". Moduulin on sisällettävä algoritmit minimipituisen syklin (matkustavamyyjän ongelma), lyhimmän polun ja minimivirittävän puun löytämiseksi.

4. Kehitä ohjelmistomoduuli "Matrix Processing". Moduulin tulee sisältää algoritmit matriisielementtien summien ja tulojen etsimiseen riveillä ja sarakkeilla sekä matriisin keskiarvo-, minimi- ja maksimiarvojen laskemiseen.

5. Kehitä Windows-sovellus "Organizer". Sovellus on tarkoitettu henkilöiden ja organisaatioiden osoitteiden ja puhelinnumeroiden sekä aikataulujen, kokousten jne. tallentamiseen, tallentamiseen ja etsimiseen. Sovellus on tarkoitettu kaikille tietokoneen käyttäjille.

6. Kehitä Windows-sovellus "Laskin". Sovellus on tarkoitettu kaikille käyttäjille ja sen tulee sisältää kaikki aritmeettiset operaatiot (prioriteettien suhteen) ja mieluiten (mutta ei välttämättä) useita matemaattisia funktioita.

7. Kehitä ohjelmistomoduuli ”Osasto”, joka sisältää tiedot osaston työntekijöistä (koko nimi, asema, korkeakoulututkinto, tieteenalat, työmäärä, yhdyskuntapalvelu, osa-aikatyö jne.). Moduuli on tarkoitettu henkilöstöosaston ja dekanaatin työntekijöiden käyttöön.

8. Kehitä "Laboratorio"-ohjelmistomoduuli, joka sisältää tiedot laboratorion työntekijöistä (koko nimi, sukupuoli, ikä, siviilisääty, lasten läsnäolo, asema, akateeminen tutkinto). Moduuli on tarkoitettu ammattiliittotoimikunnan ja henkilöstöosaston työntekijöiden käyttöön.

9. Kehitä "Kemiallinen pesu" -ohjelmistomoduuli. Palveluun rekisteröityessä täytetään hakemus, josta käy ilmi omistajan nimi, tuotteen kuvaus, palvelun tyyppi, tilauksen vastaanottopäivä ja palvelun hinta. Kun työ on valmis, tulostetaan kuitti.

10.Kehitä ohjelmistomoduuli "Liikennerikkomusten kirjanpito". Jokaisesta autosta (ja sen omistajasta) tallennetaan tietokantaan luettelo rikkomuksista. Jokaisesta rikkomuksesta kirjataan päivämäärä, kellonaika, rikkomuksen tyyppi ja sakon määrä. Kun kaikki sakot on maksettu, auto poistetaan tietokannasta.

11. Kehitä ohjelmistomoduuli "Auto Shop Card Index", joka on tarkoitettu viraston työntekijöiden käyttöön. Tietokanta sisältää tietoja autoista (merkki, moottorin koko, valmistuspäivä jne.). Kun ostopyyntö vastaanotetaan, etsitään sopiva vaihtoehto. Jos tällaista vaihtoehtoa ei ole, asiakas syötetään asiakastietokantaan ja ilmoitetaan, kun vaihtoehto tulee näkyviin.

12. Kehitä ohjelmistomoduuli “PBX Subscriber File”. Korttihakemisto sisältää tiedot puhelimista ja niiden omistajista. Kirjaa maksurästit (tilaus- ja aikaperusteiset). Paikallispuheluiden aikaperusteisen maksun uskotaan olevan jo otettu käyttöön.

13. Kehitä ohjelmistomoduuli ”Avtokassa”, joka sisältää tietoa vapaita paikoista bussireiteillä. Tietokannassa tulee olla tiedot lennon numerosta, reitistä, kuljettajasta, bussityypistä, lähtöpäivästä ja -ajasta sekä lippujen hinnoista. Kun lippuhakemus saapuu, ohjelma etsii sopivaa lentoa.

14. Kehitä "Kirjakauppa"-ohjelmistomoduuli, joka sisältää tietoja kirjoista (tekijä, nimi, kustantaja, julkaisuvuosi, hinta). Ostaja täyttää tarvitsemansa kirjapyynnön, jos niitä ei ole, hän siirtyy tietokantaan ja ilmoittaa, kun tarvitsemansa kirjat saapuvat myymälään.

15. Kehitä ohjelmistomoduuli "Parkkipaikka". Ohjelma sisältää tiedot auton merkistä, sen omistajasta, sisääntulopäivämäärästä ja -ajasta, pysäköintikuluista, alennuksista, maksamattomista maksuista jne.

Monilla julkisten hankintojen asiantuntijoilla on usein kysymys siitä, kuinka ostaa juuri ne tavarat ja palvelut, jotka vastaavat asiakasorganisaation tarpeita laadullisesti ja hinnaltaan ja samalla täyttävät kaikki voimassa olevan lainsäädännön normit. Tältä osin oikein (tai väärin) laaditulla teknisellä eritelmällä on merkittävä rooli hankintaprosessissa.

Artiklan 10 kohdan mukaisesti Lain nro 223-FZ 4 §:n mukaan hankinta-asiakirjoissa on mainittava asiakkaan asettamat vaatimukset laadulle, tuotteen teknisille ominaisuuksille, työlle, palvelulle, niiden turvallisuudelle, tuotteen toiminnallisille ominaisuuksille (kuluttajaominaisuuksille) ja koosta. , pakkaaminen, tuotteen lähetys ja tulostyö sekä muut vaatimukset, jotka liittyvät toimitetun tavaran, suoritetun työn, tarjottujen palveluiden vastaavuuden selvittämiseen asiakkaan tarpeiden kanssa.

Tämä on tekninen tehtävä, ts. kuvaus tuotteesta, työstä tai palvelusta, jonka aiot ostaa. Tämä on dokumentaation haihtuvin osa. Toimeksianto muuttuu jokaisen uuden oston myötä.

Vaatimukset teknisten eritelmien muodostamiselle.

1. Pykälän 2 osan 1, art. Lain nro 223-FZ 3 §:n mukaan asiakkaiden tulee GWS:ää ostaessaan noudattaa seuraavia periaatteita: tasa-arvo, oikeudenmukaisuus, syrjintä ja kohtuuttomat kilpailunrajoitukset hankintaan osallistuvien suhteen.

2. Laki nro 135-FZ "Kilpailun suojaamisesta" (lauseke 2, osa 1, artikla 17) toteaa, että tarjouskilpailun aikana toimet, jotka johtavat tai voivat johtaa kilpailun estämiseen, rajoittamiseen tai poistamiseen, ovat kiellettyjä, mukaan lukien se on kiellettyä luoda tarjouskilpailuun osallistumiselle edullisia ehtoja yhdelle tai useammalle tarjoajalle, mukaan lukien tiedonsaanti, ellei laissa toisin säädetä.

Kilpailua on erittäin helppo rajoittaa teknisillä eritelmillä ilmoittamalla niihin ostettavan tuotteen erityiset tekniset ominaisuudet. Tämän jälkeen valvontaviranomaiset voivat määrätä seuraamuksia. Siksi toimeksianto on laadittava erittäin huolellisesti ottaen huomioon kaikki lain vaatimukset, mutta samalla kunnioittaen asiakasorganisaation etuja siinä mielessä, että ostetaan juuri sellaisia ​​tavaroita, töitä, palveluita, jotka vaaditaan.

On parempi, että toimeksiannon laatii oston aloittaja, eli se, joka käyttää ostettavaa tuotetta. Samaan aikaan hankintaasiantuntijoiden on valvottava ja tarkistettava toimeksiannon noudattaminen monopolien vastaisen lainsäädännön (lain nro 135-FZ 17 §) suhteen.

Teknisten eritelmien muodostusvaiheessa päätetään oston jakamisesta eriin. Nuo. Toteutetaanko toimeksiannossa kuvatun kaiken osto yhdessä erässä vai kannattaako se jakaa useampaan osaan?

Teknisessä eritelmässä tulee yhtenä vaatimuksena mainita, että tuotteen tulee olla uusi. Koska laki nro 223-FZ ei sääntele tätä millään tavalla (toisin kuin laki nro 94-FZ), hankinnan osallistujilla on oikeus toimittaa käytettyjä tavaroita, jos asiakas ei nimenomaisesti ilmoita, että sen pitäisi olla uusi.

Oikea tekninen eritelmä sisältää:

• GWS:n kuvaus (toiminnalliset ominaisuudet ja kuluttajaominaisuudet).
• Määrä, toimitusaika ja -paikka.
• Täysi setti.
• Vaatimus tuotteen käyttökustannuksista.
• Laatuvaatimukset.
• Vaatimukset asennukselle ja toimitukselle.
• Henkilöstön koulutuksen vaatimukset.
• Luettelo siirretyistä asiakirjoista.
• Jäljellä olevat säilyvyysvaatimukset.
• Takausten määrää ja kestoa koskevat vaatimukset.

Muodostamme erät oikein.

On parempi olla sisällyttämättä yhteen erää:

• teknisesti ja toiminnallisesti toisiinsa liittymättömät tuotteet (tietokoneet ja tuotteet);
• lisensoitujen ja ei lisensoitujen toimintojen tyypit (tietokoneet ja ohjelmistot).

Erän muodostussäännöt.

1. Oikeus osallistua mihin tahansa määrään eriä on tarjottava.

Jos toimittaja voittaa yhden erän, on laitonta rajoittaa hänen osallistumistaan ​​muihin eriin. Tätä pidetään kilpailun rajoittamisena.

2. Alkuhinta ja vakuuden määrät on vahvistettava jokaiselle erälle erikseen.

3. Voitto yhdessä erässä ei voi perustua toisen erän voittoon.

4. Sopimukset tehdään kaikista osista erikseen, tai jos voittaja on yksi - 1 sopimus kaikista osista.

5. Tarjous voidaan julistaa pätemättömäksi kullekin erälle erikseen.

Suosittuja tapoja rajoittaa osallistujamäärää.

1. Tuotevaatimusten määrittäminen vain yhdelle tavaramerkille.

Yksityiskohtainen kuvaus tuotteen erityisistä teknisistä ominaisuuksista, jonka lisäksi vain yksi toimittaja - sen valmistaja - voi toimittaa, aiheuttaa väistämättä kysymyksiä monopolien vastaisille viranomaisille. Sen sijaan on parempi ilmoittaa vaaditun tuotteen toiminnalliset ominaisuudet.

2. Heterogeenisten tuotteiden sisällyttäminen erään.

3. Luvanvaraisten tuotteiden sisällyttäminen erään muiden tuotteiden lisäksi.

4. Eri lisensoitujen tuotteiden sisällyttäminen erään.

5. Useita toimituspaikkoja koskevat vaatimukset.

6. Epärealistiset määräajat.

7. Vaikeasti täytettävien asiakirjojen toimittamista koskevien vaatimusten asettaminen.

Säännöt tuotteen laadun määrittämiseksi Art. 469, 721 Venäjän federaation siviililaki:

1. Toimittaja on velvollinen toimittamaan asiakkaalle tavarat, joiden laatu on sopimuksen mukainen.

2. Jos sopimuksessa ei ole ehtoja tavaroiden laadusta, toimittaja on velvollinen luovuttamaan asiakkaalle tavarat, jotka soveltuvat siihen tarkoitukseen, johon tämänkaltaisia ​​tavaroita tavallisesti käytetään.

3. Jos tilaaja on sopimusta tehdessään ilmoittanut tavaran toimittajalle tavaroiden hankinnan erityisistä käyttötarkoituksista, toimittaja on velvollinen luovuttamaan asiakkaalle näiden tarkoitusten mukaisesti käytettäväksi soveltuvat tavarat.

4. Myydessään tavaroita näytteen tai kuvauksen perusteella, toimittaja on velvollinen luovuttamaan asiakkaalle näytettä tai kuvausta vastaavat tavarat.

5. Jos laissa säädetään tavaroiden laatuvaatimuksista, toimittaja on velvollinen siirtämään asiakkaalle tavarat, jotka täyttävät nämä pakolliset vaatimukset. Samalla teknisessä eritelmässä voi olla korkeampia laatuvaatimuksia verrattuna laissa säädettyihin pakollisiin vaatimuksiin.

Seuraukset teknisten eritelmien virheellisestä laatimisesta:

• sinun on ostettava halvin ja huonoin laatu;
• sinun on ostettava käytetty tuote;
• ei tarjouksia ollenkaan;
• sinun on ostettava komponentit, käyttöönotto, koulutus jne. erillisenä menettelynä.

Kun kuvailet hankintasäännöissä teknisiä eritelmiä koskevia vaatimuksia, voit luottaa laissa nro 44-FZ säädettyihin sopimusjärjestelmän normeihin.

Esimerkkejä teknisten eritelmien vaatimuksista:

Väärä	Oikein
Henkilöresurssien saatavuus	Vähintään 5 ammatillisen koulutuksen omaavaa työntekijää.
Paperitarvikkeiden liima	Liimapuikko "ErichKrause". Paino vähintään 15 grammaa. Myrkytön, sisältää glyseriiniä, joka helpottaa liukumista, hajuton, pestään helposti pois vedellä. Läpinäkyvä. Paperin liimaamiseen.
Kokea	Kokemus vastaavien palvelujen tarjoamisesta viimeisten 3 vuoden ajalta vähintään 3 sopimuksen määrässä, joiden kokonaissumma on vähintään alkuperäistä hintaa.
	Viivain on läpinäkyvä, pituus 30 cm, muovinen, muodonmuutoksia kestävä, sileä kiillotettu pinta, sileä, kirkas millimetriasteikko.

Polttoaineiden ja voiteluaineiden ostoehdot

Ennen oston tekemistä sinun on määritettävä OKDP-koodi, jotta tiedät, missä muodossa osto tulee suorittaa - sähköisesti vai ei. Tässä tapauksessa koodinumero 2320000 ei sisälly valtioneuvoston asetukseen nro 616. Tämä tarkoittaa, että hankintaa ei tarvitse suorittaa sähköisesti. Siitä huolimatta se on erittäin kätevä ja voidaan tehdä myös sähköisessä muodossa.

Sopimuksen kohde: polttoaineiden ja voiteluaineiden tai öljytuotteiden toimitus.

Teknisissä tiedoissa ilmoitamme:

• Nimi;
• ominaisuudet;
• määrä;
• näytteenotto pyyntöjen perusteella;
• toimitusosoite;
• toimitustapa (tukkumyynti, kupongilla tai korteilla, käteisellä).

Sopimuksessa tulee mainita tankkauspisteet, likimääräiset ajo-ohjeet, aukioloajat jne.

Polttoaineiden ja voiteluaineiden syöttötavat:

• tukkumyynti organisaatioiden bensiini- ja polttoainevarastoissa pankkisiirrolla;
• ostamalla kuponkeja, polttoainekortteja polttoaineen ja voiteluaineiden myöhempää ostamista varten (kupongit voidaan ilmaista fyysisinä yksikköinä (litraina) tai rahamääräisinä (ruplina);
• käteismaksua varten tilivelvollisten kautta.

Älä unohda yli 100 tuhannen ruplan ostoja. julkaista verkkosivustolla yhdeltä toimittajalta.

Polttoaineen ja voiteluaineiden maksu:

2. Loppumaksu:

• kuponkien siirron yhteydessä;
• kun hyvitetään älykortille;
• todellisen toimituksen mukaan.

Kuljetuspalveluiden ostoehdot.

Kuljetuspalvelujen määrää mitataan:

• ajetuissa kilometreissä;
• palveluntarjoamisaikoina;
• kuljetettavien ihmisten määrä;
• ajoneuvojen lukumäärä;
• lentotuntien lukumäärä lentokonetyypin mukaan.

Se riippuu organisaation erityispiirteistä ja sille osoitetuista tehtävistä.

Ilmoitamme teknisissä tiedoissa seuraavat ehdot:

• pakollisen liikennevakuutuksen ja matkustajavakuutuksen saatavuus;
• kuljettajien lääkärintarkastus ennen työn aloittamista, kuljettajien käyttäytymistä ja ulkonäköä koskevat vaatimukset;
• ajoneuvotyypit;
• asiakkaan samanaikaisesti tarvitsemien ajoneuvojen lukumäärä;
• palvelun suorituspaikka - tietty reitti tai ilmoitus siitä, että asiakas määrittää reitin suoraan kuljetuspalveluiden tarjoamisen yhteydessä.

Ohjeet vakuutuspalvelujen ostamiseen

OSAGO - kaikille osallistujille sama hinta lain mukaan. Tämä tarkoittaa, että ostaessasi sinun ei tulisi keskittyä kustannuksiin, vaan muihin tekijöihin. Esimerkiksi päivien määrä, joka tarvitaan tapahtuman vakuutustapahtumaksi tunnustamista tai tunnustamatta jättämistä koskevan päätöksen tekemiseen. Hankintasäännöissä tulee määritellä toimenpiteet tilanteessa, jossa kaikilla toimittajilla on sama hinta ja mahdollisesti myös muut toimitusehdot ovat samanlaiset.

CASCO - hinta vaihtelee eri toimittajilta. Tätä tekijää on mahdollista arvioida yhdessä muiden tärkeiden indikaattoreiden kanssa.

Tehtäväehdot sisältävät:

• vakuutuskohteiden määrä;
• niiden nimet ja tarkat ominaisuudet;
• vakuutuskausi;
• vakuutuksen määrä.

OSAGO. Hakemusten arviointi.

Sopimushinta on vakuutusmaksu, jota hankintaan osallistujat eivät voi muuttaa.

Palvelujen laatu ja osallistujien pätevyys:

• päivien lukumäärä, joka tarvitaan tapahtuman vakuutustapahtumaksi tunnustamista tai tunnustamatta jättämistä koskevan päätöksen tekemiseen;
• vakuutuskorvauksen maksamiseen tarvittavien päivien lukumäärä siitä hetkestä, kun tapahtuma on kirjattu vakuutustapahtumaksi;
• Ilmaisen evakuoinnin saatavuus vakuutustapahtuman sattuessa.

KASKO. Hakemusten arviointi.

Arviointiperusteet: sopimushinta, palvelujen laatu ja (tai) urakoitsijan pätevyys.

Mahdolliset indikaattorit:

• riippumaton tutkimus vakuutuksenantajan kustannuksella;
• ilmainen asiantuntijan vierailu asiakkaan luona;
• henkilökohtaisen työntekijän määrääminen vakuutuksenottajalle;
• tarvittavien asiakirjojen kerääminen ilman asiakkaan osallistumista ja oikeudellisen neuvonnan antaminen;
• 24 tunnin lähetyspalvelun saatavuus vakuutuskorvausten tukemiseksi;
• mahdollisuus vaurioituneen ajoneuvon vapaaseen evakuointiin onnettomuuspaikalta.

Turvallisuuspalvelujen hankinnan toimeksianto

Erityisvaatimukset osallistujille:

• oikeushenkilöllä, joka peruskirjansa mukaan harjoittaa turvapalvelujen tarjoamista, vaaditaan siihen lupa;
• organisaatioiden turvallisuustoiminta ei koske valtion suojelun alaisia ​​kohteita (luettelo on hyväksytty Venäjän federaation hallituksen asetuksella 14. elokuuta 1992 nro 587).
• Venäjän federaation 11. maaliskuuta 1992 annetussa laissa nro 2487-1 "Yksityisetsivä- ja turvallisuustoiminnasta Venäjän federaatiossa" kiinteistönomistajien suojelu luokitellaan yksityisetsivän ja turvallisuuden alalla toimivien henkilöiden palvelujen tarjoamiseksi. toimintaa. Tämäntyyppiset palvelut eivät kuulu sisäasioiden elinten yksinomaiseen toimivaltaan.

Turvallisuus. Hakemusten arviointi.

Voit asettaa seuraavat kriteerit hakemusten arviointiin:

Sopimus hinta;

Kokemus vastaavien palvelujen suorittamisesta (ei vuosissa, vaan sopimuksen määrässä), vahvistus tästä kokemuksesta;

Pätevyys (nopean toiminnan ryhmän läsnäolo, erikoisaseet jne.).

Tehtävä rakennusalan hankinnoille

• Pääasiallinen hankintatapa on tarjouskilpailu (tai tarjouspyyntö).
• On parempi ostaa arkkitehtivalvonta yhdeltä toimittajalta.
• Rakennusluvat on korvattu SRO:n luvalla.
• Alkuperäinen sopimushinta määräytyy arvioitujen standardien mukaan.
• Suunnittelu- ja arviodokumentaatio tulee olla dokumentaatiossa.
• Sopimushinta määräytyy vähentämällä suhteellisesti kaikkia arvion kohtia menettelyn aikana tehdyllä alennuksella.
• Asiakirjoissa, sopimuksessa ja asiakirjoissa olevan arvion tulee vastata työn koostumusta ja laajuutta.

Erien muodostus

Onko mahdollista yhdistää mittaus-, suunnittelu- ja rakennustyöt samassa erässä?

Art. Lain nro 135-FZ 17 §:n mukaan sähköisessä kaupankäynnissä toimet, jotka johtavat tai voivat johtaa kilpailun estämiseen, rajoittamiseen tai poistamiseen, mukaan lukien kielto luoda tarjouskilpailuun osallistumiselle edullisia ehtoja yhdelle tai useammalle tarjoajalle .

• Suunnittelu- ja kartoitustyöt voidaan yhdistää yhdeksi eräksi.
• Rakennus- ja suunnittelutyötä ei pidä yhdistää yhdeksi eräksi.
• Ilman suunnittelu- ja arviodokumentaatiota on mahdotonta määrittää lopullista rakennustyön laajuutta.
• Jos työn laajuus on tuntematon, lähtöhintaa ei voida määrittää.
• Eri SRO:iden pääsytodistukset vaaditaan.

SRO-tyypit (Venäjän federaation siviililain 55.2 artikla)

1. Suunnitteludokumenttien valmistelu pääomarakennushankkeisiin.

2. Pääomarakennushankkeiden rakentaminen, jälleenrakentaminen, suuret korjaukset.

3. Pääomarakennushankkeiden tekniset selvitykset.

Kaikille kolmelle SRO:lle ylläpidetään erillisiä rekistereitä, joita voit tarkastella verkkosivustolla: www.gosnadzor.ru.

Luettelo työtyypeistä, jotka edellyttävät SRO:n hyväksyntää, on määritetty Venäjän aluekehitysministeriön 30. joulukuuta 2009 päivätyllä määräyksellä. N:o 624. Se tuli voimaan 7.1.2010 (1.7.2010 asti tällainen luettelo määritettiin Venäjän aluekehitysministeriön 12.9.2008 päivätyllä määräyksellä nro 274). Luettelo sisältää tietyntyyppisiä töitä - vain erityisen vaarallisille, teknisesti monimutkaisille ja ainutlaatuisille esineille (Venäjän federaation siviililain 48.1 artikla), eikä se sisällä työtyyppejä suunnitteluasiakirjojen laatimiseen, rakentamiseen, jälleenrakennukseen, suuriin korjauksiin. kohteiden osalta, joille ei vaadita rakennusluvan myöntämistä (Venäjän federaation siviililain 17 osa, 51 §), sekä useiden muiden esineiden osalta (lain määräyksen kohta 2). Venäjän aluekehitysministeriö, 30. joulukuuta 2009 nro 624).

Uudet SRO-pääsytodistukset osoittavat sopimuksen enimmäismäärän, jonka osallistuja voi tehdä tällä todistuksella.

Vaatimukset sähköiseen kaupankäyntiin osallistuville

Venäjän federaation siviililain mukaan insinööritutkimuksiin, suunnitteluasiakirjojen laatimiseen, rakentamiseen, jälleenrakentamiseen ja isompien rakennushankkeiden suuriin korjauksiin liittyvät työt, jotka vaikuttavat pääomarakennushankkeiden turvallisuuteen, on suoritettava yksityishenkilöiden tai oikeussubjektit, joilla on itsesääntelyorganisaation myöntämät todistukset työhön pääsystä. Muita töitä voi tehdä kuka tahansa.

Rakentamisen tekniset tiedot jos hankitaan suuria korjauksia, jälleenrakennusta, modernisointia, teknistä laitteistoa tai uutta rakentamista koskevia töitä, sen on sisällettävä:

• Lähtökohtana on suunnitteludokumentaatio, jossa on myönteinen asiantuntijalausunto.
• Työn hyväksymismenettelyn piirteet. Sovellus SNiP 3.01.04-87 "Valmiiden rakennustilojen käyttöönotto. Perussäännökset".
• Velvollisuus toimittaa kopiot käytettyjä materiaaleja koskevista asiakirjoista (vaatimustenmukaisuustodistukset tai vaatimustenmukaisuusvakuutukset).
• Velvollisuus tarjota arkkitehtivalvontaa, rakentamisen valvontaa, valtion rakennusvalvontaa.
• Luettelot erikoisasennetuista laitteista.
• Jos nykyiset korjaukset ostetaan, niin rakentamisen toimeksianto täytyy sisältää:
• Perusteena ovat puutteelliset lausunnot, määräilmoitukset, paikallisarviolaskelmat (LSC), jotka voidaan liittää hankintadokumentaatioon.
• Työn hyväksymisen piirteet.
• Velvollisuus toimittaa kopiot käytettyjen materiaalien asiakirjoista (vaatimustenmukaisuustodistukset tai vaatimustenmukaisuusvakuutukset. Katso valtioneuvoston asetus nro 982 1.12.2009 "Yhdistetyt luettelot sertifioitavista tuotteista...").

Lisäksi rakentamisen toimeksianto voi sisältää:

• PD:n valtiotarkastuksen suorittaminen ja rakennuskustannusten luotettavuuden varmistaminen.
• Rakennuslupien saamisen varmistaminen.
• Rakennusmateriaalien ja -laitteiden toimittaminen.
• Työtuloksen hyväksymisestä aiheutuvien kustannusten kantaminen.
• Valtion rakennusvalvonnan toteuttamisen varmistaminen.
• Rakennusvalvonnan varmistaminen.
• Rakentamisen teknisen tuen sopimusten tekeminen.
• Suunnittelijan valvonnan tarjoaminen työn suorittamiseen.
• Rakennustyömaan valmistelu töihin.
• Vastuu riskivakuutuksesta.

Kysymyksiä kuuntelijoilta

Kysymys: Entä jos tuote on terveyssääntöjen mukaan tuotettava Venäjällä?

Vastaus: Jos tällaisia ​​hygieniasääntöjä on asianmukaisesti hyväksytty, sinulla on oikeus ilmoittaa asiakirjoissa, että tuotteen on oltava näiden hygieniasääntöjen mukainen, mainitsematta, että sen on oltava valmistettu Venäjällä.

Kysymys: Voidaanko toimeksiantoon sisällyttää ehto tavaroiden erissä maksamiselle?

Vastaus: Tämä ei täysin liity suoraan teknisiin eritelmiin. Hankintadokumentaatiossa tämä ehto voidaan sisällyttää tietokorttiin, esimerkiksi kohtaan "Maksumenettely".

Kysymys: Voimmeko asettaa mieltymyksiä venäläisiä tuotteita tarjoaville toimittajille?

Vastaus: Ei, sinulla ei ole oikeutta tehdä tätä. On mahdotonta asettaa etusijaa tuotantomaalle tai pienille ja keskisuurille yrityksille. Tämä ei ole sinun etuoikeutesi. Tämä kuuluu Venäjän federaation hallituksen toimivaltaan.

Kysymys: Onko mahdollista ostaa AI-92, AI-80 ja dieselpolttoainetta yhdessä erässä?

Vastaus: Jos olet varma, että markkinoilla on riittävä määrä toimittajia, jotka voivat toimittaa kaikki nämä tuotteet samanaikaisesti, etkä rajoita kilpailua tällä tavalla, voit.

Kysymys: Laissa määritellyt määrät ovat 100 tuhatta ruplaa. ja 500 tuhatta ruplaa. - lasketaanko tämä arvonlisäveron kanssa vai ilman?

Vastaus: Sopimuksessa määritellyn arvon mukaan, joka yleensä ilmoitetaan arvonlisäveroineen.

Kysymys: Onko mahdollista jatkaa polttoaineen ja voiteluaineiden toimitusta lisäsopimuksella vuodelle 2014?

Vastaus: Oikeudellisesta näkökulmasta kaikki lisäsopimukset, joiden mukaan toimitettujen tavaroiden, töiden ja palveluiden määrää lisätään, ovat uutta kauppaa. Voit tehdä tämän lisäsopimuksen polttoaineen ja voiteluaineiden toimittamisesta vuonna 2014. Samalla sinun tulee olla varma, että hankintasäännössäsi on määrätty perusteet tämän kaupan tekemiselle.

Kysymys: Mitä tehdä, jos kuljettajat tankkaavat huoltoasemilla käteistä tarpeen mukaan ja eri toimittajilta?

Vastaus: On tarpeen suorittaa kilpailullinen hankintamenettely ja tehdä sopimus tietyn toimittajan kanssa, jossa määritellään kaikki tarvittavat ehdot, mukaan lukien reitit, joilla kuljettajien on kätevää tankata käteisellä. Muista tarvittaessa julkaista tietoja tehdyistä ostoksista verkkosivustolla.

Kysymys: Polttoainetta ja voiteluaineita ostettaessa ei ole sopimushintaa ja ostetun polttoaineen määrää, voidaanko ilmoittaa vain 1 litran hinta?

Vastaus: Se on kielletty.

Kysymys: Jos maksuja samalle polttoaine- ja voiteluaineiden toimittajalle suoritetaan säännöllisesti 1-2 kertaa kuukaudessa ja maksumäärät ovat alle 100 tuhatta ruplaa, voidaanko tätä ostoa pitää ostona 100 000 ruplaan asti?

Vastaus: On parempi toteuttaa kilpailumenettely ja tehdä sopimus suurten polttoainemäärien toimittamisesta tietyissä erissä. Silloin kenelläkään ei ole sinulle kysymyksiä lain noudattamisesta.

Kysymys: Onko mahdollista ostaa polttoainetta ja voiteluaineita litramäärän mukaan?

Vastaus: Voi.

Kysymys: Esimerkiksi sopimus solmittiin 1. tammikuuta, jossain vuoden puolessa välissä asiakas tekee oston samasta tuotteesta (palvelusta) ja sama toimittaja voittaa sen, onko tarpeen allekirjoittaa uusi sopimus, joka julkaistaan ​​osana dokumentaatiota, vai voitko työskennellä aiemmin tehdyn sopimuksen mukaisesti ja määrittää uudet ehdot?

Vastaus: Tässä tapauksessa on tarpeen tehdä uusi sopimus.

Kysymys: Onko oikein tehdä toimitussopimuksessa tilaus yhdeltä toimittajalta ja ilmoittaa vain sopimuksen kokonaissumma ja maininta siitä, että toimitus tapahtuu hakemuksen mukaan, jossa ilmoitetaan tietty määrä ja yksikköhinta?

Vastaus: Hankinta yhdeltä toimittajalta tulee suorittaa oikein seuraavasti. Jos osto on yli 100 000 ruplaa. tai 500 000 ruplaa, sinun on julkaistava verkkosivustolla ilmoitus, asiakirjat ja sopimusluonnos, jossa ilmoitetaan kaikki laissa nro 223-FZ säädetyt ehdot.

Teknisten eritelmien kehittäminen on luotavan automatisoidun järjestelmän perusta. Missä EDMS-toteutusvaiheessa tämä asiakirja tulee luoda ja mitä siihen pitäisi sisällyttää? Lue vastaukset näihin peruskysymyksiin ja moniin muihin teknisten eritelmien kehittämiseen liittyviin tärkeisiin kysymyksiin tästä artikkelista.

Toimeksianto (jäljempänä - TK) on tulos organisaation prosessien analyysistä ja käsitteellisistä ehdotuksista näiden prosessien automatisoimiseksi. Ennen teknisten eritelmien laatimisen aloittamista on tarpeen tehdä tutkimusraportin muodossa laadittu tietokartoitus prosesseista ja kehittää automaatiokonsepti, joka sisältää itse automaation idean ja paljastaa automaation tavoitteet. ja tekee myös perusehdotuksia järjestelmän arkkitehtuurista ja koostumuksesta. Samalla tietoprosessien raportti ja käsite on laadittava kahdessa paradigmassa: "sellaisena kuin on" ja "sellaisena kuin pitäisi". Erittäin hyödyllinen lisäys näihin raportteihin olisi prosessien graafinen näyttö (ns. prosessimallinnus) millä tahansa valitulla menetelmällä. Yleisimmät menetelmät Venäjän käytännössä nykyään ovat merkinnät ARIS* samannimistillä työkaluilla ja UML**. EDMS-kehitys on aina projektitoimintaa, jolla on alku ja loppu. Kehitys päättyy järjestelmän siirtämiseen kaupalliseen käyttöön ja EDMS:n tukiprosessin alkamiseen.

EDMS:n kehittämisen projektipäälliköt joutuvat aina valitsemaan järjestelmää luodessaan, mitä metodologiaa käyttää: kaskadimallia vai iteratiivista.

1. Kaskadimalli.

Kaskadi tai klassinen kehitysmalli vesiputous malli- vesiputousmalli) on malli ohjelmistokehitysprosessista, jossa kehitysprosessi näyttää virtaukselta, joka kulkee peräkkäin vaatimusten analysoinnin, suunnittelun, toteutuksen, testauksen, integroinnin ja tuen vaiheet.

Kaskadimallissa EDMS:n luomisen vaiheet kulkevat peräkkäin, yhden vaiheen tulokset kehittyvät seuraavan tuloksiksi. Tässä mallissa paluu edelliseen vaiheeseen on varsin ongelmallista ja vaatii monien projektin postulaattien käsittelyä ja uudelleenajattelua. Venäjän GOST-standardit rakennetaan tämän menetelmän mukaisesti.

2. Iteratiivinen malli.

Iteratiivinen lähestymistapa iterointi- toisto) - työn suorittaminen samanaikaisesti saatujen tulosten jatkuvan analysoinnin ja edellisten työvaiheiden säätämisen kanssa. Samaan aikaan kehitys kussakin kehitysvaiheessa käy läpi toistuvan syklin: suunnittelu - toteutus - todentaminen - arviointi.

Iteratiivinen kehitysmalli on asteittainen kehitys jokaisessa vaiheessa, jossa EDMS:n koko luomisprosessi tapahtuu, mutta rajoitetussa toiminnallisuudessa. Kehitysprosessi koostuu tällaisista iteraatioista, joissa toimivuutta parannetaan jatkuvasti.

Se, mikä näistä lähestymistavoista on oikea, riippuu tietystä projektista (projektitehtävien laajuudesta) ja asiakkaan toiveista.

Riippumatta valitusta kehitysmallista, jokaisella niistä on kuitenkin vaihe, jossa muodostetaan vaatimuksia luodulle EDMS:lle. Tämä vaihe ja itse teknisen eritelmän luomista koskevat säännöt kuvataan Venäjän lainsäädännössä, nimittäin 34. sarjan GOST:issa. Perusasiakirjat - GOST 34.602-89. Tietotekniikka. Standardisarja automaattisille järjestelmille. Tekniset tiedot automatisoidun järjestelmän luomiseksi ja RD 50-34.698-90. Menetelmäohjeet. Tietotekniikka. Joukko standardeja ja ohjeita automatisoiduille järjestelmille. Automatisoidut järjestelmät. Asiakirjojen sisältöä koskevat vaatimukset.

Iteratiivisella lähestymistavalla, kun vaatimuksia muodostetaan ensimmäisen kerran, luodaan tekninen eritelmä ja myöhemmin vaatimuksia selvennetään, yksityiset tekniset tiedot (ChTZ).

Teknisten eritelmien koostumus

GOST 34.602-89:n mukaan teknisten eritelmien pääkohdat ovat:

1. Yleistä tietoa.

2. Järjestelmän luomisen (kehittämisen) tarkoitus ja tavoitteet.

3. Automaatioobjektien ominaisuudet.

4. Järjestelmävaatimukset.

5. Järjestelmän luomistyön kokoonpano ja sisältö.

6. Järjestelmän valvonta- ja hyväksymismenettely.

7. Vaatimukset työn koostumukselle ja sisällölle automaatioobjektin valmistelemiseksi järjestelmän käyttöönottoa varten.

8. Asiakirjavaatimukset.

9. Kehityksen lähteet.

Kaikki nämä osiot voidaan jakaa alakohtiin ja niihin voi sisältyä liitteitä, jotka on esitetty asiakirjan lopussa ja jotka on laadittu teknisten eritelmien liitteinä. ChTZ:llä on sama koostumus, joka voidaan luoda iteratiivisella lähestymistavalla suurissa projekteissa vaatimusten selkeyttämiseksi. EDMS:n tekninen eritelmä on laadittava A4-arkeille GOST 2.301-68* mukaisesti ilman kehystä, pääkirjoitusta ja lisäsarakkeita.

Arkkien (sivujen) numerot sijoitetaan ensimmäisestä otsikkosivua seuraavasta arkista alkaen arkin yläosaan (tekstin yläpuolelle, keskelle) TK-koodin ilmoittamisen jälkeen EDMS:ssä.

Teknisten eritelmien otsikkosivulla on seuraavat tiedot:

Leima "Hyväksyn";

EDMS:n koko nimi;

Asiakirjan nimi (tapauksessamme - "Tekniset tiedot" ja "Yksityiset tekniset tiedot");

Asiakirjan koodi;

Arkkien lukumäärä;

Paikka, jossa asiakirja on laadittu.

Hyväksyntäviisumit voidaan sijoittaa myös otsikkosivulle tai erilliselle hyväksymislomakkeelle. Seuraavaksi otsikkosivun jälkeen on arkki, jossa on tiedot dokumentin kehittäjistä - tekijöistä, jotka ovat laatineet dokumentin tekstin tai tehneet teknisissä eritelmissä kuvatut tekniset ratkaisut. Hyväksyntälomake ja tiedot asiakirjan kehittäjistä voidaan laatia yhdelle teknisten eritelmien arkille - viimeiselle GOST 34.602-89:n suositusten mukaisesti (GOST:n liite 3).

TK-koodi EDMS:ssä on suunnitteluasiakirjan nimitys, jonka asiakas tai asiakirjan kehittäjä antaa GOST 2.201-80** mukaisesti. Koodi koostuu seuraavista osista: ensimmäiset 4 merkkiä ovat kehittäjäorganisaation koodia, seuraavat 6 merkkiä luokituksen tunnuskoodia, seuraavat 3 numeroa ovat sarjarekisterinumero. Esimerkiksi TK-numero voi näyttää tältä:

CNTP. 425180.048.

Joidenkin teknisten eritelmien osien kirjoittamisen erityispiirteet

Luku " Yleistä tietoa» tulee sisältää tiedot tilaajasta ja mahdollisesta urakoitsijasta, urakoitsijan valintamenetelmästä, budjetista, josta EDMS:n luominen rahoitetaan, sekä EDMS:n luomisen arvioidut aikataulut ja työvaiheet.

Tämä osio voi esimerkiksi osoittaa, että urakoitsija määräytyy valtion sopimuksen perusteella.

Luku " Järjestelmän luomisen (kehittämisen) tarkoitus ja tavoitteet» tulee sisältää kuvaus järjestelmän luomisen päätarkoituksesta ja tuloksista, joita asiakas odottaa saavansa järjestelmän käyttöönotosta. Näiden tulosten on oltava taloudellisesti mitattavissa tai niiden mittaamiseen voidaan määrittää menetelmät.

Esimerkiksi EDMS:n käyttöönoton tavoitteena voi olla lyhentää sopimusten hyväksymiseen tarvittavaa aikaa yhteen arkipäivään kaikissa yrityksen toimipisteissä.

Luku " Automaatioobjektien ominaisuudet» sisältää kuvauksen organisaation automatisointia vaativista prosesseista ja on tulos tietokyselyraportista, joka kootaan organisaation prosessien kartoituksessa.

Luku " Laitteistovaatimukset"on teknisten eritelmien pääosa. Tähän osioon tulee kiinnittää erityistä huomiota, koska se säätelee ja konsolidoi monia tulevan järjestelmän teknisiä piirteitä.

Tässä osiossa tulee kuvata seuraavat vaatimukset:

1. Vaatimukset järjestelmälle kokonaisuutena, mukaan lukien vaatimukset järjestelmäarkkitehtuurille, työpaikkojen kokoonpanolle, vaatimukset järjestelmähenkilöstölle, luotettavuusvaatimukset, ergonomiavaatimukset, salassapitovaatimukset (jos luottamuksellisia asiakirjoja käsitellään järjestelmässä), suojausvaatimukset tiedot luvattomasta käytöstä, järjestelmän skaalausvaatimuksista ja muista.

2. Järjestelmän suorittamia toimintoja (tehtäviä) koskevissa vaatimuksissa on oltava kuvaus EDMS-alijärjestelmien (moduulien) toimivuudesta.

3. Vaatimuksissa EDMS:n osajärjestelmien (moduulien) vuorovaikutukselle tulee kuvata osajärjestelmien (moduulien) vuorovaikutusmekanismit.

4. Vaatimukset yhteenliittämiselle organisaation vastaaviin järjestelmiin tulee kuvata mitkä järjestelmät liittyvät toisiinsa ja miten ne voidaan liittää EDMS:ään.

Esimerkiksi henkilöstörekisterijärjestelmä voi tarjota käyttäjäluetteloita EDMS:lle. 5. EDMS:n toimintatilaa koskevissa vaatimuksissa on oltava kuvaus toimintatilasta (esim. 24 tuntia 7 päivää viikossa) ja järjestelmän uudelleenasentamisen tai päivityksen ennaltaehkäisevien töiden suorittamismenettely.

Esimerkiksi järjestelmäpäivitys on suoritettava pysäyttämättä järjestelmän toimintaa.

6. Tukityyppejä koskevien vaatimusten tulee sisältää: järjestelmän kielellinen tuki, EDMS:n syöttö- ja tulostusmuodot, tietokantavaatimukset, organisaatiotuen vaatimukset, järjestelmän tieto-, ohjelmisto- ja laitteistotuen vaatimukset.

7. Järjestelmänhallinnan vaatimukset kuvauksella järjestelmänvalvojien rooleista ja vastuista.

On suositeltavaa tehdä osio "Järjestelmän luomiseen tähtäävän työn kokoonpano ja sisältö" taulukon muodossa, josta käyvät ilmi EDMS:n luomisen työvaiheiden nimet, vaiheiden likimääräiset alkamis- ja päättymispäivämäärät, kuten sekä näiden vaiheiden suorittamisen tulokset.

Kohdassa "Järjestelmän tarkastus- ja hyväksymismenettely" tulee määrittää, minkä tyyppiset testit on suoritettava järjestelmän hyväksymiseksi, mukaan lukien luettelo näiden testien suorittamiseen vaadittavista asiakirjoista.

Esimerkiksi järjestelmän käyttöönottoa varten voidaan tehdä osastokokeita asiakkaan kehittämän ja hyväksymän ohjelman ja testausmetodologian mukaisesti.

Luku " Vaatimukset työn koostumukselle ja sisällölle automaatiokohteen valmistelemiseksi järjestelmän käyttöönottoa varten» kuvaa luettelon toiminnoista EDMS:n käyttäjien kouluttamiseen, käsikirjojen ja opetusmateriaalien kehittämiseen, vaatimuksia tietojen muuntamiseen tai alkutietojen syöttämiseen EDMS:ään, vaatimuksia EDMS:n toiminnan infrastruktuurin luomiselle.

"Dokumentointivaatimukset" -osiossa kuvataan yleiset säännöt järjestelmän työdokumentaation laatimiselle, ja ne voivat viitata yritysstandardeihin tai GOST-standardeihin.

Luku " Kehityksen lähteet" on lopullinen ja siinä luetellaan asiakirjat, jotka ovat olleet perustana järjestelmän kehittämiselle ja tiettyjen teknisten päätösten tekemiselle.

Tässä tapauksessa teknisen eritelmän tekstin tulee sisältää linkit kaikkiin kehityslähteisiin. Tietyn lähteen ilmoittaminen on perusteltava ja vahvistettava teknisen toimeksiannon tekstissä.

Toivomme, että luettuasi tämän artikkelin olet perehtynyt paremmin teknisten eritelmien sääntelykehykseen, sen koostumukseen ja sisältöön ja olet nyt valmis työskentelemään tämän asiakirjan parissa.

* ARIS (Architecture of Integrated Information Systems) on Software AG:n omistama metodologia ja monistettava ohjelmistotuote
organisaatioiden liiketoimintaprosessien mallintamiseen.
** UML (Unified Modeling Language) on graafinen kuvauskieli oliomallinnukseen ohjelmistokehityksen alalla; luotiin määrittelemään, visualisoimaan, suunnittelemaan ja dokumentoimaan ensisijaisesti ohjelmistojärjestelmiä.