CS 501: Software EngineeringAdministrationBuilding Dependable SystemsPrinciples for Dependable SystemsCase Study: the NSDLQuality Management ProcessesFactors for Reliable SoftwareSlide 8Process (Plan) ReviewsDesign and Code ReviewsBenefits of Design and Code ReviewsReview Team (Full Version)Example: Program DesignProcess1CS 501 Spring 2002CS 501: Software EngineeringLecture 19Reliability I2CS 501 Spring 2002AdministrationNew syllabusQuiz 4 on Thursday, April 3 (no lecture)Lecture 23 on Wednesday April 16 (evening)No office hours this weekNew instructions for submitting questionnairesSee Assignments file on Web site3CS 501 Spring 2002Building 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 2002Case Study: the NSDLDean KrafftComputing and Information ScienceCornell University6CS 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 procedures7CS 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 validation8CS 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 control9CS 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.10CS 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.11CS 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 threatening12CS 501 Spring 2002Review Team (Full Version)Moderator -- 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 process13CS 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 representative14CS 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
View Full Document
Unlocking...