Summary

• Page properties (2 modified, 0 added, 0 removed)
• Objects (1 modified, 0 added, 0 removed)
  • Confluence.Code.ConfluencePageClass[0]

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.uru
	1	+XWiki.cds

Content

...	...	@@ -23,18 +23,6 @@
23	23
24	24	Usually, your thesis is a full-time job, also meaning **full-time presence at your desk**. In case you also have other regular work to do, discuss this with your adviser at the beginning of your thesis work.
25	25
26		-= Thesis Proposal =
27		-
28		-The first thing to do after you familiarized yourself with the topic and problem of your thesis is to write a short proposal (~~2-4 pages). The proposal should be prepared as early as possible (within the first or second week) and should show your adviser that you understood the problem and have a rough idea how to solve it. It may be structured as follows.
29		-
30		-* Problem description
31		-* Planned Solutions/Goals
32		-** Hard requirements that have to be fulfilled by the end of your thesis
33		-** Soft requirements that can be solved if time permits
34		-* Schedule outlining your proceeding (this includes writing the thesis, see next section)
35		-
36		-After you finished the proposal, you should give a short (informal) talk during our daily tea meeting presenting your topic to all members of our group.
37		-
38	38	= Timing is (Almost) Everything =
39	39
40	40	Chances are your adviser has already supervised one or more theses. Take advantage of his or her experience! Send him drafts of the chapters of your thesis before submitting the final thesis. Of course, the drafts should be as good as possible from your point of view. Your adviser can only improve your drafts so much. If your draft is of low quality, (s)he can help you push it to an okay-ish level; but if the draft is already of high-quality to start with, (s)he can help you elevate it to pure awesomeness. Note that your drafts need not be complete yet: you can always hand in missing bits and pieces later on. Here's a schedule that has proven to work well regarding when to hand in what.
...	...	@@ -84,17 +84,17 @@
84	84
85	85	= Implementations =
86	86
87		-The first rule of your implementation is: **"No Crashes!"** The second rule of your implementation is: **"No crashes!"** Regardless of what your code does and regardless of what the user does, your implementation should neither crash nor freeze. Whenever you make assumptions, be sure to explicitly check them. If they are not met, your code should generate (useful!) error messages instead of crashing and the user should be able to continue working with it.
	75	+Erste Regel: **"No Crashes!"** Egal was Ihr System tut und welche Nutzereingaben geschehen, die Implementierung sollte nicht abstürzen oder einfrieren. Wo Annahmen gemacht werden, sollten diese explizit überprüft werden. Im Falle der Nichteinhaltung sollte eine brauchbare Fehlermeldung generiert werden, und der Anwender sollte weiter mit der Implementierung arbeiten können.
88	88
89		-Since you're working in an academic context, you will have less resources (less time, in particular) available than in a commercial setting. Also, your work probably won't have to compete with commercial applications. It follows that everything you develop will be less comprehensive and will have less features than a commercial product. What doesn't follow is that your implementation should be less meticulous or less documented than in a professional setting. Quite the contrary, in fact: commercially developed code often suffers from tight deadlines, the need to add new features, and at times a certain ignorance. You implementation, on the other hand, is supposed to be your masterpiece. It should reflect what you're currently capable of. Even though your software won't cause considerable economical damage or kill people, it probably won't exist in isolation. It will much rather be part of the KIELER project, which other people are supposed to use or develop further. The quality (and grade) of your thesis will be judged in part based on your implementation. Since this is the case, make use of the fact that your adviser probably has much more experience writing code than you do. Ask him or her to review your code and to give you feedback on how to improve.
	77	+Generell: Ihre Arbeit wird sehr wahrscheinlich auch einen praktischen Teil enthalten, in welcher Sie Software oder Hardware entwickeln oder erweitern sollen. Das akademische Umfeld Ihrer Arbeit bedeutet in der Regel, dass für diese Entwicklung weniger Ressourcen - insbesondere zeitliche Ressourcen - als in einem kommerziellen Umfeld zur Verfügung stehen, und dass sich Ihre Arbeit nicht am Markt behaupten muss. Die Konsequenz daraus ist, dass Ihre Arbeit in der Regel weniger umfangreich sein sollte und weniger Features bieten sollte als ein kommerzielles Produkt. Die Konsequenz ist nicht, dass Sie ihre Implementierung weniger sorgfältig vornehmen sollen, oder schlechter dokumentieren sollen, als dies in einem professionellem Umfeld der Fall wäre. Im Gegenteil - während bei kommerziellen Produkten der Termindruck, die Notwendigkeit zu ständigen Neuentwicklungen, und zum Teil eine gewisse Ignoranz auf Kunden- und/oder Entwicklerseite den Qualitätsstandard senken können, sollte die von Ihnen hier erstellte Implementierung Ihr „Meisterstück“ sein, welches zeigt, wozu Sie (im positiven Sinne) fähig sind. Es gilt hier zwar, dass Produktfehler keinen erheblichen wirtschaftlichen Schaden verursachen können oder gar Menschenleben gefährden können; jedoch ist auch hier Ihre Arbeit in der Regel nicht isoliert und „nur“ Teil Ihrer Ausarbeitung, sondern etwas, was andere anwenden und weiterentwickeln sollen. Die Qualität (und Benotung) Ihrer Arbeit wird (unter anderem) an der Qualität Ihrer Entwicklung gemessen.
