1. Presented by KARRI GOVINDA RAO ,
Asst. Prof
DEPARTMENT OF COMPUTERSCIENCE AND ENGINEERING
VISAKHA INSTITUTE OF ENGINEERING & TECHNOLOGY

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

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

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

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

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

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

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

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

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

11. 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?

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

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

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

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

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

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.