Your SlideShare is downloading. ×
0
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Software engg. pressman_ch-1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Software engg. pressman_ch-1

355

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
355
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman 1
    • 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. 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. Hardware vs. Software Hardware Software  Manufactured  Wears out  Built using components  Relatively simple Developed/engi neered  Deteriorates  Custom built  Complex 4
    • 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. Wear vs. Deterioration Hardware wears out over time 6
    • 7. Wear vs. Deterioration Software deteriorate over time 7
    • 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. 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. ? 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. 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. Why study software engineering  To acquire skills to be a better  programmer:  Higher Productivity  Better Quality Programs 12
    • 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. 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. 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. 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. 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. 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. 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

    ×