Software Engineering Introduction

Software Engineering Introduction

• 1.
  FH FFM Software Engineering SoftwareEngineering summer term 2013 - introduction & overview - Dr. Werner Weitershagen W. Weitershagen FH FFM page 01-1 Software Engineering Introduction Why Software Engineering? What is Software Engineering? W. Weitershagen page 01-2 1
• 2.
  FH FFM Software Engineering Bitterreality ... Was eigentlich what is gebraucht wird needed Was Budgetierung what the bewirkt Was der Kunde what the bestellt customer orders budgeting causes Ergebnis der result of Konstruktion construction W. Weitershagen FH FFM Was das Team what the realisiert team realizes page 01-3 Software Engineering Bitter reality ... How the customer explained it How the project leader understood it How the analyst designed it How the programmer wrote it How the consultant described it How the project was documented What operations installed How the customer was billed How it was supported What the customer really needed W. Weitershagen page 01-4 2
• 3.
  FH FFM Software Engineering Bitterreality ... Source: The Standish Group: „Chaos Report“ (2012) The Chaos Report 2012 • successful means on-time, on-budget, and with all features and functions as defined in the initial scope; • challenged means late, over budget, and/or with less features and functions than defined in the initial scope; • failed means cancelled prior to completion, or delivered but never used. W. Weitershagen FH FFM page 01-5 Software Engineering Source: The Standish Group: „Chaos Report“ (2008) Bitter reality ... W. Weitershagen page 01-6 3
• 4.
  FH FFM Software Engineering Bitterreality ... Source: Assure Consulting (2007) Why do it-projects fail? 1. 2. 3. 4. 5. 6. 7. 8. 9. project target is not clear defined time target is not realistic less coordination between project participants less or weak communication in the company project director is overstrained budget target is not realistic fine planning is not carefully done complexity is underestimated reporting / documentation does not work 10. project-cockpit is missing 71 % 61 % 55 % 45 % 44 % 43 % 41 % 39 % 36 % 36 % W. Weitershagen FH FFM page 01-7 Software Engineering Main problems with software no or weak requirement definition; too many change requests within the final implementation phase no product / programm documentation (only source code is not enough!) too big and monolithic program structures with high complexity and no reusability no comprehensive use of methods and tools no (systematic) quality management W. Weitershagen page 01-8 4
• 5.
  FH FFM Software Engineering Weakcommunication between stakeholders? How the customer explained it How the project leader understood it How the analyst designed it How the programmer wrote it How the consultant described it How the project was documented What operations installed How the customer was billed How it was supported What the customer really needed W. Weitershagen FH FFM page 01-9 Software Engineering Stakeholder of it-projects Source: Zuser / Grechenik / Köhle (2004), S. 41 customer W. Weitershagen user developer / programmer contractor page 01-10 5
• 6.
  FH FFM Software Engineering Factorof success: Software Engineering Software Engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, and the study of these approaches. It is the application of engineering to software because it integrates significant mathematics, computer science and practices whose origins are in engineering. The term ‘Software Engineering’ first appeared in the 1968 NATO Software Engineering Conference in Garmisch / Germany and was meant to provoke engineering paradigm thought regarding the perceived "software crisis" at the time. Software should be designed and created carefully and seriously like a building or a machine. W. Weitershagen FH FFM page 01-11 Software Engineering Factors of success Quelle: The Standish Group: „Chaos Report“ (2004) The Standish-Group set 9 critical factors for successful it-projects: 1. clear and well defined project targets 2. (early) participation of the user 3. encouragement by top-management 4. project mangers with experience 5. minimum of functionality 6. iterative and agile proceeding 7. standardized tools and infrastructure 8. stakeholders with qualification 9. formal methods W. Weitershagen page 01-12 6
• 7.
  FH FFM Software Engineering „Magictriangle“ of it-projects QUALITY You can get it good and fast, but then it will be expensive. TIME You can get it good and cheap, but then it needs time. You can get it fast and cheap, but then it will be not very good. COST W. Weitershagen FH FFM page 01-13 Software Engineering Project target the target of a project should be SMART • Specific, • Measurable (or at least evaluable), • Achievable (or Acceptable), • Realistic (given the current state of organizational resources) and • Time terminated (bounded) W. Weitershagen page 01-14 7
• 8.
  FH FFM Software Engineering Project– a really short definition a project • is a temporary endeavour • to create a unique product, service or result W. Weitershagen FH FFM page 01-15 Software Engineering Quelle: The Standish Group: „Chaos Report“ (2012) Proceeding models W. Weitershagen page 01-16 8
• 9.
  FH FFM Software Engineering Proceedingmodels build-and-fix-cycle ( It‘s not a real model!) waterfall model iterative model iterative incremental model spiral model v-model w-model agile methods • Rational Unified Process (RUP) • Extreme Programming (XP) • Scrum W. Weitershagen FH FFM page 01-17 Software Engineering Decisions before starting a software project self-innovation vs. order (= make-or-buy-decision) new development vs. modification individual vs. standard software selection of methods selection of programming language coding environment: conventional vs. open source W. Weitershagen page 01-18 9
• 10.
  FH FFM Software Engineering Possiblesoftware acquisition buy Quelle: Zuser / Grechenik / Köhle (2004), S. 38 fulfilled requirements modify self-made vaguely (many nearly exactly unneeded / (technical limits) unused functions or missing functions) difficult (no or weak documentation) - sw was selfmade: easy; - sw was not self-made: difficult (no or weak documentation) good (when sw has been documented) depends on requirements and spreading - self-made: low - not self-made: high high changeability cost W. Weitershagen FH FFM page 01-19 Software Engineering Documentation requirement definition (rough) concept (Brainstorming / Mindmapping) specification ... W. Weitershagen page 01-20 10
• 11.
  FH FFM Software Engineering LinksUML www.omg.org Object Management Group (OMG) www.uml.org www.uml2.com www.rational.com bzw. www-306.ibm.com/software/rational/uml IBM Rational Software W. Weitershagen page 01-21 11