1 / 55

SOFTWARE ENGINEERING – I

SOFTWARE ENGINEERING – I . CSCS 300 – Fall 2009 Ms. Saira Anwar. SOFTWARE. When executed provide desired features, functions and performance. Enable to adequately manipulate information. Describe operation and use of programs. Definition

Jimmy
Télécharger la présentation

SOFTWARE ENGINEERING – I

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOFTWARE ENGINEERING – I CSCS 300 – Fall 2009 Ms. Saira Anwar

  2. SOFTWARE When executed provide desired features, functions and performance Enable to adequately manipulate information Describe operation and use of programs • Definition • Computer software is the product that software engineers design, build and support. • Software is • Most widely used in all fields • Medical • Telecommunication • Military • Industry etc

  3. DUAL ROLE OF A SOFTWARE • A product itself • Computing Potential • Information transformer • Managing, Producing, Acquiring, Modifying, Displaying • Vehicle to deliver a product • Control of computer • Operating Systems • Communication of information • Networks • Creation of programs • Software tools and environments

  4. TYPES OF SOFTWARE • Generic software • Stand-alone systems produced by a development organization and sold on the open market to any customer • for example word processors, spreadsheets and games • Customized software • Systems commissioned by a particular customer. • for example web sites, air-traffic control systems and software for managing the finances of large organizations

  5. Some Software Characteristics • Software is engineered or developed, not manufactured in the traditional sense. Software does not wear out in the same sense as hardware.

  6. Some Software Characteristics • In theory, software does not wear out at all. BUT, • Hardware upgrades. • Software upgrades.

  7. Some Software Characteristics Thus, reality is more like this. • Most serious corporations control and constrain changes Most software is custom built, and customer never really knows what she/he wants.

  8. ENGINEERING • Definition • Implementation of a solution to a practical problem • activity which aims at • solving a problem • completing a task (definition, design, and specification) • Analysis, design, construction, verification, and management of technical (or social) entities.

  9. WHAT IS SOFTWARE ENGINEERING? Engineering approach to develop software. Building Construction Analogy. Systematic collection of past experience: techniques, methodologies, guidelines.

  10. SOFTWARE ENGINEERING • Definition • Establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.

  11. WHY SOFTWARE ENGINEERING Organized, systematic, and controlled software development Software engineering is concerned with theories, methods and tools for professional software development Customer wants low cost and short time for software development

  12. Why study software engineering? To acquire skills to develop large programs. Exponential growth in complexity and difficulty level with size.

  13. Why study software engineering? Ability to solve complex programming problems: How to break large projects into smaller and manageable parts? Learn techniques of: specification, design, interface development,testing, project management, etc.

  14. Why study software engineering? To acquire skills to be a better programmer: Higher Productivity Better Quality Programs

  15. IMPORTANCE OF SOFTWARE ENGINEERING Software crisis Software quality

  16. SOFTWARE CRISIS Software products: fail to meet user requirements. frequently crash. expensive. difficult to alter, debug, and enhance. often delivered late. use resources non-optimally.

  17. FACTORS CONTRIBUTING TO THE SOFTWARE CRISIS Larger problems, Lack of adequate training in software engineering, Increasing skill shortage, Low productivity improvements.

  18. DIFFERENCE • Software Engineering • Concerned with the practicalities of developing and delivering useful software • A field of study deals with practicalities of software development • Computer science • Concerned with theory and fundamentals • A field of study deals with theories and practices of computation, communication, automation, coordination and data manipulation.

  19. DIFFERENCE • System engineering • Concerned with all aspects of computer-based systems development, including hardware, software, and process engineering • Software engineering • Part of system engineering • Deals with software only

  20. COMPARING SOFTWARE ENGINEERING AND RELATED FIELDS • For further information, check this link • http://en.wikipedia.org/wiki/Comparing_software_engineering_and_related_fields

  21. SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES) As long as there are good standards and clear procedures in my company, I shouldn’t be too concerned. But the proof of the pudding is in the eating; not in the Recipe !

  22. SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES) As long as my software engineers(!) have access to the fastest and the most sophisticated computer environments and state-of-the-art software tools, I shouldn’t be too concerned. The environment is only one of the several factors that determine the quality of the end software product!

  23. SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES) When my schedule slips, what I have to do is to start a fire-fighting operation: add more software specialists, those with higher skills and longer experience - they will bring the schedule back on the rails! (Mongolian Horde Concept) Unfortunately, software business does not entertain schedule compaction beyond a limit! Adding people to a late software projects Make it later

  24. SOFTWARE MYTHS(CUSTOMER PERSPECTIVES) A general statement of objectives is sufficient to get started with the development of software. Missing/vague requirements can easily be incorporated/detailed out as they get concretized. Application requirements can never be stable; software can be and has to be made flexible enough to allow changes to be incorporated as they happen.

  25. SOFTWARE MYTHS(DEVELOPER PERSPECTIVES) Once the software is demonstrated, the job is done. Usually, the problems just begin!

  26. Until the software is coded and is available for testing, there is no way for assessing its quality. SOFTWARE MYTHS(DEVELOPER PERSPECTIVES) Usually, there are too many tiny bugs inserted at every stage that grow in size and complexity as they progress thru further stages!

  27. The only deliverable for a software development project is the tested code. SOFTWARE MYTHS(DEVELOPER PERSPECTIVES) The code is only the externally visible component of the entire software complement!

  28. SOFTWARE PRODUCT is a product designated for delivery to the user documents sourcecodes reports manuals plans objectcodes data test results test suites prototypes

  29. Software Myths • Reality: Requirements changes are a major cause of software degradation. • Myth: It’s in the software. So, we can easily change it. Myth: We can solve schedule problems by adding more programmers. • Reality: Maybe. It increases coordination efforts and may slow things down. Myth: While we don’t have all requirements in writing yet, we know what we want and can start writing code. • Reality: Incomplete up-front definition is the major cause of software project failures.

  30. Software Myths • Myth: Writing code is the major part of creating a software product. • Reality: Coding may be as little as 10% of the effort, and 50 - 70% may occur after delivery.

  31. Software Myths Myth: I can’t tell you how well we are doing until I get parts of it running. • Reality: Formal reviews of various types both can give good information and are critical to success in large projects. Myth: The only deliverable that matters is working code. • Reality: Documentation, test history, and program configuration are critical parts of the delivery. Myth: I am a (super) programmer. Let me program it, and I will get it done. • Reality: A sign of immaturity. A formula for failure. Software projects are done by teams, not individuals, and success requires much more than just coding.

  32. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS

  33. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS Finding and fixing a software problem after delivery of the product is 100 times more expensive than defect removal during requirements and early design phases. 1

  34. EFFORT TO REPAIR SOFTWARE(WHEN DEFECTS ARE DETECTED AT DIFFERENT STAGES)

  35. Nominal software development schedules can be compressed up to 25% (by adding people, money, etc.) but no more. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 2

  36. Maintenance costs twice what the development costs. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 3

  37. Development and maintenance costs are primarily a function of the size. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 4

  38. Variations in humans account for the greatest variations in productivity. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 5

  39. The ratio of software to hardware costs has gone from 15:85 in 1985 and continues to grow in favor of software as the dominant cost. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 6

  40. HARDWARE VS SOFTWARE COSTS

  41. Only about 15% of the development effort is in coding. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 7

  42. DISTRIBUTION OF EFFORTACROSS PHASES Testing Coding Design Analysis

  43. Applications products cost three times as much per instruction as individual programs; system software products cost nine times as much. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 8

  44. Walkthroughs catch 60% of the errors. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 9

  45. DISTRIBUTION OF ACTIVITIESIN DEFECT REMOVAL

  46. Many software processes obey a Pareto distribution. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 10 20%modules 80%cost

  47. Many software processes obey a Pareto distribution. BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS 10 20%modules 80%errors

More Related