| Software is zelden vrij van fouten of defecten . Hoewel defecten in de software kan soms rampzalig zijn, kunnen ze worden voorkomen of geminimaliseerd door goede kwaliteitsborging praktijken , configuratiebeheer en defect tracking technologieën . De software defect levenscyclus , dat overlapt de ontwikkeling van software levenscyclus ( SDLC ) , stelt ons in staat om gebreken te volgen en te elimineren zo vroeg mogelijk in de SDLC . Definitie van " Software defect"
heeft vele verwisselbare namen : software bug , fout , fout , fout , crash en anomalie . Het instituut voor elektrische en elektronische techniek ( IEEE ) , de normen lichaam reguleren zelfs de software beroep , definieert een software bug als een programmeerfout die software veroorzaakt een storing . IEEE ziet gebrek als een product anomalie wanneer software voldoet niet aan verwachtingen van de klant en specificaties . Een crash is een extreem geval van een software defect dat de software van verdere werking stopt .
Sommige bronnen van Gebreken
Software defecten
kunnen voortvloeien uit verkeerd eisen van de klant , slechte programmering gewoonten , verkeerde programmering logica , slechte testen en zelfs ongeteste software implementatie scenario's . Bijvoorbeeld , een klant opgeven van een blauwe achtergrond met een website en de ontwikkelaar het produceren van een witte achtergrond is een defect . Hoewel de website draait prima , het niet voldoen aan de eisen van de klant.
Defecten in SDLC
Gebreken
kan zich op elke fase in de ontwikkeling van software life cycle ( SDLC ) . De SDLC fasen zijn requirements analyse , systemen ontwerp , programma-ontwerp , uitvoering van het programma , het programma testen , systeem testen en onderhoud . Dus omdat defecten kan op elke fase , het gebrek levenscyclus impliceert kwaliteitsborging in elke fase . Configuratiebeheer stelt gebreken worden geregistreerd en bijgehouden te verwijderen . Zo gereedschappen voor configuratiemanagement en defect tracking nodig zal zijn in het defect levenscyclus kwaliteitsborging .
Gebreken Life Cycle ( DLC ) Stadia
Gebreken levenscyclus
kan worden beschreven als een vier - fasen . Fase 1 omvat de ontdekking en melding van defecten tijdens fase 2 wordt over het bekijken en het delegeren actie op gebreken . Fase 3 omvat het debuggen en het verwijderen van de gebreken . Fase 4 betreft de bevestiging dat de gebreken zijn verwijderd
DLC : . Stadia 1 en 2
Elke software development organisatie heeft een team van ontwikkelaars en een testteam waarvan de functie is om defecten te ontdekken en te melden bij fase 1 . Meestal het ontwikkelteam zal de software- eisen specificatie , software design specificaties en toepassingen bronnen code om het testteam los . Externe libraries kunnen worden opgenomen . Het testteam test dan voor gebreken in zowel de documenten en broncode . Fase 2 omvat een evaluatievergadering tussen beide teams wanneer een besluit wordt genomen over de ernst, de geldigheid en prioriteit van het defect . Na de beoordeling , zijn bepaalde personen toegewezen verantwoordelijkheid voor de bugs
DLC : . Stadia 3 en 4
In fase 3 , ontwikkelaars analyseren van de broncode naar de oorsprong van de te identificeren de gebreken met het doel ze te verwijderen . Een impact analyse wordt ook uitgevoerd om mogelijke storingen die kunnen optreden bij defecten die onmiddellijk kan worden gecorrigeerd , maar in een laatste softwareversie evalueren . De " vaste " versie van de software ondergaat verder onderzoek . Fase 4 van het defect levenscyclus is gewijd aan confirmatietesten dat de aanbevolen gebreken daadwerkelijk zijn verwijderd en de software is goed genoeg voor verzenden .
|
