ETSF01 - Lecture 1...• Compulsory: MTAT.03.130 Object-oriented Programming (6 ECTS, 4 CP) Related courses: • Systems Modelling (MTAT.03.083) • Software Project (MTAT.03.138)

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


Structure of Lecture 01

• General Course Information/Overview

• Introduction into Software Engineering


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


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


Student Feedback – 2013/14


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.

9/5/2014

2


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.


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


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)


Course Wiki: https://courses.cs.ut.ee/2014/SE/fall/Main/HomePage


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.


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

https://courses.cs.ut.ee/2014/SE/fall/Main/HomePage

9/5/2014

3


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%


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


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


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.


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]):



• Kauri Kägo ([email protected]):

• Thursdays 12:15-14:00, Liivi 2-004 (Lab Group 6)


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?

https://courses.cs.ut.ee/2014/SE/fall/Main/Grading

9/5/2014

4


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


GO TO LABS !!!!


FORM PROJECT TEAMS!

Student lists:

https://courses.cs.ut.ee/2014/SE/fall/Main/HomePage


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


ASK QUESTIONS

(I will try my best to give satisfactory answers)


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

9/5/2014

5


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


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?


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


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.


Engineering versus Craftsmanship


Engineering versus Craftsmanship

Organic growth?

9/5/2014

6


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)


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


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?


Magic Triangle of SE


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


Embedded Software in a Car (1)

9/5/2014

7


Embedded Software in a Car (2)


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.


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.


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.


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.


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

9/5/2014

8


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.


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.


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.


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


Waterfall Method (naïve)

Deployment &

Maintenance

Requirements

Design

Implementation

TestingWaterfall

method

Unidirectional, no way back finish this step before moving to the next


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

9/5/2014

9


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


Rational Unified Process (RUP)


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


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

9/5/2014

10


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


Software Engineering

Software Product

A bridge from customer/user needs to software product

Customer, User

Needs


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!

Documents

ETSF01 - Lecture 1...• Compulsory: MTAT.03.130 Object-oriented Programming (6 ECTS, 4 CP) Related courses: • Systems Modelling (MTAT.03.083) • Software Project (MTAT.03.138)