Sissejuhatus Tarkvaratehnika (loengud). Sissejuhatus tarkvaratehnikasse

ärakiri

1 Sissejuhatus tarkvaratehnikasse Sisukord Loeng 1. Õppeainest... 3 Tarkvaratehnika... 3 Tarkvara... 5 Kirjandus... 6 Loeng 2. Tarkvara arendusprotsess... 7 Protsess... 7 Täiendus Protsess... 8 klassikalist protsessimudelit... 9 kirjandusloeng 3. Töötoode, pühendumusdistsipliin, projektitöötoode pühendumusdistsipliin Projektikirjandus loeng 4. Tarkvaraarhitektuur Arutelu definitsioon Mitu vaatepunkti UML-i kirjanduse loeng 5. Nõudehaldusprobleemide tüübid ja omadused nõuded Nõuete vormistamise variandid Nõuetega töötsükkel Kirjandus Loeng 6. Konfiguratsioonihaldus Probleem Konfiguratsioonihaldusüksused Versioonikontroll Ehitamise haldus Põhikontseptsioon Kirjandus Loeng 7. Testimine Kvaliteedijuhtimine Testimine Vigadega tegelemine Kirjandus

2 Loeng 8. Diagrammide koostamise tehnikad teadmistes Töömeetodite kasutusjuhud Iteratiivne tsükkel Autor/retsensent Mind Maps Kirjandus Loeng 9. MSF ajalugu ja hetkeseis Põhiprintsiibid Meeskonnamudel Muud omadused Kirjandus Loeng 10. CMMI Mis on CMMI? CMMI protsessi küpsustasemed Täiendusvaldkonnad Kirjandus Loeng 11. Agiilne arendusmeetodid Üldine äärmuslik programmeerimine Scrum Literature Loeng 12. Microsofti tehnoloogia ülevaade visuaalne stuudio Meeskonnasüsteemi (VSTS) ülevaade Toote sisu Installireeglid Team Exploreri paketi loeng 13. VSTS: Tööobjektide definitsiooni, omadused, elutsükli kasutamise loeng Testipaketid Veebirakenduste automatiseeritud testimine Loeng 16. VSTS: Erinevate protsessimudelite tugi Protsessimallide tugi Ülevaade olemasolevad mallid MSF Agile Software Development Scrumile

3 Loeng 1. Õppeainest Tarkvaratehnika Mille poolest programmeerimine erineb inseneriprogrammist? Et esimene on mingi abstraktne tegevus ja võib toimuda paljudes erinevates kontekstides. Programmeerida saab oma lõbuks, õppimiseks (näiteks klassiruumis, ülikooli seminaridel), programmeerida saab teaduse arengu raames. Ja saate teha tööstuslikku programmeerimist. Reeglina toimub see meeskonnas ja kindlasti kliendil, kes maksab töö eest raha. Samas tuleb täpselt aru saada, mida tellija vajab, töö tuleb valmis teha kindla aja jooksul ning tulemus peab olema nõutava kvaliteediga, mis klienti rahuldab ja mille eest ta maksab. Nende lisanõuete rahuldamiseks “kasvatatakse” programmeerimine erinevate lisategevustega: nõuete väljatöötamine, planeerimine, testimine, konfiguratsioonihaldus, projektihaldus ning mitmesuguse dokumentatsiooni (projekt, kasutaja jne) loomine. Programmikoodi väljatöötamisele eelneb analüüs ja kujundamine (esimene tähendab loomist funktsionaalne mudel tulevane süsteem rakendamist arvestamata, et programmeerijad mõistaksid kliendi nõudeid ja ootusi; teine tähendab esialgset paigutust, eskiisi, süsteemiplaani paberil). Analüüsi ja disaini tööjõukulud ning nende tulemuste esitlemise vorm on väga erinevad, olenevalt projekti tüübist ning arendajate ja klientide eelistustest. Erilisi jõupingutusi on vaja ka arendusprotsessi korraldamiseks. Üldjuhul on tegemist iteratiiv-inkrementaalse mudeliga, kus vajalik funktsionaalsus luuakse portsjonite kaupa, mida juhid ja klient saavad hinnata ning seeläbi on võimalik arenduse edenemist kontrollida. Sellel üldmudelil on aga palju modifikatsioone ja variatsioone. Süsteemi väljatöötamisel tuleb arvestada ka selle edasise hooldamise, taaskasutamise ja teiste süsteemidega integreerimise mugavust. See tähendab, et süsteem on jaotatud komponentideks, mida on lihtne arendada, taaskasutada ja integreerida. Samuti omades nõutavad omadused kiiruse järgi. Liidesed on nende komponentide jaoks hoolikalt kavandatud. Süsteem ise on dokumenteeritud mitmel tasandil, luuakse programmikoodi kujundamise reeglid ehk jäetakse arvukalt semantilisi jälgi, mis aitavad luua ja säilitada, hoida ühtset, harmoonilist arhitektuuri, ühtset stiili, korda Kõik need ja muud protsessi käigus tehtavad täiendavad tegevused tööstuslik programmeerimine ja vajalik tellimuste edukaks täitmiseks ning seda hakatakse nimetama tarkvaratehnikaks (tarkvaratehnika) 1. Selgub, et nii tähistame esiteks mingit praktilist tegevust ja teiseks eriteadmiste valdkonda. Ehk teisisõnu teadusdistsipliin. Tõepoolest, selleks, et hõlbustada iga üksiku projekti elluviimist, kasutada ära teiste meeskondade ja teiste meeskondade mitmekülgset positiivset kogemust ja 1 Akadeemik A. P. Ershov tõlgiti 70ndatel vene keelde termin tarkvaratehnika kui "programmeerimistehnoloogia". ”. Tarkvaratehnoloogia on sama termini moodsam, kuid vähem traditsiooniline tõlge, mille pakkus 90ndate lõpus välja I. V. Potosin. Osana see kursus Kasutame seda tõlget. 3

4 arendajat, just see kogemus allub järelemõtlemisele, üldistamisele ja õigele disainile. Nii tekivad erinevad testimise, projekteerimise, nõuetega töötamise jms meetodid ja tavad (parimad praktikad), arhitektuursed mustrid jne. Nagu ka kogu protsessi kui tervikuga seotud standardid ja metoodikad (näiteks MSF) , RUP, CMMI, Scrum). Just need üldistused on tarkvaratehnika kui teadmiste valdkonna sees. Vajadust tarkvaratehnika kui eriteadmiste valdkonna järele mõistis maailma üldsus juba eelmise sajandi 60. aastate lõpus, enam kui 20 aastat pärast programmeerimise enda sündi, kui arvestada kuulsat von Neumanni aruannet “First Draft EDVAC-i aruandest”, mille ta avaldas 1945. aastal. Tarkvaratehnika sünd on 1968. aasta NATO tarkvaratehnoloogia konverents Garmischis (Saksamaa), mis oli täielikult pühendatud neile küsimustele. Kõik tarkvaraarenduse protsessi korraldamise ja täiustamise, arendusmeeskonna juhtimise, tarkvara tugivahendite arendamise ja juurutamisega seotud küsimused ja teemad kuuluvad tarkvaratehnika valdkonda. eluring tarkvara arendamine. Tarkvaratehnoloogia kasutab arvutiteaduse saavutusi, on tihedalt seotud süsteemitehnoloogiaga ja sellele eelneb sageli äritegevuse ümberkorraldus. Natuke lähemalt sellest tarkvaratehnika kontekstist. Arvutiteadus on matemaatikal põhinevate teoreetiliste teaduste kogum, mis on pühendatud arvutatavuse formaalsetele alustele. See hõlmab matemaatilist loogikat, grammatikateooriat, kompilaatori ehitusmeetodeid, matemaatilisi formaalseid meetodeid, mida kasutatakse kontrollimisel ja mudelite testimisel jne. Tarkvaratehnikat on arvutiteadusest raske eraldada, kuid üldiselt on nende erialade fookus erinev. Tarkvaratehnika on suunatud tootmisprobleemide lahendamisele, arvutiteadus aga formaalsete, matemaatiliste lähenemiste väljatöötamisele programmeerimisel. Süsteemitehnika (süsteemitehnika) ühendab erinevaid inseneriteadusi, et arendada kõikvõimalikke kunstlikud süsteemid elektrijaamad, telekommunikatsioonisüsteemid, sisseehitatud reaalajas süsteemid jne. Väga sageli on tarkvara selliste süsteemide osa, täites vastavate seadmete haldamise ülesannet. Selliseid süsteeme nimetatakse riistvaraks-tarkvaraks ning nende loomisel osaledes on programmeerijad sunnitud vastava varustuse omadusi süvitsi mõistma. Ettevõtluse ümberkorraldus (business reengineering) laiemas tähenduses tähendab äritegevuse moderniseerimist konkreetses ettevõttes, uute tavade juurutamist, mida toetavad asjakohased, uued infosüsteemid. Samas võib rõhk olla nii ettevõtte sisemisel ümberkorraldamisel kui ka uue klienditeeninduse arendamisel (reeglina on need teemad omavahel seotud). Tihti eelneb ettevõttes infosüsteemide väljatöötamisele ja juurutamisele ettevõtte ümberkorraldamine, kuna esmalt tuleb bürootöös paika panna kindel kord ja alles siis see infosüsteemiga paika panna. Tarkvaratehnika (kui praktikavaldkonna) seos arvutiteaduse, süsteemitehnika ja ärireeninguga on näidatud joonisel fig.

5 Joon. 1.1 Tarkvara määratlus. Tarkvara (SW) mõistame ajas arenevate loogiliste ettekirjutuste kogumina, mille abil teatud meeskond inimesi haldab ja kasutab multiprotsessorit ja hajutatud süsteem arvutusseadmed. IBMi tunnustatud tarkvarainsener Harald Milsi antud määratlus on järgmine. 1. Loogilised ettekirjutused pole mitte ainult programmid ise, vaid ka mitmesugune dokumentatsioon (näiteks programmide toimimise kohta) ja laiemalt määratletud suhete süsteem neid programme teatud tegevusprotsessi raames kasutavate inimeste vahel. 2. Kaasaegne tarkvara on reeglina loodud töötama samaaegselt paljude kasutajatega, keda saab füüsilises ruumis üksteisest oluliselt eemaldada. Seega muutub arvutikeskkond (personaalarvutid, serverid jne), milles tarkvara töötab, hajutatuks. 3. Kaasaegse tarkvaraga lahendatavad ülesanded nõuavad nende ülesannete erinevast spetsialiseerumisest, tehtavate tööde suurest mahust ja ka turvalisuse kaalutlustest tulenevalt sageli erinevaid arvutusressursse. Ilmub näiteks andmebaasiserver, rakendusserver vms.. Seega osutub arvutuskeskkond, milles tarkvara töötab, mitmeprotsessoriliseks. 4. Tarkvara areneb aja jooksul, parandatakse vigu, lisatakse uusi funktsioone, antakse välja uusi versioone, muutub selle riistvarabaas. Omadused. Seega on tarkvara keeruline dünaamiline süsteem, mis sisaldab tehnilisi, psühholoogilisi ja sotsiaalseid aspekte. Tarkvara erineb oluliselt teistest inimeste loodud (loodud) mehaanilistest, sotsiaalsetest, teaduslikest jne süsteemitüüpidest ning sellel on järgmised omadused, mida Frederick Brooks on esile tõstnud oma kuulsas artiklis “Ei ole hõbekuuli”. 1. Tarkvaraobjektide keerukus, mis sõltub oluliselt nende suurusest. Reeglina on rohkem sarnase funktsionaalsusega tarkvara (rohkem kasutajaid, rohkem töödeldavaid andmeid, rangemad jõudlusnõuded jne) erinev tarkvara. Ehitatud klassikaline teadus lihtsad mudelid keerulisi nähtusi ja see õnnestus, kuna keerukus ei olnud vaadeldavate nähtuste iseloomulik tunnus. (Programmeerimise võrdlemine teadusega, mitte teatri, kino, spordi ja muude inimtegevuse valdkondadega on õigustatud, kuna see tekkis, 5

6 peamiselt matemaatikast ja selle esimesed viljad olid arvutid, programmikeeled, mis olid mõeldud kasutamiseks teaduslikes arvutustes. Lisaks on enamikul programmeerijatel teaduse, matemaatika või inseneri taust. Seega kasutatakse programmeerimisel eksplitsiitselt või kaudselt teadusliku mõtlemise paradigmasid laialdaselt.) 2. Tarkvara järjepidevus ei põhine objektiivsetel eeldustel (nii nagu klassikalises teaduses põhinevad erinevad süsteemid postulaatidel ja aksioomidel), vaid peavad olema kooskõlas suure hulgaga. liidesed, millega see peab hiljem suhtlema. Neid liideseid on raske standardida, kuna need tuginevad arvukatele ja halvasti vormistatud inimlikele kokkulepetele. 3. Muudetavus Tarkvara on lihtne muuta ja sellest tulenevalt muutuvad ka sellele esitatavad nõuded arendusprotsessi käigus pidevalt. See tekitab selle arendamisel ja arenemisel palju lisaraskusi. 4. Tabamatus 2 Tarkvara pole näha, see on virtuaalne. Seetõttu on näiteks keeruline ära kasutada jooniste eelloomel põhinevaid tehnoloogiaid, mida kasutatakse edukalt teistes tööstusvaldkondades (näiteks ehituses, masinaehituses). Seal on joonistel skemaatiliselt taasesitatud loodavate objektide geomeetrilised kujundid. Kui objekt on loodud, on need kujundid näha. Millele me tarkvara kujutamisel lähtume? Kirjandus 1. H. Mills. Tarkvaratehnika juhtimine I osa: Tarkvaratehnika põhimõtted. // IBM System Journal, Vol. 38, nr 2 ja 3, 1999, lk F. Brooks. Ei mingit hõbekuuli. Info Proceeding of the IFIP 10 th World Computing Conference pp / venekeelne tõlge: F. Brooks. Müütiline inimkuu ehk kuidas luuakse tarkvarasüsteeme. SPb sümbol, c. 3. I. Sommerville'i tarkvaratehnika. 6. väljaanne. Addison-Wesley, lk. / Vene tõlge: I. Sommerville. Tarkvaraarendus. Williamsi kirjastus, c. 4. A.P. Eršov. Programmeerimissüsteemide arendamise tehnoloogia. // A.P. Ershov. Valitud teosed. VO Teadus. Novosibirsk C Pottosin I.V. Tarkvaratehnika: sisu, arvamused ja trendid. // Programmeerimine N 4. C DV Koznov. Sissejuhatus tarkvaratehnikasse. I osa. Peterburi ülikooli kirjastus, 2005, 43 lk. 2 Siin parandasime klassikut veidi, tal oli nähtamatus .. 6

7 Loeng 2. Tarkvaraarenduse protsess Ilma protsessita ei saa aru. Tarkvaraprojektijuhi ärikirjavahetusest. Protsess Kuidas me töötame, milline on meie sammude järjekord, millised on normid ja reeglid käitumises ja töös, millised on meeskonnaliikmete omavaheliste suhete reeglid, kuidas projekt suhtleb välismaailmaga jne? Seda kõike koos kipume kutsuma protsessiks. Selle teadvustamine, joondamine ja täiustamine on iga tõhusa rühmategevuse aluseks. Seetõttu pole juhus, et protsess osutus üheks tarkvaratehnika põhimõisteks. Tarkvaratehnika keskseks õppeobjektiks on tarkvarakomplekti loomise protsess. mitmesugused tarkvara ja sellega seotud toodete (projektiplaanid, dokumentatsioon, programmikood, testid, kasutajadokumentatsioon jne) arendamiseks ja arendamiseks kasutatavad tegevused, meetodid, tehnikad ja sammud. Tänapäeval ei ole aga universaalset tarkvaraarendusprotsessi meetodite, reeglite ja eeskirjade jaoks, mis sobivad mis tahes tarkvara jaoks, mis tahes ettevõtte jaoks, mis tahes rahvusest meeskondadele. Igal käimasoleval arendusprotsessil, mille teatud meeskond teatud projekti raames läbi viib, on suur hulk funktsioone ja eripärasid. Siiski on soovitav enne projektiga alustamist planeerida tööprotsess, määratledes rollid ja vastutused meeskonnas, tööproduktid (vahe- ja lõpuosa), meeskonnaliikmete nende arendamisel osalemise järjekord jne. Nimetame seda eelkirjeldust konkreetseks protsessiks, eristades seda tööplaanist, projekti spetsifikatsioonidest jne. Näiteks Microsoft Visual Tem Systemis on protsessimall, mis luuakse või kohandatakse (standardi kasutamise korral üks) enne arenduse algust. VSTS-is on konkreetsete protsesside jaoks toorikud, mis põhinevad CMMI-l, Scrum-il jne. Ettevõtte sees on võimalik ja kasulik kombineerida ja standardida kõiki praeguseid protsesse, mida nimetame standardprotsessiks. Viimane osutub seega omamoodi andmebaasiks, mis sisaldab järgmist: infot, kasutusreegleid, ettevõtte projektides kasutatavate arendusvahendite dokumentatsiooni ja paigalduspakette (versioonikontrollisüsteemid, veakontrolli tööriistad, programmeerimisvahendid erinevatele IDE-dele, DBMS-id jne.). ) ; projektijuhtimise arenduspraktikate kirjeldus, kliendiga töötamise reeglid jms; lähteülesande projekteerimisdokumentide,e, katseplaanide jms mallid. jne. Samuti on võimalik standardida konkreetse protsessi väljatöötamise protseduuri "lõikena" standardsest. peamine idee standardne protsess parimate praktikate levitamine ettevõttes, samuti arendusvahendite ühtlustamine. Väga sageli on ettevõtetes erinevad osakonnad ja projektid arendusprotsessi küpsuse poolest väga erinevad, samuti on raske parimaid praktikaid taaskasutada. Juhtub ka seda, et ettevõte kasutab mitut paralleelset arendustööriista, näiteks DBMS-i versioonikontrolli tööriistu. Mõnikord on see õigustatud (näiteks need on kliendi nõuded), sageli on see vajalik, näiteks 7

