Hvordan og når ble programvare et produkt (og hvorfor)

Å forstå når og hvorfor vi begynte å behandle programvare som et produkt krever at man følger en vei som starter med mekaniske beregninger og strekker seg til skytjenester. På bare noen få tiår har vi gått fra enorme maskiner med fysiske instruksjoner til immaterielle programmer som lisensieres, oppdateres og til og med konsumeres som en tjeneste.

På denne reisen vil du, med eksempler og historisk kontekst, se hvordan begrepene maskinvare og instruksjoner ble skilt fra hverandre , hva som utløste ideen om å selge programvare uavhengig, hvordan produksjonen ble profesjonalisert, og hvilke forretnings- og lisensieringsmodeller som har formet bransjen, fra proprietær programvare til fri programvare og SaaS.

Fra maskin til program: fra den fysiske verden til instruksjonene

I århundrer ble beregninger automatisert med fysiske artefakter: fra abakus og analoge mekanismer til maskiner som jacquard-vevstolen , der hullkort definerte atferd uten å fullstendig skille struktur og instruksjoner.

Det konseptuelle skillet begynte å ta form med Charles Babbage og Ada Lovelace . Babbage unnfanget den analytiske motoren som en programmerbar enhet, og Lovelace beskrev hvordan forskjellige kort ville inneholde forskjellige programmer; frøet til ideen om at det man skulle gjøre kunne differensieres fra det man skulle gjøre det med.

Det store spranget fremover kom på 1900-tallet med Alan Turing og von Neumann-arkitekturen . Turing formaliserte en universell maskin som var i stand til å utføre enhver algoritme; von Neumann foreslo å lagre programmer og data i samme minne, slik at instruksjoner kunne endres uten å berøre maskinvaren.

Allerede på 40- og 50-tallet konsoliderte assemblere og høynivåspråk som Fortran og Cobol ideen: hvem som helst kunne skrive et program som kjørte på familier av kompatible maskiner uten å redesigne den fysiske delen.

Hva er programvare, og hva omfatter det egentlig?

Ordet «programvare» ble populært på slutten av 50-tallet, og under denne betegnelsen grupperes alle de immaterielle elementene som et datasystem behandler : programmer, data og tilhørende dokumentasjon. John W. Tukey hadde allerede brukt begrepet i denne betydningen i 1957.

Dette konseptet går utover den kjørbare filen: manualer, spesifikasjoner, data som skal behandles og brukerinformasjon regnes også som programvare . Til syvende og sist er det den ikke-fysiske komponenten som gir mening og funksjonalitet til maskinvaren.

Det er tradisjonelt klassifisert i tre hovedtyper: systemprogramvare ( operativsystemer , drivere, verktøy og servere), programmeringsprogramvare (redigeringsprogrammer, kompilatorer, tolker, linkere, feilsøkingsprogrammer og IDE-er) og applikasjonsprogramvare ( forretnings-, utdannings-, medisinsk, CAD, databaser , videospill , telekommunikasjon, etc.).

Fra tillegg til produkt: Programvaretidene og vippepunktet

I den første epoken, 1950–1965 , ble programvare sett på som et tillegg. Programmering ble gjort med en kode-og-reparer-tilnærming, med lite eller ingen dokumentasjon, begrensede metoder og en avhengighet av prøving og feiling . Utviklingen var skreddersydd, og forfatteren brukte og vedlikeholdt vanligvis sitt eget program.

Den andre epoken, 1965–1972 , markerer et avgjørende skifte: flerprogrammerings- og flerbrukermiljøer dukker opp, sanntidsdatabehandling tar av, og de første databasehåndteringssystemene blir utbredt . Fremfor alt begynner programvare å bli oppfattet som et produkt som kan distribueres til hundrevis eller tusenvis av klienter, og den såkalte programvarekrisen begynner når kompleksitet og vedlikeholdskostnader skyter i været.

I denne sammenhengen ble programvareteknikk formelt etablert i 1968 , disiplinen som anvender ingeniørprinsipper til design, konstruksjon, drift og vedlikehold av programmer. Programmeringsspråket C dukket også opp i 1972 for generelle systemer, og tilbyr effektivitet og lavnivåfunksjoner.

Den tredje epoken, fra 1972 til midten av 80-tallet , brakte med seg distribuerte systemer, lokale og globale nettverk, og bruken av mikroprosessorer. Mikrodatamaskiner og personlig databehandling dukket opp , sammen med språk som BASIC som demokratiserte læring og programmering.

I den fjerde æraen, 1985–2000 , var det den kollektive påvirkningen som rådet: globale nettverk, klient-server-arkitekturer, objektorienterte teknologier, ekspertsystemer, nevrale nettverk og kunstig intelligens . Java dukket opp tidlig på 90-tallet med objektorientering og portabilitet, og milepæler som Deep Blue demonstrerte spranget innen datakraft og programvare, mens produkter som Microsoft Encarta illustrerte kommersialiseringen av programvare.

Den femte æraen, 2000–nåtiden , er preget av fremveksten av nettet, mobile enheter og stordata . Internettets og smarttelefonenes allestedsnærværelse akselererer kontinuerlig levering, skytjenester og kunstig intelligens , noe som gjør programvare til hjørnesteinen i den digitale økonomien.

Parallelt gikk produsenter som IBM over fra å selge maskiner og programmer som en helhet til å ta betalt separat for maskinvare og programvare , og selskaper som utelukkende var dedikert til å lage og distribuere programvareprodukter blomstret. Dette steget befestet programvare som en markedsførbar vare, med egne lisenser, oppdateringer og støtte.

Hvordan produsere et programvareprodukt: prosesser og modeller

Å bygge et pålitelig produkt krever en prosess. Kravinsamling og spesifisering markerer begynnelsen: det er nødvendig å finne ut, bli enige om og dokumentere hva systemet må gjøre og under hvilke begrensninger, for å produsere SRS eller programvarekravspesifikasjonen.

Etter dette kommer design-, koding-, test-, installasjons- og vedlikeholdsfasene . Selv om navnene kan variere, eksisterer disse stadiene fleksible avhengig av hvilken metodikk som brukes. Og det er her prosessmodeller kommer inn i bildet.

Fossmodellen eller den sekvensielle lineære modellen innebærer å gå gjennom faser med lite tilbakesporing, noe som er nyttig i rigide prosjekter med klare krav, selv om det sjelden brukes i sin rene form. Praksis i den virkelige verden inkluderer tilbakemeldinger mellom stadier for å justere design og krav når det oppstår uklarheter eller endringer.

For å ta hensyn til programvarens evolusjonære natur, dukket det opp iterative, inkrementelle og spiralmodeller . Den inkrementelle modellen foreslår å levere delvise, men funksjonelle versjoner, hver bygget på den forrige, slik at klienten får tidlig nytteverdi og risikoen for omfattende omarbeid reduseres.

Boehms spiralmodell kombinerer iterasjon med eksplisitt risikostyring. Den definerer oppgaveområder som kommunikasjon, planlegging, risikoanalyse, konstruksjon og tilbakemeldingsinnsamling, og har inspirert varianter som vinn-vinn-spiralen, som introduserer forhandling av vinnbetingelser for både klient og leverandør.

Bransjetall fremhever utfordringen: en betydelig andel av store prosjekter mislykkes eller opplever betydelige forsinkelser . Ofte skyldes ikke dette tekniske problemer, men snarere mangelfulle metoder eller dårlig krav- og risikostyring; derav viktigheten av tverrfaglige prosesser.

Fra kode til levering: artefakter, testing og installasjon

Under programmering går produktet gjennom forskjellige tilstander. Kildekoden er det utvikleren skriver. En kompilator kan transformere den til mellomliggende objektkode , som senere kobles til biblioteker for å generere den kjørbare filen . Hvis språket tolkes, kan det hende at det ikke finnes noen objektkode eller kjørbar fil på forhånd.

Feilsøking følger med koding , og formell testing følger. Enhetstester validerer små komponenter; integrasjonstester bekrefter at moduler og delsystemer samhandler riktig. Senere er en betatestperiode under virkelige forhold vanlig for å fange opp feil som har unnslapp tidligere faser.

Installasjonsprosessen overfører programvaren til målmiljøet: distribusjon, konfigurasjon og driftsverifisering . Komplekse produkter kan kreve spesialister og distribuerte topologier, mens forbrukerprogramvare tilbyr veiledede installatører for sluttbrukeren.

Deretter kommer den lengste fasen: vedlikehold . Dette omfatter korrigerende, perfeksjonerende, adaptive og evolusjonære endringer. Kvaliteten på design og dokumentasjon påvirker direkte kostnadene; med dårlig dokumentasjon kan vedlikehold være like dyrt som å bygge opp fra bunnen av.

Kontinuerlig evolusjon: Lehmans lover

Programvaren som er i bruk endres eller forringes. Lehmans evolusjonslover oppsummerer observasjoner om systemer i bruk: endring er kontinuerlig, kompleksitet har en tendens til å vokse med mindre du investerer i å kontrollere den, og funksjonaliteten må utvides for å opprettholde brukertilfredsheten.

Blant annet bemerker de at kvaliteten avtar med mindre den tilpasses , at evolusjonære prosesser innlemmer tilbakemeldinger, og at organisasjonen når relativt konstante utviklingsnivåer. Disse hypotesene hjelper til med å planlegge versjoner og budsjettere vedlikeholdsinnsats.

Krav: hjertet i det som bygges

Kravteknikk tilbyr metoder og verktøy for å forstå problemet, validere med klienten og sikre spesifikasjoner . Bruker- og systemkrav skilles mellom, i tillegg til funksjonelle, ikke-funksjonelle og domenekrav, med undertyper som organisatoriske, eksterne juridiske og etiske krav.

