diff --git a/README.md b/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..cd4ff0e509ec30bcb54294393b5fb3bb4a4a1091
--- /dev/null
+++ b/README.md
@@ -0,0 +1,106 @@
+# Praktikum 8
+Independence of Dev. Env.: java, maven library
+Simplicity: very simple
+minimal code size -> does program blows when many languages are in the atm.json
+Testing: test json config files for unit tests
+Maintainability of code: java version should be consistent
+Extensibility w.r.t. variants: For new variants you have to change the code
+Scalability w.r.t. variants: languages are easily scalable
+Startup Performance: no database needed for startup, fast
+Runtime Performance: nothing special
+
+
+# Praktikum 9
+## How do you deploy the fix? Do you re-deploy the whole core asset or only a patch? 
+Redeploy the whole core asset and re-deploy all products that are build from this core asset. It depends
+___
+It depends on the bugs. Minor fixes should have been deployed with patches. If the bug only affects some customer, patch would be better. Core Asset Team has to talk with the product team. Depends on the number of the customers. Trust in Product Line is loosing if multiple patches are not working anymore.
+## When will you release the fix? 
+It takes some time for calling all products back and rebuilding the projects with the fix. It depends on how the release is installed.
+___
+Depends on the pipeline. If it is automatically, than it can be done with an automatic pipeline like git. This approach is very fast. If it is not automatic, than you have to release it manually.
+## There are probably several projects using the faulty core asset. How do you know which projects use it?
+All the versions with a faulty core asset. You have to trace it down to find all versions with the bug.
+___
+
+## Are there other releases of your core asset that could be affected by the bug?
+yes, it depends
+## Since it is good practice, you develop a test to detect the bug automatically in case it should reoccur one day (i.e. as regression). Is this regression test a (part of your) core asset?
+yes, if it is occurred in the core asset, it should be present there. There shouldn't be duplicated in all products.
+## How do you deploy this test? 
+I would test the fix with a test configuration file to reproduce this issue. Tests should not be published.
+___
+In a patch you can deploy the test, that the product team can test it for the specific product. Customer does not like patches.
+
+## How do you decide whether the new variant should become part of the core asset?
+Answer to questions:
+- Do the new variant belong to the core asset
+- Is there any variation point where the variant belongs?
+___
+if only one product team (20 % of dev team) want the feature it should be implemented in product team. If 80 % of the development team wants it, you should add it to the core asset. The management has to decide it.
+## Your product people need the new feature immediately. What does this mean for your development?
+The core asset team should build the feature, so all product people can build multiple products with this feature at the same time
+## Assume that the new variant should be supported by your core asset. How do you proceed? When do you deploy it the first time?
+- Add the new variant to the variability model
+- Follow the links from the variation point to the various development artifacts and insert the new variant as usual
+- Deploy product with new core asset version
+## Assume that the new variant should not be supported by a core asset. How is it developed? 
+You can develop this feature as a differing feature. These features are exchangeable for the deriving products
+
+## What does it mean for your product team when you update the buggy core asset? What does this mean to your project schedule?
+The product team has to integrate new the version of the core asset and should be aware that the product specific features are also still working. Afterwards a new product release should be deployed.
+___
+You have the tests for core asset and product asset. Run these tests. 
+## Can you just ignore the bug fix and stay with the old version of the core asset?
+The core asset with the associated variability model should always be working because this feature is sold to the customer. I it is not sold, it is okay.
+
+## How do you get the list of questions (i.e. potential requirements) and available options out of your variability model? (Remember: The model is huge - you need an algorithm!)
+Algorithm:
+1. Find out the type of requirement artifacts your customer is interested in
+2. Collect the variation points and variants that are linked to the artifacts*1.) (You have afterwards a reduced variability model)
+3. Apply ordering to make sure that you start with the most basic variation points*2.)
+4. Create a questionnaire containing the description of variation points and variants. Enrich the text with information from the variability model (number of variants? exclude relationships?)
+5. Take the questionnaire to the customer and get the answers you need!
+___
+1.)*Artifacts could be User Story or Requirement artifacts or something else.
+2.)*Topology Sorting: Start with variation points/variants that have the most dependencies.
+## How do you sort the list (automatically) to make sure that you start with the most basic questions?
+You start with variation points that does not have any includes or excludes. These variation points are simpler
+## You can not get all answers in a single meeting. How do you have to adapt the algorithm to work iteratively with the variability model?
+You have to skip those answers at first and get answers for all other things.
+
+# Praktikum 10
+## Look at the slides of the lecture and refresh your knowledge about the "What to Build"-Pattern and the practice areas in the pattern
+The "What to Build" pattern focuses on determining what to create by aligning customer needs, technological feasibility, and market demands. Its practice areas often include:
+- Market analysis
+- Understanding relevant Domains
+- Technology forecasting
+- Building a business case
+- Scoping
+
+## Look at the practice areas in the pattern and think about the car radio product line. What skill or knowledge is available in our team? What is missing? Write down your findings for each practice area.
+Market Analysis:
+- Available skills:
+- Missing skills: The analysis with students should not be as good as needed
+Understanding relevant Domains: 
+- Available skills: Differentiate between common and different features, we know which capability goes to the core asset
+- Missing skills: legal restrictions, standards are unknown for radios
+Technology forecasting:
+- Available skills: Tool knowledge
+- Missing skills: don't know which tool to use because time frame is unknown
+Building a business case:
+- Available skills: we can decide which product belong to the product line, Justify the effort to adapt a product line
+- Missing skills: 
+Scoping:
+- Available skills: We can decide whether a planned or existing product is part of the product line or not
+
+### Is it a good idea to start such a product line? Why (not)? 
+No, because we need all answers to the missing information before. Otherwise the product line is not planned very good and strategic. A radio is not a quite good example for building a product line, because it is very simple. It is not worth it. Also most of us don't have any hardware or business knowledge.
+
+### If you think that a product line for car radios is no good idea - can you imagine any other products that could be a reasonable product line for a group of CS students? 
+We can build a CMS with multiple versions. One version is for customer who are paying for the product for using more Features (eg. AI) and we can build other community versions with less features, but all versions should be stable.
+
+### Imagine you have a successful product line running. What does this mean to flexibility? Your willingness to change your processes or technologies? What should you do about this? 
+- A successful product line often locks a team into specific processes, technologies, and market expectations.
+- Introducing changes can risk disrupting the established workflow and product consistency.
+- We don't do harmful changes that are disrupting the whole product line that we have to rebuild it
\ No newline at end of file