8 Java.NET (offshore-firma suurem kompetents võimaldab vastu võtta laiemat valikut tellimusi). Kuid väga sageli on see arendajate endi meelevaldne valik. Igal juhul raskendab selline paljusus oluliselt spetsialistide migreerumist projektist projekti, ühe projekti tulemuste kasutamist teises jne. Standardprotsessi korraldamisel tuleb aga jälgida, et standardprotsess ei osutuks pelgalt formaalseks, bürokraatlikuks aparaadiks. Standardprotsessi kontseptsiooni tutvustatakse ja üksikasjalikult kirjeldatakse CMMI lähenemisviisis. Tuleb märkida, et standardprotsessi olemasolu viitab "ühtse tahte" olemasolule organisatsioonis, mis eksisteerib just protsessi tasandil. Kõigile ettevõtetele tuttavate müügi-, raamatupidamis- ja muude protsesside ja varade tasandil ei ole ühtsust raske saavutada. Kuid arendusprotsesside tasandil osutub iga projekt väga sageli iseseisvaks (eriti offshore-projektides), “käive” haarab ja isoleerib projektid üksteisest väga kindlalt. Protsessi täiustamise definitsioon. Protsessi täiustamine (tarkvaraprotsesside täiustamine) on tegevus, mille käigus muudetakse olemasolevat protsessi (nii jooksvat, ühe projekti raames kui ka standardset, kogu ettevõtte jaoks), et parandada loodavate toodete kvaliteeti ja/või vähendada nende valmistamise hinda ja aega. arengut. Põhjused, miks see tegevus on tarkvaraettevõtete jaoks asjakohane, on järgmised. 1. Tarkvaraarendustehnoloogiates on toimumas kiire muutus, mis eeldab uute arendusvahendite uurimist ja juurutamist. 2. Toimub ettevõtete kiire kasv ja nende sisenemine uutele turgudele, mis eeldab uus organisatsioon töötab. 3. Konkurents on suur, mis nõuab tõhusamate, kuluefektiivsemate arendusviiside otsimist. Mida saab parandada ja kuidas. 1. Üleminek uutele arendusvahenditele, programmeerimiskeeltele jne. 2. Individuaalsete juhtimis- ja inseneritestide praktikate, nõuete haldamise jne täiustamine. 3. Projekti, osakonna, ettevõtte kõigi protsesside täielik ja terviklik ümberkorraldamine (vastavalt näiteks CMMI-le). 4. Ettevõtte sertifikaat (CMM/CMMI, ISO 9000 jne). Eraldasime lõike 3 lõikest 4, kuna praktikas ei tähenda 4. alati tõelist loomingulist tööd tarkvara arendusprotsesside täiustamiseks, vaid sageli taandub see sertifikaadi saamiseks vajaliku töövoo säilitamisele. Sertifikaadi kasutatakse siis tööriistana, trumbina võitluses tellimuste eest. Ettevõtte protsesside reaalse täiustamise peamine raskus seisneb selles, et see peab töötama ja looma tarkvara üheaegselt, seda ei saa “registreerida”. Sellest tuleneb idee protsessi pidevast täiustamisest, nii-öelda väikeste portsjonite kaupa, et mitte nii valus olla. See on seda mõistlikum, et turule ilmuvaid uusi arendustehnoloogiaid ja ka olemasolevate arengut tuleb pidevalt jälgida. See strateegia kajastub eelkõige CMMI arendusprotsesside täiustamise standardis. 8

9 Tõmbe/tõuke strateegiad. Äriettevõtete (mitte tingimata tarkvaraettevõtete) tootmisprotsessidesse uuenduste juurutamise kontekstis on kaks järgmist paradigmat. 1. Organisatsiooni tõmbavad uuendused on suunatud ettevõtte spetsiifiliste probleemide lahendamisele. 2. Tehnoloogia tõukab strateegilistel põhjustel uuenduste ulatuslikku rakendamist. Konkreetsete probleemide asemel, mis pärast innovatsiooni juurutamist lahendatakse, lähtutakse sel juhul ettevõtte näitajatest (efektiivsus, tootlikkus, fondide aastakäive, aktsiate väärtuse tõus aktsiaselts ), mida pärast uuenduste kasutuselevõttu suurendatakse, täiustatakse. Samal ajal eeldatakse, et paljud organisatsiooni konkreetsed probleemid lahenevad automaatselt, sealhulgas need, millest hetkel midagi teada ei ole. Organisatsiooni tõmbamisstrateegia kasutamise näide on uute testimisvahendite kasutuselevõtt olukorras, kus projektis on kõrged kvaliteedinõuded või kui tarkvarasüsteemi kvaliteet ei rahulda klienti. Tehnoloogia tõukestrateegia kasutamise näide on ettevõtte üleminek struktuursete arendusvahenditelt objektorienteeritud tööriistadele. Teine näide sama strateegia kasutamisest on ISO 9000 või CMMI kvaliteedistandardite rakendamine. Mõlemal juhul ei lahenda ettevõte ühtki probleemi ega mitut probleemi, vaid soovib olukorda kardinaalselt muuta, astuda uutele piiridele jne. Tehnoloogia tõukestrateegia rakendamise probleem seisneb selles, et protsessi ülemaailmne ümberkorraldamine on vajalik. Aga ettevõtet ei saa selle aja jooksul rekonstrueerimiseks sulgeda, turupositsiooni võivad hõivata konkurendid, ettevõtte aktsiad võivad langeda jne. Seega toimub uuenduste juurutamine reeglina paralleelselt ettevõtte tavapärase tegevusega, etappide kaupa, mis tehnoloogia tõuke puhul on seotud suurte raskuste ja riskidega. Organisatsiooni tõmbamisstrateegia kasutamine on vähem riskantne, protsessis tehtavad muudatused on vähem globaalsed, rohkem lokaalsed. Kuid sellised uuendused toovad ka vähem kasu võrreldes edukate rakendustega vastavalt tehnoloogia tõukestrateegiale. Samuti tuleb märkida, et on probleeme, mida ei saa protsessi kohapealsete muudatustega kõrvaldada, see tähendab, et on vaja rakendada tehnoloogia tõukestrateegiat. Toome näitena tarkvaratoodete perekonna hoolduse ja arendamise protsessi, mis on seisma jäänud, ettevõte kannab suuri kahjusid, millega kaasnevad juba tarnitud tooted, projekti tööriistad on lootusetult vananenud ja haletsusväärses seisus, juhtkond on ärritunud, kõik juhtkonna katsed protsessi muuta põhjustavad meeskonna arusaamatust, tülisid ja konflikte. Võimalik, et sel juhul on revolutsioon hädavajalik. Teine erinevus kahe strateegia vahel seisneb selles, et organisatsiooni tõukejõu puhul on reeglina investeeringu tasuvus juurutamisel kiirem kui tehnoloogiatõuke puhul. Klassikalised protsessimudelid Protsessimudeli definitsioon. Tarkvara arendusprotsess ei ole homogeenne. Üks või teine tarkvaraarenduse meetod määrab reeglina teatud tüüpi tegevuste juurutamise dünaamika, see tähendab protsessi mudeli. I

10 Mudel on hea abstraktsioon erinevatest tarkvaraarendusmeetoditest, võimaldades neid esitada lühidalt, lühidalt ja informatiivselt. Protsessimudeli idee on aga tarkvaratehnikas üks varasemaid, mil arvati, et edukas mudel on kõige olulisem, mis arenduse õnnestumisele kaasa aitab. Hiljem saadi aru, et on palju muid aspekte (juhtimise ja arendamise põhimõtted, meeskonna struktuur jne), mis tuleb omavahel kokkuleppel määratleda. Ja hakkasid arenema integreeritud arendusmetoodikad. Siiski on mitmeid klassikalisi protsessimudeleid, mis on praktikas kasulikud ja mida arutatakse allpool. Faasid ja tegevused. Protsessimudelitest rääkides on vaja eristada faase ja tegevusi. Faas (faas) on protsessi teatud etapp, millel on algus, lõpp ja väljund. Näiteks projekti teostatavuse kontrolli faas, projekti üleandmine jne. Faasid järgivad üksteist lineaarne järjekord, iseloomustab aruandlus tellijale ja sageli ka raha maksmine tehtud tööosa eest. Harva on klient nõus tulemusi esimest korda nägema alles pärast projekti lõppu. Teisest küljest eelistavad töövõtjad raha saada järk-järgult, kuna üksikud tööosad saavad valmis. Seega on faasid, mis võimaldavad luua ja esitada projekti vahetulemusi. Faasid on kasulikud ka sõltumata suhtlemisest kliendiga, nende abil saab sünkroniseerida erinevate töörühmade tegevusi, samuti jälgida projekti kulgu. Faasid võivad olla näiteks lähteülesande kooskõlastamine tellijaga, teatud tarkvara funktsionaalsuse juurutamine, arendusetapp, mis lõpeb süsteemi testimiseks tarnimisega või alfaversiooni väljaandmisega. Tegevus on teatud tüüpi töö, mida tehakse tarkvara arendusprotsessi käigus. Erinevat tüüpi tegevused nõuavad sageli erinevaid kutseoskusi ja neid teostavad erinevad spetsialistid. Näiteks projektijuhtimist teeb projektijuht, kodeerimist programmeerija, testimist testija. On tegevusi, mida saavad teha samad inimesed, näiteks kodeerimise ja disainimisega (eriti väikese projekti puhul) tegelevad sageli samad inimesed. Ühe faasi jooksul saab läbi viia palju erinevaid tegevusi. Lisaks saab erinevates faasides sooritada ühte tüüpi tegevusi, näiteks testimist: analüüsi- ja projekteerimisfaasis saab kirjutada teste ja seadistada testkeskkonda, arenduse käigus ja enne tarnimist saab reaalselt ennast testida. Praegu kasutatakse keeruka tarkvara puhul mitmemõõtmelisi protsessimudeleid, milles faaside eraldamine tegevustest hõlbustab oluliselt tarkvaraarenduse juhtimist. Tegevused on tegelikult olemas erinevate nimetuste all igas tarkvaraarenduse meetodis. RUP-is nimetatakse neid töövoogudeks, CMM-is nimetatakse neid võtmeprotsessideks. Säilitame selles või teises meetodis kasutusele võetud traditsioonilised nimed, et mitte tekitada segadust. Kose mudeli pakkus välja 1970. aastal Winston Royce. Tegelikult toodi esimest korda tarkvaraarenduse protsessis esile erinevad arendusetapid ning kõigutati primitiivsed arusaamad tarkvaraarendusest süsteemianalüüsi ja selle kodeerimise näol. 10

11 Määratleti järgmised sammud: süsteeminõuete väljatöötamine, tarkvaranõuete väljatöötamine, analüüs, projekteerimine, kodeerimine, testimine, kasutamine vt joonis nõuete kallal töötamine jne. Märgiti, et selline tulu võib katastroofiliselt suurendada projekti maksumust ja selle elluviimise ajastust. Näiteks kui testimise käigus avastatakse projekteerimis- või analüüsivigu, siis nende parandamine toob sageli kaasa süsteemi täieliku ümberkujundamise. See mudel võimaldas ainult tagasi minna eelmisele etapile, näiteks testimisest kodeerimiseni, kodeerimisest disainini jne. Süsteeminõuete väljatöötamine Tarkvaranõuete väljatöötamine Analüüs Disain Kodeerimine Testimine Kasutamine Joon. Lõpuks võeti selle mudeli raames kasutusele prototüüpimine, st tehti ettepanek arendada süsteemi kaks korda, et vähendada arendusriske. Prototüübi esimene versioon võimaldab näha peamisi riske ja teha mõistlikult peamised arhitektuursed otsused. Prototüüpimine võttis kuni ühe kolmandiku arendusajast. Eelmise sajandi aastatel oli see mudel oma lihtsuse ja sarnasuse tõttu teiste, mittetarkvaraliste süsteemide arendusmudelitega tugevalt juurdunud tarkvaraarenduses. Tulevikus, seoses tarkvaratehnika arengu ja tarkvaraarenduse protsessi iteratiivsuse teadvustamisega, kritiseeris seda mudelit aktiivselt peaaegu iga asjassepuutuvate artiklite ja õpikute autor. On saanud üldtunnustatud seisukoht, et see ei kajasta tarkvaraarenduse funktsioone. Kose mudeli puudused on järgmised: faaside ja tegevuste tuvastamine, mis toob kaasa arenduspaindlikkuse kaotuse, eelkõige iteratiivse arendusprotsessi toetamise raskused; tegevusetapi täieliku läbimise nõue, tulemuste fikseerimine üksikasjaliku algdokumendi vormis (lähteülesanne, projekti spetsifikatsioon); tarkvaraarenduse kogemus näitab aga, et see on võimatu 11

12 täielikult täielikku nõuete väljatöötamist, süsteemi projekteerimist jne. kõik see võib muutuda; ja põhjusteks pole siin mitte ainult projekti keskkond mobiilsus, vaid ka see, et paljusid otsuseid ei ole võimalik eelnevalt täpselt määrata ja sõnastada, neid täpsustatakse ja täpsustatakse alles hiljem; kõigi arendustulemuste integreerimine toimub lõpus, mille tulemusena annavad lõimumisprobleemid tunda liiga hilja; kasutajad ja klient ei saa arenduse käigus süsteemi võimalustega tutvuda ning näevad tulemust alles päris lõpus; seega ei saa nad mõjutada süsteemi loomise protsessi ning seetõttu suurenevad arendajate ja kasutajate/kliendi vahelise arusaamatuse riskid; mudel on ebastabiilne projektide rahastamise või raha ümberjagamise ebaõnnestumiste suhtes, alustatud arendusel pole tegelikult alternatiive. Kuid seda mudelit kasutatakse praktikas jätkuvalt väikeste projektide või arendustegevuse puhul tüüpilised süsteemid, kus iteratsioon pole nii nõutud. Selle abiga on mugav jälgida arengut ja teostada projekti etapiviisilist kontrolli. Seda mudelit kasutatakse sageli ka tunnipalgaga offshore-projektides3. Kose mudel on muude mudelite ja metoodikate lahutamatuks osaks, näiteks MSF-is. Spiraalmudeli pakkus välja Bary Boehm 1988. aastal, et ületada kosemudeli puudused, eelkõige parem juhtimine riske. Selle mudeli järgi toimub tootearendus spiraalina, mille iga pööre on teatud arendusfaas. Erinevalt kosemudelist ei ole spiraalmudelil etteantud ja kohustuslikku keerdude komplekti, iga pööre võib olla süsteemi arenduses viimane, selle valmimisel koostatakse järgmise pöörde plaanid. Lõpuks on mähis vaid faas, mitte teatud tüüpi tegevus, nagu jugamudeli puhul saab selle raames läbi viia palju erinevat tüüpi tegevusi, see tähendab, et mudel on kahemõõtmeline. Pöörete järjestus võib olla järgmine: esimesel pöördel otsustatakse tarkvara loomise otstarbekuse üle, järgmisel Nõuded süsteemile, siis viiakse läbi süsteemi projekteerimine jne. Pööretel võib olla ka teisi tähendusi. Igal voorul on järgmine struktuur (sektorid): projekti eesmärkide, piirangute ja alternatiivide määratlemine; alternatiivide hindamine, riskide hindamine ja lahendamine; on võimalik kasutada prototüüpimist (sh prototüüpide seeria loomist), süsteemi simulatsiooni, visuaalset modelleerimist ja spetsifikatsiooni analüüsi; keskendumine projekti kõige riskantsematele osadele; siin on võimalik arendus ja testimine, kose mudel või muude tarkvaraarenduse mudelite ja meetodite kasutamine; järgmiste iteratsioonide planeerimine, analüüsitakse tulemusi, plaane ja ressursse edasiseks arendamiseks, tehakse otsus (või mitte) uue vooru kohta; analüüsitakse, kas süsteemi arendamist on mõtet jätkata või mitte; arendus võib peatada näiteks rahastamise häirete tõttu; spiraalmudel võimaldab seda õigesti teha. 3 Inglise keelest offshore väljaspool rannikut, laiendatud tõlgenduses väljaspool ühte riiki. 12

13 Individuaalne spiraal võib vastata mõne tarkvarakomponendi arendusele või sissejuhatusele järgmised muudatused toote sisse. Seega võib mudelil olla kolmas mõõde. Spiraalmudelit ei saa kasutada väikeste projektide puhul madala riskiastmega ja piiratud eelarvega projektides. Lisaks võib spiraalmudeli kasutamise ebamugavaks muuta ka heade prototüüpimisvahendite puudumine. Spiraalmudel pole tööstuses laialdast rakendust leidnud ning on olulisem ajaloolises ja metoodilises mõttes: see on esimene iteratiivne mudel, sellel on ilus spiraalmetafoor ning sarnaselt kosemudeliga kasutati seda hiljem ka teiste protsessimudelite loomiseks ja tarkvara arendamise metoodikad. Kirjandus 1. I.Sommerville Software Engineering. 6. väljaanne. Addison-Wesley, lk. / Vene tõlge: I. Sommerville. Tarkvaraarendus. Williamsi kirjastus, c. 2. W. Humphrey. Tarkvaraprotsessi haldamine. Addison-Wesley, lk. 3. R. W. Zmud. "Push-Pull" teooria uurimine, mida rakendatakse teadmustöö protsessiinnovatsioonile, Juhtimisteadus, kd. 30(6), 1984, lk B. Boehm. Tarkvaraarenduse ja täiustamise spiraalmudel. // IEEE Computer, kd 21, #5, mai P W. W. Royce. Suurte tarkvarasüsteemide arendamise juhtimine. Proceedings of IEEE WESCON, August P Taasvälja antud: Proceedings of the 9th Rahvusvaheline tarkvara Engineering Conference, Computer Society Press, P R.T.Fatrepp, D.F.Schafer, L.I.Schafer. Tarkvaraprojektide juhtimine: saavutus optimaalne kvaliteet minimaalsete kuludega. Ed. maja "Williams" c. 7. D.V. Koznov. Visuaalse modelleerimise keeled: tarkvara disain ja visualiseerimine. Ed. Peterburi Riiklik Ülikool, lk. 8. D.V. Koznov. Sissejuhatus tarkvaratehnikasse. I osa. Peterburi ülikooli kirjastus, 2005, 43 lk. 9. D. Aachen, A. Clause, R. Turner. CMMI: integreeritud lähenemisviis protsesside täiustamisele. Per inglise keelest. M.: MFK s. 10. CMMI arenduse jaoks, versioon 1.2. CMMI-DEV (versioon 1.2, august 2006). Carnegie Melloni ülikooli tarkvaratehnika instituut (2006). Välja otsitud 22. augustil

