Programvaruutveckling

Mjukvaruutveckling är den kontinuerliga utvecklingen av en mjukvara efter den första releasen för att möta förändrade intressenter och/eller marknadskrav. Mjukvaruutveckling är viktig eftersom organisationer investerar stora summor pengar i sin programvara och är helt beroende av denna programvara. Programvaruutveckling hjälper mjukvara att anpassa sig till förändrade företagskrav, åtgärda defekter och integrera med andra föränderliga system i en mjukvarusystemmiljö.

Allmän introduktion

Fred Brooks , i sin nyckelbok The Mythical Man-Month , säger att över 90 % av kostnaderna för ett typiskt system uppstår i underhållsfasen, och att varje framgångsrik mjukvara oundvikligen kommer att bibehållas.

I själva verket härrör agila metoder från underhållsliknande aktiviteter i och kring webbaserade teknologier, där huvuddelen av kapaciteten kommer från ramverk och standarder. ^{[ citat behövs ]}

Programvaruunderhåll tar upp buggfixar och mindre förbättringar, medan mjukvaruutveckling fokuserar på anpassning och migrering .

Mjukvaruteknik kommer att fortsätta att utvecklas. Dessa förändringar kommer att kräva att nya lagar och teorier skapas och motiveras. Vissa modeller skulle också kräva ytterligare aspekter vid utveckling av framtida program. Innovationer och förbättringar ökar oväntad form av mjukvaruutveckling. Underhållsproblemen skulle troligen också förändras för att anpassa sig till utvecklingen av den framtida programvaran. Programvaruprocesser utvecklas i sig själva, efter att ha gått igenom inlärning och förfining, förbättrar det alltid deras effektivitet och effektivitet.

Grundläggande koncept

Behovet av mjukvaruutveckling kommer från det faktum att ingen kan förutsäga hur användarkraven kommer att utvecklas på förhand . Med andra ord är de befintliga systemen aldrig kompletta och fortsätter att utvecklas. Allt eftersom de utvecklas kommer systemens komplexitet att växa om det inte finns en bättre lösning tillgänglig för att lösa dessa problem. Huvudsyftet med mjukvaruutvecklingen är att säkerställa funktionell relevans, tillförlitlighet och flexibilitet hos systemet. Mjukvaruutveckling kan vara helt manuell (baserat på ändringar av mjukvaruingenjörer), delvis automatiserad (t.ex. med hjälp av refactoring-verktyg) eller helt automatiserad.

Mjukvaruutvecklingen har påverkats mycket av Internet:

den snabba tillväxten av World Wide Web och Internetresurser gör det lättare för användare och ingenjörer att hitta relaterad information.

öppen källkodsutveckling där vem som helst kunde ladda ner källkoderna och därmed modifiera den har möjliggjort snabb och parallell utveckling (genom gafflar).

Typer av mjukvaruunderhåll

EB Swanson identifierade initialt de tre kategorierna av underhåll: korrigerande, adaptiv och perfektiv. Fyra kategorier av programvara katalogiserades sedan av Lientz och Swanson (1980). Dessa har sedan dess uppdaterats och normaliserats internationellt i ISO/IEC 14764:2006:

Korrigerande underhåll : Reaktiv modifiering av en mjukvaruprodukt som utförs efter leverans för att rätta till upptäckta problem;
Adaptivt underhåll : Modifiering av en mjukvaruprodukt som utförs efter leverans för att hålla en mjukvaruprodukt användbar i en förändrad eller föränderlig miljö;
Perfekt underhåll : Modifiering av en mjukvaruprodukt efter leverans för att förbättra prestanda eller underhållsbarhet;
Förebyggande underhåll : Modifiering av en mjukvaruprodukt efter leverans för att upptäcka och korrigera latenta fel i mjukvaruprodukten innan de blir effektiva fel.

Allt det föregående sker när det finns ett känt krav på förändring.

Även om dessa kategorier kompletterades av många författare som Warren et al. (1999) och Chapin (2001), har den internationella standarden ISO/IEC 14764:2006 behållit de fyra grundläggande kategorierna.

På senare tid har beskrivningen av mjukvaruunderhåll och utveckling gjorts med hjälp av ontologier (Kitchenham et al. (1999), Deridder (2002), Vizcaíno (2003), Dias (2003) och Ruiz (2004)), som berikar beskrivningen av de många evolutionsaktiviteterna.

Scenmodell

Aktuella trender och praxis projiceras framåt med hjälp av en ny modell för mjukvaruutveckling som kallas den stegvisa modellen. Etappmodellen introducerades för att ersätta konventionell analys som är mindre lämplig för modern mjukvaruutveckling som förändras snabbt på grund av dess svårigheter att bidra med i mjukvaruutvecklingen. Det finns fem distinkta steg som bidrar i en enkel stegvis modell (Initial utveckling, Evolution, Service, Phase-out och Close-down).

Enligt KHBennett och VT Rajlich är det viktigaste bidraget att dela upp "underhållsfasen" i ett utvecklingssteg följt av ett service- och utfasningssteg. Den första versionen av mjukvarusystemet som saknar vissa funktioner kommer att utvecklas under initial utveckling eller även känd som alpha stage. Arkitekturen har dock redan ägts under detta skede kommer att medföra eventuella framtida ändringar eller tillägg. De flesta referenser i detta skede kommer att baseras på scenarier eller fallstudier. Kunskap har definierats som ett annat viktigt resultat av initial utveckling. Sådan kunskap inklusive kunskap om applikationsdomän, användarkrav, affärsregler, policyer, lösningar, algoritmer, etc. Kunskap verkar också vara den viktiga faktorn för den efterföljande utvecklingsfasen.
När det föregående steget slutförts framgångsrikt (och måste slutföras framgångsrikt innan nästa steg går in), skulle nästa steg vara evolution. Användare tenderar att ändra sina krav och de föredrar att se vissa förbättringar eller ändringar. På grund av denna faktor står mjukvaruindustrin inför utmaningarna med snabba förändringar i miljön. Därför är målet med evolutionen att anpassa applikationen till de ständigt föränderliga användarkraven och driftsmiljön. Under det föregående steget kan den första versionsapplikationen som skapas innehålla många fel, och dessa fel kommer att åtgärdas under utvecklingsstadiet baserat på mer specificerade och exakta krav på grund av fallstudien eller scenarierna.
Mjukvaran kommer att utvecklas kontinuerligt tills den inte längre är utvecklingsbar och går sedan in i servicefasen (även känd som mjukvarumognad). Under detta skede kommer endast mindre ändringar att göras.
Nästa steg som är avveckling, det finns ingen mer service tillgänglig för just den programvaran. Men programvaran fortfarande i produktion.
Till sist, stängning. Programvaruanvändningen kopplas bort eller avbryts och användarna hänvisas till en ersättare.

Lehmans lagar för mjukvaruutveckling

Prof. Meir M. Lehman , som arbetade vid Imperial College London från 1972 till 2002, och hans kollegor har identifierat en uppsättning beteenden i utvecklingen av proprietär programvara. Dessa beteenden (eller observationer) är kända som Lehmans lagar. Han hänvisar till system av E-typ som sådana som är skrivna för att utföra någon verklig aktivitet. Sådana systems beteende är starkt kopplat till miljön där det körs, och ett sådant system måste anpassas till olika krav och omständigheter i den miljön. De åtta lagarna är:

(1974) "Continuing Change" - ett E-system måste kontinuerligt anpassas eller blir det gradvis mindre tillfredsställande
(1974) "Increasing Complexity" - när ett system av E-typ utvecklas, ökar dess komplexitet om inte arbete görs för att underhålla eller minska det
(1980) "Självreglering" — E-typ systemutvecklingsprocesser är självreglerande med fördelningen av produkt- och processmått nära det normala
(1978) "Conservation of Organizational Stability (invariant work rate)" - den genomsnittliga effektiva globala aktivitetsgraden i ett utvecklande E-typsystem är oföränderligt under produktens livstid
(1978) "Conservation of Familiarity" - allt eftersom ett E-system utvecklas, allt som är associerat med det, måste utvecklare, säljare och användare, till exempel, behålla behärskning av dess innehåll och beteende för att uppnå tillfredsställande utveckling. Överdriven tillväxt minskar denna behärskning. Därför förblir den genomsnittliga inkrementella tillväxten oföränderlig när systemet utvecklas.
(1991) "Continuing Growth" - det funktionella innehållet i ett E-system måste kontinuerligt ökas för att upprätthålla användarnöjdhet under dess livstid
(1996) "Declining Quality" — kvaliteten på ett E-system kommer att tyckas sjunka om det inte underhålls noggrant och anpassas till förändringar i driftmiljön
(1996) "Feedback System" (första gången angett 1974, formaliserat som lag 1996) — E-typs evolutionsprocesser utgör återkopplingssystem i flera nivåer, flera slingor och flera agenter och måste behandlas som sådana för att uppnå betydande förbättringar jämfört med alla rimliga bas

Det är värt att nämna att tillämpligheten av alla dessa lagar för alla typer av mjukvarusystem har studerats av flera forskare. Se till exempel en presentation av Nanjangud C Narendra där han beskriver en fallstudie av ett agilt företagsprojekt i ljuset av Lehmans lagar för mjukvaruutveckling. Vissa empiriska observationer som kommer från studiet av mjukvaruutveckling med öppen källkod verkar utmana några av lagarna [ ^{vaga ] [}^{citat behövs ]} .

Lagarna förutspår att behovet av funktionsförändringar i ett mjukvarusystem är oundvikligt och inte en konsekvens av ofullständig eller felaktig analys av krav eller dålig programmering. De konstaterar att det finns gränser för vad ett mjukvaruutvecklingsteam kan åstadkomma när det gäller att säkert implementera förändringar och ny funktionalitet.

Mognadsmodeller som är specifika för mjukvaruutveckling har utvecklats för att förbättra processer och hjälpa till att säkerställa kontinuerlig föryngring av programvaran när den utvecklas iterativt [ ^{citat behövs ]} .

Den "globala processen" som görs av de många intressenterna (t.ex. utvecklare, användare, deras chefer) har många återkopplingsslingor. Utvecklingshastigheten är en funktion av återkopplingsslingans struktur och andra egenskaper hos det globala systemet. Processimuleringstekniker, såsom systemdynamik, kan vara användbara för att förstå och hantera en sådan global process.

Mjukvaruutvecklingen är sannolikt inte darwinistisk , lamarckisk eller baldwinisk , utan ett viktigt fenomen i sig. Med tanke på det ökande beroendet av mjukvara på alla nivåer i samhället och ekonomin, blir den framgångsrika utvecklingen av mjukvara allt mer kritisk. Detta är ett viktigt forskningsämne som inte har fått mycket uppmärksamhet.

Utvecklingen av mjukvara, på grund av dess snabba väg i jämförelse med andra konstgjorda enheter, sågs av Lehman som "fruktflugan" i studiet av evolutionen av artificiella system.

Se även

Tillgängliga verktyg

LibVCS4j Ett Java-bibliotek som tillåter befintliga verktyg att analysera utvecklingen av mjukvarusystem genom att tillhandahålla ett gemensamt API för olika versionskontrollsystem och problemspårare.

Vidare läsning

Andrea Capiluppi, Jesus M.Gonzalez Barahona, Israel Herraiz, Gregorio Robles, Anpassning av "Stageed Model for Software Evolution" till FLOSS
Mark C. Paulk, A History of the Capability Maturity Model Software