Software Engineering

programvareutvikling _
kunnskapsområder Databehandling
omfang Utvikling av applikasjonsprogramvare ,
systemprogramvareutvikling ,
webutvikling , mobilapplikasjonsutvikling ,
grafisk programvareutvikling ,
desktop applikasjonsutvikling , chatbotutvikling ,
blokkjedeutvikling
, beregningsfysikk
programvareutvikling ,
beregningsbasert kjemi programvareutvikling , maskinsynsutvikling
, robotprogramvareutvikling , biomedisinsk programvareutvikling , Industriell operativ programvareutvikling


, Ingeniørprogramvareutvikling ,
Anvendelser av kunstig intelligens
delområde av Datavitenskap

Software Engineering er en av grenene innen informatikk som studerer etableringen av pålitelig programvare av høy kvalitet, basert på tekniske metoder og teknikker, og som gir drifts- og vedlikeholdsstøtte . Studieretningen programvareteknikk [ 1 ] integrerer informatikk , anvendt vitenskap og de grunnleggende vitenskapene som ingeniørfaget er basert på . [ 2 ]

De mest anerkjente definisjonene er sitert, formulert av følgende prestisjetunge forfattere:

I 2004 talte US Bureau of Labor Statistics 760 840 programvareingeniører . [ 4 ] [ oppdatering ]

Begrepet " programvareingeniør " brukes imidlertid generisk i forretningsmiljøet, og ikke alle i programvareingeniørstillingen har faktisk ingeniørgrader fra anerkjente universiteter. [ 5 ]

Noen forfattere anser " programvareutvikling " for å være et mer passende begrep enn " programvareutvikling " for prosessen med å lage programvare . Folk som Pete McBreen (forfatter av Software Craftmanship ) mener at begrepet IS innebærer nivåer av strenghet og prosesstesting som ikke er passende for alle typer programvareutvikling .

Begrepene "programvareteknikk " eller " programvareteknikk " brukes om hverandre ; selv om det er mindre vanlig, blir det også ofte referert til som " software engineering ". [ 6 ]​ [ 7 ]​ [ 8 ]​ I Latin-Amerika er de mest brukte termene de to første.

Opprettelsen av programvare er en i seg selv kreativ prosess og programvareteknikk prøver å systematisere denne prosessen for å begrense risikoen for å ikke oppnå målet, gjennom ulike teknikker som har vist seg å være tilstrekkelig basert på erfaring.

Software engineering kan betraktes som engineering brukt på programvare , det vil si ved systematiserte midler og med forhåndsetablerte verktøy, anvende dem på den mest effektive måten for å oppnå optimale resultater; mål som ingeniør alltid søker. Det handler ikke bare om problemløsning , men heller å vurdere de forskjellige løsningene og velge den mest passende.

Programvareproduksjon bruker programvaretekniske kriterier og standarder , som gjør at det kan transformeres til et industrielt produkt ved å bruke ingeniørbaser som metoder, teknikker og verktøy for å utvikle et innovativt produkt styrt av metoder og god praksis. Dette produktet er et middel som griper inn i funksjonene til brukerne for å oppnå en mer effektiv og effektiv produksjonsprosess; i dag kunne bedrifter ikke fungere uten programvare fordi dette er et produkt av massiv bruk; derfor bestemmes nivået til et selskap av kvaliteten på dens teknologiske infrastruktur og produktene utviklet eller anskaffet i henhold til dets behov.

Historikk

Da de første digitale datamaskinene dukket opp på 1940-tallet, [ 9 ] var programvareutvikling så ny at det var nesten umulig å forutsi prosjektgjennomføringsdatoer, og mange prosjekter gikk over budsjetter og over tid. Utviklere måtte skrive om alle programmene sine for å kjøre på nye maskiner som kom ut hvert eller hvert annet år, noe som gjorde eksisterende foreldet.

Begrepet programvareteknikk dukket først opp på slutten av 1950-tallet. Programvareutvikling ble stimulert av programvarekrisen på 1960- og 1980-tallet. Programvareteknikk kommer for å hjelpe til med å identifisere og korrigere prosessene for utvikling og vedlikehold av programvaresystemer gjennom prinsipper og metoder .

Bortsett fra programvarekrisen i tiårene mellom 1960 og 1980, er programvareutvikling påvirket av ulykker som førte til at tre mennesker døde; dette skjedde når strålebehandlingsmaskinen Therac-25 sender ut en massiv overdose med stråling og påvirker livene til disse menneskene. [ 10 ] Dette fremhever risikoen ved programvarekontroll , [ 11 ] som direkte påvirker navnet på programvareutvikling .

På begynnelsen av 1980-tallet [ 12 ] hadde programvareingeniør allerede dukket opp som et genuint yrke, for å stå ved siden av tradisjonell informatikk og ingeniørfag. Før dette ble jobber kjørt ved å legge hullkort som input i maskinens kortleser og avvente resultatene som ble returnert av skriveren.

På grunn av behovet for ofte å oversette gammel programvare for å betjene behovene til nye maskiner, ble det utviklet språk av høyere orden. Etter hvert som fri programvare dukket opp , ga brukerorganisasjoner den ofte ut.

I lang tid var løsningen av programvarekrisen av største betydning for forskere og selskaper som var dedikert til å produsere programvareverktøy .

På 1980-tallet var kostnadene for å eie og vedlikeholde programvare dobbelt så dyre som programvareutviklingen i seg selv , og i løpet av 1990-tallet økte kostnadene for å eie og vedlikeholde programvare med 30 % i løpet av det foregående tiåret. I 1995 var mange av utviklingsprosjektene i drift, men ble ikke ansett som vellykkede. Gjennomsnittlig programvareprosjekt overskred med 50 % av tidsestimatet tidligere gjort, i tillegg hadde 75 % av alle store programvareprodukter som ble levert til klienten så alvorlige feil at de ikke ble brukt i det hele tatt eller rett og slett ikke var i samsvar med kunden. krav.

Noen eksperter hevdet at programvarekrisen skyldtes programmerernes mangel på disiplin.

Hver ny teknologi og praksis fra 1970- til 1990-tallet ble kunngjort som den eneste løsningen på alle problemene og kaoset som førte til programvarekrisen . Sannheten er at søket etter én enkelt nøkkel til suksess aldri fungerte. Feltet programvareteknikk virker for komplekst og stort til at en enkelt løsning kan forbedre de fleste problemer, og hvert problem representerer bare en liten del av alle programvareproblemer .

