Software engg. pressman_ch-1


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Information transformer - function behavior
    Computing potential - non-functional behavior
    Example of functional behavior?
    Type characters into keyboard => word processor displays them on screen
    Input program file => compiler translates to byte code
    Example of non-functional behavior?
    Type character in instant messenger => appears on friend’s screen
    Compile large program within a few seconds
    Performance - time and space
    Vehicle for product delivery
    Examples of SW controllers (other than OS)
    Examples of communication SW
    Examples of development tools
  • Software engg. pressman_ch-1

    1. 1. Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman 1
    2. 2. Software’s Dual Role  Software : is any set of machine-readable instructions that directs a computer's processor to perform specific operations.  Software is a product  Transforms information - produces, manages, acquires, modifies, displays, or transmits information  Delivers computing potential of hardware and networks  Software is a vehicle for delivering a product  Controls other programs (operating system)  Effects communications (networking software)  Helps build other software (software tools & environments) 2
    3. 3. Software  system software( service other Applicationseditor program)- compiler,  application software- MARIO,      TERACOPY engineering/scientific software – CAD TOOL embedded software –automated alarm system, REAL TIME SYSTEM product-line software-MS OFFICE web applications-skype AI software- IMAGE RECOGNITION S/W 3
    4. 4. Hardware vs. Software Hardware Software  Manufactured  Wears out  Built using components  Relatively simple Developed/engi neered  Deteriorates  Custom built  Complex 4
    5. 5. Manufacturing vs. Development  Once a hardware product has been manufactured, it is difficult or impossible to modify. In contrast, software products are routinely modified and upgraded.  In hardware, hiring more people allows you to accomplish more work, but the same does not necessarily hold true in software engineering.  Unlike hardware, software costs are concentrated in design rather than production. 5
    6. 6. Wear vs. Deterioration Hardware wears out over time 6
    7. 7. Wear vs. Deterioration Software deteriorate over time 7
    8. 8. Component Based vs. Custom Built  Hardware products typically employ many standardized design components.  Most software continues to be custom built.  The software industry does seem to be moving (slowly) toward component-based construction. 8
    9. 9. What is Software Engineering? Engineering approach to develop software The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software 9
    10. 10. ? Evolution of an Art into and Engineering Discipline  The early programmers used an exploratory (also called build and fix) style.  In the build and fix (exploratory) style, normally a `dirty' program is quickly developed.  The different imperfections that are subsequently noticed are fixed. 10
    11. 11. Why Study Software Engineering?  To acquire skills to develop large programs.  Ability to solve complex programming problems:  How to break large projects into smaller and manageable parts?  How to use abstraction?  Also learn techniques of:  Specification, design, user interface development, testing, project management, etc. 11
    12. 12. Why study software engineering  To acquire skills to be a better  programmer:  Higher Productivity  Better Quality Programs 12
    13. 13. Software engineering phases:  DEFINITION PHASE: This phase focus on  What info to be processed  What function and performance are desired  What system behavior expected  What interfaces are to be established  What design constraints exist  What validation criteria are identified 13
    14. 14. S/W ENGINEERING PHASES  DEVELOPMENT PHASE This phase focus on  How data is to be structured  How function to be implemented  How procedural details are implemented  How interfaces are to be characterized  How design will be translated into programming language  How test cases are developed 14
    15. 15. s/w engg phases continue..  SUPPORT PHASE This phase focus on  Change associated with error correction  Change associated with enhancement  Change associated with adaptations 15
    16. 16. Software Myths  Affect managers, customers (and other non-technical stakeholders) and practitioners  Are believable because they often have elements of truth, but …  Invariably lead to bad decisions, therefore …  Insist on reality as you navigate your way through software engineering 16
    17. 17. Management Myths  “We already have a book of standards and procedures for building software. It does provide my people with everything they need to know …”  “If my project is behind the schedule, I always can add more programmers to it and catch up …” (a.k.a. “The Mongolian Horde concept”)  “If I decide to outsource the software project to a third party, I can just relax: Let them build it, and I will just pocket my profits …” 17
    18. 18. Customer Myths  “A general statement of objectives is sufficient to begin writing programs - we can fill in the details later …”  “Project requirements continually change but this change can easily be accommodated because software is flexible …” 18
    19. 19. Practitioner’s Myths coding ASAP, because once we write  “Let’s start the program and get it to work, our job is done …”  “Until I get the program running, I have no way of assessing its quality …”  “The only deliverable work product for a successful project is the working program …”  “Software engineering is baloney. It makes us create tons of paperwork, only to slow us down …” 19