mājas › Multivide › Pieejas programmatūras izstrādei. Strukturēta pieeja programmatūras izstrādei. Agilas attīstības principi un nozīme

Pieejas programmatūras izstrādei. Strukturēta pieeja programmatūras izstrādei. Agilas attīstības principi un nozīme

1.Kodēšana

Programmatūras izstrādes stadijā tiek veiktas šādas galvenās darbības: kodēšana; testēšana; PP palīdzības sistēmas izstrāde; lietotāja dokumentācijas veidošana; programmatūras versijas izveide un instalēšana,

Kodēšana ir augsta un zema līmeņa dizaina rezultātu pārvēršanas process gatavā programmatūras produktā. Citiem vārdiem sakot, kodējot, sastādītais programmatūras modelis tiek aprakstīts, izmantojot izvēlēto programmēšanas valodu, kas var būt jebkura no esošajām valodām. Valodas izvēle tiek veikta vai nu pēc klienta pieprasījuma, vai arī ņemot vērā risināmo problēmu un Personīgā pieredze izstrādātājiem.

Kodējot, jāievēro izvēlētās valodas standarts, piemēram, C valodai tas ir ANSI C, bet C++ – ISO/IEC 14882 “Standarts C++ ProgrammingLanguage”.

Papildus vispārpieņemtajam programmēšanas valodas standartam uzņēmums var izstrādāt arī savas papildu prasības programmu rakstīšanas noteikumiem. Tie galvenokārt attiecas uz programmas teksta formatēšanas noteikumiem.

Standarta un uzņēmuma noteikumu ievērošana ļauj izveidot pareizi strādājošu, viegli lasāmu un citiem izstrādātājiem saprotamu programmu, kas satur informāciju par izstrādātāju, izveides datumu, nosaukumu un mērķi, kā arī nepieciešamos datus konfigurācijas pārvaldībai.

Kodēšanas stadijā programmētājs raksta programmas un pats tās pārbauda. Šāda veida testēšanu sauc par vienības testēšanu. Visi ar programmatūras testēšanu saistītie jautājumi ir apskatīti nodaļā. 10, šeit ir aprakstīta arī testēšanas tehnoloģija, kas tiek izmantota programmatūras izstrādes stadijā. Šo tehnoloģiju sauc par testēšanu "stikla kaste" (stikla kaste); dažreiz to sauc arī par testēšanu "baltā kaste" (baltā kaste) pretstatā klasiskajam “melnās kastes” jēdzienam.

Melnās kastes testēšanā programma tiek uzskatīta par objektu, kura iekšējā struktūra nav zināma. Testētājs ievada datus un analizē rezultātu, taču viņš precīzi nezina, kā programma darbojas. Izvēloties testus, speciālists meklē no viņa viedokļa interesantus ievades datus un nosacījumus, kas var novest pie nestandarta rezultātiem. Viņu galvenokārt interesē tie katras ievaddatu klases pārstāvji, kuros visticamāk var rasties kļūdas pārbaudāmajā programmā.

Pārbaudot “stikla kastīti”, situācija ir pavisam cita. Testētājs (šajā gadījumā programmētājs pats) izstrādā testus, pamatojoties uz zināšanām par avota kodu, kuram viņam ir piekļuve pilna piekļuve. Rezultātā viņš saņem šādus pabalstus.

1. Pārbaudes virziens. Programmētājs var testēt programmu pa daļām, izstrādāt īpašas pārbaudes apakšprogrammas, kas izsauc testējamo moduli un pārsūta uz to programmētāju interesējošos datus. Daudz vienkāršāk ir pārbaudīt atsevišķu moduli kā “stikla kasti”.

2. Pilns koda pārklājums. Programmētājs vienmēr var noteikt, kuri koda fragmenti darbojas katrā testā. Viņš redz, kuri citi koda atzari paliek nepārbaudīti, un var izvēlēties nosacījumus, kādos tie tiks pārbaudīti. Tālāk ir aprakstīts, kā izsekot veikto testu koda pārklājuma pakāpei.

3. Spēja kontrolēt komandu plūsmu. Programmētājs vienmēr zina, kura funkcija ir jāizpilda nākamajā programmā un kādam jābūt tās pašreizējam stāvoklim. Lai noskaidrotu, vai programma darbojas tā, kā viņš domā, programmētājs var iekļaut atkļūdošanas komandas, kas parāda informāciju par tās izpildi, vai izmantot īpašu programmu, lai to izdarītu. programmatūra sauc par atkļūdotāju. Atkļūdotājs var paveikt daudz noderīgas lietas: uzraudzīt un mainīt programmas komandu izpildes secību, parādīt tā mainīgo saturu un to adreses atmiņā utt.

4. Spēja uzraudzīt datu integritāti. Programmētājs zina, kurai programmas daļai ir jāmaina katrs datu elements. Pārraugot datu stāvokli (izmantojot vienu un to pašu atkļūdotāju), viņš var identificēt tādas kļūdas kā nepareizi moduļi mainīti dati, to nepareiza interpretācija vai neveiksmīga organizācija Programmētājs pats var automatizēt testēšanu.

