close

Software

Gå til navigation Gå til søg
Image
Tekstbehandlingsprogrammer såsom LibreOffice Writer er inkluderet i kategorien applikationssoftware .

Det er kendt som software ( engelsk udtale:  /ˈsɔftˌwɛr/ ), [ 1 ] ​logisk eller logisk støtte til det formelle system i et computersystem , som omfatter det sæt af nødvendige logiske komponenter, der gør det muligt at udføre specifikke opgaver, som f.eks. i modsætning til de fysiske komponenter, der kaldes hardware . Interaktionen mellem software og hardware gør en computer (eller anden enhed) operationel, det vil sige, at softwaren sender instruktioner, som hardwaren udfører, hvilket gør det muligt at fungere.

De logiske komponenter omfatter blandt mange andre computerapplikationer , såsom tekstbehandleren , som giver brugeren mulighed for at udføre alle opgaver vedrørende tekstredigering; den såkaldte systemsoftware , såsom operativsystemet , som i bund og grund tillader resten af ​​programmerne at fungere ordentligt, også letter interaktionen mellem de fysiske komponenter og resten af ​​applikationerne og giver en grænseflade med brugeren. [ 2 ]

Langt størstedelen af ​​softwaren er skrevet i programmeringssprog på højt niveau , da de er nemmere og mere effektive for programmører at bruge, fordi de er tættere på naturligt sprog end maskinsprog . [ 3 ] Sprog på højt niveau oversættes til maskinsprog ved hjælp af enten en compiler eller en tolk , eller en kombination af begge. Software kan også være skrevet i assemblersprog , som er lavt niveau og har en høj overensstemmelse med maskinsprog instruktioner; er oversat til maskinsprog ved hjælp af en assembler .

Anglisismesoftwaren er den mest udbredte, når man refererer til dette koncept, især i teknisk jargon , mens det synonyme udtryk " logisk ", afledt af det franske udtryk logiciel , bruges mest i lande og områder med fransk indflydelse.

Etymologi

Software ( AFI:  [ˈsoft.wer] ) er et ord fra engelsk , som på spansk ikke har en passende oversættelse til konteksten, hvortil det bruges regelmæssigt uden oversættelse og derfor blev optaget af Royal Spanish Academy (RAE). [ 4 ] Selvom det måske strengt taget ikke er det samme, erstattes det ofte af udtryk som (computer)programmer, (computer ) applikationer eller software . [ 5 ]

Software er det , der kaldes et produkt i softwareudvikling . [ 6 ]

Udtrykket "logisk" er en leksikalsk kopi af det franske udtryk logiciel , en neologisme, der blev dannet i 1969 af ordene logique ('logik') og matériel ('materiale') som en oversættelse af IT-delegationen, der er ansvarlig for Planberegningen . [ 7 ]

Softwaredefinition _

Der er flere lignende accepterede definitioner for software , men den mest formelle er nok følgende:

Det er det sæt af computerprogrammer, procedurer, regler, dokumentation og tilhørende data, som er en del af driften af ​​et computersystem.
Uddraget fra IEEE standard 729 [ 8 ]

I betragtning af denne definition går begrebet software ud over computerprogrammer i deres forskellige tilstande: kildekode , binær eller eksekverbar ; dens dokumentation, de data, der skal behandles og endda brugeroplysningerne er også en del af softwaren : det vil sige, at den omfatter alt, hvad der er immaterielt , alt, hvad der er "ikke-fysisk" relateret.

Udtrykket software blev først brugt i denne betydning af John W. Tukey i 1957 . Inden for softwareteknik og datalogi er software al information , der behandles af computersystemer : programmer og data .

Konceptet med at læse forskellige sekvenser af instruktioner ( program ) fra en enheds hukommelse for at kontrollere beregninger blev introduceret af Charles Babbage som en del af hans forskelsmotor . Teorien, der danner grundlaget for det meste af moderne software, blev foreslået af Alan Turing i sit essay fra 1936, "Computable Numbers", med en anvendelse på beslutningsproblemet. [ 9 ]

Softwareklassificering _

Image
Program Finder i Ubuntu 13.10

Selvom denne skelnen er noget vilkårlig og til tider forvirrende, kan software til praktiske formål klassificeres i tre typer: [ 10 ]

Softwareoprettelsesproces _

En "proces" er defineret som det bestilte sæt trin, der skal følges for at nå en løsning på et problem eller for at opnå et produkt, i dette særlige tilfælde, for at opnå et softwareprodukt , der løser et specifikt problem.

Softwareoprettelsesprocessen kan blive meget kompleks , afhængig af dens størrelse, karakteristika og dens kritikalitet. For eksempel er oprettelsen af ​​et operativsystem en opgave, der kræver et projekt, ledelse, mange ressourcer og et helt disciplineret team af arbejde. I den anden yderlighed, hvis det er et simpelt program (for eksempel opløsningen af ​​en andenordens ligning), kan det nemt udføres af en enkelt programmør (selv en amatør). Således opdeles de normalt i tre kategorier efter deres størrelse ( linjer med kode ) eller pris: "lille", "medium" og "stor". Der er flere metoder til at estimere det, en af ​​de mest populære er COCOMO -systemet , der leverer metoder og et software (program), der beregner og giver en tilnærmelse af alle produktionsomkostningerne i et " softwareprojekt " (forhold mellem mand/timer, pengeomkostninger, antal kildelinjer i henhold til det anvendte sprog osv.).

I betragtning af de store, er det nødvendigt at udføre komplekse opgaver, både tekniske og ledelsesmæssige, stærk ledelse og forskelligartet analyse (blandt andet), kompleksiteten af ​​dette har ført til udviklingen af ​​en specifik ingeniør til at håndtere dens undersøgelse og realisering : det er kendt som software engineering .

Hvorimod i mellemstore kan små arbejdshold (selv en solo-erfaren analytiker-programmør ) udføre opgaven. Selvom der altid i mellemstore og store tilfælde (og nogle gange også i nogle små, afhængigt af deres kompleksitet) skal følges visse stadier, der er nødvendige for konstruktionen af ​​softwaren . Sådanne stadier, selvom de skal eksistere, er fleksible i deres anvendelsesform i henhold til den metodologi eller udviklingsproces, der er valgt og brugt af udviklingsteamet eller af solo-programmør-analytikeren (hvis det var tilfældet).

" Softwareudviklingsprocesserne " har på forhånd fastlagte regler og skal anvendes i skabelsen af ​​mellemstore og store software , da ellers det sikreste er, at projektet ikke vil kunne afsluttes eller afsluttes uden at opfylde de planlagte mål. , og med en række uacceptable fejl (de fejler kort sagt). Blandt sådanne "processer" er der agile eller lette (eksempelvis XP ), tunge og langsom (eksempel RUP ) og varianter derimellem. De anvendes normalt i henhold til typen og størrelsen af ​​den software , der skal udvikles, efter lederen (hvis nogen) af udviklingsteamets skøn. Nogle af disse processer er Extreme Programming (på engelsk eXtreme Programming eller XP), Rational Unified Process (på engelsk Rational Unified Process eller RUP), Feature Driven Development ( FDD ) osv. [ 12 ]

Uanset hvilken "proces" der anvendes og anvendes til softwareudvikling (RUP, FDD, XP osv.), og næsten uafhængigt af den, skal en "livscyklusmodel" altid anvendes. [ 13 ]

Det anslås, at af alle de store softwareprojekter , der er gennemført, mislykkes 28 %, 46 % falder i alvorlige ændringer, der forsinker det, og 26 % er fuldstændig vellykkede. [ 14 ]

Når et projekt fejler, skyldes det sjældent tekniske fejl, hovedårsagen til fejl og fejl er manglende anvendelse af en god udviklingsmetodologi eller -proces. Blandt andet har en stærk tendens i et par årtier været at forbedre metoder eller udviklingsprocesser, eller skabe nye og gøre it- professionelle opmærksomme på deres korrekte brug. Normalt er specialister i undersøgelse og udvikling af disse områder (metoder) og relaterede områder (såsom modeller og endda projektledelse) softwareingeniører , det er deres orientering. Specialister inden for ethvert andet område af computerudvikling (analytiker, programmør, kandidat i datalogi, computeringeniør, systemingeniør osv.) anvender normalt deres specialiserede viden, men bruger modeller, paradigmer og processer, der allerede er udviklet.

Det er almindeligt for udvikling af mellemstor software , at de involverede menneskelige teams anvender "egne metoder", som regel en hybrid af de tidligere processer og nogle gange med deres egne kriterier. [ 15 ]

Udviklingsprocessen kan involvere mange og varierede opgaver, [ 13 ]​ fra det administrative, over det tekniske og endda ledelse og ledelse. Men næsten strengt er visse minimumstrin altid opfyldt ; som kan opsummeres som følger:

