1 / 124

Introduction to Software Engineering

Introduction to Software Engineering. C.Arunkumar B.E.,M.Tech Assistant Professor(Sr.Gr) - CSE Vice Chair – Council of Wardens – Hostels, Amrita School of Engineering, Coimbatore. Agenda for the Day. What is Software Engineering? Why Software Engineering? How to do Software Engineering?

rnewsom
Télécharger la présentation

Introduction to Software Engineering

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. Introduction to Software Engineering C.Arunkumar B.E.,M.Tech Assistant Professor(Sr.Gr) - CSE Vice Chair – Council of Wardens – Hostels, Amrita School of Engineering, Coimbatore

  2. Agenda for the Day • What is Software Engineering? • Why Software Engineering? • How to do Software Engineering? • Software Process Models • Software Testing

  3. What is Software Engineering? Software Engineering = Software + Engineering • What is Software? Software = Soft + ware Any examples? • What is Engineering? Engineering = Engine-er-ing Any examples? Is this an Engineering discipline? If yes, why? If not, why not? Is this for an Engineer or a scientist?

  4. What is Software Engineering? A historical definition: “The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines …”[Fritz Bauer, at the 1st NATO Conference on Software Engineering, 1969] IEEE definition: “Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.”

  5. Small groups arealso easy to manage! Single-person projects depend on the skill and disciplineof the developer!

  6. Large projects - high cost, heavy resources, critical nature, distributeddevelopment, … - require a moredisciplined and controlledapproach

  7. Software Characteristics • is developed or engineered, rarely manufactured • is custom-built; rarely assembled • is non-material, and therefore does not wear out • is too flexible • is too pliable(easy to bent/shape)

  8. Symptom of Software Crisis • about US$250 billion spent per year in the US on application development • of this, about US$140 billion wasted due to the projects getting abandoned or reworked; this in turn because of not following best practices and standards Ref: Standish Group, 1996

  9. Symptom of Software Crisis • 10% of client/server apps are abandoned or restarted from scratch • 20% of apps are significantly altered to avoid disaster • 40% of apps are delivered significantly late Source: 3 year study of 70 large c/s apps in 30 European firms. Compuware (12/95)

  10. Why Software Engineering? 9 software projects totaling $96.7 million: Where The Money Went [Report to Congress, Comptroller General, 1979] Delivered, but never successfully used 45% Used as delivered 2% Paid for, but not delivered 30% Usable w. rework 3% • Why? • Software hurts • Requirements • design Used w. extensive rework, but later abandoned 20%

  11. The CHAOS Ten 1. Executive Management Support 2. User Involvement 3. Experienced Project Manager 4. Clear Business Objectives 5. Minimized Scope 6. Standard Software Infrastructure 7. Firm Basic Requirements 8. Formal Methodology 9. Reliable Estimates 10. Other What Factors Contribute to Project Success? Standish Group, ‘01 (www.standishgroup.com) Project Success Factors 28% completed on time and on budget • overran original estimates: • Time overrun averaged 63% • - Cost overrun averaged 45% canceled before completion 49% 23%

  12. What Factors Contribute to Project Failure? The CHAOS Ten The CHAOS Ten Standish Group, ‘01 (www.standishgroup.com) “The definition of insanity is doing the same thing over and over again and expecting a different result.” [Albert Einstein]

  13. Factors – Success/Failure • Appropriate senior management levels of commitment to the project • Adequate project funding • A well-done set of project requirements and specifications • Careful development of a comprehensive project plan that incorporates sufficient time and flexibility to anticipate and deal with unforeseen difficulties as they arise • An appropriate commitment of time and attention on the part of those outside the IT department who have requested the project, combined with a willingness to see it through to the end • Candid, accurate reporting of the status of the project and of potential difficulties as they arise • A critical assessment of the risks inherent in the project, any potential harm associated with those risks, and the ability of the project team to manage those risks • The development of appropriate contingency plans that can be employed should the project run into problems • An objective assessment of the ability and willingness of the organization to stay the project course

  14. But the proof of the pudding is in the eating; not in the Recipe ! Software Myths (Management Perspectives) As long as there are good standards and clear procedures in my company, I shouldn’t be too concerned.

  15. The environment is only one of the several factors that determine the quality of the end software product! 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.

  16. Unfortunately, software business does not entertain schedule compaction beyond a limit! 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!

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

  18. Usually, the problems just begin! Software Myths(Developer Perspectives) Once the software is demonstrated, the job is done.

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

  20. The code is only the externally visible component of the entire software complement! Software Myths(Developer Perspectives) The only deliverable for a software development project is the tested code.

  21. Software Product is a product designated for delivery to the user documents sourcecodes reports manuals plans objectcodes data test results test suites prototypes

  22. Boehm’sTop TenIndustrial Software Metrics

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

  24. Effort to Repair Software(when defects are detected at different stages)

  25. Cumulative Effects of Error the real problem requirements correct incorrect hidden missing

  26. Cumulative Effects of Error requirements correct incorrect hidden missing design correct incorrect incorrect incorrect hidden missing

  27. Cumulative Effects of Error design correct incorrect hidden missing code correct incorrect incorrect hidden missing

  28. Boehm’s Top TenIndustrial Software Metrics Nominal software development schedules can be compressed up to 25% (by adding people, money, etc.) but no more. 2

  29. Boehm’s Top TenIndustrial Software Metrics Maintenance costs twice what the development costs. 3

  30. Boehm’s Top TenIndustrial Software Metrics Development and maintenance costs are primarily a function of the size. 4

  31. Boehm’s Top TenIndustrial Software Metrics Variations in humans account for the greatest variations in productivity. 5

  32. Boehm’s Top TenIndustrial Software Metrics The ratio of software to hardware costs has gone from 15:85 in 1985 and continues to grow in favour of software as the dominant cost. 6

  33. Hardware Vs Software Costs

  34. Boehm’s Top TenIndustrial Software Metrics Only about 15% of the development effort is in coding. 7

  35. Distribution of EffortAcross Phases Testing Coding Design Analysis

  36. Boehm’s Top TenIndustrial Software Metrics Applications products cost three times as much per instruction as individual programs; system software products cost nine times as much. 8

  37. Boehm’s Top TenIndustrial Software Metrics Walkthroughs catch 60% of the errors. 9

  38. Distribution of Activitiesin Defect Removal

  39. Boehm’s Top TenIndustrial Software Metrics Many software processes obey a Pareto distribution. 10 20%modules 80%cost

  40. Boehm’s Top TenIndustrial Software Metrics Many software processes obey a Pareto distribution. 10 20%modules 80%errors

  41. Boehm’s Top TenIndustrial Software Metrics Many software processes obey a Pareto distribution. 10 80%cost to fix 20%modules

  42. Boehm’s Top TenIndustrial Software Metrics Many software processes obey a Pareto distribution. 10 20%modules 80%exec time

  43. Boehm’s Top TenIndustrial Software Metrics Many software processes obey a Pareto distribution. 10 20%tools 80%use

  44. Software Process Model

  45. Software process model • Process models prescribe a distinct set of activities, actions, tasks, milestones, and work products required to engineer high quality software. • Process models are not perfect, but provide roadmap for software engineering work. • Software models provide stability, control, and organization to a process that if not managed can easily get out of control • Software process models are adapted to meet the needs of software engineers and managers for a specific project.

  46. Build and Fix Model

  47. Build and Fix Model The earlier approach • Product is constructed without specification or any attempt at design. • Developers simply build a product that is reworked as many times as necessary to satisfy the client. • Model may work for small projects but is totally unsatisfactory for products of any reasonable size. • Maintenance is high. • Source of difficulties and deficiencies • impossible to predict • impossible to manage

  48. Why Models are needed? • Symptoms of inadequacy: the software crisis • Scheduled time and cost exceeded • User expectations not met • Poor quality

  49. Process as a "black box" Quality? Uncertain / Incomplete requirement In the beginning

  50. Problems • The assumption is that requirements can be fully understood prior to development • Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) • Unfortunately the assumption almost never holds

More Related