Software quality assurance


Published on

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software quality assurance

  1. 1. Sof tware Quality Assurance P . Erwin M. Globio, rof MSIT Senior IT Lecturer 1
  2. 2. Sof tware Quality •Qualit y sof t war e is r easonably bug-f r ee •deliver ed on t ime •wit hin budget •meet s r equir ement s and/ or expect at ions •maint ainable. 2
  3. 3. Sof tware Quality • Conf or mance t o explicit ly st at ed f unct ional and per f or mance r equir ement s • explicit ly document ed development st andar ds • implicit char act er ist ics t hat ar e expect ed of all pr of essionally developed sof t war e. 3
  4. 4. Sof tware Quality Emphasis:1. Sof t war e r equir ement s ar e t he f oundat ion f r om which qualit y is measur ed.2. Specif ied st andar ds def ine a set of development cr it er ia t hat guide t he manner in which sof t war e is engineer ed.3. Ther e is a set of implicit r equir ement s t hat of t en goes unment ioned. 4
  5. 5. Categories of sof tware quality f actors1. Fact or s t hat can be dir ect ly measur ed (e.g. er r or s)2. Fact or s t hat can be measur ed indir ect ly (e.g. usabilit y) 5
  6. 6. McCall Sof tware Quality Factors ♦ Pr oduct Oper at ions ♦ Pr oduct Revisions ♦ Pr oduct Tr ansit ion 6
  7. 7. Product Operations Cor r ect ness (Does it do what I want ?) Reliabilit y (Does it do it accur at ely all of t he it em?) Ef f iciency (Will it r un on my har dwar e as well as it can?) I nt egr it y (I s it secur e?) Usabilit y (Can I r un it ?) 7
  8. 8. Product Revisions  Maint ainabilit y (Can I f ix it ?)  Flexibilit y (Can I change it ?)  Test abilit y (Can I t est it ?) 8
  9. 9. Product Transition  Por t abilit y (Will I be able t o use if on anot her machine?)  Reusabilit y (Will I be able t o r euse some of t he sof t war e?)  I nt er oper abilit y (Will I be able t o int er f ace it wit h anot her syst em?) 9
  10. 10. Metrics that af f ect the quality f actor • Har dwar e• Audit abilit y I ndependence• Accur acy • I nst r ument at ion.• Communicat ion • Modular it y. commonalit y • Oper at ibilit y.• Complet eness • Secur it y• Concisenes. • Self -document at ion.• Dat a commonalit y • Simplicit y.• Consist ency • Sof t war e syst em• Er r or Toler ance. independence.• Execut ion ef f iciency. • Tr aceabilit y.• Expandabilit y. • Tr aining.• Gener alit y 10
  11. 11. Sof tware Quality AssuranceI nvolves t he ent ir e sof t war e developmentPROCESS - monit or ing and impr oving t he pr ocess,making sur e t hat any agr eed-upon st andar ds andpr ocedur es ar e f ollowed, and ensur ing t hatpr oblems ar e f ound and dealt wit h.I t is or ient ed t o pr event ion . 11
  12. 12. SQA encompasses:• analysis, design, coding and t est ing met hods and t ools• f or mal t echnical r eviews t hat ar e applied dur ing each sof t war e engineer ing st ep• a mult it ier ed t est ing st r at egy• cont r ol of sof t war e document at ion and t he changes made t o it• a pr ocedur e t o assur e compliance wit h sof t war e development st andar ds• measur ement and r epor t ing mechanisms. 12
  13. 13. Reasons Why Sof tware Have Bugs miscommunicat ion or no communicat ion sof t war e complexit y pr ogr amming er r or schanging r equir ement s t ime pr essur es egos poor ly document ed code sof t war e development t ools 13
  14. 14. SQA Approaches 1. Ver if icat ion and Validat ion 2. Walkt hr ough 3. I nspect ion 14
  15. 15. Common Problems in Sof twareDevelopment Process poor r equir ement s unr ealist ic schedules inadequat e t est ing f eat ur it is miscommunicat ion 15
  16. 16. Common Solutions to Sof twareDevelopment Process Problems solid r equir ement s r ealist ic schedules adequat e t est ing st ick t o init ial r equir ement s as much as possible communicat ion t ools 16
  17. 17. SQA Activities Applicat ion of t echnical met hods. Conduct of f or mal t echnical r eviews.. Test ing of sof t war e.. Enf or cement of St andar ds.. Cont r ol of change. Measur ement . Recor dkeeping and r epor t ing. 17
  18. 18. Good Code a code t hat wor ks, is bug f r ee, and is r eadable and maint ainable I t should be kept in mind t hat excessive use of st andar ds and r ules can st if le pr oduct ivit y and cr eat ivit y 18
  19. 19. Good DesignGood internal design is indicat ed by sof t war e codewhose over all st r uct ur e is: • clear • under st andable • easily modif iable and maint ainable • is r obust wit h suf f icient er r or -handling and st at us logging capabilit y • wor ks cor r ect ly when implement ed 19
  20. 20. Good Design Good f unctional design is indicat ed by an applicat ion whose f unct ionalit y can be t r aced back t o cust omer and end-user r equir ement s. 20
  21. 21. Good User- Interf ace • t he pr ogr am should act in a way t hat least sur pr ises t he user • it should always be evident t o t he user what can be done next and how t o exit • t he pr ogr am shouldn t let t he user s do somet hing st upid wit hout war ning t hem 21
  22. 22. Useful Websites 22
  23. 23. For your IT Training needsProf. Erwin M. Globio, MSITIT Training SpecialistMobile Number: 09393741359 09323956678Email Address:erwin_globio@yahoo.comSkype Id: erwinglobio 23