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

2. Programmets livscykel. 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. Kravutvecklingsschema. Kravhantering.

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

5. Utvecklingsprocessmodeller. Vattenfall och transportör modeller. Spiral- och inkrementella modeller. Flexibla utvecklingsprocessmodeller.

6. Designa en processmodell. Identifiering av processkrav. Använda faser, milstolpar och artefakter. Val av processarkitektur. Proceduren för att genomföra ett typiskt projekt. dokumenterade rutiner.

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

8. Modeller av utvecklingsteamet. Hierarkisk lagmodell. Den kirurgiska teammetoden. Modell av ett lag av jämlikar.

9. Programmeringens natur. Vetenskap om programmering. Konsten att programmera. Hantverket att programmera. programmeringsparadigm. Strukturell programmering. Logisk programmering. Objektorienterad programmering.

10. Mjukvaruarkitektur. Händelsehantering. Klient/serverarkitektur. Tjänster. treskiktsarkitektur. 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. mjukvarusystem designas och skapas. Moskva: Nauka, 1975; ny översättningsupplaga: Mytisk man-månad. St Petersburg: 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. Tillämpningsexempel i analys av ekonomiska processer. Grundläggande makroekonomiska teorier. Tillämpningsexempel i 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ämning av cykliska fluktuationer. Multiplikatorns och acceleratorns roll för att bedöma takten i den ekonomiska utvecklingen. Produktionen fungerar i ekonomin. Tillämpningsexempel i analys av ekonomiska processer. Vinst. Beräkning av indikatorer som påverkar vinsten, grafisk representation av brytpunkten. Metodik för genomförande av investeringspolicy.

En kurs i ekonomisk teori: en lärobok för universitet / Ed. . -Kirov: "ACA", 2004. Kolemaev - matematisk modellering. Modellering av makroekonomiska processer och system: lärobok. M.: UNITY-DANA, 2005. Bazhin cybernetics. Charkiv: Consul, 2004. Leushin workshop om metoder för matematisk modellering: lärobok. Nizhny Novgorod delstaten tech. univ. - N. Novorod, 2007. Politiker om ekonomin: Föreläsningar av Nobelpristagare i ekonomi. Moskva: Modern Economics and Law, 2005. Cheremnykh. Avancerad nivå: Lärobok.-M.:INFRA-M, 2008. Utvecklingen av miniekonomiinstitutioner. Institutet för ekonomi vid den ryska vetenskapsakademins Ural-gren, - M.: Nauka, 2007.

Teknik för utveckling och antagande av ledningsbeslut [N]

Beslutsfattande är grunden för en chefs verksamhet. Introduktion till beslutsteori. Grundläggande begrepp inom beslutsteori. Företagsledningsmodeller och deras inverkan på beslutsfattande. Olika sätt att klassificera 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 beslutsmetoder. Frivilliga metoder för beslutsfattande. Mål för beslutsfattande. Dags att hitta lösningar. Grundläggande misstag Matematiska metoder för beslutsfattande. Matematiska aspekter av teorin om beslutsfattande. 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 teorin om beslutsfattande. Köteoretiska modeller. 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 sammankoppling av uppsättningar. Metoder för att fatta ett kollektivt beslut. konsensusmetoden. röstningsmetoder. Kreativa metoder för beslutsfattande. Spåna. Idékonferens. Fartygsrådet. The Mental Hats Method av de Bono. Teori om uppfinningsrik problemlösning (TRIZ). Den idealiska slutlösningen. Exempel på problem och deras lösning med hjälp av TRIZ. Tillämpning av TRIZ-metoder för att fatta unika och kreativa beslut. Metoder för att utveckla lösningsidéer och anpassa dem till situationen. Målträdmodell. Strategin för samordning av intressen. Bildande av beslut om samordning av intressen. Metoder för att fastställa motparternas intressen. Beslutsstödssystem (expertsystem). Historien om skapandet av beslutssystem. Klassificering av beslutssystem. Typisk struktur för ett expertsystem. Sätt att representera kunskap. Metoder för logisk slutledning. Tillämpning av expertsystem i praktiken.

