Planering för programutvecklingsutveckling (3 saker att tänka på)

Planering för programutvecklingsutveckling (3 saker att tänka på)!

Planeringen för applikationsutveckling handlar inte längre om att välja verktyg, språk och inköp av olika resurser som krävs för ändamålet.

Image Courtesy: transformersjobs.com/wp-content/uploads/2013/06/software-engineer.jpg

Med den ökande förverkligandet bland cheferna av deras rätt till information "och användarens engagemang i applikationsutvecklingsprocessen har några problem uppkommit som måste sorteras ut.

Dessa problem låter runt fyra grundläggande kvaliteter som man letar efter i ett bra informationssystem, nämligen flexibilitet, integration, effektivitet och kontroll. Intressant är dessa frågor sammankopplade och det finns i viss utsträckning en avvägning mellan var och en av dem.

(a) Integration vs flexibilitet:

Integrering av varje applikation med informationssystem för olika affärsfunktioner är en önskad kvalitet. Sådan integration uppnås genom samtidig uppdatering av alla relevanta uppgifter i det ögonblick då en given transaktion tas i bruk i företaget.

Integreringen av applikationer säkerställer att var och en i arbetsgruppen får konsekvent bild av företagets nuvarande verklighet. Detta i sin tur undviker möjligheten till motstridiga drivkrafter på grund av brist på senaste information till några av dem. Men integrationen kan uppnås genom att införliva reglerna för uppdatering av data i applikationsprogrammet.

En funktionell chef kräver å andra sidan flexibilitet i dessa uppdateringsregler. En försäljningstransaktion i en integrerad applikation kommer till exempel att uppdatera informationen om gäldenärerna, när varan skickas.

Å andra sidan skulle marknadschefen kräva att finansavdelningen förstår att rabattkursen fortfarande är förhandlingsbar hos kunden och varorna skickas på grund av ett brådskande krav. Således kan priset eventuellt behöva ses över senare, medan integrering av ansökan i allmänhet inte skulle tillåta förändring av uppgifter med retroaktiv effekt.

Liknande situation kan uppstå vid inköpstransaktion där det överenskomna priset är föremål för inköp av en viss kvantitet inom en bestämd tidsperiod. Om företaget inte kan lyfta den kvalificerade kvantiteten under den angivna tiden kan priset revideras med retroaktiv effekt.

Finans- och revisionspersonal godkänner i allmänhet inte ändringar med retroaktiv effekt. I avsaknad av integration var problemet enkelt. Den berörda avdelningen kunde bara hålla upp transaktionsdokumentet till den och inte låta den gå till finansinformationssystemet, fram till dess. Även om finans- och revisionspersonalen förstår behovet, måste vissa regler för uppdatering av data ändras, vilket medför risk för fel och förseningar.

Det andra alternativet är att ändra uppdateringsregeln och införliva dessa typer av situationer i ansökan. Det är så att vi gör en ansökan mer flexibel. Det förutser dessa typer av situationer och gör nödvändiga bestämmelser för dem. Men flexibiliteten har en kostnad.

Varje element av flexibilitet gör programvaran skrymmande och komplicerad. Således är det en kompromiss mellan integritet och flexibilitet. När vi integrerar, kommer vi sannolikt att förlora en del av den naturliga flexibiliteten som vi har. Frågan måste lösas av företagsledarna för varje tillfälle och lämplig balans har upprätthållits mellan integration och flexibilitet. Lyckligtvis finns det tillräckligt med utrymme för att balansera de två, eftersom det kan finnas olika grader av integration och flexibilitet.

b) Effektivitet mot flexibilitet:

Det finns en byte mellan effektivitet och flexibilitet. Eftersom man föreskriver fler regler och alternativa scenarier för olika typer av transaktioner blir ansökan mindre effektiv när det gäller hastighet för datainmatning och bearbetningshastighet.

Detta händer på grund av tillägget till antalet variabler som ska utvärderas innan data uppdateras. Det komplicerar också mjukvaran som medför extra kostnader för utbildning. Det kompletterar även hårdvarukraven och data flyger registrerar dessa ytterligare variabler.

Fortsatt med exemplet på försäljningstransaktionen ovan, flexibilitet kan införas för att föreskriva en särskild regel för behandling av sådana försäljningstransaktioner för uppdatering av data. Man får då en ytterligare typ av försäljningstransaktion.

Systemet måste kontrollera för denna typ av transaktioner varje gång den behandlar någon försäljningstransaktion. Detta komplicerar inte bara systemet men kräver också mer behandlingstid. En annan svårighet skulle uppstå när det gäller utbildning av personal i samband med datainmatningen.

Utbildningen ska göra det möjligt för dem att förstå denna typ av transaktion och alla andra som använder informationen om försäljning bör också förstå följderna av behandlingen som ges till en sådan transaktion. Allt detta skulle leda till att mjukvarans effektivitet sänks.

Det finns således ett behov av att väga fördelarna och nackdelarna med att införa flexibilitet med avseende på varje uppgift och varje typ av information och dra en balans mellan effektivitet och flexibilitet.

(c) Kontroll mot flexibilitet:

Flexibilitet har en annan kostnad. Det attackerar kontrollsystemen längst ner. Det tillåter användare att modifiera / omkonfigurera systemet enligt deras behov. Sådana arbetssätt resulterar i försvagning av kontroller som är nödvändiga för att säkerställa datakvaliteten och dess tillförlitlighet. Som noterats i exemplet ovan kan möjligheten att ändra försäljnings- eller köpuppgifter med retroaktiva effekter vara en källa till datormissbruk.

Det finns ingen regel som kan tillämpas universellt för att hantera sådana situationer. Varje situation har analyserats och alternativen utvärderas utifrån kostnader och fördelar för företagen från flexibilitet och integration. Kostnaden för flexibilitet i fråga om komplexitet och andra sådana konsekvenser för systemets effektivitet måste beaktas.