Hem › Multimedia › Tillvägagångssätt för mjukvaruutveckling. Ett strukturerat förhållningssätt till mjukvaruutveckling. Principer och betydelse för agil utveckling

Tillvägagångssätt för mjukvaruutveckling. Ett strukturerat förhållningssätt till mjukvaruutveckling. Principer och betydelse för agil utveckling

1.Kodning

På programvaruutvecklingsstadiet utförs följande huvudåtgärder: kodning; testning; utveckling av ett PP-hjälpsystem; skapande av användardokumentation; skapa en version och installation av programvara,

Kodning är processen att omvandla designresultat på hög och låg nivå till en färdig mjukvaruprodukt. Med andra ord, vid kodning beskrivs den kompilerade mjukvarumodellen med det valda programmeringsspråket, vilket kan vara vilket som helst av de befintliga språken. Valet av språk utförs antingen på begäran av kunden, eller med hänsyn till att problemet löses och personlig erfarenhet utvecklare.

Vid kodning måste du följa standarden för det valda språket, till exempel för C-språket är det ANSI C, och för C++ är det ISO/IEC 14882 "Standard for the C++ ProgrammingLanguage".

Utöver den allmänt accepterade standarden för ett programmeringsspråk kan ett företag även ta fram egna tilläggskrav för reglerna för att skriva program. De gäller främst reglerna för formatering av programtext.

Genom att följa standarden och företagets regler kan du skapa ett program som fungerar korrekt, är lätt att läsa och förståeligt för andra utvecklare, innehållande information om utvecklaren, skapandedatum, namn och syfte, samt nödvändig data för konfigurationshantering.

I kodningsstadiet skriver programmeraren program och testar dem själv. Denna typ av testning kallas enhetstestning. Alla frågor relaterade till mjukvarutestning diskuteras i kapitel. 10 beskrivs också testtekniken som används i utvecklingsstadiet för programvara. Denna teknik kallas testning "glaslåda" (glaslåda); ibland kallas det även testning "vit låda" (vit låda) i motsats till det klassiska konceptet med en "svart låda".

I black box-testning behandlas ett program som ett objekt vars interna struktur är okänd. Testaren lägger in data och analyserar resultatet, men han vet inte exakt hur programmet fungerar. När man väljer tester letar en specialist efter indata och förhållanden som är intressanta ur hans synvinkel, vilket kan leda till icke-standardiserade resultat. Han är främst intresserad av de representanter för varje klass av indata där fel i det testade programmet är mest sannolikt att uppstå.

När man testar en "glaslåda" är situationen en helt annan. Testaren (i detta fall programmeraren själv) utvecklar tester baserade på kunskap om källkoden som han har tillgång till full tillgång. Som ett resultat får han följande förmåner.

1. Testriktning. Programmeraren kan testa programmet i delar, utveckla speciella testsubrutiner som anropar modulen som testas och överför data av intresse för programmeraren till den. Det är mycket lättare att testa en separat modul som en "glaslåda".

2.Full kodtäckning. Programmeraren kan alltid avgöra vilka kodfragment som fungerar i varje test. Han ser vilka andra grenar av koden som förblir oprövade och kan välja de förhållanden under vilka de ska testas. Nedan beskriver vi hur man spårar graden av kodtäckning för de utförda testerna.

3. Förmåga att kontrollera flödet av kommandon. Programmeraren vet alltid vilken funktion som ska köras härnäst i programmet och vad dess nuvarande tillstånd ska vara. För att ta reda på om ett program fungerar som han tror kan en programmerare inkludera felsökningskommandon som visar information om dess exekvering, eller använda ett speciellt program för att göra detta. programvara kallas en debugger. Debuggern kan göra många användbara saker: övervaka och ändra sekvensen för exekvering av programkommandon, visa innehållet i dess variabler och deras adresser i minnet, etc.

4. Förmåga att övervaka dataintegritet. Programmeraren vet vilken del av programmet som ska ändra varje dataelement. Genom att övervaka datatillståndet (med samma debugger) kan han identifiera fel som att data ändras av fel moduler, deras felaktiga tolkning eller misslyckad organisation Programmeraren kan automatisera testningen själv.

5.Vision av inre gränspunkter. I källkod de gränspunkter för programmet som är dolda från utsidan är synliga. Till exempel kan flera helt olika algoritmer användas för att utföra en viss åtgärd, och utan att titta på koden är det omöjligt att avgöra vilken programmeraren valde. Ett annat vanligt exempel skulle vara ett spillproblem i en buffert som används för att tillfälligt lagra indata. Programmeraren kan omedelbart berätta vid vilken mängd data bufferten kommer att svämma över, och han behöver inte utföra tusentals tester.