I. Teori om beslutsfattande: lärobok. - M.: Examen, 2006. - 573 sid. I. Beslutsfattande. Teori och metoder för utveckling av ledningsbeslut. Handledning. - M.: Mars 2005. - 496 s. Utveckling av ett ledningsbeslut - M.: Delo Publishing House, 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, W. R. Klekka m.fl. Faktor-, diskriminant- och klusteranalys. M.: "Finans och statistik" 1989. Effektiv chef. Bok 3. Beslutsfattande. - MIM LINK, 1999 Turevsky och ledningen av ett motortransportföretag. - M .: Högre skola, 2005.,; ed. . Systemanalys i förvaltning: en handledning. - M .: Finans och statistik, 2006. , Tinkov: lärobok. – M.: KNORUS, 2006.

Modellering av affärsprocesser i integrerade ledningssystem

Vilka är principerna för affärsprocesser? Vad är problemet med en holistisk beskrivning av affärsprocesser. Vad är ett system, vilka egenskaper har det? Rollen av systemanalys 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 - en metod för strukturanalys och design). Väsen. Grundläggande bestämmelser. Hur presenteras den funktionella aktivitetsmodellen i IDEF0-metoden? Vad betyder verken i funktionsmodellens diagram, hur visas de enligt IDEF0-metoden? Vad är pilarna i funktionsmodelldiagrammen för, vad är deras typer och typer? DFD metodik. Väsen. Grundläggande komponenter i DFD-diagram. Vilka egenskaper har DFD-diagram, vad beskrivs i dem? Vilka egenskaper har DFD-diagramobjekt? Vad representerar pilarna på DFD-diagrammet? IDEF3 metodik. Väsen. Medel för dokumentation och modellering. Vilka egenskaper har IDEF3-diagram, vad beskriver de? 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 i ledningen av ett företag? Övervakning och mätning av processer. Indikatorer på organisationens processer. Numerisk och betygsutvärdering av processer.

"Modellera affärsprocesser med AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Skapa informationssystem med AllFusion Modeling Suite" utg. "Dialogue-MEPhI" 2003 "Utövandet av funktionell modellering med AllFusion Process Modeler 4.1. (BPwin) Var? Varför? Hur?" ed. "Dialogue-MEPhI" 2004 Dubeikovsky-modellering med AllFusion Process Modeler (BPwin). ed. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Metodik för strukturell analys och 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-technologies" http://www. /Level4.asp? ItemId=5810 "Teori och praktik för omorganisation av affärsprocesser"2003/ P50.1.. Funktionell modelleringsmetodik. Moskva: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Modellering av affärsprocesser med hjälp av BPwin http://www. /avdelning/se/devis/7/ IDEF0 inom affärsprocessmodellering http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Utvärdering av mjukvaruprodukters effektivitet

1. IT-arkitektur

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

3. Lista över processer för domänen Planering och organisation

4. Lista över domänprocesser Acquisition and Implementation

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

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

7. Karakterisering av 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 immateriella rättigheterna till resultaten av immateriella aktiviteter och avslöja deras innehåll.

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

4. Beskriv de viktigaste bestämmelserna för det rättsliga skyddet av datorprogrammet som ett föremål för upphovsrätt.

5. Jämför de viktigaste bestämmelserna i det rättsliga skyddet 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 för objekt med patenträttigheter: uppfinningar; användbara modeller; industriella prover.

7. Utöka innehållet i uppfinningens patenterbarhetskriterier: nyhet; uppfinningssteg; industriell tillämplighet.

8. Beskriv villkoren och tillvägagångssättet för att få patent på en uppfinning, bruksmodell eller industriell design, samt de villkor som säkerställer patentens giltighet och deras varaktighet.

9. Ge en definition av "know-how" och ange de villkor under vilka det rättsliga skyddet av produktionshemligheter uppstår och genomförs.

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

