代做program、代写Python/Java语言编程

日期：2025-01-23 08:41

Technische Universität München Winter Term 2024/25

December 2024

Introduction to Informatics for Students of

Management & Technology – Programming Lab

Course

1 Modiffed Scrum Process

During the block part, the planning, creation and implementation of the reservation application is

performed with the Scrum process. Because of time limitations, the grading process and a different

setting, a modiffed version of the Scrum process is used.

This includes a different distribution of the roles within the Scrum team as shown in the next

ffgure. The normal assignment of roles is shown on the left whilst the modiffed version can be seen

on the right.

Normal Scrum Modiffed Scrum

This means, every group member is part of the development team and additionally each team

member gets assigned a speciffc role during the implementation process. These roles are set during

Scrum meeting 2 and contain the following:

• Layout and controller developer (2-3 students)

• REST server developer (2 students)

• REST client developer (2 students)

• Interface manager (1 student)

The interface manager is a new role this semester. This person will deffne the REST server

endpoints and functions in the REST client that call these endpoints. They make sure that the

parameter names are consistent throughout the layout controllers, REST client and REST server.

Because of limited time, only ffve Scrum meetings will be performed and each meeting combines

two types of Scrum meetings from the normal Scrum process. Normally, there are ffve types of

Scrum meetings (see Lecture on Scrum). During the lab course these meetings are summarized to

only three meeting types overall, like shown in the table:

1Scrum meeting Date Purpose

0 19.12.2024

• Kick-off meeting

• Planning meeting

1 07.01.2025

• Review meeting

• Planning meeting

2 14.01.2025

• Review meeting

• Planning meeting

3 23.01.2025

• Review meeting

• Planning meeting

4 30.01.2025

• Review meeting

• Retrospective meeting

Table 1: Summary of the Scrum meetings.

Furthermore, because of feasibility reasons the daily Scrum meeting is executed only by the development

team, i.e. you and your group, without the Scrum master. This means, each day before

you start implementing, each team member tells the group what they did during the last day and

what they will do during this day.

As you know from the lecture, the sprints normally have a length of two to four weeks. Because

of the grading process and a different setting, in the lab course the sprints have a greater variety

regarding the length. This means, sprint 0 lasts for almost two weeks whereas sprint 1 ranges only

a few days.

2 Tasks per Sprint and Scrum Meeting

Before 19.12.2024

• Watch all lectures (videos) and understand their content

• Have a look at all lecture exercises and check your solution with the sample solution

• Set up all parts of the development environment and upload proof of it (Exercise 5)

• With your group, think of several ideas for a reservation application that you want to implement

(similar to the Cinema Case)

Scrum Meeting 0: 19.12.2024

• Discuss your ideas for the reservation system with your Scrum master/tutor

• Discuss the structure with your Scrum master:

– Which classes/objects does your application have?

– How do the classes interact with each other and what is their relationship?

– What is their counterpart in the CinemaCase?

• Distribute and assign tasks. You’re going to go through several software engineering activities

during the next sprint:

– Requirement analysis:

∗ Have a look at the Requirements Analysis Document from the CinemaCase

and discuss its parts

– System design:

∗ Since most of the system design questions are already answered because you’re using

the Cinema Case project as a template for your system, you don’t have to produce

anything for this activity.

– Object design:

∗ Sketch an ER diagram which depicts the database of your project

∗ Create a application domain class diagram.

2Sprint 1 (19.12.2024-07.01.2025): Requirement analysis

• For your group’s reservation system, create the following:

– Scenarios: Describe an instance of every use case. A scenario should represent a

concrete sequence of interactions between one or more actors and the system. Include

the short scenario texts in the Requirements Analysis Document.

– Use case diagrams: Formalize all the possible actions a user has. Include the diagrams

in the Requirements Analysis Document.

– Class diagram: You already discussed the application domain class diagram in the

scrum meeting. Formalize the discussed classes and their interactions in the solution

domain. Include the diagram in the Requirements Analysis Document.

– Communication diagrams: Think of two types of communication within your reservation

system in the application domain. For brevity it is sufffcient to only include the

interacting classes. Include the diagrams in the Requirements Analysis Document.

– ER diagram: Formalize the needed database tables and relationships (including primary

and foreign keys) in the solution domain. Store the diagram in the ER Diagram

Document.

– For creating the use case, class and communication diagrams use

https://apollon.ase.in.tum.de/

– For creating the ER diagram you can use https://erdplus.com/standalone

– Refer to the lecture slides for looking up the structure of the diagrams

– Save and push all diagram documents in the folder Documentation in your group repository

•

Write the Requirements Analysis Document:

– Use the Requirements_Analysis_Document_Reservation_System.docx in the folder

Documentation of your group repository as a starting point

– Fill in the corresponding content for each section

– Specify the generic functional requirements

– Reference to Requirements_Analysis_Document_Cinema_Case.pdf for an example Requirements

Analysis Document of the Cinema Case

– For completing the Requirements Analysis Document you will need to create:

∗ A set of scenarios in the form of short texts

∗ Use case diagrams for all the use cases of your project

∗ A class diagram from the solution domain, where you will show all the classes

of your project and their interactions

∗ Communication diagrams that show all the types of communication between

the objects of your system