I de foregående stadier kan deres navne variere lidt, eller være mere globale, eller tværtimod være mere raffinerede; for eksempel angive som en enkelt fase (til dokumentariske og fortolkende formål) af "analyse og design"; eller angive som "implementering" hvad der siges som "kodning"; men strengt taget eksisterer de alle og indeholder grundlæggende de samme specifikke opgaver.

Afsnit 4 i denne artikel indeholder yderligere detaljer om hvert af de angivne stadier.

Proces- eller livscyklusmodeller

For hver af de faser eller stadier, der er anført i det foregående punkt, er der underfaser (eller opgaver). Procesmodellen eller livscyklusmodellen , der bruges til udvikling, definerer rækkefølgen af ​​de involverede opgaver eller aktiviteter, [ 13 ] definerer også koordineringen mellem dem, og deres kobling og feedback. Blandt de bedst kendte kan vi nævne: kaskade- eller sekventiel model, spiralmodel , inkrementel iterativ model . Af de førnævnte er der til gengæld nogle varianter eller alternativer, mere eller mindre attraktive afhængigt af den påkrævede anvendelse og dens krav. [ 14 ]

Cascade model

Dette, selvom det er mere almindeligt kendt som vandfaldsmodellen , kaldes også den "klassiske model", "traditionel model" eller "lineær sekventiel model".

Den rene vandfaldsmodel "anvendes næsten ikke som den er", da dette ville indebære forudgående og absolut kendskab til kravene, deres ikke-flygtighed (eller stivhed) og efterfølgende fejlfrie stadier; dette kunne kun anvendes på knappe og små systemer, der skal udvikles. Under disse omstændigheder ville overgangen fra et trin til et andet af de nævnte være uden tilbagevenden, for eksempel ville bevægelse fra design til kodning indebære et nøjagtigt design uden fejl eller sandsynlig ændring eller evolution: «kode hvad der er designet uden fejl, vil der være absolut ingen fremtidige varianter. Dette er utopisk; da " software i sig selv er af evolutionær karakter", [ 17 ] skiftende og næppe fri for fejl, både under dets udvikling og i løbet af dets operationelle levetid. [ 13 ]

Image
Figur 2: Ren eller sekventiel vandfaldsmodel for softwarens livscyklus.

Enhver ændring under udførelsen af ​​nogen af ​​faserne i denne sekventielle model kan indebære genstart af hele cyklussen fra begyndelsen, hvilket ville resultere i høje tids- og udviklingsomkostninger. Figur 2 viser et muligt skema for den pågældende model. [ 13 ]

Imidlertid er vandfaldsmodellen i nogle af dens varianter en af ​​de mest brugte i dag , [ 18 ] på grund af dens effektivitet og enkelhed, mere end noget andet i små og nogle mellemstore software ; men det bliver aldrig (eller meget sjældent) brugt i sin "rene form", som nævnt ovenfor. I stedet er der altid en vis feedback mellem stadierne, som hverken er helt forudsigelig eller rigid; dette giver mulighed for udvikling af softwareprodukter , hvor der er visse usikkerheder, ændringer eller udviklinger i løbet af livscyklussen. Når kravene er fanget og specificeret (første trin), er det således muligt at gå videre til designet af systemet, men i denne sidste fase er det mest sandsynligt, at justeringer af kravene (også selvom de er minimal) vil skulle foretages, enten på grund af opdagede fejl, uklarheder eller fordi kravene i sig selv har ændret sig eller udviklet sig; hvormed det er nødvendigt at vende tilbage til den første eller forrige fase, foretage de relevante justeringer og derefter fortsætte med designet igen; sidstnævnte er kendt som feedback. Den normale ting i vandfaldsmodellen er så anvendelsen af ​​den samme med dens stadier tilbageført på en eller anden måde, hvilket gør det muligt at gå tilbage fra den ene til den forrige (og endda være i stand til at hoppe til flere tidligere), hvis det kræves.

På denne måde opnås «feedback-kaskade-modellen», som kan ske skematisk som illustreret i figur 3.

Image
Figur 3: Feedback vandfaldsmodel for livscyklussen.

Det, der er blevet sagt, er i store træk formen og brugen af ​​denne model, en af ​​de mest brugte og populære. [ 13 ]​ Feedback-vandfaldsmodellen er meget attraktiv, endda ideel, hvis projektet præsenterer høj stivhed (få ændringer, ikke-evolutionær prognose), kravene er meget klare og korrekt specificerede. [ 18 ]

Der er flere varianter, der ligner modellen: forfining af stadier (flere stadier, mindre og mere specifikke) eller viser endda færre stadier end de angivne, selvom den manglende i dette tilfælde vil være inden for en anden. Rækkefølgen af ​​disse faser angivet i det foregående punkt er logisk og passende, men bemærk som sagt, at der normalt vil være tilbagegående feedback.

Den lineære model eller vandfaldsmodel er det ældste og mest udbredte paradigme, men kritik af det (se ulemper) har sat spørgsmålstegn ved dets effektivitet. På trods af alt har den en meget vigtig plads i softwareudvikling og er fortsat den mest udbredte; og det er altid bedre end en tilfældig tilgang. [ 18 ]

Ulemper ved vandfaldsmodellen: [ 13 ]

  • Ændringer introduceret under udviklingen kan forvirre det professionelle team i de tidlige faser af projektet. Hvis ændringer sker på et modent stadium (kodning eller test), kan de være katastrofale for et stort projekt.
  • Det er ikke ofte, at klienten eller slutbrugeren klart og fuldstændigt forklarer kravene (startstadiet); og den lineære model kræver det. Den naturlige usikkerhed i starten er så svær at imødekomme. [ 18 ]
  • Kunden skal være tålmodig, da softwaren først vil være tilgængelig et godt stykke inde i projektet. En vigtig fejl opdaget af kunden (i driftsfasen) kan være katastrofal og involvere en genstart af projektet med høje omkostninger.

Evolutionære modeller

Software udvikler sig over tid. [ 19 ] ​[ 17 ]​ Bruger- og produktkrav ændrer sig ofte, efterhånden som produktet udvikles. På grund af markedsdatoer og konkurrence er det ikke muligt at vente med at bringe et helt komplet produkt på markedet, så det er tilrådeligt at introducere en begrænset funktionel version på en eller anden måde for at afhjælpe konkurrencepresset.

I disse eller lignende situationer har udviklere brug for fremskridtsmodeller, der er designet til at rumme en tid eller progressiv udvikling, hvor kernekravene er kendt på forhånd, selvom de ikke er veldefinerede i detaljer.

I vandfalds- og feedbackvandfaldsmodellen tages der ikke højde for softwarens evolutionære karakter , [ 19 ] den betragtes som statisk, med krav, der er velkendte og definerede fra begyndelsen. [ 13 ]

De evolutionære er iterative modeller, de tillader udvikling af stadig mere komplette og komplekse versioner, indtil de når det ønskede endelige mål; endda udvikle sig yderligere under driftsfasen.

De "inkrementelle iterative" og "spiral" modeller (blandt andre) er to af de bedst kendte og mest brugte af den evolutionære type. [ 18 ]

Inkrementel iterativ model

Generelt er det muligt i figur 4 at skelne mellem de generelle trin efterfulgt af udviklingsprocessen for et softwareprodukt . I den valgte livscyklusmodel er disse trin tydeligt identificeret. Beskrivelsen af ​​systemet er afgørende for at specificere og forberede de forskellige trin, indtil det globale og endelige produkt nås. De samtidige aktiviteter (specifikation, udvikling og validering) syntetiserer den detaljerede udvikling af inkrementerne, hvilket vil blive gjort senere.

Image
Figur 4: Generisk diagram over inkrementel evolutionær udvikling.

Diagrammet i figur 4 viser på en meget skematisk måde driften af ​​en inkrementel iterativ cyklus, som tillader levering af delversioner, efterhånden som det endelige produkt bygges. [ 13 ]​ Det vil sige, når hvert defineret trin når sit drifts- og vedligeholdelsesstadium. Hver udstedt version inkorporerer de funktionaliteter og krav, der blev analyseret som nødvendige i forhold til de tidligere trin.

Den inkrementelle er en evolutionær typemodel, der er baseret på adskillige feedback-kaskadecyklusser, der anvendes gentagne gange, med en iterativ filosofi. [ 18 ]​ Figur 5 viser en forfining af det foregående diagram, under en midlertidig ordning, for endelig at opnå skemaet for den inkrementelle iterative livscyklusmodel med tilhørende generiske aktiviteter. Her er hver kaskadecyklus, der anvendes for at opnå en stigning, tydeligt observeret; sidstnævnte integreres for at opnå det komplette slutprodukt. Hvert trin er en tilbagekoblingskaskadecyklus, selvom den for nemheds skyld i figur 5 er vist som ren sekventiel.