1., Immaterialrätt i Ryska federationen, lärobok // M, Prospekt, 2007

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

Projektledning och mjukvaruutveckling [R]

Vad är en metodik, varför behövs den. Metodikens allmänna struktur, metodikens huvudelement. Principer för att utforma egen metodik. Exempel på olika artefakter, roller, kompetenser, randvillkor. Cowburn metodik struktur, metod mått. Kriterier för Cowburn-projektet. Metodvalskriterier, Cowburn-matris. Projektets livscykel. Vattenfall och iterativa livscykelmodeller. Tillämpningsgränser för vattenfall och iterativa modeller. RUP som ett exempel på en iterativ metodik. Grundläggande RUP-koncept, tillämplighetsgränser. Mänsklig roll i mjukvaruutveckling. Agila metoder, grundläggande principer för agila metoder. Ursprunget till agila metoder. Scrum som exempel på en agil metodik. Roller, artefakter, aktiviteter i Scrum. Tillämpningsgränserna för Scrum. Extreme Programmering (XP) Idéer, värderingar, grundläggande praxis, gränser för tillämplighet. Likheter och skillnader mellan Scrum och XP. Insamling och hantering av krav. Grundläggande praxis, termer, principer. Metoder för att dokumentera projektet och produkten, huvudtyperna 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. Testning inom mjukvaruutveckling. Konceptet med montering (bygge) av en mjukvaruprodukt. Grundläggande testmetoder, termer. Exempel på testmetoder från de metoder som diskuteras i kursen. Konceptet montering (bygga), sätt att lagra kod, verktyg. Två principer för att organisera arbetet med ett versionskontrollsystem. Funktioner i produktlansering/layoutprocessen för olika produktkategorier, exempel på praxis. Moderna koncept för programvaruarkitektur, flernivåarkitekturer, arkitekturkriterier. Lista över nödvändiga beslut vid utformning av programvara, metoder för att välja ett datalagringssystem.

Kent Beck - Extrem programmering Frederic Brooks - Den mytiska man-månaden eller hur mjukvarusystem skapas. Tom de Marco - Deadline. En roman om projektledning. Tom de Marco, Timothy Lister - Waltzing with Bears. Tom de Marco, Timothy Lister - Den mänskliga faktorn_ 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 inom mjukvaruutveckling. Andriy Orlov - Anteckningar om en automatör. Professionell bekännelse. Philip Krachten - Introduktion till den rationella förenade processen. Henrik Kniberg - Scrum och XP: anteckningar från frontlinjen. Kursföreläsningar

Så kärnan i det strukturella tillvägagångssättet för utvecklingen av EIS-programvara ligger i dess nedbrytning (partitionering) i automatiserade funktioner: systemet är uppdelat i funktionella delsystem, som i sin tur är uppdelade i underfunktioner, de i uppgifter, och så vidare upp till specifika förfaranden. Samtidigt behåller systemet en helhetssyn där alla ingående komponenter är sammankopplade. När man utvecklar ett "bottom-up"-system, från enskilda uppgifter till hela systemet, går integriteten förlorad, 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 - principen att organisera de ingående delarna av systemet i hierarkiska trädstrukturer med tillägg av nya detaljer på varje nivå.

Valet av 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:

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

2. Principen om konsistens, giltighet och konsistens för systemets delar.

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

I det strukturella angreppssättet finns i grunden 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) - diagram över dataflöden;

SADT (Structured Analysis and Design Technique - metodik för strukturanalys och design) - modeller och motsvarande funktionsdiagram: notationer IDEF0 (funktionell modellering av system), IDEF1x (konceptuell modellering av databaser), IDEF3x (bygga system för att bedöma kvaliteten på ett objekt grafisk beskrivning av flödesprocesserna, samspelet mellan processer och objekt som förändras av dessa processer);

· ERD (Entity - Relationship Diagrams) - "entity-relationship" diagram.

I nästan alla metoder för det strukturella tillvägagångssättet (strukturell analys) används två grupper av modelleringsverktyg i stadiet för bildandet av programvarukrav:

1. Diagram som illustrerar de funktioner som systemet måste utföra och sambanden 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 konstruktioner beror på stadiet i mjukvarans livscykel.

I stadiet av kravbildning för mjukvara 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 (med användning 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 utförs beskrivningen av den data som används i organisationen på konceptuell nivå, oavsett hur databasen (DBMS) implementeras.

1.Kodning

I stadiet av mjukvaruutveckling utförs följande huvudåtgärder: kodning; testning; utveckling av ett referenssystem för programvara; skapa användardokumentation; skapa en version och installera programvara,

Kodning är processen att omvandla designresultat på hög och låg nivå till en färdig mjukvaruprodukt. Med andra ord, vid kodning sker beskrivningen av den kompilerade PP-modellen med hjälp av det valda programmeringsspråket, vilket kan vara vilket som helst av de befintliga språken. Valet av språk görs antingen på begäran av kunden, eller med hänsyn till uppgiften som löses och utvecklarnas personliga erfarenhet.

Vid kodning är det nödvändigt att 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 "Standart för C++ ProgrammingLanguage".

Utöver den allmänt accepterade standarden för ett programmeringsspråk kan ett företag även använda sina egna tilläggskrav för reglerna för att skriva program. I grund och botten relaterar de till reglerna för formatering av programmets text.

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

I kodningsstadiet skriver programmeraren program och testar dem själv. Sådan testning kallas enhetstestning. Alla frågor relaterade till mjukvarutestning diskuteras i kap. 10, beskriver den också testtekniken som används vid utvecklingsstadiet av programvara. Denna teknik kallas testning. "glaslåda" (glaslåda); ibland även kallad testning "vit låda" (vit låda) i motsats till det klassiska konceptet med en "svart låda" (blackbox).

I black box-testning behandlas programmet som ett objekt vars interna struktur är okänd. Testaren lägger in data och analyserar resultatet, men han vet inte 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. Först och främst är han intresserad av de representanter för varje klass av indata, där felen i programmet som testas mest sannolikt kommer att dyka upp.

När man testar "glaslådan" är situationen en helt annan. Testaren (i det här fallet programmeraren själv) utvecklar tester baserade på kunskap om källkoden, som han har full tillgång till. 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 vidarebefordra data av intresse till programmeraren. En enskild modul är mycket lättare att testa precis som en "glaslåda".

2.Full kodtäckning. Programmeraren kan alltid avgöra vilka kodfragment som fungerar i varje test. Den ser vilka andra kodgrenar som lämnas oprövade och kan välja under vilka förhållanden de ska testas. Följande beskriver hur du spårar kodtäckningen för de tester du kör.

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 det tror kan en programmerare inkludera felsökningskommandon som visar information om hur det körs, eller använda ett speciellt verktyg som kallas en debugger för att göra detta. Debuggern kan göra många användbara saker: spåra 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 spåra dataintegritet. Programmeraren vet vilken del av programmet som måste modifiera varje dataelement. Genom att spåra datas tillstånd (med samma debugger) kan han identifiera fel som dataändringar av fel moduler, deras felaktiga tolkning eller misslyckad organisation Programmeraren kan automatisera testning på egen hand.

5. Vision av inre gränspunkter. I källkoden är de gränspunkter för programmet som är dolda från utsidan 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 har valt. Ett annat typiskt exempel skulle vara ett buffertspillproblem 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. Särskild teknik kan behövas för att testa databehandling som använder mycket komplexa beräkningsalgoritmer. Matristransformation och datasortering är klassiska exempel. En testare, till skillnad från en programmerare, behöver veta exakt vilka algoritmer som används, så man måste hänvisa till specialiserad litteratur.

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

När du utför enhetstestning kan du använda antingen strukturella eller funktionella testtekniker, eller båda.

Strukturell Testning är en typ av testning av glaslåda. Dess huvudidé är det korrekta valet av mjukvaruvägen som testas. I motsats till honom funktionell testning tillhör kategorin "black box"-testning. Varje funktion i programmet testas genom att ta dess input och analysera resultatet. I det här fallet beaktas programmets interna struktur mycket sällan.

Medan strukturell testning har en mycket kraftfullare teoretisk grund, föredrar de flesta testare funktionell testning. Strukturella tester lämpar sig bättre för matematisk modellering, men det betyder inte alls att det är mer effektivt. Var och en av teknikerna låter dig identifiera fel som missas vid användning av den andra. Ur denna synvinkel kan de kallas lika effektiva.

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

3. Utveckling av ett hjälpsystem för en mjukvaruprodukt. Skapa användardokumentation

Det är lämpligt att utse en av projektanställda som teknisk redaktör för dokumentationen. Denna medarbetare kan utföra annat arbete, men hans huvudsakliga uppgift bör vara att analysera dokumentationen, även om andra medarbetare utvecklar den.

Det händer ofta att flera personer arbetar med att skapa programvara, men ingen av dem är helt ansvarig för dess kvalitet. Som ett resultat drar PP inte bara nytta av det faktum att fler människor utvecklar det, utan också förlorar, eftersom alla undermedvetet flyttar ansvaret till den andra och förväntar sig att hans kollegor ska göra den eller den delen av arbetet. Detta problem löses genom utnämningen av en redaktör som är fullt ansvarig för kvaliteten och noggrannheten i teknisk dokumentation.

Programvaruhjälpsystemet bildas på basis av det material som tagits fram för användarmanualen. Formar och skapar den ansvarig för utförandet av detta arbete. Det kan vara antingen en teknisk redaktör eller en av utvecklarna tillsammans med en teknisk redaktör.

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

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

2. Lägre kostnad för teknisk support. När användaren inte kan ta reda på hur han ska utföra de åtgärder han behöver ringer han mjukvarutillverkaren till den tekniska supporttjänsten. Underhållet av en sådan tjänst är mycket dyrt. En bra manual, å andra sidan, hjälper användarna att lösa problem på egen hand och minskar behovet av att kontakta den tekniska supportgruppen.

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, är det svårt för dem att ta reda på vad som orsakar dem och hur de ska hantera deras konsekvenser.

Enkel eskort. En enorm mängd pengar och tid läggs på att analysera problem som genereras av användarfel. Ändringar som görs i nya programversioner är ofta bara en förändring 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 den tekniska supporttjänsten. Bra ledarskap till stor del

När man överväger teknologi för mjukvaruutveckling är det nödvändigt att använda ett systematiskt tillvägagångssätt, vilket innebär att man inte överväger några enskilda aspekter av mjukvaruutvecklingsproblemet, utan problemet som helhet. Systemansatsen implementeras i rum och tid.

Systemansatsen i tid tar hänsyn till sekvensen av stadier av mjukvaruskapande från det ögonblick då ett ouppfyllt behov av mjukvara bildas till dess tillstånd och stöd i driften av den resulterande mjukvaruprodukten.

Systemansats i "rymden" föreskriver övervägande av programvaran som utvecklas som en del av systemet. Samtidigt formuleras målen och uppsättningen av mjukvarufunktioner på grundval av att studera informationsbehoven i systemet, vilket kommer att inkludera den mjukvara som utvecklas, och prototyper av mjukvara analyseras. Programvarukrav utformas och dokumenteras.

Modern mjukvaruutvecklingsteknologi betraktar programmering som ett av utvecklingsstadierna i kedjan av successiva steg i utvecklingscykeln. Alla dessa stadier förenas av konceptet med mjukvarans livscykel och måste stödjas av lämplig mjukvara och hårdvaruverktyg.

I enlighet med den internationella standarden ISO/IEC 12207 "informationsteknologi - Programvarulivscykelprocesser" innehåller mjukvaruutvecklingsprocessen följande stadier av mjukvarans livscykel:

1) analys av systemkrav och omfattning;

