MTAT Introduction to Informatics

Size: px
Start display at page:

Download "MTAT Introduction to Informatics"

Transcription

1 MTAT Introduction to Informatics Lecture: Software Engineering Dietmar Pfahl Fall

2 Today: Software is everywhere (=ubiquitous)

3 How did we get there?

4 Before expulsion from paradise No calculation needed No computer needed No software needed Adam & Eve

5 After expulsion from paradise Pre-civilisation: Counting Writing Ancient civilisations (China, India, Persia, Egypt, Greece, ): Number systems Algebra Geometry Logic Astronomy

6 After expulsion from paradise Middle ages: Invention of 0 Development and popularisation of rules for addition and multiplication Production of calculation tables Blaise Pascal: Binary system

7 The computer age starts 19 th inspired by the programmable loom (kudumismasin), Charles Babbage and Ada Lovelace discuss the idea of a programmable calculator 20 th century Conrad Zuse: builds first programmable computers (1930s) Z1 (using relays) Z3 (using tubes) unfinished

8 The computer age evolves 1940s: first functioning computers in USA and UK (Turing) used for number crunching 1950s & 1960s: IBM: Mainframes for commercial use Advanced OS 3 rd gen. programming languages (FORTRAN, COBOL, Algol...) Application programs for commercial use in many fields Software grows, legacy systems

9 1968 NATO Conference in Garmisch- Partenkirchen, Germany Recognition of Software Crisis Coining of term Software Engineering

10 Software Engineering: Why and What?

11 Engineering versus Craftsmanship

12 Engineering versus Craftsmanship Organic growth?

13 Engineering vs. Science Science Detect (and prove) new 'laws' governing reality Proof that a solution to a known problem exists Invent new devices (prototypes) that demonstrate the existence of a solution to a problem Find new problems Engineering Find solutions to known problems under given constraints (time and effort budgets, quality needs = functional and nonfunctional requirements)

14 Magic Triangle of SE

15 SW Eng. vs. 'Other' Engineering SW Engineering: Many engineers (up to 500) collaborate/cooperate to solve a problem Cannot rely on laws of nature (only math/logic and sociology/psychology) Material cost is negligible compared to personnel cost of engineers / Production is not a cost factor Non-SW Engineering: Small teams of engineers solve a problem / design a solution Can rely on laws of nature (i.e., physics and chemistry) Many workers (and much material) involved in the construction/production process of (physical) artifacts

16 What is Software Engineering? Software Engineering = An engineering discipline that is concerned with all aspects of software production. Software Engineers should adopt a systematic and organised approach to their work use appropriate tools and techniques depending on - the problem to be solved, - the development constraints and - the resources available.

17 Elements of Software Engineering

18 The Three Ps in Software Projects Software development happens in projects P? Project P? P?

19 The Three Ps in Software Projects Software development happens in projects Products People Project Processes

20 Products Code: - Production code: - Source code - Object code - Non-production code: - Test code Products Properties of Software: - Functionality - Reliability - Usability - Efficiency - Maintainability - Portability Non-Code: - Requirements - Specifications - Architecture/Design docs - Issue reports - User manuals - Plans of all kinds -... Models Types of Software: - Embedded/real-time - Information System - Web application - System software -...

21 Software in a Car Products ECU = Electronic Control Unit

22 Software in a Car Products ECU = Electronic Control Unit

23 Properties of Software Products The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable. Maintainability Software must evolve to meet changing needs; Dependability (Reliability) Software must be trustworthy; Efficiency Software should not make wasteful use of system resources; Usability Software must be accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems.

24 Product Modeling Products UML = Unified Modeling Language Online information:

25 Products Products Software Engineering helps with: Requirements gathering/analysis (requirements engineering) Defining/analysing architecture/design Defining/selecting/applying modeling languages to create product models (UML, ADL, SDL,...) Analysing/improving code (code smells, refactoring) Defining/analysing code properties (Semi-)automatically generating code and test cases (from models) Detecting and maintaining traceablity between artifacts...

26 The Three Ps in Software Projects Software development happens in projects Products People Project Processes

27 People Roles: - Project Manager - Product Manager - Architect - Programmer - Tester -... Teams: - Team building - Geographically distributed (international/global) - Mechanisms for collaboration/cooperation - Motivation, Personality, Values, Culture People Skills: - Must match roles Training: - Must fill skill-gaps Education: - Curricula (ACM/IEEE) User models

28 ACM/IEEE Curriculum for Undergraduate Studies in SE (2004) People

29 ACM/IEEE Curriculum for Undergraduate Studies in SE (2004) People

30 People People Software Engineering helps with: Defining roles Defining and assessing skills Defining a body of knowledge (SWEBOK) and professional code of ethics Training and education (curricula) Methods, techniques, tools Team building (i.e., global/international teams) Developing tools for developer/team support (IDEs, CSCW)... SWEBOK = Software Engineering Book of Knowledge IDE = Integrated Development Environment (e.g., Eclipse) CSCW = Computer-Supported Cooperative Work

31 The Three Ps in Software Projects Software development happens in projects Products People Project Processes

32 Process (Model) Elements: - Activity - Input/Output Product(s) - Roles - Methods/Techniques/Tools Processes Process Models: - Descriptive PMs - Prescriptive PMs - Standards - Families Process Types: - Heavy-weight (rich) - Light-weight - Lean - Agile - Kanban Process Taxonomy: - Non-engineering processes - Business processes - Social processes - Engineering processes - Product-engineering proc. - Technical prod.-eng. proc. - Managerial prod.-eng. proc. - Process-engineering proc. Processes

33 Process Taxonomy H. Dieter Rombach, Martin Verlage, Directions in Software Process Research, Advances in Computers, Volume 41, Marvin V. Zelkowitz (Ed.), Pages 1-63, Academic Press, Boston, MA, Processes A Process defines Who does What, When and How to reach a specific goal. In software engineering the goal is to build a software product or to enhance an existing one

34 SW Development Process Examples Processes

35 Processes Waterfall Method (naïve) requirements design Unidirectional, no way back implement test finish this step before moving to the next deliver

36 Processes Requirements and Customers

37 Development Process Types Processes RUP = Rational Unified Process XP = Extreme Programming

38 Scrum Elements Process, Artifacts, Roles Processes

39 What is a software process model? Processes A simplified representation (abstraction) of a software process, holistic or presented from a specific perspective in the form of an Electronic Process Guide (EPG) Examples of process perspectives are Workflow perspective sequence of activities Data/Product-flow perspective information flow Role/action perspective who does what?

40 Descriptive vs. Prescriptive Process Models Processes

41 Plan-Do-Check-Act (PDCA): A systematic approach to Software Process Improvement (SPI) PLAN what you want to accomplish over a period of time and what you might do, or need to do, to get there DO what you planned to do CHECK the results of what you did to see if the objective was achieved ACT on the information standardize or plan for further improvement Processes

42 Plan-Do-Check-Act Plan Processes

43 Processes Processes Software Engineering helps with: Defining processes, including: Guidelines, methods, techniques, tools,... Eliciting/discovering processes Describing processes Managed Optimizing Process change management Technology change management Defect prevention Software quality management Quantitative process management Improving processes... Plan-Do-Check-Act Measurement CMMI, TMMI,... Repeatable Defined Peer reviews Intergroup coordination Software product engineering Integrated software management Training programme Organization process definition Organization process focus Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Initial

44 Wrap-Up

45 Software Engineering Consistent application of engineering principles and methods to the development of software (intensive) systems Engineering Principles: Application of systematic (i.e., predictable, repeatable, scalable) procedures - with well-defined goals (e.g., quality, functionality/scope, cost, time) - with well-defined/structured products, processes, and organization Adherence to existing body of knowledge Observation of constraints (standards, time/cost/quality requirements, etc.) Development and use of models

46 Software Engineering Management Consistent application of engineering principles and methods to the development of software (intensive) systems Planning deciding what is to be done Organizing making arrangements Staffing selecting the right people for the job Directing giving instructions Monitoring checking on progress Controlling taking action to remedy hold-ups Innovating finding solutions when problems emerge Representing liaising with clients, users, developers and other stakeholders Engineering Principles: Application of systematic (i.e., predictable, repeatable, scalable) procedures - with well-defined goals (e.g., quality, functionality/scope, cost, time) - with well-defined/structured products, processes, and organization Adherence to existing body of knowledge Observation of constraints (standards, time/cost/quality requirements, etc.) Development and use of models

47 Software Engineering A bridge from customer/user needs to software product Software Product Customer, User Needs

48 Thank You