17.11.2014

Iga töö algab ülesandest ja tehnilise kirjaniku töö peab algama tehnilisest ülesandest. Jääb vaid välja mõelda, mis see on ja miks me seda vajame. Lugege Kimberly Chani artiklit, et te ei satuks meie juba armastatud koomiksisarja arendajaga samasse olukorda.

Mis on tarkvaraarenduse lähteülesanne?

Enamik arendajaid eelistab töötada tarkvaraarenduse spetsifikatsioonidega, kuna see dokument sisaldab tavaliselt järgmist.

• Tarkvara eesmärgi ja funktsionaalsuse täielik kirjeldus;
• Üksikasjad selle kohta, kuidas programm töötab kiiruse, reageerimisaja, saadavuse, teisaldatavuse, töökindluse, taastekiiruse jms osas;
• Valikud selle kohta, kuidas kasutajad tarkvara kasutavad;
• Rakenduse riistvara või muude programmidega suhtlemise viisi kindlaksmääramine;
• Mittefunktsionaalsed nõuded (näiteks: jõudlusnõuded, kvaliteedistandardid või disainipiirangud)

Miks see oluline on?

TOR võimaldab arendajatel selgelt mõista tarkvara eesmärke ja millele keskenduda. Lisaks sellele:

Kuidas kirjutada tarkvaraarenduse jaoks TOR-i?

TOR-i kirjutamiseks pole standardset meetodit, kuid saame anda nõu:

Looge skeem

Kui teil veel malli pole, leiate need Internetist. Kasutage dokumendi kontuuri loomiseks malli. Muutke seda vastavalt oma organisatsiooni vajadustele.

Lähteülesannete plaanid erinevad olenevalt organisatsioonist ja selle protsessidest. Mõned neist võivad olla lihtsad, teised on üksikasjalikumad ja keerukamad.

Siin on näide lihtsast tarkvara TOR-plaanist:

1. Kohaldamisala
2. Süsteemi ülevaade
3. Lingid
4. Definitsioonid
5. Kasutamise näited
6. Funktsionaalsed nõuded
7. Mittefunktsionaalsed nõuded

Pärast plaani koostamist saate kirjutada spetsifikatsiooni. Siin on mõned näpunäited.

Valige parem kirjutamine

Kirjanikul peab olema suurepärane suhtlemisoskus. Spetsifikatsiooni eesmärk on, et kõik saaksid sellest aru. Kõik, mis jääb ebaselgeks või arusaamatuks, võib viia mitte eriti meeldivate tagajärgedeni. Paljud eeldavad, et tehnilise kirjaniku kaasamine protsessi aitab vältida arusaamatusi. On kirjanikke, kes on kogenumad kui arendajad, kellel on täpsus ja selgus. Tehnilised kirjutajad teavad, kuidas koguda ja töödelda õiget teavet; nad teavad ka, kuidas edastada klientide nõudmisi.

Muutke teave visuaalseks

Pilt võib salvestada 1000 sõna. Lülitage sisse visuaalne teave, nagu tabelid ja graafikud, et ideid paremini edasi anda.

Ärge dokumenteerige liiga palju

Püüdke mitte lisada dokumenti elemente, mida ei ole vaja dokumenteerida. TOR võib muutuda liiga pikaks, seega vältige üleliigset teavet.

Looge TOR-i veebiversioon ja hoidke seda ajakohasena

Kui ülesanded on lõpetatud või kui personalis või protsessides toimub muudatusi, tuleb TOR-i uuendada. Sel põhjusel säilitage virtuaalne versioon – see aitab tagada, et kogu meeskond saab iga muudatuse kohta värskendatud dokumendi.

