1. Introduction to Software Engineering (2/2) Moonzoo Kim KAIST (slides from CS550 ‘06 taught by prof. D. Bae)

2. Software Development Process 2 A SW Development Framework for SW with High Assurance Formal require- ment Spec. Formal require- ment Spec. Formal system modeling Formal system modeling Model analysis/ verification Model analysis/ verification Model- assisted code generation Model- assisted code generation Model- based testing Model- based testing Runtime monitoring and checking Runtime monitoring and checking Systemdesign Requirementanalysis Designanalysis Implement-ation Testing Monitoring

3. Sources of Errors in S/W Developments 3 Functionality & Misunderstanding 15% Documentation & Others 35% Coding 30% Logic design & Misunderstanding 20%

4. Ex. Requirement on Retail Chain Management Software Find ambiguous points in the following requirement Find ambiguous points in the following requirement If the sales for the current month are below the target sales, then a report is to be printed, If the sales for the current month are below the target sales, then a report is to be printed, unless the difference between target sales and actual sales is less than half of the difference between target sales and actual sales in the previous month unless the difference between target sales and actual sales is less than half of the difference between target sales and actual sales in the previous month or if the difference between target sales and actual sales for the current month is under 5 percent. or if the difference between target sales and actual sales for the current month is under 5 percent. 4

5. Scope of S/W Engineering Historical Aspects Historical Aspects Economic Aspects Economic Aspects Maintenance Aspects Maintenance Aspects Specification & Design Aspects Specification & Design Aspects Team Programming Aspects Team Programming Aspects 5

6. Historical Aspects 1967, A NATO group coined the term " Software Engineering" 1967, A NATO group coined the term " Software Engineering" 1968, NATO conference concluded that software engineering should use the philosophies and paradigms of established engineering disciplines, to solve the problem of software crisis 1968, NATO conference concluded that software engineering should use the philosophies and paradigms of established engineering disciplines, to solve the problem of software crisis 6

7. Economic Aspects Relationship between computer science and software engineering Relationship between computer science and software engineering cf: chemistry and chemical engineering cf: chemistry and chemical engineering Software engineer is intended in only those techniques which make sound economic sense, while computer scientists investigate a variety of ways of producing software, some good and some bad Software engineer is intended in only those techniques which make sound economic sense, while computer scientists investigate a variety of ways of producing software, some good and some bad 7

8. Maintenance Aspects 8 Maintenance 67 % Requirements 3% Specification 4% Planning 2% Module coding 5% Module Testing 7% Integration 6% Design 6%

9. 9 Specification and Design Aspects Requirements Specification Planning Design Implementation Integration Maintenance Approximate relative cost to detect and correct a fault

10. Team Programming Aspect Parnas, "Multi-person construction of multiversion software." Parnas, "Multi-person construction of multiversion software." Programming : personal activity Programming : personal activity S/W engineering : team activity S/W engineering : team activity 10

11. Team Programming Aspect (Cont.) (From programming to sw engineering) Programming in early days Programming in early days The problem is well understood. The problem is well understood. Mostly scientific applications. Mostly scientific applications. By a person, who is an expert in that area. By a person, who is an expert in that area. User = programmer = maintainer User = programmer = maintainer User and programmer separation User and programmer separation User: specify the problem(tasks) User: specify the problem(tasks) Programmer: interpret and translate into code Programmer: interpret and translate into code 11

12. Team Programming Aspect (Cont.) Team project started in late 1960's Team project started in late 1960's IBM360 Operating system IBM360 Operating system Software crisis observed Software crisis observed ``Software Engineering'' coined ``Software Engineering'' coined Solutions to software crisis Solutions to software crisis Management techniques Management techniques Team organization Team organization Chief programmer team Chief programmer team Democratic team Democratic team Hierarchical team Hierarchical team Better languages and tools Better languages and tools Standards Standards ==> Applying engineering approach ==> Applying engineering approach 12

13. Team Programming Aspect (Cont.) Requirements in the programming-in-the-small Requirements in the programming-in-the-small Good programming skill Good programming skill Skilled in data structures and algorithms Skilled in data structures and algorithms Fluent in programming languages Fluent in programming languages Requirements in the programming-in-the large Requirements in the programming-in-the large Needs communication skills and interpersonal skills Needs communication skills and interpersonal skills Be familiar with design approaches (i.e. system abstraction) Be familiar with design approaches (i.e. system abstraction) Top-down design Top-down design Divide and conquer paradigm Divide and conquer paradigm Component based integration Component based integration Be able to translate vague requirements and desires into precise spec. Be able to translate vague requirements and desires into precise spec. Be able to build and use a model of the application Be able to build and use a model of the application Needs ability to schedule work Needs ability to schedule work 13

