This document discusses software quality assurance. It defines quality software as being reasonably bug-free, delivered on time and within budget, meeting requirements, and maintainable. It also discusses factors that can directly and indirectly measure quality, categories of quality factors, the McCall model for quality factors, and common problems and solutions in the software development process. The document emphasizes that requirements are foundational to quality and standards guide development. It also covers SQA activities, good code, design, user interfaces, and useful websites.

1. Sof tware Quality
Assurance
P . Erwin M. Globio,
rof
MSIT
Senior IT Lecturer
1

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. 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. 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. Categories of sof tware quality f actors
1. 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. McCall Sof tware Quality Factors
♦ Pr oduct Oper at ions
♦ Pr oduct Revisions
♦ Pr oduct Tr ansit ion
6

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. 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. 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. 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. Sof tware Quality Assurance
I nvolves t he ent ir e sof t war e development
PROCESS - monit or ing and impr oving t he pr ocess,
making sur e t hat any agr eed-upon st andar ds and
pr ocedur es ar e f ollowed, and ensur ing t hat
pr oblems ar e f ound and dealt wit h.
I t is or ient ed t o ' pr event ion' .
11

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. Reasons Why Sof tware Have Bugs
miscommunicat ion or no communicat ion
sof t war e complexit y
pr ogr amming er r or s
changing r equir ement s
t ime pr essur es
egos
poor ly document ed code
sof t war e development t ools
13

14. SQA Approaches
1. Ver if icat ion and Validat ion
2. Walkt hr ough
3. I nspect ion
14

15. Common Problems in Sof tware
Development Process
poor r equir ement s
unr ealist ic schedules
inadequat e t est ing
f eat ur it is
miscommunicat ion
15

16. Common Solutions to Sof tware
Development 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. 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. 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. Good Design
Good internal design is indicat ed by sof t war e code
whose 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. 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. 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. Useful Websites
http://erwinglobio.wix.com/ittraining
http://ittrainingsolutions.webs.com/
http://erwinglobio.sulit.com.ph/
22

23. For your IT Training needs
Prof. Erwin M. Globio, MSIT
IT Training Specialist
Mobile Number: 09393741359
09323956678
Email Address:
erwin_globio@yahoo.com
Skype Id: erwinglobio
23