ETSF01 - Lecture 1 - ut

9/5/2015

1

MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015

MTAT.03.094

Software Engineering

Lecture 01:

Course Introduction

Dietmar Pfahl

email: [email protected] Fall 2015


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 (2014/15): A – Excellent 35 B – Very good 46 C – Good 45 D – Satisfactory 20 E – Sufficient 6 F – Insufficient 4


Student Feedback – 2013/14

137 Students


Student Feedback – 2014/15

156 Students

9/5/2015

2


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.


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: No lecture

Week 09: Refactoring

Week 10: Verification and Validation I

Week 11: Verification and Validation II

Week 12: Agile/Lean Methods

Week 13: Software Quality

Management

Week 14: no lecture

Week 15: Measurement / Course

wrap-up, review and exam

preparation

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/2015/SE/fall/Main/HomePage


Project Topic: POS System (POS: Point-of-Sale)

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

9/5/2015

3


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 “Home Improvement International (HII)” company. This company is mostly dealing with the management of home improvement stores (Note: A home improvement store is something like K-rauta, Obi, Bauhof, Home Depot, ByggMax). Currently, the company has 22 stores in Estonia, Latvia, Lithuania and Poland. Your customer has ambitions to expand to 100 stores, and enter the markets of Finland, Sweden and Norway. The company's concept is to mostly sell retail products to private customers and to supply small construction companies with materials for their small and mid-size projects. Today, your customer is using a different POS software in their stores, 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 04-07: Task 2: Formalizing, modeling, planning

• Weeks 06-09: Task 3: Development infrastructure

• Weeks 08-11: Task 4: Realization - I

• Weeks 10-13: Task 5: Realization - II

• Weeks 12-15: Task 6: Automatic testing and refactoring

• Weeks 14-16: Task 7: Verification and validation

Details can be found on the course wiki

Team


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%

Team


Week Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7

2 Assigned

3 Consult

4 Submit* Assigned

5 Assess Consult

6 Submit* Assigned

7 Assess Consult

8 Submit* Assigned

9 Assess Consult

10 Submit* Assigned

11 Assess Consult

12 Submit* Assigned

13 Assess Consult

14 Submit* Assigned

15 Assess Consult

16 Submit* /

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

• You will get a brief intro on how to use Bitbucket 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/2015/SE/fall/Main/Grading

Team


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.

Team

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

9/5/2015

4


Lab Instructors

• Kristiina Rahkema ([email protected]):

• Mondays 12:15-14:00, Liivi 2-205 (Lab Group 7)

• Tuesdays 14:15-16:00, Liivi 2-205 (Lab Group 4)

• Wednesdays 14:15-16:00, Liivi 2-205 (Lab Group 1)

• Yar Muhammad ([email protected]):

• Mondays 12:15-14:00, Liivi 2-402 (Lab Group 8)



• Sander Soo ([email protected]):


• Svetlana Omelkova ([email protected]):


Picture of Sander

Picture of Svetlana


Assessment (1)

• Labs – 70% of total grade

• Exam – 30% of total grade

• Rules: • All members in a team receive equal grades in labs

• BUT: 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 08-Jan-2015 in 405 – 14:15-16:15

• Exam 2: Friday 15-Jan-2015 in 405 – 14:15-16:15

• (Retake: Wednesday 20-Jan-2015)

If there is an important reason why you cannot attend an assessment session, you must inform your TA beforehand via email stating the reason.


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/2015/SE/fall/Main/HomePage


Lab Groups and Teams

Lab

Group

Limit of

attendants

Registered

attendants

Lab

Supervisor

Weekday

1. rühm 21 18+2 Kristiina Wednesday

2. rühm 21 15+2 Yar Wednesday

3. rühm 21 21 Svetlana Wednesday

4. rühm 18 18 Kristiina Tuesday

5. rühm 18 9+1 Yar Tuesday

6. rühm 18 18 Sander Tuesday

7. rühm 21 21 Kristiina Monday

8. rühm 21 18+2 Yar Monday

Status: 04 Sep 2015 at 09:24