Image
Figur 5: Inkrementel iterativ model for softwarens livscyklus .

Det observeres, at der er udviklingsaktiviteter (for hvert trin), der udføres parallelt eller samtidigt, således f.eks. i figuren, mens det detaljerede design af det første trin udføres, er analysen af ​​det andet allerede udføres. Figur 5 er kun skematisk, en stigning vil ikke nødvendigvis starte under designfasen af ​​den forrige, den kan være senere (selv før), på et hvilket som helst tidspunkt af det foregående trin. Hver stigning afsluttes med aktiviteten "drift og vedligeholdelse" (angivet som "Drift" i figuren), hvor leveringen af ​​delproduktet til kunden finder sted. Starttidspunktet for hvert trin afhænger af flere faktorer: type system; uafhængighed eller afhængighed mellem trin (to fuldstændigt uafhængige trin kan nemt startes på samme tid, hvis tilstrækkeligt personale er til rådighed); kapacitet og antal fagfolk involveret i udvikling; etc. [ 15 ]

Under denne model leveres software "af mindre funktionelle dele", men genbrugelig, kaldet inkrementer. Generelt bygger hver stigning på den, der allerede er leveret. [ 13 ]

Som vist i figur 5, anvendes kaskadesekvenser på en forskudt måde, efterhånden som kalendertiden skrider frem. Hver lineær sekvens eller kaskade producerer et trin, og ofte er det første trin et grundlæggende system, med mange ekstra funktioner (kendte eller ej) uden at blive leveret.

Klienten bruger i første omgang dette grundlæggende system, i mellemtiden kan resultatet af dets brug og evaluering bidrage til planen for udvikling af følgende trin (eller versioner). Derudover bidrager andre faktorer også til denne plan, såsom prioritering (større eller mindre presserende behov for hvert enkelt inkrement) og afhængigheden mellem inkrementer (eller uafhængighed).

Efter hver integration leveres et produkt med større funktionalitet end det foregående. Processen gentages, indtil den færdige software er nået .

Da den er iterativ, leveres der med den inkrementelle model et delvist, men fuldt operationelt produkt i hvert trin , og ikke en del, der bruges til at justere kravene (som i prototypemodellen ). [ 18 ]

Den trinvise tilgang er meget nyttig, når udviklingsbemandingen er lav; også hvis der ikke er nogen projektdeadline tilgængelig, så ufuldstændige versioner leveres, men giver brugeren grundlæggende (og voksende) funktionalitet. Det er også en nyttig skabelon til evalueringsformål.

Bemærk: Det kan overvejes og være nyttigt, når som helst eller i trin, midlertidigt at inkorporere MCP -paradigmet som et komplement, og dermed have en blanding af modeller, der forbedrer ordningen og den generelle udvikling.

Eksempel:

Et tekstbehandlingsprogram, der er udviklet under det inkrementelle paradigme, kunne i princippet levere grundlæggende filredigerings- og dokumentproduktionsfunktioner (noget som en simpel editor ). I et andet trin kunne mere sofistikeret redigering og dokumentgenerering og blanding tilføjes . I et tredje trin kunne tilføjelsen af ​​stavekontrolfunktioner , pagineringsskemaer og skabeloner overvejes ; i en fjerde egne tegnefærdigheder og matematiske ligninger. Så videre, indtil du når den nødvendige slutprocessor. Således vokser produktet og kommer tættere på dets endelige mål, men fra leveringen af ​​det første trin er det allerede nyttigt og funktionelt for kunden, som observerer en hurtig reaktion i form af tidlig levering; uden at bemærke, at projektfristen ikke må være begrænset eller defineret, hvilket giver driftsmargin og aflaster udviklingsteamet. [ 15 ]

Som sagt er den inkrementelle iterativ en model af den evolutionære type, det vil sige, hvor sandsynlige ændringer i kravene tillades og forventes på udviklingstidspunktet; en vis margen er tilladt, så softwaren kan udvikle sig. [ 17 ]​ Gælder, når kravene er ret velkendte, men ikke er fuldstændig statiske og definerede, et problem der er essentielt for at kunne bruge en Cascade-model.

Modellen er tilrådelig til softwareudvikling , hvor det i sin indledende fase af analyse observeres, at den har ret veldefinerede områder at dække, med tilstrækkelig uafhængighed til at blive udviklet i successive faser. Sådanne områder, der skal dækkes, har normalt forskellige grader af hastende karakter, som de skal prioriteres for i en tidligere analyse, dvs. definere, hvilken der vil være den første, den anden, og så videre; dette er kendt som "definering af trin" baseret på prioritering. Der er muligvis ingen funktionelle prioriteter på klientens side, men udvikleren skal sætte dem alligevel og med nogle kriterier, da de forskellige trin vil blive udviklet og leveret ud fra dem.

Det faktum, at der er funktionelle stigninger i softwaren , får os straks til at tænke på et modulært udviklingsskema , derfor letter denne model et sådant designparadigme.

Sammenfattende leder en inkrementel model en til at tænke på en modulær udvikling, med delleverancer af softwareproduktet kaldet "inkrementer" af systemet, som på en eller anden måde vælges i henhold til foruddefinerede prioriteter. Modellen tillader en implementering med successive forbedringer (udvidelse eller forbedring). Med hver stigning tilføjes ny funktionalitet eller nye krav opfyldes, eller den tidligere implementerede version af softwareproduktet forbedres .

Denne model giver en vis fleksibilitet, således at ændringer under udvikling inkluderes i kravene af brugeren, en foreslået og godkendt ændring i krav kan analyseres og implementeres som en ny stigning eller i sidste ende kan den udgøre en forbedring/tilpasning af en allerede planlagt ... Selvom der er en ændring af kundens krav, som påvirker tidligere gennemførte inkrementer (sen detektering/inkorporering) , skal gennemførligheden vurderes, og der skal laves en aftale med kunden, da det kan have stor indflydelse på omkostningerne. [ 15 ]

Valg af denne model giver mulighed for tidlige funktionelle leveringer til kunden (hvilket er gavnligt for både kunden og udviklingsgruppen). Leveringerne af de moduler eller inkrementer, hvor det operationelle behov opstår, prioriteres, for eksempel for tidligere belastninger af information, som er afgørende for de følgende inkrementer. [ 18 ]

Den inkrementelle iterative model tvinger ikke til at specificere med præcision og detaljer, absolut alt, hvad systemet skal gøre (og hvordan), før det bygges (som i tilfældet med vandfaldet, med frosne krav). Det gøres kun i udviklingstilvæksten. Dette gør processen mere overskuelig og reducerer omkostningspåvirkningen. Dette er tilfældet, fordi i tilfælde af at kravene ændres eller laves om, påvirker det kun en del af systemet. Selvom denne situation logisk set forværres, hvis den opstår i et fremskredent stadium, det vil sige i de sidste trin. I sidste ende gør modellen det nemt at indarbejde nye krav under udviklingen.

Med et inkrementelt paradigme reduceres den indledende udviklingstid, da delvis funktionalitet er implementeret. Det giver også en fordelagtig indvirkning på kunden, som er tidlig levering af fungerende dele af softwaren .

Modellen giver alle fordelene ved feedback-kaskademodellen, og reducerer dens ulemper kun til omfanget af hvert trin.

Den inkrementelle model anbefales ikke til realtidssystemer , højsikkerhedssystemer, distribueret behandling eller højrisikosystemer.

Spiralmodel

Spiralmodellen blev oprindeligt foreslået af Barry Boehm . Det er en evolutionær model, der kombinerer MCP -modellens iterative karakter med de kontrollerede og systematiske aspekter af Cascade-modellen. Giver potentiale for hurtig udvikling af inkrementelle udgivelser. I spiralmodellen er software bygget i en række trinvise versioner. I de første iterationer kunne den inkrementelle version være en papirmodel eller en prototype. I de sidste iterationer produceres flere og flere komplette versioner af det designede system. [ 13 ] ​[ 18 ]

Modellen er opdelt i en række rammeaktiviteter, kaldet "opgaveregioner". Generelt er der mellem tre og seks opgaveregioner (der er varianter af modellen). Figur 6 viser skematisk en spiralmodel med seks områder. I dette tilfælde forklares en variant af Boehms originale model, afsløret i hans afhandling fra 1988; i 1998 afslørede han en nyere afhandling.

Image
Figur 6: Spiralmodel for softwarens livscyklus .