6. Möjlighet till testning bestäms av den valda algoritmen. Att testa databehandling som använder mycket komplexa beräkningsalgoritmer kan kräva speciell teknik. Klassiska exempel inkluderar matristransformation och datasortering. En testare, till skillnad från en programmerare, behöver veta exakt vilka algoritmer som används, så han måste vända sig till specialiserad litteratur.

Glasboxtestning är en del av programmeringsprocessen. Programmerare gör det här arbetet hela tiden, de testar varje modul efter att ha skrivit den och sedan igen efter att ha integrerat den i systemet.

När du utför enhetstestning kan du använda antingen strukturell eller funktionell testteknik, eller båda.

Strukturell testning är en typ av glasboxtestning. Dess huvudidé är det korrekta valet av mjukvaruvägen som ska testas. I motsats till honom funktionell testning faller i kategorin black box-testning. Varje programfunktion testas genom att mata in dess indata och analysera dess utdata. Samtidigt tar man mycket sällan hänsyn till programmets interna struktur.

Även om strukturella tester är mycket kraftfullare teoretisk grund, de flesta testare föredrar funktionstestning. Strukturella tester lämpar sig bättre för matematisk modellering, men det betyder inte att det är mer effektivt. Varje teknik låter dig identifiera missade fel när du använder den andra. Ur denna synvinkel kan de kallas lika effektiva.

Målet för testning kan inte bara vara fullständig sökväg program (sekvensen av kommandon som det kör från start till slut), men också dess individuella sektioner. Det är absolut orealistiskt att testa alla möjliga sätt att köra ett program. Därför identifierar testspecialister från alla möjliga vägar de grupper som absolut behöver testas. För urval använder de speciella kriterier som kallas täckningskriterier (täckningskriterier), som bestämmer ett mycket reellt (även om ganska stort) antal tester. Dessa kriterier kallas ibland logiska täckningskriterier, eller fullständighetskriterier.

3. Utveckling av hjälpsystem mjukvaruprodukt. Skapa användardokumentation

Det är lämpligt att utse en av projektanställda som teknisk redaktör för dokumentationen. Denna medarbetare kan även utföra annat arbete, men hans huvuduppgift bör vara analys av dokumentation, även om andra anställda också utvecklar den.

Det händer ofta att flera personer arbetar med att skapa mjukvara, men ingen av dem bär det fulla ansvaret för dess kvalitet. Som ett resultat drar programvaran inte bara nytta av det faktum att den utvecklas av fler människor, utan förlorar också, eftersom var och en undermedvetet flyttar ansvaret till den andra och förväntar sig att hans kollegor kommer att göra den eller den delen av arbetet. Detta problem löses genom att utse en redaktör som bär det fulla ansvaret för kvaliteten och riktigheten i den tekniska dokumentationen.

PP-hjälpsystemet bildas utifrån det material som tagits fram till användarmanualen. Den bildas och skapas av den som är ansvarig för att utföra detta arbete. Det kan vara antingen en teknisk redaktör eller en av utvecklarna tillsammans med den tekniska redaktören.

En väldokumenterad PP har följande fördelar.

1. Lätt att använda. Om programvaran är väldokumenterad är den mycket lättare att applicera. Användare lär sig det snabbare, gör färre misstag och gör som ett resultat sitt arbete snabbare och mer effektivt.

2. Lägre kostnad teknisk support. När användaren inte kan komma på hur han ska utföra de åtgärder han behöver ringer han PCB-tillverkarens tekniska supporttjänst. Att driva en sådan tjänst är mycket dyrt. En bra manual hjälper användare att lösa problem på egen hand och minska behovet av att kontakta det tekniska supportteamet.

3. Hög tillförlitlighet. Obegriplig eller slarvig dokumentation gör programvaran mindre tillförlitlig, eftersom dess användare är mer benägna att göra misstag och har svårt att förstå vad som orsakade dem och hur de ska hantera deras konsekvenser.

Enkelt underhåll. En enorm mängd pengar och tid läggs på att analysera problem som orsakas av användarfel. Ändringar som görs i nya programversioner är ofta helt enkelt ändringar i gränssnittet för gamla funktioner. De introduceras så att användare äntligen kommer på hur de ska använda programvaran och slutar ringa teknisk support. Bra förvaltning i hög grad

Datavetenskap, cybernetik och programmering