1. Sissejuhatus
1.1. Programmi nimi
1.2. Programmi eesmärk ja ulatus
2. Nõuded programmile
2.1. Nõuded programmi funktsionaalsetele omadustele
2.2. Programmi töökindluse nõuded
2.2.1. Nõuded programmi usaldusväärse töö tagamiseks
2.2.2. Programmi taastumisaeg pärast riket
2.2.3. Programmi tõrked operaatori valede toimingute tõttu
3. Programmi kasutustingimused 3.1. Programmi toimimise kliimatingimused
3.2. Nõuded kvalifikatsioonile ja töötajate arvule
3.3. Nõuded tehniliste vahendite koostisele ja parameetritele
3.4. Teabe ühilduvuse nõuded
3.4.1. Nõuded infostruktuuridele ja lahendusmeetoditele
3.4.2. Nõuded lähtekoodidele ja programmeerimiskeeltele
3.4.3. Nõuded programmis kasutatavale tarkvarale
3.4.4. Teabe ja programmide kaitse nõuded
3.5. Erinõuded
4. Nõuded tarkvara dokumentatsioonile
4.1. Programmi dokumentatsiooni esialgne koosseis
5. Tehnilised ja majanduslikud näitajad
5.1. Programmi arendamise majanduslik kasu
6. Programmi arendamise etapid ja etapid
6.1. Programmi arendamise etapid
6.2. Programmi arendamise etapid
6.3. Töö sisu etappide kaupa
7. Kontrollimise ja vastuvõtmise kord
7.1. Testitüübid
7.2. Üldnõuded tööde vastuvõtmisele

1. Sissejuhatus

1.1. Programmi nimi

Programmi nimi: "Testprogramm"

1.2. Eesmärk ja ulatus

Programm on mõeldud...

2. Nõuded programmile

2.1. jõudlusnõuded

Programm peab võimaldama täita järgmisi funktsioone:

2.2. Usaldusväärsuse nõuded

2.2.1 Nõuded programmi usaldusväärse toimimise tagamiseks

Programmi töökindel (jätkusuutlik) toimimine peab olema tagatud kliendi poolt organisatsiooniliste ja tehniliste meetmete komplekti rakendamisega, mille loetelu on toodud allpool:
a) tehniliste vahendite katkematu elektrivarustuse korraldamine;
b) litsentsitud tarkvara kasutamine;
c) Vene Föderatsiooni töö- ja sotsiaalarengu ministeeriumi 23. juuli 1998. aasta dekreedis nr.
Arvutite ja kontoritehnika hoolduse ning tarkvara hoolduse sektoritevaheliste standardajanormide kinnitamise kohta”;
d) GOST 51188-98 nõuete regulaarne järgimine. Andmekaitse. Tarkvara testimine arvutiviiruste jaoks

2.2.2. Taastumisaeg pärast ebaõnnestumist

Taastumisaeg pärast riket, mis on põhjustatud tehniliste vahendite voolukatkestusest (muud välistegurid), operatsioonisüsteemi mittesurmavast rikkest (mitte krahhist),
ei tohiks ületada 30 minutit, olenevalt riist- ja tarkvara töötingimustest.
Taastumisaeg pärast riistvara rikkest põhjustatud riket, operatsioonisüsteemi surmavat riket (krahhi) ei tohiks ületada riistvara tõrkeotsinguks ja tarkvara uuesti installimiseks kuluvat aega.

2.2.3. Rikked, mis on tingitud operaatori ebaõigest tegevusest

Programmi tõrked on võimalikud operaatori (kasutaja) ebaõigete toimingute tõttu operatsioonisüsteemiga suhtlemisel.
Et vältida ülaltoodud põhjustest tulenevaid programmitõrkeid, peaksite tagama, et lõppkasutaja töötab ilma talle administraatoriõigusi andmata

3. Töötingimused

3.1. Kliimalised töötingimused

Käitamise klimaatilised tingimused, mille puhul tuleb tagada kindlaksmääratud omadused, peavad vastama nõuetele
tehnilistele vahenditele nende töötingimuste osas

3.2. Nõuded kvalifikatsioonile ja töötajate arvule