De områder, der er defineret i modellen af ​​figuren, er:

  • Region 1 — Opgaver, der kræves for at etablere kommunikation mellem bygherren og bygherren.
  • Region 2 — Opgaver, der er forbundet med definitionen af ​​ressourcer, tid og anden information relateret til projektet.
  • Region 3 — Opgaver, der er nødvendige for at vurdere de tekniske og ledelsesmæssige risici ved projektet.
  • Region 4 — Opgaver til at bygge en eller flere repræsentationer af softwareapplikationen .
  • Region 5 — Opgaver til at bygge applikationen, installere den, teste den og yde bruger- eller kundesupport (f.eks. dokumentation og praksis).
  • Region 6 — Opgaver til at få kundefeedback, baseret på evaluering af, hvad der blev bygget og installeret i tidligere cyklusser.

De aktiviteter, der er anført for rammen, er generelle og gælder for ethvert projekt, stort, mellem eller lille, komplekst eller ej. De regioner, der definerer disse aktiviteter, omfatter et "sæt af opgaver" af arbejdet: dette sæt skal tilpasses karakteristikaene ved det særlige projekt, der skal gennemføres. Bemærk, at det, der er anført i punkt 1 til 6, er sæt af opgaver, hvoraf nogle normalt afhænger af selve projektet eller udviklingen.

Små projekter kræver et lavt antal opgaver og også formalitet. I større eller kritiske projekter indeholder hver opgaveregion opgaver med en højere formalitet. Under alle omstændigheder gælder beskyttelsesaktiviteter (f.eks. softwarekonfigurationsstyring , kvalitetssikring osv.).

I begyndelsen af ​​cyklussen, eller den evolutionære proces, drejer ingeniørteamet rundt om spiralen (metaforisk set) begyndende i midten (markeret med ๑ i figur 6) og i den angivne retning; det første kredsløb i spiralen kan føre til udvikling af en produktspecifikation ; de følgende trin kunne generere en prototype og gradvist mere sofistikerede versioner af softwaren .

Hver passage gennem planlægningsregionen medfører justeringer af projektplanen; omkostningerne og planlægningen er tilbageført på baggrund af kundens vurdering. Projektlederen skal justere antallet af iterationer, der kræves for at fuldføre udviklingen.

Spiralmodellen kan tilpasses og anvendes gennem hele softwarens livscyklus (i den klassiske model, eller vandfaldet, slutter processen med leveringen af ​​softwaren ).

Et alternativt syn på modellen kan ses ved at undersøge 'projektets indgangspunktakse'. Hver af de små cirkler (๏) fastgjort langs aksen repræsenterer udgangspunkter for de forskellige (relaterede) projekter; nemlig:

  • Et "konceptudviklingsprojekt" starter i begyndelsen af ​​spiralen, går gennem flere iterationer, indtil det er færdigt, det er området markeret med grønt.
  • Hvis ovenstående skal udvikles som et rigtigt produkt, startes endnu et projekt: ”New Product Development”. Det vil udvikle sig med gentagelser, indtil det kulminerer; er området markeret med blåt.
  • Til sidst og tilsvarende vil der blive genereret "produktforbedring" og "produktvedligeholdelse"-projekter med de nødvendige iterationer i hvert område (henholdsvis røde og grå områder).

Når spiralen er karakteriseret på denne måde, er den operationel, indtil softwaren fjernes, til sidst kan den være inaktiv (processen), men når der sker en ændring, starter processen igen ved det passende indgangspunkt (for eksempel i "forbedring" ). af produktet").

Spiralmodellen giver en realistisk tilgang, som udvikler sig som software ; [ 19 ] er meget velegnet til udvikling i stor skala.

Spiralen bruger MCP til at reducere risici og gør det muligt at anvende det på ethvert trin i udviklingen. Den fastholder den klassiske tilgang (vandfald), men inkorporerer en iterativ ramme, der bedre afspejler virkeligheden.

Denne model kræver, at man overvejer tekniske risici i alle faser af projektet; Korrekt anvendt bør det reducere dem, før de bliver et reelt problem.

Den evolutionære model som spiral er særligt velegnet til udvikling af (komplekse) operativsystemer; også i højrisiko- eller kritiske systemer (f.eks. luftfartsbrowsere og controllere) og i alle dem, hvor en stærk styring af projektet og dets risici, teknisk eller ledelsesmæssig, er nødvendig.

Vigtige ulemper :

  • Det kræver stor erfaring og dygtighed i risikovurdering, hvilket er nødvendigt for projektets succes.
  • Det er svært at overbevise store kunder om, at denne evolutionære tilgang kan kontrolleres.

Denne model er ikke blevet brugt så meget som Cascade (Inkrementel) eller MCP , så dens effektivitet er ikke godt målt, det er et relativt nyt paradigme og vanskeligt at implementere og kontrollere.

Win & Win spiralmodel

En interessant variant af Spiralmodellen, der tidligere er set (Figur 6), er "Win-Win Spiral Model" [ 14 ] ( Barry Boehm ). Den tidligere (klassiske) spiralmodel foreslår kommunikation med klienten for at fastlægge kravene, hvor klienten blot bliver spurgt om, hvad han har brug for, og han giver informationen til at fortsætte; men dette er i en ideel sammenhæng, som sjældent sker. Normalt indgår klient og udvikler i en forhandling, omkostninger forhandles mod funktionalitet, ydeevne, kvalitet mv.

"Det er således, at opnåelse af krav kræver en forhandling, som er vellykket, når begge parter vinder."

De bedste forhandlinger er tvunget til at opnå "Victoria & Victoria" (Win & Win), det vil sige, at kunden vinder ved at få det produkt, der tilfredsstiller ham, og udvikleren vinder også ved at få et realistisk budget og leveringsdato. Det er klart, at denne model kræver stærke forhandlingsevner.

Win-Win-modellen definerer et sæt handelsaktiviteter i begyndelsen af ​​hvert trin rundt om spiralen; følgende aktiviteter er defineret:

  1. Identifikation af ledernes nøglesystem eller undersystemer * (ved, hvad de vil have).
  2. Bestemmelse af "sejrsbetingelser" for ledere (ved hvad de har brug for og tilfredsstiller dem)
  3. Forhandling af ledernes «sejr»-betingelser for at opnå «Sejr og sejr»-betingelser (forhandle, så begge vinder).

* Manager: Udvalgt klient med en direkte interesse i produktet, som kan blive belønnet af organisationen, hvis det lykkes eller kritiseres, hvis ikke.

Win & Win-modellen lægger vægt på den indledende forhandling, den introducerer også 3 milepæle i processen kaldet "fikseringspunkter", som hjælper med at etablere afslutningen af ​​en cyklus af spiralen, og giver beslutningsmilepæle, før forhandlingsprojektet fortsættes. softwareudvikling .

Stadier i softwareudvikling

Kravregistrering, analyse og specifikation

I begyndelsen af ​​en udvikling (ikke et projekt) er dette den første fase, der udføres, og afhængigt af den valgte procesmodel kan den næsten ende for at gå videre til næste fase (tilfælde af Feedback Waterfall Model) eller det kan gøres delvist for derefter at vende tilbage til det (tilfælde af iterativ inkrementel model eller andre af evolutionær karakter).

I enkle ord og dybest set i denne fase, er de funktionelle og ikke-funktionelle egenskaber, som det fremtidige program eller system, der skal udvikles, skal opfylde, opsamlet og specificeret.

Fordelene ved egenskaberne, både af systemet eller programmet, der skal udvikles, såvel som dets miljø, ikke-funktionelle parametre og arkitektur, afhænger enormt af, hvor godt dette trin opnås. Dette er nok den vigtigste og en af ​​de sværeste faser at opnå præcist, da det ikke kan automatiseres, det er ikke særlig teknisk, og det afhænger i høj grad af dygtigheden og erfaringen hos den analytiker, der udfører det.

Det involverer i høj grad brugeren eller klienten af ​​systemet, derfor har det meget subjektive nuancer, og det er svært at modellere med sikkerhed eller anvende en teknik, der er "nærmest på den rigtige" (faktisk er der ikke sådan noget som " den rigtige"). Selvom der er blevet udviklet adskillige metoder, herunder supportsoftware , til at indfange, fremkalde og registrere krav, er der ingen ufejlbarlig eller absolut pålidelig måde, og gode kriterier og en masse sund fornuft skal anvendes sammen af ​​analytikeren eller analytikerne med ansvar for krav.opgave; Det er også vigtigt at opnå en flydende og tilstrækkelig kommunikation og forståelse med slutbrugeren eller klienten af ​​systemet.

Den vigtigste artefakt, der er resultatet af færdiggørelsen af ​​denne fase, er det, der er kendt som en softwarekravspecifikation eller blot et ERS-dokument.

Som nævnt er analytikerens evne til at interagere med klienten væsentlig; Det almindelige er, at klienten har et generelt mål eller et problem at løse, han kender slet ikke området (datalogi) eller dets jargon, han ved ikke engang præcist, hvad softwareproduktet skal gøre (hvad og hvor mange funktioner) meget mindre, hvordan den skal fungere. I andre mindre hyppige tilfælde "tror" klienten, at han ved præcist, hvad softwaren skal gøre, og generelt er han meget delvist korrekt, men hans stædighed hindrer udløsningsopgaven. Analytikeren skal have evnen til at håndtere disse typer problemer, som omfatter menneskelige relationer; Du skal vide, hvordan du placerer dig på brugerens niveau for at tillade tilstrækkelig kommunikation og forståelse. [ 20 ]

Der er få situationer, hvor klienten ved med sikkerhed og endda fuldstændig, hvad han kræver af sit fremtidige system, dette er den enkleste sag for analytikeren.

Opgaverne i forbindelse med indfangning, fremkaldelse, modellering og registrering af krav kan, udover at være ekstremt vigtige, blive svære at opnå korrekt og tage lang tid i forhold til den samlede udviklingsproces; Processen og metoderne til at udføre dette sæt af aktiviteter antages normalt at være en del af software engineering , men i betragtning af den førnævnte kompleksitet, omtales det i øjeblikket som krav engineering , [ 21 ] , selvom det endnu ikke eksisterer formelt.

Der er undersøgelses- og forskningsgrupper over hele verden, som udelukkende beskæftiger sig med at udtænke modeller, teknikker og processer for at forsøge at opnå den korrekte opsamling, analyse og registrering af krav. Disse grupper er dem, der normalt taler om kravteknik; det vil sige, at dette betragtes som et område eller en disciplin, men ikke som en universitetskarriere i sig selv.

Nogle krav behøver ikke kundens tilstedeværelse, for at blive fanget eller analyseret; I visse tilfælde kan de foreslås af analytikeren selv eller endda ensidigt vedtage beslutninger, som han finder passende (både i funktionelle og ikke-funktionelle krav). For at nævne sandsynlige eksempler: Nogle systemarkitekturkrav, ikke-funktionelle krav, såsom dem, der er relateret til ydeevne, niveau af operationel fejlsupport, udviklingsplatforme, interne relationer eller links mellem information (mellem poster eller datatabeller) til lagring i databaser eller databaser, etc. Nogle funktionelle, såsom sekundære eller støttemuligheder, der er nødvendige for en bedre eller enklere betjening; etc.

Indhentning af specifikationer fra klienten (eller andre intervenerende aktører) er en meget interaktiv og iterativ menneskelig proces; Normalt, efterhånden som informationen fanges, analyseres den og sendes tilbage med klienten, finpudser den, poleres og korrigeres om nødvendigt; uanset den anvendte ERS- metode . Analytikeren skal altid lære emnet og problemet, der skal løses, at kende, dominere det, til en vis grad, i det omfang det fremtidige system, der skal udvikles, omfatter det. Derfor skal analytikeren have en høj kapacitet til at forstå problemer fra meget forskellige områder eller arbejdsdiscipliner (som ikke specifikt er deres); Således, hvis systemet, der skal udvikles, for eksempel skal være at administrere information fra et forsikringsselskab og dets fjerntliggende filialer, skal analytikeren forstå, hvordan det fungerer og administrerer sin information, fra meget lave niveauer og endda når ledelsesniveauer. I betragtning af den store mangfoldighed af områder, der skal dækkes, assisteres analytikere normalt af specialister, det vil sige folk, der har dyb viden om det område, som softwaren vil blive udviklet til ; Det er klart, at en enkelt person (analytikeren) ikke kan dække et så stort antal vidensområder. I store softwareproduktudviklingsvirksomheder er det almindeligt at have specialiserede analytikere inden for visse arbejdsområder.

Tværtimod er det ikke kundens problem, det vil sige, at han ikke behøver at vide noget om software , design eller andre relaterede ting; det bør kun være begrænset til at levere mål, data og information (af sine egne eller fra sine optegnelser, udstyr, medarbejdere osv.) til analytikeren og guidet af ham, således at han i første omgang definerer « universet af diskurs », og med efterfølgende arbejde var jeg i stand til at udarbejde det relevante ERS- dokument .

Presset på udviklere af computersystemer for at forstå og imødekomme kundernes/brugernes behov er velkendt. Jo mere kompleks konteksten af ​​problemet er, jo sværere er det at opnå, hvilket nogle gange tvinger udviklere til at blive næsten eksperter på de domæner, de analyserer.

Når dette ikke sker, er det meget sandsynligt, at der vil blive genereret et sæt fejlagtige eller ufuldstændige krav [ 22 ] og derfor et softwareprodukt med en høj grad af misbilligelse fra kunder/brugere og meget høje omkostninger til rekonstruktion og vedligeholdelse. Alt, der ikke opdages eller misforstås i den indledende fase, vil forårsage en stærk negativ indvirkning på kravene, sprede denne nedbrydende strøm gennem hele udviklingsprocessen og øge dens skade, jo senere den opdages (Bell og Thayer 1976) (Davis 1993).

Kravfremkaldelsesprocesser, modellering og formularer

Da indfangning, fremkaldelse og specifikation af krav er en afgørende del af softwareudviklingsprocessen , da opnåelsen af ​​de forventede endelige mål afhænger af denne fase, er modeller og forskellige arbejdsmetoder blevet udtænkt til disse formål. Der er også softwareværktøjer, der understøtter de relaterede opgaver, der udføres af kravingeniøren.

IEEE 830-1998 standarden giver en standardisering af "Recommended Practices for Software Requirements Specification ". [ 23 ]

Efterhånden som kravene er opnået, analyseres de normalt, resultatet af denne analyse, med eller uden klienten, afspejles i et dokument, kendt som en ERS eller Software Requirements Specification , hvis struktur kan defineres af forskellige standarder, såsom CMMI .

Et første skridt til at gennemføre undersøgelsen af ​​information er viden og korrekt definition af det, der er kendt som "diskursens univers" af problemet, som defineres og forstås af:

Universe of Discourse (UdeD) : det er den generelle kontekst, hvori softwaren skal udvikles og skal fungere. UofD omfatter alle informationskilder og alle personer relateret til softwaren . Disse mennesker er også kendt som skuespillere i det univers. UdeD er den omstændighed, at den virkelighed er baseret på det sæt af mål, der er defineret af dem, der efterspurgte softwaren .

Fra udvinding og analyse af information inden for sit område opnås alle de nødvendige specifikationer og typer af krav til det fremtidige softwareprodukt .

Formålet med kravsteknik (RI) er at systematisere kravdefinitionsprocessen, hvilket muliggør fremkaldelse, modellering og analyse af problemet, generere et engagement mellem kravingeniørerne og kunderne/brugerne, da begge deltager i genereringen og definitionen af krav til systemkravene. IR giver et sæt metoder, teknikker og værktøjer, der hjælper kravingeniører (analytikere) til at opnå krav, der er så sikre, sandfærdige, fuldstændige og rettidige som muligt, hvilket grundlæggende tillader:

  • forstå problemet
  • Lette indhentning af kundens/brugerens behov
  • Valider med klienten/brugeren
  • Sikring af kravspecifikationer

Selvom der er forskellige måder, modeller og metoder til at fremkalde, definere og dokumentere krav, kan det ikke siges, at den ene af dem er bedre eller dårligere end den anden, de har normalt meget tilfælles, og de opfylder alle det samme formål. Det, der dog uden tvivl kan siges, er, at det er vigtigt at bruge en af ​​dem til at dokumentere specifikationerne for det fremtidige softwareprodukt . Således er der for eksempel en argentinsk forskergruppe, der i flere år har foreslået og studerer brugen af ​​LEL (Extended Lexicon of Language) og Scenarier som metodik, her [ 24 ] er en af ​​de mange referencer og bibliografi om den. præsenteret.. En anden, mere ortodoks måde at indfange og dokumentere krav på kan fås i detaljer, for eksempel i arbejdet fra University of Sevilla om «Methodology for the Analysis of Software Systems Requirements». [ 25 ]

Figur 7 viser et skema, mere eller mindre strengt, men ikke detaljeret, over de trin og opgaver, der skal følges for at registrere, analysere og specificere softwarekrav . Også der kan du se, hvilket artefakt eller dokument der opnås på hvert trin af processen. Diagrammet forklarer ikke metoden eller modellen, der skal bruges, det skitserer blot de opgaver, der skal udføres på en eller anden måde.

Image
Figur 7: Opgavediagram til kravopsamling og analyse.

En mulig liste, generel og ordnet, over anbefalede opgaver for at opnå definitionen af, hvad der skal gøres, de produkter, der skal opnås, og de teknikker, der skal bruges under kravfremkaldelsesaktiviteten i fasen med specifikation af softwarekrav er:

  1. Indhent information om problemdomænet og det aktuelle system (UdeD).
  2. Forberede og afholde møder til elicitation/forhandling.
  3. Identificere/gennemgå brugermål.
  4. Identificere/gennemgå systemmål.
  5. Identificer/gennemgå informationskrav .
  6. Identificere/gennemgå funktionelle krav .
  7. Identificer/gennemgå ikke-funktionelle krav .
  8. Prioriter mål og krav.

