1 / 19

Presented by BHEEMIREDDI CHINNA VENKATA RAMANA, Asst. Prof

Presented by BHEEMIREDDI CHINNA VENKATA RAMANA, Asst. Prof DEPARTMENT OF COMPUTERSCIENCE AND ENGINEERING VISAKHA INSTITUTE OF ENGINEERING & TECHNOLOGY. Inherent Difficulties Complexity Conformity Changeability Invisibility. Essence and Accident. Essence

muriela
Download Presentation

Presented by BHEEMIREDDI CHINNA VENKATA RAMANA, Asst. Prof

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Presented by BHEEMIREDDI CHINNA VENKATA RAMANA, Asst. Prof DEPARTMENT OF COMPUTERSCIENCE AND ENGINEERING VISAKHA INSTITUTE OF ENGINEERING & TECHNOLOGY

  2. Inherent Difficulties Complexity Conformity Changeability Invisibility Essence and Accident • Essence • difficulties inherent in the nature of software • Accidents • difficulties encountered but not inherent

  3. Reliability Portability Efficiency Human Engineering Software Engineering Processes attempt to maximize QUALITY in the form of: • Testability • Understandability • Modifiability

  4. Why? Issues concerning software quality Relative costs of fixing faults Price performance factors Product size increase leads to larger teams Software Engineering Processes

  5. Requirements Specifications Design Implementation Integration Maintenance Retirement What are the phases in the lifecycle of a software product?

  6. What does the problem require in terms of the solution? Written document Customer driven Requirements testing Rapid prototype Mock-up Partial system Requirements Phase“What I need, not what I said I needed”

  7. 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 Specifications PhaseWhat the developer wants to know:

  8. 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 Design PhaseHow does the product do what it is supposed to do?

  9. Code Documentation Tests Implementation testing desk checking test cases reviews Implementation PhaseInitial CS courses have to focus on this element first

  10. Composition order Integration testing interfaces Testing does it meet the specs? product testing by SQA acceptance testing by customer Integration PhasePutting it all together

  11. Maintenance testing changes regression testing Retirement cost-effective? Maintenance PhaseIn the user’s hands • Why? • operation • documentation • turnover • Kinds of maintenance • Corrective • Adaptive • Perfective • Preventive

  12. 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

  13. 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

  14. 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

  15. TestingTesting 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. CSE1320 Intermediate Programming

  16. 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

  17. 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? CSE1320 Intermediate Programming

  18. Activities of SCM ID change control change ensure that change is properly implemented report change to others SCM output programs documentation data structures Software Configuration ManagementChange is inevitable SCM is not the same as maintenance

  19. 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.

More Related