14 Loeng 3. Tööprodukt, pühendumusdistsipliin, projekt tööstuslik tootmine mis on ammu tavaliseks saanud. Esiteks on see pühendumise distsipliin ja tööprodukt. Need teadmised, mida praktikas omandatakse, on äärmiselt kasulikud meeskonnatöö. Lisaks kasutavad praegu praktikas laialdaselt kasutatavad tarkvaraarendusmetoodikad, mida toetavad vastavad tarkvaravahendid, neid mõisteid aktiivselt, täpsustades ja konkretiseerides. Töötoode Tööstusprotsessi juhitavuse üheks oluliseks tingimuseks on eraldi teostatud töötulemuste olemasolu nii lõpptarne- kui ka vahetöödel. Need individuaalsed tulemused osana üldtulemused tööd aitavad tuvastada, planeerida ja hinnata tulemuse erinevaid osi Vahetulemused aitavad erineva tasemega juhtidel jälgida projekti elluviimise protsessi, tellija saab võimaluse tutvuda tulemustega ammu enne projekti lõppu. Veelgi enam, projektis osalejad ise saavad oma igapäevatöös lihtsa ja tõhusa võimaluse tööalase teabe ja tulemuste vahetamiseks. See väljund on töötoode – mis tahes tarkvaraarendusprotsessi käigus toodetud artefakt, näiteks fail või failide komplekt, dokumendid, tootekomponendid, teenused, protsessid, spetsifikatsioonid, arved jne. Osa lõpptarnest Vahetase Mõnikord Töötoode Näiteks Kasutaja dokumentatsioon Tarkvarakomponendid Väljakujunenud protsessid Joon

15 Peamine erinevus töötoote ja tarkvarakomponendi vahel seisneb selles, et esimene ei pruugi olla käegakatsutav ja käegakatsutav (mitte kujundada), kuigi see võib olla. Immateriaalne töötoode on reeglina mingi väljakujunenud protsess - tööstusprotsess mis tahes toote valmistamiseks, õppeprotsess ülikoolis (teaduskonnas, osakonnas) jne. Oluline on märkida, et töötoode ei pruugi seda olla lahutamatu osa lõplik tarnimine. Näiteks väljakujunenud süsteemi testimise protsessi ei edastata kliendile koos süsteemi endaga. Projektide juhtimise oskus (mitte ainult programmeerimise vallas) on suuresti seotud vajalike tööproduktide väljaselgitamise, nende loomise nõudmise ja nende mõistes töö vaheetappide aktsepteerimise, erinevate töörühmade sünkroniseerimise korraldamise kunstiga. ja üksikud spetsialistid. Paljud metoodikad sisaldavad konkreetsete töötoodete kirjeldust, mida kasutatakse CMMI, MSF, RUP jne protsessis Näiteks MSF-is on nendeks programmikood, rakendus- ja klassiskeemid (rakendusdiagrammid ja klassidiagrammid), iteratsiooniplaan (iteratsiooniplaan) , ühikutest (ühiktest) jne. Igaühe puhul on täpselt kirjeldatud sisu, arenduse eest vastutav, koht protsessis ja muud aspektid. Vaatame lähemalt vahepealseid töötooteid. Töötooteks osutub ühe arendaja projektis loodud ja teise arendaja poolt kasutamiseks antud tarkvarakomponent. Seda on vaja minimaalselt testida, parandada liideste klasside ja meetodite nimetusi, võib-olla tuleks eemaldada üleliigne, mis pole selle komponendi funktsionaalsusega seotud, tuleks parem eraldada avalik ja privaatne jne. See tähendab, et teha lisatööd, mida arendaja võib-olla ei teeks, kui ta jätkaks komponendi kasutamist ainult ise. Selle lisatöö maht suureneb oluliselt, kui komponent soovitakse anda arenduses kasutamiseks näiteks mõnele teisele arenduskeskusele (näiteks välispartneritele, mis on offshore-arenduses tavaline olukord). Seega on heade vahetöötoodete valmistamine projekti õnnestumiseks väga oluline, kuid nõuab nende autoritelt lisatööd. Üksi töötamine ilma töötooteid pakkumata on paljude jaoks lihtsam ja ihaldusväärsem. Kuid meeskonnas töötamine nõuab üldkulusid, sealhulgas kulutusi vahetöötoodete loomisele. Loomulikult on nende toodete kvaliteet ja nende valmistamisel kasutatud tööjõud olenevalt olukorrast väga erinev, kuid oluline on mõista põhimõtet. Kokkuvõtteks võib öelda, et vahepealsel töötootel peab tingimata olema selge eesmärk ja konkreetsed kasutajad, et selle loomisega seotud üldkulusid minimeerida. 15

16 Arengukontrolli tulemuste jagamine Tööks kasutatav Toode peab olema Nõuab Eesmärk Kasutaja Üldkulud Joon Pühendumise distsipliin Ettevõtlus- ja tööstustootmise tööülesannete lahusus põhineb, ettevõtte reeglid ja regulatsioonid põhinevad teatud ärieetikal, kohustuste suhtedistsipliini vormil. Seda kasutatakse laialdaselt praktikas ja see on üks võimalikest inimestevaheliste sotsiaalsete suhete vormidest. Teiste inimsuhete mudelite – perekondlik, seksuaalne, sõbralik jne – juurutamine ärisse ja tööstusesse. põhjustab sageli tõsist kahju asjadele, tekitab konflikte, vähendab efektiivsust. Selle suhtevormi aluseks on kohustused, mis: antakse vabatahtlikult; töö ei ole kerge, tuleb hoolikalt läbi mõelda vahendid, ajakava; osapoolte vahel hõlmab see, mida, kes ja mis aja jooksul teeb; avalikult ja avalikult sõnastatud (st see ei ole salateadmine). Lisaks: vastutav pool püüab oma kohustusi täita, isegi kui abi vajatakse; enne tähtaega, niipea kui selgub, et töid ei saa õigeks ajaks valmis teha, hakatakse uute kohustuste võtmisel läbi rääkima. Pange tähele, et kohustuste distsipliin ei ole mingi reeglite, seaduste kogum, see erineb ka ettevõtte kultuurist. See on teatud grupi vaimne nähtus, mis eksisteerib tänapäeva inimeste ühiskonnas. Ülaltoodud punktid ei ole selle nähtuse ammendav kirjeldus, vaid ainult manifesteerivad ja määravad seda, nii-öelda kutsuvad esile vajalikke mälestusi. Kohustuste distsipliini, hoolimata ilmselgusest, ei rakendata mõnikord lihtsalt praktikas, näiteks inimtegevuse loomingulistes valdkondades, 16.

17 koolitus jne. On üksikuid inimesi, kellele see distsipliin on sisemiselt võõras, olenemata nende tegevuse liigist. Teisest küljest püüavad selle distsipliini omandanud inimesed sageli rakendada seda teistes eluvaldkondades ja inimsuhetes, mis ei ole alati õigustatud. Rõhutame, et see distsipliin pole kaugeltki ainus inimestevaheliste suhete mudel. Näitena võib tuua perekondlikud suhted või sõprussuhted, mida ilmselgelt ei saa väljendada kohustuste distsipliiniga. Seega on nendes suhetes täpsuse ja täpsuse asemel oluline emotsionaalne-sensoorne empaatia, ilma milleta on need võimatud. MSF-is pööratakse palju tähelepanu pühendumise distsipliinile, kuna meeskonnamudelis pole juhti ega ülemust. Seda distsipliini rakendatakse ka Scrumis: Scrumi meeskonnal on palju vabadusi ja seega ka suur vastutus. Tegevusreeglid on reguleeritud ka siis, kui selline meeskond ei suuda kohustusi täita. Projekt Klassikaline operatiivne tööjaotus pärineb Adam Smithilt ja on masstööstusliku tootmise põhiolemus. Ehk siis on väljakujunenud tööprotsess ja on spetsialiseerumisvaldkonnad: üks töökoda teritab, teine hööveldab, kolmas kogub, neljas värvib jne. Sellise toodangu läbilaskevõime ületab tunduvalt ühe inimese või grupi kogu töö jõudlust. Nii sai 19. sajandil manufaktuuride aluseks operatiivne tööjaotus, mis tõrjus välja individuaalse, käsitöölise tootmise. 20. sajandi alguses viidi see tööstruktuur üle juhtimise alla, st kontrollisid arvukad juhid eraldi sektsioonid töötab. Mitmete ülesannete keerukus tööstuses ja ettevõtluses ei võimalda aga (õnneks!) igal pool niimoodi töötada. On palju loomingulisi, uusi ülesandeid, kus võib-olla on tulevikus võimalik luua konveiereid, kuid hetkel nõuab nende lahendamine inimeste märkimisväärset jõu ja energia koondamist, ootamatuid otsuseid, samuti õnne ja kerge käsi. See on projektide valdkond. Projekt on ainulaadne (erinevalt traditsioonilisest järkjärgulisest tööstuslikust tootmisest) tegevus, millel on ajas algus ja lõpp ning mille eesmärk on saavutada kindel tulemus/eesmärk, luua konkreetne, unikaalne toode või teenus etteantud ressursi ja ajaga. piirangud, aga ka kvaliteedinõuded vastuvõetav tase risk. Eelkõige on tarkvaraarendus valdavalt projektivaldkond. Tuleb teha vahet tööstusprojektidel ja loomingulistel projektidel. Neil on erinevad põhimõtted juhtimine. Tööstusprojektide keerukus paljudes erinevates organisatsioonides, ettevõtetes ja tööde endi suhteline ainulaadsus. Näide mitmekorruselise hoone ehitamisest. See hõlmab ka erinevaid rahvusvahelisi projekte, mitte ainult tööstus-, haridus-, kultuuri- jne projekte. Selliste projektide juhtimise ülesanne on kõike katta, kõike kontrollida, mitte midagi unustada, kõik kokku viia, saavutada liikumine ja koordineeritud liikumine. Loomingulisi projekte iseloomustab idee absoluutne uudsus uus teenus, täiesti uus tarkvaratoode, mis pole veel turule tulnud, kunsti- ja teadusvaldkonna projektid. Iga alustav ettevõte on reeglina selline loominguline projekt. Pealegi pole selliste projektide uudsus mitte ainult absoluutne, seda pole kunagi varem juhtunud. See võib olla projektimeeskonna poolt juba juhtunud, kuid mitte unenägudes. See tähendab, et seda projekti kehastavate inimeste endi jaoks on tohutult suhtelist uudsust. 17

18 Tarkvaraarendusprojekti asuvad nende kahe äärmuse vahel, hõivates selles ruumis erinevaid positsioone. Sageli on need keerulised, kuna need on mahukad ja on selle erinevate erialade ristumiskohas sihtettevõte kuhu tarkvaratoode peaks olema manustatud, ja keeruline, mittetriviaalne programmeerimine. Sageli lisandub siia unikaalsete elektromehaaniliste seadmete väljatöötamine. Teisest küljest, kuna programmeerimist propageeritakse aktiivselt erinevad valdkonnad inimtegevus, siis toimub see täiesti uute ainulaadsete toodete loomise kaudu ning nende arendamisel ja reklaamimisel on kõik loominguliste projektide omadused. Projektijuhtimine on tegevusvaldkond, mille käigus teatud projektide raames määratletakse ja saavutatakse selged eesmärgid, leides samal ajal kompromissi töömahu, ressursside (nagu aeg, raha, tööjõud, materjalid, energia, ruum jne) vahel. .), aeg, kvaliteet ja risk. Märgime ära mitu projektijuhtimise olulist aspekti. Sidusrühmad on inimesed/pooled, kes ei ole projektiga otseselt seotud, kuid mõjutavad seda ja/või on huvitatud selle tulemustest. Nendeks võivad olla süsteemi tulevased kasutajad (näiteks olukorras, kus nad ja klient ei ole samad), arendajafirma kõrgem juhtkond jne. Eduka projektijuhtimise oluline komponent on kõigi sidusrühmade väljaselgitamine ja pädev töö nendega.Projekti ulatus on projekti piirid. See on nõuete varieeruvuse tõttu tarkvaraprojektide jaoks väga oluline kontseptsioon. Sageli juhtub, et arendajad hakkavad looma ühte süsteemi ja siis järk-järgult muutub see teiseks. Veelgi enam, müügijuhtide ja ka kliendi jaoks ei juhtunud midagi radikaalselt, kuid tarkvara sisemise struktuuri, tehnoloogiate, rakendusalgoritmide ja arhitektuuri seisukohalt muutub kõik radikaalselt. Projektijuhtkond peaks selliseid suundumusi jälgima ja asjatundlikult käsitlema. Kompromissid on tarkvara järjepidevuse tõttu tarkvaraprojektide juhtimise kriitiline aspekt. Oluline on mitte kaotada kõiki kokkulepitud parameetreid ja osapooli ning leida vastuvõetav kompromiss. MSF-i metoodika uurimise kontekstis arutatakse üht nende kompromisside juhtimise tehnikat. MSF 3.1 järgsete tarkvaraprojektide väljatöötamisel on olulised järgmised juhtimisvaldkonnad. Projektijuhtimise valdkonna kirjeldus Projekti planeerimine ja monitooring, projekti muudatuste kontroll (Projekti planeerimine / Jälgimine / Muudatuste juhtimine) Projekti ulatuse juhtimine (Scope Management) Projekti ajakava haldamine (Schedule Management) Projektiplaanide integreerimine ja sünkroniseerimine; protseduuride ja süsteemide korraldamine projekti muudatuste juhtimiseks ja seireks Tööde mahu määramine ja jaotamine (projekti ulatus); projekti kompromisside haldamine Tööprognooside ajastamine, ülesannete järjestamine, olemasolevate ressursside sobitamine ülesannetega, 18

19 Kulude juhtimine Personal Ressursijuhtimine Sidejuhtimine Riskijuhtimine Hangete Kvaliteedijuhtimine Statistiliste meetodite rakendamine, ajakava tugi Kuluprognoosid, mis põhinevad ajakalkulatsioonidel kuludel; projekti edenemise aruandlus ja analüüs; kulude riskianalüüs; väärtusanalüüs Ressursiplaneerimine; projektimeeskonna moodustamine; konflikti lahendamine; ettevalmistuse planeerimine ja juhtimine Kommunikatsiooni planeerimine (vahel projekti tiim, klient/sponsor, tarbijad/kasutajad jne. sidusrühmad); projekti edenemisest aruandlus Meeskonnasisese riskijuhtimise protsessi sisseseadmine ja hõlbustamine; riskijuhtimise töövoo pakkumine Teenusepakkujate ja/või riist-/tarkvara hindade analüüs; pakkumiste algatamise dokumentide (pakkumistaotluste RFP) koostamine, tarnijate ja alltöövõtjate valik; lepingute koostamine ja nende tingimuste läbirääkimine; lepingud; ostutellimused ja maksetaotlused Kvaliteedi planeerimine, kohaldatavate standardite määratlemine, kvaliteedikriteeriumide ja kvaliteedi mõõtmise protsesside dokumenteerimine Kirjandus 1. W. Humphrey. Tarkvaraprotsessi haldamine. Addison-Wesley, lk. 2. D. Aachen, A. Clause, R. Turner. CMMI: integreeritud lähenemisviis protsesside täiustamisele. Per inglise keelest. M.: MFK s. 3. Carnegie Melloni ülikooli tarkvaratehnika instituut (2006). Välja otsitud 22. augustil

20 4. loeng. Tarkvaraarhitektuuri arutelu Ühel päeval selgitas juht ühe enda juhitud küllaltki suure projekti peamisi ideid. Ta joonistas tahvlile kolm kuubikut: frontend, backend, tööriistad. Ja ta ütles, et see on projekti põhistruktuur. Nii toote sisemise struktuuri kui ka meeskonnatöö jaotuse poolest kolme eemal asuva arenduskeskuse vahel. Taustaprogrammi ülesanded on keerulised, ressursimahukad ja neid täidetakse partiidena. Need on eraldatud toote graafilisest liidesest (frontend), mis pole samuti lihtne. Frontend on kasutajaliides: keerukas, parameetritega seadistatav, paljude sisseehitatud kasutajateenustega (eelkõige teabebrauser) ja ka kohandatav. Mõlemad alamsüsteemid suhtlevad üksteisega läbi täpselt määratletud ja üksikasjaliku programmeerimisliidese: taustaprogrammi algoritmid jaotatakse meetoditeks, mida kasutajaliides saab erireeglite järgi kutsuda, koos parameetritega, aheldades oma eesmärkide saavutamiseks. Kõige selle "küljel" on lisatööriistad. Nad integreeruvad frontendisse, kuid ei kasuta taustameetodeid, vaid rakendavad oma ülesandeid iseseisvalt. Need ülesanded ei nõua keerulisi partii töötlemine ja on suunatud interaktiivsele suhtlusele kasutajaga. Nende rakendamisel pöörati palju tähelepanu kasutatavusele. Kõik kolm alamsüsteemi nõudsid arendajatelt spetsiifilisi oskusi. Taustaprogrammi puhul oli selleks oskus ja kogemus sedasorti pakk-algoritmide realiseerimisel, frontendi puhul oskus luua keerukat kasutajaliidest, tööriistade puhul nõudis oskust “kergekaaluliste” kujundamisel ja juurutamisel. ” tööriistad, mis pakuvad süsteemi kasutajatele täiendavaid teenusevõimalusi. Teoste sellisel jagamisel oli ka mitmeid poliitilisi aspekte. Eelkõige soovis projektijuhtkond, et kasutajaliidese arendusprotsess oleks neile lähedal, ühes kolmest peakorteriga kokku langenud arenduskeskusest. Usuti, et toote välimus on selle edukaks müügiks väga oluline ja nõuab erilist tähelepanu. Projekti tulemusena (ja see on arenenud juba üle 15 aasta, ulatudes haripunktis kuni 150 samaaegselt selles töötavate inimesteni) on selline selge struktuur mõnevõrra nihkunud, nii et geograafiliselt on liides peaaegu “kolinud” keskus, kus taustaprogramm arendati. Kuid üldiselt jäi selline projekti otsast lõpuni osadeks jagamine püsima paljudeks aastateks ja oli kogu arenduse põhiskelett. See on näide tarkvaraprojekti arhitektuurist. Definitsioon Tarkvaraarhitektuuri all mõistame toote sisemist struktuuri (komponendid ja nende ühendused), toote kasutajaliidese põhitõdesid, aga ka arendus- ja projektijuhtimise tööriistaks olevate teadmiste ja lahenduste kvintessentsi. See tähendab, et arhitektuur on läbiv kontseptsioon või nende kogum entroopia ja kaose ületamiseks, mille eesmärk on tarkvara keerukust, hoomamatust, järjepidevust ja varieeruvust silmas pidades arengut "alla neelata". Samal ajal ei eralda me toodet ja projekti, kuna praktikas on see reeglina üks tervik ja see "läbivus", kui see on olemas, on selle arenduse "tugevus". Sageli mõistetakse arhitektuuri all näiteks ainult tarkvara sisemist struktuuri, mida väljendatakse UML-diagrammides. Siin on nali selle üle, et arhitektuuri ei saa ühekülgselt mõista. Kuulsalt ringhäälinguorganisatsioonilt küsiti, miks tema kuulsal ringhäälingul oli täpselt 21 vaatamist. Ootasime, et kuuleme loendit algoritmilistest probleemidest, mis meil õnnestus sel viisil ületada, umbes 20

Osa 2: Kasutajate vajaduste mõistmine Lisa D SEI-CMM ja ISO 9000 nõuete halduspõhimõtted SEI-CMM nõuete halduspõhimõtted 1986. aasta novembris instituudis

GOST R ISO/IEC TO 9294-93 VENEMAA FÖDERATSIOONI RIIGISTANDARDI Infotehnoloogia JUHEND TARKVARA DOKUMENTATSIOONI HALDAMISEKS GOSSTANDARD VENEMAA Moskva Eessõna

GOST R ISO / IEC TO 9294-93 Group T55 VENEMAA FÖDERATSIOONI RIIGISTANDARD Infotehnoloogia JUHEND TARKVARA DOKUMENTATSIOONI HALDAMISEKS Infotehnoloogia.

Planeerimine Teostus / Kontroll ja analüüs Otsuste tegemine Projektijuhtimine Infotehnoloogiad "1C: Enterprise" ETTEVÕTETE RAKENDAMISE TEHNOLOOGIA: AKSIOOMID, ELUTSÜKLI MUDEL JA PIIRKOND

GOST R ISO/IEC TO 9294-93 VENEMAA FÖDERATSIOONI RIIGISTANDARDI Infotehnoloogia JUHEND TARKVARA DOKUMENTATSIOONI HALDAMISEKS Ametlik väljaanne GOSSTANDARD VENEMAA

SÜSTEEMEHNIKA ALUSED LOENG 1. SÜSTEEMINEERIMISE PÕHIMÕISTED 1.1. Süsteemitehnika tekkimine

Pealkiri: "Kvaliteedijuhtimine tarkvaraarendusprotsessides." (Kvaliteedijuhtimine tarkvara arendusprotsessides.)

B.A. Êîïíîâ ÌÅÒÎÄÈ ÅÑÊÈÅ ÓÊÀÇÀÍÈß ISO 9001 Ñèñòåìû Ìåíåäæìåíòà Êà åñòâà Ñåìèíàð äëÿ âûñøåãî ðóêîâîäñòâà Ñåðèÿ ìåæäóíàðîäíûõ ñòàíäàðòîâ ISO9000 Ïðèíöèïû ìåíåäæìåíòà êà åñòâà òî òàêîå Ñèñòåìà Ìåíåäæìåíòà

D. F. Ustinovi nimeline BALTIRIIK TEHNIKAÜLIKOOL "VOENMEH" Ülevaade standardist GOST R ISO/IEC 12207-99.

VENEMAA FÖDERATSIOONI HARIDUSMINISTEERIUM

ISO logo dokument: ISO/TC 176/SC 2/N 544R3 Meie number ISO/TC 176/SC 2 sekretariaat Kuupäev: 15. oktoober 2008 ISO 9000 juurutamis- ja hoolduspakett: kontseptsiooni juhend

Meeskonnaülene koostöö Rational Team Concert for Power lihtsustab oluliselt kriitilist koostööd. aprill 2010 Don Yantzi

UDC 004.55 IT-ETTEVÕTETE TARKVARAARENDUSE JUHTIMISE TUNNUSED 2013 O.S. Kulakova* Märksõnad: tarkvaraarendus, tarkvaraarenduse juhtimine,

Teaduslikud ja praktilised tulemused 2014. aastal. Nende arendamise väljavaated Tolepbergen S. O., Ph.D. n. Bermukhamedova G. B. Kasahstan, Aktau, Kasahstani Riiklik Tehnika- ja Tehnikaülikool

Merezhnі tekhnologii-2 Internetitehnoloogiad Loeng Tarkvaraarenduse metoodika Shtogrina Elena Sergeevna Metoodika Metoodika on põhimõtete süsteem, samuti ideede, kontseptsioonide, meetodite, meetodite ja

266 E. I. Plastinina Vjatka Riiklik Põllumajandusakadeemia, Kirov

Fred Brooks ja "müütiline meeskuu" Frederick Phillips Brooks Jr. Sündis 19. aprillil 1931 Durhamis, Põhja-Carolinas. 1953. aastal lõpetas Duke'i ülikooli 1956. aastal sai doktorikraadi. rakendatud

UDC 338.24.01 INTEGREERITUD HALDUSSÜSTEEMI ARENDAMINE JA RAKENDAMINE T.A. Salimova, majandusdoktor. teadused, professor, juhataja. Mordovia osariigi ülikooli riikliku kõrgkooli kvaliteedijuhtimise osakond

Sissejuhatav loeng Loengu eesmärk: 1. Näidata infotehnoloogia tähtsust ja asjakohasust organisatsiooni (ettevõtte) juhtimisel 2. Määrata distsipliini õppimise nõuded. 3. Esitage kirjeldus

SWorld, 17.–28. juuni 2014 http://www.sworld.com.ua/index.php/ru/conference/the-content-of-conferences/archives-of-individual-conferences/june-2014 MODERNIDE PROBLEEMID JA VIISID NENDE LAHENDUS TEADUSES, TRANSPORTIS,

UDC 654-34 INVESTEERINGUTE JUHTIMINE INFOTEHNOLOOGIADES ISO/IEC 15288 STANDARDI JA ETTEVÕTETE KÜPSUSE MUDELIL PÕHINEV Godunova Anastasia Olegovna, majandusteaduskonna 4. kursuse üliõpilane, e-post:

KLIENT-SERVER SÜSTEEMI TESTIMISE PLAAN 1 SISUKORD 1. SISSEJUHATUS ... 3 1.1. Testimise eesmärgid... 3 1.2. Testimisstrateegiad... 3 1.3. Testimise liigid... 3 1.4. Dokumentatsioon... 5 2. KATSETÜKKEL...

EDUKUTE PANKADE SALADUSED ISAEV EDUKUTE PANKADE SALADUSED: kvaliteedijuhtimine ja ISO 9000 ELECTRONIC ORGANIZER BOOK Moscow INFRA M 2012 UDC 650 BBC 65.290 I85 I85 Isaev R.A. Edukate pankade saladused:

Tarkvaraarendustehnoloogia 2015-2016 Loengud 3-4: paindlikud tehnoloogiad Pudov Sergei Grigorjevitš TOR-i ja tööplaani koostamine Lähteülesanne (TOR) dokument, mis sisaldab nõuete kogumit

Višnjakov Oleg Leonidovitš, Business Consulting OÜ "Business Logic" direktor, Tulintsev Konstantin Gennadievitš, OÜ "Business Logic" konsultant Protsessi lähenemine organisatsiooni juhtimisele Natuke ajalugu

Arenduskvaliteedi juurutamine Atom/MeeGo platvormile V. I. Kiyaev 1 Loeng 13 Kvaliteedi juurutamine

ISSN 2079-8490 Elektrooniline teadusväljaanne "Scientific notes of the PNU" 2014, 5. köide, 4, lk 20 24 [e-postiga kaitstud] UDK 338.242.2

Sissejuhatus Praegu on enamikus erineva profiiliga organisatsioonides vaja spetsialiste, kes valdavad professionaalselt erinevaid kaasaegseid infotehnoloogiaid. Kell

Zherebina O.G., [e-postiga kaitstud] Firma "1C", Moskva Kutsestandardi "Infosüsteemide spetsialist" kasutamine kõrg- ja keskerihariduses Kutsearenduse projekt

VENEMAA FÖDERATSIOONI RIIKLIK TEHNILINE KOMISJON Juhenddokument ARVUTISEADMED. TULEMüürid. KAITSE TEABELE LOATAMATA JUURDEPÄÄSU EEST. TURVALISINÄITAJAD

ELEKTROONILINE TEADUSLEHT “APRIORI. SARI: LOODUS- JA TEHNIKATEADUSED" 6 2015 UDC 004 TÖÖOHUTUSE OSAKONNA AUTOMATISEERIMINE Baulin Stanislav Sergeevitš Mordovia Riikliku Ülikooli bakalaureuseõpe

NOU HPE Erakõrgharidusasutus "ESSENTUK INSTITUTE OF MANAGEMENT, BUSINESS AND LW" Kõrgmatemaatika ja informaatika osakond EIUBiP CHOU HE EIUBP DISTSIPLIINI TÖÖPROGRAMM

ISE TEISTE AITAMINE AITAS ENDA Marianna Matjukova, asetäitja. Kvaliteedidirektor, Alter Logo Hästi toimiv ja tõhus kvaliteedijuhtimissüsteem võib tagada püsivalt kõrge edu

1 2 3 4 5 6 7 80 9 0 Loeng 6 Tehnoloogilise kihi elemendid. Tehnoloogilise arhitektuuri modelleerimisteenuse liides Artefaktide funktsionaalsus Node Network 90/142 rakendab Autoriõigus Rubenchik A.V. 2016. Kõik

Teema 3 Projekti etapid ja selle elutee. Projekti väljatöötamine ja hindamine Iga projekt, olenemata selle keerukusest, mahust või elluviimiseks vajaliku töö mahust, läbib oma väljatöötamise

UDC 002:658.516+658.562 P.V. STRELNIKOV KVALITEEDIJUHTIMISSÜSTEEMIDE SERTIFITSEERIMISEST Kokkuvõte: Kvaliteedijuhtimissüsteemide loomise põhistiimul ettevõtetes luuakse. Mõned eelised

LOGISTILISE LÄHENEMISE KASUTAMINE ETTEVÕTTE TEGEVUSES UUENDUSLIKE TOODETE LOOMISES Levkin G.G. loomaarst. majandusteaduse erialal, Omski transpordiökonoomika, logistika ja kvaliteedijuhtimise osakonna dotsent

SISSEJUHATUS Käesolev käsiraamat on koostatud vastavalt eriala "Rakendusinformaatika majandusteaduses" riikliku haridusstandardi nõuetele ja kajastab distsipliini "Arendus" järgmisi jaotisi.

Juhend Arvutiseadmed. Tulemüürid Kaitse volitamata juurdepääsu eest teabele Kaitse indikaatorid volitamata juurdepääsu eest teabele Kinnitatud

Tulemusjuhtimise süsteem Tehnoloogia areng, turutingimuste muutused ja konkurentsi suurenemine seavad ettevõtetele ja organisatsioonidele ülesandeks parandada juhtimise efektiivsust,

ÄRIKINNITUS ISO 9001:2015 põhimuudatuste ülevaade 2016-02-22 1 TURVAM, TARKAM, ROHELISEM Sisu ISO 9001 põhiarengud Ühtne struktuur kõrgeim taseÜhtlustamine

Fastweli kvaliteedijuhtimissüsteem: juurutamise ja sertifitseerimise kogemus Aleksey Maklakov

Integratsiooni- ja välissüsteemid "Ettevõtte juhtimine" 12 (47), 2014 IT-infrastruktuur Mihhail Kireev KORUS Consulting Group of Companies 1C osakonna arendusosakonna juhataja. Juhtis arendusprojekte ja

SIBERI TARBIJAKOOSTÖÖÜLIKOOL SISSEJUHATUS

ELEKTROONILISTE DOKUMENTIDE VOOSÜSTEEMI JAOTUSKEEM JA TOOTMISTSÜKLIlehed 9 2016 SISUKORD 1. MÕISTED, LÜHENDID JA MÕISTED... 3 2. SISSEJUHATUS... 4 2.1. Dokumendi eesmärk... 4 2.2.

AYUSoolyatte Kontorite mudelid projektide, programmide, projektiportfellide haldamiseks See materjal on väljavõte Andrey Soolyatte raamatust "Projektijuhtimine ettevõttes: metoodika, tehnoloogiad, praktika"

IS projekteerimise etappide dokumenteerimine 1 Etapp 1. PS projekti süsteemianalüüs 1.1. PS versiooni kontseptsiooni uurimine ja määratlemine Uuringu tulemused ja objekti kirjeldamine ning selle informatiseerimise eesmärgid

38 REA Bulletin 2007 6 KM Marchenkova FINANTSKONTROLLI ÜLESANDED JA FUNKTSIOONID Finantskontrolli mõiste kui tõhus vahend ettevõtte finantsjuhtimine. Asjakohasus

Tööajatabel (vene ajahaldus) Tööajaarvestuse moodul on mõeldud ettevõtte töötajate tööaja kasutamise planeerimiseks ja fikseerimiseks. Ajakaardi moodul on integreeritud Oracle HRMS rakendusse.

Töö teema: "SÜSTEEMI ANALÜÜSI INFOASPEKTID MAANTEETRANSPORT- ETTEVÕTTE JUHTIMISSÜSTEEMIDE LOOMISES" Abstraktne teema: "MAANTEETRANSPORT- ETTEVÕTTE JUHTIMISSÜSTEEM" Täiustatud üliõpilane (ka)

Arengu põhimõtted ja probleemid keerulised programmid süsteemid Diskreetse matemaatika ja infotehnoloogia osakond Sinelnikov Evgeniy Aleksandrovich [e-postiga kaitstud] 12. september 2011 TIOBE programmeerimine

ISO 9000 standardiseeria tulevik Ivan Tšaika, Rahvusvahelise Kvaliteediprofessionaalide Gildi president, Ph.D., Kvaliteediprobleemide Akadeemia akadeemik Tänapäeval kasutab ISO standardeid enam kui miljon ettevõtet

JUHTIMINE JA TURUNDUS Ettevõtluse sotsiaalne vastutus kui ühingujuhtimise tava element L.NUGUMANOVA Ettevõttejuhtimise olemus ja põhimõtted. Tänapäeval paljudes maailma riikides, sealhulgas

Juhend Arvutiseadmed Kaitse volitamata juurdepääsu eest teabele Turvanäitajad volitamata juurdepääsu eest teabele Kinnitatud esimehe otsusega

Valgevene Vabariigi Haridusministeerium Haridusasutus "Valgevene Riiklik Informaatika ja Raadioelektroonika Ülikool" V. V. Bakhtizin, L. A. Glukhova Tarkvaraarendustehnoloogia

Alperin M.I., Samsonova E.R., Reshetnikov R.S. Alperin M.I., Samsonova E.R., Reshetnikov R.S. TARKVARA VÄIKESES RÜHMADES KOOLITUSEKS [e-postiga kaitstud]

TARKVARA USALDUSVÄÄRSUS. VIGADE LIIGID JA KRIITILISUS. Drobotun E. B. Lennundus- ja kosmosekaitse sõjaväeakadeemia, Tver [e-postiga kaitstud] Töös käsitletakse tarkvara kvaliteeti ja töökindlust

Eelmise sajandi 60ndate lõpus ja 70ndate alguses leidis aset sündmus, mis läks ajalukku esimese programmeerimiskriisina. Sündmus seisnes selles, et tarkvara hind hakkas lähenema riistvara maksumusele ("raud") ja nende kulude kasvu dünaamika võimaldas ennustada, et 90ndate keskpaigaks on kogu inimkond arvutiprogrammide arendamine. Siis hakati rääkima tarkvaratehnikast (ehk programmeerimistehnoloogiast, nagu Venemaal nimetati) kui teatud distsipliinist, mille eesmärk on programmide maksumuse vähendamine.

Sellest ajast peale on tarkvaratehnika läbinud üsna kiire arengu. Tarkvaratehnika arenguetappe saab eristada erinevalt. Iga etapp on seotud järgmise probleemi esilekerkimisega (või teadvustamisega) ning selle probleemi lahendamise viiside ja vahendite leidmisega. Slaid tutvustab mitmeid tarkvaraarenduse fundamentaalseid probleeme ja leitud fundamentaalseid meetodeid nende lahendamiseks. Need meetodid on endiselt aluseks tarkvaratoodete kavandamisel.

Koodi taaskasutus (moodulprogrammeerimine)

Probleem. Tarkvaratehnika kujunemise algfaasis (isegi kui seda veel nii ei kutsutud) märgiti, et programmide kõrge hind on seotud samade (või sarnaste) koodifragmentide arendamisega erinevates programmides. Selle põhjuseks oli asjaolu, et erinevates programmides lahendati nende programmide osana samu (või sarnaseid) ülesandeid: mittelineaarsete võrrandite lahendamine, palkade arvutamine, ... Varem kirjutatud fragmentide kasutamine uute programmide loomisel tõotas märkimisväärset arendusaja ja kulude vähendamine.

Modulaarne programmeerimine. Modulaarse programmeerimise põhiprintsiip oli selliste fragmentide eraldamine ja mooduliteks korrastamine. Iga moodul oli varustatud kirjeldusega, mis kehtestas selle kasutamise reeglid - mooduli liides. Liides seab mooduli seosed põhiprogrammiga – andmelingid ja juhtlingid. Samas määras moodulite taaskasutamise võimaluse ära nende linkide arv ja keerukus ehk see, kuivõrd suudeti neid linke kooskõlastada põhiprogrammi andmete korralduse ja juhtimisega. Lihtsamad olid selles osas matemaatiliste ülesannete lahendamise moodulid: võrrandite lahendamine, võrrandisüsteemid, optimeerimisülesanded. Tänaseks on kogunenud ja edukalt kasutatud selliseid mooduleid suuri raamatukogusid.

Paljude muude moodulite tüüpide puhul on nende korduvkasutatavus osutunud problemaatiliseks nende linkide keerukuse tõttu põhiprogrammiga. Näiteks ühele ettevõttele kirjutatud palgamoodul ei pruugi teisele sobida, sest. palku nendes firmades ei arvutata kõiges ühtemoodi. Keeruliste liidestega moodulite taaskasutamine on tänapäeval üsna aktuaalne. Selle lahendamiseks töötatakse välja spetsiaalsed vormid (struktuurid) moodulite kujutamiseks ja nende liideste korrastamiseks.

Programmi kasvav keerukus (struktureeritud programmeerimine)

Probleem. Tarkvara kallinemise järgmine etapp oli seotud üleminekuga arenduselt suhteliselt lihtsad programmid keeruliste tarkvarasüsteemide arendamiseks. Selliste keerukate programmide hulka kuuluvad: kosmoseobjektide juhtimissüsteemid, kaitsekompleksi juhtimine, suure finantsasutuse automatiseerimine jne. Selliste komplekside keerukust hinnati järgmiste näitajate abil:

Suur hulk koodi (miljoneid ridu)

Suur hulk linke koodielementide vahel

Suur hulk arendajaid (sadu inimesi)

Suur hulk kasutajaid (sadu ja tuhandeid)

Pikaajaline kasutus

Selliste keeruliste programmide puhul selgus, et suurem osa nende maksumusest ei tulene mitte programmide loomisest, vaid nende rakendamisest ja toimimisest. Analoogiliselt tööstustehnoloogiaga hakati rääkima tarkvaratoote elutsüklist kui teatud etappide jadast: projekteerimine, arendus, testimine, juurutamine ja hooldus.

Struktureeritud programmeerimine. Tarkvarakompleksi hooldusetapp hõlmas tegevusi programmi vigade parandamiseks ja muudatuste tegemiseks vastavalt kasutajate muutunud nõuetele. Hooldusfaasi kõrge hinna (ja mõnikord ka võimatuse) peamiseks põhjuseks oli programmide kehv kujundus – dokumentatsioon ei olnud selge ega ühtinud programmi koodiga ning programmikood ise oli väga keeruline ja segane. Vajame tehnoloogiat, mis tagab "õige" disaini ja kodeerimise. Konstruktsioonide projekteerimise ja kodeerimistehnoloogia põhiprintsiibid:

Ülevalt alla funktsionaalne disain, mille käigus tuvastatakse süsteemis peamised funktsionaalsed alamsüsteemid, mis seejärel jaotatakse alamsüsteemideks jne. (jaga ja valitse põhimõte)

Spetsiaalsete disainikeelte ja automatiseerimistööriistade kasutamine nende keelte kasutamiseks

Disaini- ja arendusdistsipliin: projekti planeerimine ja dokumenteerimine, koodi vastavuse säilitamine projekti dokumentatsioonile

Struktuurne kodeerimine ilma gotota

Avaleht > Dokument

Sissejuhatus tarkvaratehnikasse

Tarkvaratehnika: eesmärk, aluspõhimõtted ja kontseptsioonid

1.1 Taust ja ajalugu

Koodi taaskasutus (moodulprogrammeerimine)

Modulaarne programmeerimine. Modulaarse programmeerimise põhiprintsiip oli selliste fragmentide eraldamine ja mooduliteks korrastamine. Iga moodul oli varustatud kirjeldusega, mis kehtestas selle kasutamise reeglid - mooduli liides. Liides seab mooduli seosed põhiprogrammiga – andmelingid ja juhtlingid. Samas määras moodulite taaskasutamise võimaluse ära nende linkide arv ja keerukus ehk see, kuivõrd suudeti neid linke kooskõlastada põhiprogrammi andmete korralduse ja juhtimisega. Lahendusmoodulid osutusid selles osas kõige lihtsamateks. matemaatika ülesandeid: võrrandite lahendamine, võrrandisüsteemid, optimeerimisülesanded. Tänaseks on kogunenud ja edukalt kasutatud selliseid mooduleid suuri raamatukogusid.

Programmi kasvav keerukus (struktureeritud programmeerimine)

Probleem. Tarkvara kallinemise järgmine etapp oli seotud üleminekuga suhteliselt lihtsate programmide arendamiselt keerukate tarkvarasüsteemide arendamisele. Selliste keerukate programmide hulka kuuluvad: kosmoseobjektide juhtimissüsteemid, kaitsekompleksi juhtimine, suure finantsasutuse automatiseerimine jne. Selliste komplekside keerukust hinnati järgmiste näitajate abil:

Suur hulk koodi (miljoneid ridu)

Suur hulk linke koodielementide vahel

Suur hulk arendajaid (sadu inimesi)

Suur hulk kasutajaid (sadu ja tuhandeid)

Pikaajaline kasutus

Ülevalt alla funktsionaalne disain, mille käigus tuvastatakse süsteemis peamised funktsionaalsed alamsüsteemid, mis seejärel jaotatakse alamsüsteemideks jne. (jaga ja valitse põhimõte)

Spetsiaalsete disainikeelte ja automatiseerimistööriistade kasutamine nende keelte kasutamiseks

Disaini- ja arendusdistsipliin: projekti planeerimine ja dokumenteerimine, koodi vastavuse säilitamine projekti dokumentatsioonile

Struktuurne kodeerimine ilma gotota

Programmi muutmine (OOP)

Probleem. Järgmine probleem Programmide kallinemine tulenes sellest, et muudatused programmile esitatavates nõuetes hakkasid tekkima mitte ainult hoolduse, vaid ka projekteerimise etapis – probleem on kliendis, kes ei tea, mida ta tahab. Tarkvaratoote loomine on muutunud selle püsivaks ümberkujundamiseks. Tekkis küsimus, kuidas kujundada ja kirjutada programme, et programmis saaks muudatusi teha ilma eelnevalt kirjutatud koodi muutmata.

Objektorienteeritud programmeerimine. Selle probleemi lahenduseks oli lähenemise või meetodi kasutamine, mida hakati nimetama objektorienteeritud disainiks ja programmeerimiseks. Lähenemise olemus seisneb selles, et klassi mõiste võetakse kasutusele kui mooduli mõiste edasiarendus, millel on teatud omadused ja käitumine, mis iseloomustavad klassi ülesandeid. Iga klass saab genereerida objekte – selle klassi eksemplare. Samal ajal toimivad OOP põhiprintsiibid (paradigmad):

Kapseldamine on andmete (omaduste) ja meetodite (töötlusprotseduuride) kombinatsioon klassis.

Pärand – võime tuletada vanast klassist uus klass, mille omadused ja meetodid muutuvad osaliselt

Polümorfism - objekti omaduste ja meetodite määratlemine konteksti järgi

Järgmine näide illustreerib OOP põhimõtete võimalusi. Kolmest osakonnast koosnevas organisatsioonis on vaja töötasu arvutada. Programmis on iga osakond esindatud oma mooduliga - objektiga ja palgaarvestust - objektiga "Palk". Kui on vaja palgaarvestust arvutada, edastatakse Palga objekti eksemplar osakonna objektile. Objekt "Osakond" edastab vajalikud andmed objektile "Palk" ja seejärel objekti "Palk" meetodeid kasutades teostab vajalikud arvutused.

3. osakonnas on osaliselt muutunud töötasude arvestamise reeglid. Sellises olukorras tuletatakse objektorienteeritud lähenemisega klass Palk 1 klassist Palk, mis pärib muutumatud palgaarvestuse reeglid ja tühistab muudetud. Siin saavad palga arvutamisel objektid "osakond 1" ja "osakond 2" objektiks "palk" ning objekt "osakond 3" - objektiks "palk 1". Nende muudatustega:

Pärimispõhimõte töötab: kood "Palk", "osakond 1" ja "osakond 2" jäävad muutumatuks ning kood "Palk 1" muutub täpselt nii palju kui vaja.

Polümorfismi põhimõte töötab: ka kood "osakond 3" ei muutu - see arvab jätkuvalt, et see töötab objektiga "Palk"

Mõned tulemused

Tarkvaratehnika (ehk programmeerimistehnoloogia) kui teatud suund tekkis ja kujunes välja loodava tarkvara kallinemise survel. Selle teadmiste valdkonna peamine eesmärk on vähendada programmi arendamise kulusid ja aega.

Tarkvaratehnika on läbinud mitmeid arenguetappe, mille käigus sõnastati tarkvaratoodete arendamise aluspõhimõtted ja meetodid. Tarkvaratehnika põhiprintsiip on, et programmid luuakse mitme omavahel seotud etapi (nõuete analüüs, projekteerimine, arendus, juurutamine, hooldus) tulemusena, mis moodustavad tarkvaratoote elutsükli. Disaini ja arenduse põhimeetodid on modulaarne, struktuurne ja objektorienteeritud projekteerimine ja programmeerimine.

Programmeerimiskriisi jätkumine

Vaatamata sellele, et tarkvaratehnika on saavutanud mõningast edu, jätkub programmeerimise püsiv kriis. Selle põhjuseks on asjaolu, et 80-90ndate vahetust tähistatakse infotehnoloogia revolutsiooni algusena, mille põhjuseks on infovahendite kasutamise plahvatuslik kasv: personaalarvuti, kohalikud ja globaalsed arvutivõrgud, mobiilne ühendus, meili, Internet jne.

Edu hind – programmeerimiskriis võtab kroonilisi vorme:

USA kulutab aastas üle 200 miljardi dollari enam kui 170 000 IT-tarkvara arendusprojektile; 31,1% neist on lõpetamata suletud; 52,7% projektidest viiakse lõpule üle eelarve/aja prognooside ja piiratud funktsionaalsusega; tarkvara juurutamise ebapiisavast mõjust tulenevaid kahjusid mõõdetakse triljonites.

USA ettevõtete 30 000 tarkvaraarendusprojekti statistika näitab järgmist jaotust:

Kell kiirustades - kogu töö sai tehtud õigeaegselt ja eelarve piires

Probleemne – tähtaegadest möödas, eelarve ületamine ja/või ei teinud kõike nõutavat

Ebaõnnestunud – ei lõpetatud kulude ületamise, eelarve ja kvaliteedi tõttu.

Allikas: The Standish Group International Standish Group International, Inc. Äärmuslik kaos 2000-//sample_research/PDFpages/extreme_chaos.pdf

1.2 Tarkvaratehnoloogia – mis see on?

Alustame määratlustega

Siiani pole "tarkvaratehnoloogia" mõistel ühtset määratlust. Slaidil on mitu sellist määratlust, mille on andnud selle valdkonna suured eksperdid või mis on salvestatud juhtivate organisatsioonide dokumentidesse.

Mõiste ise – tarkvaratehnika (tarkvaratehnika) – kuulutati esmakordselt välja 1968. aasta oktoobris NATO teaduse ja tehnoloogia allkomitee konverentsil (Garmisch, Saksamaa). Osales 50 professionaalset tarkvaraarendajat 11 riigist. Käsitleti programmide kavandamise, arendamise, levitamise ja toetamise probleeme. Seal kasutati esimest korda mõistet “tarkvaratehnika” omamoodi distsipliinina, mis tuleb luua ja millest tuleks nende probleemide lahendamisel juhinduda.

Varsti pärast seda toimus Londonis 22 tarkvaraprojektijuhi kohtumine. Kohtumisel analüüsiti tarkvaraarenduse probleeme ja väljavaateid. Märgiti tarkvara kasvavat mõju inimeste elule. Esimest korda räägiti tõsiselt lähenevast tarkvarakriisist. Rakendatud tarkvaraarenduse põhimõtted ja meetodid nõudsid pidevat täiustamist. Just sellel koosolekul pakuti välja tarkvara elutsükli (SLC – Software Lifetime Cycle) kontseptsioon kui etappide-etappide jada, mis tuleb tarkvara loomise ja käitamise protsessis läbida. Selle kontseptsiooni ümber on olnud palju vaidlusi. Aastal 1970 W.U. Royce (W.W. Royce) tuvastas tüüpilises tsüklis mitu etappi ja tehti ettepanek, et etappide kontrollimine toob kaasa tarkvara kvaliteedi tõusu ja arenduskulude vähenemise.

Saame küsimustest aru

Et saada aimu, mis on tarkvaratehnika, proovime mõista järgmisi küsimusi:

Mis on tarkvara (tarkvara)? Mis on tarkvaratehnika? Mis vahe on tarkvaratehnikal ja arvutiteadusel? Mis vahe on tarkvaratehnikal ja süsteemitehnikal? Mis vahe on tarkvaratehnikal ja muul inseneritööl?

Mis on tarkvara (tarkvara)?

Tarkvara on arvutiprogrammide, protseduuride ning nendega seotud dokumentatsiooni ja andmete kogum (ISO/IEC 12207). Tarkvara vaatamine kui lihtsalt arvutis istuv programm on liiga kitsas. Fakt on see, et mitte ainult ei müüda (kaasastatakse) programmi, vaid ka dokumentatsiooni, millest saate lugeda, kuidas programmi installida ja kuidas seda kasutada, ning andmeid programmi installimiseks erinevatel tingimustel (konfiguratsioonifailid). Seetõttu nimetatakse tarkvara mõnikord tarkvaratooteks. Need. Tarkvaratoode (tarkvara) ei ole ainult programmid, vaid ka kogu nende jaoks vajalik dokumentatsioon ja konfiguratsiooniandmed õige toimimine programmid. Ja tarkvaraspetsialistid arendavad tarkvaratooteid, st. tarkvara, mida saab tarbijale müüa.

Sõltuvalt sellest, kelle jaoks tarkvaratooteid arendatakse (konkreetne klient või turg, on tarkvaratooteid kahte tüüpi:

karbis olevad tooted (üldtooted – üldtooted või kokkutõmbunud tarkvara – pakitud tarkvara) kohandatud tooted (eritellimus – valmistatud eritellimusel või kohandatud tooted – kohandatud toode). Oluline erinevus nende vahel on see, kes ülesande püstitab (määrab või täpsustab nõuded). Esimesel juhul teevad seda turuanalüüsi (turunduse) alusel arendajad ise – ja samas riskivad ise. Teisel juhul on tegemist tellijaga ja samas riskid sellega, et arendaja ei suuda tegelikult kõiki nõudeid õigeaegselt ja eraldatud eelarvega täita.

Mis on tarkvaratehnika?

Tarkvaratehnoloogia on inseneriteadus, mis tegeleb tarkvara tootmise kõigi aspektidega alates spetsifikatsiooni algfaasist kuni süsteemitoeni pärast väljalaskmist. Selles määratluses on kaks võtmefraasi:

Inseneridistsipliin

Kõik tarkvara tootmise aspektid

Inseneridistsipliin. Insenerid on need spetsialistid, kes teevad praktilist tööd ja saavutavad praktilisi tulemusi. Teadlane võib öelda: probleem on olemasolevate teooriate raamides lahendamatu ja seda ei saagi teaduslik tulemus väärt avaldamist ja väitekirja kaitsmist.

Probleemi lahendamiseks rakendavad insenerid antud probleemi lahendamiseks sobivaid teooriaid, meetodeid ja tööriistu, kuid rakendavad neid valikuliselt ning püüavad alati leida lahendusi ka juhtudel, kui antud probleemile vastavaid teooriaid või meetodeid veel ei eksisteeri. Sel juhul otsib insener probleemi lahendamiseks meetodit või vahendit, rakendab seda ja vastutab tulemuse eest – meetod või vahend pole ju veel testitud. Selliste insenerimeetodite või -meetodite kogum, mis teoreetiliselt võib-olla ei ole põhjendatud, kuid praktikas korduvalt kinnitatud, mängib suurt praktilist rolli. Tarkvaratehnikas nimetatakse neid parimateks tavadeks.

Insenerid töötavad piiratud ressursside tingimustes: ajaliselt, rahaliselt ja organisatsiooniliselt (seadmed, masinad, inimesed). Ehk siis toode peab valmima õigel ajal, eraldatud vahendite, seadmete ja inimeste piires. Kuigi see puudutab eelkõige eritellimustoodete (lepingutingimustes märgitud) loomist, kuid karbitoodete loomisel pole need piirangud vähem olulised, sest. siin dikteerivad need turukonkurentsi tingimused.

Kõik tarkvara tootmise aspektid. Tarkvaratehnika ei tegele ainult tarkvaratootmise tehniliste küsimustega (nõuete täpsustamine, disain, kodeerimine, ...), vaid ka tarkvaraprojektide juhtimisega, sh planeerimise, finantseerimise, meeskonnahalduse jms. Lisaks on tarkvaratehnika ülesandeks töötada välja tööriistu, meetodeid ja teooriaid tarkvara tootmisprotsessi toetamiseks.

Tarkvarainsenerid kasutavad saavutamise nimel süstemaatilisi ja organiseeritud lähenemisviise maksimaalne efektiivsus ja tarkvara kvaliteet. Nende ülesanne on kohandada olemasolevaid meetodeid ja lähenemisviise oma konkreetse probleemi lahendamiseks.

Mis vahe on informaatika vahel?

Arvutiteadus tegeleb andmetöötluse ja tarkvarasüsteemide teooria ja meetoditega, tarkvaratehnika aga tarkvara loomise praktiliste probleemidega. Arvutiteadus moodustab tarkvaratehnika teoreetilised alused ja tarkvarainsener peab tundma arvutiteadust. Nii nagu elektroonikainsener peab teadma füüsikat. Ideaalis peaksid tarkvaratehnoloogiat toetama mõned arvutiteaduse teooriad, kuid tegelikkuses see alati nii ei ole. Tarkvarainsenerid kasutavad sageli tehnikaid, mis on rakendatavad ainult teatud tingimustes ja mida ei saa üldistada muudel juhtudel, ja elegantseid arvutiteaduse teooriaid ei saa alati rakendada tõeliste suurte süsteemide puhul.

Lõpuks ei ole arvutiteadus tarkvaratehnika ainus teoreetiline alus, sest tarkvarainseneri probleemide hulk on palju laiem kui lihtsalt programmide kirjutamine. See on ka finantsjuhtimine, töö organiseerimine meeskonnas, suhtlemine kliendiga jne. Nende probleemide lahendamine nõuab fundamentaalseid teadmisi, mis ulatuvad arvutiteadusest kaugemale.

Kuidas see erineb muust inseneritööst?

Erinevus tarkvaratehnika ja muu inseneri vahel on huvitav eelkõige kahe küsimuse seisukohalt:

Miks on ebaõnnestunud projektide osakaal tarkvaratehnikas muu inseneritööga võrreldes nii kõrge?

Kas tarkvaratehnikas on võimalik rakendada muu inseneri kogemust?

Need küsimused on tarkvaratehnika jaoks põhilised. Selle kohta on palju arvamusi (ja sageli ka vastakaid). Peatugem mõnel enam-vähem ilmselgel erinevusel tarkvaratehnika ja muu inseneritöö vahel.

Esiteks märgime, et mis tahes inseneritoote elutsükkel lihtsustatud kujul hõlmab järgmisi etappe: projekteerimine, näidiste loomine, testimine, tootmine, käitamine.

Arvutiprogramm ei ole (erinevalt muu inseneriobjektidest) materiaalne objekt (palun ärge ajage seda segamini programmikandjaga - mis tahes tüüpi mäluseadmega). Sellest tulenevad järgmised erinevused. Tootmisetapp seisneb proovi kopeerimises teistele kandjatele. Kadumise etapi maksumus on väike. Kui kodeerimist pidada kujunduselemendiks (mis on tõele väga lähedal), siis puudub ka näidise loomise faas (ehitatud kompilaatori ja linkeri poolt)

Sellest järeldub järgmised järeldused:

Programmi maksumus on ainult selle disaini maksumus.

Koopiatele "määritakse" karbitoodete kujundamise maksumus

Kohandatud toodete (mitte massiliselt kopeeritud) hind on endiselt kõrge

Mis veel erineb muust inseneritööst?

Teine oluline erinevus on see, et programm on tehisobjekt. Need. programmi jaoks pole objektiivseid seadusi, millele selle käitumine alluks. Näiteks ehitusinseneril on objektiivsed ehitusmehaanika seadused: momentide ja jõudude tasakaal, mehaaniliste süsteemide stabiilsus jne. Ehitusinsener saab testida oma arhitektuurseid projekte nende seadustega vastavuses ja seeläbi tagada projekti edu. Need seadused on objektiivsed, need toimivad alati. Tarkvarainseneril on esmapilgul olemas ka tüüpilised ajaproovitud arhitektuursed lahendused (näiteks klient-server arhitektuur). Kuid need otsused määrab arvutitehnoloogia arengutase (ja neile vastavate nõuete tase). Põhimõtteliselt uute võimalustega tehnoloogia tulekuga peab tarkvarainsener otsima uusi lahendusi.

Projekti "teoreetilise" kontrolli võimaluse puudumise otsene tagajärg on toote testimine ainus viis veenduge selle kvaliteedis. Seetõttu on testimise hind märkimisväärne tarkvara hind. Muide, ehitusinsener on reeglina ilma jäetud võimalusest oma toodet enne kasutuselevõttu selliseks “testimiseks”.

Lõpuks on tarkvaratehnika noor eriala, millel on vaid mõnekümne aasta pikkune kogemus. Võrreldes hoonetehnika kogemusega (aastatuhanded) on seda muidugi väga vähe. Tarkvaratehnikat võrreldakse mõnikord varajase ehitustehnikaga, mil ehitusmehaanika seaduspärasusi veel ei tuntud ja ehitusinsenerid tegutsesid katse-eksituse meetodil, omandades hindamatuid kogemusi. Vaatamata oma noorele eale on tarkvaratehnikal kogunenud ka teatud kogemus, mis võimaldab (mõistliku rakendusega) teha edukaid projekte. See kogemus väljendub tarkvaratehnika aluspõhimõtetes, mida me nüüd kaalume.

Lisateavet tarkvaradisaini väljakutsete kohta leiate Coney Buereri vastuolulisest artiklist "Käsitööst teaduseni: tarkvaraarenduse põhialuste leidmine" /fset.asp?Url=/rational/science.htm

Mis on tarkvara hind?

Tarkvara kulustruktuur sõltub suuresti tarkvara tüübist, selle arendamiseks kasutatavatest meetoditest ja … hindamismeetodist. Seega märgivad paljud autorid suurt osa hooldusetapi kuludest. Teatud tüüpi tarkvara puhul võib see moodustada 60 protsenti või rohkem kogumaksumusest. Vahepeal hõlmab hooldusfaas kahte tüüpi tööde teostamist: programmis esinevate vigade parandamine (ebaühtlused algsete nõuetega) ja programmis muudatuste tegemine (uute nõuete lisamine). Hindamise teistsuguse lähenemise korral võib arvata, et hooldusetappi ei tohiks eraldi hinnata, kuna Vigade parandamise põhjuseks võib olla testimise jätkamine ja uues projektis muudatuste tegemine.

Tüüpiline kulude jaotus põhietappide vahel (ilma toetuseta) on järgmine:

15% - täpsustus - nõuete ja arendustingimuste sõnastamine

25% - projekteerimine - projekti väljatöötamine ja kontrollimine

20% - arendus - komponentide kodeerimine ja testimine

40% - integreerimine ja testimine - toote integreerimise ja kooste testimine

Kõrvalekalded sellest skeemist olenevalt tarkvara tüübist on järgmised:

Kastitarkvara iseloomustab suurem testimise osakaal, mis tuleneb eelkõige spetsifikatsiooni osakaalu vähenemisest (kuni 5%).

Kohandatud tarkvara maksumuse jaotus sõltub selle keerukusest. Keerulise tarkvara puhul suureneb ka integreerimise ja testimise osakaal, kuid projekteerimise ja arenduse osakaalu vähendades võib spetsifikatsioonide osakaal suureneda. Disaini ja arenduse osakaalu vähendamine saavutatakse läbi tõestatud disainilahenduste rakendamise ja taaskasutuse kokkupandavad komponendid.

Läbiproovitud lahenduste ja valmiskomponentide kasutamine karbitoodete loomisel võimaldab parandada kvaliteeti ja vähendada arendusaega.

Veel küsimusi

Et saada aimu, millest tarkvaratehnika kogutud kogemus koosneb, proovime mõista järgmisi küsimusi:

Mis on tarkvaraprotsess?

Mis on tarkvaraprotsessi mudel?

Mis on tarkvaratehnoloogia meetodid?

Mis on CASE (Computer-Aided Software Engineering)?

Millised on hea programmi omadused?

Millised on tarkvaratehnika peamised väljakutsed?

tarkvara protsess?

Tarkvaratehnika üks põhimõisteid on tarkvaratoote ja tarkvaraprotsessi elutsükli kontseptsioon.

Elutsükkel on pidev protsess, mis algab tarkvara loomise otsusega ja lõpeb selle kasutusest kõrvaldamisega. Elutsükkel on jaotatud üksikud protsessid.

Protsess - tegevuste ja ülesannete kogum, mille eesmärk on saavutada märkimisväärne tulemus. Elutsükli peamised protsessid (mida mõnikord nimetatakse etappideks või faasideks) on järgmised:

Nõuete spetsifikatsiooni väljatöötamine (tulemus - täitmiseks kohustuslike programmi nõuete kirjeldused - kirjeldus, mida programm tegema peaks)

Programmi kavandi väljatöötamine (tulemuseks on programmi toimimise kirjeldus)

Kodeerimine (tulemus - allikas ja konfiguratsioonifailid)

Programmi testimine (tulemus – programmi nõuetele vastavuse kontroll)

Dokumentatsioon (tulemus – programmi dokumentatsioon)

Lisaks peamistele on palju lisa- ja abiprotsesse, mis ei ole seotud toote loomisega, vaid töö korraldamisega (mittefunktsionaalsed protsessid): infrastruktuuri loomine, konfiguratsioonihaldus, kvaliteedijuhtimine, koolitus, konfliktide lahendamine, ...

Protsess tuleb installida. Protsessi täielik loomine hõlmab:

Protsessi kirjeldus - Protsessi tegevuste ja tegevuste üksikasjalik kirjeldus Protsessi koolitus - Koolituste läbiviimine töötajatega protsessi valdamiseks Mõõdikute tutvustamine - Protsessi kvantitatiivsete mõõtmiste kehtestamine Edusammude jälgimine - Mõõdikute mõõtmine ja edusammude hindamine Täiustamine - Protsessi muutmine muutuvates rakendustingimustes

Terviklike (raskete) protsesside kasutamine nõuab lisaressursse (sageli märkimisväärseid) ja seda ei tasu alati tulemus ära. Seetõttu saab protsesside koosseisu, nende kehtestamise astme (seadistamise täielikkuse) valiku igal konkreetsel juhul teha erinevalt vastavalt valitud protsessimudelile.

Suurus: 821 Kb
Slaidide arv: 61

Ettekande kirjeldus Sissejuhatus tarkvaratehnikasse TARKVARAINENERIMISE MÕISTE slaidide kaupa

TARKVARAINSENERIMISE MÕISTE Mille poolest programmeerimine erineb inseneriprogrammist? Programmeerimine on abstraktne tegevus ja võib toimuda paljudes erinevates kontekstides. Tööstuslik programmeerimine toimub reeglina meeskonnas ja kindlasti kliendile, kes maksab töö eest raha. Tuleb täpselt aru saada, mida klient vajab, töö tuleb valmis teha kindla aja jooksul ning tulemus peab olema nõutava kvaliteediga – selline, mis klienti rahuldab ja mille eest ta maksab. Nende lisanõuete rahuldamiseks “kasvatatakse” programmeerimine erinevate lisategevustega: nõuete väljatöötamine, planeerimine, testimine, konfiguratsioonihaldus, projektihaldus ning mitmesuguse dokumentatsiooni (projekt, kasutaja jne) loomine.

Programmikoodi väljatöötamisele eelneb analüüs ja projekteerimine (esimene tähendab tulevase süsteemi funktsionaalse mudeli loomist ilma juurutamist arvestamata, et programmeerijad saaksid aru tellija nõuetest ja ootustest; teine tähendab esialgset paigutus, eskiis, süsteemiplaan paberil). Arendusprotsessi korraldamiseks on vaja teha erilisi jõupingutusi. Süsteemi väljatöötamisel tuleb arvestada selle edasise hoolduse, taaskasutamise ja teiste süsteemidega integreerimise mugavust. See tähendab, et süsteem on jaotatud komponentideks, mida on lihtne arendada, mis sobivad taaskasutamiseks ja integreerimiseks.Liidesed on nende komponentide jaoks hoolikalt kavandatud. Süsteem ise on dokumenteeritud mitmel tasandil, luuakse programmikoodi kujundamise reeglid - see tähendab, et jäetakse arvukalt semantilisi jälgi, mis aitavad luua ja säilitada, säilitada ühtset, harmoonilist arhitektuuri, ühtset stiili, korda ... Kõik need ja muud täiendavad tegevused, mida tehakse tööstusliku programmeerimise käigus ja mis on vajalikud tellimuste edukaks täitmiseks ning mida nimetatakse tarkvaratehnikaks (tarkvaratehnika)

Eeldused tarkvaratehnika tekkeks Tarkvaratehnika (ehk tööstusliku programmeerimise tehnoloogia) kui teatud suund tekkis ja kujunes välja loodava tarkvara kallinemise survel. Selle teadmiste valdkonna peamine eesmärk on vähendada programmi arendamise kulusid ja aega. Tarkvaratehnika on läbinud mitmeid arenguetappe, mille käigus sõnastati tarkvaratoodete arendamise aluspõhimõtted ja meetodid. Tarkvaratehnika põhiprintsiip on, et programmid luuakse mitme omavahel seotud etapi (nõuete analüüs, projekteerimine, arendus, juurutamine, hooldus) tulemusena, mis moodustavad tarkvaratoote elutsükli. Disaini ja arenduse põhimeetodid on modulaarne, struktuurne ja objektorienteeritud projekteerimine ja programmeerimine.

Koodi taaskasutamise (moodulprogrammeerimine) probleem. Tarkvaratehnika arendamise algfaasis märgiti, et programmide kõrge hind on seotud samade (või sarnaste) koodifragmentide arendamisega erinevates programmides. Selle põhjuseks oli asjaolu, et erinevates programmides lahendati nende programmide osana samu (või sarnaseid) ülesandeid: mittelineaarsete võrrandite lahendamine, palkade arvutamine, ... Varem kirjutatud fragmentide kasutamine uute programmide loomisel tõotas märkimisväärset arendusaja ja kulude vähendamine. Programmide kasvav keerukus (struktureeritud programmeerimine) Probleem. Tarkvara kallinemise järgmine etapp oli seotud üleminekuga suhteliselt lihtsate programmide arendamiselt keerukate tarkvarasüsteemide arendamisele. Tuleb märkida, et selle ülemineku põhjustas kolmanda põlvkonna arvutustehnoloogia (integraallülituste) tulek. Integraallülituste kasutamisele üleminekuga on arvutite jõudlus kasvanud suurusjärkude võrra, mis lõi eeldused keeruliste probleemide lahendamiseks. Selliste keerukate ülesannete hulka kuuluvad: kosmoseobjektide juhtimissüsteemid, kaitsekompleksi juhtimine, suure finantsasutuse automatiseerimine jne.

Selliste komplekside keerukust hinnati järgmiste näitajate järgi: – suur hulk koodi (miljoneid ridu) – suur hulk linke koodielementide vahel – suur arv arendajaid (sadu inimesi) – suur hulk kasutajaid (sadu ja tuhandeid) – Pikk kasutusaeg Nii keeruliste programmide puhul selgus, et suurem osa nende maksumusest ei tulene programmide loomisest, vaid nende rakendamisest ja toimimisest. Analoogiliselt tööstustehnoloogiaga hakati rääkima tarkvaratoote elutsüklist kui teatud etappide jadast: projekteerimine, arendus, testimine, juurutamine ja hooldus. Programmide muutmine (OOP) Probleem. Järgmise programmide kallinemise probleemi põhjustas asjaolu, et muudatused programmile esitatavates nõuetes hakkasid tekkima mitte ainult hoolduse, vaid ka projekteerimisetapis - kliendi probleem, kes ei tea. mida ta tahab. Tarkvaratoote loomisest on saanud selle püsiv ümberkujundamine. Tekkis küsimus, kuidas kujundada ja kirjutada programme, et oleks võimalik programmis muudatusi teha ilma eelnevalt kirjutatud koodi muutmata.

Programmeerimiskriis jätkub Kuigi tarkvaratehnika on teinud mõningaid edusamme, jätkub püsiv programmeerimiskriis. Selle põhjuseks on asjaolu, et 1980. ja 1990. aastate vahetust tähistatakse infotehnoloogia revolutsiooni algusena, mille põhjuseks on infovahendite kasutamise plahvatuslik kasv: personaalarvuti, lokaalsed ja globaalsed arvutivõrgud, mobiilside, e-post, Internet jne Hinnaedu – programmeerimiskriis võtab kroonilisi vorme. Standish Group, analüüsinud sadade Ameerika korporatsioonide tööd ja mitmekümne tuhande tarkvaraarendusega seotud projektide tulemusi, jõudis oma kõneka pealkirjaga "Kaos" aruandes järgmistele järeldustele: - Ainult 35% projektidest oli õigeaegselt valmis, ei ületanud planeeritud eelarvet ning rakendas kõik nõutavad funktsioonid ja funktsioonid. – 46% projektidest viidi lõpule hilinemisega, kulud ületasid planeeritud eelarvet, vajalikke funktsioone ei täidetud täies mahus. Keskmine kulu ületas 120%, keskmine kulu ületas 100% ja märkimisväärne hulk funktsioone jäeti tavaliselt välja.

19% projektidest ebaõnnestus täielikult ja tühistati enne lõpetamist. 2006. aasta tarkvaraprojektide edukuse analüüsi tulemused

Põhimõisted Programmeerimine on teatud eesmärkide kogumi kaardistamine masinakäskude ja andmete kogumile, mille tõlgendamine arvutis või arvutisüsteemis tagab seatud eesmärkide saavutamise. See kaardistamine võib olla väga lihtne või mitmeastmeline ja väga keeruline, kui esmalt kaardistatakse eesmärgid süsteeminõuetele, nõuded kõrgetasemelisele arhitektuurile ja komponentide spetsifikatsioonidele, spetsifikatsioonid komponentide disainile, disain lähtekoodile. Professionaalne programmeerimine (tarkvara tootmise sünonüüm) on tegevus, mille eesmärk on programmeerimise kaudu tulu teenimine. Professionaalne programmeerija on inimene, kes tegeleb professionaalse programmeerimisega.

Tarkvaratoode - programmide komplekt ja kaasasolevad dokumendid nende installimiseks, konfigureerimiseks, kasutamiseks ja täiustamiseks. Vastavalt standardile hõlmab programmi, tarkvarasüsteemi, tarkvaratoote elutsükkel arendust, juurutamist, tuge ja hooldust. Tarkvaratoote elutsükkel

Tarkvara arendusprotsess on protsesside kogum, mis tagab tarkvara loomise ja arendamise. Tarkvaraarendusprotsessi mudel on tarkvara arendusprotsessi formaliseeritud esitus. Sageli kasutatakse protsesside kirjeldamisel sõna mudel asemel mõistet metodoloogia. Siiani pole "tarkvaratehnoloogia" mõistel ühtset määratlust. Siin on mõned nendest definitsioonidest, mille on andnud selle valdkonna peamised eksperdid või dokumenteerinud juhtivad organisatsioonid: - usaldusväärsete inseneripõhimõtete (meetodite) loomine ja kasutamine, et hankida säästlikult tarkvara, mis on usaldusväärne ja töötab reaalsetel masinatel. ; Inseneriteaduse vorm, mis rakendab arvutiteaduse ja matemaatika põhimõtteid, et kulutõhusalt lahendada tarkvaraprobleeme. – süstemaatilise, distsiplineeritud, mõõdetava lähenemise rakendamine tarkvara arendamisel, kasutamisel ja hooldamisel. - distsipliin, mille eesmärk on luua kvaliteetne tarkvara, mis valmib õigeaegselt, ei ületa eelarves ettenähtud vahendeid ja vastab seatud nõuetele.

Tarkvaratehnika arengu ajaskaala 1958 – maailmakuulus statistik John Tukey (John Tukey) võttis esmakordselt kasutusele termini tarkvara – tarkvara. 1968 – Mõiste tarkvaratehnika (tarkvaratehnoloogia) ilmus esmakordselt Saksamaal nn tarkvarakriisile pühendatud NATO konverentsi pealkirjas. 1970 – W. W. Royce tuvastas tüüpilises tsüklis mitu etappi ja tehti ettepanek, et etappide täitmise kontrollimine tooks kaasa tarkvara kvaliteedi paranemise ja arenduskulude vähenemise. Pakuti välja elutsükli kontseptsioon (SLC – Software Lifetime Cycle). 1990 - 1995 - töötati välja rahvusvahelise standardi kallal, mis pidi andma ühtse ettekujutuse tarkvara arendusprotsessidest. Selle tulemusena anti välja ISO/IEC 12207 „Tarkvara elutsükli protsesside” standard. – Vastav Venemaa riiklik standard – GOST R ISO/IEC 12207-99 [GOST 12207, 1999] sisaldab rahvusvahelise standardi ISO/IEC 12207 teksti täielikku autentset tõlget —

1. Tarkvaratehnoloogia teadmuskogu (SWEe. K) juhend, IEEE 2004 versioon K; SWEe üks olulisemaid eesmärke. K on just nende tegevuse aspektide määratlus, mis moodustavad tarkvarainseneri elukutse olemuse. 2. Tarkvaratehnika 2004. - Tarkvaratehnika õpetamise õppekava ülikoolides [SE, 2004]. 2004 – ACM/IEEE-CS sõnastas kaks peamist kirjeldust selle kohta, mida tänapäeval nimetame tarkvaratehnika alusteks – Tarkvaratehnika:

SWEBOKi struktuur ja sisu SWEBOK 2004 järgi sisaldab tarkvaratehnika 10 peamist ja 7 täiendavat teadmusvaldkonda, millel põhinevad tarkvara arendusprotsessid. Peamised teadmiste valdkonnad hõlmavad järgmisi valdkondi: Tarkvaranõuded – tarkvaranõuded. Tarkvara projekteerimine - disain (arhitektuur). Tarkvaraehitus – tarkvara koostamine. Tarkvara testimine – testimine. Tarkvara hooldus - tarkvara käitamine (tugi). Tarkvara konfiguratsioonihaldus – konfiguratsioonihaldus. Tarkvaratehnika juhtimine - tarkvaratehnika juhtimine. Tarkvaraehitusprotsess – tarkvaratehnoloogia protsessid. Tarkvaratehnoloogia tööriistad ja meetodid - tööriistad ja meetodid. Tarkvara kvaliteet – tarkvara kvaliteet. SWE teadmiste valdkondade kirjeldus. K on üles ehitatud hierarhilisel alusel, struktuurse lagunemise tulemusena.

Seotud erialad Täiendavad valdkonnad hõlmavad järgmist: Arvutitehnika – arvutite projekteerimine. Arvutiteadus – informaatika. Juhtimine – üldjuhtimine. Matemaatika – matemaatika. Projektijuhtimine – projektijuhtimine. Kvaliteedijuhtimine – kvaliteedijuhtimine. Süsteemitehnika – süsteemide projekteerimine.

Tarkvaratehnoloogia kasutab arvutiteaduse saavutusi, on tihedalt seotud süsteemitehnoloogiaga ja sellele eelneb sageli äritegevuse ümberkorraldus. Arvutiteadus on matemaatikal põhinevate teoreetiliste teaduste kogum, mis on pühendatud arvutatavuse formaalsetele alustele. See hõlmab matemaatilist loogikat, grammatikateooriat, kompilaatorite ehitusmeetodeid, matemaatilisi formaalseid meetodeid, mida kasutatakse verifitseerimisel ja mudelite testimisel, jne. Tarkvaratehnikat on keeruline arvutiteadusest rangelt eraldada, kuid üldiselt on nende erialade fookus erinev. Tarkvaratehnika on suunatud tootmisprobleemide lahendamisele, arvutiteadus aga formaalsete, matemaatiliste lähenemiste väljatöötamisele programmeerimisel.

Süsteemitehnika (süsteemitehnika) ühendab erinevaid inseneriteadusi kõikvõimalike tehissüsteemide arendamiseks – elektrijaamad, telekommunikatsioonisüsteemid, manustatud reaalajas süsteemid jne. Väga sageli on selliste süsteemide osaks tarkvara, mis täidab süsteemide kontrollimise ülesannet. vastavad seadmed. Selliseid süsteeme nimetatakse riistvaraks-tarkvaraks ning nende loomisel osaledes on programmeerijad sunnitud vastava varustuse omadusi süvitsi mõistma. Business reengineering (business reengineering) - laiemas tähenduses tähendab ettevõtte moderniseerimist konkreetses ettevõttes, uute tavade juurutamist, mida toetavad asjakohased, uued infosüsteemid. Samas võib rõhk olla nii ettevõtte sisemisel ümberkorraldamisel kui ka uue klienditeeninduse arendamisel (reeglina on need teemad omavahel seotud). Tihti eelneb ettevõttes infosüsteemide väljatöötamisele ja juurutamisele ettevõtte ümberkorraldamine, kuna esmalt tuleb bürootöös paika panna kindel kord ja alles siis see infosüsteemiga paika panna.

TARKVARATOOTE ELUtsükkel Iga inseneritöö metodoloogiline alus on toote (toote) elutsükli (LC) kontseptsioon kui kõigi toimingute kogum, mida tuleb teha kogu toote "eluea" jooksul. Elutsükli tähendus on kõigi nende toimingute omavaheline seotus. Tööstustoote elutsükkel on defineeritud kui etappide (faaside, etappide) jada, mis koosneb tehnoloogilistest protsessidest, tegevustest ja operatsioonidest. Tarkvara elutsükli ja tarkvara elutsükli mudeli mõistete eraldamine. – Tarkvara elutsükkel – tarkvara loomise ja kasutamise protsesside ja toimingute täielik komplekt; - olelusringi mudel - elutsükli korralduse konkreetne variant, mis on igaks konkreetseks juhtumiks mõistlikult (mõistlikult) valitud.

Üldiselt määratletakse elutsükkel mudeliga ja kirjeldatakse metoodika (meetodi) kujul. Elutsükli mudel ehk paradigma määratleb elutsükli korralduse kontseptuaalse vaate ja sageli ka elutsükli peamised faasid ja nendevahelise ülemineku põhimõtted. Metoodika (meetod) määratleb tööde komplekti, nende üksikasjaliku sisu ja spetsialistide rollid valitud elutsükli mudeli kõikides etappides, defineerib tavaliselt mudeli enda ning soovitab ka praktikaid (parimaid praktikaid), mis võimaldavad kõige tõhusamalt kasutada elutsükli mudelit. sobiv metoodika ja selle mudel.

Klassikaline elutsükkel Klassikaline tarkvaraarenduse elutsükkel on tarkvara arendusprotsessi vanim paradigma (autor Winston Royce, 1970) Klassikalist elutsüklit nimetatakse kosemudeliks; Arendust käsitletakse etappide jadana ja üleminek järgmisele, hierarhiliselt madalamale etapile toimub alles pärast töö lõpetamist praeguses etapis.

Peamiste etappide sisu. Süsteemianalüüs – määrab iga elemendi rolli arvutisüsteemis, elementide omavahelist interaktsiooni. Selles etapis algab tarkvaraprojekti planeerimise probleemi lahendamine. Määrati: - projekteerimistööde maht; - risk; - vajalikud tööjõukulud; - kujundatakse tööülesanded; - töögraafik. Nõuete analüüs – see viitab tarkvaraelemendile – tarkvarale. Selgitatud ja üksikasjalik – funktsioonid; - Omadused; – liides. Kõik määratlused on dokumenteeritud analüüsi spetsifikatsioonis. See lõpetab projekti planeerimise probleemi lahendamise.

Projekteerimine seisneb esinduste loomises: – tarkvara arhitektuurist; – modulaarne tarkvara struktuur; – tarkvara algoritmiline struktuur; – andmestruktuurid; – sisend- ja väljundliides (sisend- ja väljundandmete vormid). Disaini sisend sisaldub analüüsi spetsifikatsioonis. Disainiprobleemide lahendamisel pööratakse põhitähelepanu tulevase tarkvaratoote kvaliteedile. Kodeerimine seisneb disainitulemuste tõlkimises tekstiks programmeerimiskeeles. Testimine on programmi käivitamine tarkvaratoote funktsioonide, loogika ja teostusvormi defektide tuvastamiseks. Hooldus on muudatuste sisseviimine operatsioonitarkvarasse. Muudatuste eesmärgid: – vigade parandamine; – kohanemine tarkvaravälise keskkonna muutustega; - Tarkvara täiustamine vastavalt kliendi nõudmistele.

Tarkvara hooldus koosneb taaskasuta elutsükli iga eelnev etapp (etapp) olemasoleva programmi juurde, kuid mitte uue programmi väljatöötamisel. Klassikalise elutsükli eelised: - annab plaani ja ajakava projekti kõikideks etappideks; – ühtlustab projekteerimise kulgu Klassikalise elutsükli puudused: – tegelikud projektid nõuavad sageli kõrvalekaldeid standardsest sammude jadast; – tsükkel põhineb täpsel koostisel esialgsed nõuded tarkvarale (tegelikult on projekti alguses kliendi nõudmised vaid osaliselt määratletud); - projekti tulemused on tellijale kättesaadavad alles töö lõppedes.

Prototüüpimisprobleemid Klient – ei saa sõnastada üksikasjalikke nõudeid andmete sisestamiseks, töötlemiseks või väljastamiseks tulevase tarkvaratoote jaoks. Arendajal võib tekkida kahtlusi: – toote kohandatavuses operatsioonisüsteemiga; – dialoogi vorm kasutajaga; – rakendatud algoritmi efektiivsuses. Sellistel juhtudel on soovitatav kasutada prototüüpimist. Prototüüpimise peamine eesmärk on kõrvaldada ebakindlus kliendi nõuetes. Modelleerimine (prototüüpimine) on vajaliku tarkvaratoote mudeli loomise protsess. Mudelil võib olla üks kolmest vormist: 1) paberi- või arvutipõhine paigutus (kujutab või joonistab inimese ja masina dialoogi); 2) tööplaan (täidab mõnda nõutavat funktsiooni); 3) olemasolev programm (mille omadusi tuleb siis parandada).

Loodud tarkvarale nõuete kogumine ja täpsustamine. Arendaja ja klient vastavad ja määratlevad kõik tarkvara eesmärgid, määravad kindlaks, millised nõuded on teada ja millised on vaja uuesti määratleda. Kiire disain. Tähelepanu on suunatud tarkvara nendele omadustele, mis peaksid olema kasutajale nähtavad. Kiire projekteerimine viib paigutuse ehitamiseni. Prototüüpimine. Paigutust hindab klient – seda kasutatakse tarkvarale esitatavate nõuete selgitamiseks. Paigutuse täpsustamine. Iteratsioone korratakse seni, kuni paigutus paljastab kõik kliendi nõudmised ja seega ei võimalda arendajal aru saada, mida tuleks teha. Maketi eelis: annab definitsiooni täielikud nõuded tarkvara juurde. Maketi puudused: klient võib maketti tootega ekslikult pidada; arendaja võib küljenduse tootega ekslikult pidada.

Töötava paigutuse kiireks saamiseks teeb arendaja sageli teatud kompromisse: - mitte kõige rohkem sobivad keeled programmeerimine või operatsioonisüsteem; – võimete lihtsalt demonstreerimiseks võib kasutada ebaefektiivset algoritmi.

Tarkvara kujundamise strateegiad Tarkvara kujundamise strateegiaid on 3: ühekäiguline (jugastrateegia) – projekteerimisetappide lineaarne jada; astmeline strateegia. Protsessi alguses määratakse kindlaks kõik kasutaja- ja süsteeminõuded, ülejäänud ehitus viiakse läbi versioonide seeriana. Esimene versioon rakendab mõningaid kavandatud funktsioone, järgmine versioon rakendab lisafunktsioone ja nii edasi kuni kogu süsteemi saamiseni; evolutsiooniline strateegia. Süsteem on ehitatud ka versioonide seeriana, kuid kõiki nõudeid pole protsessi alguses määratletud. Nõuded täpsustatakse versioonide väljatöötamise tulemusena.

Tarkvara projekteerimisstrateegiate karakteristikud vastavalt standardi IEEE / EIA 12207 nõuetele 2 Disainistrateegia Kas kõik nõuded on protsessi alguses määratletud? Palju disainitsükleid? Kas vahevara levitatakse edasi? Ühekordne läbipääs Täiendav (kavandatud tootetäiustus) Evolutsiooniline Jah Jah Ei Võib-olla Jah

Inkrementaalne mudel Inkrementaalne mudel on klassikaline näide inkrementaalsest disainistrateegiast, mis ühendab järjestikuse kosemudeli elemendid iteratiivse paigutuse filosoofiaga.

Iga siinne rida loob kaasasoleva tarkvaralise juurdekasvu. Näide. 1. sammuga tekstitöötlustarkvara rakendab põhilisi failitöötlus-, redigeerimis- ja dokumenteerimisfunktsioone; 2. juurdekasvus - rohkem keerulisi võimalusi toimetamine ja dokumenteerimine; 3. astmes - õigekirja ja grammatika kontroll; 4. sammuga - lehe paigutuse võimalused. Esimese juurdekasvu tulemuseks on baastoode, mis rakendab põhinõudeid (paljud abinõuded jäävad siiski realiseerimata). Järgmise juurdekasvu plaan hõlmab põhitoote muutmist, et pakkuda täiendavaid funktsioone ja funktsioone. Oma olemuselt on inkrementaalne protsess iteratiivne, kuid erinevalt leivalaua kasutamisest pakub inkrementaalne mudel igal sammul töötava toote. Inkrementaalse lähenemise kaasaegne rakendamine on XP Extreme Programming. (Kent Beck, 1999)

Kiire rakenduste arendus Kiire rakenduste arendusmudel (Rapid Rakenduste arendus) – teine näide inkrementaalse ehitusstrateegia rakendamisest

RAD-mudel pakub äärmiselt lühikest arendustsüklit. RAD on lineaarse järjestikuse mudeli kiire adaptsioon, milles kiire areng saavutatakse komponentidele orienteeritud disaini kasutamisega. Kui nõuded on täielikult määratletud ja projekti piirkond on piiratud, võimaldab RAD-protsess meeskonnal luua tervikliku funktsionaalne süsteem väga lühikese aja jooksul (60-90 päeva). RAD-lähenemine on keskendunud infosüsteemide arendamisele ja eristab järgmisi etappe: – äri modelleerimine. Modelleeritakse infovoogu ärifunktsioonide vahel. Otsitakse vastust järgmistele küsimustele: Milline teave juhib äriprotsessi? Millist teavet genereeritakse? Kes selle genereerib? Kus teavet rakendatakse? Kes seda töötleb? – andmete modelleerimine. Äri modelleerimise etapis tuvastatud teabevoog kaardistatakse andmeobjektide kogumiga, mis on ettevõtte toetamiseks vajalikud. Tuvastatakse iga objekti omadused (omadused, atribuudid), määratakse objektidevahelised suhted;

– töötlemise simuleerimine. Määratletakse andmeobjektide teisendused, mis tagavad ärifunktsioonide rakendamise. Töötlemise kirjeldused luuakse andmeobjektide lisamiseks, muutmiseks, kustutamiseks või leidmiseks (parandamiseks); – rakenduste genereerimine. See peaks kasutama meetodeid, mis on keskendunud 4. põlvkonna programmeerimiskeeltele. Selle asemel, et ehitada tarkvara 3. põlvkonna programmeerimiskeeli kasutades, töötab RAD-protsess korduvkasutatavate tarkvarakomponentidega või loob korduvkasutatavaid komponente. Ehituse toetamiseks kasutatakseid; - testimine ja ühendamine. Kuna kasutatakse korduvkasutatavaid komponente, on paljusid tarkvaraelemente juba testitud. See vähendab testimisaega (kuigi kõiki uusi esemeid tuleb testida). RAD-i kasutamine on võimalik, kui iga põhifunktsioon saab valmis 3 kuuga. Iga põhifunktsiooni käsitletakse eraldi grupp arendajatele ja seejärel integreerida kogu süsteemi.

RAD-i kasutamisel on oma puudused ja piirangud. 1. RAD-i suurte projektide jaoks on vaja märkimisväärset inimressurssi (tuleb luua piisav arv meeskondi). 2. RAD on rakendatav ainult nende rakenduste jaoks, mida saab lahti võtta eraldi mooduliteks ja mille puhul jõudlus ei ole kriitiline väärtus. 3. RAD ei ole rakendatav kõrge tehnilise riskiga keskkondades (s.o. uue tehnoloogia kasutamisel).

Spiraalmudel Spiraalmudel on evolutsioonilise disainistrateegia klassikaline näide. Spiraalmudel (autor Barry Boehm, 1988) tugineb klassikalise elutsükli ja prototüüpimise parimatele omadustele, millele lisandub uus element – riskianalüüs, mis neis paradigmades puudub.

Spiraalmudel: 1 - esialgsete nõuete kogumine ja projekti planeerimine; 2 - sama töö, kuid kliendi soovituste alusel; 3 - esialgsetel nõuetel põhinev riskianalüüs; 4 - kliendi reaktsioonil põhinev riskianalüüs; 5 - minge integreeritud süsteem; 6 - süsteemi esialgne paigutus; 7 - järgmine paigutustase; 8 - kavandatud süsteem; 9 - kliendipoolne hindamine. Mudel määratleb neli tegevust, mida esindavad spiraali neli kvadrandit. 1. Planeerimine – eesmärkide, valikute ja piirangute määratlemine. 2. Riskianalüüs - optsioonide analüüs ja riskide tuvastamine/valik. 3. Disain – tootearendus järgmine tase. 4. Hindamine – hetkeprojekti tulemuste hindamine tellija poolt.

Spiraali mudeli integreeriv aspekt on ilmne, kui arvestada spiraali radiaalset mõõdet. Iga iteratsiooniga spiraalselt (keskmest perifeeriasse liikudes) luuakse tarkvarast üha enam terviklikke versioone. Spiraali esimene pööre - määratakse esialgsed eesmärgid, võimalused ja piirangud, teadvustatakse risk ja analüüsitakse seda. Kui riskianalüüsi käigus ilmneb nõuete ebakindlus, tuleb arendajale ja tellijale appi prototüüpimine (kasutatakse disainikvadrandis). Järgmine planeerimise ja riskianalüüsi faas põhineb klientide ettepanekutel. Igas spiraali läbivas tsüklis vormistatakse riskianalüüsi tulemused kujul "jätka, ära jätka" . Kui risk on liiga suur, võidakse projekt peatada. Spiraal jätkub, kusjuures iga samm viib arendajaid rohkemate poole üldine mudel süsteemid.

Spiraalmudeli eelised: 1) peegeldab kõige realistlikumalt (evolutsiooni vormis) tarkvaraarendust; 2) võimaldab selgesõnaliselt arvestada riskiga arengu evolutsiooni igas etapis; 3) sisaldab arenduse iteratiivses struktuuris süstemaatilise lähenemise sammu; 4) kasutab simulatsiooni riski vähendamiseks ja tarkvaratoote täiustamiseks. Spiraalmudeli puudused: 1) uudsus (puudub piisav statistika mudeli efektiivsuse kohta); 2) kõrgendatud nõuded kliendile; 3) raskused arendusaja jälgimisel ja juhtimisel.

Komponendipõhine mudel on spiraalmudeli edasiarendus ja põhineb ka evolutsioonilisel disainistrateegial. Mudel täpsustab disainikvadrandi sisu – see peegeldab tõsiasja, et tänapäevastes tingimustes peaks uusarendus põhinema olemasolevate tarkvarakomponentide taaskasutamisel. - Tarkvarakomponendid, mis on loodud rakendatud tarkvaraprojektides, salvestatakse raamatukogus. – Uues tarkvaraprojektis selgitatakse välja kandidaatkomponendid, lähtudes kliendi nõudmistest. – Järgmisena kontrollitakse nende kandidaatide olemasolu raamatukogus. – Kui kandidaate leitakse, hangitakse komponendid raamatukogust välja ja kasutatakse uuesti. – Vastasel juhul luuakse uued komponendid, rakendatakse need projektile ja lisatakse teeki. Komponentidele orienteeritud mudeli eelised: 1) vähendab tarkvaratoote arendusaega 30% võrra; 2) vähendada kulusid tarkvara arendamine kuni 70%; 3) tõstab arenduse tootlikkust poolteist korda.

Raske- ja kergekaalulised protsessid 21. sajandil on ühiskonna vajadused infotehnoloogia tarkvara järele jõudnud äärmuslikule tasemele. Traditsiooniliselt on tarkvaraarenduse tõhustamiseks ja kiirendamiseks välja pakutud raskekaaluliste protsesside range järjestamine. Nendes protsessides ennustatakse kogu eelseisva töö maht, seetõttu nimetatakse neid ennustavateks (ennustuslikeks) protsessideks. Järjekord, mida inimarendaja peab antud juhul järgima, on äärmiselt range ja inimlikke nõrkusi ei arvestatud ning vajaliku dokumentatsiooni maht oli väga suur. IN viimased aastad on ilmunud rühm uusi, kergeid (kergekaalulisi) protsesse, mida nüüd nimetatakse mobiilseteks (agiilseteks) protsessideks. Need on atraktiivsed rasketele (ennustus)protsessidele omase bürokraatia puudumise tõttu ning kehastavad mõistlikku kompromissi liiga range distsipliini ja selle täieliku puudumise vahel.

Seega on tarkvaratehnika kaasaegses infrastruktuuris kaks arendusprotsesside perekonda: - ennustavate (raskekaaluliste) protsesside perekond; – adaptiivsete (mobiilsete, kergekaaluliste) protsesside perekond. Igal perel on omad plussid, miinused ja ulatus: - kasutatakse adaptiivset protsessi koos sagedaste nõuete muutumisega, väike grupp kõrgelt kvalifitseeritud arendajaid ja kompetentne klient, kes on nõus arenduses osalema; – ennustamisprotsessi kasutatakse fikseeritud nõuetega ja suure hulga erineva kvalifikatsiooniga arendajaid.

XP protsess Extreme programmeerimine (nt Xtreme Programming, XP) on kerge (mobiilne) protsess (või metoodika) (Kent Beck, 1999). XP protsess on suunatud väikestele ja keskmise suurusega meeskondadele, kes ehitavad tarkvara, pidades silmas ebakindlaid või kiiresti muutuvaid nõudeid. XP-grupi moodustavad kuni 10 töötajat, kes asuvad samas ruumis. XP põhiidee on kõrvaldada muudatuste kõrge hind, mis on omane objekte, mustreid ja relatsiooniandmebaase kasutavatele rakendustele. XP protsess peaks olema väga dünaamiline protsess. XP meeskond tegeleb nõuete muudatustega kogu arenduste iteratsioonitsükli jooksul ja tsükkel koosneb väga lühikestest iteratsioonidest. XP tsükli neli põhitegevust on: kodeerimine, testimine, kliendi kuulamine ja kujundamine. Dünaamilisust annavad neli omadust: pidev suhtlus kliendiga (ja grupi sees), lihtsus (vali alati miinimumlahendus), kiire tagasisidet(läbi ühiku- ja funktsionaalse testimise), julgust ennetada võimalikke probleeme.

Enamik XP toetatud põhimõtteid (minimalism, lihtsus, evolutsiooniline arendustsükkel, lühike iteratsiooniaeg, kasutajate osalus, optimaalsed kodeerimisstandardid jne) on dikteeritud tervest mõistusest ja kehtivad igas korrastatud protsessis. XP-s jõuavad need põhimõtted "äärmuslike väärtusteni". Enamik XP toetatud põhimõtteid (minimalism, lihtsus, evolutsiooniline arendustsükkel, lühike iteratsiooniaeg, kasutajate osalus, optimaalsed kodeerimisstandardid jne) on dikteeritud tervest mõistusest ja kehtivad igas korrastatud protsessis. XP-s jõuavad need põhimõtted "äärmuslike väärtusteni". Mõelge "ideaalse" XP protsessi struktuurile. Protsessi põhiline struktuurielement on XP-rakendus, millesse põhielement, XP-iteratsioon, on korduvalt põimitud. XP juurutamine ja XP iteratsioon koosnevad kolmest faasist - - uurimine, - blokeerimine, - reguleerimine.

Uurimine on uute nõuete (lugude, ülesannete) otsimine, mida süsteem peab täitma. Lukk (kohustus) - valik kõigi võimalike nõuete konkreetse alamhulga rakendamiseks (teisisõnu planeerimiseks). Reguleerimine (juhtimine) - arenduse läbiviimine, plaani ellu viimine. XP soovitab: – Esimene juurutamine peaks kestma 2–6 kuud – Ülejäänud juurutused peaksid kestma umbes kaks kuud – Iga iteratsioon peaks kestma umbes kaks nädalat – Arendusmeeskond ei tohiks ületada 10 inimest. XP näide Seitsme juurutusega 15-kuulise projekti protsess – protsessi käivitab esialgne uurimisetapp. – Uurimisfaasis, millest algab igasugune juurutamine ja iteratsioon, on vahelejätmise klapp, selles etapis tehakse otsus töö edasise jätkamise otstarbekuse kohta. - Eeldatakse: esimese rakendamise kestus on 3 kuud, teise - seitsmenda rakenduse kestus - 2 kuud.

Teine - seitsmes teostus moodustavad hooldusperioodi, mis iseloomustab XP projekti olemust. Iga iteratsioon kestab kaks nädalat, välja arvatud need, mida nimetatakse juurutamise hilisem etapiks - "käivitamine tootmises" (sel ajal iteratsiooni tempo kiireneb). Esimene juurutamine on kõige keerulisem – kolme kuuga on väga raske jõuda tavapärasest algusest (ütleme, et üksiktöötaja ei ole mingeid nõudeid fikseerinud, piiranguid pole määratletud) tööstusliku kvaliteedisüsteemi kliendile tarnimiseni.

Projekteerimisprotsesside kvaliteedimudelid Tiheda konkurentsiga keskkonnas on oluline tagada kõrge kvaliteet tarkvara ehitusprotsess. Garantii annab protsessi kvaliteedisertifikaat, mis kinnitab selle vastavust aktsepteeritud rahvusvahelistele standarditele. Iga standard määrab kindlaks oma kvaliteedi tagamise mudeli. Kõige autoriteetsemad mudelid on standardid: - ISO 9001: 2000; – ISO/IEC 15504; – Ameerika ülikooli Carnegie Melloni tarkvaratehnika instituudi tarkvara ehitusprotsessi küpsuse mudel (Capability Maturity Model – CMM). ISO 9001:2000 standardi mudel on keskendunud arendusprotsessidele kõigist inimtegevuse valdkondadest. ISO/IEC 15504 standard keskendub tarkvara arendusprotsessidele ja on detailsema tasemega. CMM mudeli põhikontseptsiooniks on ettevõtte küpsus – Immature on ettevõte, kus tarkvara disainimise protsess ja tehtavad otsused sõltuvad vaid konkreetsete arendajate talendist. Selle tulemusena on suur tõenäosus eelarve ületamiseks või projekti lõpetamata jätmiseks.

– Küpsel ettevõttel on selged protseduurid projektide haldamiseks ja tarkvaratoodete loomiseks. – Arendusaja ja kulu hinnangud on täpsed ja põhinevad kogemustel. – Ettevõttel on ettevõtte standardid kliendiga suhtlemise protsesside, tarkvaratoodete analüüsi, projekteerimise, programmeerimise, testimise ja juurutamise protsesside jaoks ja need toimivad. CMM-mudel fikseerib ettevõtte küpsuse hindamise kriteeriumid ja pakub retsepte selles olemasolevate protsesside täiustamiseks.CMM-mudel on keskendunud protsesside pideva täiustamise süsteemi ülesehitamisele. Mudel hõlmab viit küpsusastet ja pakub sujuvat, järkjärgulist lähenemist protsessi täiustamisele – samm-sammult kinnituse protsessi täiustamise kohta saab pärast iga küpsusastet.

Tase 1 (esialgne) tähendab, et protsess ettevõttes ei ole vormistatud. Seda ei saa rangelt planeerida ja jälgida, selle õnnestumine on juhuslik. Töö tulemus sõltub täielikult üksikute töötajate isikuomadustest. Selliste töötajate lahkumisel projekt peatub. Tase 2 (korduv). Korratavale tasemele liikumiseks on vaja kasutusele võtta formaalsed protseduurid projekteerimisprotsessi põhielementide teostamiseks. Protsessi tulemused vastavad kindlaksmääratud nõuetele ja standarditele. Peamine erinevus 1. tasemest seisneb selles, et protsessi läbiviimine on planeeritud ja kontrollitud. Rakendatud planeerimis- ja juhtimisvahendid võimaldavad korrata varem saavutatud õnnestumisi. 3. tase (määratletud) nõuab, et kõik protsessi elemendid oleksid määratletud, standarditud ja dokumenteeritud. Peamine erinevus 2. tasemest seisneb selles, et 3. taseme protsessielemendid planeeritakse ja juhitakse ühe ettevõtte standardi alusel. Arendatava tarkvara kvaliteet ei sõltu enam inimeste võimetest.

4. tase (hallatud). Juhtitavale tasemele üleminekuga aktsepteerib ettevõte nii tarkvaratoodete kui ka protsessi kvaliteedi kvantitatiivseid näitajaid. See tagab täpsema projekti planeerimise ja selle tulemuste kvaliteedikontrolli. Peamine erinevus 3. tasemest on toote ja protsessi objektiivsem, kvantitatiivsem hindamine. 5. tase (optimeerimine). Kõrgeim tase viitab sellele peamine ülesanne ettevõte täiustab ja tõhustab pidevalt olemasolevaid protsesse, juurutab uusi tehnoloogiaid. Peamine erinevus 4. tasemest seisneb selles, et tarkvaratoodete loomise ja hooldamise tehnoloogiat täiustatakse süstemaatiliselt ja järjepidevalt. Iga HMM-i taset iseloomustab ala võtmeprotsessid(OKP) ja arvestatakse, et iga järgmine tase sisaldab kõiki eelmiste tasemete omadusi. Protsessi põhivaldkond koosneb protsessidest, mis koos läbiviimisel viivad konkreetsete eesmärkide saavutamiseni. Näiteks 5. taseme OKP moodustavad protsessid: – defektide ennetamine; – tehnoloogiamuutuste juhtimine; – protsessimuutuste juhtimine. Kui kõik OKP eesmärgid on saavutatud, antakse ettevõttele selle küpsusastme tunnistus. Kui vähemalt ühte eesmärki ei saavutata, ei suuda ettevõte seda SMM-i taset täita

Projekti juht. Definitsioonid ja mõisted Projektijuhtimine on vaid üks 17-st tarkvaratehnika teadmiste valdkonnast ja isegi siis on see abistav. Enamiku tarkvaraprojektide ebaõnnestumiste peamine põhjus on aga ebaadekvaatsete arendusjuhtimistavade kasutamine. Projekt on jõupingutuste kogum, mis tehakse konkreetsete ainulaadsete tulemuste saavutamiseks ettenähtud aja jooksul ja kinnitatud eelarve piires, mis on ette nähtud projektis kasutatud või tarbitud ressursside eest tasumiseks. [Archibald R.]. Projekt on tegevuste kogum, mille eesmärk on saavutada unikaalne tulemus, olgu selleks siis toode või teenus. Projekti eesmärk kirjeldab, milliseid ülesandeid tuleks projekti tulemusena lahendada. Projekti ulatus – mis täpselt on projekti tulemus. Infosüsteemi jaoks selle funktsionaalsus. Projektijuhtimine määrab “kuidas”, milliste tegevustega saavutatakse projekti eesmärk ja luuakse soovitud tulemus. Samas saab ja peakski projektijuhtimist rakendama projekti elutsükli kõikides etappides, st projektijuhtimine on pidev tegevus.

Tulenevalt projekti sisulisest mastaabist või näiteks selle komponentide heterogeensusest (näiteks tarkvara- ja riistvarakompleks andmete krüpteerimiseks) saab projekti jagada mitmeks väiksemaks projektiks. Kuna eesmärgid, ressursid, aeg on seotud iga projektiga, võime sõnastada, et projektijuhtimine on distsipliin, kus rakendatakse meetodeid, tavasid ja kogemusi projektitegevustes, et saavutada projektide eesmärgid, tingimusel et rahuldatakse piirangud, mis määravad nende ulatuse. . Piirangud projektides. Enamasti räägitakse kolmest peamisest piirangust ehk “raudsest kolmnurgast” 1. Projekti sisu 2. Aeg 3. Maksumus

Igasugune kvaliteedihindamine peaks põhinema mõõtmistel ja kvantifitseeritavatel mõõtmistulemustel. Kvaliteedinõudeid tuleks kirjeldada ka kvantifitseeritavate tunnustega. Projektijuhtimise protsess. Piirangute roll.

Tarkvaratööstuse rakenduses lisatakse tavaliselt neljas piirang - kvaliteet, vastuvõetav kvaliteet. Olenevalt kontekstist ja konkreetsel juhul käsitletavatest kvaliteedikriteeriumidest võib „vastuvõetavat“ kvaliteeti pidada vajalikuks, näiteks kvaliteedinõuete ja ettevõtte sisestandardite järgi.