5.Iekšējo robežpunktu redzējums. IN avota kods ir redzami tie programmas robežpunkti, kas ir paslēpti no ārpuses. Piemēram, noteiktas darbības veikšanai var tikt izmantoti vairāki pilnīgi atšķirīgi algoritmi, un, neapskatot kodu, nav iespējams noteikt, kuru programmētājs izvēlējās. Vēl viens izplatīts piemērs būtu pārpildes problēma buferī, ko izmanto ievades datu īslaicīgai glabāšanai. Programmētājs var uzreiz pateikt, pie kāda datu apjoma buferis pārpildīsies, un viņam nav jāveic tūkstošiem testu.

6. Testēšanas iespēja, ko nosaka izvēlētais algoritms. Lai pārbaudītu datu apstrādi, kurā tiek izmantoti ļoti sarežģīti skaitļošanas algoritmi, var būt nepieciešamas īpašas tehnoloģijas. Klasiskie piemēri ietver matricas transformāciju un datu kārtošanu. Testētājam, atšķirībā no programmētāja, ir precīzi jāzina, kādi algoritmi tiek izmantoti, tāpēc viņam ir jāvēršas pie specializētās literatūras.

Stikla kastes testēšana ir daļa no programmēšanas procesa. Programmētāji šo darbu veic pastāvīgi, pārbauda katru moduli pēc tā uzrakstīšanas un pēc tam vēlreiz pēc integrēšanas sistēmā.

Veicot vienību testēšanu, varat izmantot strukturālās vai funkcionālās testēšanas tehnoloģiju, vai abus.

Strukturāls testēšana ir stikla kastes testēšanas veids. Tās galvenā ideja ir pareiza pārbaudāmā programmatūras ceļa izvēle. Pretstatā viņam funkcionāls testēšana ietilpst melnās kastes testēšanas kategorijā. Katra programmas funkcija tiek pārbaudīta, ievadot tās ievades datus un analizējot tās izvadi. Tajā pašā laikā ļoti reti tiek ņemta vērā programmas iekšējā struktūra.

Lai gan strukturālā pārbaude ir daudz spēcīgāka teorētiskā bāze, lielākā daļa testētāju dod priekšroku funkcionālajai pārbaudei. Strukturālā pārbaude ir labāk piemērota matemātiskajai modelēšanai, taču tas nenozīmē, ka tā ir efektīvāka. Katra tehnoloģija ļauj identificēt kļūdas, kas pieļautas, izmantojot otru. No šī viedokļa tos var saukt par vienlīdz efektīviem.

Pārbaudes objekts var būt ne tikai pilns ceļš programma (komandu secība, ko tā izpilda no sākuma līdz beigām), bet arī tās atsevišķās sadaļas. Ir absolūti nereāli pārbaudīt visus iespējamos programmas izpildes veidus. Tāpēc testēšanas speciālisti no visiem iespējamiem ceļiem identificē tās grupas, kuras noteikti ir jāpārbauda. Atlasei viņi izmanto īpašus kritērijus, ko sauc pārklājuma kritēriji (coveragecriteria), kas nosaka ļoti reālu (pat ja diezgan lielu) testu skaitu. Šos kritērijus dažreiz sauc loģiski pārklājuma kritēriji, vai pilnīguma kritēriji.

3. Palīdzības sistēmas izveide programmatūras produkts. Lietotāja dokumentācijas izveide

Kādu no projekta darbiniekiem vēlams iecelt par dokumentācijas tehnisko redaktoru. Šis darbinieks var veikt arī citus darbus, taču viņa galvenais uzdevums ir dokumentācijas analīze, pat ja to izstrādā arī citi darbinieki.

Bieži gadās, ka pie programmatūras izveides strādā vairāki cilvēki, taču neviens no viņiem neuzņemas pilnu atbildību par tās kvalitāti. Rezultātā programmatūra ne tikai negūst labumu no tā, ka to izstrādā vairāk cilvēku, bet arī zaudē, jo katrs zemapziņā novelk atbildību uz otru un sagaida, ka viņa kolēģi paveiks šo vai citu darba daļu. Šī problēma tiek atrisināta, ieceļot redaktoru, kurš ir pilnībā atbildīgs par tehniskās dokumentācijas kvalitāti un precizitāti.

PP palīdzības sistēma tiek veidota, pamatojoties uz lietotāja rokasgrāmatai izstrādāto materiālu. To veido un veido atbildīgā persona par šī darba veikšanu. Tas var būt tehniskais redaktors vai viens no izstrādātājiem kopā ar tehnisko redaktoru.

Labi dokumentētam PP ir šādas priekšrocības.

1. Lietošanas ērtums. Ja programmatūra ir labi dokumentēta, to ir daudz vieglāk lietot. Lietotāji to apgūst ātrāk, pieļauj mazāk kļūdu, kā rezultātā savu darbu veic ātrāk un efektīvāk.

2. Zemākas izmaksas tehniskā palīdzība. Ja lietotājs nevar saprast, kā veikt viņam nepieciešamās darbības, viņš zvana PCB ražotāja tehniskā atbalsta dienestam. Šāda pakalpojuma nodrošināšana ir ļoti dārga. Laba rokasgrāmata palīdz lietotājiem pašiem atrisināt problēmas un samazina nepieciešamību sazināties ar tehniskā atbalsta komandu.

3. Augsta uzticamība. Nesaprotama vai nevīžīga dokumentācija padara programmatūru mazāk uzticamu, jo tās lietotāji biežāk pieļauj kļūdas un viņiem ir grūti saprast, kas tās izraisījis un kā rīkoties ar to sekām.

