Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
SOFTWARE ENGINEERING
INTRODUCTION TO SOFTWARE ENGINEERING.
COURSE STRUCTURE AND REQUIREMENTS
Saulius Ragaišis
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]