Planlægning til Software Application Development (3 ting at huske på)
Planlægning af Software Application Development (3 ting at huske på)!
Planlægningen for applikationsudvikling er ikke længere et spørgsmål om at vælge værktøjer, sprog og indkøb af forskellige ressourcer, der kræves til formålet.
Image Courtesy: transformersjobs.com/wp-content/uploads/2013/06/software-engineer.jpg
Med den stigende realisering blandt ledere af deres ret til information 'og brugerens inddragelse i applikationsudviklingsprocessen er der opstået et par beslægtede spørgsmål, der skal sorteres ud.
Disse problemer svæver omkring fire grundlæggende kvaliteter, som man ser efter i et godt informationssystem, nemlig fleksibilitet, integration, effektivitet og kontrol. Interessant nok er disse problemer indbyrdes forbundne, og der er til en vis grad en bytte mellem hver af dem.
(a) Integration vs fleksibilitet:
Integration af hver applikation med informationssystemer til forskellige forretningsfunktioner er en ønsket kvalitet. En sådan integration opnås ved samtidig opdatering af alle relevante data i det øjeblik en given transaktion er taget på rekord i virksomheden.
Integrationen af applikationer sikrer, at hver enkelt i arbejdsgruppen får et konsistent billede af virksomhedens aktuelle realiteter. Dette til gengæld undgår muligheden for modstridende stød på grund af manglende seneste oplysninger til nogle af dem. Men integrationen kan opnås ved at indarbejde regler for opdatering af data i applikationssoftwaren.
En funktionel leder kræver derimod fleksibilitet i disse opdateringsregler. For eksempel vil en salgstransaktion i en integreret applikation opdatere oplysningerne om skyldnerne, i det øjeblik varerne sendes.
På den anden side vil markedsføringschefen kræve, at finansafdelingen forstår, at rabatkursen stadig er omsætningspligtig hos kunden, og varerne afsendes på grund af et presserende krav. Prisen må muligvis revideres senere, mens integrering af ansøgningen generelt ikke tillader ændring af data med tilbagevirkende kraft.
En lignende situation kan opstå i tilfælde af købstransaktion, hvor den aftalte pris er betinget af køb af en vis mængde inden for en bestemt periode. Hvis selskabet ikke er i stand til at løfte den kvalificerede mængde i den angivne tid, kan prisen revideres med tilbagevirkende kraft.
Finans- og revisionspersonalet godkender generelt ikke ændringer med tilbagevirkende kraft. I mangel af integration var problemet simpelt. Den pågældende afdeling kunne kun holde transaktionsdokumentet til det og lade det ikke gå til finansinformationssystemet, indtil det tidspunkt. Selvom finans- og revisionspersonalet forstår behovet, skal nogle af reglerne for opdatering af data ændres, hvilket resulterer i tilhørende risiko for fejl og forsinkelser.
Det andet alternativ er at ændre opdateringsreglen og inkorporere disse typer situationer i applikationen. Sådan gør vi en applikation mere fleksibel. Det forudser disse typer situationer og træffer nødvendige bestemmelser for dem. Men fleksibiliteten har en omkostning.
Hvert element af fleksibilitet gør softwaren klodset og kompliceret. Således er der en bytte mellem integritet og fleksibilitet. Når vi integrerer, vil vi sandsynligvis miste en del af den naturlige fleksibilitet, vi har. Problemet skal løses af virksomhedsledere for hver lejlighed, og der er opretholdt passende balance mellem integration og fleksibilitet. Heldigvis er der nok plads til at afbalancere de to, da der kan være forskellige grader af integration og fleksibilitet.
(b) Effektivitet vs fleksibilitet:
Der er en bytte mellem effektivitet og fleksibilitet. Da man giver mulighed for flere regler og alternative scenarier for forskellige typer transaktioner, bliver applikationen mindre effektiv med hensyn til hastigheden af dataindtastning og hastigheden af behandlingen.
Dette sker på grund af tilføjelsen til antallet af variabler, der skal evalueres, før data opdateres. Det komplicerer også softwaren, der medfører ekstra omkostninger ved træning. Det tilføjer også hardwarekravene, og dataene flyver registrerer disse ekstra variabler.
Fortsat med eksemplet på den ovenfor beskrevne salgstransaktion kan fleksibilitet indføres for at fastsætte en særlig regel for behandling af sådanne salgstransaktioner til opdatering af data. En vil så have en yderligere type salgstransaktion.
Systemet skal kontrollere for denne type transaktioner hver gang det behandler enhver salgstransaktion. Dette komplicerer ikke blot systemet, men kræver også mere behandlingstid. Der vil opstå en anden vanskelighed med hensyn til uddannelse af det personale, der er forbundet med dataindgangen.
Uddannelsen skal gøre det muligt for dem at forstå denne type transaktion, og alle andre, der bruger oplysningerne om salg, bør også forstå konsekvenserne af behandlingen givet til en sådan transaktion. Alt dette vil resultere i at sænke effektiviteten af software.
Der er således et behov for at afveje fordele og ulemper ved at indføre fleksibilitet med hensyn til hver opgave og hver type information og tegne en balance mellem effektivitet og fleksibilitet.
(c) Kontrol vs fleksibilitet:
Fleksibilitet har en anden omkostning. Det angriber styresystemerne lige nederst. Det giver brugerne mulighed for at ændre / omkonfigurere systemet efter deres behov. Sådanne funktionsformer resulterer i svækkelse af kontroller, der er afgørende for at sikre datakvaliteten og dens pålidelighed. Som nævnt i ovenstående eksempel kan muligheden for at ændre salgs- eller købstal med tilbagevirkende effekt være en kilde til computermisbrug.
Der er ingen regel, der kan anvendes universelt til at håndtere sådanne situationer. Hver situation er analyseret, og alternativerne vurderes ud fra omkostninger og fordele til virksomhederne fra fleksibilitet og integration. Omkostningerne ved fleksibilitet med hensyn til kompleksitet og andre sådanne konsekvenser for systemets effektivitet skal tages i betragtning.
