Ivica Crnkovic Mälardalen University Department of Computer Science and Engineering

Transcription

1 Ivica Crnkovic Mälardalen University Department of Computer Science and Engineering Page 1, 10/21/2008

2 Contents What is Software Engineering? i Software Engineering and Science Methods of Software Engineering i Software Engineering Research Example Software architecture t Page 2, 10/21/2008

3 What is Software Engineering? Software engineering is an engineering discipline which is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after gone into use. Ian Sommerville, Software Engineering We need further explanation of: Engineering discipline All aspects of software production Page 3, 10/21/2008

4 Engineering Engineers make the things work Solving gproblems understand the problem analyze the problem Find solutions Constructing the solution from parts that address the problem's various aspects - do a synthesis To achieve the goal engineers apply theories, methods and tools from different disciplines Search for solutions even when there is not theory or methods Page 4, 10/21/2008

5 Analysis of a problem PROBLEM Identify different aspects of the problem Arrange the problems in clearly defined and understandable sub-problems Subproblem 1 Subproblem 2 Subproblem 3 Page 5, 10/21/2008

6 The synthesis Find solutions for subproblems Solution 1 Solution 2 Solution 4 Solution 3 Put together solutions to a consistent view Provide (make) a solution SOLUTION Page 6, 10/21/2008

7 Engineering Example the Vasa Ship A master piece of work! 1625 King Gustav II Adolf decided to start build Wasa maiden voyage. Length- 69 metres Maximum width metres From keel to the top of the main mast metres Height of the stern metres Crew: 445 men, Seamen 145, Soldiers Armament 64 guns Thousands of people involved in the project Selecting wood, building different parts Providing food, other services Page 7, 10/21/2008

8 WHat happen with the Vasa ship? Page 8, 10/21/2008

9 Vasa Example of Bad Engineering the ship capsized on her maiden voyage in the harbor of Stockholm. Why did the Vasa capsize? Page 9, 10/21/2008

10 Why did the Vasa capsize? The Vasa capsized because it was not stable; The Vasa capsized because the methods for calculating l stability were now known or the building process (or in terms of software engineering, the development project) was inadequate. Page 10, 10/21/2008

11 How to calculate stability? Gravity force Ship weight Ship s center of gravity Buoyancy (bärkraft) Center of buoyancy (water) displacement The forces are of equal size and in the opposite directions Page 11, 10/21/2008

12 The ship heels at an angle h h leverage effect (påtryckning) Ship s center of gravity Center of buoyancy (water displacement) Has moved right Page 12, 10/21/2008

13 Leverage effect (Moment) Torque is defined as the product of radius, force, and the sine of the angle between force and radius: t = r F (sin(x)) X Page 13, 10/21/2008

14 The ship heels at an angle h leverage effect (påtryckning) This Torque (Moment) will force the Ship to return back h Page 14, 10/21/2008

15 The ship is unstable h leverage effect (påtryckning) Torque has change the direction The ship will capsized h h Page 15, 10/21/2008

16 The ship is stable If the center of gravity is very low the ship will be stable h h Page 16, 10/21/2008

17 Why the ships heel? Because of wind! Or waves h Page 17, 10/21/2008

18 Stability Curve Torque Result = S -W Wind (opposite direction) A S 2 B S 1 α α α α α α Α α 1 α Β α 2 Page 18, 10/21/2008

19 Why did Vasa capsize? It was not stable At that time there was no formal modeling for calculating stability But at that time there were many ships which did not capsized! Page 19, 10/21/2008

20 Why did Vasa capsize? Engineering i Solve problems even when there is no formal theory Experience best practices Observations Rules of thumb Processes to ensure the feasibility of problem solving COULD VASA BE SUCSSESFULLY BUILT IN SPITE OF LACK OF THEORY? WHAT DID PROJECT FAILED TO DO? Page 20, 10/21/2008

21 Other reasons why Vasa capsized? Resource & budget plan. The project was delayed and in its later phases, there was enormous pressure to finish work on time. Project management. The main builder (or in modern terms, the project manager) unfortunately sickened and died during the building of the ship, and the consequence was weak management and very poor coordination of the groups building different parts. Changes in requirements. The original requirement for one gun deck was changed to two gun decks when the building of the ship had already begun. Because the king was behind the decision, its possible consequences were not analyzed. Page 21, 10/21/2008

22 Other reasons why Vasa capsized? Conflicting requirements and trade-off analysis. The Vasa was intended to be a new type of ship combining superior sailing characteristics ti and maneuverability with overwhelming striking force. Design changes during the construction. The dimensions of the ship were changed several times during its construction with no proper analysis of the consequences. Scalability. Vasa was designed d as a smaller ship, and its dimensions were merely proportionally increased. Validation. The stability and other tests were primitive and not well performed. (Test: running across the deck) Page 22, 10/21/2008

23 Vasa Disaster Similar do Software Projects Similar il situation i in software development project No formal/theoretical background for requirements and solution Feasibility of the requirements not analyzed Changes in requirements during the project work Time and Budget not properly planned No proper verification/validation Bad quality assurance Shortage in knowledge in new disciplines... Page 23, 10/21/2008

24 Engineering vs. Software Engineering Many similarities Methods and procedures Similar objectives and goals Many differences Difference between software and hardware/the real world Software no physical limits Not visible Modifiable More complex Different theories and methods used Different experiences, traditions Different maturity level Page 24, 10/21/2008

25 All aspects of Software Development Aspects Technical (how technically solve the problem) Organizational (how to organize people) Financial Marketing Professional and ethical responsibility Research and Science Page 25, 10/21/2008

26 Example distributed software development Developing software on different locations Advantages:. Disadvantages. Different techniques, different processes, different people Page 26, 10/21/2008

27 How to break the barriers? Teachers teachers Common Course Common projects Students Video Conference Web Cameras Chat - Messengers Mail Web Database Students Page 27, 10/21/2008

28 Computer Science Vs. Software Engineering COMPUTER SCIENCE OTHER SCIENCES CUSTOMER Computer Functions Theories Problem Software Engineering Research & Science SOFTWARE ENGINEERING Principles, Methods and Tools to Solve Problem and Construct ssolutions Solution Page 28, 10/21/2008

29 Computer Science Vs. Software Engineering COMPUTER SCIENCE Algorithms and data structures Programming languages Architecture Numerical and symbolic computation Operating systems Software methodology and engineering Databases and information retrieval Artificial intelligence and robotics Human-computer communication Social, ethical, and professional issues SOFTWARE ENGINEERING In many cases a defuse boundaries between SE and CS Page 29, 10/21/2008

30 Methods and Technologies Solution Phases Requirements Analysis Design Implementation Test Delivery Maintenance Service Software/Systems Engineering Methods Different ee Technologies ooges Page 30, 10/21/2008

31 SE disciplines and areas From European Software Engineering Conference and Symposium on the Foundations of Software Engineering Requirements Engineering Component-based Software Specification and Verification Engineering Software Architecture and Model Driven Engineering Design Web Applications Analysis and Testing Distributed Systems and Development Paradigms and Middleware Software Processes Service Oriented Applications Evolution and Refactoring Mobile and Embedded System Tools and Environments Empirical Software Engineering Software Metrics Software Quality and Performance Open Standards and Certification Software Economics and Human Resources Dependability (safety, security, reliability) Case Studies and Experience Reports Page 31, 10/21/2008

32 SE disciplines - more examples Project management Development processes Reverse engineering Software Maintenance Object-oriented modelling Formal specification Software dependability (reliability, safety, ) Real-time Tools and environments Software Configuration Management Software engineering ee g and the Internet Education Software Economics... Page 32, 10/21/2008

33 Software Engineering Methods - Examples Requirements Analysis Design Implementation Test Delivery Maintenance Service Project Management Software Development Models and Processes support Component-based Software Engineering (CBSE) Requirements Engineering Analyse/design methods (UML, OOP, Formal methods,...) Architectural analysis (tradeoff analysis, quality, attributes ) Programming Methods /Languages Configuration Management Test and Verification Customer support, Maintenance Page 33, 10/21/2008

34 What is then Software Engineering Research? Analyzing natures of problems and their solutions Finding more general principles that SE can use Developing methods and tools Implementing principles on new problem domains Page 34, 10/21/2008

35 Software Engineering Research Different methods used SE Exemplified by Software Architecture Presentation extracted from Mary Shaw s presentation on ICSE 2001 in Toronto 2.cs.cmu.edu/ cmu edu/~compose/paper_abstracts/etaps-2002.html Page 35, 10/21/2008

36 The basic characteristic of SE REAL WORLD Practical problem? REAL WORLD Practical Solution Page 36, 10/21/2008

37 Page 37, 10/21/2008

38 Research Strategy Page 38, 10/21/2008

39 Validation of the Result Page 39, 10/21/2008

40 Nasreddin story and Software Engineering Story about a lost ring Nasreddin Hodja Page 40, 10/21/2008

41 Page 41, 10/21/2008

42 SE Research process Research Questions Research Results Result Validation Page 42, 10/21/2008

43 Page 43, 10/21/2008

44 Page 44, 10/21/2008

45 Example: Software Architecture The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them L. Bass, P. Clements, R. Kazman, Software Architecture t In Practise, Addison Wesley, 1998 System subsystem Subsystem component component component Page 45, 10/21/2008

46 Page 46, 10/21/2008

47 Page 47, 10/21/2008

48 Page 48, 10/21/2008

49 Page 49, 10/21/2008

50 Page 50, 10/21/2008

51 Page 51, 10/21/2008

52 Page 52, 10/21/2008

53 Page 53, 10/21/2008

54 Page 54, 10/21/2008

55 Page 55, 10/21/2008

56 Page 56, 10/21/2008

57 Page 57, 10/21/2008

58 Page 58, 10/21/2008

59 Page 59, 10/21/2008

60 Page 60, 10/21/2008

61 Page 61, 10/21/2008

62 Research Model different phases in research life cycle Page 62, 10/21/2008

63 Example:Software architecture New concept: system decomposition System subsystem Subsystem component component component Page 63, 10/21/2008

64 Next step Characterisation - Architectural Style Recurring structures that occur in software systems AS = {Component types,connector types,constraints} Component and Connector Types Pipe and Filter Shared Repository Layered Abstract Machines Buss Page 64, 10/21/2008

65 Next step: Aspects of Software Architecture Further characterisation Elements and Form Connector Attachment Arch Component Port Role (sub)system Representation Rationale Describes how the architecture satisfies system requirements for both functional and extra-functional properties. Page 65, 10/21/2008

66 Next step: Formalization Example - UML IComA <<subsystem>> ComA IComB <<subsystem>> ComB IComA <<subsystem>> ComC Conceptual Architecture Page 66, 10/21/2008

67 Page 67, 10/21/2008

68 Page 68, 10/21/2008

69 Page 69, 10/21/2008

70 Summary Software Engineering i is oriented on practical things from the real word Understanding problems, providing software solutions SE uses methods and tools for solving the problems from different disciplines SE research Understanding principles Defining principle for solving the problems Developing methods and tools Page 70, 10/21/2008