



















Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
This lecture is part of lecture series for Software Engineering course. Prof. Prateek Aron delivered this lecture at Allahabad University. Its main points are: Static, Dynamic, Verification, Software, Inspections, Testing, Specification, Error, Checklist, System, Overview, Modifications
Typology: Slides
1 / 27
This page cannot be seen from the preview
Don't miss anything!




















๏ To describe the program inspection process and its role in V & V
๏ To explain static analysis as a verification technique
๏ To describe the Cleanroom software development process
๏ Verification : "Are we building the product right"
๏ The software should conform to its specification
๏ Validation : "Are we building the right product"
๏ The software should do what the user really requires
๏ A precise specification must be available
๏ Team members must be familiar with the organisation standards
๏ Syntactically correct code must be available
๏ An error checklist should be prepared
๏ Management must accept that inspection will increase costs early in the software process
๏ Management must not use inspections for staff appraisal
Inspection meeting
Individual preparation
Overview
Planning
Rework
Follow-up
๏ Made up of at least 4 members
๏ Author of the code being inspected ๏ Inspector who finds errors, omissions and inconsistencies ๏ Reader who reads the code to the team ๏ Moderator who chairs the meeting and notes discovered errors
๏ Other possible roles are Scribe and Chief moderator
๏ Checklist of common errors should be used to drive the inspection
๏ Error checklist is programming language dependent
๏ The 'weaker' the type checking, the larger the checklist
๏ Examples: ๏ Initialisation, ๏ Constant naming, ๏ loop termination, ๏ array bounds, etc.
๏ 500 statements/hour during overview
๏ 125 source statement/hour during individual preparation
๏ 90-125 statements/hour can be inspected
๏ Inspection is therefore an expensive process
๏ Inspecting 500 lines costs about 40 man/hours effort
๏ Static analysers are software tools for source text processing They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the Verification & Validation team
๏ Very effective as an aid to inspections. A supplement to but not a replacement for inspections
๏ Control flow analysis. Checks for loops with multiple exit or entry points, finds unreachable code, etc.
๏ Data use analysis. Detects uninitialised variables, variables written twice without an intervening assignment, variables which are declared but never used, etc.
๏ Interface analysis. Checks the consistency of routine and procedure declarations and their use
๏ Information flow analysis. Identifies the dependencies of output variables. ๏ Does not detect anomalies itself but highlights information for code inspection or review
๏ Path analysis. Identifies paths through the program and sets out the statements executed in that path. ๏ Again, potentially useful in the review process
๏ Both these stages generate vast amounts of information. Must be used with care.
๏ Particularly valuable when a language such as C is used which has weak typing and hence many errors are undetected by the compiler
๏ Less cost-effective for languages like Java that have strong type checking and can therefore detect many errors during compilation
๏ Recall that formal methods are based on mathematical representations of the software as a formal specification.
๏ They are concerned with:
๏ Mathematical analysis of the specification; ๏ Transformation of the specification to a more detailed semantically equivalent representation; ๏ Formally verifying that one representation of a system is equivalent to another.
๏ The name is derived from the 'Cleanroom' process in semiconductor fabrication.
๏ The philosophy is defect avoidance rather than defect removal
๏ Software development process based on:
๏ Incremental development ๏ Formal specification. ๏ Static verification using correctness arguments ๏ Statistical testing to determine program reliability.
Construct structured program
Define software increments
Formally verify code
Integrate increment
Formally specify system
Develop operational profile (^) statisticalDesign tests
Test integrated system
Error rework