Apkopes vienkāršība. Milzīgs daudzums naudas un laika tiek tērēts, lai analizētu problēmas, ko izraisa lietotāja kļūdas. Jaunajos programmatūras laidienos veiktās izmaiņas bieži vien ir vienkārši veco funkciju saskarnes izmaiņas. Tie tiek ieviesti, lai lietotāji beidzot saprastu, kā lietot programmatūru, un pārtrauktu zvanīt tehniskajam atbalstam. Lielā mērā laba vadība

Datorzinātne, kibernētika un programmēšana

Iterācija N vienotais izstrādes process programmatūra USDP lietošanas gadījuma modelis apraksta gadījumus, kādos lietojumprogramma tiks izmantota. Analītiskais modelis apraksta lietojumprogrammas bāzes klases. Dizaina modelis apraksta savienojumus un attiecības starp klasēm un piešķirtajiem objektiem.Izvietošanas modelis apraksta programmatūras sadalījumu pa datoriem.

Nodarbība Nr.20
Programmatūras izstrādes vispārīgie principi un pieejas

Programmatūras izstrādes modeļi

Vodopadnaja
Kaskādes modelis
Spirāle
Ekstrēmā programmēšana
Papildu
MSF metodoloģija

Ūdenskrituma modelis

Spirālveida modelis

Inkrementāla attīstība

Prasību analīze

Dizains

Īstenošana

Komponents

testēšana

Integrācija

Testēšana

viens vesels

1. iterācija 2. iterācija…. Iterācija N

Vienotais programmatūras izstrādes process (USDP)

Lietošanas gadījumu modelis apraksta gadījumus, kādos lietojumprogramma tiks izmantota.
Analītiskais modelis apraksta lietojumprogrammas bāzes klases.
Dizaina modelis apraksta savienojumus un attiecības starp klasēm un atlasītajiem objektiem
Izvietošanas modelis apraksta programmatūras izplatīšanu starp datoriem.
Īstenošanas modelis apraksta programmas koda iekšējo organizāciju.
Testa modelis sastāv no testa komponentiem, testa procedūrām un dažādiem testa gadījumiem.

MSF metodoloģija

Tipiski programmatūras produktu arhitektūras komponenti un tipiskas programmatūras prasības

kļūdu tolerancesistēmas īpašību kopums, kas palielina tās uzticamību, atklājot kļūdas, atjaunojot un lokalizējot sliktās sekas sistēmai. Projektējot jebkuru reālu sistēmu, lai nodrošinātu kļūdu toleranci, ir jāparedz visas iespējamās situācijas, kas var izraisīt sistēmas atteici un jāizstrādā mehānismi kļūdu novēršanai.

Uzticamība sistēmas spēja izturēt dažādas atteices un atteices.

Atteikums šī ir sistēmas pārejakļūdas rezultātā nonāk pilnīgi nederīgā stāvoklī.

Avārija kļūda sistēmas darbībā, kas neizraisa sistēmas atteici.

Jo mazāk kļūmju un kļūmju noteiktā laika periodā, jo uzticamāka tiek uzskatīta sistēma.

Kā arī citi darbi, kas varētu jūs interesēt
57355.		Organisko savienojumu daudzveidība, to klasifikācija. Dzīvās dabas organiskās vielas	48,5 KB
	Organisko savienojumu daudzveidību nosaka unikālā oglekļa atomu spēja savienoties vienam ar otru ar vienkāršām un daudzkārtējām saitēm, veidojot savienojumus ar gandrīz neierobežotu skaitu ķēdēs savienotu atomu: cikli, velosipēdi, trīsriteņi, policikli, karkasi u.c.
57359.		Verbālās informācijas modeļu apstrāde	291 KB
	Pamatjēdzieni: modelis; informācijas modelis; verbālās informācijas modelis; anotācija; abstrakts. Anotācija Konspekts no lat. Izveidojiet piezīmi 2. Saglabājiet dokumentu savā mapē ar nosaukumu Piezīme.
57361.		Skaitlis un attēls 3. Ciparu izlīdzināšana pie robežām 3. Ciparu rakstīšana 3. Objektu skaita līdzināšana	35,5 KB
	Cik radījumu ir Kurš ieņem pirmo Kurš ieņem pēdējo Kurš ieņem 1. numuru Kurš ieņem 2. numuru Nosauc eža kaimiņus. Kas ir labrocis vāvere Kurš ir kreisais žirafe Kurš ir lielākais Kurš ir mazākais Kas stāv būtņu vidū Gra Parādi man, neapžēlojies.

Mūsdienās programmatūras inženierijā EIS programmatūras izstrādei ir divas galvenās pieejas, kuru būtiskā atšķirība ir saistīta ar Dažādi ceļi sistēmu sadalīšanās. Pirmo pieeju sauc par funkcionāli modulāru vai strukturālu. Tas ir balstīts uz funkcionālās dekompozīcijas principu, kurā sistēmas struktūra ir aprakstīta tās funkciju hierarhijas izteiksmē un informācijas pārraides starp indivīdiem. funkcionālie elementi. Otrā uz objektu orientētā pieeja izmanto objektu sadalīšanu. Šajā gadījumā sistēmas struktūra ir aprakstīta ar objektiem un savienojumiem starp tiem, un sistēmas uzvedību raksturo ziņojumu apmaiņa starp objektiem.