Iteration N Unified Development Process programvara USDP Use Case Model beskriver de fall där applikationen kommer att användas. Den analytiska modellen beskriver basklasserna för applikationen. Designmodellen beskriver kopplingar och relationer mellan klasser och tilldelade objekt, och distributionsmodellen beskriver distributionen av programvara över datorer.

Lektion nr 20
Allmänna principer och tillvägagångssätt för mjukvaruutveckling

Modeller för mjukvaruutveckling

Vodopadnaya
Cascade modell
Spiral
Extrem programmering
Inkrementell
Läkare Utan Gränsers metodik

Vattenfall modell

Spiral modell

Inkrementell utveckling

Kravanalys

Design

Genomförande

Komponent

testning

Integration

Testning

en hel

Upprepning 1 Upprepning 2…. Iteration N

Unified Software Development Process (USDP)

Use case-modellen beskriver i vilka fall applikationen kommer att användas.
Den analytiska modellen beskriver basklasserna för applikationen.
Designmodellen beskriver sambanden och relationerna mellan klasser och utvalda objekt
Implementeringsmodellen beskriver distributionen av programvara mellan datorer.
Implementeringsmodellen beskriver programkodens interna organisation.
En testmodell består av testkomponenter, testprocedurer och olika testfall.

Läkare Utan Gränsers metodik

Typiska programoch typiska programvarukrav

feltoleransen uppsättning systemegenskaper som ökar dess tillförlitlighet genom att upptäcka fel, återställa och lokalisera dåliga konsekvenser för systemet. När man designar ett riktigt system för att säkerställa feltolerans är det nödvändigt att ta hänsyn till alla möjliga situationer som kan leda till systemfel och utveckla mekanismer för att hantera fel.

Pålitlighet systemets förmåga att motstå olika fel och fel.

Vägran detta är en systemövergångsom ett resultat av felet till ett helt inoperabelt tillstånd.

Krascha ett fel i systemets funktion som inte leder till systemfel.

Ju färre fel och fel under en viss tidsperiod, desto mer tillförlitligt anses systemet.

Samt andra verk som kan intressera dig
57355.		Olika organiska föreningar, deras klassificering. Organiska ämnen av levande natur	48,5 kB
	Mångfalden av organiska föreningar bestäms av den unika förmågan hos kolatomer att ansluta med varandra genom enkla och multipla bindningar för att bilda föreningar med ett nästan obegränsat antal atomer kopplade i kedjor: cykler, cyklar, trehjulingar, polycyklar, ramverk, etc.
57359.		Bearbetning av verbala informationsmodeller	291 KB
	Grundläggande begrepp: modell; informationsmodell; verbal informationsmodell; anteckning; abstrakt. Synopsis Synopsis från lat. Skapa en anteckning för 2. Spara dokumentet i en egen mapp under namnet Anteckning.
57361.		Nummer och figur 3. Justera siffror vid gränser 3. Skriva siffror 3. Justera antalet objekt	35,5 kB
	Hur många varelser finns det Vem rankas först Vem rankas sist Vem rankas som nummer 1 Vem rankas som nummer 2 Namnge igelkottens grannar. Vem är den högerhänta ekorren Vem är den vänsterhänta giraffen Vem är störst Vem är minst Vem står i mitten av varelserna Gra Visa mig, ha inte nåd.

Idag inom mjukvaruteknik finns det två huvudsakliga tillvägagångssätt för utveckling av EIS-mjukvara, den grundläggande skillnaden mellan vilka beror på olika sätt nedbrytning av system. Den första metoden kallas funktionell-modulär eller strukturell. Den är baserad på principen om funktionell nedbrytning, där systemets struktur beskrivs i termer av hierarkin av dess funktioner och överföring av information mellan individer funktionella element. Det andra, objektorienterade tillvägagångssättet använder objektnedbrytning. I detta fall beskrivs systemets struktur i termer av objekt och kopplingar mellan dem, och systemets beteende beskrivs i termer av utbyte av meddelanden mellan objekt.

Så kärnan i det strukturella tillvägagångssättet för EIS-mjukvaruutveckling ligger i dess nedbrytning (nedbrytning) i automatiserade funktioner: systemet är uppdelat i funktionella delsystem, som i sin tur är uppdelade i underfunktioner, de i uppgifter, och så vidare ner till särskilda förfaranden. Samtidigt upprätthåller det automatiserade systemet en helhetssyn där alla komponenter är sammankopplade. När man utvecklar ett system "bottom up", från enskilda uppgifter till hela systemet, går integriteten förlorad, problem uppstår vid beskrivning informationsinteraktion enskilda komponenter.