2) design av systemarkitektur;

3) analys av mjukvarukrav (specifikationer, externa gränssnitt,);

4) design av mjukvaruarkitektur;

5) detaljerad design av varje enhet av programvara;

6) programvarukodning (programmering)

7) testning av mjukvaruenheter;

8) integration (sammanslutning av programvara) och testning av en uppsättning mjukvaruenheter;

9) kvalifikationstester för programvara (integrerad testning);

10) systemintbör integreras med hårdvaruenheter;

11) kvalifikationsprov av systemet;

12) installation av programvara.

Således startar mjukvaruutvecklingsprocessen från systemet där denna programvara kommer att användas och slutar igen i systemet.

Efter utvecklingsstadierna i mjukvarans livscykel följer steget för drift av programvara och underhåll i drift. Ibland ges listan över stadier av mjukvarans livscykel med några generaliseringar (aggregationer) av de 12 stadierna. Till exempel stadierna av systemdesign och definition av mjukvarukrav, programvarupaketdesign, programvarualgoritmdesign, programmering (kodning), offlineprogramvarufelsökning, komplex mjukvarufelsökning, mjukvarudrift.

Om man försummar stadierna av mjukvarudesign leder önskan att omedelbart börja programmera utan tillräckliga studier av algoritmer och frågor om interaktion mellan mjukvarustrukturenheter ofta till en kaotisk mjukvaruutvecklingsprocess med liten chans att lyckas.

Spiral mjukvara livscykelmodell. "Tung och lätt" (snabb) teknik för mjukvaruutveckling

Den övervägda livscykelmodellen (LC) tillhör modellen av kaskadtyp. Den här typen av livscykelmodeller är bra för programvara för vilken det i början av utvecklingen är möjligt att fullt ut och exakt formulera alla krav på programvaran.

Schema för en spiralprogramvarulivscykel. Den verkliga processen att skapa programvara passar dock inte alltid in i ett så stelbent schema och ofta finns det ett behov av att återgå till de tidigare stadierna med förtydligande eller revidering av de beslut som fattas.

För mjukvara, såväl som för andra komplexa system, vars initiala krav inte är tillräckligt fullständiga, är en iterativ utvecklingsprocess karakteristisk. Samtidigt, för vissa typer av programvara, är det till och med önskvärt att gå till nästa steg så snabbt som möjligt. Samtidigt elimineras de oundvikliga bristerna med ett sådant hastigt arbete vid nästa iteration eller förblir för alltid.

Huvuduppgiften är att så snart som möjligt få en fungerande mjukvara och därigenom aktivera processen med att förtydliga och komplettera krav. Detta är den så kallade spiralprogramvarans livscykelmodell.

Vid varje varv av spiralen skapas en produktversion, mjukvarukrav specificeras och arbetet med nästa varv planeras. Livscykelmodellen för spiralprogram speglar den objektivt existerande processen för iterativ mjukvaruutveckling (Fig. 8.2).

Man tror att spiralschemat för mjukvarans livscykel inte är avsett så mycket för förhastade utvecklare, utan för mjukvara, vars första versioner av låg kvalitet är acceptabla för programvarans funktionella syfte.

Det finns en riktning för "snabbteknologier" för mjukvaruutveckling (Agil Software Development), som ger en ideologisk motivering för de åsikter som är förknippade med livscykelns spiralmodell. Dessa tekniker bygger på fyra idéer:

Interaktiv interaktion mellan individer är viktigare än formella procedurer och verktyg,

Fungerande mjukvara är viktigare än att ha dokumentation för det,

Samarbete med kunden är viktigare än formella avtal,

Ett snabbt svar på externa förändringar är viktigare än strikt efterlevnad av planerna.

Ris. 8.2 - Schema för spiralprogramvarans livscykel

Snabba teknologier syftar med andra ord till att ersätta formella och tidskrävande dokumenterade interaktionsprocedurer under utveckling med interaktiva, vilket är möjligt med små projektstorlekar, utvalda egenskaper hos anställda, placering av utvecklare och kunder ”i samma rum” och för utveckla mjukvara för icke-kritiska system.