Tātad EIS programmatūras izstrādes strukturālās pieejas būtība ir tās sadalīšanā (sadalīšanā) automatizētās funkcijās: sistēma ir sadalīta funkcionālās apakšsistēmās, kuras savukārt tiek sadalītas apakšfunkcijās, tās - uzdevumos un tā tālāk līdz. īpašas procedūras. Tajā pašā laikā automatizētā sistēma uztur holistisku skatījumu, kurā visas sastāvdaļas ir savstarpēji savienotas. Izstrādājot sistēmu "no apakšas uz augšu", no atsevišķiem uzdevumiem uz visu sistēmu, tiek zaudēta integritāte, rodas problēmas, aprakstot informācijas mijiedarbība atsevišķas sastāvdaļas.

Visas izplatītākās strukturālās pieejas metodes ir balstītas uz vairākiem vispārīgiem principiem. Pamatprincipi ir:

“skaldi un valdi” princips (skat. 2.1.1. apakšnodaļu);

hierarhiskās sakārtošanas princips ir sistēmas komponentu organizēšanas princips hierarhiskās koku struktūrās, katrā līmenī pievienojot jaunas detaļas.

Divu pamatprincipu izcelšana nenozīmē, ka pārējie principi ir sekundāri, jo jebkura no tiem ignorēšana var novest pie neparedzamām sekām (tostarp visa projekta neveiksmes). Galvenie no šiem principiem ir:

abstrakcijas princips - sistēmas būtisko aspektu izcelšana un abstrahēšana no nesvarīgā;

konsekvences princips - sistēmas elementu derīgums un konsekvence;

datu strukturēšanas princips – datiem jābūt strukturētiem un hierarhiski sakārtotiem.

Strukturālā pieeja galvenokārt izmanto divas rīku grupas, kas apraksta sistēmas funkcionālo struktūru un attiecības starp datiem. Katra rīku grupa atbilst noteikta veida modeļiem (diagrammām), no kuriem visizplatītākie ir:

DFD (Data Flow Diagrams) - datu plūsmas diagrammas;

SADT (Structured Analysis and Design Technique - strukturālās analīzes un projektēšanas metode) - modeļi un atbilstošās funkcionālās diagrammas;

ERD (Entity-Relationship Diagrams) - entītiju attiecību diagrammas.

Datu plūsmas diagrammas un entītiju attiecību diagrammas ir visbiežāk izmantotie modeļu veidi CASE rīkos.

Konkrēts skats no uzskaitītajām diagrammām un to dizaina interpretācija ir atkarīga no programmatūras dzīves cikla posma.

Programmatūras prasību veidošanas posmā SADT modeļi un DFD tiek izmantoti, lai izveidotu modeli "AS-IS" un "TO-BE" modeli, tādējādi atspoguļojot esošo un piedāvāto organizācijas biznesa procesu struktūru un mijiedarbību starp tiem ( SADT modeļu izmantošana, kā likums, aprobežojas tikai ar šo posmu, jo sākotnēji tie nebija paredzēti programmatūras projektēšanai). Ar ERD palīdzību tiek veikts organizācijā izmantoto datu apraksts konceptuālā līmenī neatkarīgi no datu bāzes ieviešanas rīkiem (DBVS).

Projektēšanas stadijā DFD izmanto, lai aprakstītu projektētās programmatūras sistēmas struktūru, un tos var pilnveidot, paplašināt un papildināt ar jauniem dizainiem. Tāpat ERD tiek pilnveidotas un papildinātas ar jaunām konstrukcijām, kas apraksta datu attēlojumu loģiskā līmenī, kas piemērots turpmākai datu bāzes shēmas ģenerēšanai. Šos modeļus var papildināt ar diagrammām, kas atspoguļo programmatūras sistēmas arhitektūru, programmu blokshēmas, hierarhiju ekrāna formas un ēdienkarte utt.

Uzskaitītie modeļi kopā sniedz pilnīgu EIS programmatūras aprakstu neatkarīgi no tā, vai sistēma ir esoša vai jaunizstrādāta. Diagrammu sastāvs katrā konkrētajā gadījumā ir atkarīgs no sistēmas sarežģītības un nepieciešamās tās apraksta pilnības.

Lielākajai daļai šajā nodaļā sniegto diagrammu piemēru tēma ir Krievijas Federācijas nodokļu sistēma, kuras vispilnīgākais apraksts ir ietverts Krievijas Federācijas Nodokļu kodeksā. Informāciju tehnoloģijas, ko izmanto Krievijas Federācijas nodokļu sistēmā, ir noteiktas iezīmes.

Tātad EIS programmatūras izstrādes strukturālās pieejas būtība slēpjas tās sadalīšanā (sadalīšanā) automatizētās funkcijās: sistēma ir sadalīta funkcionālās apakšsistēmās, kuras savukārt ir sadalītas apakšfunkcijās, tās — uzdevumos un tā tālāk līdz. īpašas procedūras. Tajā pašā laikā sistēma uztur holistisku skatījumu, kurā visas sastāvdaļas ir savstarpēji saistītas. Izstrādājot sistēmu “no apakšas uz augšu”, no atsevišķiem uzdevumiem uz visu sistēmu, tiek zaudēta integritāte, un rodas problēmas, aprakstot atsevišķu komponentu informācijas mijiedarbību.

Visas visizplatītākās strukturālās pieejas metodes balstās uz vairākiem vispārīgiem principiem:

1. “Skaldi un valdi” princips;