Bommen i bruken av Internett førte til en svimlende vekst i etterspørselen etter internasjonale informasjonsskjermsystemer på World Wide Web. Utviklere fikk i oppgave å håndtere illustrasjoner, kart, bilder og animasjoner i en hastighet som aldri er sett før, med nesten ingen metode for å optimalisere bildevisning og lagring. Det var også nødvendig med systemer for å oversette informasjonsflyten på flere fremmedspråk til menneskelig naturlig språk, med mange programvaresystemer designet for flerspråklig bruk, basert på menneskelige oversettere.

Programvareutvikling bidro med rundt 90 milliarder dollar per år, siden Internett kom inn. Dette gjør at utviklere må håndtere bildekart og animasjoner for å optimalisere visning/lagring av bilder (som bruk av miniatyrbilder). Bruken av nettlesere og bruken av HTM L-språket endrer synet og mottaket av informasjon drastisk.

Omfattende nettverkstilkoblinger forårsaket spredning av datavirus og søppelpost eller spam i elektronisk post ( e- post ). Denne situasjonen satte utviklere i et kappløp mot tiden for å lage nye blokkerings- eller sikkerhetssystemer for nevnte dataavvik, siden de ble ekstremt kjedelige og vanskelige å fikse.

Etter en sterk og økende etterspørsel, oppstår behovet for å lage rimelige programvareløsninger, noe som fører til bruk av enklere og raskere metodikk som utvikler funksjonell programvare . Det skal bemerkes at mindre systemer hadde en enklere og raskere tilnærming til å kunne styre utviklingen av programvareberegninger og algoritmer .

Mål

Programvareteknikk bruker forskjellige standarder og metoder som gjør det mulig å oppnå bedre resultater, når det gjelder utvikling og bruk av programvare , gjennom korrekt anvendelse av disse prosedyrene er det mulig å tilfredsstille de grunnleggende målene for programvareutvikling .

Blant målene med programvareutvikling er:

Ressurser

Menneskelige ressurser

Se også: Menneskelige ressurser

De er alle de personene som er involvert i planleggingen av programvareforekomster (for eksempel: leder, erfaren programvareingeniør , etc.), Antall personer som kreves for et programvareprosjekt kan bare bestemmes etter å ha estimert innsatsen for utvikling ...

Miljøressurser

Det er miljøet til applikasjonene ( programvare og maskinvare ) maskinvaren gir de fysiske midlene til å utvikle applikasjonene ( programvare ), denne ressursen er viktig. [ 14 ]

Sosioøkonomiske implikasjoner

Økonomisk

I USA bidro programvare med en åttendedel av all BNP-vekst på 1990-tallet (omtrent 90 milliarder dollar per år), og en niendedel av all produktivitetsvekst i løpet av de siste årene av tiåret. . Programvareutvikling bidro til 1 billion dollar av økonomisk vekst og produktivitet i det tiåret. Rundt om i verden bidrar programvare til økonomisk vekst på lignende måter, selv om pålitelig statistikk er vanskelig å finne. [ referanse nødvendig ]

I tillegg finner den med språkindustrien flere og flere bruksområder på global skala.

Sosialt

Programvareteknikk endrer kulturen i verden på grunn av den utbredte bruken av datamaskinen . Elektronisk post (e-post), WWW og direktemeldinger lar folk samhandle på nye måter. Programvaren senker kostnadene og forbedrer kvaliteten på helsetjenester, brannvesen, offentlige etater og andre sosiale tjenester. Vellykkede prosjekter der programvareutviklingsmetoder har blitt brukt inkluderer GNU/Linux , Space Shuttle- programvare , minibanker og mange andre.

Notasjoner

LUM (Unified Modeling Language) eller UML

Det er et allment anerkjent og for tiden brukt modelleringsspråk som brukes til å beskrive eller spesifisere metoder. Det er også anvendelig i programvareutvikling .

Akronymet UML står for Unified Modeling Language, dette betyr at det ikke er ment å definere en standard utviklingsmodell, men kun et modelleringsspråk. [ 15 ]

Et modelleringsspråk består av synspunkter, modellelementer og et sett med syntaktiske, semantiske og pragmatiske regler som indikerer hvordan elementene skal brukes.

I denne saken finner vi flere diagrammer som kan brukes som: use cases , classes , komponenter , deployment , etc.

BPMN (Business Process Modeling Notation)

Målet med notasjonen for forretningsprosessmodellering er å gi en enkel måte å definere og analysere offentlige og private forretningsprosesser ved å simulere et flytskjema . Notasjonen er spesielt designet for å koordinere sekvensen av prosesser og meldinger som flyter mellom prosessdeltakere, med et sett med relaterte aktiviteter. Grunnleggende egenskaper ved BPMN-elementer

Dataflytdiagram (DFD)

Et dataflytdiagram lar deg representere bevegelsen av data gjennom et system ved hjelp av modeller som beskriver datastrømmene, prosessene som transformerer eller endrer dataene, datadestinasjonene og datalagrene den har tilgang til systemet.

Dens oppfinner var Larry Constantine , basert på Martin og Estrins beregningsmodell: grafdataflyt. Med dataflytdiagrammer bestemmer du hvordan ethvert system kan utvikles, bistår med å identifisere transaksjonsdataene i datamodellen, og gir brukeren en fysisk ide om hvordan dataene til slutt vil slå ut. [ 16 ]

CASE-verktøy

CASE Tools er beregningsverktøy ( programvare ) som er ment å bistå i livssyklusprosessene til programvare , lette produksjonen av programvare , flere er hovedsakelig basert på ideen om en grafisk modell. [ 17 ]

Metodikk

Et mål i flere tiår har vært å finne prosesser og metoder som er systematiske, forutsigbare og repeterbare, for å forbedre produktiviteten i utviklingen og kvaliteten på programvareproduktet , kort sagt, det bestemmer trinnene som skal følges og hvordan de skal utføres for å fullføre en hjemmelekse.

Prosessstadier

Programvareutvikling krever å utføre en rekke oppgaver gruppert i stadier, settet med disse stadiene kalles livssyklusen . Stadiene som er felles for nesten alle livssyklusmodeller er som følger:

Innhenting av kravene

Det som jobbes med må identifiseres, det vil si hovedproblemstillingen som motiverer studiestart og opprettelse av ny programvare eller modifikasjon av eksisterende. I sin tur identifisere ressursene som er tilgjengelige, dette inkluderer å kjenne til de menneskelige og materielle ressursene som deltar i utviklingen av aktivitetene. Det er viktig å forstå forretningskonteksten for å identifisere krav på riktig måte.

Du må beherske informasjonen om et problem, som inkluderer data utenfor programvaren (sluttbrukere, andre systemer eller eksterne enheter), data som kommer ut av systemet (gjennom brukergrensesnittet, nettverksgrensesnitt, rapporter, grafikk og andre medier). ) og datalagre som samler inn og organiserer vedvarende dataobjekter (for eksempel de som holdes permanent).