– Copy and paste the sections or parts of sections from the Requirements Analysis Document

of the Cinema Case which are the same for your application into your own

Requirements Analysis Document (if needed, adapt the text according to your application)

–

Save and push the ffnished Requirements Analysis Document in the folder Documentation

of your group repository

• On the end of the sprint, each team member evaluates the quantity and quality of performed

work of every team member (including oneself) with a small table e.g.:

3Team member Quantity in % Quality

Name 1 20% 1

Name 2 10% 2

Name 3 30% 2

Name 4 15% 1

Name 5 15% 2

Name 6 10% 3

100%

Table 2: Team member evaluation table.

• Each team member needs to upload the completed evaluation table to the lab course moodle

page before the next scrum meeting. Use the provided sprintN_eval_name_groupM.xlsx

as template. It is uploaded on Moodle as Group Evaluation Template ffle. Please include

your name, your group number, and the sprint id in the title of the ffle you’re sending (an

example name of the ffle: sprint0_eval_Miriam_Anschuetz_group3.xslx).

Scrum Meeting 1: 07.01.2025

• Each team member presents equal amount of progress from sprint 1

• Evaluate possible problems and solutions from sprint 1 with the tutor

• Solve possibly still existing ambiguities with project structure

• Split up creation of SQL statements among all team members

Sprint 2 (07.01.2025-14.01.2025): Database

• Each team member creates their part of the SQL commands for the database

• Provide SQL statements for creation of tables and exemplary data in /SQLScripts/setupDatabaseAndTables.sql

Note:

The database is the heart of your system. A well-designed layout and consistent

naming of tables and columns will simplify the implementation later.

• Each team member evaluates all group members (including themselves) according to quantity

and quality of work as shown in Table 2 and uploads their evaluation to Moodle

Scrum Meeting 2: 14.01.2025

• Each team member presents equal amount of progress from sprint 2

• Evaluate possible problems and solutions from sprint 2 with the tutor

• Solve possibly still existing ambiguities with project structure

• Discuss and divide implementation tasks for reservation system:

– Solve/discuss existing problems with understanding of implementation structure

– Assign a role to every team member: layout and controller developer(2-3), REST server

developer(2), REST client developer(2), interface manager (1)

• Think of speciffc test cases:

– Which methods do you want to test?

– Assign equal amount of test methods for implementation to each team member

4Sprint 3 (14.01.2025– 23.01.2025): Base requirements

• This sprint focuses on the base requirements

• Implement your reservation application in the project from your group Git repository using

the folder src

• Follow the TODOs in the relevant classes (as shown in lecture 7)

• Make sure you comment your code

• Use the provided package structure and extend it for your system

• Test your system in the folder test using JUnit. Every team member should write at least

2 tests, i.e., test cases that were not present in the CinemaCase. Code that is provided from

the template does not need to be tested.

• Each team member evaluates all group members (including themselves) according to quantity

and quality of work as shown in Table 2 and uploads their evaluation to Moodle

• Refer to the Cinema Case for looking up implementation concepts

• Upon problems post your questions to the Moodle forum or ask your tutor

Scrum Meeting 3: 23.01.2025

• Each team member presents equal amount of progress from sprint 3

• Evaluate possible problems and solutions from sprint 3 with the tutor

• Assign who implements which extra requirements

Sprint 4 (23.01.2025– 30.01.2025): Extra requirements

• This sprint focuses on the extra requirements

• Implement your reservation application in the project from your group Git repository using

the folder src

• Extend the project for implementing the extra requirements

• A detailed description of the extra requirements is uploaded on Moodle

• Make sure you comment your code

• Use the provided package structure and extend it for your system

• Test your system in the folder test using JUnit. Every team member should write at least

4 additional tests. Code that is provided from the template does not need to be tested.

• Each team member evaluates all group members (including themselves) according to quantity

and quality of work as shown in Table 2 and uploads their evaluation to Moodle

• Refer to the Cinema Case for looking up implementation concepts. The extra requirements

themselves are not implemented for the Cinema Case.

• Upon problems post your questions to the Moodle forum or ask your tutor

Scrum meeting 4: 30.01.2025

• Present the progress

• Discuss programming problems

5Sprint 5: 30.01.2025– 06.02.2025

• Finalize your work:

– Fix remaining bugs and issues

– Add missing functionality

– Comment your code

– Make sure that you have enough test cases and that they don’t produce errors

– (Optional) Improve the layout and make it more appealing

• Prepare the final presentation:

– The presentation should be 10-15 minutes.

– You should have presentation slides (e.g. Powerpoint, Keynote, ..)

– Distribute the talking time evenly among your group members

– The tutors and instructors will act as customers. Try to sell your product to them (you

can expect technical background knowledge, so highlight interesting functionality)

– Include a showcase of your tool to prove that it is running smoothly. You may record

the showcase upfront to avoid unforeseen problems during the presentation

– Show that you have good understanding of the code and structure of your project. Do

not show explicit code fragments but pseudo code and diagrams (e.g. flowcharts) may

be a good idea

• Each team member evaluates all group members (including themselves) according to quantity

and quality of work as shown in Table 2 and uploads their evaluation to Moodle

Final presentation: 06.02.2025

• Every team member presents the part of the implementation they have done

• All teams listen to the other groups’ presentations

6