Programvare vedlikehold er praksisen med å fikse bugs og legge til funksjoner til eksisterende programvare plattformer for å møte endrede organisatoriske behov . Det beste estimatet på programmering som en karriere , i henhold til IEEE , er at mer enn 70 prosent av alle dataprogrammering timer brukes over hele verden er viet til programvare vedlikehold . Lage programvare som er enkel å vedlikeholde tar litt strategisk tenkning og due diligence i koding og dokumentasjon praksis. Instruksjoner
en

Start med et design dokument. Spesifisere hva programvaren er ment å oppnå. Beskriv den underliggende metodikk og logisk prosess under den. For modifikasjoner og vedlikehold på eksisterende programvare , beskrive hva den eksisterende programvaren ikke gjorde, og hva virksomheten eller andre behov kjørte gjennomføringen av endringen . Dette dokumentet er en rettesnor for hva som er og ikke er , innenfor rammen av denne software engineering prosjekt .
2

Skriv inn koden modulært . Hvis du kan, opprette en ny modul av kode som presenterer data på måter som den eksisterende programvare kan utnytte. Hvis du ikke kan det, sørg for at du dokumentet hvorfor og hvordan du endret den eksisterende programvare for å ta den nye data format.
3

Behold din variabelbruk til modulen av koden du jobber i når du legger til nye variabler . Ved bruk av eksisterende variabler , tenke to ganger om å implementere kode eller prosedyrer som skriver data til dem - dette er nummer én årsak til forårsaker bugs og programvare glitches nedover veien
4

Kommentar og dokumentere koden din. . Hver gang du definerer en variabel , dokumentere hva som går inn i variabelen , og hvor den skal brukes . Hver gang du skriver data til en variabel , dokumentere hva som blir skrevet inn i den, godkjente formater for dataene , og hva du forventer for utfallet . Hensikten med dette nivået av inline kommenterer og dokumentasjon er å gjøre det mulig for noen (som du , seks måneder senere ) å lese koden og finne ut hva modulen gjør uten å måtte bruke tid sammenlignes med å skrive det å sette det sammen .
5

Test de "dumme bruk " også. Hver programvare ingeniør har skylapper på . De vet hva koden er ment å gjøre , de vil ikke prøve noe fordi det ser fornuftig , men er ikke en del av programmet . Det er alltid en god idé - selv om det er tidkrevende - å sette programvaren foran ikke-tekniske brukere som ellers ville bli konfrontert med det og observere hvordan de samhandler med koden
< . br >