Nogle grundlæggende principper at huske på:

  • Præsenter og forstå problemets informationsdomæne fuldt ud.
  • Definer de funktioner, der skal udføres af softwaren korrekt .
  • Repræsenter softwarens adfærd som et resultat af eksterne, særlige, endda uventede hændelser.
  • Genkend ufuldstændige, tvetydige eller modstridende krav.
  • Opdel tydeligt de modeller, der repræsenterer information, funktioner og adfærd og ikke-funktionelle egenskaber.
Klassificering og identifikation af krav

Der kan identificeres to former for krav:

  • Brugerkrav: Brugerkrav er sætninger i naturligt sprog sammen med diagrammer med de tjenester, som systemet skal levere, samt de begrænsninger, det skal fungere under.
  • Systemkrav: Systemkravene bestemmer systemtjenesterne og dog med begrænsningerne i detaljer. De fungerer som en kontrakt.

Det vil sige, at begge er ens, men med forskellig detaljegrad.

Eksempel på brugerkrav: Systemet skal yde lån. Eksempel på systemkrav: Lånefunktion: input partnerkode, eksempelkode; afrejse: hjemrejsedato; etc.

Der er tre typer systemkrav:

  • funktionelle krav

De funktionelle krav beskriver:

  • De tjenester, som systemet (funktioner) tilbyder.
  • Systemets reaktion på visse input.
  • Systemets adfærd i særlige situationer.
  • ikke-funktionelle krav

Ikke-funktionelle krav er begrænsninger på de tjenester eller funktioner, som systemet tilbyder (f.eks. tidsgrænser, udviklingsproces, ydeevne osv.)

Eksempel 1. Centralbiblioteket skal kunne betjene alle universitetets biblioteker samtidigt
Eksempel 2. Svartiden på en fjernforespørgsel bør ikke overstige 1/2 s
Til gengæld er der tre typer ikke-funktionelle krav:
  • Produktkrav. De specificerer produktets adfærd (f.eks. ydeevne, hukommelse, fejlfrekvens osv.)
  • Organisatoriske krav. De er afledt af klient- og udviklerorganisationernes politikker og procedurer (f.eks. processtandarder, programmeringssprog osv.)
  • Eksterne krav. De stammer fra faktorer uden for systemet og udviklingsprocessen (f.eks. lovkrav, etik osv.)
  • Domænekrav.

Domænekrav er afledt af applikationsdomænet og afspejler det pågældende domænes egenskaber.

De kan være funktionelle eller ikke-funktionelle.

For eksempel skal universitetets bibliotekssystem kunne eksportere data gennem det spanske biblioteks interkommunikationssprog (LIBE). F.eks. vil bibliotekssystemet ikke kunne få adgang til biblioteker med censureret materiale.

Systemdesign

I softwareudvikling er design en softwarelivscyklusfase . Det er baseret på kravspecifikationen produceret af kravanalysen (analysefasen), designet definerer hvordan disse krav vil blive opfyldt, den struktur der skal gives til softwaresystemet for at gøre det til virkelighed.

Design forbliver en separat fase fra programmering eller kodning, hvor sidstnævnte svarer til oversættelsen til et givet programmeringssprog af de lokaler, der er vedtaget i designet.

Forskellene mellem de hidtil nævnte aktiviteter er ikke altid så klare, som man kunne ønske sig i klassiske software engineering-teorier . Især design kan beskrive den indre funktion af et system på forskellige detaljeringsniveauer, som hver falder et sted mellem analyse og kodning.

"Arkitektonisk design" forstås normalt som "meget højt niveau" design, som kun definerer systemets struktur i forhold til de softwaremoduler , det er sammensat af, og de makroskopiske forhold mellem dem. Til dette designniveau hører formler som klient-server eller "tre niveauer" eller mere generelt beslutninger om brugen af ​​den specielle hardwarearkitektur, der skal bruges, operativsystemet, DBMS , netværksprotokoller osv.

Et mellemliggende detaljeringsniveau kan definere nedbrydningen af ​​systemet i moduler, men denne gang med en mere eller mindre eksplicit reference til den dekomponeringstilstand, der tilbydes af det bestemte programmeringssprog, som udviklingen skal implementeres med, f.eks. designet med objektteknologi , kunne projektet beskrive systemet i form af klasser og deres indbyrdes sammenhænge.

Detaljeret design er endelig en beskrivelse af systemet, der er meget tæt på kodning (for eksempel beskriver ikke kun klasser i det abstrakte, men også deres attributter og metoder med deres typer).

På grund af softwarens "immaterielle" natur og afhængigt af de værktøjer, der bruges i processen, kan grænsen mellem design og kodning også være praktisk talt umulig at identificere. For eksempel er nogle CASE-værktøjer i stand til at generere kode fra UML-diagrammer, som grafisk beskriver strukturen af ​​et softwaresystem .

Softwarekodning _

I løbet af denne fase udføres de opgaver, der almindeligvis er kendt som programmering ; som i det væsentlige består i at konvertere alt designet i den foregående fase til kildekode, i det valgte programmeringssprog. Denne opgave udføres af programmøren , helt efter de retningslinjer, der er pålagt i designet og altid under hensyntagen til de funktionelle og ikke-funktionelle krav (ERS) specificeret i første fase.

Det er almindeligt at tro, at programmerings- eller kodningsfasen (nogle kalder det implementering) er den, der optager det meste af softwareudviklingsarbejdet ; dette kan dog være relativt (og generelt anvendeligt til små systemer), da de foregående faser er afgørende, kritiske og kan tage meget længere tid. Estimater er normalt lavet af 30% af den samlede tid brugt på programmering, men dette tal er ikke konsistent, da det i høj grad afhænger af systemets karakteristika, dets kritikalitet og det valgte programmeringssprog. [ 14 ] Jo lavere sprogniveau, desto længere kræves programmeringstid, så det vil for eksempel tage længere tid at kode en algoritme i assemblersprog end den samme programmeret i C-sprog .

Mens applikationen, systemet eller softwaren generelt bliver programmeret, udføres også fejlfindingsopgaver, dette er opgaven med at frigøre koden for fejl, der kan findes i denne fase (af semantik, syntaks og logik). Der er en slags overlapning med den næste fase, da debugging af logikken kræver enhedstest, normalt med testdata; Det er klart, at ikke alle fejl kun vil blive fundet i programmeringsfasen, der vil være andre, der vil blive fundet i de efterfølgende faser. Forekomsten af ​​en funktionel fejl (dårlig reaktion på kravene) kan i sidste ende føre til, at man vender tilbage til designfasen, før man fortsætter kodningen.

Under programmeringsfasen kan koden antage forskellige tilstande, afhængigt af måden at arbejde på og det valgte sprog, nemlig:

  • Kildekode : er koden skrevet direkte af programmørerne i teksteditorer, som genererer programmet . Den indeholder et sæt instruktioner, der er kodet på et højt niveau sprog. Det kan distribueres i pakker, procedurer, kildebiblioteker osv .
  • Objektkode : er den binære eller mellemliggende kode, der stammer fra behandling af kildekoden med en compiler . Den består af en komplet og engangsoversættelse af sidstnævnte. Objektkoden kan ikke læses af mennesker (den er normalt i binært format), men den er heller ikke direkte eksekverbar af computeren. Det er en mellemrepræsentation mellem kildekoden og den eksekverbare kode med henblik på en endelig forbindelse med biblioteksrutiner og mellem procedurer eller til brug med en lille mellemfortolker [for forskellige eksempler se EUPHORIA , (mellemfortolker), FORTRAN (ren compiler) MSIL (Microsoft Intermediate Language) (tolk) og BASIC (ren fortolker, mellemfortolker, mellemkompiler eller ren compiler, afhængig af den anvendte version)].
    • Objektkoden eksisterer ikke, hvis programmøren arbejder med et sprog som en ren fortolker , i dette tilfælde er den samme fortolker ansvarlig for at oversætte og udføre kildekoden linje for linje (i henhold til programmets flow), på udførelsestidspunktet . I dette tilfælde eksisterer den eller de eksekverbare kodefiler heller ikke . En ulempe ved denne tilstand er, at afviklingen af ​​programmet eller systemet er lidt langsommere, end hvis det blev gjort med en mellemfortolker, og betydeligt langsommere, end hvis den eller de eksekverbare kodefiler eksisterer. Det vil sige, at det ikke favoriserer ydeevne i udførelseshastighed. Men en stor fordel ved den rene fortolkertilstand er, at denne måde at arbejde på i høj grad letter opgaven med at fejlsøge kildekoden (sammenlignet med alternativet med at gøre det med en ren compiler). Ofte bruges en blandet måde at arbejde på (hvis det valgte programmeringssprog tillader det), det vil sige, at man i første omgang arbejder som en ren fortolker, og når kildekoden er blevet fejlrettet (fri for fejl), er en compiler af samme sprog bruges til at få den komplette eksekverbare kode, som fremskynder fejlfinding og optimerer eksekveringshastigheden.
  • Eksekverbar kode : Det er den binære kode, der er et resultat af at forbinde et eller flere fragmenter af objektkode med de nødvendige rutiner og biblioteker . Det udgør en eller flere binære filer med et format, således at operativsystemet er i stand til at indlæse det i RAM -hukommelsen (muligvis også en del af virtuel hukommelse ), og fortsætte til dens direkte udførelse. Derfor siges den eksekverbare kode at være direkte "forståelig af computeren". Eksekverbar kode, også kendt som maskinkode , findes ikke, hvis den er programmeret i "ren fortolker"-tilstand.

