DEVELOPMENT DEVELOPMENT PROCESS AND PROCESS AND

QUALITY ASSURANCEQUALITY ASSURANCE

Paola Di MaioPaola Di Maio

School of ITSchool of IT

MFU.AC.THMFU.AC.TH

INTRODUCTIONINTRODUCTION

Software engineering as a method to Software engineering as a method to reduce risks (what risks?)reduce risks (what risks?)

Some examples:Some examples:

In early 2006 problems in a government's fIn early 2006 problems in a government's financial monitoring software resulted in incinancial monitoring software resulted in incorrect election candidate financial reports orrect election candidate financial reports being made available to the public. The gobeing made available to the public. The government's election finance reporting web vernment's election finance reporting web site had to be shut down until the software site had to be shut down until the software was repaired. was repaired.

A September 2006 news report indicated pA September 2006 news report indicated problems with software utilized in a state goroblems with software utilized in a state government's primary election, resulting in pvernment's primary election, resulting in periodic unexpected rebooting of voter checeriodic unexpected rebooting of voter checkin machines, which were separate from thkin machines, which were separate from the electronic voting machines, and resulted e electronic voting machines, and resulted in confusion and delays at voting sites. Thin confusion and delays at voting sites. The problem was reportedly due to insufficiee problem was reportedly due to insufficient testing.nt testing.

In August of 2006 a U.S. government studIn August of 2006 a U.S. government student loan service erroneously made public tent loan service erroneously made public the personal data of as many as 21,000 bohe personal data of as many as 21,000 borrowers on it's web site, due to a software rrowers on it's web site, due to a software error. The bug was fixed and the governmerror. The bug was fixed and the government department subsequently offered to arrent department subsequently offered to arrange for free credit monitoring services for ange for free credit monitoring services for those affected. those affected.

A software error reportedly resulted in overA software error reportedly resulted in overbilling of up to several thousand dollars to billing of up to several thousand dollars to each of 11,000 customers of a major teleceach of 11,000 customers of a major telecommunications company in June of 2006. ommunications company in June of 2006. It was reported that the software bug was fIt was reported that the software bug was fixed within days, but that correcting the billixed within days, but that correcting the billing errors would take much longer.ing errors would take much longer.

A May 2005 newspaper article reported that A May 2005 newspaper article reported that a major hybrid car manufacturer had to insa major hybrid car manufacturer had to install a software fix on 20,000 vehicles due ttall a software fix on 20,000 vehicles due to problems with invalid engine warning ligo problems with invalid engine warning lights and occasional stalling. In the article, ahts and occasional stalling. In the article, an automotive software specialist indicated n automotive software specialist indicated that the automobile industry spends $2 billithat the automobile industry spends $2 billion to $3 billion per year fixing software proon to $3 billion per year fixing software problems. blems.

WHAT ARE BUGS?WHAT ARE BUGS? BUGS ARE DEFECTSBUGS ARE DEFECTS

At At Harvard one August night in 1945, Hopper and her Harvard one August night in 1945, Hopper and her associates were working on the "granddaddy" of modassociates were working on the "granddaddy" of modern computers, the Mark I. "Things were going badly; ern computers, the Mark I. "Things were going badly; there was something wrong in one of the circuits of ththere was something wrong in one of the circuits of the long glass-enclosed computer," she said. "Finally, se long glass-enclosed computer," she said. "Finally, someone located the trouble spot and, using ordinary tomeone located the trouble spot and, using ordinary tweezers, removed the problem, a two-inch moth. Froweezers, removed the problem, a two-inch moth. From then on, when anything went wrong with a computem then on, when anything went wrong with a computer, we said it had bugs in it." Hopper said that when the r, we said it had bugs in it." Hopper said that when the veracity of her story was questioned recently, "I referrveracity of her story was questioned recently, "I referred them to my 1945 log book, now in the collection of ed them to my 1945 log book, now in the collection of Naval Surface Weapons Center, and they found the rNaval Surface Weapons Center, and they found the r

emains of that moth taped to the page in question."emains of that moth taped to the page in question."

WWhy does software have bugs? hy does software have bugs? MMiscommunication or no communication iscommunication or no communication software complexity - the complexity of current software applications csoftware complexity - the complexity of current software applications c

an be difficult to comprehend for anyone without experience in moderan be difficult to comprehend for anyone without experience in modern-day software development. Multi-tiered applications, client-server ann-day software development. Multi-tiered applications, client-server and distributed applications, data communications, enormous relational d distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the edatabases, and sheer size of applications have all contributed to the exponential growth in software/system complexity. xponential growth in software/system complexity.

programming errors - programmers, like anyone else, can make mistaprogramming errors - programmers, like anyone else, can make mistakes. kes.

changing requirements (whether documented or undocumented) - the changing requirements (whether documented or undocumented) - the end-user may not understand the effects of changes, or may understaend-user may not understand the effects of changes, or may understand and request them anyway - redesign, rescheduling of engineers, efnd and request them anyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be rfects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etcedone or thrown out, hardware requirements that may be affected, etc. .

time pressures - scheduling of software projects is difficult at best, often requtime pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made. es will be made.

