MTAT Software Engineering

Transcription

1 MTAT Software Engineering Lecture 01: Course Introduction Dietmar Pfahl Fall

2 Structure of Lecture 01 General Course Information/Overview Introduction into Software Engineering

3 Course Information/Overview Level: Bachelor s level (in English) Credits: 6 ECTS, 4 CP Pre-requisite: MTAT 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

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

5 Student Feedback 2013/ Students

6 Student Feedback 2014/ Students

7 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 Object-oriented Programming (6 ECTS, 4 CP) Related courses: Systems Modelling (MTAT ) Software Project (MTAT ) Information Systems (MTAT ) Software Economics (MTAT ) That implies that we (I and the lab supervisors) take it for granted that you know the principles of objectoriented programming and how to program java code.

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

9 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

10 Recommended Literature (Readings) Ian Sommerville: Software Engineering, 9th edition, 2010 ( Ivan Marsic: Software Engineering, 2012 ( SE_marsic.pdf) Chapters 1-6 (selective) (more literature is listed on the course wiki)

11 Course Wiki:

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

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

14 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

15 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

16 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 before midnight of the day before Lab Submit* / Assess Project Schedule

17 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: Team

18 Project Rules (2) Each team must complete all tasks independently. Team 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.

19 Lab Instructors Kristiina Rahkema Mondays 12:15-14:00, Liivi (Lab Group 7) Tuesdays 14:15-16:00, Liivi (Lab Group 4) Wednesdays 14:15-16:00, Liivi (Lab Group 1) Yar Muhammad Mondays 12:15-14:00, Liivi (Lab Group 8) Tuesdays 14:15-16:00, Liivi (Lab Group 5) Wednesdays 14:15-16:00, Liivi (Lab Group 2) Sander Soo Tuesdays 14:15-16:00, Liivi (Lab Group 6) Svetlana Omelkova Wednesdays 14:15-16:00, Liivi (Lab Group 3) Picture of Sander Picture of Svetlana

20 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 :15-16:15 Exam 2: Friday 15-Jan-2015 in :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 stating the reason.

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

22 GO TO LABS!!!!

23 FORM PROJECT TEAMS! Student lists:

24 Lab Groups and Teams Lab Group Limit of attendants Registered attendants Lab Supervisor Weekday 1. rühm Kristiina Wednesday 2. rühm Yar Wednesday 3. rühm Svetlana Wednesday 4. rühm Kristiina Tuesday 5. rühm Yar Tuesday 6. rühm Sander Tuesday 7. rühm Kristiina Monday 8. rühm Yar Monday Status: 04 Sep 2015 at 09:24

25 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

26 ASK QUESTIONS (I will try my best to give satisfactory answers)

27 Structure of Lecture 01 General Course Information/Overview Introduction into Software Engineering Acknowledgement: - Ian Sommerville: Software Engineering, 9th edition, Ivan Marsic: Software Engineering, 2012

28 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

29 Software Engineering What? Why?

30 Software Development Three Ps Software Development P? Project or Iteration P? P?

31 Software Development Three Ps Software Development Products People Project or Iteration Processes

32 Engineering and/or Craftsmanship?

33 Engineering versus Craftsmanship Organic growth?

34 Engineering versus Craftsmanship 3D Printed House

35 Engineering versus Craftsmanship

36 Craftsmanship versus Engineering mostly craftsmanship craftsmanship plus engineering Individual Developer Large Teams Possibly geographically distributed Code LOC Student s BSc/MSc project Large, evolving systems with 10s or 100s of millions of LOC Software Industry

37 Software Development Three Ps Software Development Products People Project or Iteration Processes

38 Products in Software Development Code: - Production code: - Source code - Object code - Non-production code: - Test code Products Properties of Software: - Functionality - Reliability - Usability - Efficiency - Maintainability - Portability 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 -...

39 Software in a Car Products ECU = Electronic Control Unit

40 Properties of Software Products 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.

41 SW Product Modeling Products UML = Unified Modeling Language Online information:

42 Software Development Three Ps Software Development Products People Project or Iteration Processes

43 People in Software Development Roles: - Project Manager - Product Manager - Architect/Analyst - Programmer - Tester -... Teams: - Team building - Geographically distributed (international/global) - Mechanisms for collaboration/cooperation - Motivation, Personality, Values, Culture People Skills: - Must match roles Training: - Must fill skill-gaps Education: - Curricula (ACM/IEEE) User models

44 Software Development Three Ps Software Development Products People Project or Iteration Processes

45 Software Development Process Processes Coding Deploying

46 Software Development Process Processes Find Requirements Analysis / Designing Coding Testing Deploying

47 Software Development Process Processes SYSTEM REQUIREMENTS SOFTWARE REQUIREMENTS PRELIMINARY PROGRAM DESIGN ANALYSIS PROGRAM DESIGN PRELIMINARY DESIGN ANALYSIS CODING PROGRAM DESIGN TESTING CODING TESTING OPERATIONS USAGE (Royce, 1970)

48 Rational Unified Process (RUP) Processes

49 RUP Iteration Process Processes Inception Elaboration Construction Transition Incremental & Iterative Heavy Weight ( Rich Process) Iteration 1 Iteration 2 Iteration 3 Mini-Waterfall Process Iteration Planning Rqmts Capture Analysis & Design Implementation Test Prepare Release

50 Agile Process Processes

51 Agile Process Processes Scrum extreme Programming (XP)

52 Scrum Elements Process, Artifacts, Roles Processes

53 Processes

54 Comparison of Basic Process Types Processes RUP = Rational Unified Process XP = Extreme Programming

55 Processes in SW Development Process (Model) Elements: - Activity - Input/Output Product(s) - Roles - Methods/Techniques/Tools Process Modeling: - Descriptive PMs - Prescriptive PMs - Standards - Families Process Types: - Heavy-weight (rich) - Light-weight - Lean - Agile - Kanban 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. Processes

56 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, Processes 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

57 Software Engineering Management Consistent application of engineering principles and methods to the development of software (intensive) systems 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 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

58 Software Engineering Management Consistent application of engineering principles and methods to the development of software (intensive) systems 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 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

59 Software Engineering A bridge from customer/user needs to software product Software Product Customer, User Needs Developer (SW Engineer)

60 Next Lecture Date/Time: Topic: Friday, 11-Sep, 10:15-12:00 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!