software engineeringragaisis/psi_inf2012/se-01-introduction.pdfin ieee standards software...

SOFTWARE ENGINEERING

INTRODUCTION TO SOFTWARE ENGINEERING.

COURSE STRUCTURE AND REQUIREMENTS

Saulius Ragaišis

saulius.ragaisis@mif.vu.lt

WHAT IS SOFTWARE ENGINEERING?

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.

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 610.12-1990. In IEEE Standards Software Engineering, 1999 Edition, Volume One: Customer and Terminology Standards. IEEE Press, 1999.

Other definitions (1)

• The systematic activities involved in the design, implementation and testing of software to optimize its production and support. Canadian Standards Association

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

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 2001. ACM and IEEE, 2008.

The Computing Disciplines

• Computer Engineering

• Computer Science

• Information Systems

• Information Technology

• Software Engineering Computing Curricula 2005: The Overview Report. ACM and IEEE, 2006.

CC2005: Computer Engineering

CC2005: Computer Science

CC2005: Information Systems

CC2005: Information Technology

CC2005: Software Engineering

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.”

SWEBOK

Guide to the Software Engineering Body of Knowledge, 2004 Version, SWEBOK®. IEEE, 2004. “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.”

SWEBOK: 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

SWEBOK: Related disciplines

• Computer engineering

• Computer science

• Management

• Mathematics

• Project management

• Quality management

• Software ergonomics

• Systems engineering

Software Engineering in practice

Software Engineering in practice (2)

COURSE STRUCTURE

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 2001. ACM and IEEE, 2008.

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

CSC2008 SE: Elective units

• Component Based Computing

• Formal Methods

• Software Reliability

• Specialized Systems

• Risk Assessment

• Robust and Security-Enhanced Programming

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

Our SE course vs. CSC2008 SE

SE course topic Lectures

hours CSC 2008 SE CSC min

hours

Introduction 1

Software-life cycle and process models 1 Software Processes 1

Software Project Management 4 Software Project Management + Tools and Environments

4

Requirements Analysis and Specification 3 Requirements Specifications + Tools and Environments

5

Object-Oriented Analysis 3

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

4

Software Process 1 Software Processes 1

Software Evolution 3 Software Evolution 3

- Using APIs

Total 32 26

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.

REQUIREMENTS

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. If exam evaluation is < 2, the final grade is < 5.

Teamwork assignments

Team should consist of 4-5 students. It should be the same for all 3 assignments.

1. Project plan (5th week)

2. Software requirements specification (9th week)

3. Software design (13th week)

The exact deliverables of each assignment and requirements for them will be defined during laboratory works.

Required reading

• R. S. Pressman, Software Engineering: a Practitioner’s Approach (6th edition), McGraw Hill Higher Education, 2005. ISBN 0071238409

• B. Oestereich, Developing Software with UML: Object-Oriented Analysis and Design in Practice (2nd edition). Addison-Wesley Professional, 2002. ISBN 020175603X

Recommended reading

• I. Sommerville, Software Engineering (8th edition). Addison-Wesley, 2007. ISBN 0321313798

• C. Larman, Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development. Prentice Hall, 2010. ISBN 0131489062

• A. Cockburn, Writing effective use cases. Addison-Wesley, 2006. ISBN 0201702258

Summary

• General understanding about Software Engineering

• Overview of the course

• Exact information about course requirements and assessment strategy

QUESTIONS?

APPENDIX

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

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

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.

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]

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]

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]