• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Software engg. pressman_ch-1
 

Software engg. pressman_ch-1

on

  • 345 views

 

Statistics

Views

Total Views
345
Views on SlideShare
345
Embed Views
0

Actions

Likes
0
Downloads
16
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Information transformer - function behavior <br /> Computing potential - non-functional behavior <br /> Example of functional behavior? <br /> Type characters into keyboard => word processor displays them on screen <br /> Input program file => compiler translates to byte code <br /> Example of non-functional behavior? <br /> Type character in instant messenger => appears on friend’s screen <br /> Compile large program within a few seconds <br /> Performance - time and space <br /> Vehicle for product delivery <br /> Examples of SW controllers (other than OS) <br /> Examples of communication SW <br /> Examples of development tools <br />

Software engg. pressman_ch-1 Software engg. pressman_ch-1 Presentation Transcript

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