Det er også nødvendig å se de kritiske punktene, som betyr å ha på en klar måte de aspektene som hindrer og begrenser at gjeldende prosedyrer fungerer, de vanligste og mest relevante problemene som oppstår, årsakene som skaper misnøye og de som bør fullt dekket. For eksempel: Dekker innholdet i de genererte rapportene virkelig brukerens behov? Er responstidene tilbudt rettidig?, osv.

Det er nødvendig å definere funksjonene som programvaren skal utføre siden disse hjelper sluttbrukeren og driften av selve programmet.

Du må ta hensyn til hvordan programvaren vil oppføre seg i uventede situasjoner, for eksempel et stort antall brukere som bruker programvaren eller en stor mengde data, blant annet.

Kravanalyse Å trekke ut kravene til et programvareprodukt er det første trinnet i å lage det. Under analysefasen oppgir klienten hvilke behov som oppstår og forsøker å forklare hva programvaren eller sluttproduktet skal gjøre for å tilfredsstille nevnte behov mens utvikleren fungerer som en avhører, som den som løser problemer. Med denne analysen kan systemingeniøren velge funksjonen som programvaren skal utføre og etablere eller indikere hvilket som er best egnet grensesnitt for den. [ 18 ]

Kravanalyse kan virke som en enkel oppgave, men det er ikke fordi mange ganger kunder tror de vet alt programvaren trenger for at den skal fungere, men det kreves ferdigheter og erfaring fra en spesialist for å gjenkjenne ufullstendige krav. , tvetydige eller motstridende. Disse kravene bestemmes under hensyntagen til behovene til sluttbrukeren, og introduserer teknikker som lar oss forbedre kvaliteten på systemene vi jobber med. [ 19 ]

Resultatet av kravanalysen med klienten gjenspeiles i ERS-dokumentet (systemkravspesifikasjon), hvis struktur kan defineres av ulike standarder, for eksempel CMMI . På samme måte er det definert et enhets-/relasjonsdiagram , der hovedenhetene som skal delta i utviklingen av programvaren reflekteres .

Innsamling, analyse og spesifikasjon av krav (til og med tester av dem), er en avgjørende del; Oppnåelsen av de endelige målene avhenger i stor grad av dette stadiet. Modeller og ulike metodiske arbeidsprosesser er utviklet for disse formålene. Selv om det ikke er formalisert ennå, er det allerede snakk om kravteknikk .

IEEE Std. 830-1998 standardiserer opprettelsen av programvarekravsspesifikasjoner .

Formål med kravanalyse:

  • Gi brukeren alt nødvendig slik at han kan jobbe sammen med den utviklede programvaren og oppnå best mulig resultater.
  • Ha en mer fullstendig kontroll i programvareopprettingsstadiet , når det gjelder utviklingstid og kostnader.
  • Bruk av mer effektive metoder som tillater best mulig bruk av programvaren avhengig av formålet med bruken.
  • Øk kvaliteten på programvaren som er utviklet ved å redusere risikoen for funksjonsfeil. [ 19 ]

Ikke alltid i «kravanalyse»-stadiet er de ulike utviklingsmetodikkene knyttet til en mulighetsstudie og/eller kostnadsestimat. Den mest kjente av programvarekostnadsberegningsmodellene er COCOMO- modellen.

Begrensninger [ 20 ]

Programvare har evnen til å etterligne intelligens ved å lage en modell av visse kjennetegn ved menneskelig intelligens, men den har bare forhåndsdefinerte funksjoner som omfatter et sett med løsninger som på noen felt blir begrenset. Selv når den har evnen til å imitere visse menneskelige atferder, er den ikke i stand til å etterligne menneskelig tanke fordi den handler under forhold.

Et annet begrensende aspekt ved programvaren kommer fra den helt mekaniske prosessen som krever større innsats og høye utførelsestider, noe som fører til at man må implementere programvaren på en maskin med større kapasitet.

Spesifikasjon

Kravspesifikasjonen beskriver forventet oppførsel til programvaren når den er utviklet. Mye av suksessen til et programvareprosjekt vil ligge i identifiseringen av forretningsbehov (definert av toppledelsen), samt samhandlingen med funksjonelle brukere for innsamling, klassifisering, identifikasjon, prioritering og spesifikasjon av programvarekrav .

Blant teknikkene som brukes for spesifikasjon av krav er:

Å være den første mer streng og formell, den andre mer smidig og uformell.

Arkitektur

Integrasjonen av infrastruktur, applikasjonsutvikling, databaser og styringsverktøy krever kapasitet og lederskap for å kunne konseptualiseres og projiseres inn i fremtiden, og løse dagens problemer. Rollen som alle disse aktivitetene er delegert til er arkitektens.

Programvarearkitekten er personen som tilfører verdi til forretningsprosesser takket være hans verdifulle bidrag av teknologiske løsninger.

Systemarkitektur generelt er en planleggingsaktivitet, enten på maskinvare- og nettverksinfrastrukturnivå , eller på programvarenivå .

Hovedsaken på dette punktet er å avklare de logiske og fysiske aspektene ved utgangene, organisasjonsmodellene og datarepresentasjonen, innganger og prosesser som utgjør systemet, med tanke på fordelene og begrensningene til de tilgjengelige ressursene for å tilfredsstille pasifikasjonene som tilbys. for analyse.

Du må ta hensyn til arkitekturen til systemet du skal jobbe i, utarbeide en arbeidsplan med tanke på prioritering av tid og tilgjengelige ressurser. I output-designene er kravtolkningen inkludert, som er informasjonsdomenet til problemet, funksjonene som er synlige for brukeren, oppførselen til systemet og et sett med kravklasser som grupperer forretningsobjektene med metodene som betjener dem.

Programvarearkitektur består av design av applikasjonskomponenter (forretningsenheter), vanligvis ved bruk av arkitektoniske mønstre . Den arkitektoniske utformingen skal tillate visualisering av samspillet mellom forretningsenhetene og også kunne valideres, for eksempel ved hjelp av sekvensdiagrammer. Et arkitektonisk design beskriver generelt hvordan en programvareapplikasjon skal bygges . Dette er dokumentert ved hjelp av diagrammer, for eksempel:

Klasse- og databasediagrammer er det minimum som er nødvendig for å beskrive arkitekturen til et prosjekt som skal begynne å bli kodet. Avhengig av prosjektets omfang, kompleksitet og behov vil arkitekten velge hvilke av diagrammene som skal utdypes.

Verktøyene for programvaredesign og modellering kalles CASE ( Computer Aided Software Engineering ) blant dem:

  • Enterprise Architect
  • Microsoft Visio for Enterprise Architects