God praksis inkluderer å definere diskursens univers , forberede workshops om utlysning, prioritere mål og oppdage tvetydigheter. Det finnes flere tilnærminger: fra utvidede leksikon og scenarier til mer ortodokse metoder dekket av standarder som IEEE 830-1998 eller CMMI-lignende forbedringsrammeverk.

Forretningsmodeller og lisensiering: fra proprietær til åpen kildekode og SaaS

Etter hvert som programvare ble etablert som et produkt, dukket det opp ulike lisensieringsmodeller . Proprietær lisensiering definerer bruksvilkår, rettighetstildelinger og gyldighetsområde. I motsetning til dette tillater åpen lisensiering kopiering, modifisering og omdistribusjon, noe som gir opphav til åpne fellesskap og økosystemer.

Siden 80- og 90-tallet har det vært standardkriger innen operativsystemer og plattformer: Unix og dets varianter, Windows , fremveksten av fri programvare med GNU-prosjektet og Linux , og styrkingen av brukerens rolle i valg av ikke bare maskinvare, men også system og applikasjoner.

Det nyeste spranget innen leveringsmodeller er programvare som en tjeneste, eller SaaS . Røttene går tilbake til tidsdelingen på 60-tallet med store systemer, men den moderne populariteten kom med internett og skyen. Tidligere, på 80-tallet, dukket de første CRM-ene opp, som delte kundeinformasjon, og på 90-tallet overgikk programvareveksten noen ganger tilgjengelig maskinvare, og presset tilbake mot sentralisert hosting.

Med det nye årtusenet gjorde kombinasjonen av allestedsnærværende nett- og skydata SaaS til et dominerende alternativ: abonnementsbetalinger, kontinuerlige oppdateringer, elastisk skalering og enhetsuavhengig tilgang. I dag sameksisterer det med tradisjonelle lisenser, freemium-modeller, mikrobetalinger og reklame.

Økonomisk og sosial innvirkning: hvorfor det var viktig å gjøre det om til et produkt

Å behandle programvare som et frittstående produkt muliggjorde spesialisering, stordriftsfordeler og spesifikke verdikjeder . Rene programvareselskaper ble verdt mer enn mange maskinvareprodusenter, og livssykluser, API-er og rammeverk la til rette for hele tredjepartsøkosystemer.

Men det oppsto også risikoer. Dårlig utvikling kan ha kostnader i millionklassen eller alvorlige konsekvenser : fra feil i reservasjonssystemer som forårsaker tap, til feil i kritiske miljøer med falske alarmer eller gale beslutninger som påvirker mennesker. Å profesjonalisere prosessen er ikke et innfall, det er en nødvendighet.

Som svar har bransjen styrket beste praksis, grundig testing og risikostyring . I miljøer med høy risiko eller høy sikkerhet er modeller som spiraltilnærmingen, fokusert på risikoer og kvalitetsstandarder, spesielt egnet. I andre tilfeller balanserer iterative og inkrementelle tilnærminger hastighet og kontroll.

For å forbli nyttig må et programvareprodukt utvikle seg med miljøet sitt , tilpasse seg nye plattformer, forbedre ytelsen, innlemme nye funksjoner og reagere på endringer i regelverket. Og selvfølgelig må det opprettholde grundig dokumentasjon slik at vedlikehold ikke blir en labyrint.

Hele denne historiske, tekniske og økonomiske reisen forklarer hvorfor programvare selges, lisensieres eller tilbys som en tjeneste i dag , med målinger for suksess, støtte, versjoner og planlagt pensjonering. Skillet mellom maskinvare og programvare er grunnlaget for hvordan vi oppfatter og markedsfører moderne teknologi.

Når man ser tilbake, er det tydelig at overgangen til programvare som produkt tok form mellom 60- og 70-tallet , drevet av økende kompleksitet, behovet for metoder, separat prising sammenlignet med maskinvare og fremveksten av spesialiserte selskaper. Siden den gang har språk som Fortran, Cobol, C, Basic og Java, milepæler som mikroprosessorer, internett, personlig databehandling og AI, og prosessmodeller som waterfall, inkrementell og spiral, befestet en industri som nå også trives i skyen og på mobile enheter.

Relatert artikkel:

Komplett veiledning til Microsoft Azure-tjenester og -produkter: hva hver enkelt gjør

Isaac

Lidenskapelig forfatter om verden av bytes og teknologi generelt. Jeg elsker å dele kunnskapen min gjennom å skrive, og det er det jeg skal gjøre i denne bloggen, vise deg alle de mest interessante tingene om dingser, programvare, maskinvare, teknologiske trender og mer. Målet mitt er å hjelpe deg med å navigere i den digitale verden på en enkel og underholdende måte.