Presented by KARRI GOVINDA RAO , Asst. Prof DEPARTMENT OF COMPUTERSCIENCE AND ENGINEERING VISAKHA INSTITUTE OF ENGINEERING & TECHNOLOGY
Inherent Difficulties Essence and Accident Essence difficulties inherent in the nature of software Accidents difficulties encountered but not inherent Inherent Difficulties Complexity Conformity Changeability Invisibility
Software Engineering Processes attempt to maximize QUALITY in the form of: Testability Understandability Modifiability Reliability Portability Efficiency Human Engineering
Software Engineering Processes Why? Issues concerning software quality Relative costs of fixing faults Price performance factors Product size increase leads to larger teams
What are the phases in the lifecycle of a software product? Requirements Specifications Design Implementation Integration Maintenance Retirement
Requirements Phase “What I need, not what I said I needed” What does the problem require in terms of the solution? Written document Customer driven Requirements testing Rapid prototype Mock-up Partial system
Specifications Phase What the developer wants to know: What does the product do? What are the constraints on the product? Acceptance criteria Frequent problems with a spec: ambiguous incomplete contradictory Specifications testing SQA reviews
Design Phase How does the product do what it is supposed to do? Analysis of the problem Structured analysis : decomposing problem by how data is manipulated (acted upon) Object-oriented analysis: decomposing problem by how data is represented Developer must make design decisions about: algorithms data representations I/O interfaces data flow modules Design testing traceability
Implementation testing Implementation Phase Initial CS courses have to focus on this element first Code Documentation Tests Implementation testing desk checking test cases reviews
Integration Phase Putting it all together Composition order Integration testing interfaces Testing does it meet the specs? product testing by SQA acceptance testing by customer
Maintenance Phase In the user’s hands Why? operation documentation turnover Kinds of maintenance Corrective Adaptive Perfective Preventive Maintenance testing changes regression testing Retirement cost-effective?
Specification principles Separate functionality from implementation A process-oriented systems spec language is required A spec must encompass the system of which the SW is a component A spec must encompass the environment in which the system operates A system spec must be a cognitive model A spec must be operational The spec must be tolerant of incompleteness and augmentable A spec must be localized and loosely coupled
Analysis principles and issues What differentiates one analysis technique from another? hueristics and notions point of view notation modeling approach What things are common about analysis methods? hierarchical representation external and internal interfaces design and implementation foundation no focus on constraints or validation
Analysis principles and issues Analysis is information-driven First provide a mechanism for representing info then derive function and behavior Common characteristics mechanism for info domain analysis approach for functional and/or behavior representation definition of interfaces mechanisms for problem partitioning support of abstraction representation of essential and implementation views
CSE1320 Intermediate Programming Testing Testing cannot show the absence of defects, it can only show that software defects are present. Testing is a process of executing a program with the intent of finding an error. A good test case is one that has a high probability of finding an as yet undiscovered error. A successful test is one that uncovers an as yet undiscovered error. RA402 jcmt CSE1320 Intermediate Programming
White-box or glass-box testing Testing Methods Black-box testing Knowing the specified function that a product has been designed to perform, tests can be conducted that demonstrate each function is fully operational. White-box or glass-box testing Knowing the internal workings of a product, tests can be conducted to ensure that "all the gears mesh". independent paths at least once logical decisions both true and false loops internal data structures
CSE1320 Intermediate Programming Development Testing Debugging approaches brute force backtracking cause elimination Before you fix Is the cause of this bug also reproduced elsewhere? What new bug might I be putting in? What would have prevented this bug? RA402 jcmt CSE1320 Intermediate Programming
Software Configuration Management Change is inevitable Activities of SCM ID change control change ensure that change is properly implemented report change to others SCM output programs documentation data structures SCM is not the same as maintenance
Systems Engineering Issues Takes customer-defined goals and constraints and derives a representation of function, performance, interfaces, design constraints and information structure that can be allocated to each of the generic system elements available.