Programmering

Implementering av et design i kode kan være den mest åpenbare delen av programvareingeniørarbeid , men det er ikke nødvendigvis den mest arbeidskrevende eller kompliserte. Kompleksiteten og varigheten av dette stadiet er nært knyttet til programmeringsspråket( e) som brukes, samt designen som tidligere ble utført.

Applikasjonsutvikling

For utviklingen av applikasjonen er det nødvendig å vurdere fem faser for å ha en effektiv applikasjon eller program, disse er:

  • Infrastrukturutvikling: Denne fasen tillater utvikling og organisering av elementene som skal danne applikasjonsinfrastrukturen, med det formål å fullføre applikasjonen effektivt.
  • Tilpasning av pakken: Hovedmålet med denne fasen er å forstå på en detaljert måte driften av pakken, dette har som formål å garantere at pakken kan brukes med maksimal ytelse, både for virksomheter eller ressurser. Alle elementene som utgjør pakken blir inspisert i detalj for å unngå feil og bedre forstå alle egenskapene til pakken.
  • Utvikling av interaktive designenheter: I denne fasen gjennomføres prosedyrene som utføres av en bruker-system-dialog. Prosedyrene i denne fasen har som hovedmål:
  1. Bestem spesifikt handlingene som skal utføres av designenheten.
  2. Opprette komponenter for prosedyrene dine.
  3. Kjør enhets- og integrasjonstester på designenheten.
  • Utvikling av batchdesignenheter: I denne fasen brukes en rekke kombinasjoner av teknikker, som flytskjemaer , strukturdiagrammer, beslutningstabeller, etc. Uansett hvilken som skal brukes vil det være fordelaktig å fange opp spesifikasjonene klart og objektivt, og dermed har programmereren større forståelse når han programmerer og tester programmene som tilsvarer ham.
  • Utvikling av manuelle designenheter: I denne fasen er det sentrale målet å prosjektere alle administrative prosedyrer som skal utvikles rundt bruk av datastyrte komponenter. [ 21 ]
Programvaretesting _

Det består i å verifisere at programvaren utfører oppgavene som er angitt i problemspesifikasjonen på riktig måte. En teknikk er å teste hver programvaremodul separat ( enhetstesting ), og deretter teste den som en helhet ( integrasjonstesting ), for å nå målet. Det anses som god praksis at testing utføres av noen andre enn utvikleren som programmerte den, ideelt sett et testområde; til tross for det foregående, må programmereren gjøre sine egne tester. Generelt er det to hovedmåter å organisere et testområde på, den første er at det består av uerfarent personell og at de ikke kan emnet for testing, på denne måten blir det evaluert at dokumentasjonen som leveres er av kvalitet, at prosessene beskrevet er så tydelige at alle kan forstå dem og programvaren gjør ting som beskrevet. Den andre tilnærmingen er å ha et testområde som består av erfarne programmerere, folk som uten ytterligere indikasjoner vet under hvilke forhold en applikasjon kan mislykkes og som kan ta hensyn til detaljer som uerfarent personell ikke vil vurdere.

I følge Roger S. Pressman fokuserer testprosessen på programvarens interne logiske prosesser , og sikrer at alle utsagn er sjekket, og funksjonelle eksterne prosesser, dvs. testing for feil. Det kreves å kunne teste programvaren med reelle forsøkspersoner som kan evaluere programvarens oppførsel for å gi tilbakemelding til utviklerne. Det er viktig at under programvareutviklingsprosessen ikke tapes kontakt med interesserte parter eller søkere for programvareutvikling , på denne måten vil målene for prosjektet forbli gyldige og det vil være en klar ide om aspektene som må være testet i løpet av prøveperioden. [ 22 ]

Implementering

En implementering er realisering av en teknisk spesifikasjon eller algoritmer med et program, programvarekomponent eller annet datasystem. Mange spesifikasjoner er gitt i henhold til din spesifikasjon eller en standard. De anbefalte spesifikasjonene i henhold til World Wide Web Consortium og programvareutviklingsverktøyene inneholder implementeringer av programmeringsspråk. Implementeringsmodellen er en samling av komponenter og delsystemene de inneholder. Komponenter som: kjørbare filer, kildekodefiler og alle andre typer filer som er nødvendige for implementering og distribusjon av systemet.

Implementeringsfasen av programvaredesign er prosessen med å konvertere en systemspesifikasjon til et kjørbart system. Det involverer alltid programvaredesign og programmeringsprosesser , men hvis en evolusjonær tilnærming til utvikling brukes, kan det også innebære en foredling av programvarespesifikasjonen . Dette stadiet er en beskrivelse av strukturen til programvaren som skal implementeres, dataene som er en del av systemet, grensesnittene mellom komponentene i systemet, og noen ganger algoritmene som brukes. [ 23 ]

Dokumentasjon

Det er alt relatert til dokumentasjonen av selve programvareutviklingen og prosjektledelse, inkludert modellering ( UML ), use case diagrammer, tester, brukermanualer, tekniske manualer, etc; alt med tanke på eventuelle rettelser, brukervennlighet, fremtidig vedlikehold og systemutvidelser.

Vedlikehold

Fase dedikert til vedlikehold og forbedring av programvaren for å korrigere oppdagede feil og innlemme nye krav. Dette kan ta enda lengre tid enn den første programvareutviklingen . Rundt 2/3 av livssyklustiden til et prosjekt [ 14 ] er dedikert til vedlikehold. En liten del av dette arbeidet består i å eliminere feil (bugs) ; er at det meste ligger i å utvide systemet til å inkludere nye funksjoner og håndtere utviklingen .

Programvarevedlikehold , ifølge Lehman -forskning, er 80 % av vedlikeholdet ikke korrigerende tiltak. De er forbedringer av funksjonalitet (og inkorporering av nye krav), ifølge Lehman utvikler programvaren seg over tid. Tatt i betraktning, kan selve vedlikeholdsstadiet inkludere de tidligere stadiene mellom utrulling av hver ny versjon, gjenbruk av eksisterende programvare, oppussing og tilpasning av den.

Fordeler [ 24 ]

Fra et ledelsessynspunkt
  • Tilrettelegge oppgaven med å overvåke prosjektet
  • Optimalisere ressursbruken
  • Tilrettelegge for kommunikasjon mellom brukere og utviklere
  • Tilrettelegge for evaluering av resultater og oppfyllelse av mål
Fra programvareingeniørers synspunkt
  • Hjelp til å forstå problemet
  • tillate gjenbruk
  • Forenkle vedlikeholdet av sluttproduktet
  • Optimaliser helheten og hver enkelt av fasene i utviklingsprosessen
Fra kundens eller sluttbrukerens synspunkt
  • Garanterer kvalitetsnivået til sluttproduktet
  • Få riktig livssyklus for prosjektet
  • Tillit til tidsrammene vist i prosjektdefinisjonen

Programvareutvikling livssykluser og modeller

Programvareteknikk , for å bestille kaoset som tidligere var programvareutvikling , har flere modeller, paradigmer og utviklingsfilosofier , vi kjenner dem hovedsakelig som modeller eller livssykluser for programvareutvikling , dette inkluderer prosessen som følger for å bygge, levere og utvikle programvare , fra unnfangelse av en idé til levering og pensjonering av systemet, og representerer alle aktivitetene og artefaktene (mellomprodukter) som kreves for å utvikle en applikasjon. [ 25 ]

Programvarens livssyklus inneholder følgende prosedyrer:

  • Definisjon av mål : definere resultatet av prosjektet og dets rolle i den overordnede strategien. [ 26 ]
  • Analyse av kravene og deres gjennomførbarhet : samle inn, undersøke og formulere kundens krav og undersøke eventuelle begrensninger som kan gjelde. [ 26 ]
  • Generell design – Generelle krav til applikasjonsarkitekturen. [ 26 ]
  • Design i detalj : presis definisjon av hvert delsett av applikasjonen. [ 26 ]
  • Programmering (programmering og implementering): er implementeringen av et programmeringsspråk for å lage funksjonene som er definert under designstadiet. [ 26 ]
  • Enhetstesting – Tester hver delsett av applikasjonen individuelt for å sikre at de ble implementert i henhold til spesifikasjonene. [ 26 ]
  • Integrasjon – for å sikre at de ulike modulene integreres med applikasjonen. Dette er hensikten med den nøye dokumenterte integrasjonstesten . [ 26 ]
  • Betatesting (eller validering ), for å sikre at programvaren oppfyller de originale spesifikasjonene. [ 26 ]
  • Dokumentasjon : tjener til å dokumentere nødvendig informasjon for brukere av programvaren og for fremtidig utvikling. [ 26 ]
  • Gjennomføring
  • Vedlikehold – For alle korrigerende prosedyrer (Korrigerende vedlikehold) og mindre programvareoppdateringer (løpende vedlikehold). [ 26 ]

Kaskade eller klassisk modell

I programvareteknikk er fossefallmodellen -også kalt fossefallsutvikling eller klassisk livssyklus- basert på en metodisk tilnærming som strengt sorterer stadiene i programvarens livssyklus , dette antyder en systematisk sekvensiell tilnærming til programvareutviklingsprosessen. programvare , som begynner med spesifikasjonen av kundekrav og fortsetter gjennom planlegging, modellering, konstruksjon og distribusjon for å kulminere med støtte for den ferdige programvaren . [ 27 ]

Prototyping modell

I programvareteknikk tilhører prototypemodellen de evolusjonære utviklingsmodellene. Dette gjør at hele systemet, eller noen av dets deler, kan bygges raskt for enkelt å forstå og avklare enkelte aspekter for å sikre at utvikler, bruker, oppdragsgiver er enige om hva som trengs samt løsningen som foreslås for nevnte behov og på denne måten minimere risikoen og usikkerheten i utviklingen, denne modellen er ansvarlig for utviklingen av design slik at de blir analysert og dispenserer fra dem etter hvert som nye spesifikasjoner overholdes, den er ideell for å måle omfanget av produktet, men dets faktiske bruk er ikke sikret.

Denne modellen brukes hovedsakelig når en klient definerer et sett med generelle mål for programvaren som skal utvikles uten å definere inndata, prosessering og utdata i detalj, det vil si når den ansvarlige ikke er sikker på effektiviteten til en algoritme, av systemets tilpasningsevne eller måten menneske og maskin samhandler på.

Denne modellen er først og fremst opptatt av å hjelpe systemingeniøren og kunden til å bedre forstå hva byggeresultatet blir når kravene er tilfredsstilt. [ 28 ]

Spiralmodell

Spiralmodellen, opprinnelig foreslått av Barry Boehm i 1986, er en evolusjonær programvareprosessmodell som kombinerer den iterative karakteren til prototyping med de kontrollerte og systematiske aspektene ved fossefallsmodellen, det vil si at når denne modellen brukes, utvikles programvaren i en serie evolusjonære leveranser (sykluser eller iterasjoner), hver av disse leverer mer komplette prototyper enn den forrige, alt basert på risikoanalyse og kundebehov. Selv om spiralmodellen representerer fordeler fremfor lineær utvikling, kan beregningen av risiko være svært komplisert, og derfor er bruken i den virkelige verden svært knapp. [ 29 ]

Etappevis utviklingsmodell

Det er en modell der programvaren vises til klienten i suksessivt raffinerte stadier. Med denne metodikken utvikles de viktigste kapasitetene, noe som reduserer tiden som er nødvendig for konstruksjonen av et produkt; den trinnvise leveringsmodellen er nyttig for utviklingen av verktøyet fordi bruken av det anbefales for problemer som kan behandles ved å bryte dem ned i mindre problemer og er hovedsakelig preget av at spesifikasjonene ikke er kjent i detalj i begynnelsen av prosjekt og derfor utvikles de samtidig med de forskjellige versjonene av koden.

Følgende faser kan skilles i denne modellen:

  • Konseptspesifikasjon.
  • Analyser av krav.
  • Opprinnelig design.
  • Detaljert design (koding, feilsøking, testing og utgivelse).

Når det er trinnvis, i den globale designen kan disse fasene gjentas i henhold til antall trinn som kreves.

Blant fordelene har vi:

  • Oppdagelse av problemer før og ikke før den eneste endelige leveransen av prosjektet.
  • Eliminering av tid i rapporter fordi hver versjon er en forhåndsvisning.
  • Tidsestimat per versjon, unngå feil i estimeringen av det generelle prosjektet.
  • Overholdelse til dags dato av utviklere.

Inkrementell eller iterativ modell

Iterativ og inkrementell (eller inkrementell) utvikling er en programvareutviklingsprosess , opprettet som svar på svakhetene til den tradisjonelle fossefallsmodellen, dvs. denne modellen bruker lineære sekvenser som fossefallsmodellen, men på en iterativ eller skalert måte i henhold til utviklingsprosessen As. fremskritt og med hver av disse lineære sekvensene produseres inkrementer (forbedringer) av programvaren . [ 30 ]

Det må tas i betraktning at prosessflyten til ethvert inkrement kan inkludere prototypekonstruksjonsparadigmet, siden som nevnt ovenfor, denne typen modell er iterativ av natur, men den skiller seg ved at den søker levering av et driftsprodukt med hvert inkrement laget til programvaren .