2. Hierarhiskās sakārtošanas princips ir sistēmas komponentu organizēšanas princips hierarhiskās koku struktūrās, katrā līmenī pievienojot jaunas detaļas.

Divu pamatprincipu izdalīšana nenozīmē, ka pārējie principi ir sekundāri, jo ignorējot kādu no tiem, var rasties neparedzamas sekas (tostarp visa projekta neveiksme”). Galvenie no šiem principiem ir:

1. Abstrakcijas princips - sistēmas būtisko aspektu izcelšana un abstrahēšana no nesvarīgā.

2. Sistēmas elementu konsekvences, derīguma un konsekvences princips.

3. Strukturēšanas princips dati - dati jābūt strukturētiem un hierarhiski sakārtotiem.

Strukturālajā pieejā galvenokārt ir divas rīku grupas, kas apraksta sistēmas funkcionālo struktūru un attiecības starp datiem. Katra rīku grupa atbilst noteikta veida modeļiem (diagrammām), no kuriem visizplatītākie ir:

· DFD (Data Flow Diagrams) - datu plūsmas diagrammas;

· SADT (Structured Analysis and Design Technique - strukturālās analīzes un projektēšanas metodoloģija) - modeļi un atbilstošās funkcionālās diagrammas: apzīmējumi IDEF0 (sistēmu funkcionālā modelēšana), IDEF1х (konceptuālā datu bāzu modelēšana), IDEF3х (sistēmu uzbūve kvalitātes novērtēšanai). objekta darbs; grafiskais apraksts procesu plūsma, procesu un objektu mijiedarbība, ko šie procesi maina);

· ERD (Entity - Relationship Diagrams) - entītiju attiecību diagrammas.

Gandrīz visas strukturālās pieejas (strukturālās analīzes) metodes programmatūras prasību veidošanas stadijā izmanto divas modelēšanas rīku grupas:

1. Diagrammas, kas ilustrē funkcijas, kas sistēmai ir jāveic, un attiecības starp šīm funkcijām - DFD vai SADT (IDEF0).

2. Diagrammas, kas modelē datus un to attiecības (ERD).

Norādīto diagrammu īpašā forma un to dizaina interpretācija ir atkarīga no programmatūras dzīves cikla posma.

Programmatūras prasību veidošanas stadijā SADT modeļi un DFD tiek izmantoti, lai izveidotu modeli “AS-IS” un “TO-BE” modeli, tādējādi atspoguļojot esošo un piedāvāto organizācijas biznesa procesu struktūru un mijiedarbību starp tiem ( SADT modeļu izmantošana, kas parasti ir ierobežota tikai šajā posmā, jo sākotnēji tie nebija paredzēti programmatūras projektēšanai). Ar ERD palīdzību tiek veikts organizācijā izmantoto datu apraksts konceptuālā līmenī neatkarīgi no datu bāzes ieviešanas rīkiem (DBVS).

1. Programmēšanas tehnoloģijas mērķis. Programmēšanas tehnoloģiju attīstības vēsture. Programmatūras projektu veidi. Programmēšanas tehnoloģijas sastāvdaļas. Projekts, produkts, process un cilvēki

2. Programmas dzīves cikls. Attīstības cikliskais raksturs. Programmēšanas tehnoloģijas pamatjēdzieni. Procesi un modeļi. Fāzes un pagriezieni. Pagrieziena punkti un artefakti. Ieinteresētās personas un darbinieki.

3. Prasību noteikšana un analīze. Programmatūras prasības. Prasību izstrādes blokshēma. Prasību pārvaldība.

4. Arhitektūras un detālplānojums. Ieviešana un kodēšana. Testēšana un verifikācija. Kvalitātes kontroles process. Baltās kastes un melnās kastes metodes. Pārbaudes un apskati. Pārbaudes mērķi. Verifikācija, validācija un sistēmas testēšana. Uzturēšana un nepārtraukta attīstība.

5. Izstrādes procesa modeļi. Ūdenskritumu un konveijera modeļi. Spirālveida un inkrementālie modeļi. Elastīgi attīstības procesa modeļi.

6. Procesa modeļa konstruēšana. Nosakiet procesa prasības. Izmantotās fāzes, atskaites punkti un artefakti. Procesa arhitektūras izvēle. Standartprojekta izpildes kārtība. Dokumentētas procedūras.

7. Attīstības komandas modeļi. Attīstības kolektīvais raksturs. Optimāls komandas lielums. Projekta dalībnieku pakļautība. Komandas attīstība un personāla attīstība. Specializācija, sadarbība un mijiedarbība.

8. Attīstības komandas modeļi. Hierarhiskais komandas modelis. Ķirurģiskās komandas metode. Vienaudžu komandas modelis.

9. Programmēšanas būtība. Programmēšanas zinātne. Programmēšanas māksla. Programmēšanas amats. Programmēšanas paradigmas. Strukturēta programmēšana. Loģiskā programmēšana. Objektorientētā programmēšana.

10. Programmatūras arhitektūra. Pasākumu vadība. Klienta/servera arhitektūra. Pakalpojumi. Trīsslāņu arhitektūra. Programmas dizains. Konceptuāls dizains. Loģisks dizains. Detalizēts dizains.

1. Novikova pieejas programmatūras izstrādei" http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Ekstrēma programmēšana. – Sanktpēterburga: Pēteris, 2002.

3. Programmatūras izstrādes tehnoloģija. - Sanktpēterburga. : Pēteris, 2004.