Alla de vanligaste metoderna för det strukturella tillvägagångssättet bygger på ett antal allmänna principer. De grundläggande principerna är:

principen om "dela och härska" (se underavsnitt 2.1.1);

principen om hierarkisk ordning är principen att organisera komponenterna i ett system i hierarkiska trädstrukturer med tillägg av nya detaljer på varje nivå.

Att lyfta fram två grundläggande principer betyder inte att de återstående principerna är sekundära, eftersom att ignorera någon av dem kan leda till oförutsägbara konsekvenser (inklusive att hela projektet misslyckas). De viktigaste av dessa principer är:

abstraktionsprincipen - lyfta fram de väsentliga aspekterna av systemet och abstrahera från det oviktiga;

principen om konsekvens - giltighet och konsistens av systemelement;

principen för datastrukturering - data måste vara strukturerade och hierarkiskt organiserade.

Det strukturella tillvägagångssättet använder huvudsakligen två grupper av verktyg som beskriver systemets funktionella struktur och relationerna mellan data. Varje grupp av verktyg motsvarar vissa typer av modeller (diagram), av vilka de vanligaste är:

DFD (Data Flow Diagrams) - dataflödesdiagram;

SADT (Structured Analysis and Design Technique - metod för strukturanalys och design) - modeller och motsvarande funktionsdiagram;

ERD (Entity-Relationship Diagrams) - diagram över entitetsrelationer.

Dataflödesdiagram och entitetsrelationsdiagram är de vanligaste typerna av modeller i CASE-verktyg.

Specifik vy av de listade diagrammen och tolkningen av deras design beror på stadiet i mjukvarans livscykel.

I stadiet för att skapa mjukvarukrav, används SADT-modeller och DFD för att bygga "AS-IS"-modellen och "TO-BE"-modellen, vilket återspeglar den befintliga och föreslagna strukturen för organisationens affärsprocesser och interaktionen mellan dem ( användning av SADT-modeller är som regel begränsade till endast detta stadium, eftersom de inte ursprungligen var avsedda för mjukvarudesign). Med hjälp av ERD genomförs en beskrivning av den data som används i organisationen på en konceptuell nivå, oberoende av databasimplementeringsverktygen (DBMS).

På designstadiet används DFD:er för att beskriva strukturen i det designade mjukvarusystemet, och de kan förfinas, utökas och kompletteras med nya konstruktioner. På liknande sätt förfinas ERD och kompletteras med nya konstruktioner som beskriver representationen av data på en logisk nivå som lämpar sig för efterföljande generering av ett databasschema. Dessa modeller kan kompletteras med diagram som återspeglar mjukvarusystemets arkitektur, programblockdiagram, hierarki skärmformulär och meny osv.

De listade modellerna ger tillsammans en komplett beskrivning av EIS-programvara, oavsett om systemet är befintligt eller nyutvecklat. Sammansättningen av diagrammen i varje specifikt fall beror på systemets komplexitet och den nödvändiga fullständigheten av dess beskrivning.

Ämnesområdet för de flesta av diagramexemplen som ges i detta kapitel är Ryska federationens skattesystem, vars mest fullständiga beskrivning finns i Ryska federationens skattelag. Informationsteknologi, som används i Ryska federationens skattesystem, har vissa funktioner.

Så kärnan i det strukturella tillvägagångssättet för EIS-mjukvaruutveckling ligger i dess nedbrytning (nedbrytning) i automatiserade funktioner: systemet är uppdelat i funktionella delsystem, som i sin tur är uppdelade i underfunktioner, de i uppgifter, och så vidare ner till särskilda förfaranden. Samtidigt har systemet en helhetssyn där alla komponenter är sammankopplade. När man utvecklar ett system "bottom-up", från enskilda uppgifter till hela systemet, går integriteten förlorad och problem uppstår när man beskriver informationsinteraktionen mellan enskilda komponenter.

Alla de vanligaste metoderna för det strukturella tillvägagångssättet är baserade på ett antal allmänna principer:

1. Principen om "dela och härska";

2. Principen för hierarkisk ordning är principen att organisera komponenterna i ett system i hierarkiska trädstrukturer med tillägg av nya detaljer på varje nivå.