Programmi tööks vajalik minimaalne personali arv peab olema vähemalt 2 töötaja kohta - süsteemiadministraator ja programmi lõppkasutaja - operaator.
Süsteemiadministraatoril peab olema kõrgharidus ja operatsioonisüsteemi tootja sertifikaadid. Süsteemiadministraatori ülesannete loend peaks sisaldama järgmist:
a) tehniliste vahendite töövõime säilitamise ülesanne;
b) süsteemitarkvara tööriistade - operatsioonisüsteemi - installimise (paigaldamise) ja töövõime säilitamise ülesanded;
c) programmi installimise (paigaldamise) ülesanne.
d) andmebaasi varukoopiate loomise ülesanne.

3.3. Nõuded tehniliste vahendite koostisele ja parameetritele

3.3.1. Riistvara peaks sisaldama IBM-iga ühilduvat personaalarvutit (PC), mis toimib serverina, sealhulgas:
3.3.1.1. protsessor Pentium-2,0 Hz, mitte vähem;
3.3.1.2. RAM, 1 GB, mitte vähem;
3.3.1.3. RAM, 1 GB, mitte vähem;
3.3.1.4. operatsioonisüsteem Windows 2000 Server või Windows 2003;
3.3.1.5. operatsioonisüsteem Windows 2000 Server või Windows 2003;
3.3.1.6. Microsoft SQL Server 2000

3.4. Nõuded teabe ja tarkvara ühilduvusele

3.4.1. Nõuded infostruktuuridele ja lahendusmeetoditele

Andmebaas töötab Microsoft SQL Serveri all. Kasutatakse mitme lõimega juurdepääsu andmebaasile. Vajalik on tagada samaaegne töö programmiga sama väliste andmeekspordi moodulite andmebaasiga.

3.4.2. Nõuded lähtekoodidele ja programmeerimiskeeltele

Lisanõudeid pole

3.4.3. Nõuded programmis kasutatavale tarkvarale

Programmi kasutatav süsteemitarkvara peab olema operatsioonisüsteemi Windows 2000 Server või Windows 2003 ja Microsoft SQL Server 2000 litsentsitud lokaliseeritud versioon

3.4.4. Teabe ja programmide kaitse nõuded

Teabe ja programmide kaitsele puuduvad nõuded

3.5. Erinõuded

Sellel programmil pole erinõudeid.

4. Nõuded tarkvara dokumentatsioonile

4.1. Programmi dokumentatsiooni esialgne koosseis

Programmi dokumentatsiooni koosseis peaks sisaldama:
4.1.1. tehniline ülesanne;
4.1.2. programm ja katsemeetodid;
4.1.3. kasutusjuhend;

5. Tehnilised ja majanduslikud näitajad

5.1. Arengu majanduslik kasu

Hinnangulist majanduslikku efektiivsust ei arvutata. Analoogiat ei teostata arendusnõuete ainulaadsuse tõttu.

6. Etapid ja arenguetapid

6.1. Arengu etapid

Arendus peaks toimuma kolmes etapis:
1. tehniliste kirjelduste väljatöötamine;
2. tööprojekt;
3. rakendamine.

6.2. Arengu etapid

Lähteülesande väljatöötamise etapis tuleb läbida käesoleva lähteülesande väljatöötamise, kooskõlastamise ja kinnitamise etapp.
Detailprojekti etapis tuleks läbi viia järgmised tööetapid:
1. programmi arendamine;
2. programmi dokumentatsiooni väljatöötamine;
3. katseprogramm.
Rakendusetapis peab olema lõpule viidud arendusetapp, programmi ettevalmistamine ja üleandmine

Lähteülesande väljatöötamise etapis tuleks teha järgmised tööd:
1. probleemipüstitus;
2. tehnilistele vahenditele esitatavate nõuete määratlemine ja täpsustamine;
3. programmile esitatavate nõuete määratlemine;
4. programmi ja selle dokumentatsiooni etappide, etappide ja tähtaegade määratlemine;
5. lähteülesande kooskõlastamine ja kinnitamine.
Programmi arendamise etapis tuleks teha tööd programmi programmeerimise (kodeerimise) ja silumisega.
Programmidokumentatsiooni väljatöötamise etapis tuleks programmidokumentide väljatöötamine läbi viia vastavalt dokumentatsiooni koostamise nõuetele.
Programmi testimisetapis tuleb teha järgmist tüüpi tööd:
1. katsemeetodite väljatöötamine, koordineerimine ja heakskiitmine;
2. vastuvõtutestide läbiviimine;
3. Programmi ja programmi dokumentatsiooni korrigeerimine testitulemuste põhjal.
Programmi koostamise ja üleandmise etapis tuleb teha tööd programmi ja programmi dokumentatsiooni ettevalmistamiseks ja kasutuselevõtmiseks Kliendi ruumides.

7. Kontrollimise ja vastuvõtmise kord

7.1. Testitüübid

Vastuvõtutestid tuleb kokkulepitud aja jooksul läbi viia Kliendi objektil.
Programmi vastuvõtutestid tuleb läbi viia vastavalt Täitja poolt välja töötatud ja Tellijaga kokku lepitud Programmile ja testimismeetoditele.
Vastuvõtukatsetuste käik dokumenteeritakse Tellija ja Töövõtja poolt Testimise protokollis

7.2. Üldnõuded tööde vastuvõtmisele

Testimise protokolli alusel allkirjastab Töövõtja koos Tellijaga Programmi vastuvõtmise ja kasutuselevõtu akti.

Pidevalt kuuleme tehnilistest ülesannetest, nende tähtsusest ja õigest koostamisest. Tehniline ülesanne kodulehtede loomiseks, disainiprojektide lähteülesanne, tarkvaraarenduse lähteülesanne, selle lähteülesanne, selle jaoks lähteülesanne ... Kas see on tõesti nii oluline, lähteülesanne, tuttavalt TK. ? Ja uurime välja!

Näiteks toome välja ühe enamlevinud valdkonna – programmide arendamise lähteülesande koostamise. Ja võib-olla hakkame tekkivatele küsimustele järk-järgult vastama.

Miks tehniline ülesanne?

Vastates küsimusele "miks?" Oluline on mõista, mida tegelikult öeldakse. Nagu eespool juba märgitud, valiti lähteülesande koostamise näitena programmide väljatöötamine. Ja see tähendab, et ettevõttel, ettevõttel, organisatsioonil on reaalselt olemasolevad, jooksvad ülesanded, mida saab ja tuleks lahendada tõhusamalt, kui seda hetkel tehakse. Teisisõnu, kulukas ja erineva kvaliteediga inimtöö on vaja asendada tõhusa ja palju odavama tarkvaratööga.

Tõepoolest, töötajad vajavad puhkust, nad kõik tahavad õigel ajal palka saada, perioodiliselt "haiguslehel minna" ega väljenda reeglina soovi nädalavahetustel töötada. Programmide arendamine, vastupidi, mitte ainult ei too kaasa näidatud probleeme, asendades üksteist kadestamisväärse regulaarsusega, vaid, vastupidi, lahendab need!

Vaatame lahendusi lähemalt. Kuna tarkvara abil lahendamist vajavate aktuaalsete probleemide nimekiri on juba moodustatud, on aeg mõelda lahenduse enda protsessile. Koguneme, istume, vaidleme, uurime ja lõpuks on siin see enam-vähem vastutavate isikute üldine arvamus, mida tulevane programm teeb. Nii sünnibki aeglaselt, kuid kindlalt eeldus programmide arendamise lähteülesande koostamiseks.

Muidugi võivad asjad olla üsna erinevad. Lähteülesande koostamise usaldame programmide väljatöötamist pakkuva ettevõtte spetsialistidele. Paar kohtumist asjalikus, kuid sõbralikus õhkkonnas, valmis briifid, blanketid, lepingud, blanketid. Kõik on tehtud ja kõik on rahul. Vähemalt praegu.

Omanik, nagu öeldakse, on härrasmees ja võib alati vabalt valida parima variandi nii hinna kui kvaliteedi osas. Ideaalis muidugi, kui mõlemad on proportsionaalsed, kuid alati tuleb teha kompromisse. Kui hind on liiga madal, nihkub tarkvaraarenduse kompromiss loomulikult tarkvara kvaliteedi järsu halvenemise suunas. Paradoksaalsel kombel juhtub aga sama lugu programmide arendamise tehniliste kirjelduste kirjaoskamatu koostamisega. Raha makstud, kaup kätte, töötab, aga mitte niisama.

Siin on tegelikult vastus küsimusele, miks on vaja programmide väljatöötamiseks koostada pädev tehniline ülesanne. Liigu edasi.

Kellele spetsifikatsioon on mõeldud?

Programmide väljatöötamise lähteülesanne koostatakse ennekõike nende inimeste jaoks, kes just selle arenduse läbi viivad. Sellest lähtuvalt peaks see olema selge inimesele, kes ei tea kliendist midagi, ja veelgi enam, tema ülesannetest ja probleemidest. Vähemalt ta ei tea veel.

Järelikult peaks programmide väljatöötamise lähteülesanne rääkima töövõtjale ettevõttest, eesmärkidest ja ülesannetest. Samas, mida konkreetsem on jutt, seda parem - nii jutustajale ehk Tellijale saadete arendamiseks kui ka kuulajale ehk siis projekti teostajale.

Üldjuhul on lähteülesandel mitu eesmärki ja kuigi see võis juba alguses öeldud, pole kunagi hilja tegematajätmisi parandada. Ja eesmärgid:

• Organisatsioon
• Teave
• Suhtlemine
• Jurisdiktsioon.

Organisatsioon peaks olema suunatud protsessi enda juurde ehk teisisõnu programmi ehk tarkvarapaketi loovuse ja loomise tõhustamiseks. Rangelt võttes peaks programmide väljatöötamise lähteülesannete struktuur olema selge ja ühtaegu ülevaatlik. Kuna lugedes 120-150 või isegi rohkem lehekülge seedimatut tehnilist teksti, siis programmeerija loominguline isiksus lihtsalt ei suuda. Niisiis, lühidus on andekuse õde.

TOR-i teabekomponent peaks olema täielik, kuid sisutihe.

Ja jälle lihtne reegel, "vajalik ja piisav". Sellest tuleb, nagu ikka, alati ja igal pool kinni pidada, kuid programmide arendamise lähteülesande koostamisel saab sellest reeglist number üks. Pädev tehniline ülesanne on esimene ja viimane dokument, mis räägib kõigist kliendi soovidest programmeerijale arusaadaval kujul. Kas soovite pöörata oma ettevõtte või ettevõtte elu põhimõtteliselt uuele tasemele? Siis on programmide arendamise lähtepunkt just see tugipunkt, millega maailm pöördub teie näidatud suunas. Ja seda, näete, ei saa mingil juhul tähelepanuta jätta.

Suhtlemine on mõnevõrra keerulisem. Miks? Jah, sest suhtlemine ja isegi suhteliselt loomingulises protsessis on alati keeruline. Eriti kui sa räägid erinevaid keeli. Ja siin võib olla mitu keelt, täpsemalt - vastavalt projektis osalejate arvule, koodnimega "tarkvaraarendus".

Lihtsamalt öeldes:

• Klient, tema on Klient
• Projektijuht
• Projekti teostajad, nemad või ta: programmeerija(d)
• Teised võimalikud osalejad, kellel on arvamus: kuidas seda teha, kuidas paremini teha ja kuidas see peaks lõppema.

Loomulikult on need osalejad ühise projekti loomisel sunnitud otsima keelt, mis oleks kõigile kättesaadav. See keel on mõeldud programmide arendamise lähteülesandeks. Ideaalis on peamine luua sidekanal esimese ja kolmanda lingi vahel ning mida vähem häireid teine ​​ja neljas link tekitavad, seda parem on tulemus ning programmide arendamine toob soovitud tulemuse minimaalse närvikaoga. .