Det är svårt att ifrågasätta riktigheten av dessa principer i viss utsträckning när mjukvaruutveckling utförs av ett litet antal kvalificerade och dedikerade "fans") för utveckling av vissa typer av mjukvara. Agila teknologier och deras ideologer inser dock att detta är tillämpligt på programvaruprojekt av en viss klass och skala, precis som spirallivscykelmodellen i allmänhet, nämligen där programvarufel leder till viss olägenhet eller förlust av återvinningsbara medel.

Där felaktigt fungerande programvara leder till ett hot mot människoliv eller till stora materiella förluster, bör fullfjädrad och genomtänkt teknik användas för att säkerställa tillförlitligheten hos mjukvaruprodukten.

Med en ökning av omfattningen av ett mjukvaruprojekt - en ökning av antalet personer som deltar i det, ökar behovet av en stel utvecklingsteknik som utgör livscykeln för kaskadprogramvaran. Här behövs dokumentation, eftersom förlusten av någon av utvecklarna när som helst är möjlig, formalisering av kommunikation mellan program, hantering av mjukvaruförändringar etc. Det är inte för inte som kaskadlivscykelmodellen har introducerats i mjukvaruutveckling standarder. Samtidigt gör det också möjligt att implementera en iterativ utvecklingsprocess på grund av den tillhandahållna fasningen av designen av CTS och mjukvara för dem.

För mycket stora programvaruprojekt (mer än 100 utvecklare) är utvecklingsteknik en nyckelfaktor som påverkar inte bara kvaliteten på programvaran utan också själva möjligheten att skapa den.

"Tung och lätt" teknologi för mjukvaruutveckling . Utvecklare av många typer av mjukvara anser att livscykelmodellen för vattenfall är för reglerad, för dokumenterad och tung och därför irrationell. Det finns en riktning för "Snabbteknologier" (ljusteknologier) för mjukvaruutveckling (Agil Software Development), vilket ger en ideologisk motivering för dessa åsikter. Dessa tekniker bygger på fyra idéer:

1. interaktiv interaktion mellan individer är viktigare än formella förfaranden och verktyg,

2. fungerande programvara är viktigare än tillgången på dokumentation för den,

3. samarbete med kunden är viktigare än formella avtal med denne,

4. snabb respons på externa förändringar är viktigare än strikt efterlevnad av planerna.

Riktigheten av dessa principer, förutom den tredje, i viss utsträckning (programvaruutveckling utförs av ett litet antal kvalificerade programmerare - "fans" som inte behöver kontroll och ytterligare motivation) för mjukvaruutveckling är svår att ifrågasätta. Agila teknologier och detta erkänns av deras ideologer är dock tillämpliga på programvaruprojekt av en viss klass och skala, såväl som spirallivscykelmodellen i allmänhet, nämligen där programvarufel leder till viss olägenhet eller förlust av återvinningsbara medel och där programvara kraven förändras ständigt, eftersom de var dåligt definierade i förväg, och snabb anpassning till dessa förändringar krävs.

Snabba teknologier - försöker nå en kompromiss mellan strikt utvecklingsdisciplin och dess fullständiga frånvaro i namn av att minska flödet av pappersarbete som följer med utvecklingen. Snabba tekniker kan inte garantera hög tillförlitlighet för en mjukvaruprodukt just på grund av minimeringen av pappersarbete som juridiskt bekräftar utvecklarens ansvar .

Ett exempel på agila teknologier är Extreme Programming (XP). Iterationer i XP är mycket korta och består av fyra operationer: kodning, testning, lyssna på kunden, designa. Principerna för XP - minimalism, enkelhet, kundmedverkan, korta cykeltider, nära interaktion mellan utvecklare - de ska sitta i samma rum, dagliga operativa möten tillsammans med kunden verkar rimliga och har länge använts inte bara i snabba teknologier, utan i XP förs de till extrema värden.