90	90
91		-Let's look at an example. Suppose your thesis is a proof of concept. This means that you should constrain the goals of your thesis (**in accordance with your adviser**) to a well-defined subset of the problem you're tackling. The end user should be well aware of what your implementation can do and what it cannot do. A reasonable constraint could for instance be: "The transformation only works for //pure signals//, not for //valued signals//. Hierarchy-crossing transitions cannot be drawn." An unreasonable constraint could be: "Sometimes, adding a state works; other times, the software crashes." If you notice while working on your implementation that you won't be able to make certain goals, talk to your adviser. Together, you will constrain the problem further. This will allow you to solve the more constrained problem properly instead of not solving the more general problem at all. You colleagues or successors will be glad to be able to start from a smaller, but well-developed code base and add features to it instead of having to try to get your code to a reasonable quality standard — or throwing it away and starting over.
	79	+Zur Verdeutlichung: wenn Ihre Arbeit eine Machbarkeitsstudie (//proof of concept//) sein soll, bedeutet dies, dass Sie Ihre Arbeit **in Absprache mit dem Betreuer** auf eine wohldefinierte Teilmenge des Gesamtproblems einschränken sollen. Es sollte für den Anwender klar erkennbar und vorhersagbar sein, was Ihre Implementierung leistet und was nicht. Sinnvolle Einschränkungen können zum Beispiel sein: „die Transformation betrachtet nur //pure signals//, keine //valued signals// ... Es können keine hierarchieübergreifenden Transitionen gezeichnet werden“. Keine sinnvolle Einschränkung ist: „Mal funktioniert das Einfügen eines Zustands - mal stürzt das System ab“. Wenn im Laufe Ihrer Implementierungsarbeit ersichtlich wird, dass bestimmte Implementierungsziele nicht erreicht werden können (aufgrund falscher Einschätzung des Problems, oder aufgrund schlechter Ressourcenplanung), sollte sofort mit dem Betreuer abgesprochen werden, wie das Problem sinnvollerweise eingeschränkt werden könnte; es sollte nicht zu einer schlampigen Entwicklung führen. Schließlich gilt: es ist für etwaige Teamkollegen/Nachfolger von Ihnen eine wesentlich dankbarere Aufgabe, auf Ihrer kleinen, sauber entwickelten Arbeit aufzusetzen und diese um neue Features zu erweitern, als zu versuchen, Ihre große, defekte Arbeit auf einen brauchbaren Qualitätsstandard anzuheben - oder diese ganz wegzuschmeißen und von vorne anzufangen.
92	92
93		-The bottom line: write clean and proper code that adheres to our coding guidelines and document it. The quality and the readability of your code and of your documentation will influence your grade.
	81	+Grundsätzlich gilt: Die Software ist „sauber“ zu schreiben und zu dokumentieren, unter Beachtung eines evtl. vorhandenen Projekthandbuchs. Die Qualität und Leserlichkeit Ihrer Software sowie der Dokumentation geht in die Bewertung Ihrer Arbeit mit ein.
94	94
95	95	== Reviews and Ratings[[url:http://trac.rtsys.informatik.uni-kiel.de/trac/rtsys/wiki/Hinweise_Arbeiten#ReviewsundRatings||style="text-decoration: none;" title="Link to this section" shape="rect" class="anchor"]] ==
96	96
97		-To make sure that code is of a certain quality, it must be run through design and code reviews. The way this works is explained [[on this page>>doc:KIELER.Review Process]]. The reviews are not only intended to improve the quality of your code, but also to give feedback to you as a programmer to help you improve.
	85	+More often than not, you will write code as part of your thesis. To make sure that code is of a certain quality, it must be run through design and code reviews. The way this works is explained [[on this page>>doc:KIELER.Review Process]]. The reviews are not only intended to improve the quality of your code, but also to give feedback to you as a programmer to help you improve.
98	98
99	99	= What Grade Do I Get For All This? =
100	100

Confluence.Code.ConfluencePageClass[0]

Id

...	...	@@ -1,1 +1,1 @@
1		-10751501
	1	+9471804

URL

...	...	@@ -1,1 +1,1 @@
1		-https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTSYS/pages/10751501/Writing and Grading Theses
	1	+https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTSYS/pages/9471804/Writing and Grading Theses