Att isolera två grundläggande principer betyder inte att de återstående principerna är sekundära, eftersom ignorera någon av dem kan leda till oförutsägbara konsekvenser (inklusive misslyckande av hela projektet"). De viktigaste av dessa principer är:

1. Abstraktionsprincipen - att lyfta fram de väsentliga aspekterna av systemet och abstrahera från det oviktiga.

2. Principen om konsistens, giltighet och konsekvens av systemelement.

3. Struktureringsprincip data - data måste vara strukturerad och hierarkiskt organiserad.

I det strukturella angreppssättet finns det främst två grupper av verktyg som beskriver systemets funktionella struktur och relationerna mellan data. Varje grupp av verktyg motsvarar vissa typer av modeller (diagram), de vanligaste bland dem är:

· DFD (Data Flow Diagrams) - dataflödesdiagram;

· SADT (Structured Analysis and Design Technique - metodik för strukturanalys och design) - modeller och motsvarande funktionsdiagram: notationer IDEF0 (funktionell modellering av system), IDEF1х (konceptuell modellering av databaser), IDEF3х (konstruktion av system för att bedöma kvaliteten på ett föremåls arbete; grafisk beskrivning flöde av processer, interaktion mellan processer och objekt som förändras av dessa processer);

· ERD (Entity - Relationship Diagrams) - Entity-relationship diagrams.

Nästan alla metoder för det strukturella tillvägagångssättet (strukturell analys) i stadiet för att skapa programvarukrav använder två grupper av modelleringsverktyg:

1. Diagram som illustrerar de funktioner som systemet måste utföra och relationerna mellan dessa funktioner - DFD eller SADT (IDEF0).

2. Diagram som modellerar data och deras samband (ERD).

Den specifika formen för de listade diagrammen och tolkningen av deras design beror på stadiet i mjukvarans livscykel.

I stadiet för att skapa mjukvarukrav, används SADT-modeller och DFD för att bygga "AS-IS"-modellen och "TO-BE"-modellen, vilket återspeglar den befintliga och föreslagna strukturen för organisationens affärsprocesser och interaktionen mellan dem ( användningen av SADT-modeller som vanligtvis endast är begränsade till detta stadium, eftersom de inte ursprungligen var avsedda för mjukvarudesign). Med hjälp av ERD genomförs en beskrivning av den data som används i organisationen på konceptuell nivå, oavsett databasimplementeringsverktygen (DBMS).

1. Syfte med programmeringsteknik. Historien om utvecklingen av programmeringsteknik. Typer av mjukvaruprojekt. Komponenter i programmeringsteknik. Projekt, produkt, process och människor

2. Programlivscykel. Utvecklingens cykliska karaktär. Grundläggande begrepp inom programmeringsteknik. Processer och modeller. Faser och svängar. Milstolpar och artefakter. Intressenter och anställda.

3. Identifiering och analys av krav. Programvarukrav. Flödesschema för kravutveckling. Kravhantering.

4. Arkitektonisk och detaljutformning. Implementering och kodning. Testning och verifiering. Kvalitetskontrollprocess. White box och black box metoder. Besiktningar och granskningar. Testa mål. Verifiering, validering och systemtestning. Underhåll och löpande utveckling.

5. Modeller av utvecklingsprocessen. Vattenfall och transportör modeller. Spiral- och inkrementella modeller. Flexibla utvecklingsprocessmodeller.

6. Konstruktion av en processmodell. Identifiera processkrav. Faser, milstolpar och artefakter som används. Att välja en processarkitektur. Procedur för att genomföra ett standardprojekt. Dokumenterade rutiner.

7. Utvecklingsteammodeller. Utvecklingens kollektiva karaktär. Optimal lagstorlek. Underordning av projektdeltagare. Teamutveckling och personalutveckling. Specialisering, samarbete och interaktion.

8. Modeller för utvecklingsteam. Hierarkisk lagmodell. Kirurgisk teammetod. Peer team modell.

9. Programmeringens natur. Vetenskapen om programmering. Konsten att programmera. Hantverket att programmera. Programmeringsparadigm. Strukturerad programmering. Logisk programmering. Objektorienterad programmering.

10. Mjukvaruarkitektur. Händelsehantering. Klient/serverarkitektur. Tjänster. Tre-lagers arkitektur. Programdesign. Konceptdesign. Logisk design. Detaljerad design.

1. Novikovs metoder för mjukvaruutveckling" http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Extrem programmering. – St Petersburg: Peter, 2002.

3. Teknik för mjukvaruutveckling. - St. Petersburg. : Peter, 2004.

4. Brooks Jr. är designade och skapade mjukvarusystem. M.: Nauka, 1975; ny upplaga av översättningen: The Mythical Man-Month. SPb.: SYMBOL+, 1999.

5. Algoritmer + datastrukturer = program. M., Mir, 1978.

6. Systematisk programmering. Introduktion. M.: Mir, 1977.

7. Strukturerad programmering. M.: Mir, 1975.

8. Programmeringsdisciplin. M.: Mir, 1978.

9. Teknik för mjukvaruutveckling. – St Petersburg: Peter, 2002.

10. Terekhov programmering. M.: BINOM, 2006.

11. Rambo J. Unified mjukvaruutvecklingsprocess. St Petersburg: Peter, 2002.

Ekonomisk teori för chefer

Grundläggande mikroekonomiska teorier. Exempel på tillämpning vid analys av ekonomiska processer. Grundläggande makroekonomiska teorier. Exempel på tillämpning vid analys av ekonomiska processer. Principer och metoder för att hantera ekonomiska processer. Verktyg för att bedöma utvecklingsnivån för ekonomiska processer Problem med utökad reproduktion. Faktorer för ekonomisk tillväxt i den ryska ekonomin. Kriterier och indikatorer för hållbar utveckling. Utjämna konjunktursvängningar. Multiplikatorns och acceleratorns roll för att bedöma takten i den ekonomiska utvecklingen. Produktionsfunktioner inom ekonomi. Exempel på tillämpning vid analys av ekonomiska processer. Vinst. Beräkning av indikatorer som påverkar vinsten, grafisk bild brytpunkt. Metodik för att implementera investeringspolicy.

Kurs i ekonomisk teori: lärobok för universitet / Ed. . –Kirov: “ASA”, 2004. Kolemaev - matematisk modellering. Modellering av makroekonomiska processer och system: lärobok. M.: UNITY-DANA, 2005. Bazhin cybernetics. Kharkov: Consul, 2004. Leushin workshop om metoder för matematisk modellering: lärobok. Nizhny Novgorod delstaten tech. univ. - N. Novorod, 2007. Politiker om ekonomi: Föreläsningar av Nobelpristagare i ekonomi. M.: Modern ekonomi och juridik, 2005. Cheremnykh. Avancerad nivå: Lärobok.-M.:INFRA-M, 2008. Evolution of mini-economy institutions. Institutet för ekonomi, Ural-grenen av Ryska vetenskapsakademin, - M.: Nauka, 2007.

Teknik för utveckling och beslutsfattande inom förvaltning [N]

Beslutsfattande som grund för en chefs verksamhet. Introduktion till beslutsteori. Grundläggande begrepp inom beslutsteori. Företagsledningsmodeller och deras inverkan på beslutsfattande. Olika sätt klassificering av lösningar. Klassificeringar: enligt graden av formalitet, enligt graden av rutin, enligt frekvens, enligt brådska, enligt graden av uppnående av mål, enligt metoden för att välja ett alternativ. Grundläggande metoder för beslutsfattande. Frivilliga metoder för beslutsfattande. Mål för beslutsfattande. Tid när man letar efter lösningar. Grundläggande misstag Matematiska metoder för beslutsfattande. Matematiska aspekter av beslutsteori. Operationsforskning. Matematiskt förhållningssätt till beslutsfattande. Beslutsträd. Modeller för utveckling och beslutsfattande. Spel teori. Matematiska metoder för beslutsfattande. Matematiska aspekter av beslutsteori. Modeller av köteori. Lagerhanteringsmodeller. Linjär programmeringsmodell. Transportuppgifter. Simuleringsmodellering. Nätverksanalys. Ekonomisk analys. Begränsningar av rationella modeller. Drag av utveckling och beslutsfattande i en grupp. En metod för att bestämma gruppsammanhållning baserat på graden av anslutning av uppsättningar. Metoder för att fatta kollektiva beslut. Konsensusmetod. Röstningsmetoder. Kreativa metoder för beslutsfattande. Spåna. Idékonferens. Skeppsråd. De Bonos "Thinking Hats"-metod. Teori om uppfinningsrik problemlösning (TRIZ). Den perfekta slutlösningen. Exempel på problem och deras lösningar med hjälp av TRIZ. Tillämpning av TRIZ-metoder vid unika och kreativa beslut. Metoder för att utveckla lösningsidéer och anpassa dem till situationen. Målträdsmodell. Strategi för samordning av intressen. Bildande av beslut för att samordna intressen. Metoder för att fastställa motparternas intressen. Beslutsstödssystem (expertsystem). Historien om skapandet av beslutssystem. Klassificering av beslutssystem. Typisk struktur expertsystem. Metoder för att presentera kunskap. Metoder för logisk slutledning. Tillämpning av expertsystem i praktiken.

I. Beslutsfattande teori: Lärobok. - M.: Examen, 2006. - 573 sid. I. Beslutsfattande. Teori och metoder för att ta fram ledningsbeslut. Handledning. - M.: MarT, 2005. - 496 s. Utveckling av ledningsbeslut - M.: Publishing House "Delo", 2004 - 392 s. G. Expertbedömningar och beslutsfattande - M.: Patent, 1996. - 271 sid. Taha // Introduction to Operations Research = Operations Research: An Introduction. - 7:e uppl. - M.: "Williams", 2007. - S. 549-594. G. Theil. Ekonomiska prognoser och beslutsfattande. M.: "Progress" 1970. K. D. Lewis. Metoder för att prognostisera ekonomiska indikatorer. M.: "Finans och statistik" 1986. G. S. Kildishev, A. A. Frenkel. Tidsserieanalys och prognoser. M.: ”Statistik” 1973. O. Kim, C. W. Muller, U. R. Klekka m.fl. Faktor-, diskriminant- och klusteranalys. M.: ”Finans och statistik” 1989. Effektiv chef. Bok 3. Beslutsfattande. – MIM LINK, 1999 Turevsky och ledning av ett motortransportföretag. - M.: Högre skola, 2005. , ; redigerad av . Systemanalys inom förvaltning: handledning. – M.: Finans och statistik, 2006. , Tinkov: lärobok. – M.: KNORUS, 2006.

Modellering av affärsprocesser i integrerade ledningssystem

Genom vilka principer kännetecknas affärsprocesser? Vad är problemet med en holistisk beskrivning av affärsprocesser? Vad är ett system, vilka egenskaper har det? Systemanalysens roll i affärsprocessmodellering? Process som ett kontrollobjekt. Processmiljö. Grundläggande element i en affärsprocess. För- och nackdelar med funktions- och processledning. PDCA-hanteringscykel. Stadier av processhanteringscykeln. PDCA-cykel och implementering av ISO 9001:2008 krav. SADT-metodik (Structured Analysis and Design Technique - metod för strukturanalys och design). Väsen. Grundläggande bestämmelser. Hur representeras den funktionella aktivitetsmodellen i IDEF0-metoden? Vad betyder aktiviteterna i funktionsmodelldiagrammen, hur visas de enligt IDEF0-metoden? Vad är pilarna i funktionsmodelldiagram för, vad är deras typer och typer? DFD metodik. Väsen. Grundläggande komponenter i DFD-diagram. Vilka egenskaper har DFD-diagram och vad beskrivs i dem? Vilka egenskaper har DFD-diagramobjekt? Vad betyder pilarna på ett DFD-diagram? IDEF3 metodik. Väsen. Dokumentations- och modelleringsverktyg. Vilka egenskaper har IDEF3-diagram och vad beskrivs i dem? Vilka egenskaper har IDEF3-diagramobjekt? Och skytten? Klassificering av processer. Typiska affärsprocesser. Reengineering och dess teknik. När är det lämpligt att använda reengineering när man leder ett företag? Övervakning och mätning av processer. Indikatorer för organisatoriska processer. Numeriska och betygsbedömningar av processer.

"Modellera affärsprocesser med AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Skapa informationssystem med AllFusion Modeling Suite" utg. "Dialog-MEPhI" 2003 "Övning av funktionell modellering med AllFusion Process Modeler 4.1. (BPwin) Var? Varför? Hur?" ed. "Dialogue-MEPhI" 2004 Dubeykovsky-modellering med AllFusion Process Modeler (BPwin). ed. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Methodology of structural analysis and design SADT" 1993 klassiskt arbete om SADT-metoden. Cheremnykh analys av system: IDEF-teknologier, Modellering och analys av system. IDEF-teknik. Verkstad. M.: Finans och statistik, 2001. "Strukturella affärsmodeller: DFD-teknologier" http://www. /Level4.asp? ItemId=5810 "Teori och praktik för omorganisation av affärsprocesser" 2003/ P50.1.. Funktionell modelleringsmetodik. M.: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Modellera affärsprocesser med hjälp av BPwin http://www. /avdelning/se/devis/7/ IDEF0 i modellering av affärsledningsprocesser http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Utvärdera effektiviteten av mjukvaruprodukter

1. IT-arkitektur

2. Domäner för förvaltningsprocesser.

3. Lista över processer i planerings- och organisationsdomänen

4. Lista över domänprocesser Acquisition and Implementation

5. Lista över processer i domänen Drift och underhåll

6. Lista över processer i övervaknings- och utvärderingsdomänen

7. Egenskaper för nivåerna i processmognadsmodellen

9. KPI och KGI deras relation och syfte

1. 10.Allmänna IT-kontroller och applikationskontroller. Ansvarsområden och ansvar för verksamhet och IT.

Cobit 4.1 rysk utgåva.

Rättslig reglering av skapandet och användningen av immateriella rättigheter

1. Lista de intellektuella rättigheterna till resultaten av intellektuell verksamhet och avslöja deras innehåll.

2. Lista typerna av avtal för förfogande över exklusiva rättigheter. Beskriv vart och ett av dessa avtal om förfogande över exklusiva rättigheter.

4. Beskriv de huvudsakliga bestämmelserna om rättsligt skydd för ett datorprogram som föremål för upphovsrätt.

5. Jämför de viktigaste bestämmelserna om rättsligt skydd av databasen som föremål för upphovsrätt och som föremål för närstående rättigheter.

6. Beskriv villkoren för patenterbarhet av patenträttsobjekt: uppfinningar; bruksmodeller; industriell design.

7. Utöka innehållet i patenterbarhetskriterierna för en uppfinning: nyhet; uppfinningssteg; industriell tillämplighet.

8. Beskriv villkoren och förfarandet för att erhålla patent på en uppfinning, bruksmodell eller industriell design samt villkoren för att säkerställa patentens giltighet och deras giltighetstid.

9. Definiera "know-how" och lista de villkor under skapandet av vilka rättsligt skydd av produktionshemligheter uppstår och genomförs.

10. Lista de skyddade medlen för individualisering och ange deras jämförande egenskaper.

1. Immateriella rättigheter i Ryska Federationen, lärobok // M, Prospekt, 2007

2., Immaterialrätt, lärobok // M, RIOR, 2009.

Projekt- och mjukvaruutvecklingshantering [I]

Vad är metodik, varför behövs det. Metodikens allmänna struktur, huvudelementen i metodiken. Principer för att utforma din egen metodik. Exempel på olika artefakter, roller, kompetenser, randvillkor. Metodikens struktur enligt Cowburn, metodikmått. Cowburns designkriterier. Kriterier för val av metodik, Cowburn-matris. Projektets livscykel. Vattenfall och iterativa livscykelmodeller. Tillämpningsgränser för vattenfall och iterativa modeller. RUP som exempel på iterativ metodik. Grundläggande begrepp för RUP, gränser för tillämplighet. Människans roll i mjukvaruutveckling. Agila metoder, grundläggande principer för agila metoder. Anledningen till uppkomsten av flexibla metoder. Scrum som exempel på flexibel metodik. Roller, artefakter, aktiviteter i Scrum. Scrum-tillämpningsgränser. Extreme Programmering (XP) Idéer, värderingar, grundläggande praxis, gränser för tillämplighet. Likheter och skillnader mellan Scrum och XP. Kravinsamling och hantering. Grundläggande praxis, termer, principer. Tillvägagångssätt för att dokumentera ett projekt och produkt, huvudtyper av dokument. Exempel på kravhanteringsmetoder från de metoder som diskuteras i kursen. Programvaruutvecklingsplanering. Typer av planer, riskhantering, populära risker. Exempel på utvecklingsplaneringsmetoder från de metoder som diskuteras i kursen. Tester inom mjukvaruutveckling. Konceptet med montering (bygge) av en mjukvaruprodukt. Grundläggande testmetoder, termer. Exempel på testpraxis från de metoder som diskuteras i kursen. Konceptet för montering (bygga), metoder för att lagra kod, verktyg. Två principer för att organisera arbetet med ett versionskontrollsystem. Funktioner i produktsläpp-/visningsprocessen för olika produktkategorier, exempel på metoder. Moderna koncept för mjukvaruarkitektur, flernivåarkitekturer, arkitekturkriterier. Lista över nödvändiga beslut vid design av programvara, metoder för att välja ett datalagringssystem.

Kent Beck - Extrem programmering Frederick Brooks - The Mythical Man-Month eller hur mjukvarusystem skapas. Tom DeMarco - Deadline. En roman om projektledning. Tom De Marco, Timothy Lister - Waltzing with the Bears. Tom de Marco, Timothy Lister - Human factor_ framgångsrika projekt och team. Alistair Cowburn - Varje projekt har sin egen metodik. Alistair Cowburn - Människor som icke-linjära och de viktigaste komponenterna för att skapa mjukvara. Andriy Orlov - Anteckningar från en automationsingenjör. Professionell bekännelse. Philipp Kratchen - Introduktion till den rationella förenade processen. Henrik Kniberg - Scrum och XP: anteckningar från frontlinjerna. Presentationer av föreläsningar på kursen

Populär i kategorin: