Essence and Accident - PowerPoint PPT Presentation

1 / 19
About This Presentation
Title:

Essence and Accident

Description:

difficulties inherent in the nature of software. Accidents ... Software Engineering Metrics and Models, Conte, S.D., H.E. Dunsmore, V.Y. Shen; ... – PowerPoint PPT presentation

Number of Views:37
Avg rating:3.0/5.0
Slides: 20
Provided by: jcartermat
Learn more at: http://ranger.uta.edu
Category:

less

Transcript and Presenter's Notes

Title: Essence and Accident


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

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

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

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

5
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

6
Specifications PhaseWhat 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

7
Design PhaseHow 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

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

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

10
Maintenance PhaseIn the users hands
  • Why?
  • operation
  • documentation
  • turnover
  • Kinds of maintenance
  • Corrective
  • Adaptive
  • Perfective
  • Preventive
  • Maintenance testing
  • changes
  • regression testing
  • Retirement
  • cost-effective?

11
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

12
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

13
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

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

15
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

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

17
Software Configuration ManagementChange 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
18
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.

19
Software Engineering Notes for CSE1320
Intermediate Programming
  • Sources
  • The Mythical Man-Month, Brooks, Frederick P.
    Addison-Wesley Publishing Company, (Reprint)1982
  • No Silver Bullet Essence and Accidents of
    Software Engineering,, Computer, Vol. 20, No. 4
    (April 1987) pp. 10-19
  • Software Engineering,Schach, Stephen R.Aksen
    Associates Incorporated Publishers, 1990
  • Software Engineering, A Practitioners
    Approach,Pressman, Roger S.McGraw-Hill, Inc.
    1992
  • Software Engineering, Design, Reliability,and
    Management,Shooman, Martin L.McGraw-Hill, Inc.
    1983
  • Software Engineering Metrics and Models, Conte,
    S.D., H.E. Dunsmore, V.Y. ShenThe
    Benjamin/Cummings Publishing Company, Inc., 1986
Write a Comment
User Comments (0)
About PowerShow.com