1. Ch.11 Software Engineering A Preview

2. Ch.12 Outline Definitions of software engineering (SE) Historical origins of SE SE as part of systems engineering SE consists of many activities in addition to programming SE and other disciplines

3. Software Engineering: A Preview A computer science field that is dealing w/ –large & complex sw systems –buit by a team or team of engineers –multi-version systems –long life-cycle (changes -> fix detects, enhance, adaptation to new environment etc.) Ch.13

4. 4 Definitions SE is –«the application of engineering to software» –«application of a systematic, disciplined, quantifiable, approach to development, operation, and maintenance of sw» IEEE –«multi-person construction of multi verison sw» Parnas

5. Ch.15 Meaning Programmer –writes a complete program –a personal activity Software engineer –writes a sw component to be combined w/ components written by other SEs. –components –> reusable, modifiable –a team activity

6. Ch.16 Need Programming evolved by algorithms, data structures, and OO programming. –not helping build [better, larger] software. –writes a complete program –a personal activity differential equation solving (small program) OS developing (scaled-up)

7. Ch.17 Strategy Vital engineering strategy –define problem –use and develop tools and techs. Parameters are not clear for SE –no mathematical tools exist –relies on experience & debate

8. Ch.18 Role of SE in system design SS is a part of a larger systems Software requirements to be balanced against others –eg. Telephone switching system Computers Telephone lines HW (satellite, telephones) a controller SW –eg. Traffic monitoring system –eg. Hospital administration Satisfy requirements of HW, SW, and special devices

9. Ch.19 Role of SE in system design Complex balancing require SE to participate in developing requirements for the whole system. SE is a part of systems engineering –compromise & trade-offs –SW offers flexibility, HW offers performance (eg. Coin-operated coffee machine)

10. A shortened history Programming –place sequence of instructions to get the computer do sth useful –interaction btw programmer & computer –problematic when developing large systems Large SW systems are significanty different Ch.110

11. Ch.111 A shortened history The field of software engineering was born in 1968 in response to chronic failures of large software projects to meet schedule and budget constraints –recognition of "the software crisis" Term became popular after NATO Conference in Garmisch Partenkirchen (Germany), 1968

12. Ch.112 History – problem defined Problems in constructing large systems –understanding of problem –too much communication time –people leaving the Project –changes are not easy to apply

13. Ch.113 History – solutions Offered solutions –better managemet techs –different team organization –better programming languages & tools –uniform coding conventions –mathematical approaches Conclusion: apply engineering to software

14. History SW costs < HW costs (was) SW costs >> HW costs (now) SE deals w/ entire life-cycle –conception -> design -> development -> maintenance -> deployment -> evolution Ch.114

15. Ch.115 Role of software engineer Software Engineer –must be a good-programmer Programming skill not enough (programming-in-the- small) –familiar w/ design –translate vague requirements –form precise specifications –build models to balance trade-offs –A good Communicator –Schedule work (own and others) programming -in-the-large

16. Ch.116 The software lifecycle «In theory- theory and practice are the same. In practice, they never are.» Waterfall model -> life-cycle model 1. Requirements analysis & specification –feasibility study (costs & benefits) –by customer, developer, or marketing org. –should be in end-user terms –requires interaction w/ users

17. Ch.117 The software lifecycle Waterfall model -> life-cycle model 2. System design & specification –architectural (high-level) design –detailed design –what – how dichotomy 3. Coding & module testing –produce actual code for end-user the problem (analysis) to solve (design)

18. Ch.118 The software lifecycle Waterfall model -> life-cycle model 4. Integration & system testing –integrate components & test whole system –might require testing code 5. Delivery & maintenance –deliver product (SW) to the customer –make sure it works well

19. Ch.119 The software lifecycle (a preview) waterfall model Concurrent engineering? parallelism

20. Ch.120 Relationships between SE and other CS disciplines There is a synergistic relationship 1. Programming languages SE -> PL –modularity (Java packages) –Exception-handling (reliable SW) –UI (visual languages) PL -> SE –precise requirement (by machine processible PLs) –Forming a language of commands (UNIX Shell commands) –Formalization leads to automation (exploited for automatic SW generation)

21. Ch.121 Relationships between SE and other CS disciplines 2. Operating systems OS -> SE –initial large projects –virtual machines, levels of abstraction –separation of policy from mechanism fairness in task scheduling – time-slicing concurrency (what – policy) (how – mechanism) SE -> OS –portable OSs –Protected and unprotected kernels (command line interpreter)

22. Ch.122 Relationships between SE and other CS disciplines 3. Databases DB -> SE –data independence notion (separation&specification) Use data w/o worrying about representation DB offers concurrent Access to data (useful component) SE -> DB –long transactions CVS (lock code, work on a small piece, forbid access)

23. Ch.123 Relationships between SE and other CS disciplines 4. Artificial intelligence AI -> SE –explaratory development notion caused uncertainty handling (reverse Software Engineering) –programming assistants –cognitive models UI design SE -> AI –expert systems Separation of «known» facts by «used» rules

24. Ch.124 Relationships between SE and other CS disciplines 5. Theoretical models TM -> SE –Finite-state machines SW specification & SW design –Petri nets Modeling of SW and HW –Logic Specification languages SE -> TM –Abstract data type notion

25. Ch.125 Relationships between SE and other disciplines SE cannot be practiced in vacuum. 1.Management science –project estimation, scheduling, human resource planning 2.Systems engineering –certain laws govern the behavior of any complex system –analysis models

26. Ch.126 Concluding remarks ! SE is an evolving engineering discipline. –deals w/ systematic approaches to building large SW systems by teams of programmers ! We will study essential principles to the engineering activity of building SW.