Tests (enhed og integration)

Blandt de forskellige test , der udføres på softwaren , kan følgende skelnes:

  • Enhedstests : De består af test eller test af små stykker software ; på niveau med sektioner, procedurer, funktioner og moduler; dem med specifikke funktioner. Disse tests bruges til at sikre den korrekte funktion af kodesektioner, der er meget mindre end helheden, og som har specifikke funktioner med en vis grad af uafhængighed.
  • Integrationstests : De udføres, når enhedstestene er blevet gennemført med succes ; disse har til formål at sikre, at hele systemet, inklusive de delsystemer, der udgør de store individuelle stykker software , fungerer korrekt, når de opererer og interopererer sammen.

Test udføres normalt med såkaldte testdata , som er et udvalgt sæt typiske data, som systemet, modulerne eller kodeblokkene kan blive udsat for. Også valgt: Data, der fører til softwaregrænsebetingelser for at teste dets tolerance og robusthed; nyttedata til præstationsmålinger; data, der forårsager ualmindelige eventuelle eller særlige forhold, og som softwaren normalt ikke vil være underlagt, men kan forekomme; etc. 'Testdata' er ikke nødvendigvis fiktive eller 'skabte', men typisk er data med lav sandsynlighed for forekomst.

Generelt er der en afsluttende og komplet testfase af softwaren , kaldet Beta Test , hvor det installerede system under normale drifts- og arbejdsforhold testes grundigt for at finde fejl, ustabiliteter, fejlagtige svar osv. at de tidligere kontroller er bestået. Disse udføres normalt af egnet personale, der er ansat eller specifikt berørt af det. Mulige fejl, der er fundet, videregives til udviklerne til fejlretning. I tilfælde af "on-demand"-udviklingssoftware er slutbrugeren ( klienten ) den, der udfører Beta-testen, med en prøveperiode aftalt med udvikleren.

Installation og flytning til produktion

Softwareinstallation er den proces , hvorved de udviklede programmer på passende måde overføres til destinationscomputeren, initialiseres og til sidst konfigureres ; alt med det formål at blive brugt af slutbrugeren. Det udgør den sidste fase i selve udviklingen af ​​softwaren . Herefter vil produktet gå ind i drifts- og produktionsfasen, som det er designet til.

Installationen kan, afhængigt af det udviklede system, bestå af en simpel kopi til destinationsharddisken (i øjeblikket sjældne tilfælde); eller mere almindeligt med en af ​​mellemliggende kompleksitet, hvor de forskellige komponentfiler i softwaren (eksekverbare filer, biblioteker , egne data osv.) dekomprimeres og kopieres til bestemte forud-etablerede steder på disken; links oprettes endda med andre produkter, ud over selve operativsystemet . Dette sidste tilfælde er normalt en ret automatisk proces, der oprettes og guides med specifikke softwareværktøjer ( pakke og distribution, installatører ).

I mere komplekse produkter er det andet alternativ det, der bruges, men det udføres eller guides af specialister; det kan endda kræve installation på flere forskellige computere (distribueret installation).

Også i software af middel og høj kompleksitet kræves der normalt en konfigurations- og kontrolproces , hvorved passende driftsparametre tildeles, og produktets funktionelle funktionalitet testes.

I massesælgende produkter udføres komplette installationer, hvis de er relativt enkle, normalt af slutbrugerne selv (såsom operativsystemer, kontorpakker, hjælpeprogrammer osv.) med deres egne guidede installationsværktøjer; selv konfigurationen er normalt automatisk. I produkter af specifikt design eller "tilpasset" er installationen normalt begrænset til specialister involveret i udviklingen af ​​den pågældende software .

Når softwaren er blevet installeret med succes , går den til produktionsfasen (drift), hvor den opfylder de funktioner, som den er udviklet til, det vil sige, at den endelig bliver brugt af slutbrugeren(e), og producerer de forventede resultater.

Vedligeholdelse

Softwarevedligeholdelse er processen med kontrol, forbedring og optimering af den software , der allerede er udviklet og installeret, hvilket også omfatter fejlretning af fejl og defekter, der kan være lækket fra kontrol- og betatestfasen. Denne fase er den sidste (før iteration, afhængigt af den anvendte model), der anvendes på softwareudviklingens livscyklus . Vedligeholdelsesfasen er den, der kommer efter, at softwaren er operationel og i produktion.

Vedligeholdelsesfasen vil afhænge af en god design- og udviklingsdokumentation, både hvad angår tid og penge. Ændringer af software , der er udviklet med forkert eller dårlig dokumentation og dårligt design, kan være lige så dyre eller dyrere end at udvikle softwaren fra bunden. Af denne grund er det af grundlæggende betydning at respektere alle opgaver i udviklingsfaserne og opretholde tilstrækkelig og fuldstændig dokumentation.

Perioden i vedligeholdelsesfasen er normalt den længste i hele livscyklussen. [ 14 ] Denne fase involverer også softwareopgraderinger og udviklinger ; det betyder ikke nødvendigvis, at systemet havde fejl. En eller flere ændringer i softwaren , for eksempel adaptiv eller evolutionær, kan endda føre til revision og tilpasning fra en del af de første faser af den indledende udvikling, og ændrer alle de andre; afhængig af hvor dybe ændringerne er. Den almindelige vandfaldsmodel er særlig dyr at vedligeholde, da dens stivhed indebærer, at enhver ændring medfører tilbagevenden til startfasen og kraftige ændringer i de øvrige faser af livscyklussen.

Under vedligeholdelsesvinduet er det almindeligt, at nye revisioner og versioner af produktet dukker op; der frigiver det mere raffineret, med større og bedre funktionalitet, bedre ydeevne osv. Der er flere facetter, der kan ændres for at forårsage ønskelige, evolutionære ændringer, tilpasninger eller udvidelser og forbedringer.

Grundlæggende er der følgende typer ændringer:

  • Perfekt: De, der fører til en forbedring af den interne kvalitet af softwaren i ethvert aspekt: ​​Omstrukturering af koden, klarere definition af systemet og dets dokumentation; optimering af ydeevne og effektivitet.
  • Evolutionært: Tilføjelser, modifikationer, endda elimineringer, nødvendige i softwaren for at dække dens udvidelse eller ændring, alt efter brugerens behov.
  • Adaptive: Ændringer, der påvirker de miljøer, som systemet fungerer i, såsom: Hardwarekonfigurationsændringer (til opdatering eller forbedring af elektroniske komponenter), ændringer i basissoftwaren , i databaseadministratorer, i kommunikation osv.
  • Korrigerende: Ændringer, der er nødvendige for at rette fejl af enhver art i det udviklede softwareprodukt .

Evolutionær karakter af software

Software er biproduktet af udviklingsprocessen, ifølge software engineering . Dette produkt er i sig selv evolutionært i løbet af dets livscyklus: generelt udvikler det sig til at generere versioner, der er mere og mere komplette, komplekse, forbedrede, optimeret i et eller andet aspekt, egnede til nye platforme (uanset om det er hardware eller operativsystemer) osv. [ 26 ]

Når et system holder op med at udvikle sig, vil det i sidste ende fuldføre sin livscyklus, blive forældet og uundgåeligt, før eller siden, blive erstattet af et nyt produkt.

Software udvikler sig simpelthen fordi den skal tilpasse sig ændringer i miljøet, hvad enten de er funktionel (brugerkrav), operationel, platform eller hardwarearkitektur .