4. Brūkss jaunākais. ir izstrādāti un radīti programmatūras sistēmas. M.: Nauka, 1975; tulkojuma jauns izdevums: The Mythical Man-Month. SPb.: SYMBOL+, 1999. gads.

5. Algoritmi + datu struktūras = programmas. M., Mir, 1978.

6. Sistemātiska programmēšana. Ievads. M.: Mir, 1977.

7. Strukturētā programmēšana. M.: Mir, 1975.

8. Programmēšanas disciplīna. M.: Mir, 1978.

9. Programmatūras izstrādes tehnoloģijas. – Sanktpēterburga: Pēteris, 2002.

10. Terekhova programmēšana. M.: BINOM, 2006.

11. Rambo J. Vienots programmatūras izstrādes process. Sanktpēterburga: Pēteris, 2002.

Ekonomikas teorija vadītājiem

Mikroekonomikas pamatteorijas. Pielietojuma piemēri ekonomisko procesu analīzē. Makroekonomikas pamatteorijas. Pielietojuma piemēri ekonomisko procesu analīzē. Ekonomisko procesu vadīšanas principi un metodes. Līdzekļi ekonomisko procesu attīstības līmeņa novērtēšanai Paplašinātās pavairošanas problēmas. Krievijas ekonomikas ekonomiskās izaugsmes faktori. Ilgtspējīgas attīstības kritēriji un rādītāji. Ciklisko svārstību izlīdzināšana. Multiplikatora un akseleratora loma tautsaimniecības attīstības tempu novērtēšanā. Ražošanas funkcijas ekonomikā. Pielietojuma piemēri ekonomisko procesu analīzē. Peļņa. Peļņu ietekmējošo rādītāju aprēķināšana, grafiskais attēls līdzsvara punkts. Investīciju politikas īstenošanas metodika.

Ekonomikas teorijas kurss: mācību grāmata augstskolām / Red. . –Kirovs: “ASA”, 2004. Koļemajevs - matemātiskā modelēšana. Makroekonomisko procesu un sistēmu modelēšana: mācību grāmata. M.: VIENOTĪBA-DANA, 2005. Bažin kibernētika. Harkova: Consul, 2004. Leušina seminārs par matemātiskās modelēšanas metodēm: mācību grāmata. Ņižņijnovgorodas štats tech. universitāte - N. Novorod, 2007. Politiķi par ekonomiku: Nobela prēmijas laureātu lekcijas ekonomikā. M.: Mūsdienu ekonomika un tiesības, 2005. Čeremnihs. Padziļinātais līmenis: Mācību grāmata.-M.:INFRA-M, 2008. Mini-ekonomikas institūciju evolūcija. Krievijas Zinātņu akadēmijas Urālu filiāles Ekonomikas institūts, - M.: Nauka, 2007.

Tehnoloģijas izstrādei un vadības lēmumu pieņemšanai [N]

Lēmumu pieņemšana kā vadītāja darbības pamats. Ievads lēmumu teorijā. Lēmumu teorijas pamatjēdzieni. Uzņēmējdarbības vadības modeļi un to ietekme uz lēmumu pieņemšanu. Dažādi veidi risinājumu klasifikācija. Klasifikācijas: pēc formalitātes pakāpes, pēc rutīnas pakāpes, pēc biežuma, pēc steidzamības, pēc mērķu sasniegšanas pakāpes, pēc alternatīvas izvēles metodes. Lēmumu pieņemšanas pamatmetodes. Brīvprātīgas lēmumu pieņemšanas metodes. Lēmumu pieņemšanas mērķi. Risinājumu meklēšanas laiks. Pamatkļūdas Lēmumu pieņemšanas matemātiskās metodes. Lēmumu teorijas matemātiskie aspekti. Operāciju izpēte. Matemātiskā pieeja lēmumu pieņemšanai. Lēmumu koks. Attīstības un lēmumu pieņemšanas modeļi. Spēļu teorija. Lēmumu pieņemšanas matemātiskās metodes. Lēmumu teorijas matemātiskie aspekti. Rindas teorijas modeļi. Krājumu pārvaldības modeļi. Lineārās programmēšanas modelis. Transporta uzdevumi. Simulācijas modelēšana. Tīkla analīze. Ekonomiskā analīze. Racionālo modeļu ierobežojumi. Attīstības un lēmumu pieņemšanas iezīmes grupā. Metode grupu kohēzijas noteikšanai, pamatojoties uz kopu savienojamības pakāpi. Kolektīvu lēmumu pieņemšanas metodes. Vienprātības metode. Balsošanas metodes. Radošas lēmumu pieņemšanas metodes. Prāta vētra. Ideju konference. Kuģa padome. De Bono "Domājošo cepuru" metode. Izgudrojuma problēmu risināšanas teorija (TRIZ). Ideāls gala risinājums. Problēmu un to risinājumu piemēri, izmantojot TRIZ. TRIZ metožu pielietošana, pieņemot unikālus un radošus lēmumus. Metodes risinājuma ideju izstrādei un pielāgošanai situācijai. Mērķa koka modelis. Interešu saskaņošanas stratēģija. Interešu saskaņošanas lēmumu veidošana. Darījuma partneru interešu noteikšanas metodes. Lēmumu atbalsta sistēmas (ekspertu sistēmas). Lēmumu pieņemšanas sistēmu izveides vēsture. Lēmumu pieņemšanas sistēmu klasifikācija. Tipiska struktūra ekspertu sistēma. Zināšanu pasniegšanas metodes. Loģisko secinājumu metodes. Ekspertu sistēmu pielietošana praksē.

