SOFTWARE ENGINEERING

Transcription

1 SOFTWARE ENGINEERING INTRODUCTION TO SOFTWARE ENGINEERING. COURSE STRUCTURE AND REQUIREMENTS Saulius Ragaišis

2 WHAT IS SOFTWARE ENGINEERING?

3 First definition Software engineering is the establishment and use of sound engineering principals in order to obtain economically software that is reliable and work efficiently on real machines. Software Engineering: A Report on a Conference Sponsored by the NATO Science Committee, NATO, 1969.

4 IEEE Computer Society definition 1. The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, that is, the application of engineering to software. 2. The study of the approaches as in (1). IEEE Standard Glossary of Software Engineering Terminology In IEEE Standards Software Engineering, 1999 Edition, Volume One: Customer and Terminology Standards. IEEE Press, 1999.

5 Other definitions (1) The systematic activities involved in the design, implementation and testing of software to optimize its production and support. Canadian Standards Association

6 Other definitions (2) Use of techniques, methods and methodologies to develop high quality software: reliable, easy to understand, useful, modular, efficient, modifiable, reusable, delivered in cost effective and timely manner, good user interface, well documented. Texas A&M University, Computer Science Department

7 Other definitions (3) SE is the discipline concerned with the application of theory, knowledge, and practice for effectively and efficiently building software systems that satisfy the requirements of users and customers. SE is applicable to small, medium, and large-scale systems. It encompasses all phases of the life cycle of a software system. The life cycle includes requirements analysis and specification, design, construction, testing, deployment, and operation and maintenance. Computer Science Curriculum 2008: An Interim Revision of CS ACM and IEEE, 2008.

8 The Computing Disciplines Computer Engineering Computer Science Information Systems Information Technology Software Engineering Computing Curricula 2005: The Overview Report. ACM and IEEE, 2006.

9 CC2005: Computer Engineering

10 CC2005: Computer Science

11 CC2005: Information Systems

12 CC2005: Information Technology

13 CC2005: Software Engineering

14 CC2005: Software Engineering (2) The development of SE is a response to a very real problem: a shortage of degree programs that produce graduates who can properly understand and develop software systems. many believe that they [CS programs] have not been successful at reliably producing graduates able to work effectively on complex software systems that require engineering expertise beyond the level of programming fundamentals.

15 SWEBOK (2004) Guide to the Software Engineering Body of Knowledge, 2004 Version, SWEBOK. IEEE, The software engineering body of knowledge is an all-inclusive term that describes the sum of knowledge within the profession of software engineering. This Guide will seek to identify and describe that subset of the body of knowledge that is generally accepted, even though software engineers must be knowledgeable not only in software engineering, but also, of course, in other related disciplines.

16 SWEBOK 2004: Knowledge Areas Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering tools and methods Software quality

17 SWEBOK 2004: Related disciplines Computer engineering Computer science Management Mathematics Project management Quality management Software ergonomics Systems engineering

18 SWEBOK (2014) SWEBOK v3.0. Guide to the Software Engineering Body of Knowledge. IEEE, The Software Engineering Body of Knowledge is an all-inclusive term that describes the sum of knowledge within the profession of software engineering. However, the SWEBOK Guide seeks to identify and describe that subset of the body of knowledge that is generally recognized or, in other words, the core body of knowledge.

19 SWEBOK 2014: Knowledge Areas Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering models and methods Software quality

20 SWEBOK 2014: Knowledge Areas (2) Software engineering professional practice Software engineering economics Computing foundations Mathematical foundations Engineering foundations

21 Software Engineering in practice

22 Software Engineering in practice (2)

23 COURSE STRUCTURE

24 CSC2008: Software Engineering CSC2008* defines Software Engineering (SE) course(s) consisting of: Core units (minimum coverage 31 hours); Elective units. * Computer Science Curriculum 2008: An Interim Revision of CS ACM and IEEE, 2008.

25 CSC2008 SE: Core units Software Design (8 hours*) Using APIs (5 hours) Tools and Environments (3 hours) Software Processes (2 hours) Requirements Specifications (4 hours) Software Verification and Validation (3 hours) Software Evolution (3 hours) Software Project Management (3 hours) * minimum coverage hours

26 CSC2008 SE: Elective units Component Based Computing Formal Methods Software Reliability Specialized Systems Risk Assessment Robust and Security-Enhanced Programming

27 Our SE course topics Introduction Software-life cycle and process models Software Project Management Requirements Analysis and Specification Object-Oriented Analysis UML Fundamentals Software Design Object-Oriented Design Software Verification and Validation Software Process Software Evolution

28 Our SE course vs. CSC2008 SE Lectures SE course topic hours Introduction 1 CSC 2008 SE Software-life cycle and process models 1 Software Processes 1 Software Project Management 4 Software Project Management + Tools and Environments Requirements Analysis and Specification 3 Requirements Specifications Object-Oriented Analysis 3 + Tools and Environments UML Fundamentals 2 - Software Design 6 Software Design 8 Object-Oriented Design 4 Software Verification and Validation 4 Software Verification and Validation + Tools and Environments Software Process 1 Software Processes 1 Software Evolution 3 Software Evolution 3 - Using APIs CSC min hours Total

29 CSC2008 SE unit Using APIs Learning Objectives: Explain the value of application programming interfaces (APIs) in software development. Use class browsers and related tools during the development of applications using APIs. Design, implement, test, and debug programs that use large-scale API packages. This unit will not be covered in our SE course.

30 REQUIREMENTS

31 Assessment strategy Small individual assignments (0-10%): grade-points are given for correct and fast problem solving. Teamwork assignments (40-50%): the evaluation takes into account correctness, conformance to requirements, readability, delivery on time, and presentation. Exam (written) (50%); all 3 teamwork assignments should be performed.

32 Teamwork assignments Team should consist of 4-5 students. It should be the same for all 3 assignments. 1. Project plan (5 th week) 2. Software requirements specification (9 th week) 3. Software design (13 th week) The exact deliverables of each assignment and requirements for them will be defined during laboratory works.

33 Required reading R. S. Pressman, Software Engineering: a Practitioner s Approach (6th edition), McGraw Hill Higher Education, ISBN B. Oestereich, Developing Software with UML: Object-Oriented Analysis and Design in Practice (2nd edition). Addison-Wesley Professional, ISBN X

34 Recommended reading I. Sommerville, Software Engineering (8th edition). Addison-Wesley, ISBN C. Larman, Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development. Prentice Hall, ISBN A. Cockburn, Writing effective use cases. Addison-Wesley, ISBN

35 Summary General understanding about Software Engineering Overview of the course Exact information about course requirements and assessment strategy

36 QUESTIONS?

37 APPENDIX

38 Engineering vs. Science: Traditional View Scientists create knowledge study the world as it is are trained in scientific method use explicit knowledge are thinkers Engineers apply that knowledge seek to change the are trained in engineering design use tactic knowledge are doers Steve Easterbrook, Department of Computer Science, University of Toronto

39 Engineering vs. Science: More realistic View Scientists create knowledge are problem-driven seek to understand and explain design experiments to test theories prefer abstract knowledge but rely on tactic knowledge Engineers create knowledge are problem-driven seek to understand and explain design devices to test theories prefer contingent knowledge but rely on tactic knowledge Steve Easterbrook, Department of Computer Science, University of Toronto

40 Characteristics of software Software is developed or engineered; it is not manufactured in the classical sense. Software doesn t wear out. Although the industry is moving toward component-based construction, most software continues to be custom built. [Pre2005] R. S. Pressman, Software Engineering: a Practitioner s Approach (6th edition), McGraw Hill Higher Education, 2005.

41 Software myths: Management myths We already have a book that s full of standards and procedures for building software. Won t that provide my people with everything they need to know? If we get behind schedule, we can add more programmers and catch up. If we decide to outsource the software project to a third party, I can just relax and let that firm build it. [Pre2005]

42 Software myths: Customer myths General statement of objectives is sufficient to begin writing programs we can fill in the details later. Project requirements continually change, but change can be easily accommodated because software is flexible. [Pre2005]

43 Software myths: Practitioner s myths Once we write the program and get it to work, our job is done. Until I get the program running, I have no way of assessing its quality. The only deliverable work product for a successful project is the working program. Software engineering will make us create voluminous and unnecessary documentation and invariably slow us down. [Pre2005]