Strukturert modell

Denne modellen - som navnet indikerer - bruker teknikkene for strukturert design eller strukturert programmering for utviklingen, den brukes også til å lage programmets algoritmer. Dette formatet gjør det enkelt å forstå datastrukturen og dens kontroll. [ 31 ] Blant hovedkarakteristikkene til denne modellen er følgende:

  • Generelt kan prosesser og datastrukturer skilles tydeligere.
  • Det finnes metoder som hovedsakelig fokuserer på visse data.
  • Abstraksjonen av programmet er på et mye høyere nivå.
  • Prosesser og datastrukturer er representert hierarkisk. [ 31 ]

Denne modellen har også sine ulemper, blant annet kan vi nevne noen:

  • Gjentatte data kan finnes i ulike deler av programmet. [ 31 ]
  • Når koden blir veldig omfattende eller stor, blir håndteringen for komplisert. [ 32 ]

I den strukturerte modellen er teknikkene som vanligvis brukes:

  • Entity -relationship-modellen , denne teknikken er hovedsakelig relatert til data.
  • Dataflytdiagrammet , dette brukes hovedsakelig for prosesser. [ 33 ]
Objektorientert modell

Disse modellene har sine røtter i objektorientert programmering og som en konsekvens dreier det seg om klassekonseptet, det samme gjør kravanalyse og design. I tillegg til å introdusere nye teknikker, utnytter dette også strukturerte utviklingsteknikker og konsepter, som tilstandsdiagrammer og overganger. Den objektorienterte modellen har to hovedegenskaper, som har favorisert utvidelsen:

  • Det tillater gjenbruk av programvare i betydelig grad.
  • Dens enkelhet letter utviklingen av programvareutviklingshjelpemidler, som enkelt implementeres i en objektorientert notasjon kalt UML . [ 34 ]

RAD (rask applikasjonsutvikling) modell

RAD ( rask applikasjonsutvikling): 'rask applikasjonsutvikling', er en inkrementell programvareprosessmodell , opprinnelig utviklet av James Maslow i 1980, som hovedsakelig legger vekt på en kort utviklingssyklus.

Dette er en metodikk som muliggjør konstruksjon av beregningssystemer som kombinerer CASE (Computer Aided Software Engineering) teknikker og verktøy , konstruksjon av brukersentrerte prototyper og lineær og systematisk sporing av mål, noe som øker hastigheten som resultatene produseres med. systemer ved å bruke en komponentbasert utviklingstilnærming. [ 35 ]

Hvis kravene er godt forstått og omfanget av prosjektet er begrenset, lar RAD-prosessen et utviklingsteam lage et fullt funksjonelt produkt innen en svært begrenset tidsperiode uten å redusere kvaliteten på produktet det minste. [ 36 ]

Samtidig utviklingsmodell

Den samtidige utviklingsmodellen er en nettverksmodell der alle menneskene handler samtidig eller samtidig. Denne typen modell kan representeres skjematisk som en serie viktige tekniske aktiviteter, oppgaver og tilstander knyttet til dem.

Den samtidige prosessmodellen definerer en serie hendelser som vil utløse tilstand-til-stat-overganger for hver av programvareutviklingsaktivitetene . For eksempel, i de tidlige stadiene av design, er en inkonsekvens av analysemodellen ikke vurdert. Dette genererer hendelsesparsemodellen, som vil utløse parsingsaktiviteten fra ferdig-tilstanden til ventende endringstilstand. Denne utviklingsmodellen brukes ofte som klient/server-applikasjonsutviklingsparadigmet. Et klient/serversystem består av et sett med funksjonelle komponenter. Når den brukes på klient/server, definerer den samtidige prosessmodellen aktiviteter i to dimensjoner: en systemdivisjon og en komponentdivisjon. Problemer på systemnivå håndteres gjennom to aktiviteter: design og implementering.

Samtidig oppnås på to måter:

  • System- og komponentaktiviteter skjer samtidig og kan modelleres ved hjelp av den objektorienterte tilnærmingen beskrevet ovenfor;
  • En typisk klient/server-applikasjon er implementert med mange komponenter, som hver kan designes og implementeres samtidig.

Faktisk er den samtidige utviklingsmodellen anvendelig for alle typer programvareutvikling og gir et nøyaktig bilde av den nåværende tilstanden til et prosjekt. I stedet for å begrense programvareutviklingsaktiviteter til en rekke hendelser, definere et nettverk av aktiviteter, eksisterer alle aktivitetene i nettverket samtidig med hverandre. Hendelser generert innenfor en gitt aktivitet eller en annen side av aktivitetsnettverket setter i gang overganger mellom tilstander til en aktivitet.

Enhetlig programvareutviklingsprosess

The Unified Process er en generisk programvareprosess som kan brukes til et stort antall typer programvaresystemer , for ulike applikasjonsområder, ulike typer organisasjoner, ulike kompetansenivåer og ulike størrelser på prosjekter.

Gir en disiplinert tilnærming til å tildele oppgaver og ansvar i en utviklingsorganisasjon. Målet er å sikre produksjon av svært høykvalitets programvare som møter behovene til sluttbrukere, innenfor en forutsigbar tidsplan og budsjett. [ 37 ]

Den enhetlige prosessen har to dimensjoner:

  • En horisontal akse som representerer tid og viser aspektene ved prosessens livssyklus gjennom hele utviklingen
  • En vertikal akse som representerer disiplinene, som grupperer aktiviteter på en logisk måte etter deres natur.

Den første dimensjonen representerer det dynamiske aspektet av prosessen slik den utfolder seg, uttrykt i form av faser, iterasjoner og milepæler (milepæler).

Den andre dimensjonen representerer det statiske aspektet av prosessen: hvordan den beskrives i form av prosesskomponenter, disipliner, aktiviteter, arbeidsflyter, artefakter og roller.

Den mest kjente og dokumenterte foredlingen av Unified Process er RUP (Rational Unified Process).

Den enhetlige prosessen er ikke bare en prosess, men et utvidbart rammeverk som kan skreddersys til spesifikke organisasjoner eller prosjekter. På samme måte er rationals Unified Process også et utvidbart rammeverk, så det er ofte umulig å si om en spesiell foredling av prosessen har blitt avledet fra Unified Process eller fra RUP. Av denne grunn brukes de to navnene ofte for å referere til det samme konseptet. [ 38 ]

Produkt

Programvare har blitt noe veldig nødvendig i vårt nåværende samfunn, det er maskinen som driver forretningsbeslutninger, den tjener moderne vitenskapelig forskning, den er en nøkkelfaktor som skiller moderne produkter og tjenester. Dette er fordi programvare er innebygd i systemer av alle slag rundt oss.

Dataprogramvare er produktet som programvareingeniører designer og bygger . Dette omfatter programmer som kjører inne i en datamaskin uansett størrelse og arkitektur, som er bygget av nesten alle i den industrialiserte verden, enten direkte eller indirekte.

Produktene kan klassifiseres i:

  • Generiske produkter: De er de som produseres av en organisasjon for å selges til markedet.
  • Skreddersydde produkter: Systemer som utvikles på forespørsel til en spesifikk utvikler.

Disse produktene må oppfylle flere egenskaper ved levering, disse er:

  • Vedlikeholdbar: Programvaren må kunne utvikle seg mens den oppfyller funksjonene.
  • Pålitelighet: Det skal ikke forårsake skade ved feil.
  • Effektivitet: Programvaren skal ikke kaste bort ressurser.
  • Riktig bruk: Den må ha et egnet brukergrensesnitt og dens dokumentasjon.

Hva som utgjør sluttproduktet er forskjellig for ingeniøren og brukerne, for ingeniøren er det programmene, dataene og dokumentene som konfigurerer programvaren , men for brukeren er sluttproduktet informasjonen som på en bestemt måte løser problemet brukeren..

Arten av programvareutvikling

Software engineering er en disiplin som er orientert mot å anvende ingeniørkonsepter og metoder for utvikling av kvalitetsprogramvare .

Matematikk

Programmer har mange matematiske egenskaper. For eksempel er riktigheten og kompleksiteten til mange algoritmer matematiske konsepter som kan testes grundig. Bruk av matematikk i SI kalles formelle metoder .

Oppretting

Programmer bygges i en sekvens av trinn. Det faktum å riktig definere og utføre disse trinnene, som i et samlebånd, er nødvendig for å forbedre produktiviteten til utviklerne og den endelige kvaliteten på programmene. Dette synspunktet inspirerer de forskjellige prosessene og metodene som finnes i SI.

Prosjektledelse

Stor programvareutvikling krever riktig prosjektledelse. Det er budsjetter, etablering av leveringstider, et team av fagfolk å lede. Ressurser (kontorlokaler, rekvisita, utstyr) å anskaffe. For administrasjonen er det nødvendig å ha en klar visjon og opplæring i prosjektledelse.

Deltakere og roller

Utviklingen av et programvaresystem krever samarbeid fra mange mennesker med ulike ferdigheter, evner og interesser. Gruppen personer som er involvert i prosjektet er kjent som deltakere.

Settet med funksjoner og ansvar innenfor prosjektet eller systemet er kjent som roller eller roller. Rollene er knyttet til oppgavene som er tildelt deltakerne, følgelig kan en person spille en eller flere roller, samt at den samme rollen kan representeres av et team. [ 39 ]

Klient

Begrepene «brukere», «sluttbrukere» og «kunder» brukes ofte synonymt, noe som kan skape forvirring; Strengt tatt er klienten (person, bedrift eller organisasjon) den som spesifiserer systemkravene , [ 40 ] mens brukeren er den som til slutt bruker eller drifter programvareproduktet , og kan være klienten eller ikke.

Utviklere

Denne klassen av deltakere er involvert i alle fasetter av programvareutviklingsprosessen . Arbeidet hans inkluderer forskning, design, implementering, testing og feilsøking av programvare . [ 41 ]

Ledere

I sammenheng med programvareutvikling er programvareutviklingssjefen en deltaker som rapporterer til administrerende direktør i selskapet som leverer utviklingstjenesten. Han er ansvarlig for styring og koordinering av ressurser og prosesser for korrekt levering av programvareprodukter , samtidig som han deltar i definisjonen av strategien for teamet av utviklere, og gir initiativer som fremmer visjonen til selskapet. [ 42 ]

Sluttbrukere

Sluttbrukeren er den som samhandler med programvareproduktet når det er levert. [ 40 ] Det er generelt brukerne som er klar over problemet, siden de betjener systemene på daglig basis.

Etisk kode for en programvareingeniør

En programvareingeniør må ha en kode som i den grad det er mulig sikrer at innsatsen som gjøres blir brukt til gode og må være forpliktet til å gjøre programvareingeniør til et respektert og nyttig yrke. For overholdelse av denne standarden er åtte prinsipper knyttet til oppførsel og beslutninger tatt av ingeniøren tatt i betraktning; hvor disse prinsippene identifiserer de etisk ansvarlige relasjonene til individene, gruppene og organisasjonene der de deltar. Prinsippene de skal forholde seg til handler om samfunn, oppdragsgiver og arbeidsgiver, produkt, utprøving, administrasjon, profesjon, kollegaer og til slutt personalet.

  • Samfunn: Programvareingeniører må handle på en måte som er forenlig med den sosiale interessen, påta seg fullt ansvar for sitt arbeid, temperere interesser med sosial velferd, godkjenne programvare bare hvis de har en velbegrunnet overbevisning, samarbeide i arbeidet med å løse viktige saker av sosial interesse , vær rettferdig og sannferdig i alle uttalelser angående programvaren eller tilknyttede dokumenter.
  • Oppdragsgiver og arbeidsgiver: Tiltak må gjøres på en slik måte at det beste for klienter og arbeidsgivere forenes, i samsvar med samfunnsinteressen. De må yte tjenester innenfor sine kompetanseområder, være ærlige og åpne om begrensningene, ikke bruke programvare som er anskaffet ulovlig eller uetisk, bruke eiendommen til klienter eller arbeidsgivere på en autorisert måte, holde eventuelle konfidensielle informasjonsdokumenter hemmelig.
  • Produkt: Det er nødvendig å sikre at produktene og deres modifikasjoner oppfyller høyest mulig faglige standarder, sikre høy kvalitet, akseptable kostnader og en rimelig agenda, sikre at kostnadene og fordelene er klare og akseptert av arbeidsgiver og oppdragsgiver. Sørg for at målene og målene for ethvert prosjekt er tilstrekkelige og oppnåelige.
  • Vurdering: Integritet og uavhengighet i profesjonell dømmekraft må opprettholdes, moderere all teknisk vurdering av behovet for å støtte og opprettholde menneskelige verdier, opprettholde profesjonell objektivitet med hensyn til programvare eller relaterte dokumenter, ikke delta i uredelig økonomisk praksis.
  • Administrasjon: Det skal sikres god administrasjon for ethvert prosjekt der det arbeides, ved å bruke effektive prosedyrer for å fremme kvalitet og redusere risiko, også sikre at selskapets retningslinjer og prosedyrer er kjent for å beskytte passord, filer og konfidensiell informasjon.
  • Yrke: Profesjonens integritet og omdømme må økes i forbindelse med sosial interesse, bidra til å utvikle et gunstig organisasjonsmiljø for å handle, fremme offentlig kunnskap om programvareteknikk , spre kunnskap om programvareteknikk gjennom deltakelse i organisasjoner, møter og faglige publikasjoner .
  • Kolleger: Hver ingeniør må støtte og være rettferdig mot kolleger, motivere sine kolleger ved å følge koden, også hjelpe deres faglige utvikling, anerkjenne andres arbeid og avstå fra å ta unødig kreditt, gjennomgå arbeidet objektivt, oppriktig og riktig dokumentert.
  • Personale: Programvareingeniører vil engasjere seg i livslang læring ved å gjøre og fremme en etisk tilnærming til profesjonen, og øke kunnskapen deres om fremskritt innen programvareanalyse , spesifikasjoner, design, utvikling, vedlikehold, testing og relaterte dokumenter sammen med administrasjon av utviklingsprosessen . [ 43 ]