9/5/2015

5


Communication Rules

Message Board !!!

Lab Lab Instructors (Kristiina, Yar, Sander, Svetlana)

Members of a team will - as much as possible - be treated equally.

Implies: 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 2015

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


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: No lecture

Week 09: Refactoring

Week 10: Verification and Validation I

Week 11: Verification and Validation II

Week 12: Agile/Lean Methods

Week 13: Software Quality

Management

Week 14: no lecture

Week 15: Measurement / Course

wrap-up, review and exam

preparation

Week 16: no lecture



What?

Why?


Software Development – Three Ps

• Software Development

Project or Iteration

P ?

P ?

P ?

9/5/2015

6





Products

People Processes


Engineering and/or Craftsmanship?


Engineering versus Craftsmanship

Organic growth?



3D Printed House




Craftsmanship versus Engineering

Student’s BSc/MSc project

Individual Developer

Code

500 – 5000 LOC

Software Industry

Large Teams Possibly geographically distributed

Large, evolving systems with 10s or 100s of millions of LOC

mostly craftsmanship

craftsmanship plus engineering

9/5/2015

7





Products

People Processes


Products in Software Development

Products Code: - Production code:

- Source code - Object code

- Non-production code: - Test code

Non-Code: - Requirements - Specifications - Architecture/Design docs - Issue reports - User manuals - Plans of all kinds - ...

Models

Types of Software: - Embedded/real-time - Information System - Web application - System software - ...

Properties of Software: - Functionality - Reliability - Usability - Efficiency - Maintainability - Portability


Software in a Car Products

ECU = Electronic Control Unit


Properties of 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.

Products


SW Product Modeling UML = Unified Modeling Language

Online information: http://www.uml.org

Products





Products

People Processes

9/5/2015

8


People in Software Development

People

Roles: - Project Manager - Product Manager - Architect/Analyst - Programmer - Tester - ...

Skills: - Must match roles Training: - Must fill skill-gaps Education: - Curricula (ACM/IEEE)

Teams: - Team building - Geographically distributed (international/global) - Mechanisms for collaboration/cooperation - Motivation, Personality, Values, Culture

User models





Products

People Processes


Software Development Process

Coding

Deploying

Processes


Software Development Process

Find Requirements

Analysis / Designing

Coding

Testing

Deploying

Processes


Processes Software Development Process

SYSTEM

REQUIREMENTS

TESTING

CODING

PROGRAM

DESIGN

ANALYSIS

PRELIMINARY

PROGRAM

DESIGN

SOFTWARE

REQUIREMENTS

OPERATIONS

PRELIMINARY

DESIGN

ANALYSIS

PROGRAM

DESIGN

CODING

TESTING

USAGE

(Royce, 1970)


Processes

Rational Unified Process (RUP)

9/5/2015

9


Processes

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

Incremental & Iterative Heavy Weight (’Rich’ Process)


Agile Process Processes


Agile Process Processes

Scrum

eXtreme Programming (XP)


Scrum Elements – Process, Artifacts, Roles

http://www.scrumforteamsystem.com/processguidance/v1/Scrum/Scrum.html

Processes


Processes


Processes

Comparison of Basic Process Types

RUP = Rational Unified Process XP = Extreme Programming

9/5/2015

10


Processes in SW Development

Processes

Process (Model) Elements: - Activity - Input/Output Product(s) - Roles - Methods/Techniques/Tools

Process Taxonomy: - Non-engineering processes

- Business processes - Social processes

- Engineering processes - Product-engineering proc.

- Technical prod.-eng. proc. - Managerial prod.-eng. proc.

- Process-engineering proc.

Process Modeling: - Descriptive PMs - Prescriptive PMs

- Standards - Families

Process Types: - Heavy-weight (rich) - Light-weight

- Lean - Agile - Kanban


Processes

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 (Model) … … 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


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 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 Product

A bridge from customer/user needs to software product

Customer, User

Needs Developer (SW Engineer)


Next Lecture

• Date/Time:

• Friday, 11-Sep, 10:15-12: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 - ut