Nii jõudsime jurisdiktsioonini, puudutades muuseas ka "närvide kaotuse" teemat. Tänu lähteülesandele on võimalik hinnata programmide väljatöötamise tulemuse ja antud lähtetingimuste vastavust. Peab ütlema, et lühiajaline mälu kannatab nii projekti tellijatel kui ka teostajatel. Esimene unustab kokkulepitud maksumuse, muudatuste arvu, juurutamise ja silumise võimalused ning teine ​​- põhimõtteliselt selle, mida ja millal oleks pidanud tegema. Amneesia ja selle tagajärgede vähendamiseks miinimumini on jällegi vaja selget ja konkreetset TOR programmide arendamiseks!

Kuidas kirjutada tehnilist ülesannet?

Olles veendunud programmide väljatöötamise lähteülesande vajalikkuses ja isegi hindamatus väärtuses, võime vestlust jätkata. Nüüd oleme jõudnud kõige tõsisema küsimuseni: kuidas koostada TOR nii, et see oleks pädev, selge, lühike, kuid konkreetne ?! Ja me ei vaja midagi muud.

Selle eest hoolitseti juba iidsetel NSV Liidu aegadel, töötades välja terve standardite kontseptsiooni, mida nimetatakse GOST-ideks. Üllataval kombel näevad need standardid ette ka programmide arendamise, et nõustute, ei saa muud kui rõõmustada.

Programmide väljatöötamist ja volituste koostamist selles valdkonnas reguleerib GOST 19.201-78 üks süsteem tarkvara dokumentatsioon. Tehniline ülesanne. Nõuded sisule ja kujundusele.

Samuti ei ole üleliigne veel kaks juhendit:

• GOST 2.114-95 Projekteerimisdokumentatsiooni ühtne süsteem. Tehnilised andmed;
• Infotehnoloogia GOST 34.602-89. Automatiseeritud süsteemide standardite kogum. Loomise lähteülesanne automatiseeritud süsteem. Seda kolmainsust võib mõistagi pidada "pühade pühaks" peaaegu iga ainevaldkonna tehniliste kirjelduste väljatöötamisel ja koostamisel. Muidugi on ka teisi standardeid, mida saab ja tuleks järgida, kuid meenutagem "vajalikku ja piisavat".

Milleni me lõpuks jõuame?

Vastus: lähteülesande üldine struktuur, sh programmide väljatöötamine.

• Mida on vaja projekti raames ära teha;
• Miks seda vaja on ja millistel konkreetsetel eesmärkidel;
• Kus projekti tulemust kasutatakse (loe, programmiarendus), millises tegevusvaldkonnas ja millisel tasemel;
• Milliseid nõudeid peaks programmide arendamine vastama?
• Mida on vaja projekti kallal töötamise protsessis teha;
• Kuidas hindab tulemust Klient;
• Millised dokumendid kehtestavad projektiga suhtlemise korra;
• Mille alusel alustatakse tööd tarkvara arendusprojektiga.

Määratud GOST 19.201-78 teine ​​osa, mis määrab jaotiste sisu, aitab üksikasjalikumalt koostada programmide väljatöötamise lähteülesande.

Eraldi punkt meie spetsiifikast on tarkvaraarendus, toon välja tarkvaranõuete osa. Selle osa koostamisel tuleks probleemile läheneda formaalselt. Teisisõnu "avage uus aken", "muutke praegust faili kasutajakonsoolide käskude kaudu" ja "salvesta muudatused, kui programmi põhiaken on suletud" on selge ja formaalne lähenemine.

Samuti peab programmide väljatöötamine vastama mitmetele nõuetele, mis peavad olema lähteülesandes kirjas. Siin on nõuete loend:

• programmi poolt täidetavate funktsioonide kogumile;
• sisend- ja väljundandmete korralduse kohta;
• kiirendama;
• töökindlusele;
• rikete korral taastumise kestusele;
• rikete kohta, mis on tingitud kasutaja ebaõigest tegevusest;
• teenuste liikide kohta;
• programmiga suhtlevate töötajate arvule ja kvalifikatsioonile;
• tehniliste vahendite parameetritele, millega tagatakse programmi normaalne toimimine;
• lähtekeeltele ja programmeerimiskoodidele, teabestruktuuridele ja kolmandate osapoolte tarkvaratööriistadele;
• kaitse ja infoturbe kohta;
• märgistamisele ja pakkimisele;
• transpordi- ja ladustamistingimustele.

Samuti saab programmide väljatöötamise nõuete loetelu muuta: täiendada või vähendada olenevalt projekti konkreetsetest tingimustest.

Kes koostab lähteülesande?

On aeg kokkuvõtteid teha. Kes peaks oma, kindlasti habrastele õlgadele nii raske koorma kandma - tehniliste kirjelduste koostamine programmide arendamiseks. Loomulikult projektijuht! just see inimene sillutab ületöötamisega teed Töövõtja ja Tellija ühisele õnnele, harmooniale ja üksteisemõistmisele.

Loomulikult ei ole juhi töö vähem loominguline kui programmeerija töö ning loomingulise kaose ja korratuse vältimiseks vajab see ka selget disaini. Paneme kõik arenduse käigus projektijuhi funktsioonidega seonduv omale kohale:

1. Projekti ülesande püstitamine;
2. Tehnilise teostuse nõuete kujundamine ja täpsustamine;
3. Nõuete sõnastamine arendatud programmile;
4. Etappide koordineerimine, kestus ja dokumentatsiooni koostamine;
5. Programmeerimiskeelte ja koodide märkimine;
6. Tehniliste kirjelduste koostamine, uuendamine ja kinnitamine Kliendi poolt.

Vaatamata nende funktsioonide näilisele lihtsusele on vaid väike osa juhtidest võimelised neid hästi täitma. ja selleks, et kedagi süüdi ei mõistetaks, on vaja programmide arendamise lepingu tingimustes märgitud lähteülesanne kinnitada mõlema poole esindajate allkirjadega.

Eks need peod peavadki juhinduma GOST 19.201-78-st, mis pole ei rohkem ega vähem, aga peaaegu 30 aastat vana.

Seonduvad postitused

Mõiste "pöördprojekteerimine" on endise kontseptsiooni kaasaegne sõnastus - kopeerimine, täiustamine ... Arvutitehnoloogia arenguga ...

Sisuliselt koos infotehnoloogia Inimkond on silmitsi seisnud ja seisab silmitsi igal oma eluetapil. Lihtsalt…

Ümberkorralduse kontseptsioon sündis 90ndatel kui sisukas vastus massilise automatiseerimise käigus tekkinud probleemidele ...

TEADUS- JA HARIDUSMINISTEERIUM

VENEMAA FÖDERATSIOON

SEI HPE "ADYGE STATE UNIVERSITY"

FÜÜSIKATEADUSKOND

OSAKOND ASOIU

TARKVARA LOOMISE TINGIMUSED

TOODE

SISSEJUHATUS……………………………………………………………………………. ... 3

1. ARENDUSE ALUS…………………………………………….. ...…4

1.1. Arendustöö aluseks olev dokument……………………………..4

1.2. Organisatsioon, kes kinnitas arenduse aluse, ja selle kinnitamise kuupäev4

1.3. Arendusteema nimetus………………………………………………….4

2. ARENDUSE EESMÄRK………………………………………………………..5

2.1 Programmi tõhususe ja kvaliteedi kriteeriumid…………………………………..5

5

3. NÕUDED PROGRAMMILE…………………………………………………………6

3.1 Toimivusnõuded……………………………….6

3.1.1 Täidetavate funktsioonide koosseis…………………………………………………….6

3.1.2 Sisend- ja väljundandmete korraldus……………………………………….6

3.1.3 Ajakarakteristikud ja mälu maht………………………6