Etisk utdanning

Organisasjoner

Se også

Referanser

  1. ↑ SWEBOK utøvende redaktører, Alain Abran, James W. Moore; redaktører, Pierre Bourque, Jonathan Aguilar, Robert Dupuis. (2004). Pierre Bourque og Robert Dupuis, red. Veiledning til Software Engineering Body of Knowledge - 2004 versjon . IEEE Computer Society . s. 1-1. ISBN  0-7695-2330-7 . 
  2. ↑ MCA (2006). Databehandlingsgrader og karrierer . MCA. Arkivert fra originalen 17. juni 2011 . Hentet 2010-11-23 .  
  3. ↑ IEEE Standard Glossary of Software Engineering Terminology , IEEE std 610.12-1990, 1990.
  4. ↑ Bureau of Labor Statistics, US Department of Labor, USDL 05-2145: Occupational Employment and Wages, november 2004 ( brutt lenke tilgjengelig på Internet Archive ; se historikk , første og siste versjoner ). , Tabell 1.
  5. ^ "Vitenskapen i dag er morgendagens teknologi" . 
  6. ^ "XXI Century University, Argentina" . Arkivert fra originalen 16. mars 2014 . Hentet 11. mars 2014 . 
  7. ^ "Autonomous University of Guadalajara, Mexico" . Arkivert fra originalen 25. mars 2014 . Hentet 11. mars 2014 . 
  8. ↑ Tecnológico de Antioquía, Colombia ( ødelagt lenke tilgjengelig på Internet Archive ; se historikk , første og siste versjon ).
  9. ↑ Leondes (2002). intelligente systemer: teknologi og applikasjoner . CRC Trykk. ISBN  978-0-8493-1121-5 . 
  10. ^ "En undersøkelse av Therac-25-ulykker" . Arkivert fra originalen 2. mai 2014 . Hentet 11. april 2014 . 
  11. ↑ Association for Computing Machinery. "The Risks Digest" (på engelsk) . Hentet 10. november 2018 . 
  12. ^ Sommerville, Ian (1985) [1982]. Software Engineering (på engelsk) . Addison-Wesley. ISBN  0-201-14229-5 . «Software engineering... har nylig dukket opp som en disiplin i seg selv. » 
  13. ↑ Polytekniske universitetet i Madrid. "Programvareingeniørmål" . 
  14. ^ a b Pressman, Roger S. (2003). "Prosessen". Programvareteknikk, en praktisk tilnærming . Mexico: McGraw Hill, femte utgave. 
  15. ↑ a b Monografias.com. "UML Software Engineering" . Hentet 10. november 2018 . 
  16. ↑ Software Engineering-notasjoner ,.
  17. ↑ Monografias.com Programvareutvikling
  18. ^ "Arkiveret kopi" . Arkivert fra originalen 31. mars 2014 . Hentet 9. april 2014 . 
  19. ↑ a b [1]
  20. ↑ "Begrensninger for programvaren" , artikkel på Mundo Kramers nettsted .
  21. ↑ "Enhet 2: Fundamentals of Software Engineering" Arkivert 2014-04-13 på Wayback Machine , artikkel på Ing Softwares nettsted.
  22. ↑ [2]
  23. ↑ Sommerville, Ian. Programvareteknikk . 
  24. ↑ Software Engineering Methodology , artikkel på Slide Share-nettstedet.
  25. ↑ Programvareteknikk : livssykluser og metoder , artikkel publisert på nettsiden til Fakultet for ingeniørvitenskap ved Universidad de Los Andes .
  26. ↑ a b c d e f g h i j "Programvarelivssyklus" . Hentet 14.12.16 . 
  27. ↑ Pressman, Roger S.: Software Engineering: A Practical Approach . Sjette utgave, s. 50-51.
  28. ↑ Lawrence Peleeger, Shari: Software Engineering: Model Prototyping . Statens universitet for mirakel.
  29. ↑ Pressman, Roger S.: Software Engineering: A Practical Approach . Sjette utgave, s. 58-60.
  30. ↑ Pressman, Roger S.: Software Engineering: A Practical Approach . Sjette utgave, s. 52-53.
  31. ↑ a b c Structured Design , artikkel på Slide Share-nettstedet.
  32. ↑ [3] , Sammenlignende diagram over strukturert programmering og objektorientert programmering.
  33. ↑ [4] , Benet Campderrich Falgueras, redaksjonell UOC, 2002 - 320 sider.
  34. ↑ Campderrich Falgueras, Benet (2002): Programvareteknikk . Barcelona: Redaksjonell UOC, 2002. 320 sider.
  35. ^ [5] Arkivert 2014-08-24 på Wayback Machine , Hva er rask applikasjonsutvikling?
  36. ↑ Pressman, Roger S.: Software Engineering: A Practical Approach . Sjette utgave, s. 53-54.
  37. ↑ "Unified Software Development Process" Arkivert 2014-03-29 på Wayback Machine , artikkel på Yaqui-nettstedet.
  38. ↑ Pressman, Roger S.: Software Engineering: A Practical Approach . Sjette utgave, s. 67-72.
  39. ↑ Bernd Bruegge & Allen H. Dutoit. Objektorientert programvareteknikk, Prentice Hall, side 11.
  40. ^ a b Pressman, 2002 , s. 39
  41. ↑ "O*NET Code Connector - Programvareutviklere, systemprogramvare - 15-1133.00" . Onetcodeconnector.org . Hentet 4. august 2014 . 
  42. ^ "Posisjonsbeskrivelse for programvareutviklingssjef" . interfacing.com . Hentet 4. august 2014 . 
  43. ^ "Software Engineering Code of Ethics and Professional Practice" . SEERI, East Tennessee State University. 1999. Arkivert fra originalen 7. desember 2013 . Hentet 8. april 2014 . 

Bibliografi

Eksterne lenker