CS 501: Software EngineeringAdministrationPrinciples for Dependable SystemsSlide 4Quality Management ProcessesFactors for Reliable SoftwareSlide 7Process (Plan) ReviewsDesign and Code ReviewsBenefits of Design and Code ReviewsReview TeamExample: Program DesignProcessValidation and VerificationDiscussion of Pfleeger, Chapter 8Q1: Failures and FaultsQ2. Types of FaultQ3. TestingQ4. InspectionQ5. Methods of TestingQ6. Test StrategiesQ7. Static and dynamic analysis1CS 501 Spring 2002CS 501: Software EngineeringLecture 21Reliability I2CS 501 Spring 2002Administration3CS 501 Spring 2002Principles for Dependable SystemsThe human mind can encompass only limited complexity:=> Comprehensibility=> Simplicity=> Partitioning of complexity4CS 501 Spring 2002Principles for Dependable SystemsHigh-quality has to be built-in:=> Each stage of development must be done well=> Testing and correction does not lead to quality=> Changes should be incorporated into the structure5CS 501 Spring 2002Quality Management ProcessesAssumption:Good processes lead to good softwareThe importance of routine:Standard terminology (requirements, specification, design, etc.)Software standards (naming conventions, etc.)Internal and external documentationReporting procedures6CS 501 Spring 2002Factors for Reliable Software• Precise, unambiguous specification• Organization culture that expects quality• Approach to software design and implementation that hides complexity (e.g., structured design, object-oriented programming)• Use of software tools that restrict or detect errors (e.g., strongly typed languages, source control systems, debuggers)• Programming style that emphasizes simplicity, readability, and avoidance of dangerous constructs• Incremental validation7CS 501 Spring 2002Quality Management ProcessesChange management:Source code management and version controlTracking of change requests and bug reportsProcedures for changing requirements specifications, designs and other documentationRelease control8CS 501 Spring 2002Process (Plan) ReviewsObjectives:• To review progress against plan (formal or informal)• To adjust plan (schedule, team assignments, functionality, etc.)Impact on quality:Good quality systems usually result from plans that are demanding but realisticGood people like to be stretched and to work hard, but must not be pressed beyond their capabilities.9CS 501 Spring 2002Design and Code ReviewsDESIGN AND CODE REVIEWS ARE A FUNDAMENTAL PART OF GOOD SOFTWARE DEVELOPMENTConceptColleagues review each other's work: can be applied to any stage of software development can be formal or informalMost effective when everybody prepares well.10CS 501 Spring 2002Benefits of Design and Code ReviewsBenefits:• Extra eyes spot mistakes, suggest improvements• Colleagues share expertise; helps with training• An occasion to tidy loose ends• Incompatibilities between components can be identified• Helps scheduling and management control Fundamental requirements:• Senior team members must show leadership• Must be helpful, not threatening11CS 501 Spring 2002Review TeamModerator -- ensures that the meeting moves ahead steadilyScribe -- records discussion in a constructive mannerDeveloper -- person(s) whose work is being reviewedInterested parties -- people above and below in the software processOutside experts -- knowledgeable people who have are not working on this projectClient -- representatives of the client who are knowledgeable about this part of the process12CS 501 Spring 2002Example: Program DesignModerator Scribe Developer -- the design teamInterested parties -- people who created the system design and/or requirements specification, and the programmers who will implement the systemOutside experts -- knowledgeable people who have are not working on this projectClient -- only if the client has a strong technical representative13CS 501 Spring 2002ProcessPreparationThe developer provides colleagues with documentation (e.g., specification or design), or code listing Participants study the documentation in advanceMeetingThe developer leads the reviewers through the documentation, describing what each section does and encouraging questions Must allow plenty of time and be prepared to continue on another day.14CS 501 Spring 2002Validation and VerificationValidation: Are we building the right product?Verification: Are we building the product right?In practice, it is sometimes difficult to distinguish between the two.That's not a bug. That's a feature!15CS 501 Spring 2002Discussion of Pfleeger, Chapter 8Format:State a question.Ask a member of the class to answer. (Sorry if I pronounce your name wrongly.)Provide opportunity for others to comment.When answering:Stand up.Give your name or NetID. Make sure the TA hears it.Speak clearly so that all the class can hear.16CS 501 Spring 2002Q1: Failures and Faults(a) Define the term failure.(b) Define the term fault.(c) What is the usual term for fault?17CS 501 Spring 2002Q2. Types of FaultWhat types of fault cause the following failures:(a) A mathematical function loops for ever from rounding error.(b) A distributed system hangs because of a concurrency problem.(c) After a network is hit by lightning, it crashes on restart.(d) A program dies because the programmer typed: x = 1 instead of x == 1.(e) The President is paid $5 a month instead of $10,005 because the maximum salary allowed by the program is $10,000.(f) An operating system fails because of a page-boundary error in the firmware.18CS 501 Spring 2002Q3. TestingDefine the following. Who carries out each type of test?(a) unit test(b) integration test(c) function test(d) performance test(e) acceptance test(f) installation test19CS 501 Spring 2002Q4. Inspection(a) Define code inspection.(b) How does a code inspection differ from a code review.(c) The book makes some strong claims about the effectiveness of code inspection. Do you believe the claims?(d) A code inspection is a great deal of work. When is it worthwhile?20CS 501 Spring 2002Q5. Methods of Testing(a) Define the terms:closed box testingopen box testing(b) What is the advantage of each approach?(c) In each case, how do you set about selecting test cases?21CS 501 Spring 2002Q6. Test StrategiesDefine (a) statement analysis. (b) branch testingIf every statement and every branch is tested is the program correct?22CS 501 Spring 2002Q7. Static and
View Full Document
Unlocking...