Commit fd9330ff authored by denis.lohner's avatar denis.lohner
Browse files

Moved tips => tipps

parents
BUILD=build
BASE=tipps
default: $(BASE).pdf
$(BUILD)/$(BASE).pdf: $(BASE).tex
mkdir -p $(BUILD)
latexmk -f -pdf -outdir=build $<
$(BASE).pdf: $(BUILD)/$(BASE).pdf
mv $< $@ # atomic
cp $@ $<
.PHONY: show clean
show: $(BASE).pdf
gnome-open $< || open $<
clean:
rm -rf build
# Tipps & Tricks
A collection of practical advice for the students.
Stuff we have to tell again and again.
\documentclass{article}
\usepackage[utf8]{inputenc} % utf8 file encoding
\usepackage[T1]{fontenc} % powerful pdf output encoding
\usepackage[color]{PPaushang}
\usepackage{helvet}
\usepackage{csquotes}
\usepackage[german]{babel}
\setlength{\parskip}{12pt}
\title{Praxis der Software-Entwicklung \\
\Large{Tipps und Tricks}}
\author{%
\normalsize{Lehrstuhl Programmierparadigmen}\\
\normalsize{Karlsruher Institut f\"ur Technologie (KIT)}}
\date{\normalsize{Stand: \today}}
\begin{document}
\maketitle
Manche Tipps und Tricks geben wiederholen wir häufig.
Dies ist eine Sammlung, um nichts zu vergessen
und weniger Fehler beim Erklären zu machen.
\section{Technisches}
\subsection{Versionskontrollsystem}
Wir empfehlen Subversion oder Git,
weil wir als Betreuer damit Erfahrung haben.
Git-Tipps:
\begin{itemize}
\item \href{http://try.github.io}{Interactive Git Tutorial}: für Anfänger.
\item \href{http://gitref.org/}{Git Reference}: relativ kompakte Anleitung.
\item \href{http://git-scm.com/}{Offizielle Git Projektseite}
\item \href{http://eagain.net/articles/git-for-computer-scientists/}
{Git for Computer Scientists}:
\enquote{Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.}
\item Vermeide den Parameter \texttt{--force} bzw. \texttt{-f}.
Häufig schiebst du damit Probleme nur deinen Teamkollegen zu.
\end{itemize}
\subsection{Dokumentenformat}
Wir empfehlen \LaTeX,
weil es sich gut mit Versionskontrollsystemen vereinbaren lässt
und man hier schon für die Bachelorarbeit üben kann.
Office o.ä. ist aber auch möglich.
\subsection{UML Diagramme}
\begin{itemize}
\item \href{http://umbrello.kde.org/}{Umbrella} um einfach nur Diagramme zu zeichnen
\item \href{http://argouml.tigris.org/}{ArgoUML} um auch Code zu generieren und beim Entwurf zu helfen
\item \href{http://www-01.ibm.com/software/rational/uml/}{IBM Rational Software Architect} ist im ATIS Pool installiert.
\end{itemize}
\section{Organisatorisches}
\begin{itemize}
\item Meldet euch so früh wie möglich im \href{https://studium.kit.edu}{Studierendenportal} für PSE (Pr.Nr. 529) und TSE (Pr.Nr. 455) an.
\item Mails an den Betreuer sollten vom Phasenverantwortlichen kommen.
\end{itemize}
\section{Pflichtenheft}
Das fertige (Software-)Produkt wird am Ende der gesamten Entwicklung am Pflichtenheft gemessen (Stichwort Endabnahme).
Stellt der Auftraggeber zu große Unterschiede fest, wird er nicht bezahlen.
D.h.\ schon das Pflichtenheft muss es dem Leser ermöglichen, eine exakte Vorstellung des fertigen Produkts zu bekommen.
Insbesondere müssen \emph{alle} Produktfunktionen und -daten genannt und hinreichend genau beschrieben werden,
(G)UI-Entwürfe sind Pflicht, Bedienelemente müssen erklärt sein (z.B. Menüführung), und der Leser muss durch das Pflichtenheft
wissen, wie er das fertige Produkt verwenden kann (Stichwort Testfallszenarien).
\begin{description}
\item[Musskriterien]
Mindestanforderungen, gehen aus Aufgabenstellung hervor.
Möglichst klein halten.
\item[Wunschkriterien]
Von den Gruppen selbst definierte, zusätzliche Funktionalität.
\item[Abgrenzungskriterien]
Was unterstützt unser Produkt explizit \emph{nicht}.
\end{description}
Beschreibung und Beispiele von Pflichtenheften
finden sich in der Vorlesung Softwaretechnik 1.
Die Struktur muss aber nicht exakt übernommen werden.
Sinnvolle Änderungen könnten sein:
\begin{itemize}
\item Funktionale Anforderungen von Muss- und Wunschkriterien mischen und
durch Layout, Stil, Marker, Icons entsprechend kennzeichnen.
\item
Ein Pflichtenheft darf mehr enthalten als nur einen Katalog an Kriterien.
Das Endprodukt soll komplett erklärt werden,
also könnte Hintergrundwissen aus anderen Quellen hilfreich sein.
\end{itemize}
\subsection{Technisches Schreiben}
Technisches Schreiben ist wichtig für alle Arten von technischen und wissenschaftlichen Dokumenten,
also auch API-Dokumentation, Bachelorarbeit und Pflichtenheft.
Es bedeutet vor allem eine präzise Ausdrucksweise
und widerspricht dabei einigen Regeln,
die man im Deutschunterricht gelernt hat.
Ein paar praktische Tipps:
\begin{itemize}
\item Vermeide Adjektive.
Oft (nicht immer) sind sie unnötig oder
ein schlechter Ersatz für einen ungenauen Begriff.
\item Definiere Begriffe klar und verwende keine Synonyme.
Synonyme lassen offen, ob genau das gleiche gemeint ist
oder nur etwas ähnliches.
\item Versuche konkrete Zahlen und Namen anzugeben.
Vermeide ungenaue Ausflüchte wie:
meistens, viele, oft, möglichst, üblich, jemand, manche.
\item Viele kurze Sätze sind einfacher zu verstehen als wenige lange Sätze.
\item Beispiele machen das Endprodukt greifbarer.
\item Illustrationen minimalistisch halten (z.B. IKEA Bauanleitung).
Eine Information, ein Bild.
Lieber mehrere ähnliche Bilder als ein komplexes Bild.
\item Vermeide Wiederholung, stattdessen Referenzen benutzen.
Wiederholungen haben oft subtile Unterschiede,
was zu Unklarheit und Verwirrung führt.
Bei Änderungen wird oft vergessen,
dass Wiederholungen auch angepasst werden müssen.
\item Versionskontrolle ergibt auch für technische Texte Sinn
und nicht nur für Code.
\end{itemize}
Das Pflichtenheft ist das entscheidenste Dokument
zwischen Kunde und Entwickler am Ende eines Projekts.
Es darf \textbf{keinen Spielraum für Interpretationen} offen lassen.
\section{Entwurf}
\section{Implementierung}
\section{Qualitätssicherung}
\section{Präsentation}
\end{document}
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment