Software Engineering Chapter 3 CPSC 110 Pascal Brent
Software Engineering Chapter 3 CPSC 110 - Pascal Brent M. Dingle Texas A&M University
Software Engineering w w Robustness of a program Iterative Enhancement Testing and Debugging – types of errors Software Life Cycle
Robustness w In general a robust program is a program that does not fail due to unexpected or unlikely input. w In general a robust program will consider all forms and types of input – including input that is entered incorrectly by the user. w It will guarantee that any assumptions it had to make about the input are indeed true. w How this is accomplished is dependant on the programmer, the problem and ‘other’ things.
Iterative Enhancement w Iterative Enhancement is the process of first designing a simple program and then adding features and refinements as deemed necessary.
Testing and Debugging w This is perhaps THE most important part of programming. w If a program is NOT tested how do you know it was actually programmed correctly? w Even the best algorithms must be explained to the computer correctly.
Testing w Testing a program means running it and trying to find errors in it. w It is best to use as many forms of testing as possible. w It is best to have as many people as possible test the program – and the program’s writers are NOT very good testers because they already know what the program is supposed to do.
Debugging w Debugging is the removing of errors (bugs) from a program. w There are several ‘types’ of errors you will find: n n n syntax errors runtime errors logical errors
Syntax Errors w Syntax errors are violations of the syntax (grammar) rules of the programming language. w These are the ONLY type of errors that the compiler will detect.
Runtime Errors w Runtime errors occur when the program is running. w Most runtime errors involve numeric calculations. w For example: n Because a computer is finite you can increment a number too far – this results in an overflow error. l n In old video games you could ‘flip’ the score back to zero. Other runtime errors are: l l l division by zero taking the square root of a negative number etc. w Do NOT confuse these with logical errors ! w Some say runtime errors are caused by logical errors – but it is more often a failure in robustness.
Logical Errors w Logical errors are mistakes in the algorithm itself. w This means that the program compiles AND runs, but produces an incorrect result. w You will NOT receive any error from the computer concerning these types of errors. w Often these errors involve using less than (<) when you meant to use greater than(>) or something similar. w But every now and then, they are caused by simply using an incorrect algorithm entirely.
Software Life Cycle – in general w There are several different descriptions of the software life cycle found throughout computer science. w For this class we will use the one presented in the book. w If you would like to see others, do some research on it. =)
Software Life Cycle – 6 Phases w w w Analysis and task specification. Design of the software. Implementation (coding). Testing. Maintenance and evolution of the system. Obsolescence.
Analysis Phase w During this phase, many questions are answered in particular the question: WHAT must the software do? w Here it must be determined what the software is expected to do by the person paying for the development and by the expected users. w Usually specifications are set in this phase – or rather the software’s requirements.
Design Phase w This phase answers the question: HOW must the software do (whatever)? and the (whatever) was determined in the Analysis phase. w In this phase algorithms will be selected or created as needed. w The (program and data) structure of the software should also be determined here.
Implementation (coding) Phase w Once the algorithms are determined, they will be coded (programmed into the computer). w Sometimes (often) this phase will lead back to the design phase as unforeseen problems in the design are encountered.
Testing Phase w Testing is often broken down into small pieces so that each part of a piece of software is tested at first. w Once each small part is tested then larger parts are tested and eventually the final product will be tested (all this is theoretical of course =) w Testing is sometimes incorporated into the Design and/or the Implementation Phase and you will bounce back and forth as debugging takes place.
Maintenance Phase w This phase begins immediately after the program is ‘released’ for use. w Inevitably more bugs are found as time goes on and more needs will arise, so the software will need to be maintained – to fix previously unknown bugs, to modify the code to meet new needs, to fix new bugs introduced by the maintenance process itself and so on.
Obsolescence Phase w This phase is entered when a piece of software is seen to no longer have any value. w This does not always mean the software is removed completely from use. w It means that the maintenance phase will no longer occur and that using an obsolete piece of software is ‘at your own risk. ’ w This phase often occurs when a company changes operating systems or computer systems or when technology simply advances beyond the software and better software is available.
End Software Engineering
- Slides: 19