I. Lēmumu pieņemšanas teorija: mācību grāmata. - M.: Eksāmens, 2006. - 573 lpp. I. Lēmumu pieņemšana. Vadības lēmumu izstrādes teorija un metodes. Apmācība. - M.: MarT, 2005. - 496 lpp. Vadības lēmumu izstrāde - M.: Izdevniecība "Delo", 2004 - 392 lpp. G. Ekspertu vērtējumi un lēmumu pieņemšana - M.: Patents, 1996. - 271 lpp. Taha // Ievads operāciju izpētē = Operations Research: An Introduction. - 7. izd. - M.: “Viljamss”, 2007. - 549.-594.lpp. G. Theil. Ekonomiskās prognozes un lēmumu pieņemšana. M.: “Progress” 1970. K. D. Lūiss. Ekonomisko rādītāju prognozēšanas metodes. M.: “Finanses un statistika” 1986. G. S. Kildiševs, A. A. Frenkels. Laika rindu analīze un prognozēšana. M.: “Statistika” 1973. O. Kim, C. W. Muller, U. R. Klekka uc Faktoru, diskriminantu un klasteru analīze. M.: “Finanses un statistika” 1989. Efektīvs vadītājs. 3. grāmata. Lēmumu pieņemšana. – MIM LINK, 1999 Turevskis un autotransporta uzņēmuma vadība. - M.: Augstskola, 2005. , ; rediģēja . Sistēmas analīze pārvaldībā: pamācība. – M.: Finanses un statistika, 2006. , Tinkovs: mācību grāmata. – M.: KNORUS, 2006. gads.

Biznesa procesu modelēšana integrētās vadības sistēmās

Pēc kādiem principiem izšķir biznesa procesus? Kāda ir biznesa procesu holistiska apraksta problēma? Kas ir sistēma, kādas īpašības tai piemīt? Sistēmu analīzes loma biznesa procesu modelēšanā? Process kā kontroles objekts. Procesa vide. Biznesa procesa pamatelementi. Funkcionālās un procesu vadības priekšrocības un trūkumi. PDCA pārvaldības cikls. Procesa vadības cikla posmi. PDCA cikls un ISO 9001:2008 prasību ieviešana. SADT metodoloģija (Structured Analysis and Design Technique – strukturālās analīzes un projektēšanas metode). Esence. Pamatnoteikumi. Kā IDEF0 metodoloģijā tiek attēlots darbības funkcionālais modelis? Ko nozīmē darbības funkcionālo modeļu diagrammās, kā tās tiek attēlotas pēc IDEF0 metodoloģijas? Kam domātas bultiņas funkcionālo modeļu diagrammās, kādi ir to veidi un veidi? DFD metodoloģija. Esence. DFD diagrammu pamatkomponenti. Kādas ir DFD diagrammu iezīmes un kas tajās ir aprakstīts? Kādas ir DFD diagrammu objektu iezīmes? Ko nozīmē bultiņas DFD diagrammā? IDEF3 metodoloģija. Esence. Dokumentācijas un modelēšanas rīki. Kādas ir IDEF3 diagrammu iezīmes un kas tajās ir aprakstīts? Kādas ir IDEF3 diagrammas objektu iezīmes? Un šāvējs? Procesu klasifikācija. Tipiski biznesa procesi. Pārveidošana un tās tehnoloģija. Kad, vadot uzņēmumu, ir ieteicams izmantot reinženieru? Monitoringa un mērīšanas procesi. Organizatorisko procesu rādītāji. Procesu skaitliskais un reitingu novērtējums.

"Biznesa procesu modelēšana ar AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Informācijas sistēmu izveide ar AllFusion Modeling Suite" ed. "Dialog-MEPhI" 2003 "Funkcionālās modelēšanas prakse ar AllFusion Process Modeler 4.1. (BPwin) Kur? Kāpēc? Kā?" ed. "Dialogue-MEPhI" 2004 Dubeikovska modelēšana ar AllFusion Process Modeler (BPwin). ed. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Strukturālās analīzes un dizaina metodoloģija SADT" 1993. gads klasisks darbs par SADT metodoloģiju. Cheremnykh sistēmu analīze: IDEF-tehnoloģijas, Sistēmu modelēšana un analīze. IDEF tehnoloģijas. Seminārs. M.: Finanses un statistika, 2001. “Uzņēmējdarbības strukturālie modeļi: DFD tehnoloģijas” http://www. /Level4.asp? ItemId=5810 "Uzņēmējdarbības procesu reorganizācijas teorija un prakse" 2003/ P50.1.. Funkcionālās modelēšanas metodika. M.: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Biznesa procesu modelēšana, izmantojot BPwin http://www. /department/se/devis/7/ IDEF0 biznesa vadības procesu modelēšanā http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Programmatūras produktu efektivitātes novērtēšana

1. IT arhitektūra

2. Vadības procesu jomas.

3. Procesu saraksts plānošanas un organizācijas jomā

4. Domēna procesu saraksts Iegūšana un ieviešana

5. Darbības un apkopes domēna procesu saraksts

6. Procesu saraksts uzraudzības un novērtēšanas jomā

7. Procesa brieduma modeļa līmeņu raksturojums

9. KPI un KGI to attiecības un mērķis

1. 10. Vispārējās IT vadīklas un lietojumprogrammu vadīklas. Biznesa un IT atbildības jomas un pienākumi.

Cobit 4.1 krievu izdevums.

Intelektuālā īpašuma radīšanas un izmantošanas tiesiskais regulējums

1. Uzskaitiet intelektuālās tiesības uz intelektuālās darbības rezultātiem un atklājiet to saturu.

2. Uzskaitiet ekskluzīvo tiesību atsavināšanas līgumu veidus. Aprakstiet katru no šiem līgumiem par ekskluzīvu tiesību atsavināšanu.

4. Aprakstiet Datorprogrammas kā autortiesību objekta tiesiskās aizsardzības galvenos noteikumus.

5. Salīdzināt Datu bāzes kā autortiesību objekta un kā blakustiesību objekta tiesiskās aizsardzības galvenos noteikumus.

6. Aprakstiet patenta tiesību objektu patentspējas nosacījumus: izgudrojumus; lietderības modeļi; rūpnieciskie dizaini.

7. Paplašināt izgudrojuma patentspējas kritēriju saturu: novitāte; izgudrojuma solis; rūpnieciskā pielietojamība.

8. Aprakstiet izgudrojuma, lietderības modeļa vai rūpnieciskā dizaina patenta iegūšanas nosacījumus un kārtību, kā arī patentu derīguma nodrošināšanas nosacījumus un to derīguma termiņus.

9. Definējiet “know-how” un uzskaitiet nosacījumus, kuru radīšanas laikā rodas un tiek veikta ražošanas noslēpumu tiesiskā aizsardzība.

10. Uzskaitiet aizsargājamos individualizācijas līdzekļus un norādiet to salīdzinošās īpašības.

1. Intelektuālā īpašuma tiesības Krievijas Federācija, mācību grāmata // M, Prospekts, 2007

2., Intelektuālā īpašuma tiesības, mācību grāmata // M, RIOR, 2009.

Projektu un programmatūras izstrādes vadība [I]

Kas ir metodoloģija, kāpēc tā ir vajadzīga. Metodoloģijas vispārīgā struktūra, galvenie metodoloģijas elementi. Principi savas metodikas izstrādei. Dažādu artefaktu, lomu, kompetenču, robežnosacījumu piemēri. Metodoloģijas struktūra pēc Cowburn, metodoloģijas metrika. Cowburn dizaina kritēriji. Metodoloģijas izvēles kritēriji, Cowburn matrica. Projekta dzīves cikls. Ūdenskritums un iteratīvie dzīves cikla modeļi. Piemērojamības ierobežojumi ūdenskritumiem un iteratīvajiem modeļiem. RUP kā iteratīvās metodoloģijas piemērs. RUP pamatjēdzieni, pielietojamības robežas. Cilvēka loma programmatūras izstrādē. Agilās metodoloģijas, veiklo metodoloģiju pamatprincipi. Elastīgu metodoloģiju rašanās iemesls. Scrum kā elastīgas metodoloģijas piemērs. Lomas, artefakti, aktivitātes Scrum. Scrum pielietojamības robežas. Extreme Programming (XP) Idejas, vērtības, pamatprakses, pielietojamības robežas. Līdzības un atšķirības starp Scrum un XP. Prasību apkopošana un pārvaldība. Pamatprakses, termini, principi. Projekta un produkta dokumentēšanas pieejas, galvenie dokumentu veidi. Prasību pārvaldības prakses piemēri no kursā apskatītajām metodoloģijām. Programmatūras izstrādes plānošana. Plānu veidi, risku vadība, populārie riski. Attīstības plānošanas prakses piemēri no kursā apskatītajām metodoloģijām. Testēšana programmatūras izstrādē. Programmatūras produkta montāžas (būvēšanas) jēdziens. Testēšanas pamatmetodes, termini. Testēšanas prakšu piemēri no kursā apskatītajām metodoloģijām. Montāžas (būvēšanas) jēdziens, koda glabāšanas metodes, instrumenti. Divi principi darba organizēšanai ar versiju kontroles sistēmu. Preču izlaišanas/izstādīšanas procesa iezīmes dažādām preču kategorijām, prakses piemēri. Mūsdienu programmatūras arhitektūras koncepcijas, daudzlīmeņu arhitektūras, arhitektūras kritēriji. Nepieciešamo lēmumu saraksts, izstrādājot programmatūru, pieejas datu uzglabāšanas sistēmas izvēlei.

Kents Beks — Ekstrēmā programmēšana Frederiks Brūks — Mītiskais cilvēka mēnesis jeb kā tiek radītas programmatūras sistēmas. Toms Demarko — termiņš. Romāns par projektu vadību. Toms De Marko, Timotijs Listers – Valsis ar lāčiem. Toms de Marko, Timotijs Listers - Cilvēciskais faktors_ veiksmīgi projekti un komandas. Alistair Cowburn – katram projektam ir sava metodoloģija. Alistair Cowburn - Cilvēki kā nelineāri un vissvarīgākie komponenti programmatūras izveidē. Andris Orlovs - automatizācijas inženiera piezīmes. Profesionāla atzīšanās. Filips Kračens – Ievads racionālajā vienotajā procesā. Henriks Knibergs - Scrum un XP: piezīmes no priekšējām līnijām. Kursa lekciju prezentācijas

Populārs kategorijā: