A Quick Overview of Software Engineering. Paul Klint

Transcription

1 A Quick Overview of Software Engineering Paul Klint

2 g n i t o qu r o f s ie ch g o t l u o Ap me D pers so wspa ne 2

3 3

4 4

5 Software Engineering is about... Building large software systems Using state-of-the-art scientific knowledge Using solid engineering practices Dealing with evolving software Controlling complexity Controlling quality 5

6 Societal Relevance All parts of society essentially depend on software: Government (taxes, social security,...) Healthcare Services (banking and insurance companies) Transportation, logistics, telecommunication Entertainment (games, animation)... 6

7 Facts about Software 50% of all software projects costs more than twice the original budget One-third of all projects has a delay of % 80% of all projects fails Failing software costs in the US 56 billion $ per year 60% of all programmers works on maintenance 7

8 Software Engineering has to reconcile The requirements of the stakeholders and users of a system The engineering of the system including designing, building, testing, and maintaining it The process how to organize all the above 8

9 Requirements 9

10 Requirements 10

11 Requirements Interviews with stakeholders User stories and Use cases Mock ups Early prototypes Customer on site 11

12 User Stories Pattern: As a <role>,i want <goal/desire> As a user, I want to search for my customers by their first and last names. As a want made last user closing the application, I to be prompted to save if I have any change in my data since the save. 12

13 Use Case 13

14 Message Sequence Chart 14

15 Mock-ups 15

16 Engineering Software Architecture Software Design Software Construction Software Quality Assessment Software Maintenance 16

17 Software Architecture and Design 17

18 Sagrada Familia Barcelona, Spain,

19 19

20 20

21 21

22 22

23 23

24 Antoni Gaudi,

25 Why is Gaudi's Design Good? Forms inspired by nature Organic integration of parts Each facade a separate theme Unconventional Impressive Note: miniature models were used to study the design 25

26 Johnson Wax Headquarters

27 Fallingwater,271935

28 Robie House

29 Frank Loyd Wright

30 Why are Loyd Wright's Designs Good? Clear lines and forms Simple Design has a perfect fit with the environment Careful consideration how light enters building 30

31 Gasuniegebouw, Groningen, Alberts en Huut, Mooiste gebouw van Nederland, Trouw,

32 What is Software Architecture? The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. The term also refers to documentation of a system's "software architecture." Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects 32

33 Software Architecture Client-server architecture 33

34 Software Architecture Service Bus 34

35 What is Software Design? Software design is a process of problemsolving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view. Source: Wikipedia 35

36 Software Design Design Patterns Algorithm Design Data design Unclear separation between high-level and low-level concerns 36

37 SW Design is a Wicked Problem No definite formulation of the problem No stopping rule: we never reach the solution Solution not true/false but only good/bad. Many acceptable solutions Every solution may lead to other wicked problems Source: Van Vliet, Software Engineering 37

38 Global SW Design Strategies Top-down: start from problem domain Pro: good fit with the requirements, global picture Con: unclear whether you can reach good (efficient) solution at the code level Bottom-up: start from solutions domain Pro: good solution for local problems Con: unclear whether you will eventually satisfy the global requirements YoYo: reconcile these strategies 38

39 YoYo Design Start with global, top-down, design Do bottom-up design of selected parts to verify that detailed design is feasible Integrate with (and change) global design Repeat 39

40 Software Construction Programming Languages Paradigms: imperative OO functional... Approaches: Design Patterns Domain-specific Languages (DSLs) Model-driven Aspect-oriented programming Tools: IDEs, debuggers, test tools, version management,... 40

41 Software Quality Assessment Software complies with requirements and is functionally correct? Non-functional quality aspects: Performance, reliability, security, maintainability, documentation, ease-of-use,... Rule of thumb: the earlier a problem is found, the cheaper you can fix it: Requirements (1x); Post-release (100x) 41

42 Code Review Interactive session, where a developer explains his/her code to colleagues Finds more errors than any other technique! Pair-programming (discussed later) supports this 42

43 The Word bug In relay-based machines little insects could disrupt machine operation Here a moth found in the Harvard Mark II Now used for software errors Debugging: removing errors 43

44 Testing Testing can only show the presence of bugs, not their absence (Edsger Dijkstra) White-box testing Black-box testing During testing the implementation is known Implementation is unknown Test levels Unit Integration System 44

45 Manual Unit Testing Manually write test cases that exercise a function for average values and boundary values Example: test cases for a list sort function: Empty list Non-empty, sorted, lists Non-empty, reversely sorted, lists Random lists of various sizes 45

46 Automatic Unit Testing Write a predicate issorted to test that a list is sorted. bool testsort(list[int] L) = issorted(sort(l)) Randomly generate lists and use testsort as oracle. This approach is called QuickCheck and is highly effective. 46

47 Test Tools for the Rascal programmer test is a function modifier, currently for Boolean functions without parameters. Use :test on the command line to run all test functions A Master's project is well-advanced to add QuickCheck functionality to Rascal's test framework. 47