En analys av många mjukvaruprojekt har visat att lättviktsteknologier som predikar principerna för självorganisering, betonar användningen av individuella förmågor hos utvecklare, korta utvecklingsiterationer i en spiralmodell, XP, SCRUM är vanliga och ofta också leder till framgång, vilket gör de flesta funktionerna i att arbeta i små team.

Där felaktigt fungerande programvara leder till ett hot mot människoliv eller till stora materiella förluster, bör ordnad, genomtänkt och förutsägbar formaliserad "tung" teknik användas för att säkerställa tillförlitligheten hos mjukvaruprodukten även när det gäller medelskickliga utvecklare Med en ökning av omfattningen av ett mjukvaruprojekt, en ökning av antalet deltagare i det, ökar behovet av en stel och formell utvecklingsteknologi som fixerar ansvaret för varje utvecklingsdeltagare som utgör livscykeln för kaskadprogramvaran. Det är inte för inte som vattenfallets livscykelmodell har introducerats i standarder för mjukvaruutveckling.

I stora utvecklingsteam kommer problemet med ledning i förgrunden.

För mycket stora programvaruprojekt är frågorna om ordnad koordinerad utveckling: strukturering, integrering, säkerställande av att program interagerar korrekt, organisera oundvikliga förändringar på ett korrekt och koordinerat sätt nyckeln. och påverka själva möjligheten att skapa dem.

I små mjukvaruprojekt, algoritmiska förfiningar, spelar inflytandet från enskilda begåvade individer en avgörande roll, medan dessa faktorer i stora projekt utjämnas och inte har ett avgörande inflytande på utvecklingsprocessen.

Mjukvaruutvecklare som har genomsnittliga förmågor, och de är i majoritet, och som håller teknisk disciplin inom rätt teknik, bör utveckla mjukvara av den kvalitet som krävs. "Håll ordning så håller han dig."

Datavetenskap, cybernetik och programmering

Iteration N USDP Unified Software Development Process Användningsfallsmodellen 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 dedikerade objekt, och distributionsmodellen beskriver distributionen av programvara mellan datorer.

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

Programvaruutvecklingsmodeller

1. Vodopadnaya
2. Cascade modell
3. Spiral
4. Extrem programmering
5. inkrementell
6. Läkare Utan Gränsers metodik

vattenfall modell

spiralmodell

Inkrementell utveckling

Kravanalys

Design

Genomförande

Komponent

testning

Integration

Testning

hela

Iteration 1 Iteration 2 …. Iteration N

Unified Software Development Process (USDP)

1. Användningsfallsmodellen beskriver i vilka fall applikationen kommer att användas.
2. Den analytiska modellen beskriver basklasserna för applikationen.
3. Designmodellen beskriver sambanden och relationerna mellan klasser och utvalda objekt
4. Implementeringsmodellen beskriver distributionen av programvara mellan datorer.
5. Implementeringsmodellen beskriver den interna organisationen av programkoden.
6. Testmodellen består av testkomponenter, testprocedurer och olika testfall.

Läkare Utan Gränsers metodik

Typiska programoch typiska programvarukrav

feltolerans- en 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 förutse alla möjliga situationer som kan leda till ett systemfel och utveckla mekanismer för att hantera fel.

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

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

krascha - ett fel i driften av systemet som inte leder till fel på systemet.

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. Naturens organiska ämnen	48,5 kB
	Mångfalden av organiska föreningar bestäms av den unika förmågan hos kolatomer att kombinera med varandra genom enkla och multipla bindningar för att bilda föreningar med ett nästan obegränsat antal atomer sammanlänkade 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 disposition för 2. Spara dokumentet i din egen mapp under namnet Abstrakt.
57361.		Nummer och nummer 3. Parning av nummer vid gränserna 3. Skriftliga nummer 3. Parning av gamla föremål	35,5 kB
	Siffror för alla varelser Vem borde vara den första Vem borde vara den sista Vem borde vara under siffran 1 Vem borde vara under siffran 2 Vem är den susid högerhänta ekorren Vem är den susid vänsterhänta giraffen