Typische Fehler beim Schreiben der Bachelorarbeit

Der zentrale Denkfehler lautet: „Wenn meine Software funktioniert und ich ihre Entwicklung beschreibe, habe ich eine wissenschaftliche Arbeit geschrieben.“ Entscheidend ist jedoch die Begründungskette: vom Problem über die Forschungsfrage und das methodische Vorgehen bis zur belegten Antwort.

Problemstellung und Forschungsfragen

Typischer Fehler	Beispiel oder Erkennungsmerkmal	Besseres Vorgehen
Ein Thema mit einer Forschungsfrage verwechseln	„Meine Forschungsfrage ist: Künstliche Intelligenz in der Softwareentwicklung.“	Aus dem Themengebiet eine konkrete, beantwortbare Frage ableiten: Was wird an welchem Gegenstand unter welchen Bedingungen untersucht?
Eine Entwicklungsaufgabe als ausreichendes Erkenntnisziel betrachten	„Ziel der Arbeit ist die Entwicklung einer App.“	Zusätzlich klären, welche Erkenntnis die Entwicklung und Untersuchung liefern soll – beispielsweise zur Eignung eines Lösungsansatzes unter bestimmten Anforderungen.
Die Frage zu breit formulieren	„Wie verbessert KI die Softwareentwicklung?“	Aufgabe, Zielgruppe, Verfahren, Kontext und untersuchte Qualitätsmerkmale eingrenzen.
Das gewünschte Ergebnis vorwegnehmen	„Warum ist mein Verfahren besser als bestehende Ansätze?“	Ergebnisoffen fragen: „Wie unterscheiden sich die Verfahren hinsichtlich …?“
Unklare Bewertungsbegriffe verwenden	„Die Lösung soll effizient, intuitiv und skalierbar sein.“	Erläutern, was diese Begriffe im konkreten Kontext bedeuten und wie sie untersucht werden.
Forschungsfrage und Untersuchung auseinanderlaufen lassen	Die Frage betrifft Benutzerfreundlichkeit; untersucht wird ausschließlich die Antwortzeit.	Für jede Forschungsfrage festlegen, welche Untersuchung eine Antwort liefern kann.

Beispiel

Ungünstig:

„Wie kann man eine bessere Suchmaschine entwickeln?“

Konkreter:

„Wie unterscheiden sich eine semantische Suche und eine Volltextsuche hinsichtlich der Relevanz der ersten zehn Treffer bei natürlichsprachlichen Suchanfragen zu deutschsprachigen Modulbeschreibungen?“

Die zweite Formulierung benennt Vergleichsgegenstände, Anwendungskontext und untersuchte Eigenschaft. Wie „Relevanz“ bestimmt wird, muss anschließend noch methodisch festgelegt werden.

Literaturarbeit und fachliche Einordnung

Typischer Fehler	Beispiel oder Erkennungsmerkmal	Besseres Vorgehen
Erst implementieren und anschließend passende Literatur suchen	Quellen werden nachträglich gesammelt, um bereits getroffene Entscheidungen zu bestätigen.	Vor wesentlichen Entscheidungen bestehende Ansätze recherchieren und die Recherche im Verlauf gezielt ergänzen.
Quellen lediglich aneinanderreihen	„Autor A macht X. Autor B macht Y. Autor C macht Z.“	Ansätze anhand gemeinsamer Kriterien vergleichen und daraus Konsequenzen für die eigene Arbeit ableiten.
Behauptungen ohne geeignete Belege übernehmen	„Microservices sind grundsätzlich skalierbarer.“	Aussage eingrenzen und prüfen, welche Quelle sie unter welchen Bedingungen tatsächlich trägt.
Quellen verwenden, ohne ihre Eignung zu prüfen	Eine Produktwerbung dient als alleiniger Beleg für die Überlegenheit eines Verfahrens.	Zwischen Herstellerangaben, technischer Dokumentation und unabhängigen Untersuchungen unterscheiden.
Zitieren mit Verstehen verwechseln	Ein Verfahren wird korrekt zitiert, aber seine Annahmen und Grenzen bleiben unklar.	Erklären können, wie der Ansatz funktioniert und weshalb er zur eigenen Fragestellung passt.
Neuheit nur behaupten	„Dazu gibt es bisher keine Lösung“, ohne nachvollziehbare Recherche.	Beschreiben, welche Ansätze gefunden wurden und worin sich der eigene Beitrag unterscheidet. Nichtauffinden ist kein Beweis für Nichtexistenz.

Anforderungen und Lösungsentwurf

Typischer Fehler	Beispiel oder Erkennungsmerkmal	Besseres Vorgehen
Anforderungen frei erfinden	Die Anforderungsliste bildet ausschließlich die Vorstellungen der entwickelnden Person ab.	Anforderungen aus benannten Quellen ableiten, etwa Interviews, vorhandenen Prozessen, Dokumenten oder Rahmenbedingungen.
Anforderungen und technische Lösungen vermischen	„Das System muss eine bestimmte Datenbank verwenden“, obwohl eigentlich kurze Antwortzeiten benötigt werden.	Bedarf, verbindliche Randbedingung und Entwurfsentscheidung unterscheiden. Eine vorgeschriebene Technologie als Randbedingung kennzeichnen.
Nicht prüfbare Anforderungen formulieren	„Die Anwendung muss benutzerfreundlich sein.“	Das Qualitätsziel durch konkrete Nutzungsszenarien und nachvollziehbare Bewertungskriterien präzisieren.
Anforderungen nicht validieren	Die selbst formulierte Liste wird ohne Rücksprache als richtig behandelt.	Anforderungen mit geeigneten Beteiligten oder anhand begründeter fachlicher Kriterien prüfen; offene Punkte dokumentieren.
Technologien nach persönlicher Vorliebe auswählen	„Ich verwende Framework X, weil ich es bereits kenne.“	Auswahlkriterien und Alternativen erläutern. Vorkenntnisse dürfen ein praktischer Faktor sein, ersetzen aber keine fachliche Eignungsprüfung.
Nachträgliche Entscheidungen als ursprünglichen Plan darstellen	Eine erst während der Umsetzung entstandene Einschränkung erscheint später als angeblich ursprüngliche Anforderung.	Änderungen, Gründe und Auswirkungen offen dokumentieren.

Eine besonders wichtige Unterscheidung Diese drei Aussagen beantworten unterschiedliche Fragen:

• „Die Beteiligten benötigen diese Funktion.“ → Bedarf.
• „Wir realisieren sie mit dieser Architektur.“ → Lösungsentscheidung.
• „Der implementierte Ablauf erfüllt das vereinbarte Kriterium.“ → Prüfergebnis.

Wer diese Ebenen vermischt, erschwert sowohl die Begründung der Lösung als auch ihre spätere Bewertung.

Methodik und Durchführung

Typischer Fehler	Beispiel oder Erkennungsmerkmal	Besseres Vorgehen
Die Methode nach Bequemlichkeit auswählen	„Ich mache einen Fragebogen, weil Interviews zu aufwendig sind.“	Zuerst klären, welche Informationen benötigt werden; dann eine geeignete und im Zeitrahmen durchführbare Methode wählen.
Eine Methode nur benennen, aber nicht beschreiben	„Es wurde eine qualitative Analyse durchgeführt.“	Datenauswahl, Erhebung, Auswertungsschritte und verwendete Kriterien konkret erläutern.
Untersuchungsschritte nicht ausreichend dokumentieren	Parameter, Softwareversionen, Interviewleitfaden oder Ausschlussregeln fehlen.	Während der Durchführung ein Forschungs- oder Arbeitsprotokoll führen und relevante Materialien sichern.
Auswahlentscheidungen unklar lassen	Es bleibt offen, weshalb genau diese Datensätze, Personen oder Vergleichsverfahren verwendet wurden.	Auswahlkriterien und ihre Konsequenzen für die Aussagekraft begründen.
Änderungen am Vorgehen verschweigen	Nach ersten Ergebnissen werden Messgrößen oder Daten verändert, ohne dies offenzulegen.	Anpassungen begründen und zwischen ursprünglicher Planung und späteren Änderungen unterscheiden.
Aufwand mit Erkenntnisbeitrag verwechseln	„Die Implementierung umfasst 8.000 Zeilen Code.“	Herausarbeiten, welches Problem gelöst wurde, welche Entscheidungen anspruchsvoll waren und welche Erkenntnisse daraus entstanden sind.

Evaluierung

Typischer Fehler	Beispiel oder Erkennungsmerkmal	Besseres Vorgehen
Die Evaluierung erst am Ende planen	Nach der Implementierung fehlen geeignete Testdaten, Vergleichsverfahren oder Teilnehmende.	Bereits bei der Forschungsfrage überlegen, wie eine belastbare Antwort gewonnen werden kann.
Eine Demonstration mit einer Evaluierung verwechseln	Einige Screenshots zeigen, dass die Anwendung startet und Ergebnisse ausgibt.	Systematisch untersuchen, ob und unter welchen Bedingungen die relevanten Ziele erreicht werden.
Funktionstests als Nachweis aller Qualitätsmerkmale behandeln	„Alle Tests sind grün, deshalb ist die Anwendung benutzerfreundlich und effizient.“	Für jedes Qualitätsmerkmal passende Nachweise erheben. Funktionale Korrektheit, Leistung und Gebrauchstauglichkeit getrennt betrachten.
Ohne sinnvolle Vergleichsbasis urteilen	„Das neue Verfahren ist schnell“, ohne Bezugspunkt oder Zielkriterium.	Mit einer geeigneten Baseline, einer begründeten Anforderung oder einem anderen passenden Referenzmaßstab vergleichen.
Nur günstige Beispiele auswählen	Gezeigt werden ausschließlich Suchanfragen, bei denen das eigene Verfahren überzeugt.	Auswahlregeln begründen und auch schwierige Fälle, Fehlleistungen und Gegenbeispiele berücksichtigen.
Verfahren unfair vergleichen	Unterschiedliche Hardware, Datenbestände oder Optimierungsbudgets beeinflussen das Ergebnis.	Vergleichsbedingungen angleichen oder verbleibende Unterschiede transparent berücksichtigen.
Ergebnisse überinterpretieren	Ein kleiner Unterschied in einem begrenzten Test wird als grundsätzliche Überlegenheit dargestellt.	Schlussfolgerungen an Umfang, Qualität und Unsicherheit der Evidenz anpassen.
Die eigene Lösung selbst bestätigen lassen	Die entwickelnde Person bewertet allein, ob die Oberfläche verständlich ist.	Für Aussagen über die Zielgruppe geeignete Perspektiven einbeziehen; verbleibende Einschränkungen offenlegen.

Typischer Fehlschluss

„Meine Anwendung beantwortet die Anfrage in 300 Millisekunden. Damit ist der Ansatz praxistauglich.“

Die Messung kann eine Aussage zur Antwortzeit unter bestimmten Bedingungen stützen. Ob der Ansatz insgesamt praxistauglich ist, hängt darüber hinaus beispielsweise von Ergebnisqualität, Nutzungskontext, Zuverlässigkeit und Betriebsbedingungen ab.

Auswertung, Diskussion und Schlussfolgerungen

Typischer Fehler	Beispiel oder Erkennungsmerkmal	Besseres Vorgehen
Ergebnisse und Interpretation vermischen	Eine vermutete Erklärung wird wie eine gemessene Tatsache formuliert.	Erst darstellen, was beobachtet wurde; anschließend erläutern, wie sich der Befund interpretieren lässt.
Aus einem Zusammenhang eine Ursache ableiten	„Personen mit Werkzeug X waren schneller; also macht X schneller.“	Prüfen, ob andere Unterschiede – etwa Erfahrung oder Aufgabenschwierigkeit – das Ergebnis erklären könnten.
Negative Ergebnisse als persönliches Scheitern behandeln	Ungünstige Messungen werden weggelassen oder kleingeredet.	Auch nicht bestätigte Erwartungen berichten und analysieren, was sich daraus lernen lässt.
Grenzen nur als Standardfloskel nennen	„Die Stichprobe war klein. Weitere Forschung ist erforderlich.“	Konkret erklären, welche Aussage dadurch eingeschränkt wird und welche alternative Erklärung offenbleibt.
Die Forschungsfragen im Fazit nicht beantworten	Das Fazit wiederholt lediglich die Kapitel oder zählt implementierte Funktionen auf.	Jede Forschungsfrage ausdrücklich beantworten und die Antwort auf die wesentlichen Ergebnisse stützen.
Weiterreichende Aussagen machen, als die Daten erlauben	Ein einzelner Unternehmensfall wird auf sämtliche Softwareprojekte übertragen.	Den Geltungsbereich der Ergebnisse benennen und Übertragbarkeit begründet diskutieren.

Wissenschaftliches Schreiben und Arbeitsorganisation

Typischer Fehler	Beispiel oder Erkennungsmerkmal	Besseres Vorgehen
Die Arbeit als Entwicklungstagebuch schreiben	„Zuerst installierte ich … Danach probierte ich …“	Nach Problem, Begründung, Vorgehen, Ergebnissen und Erkenntnissen strukturieren – nicht bloß nach zeitlicher Reihenfolge.
Grundlagen ohne Bezug zur Fragestellung ausführen	Viele Seiten zu bekannten Technologien, aber kaum Analyse der eigenen Entscheidungen.	Nur so viel Grundlagenwissen aufnehmen, wie zum Verständnis und zur Beurteilung der Arbeit erforderlich ist.
Wissenschaftlichkeit mit komplizierter Sprache verwechseln	Lange Sätze und unklare Begriffe verdecken die eigentliche Aussage.	Präzise und verständlich schreiben; Fachbegriffe gezielt einsetzen und definieren.
Fremde und eigene Beiträge nicht trennen	Es bleibt unklar, welche Architektur, Daten oder Komponenten übernommen wurden.	Übernahmen, Anpassungen und eigene Leistungen ausdrücklich kennzeichnen.
Zu spät mit dem Schreiben beginnen	Begründungen müssen am Ende aus der Erinnerung rekonstruiert werden.	Recherche, Entscheidungen, Methoden und Ergebnisse fortlaufend dokumentieren und früh erste Textfassungen erstellen.
Den Umfang nicht begrenzen	Zusätzliche Features verdrängen Evaluierung und Auswertung.	Notwendigen Kernumfang festlegen und Erweiterungen dem Erkenntnisziel unterordnen.

Selbstprüfung für Studierende

Kompakte Selbstprüfung für Studierende

Vor der Abgabe sollten Studierende folgende Fragen konkret beantworten können:

• Welche Frage beantwortet meine Arbeit?
• Warum ist diese Frage relevant?
• Welche vorhandenen Ansätze habe ich berücksichtigt?
• Warum eignet sich meine Methode zur Beantwortung der Frage?
• Woher stammen meine Anforderungen und Bewertungskriterien?
• Welche Evidenz liefern meine Ergebnisse tatsächlich?
• Welche alternativen Erklärungen oder Einschränkungen bestehen?
• Welche Aussagen kann ich ausdrücklich nicht treffen?
• Was habe ich selbst beigetragen, was übernommen?
• Kann eine andere Person meine wesentlichen Schritte nachvollziehen?