48 Testing Rascal itself Thousands of tests for basic language elements and libraries Code examples in Tutor are also executed and also act as tests. Developer and tester should wear different hats 48

49 Testing the Integer public void testint() { asserttrue(runtest("1 == 1;")); asserttrue(runtest("1!= 2;")); asserttrue(runtest("-1 == -1;")); asserttrue(runtest("-1!= 1;")); asserttrue(runtest("1 + 1 == 2;")); asserttrue(runtest(" == 1;")); asserttrue(runtest("1 + (-2) == -1;")); asserttrue(runtest("2-1 == 1;")); asserttrue(runtest("2-3 == -1;")); asserttrue(runtest(" == 3;")); asserttrue(runtest("-2-1 == -3;")); asserttrue(runtest("2 * 3 == 6;")); asserttrue(runtest("-2 * 3 == -6;")); asserttrue(runtest("2 * (-3) == -6;")); asserttrue(runtest("-2 * (-3) == 6;")); asserttrue(runtest("8 / 4 == 2;")); asserttrue(runtest("-8 / 4 == -2;")); asserttrue(runtest("8 / -4 == -2;")); asserttrue(runtest("-8 / -4 == 2;")); asserttrue(runtest("7 / 2 == 3;")); asserttrue(runtest("-7 / 2 == -3;")); asserttrue(runtest("7 / -2 == -3;")); asserttrue(runtest("-7 / -2 == 3;")); asserttrue(runtest("5 % 2 == 1;")); asserttrue(runtest("-5 % 2 == -1;")); asserttrue(runtest("5 % -2 == 1;")); asserttrue(runtest("-2 <= -1;")); asserttrue(runtest("-2 <= 1;")); asserttrue(runtest("1 <= 2;")); asserttrue(runtest("2 <= 2;")); assertfalse(runtest("2 <= 1;")); asserttrue(runtest("-2 < -1;")); asserttrue(runtest("-2 < 1;")); asserttrue(runtest("1 < 2;")); assertfalse(runtest("2 < 2;")); asserttrue(runtest("-1 >= -2;")); asserttrue(runtest("1 >= -1;")); asserttrue(runtest("2 >= 1;")); asserttrue(runtest("2 >= 2;")); assertfalse(runtest("1 >= 2;")); asserttrue(runtest("-1 > -2;")); asserttrue(runtest("1 > -1;")); asserttrue(runtest("2 > 1;")); assertfalse(runtest("2 > 2;")); assertfalse(runtest("1 > 2;")); asserttrue(runtest("(3 > 2? 3 : 2) == 3;")); } asserttrue(runtest("0 / 5 == 0;")); asserttrue(runtest("5 / 1 == 5;")); 49

50 Testing public void sort() { prepare("import List;"); asserttrue(runtestinsameevaluator("{list::sort([]) == [];}")); asserttrue(runtestinsameevaluator("{sort([]) == [];}")); asserttrue(runtestinsameevaluator("{list::sort([1]) == [1];}")); asserttrue(runtestinsameevaluator("{sort([1]) == [1];}")); asserttrue(runtestinsameevaluator("{list::sort([2, 1]) == [1,2];}")); asserttrue(runtestinsameevaluator("{sort([2, 1]) == [1,2];}")); asserttrue(runtestinsameevaluator("{list::sort([2,-1,4,-2,3]) == [-2,-1,2,3, 4];}")); asserttrue(runtestinsameevaluator("{sort([2,-1,4,-2,3]) == [-2,-1,2,3, 4];}")); } 50

51 Test Driven Developmen (TDD) Write test cases first (they act as a specification) Then write the implementation of the code that is tested 51

52 The Software Process 52

53 Software Process All aspects of the software life cycle Two main styles: Waterfall Agile 53

54 Waterfall Model Requirements Design Implementation Verification Maintenance 54

55 Waterfall Model All steps are traceable Solid engineering practices Long development cycles Not so easy to steer the project Much bureaucracy 55

56 Agile Development Originally called Extreme Programming Agile Manifesto Agile Principles Agile Practices Large commercial interests in selling you agile methods 56

57 57

58 Agile Principles Customer satisfaction by rapid delivery of useful software Welcome changing requirements, even late in development Working software is delivered frequently (weeks, not months) Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Daily co-operation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated, trusted, individuals Continuous attention to technical excellence and good design Simplicity- The art of maximizing the amount of work not done - is essential Self-organizing teams Regular adaptation to changing circumstances 58

59 Agile Practices Pair programming Design patterns Continuous Integration Test-driven development Automated unit testing Refactoring 59

60 Agile Development Many agile approaches: SCRUM, Kanban, XP, DSDM There is no scientific proof that waterfall methods or agile methods are better We have done various studies; it is hard to obtain and compare data The influence of individual programmers is large (10x difference between individuals) 60

61 Software Engineering At the core of Many faces: Web technologies Technical Mobile applications Human Gaming Organizational Big Data Scientific computing 61

62 62