Page 1
9/5/2014
1
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
MTAT.03.094
Software Engineering
Lecture 01:
Course Introduction
Dietmar Pfahl
email: [email protected] Fall 2014
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Structure of Lecture 01
• General Course Information/Overview
• Introduction into Software Engineering
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Course Information/Overview
• Level: Bachelor’s level (in English)
• Credits: 6 ECTS, 4 CP
• Pre-requisite: MTAT.03.130 Object-oriented Programming (6 ECTS, 4 CP)
• Work load (per student):
• Lectures: 14 x 2 = 28 hours
• Lab work (incl. independent work): 14 x (2 + 5) = 98 hours
• Exam preparation: 30 hours
• Assessment:
• 7 Lab Assignments / Tasks (team work) – 70% of grade
• 1 Exam (written) – 30% of grade
• Grade scale: A (90%+), B(80%+), C(70%+), D(60%+), E(50%+), F
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Letter Grades
A - An excellent performance, clearly outstanding. The candidate demonstrates excellent
judgement and a high degree of independent thinking.
B - A very good performance. The candidate demonstrates sound judgement and a very good
degree of independent thinking.
C - A good performance in most areas. The candidate demonstrates a reasonable degree of
judgement and independent thinking in the most important areas.
D - A satisfactory performance, but with significant shortcomings. The candidate demonstrates
a limited degree of judgement and independent thinking.
E - A performance that meets the minimum criteria, but no more. The candidate demonstrates a
very limited degree of judgement and independent thinking.
F - A performance that does not meet the minimum academic criteria. The candidate
demonstrates a lack of both judgement and independent thinking.
Last year (2013/14): A – Excellent 32 B – Very good 48 C – Good 30 D – Satisfactory 18 E – Sufficient 2 F – Insufficient 7
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Student Feedback – 2013/14
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Course Objectives
• To obtain basic knowledge in software engineering and primary skills for working at any stage of software development projects.
Required pre-requisite:
• Compulsory: MTAT.03.130 Object-oriented Programming (6 ECTS, 4 CP)
Related courses:
• Systems Modelling (MTAT.03.083)
• Software Project (MTAT.03.138)
• Information Systems (MTAT.03.139)
• Software Economics (MTAT.03.244)
That implies that we (I and the lab supervisors) take it for granted that you know the principles of object-oriented programming and how to program java code.
Page 2
9/5/2014
2
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Learning Outcomes
• Upon successful completion of this course, you should be able
to demonstrate basic knowledge of and skills in:
• software engineering paradigms;
• system analysis;
• requirements analysis;
• planning;
• implementation;
• quality assurance (verification and validation; testing);
• maintenance (evolution);
• project management;
• software processes and methodology.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Schedule of Lectures (Tentative)
Week 01: Introduction to SE
Week 02: Requirements Engineering I
Week 03: Requirements Engineering II
Week 04: Analysis
Week 05: Development Infrastructure I
Week 06: Development Infrastructure II
Week 07: Architecture and Design
Week 08: Refactoring
Week 09: Verification and Validation I
Week 10: Verification and Validation II
Week 11: Software Quality
Management
Week 12: Agile/Lean Methods
Week 13: Measurement & Process
Improvement
Week 14: Course wrap-up, review and
exam preparation
Week 15: no lecture
Week 16: no lecture
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Recommended Literature (Readings)
• Ian Sommerville: Software Engineering, 9th edition, 2010 (http://www.softwareengineering-9.com/)
• Ivan Marsic: Software Engineering, 2012 (http://www.ece.rutgers.edu/~marsic/books/SE/book-SE_marsic.pdf)
• Chapters 1-6 (selective)
(more literature is listed on the course wiki)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Course Wiki: https://courses.cs.ut.ee/2014/SE/fall/Main/HomePage
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Project Topic: POS System (POS: Point-of-Sale)
Intro
• Congratulations, you are employed as an analyst by "Joostes Marss AS" company. During the first day at work you are informed that "Joostes Marss" got a new client who needs a new POS system. Your new boss is patting your shoulder and says that you are responsible for the project and become the lead analyst of the project.
Customer
• Your customer is the “Beerhouse International” company. This company is mostly dealing with the management of beer restaurants. Currently, the company has 32 restaurants in Estonia, Latvia, Lithuania and Finland. Your customer has ambitions to expand to 100 restaurants, and enter the markets of Sweden and Norway. The company's concept is to mostly sell local beer brands with a small addition of international brands from their supply network (Guinness, Corona, …). Today, your customer is using a different POS software in their restaurants, which makes it expensive to maintain business processes across the company. The administration decided to replace their current POS software by a new software solution developed specifically for their needs.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Project Tasks (Labs)
• Week 01: no labs
• Weeks 02-05: Task 1: Requirements gathering
• Weeks 03-06: Task 2: Formalizing, modeling, planning
• Weeks 05-08: Task 3: Development infrastructure
• Weeks 07-10: Task 4: Realization - I
• Weeks 09-12: Task 5: Realization - II
• Weeks 11-14: Task 6: Automatic testing and refactoring
• Weeks 13-16: Task 7: Verification and validation
Details can be found on the course wiki
Page 3
9/5/2014
3
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Project Set-Up
Within each lab group (1 to 7),
students are divided into
project teams of three (or
four).
Each project team has a
permanent lab instructor and a
fixed weekly lab time.
Each project team gets 7
tasks, each task equaling a
maximum of 10 grading points.
Submission of task solutions
has strict deadlines.
Penalties for late delivery
are as follows:
up to 24 h late: -10%
up to 7x24h late: -50%
> 7x24h late: -100%
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Week Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7
2 Assigned
3 Consult Assigned
4 Submit* Consult
5 Assess Submit* Assigned
6 Assess Consult
7 Submit* Assigned
8 Assess Consult
9 Submit* Assigned
10 Assess Consult
11 Submit* Assigned
12 Assess Consult
13 Submit* Assigned
14 Assess Consult
15 Submit*
16 Assess
Project Schedule
* = submit before midnight of the day before Lab
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Project Rules (1)
• Teams must deliver their solutions to their lab assistant using course development environment via repository on GitHub.
• You will get a brief intro on how to use GitHub in the first lab session.
• Delivered solutions must be presented/explained to the lab assistant by a randomly selected team member during assessment sessions.
• It is important for the solution presenter to know every aspect of the solution and be able to explain them. If he/she needs help from other team members, they may jump in and help.
• Not being able to explain solution aspects or answer technical questions will lead to penalties.
• During the assessment session teams have to be present with ALL their team members.
• If team members are missing without acceptable excuse (e.g., illness confirmed by a doctor's note), penalties apply.
• Please see also: https://courses.cs.ut.ee/2014/SE/fall/Main/Grading
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Project Rules (2)
• Each team must complete all tasks independently.
• This does not mean that you are not allowed to talk to other teams and discuss solutions.
• Communication is a good thing and we welcome it.
• However, copying the work of others, i.e., copying of code, is considered plagiarism and strongly prohibited (we have special software for automatic checks).
• According to University rules, if we find evidence of plagiarism, we must inform the head of Institute and formal steps will be taken.
• If something in a homework task assignment is not clear to you, then you should ask for clarifications from your lab assistant (during consulting sessions – or immediately when the task is introduced/assigned).
• If you detect that a task is unclear only at the night before the deadline (when your lab assistant is not available for you) then you should stick to as close to a real world solution as possible: the solution/result should be such that you (and your customer) get maximum benefit from it in the real world.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Lab Instructors
• Margus Luik ([email protected] ):
• Mondays 16:15-18:00, Liivi 2-202 (Lab Group 1)
• Wednesdays 12:15-14:00, Liivi 2-206 (Lab Group 7)
• Kristiina Rahkema ([email protected] ):
• Tuesdays 10:15-12:00, Liivi 2-205 (Lab Group 2)
• Wednesdays 12:15-14:00, Liivi 2-205 (Lab Group 4)
• Mati Kärner ([email protected] ):
• Tuesdays 10:15-12:00, Liivi 2-206 (Lab Group 3)
• Tuesdays 14:15-16:00, Liivi 2-205 (Lab Group 5)
• Kauri Kägo ([email protected] ):
• Thursdays 12:15-14:00, Liivi 2-004 (Lab Group 6)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Assessment (1)
• Labs – 70% of total grade
• Exam – 30% of total grade
• Rules: • All team members receive equal grades in labs
• BUT: This year, exceptions from equal grade rule will be made, if individuals
in a team don’t participate actively
• Penalties apply for late delivery / not atttending assessment session
• Don’t plagiarize!
• Proposed Exam Dates: • Exam 1: Friday 09-Jan-2015 (tentative)
• Exam 2: Friday 16-Jan-2015
• (Retake: Wednesday 21-Jan-2015)
Alternative: Have exam 1 on Friday, 19 Dec 2014. What do you prefer?
Page 4
9/5/2014
4
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Assessment (2)
Labs – Practical Assessment
10 points per lab session. Total = 70 points.
If you get less than 30 out of 70 points in the practical assessment, you will get a grade of 'F' in your first examination (i.e., exam 1/2).
In this case, you will be given a second chance to improve your practical assessment score.
If your score after the improvement is at least 30 out of 70, you will become eligible for a retake exam (korduseksam).
Exam – Conceptual Assessment
The Conceptual Assessment will consist of an exam worth 30 points.
Students who get less than 10 out of 30 in this exam, will get a grade of 'F', regardless of their Practical Assessment score.
This same rule will apply for the retake exam (korduseksam).
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
GO TO LABS !!!!
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
FORM PROJECT TEAMS!
Student lists:
https://courses.cs.ut.ee/2014/SE/fall/Main/HomePage
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Communication Rules
Message Board !!!
Lab Lab Instructors (Kristiina, Margus, Mati Kauri)
Members of a team will - as much as possible - be treated equally. That implies that each member of a team will get the same grades.
If you encounter problems within a team (e.g., lack of communication or active participation of a team member) try to solve the problems first internally. If that doesn't work, notify your lab assistant and ask him for help to get the team back on track.
Lecture/Exam Dietmar
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
ASK QUESTIONS
(I will try my best to give satisfactory answers)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Structure of Lecture 01
• General Course Information/Overview
• Introduction into Software Engineering
Acknowledgement:
- Ian Sommerville: Software Engineering, 9th edition, 2010
- Ivan Marsic: Software Engineering, 2012
Page 5
9/5/2014
5
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Schedule of Lectures (Tentative)
Week 01: Introduction to SE
Week 02: Requirements Engineering I
Week 03: Requirements Engineering II
Week 04: Analysis
Week 05: Development Infrastructure I
Week 06: Development Infrastructure II
Week 07: Architecture and Design
Week 08: Refactoring
Week 09: Verification and Validation I
Week 10: Verification and Validation II
Week 11: Software Quality
Management
Week 12: Agile/Lean Methods
Week 13: Measurement & Process
Improvement
Week 14: Course wrap-up, review and
exam preparation
Week 15: no lecture
Week 16: no lecture
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
FAQs about SE
• What is software?
• What is software engineering?
• What is the difference between software engineering and computer science?
• What is the difference between software engineering and system engineering?
• What is a software process?
• What is a software process model?
• What are the costs of software engineering?
• What are software engineering methods?
• What are the attributes of good software?
• What are the key challenges facing software engineering?
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What is Software?
• Computer programs and associated documentation such as requirements, design models, test cases, user manuals, etc.
• Software products may be developed for a particular customer or may be developed for a general market.
• Bespoke (custom-made) - developed for a single customer according to their specification.
• Generic (market-driven) - developed to be sold to a range of different customers e.g. PC software such as Excel or Word, Apps, etc.
• New software can be created by
• developing new programs (‘green-field development’),
• configuring generic software systems or
• reusing existing software (own or third-party).
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What is Software Engineering?
• Software Engineering = An engineering discipline that is concerned with all aspects of software production.
• Software engineers should
• adopt a systematic and organised approach to their work and
• use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Engineering versus Craftsmanship
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Engineering versus Craftsmanship
Organic growth?
Page 6
9/5/2014
6
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
The Role of Software Eng. (1)
Customer / User Programmer
A bridge from customer/user needs to programming/implementation
First law of software engineering: Software engineer is willing to learn the problem domain (problem cannot be solved without understanding it first)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
The Role of Software Eng. (2)
Customer:
Requires a computer system to achieve some business goals
by user interaction or interaction with the environment
in a specified manner
System-to-be
Software-to-be
System-to-be
Software-to-beUser
Software Engineer’s task:
To understand how the system-to-be needs to interact with
the user or the environment so that customer’s requirement is met
and design the software-to-be
Programmer’s task:
To implement the software-to-be
designed by the software engineer
Environment
May be the
same person
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What is the difference between software engineering and computer science?
• Computer Science is concerned with theory and fundamentals (e.g., formal semantics, computability);
• Software Engineering is concerned with the practicalities of developing and delivering useful software (function/quality – time – money/effort).
--
• Computer science theories are (still) insufficient to act as a complete underpinning for software engineering (unlike e.g. in physics and electrical engineering).
• Why?
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Magic Triangle of SE
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What is the difference between software engineering and system engineering?
• System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering.
• Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system.
• System engineers vs. Software engineers
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Embedded Software in a Car (1)
Page 7
9/5/2014
7
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Embedded Software in a Car (2)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What is a software process?
• A set of activities whose goal is the development or evolution of software.
• Generic activities in all software processes are:
• Specification - what the system should do and its development constraints
• Development - production of the software system
• Validation - checking that the software is what the customer wants
• Evolution - changing the software in response to changing demands.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What is a software process model?
• A simplified representation (abstraction) of a software process, presented from a specific perspective.
• Examples of process perspectives are
• Workflow perspective - sequence of activities;
• Data/Product-flow perspective – information flow;
• Role/action perspective - who does what.
• Generic process models
• Waterfall;
• Incremental and iterative development;
• Component-based software engineering;
• Product Lines.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What are the costs of software engineering?
• Roughly 60% of costs are construction (specification, development, evolution) costs, 40% are testing (verification, validation) costs.
• For custom software, evolution costs often exceed development costs.
• Costs vary depending on
• the type of system being developed and
• the requirements of system attributes such as performance and system reliability.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What are software engineering methods?
• Structured approaches to software development which include models, notations, rules, design advice and process guidance.
• Modelling (notations)
• Descriptions of (graphical) models which should be produced;
• Rules / Recommendations
• Constraints applied to models;
• Advice on good design practice;
• Process guidance
• What activities to follow; what responsibilities (roles) to assign; what artefacts to produce; what tools to use; etc.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
UML – Language of Symbols
«interface»
BaseInterface
+ operation()
Actor
ClassName
# attribute_1 : int
# attribute_2 : boolean
# attribute_3 : String
+ operation_1() : void
+ operation_2() : String
+ operation_3(arg1 : int)
Software Class
Three common
compartments:
1. Classifier name
2. Attributes
3. Operations
Comment
Class1Implement
+ operation()
Class2Implement
+ operation()
Software Interface Implementation
Interaction Diagram
doSomething()
instance1 : Class1 instance5 : Class2 instance8 : Class3
doSomethingElse()
doSomethingYetElse()
Inheritance
relationship:
BaseInterface
is implemented
by two classes
Stereotype
«» provides
additional info/
annotation/
explanation
UML = Unified Modeling Language
Online information: http://www.uml.org
Page 8
9/5/2014
8
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What are the attributes of good software?
The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable.
Maintainability
Software must evolve to meet changing needs;
Dependability (Reliability)
Software must be trustworthy;
Efficiency
Software should not make wasteful use of system resources;
Usability
Software must be accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
What are the key challenges facing software engineering?
Heterogeneity, delivery and trust.
• Heterogeneity
• Developing techniques for building software that can cope with heterogeneous platforms and execution environments;
• Delivery
• Developing techniques that lead to faster delivery of software;
• Trust
• Developing techniques that demonstrate that software can be trusted by its users.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Key points (so far)
• Software engineering is the engineering discipline that is concerned with all aspects of software production.
• Software products consist of developed programs and associated documentation.
• Essential product attributes are maintainability, dependability, efficiency and usability.
• The software process consists of activities that are involved in developing software products.
• Basic activities are software specification, development, validation and evolution.
• Methods are organised ways of producing software.
• They include suggestions for the process to be followed, the notations to be used, rules governing the software system descriptions which are produced and design guidelines.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Software Development Methods
Method = work strategy / process
• The Feynman Problem-Solving Algorithm:
• (i) Write down the problem (ii) think very hard, and (iii) write down the
answer.
• Waterfall
• Unidirectional (naïve version), finish current step before moving to the
next
• Iterative + Incremental (Evolutionary)
• Develop increment of functionality, repeat in a feedback loop
• Agile (& Lean)
• User feedback essential; feedback loops on several levels of
granularity
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Waterfall Method (naïve)
Deployment &
Maintenance
Requirements
Design
Implementation
TestingWaterfall
method
Unidirectional, no way back finish this step before moving to the next
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Waterfall: Royce Model (1970)
SYSTEM
REQUIREMENTS
TESTING
CODING
PROGRAM
DESIGN
ANALYSIS
PRELIMINARY
PROGRAM
DESIGN
SOFTWARE
REQUIREMENTS
OPERATIONS
PRELIMINARY
DESIGN
ANALYSIS
PROGRAM
DESIGN
CODING
TESTING
USAGE
Idea: Sequential creation
of products on
different levels of
abstraction (e.g.,
precede code by
design, precede
design by
requirements) and
integration in
reverse direction
Strictly sequential
control flow can be
weakened by
controlled iterations
Prerequisites: Familiarity with
application
domains, methods,
techniques, tools,
engineering
processes
Good understanding
of the requirements
Stable requirements
High capabilities for
effort estimation
Page 9
9/5/2014
9
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Boehm’s Spiral Model
Project
Start
The spiral model proposed by
Boehm (1988) is an iterative
model with focus on risk
resolution:
• Determine objectives and constraints
• Evaluate alternatives
• Identify risks
• Resolve risks after assigning priorities
to risks
• Develop a series of prototypes for the
identified risks starting with the highest
risk
• Use a waterfall model for each
prototype development (“cycle”)
• If a risk has successfully been
resolved, evaluate the results of the
“cycle” and plan the next round
• If a certain risk cannot be resolved,
terminate the project immediately
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Rational Unified Process (RUP)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
RUP Iteration Process
Inception Elaboration Construction Transition
Iteration 1 Iteration 2 Iteration 3
Iteration Planning
Rqmts Capture
Analysis & Design
Implementation
Test
Prepare Release
“Mini-Waterfall” Process
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Comparison of Basic Process Types
RUP = Rational Unified Process XP = Extreme Programming
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014 MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Process Taxonomy H. Dieter Rombach, Martin Verlage,
Directions in Software Process Research,
Advances in Computers, Volume 41,
Marvin V. Zelkowitz (Ed.), Pages 1-63,
Academic Press, Boston, MA, 1995.
A Process … … defines Who does What, When
and How to reach a specific goal. In software engineering the goal is
to build a software product or to enhance an existing one
Page 10
9/5/2014
10
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Software Engineering Management
Consistent application of engineering principles and methods to the development of software (intensive) systems
Engineering: Application of systematic (i.e., predictable, repeatable, scalable) procedures - with well-defined goals (e.g., quality, functionality/scope, cost, time) - with well-defined/structured products, processes, and organization Adherence to existing body of knowledge Observation of constraints (standards, time/cost/quality requirements, etc.) Development and use of models
Planning – deciding what is to be done Organizing – making arrangements Staffing – selecting the right people for the job Directing – giving instructions Monitoring – checking on progress Controlling – taking action to remedy hold-ups Innovating – finding solutions when problems emerge Representing – liaising with clients, users, developers and other stakeholders
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Software Engineering
Software Product
A bridge from customer/user needs to software product
Customer, User
Needs
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2014
Next Lecture
• Date/Time:
• Friday, 12-Sep, 14:15-16:00
• Topic:
• Requirements Engineering – I 1st Homework!
• For you to do:
• Have a look at the course wiki
• Make sure you know to which lab group you have
been enrolled + start forming project teams
• MOST IMPORTANTLY: Go to the labs next week!