ETSF01 - Lecture 1 - ut
Transcript of 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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Structure of Lecture 01
• General Course Information/Overview
• Introduction into Software Engineering
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Student Feedback – 2013/14
137 Students
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Student Feedback – 2014/15
156 Students
9/5/2015
2
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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 2015
Course Wiki: https://courses.cs.ut.ee/2015/SE/fall/Main/HomePage
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Project Topic: POS System (POS: Point-of-Sale)
9/5/2015
3
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
9/5/2015
4
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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)
• Tuesdays 14:15-16:00, Liivi 2-402 (Lab Group 5)
• Wednesdays 14:15-16:00, Liivi 2-402 (Lab Group 2)
• Sander Soo ([email protected]):
• Tuesdays 14:15-16:00, Liivi 2-203 (Lab Group 6)
• Svetlana Omelkova ([email protected]):
• Wednesdays 14:15-16:00, Liivi 2-004 (Lab Group 3)
Picture of Sander
Picture of Svetlana
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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.
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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 2015
GO TO LABS !!!!
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
FORM PROJECT TEAMS!
Student lists:
https://courses.cs.ut.ee/2015/SE/fall/Main/HomePage
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Software Engineering
What?
Why?
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Software Development – Three Ps
• Software Development
Project or Iteration
P ?
P ?
P ?
9/5/2015
6
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Software Development – Three Ps
• Software Development
Project or Iteration
Products
People Processes
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Engineering and/or Craftsmanship?
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Engineering versus Craftsmanship
Organic growth?
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Engineering versus Craftsmanship
3D Printed House
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Engineering versus Craftsmanship
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Software Development – Three Ps
• Software Development
Project or Iteration
Products
People Processes
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Software in a Car Products
ECU = Electronic Control Unit
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
SW Product Modeling UML = Unified Modeling Language
Online information: http://www.uml.org
Products
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Software Development – Three Ps
• Software Development
Project or Iteration
Products
People Processes
9/5/2015
8
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Software Development – Three Ps
• Software Development
Project or Iteration
Products
People Processes
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Software Development Process
Coding
Deploying
Processes
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Software Development Process
Find Requirements
Analysis / Designing
Coding
Testing
Deploying
Processes
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Processes
Rational Unified Process (RUP)
9/5/2015
9
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Agile Process Processes
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Agile Process Processes
Scrum
eXtreme Programming (XP)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Scrum Elements – Process, Artifacts, Roles
http://www.scrumforteamsystem.com/processguidance/v1/Scrum/Scrum.html
Processes
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Processes
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
Processes
Comparison of Basic Process Types
RUP = Rational Unified Process XP = Extreme Programming
9/5/2015
10
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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 2015
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 2015
Software Engineering
Software Product
A bridge from customer/user needs to software product
Customer, User
Needs Developer (SW Engineer)
MTAT.03.094 / Lecture 01 / © Dietmar Pfahl 2015
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!