14. Three Elements of S/W Development 14 Technology Resources Process Quality/ProductivityImprovement ProductProduct Product Facilities Staff Budget Water-fall process Incremental process Evolutionary process OOP Model based testing

15. Special Software Domain:Commercial Electronics and Embedded System

16. /19 Strong IT Industry in South Korea 16 Moonzoo Kim Time-to- Market? SW Quality?

17. What’s Different About Embedded Systems Embedded systems have different design constraints than general purpose systems Embedded systems have different design constraints than general purpose systems Cost may matter more than speed Cost may matter more than speed Long life cycle may dominate design decision Long life cycle may dominate design decision Since ubiquitous computing paradigm occurred, this aspect is changing Since ubiquitous computing paradigm occurred, this aspect is changing Reliability/safety may constraint design choice Reliability/safety may constraint design choice Because applications are often unique, software development may wait for hardware to become available Because applications are often unique, software development may wait for hardware to become available need for simulator/emulators/etc need for simulator/emulators/etc Time to market constraints Time to market constraints Rapid redesign for changing form factors Rapid redesign for changing form factors Rapid redesign for changing control algorithms Rapid redesign for changing control algorithms 17

18. Software Characteristics by Domain Ordinary IT Software System(e.g. systems developed by SI organizations) Ordinary IT Software System(e.g. systems developed by SI organizations) Size : Very Large Size : Very Large Domain consistency: Low Domain consistency: Low New technology sensitivity: High New technology sensitivity: High Hardware dependency: Low Hardware dependency: Low Time-to-market pressure: Low Time-to-market pressure: Low 18

19. Software Characteristics by Domain Commercial Software(e.g. systems developed by software vendors) Commercial Software(e.g. systems developed by software vendors) Size : Large Size : Large Domain consistency: High Domain consistency: High New technology sensitivity: High New technology sensitivity: High Hardware dependency: Low Hardware dependency: Low Time-to-market pressure: Moderate Time-to-market pressure: Moderate 19

20. Software Characteristics by Domain Controller Systems/Automation Systems Controller Systems/Automation Systems Size : Medium Size : Medium Domain consistency: High Domain consistency: High New technology sensitivity: Low New technology sensitivity: Low Hardware dependency: Moderate Hardware dependency: Moderate Time-to-market pressure: Moderate Time-to-market pressure: Moderate 20

21. Software Characteristics by Domain Embedded Systems /Commercial Electronics Embedded Systems /Commercial Electronics Size : Small Size : Small Domain consistency: High (-> Moderate) Domain consistency: High (-> Moderate) New technology sensitivity: High New technology sensitivity: High Hardware dependency: High Hardware dependency: High Time-to-market pressure: High Time-to-market pressure: High 21

22. Software Engineering Applicability In general, Controller Systems/Automation Systems (and Embedded Systems /Commercial Electronics) can give much higher rewards for software engineering activity In general, Controller Systems/Automation Systems (and Embedded Systems /Commercial Electronics) can give much higher rewards for software engineering activity Domain consistency is high and new technology sensitivity is low Domain consistency is high and new technology sensitivity is low Ease of accumulating empirical data Ease of accumulating empirical data High reusability in accumulated developments assets(e.g. requirements specification, domain model, test cases, modules) High reusability in accumulated developments assets(e.g. requirements specification, domain model, test cases, modules) Ease of continuous improvement Ease of continuous improvement 22

23. General Obstacles Hardware dependency is high Hardware dependency is high Software development may wait for hardware to become available Software development may wait for hardware to become available Confident testing environment is not supported even until complete hardware is ready Confident testing environment is not supported even until complete hardware is ready May need for effective simulator/emulator for testing May need for effective simulator/emulator for testing Time-to-market pressure is high Time-to-market pressure is high High schedule pressure causes difficulties in software engineering activities High schedule pressure causes difficulties in software engineering activities Overcome the hardware dependency as much as possible Overcome the hardware dependency as much as possible Set up process to reduce redundant time consumption Set up process to reduce redundant time consumption Asset reuse Asset reuse 23

24. /19 Embedded Software in Two Different Domains 24 Consumer Electronics Safety Critical Systems ExamplesSmartphones, flash memory platforms Nuclear reactors, avionics, cars Market competition HighLow Life cycleShortLong Development time ShortLong Model-based development NoneYes Important value Time-to-marketSafety Moonzoo Kim Model checking Conventional Testing Concolic testing