egos - people prefer to say things like: 'no problem' 'piece of cake' 'I can whiegos - people prefer to say things like: 'no problem' 'piece of cake' 'I can whip that out in a few hours' 'it should be easy to update that old code' instead op that out in a few hours' 'it should be easy to update that old code' instead of: 'that adds a lot of complexity and we could end up making a lot of mistakesf: 'that adds a lot of complexity and we could end up making a lot of mistakes' 'we have no idea if we can do that; we'll wing it' 'I can't estimate how long it ' 'we have no idea if we can do that; we'll wing it' 'I can't estimate how long it will take, until I take a close look at it' 'we can't figure out what that old spaghwill take, until I take a close look at it' 'we can't figure out what that old spaghetti code did in the first place' If there are too many unrealistic 'no problem's', etti code did in the first place' If there are too many unrealistic 'no problem's', the result is bugs. the result is bugs.

poorly documented code - it's tough to maintain and modify code that is badlpoorly documented code - it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations may written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or nagement provides no incentive for programmers to document their code or write clear, understandable, maintainable code. In fact, it's usually the opposiwrite clear, understandable, maintainable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job securitte: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to y if nobody else can understand it ('if it was hard to write, it should be hard to read'). read').

software development tools - visual tools, class libraries, compilers, scripting software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs. in added bugs.

SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

"The application of systematic, "The application of systematic, quantifiable, disciplined approach to quantifiable, disciplined approach to development, operation and mainteanance development, operation and mainteanance of software: the application of engineering of software: the application of engineering principles to software“ IEEE 610.12principles to software“ IEEE 610.12

SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT PROCESSPROCESS

PROCESS = LIFECYCLEPROCESS = LIFECYCLE

LIFECYCLE=METHOD, STEPSLIFECYCLE=METHOD, STEPS

PPhases of the software cycle and the order ihases of the software cycle and the order in which those phases are executed. n which those phases are executed. 

Different development methods result in Different development methods result in different types of lifecycles: different types of lifecycles:

example: waterfall, v-shaped, spiralexample: waterfall, v-shaped, spiral

General Life Cycle ModelGeneral Life Cycle Model Each phase produces deliverables required by the next phase in the Each phase produces deliverables required by the next phase in the

life cycle.  Requirements are translated into design.  Code is produclife cycle.  Requirements are translated into design.  Code is produced during implementation that is driven by the design.  Testing verified during implementation that is driven by the design.  Testing verifies the deliverable of the implementation phase against requirementes the deliverable of the implementation phase against requirements.s.

REQUIREMENTS REQUIREMENTS

>>>>DESIGN>>>>DESIGN

>>>>IMPLEMENTATION>>>>IMPLEMENTATION

>>>>TESTING>>>>TESTING

WATERFALLWATERFALL

V SHAPEDV SHAPED

INCREMENTALINCREMENTAL

SPIRALSPIRAL

WHAT IS QUALITY?WHAT IS QUALITY?

""Quality software is reasonably bug-free, delivered on time Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or and within budget, meets requirements and/or expectations, and is maintainable. "expectations, and is maintainable. "

1) FIT FOR PURPOSE1) FIT FOR PURPOSE

2) ZERO DEFECT2) ZERO DEFECT

3) COMPLIANT WITH STANDARD3) COMPLIANT WITH STANDARD

(What standards?)(What standards?)

GOOD CODE (examples)GOOD CODE (examples) minimize or eliminate use of global variables. minimize or eliminate use of global variables. use descriptive function and method names - use both upper and lower case, use descriptive function and method names - use both upper and lower case,

avoid abbreviations, use as many characters as necessary to be adequately davoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in nescriptive (use of more than 20 characters is not out of line); be consistent in naming conventions. aming conventions.

use descriptive variable names - use both upper and lower case, avoid abbreviuse descriptive variable names - use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (usations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming convee of more than 20 characters is not out of line); be consistent in naming conventions. ntions.

function and method sizes should be minimized; less than 100 lines of code is function and method sizes should be minimized; less than 100 lines of code is good, less than 50 lines is preferable. good, less than 50 lines is preferable.

function descriptions should be clearly spelled out in comments preceding a fufunction descriptions should be clearly spelled out in comments preceding a function's code. nction's code.

GOOD CODE/2GOOD CODE/2

use whitespace generously - vertically and horizontally use whitespace generously - vertically and horizontally each line of code should contain 70 characters max. each line of code should contain 70 characters max. one code statement per line. one code statement per line. coding style should be consistent throught a program (eg, use of brackets, incoding style should be consistent throught a program (eg, use of brackets, in

dentations, naming conventions, etc.) dentations, naming conventions, etc.) in adding comments, err on the side of too many rather than too few commein adding comments, err on the side of too many rather than too few comme

nts; a common rule of thumb is that there should be at least as many lines of nts; a common rule of thumb is that there should be at least as many lines of comments (including header blocks) as lines of code. comments (including header blocks) as lines of code.

no matter how small, an application should include documentaion of the overno matter how small, an application should include documentaion of the overall program function and flow (even a few paragraphs is better than nothing); all program function and flow (even a few paragraphs is better than nothing); or if possible a separate flow chart and detailed program documentation. or if possible a separate flow chart and detailed program documentation.

make extensive use of error handling procedures and status and error logginmake extensive use of error handling procedures and status and error loggin

gg. .

GOOD DESIGNGOOD DESIGN 'functional design' or 'internal design'. 'functional design' or 'internal design'. Good internal design is indicated by software code whose overall structure iGood internal design is indicated by software code whose overall structure i

s clear, understandable, easily modifiable, and maintainable; is robust with s clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works correctly wsufficient error-handling and status logging capability; and works correctly when implemented. Good functional design is indicated by an application whhen implemented. Good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirementose functionality can be traced back to customer and end-user requirementss

For programs that have a user interface, it's often a good idea to assume thFor programs that have a user interface, it's often a good idea to assume that the end user will have little computer knowledge and may not read a user at the end user will have little computer knowledge and may not read a user manual or even the on-line help; some common rules-of-thumb include: manual or even the on-line help; some common rules-of-thumb include:

the program should act in a way that least surprises the user the program should act in a way that least surprises the user it should always be evident to the user what can be done next and how to eit should always be evident to the user what can be done next and how to e

xit xit the program shouldn't let the users do something stupid without warning thethe program shouldn't let the users do something stupid without warning the

m. m.

SOFTWARE QUALITY SOFTWARE QUALITY STANDARDSSTANDARDS

SEI = 'Software Engineering Institute' at CSEI = 'Software Engineering Institute' at Carnegie-Mellon University; initiated by the arnegie-Mellon University; initiated by the U.S. Defense Department to help improve U.S. Defense Department to help improve software development processes software development processes

CMMICMMI (5 Levels)(5 Levels)

ISOISO

'International Organisation for Standardization' - The ISO 'International Organisation for Standardization' - The ISO 9001:2000 standard (which replaces the previous standa9001:2000 standard (which replaces the previous standard of 1994) concerns quality systems that are assessed rd of 1994) concerns quality systems that are assessed by outside auditors, and it applies to many kinds of produby outside auditors, and it applies to many kinds of production and manufacturing organizations, not just software. ction and manufacturing organizations, not just software. It covers documentation, design, development, productioIt covers documentation, design, development, production, testing, installation, servicing, and other processes. n, testing, installation, servicing, and other processes.

ISO (continued)ISO (continued)

The full set of standards consists of: (a)Q9001-2000 - QuThe full set of standards consists of: (a)Q9001-2000 - Quality Management Systems: Requirements; (b)Q9000-20ality Management Systems: Requirements; (b)Q9000-2000 - Quality Management Systems: Fundamentals and V00 - Quality Management Systems: Fundamentals and Vocabulary; (c)Q9004-2000 - Quality Management Systeocabulary; (c)Q9004-2000 - Quality Management Systems: Guidelines for Performance Improvements. To be ISms: Guidelines for Performance Improvements. To be ISO 9001 certified, a third-party auditor assesses an organiO 9001 certified, a third-party auditor assesses an organization, and certification is typically good for about 3 yearzation, and certification is typically good for about 3 years, after which a complete reassessment is required. Note s, after which a complete reassessment is required. Note that ISO certification does not necessarily indicate qualitthat ISO certification does not necessarily indicate quality products - it indicates only that documented processes y products - it indicates only that documented processes are followed.are followed.

ISO 9126ISO 9126

SixSix high level quality characteristics that can be used in s high level quality characteristics that can be used in software evaluation. oftware evaluation.

functionalityfunctionality reliabilityreliability usabilityusability efficiencyefficiency maintainabilitymaintainability portabilityportability

READING LIST AND READING LIST AND SOURCESSOURCES

httphttp://://wwwwww..softwareqatestsoftwareqatest..comcom//qatfaq1qatfaq1..htmlhtml Various sources form the textbooks and the internetVarious sources form the textbooks and the internet

ASSIGNMENT 1ASSIGNMENT 1

1) Describe advantages and disadvantages 1) Describe advantages and disadvantages of different software development methodsof different software development methods

2) What is quality?2) What is quality?

3) List the most important standards in3) List the most important standards in

Software developmentSoftware development

4) Give some examples of good code4) Give some examples of good code

5) Give some examples of good design5) Give some examples of good design

LEARNING TARGETSLEARNING TARGETS

1. 1. UNDERSTAND RISKS ASSOCIATED WITH UNDERSTAND RISKS ASSOCIATED WITH SOFTWARE AND GIVE SOME EXAMPLESSOFTWARE AND GIVE SOME EXAMPLES

2. UNDERSTAND THE BENEFITS OF SE AND VARIOUS 2. UNDERSTAND THE BENEFITS OF SE AND VARIOUS APPROACHES WITH EXAMPLESAPPROACHES WITH EXAMPLES

3. UNDERSTAND QUALITY3. UNDERSTAND QUALITY

4. DEFINE SOME OF THE MOST IMPORTANT QUALITY 4. DEFINE SOME OF THE MOST IMPORTANT QUALITY STANDARDSSTANDARDS