Softwareevolutionens dynamik er studiet af systemændringer. Det største bidrag på dette område blev ydet af Meir M. Lehman og Belady , begyndende i 1970'erne og 1980'erne. Deres arbejde fortsatte ind i 1990'erne med Lehman og andre forskere [ 27 ] af relevans for feedback i evolutionsprocesser (Lehman, 1996; Lehman et al., 1998; Lehman et al., 2001). Fra disse undersøgelser foreslog de et sæt love (kendt som Lehmans love ) [ 17 ] vedrørende ændringerne i systemerne. Disse love (faktisk hypoteser) er invariante og bredt anvendelige.

Lehman og Belady analyserede væksten og udviklingen af ​​flere store softwaresystemer ; endelig udlede, ifølge deres mål, følgende otte love:

  1. Kontinuerlig ændring: Et program, der bruges i et virkeligt miljø, skal nødvendigvis ændre sig, ellers bliver det gradvist mindre nyttigt i det miljø.
  2. Stigende kompleksitet: Efterhånden som et udviklende program ændrer sig, har dets struktur en tendens til at blive mere og mere kompleks. Der skal afsættes ekstra ressourcer til at bevare og forenkle strukturen.
  3. Forlænget programudvikling: Programudvikling er en selvregulerende proces. Systemattributter såsom størrelse, tid mellem udgivelser og antallet af dokumenterede fejl er tilnærmelsesvis invariable for hver systemudgivelse.
  4. Organisatorisk stabilitet: I løbet af et programs levetid er dets udviklingshastighed omtrent konstant og uafhængig af de ressourcer, der er dedikeret til udviklingen af ​​systemet.
  5. Bevarelse af fortrolighed: I løbet af et systems levetid er den trinvise ændring i hver udgivelse omtrent konstant.
  6. Kontinuerlig vækst: Den funktionalitet, som systemerne tilbyder, skal vokse kontinuerligt for at opretholde brugertilfredsheden.
  7. Fald i kvalitet: Kvaliteten af ​​softwaresystemer vil begynde at falde, medmindre disse systemer tilpasser sig ændringer i deres driftsmiljø.
  8. Systemfeedback: Evolutionsprocesser inkorporerer multi-agent og multi-loop feedback-systemer, og disse skal behandles som feedback-systemer for at opnå væsentlig produktforbedring.

Referencer

  1. ↑ Ordbog over det spanske sprog 2005 (2010). wordreference.com, red. "software" (ordbog) . Espasa-Calpe . Hentet 1. februar 2010 . 
  2. ^ "SYSTEMSOFTWARE" . 30. maj 2001. Arkiveret fra originalen 30. maj 2001 . Hentet 10. februar 2018 . 
  3. ↑ «Onderwijs Informatica in Informatiekunde | Institut for Informations- og Datavidenskab» . www.cs.uu.nl. _ Hentet 10. februar 2018 . 
  4. ↑ Det kongelige spanske akademi og sammenslutningen af ​​akademier for det spanske sprog. "software" . Ordbog over det spanske sprog (23. udgave) . Hentet 14. marts 2008 . 
  5. ↑ Royal Spanish Academy and Association of Academy of the Spanish Language (2005). "software" . Panhispansk ordbog af tvivl . Madrid: Santillana. ISBN  978-8-429-40623-8 . Hentet 8. februar 2009 . 
  6. ^ Pressman, Roger S. (2003). "Produktet". Software Engineering, A Practical Approach, Fifth Edition Edition . Mexico: McGraw Hill.  
  7. ↑ Pierre Mounier-Kuhn, L'informatique en France, de la seconde guerre mondiale au Plan Calcul. L'emergence d'une science , Paris, PUPS, 2010, kap. Fire.
  8. ↑ IEEE Std, IEEE Software Engineering Standard: Ordliste over Software Engineering Terminology. IEEE Computer Society Press, 1993
  9. ^ "Softwaredefinition" . 
  10. ^ "Softwareklassificeringskomponenter" . 
  11. ↑ Global Euroworld. "Brugen af ​​software reducerer fejl i lønstyring betydeligt" . Hentet 10. december 2019 . 
  12. ↑ Fernandez af rosens buste, Gabriela. IKT i undervisningen . 
  13. ↑ a b c d e f g h i j k "Software Life Cycle" . Grupo Alarcos - Higher School of Computing i Ciudad Real. Arkiveret fra originalen den 14. juni 2013. 
  14. ↑ abcde Pressman , Roger S. (2003). "Processen". Software Engineering, A Practical Approach, Fifth Edition Edition . Mexico: McGraw Hill.  
  15. ↑ a b c d Alejandro Gutiérrez Díaz. "Avanceret Software Engineering" . 
  16. ^ "Udtrykket "fremkalde " " . 1. betydning - Wiktionary Hentet 15. december 2008 . 
  17. ↑ a b c d «Softwareudviklingslove» . Forbindelser - Pædagogisk indholdsarkiv. 
  18. ↑ a b c d e f g h i "Software Life Cycle and Development Models" . Erhvervsuddannelsesinstituttet - Digitale Bøger. Arkiveret fra originalen 2010-02-15. Tekst "sted: Asunción del Paraguay" ignoreret ( hjælp ) 
  19. ↑ a b c "Softwareudvikling" . Forbindelser - Pædagogisk indholdsarkiv. 
  20. ↑ Adolfo González Marín, Gustavo. SOFTWARE TIL KONTROL OG STYRING AF DATAFLOW I SIMETRIA-SELSKABETS PRODUKTIONSOMRÅDE OG LAGEHUS . Pereira. 
  21. ↑ Software Requirements Engineering, 2nd Edition, IEEE Computer Society. Los Alamitos, CA, 1997 (Kompendium af artikler og artikler om kravteknik)
  22. ^ "III Krav Engineering Workshop" . WER 2000, Rio de Janeiro, 2000. 
  23. ^ "Anbefalet praksis for softwarekravspecifikation" . IEEE-SA Standards Board . 
  24. ↑ «LEL og scenarier som metodik i kravteknik» . University of Moron, Buenos Aires. Arkiveret fra originalen den 28. juli 2011 . Hentet 23. juli 2008 . 
  25. ↑ «Metode til analyse af softwaresystemkrav» . Universitetet i Sevilla, 2001.  
  26. ^ Sommerville, Ian (2005). "21-Evolution af software". Software Engineering . Spanien: Pearson Education S.A.  
  27. ^ "ACM Fellow-profil for Meir M. (Manny) Lehman" . ACM . 31. maj 2007. Arkiveret fra originalen 28. september 2011 . Hentet 27. november 2011 . 

Bibliografi

Bøger

  • JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James (2000). Den fælles softwareudviklingsproces . Pearson Addison-Wesley. 
  • Pressman, Roger S. (2003). Software Engineering, A Practical Approach (femte udgave). McGraw Hill. ISBN  84-481-3214-9 . 
  • JACOBSON; BOOCH; RUMBAUGH (1999). UML - The Unified Modeling Language . Pearson Addison-Wesley. Rational Software Corporation, Addison Wesley Iberoamericana. ISBN  84-7829-028-1 . 
  • Haeberer, AM; PAS Veloso, G. Baum (1988). Formalisering af softwareudviklingsprocessen (Foreløbig udgave). Buenos Aires: Kapelusz. ISBN  950-13-9880-3 . 
  • Fowler, Martin; Kendall Scott (1999). UML Dråbe for Dråbe . Addison Wesley. ISBN  9789684443648 . 
  • Loucopoulos, Pericles; Karakostas, V. (1995). Systemkrav Engineering . London: McGraw-Hill Companies. pp. 160p ISBN  978-0077078430 . 
  • Gottesdiener, Ellen; P. Sawyer (2002). Krav ved samarbejde : Workshops til at definere behov . Addison-Wesley Professional. pp. 368 sider ISBN  978-0201786064 . Hentet 2008 . 
  • Sommerville, Ian (2005). Software Engineering (7. udgave). Madrid: Pearson Education S.A. ISBN  84-7829-074-5 . 

Artikler og magasiner

  • Weitzenfeld - "Processen til softwareudvikling" - 2002
  • Carlos Reynoso - «Heterodox Methods in Software Development» - 2004
  • ISSI Group - Polytekniske Universitet i Valencia - «Agile metoder i softwareudvikling» - 2003
  • Martin Fowler - "Den nye metode" - 2003
  • Cutter IT Journal – «Requirements Engineering and Management». 25. august 2000. Kutterkonsortium.
  • "Software Requirements Engineering," 2nd Edition, IEEE Computer Society. Los Alamitos, CA, 1997 (Kompendium af artikler og artikler om kravteknik).
  • Lehman, MM - «Laws of Software Evolution Revisited», pos. pap., EWSPT96, okt. 1996, LNCS 1149, Springer Verlag, 1997, s. 108-124

Se også

Livscyklusmodeller

Eksterne links

Hentet fra « https://es.wikipedia.org/w/index.php?title=Software&oldid=146550099 »