3.2 Töökindlusnõuded …………………………………………………………….…6

3.2.1 Nõuded töökindlaks tööks…………………………………6

3.2.2 Sisend- ja väljundteabe juhtimine…………………………………..7

3.2.3 Taastumisaeg pärast tõrget………………………………………..7

3.3 Kasutustingimused……………………………………………………………..7

3.4 Nõuded tehniliste vahendite koostisele ja parameetritele………………………7

3.5 Nõuded programmeerimiskeeltele……………………………………….8

3.6 Nõuded programmis kasutatavale tarkvarale………8

3.7 Nõuded tarkvara dokumentatsioonile………………………………………… 8

4. TEHNILISED JA MAJANDUSLIKUD NÄITAJAD…………………………… ..... 9

5. ETAPID JA ARENGUETAPID………………………………………………………………………………………………………………

6. KONTROLLI JA VASTUVÕTMISE KORD………………………………………………………..9

6.1 Katsete tüübid…………………………………………………………………..9

6.2 Vastuvõtmise üldnõuded……………………………………………………………………………………………………………………………………………………

7. RAKENDAMISE ETAPID……………………………………………………………......10

SISSEJUHATUS

Tarkvaraarenduse täisnimi: "Programm K", edaspidi "programm". Programmi lühinimi on "PC".

Hetkel sarnaseid tarkvaratooteid ei ole.

Väljatöötatud programmi rakendatakse igas ettevõttes, kus on töötajaid.

Selle tarkvaratoote arendaja on rühma 4A1 õpilane Ivanov A.V. edaspidi "arendaja".

Tarkvaratoote tellija on OJSC RTS, keda esindab direktor A.M. Gutenko.

1 ARENGU ALUS

1.1 Dokument, mille alusel arendus toimub

Töö toimub distsipliini "Automaatjuhtimise teoreetilised alused" ülesande alusel.

1.2 Heakskiitv organisatsioon ja käesoleva dokumendi kinnitamise kuupäev

Ülesande kiitis heaks ja andis välja RTS OJSC tehnilise osakonna juhataja A. V. Kozakov.

Kozakov A.V.

1.3 Arendusteema nimetus

Arendusteema nimetus on “Tööaja arvestus”.

2 ARENDUSE EESMÄRK

See arendus on semestritöö distsipliinil "Automaatjuhtimise teoreetilised alused"

2.1 Programmi tõhususe ja kvaliteedi kriteeriumid

sotsiaalne tegur. Seda tarkvaraarendust on väga lihtne õppida ja see on mõeldud mitte ainult professionaalidele, vaid ka Windowsis töötavatele tavakasutajatele. Mugav, intuitiivne liides koos võimsa abipiltide ja tööriistavihjete süsteemiga võimaldab teil programmiga töötada ilma eelneva ettevalmistuseta.

Vastavus selle profiili tarkvaraturu hetkeseisule. Erinevalt kallitest ja keerukatest programmidest on arvuti ideaalne äriesindajatele, kuna sisaldab kõike vajalikku, kuid ei ole üle koormatud kasutute ja ebavajalike funktsioonidega. Programmi loomise tehnoloogia visuaalsetes programmeerimiskeskkondades muudab selle liidese universaalseks ja ühilduvaks operatsioonisüsteemidega Windows 95/98/2000/XP.

Majanduslikud jõud. Programm esindab parimat hinna ja pakutavate funktsioonide suhet ning võtab kahtlemata oma niši odavate programmide turul. Peamised kasutajad on ettevõtete esindajad, kes lihtsalt ei saa maksta 1C kallite programmide jms eest.

2.2 Programmi koostamise eesmärgid

Selle programmi loomisel on mitu tehnilist ja majanduslikku eesmärki:

Tööaja fikseerimiseks vajaliku tarkvaratoote loomine.

Odava alternatiivi loomine praegu olemasolevatele kallitele programmidele.

Looge mugava ja mitmekülgse Windowsiga intuitiivne programm.